Live data from Hacker News

Why study programming languages (2022)

people.csail.mit.edu

71–80 of 118 posts

Re: Why study programming languages (2022)

#71
post #69
post #65

Earlier quoted context omitted.

GC was a bit earlier. :)

Earlier than the sixties? All elements of OOP were known before 1967, but their combination, which we still use today under the title OOP, appeared in Simula 67 for the first time. I think the first appearance of a GC in literature was in 1960.

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

Re: Why study programming languages (2022)

#72
post #70
post #37

> Usability is similarly ill-defined and hard to measure. Human factors are very well studied and standardized, and there is a well-established discipline called "Human Factors Engineering", which also provides established test and evaluation methods. Human Factors research is considered solid and well-established because it has been built on rigorous experimental psychology and engineering principles developed over…

Honest question: given the relatively niche status of Ada compared to other systems programming languages, and similar diminished levels of popularity for other languages mentioned in this thread (Pascal, Perl), does this really prove that these principles are particularly effective for programming languages? I understand that this is a relatively small sample size, but I feel like that could be just as well used to…

I didn't claim that usability features were "important to the successes of languages designed like Ada". But Ada at least explicitly considered human factors in their design (even if mostly based on expert judgment and established principles, not practical studies), which also seems very appropriate given the criticality of most applications written in Ada. But as my ergonomics professor at ETH Zurich, Helmut Krüger (successor to the renowned Étienne Grandjean), used to say: people get used to even the most ergonomically terrible systems. The "level of suffering" experienced by most people is probably simply not great enough to systematically take such aspects into account. But there are still industries where it is important to reduce the human tendency to make mistakes by taking appropriate measures. Ada was created for such an industry from the very beginning.

Re: Why study programming languages (2022)

#73
post #44

Earlier quoted context omitted.

> Programming languages are obsolete in the LLM era. Wouldn't LLM need to directly output machine code for that to be true?

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?

Re: Why study programming languages (2022)

#74
post #69

Earlier quoted context omitted.

Earlier than the sixties? All elements of OOP were known before 1967, but their combination, which we still use today under the title OOP, appeared in Simula 67 for the first time. I think the first appearance of a GC in literature was in 1960.

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.

Re: Why study programming languages (2022)

#75
post #17

I think that one of the things that they neglect to mention, on why we invent new languages, and it's probably the most important thing - people want new ways to express concepts. It's super important because those concepts get measured, and absorbed into existing languages (as best they can), but that wouldn't have happened without the new languages New concepts like Rust's "ownership model", Smalltalk's "Object Ori…

While those languages made the concepts mainstream, they weren't the ones coming up with them. Rust's "ownership model", is a simplification of Cyclone, AT&T's research on a better C, based on mix of affine and linear type systems. https://en.wikipedia.org/wiki/Cyclone_(programming_language) Haskell's "Lazy evaluation" was present in Miranda, before all related researchers came up with Haskell as common playground. h…

And while Smalltalk may be the first quite "pure" OO language, it by no means invented the concept (you could argue it has a purer implementation of messaging but even some of that was in Simula 67, five years earlier).

Re: Why study programming languages (2022)

#76

I think that one of the things that they neglect to mention, on why we invent new languages, and it's probably the most important thing - people want new ways to express concepts. It's super important because those concepts get measured, and absorbed into existing languages (as best they can), but that wouldn't have happened without the new languages New concepts like Rust's "ownership model", Smalltalk's "Object Ori…

> New concepts like Rust's "ownership model", Smalltalk's "Object Orientation", Lisp's "Functional programming", Haskell's "Lazy evaluation", Java's "Green threads"

I sincerely want to ask if this was an ironic comment given the topic? Because obviously none of these core concepts were really new to the languages you ascribe them to.

Re: Why study programming languages (2022)

#77
post #12

Earlier quoted context omitted.

Many new languages are still recycling ideas from the 1970's research labs. Outside affine types, all the praise for Rust's type system traces back to Standard ML from 1976. The heretic of doing systems programming in GC enabled programming languages (GC in the CS sense, including RC), goes back to research at Xerox PARC, DEC and ETHZ, late 1970's, early 1980's. Other things that we know, like dependent types, effect…

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 computer science feel insignifiant by comparison, everything about it is absurd.

