Live data from Hacker News

A few good ideas in programming languages

prydt.xyz

71–77 of 77 posts

Re: A few good ideas in programming languages

#71

> Borrow Checking It's very confusing name for this feature. It suggest that some sort of borrowing takes place and that it's just an optional check, which isn't the case. It should be named something like "enforced static usage analysis" instead. In my programming language I have similar mechanism. But it isn't just checking, since it affects code generation by tracking which variables are still in use and which can…

> It suggest that some sort of borrowing takes place

It does. A value is passed by reference, borrowing it from the owner.

> and that it's just an optional check

I don't see how the word "check" implies that it's optional.

Re: A few good ideas in programming languages

#72

Earlier quoted context omitted.

Programming language innovation is measured in decades. I expect LLMs will make it easier to prototype new concepts, but adoption will still progress on a human timescale

The marketing pitch for these things was that they were supposed to induce "cambrian explosion of creations". That there was zero barrier to building anything anymore. This is surely true in programming languages especially, considering how fast LLMs took over software development? Surely this would mean we would get new ideas faster if that was the case? There is literally nothing stopping language designers from ge…

> That there was zero barrier to building anything anymore. ... Surely this would mean we would get new ideas faster if that was the case?

No, of course not. The point is that the tools comprehend the idea and implement it. Not that they have the idea for you.

Re: A few good ideas in programming languages

#73
post #27

I wonder how soon until we see a language designed for LLMs. I wouldn't be surprised if Anthropic or OpenAI were working on something like that. No idea what it would look like, but it's pretty likely that "optimized for humans" and "optimized for agents" are not identical. For some class of problem, we really don't need people to be in the code, and I expect that surface area to continue to expand. Something that is…

> but it's pretty likely that "optimized for humans" and "optimized for agents" are not identical.

Why?

> we really don't need people to be in the code

Code exists for humans, if only for safety reasons.

Re: A few good ideas in programming languages

#74
post #64

Could someone explain the appeal of flow typing? I can see how it can be useful to start with a broad type, e.g. a union, and narrow it down in a block. However, I don't quite get the opposite direction shown in their example (first an int, then a string, then a union).

Same rationale as flow valuing. Some people like values being reassigned, and some people like types being reassigned.

You might be reading too much into the union example. The checker just doesn't know if the middle block ran, so maybe it remained an int, or maybe it became a string.

Re: A few good ideas in programming languages

#75

Earlier quoted context omitted.

I (briefly) used Eiffel in the 1990s. It had some of, if not the, worst tooling I've ever experienced for a programming language, and I've used COBOL compilers and MVS. A pretty nice language, but the software tool support initially was appalling.

That was due largely to the designers of the language, Bertrand Meyer and his wife, creating the tools. The tools, the seminars, and the books were primary income streams.

Interesting, I wasn't aware of that, although it certainly felt like academic-grade code, which someone once described to me as "thrown together by a caffeine-crazed grad student at 3am and run on at least one test case". It's a real pity because there were some really good ideas in there, but the required tooling would have been just too much for just two people to assemble out of whole cloth.

Re: A few good ideas in programming languages

#76

For pedantry, should we note that design by contract came all the way from Eiffel ? (But it's possible that even less people ever wrote Eiffel than D, so, who knows)

I (briefly) used Eiffel in the 1990s. It had some of, if not the, worst tooling I've ever experienced for a programming language, and I've used COBOL compilers and MVS. A pretty nice language, but the software tool support initially was appalling.

Did you mean EiffelStudio ? What was the painpoint at the time ?

I've only played with it 20+ years ago (a colleague was one of the few practitioner) and I don't remember EiffelStudio being _that_ terrible (it has a class browser that was not that much more horrible than Eclipse at the time) - but again, I only dabbled.

Now, I have to agree that the way they market the IDE as the best thing since bread came baked is kinda cringy..

Re: A few good ideas in programming languages

#77

Earlier quoted context omitted.

I (briefly) used Eiffel in the 1990s. It had some of, if not the, worst tooling I've ever experienced for a programming language, and I've used COBOL compilers and MVS. A pretty nice language, but the software tool support initially was appalling.

That was due largely to the designers of the language, Bertrand Meyer and his wife, creating the tools. The tools, the seminars, and the books were primary income streams.

Do you mean they created the tools to be unusable, so that they would get training contracts :D ?
Post reply on HN