I have to agree, I've done over 5 years of C# and then went to ruby and never looked back. Static type checking raises the floor on incompetence, but also lowers the ceiling on excellence. I have to admit I don't have experience with the extremes which would be Haskell and Clojure.
The amount of cruft I had to type in C# just to get shit done... It's all implicit in ruby thank god for that.
I never EVER have to check the type of a variable at runtime. I always know its type just by looking at its name. Is it enforced in ruby? Of course not. Ruby assumes I'm an adult and I know that I'm doing.
> Static type checking raises the floor on incompetence, but also lowers the ceiling on excellence.
At 40 years old, I've seen enough of my own incompetence that I'll gladly accept things that can mitigate it. As for excellence, I suppose static typing would have prevented a handful of clever hacks that I did in Python and Lua when I was in my 20s, 12+ years ago. Truthfully though, my memory of that period has faded enough that I'm not sure, and I doubt that any of those hacks were crucial for the products that I was developing at that time. Yes, a type system as primitive as Java's at that time would have felt like a straitjacket. The same might have also been true for C#. But modern static type systems are much more flexible, and I don't think I've rejected a language based on its static type system in the past several years. (I've recently done a project in Elixir, but that was despite its dynamic typing, not because of it.)
I"m guessing by rejecting perfectly valid and correct programs that are unable to be type checked. There is a large space of "false negative" programs that a type checker will reject, but that could be perfectly correct. E.g. compare Python-esque duck typing with nominal typing.
You can have that by using Any as your type if you so wish typically and escape the type system for those rare circumstances.
Also C# suffers a similar issue with what I call "unproductive Java bureaucracy", since it's basically Microsoft Java. Bureaucracy is not static typing. You can also have full dynamic dispatch and still have static typing too.
Tbh I'm conflating multiple things, I've heard a lot of good things about Haskell.
But in C# for example, if the system was not designed with dependency injection and everything being an interface it's very hard to build a test harness since you can't mock anything. Which means everything has to be tested manually. (I haven't done any C# in a long time, maybe it's not the case anymore)
So you have to create an interface and classes for every implementations for every type in the system just so I can change its type dynamically. By the time you're done with all the cruft, you forgot what you were about to code.
I'm infinitely more productive in Ruby compared to C#. But I can understand dynamic languages not being welcoming to juniors, since they can code themselves into pitfalls that will bite them later.
> But in C# for example, if the system was not designed with dependency injection and everything being an interface it's very hard to build a test harness since you can't mock anything. Which means everything has to be tested manually.
I wouldn't have put it like that, but I think I know what you mean. Mocks for unit testing do require that you have defined an interface to implement, which means that every class that you want to be mocked out needs to have an interface extracted. It is extra work. Overall I think the tradeoff is worth it, myself, especially if your IDE can automated extracting an interface. But it is dumb work that a smarter language/type system could avoid.
> [...] which means that every class that you want to be mocked out needs to have an interface extracted. It is extra work.
If you define the interface first, then you can simply copy-paste that into the class definition and off you go implementing it. Hardly any more work at all.
i'm guessing maybe sometimes type checkers make you jump through the hoops to pass, and the OP finds that distracting? To me though, the benefits of type checking far outweigh the cost.
>I always know its type just by looking at its name.
Do you ever feel the names are getting too verbose and it would be great to have tooling that would allow you to get that information on mouse-over instead of having it make your lines almost unreadable?
I mean, there's a reason mathematics have decided to keep variable names short instead of having the names contain all the context.
There is zero real world evidence for that statement. The smartest developers I have ever worked with love types. The not-so-smart ones couldn’t figure out how to use types well and their code was a buggy mess. Not evidence of anything of course but certainly a sample point.
I'm curious, after having done a significant amount of Haskell, I have flipped that opinion. The biggest difference is how the types help make things explicit and clear.
(although, IMO, I think purity makes a very large impact here too)
i have a small side project in clojure [1] and i always miss type checking when working on it. not by much because it's a small project but i am tired of iseq is not a function error.
I sort of think there are two mindsets behind this debate: people that miss the guard rails of a static type system and people that enjoy the experience of iterating quickly in a dynamically typed language. I don't really want to say everyone should pick one side or the other, just that my experience doesn't bear out the claim that "statically typed languages produce more maintainable code". And, the little bit of empirical evidence for this proposition is largely inconclusive: https://danluu.com/empirical-pl/
>and people that enjoy the experience of iterating quickly in a dynamically typed language
Programmers spend more time reading code then writing it.
So I personally prefer the devs in the team will spend more time typing the code or use a bit more brain energy to think about types so later we can all read the code and understand it and edit faster.
People always say this about reading code and it’s just never matched my experience working in either sort of codebase: one difference (comparing lisps and, say, Typescript or Java) is that lisps just have fewer lines to read. So, any assistance you get from the types is counteracted by having to read more code.
But, additionally, I just don’t find it true to my experience that it’s easier to read and understand a dynamically typed codebase vs. a statically typed one. Especially when you have a lisp-like environment that makes accurate jump-to-definition possible.
EDIT: I think I just tend to think about codebases in terms of operations rather than types. And, consequently, when I build a codebase around compositions of functions, the way I think about it isn’t very different in either paradigm.
1 we have a simple problem I implement a simple elegant solution
2 some new feature is added, this means there are some special cases now, most of the time someone else in the team adds this new feature , so 4-5 different places are modified, functions need to get more parameters and some IFs are added in those 4-5 places
3 later a new feature is added again, a few more extra special cases again , the dev will again go add some more function parameters here and there , add more IFs but fails to find where all the places that might need to be modified are.
4 things are now a big mess, I have to fix it, and I now have to read all the code, my own old code that was changed with different exceptions and the other developers code.
I spend a lot of time on reading stuff, understanding how stuff works now, understand why this new code does some stuff then I spend the time abstracting again a solution, abstracting all the special cases. After I have a solution in mind comes the refactoring, with static types or type hints is much easier to find where stuff is used so you know what to modify.
I am sure one some projects where maybe there is only 1 or few devs that all write quality code and there are no new requirements that need implemented ASAP the code could stay more readable but this is the exception unfortunately.
Is it possible to elaborate in a comment? Honestly I probably wouldn’t take the time to read a lengthy article, but if there’s some elevator pitch then I’m all ears.
What makes CL/Clojure really work is that your editor (emacs usually, but there’s other options now) connects to the live program and has access to the entire runtime environment. So, you can do a lot of the things other languages need static types for via introspection (e.g. autocomplete: CL just asks the running program what functions are available that matches the current pattern and returns a list).
Secondly, since I’ve learned statically typed languages, I already have a mental model for how they make you structure your code, except dynamically typed languages make patterns easy that would require something like dependent types to check (see how complicated Typescript is, because it has to be able to model JS idioms). My experience is that a lot of the value of static types isn’t in the checking but in the modeling aspect: if you follow the general patterns you’d use in Haskell (represent algorithms like “apply a function to each member of the list” as functions), you reduce the amount of thought it takes to see the program is correct by splitting it up. For example, if I have this pattern in my imperative codebase:
let result = []
for (let idx = 0; idx <= input.length; idx++) {
result.push(input[idx]+1);
}
return result
I have at least three things mixed up together: accessing each member of a list (and there's an easy to miss off-by-one error in this implementation), transforming that member and building up a result. If I translate this to a functional style, it's easier to see that the implementation is correct:
const inc = v => v+1
. . .
return list.map(inc)
Looking at this code, I can break down correctness into three questions: is list.map implemented correctly? is inc (the transformation) implemented correctly? And, assuming both are correct, are these two functions combined in the correct way? Types definitely can help here but my experience is that 90% of the benefit isn't the _checking_, it's the code structure you end up with as a result.[1]
Now, if this is true, why do I prefer dynamically typed languages? Well, it comes down to two things: I find the "live programming" model of CL/Clojure more productive and roughly equal to types when it comes to checking correctness (and I don't think it's just me, I've seen various papers, etc. that claim Haskell and Clojure have roughly equal defect rates); and, I find the patterns I like in CL/Clojure/Javascript require much more sophisticated type checkers to actually validate, and such type-checkers have a huge up-front learning cost and still add a lot of boilerplate that exists mainly to convince the type-checker that you know what you're doing.
Finally, in a language with macros, you can roll your own static guarantees: one project I worked on was doing a bunch of calculations inside a database. We hit an edge case where the DB's idea of a week didn't match our requirements. As a result, I wrote a code generator that generated Clojure functions and DB queries simultaneously. In this situation, if you assume the code generator is correct, you have a compile-time guarantee that the Clojure versions of the queries are equivalent to the calculations being done inside the DB.
[1]: This page surveys a bunch of studies on the question of dynamic v. static types and finds the evidence in favor of static types to be surprisingly small https://danluu.com/empirical-pl/
> This page surveys a bunch of studies on the question of dynamic v. static types and finds the evidence in favor of static types to be surprisingly small
Most of the studies seem to be rather poor though, so difficult to draw any solid conclusions from them. Almost all seem to drown in noise, or have flawed setups.
From personal experience, with a static type language I can jump into an unknown codebase and make non-trivial modifications much, much faster than if it's a dynamic type language codebase.
I've wasted soooo many hours doing print(dir(x)) in Python it's far beyond funny.
On the flip side, over the years I've helped countless people with their C/C++/Delphi code in minutes, frequently using libraries and API's I've never seen before.
Yeah, the evidence here is mostly anecdotal but, while we’re trading anecdotes, I think you have to distinguish Smalltalk/Clojure/Common Lisp from other dynamic languages. Most dynamic language essentially work like statically-typed languages without typechecking: you put code in a file and then run it all at once (or run unit tests) and see what happens. The languages I mention actually bring your development environment to runtime (twisted manhole and pry are the closest things I can think of here) so, you don’t have to run the whole thing, you can just run the parts you care about and see what they do.
That being said, my experience isn’t the same: I’ve been able to make helpful changes to dynamically-typed codebases in roughly the same amount of time as to static codebases. I’ve never really identified what it is about how I approach code that makes a difference here, but I think it is because I think about changes in terms of operational equivalence (e.g. l.map(a).map(b) === l.map(compose(b, a)) ) rather than in terms of data types.
This is actual JavaScript code, from one of my projects:
function processAudioData(data, callback) {
// dump audio data to WAV file
}
It's implementing a callback from a library.
Even reading the source code of the library I had problems figuring this one out. Had it been say C# code I'm pretty certain I would have had it done in seconds.
How do you solve this in seconds? I'm genuinely curious as this is something I often struggle with when having to use say Python or JavaScript.
I could see a statically typed language that would give you a live reflection system and macros. I think it's more if you have to chose, you'd rather have that than static types.
But I think it is possible to have all 3, it just doesn't exist in any popular language that I am aware of.
The problem is that the “live programming” aspect violates a fundamental assumption of a lot of static type systems: the “closed world” assumption that all the relevant types are known at compile-time. If you can dynamically extend/redefine the types on the fly, your type-system guarantees start getting weaker anyways. Instead, you need a system of contracts or something like Racket has.
Also, if you have macros, you can always just embed a Haskell into your language for the parts where you want that sort of guarantee: https://coalton-lang.github.io/
The amount of cruft I had to type in C# just to get shit done... It's all implicit in ruby thank god for that.
I never EVER have to check the type of a variable at runtime. I always know its type just by looking at its name. Is it enforced in ruby? Of course not. Ruby assumes I'm an adult and I know that I'm doing.