Live data from Hacker News

All Programming Languages are Wrong (2018)

users.rcn.com

51–60 of 79 posts

Re: All Programming Languages are Wrong (2018)

#51
post #7

Computation is not almost free and people are doing just fine writing slow code without the language helping them. Taken that we've more or less stalled with regards single core performance, I'd argue that computers are now getting slower (because software is bloating faster than single core performance is increasing).

> Computation is not almost free...

In the vast majority of cases, it is. He's talking about the ALUs actually performing work, as opposed to waiting on memory. He rightly points out that cache misses make the biggest performance impact on modern systems. Most languages these days do not address this, there's tons of indirection by design.

> Taken that we've more or less stalled with regards single core performance, I'd argue that computers are now getting slower (because software is bloating faster than single core performance is increasing).

Again, if you can actually give your ALUs enough work to saturate them, your problem is most likely embarrassingly parallel, in which case single-core performance is not the bottleneck. Otherwise, you will want to optimize for memory access.

Re: All Programming Languages are Wrong (2018)

#52

What a bunch of bs. There are so many places where computation is far from free and size matters (embedded, HPC for example). And the end of Moore law is just gonna emphasize the need for performance even more. This article just tells me that the author didn’t have to write any performance critical code in his life and he just extended his experience to everything

> There are so many places where computation is far from free and size matters (embedded, HPC for example).

The amount of code where the cost of actual computation isn't vanishingly small relative to memory access is so tiny, it arguably should not dominate the design of a general purpose language.

This wasn't true forty-plus years ago, when these languages were designed, and it's not true on some microcontrollers, but it's generally true today.

The author is completely right in that general purpose languages do virtually nothing to optimize memory access (which is a hard problem), as opposed to optimizing ALU usage (which is relatively easy).

Re: All Programming Languages are Wrong (2018)

#54
post #27

The author has a good point, although he miscommunicates it: The common use-cases, such as servers, business logic, glue code, etc., don't usually require hyper-optimized performance. It only needs to be reasonable and predictable. They need a language that is easy to work with, and share with others, and there are few that really do that. But of course, there are. Go, Python, Julia and others I'm sure, all prioritiz…

> But of course, there are

Your statements are contradictory.

> they might one day actually become faster

faster compared to C/C++ ? Of course, Performance is improving day by day. What's the point?

Re: All Programming Languages are Wrong (2018)

#55
post #6

Pretty vague and empty argument (rant?). Doesn't really say anything I haven't seen complained about (and disputed) elsewhere and doesn't really propose any actual solutions.

> ...doesn't really propose any actual solutions.

The proposed solution is the language he designed:

http://users.rcn.com/david-moon/Lunar/introduction.html

Re: All Programming Languages are Wrong (2018)

#57
post #20

Earlier quoted context omitted.

I used to think so, but * Java also has unchecked exceptions, and, incredibly, there's still no consensus as to which exceptions should be used for what and when, though these days the most common approach is to simply stick only to RuntimeExceptions, which is terrible. * Functional error handling using Option, Either, Try etc are arguably much simpler, safer and more powerful than exceptions. Simpler because they do…

Slightly off topic, but what should a map or flatMap implementation on boolean do? Presumably run on true and skip on false? That’s not really what I expect from map (that it’s filtered the input). I could imagine book.filter.map as a way to conditionally execute

I rather like that, `if condition` is a 0/1 iteration with no input. flatMap can return empty, what should map return when run on false, None?

Re: All Programming Languages are Wrong (2018)

#58
post #2

Hmm...BCPL isn't from the 50s. C++ isn't from the 70s.

Nitpicking. Fortran was designed in the fifties, the precursor to BCPL was designed in the early sixties, and C++ (C with classes) was originally designed in 1979, heavily influenced by Simula which also dates back to the sixties.

The time of the design of the language is different from actual implementations being made available. C++ compilers were pretty much unusable until the nineties.

Re: All Programming Languages are Wrong (2018)

#59
post #16

Does anyone else consider these type of articles the clickbait of the programming world? They tend to all follow the formula of 1. Make over the top statement in title. 2. Vaguely address the over the top statement in content. For example the author hasn't shown us why "All" programming languages are "wrong". They haven't shown how they would fix them to make them "right". Their premises (e.g. "computation is almost…

I simply agree with what you said. "Computation is always free" made me cringe as well. I also felt that the initial page is abruptly stopped without giving any kind of explanation.

Then clicking next you get jumped into a new language implementation : /

Re: All Programming Languages are Wrong (2018)

#60
post #7

Computation is not almost free and people are doing just fine writing slow code without the language helping them. Taken that we've more or less stalled with regards single core performance, I'd argue that computers are now getting slower (because software is bloating faster than single core performance is increasing).

I just watched a talk from Bjarne Stroustrup who told about a biologist who was getting data using python. It's script had to run for 3 month to get that data.

The script was re-written and they got it right into 10 min exec time when he couldn't do it in 3 months anymore

https://www.youtube.com/watch?v=fX2W3nNjJIo&feature=youtu.be...

Post reply on HN