By the way, about void-safety: for a decade now, Eiffel has been void-safe, meaning a compile-time guarantee of no run-time null pointer dereferencing. It is beyond my understanding how the rest of the world can still live with programs that run under myriad swords of Damocles: x.op (…) calls that might any minute, without any warning or precedent, hit a null x and crash.
—Bertrand Meyer, Why not program right?
I knew this would be exasperating, but really now. At this point, my eyes rolled completely out of my head and I no longer have eyes. ?
References don't just randomly become null without warning. You chose to call a function that might return null, and didn't bother to put in an if or assert when that's a possibility. Typically the exception system catches it if you do miss it.
The Objective-C model of nil messaging just returning nil or 0 was theoretically dangerous, but in practice incredibly useful. Crashing out in Javascript means I have to wrap everything with (x ? x.op() : null) to get the same effect, which might require a lot of temp vars.
Do type devotees actually believe in randomly-appearing errors, or that dynamic programmers just flail our limbs on a keyboard until something manages to pass tests, or do they just exaggerate a rare edge case they saw once, or are they completely fabricating this stuff to justify their waste of time/perversion?
Type systems are self-inflicted BDSM, and it is not self-evident that everyone wants to wear a gimp suit.
@adiabatic That is truly hideous, just what I'd imagined C++ "dynamics" to look like! I dislike Haskell but it is very pretty handcuffs at least.
@mdhughes https://www.boost.org/doc/libs/1_67_0/doc/html/variant/tutorial.html
This is bondage-and-discipline done poorly. Languages that smell like Haskell (including Rust) would handle discriminated unions better than this…
@mdhughes Sure. I've been using some R lately, and it's so frustrating that you have to deploy and run a test just to find a syntax error. IDEs should help, but R doesn't seem to have great support.
@devilgate One of the big improvements in the last decade (2 decades counting Java) are JIT compilers. V8 and Webkit's Nitro run JS faster than many pre-compiled binary languages.
@mdhughes Fair enough. I still prefer to specify the type, I think.
Now, don’t get me started on the lack of a compiler in scripting languages. I think that’s a blog post I’ll soon be writing.
@adiabatic I'm a C, not a C++, how does
anyresolve method dispatch? Or do you just have a giant if typeof/cast tree after pulling something out? somelist.pop().quack() plus or minus some null checking works in dynamic langs…@mdhughes Isn’t the C++ case solved with boost::any which is probably in the STL by now?
@devilgate Or: You tied yourself up so you can only wiggle around enough to put a string in that list, and that's getting you off. And it's dom/sub is when the language designer does it to you. Bjarne has a lotta subs.
@mdhughes The thing with BDSM, though, is that there’s always someone dominating and someone submitting. I don’t see myself being dominated by generics: I’m using them to enforce my will. This
Collectioncan only haveStrings in it, or it’s going to be inserious trouble.@devilgate Java's a little BDSM with Generics, but there are much more dominating and abusive languages now, where it's all but impossible to express free thought and just shove objects in a collection.
@devilgate Well, specifically Eiffel, since that's the linked article. But Swift also bans nulls from normal use (! ? punctuation to do various "wrong" things).
Dynamic objects have a class, but a reference or expression doesn't need to know it, which is what a "type system" is.
@mdhughes You seem to be conflating two things. Having a type system doesnt automatically prevent null references. I mean, some languages may work like that, and that would be great. But to take Java, for example, since it’s he one I know best: checking for
nullvalues is depressingly the norm.That said, I find the idea of setting a variable without specifying — or maybe even knowing — its type, to be... worrying, let’s say.