enkiv2

enkiv2, 9 months ago

@markusl
Yes; pretty sure it's related to other tunnel vision / attention type issues.

enkiv2, 10 months ago

@futurebird
Ambient harshnoise

enkiv2, 10 months ago

@vertigo

i'll have to dig into this; there are certainly mechanisms for code sharing that do not involve dynamic linking (like message passing & interrupt service routines) but i'm struggling to imagine a code-sharing mechanism based on linking that's not a variation on dynamic linking (even if it's static linking plus a kind of emulation of dynamic linking)...

enkiv2, 10 months ago

@vertigo

Oh, ok. Yeah, in my head that's a kind of pseudo-dynamic-linking but I'm sure there's some distinction

enkiv2, 10 months ago

@Gwendolyn
'ph' is an orthography we settled on for a strong p in greek (which i think is pi?)

i know there are linguistics people around who can correct me on this, but i think the plosive beginning of the strong p sound slowly disappeared in greek loan words to some other language (maybe latin?) leaving only the fricative end of the sound

enkiv2, 10 months ago

@foone

half the time when people say strong/weak typing they actually mean static/dynamic typing

the other half of the type they actually mean nominative/structural typing

i don't think they ever actually mean strong/weak typing

enkiv2, 11 months ago

@feld
what part of it isn't true? that some professional programmers are trying to use LLMs, or that LLMs produce incorrect code? because I can verify both from experience.

enkiv2, 11 months ago

@feld
maybe not yet. or maybe you're asking it to produce exceedingly trivial code. either way, you must be at least reading and checking it for bugs -- something that's a lot easier to do with code one has written oneself.

that said, you've completely missed the point of my post.

the fact that LLMs perform well enough on code generation that anybody wants to use them instead of coding means that we are doing coding in a fundamentally antihuman, gatekeepy way.

statistical models like LLMs work well in a narrow novelty range (since they are novelty-minimizing engines). that novelty range is well below the one we would want programming to live in.

we're supposed to all be refactoring code to avoid duplication, using third party libraries to avoid duplication of effort, writing code that's dense enough that it can be understood and consulted without putting too much load on short-term memory but spread out enough that new maintainers can reason about it. if we were doing that, LLMs couldn't write code based on arbitrary prompts, because most lines of code would be so specific to their top-level requirements that the only patterns that LLMs could learn would be generic -- it would not be able to do any better than a typeahead that checked the current token against a list of reserved words.

enkiv2, 11 months ago

@drwho

i haven't read enough go code to know how bad it is in practice, though i've written enough to know that some common patterns are extremely awkward and verbose if you do them in a naive way.

i do know that actual-existing java code is horribly and unnecessarily verbose, that writing clean and dense java code is nigh-impossible because of various stylistic rules enforced by the compiler, and that in practice most java programmers are doing a copy-paste-modify loop for development and don't refactor away even completely identical chunks of code.

(i've also seen, in real time, as python gets java syndrome and actually-existing python code becomes unnecessarily verbose and repetitive on average -- mostly a result of an influx of java programmers, poor training, & people taking linters way too seriously.)

enkiv2, 11 months ago

@drwho

part of this problem is probably also not the result of particular languages being poorly designed but the result of people using the wrong language, too.

the correct language for any job -- for code that ought to survive beyond a few hours -- is the one that makes the resulting code as maintainable as possible. part of maintainability is that the important/novel parts of the code should be more voluminous than the unimportant/generic parts -- that the number of characters in a section of code should roughly correlate to how long you ought to be thinking about it in order to understand it.

but in a business context where learning new languages is typically considered an expensive distraction, the correct language for a job is assumed to be whichever language some developer already knows (or worse, whichever language was listed in the job listing). so you get a lot of mismatches between language and problem, all of which make the code unnecessarily confusing and some of which make the code into a monstrosity. naturally, when all the code is super confusing, maintainers and developers chunk differently: doing something that would be 1 line in language X is 500 in language Y, and some slightly different action, which would be a completely different 1 line in language X, is also 500 lines in language Y, 300 of which are near-exact duplicates that due to language affordances can't be easily factored out.

enkiv2, 10 months ago

@mnl @clacke

The thing is, we already have constraint solvers and optimizing compilers.

The common solutions (like template expansion systems) are a nightmare, sure: nobody wants to write m4 code. But if you have a requirement, and you want to generate code to satisfy the requirement that actually works without writing any code yourself, the right way to do this is to use a constraint solver.

Normal code-monkey ecosystems have almost no interaction with the kind of tooling that solves these problems reliably -- they aren't covered in most university undergraduate CS programs, and they were too slow and awkward to use for this purpose when they were originally invented in the late 60s -- but there's no theoretical reason why we can just write formal requirments as prolog & generate javascript or whatever, provided somebody writes an ontology for doing it.

Retaining compatibility with popular and widely-used technical stacks is a killer in this respect, though: prolog is slow because optimizations intended for early-70s hardware (now incorporated into the standard) prevent certain modern hardware features from being used, algol68-like languages (i.e., basically every 'mainstream' language) are structured in a way that makes most tasks unnecessarily verbose but people don't want to learn the 'weird' languages that make these tasks easier, etc. Languages and development tools, outside of the esolang context and the occasional weird experiment like smalltalk, are designed to resemble and interact with the rest of the development ecosystem (and thereby inherit the ecosystem's attitudes and problems).

