21–30 of 468 posts
I once told a JavaScript guru colleague of mine that I was spending my free time dabbling in Haskell. His response was 'lol, why would you do that?'. His point was that spending time learning things that you're not going to be using directly any time soon is a waste of time. My point was (and still is), that learning such things opens up a completely new way of thinking about problems and potential solutions.
Earlier quoted context omitted.
It's interesting that you talk about bugs, when the OP doesn't make that argument. The OP is very clear, actually: > It didn't mean I was free from logic bugs. (Nothing can do that in the general case!) It did mean that a program which type-checked wouldn't blow up in ways the type-checker said it shouldn't, though. Other than soundness (which is not the same as avoiding logic bugs, anyway), the points the OP raises…
That might be a matter of personal taste. How ones brain is wired. For me, types make code less expressive. I can grasp the structure of a piece of code the easier, the less meta data there is on top of the algorithmic structure.
I code without types. My "proof", that types do not pay for themselves goes like this: Every time I encounter a bug (during coding, testing or in production) I make a note what type of bug it was and how it could have been prevented. Types are way down on the list of what could have prevented the bug. Especially for production bugs, which are the most important of course. It is so rare, that a bug could have prevente…
I find the value of static typing to be more from increasing the ease of exploration and understanding of a codebase than preventing bugs directly. The constraints on how the code you're reading could be being used making building a mental model faster. Not to mention the tooling built on top of the typing that can help with exploration.
Very true and a good thing to remember when discussing static typing.
Hence my beef with them. PyLint (as an example) can deduce and type check your program for you. Why do I need to annotate the types for every single thing? Python is not exactly a weakly typed language if you go down the details.
So if the compiler knows (or even worse in the case of Java: the IDE knows), why do I need to tell it that? Then you end up with the cases of several prototypes for the same function for things that are essentially the same.
I can understand type annotations for documenting interfaces. Those make sense.
I followed a similar trajectory. Types were the bane of my early career. Hideous, extraneous. But really, they're the light at the end of the tunnel once you've worked your way though the dynamic / weak typing minefield. It took me a lot of Python, Javascript, and Ruby for me to get there, but now I'm way more comfortable on the other side. The correct type system is actually way more expressive than not having stron…
The incoherent thinking I see with some people even in typed systems, would make me very scared to let them do the same in dynamic ones.
But I can relate to the pressure to deliver quick results. I found myself burnt out when working on a forecast model around three years ago. The constant "how's it goin'?" tore my attention away from the work, and I'm still convinced I could have delivered a better result.
So, in a way, I agree. In another, I understand the other side of the issue, and I think there are so many less time-intensive tasks going on around engineering that there's often little awareness that something like refactoring a class for better efficiency pays in smaller but compounding ways long-term, with most of the time cost and perceived opportunity cost being immediate and short-term. It's still worth it if you really do the math on the long-term benefit.
Programming languages and their type systems are tools, at the end of the day.
Occasionally, an overwrought system of types will slow you down, or quite possibly make simple changes impossible.
On another day, some other type declaration could save you hours of debugging, or speed up your program by orders of magnitude...
Simply put, I feel that many Java programs probably could happily be replaced by Python or Node JS.
On the other hand, some safety critical UI projects (or at least, some key portions of them) absolutely would benefit from Typescript or Elm.
I wish there was more discussion about when each is a better fit, rather than talking about how much worse A is than B.
Now I focus on things that matter: deep learning, AI, and robotics.
I've never found a valid use case for allowing undefined references, though I suppose it does make the language implementation significantly easier.
Writing tests is not really a solution either. Tests are also code and suffer from the same problem.
I'm grown up with statically typed languages from C/C++/C#/Java and later and didn't know about dynamic languages till recently.
1. Which types are we talking about?
- In earlier static-typed language, the processor-based types `uint64` looked very strict, optimized the code for hardware architecture.
- Having mathematically and ontological correct types is one approach `integer`/`float`/`string`/`datetime`.
- Each type being well defined and each object-class being used as type is another strict approach.
Look at the types of Rust and Kotlin and see the cacophony of decisions made:
- Rust https://doc.rust-lang.org/reference/types.html
- Kotlin https://kotlinlang.org/docs/reference/basic-types.html
2. When you want to implement a method which applies to multiple libraries, you end up writing `fooString`, `fooInteger`, `fooDatetime` etc (or foo(String), foo(Integer)) etc. DRYing is too hard. So you end up writing 10x more methods
3. No you don't avoid `null` checks at all.
4. Generalizations are harder to implement.
5. Interfaces are uglier compared to dynamic languages.
6. The code becomes less readable, not concise and verbose
7. Every new and old typed language is less elegant compared to the dynamic. Look at typescript vs javascript, typescript code is ugly, verbose, non-readable at all.