I love that "late binding" is listed as a flaw. Some would call that a feature. Those of us in the "some" must be wired a bit differently that the "early binding" crowd, I guess :-)
How can deferring checks of correctness to runtime be considered a feature? Haskell has an option to defer type errors to runtime, so I don’t see why early binding wouldn’t be preferable, since you can have it as you like.
My life quality has increased substantially since switching from Python to Haskell, and no longer getting runtime crashes saying “AttributeError: <x> has no attribute <y>”.
"How can deferring checks of correctness to runtime be considered a feature?"
Correctness is not something that matters in the real world. Even defects don't really matter. What matters is problems that defects cause. It's a subtle difference, but very important one. Because you can either limit the scope of those problems at runtime or try to make sure that there are as few defects as possible to cause problems in the first place. First approach doesn't force you to specify anything to check correctness for, is flexible, productive, prepared for the real world. Second approach is much less flexible, much less productive, doesn't work well in the real world, where things fail not only because of defects, but by nature. So, this is how it can be considered a feature.
(While writing this I realized that Roboprog probably meant late binding as a feature from OOP, where it is considered necessary for OOP to even exist, not reliability.)
> Correctness is not something that matters in the real world. Even defects don't really matter. What matters is problems that defects cause. It's a subtle difference, but very important one.
What, exactly, do you consider the difference between these two?
To me, saying ”correctness doesn’t matter” is equivalent to saying “it doesn’t matter whether your app does what you want it to do”, which makes no sense to me.
I think there are two different definitions of "late binding" in play here. The footnote makes it clear that the author considers C++ not to have "late binding"
> Early binding allows for static verification of the existence of method-signature pairs (e.g. v-tables). Late binding does not give the compiler (or an IDE) enough information for existence verification, it has to be looked up at run-time.
Disclosure: using JS for UI work, not nuclear reactor controls. Hate reading reams of verbose, flabby, painfully explicit, long, statically typed (often believed to be "self documenting", as well), code. Prefer short, intuitive code (and LESS of it, but with explanations of context and "why") for non safety critical work.
Haskell's syntax is very terse, but Haskell codebases can still be more verbose than JavaScript ones because the type system actually makes you think about things like error states. JavaScript is definitely more verbose when you write code for all paths and not just the happy one, but doing so seems far less common in practice than it ought to be.
Another angle on the parent comment is that Roboprog hasn't been exposed to statically-typed languages with good inference. It sounds like they're mostly complaining about type annotations, but at least in Haskell you can get quite far without having to annotate anything.
I love that "late binding" is listed as a flaw. Some would call that a feature. Those of us in the "some" must be wired a bit differently that the "early binding" crowd, I guess :-)