enkiv2, 10 months ago

@mnl @clacke

like, sure: the individual developer working for some company doesn't have any power over the tech stack, and is forced to write code that's less maintainable than it could be with proper tooling. and furthermore, the proper tooling largely doesn't exist or is limited to unmaintained experiments. that doesn't mean that we should all give up on the possibility of eventually having non-horrifying computing ecosystems.

using an LLM to write code is a lot like cramming for tests: it allows you to pass short-term metrics, which is fine if you don't care about long-term or big-picture concerns, but LLM-generated code is never going to be substantially better than the average piece of human-written code, and the average piece of human-written code is trash

enkiv2, 10 months ago

@wakame @drwho

This is true (and the trend toward using type hints in python code is probably downstream of the influx of java people into python) but many of the elements of 'java syndrome' that have made their way into python don't relate to the type system at all.

(I think we've really overplayed this whole "the most important part of any programming language is the type system" thing. Certain representations of types are powerful in unexpected ways, but using these powers is awkward, and only type system nerds know how. You know what else is unexpectedly powerful but difficult to use? The c++ template system, and every esolang.)

Something like a decade ago, because big data was hype and numpy was a thing, a bunch of people who learned java in college started writing python that's structured like java: a billion tiny little classes that, individually, do nothing, all in a complicated class hierarchy, intermixed with single giant totally-procedural monolithic functions that do all the real work (when the dev gets tired of figuring out the class hierarchy); running linters to enforce somebody else's idea of what good code looks like; integration with big build systems and CICD pipelines. Pretty quickly, you got the kind of code that makes people want to install an IDE.

Python used to be the kind of language where you can write a quick function, naively, that's a couple of lines long, to perform even fairly complex tasks, and that function will typically be longer but more readable than the equivalent perl. Now, it's more like java: a piece of software enforces a list of 'best practices' written by a committee and following those best practices turns a program from four lines of simple understandable code into fifty lines of Extruded Software Product.

enkiv2, 11 months ago

@whitequark @ljrk

Well, they can submit one, but that doesn't mean I'll approve it (or even really look at it)...

enkiv2, 11 months ago

@whitequark @ljrk

It is. I don't think it's a tenable policy for anything other than, like, medical equipment & maybe cryptography.

Those things can have the highly technical and supportable aspects modularized out, though.

enkiv2, 11 months ago

@whitequark @ljrk

My policy is that any software development I do in my spare time is for me, and while I allow everybody else to have it, I don't owe them anything.

So -- "maintained" or "unmaintained" is more of a spectrum. How many years has it been since the last commit? Do I actually remember this section of the code? Is the problem interesting? All of these are factors in what the binary "maintained" / "unmaintained" means.

enkiv2, 11 months ago

@whitequark @ljrk

Yeah, software quality is generally quite bad -- proprietary is no better than open source on this. The bar is extremely low on doing better than average here.

I suspect that much of the problem is organizational: how do we think about what a program is with respect to who uses it, and how would we do that differently if we wanted to invite users deeper into the development process -- what kinds of possibilities would that open up for us. I think that a lot of software can afford to be bad (software that performs a task acceptably enough for its developer's purposes) and some software needs to be extremely solid (like cryptography, statistical and mathematical libraries, core OS functions), and we don't distribute the workload in a sensible way.

This belief might be a little self-serving: if I take it seriously, then the correct response is not to make Extremely Solid Applications (which I find kind of tedious) but to write polemics (which I enjoy immensely), make Extremely Solid Libraries (which I find fun), and design New Languages (which I also love).

enkiv2, 11 months ago

@sidereal @feoh @smyth

I fairly regularly use the text-based client tootstream, & I wrote the TUI client Fern (though some python version compatibility problems are plaguing it right now). There's also the (graphical but minimalist) web client Brutaldon.