Live data from Hacker News

All Programming Languages are Wrong (2018)

users.rcn.com

31–40 of 79 posts

Re: All Programming Languages are Wrong (2018)

#31
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…

Agreed. Between Lobste.rs and HN its becoming increasingly difficult to filter out worth-while content.

> filter out worth-while content

Isn't that the opposite of the goal?

Re: All Programming Languages are Wrong (2018)

#32
post #10

IMO the biggest problems with almost all popular programming languages are 1) null 2) exception based error handling such that, when you call foo() where foo is String foo(){ blabla } you can get a String, null OR an exception (!!!) and most compilers happily let you treat it as if it only ever returns a String. I hope some day null is no longer a thing, and that Functional Programming types like Option, Either, Try…

I am probably in the minority here but I think Java was on the right track with checked exceptions.

  stream.map(f).collect(…)
is where checked exceptions failed. #map is a generic method that should obviously throw each of the checked exceptions f can throw, but without some kind of generic sum type Java can't express that. Everyone is forced to choose between "can throw any exception" (e.g., Callable) and "can only throw unchecked exceptions" (e.g., Function), each of which spreads virally and punishes anyone using specific throws clauses.

Re: All Programming Languages are Wrong (2018)

#33
post #25
post #12

Earlier quoted context omitted.

Ive thought a bit about this, and how is Option types (which I like and prefer to error checking) really different from the compiler emitting an error when you fail to explicitely check for nulls and stdlib returning nulls when you have one ?

I think it's better, see the other reply at https://news.ycombinator.com/reply?id=22306638&goto=threads%...

[deleted]

Re: All Programming Languages are Wrong (2018)

#34
post #20

Earlier quoted context omitted.

I am probably in the minority here but I think Java was on the right track with checked exceptions.

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

Re: All Programming Languages are Wrong (2018)

#35
post #10

IMO the biggest problems with almost all popular programming languages are 1) null 2) exception based error handling such that, when you call foo() where foo is String foo(){ blabla } you can get a String, null OR an exception (!!!) and most compilers happily let you treat it as if it only ever returns a String. I hope some day null is no longer a thing, and that Functional Programming types like Option, Either, Try…

I am probably in the minority here but I think Java was on the right track with checked exceptions.

Something that Java typically gets the blame for, but was actually introduced in CLU, adopted by Modula-3 and C++ before Java was even born.

And with my .NET hat, I hate having to dig into outdated documentation to discover what exceptions might come my way, so one ends up catching any kind of exception, just in case it might blow, in critical code paths.

Re: All Programming Languages are Wrong (2018)

#36

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).

Even in more typical use cases, it matters: for example performance or memory use can mean the difference between a small or large EC2 instance which has very real cost implications. Or it affects battery life of my phone app. Or between my application feeling fluid or laggy.

All of there’s things have real implications for users.

I very much care when I need a top of the line computer to run some shitty application that should be able to run on 20 year old hardware.

Yet I also understand programmer ergonomics and recently implemented an interpreter for a domain specific language in an already not the fastest language because productivity mattered more to me and correct easy to write domain code mattered more to me. But the point is that it was a conscious decision made after weighing the costs and benefits, not just because I think compute and memory are free. They’re not, this has a real cost for me being able to run it, in terms of servers, but with the benefit that I can replace complex buggy code that took me months to write, with simple easy to understand code that I could write in a few hours (and a thoroughly unit tested parser and interpreter that took a week to write)

Re: All Programming Languages are Wrong (2018)

#37
post #29
post #2

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

yeah that was my immediate thought, stopped reading at that point. BCPL was from the late 60s, most people were introduced to it in the 70s, C++ from the mid-80s

And it was never intended to be used as full programming language rather to bootstrap the CPL compiler, hence the B.

https://en.wikipedia.org/wiki/CPL_(programming_language)

In an alternative universe, had the CPL project not suffered management issues and C would never had happened.

Re: All Programming Languages are Wrong (2018)

#38

> Most current-day programming languages seem to be based on the idea that computation is slow, so the user and the compiler must work hard to minimize the number of instructions executed. Instructions executed is not the only metric to consider! It doesn't makes sense to have loads and stores in the program with all of them having a cache miss. Does the author mean that the memory hasn't caught up with the computati…

There's also energy consumption. Maybe the inefficient implementation isn't noticably slow to me, but i'll be unhappy if it drains my battery.

Yes, there are so many things to consider. Another would be size of the binary..

Different kinds of problems are solved by different languages. Simply rejecting them without stating the details doesn't fly!

Re: All Programming Languages are Wrong (2018)

#39

Earlier quoted context omitted.

I am probably in the minority here but I think Java was on the right track with checked exceptions.

stream.map(f).collect(…) is where checked exceptions failed. #map is a generic method that should obviously throw each of the checked exceptions f can throw, but without some kind of generic sum type Java can't express that. Everyone is forced to choose between "can throw any exception" (e.g., Callable ) and "can only throw unchecked exceptions" (e.g., Function ), each of which spreads virally and punishes anyone usi…

There is no need to get rid of checked exceptions to fix that.

You need generics for exceptions. If the inner function can throw some exception, then it should be possible to declare the stream method that it will throw the same exception.

I believe that the JVM doesn't actually support this, so the reasons were got the horrible situation we're in is because they didn't want to sacrifice backward compatibility.

Post reply on HN