What are the costs of statically typed languages? The author stated "thinking about the correct types" and "increases compile times" among some other, weaker (imo) costs. What is wrong with "thinking about the correct types"? You are thinking about the same things in a dynamic language, right? For example, say you need to know about things that are "thennable". Weather you are in a statically typed language or not, you are still checking for the same thing: does it have the then() method? The tradeoff is in reading vs implementing code. With a statically typed language, you can easily search for implementers of the Thennable interface and you are guaranteed to be show every implementer. The downside is that you have to write a few more lines of code to satisfy the static typing. With a dynamically typed language, you have to find the implementers yourself, but you can just slap a then method on anything and it will work. I am biased toward static typing so I am interested to hear counter points.
Diminishing returns of static typing
191–200 of 632 posts
Re: Diminishing returns of static typing
#192Earlier quoted context omitted.
I think dynamic typing proponents get hung up on the auto-complete aspect. The real benefit is when you find someone writing a property with a common-ish name to a data structure and you want to know "who the hell uses this", you can answer that question pretty easy in statically typed languages. In dynamically typed languages you kind of just grep and hope the name is not too common.
What are your favorite tools for doing this in C/C++ (which are extremely statically typed, if not very strongly typed)? I think the best thing I've found for this personally is coccigrep, which works but I've only used it a couple of times. I'd like something I'd reach for about as often as I reach for grep. (Also I think these days you'd want it to be based on clang or something.) One thing that does seem to be tru…
I imagine CLion is a popular answer here:
https://www.jetbrains.com/clion/
Re: Diminishing returns of static typing
#193Earlier quoted context omitted.
Definitely. Static typing lets you turn the compiler into a hard-working friend that helps you refactor large projects without going insane. There are no diminishing returns. Defining types is easy and enhances code readability.
Defining types is easy and enhances code readability until you go too far. Some type declarations in Haskell or highly templated C++ are hard to read.
While this is a valid point, it's also worth remembering that if you have a data structure of sufficient complexity that writing out its type is cumbersome, then your data is still in that structure whether you choose to be explicit about it or not. Any code reading or modifying some element within that data still needs to correctly find that element, and if writing out the types is a burden then probably finding the correct location every time is also difficult. So if anything, when you have more complicated data structures flying around, and particularly if you work with several similar but different complicated structures, that could make having the types explicit much more useful for ensuring correctness and maintainability.
Re: Diminishing returns of static typing
#194Earlier quoted context omitted.
I'm so happy to see the pendulum swing the other way, because when JavaScript was becoming popular, and Ruby and Python had a popularity renaissance (around mid to late 2000s), I had a lot of online arguments about the value of static typing. People were complaining about static typing for the dumbest reasons (it's too 'wordy'). It started as a backlash against old-school enterprise Java development (which was fair,…
Typing in Java could be better, sure, but even with its quirks it's way better than the nothing you get with dynamic languages. I disagree; that Java was the standard example of statically typed languages is what convinced me for a long time that I didn't want anything to do with it. Having to pollute my code with all that crap, deal with a lot of dumb restrictions and still have NPEs left me with a sour taste. Only…
Agreed, every time I had to patiently explain to javac that shockingly, my new ArrayList was a List, my new FooBar was a FooBar, and always would be, it drove me slowly mad. Still, I was thankful for the static types when trying to understand where this strange object came from and what it was supposed to do. I’m glad we have modern languages that have the potential to do an even better job of that without a lot of the verbosity.
Re: Diminishing returns of static typing
#195There is one aspect to this debate that is worth pointing out. What about generative testing, which is possible in static or dynamically typed languages? The article mentions that testing is perhaps more important in a dynamically typed language since there is less compiler support. But for example, Clojure rolled out the very clever Clojure.spec library that allows you to precisely specify all details relating to function arguments, data structures, etc, in even more fine-tuned methodology than just types; you can specify that the second argument to a function must be larger than the first, or that a function should only return a value between 5 and 10, etc. These "specs" have the interesting property of being run-time checked or compile-time checked in the form of automatic tests, which can generate inputs based on the specs.
In such a case, the line between these two type environments narrows.
Re: Diminishing returns of static typing
#196What amuses me in all "static typing versus..." discussions, is that it usually it is the comparison between two camps: Camp A: Languages with mediocre static typing facilities, for example: -- C (weakly typed) -- C++ (weakly typed in parts, plus over-complicated type features) -- TypeScript (the runtime is weakly typed, because it's Javascript all the way down) Camp B: Languages with mediocre dynamic typing faciliti…
> Ruby
Ruby has some of the best meta-programming facilities out there. Yes you can't manipulate syntax in the same way as lisp, but the fact that all methods are message passing and first class blocks make tons of very powerful meta programming possible. Basic features that look otherwise first class are based on Ruby's meta programming facilities like `attr_reader` and friends. Funnily enough, the meta programming facilities of Ruby are precisely what turns a lot of people off. The wtfs per minute of using something like ActiveRecord is super high for people with only passing familiarity because there's so much that that's defined through Ruby's meta programming facilities.
Re: Diminishing returns of static typing
#197Earlier quoted context omitted.
I think the idea is that you have to write tests anyway.
No, you don't have to write tests for invariants enforced by the type system.
I think the bigger idea is that people who've never actually written serious code in a dynamically-typed language assume that people who do always write a bunch of extra unit tests to assert correct types, assert behavior on incorrect types, etc. etc., and that programs crashing due to type errors is a super frequent occurrence.
None of those things are true.
Re: Diminishing returns of static typing
#198Earlier quoted context omitted.
I agree that static typing helps reading comprehension and that IDEs like pycharm help getting into big code bases, that said, at the end of the day, when you know the code both the IDE and static typing are getting in the way. Actually, I never saw anybody as quick as people using simple editors like emacs and vim. GUI is getting in the way of the programmers intent. Static typing is a hindrance in front of refactor…
You're kinda damning it with faint praise when you say that you can use dynamically typed languages on small projects that fit in your head (and are also probably written by a single developer). You can pretty much use any language in that scenario. But the chickens come to roost around day 30+ or so.
Personally I'd only use a language like C or C++ or Java for a tiny puny baby child's toy program. They're fundamentally unfit for real-world codebases.
Re: Diminishing returns of static typing
#199Earlier quoted context omitted.
What are your favorite tools for doing this in C/C++ (which are extremely statically typed, if not very strongly typed)? I think the best thing I've found for this personally is coccigrep, which works but I've only used it a couple of times. I'd like something I'd reach for about as often as I reach for grep. (Also I think these days you'd want it to be based on clang or something.) One thing that does seem to be tru…
I imagine CLion is a popular answer here: https://www.jetbrains.com/clion/
Oooh, I've heard of people using it but for some reason I just thought it was an editor. I'll have to give it a try.
Re: Diminishing returns of static typing
#200What amuses me in all "static typing versus..." discussions, is that it usually it is the comparison between two camps: Camp A: Languages with mediocre static typing facilities, for example: -- C (weakly typed) -- C++ (weakly typed in parts, plus over-complicated type features) -- TypeScript (the runtime is weakly typed, because it's Javascript all the way down) Camp B: Languages with mediocre dynamic typing faciliti…
Perhaps it's because the languages you mentioned barely register in statistics(aside from Clojure maybe).
Maybe it's simply hard to have both a good type system and a friendly learning curve?