41–50 of 79 posts
He claims all programming languages are wrong and then he bashes C++ virtual functions vs regular functions, C++ templates, single dispatch and fixed precision arithmetic. Looks like "all languages" means C++ to him. There exist languages with arbitrary precision arithmetic, e.g. Python or languages with much sophisticated polymorphism e.g. Haskell, Scala or Rust.
Earlier quoted context omitted.
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.
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
Maybe flatMap would return true only if all chained booleans are true?
Bimap would allow you to provide functions for what to do in true and false case?
Fold would allow you to turn true or false into a single type?
I'm sure someone more experienced in FP can weigh in with something more correct! :p
He claims all programming languages are wrong and then he bashes C++ virtual functions vs regular functions, C++ templates, single dispatch and fixed precision arithmetic. Looks like "all languages" means C++ to him. There exist languages with arbitrary precision arithmetic, e.g. Python or languages with much sophisticated polymorphism e.g. Haskell, Scala or Rust.
Floating point numbers are implemented using double in C.
All bets on their precision are off unless you happen to
know the machine you are working with.
Some of his views might be controversial, but he has plenty of Lisp implementation experience and clearly knows his stuff.
And from what I've read so far, he writes excellent documentation. I'd recommend anyone to at least skim the whole thing [0].
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.
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…
"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?
Numbers are hard!
Consider something simple:
9999999999999999.0 - 9999999999999998.0
1. atof() could fail since the string representation doesn’t match the resulting float, but then what should happen for 0.3? I've seen this only occasionally.
2. We could use a hypothetical atonumber() which uses decimal or big float or some other representation, but what does this do to performance? This gets tried a lot.
3. We can ignore the issue and blame the programmer for not constraining the input domain to that of our function. This is what most people do.
I don't personally like any of these; I've seen and experienced some of the problems with each of the approaches, so I wonder if there's a Good™ fourth option (or a fifth). Maybe it's only because I have my own ideas of what a fourth option might look like that I'm not very quick to consider this a "solved" problem to the point that someone (anyone) knows the Right™ answer, but maybe it's worth you (and others!) thinking about this too.
I'm extremely interested in suggestions here.
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.
So this means, you will have a whole bunch of re-throws, or exceptions wrapped in "higher design level" exceptions which you then throw to finally communicate the error condition to the proper component, polluting all signatures on the way with "throws".
Or you catch it as early as possible, wrap it in a RuntimeException, re-throw it unchecked and let the high level component properly handle it, effectively bypassing the "checked exceptions" system :D
Just my two cents, I know this might be a controversial position.