Dynamic type systems aren’t even simpler
hisham.hm
hisham.hm
This has some implications for simplicity but not in the sense that the article tries to argue about. The real benefit from dynamic languages is not that you don't have types, it's that your program becomes more flexible at runtime. This is riskier by definition, but it also has the advantage of not eliminating countless of valid programs that a static language eliminates, or only makes possible through fairly complicated constructs.
>"[...]One day you open that module which you haven’t touched in six months, and you see a function call where the third argument is null. You need to remember what kinds of variables you can pass to that third argument[...]"
You don't need to remember that at all. The issue here is that the author applies the static mindset to the dynamic paradigm. The correct behaviour here is to not 'expect' or take for granted any particular input, but for the object/function in question to on its own deal with whatever input it gets. In Smalltalk style OO you would say it's the object that is solely responsible for the message it receives. That's not surprising but the very essence of late-binding.
In Java, you could have a LinkedList<Object>. You'll need to cast to do any operations on the objects; but, it's a heterogeneous list anyway, so why would you?
There could be a reason, though.
Let's say they all have the same function, then, but they're different objects. Well, for that, you could write a wrapper object that all inherit from the same class, say:
interface Clicker { public void click(); }
public class ClickerWidget implements Clicker {
Widget w;
public void click() { w.click(with_parameters); }
}
But your Java example isn't a true heterogeneous lists, very close but not really. You cannot put instances of value types into it.
Even if it were a true heterogeneous list. You have given up on static typing with such a list and defer it to runtime. Which is exactly the dynamic typing approach.
If you want to do tricky pointer stuff, the Java hack around that is an array that holds the pointer to the value instead; and, autoboxing allows ints into it. It’s a heterogeneous list.
I'd wager that the up and coming inline classes in java also can't be put into a List<Object> but maybe I'm wrong.
At this point, don't you think you're being more than a little pedantic to the point of having a heterogeneous list?
Also the rub is that "type" means two things: what a variable can have OR a class (that inherits from `Object`).
There isn't in my opinion a good reason for this design of Java's type system: https://stackoverflow.com/questions/14477743/why-are-there-p...
Like, chances are, the individual is going to say that Ruby provides that power; but, by the time you've reached Ruby levels of abstraction, the odds of any argument about performance and data marshalling go out the window.
It's a difference without a meaning, as far as I can tell.
If dynamic type systems are like not having pen and paper, then static type systems are like a teacher forcing you to "show your work" by writing every little step on pen and paper, no matter how obvious. What's interesting is finding good middle grounds.
MyObject obj = new MyObject();
can also be expressed as
var obj = new MyObject();
or
MyObject obj = new();
Neither of these were possible in early versions of c# but both are there now.
Type inference, generics and variable shadowing have mostly covered almost all the pain points since. I don't have to declare what's obvious, I don't have to cover irrelevant differences, and I don't have to consider the artefacts of types past.
Still think generics are static typists admitting the shortcomings of a type system, without actually doing so, though.
Wait, what? Any static type person will readily say that type systems have shortcomings (though I'd probably prefer limits or limitations as a word with fewer negative connotations). It's just a matter of which limitations.
This largely jives with my personal experiences using Python, Typescript, Clojure and Scala. This also jives with casual observations of the product landscape, where for every good product built in something like Python, you can find a good product built in Java.
The major problem with dynamic typing is performance. There are not many dynamic type systems added to existing languages which made the language faster. More secure yes. Better documentation via typed signatures yes. Better error messages. But only a few made it faster, by using the available type optimizations. Racket complained, python complained, perl5 complained, ruby complained, everybody complained. I think only PHP and my cperl gained speed with added dynamic types.
The compiler overhead adds to the runtime. With static types you don't care, your compiler and typechecker doesn't need to be Rocket science. With dynamic languages it needs to be. And your paired runtime optimizations, liked typed arrays, eliminated bounds checking, optimized int ops must be worth it. You don't need a jit with types.
"Is Sound Gradual Typing Dead?" https://www2.ccs.neu.edu/racket/pubs/popl16-tfgnvf.pdf
def foo(bar, baz):
if bar == “thing1”
baz.methodFromTypeX()
elif bar == “thing2”:
baz.methodFromTypeY()
Type would be something like:
Union[Tuple[Literal[“thing1”], TypeX], Tuple[Literal[“thing2”], TypeY]]Add in no comments or out of date comments or comments that were always wrong about function inputs and outputs and you get ... frustration.