Yeah exactly, we all know that the most used programming languages like Python and Javascript are way too focused on performance.
All Programming Languages are Wrong (2018)
21–30 of 79 posts
Re: All Programming Languages are Wrong (2018)
#22IMO 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…
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 ?
That is what it is, a branch at the type level that the type checker mandates you complete both sides of.
Re: All Programming Languages are Wrong (2018)
#23> 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.
Re: All Programming Languages are Wrong (2018)
#24I can't agree about the dot.
Dot makes it easy to chain things left to write, and also almost always dot based syntax is more readable than stuffing all arguments in parenthesis.
xs.delete(x)
vs
delete(xs,x)
And virtual / regular function distinction exists in performance centered languages for a good reason. Either you have to go out of your way to prevent dynamic dispatch or use clunky function pointer syntax and manage vtables manually. Similar can be said to many features he complains about.
Re: All Programming Languages are Wrong (2018)
#25IMO 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…
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%...
Re: All Programming Languages are Wrong (2018)
#26Does 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…
"computation is almost free" actually triggered me. that's the java argument from 20 years ago, now we have go and rust. it implies electron is actually a sane approach to ui development.
the author is very vague about why exactly numbers don't fit in the type system, and in which languages. first class types for numbers exist in some languages. is he advocating for default overflow checks, which bloat code size?
Re: All Programming Languages are Wrong (2018)
#27The 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 prioritize comfort over performance. Although, as compilers improve, they might one day actually become faster -- since the user writes more abstractly, there is a wider search space for optimizations.
Re: All Programming Languages are Wrong (2018)
#28> For example, one cache miss might take as much time as a hundred add instructions. > Today's languages contain far too many features that do almost the same thing but have slightly different performance characteristics, for example regular and virtual functions in C++. Odd example. Virtual functions help enable certain designs, but avoiding virtual functions is commonly recommended when writing cache friendly code.
Honestly it really hurts the author's credibility.
Virtual functions hurt performance (generally not significantly) but allow for OOP design, in theory to make the program structure more clear/organized. Exactly what the author is supposedly advocating.
Re: All Programming Languages are Wrong (2018)
#29Hmm...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
Re: All Programming Languages are Wrong (2018)
#30Does 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…
"computation is almost free" actually triggered me. that's the java argument from 20 years ago, now we have go and rust. it implies electron is actually a sane approach to ui development. the author is very vague about why exactly numbers don't fit in the type system, and in which languages. first class types for numbers exist in some languages. is he advocating for default overflow checks, which bloat code size?
> the author is very vague about why exactly numbers don't fit in the type system
No, he’s quite specific: “hardware details such as the number of bits supported by an integer add instruction show through in the language semantics.”
Now, it's also true that there are quite a lot of languages where this is not true, e.g., Scheme, Haskell (IIRC with the default numeric settings), Ruby, Python, for instance, and many more have numeric types in core language or stdlib that don't face this problem but don't make them the default for simple numeric literals.