Live data from Hacker News

Why study programming languages (2022)

people.csail.mit.edu

81–90 of 118 posts

Re: Why study programming languages (2022)

#81
post #74

Earlier quoted context omitted.

Did Lisp have GC from the beginning? If so, that would be 1958.

I think, the first mark‑and‑sweep collector was published in McCarthy's 1960 Communications of the ACM paper "Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I". It's resonable to assume, that they already had it when Steve Russell implemented the first Lisp evaluator, but we don't know exactly when it was added.

No, that paper doesn't describe the garbage collector. I do think it is true that before it was published Slug Russell had implemented the GC, but I think it's correct that we don't have listings from that early.

Edit: yes, yes it does describe the garbage collector.

Re: Why study programming languages (2022)

#82
post #77

Earlier quoted context omitted.

It seams like most things boil down to ideas from the 70's. The internet, distributed computing, AI, etc...

Yes, but ideas are (mostly) worthless. I mean, they are necessary, but that's the easy part, building the technical foundation that make it possible is the hard part. The internet needs wires and routers, distributed computing need a good network (i.e. the internet), current-day AI needs GPUs and GPUs need silicon chips that defy the laws of physics. Really, looking at the EUV lithography process makes all of compute…

As for this measure, Software is worthless as well, which is basically fully specified ideas.

Re: Why study programming languages (2022)

#83
post #50

(2022) This is particularly important here as the essay makes no mention of LLMs or coding agents (which were still in their infancy in development environments; this article is post original copilot/codex but pre ChatGPT).

Yeah. Now the trend goes in an entirely different direction: telling an LLM in natural language what to achieve using those programming languages. How quickly times change. Edit: I assume this comment gets downvoted because people don't like where we are heading, not because they really think LLM programming capabilities won't continue to improve at a staggering pace.

> LLM programming capabilities won't continue to improve at a staggering pace.

The error rate of models make language design, tooling, testing methodology and human review more important than ever before. This demands language evolution. You could get faar with lax testing and language tooling with enough caution and skill. but when LLMs enter the picture, that no longer flies.

we need tooling, static analysis, testing paradigms, language design that restrict how dangerous the LLM is allowed to act.

natural language is faar to fuzzy to replace programming (system specification is already famously impossible thing to do right). If you think it truly will replace code, i highly suspect you work om webbdesign, where testing and reliability was always a secondary concern.

And even then, I think were already on the convergence platoe of LLM code. The companies are raising prices as diminishing improvement and balooning compute costs.

Re: Why study programming languages (2022)

#84
post #44

Earlier quoted context omitted.

They can, trivially, with tool [0] usage. [0] https://modelcontextprotocol.io/specification/2025-06-18/ser...

Ok let me put in the missing implicit words. > Wouldn't LLM need to directly output the correct machine code for that to be true?

zzz..

Re: Why study programming languages (2022)

#85
post #2

I tries to answer the question "Why do we design new programming languages?" but it forgets the simplest of answers: Because we can. Because a compiler is nothing more than a fancy text translator.

Because we can, because it's fun, and because some of us are compulsively obsessed.

Re: Why study programming languages (2022)

#86
post #78
post #54

Earlier quoted context omitted.

Niklaus Wirth designed Pascal (1970) with explicit pedagogical and human factors goals documented in his seminal paper "On the Design of Programming Languages". Wirth explicitly stated his belief that "insights gained from educational considerations could benefit programming language design in general, and that the simplicity and clarity he was striving for should be a guiding principle for all language design, servi…

Human factors studies on programming languages are really hard to do right. It is easy to study someone seeing a language for the first time. However programming well requires a high level of expertise and so the real question isn't how easy it is for a beginner, it is how easy it is for someone who has been doing it for years. Or maybe how much different is someone after a week vs month vs year (that is at what poin…

I think it's not more difficult than identifying representative user groups (at least five members per group) and defining typical tasks for a usability test, focussing on the specific features in question. It's just a lot of work and requires experience and training.

Re: Why study programming languages (2022)

#87
post #81
post #74

Earlier quoted context omitted.

I think, the first mark‑and‑sweep collector was published in McCarthy's 1960 Communications of the ACM paper "Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I". It's resonable to assume, that they already had it when Steve Russell implemented the first Lisp evaluator, but we don't know exactly when it was added.

No, that paper doesn't describe the garbage collector. I do think it is true that before it was published Slug Russell had implemented the GC, but I think it's correct that we don't have listings from that early. Edit: yes, yes it does describe the garbage collector.

The concept of automatic memory management dates back to the 1950s.

However, John McCarthy, the creator of Lisp, introduced the first widely recognized garbage collection mechanism around 1959/1960.

Re: Why study programming languages (2022)

#88

Earlier quoted context omitted.

Realistically? No, not at all. The reason there are no toolchains for BASIC is because nobody uses BASIC (because it's not functional in our modern world), not the other way round.

Why do you think BASIC is not functional? Our modern world does not differ from the 1980 world at all. Variables are variables, subroutines are subroutines. It fall out of fashion, along with Pascal, Perl, Ruby, but that's just fashion.

> Why do you think BASIC is not functional?

Because BASIC simply doesn't have first-class functions, and they would be quite hard to represent in a BASIC-like syntax while keeping the language idiomatic. Even the unreasonably clunky C pattern of having a pointer to a function taking void* as its first argument (to account for closure captures) gets you a whole lot closer to functional programming than even the fanciest BASICs.

Re: Why study programming languages (2022)

#89

Earlier quoted context omitted.

Why do you think BASIC is not functional? Our modern world does not differ from the 1980 world at all. Variables are variables, subroutines are subroutines. It fall out of fashion, along with Pascal, Perl, Ruby, but that's just fashion.

> Why do you think BASIC is not functional? Because BASIC simply doesn't have first-class functions, and they would be quite hard to represent in a BASIC-like syntax while keeping the language idiomatic. Even the unreasonably clunky C pattern of having a pointer to a function taking void* as its first argument (to account for closure captures) gets you a whole lot closer to functional programming than even the fancie…

Here, "functional" is being used to mean "ablity to function", not "relating to the functional programming paradigm".

Re: Why study programming languages (2022)

#90
post #56

> Why do we design new programming languages? The main answer is that we have only a limited ability to modernize existing programming languages. For example, most languages are not null safe, because most languages are old and we can't make them null safe without breaking backward compatibility with most existing code. And we can't break backward compatibility for practical reasons. So Java will never be null safe,…

It's not just 30 years old. It's 30 years of people building libraries of useful code. If you "modernize" it so that much of that 30 years of work is thrown away, that's really expensive - maybe more expensive than continuing to build on a less-than-perfect foundation.

But that turns into the trap of short-term thinking - eventually you reach the point where you would have been better off throwing it away and starting over. You don't reach that in the year you throw it away, though, nor in the year after.

Post reply on HN