Comment by meetups323 | Hacker News Reader

Comment by meetups323 | Hacker News Reader

Parent Full thread

The author seems to completely ignore the possibility that language designers get better at designing languages over time, and people simply prefer to develop new projects in well-designed over poorly designed languages.

This to me seems to be the null-hypothesis, and I see no evidence on the page that use in "greenfield projects" vs "brownfield projects" provides any more indication than a simple underlying "well designed" vs "poorly designed" metric.

For instance: why do people dislike Objective-C but like Swift? Could it be simply that Swift was expressly designed to ease pain points of Objective-C? Or is it, as this author claims, that Objective-C is in more legacy projects and if Swift were to have been invented first then replaced with Objective-C, people would suddenly love Objective-C and hate Swift? Same reasoning holds for C/Rust, VBA/Python&TS, Assembly/LiterallyAnythingElse [1], Java/C# [2], and R/Julia.

[1] I imagine if this author were to have been around to write this in 1980, they'd make a claim something like "People say the enjoy C projects more then Assembly ones, but in this essay I describe how this is actually just because Assembly is more likely to be used in existing codebases, and if Assembly had come around after C people would certainly prefer Assembly and detest C"

[2] Note C# is incredibly enterprise/legacy, yet well-designed. This supports the null hypothesis perhaps the most.

I'm the author. Its not as if I've never heard anyone say how amazing new language X is. That seems to be about the only thing I do hear.

I love programming languages and play around with them all the time and have interviewed creators of programming languages. Clearly there is progress being made in the field of programming language design.

The article was saying that you can't necessarily take people opinions in the SO survey at face-value when considering programming languages that are still in a honeymoon phase. There are no 15 year old Julia code bases. Once you have taken over a large code base in a language and have the experience maintaining it that is something else.

I think your perspective have all to do with experience. My younger self used to see new languages as magic wands, secret recipes that would make my code lead me to new things and discoveries.

Now my modern self understand how naive i was, and that actually man-years, algorithms, experience and resilience are super important, all that of course with a good sense of opportunity and also luck to make the right thing on the proper time (nor before or after).

Reading codebases of others, with pearls collected over the years of how to do well some things in particular fields gives you a bigger perspective that as long you are able to choose the right tool for the job, the quality and excelence of the final product will depend much more of this experience than of the programming language chosen.

The ecosystem around the language also matters a lot. For instance other languages might be more suitable or performant than Go in cloud, distributed and server computing. But the fact that you will have a great ecosystem giving the language community will make new projects more likely to succeed even if other languages might be better in performance or memory footprint for instance.

The most upvoted comment in this section for instance is in denial and trying to validade the hype. Because theres nothing more comforting than feel good emotionally about something, and the people that also have gone through this and know what you are experiencing, that warns you about it, are perceived as enemies. Because you are breaking this "feels good" cycle, so you must be the enemy right?

(But the thing gets me a little scared about is that the last hypes have been much more ferocious, reminding a lot religious cults dividing people between the ones that believe and the ones that does not)

Yeah, this seems like one of those "correlation is not causation" situations. If you noticed that languages many people loved were correlated to languages that were used for new projects, it seems crazy to eliminate "loved language causes people choose it for new projects" in favor of "people choose it for new projects causes loved language".

The article makes the observation that "loved languages don't have legacy codebases". Also, using Ruby as an example, it postulates that "once a language has enough legacy codebases, it stops being a loved language".

Except it mentions C# as a loved language, which far up there in terms of legacy/enterprise-y.

I suspect there are two C#s in play here - the original C# in which many legacy/enterprise-y codebases are written, and the C# on .NET Core which is a fairly new ecosystem.

I wonder what the 'ugh factor' is for old C# code bases vs those in other languages.

I've never had to maintain legacy code before, and I would prefer any language on the green list to any language on the brown list (right tool for the job aside), aside from Python and maybe C#. I know there are plenty of students and hobbyists who feel the same.

I think the author is thinking too hard and overstating their results.

> I've never had to maintain legacy code before

If you didn't mistype your comment, it's super funny.

So in a discussion about programming languages and software maintenance, you comment saying that you've never had to maintain legacy code? :-))

I mean, if I've never had to maintain legacy code then my opinions on any given language are completely uninfluenced by the "honeymoon period" factor that the article is about, yeah?

In the argument of which is the best pet, Guinea Pig vs Squirrel, having owned none of them, I'd also be completely "uninfluenced by the honeymoon period" of owning them as pets.

But I'd probably just call myself, maybe less politely but probably closer to the truth, clueless about owning small pet rodents :-)

They have owned both a Guinea Pig and Squirrel, just never an old diseased one.

You make a good point about analogies.

But since we were discussing about what the best way to raise them so that they avoid most old age diseases, I guess that takes us to square one :-)

But they're also just uninformed about the subject, generally, no?

The subject is about why the stack overflow most loved programming languages tend to be recent. The article argues that because developers don't like legacy code, their impressions of languages used in legacy codebases are tainted. The subject is distinctly not about what languages are best in legacy codebases.

I have written code in many of the languages on the list, green or brown, and in a few of them I've worked with large codebases not written by me. I wouldn't consider any of them legacy though since they're fairly recent.

I am also a person, so I have preferences about the languages I write in. These preferences are exactly what stack overflow polls about. Because I have not worked on any legacy codebases, my impression of brown languages has not been affected by working on legacy code.

The fact that I, as a person who responded to the stack overflow poll who generally prefers green languages to brown languages, am unaffected by the factor that the author presents as significant, is an anecdata in opposition with the author's argument.

It's true that I'm uninformed about working on legacy codebases, but that's not the subject that my initial comment addressed

You got me thinking, it is somewhat surprising that languages actually didn't get that much better.

Most of the languages on the list are from the early 90s, and while there are some newcomers, it is not like they are winning by a landslide. And it interesting that you put Python after VBA even though Python came first. And in the article Haskell is "green" even though it dates back from 1990.

One would think that modern languages, designed for modern computers, with decades of accumulated knowledge would completely obsolete older languages, but no, new projects, made by people fresh out of school, are still made using languages from the early 90s. In fact, SQL and C, both from the 70s are still strong.

In fact, the only languages that have been obsoleted are from the 60s (COBOL, Fortran, BASIC, ...). They are still in use, but it has been decades since no one started a project with these.

EDIT: and I don't consider assembly to be a programming languages like the others. It is a 1:1 representation of machine code and is tied to the machine. In fact, just saying "I write assembly code" is meaningless if you don't specify the architecture.

I think it's because the last big idea that really shaped programming languages was memory safety/management.

Lots of people predicted in the early '00s that concurrency would have the same effect, but it seems like enough of us work on embarrassingly parallel programs that it doesn't matter that much.

> it seems like enough of us work on embarrassingly parallel programs that it doesn't matter that much.

I'm not sure that's true, it's just that because of the absurd amount of computing resources available, the lack of concurrency doesn't appear to cause business problems, therefore there's been no incentive to solve it.

It is interesting that many of the recent approaches to loads of data rely on inter-computer communication, rather than the intra-computer communication that is concurrency.

Reply on news.ycombinator.com