The real progress is that now, we can implement the ideas from the 70s, the good ones at least. I don't want to diminish the work of the founders of computer science, there is real genius here, but out of the billions of people on this planet, individual geniuses are not in short supply, but the real progress come from the millions of people that worked on the industrial complex, supply chains and trade that lead to modern GPUs, among everything that define modern computing.

Re: Why study programming languages (2022)

#78
post #54
post #49

Earlier quoted context omitted.

Apart from ADA, what are languages / stacks with most aspects of "Human Factors Engineering" considered?

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 point do the experience gains plateau)- in all this you have to be careful to ask different tasks - since good programmers will abstract when they need to do something twice.

Re: Why study programming languages (2022)

#79
post #72
post #70

Earlier quoted context omitted.

Honest question: given the relatively niche status of Ada compared to other systems programming languages, and similar diminished levels of popularity for other languages mentioned in this thread (Pascal, Perl), does this really prove that these principles are particularly effective for programming languages? I understand that this is a relatively small sample size, but I feel like that could be just as well used to…

I didn't claim that usability features were "important to the successes of languages designed like Ada". But Ada at least explicitly considered human factors in their design (even if mostly based on expert judgment and established principles, not practical studies), which also seems very appropriate given the criticality of most applications written in Ada. But as my ergonomics professor at ETH Zurich, Helmut Krüger…

> I didn't claim that usability features were "important to the successes of languages designed like Ada".

This kind of seems like it's focusing too much on my exact word choice and less the actual intent of my question behind it. The question I have is why following established principles should matter; I don't think it should be particularly surprising that someone might assume that making a language more usable for humans would be related to the number of humans who end up deciding to use it, and if that's not the case, I wanted to understand why my intuition is wrong.

> there are still industries where it is important to reduce the human tendency to make mistakes by taking appropriate measures. Ada was created for such an industry from the very beginning

This is a good point that I hadn't considered; it definitely makes sense to me that some domains might be less tolerant to human errors than others, and those domains would better reflect how well-designed a language is for humans.

> The "level of suffering" experienced by most people is probably simply not great enough to systematically take such aspects into account. But there are still industries where it is important to reduce the human tendency to make mistakes by taking appropriate measures.

Reading this part a couple of times, I think this might be where the nuance lies. My colloquial understanding of what it means for something to be ergonomic (and even by the idea of what"level of suffering" would mean) isn't quite the same as the measurement of how likely it is for something to induce human error. This might just be a case where the common use of the term isn't the same as how it's used inside the field of study, but I would have expected that the ergonomics of a language and measurement of the "level of suffering" would be with respect to the programmer, not the one experiencing the use of the software that's developed as a result. That isn't to say I disagree with the idea that the end-user experience should ultimately be more important, but I think that might account for the disconnect between what you're describing here and what I would have expected from a discussion around "programming language ergonomics" (which also might explain the difference between Ada and the other languages mentioned in this thread).

Re: Why study programming languages (2022)

#80
post #58

Earlier quoted context omitted.

Perl is one obvious one, as anyone will realize, if one has read some of Larry Wall's articles about his (and later the team's) motivations for the (syntax and semantics) design decisions they made about the language. For example, in his annual State of The Onion talks, he often discusses these points. They may not have used standards such as the gp comment mentions, but they definitely considered human factors a lot…

Perl presents a fascinating counterexample: Larry Wall, trained as a linguist, explicitly cared about human factors, but his linguistic philosophy produced a language that empirical tests show performs poorly on readability and learnability measures (see e.g. http://dx.doi.org/10.1145/2534973 or https://doi.org/10.1145/2089155.2089159 ).

I haven't used Perl much, but my impression it is much easier to learn if you already know awk and sed - his original target was people who knew awk and sed well but were running into limitations using the two as separate tools. However the language quickly spread to people who don't know either of the previous tools and then it is difficult to learn.
Post reply on HN