> Types, abstractions, tests, versions, state machines, immutability, formal analysis, all these are tools available to us in unfamiliar terrain. Use them to taste.
How did people program in Lisp for decades? I like types and such, and have even gone so far as to write Python like it's Rust. But in the end I realized dynamic languages have an appeal for a reason, and by using types all over the place, I was not getting the benefits of a dynamic language like Python.
When context is mostly static, dynamic languages shine. Context could be, for example, the structure of the directory. If I want to read a file and I know that the file exists, throwing a bunch of type checks about file reading operation is just overkill and slows down the development.
Hmm, rarely have I thought types were a burden, rather than help, maybe I’m weird.
Maybe I spend effort in making sure my types are useful and easy to work with, but one previous TypeScript I got to a state where _all_ of my database queries were automatically typed, and all of my requests and responses too, so both input output were guaranteed to be correct bg the compiler, so any bugs or errors that were left were business logic.
It was incredibly liberating - like pairing with someone who was junior but very pedantic. I ended up writing almost no unit test and only having integration level tests, cause the job of those test was mostly covered by types.
And writing the code itself was such a pleasure - you get immediate feedback if your program is correct _as you type it_. The most bizarre consequence of all this to me was writing a program for almost 2 hours, hundreds of lines of code, and then executing it and having it do exactly what you wanted on the first compile. That was both scary but exciting!
One can get over-constrained with types for sure, where you’re sending more time “fighting the types” rather than writing your code. But this is all just learning, once you understand how the typesystem works it all becomes easy to work with.
It was the same story with tests - once I started testing everything- it wasn’t easy to adopt my code to be testable, took effort, but then I learned how to make code pure, move state to the edges, manage dependencies etc, and all of those are useful practices in their own right, regardless if you write the tests or not.
Same with types - schema design and invariants, state machines, edge cases in type conversion and how to lock and manage external dependencies. Sets, unions etc - it became the way I reason about code with of without types and my code is better for it.
I also assume that types would make AI generated code much better _and more reliable_ because of the additional information and structure that it provides, so I recon they are here ti stay.
Regarding programming with a mature static type system:
> It was incredibly liberating - like pairing with someone who was junior but very pedantic.
This is exactly what is happening. To achieve the same level of semantic confidence across a code-base in a dynamically typed language (such as JavaScript, Perl, Python, Ruby, etc.) would take the effort of a diligent junior programmer.
Which, in a way, is what a strongly-typed language compiler does IMHO.
have you worked with java or C#? both are where types sometimes become a burden.
No, you cannot just do something like this:
```
return { data, message: "OK" };
```
you need to declare a class or struct that match the definition. There's mapper and builder everywhere. Adding / deleting 1 column from a datatype can force you to make changes in 5 places due to mapper / builder.
The flip side of this "burden" is that it prevents you from returning an arbitrary data structure that is not expected by the caller and may cause errors further down the call stack if you return the wrong type. The whole point of static typing in the first place is to eliminate this kind of footgun.
As a matter of fact - no I haven’t. My experience with types is TypeScript, Elixir and a bit of Scala.
I always try to have “clojure style” types where I don’t try to be too prescriptive - don’t lock things down if you don’t need to, just the minimum possible types to make sure the code I’m writing is correct, and nothing more - Rich Hicky’s talks on Clojure’s Spec was an eye opener.
I have been told by some java devs though that it is a matter of style - while unconditional it is possible to write java code with much less boilerplate if one uses newer language features and actually tries to hold the cruft at bay. Is that true?
idk, haven't use newer java or C# after 2014-ish, though I think I've read C# has support some dynamic typing, never explore that. Never touch Elixir and Scala too so cannot comment on that.
TS though, the type declaration is amazing with it's union, optional and intersection type!
While not part of the compiler, the dialyzer’s types are quite nice, even if sometimes it is a bit clunky - I’ve noticed that most of the time when I thought it was “wrong” it actually wasn’t and had picked up on some bug / misunderstanding in my code, though error messages could have been better
> have you worked with java or C#? both are where types sometimes become a burden.
> No, you cannot just do something like this:
> ``` return { data, message: "OK" }; ```
Yes, in Java you can:
return new Object() {
String message = "OK";
Object data = itsValue;
};
There are many reasons to dislike Java and it is nowhere near my programming language of choice. The specific semantic deficiency you chose happens to be an invalid one.
Yes you can. C# has had anonymous types since language version 3.0, released nearly 20 years ago; everyone who has used .Select() at the end of a LINQ query has used this.
I quite like Lisp 'cause I can do silly things like:
(defun sum-triplet? (list)
(declare (type List list))
(and (= (length list) 3)
(destructuring-bind (a b c)
list
(and (numberp a)
(numberp b)
(numberp c)
(= (+ a b) c)))))
(deftype Sum-Triplet ()
'(and List
(satisfies sum-triplet?)))
The very next dot point is agreeing with you: "The ideal quantity to use these tools is tiny, much more miniscule than any of us is trained to think".
And I agree tbh. The TS community has turned me off static typing for life. It's just wall to wall bikeshedding from the least productive people I've ever had the displeasure of working with.
Honestly, that explains perfectly why all MS apps have gone from useable if a bit slow or buggy to just unusable buggy messes that crash constantly and make my machine feel like its running on molasses.
It doesn't "explain" it at all (and indeed many of reject the idea that MS apps - in general - are worse. They've had a bad reputation for decades, and that isn't based on nothing).
The actual quality of their apps has significantly degraded over time. Many of their apps which use web-native technologies have become nearly unusable, and I strongly suspect it's exactly because they've gone down this insane road of bike shedding and constant re-inventing of the wheel instead of pursuing excellence.
That's true but that has absolutely nothing to do with types in programming languages; it has more to do with MS's culture of always favouring backward compatibility and never culling any features in every version.
> it has more to do with MS's culture of always favouring backward compatibility and never culling any features in every version.
The new Office suite are unbelievably buggy and slow not because of backward compatibility, but because of numerous useless "features" Microsoft added which made the software essentially bloatware. By the time Excel opens up on my Mac, I can open several Google Sheets and start working.
Has Teams ever been good? From the first time I used it it has always been one of the worst pieces of software I use.
Office seems fine to me - not great software, but I haven't noticed any particular decline (not a heavy user, but have been using it since Word v2 in the 1990s)
And in any case what does this have to do with Typescript and the (over?) use of types?
How did people program in Lisp for decades? I like types and such, and have even gone so far as to write Python like it's Rust. But in the end I realized dynamic languages have an appeal for a reason, and by using types all over the place, I was not getting the benefits of a dynamic language like Python.
When context is mostly static, dynamic languages shine. Context could be, for example, the structure of the directory. If I want to read a file and I know that the file exists, throwing a bunch of type checks about file reading operation is just overkill and slows down the development.