The benefit of static typing isn't just reliability. Tooling is another major argument. Won't appeal to certain hardcore programmers who think that even notepad has too many features. But it is great for refactoring, finding all references to a function or a property or navigating through the code at design time. Basically all the features visual studio excels at for .net languages.
And I disagree with the barrier to entry argument. Static typing, by enabling rich tooling, helps a beginner (like it helped me) a lot more by giving live feedback on your code, telling you immediately where you have a problem and why, telling you through a drop down what other options are available from there, etc. Basically makes the language way more self-discoverable than having to RTFM to figure out what you can do on a class.
Live coding environments are amazing at this, as well. Often without the need for as extensive static typing, since it can just use reflection.
This isn't to say that static typing isn't good at this. Just, even with that, there is a lot of effort that goes into making the rich tooling. A lot of very smart and capable folks work hard to make Visual Studio.
Dynamic languages support this kind of tooling too - you can even have seamless data completion (eg. map/dictionary keys). The original Refactoring Browser was written for Smalltalk. Etc.
Of course there are cases where dynamic languages do worse, but it balances out I think.
In dynamic languages functions aren't typically overloaded by argument type.
For OO languages and methods it does get a little guesswork-y, and tools often offer a wider range of guesses than is correct for completion. But you can show the class along with the offered completion, so it's not too bad.
You can, but you may start to run into some limitations. Many languages have some version of type inference, which allows them to figure out the type of a thing, even though the programmer didn’t specify it.
C# has a very weak version of this with the auto keyword. Languages like Crystal take it much further by tracing the flow of data through the entire program. It generally works quite well, though there are a few edgecases that require explicit type annotations.
As for auto-completion, some languages feature designs that make it easy to offer auto completion even without type information. For instance, Elixir doesn’t have methods. You only have functions defined on modules, and it’s trivially easy to know what functions are defined on a module.
IMO the autocomplete argument is rather unconvincing. Every dynamic language I've worked deeply with has powerful and simple introspection capabilities, and they generally come with much more interactive development environments (shell/REPL), so I've never found API discoverability to be any worse than statically typed languages, just different.
In general though, the more you can formally reason about the program, the more you can automate program transformations (refactoring). Programmers in dynamic languages will argue that the amount of code is far less than the equivalent code in a mainstream statically-typed language, so while the cost of refactoring may be higher per unit, the number of units is less, so the overall cost is the same (or less).
I believe in using the best tool for the job...some use cases would benefit more from static typing, while others would benefit more from using a dynamic language. One of the most important factors is the team and its engineers' backgrounds, preferences, styles, etc.
I found Ruby (even in something like RubyMine) to be a far cry from even the basic stuff you get from Java. Suggestions for vars and funcs that don't actually exist really slowed down things.
It might still, at least arguably, be "the right tool for the job." If you have a huge team of expert C# developers C# might be "the right tool for the job" even if it would be a little easier to do in a different language, given the same pool of experts in that language.
Agree. My point is that, if I personally dislike C# (I don't), and I'm on a team of C# experts and C# is the best choice for shipping the product given those experts and all the other use cases, then C# is the best tool for the job and I'll peruse C# documentation. I try my best to focus objectively on the product, not my ego or subjective preferences...and I often fail :(.
Yeah, sure, and I was able to avoid the painful years. But C# pre-generics and pre-Linq is a way less appealing language too, you know? Most languages that are popular now look kind of rough to work in several versions ago.
Oh definitely. I think that’s the case for nearly any language that’s worth the code it’s written in. C++ is an interesting case study in how to do it both right and wrong; we’re spoilt for choice and it keeps getting better every day
> Nobody would say "I intend to use the wrong tool for the job."
...but there's plenty of sales charlatans out there who will say "I intend to get the manager of that IT dept to make its developers use my tool for the job, and I don't care if my tool is the right one or the wrong one."
Yeah, I agree: Two of the languages with the best autocomplete and introspection in general are Common Lisp and Smalltalk. Some of that's simple maturity, but it proves that those features can work very, very well in even the most dynamic languages around.
Sorry, but I'd contest that remark, at least for Smalltalk. It only has the best autocomplete/introspection for people who have never worked with modern statically typed languages/IDEs and/or significantly large projects. It just doesn't have the neccessary information.
The thing about magical refactoring though is that it often isn't a good idea. You usually don't just change the name of something, but you change it conceptually. If you just let the ide go and change the name everywhere, you create bugs because you never actually went and made sure the old code was updated for the new concept, rather than just the name.
In my mind, what swayed me towards static typing languages was after I played around with Haskell and was able to use the 'deriving' clause.
The realization that with types, smart enough compiler can implement interfaces for me, was amazing.
Unfortunately, I am afraid that it will take a while for these techniques to go mainstream. A.f.a.i.k most a mainstream language can do, is to fill in the method stubs for you.
Agreed. Although other comments claim that their dynamically typed languages have this same property, inherently in dynamic languages the auto complete will fail out unless you effective write code as if you were using static types.
My main progamming language at the time is Java, and the amount of assistance my IDE provides is astonishing (to the surprise of no one, it's IntelliJ). The confidence strong automatic refactors provide is of great help when managing large codebases.
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 refactoring. Unit tests is the only truth that matters, static typing or not.
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.
Meanwhile real-world non-trivial projects tend to be large projects.
Nice to be prepared for that instead of gambling on "surely we'll extract out smaller projects that fall on the right abstraction boundaries in the face of unknown future requirements."
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.
How big are the "real-world codebases" you're talking about, and how many programmers are working on the code? Once you hit 5-10 million lines of code and/or thousands of developers, static typing really helps manage complexity.
> Unit tests is the only truth that matters, static typing or not.
Well that's provably false, because there exist properties that you can type check that literally can't be verified via unit tests, even in principle. For instance, race and deadlock freedom.
No one is saying there is no cost. The cost of using static types is (1) you have to think about type info when writing the code and (2) you have to fix compile-time type errors while you are developing. The poster is claiming that, over time, as code bases tend to grow large, this small investment yields increasing (not diminishing) returns; a claim I would agree with.
Well, the easy answer is that dependently-typed languages like Agda and Idris aren't very mature yet. They're still missing many commonly-needed libraries, compile times are slow, the tooling isn't great, etc etc.
Getting a language to the point where it's workable for serious projects is a lot of work. Rust is getting there with the backing of Mozilla, Haskell has made some decent strides too (but still has a way to go, and I think has some pretty fundamental flaws entirely apart from the type system). It'll be probably another decade at least before we see any dependently-typed languages getting a serious foothold, but I do think they're going to become a lot more common eventually.
It isn't just a matter of tooling. There exist hard limits on how much can be inferred about unannotated programs, and when you go past those limits, the price you have to pay is to embed (partial) proofs of correctness in your own code. For example, think about why GADTs don't play nicely with type inference.
IMO, machine assistance is useful to the extent it relieves us humans from work. In particular, types are useful to the extent they can be inferred. Beyond that, you still need to prove the correctness of your programs on your own, so there is no point to the ceremony of writing down those proofs in a machine-checkable format.
> Well, the easy answer is that dependently-typed languages like Agda and Idris aren't very mature yet.
It's also self-evidently wrong. Agda was first released in 1999, ten years before Go. If you use a wallclock interpretation of "maturity", Agda is twice as old as Go and Idris is roughly as old as Go. Both are used significantly less (by several orders of magnitude), though. Despite them having a far stronger type-system.
If you, on the other hand, you are using a "developers' time" interpretation of maturity, on the other hand, you are making a circular argument, i.e. "Agda is seeing less use, because it has been used less", as resources invested in a language ecosystem tend to be strongly correlated with it's usage.
Have you used them? Switching to a language like Agda or Idris is entering the realm of formal verification because the types are so expressive. It's completely different to what most programmers are used to.
Essentially the types being used as so complex the type checker cannot automate the decision about two types being compatible so you have to write maths proofs to help. The types used in mainstream languages are simple enough that the type checker never needs help like that.
The cost of formal verification right now is immense but the benefit is close to bug free code. Mainstream strong statically languages require nowhere near the same amount of effort and give clear benefits over dynamic types.
When using languages with static typing amount of refactoring of that type is disproportionately large, so people notice how much the ide helps, without noticing that most of the help wouldn't be even necessary without the complexity added by static types.
Semi-automatic refactoring tools is just one part of what a type system enables. A much bigger benefit in my opinion is that it immediately highlights issues in your code while you are refactoring. Basically answer "What do I still need to change to finish the refactoring?". Unit testing also gives you some of this, but is typically much slower - both in execution time, and the additional time it takes to figure out where the issue is.
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.
I can do all of those things in Smalltalk, which is dynamically typed; these things are not byproducts of static typing, they're simply byproducts of mature tools. So no, these are not arguments in favor of static types.
Yes, you can find all references to a method in Smalltalk -- but those references are not separated-out from all the references to other methods that happen to have the same method name but are defined on a different class.
With type information for the receiver and method arguments, we can find just the references we're looking for.
I can't speak to Smalltalk, but any namespaced Lisp system can figure out what references what. The key is that the searches happen through the REPL, not grep/ag. So if I tell CIDER to find all instances of a Clojure symbol, it can use the namespace to avoid false positives.
Which is why Smalltalk's refactoring browser has a manual intervention step to allow you to see what it proposes to do, and remove any steps you don't agree with, as well as the ability to scope your refactorings to a package or class to limit the scope to more relevant data. Either way, it's sufficient to get 99% of the benefits of automated refactorings without the 100% guarantee static typing provides; good enough for me.
Automated refactoring was invented in Smalltalk, claiming it's a benefit only static typing provides is to not know history.
Ralph Johnson, a prominent Smalltalk'er, was advisor on that paper and was the creator of the first Smalltalk refactoring browser and that paper is littered with references to how things are done in Smalltalk. I was unaware a C++ was involved, but I still think Smalltalk had the first commercial refactoring browser. A research paper is not a product, however, thanks for the ref.
Don't be a douche, obviously I don't think it's the same hence my comment. And I'm willing to bet, same as you, my source was Google to verify my memory of something I read long ago.
I didn't name call, saying don't be something isn't remotely the same as saying you are something. If someone tells you don't be a jerk, they're not calling you a jerk, they're warning you you're nearing that point. We're done, good will has exited the building, there's no point in continuing.
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.
>Not just, "who the hell uses this", but "where the hell is this defined" as well.
On Common Lisp, a dynamic language, I can also get this answered instantly. I just press a key combination on a method call and i jump to the definition.
So this isn't exclusive to statically typed languages.
Does it work in the presence and (ab)use of dynamic features? (e.g., when you have lots of decorated functions) Or is it just a best effort thing? (i.e., only works when your code would actually be expressible in a static way)
This is a continuum... in many statically typed languages there are regularly used paths that lead outside the realm of the language-defined type system as well. Consider dynamic class loading in Java, dlopen / reinterpret_cast in C++ etc.
IntelliJ/WebStorm is also pretty good at this (with JavaScript at least) by indexing a whole project and its dependencies. Refactoring doesn't work that well, though.
It's worth noting that Elixir (by descent from Erlang) can emulate at least a basic static typing system pretty easily through pattern matching. You miss out on some features common in more traditionally-object-oriented languages (namely: subtypes), but tagged tuples and structs do provide a lot of the same safety benefits in runtime (and tools like Dialyzer can - last I check - use such pattern matching as a basis for static verification).
You can still pattern match when receiving, though (in fact, 'receive' in both Erlang and Elixir does pattern matching already in the same vein as 'case'); just match messages based on a tagged tuple or a record (Erlang) / struct (Elixir) signature or however else you want to define your "types".
>Lets be real, when we say dynamic languages, we aren't talking about niche languages like Lisp.
How can it be a niche language, if it's an ANSI standard, has more than 8 or 10 fully feature, standard-conformant implementations, runs on most CPU types, and has been proven to work in production systems for spaceship guiding, worldwide airfare reservation and credit card transaction verification?
You use Js and Python because you choose to use it, but it's not the only choice. Not only Common Lisp, you could also be working in Clojure with many benefits.
But if the compiler doesn't enforce that types are statically determinable, there will be cases where the tool will have to show you more potential definitions for function definitions than would be shown for a statically typed language.
Maybe good tools are able to perform some static analysis and rule out some of the methods with the same name but impossible types, but the language doesn't rule out situations where the best the tool will be able to do is show you all of the function definitions with the same name as the (dynamically dispatched) function call site you're looking at.
Let's say you have seven different type hierarchies having dynamically dispatched functions named "run", with 5 definitions in each hierarchy, for a total of 35 functions named "run". In a statically typed language, if the code compiles, it's possible to narrow down the type for a given call site to either one of the hierarchies or one definition, meaning you have to look at either 1 or 5 definitions. In a dynamically typed language, there are situations where legal code results in the tool having to throw up its hands and show you all 35 definitions.
The flip side is that if you really have a spot where you'll need to dispatch to any of the different hierarchies, then in a strong statically typed language, you'll need to either create an algebraic sum type covering all 7 hierarchies, or you'll need something like a typecase / typeswitch statement to enumerate out your possibilities.
there will be cases where the tool will have to show you more potential definitions for function definitions than would be shown for a statically typed language.
And even in a statically-typed language there will be cases where the tooling can only determine fairly generic things statically.
I don't see anyone advocating for abandoning static typing over that occasional limitation. Yet I do see people proposing similarly-infrequent issues as cause to abandon dynamic typing.
I had to do a decent amount of setup and wrote a quick script to run the tools which generate ctags to make this happen in CL using slimv. With top tier ides for static languages, this is built in from day 1 with no effort. You can't not have it. That said, a top tier repl for development is missing in languages like C#. I'd love to see that gap bridged.
I think it's telling that while there are Lisp aficionados in this thread telling us how great it is, none of these ideas have been implemented in Python or JavaScript or Ruby, the most common dynamically typed languages.
And that's really all I care about, I'm not about to start writing production code in Lisp.
IME, add that 1% to another "1% isn't worth switching" argument with some other Python deficiency and then to another and so on, and reasonable case for choosing other languages can be made. I'm not saying Python should be abandoned for all projects, but we should be careful with "but if we make everyone use this one tool, and this one tool does it right almost all of the time, so we're good" arguments.
I'm reading Type-Driven Development with Idris right now exactly because I don't think Python is always the correct choice. I just don't find slight improvements in IDE features to be relevant.
What about the time accounted for in each of those buckets? If "that 1%" accounts for more than 1% of debugging, error chasing, and related time it starts to look more important, yes?
For me, what I miss when using dynamic languages is good, solid refactoring tools that can inline functions/methods, rename across source files, etc. In my experience, in both Python and Clojure, the refactoring tools simply don't come close to those of languages like C++, C# and Java. And I say this as a major Clojure fanboy...
Namespaced keywords can really help with refactoring your domain model.
Usually I use normal keywords for throwaway or glue code, but anything important (my actual domain entities) will be namespaced, allowing (relatively) pain free refactoring.
Cursive has a few good refactoring tools/shortcuts, but I would also like to see extract/inline/move for functions.
I'm not saying that I don't have facilities or tools (clj-refactor) to do refactoring, just that they are, in my opinion and experience, not as good or full featured as in the mainstream static languages (and this experience seems to translate between other dynamic languages, eg, Python: I have refactoring tools, but they're not as good as what I can do in, say, Java).
Its not a huge problem, just something I miss from the static languages.
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 true is that the requirement to name types means that a textual grep is way more reliable than it is in C. If I want to find all places where a Python class is used in a large codebase, I might as well give up.
Also they are backed by Clang and muuuuuuuuuuuch faster than in Visual Studio + whatever paid extension
A very nice feature it has and that I didn't see elsewhere is the optional case-sensitive renaming.
eg renaming Foo to Bar will also change foo to bar and FoO to BaR.
In smalltalk the parameter names are part of the function name to reduce the likelyhood of name clashes. You still have the same problem when you have two functions with the same name and parameters.
And smalltalk had to leave trampolines in place to deal with renames that it couldn't finish deterministically. No thank you.
Nobody ever talks about that little horror when they bring up how Smalltalk could to refactoring JUST FINE without static types. It wasn't just fine, turns out.
> In dynamically typed languages you kind of just grep and hope the name is not too common.
For four days, I spent debugging a python production script because in one place I had typo'd ".recived=true" on an object and just couldn't understand why my state machine wouldn't work.
And very quickly, the whole team became fans of __slots__ in Python.
I still write 90% of my useful code in python, but that one week of debugging was exhausting & basically wouldn't have even compiled in a statically declared language. Even in python, the error is at runtime, after I got the __slots__ in place.
> I still write 90% of my useful code in python, but that one week of debugging was exhausting & basically wouldn't have even compiled in a statically declared language.[...]
nothing stops you from using static typing with python3
I haven't used optional typing in python. However, the problem I see with optional typing is that while I may choose to use it my team mates might not. Even more importantly, the 3rd party dependencies I use probably don't. So the amount of code that actually uses the types would be very limiting. Saying the choice is entirely up to you personally is a misnomer.
Strict use of type annotations has to be a team decision, yes. Checking for them can be integrated into a CI build, though.
The typing spec provides for supplementary "stub files" that can be provided for third-party dependencies without their own annotations. The typeshed project provides these for a fair and quickly increasing number of common dependencies, and is plugged into pycharm and mypy by default:
https://github.com/python/typeshed
I think GP meant 'you' as in 'your team'. Anyway, Python has a type repository for popular libraries, just like TypeScript does. And mypy can still typecheck your code even without type annotations.
Well, nothing except almost the whole ecosystem of libraries not having type annotations, those type annotations that exist themselves being quite limited (IIRC), etc. etc.?
Can we stop pretending that adding type annotations to a 'dynamic' language solves the "good static typing" problem? It's just silly.
(About as silly as pretending that static types solve all problems.)
Is that really a typing problem, though? If I tried to use a "recived" slot on a Lisp struct that only had a "received" slot defined, I'd get a read-time error, and there's zero typing involved there.
> For four days, I spent debugging a python production script because in one place I had typo'd ".recived=true" on an object and just couldn't understand why my state machine wouldn't work
Is that really a dynamic typing problem or a language that allows you to create instance members anywhere? It seems like that is a flaw in the declaration model of the language and not a static / dynamic issue.
Could you clarify - did you go over all classes in your codebase and added __slots__ attribute? Or you have some tooling to do that for you? I don't have any clear counterargument but that sounds wildly unpythonic thing to do.
$ txr
This is the TXR Lisp interactive listener of TXR 185.
Quit with :quit or Ctrl-D on empty line. Ctrl-X ? for cheatsheet.
1> (set a.b 3)
** warning: (expr-1:1) qref: symbol b isn't the name of a struct slot
** warning: (expr-1:1) unbound variable a
** (expr-1:1) unbound variable a
** during evaluation of form (slotset a 'b 3)
** ... an expansion of (set a.b 3)
** which is located at expr-1:1
Both warnings are static. If we put that into a function body and put that function into a file, and then load the file, we get the warnings.
The diagnostics after the warnings are then from evaluation.
Those are nothing; TXR Lisp will get better diagnostics over time. I'm just starting the background work for a compiler.
There is dynamic and then there is crap dynamic.
Don't confuse the two.
There is crap static too. Shall we use C as the strawman examples of static? Hey look, two argument function called with three arguments; and there's a buffer overrun ...
>There is dynamic and then there is crap dynamic. (...) There is crap static too.
Excellent. My point exactly. I have no fear of using a static or dynamic language, as long as it is a good implementation of a statically (or dynamically) typed language.
A "static language" occurs when we have a model of program execution that involves erasing all of the type info before run-time. Or most of it. (Some static languages support OOP, and so stuff some minimal type info into objects for dispatch.)
Note how above, my expression executes anyway; the checks produce only warnings. The warning for the lack of a binding for the a variable is confirmed upon execution; the non-existence of the slot isn't since evaluation doesn't get that far.
If we retain the type info, we have dynamic typing. There is no limit to how much checking we can do in a dynamic setting. The checking can be incomplete, and it can be placed in an advisory role: we are informed about interesting facts that we can act on if we want, yet we can run the program anyway as-is.
This really sounds like "semantics" to me (not PL semantics! :).
For example, these days it's quite possible to ask GHC to defer type errors to runtime. Does that mean that the GHC dialect of Haskell is dynamically typed? This is basically a command line switch away, btw.
Retention of type information does not "dynamic typing" make. As a trivial example, consider C++ RTTI.
You really have just reinvented static (type) checking and a good runtime. There's no shame in that, but let's not pretend that these are opposing forces.
C++ RTTI is only for class objects, and only useful when they are manipulated by pointer or reference. I believe I covered that sort of thing with my statement, "Some static languages support OOP, and so stuff some minimal type info into objects for dispatch.". It's a gadget which provides an alternative to the structure of doing everything via virtual functions on a base class reference.
Ok, fair enough, but what about e.g. "-defer-type-errors" for GHC?
I still think you're just arguing semantics.
EDIT: Incidentally, the statically typed crowd can even go the "other way", namely from runtime -> compile time. For example, it's quite possible to derive a static proof/type from a runtime value in e.g. Idris by pattern matching as long as you're meticulous about building up the proof.
I work with an in-house framework written in Javascript.
You would think by looking at the code that the creators had a 30 word vocabulary, because 80% of the code uses the same six nouns and four verbs to pass data around and what you use those for depends on the context of who is calling it.
Oh, but the entire thing is written using promises, so most of your function calls have no context. It's hell, and I'm starting to worry that Node has dug itself a reputation hole it will never get out of.
I can feel your pain, but note that this isn't a fault of dynamic typing per se. This is bad coding (for example, no good use of modules) plus the problem of Javascript itself having many issues; not to mention the wildly different levels of quality within the JS library ecosystem.
vscode seems to figure out the types in javascript without any static typing.
>But it is great for refactoring
Searching for strings isn't that much worse. Also, when it comes to web development, you cross into the client-side and suddenly you can't refactor. So you can only refactor the server-side and end up with a mismatch.
>finding all references to a function or a property or navigating through the code at design time
You can do that without static typing in many cases as well.
>Basically all the features visual studio excels at for .net languages.
When I was working in c# on the server and javascript on the client, I really hated having to go back into c#.
>telling you through a drop down what other options are available from there
vscode seems to be able to figure this out most of the time as well.
I think static typing is necessary when you need performance because all of the fast languages are statically typed.
I think a lot of these things are about organisational complexity and making sure new and average programmers don't screw up the software. It is about large companies trying to manage their organisation, it isn't about the complexity of the code itself.
There are a ridiculous amount of tech companies that have used dynamic languages to go from nothing to the biggest companies in the world and only switched to static languages well and truly after that occurred.
No it works without using typescript. I just figures it out through... I have never thought about it. I mean, var p = new Cat();. I am sure it can find the cat definition easy and read the properties and so on. It probably can't prove things 100% but it can guess very well at what things are.
> Visual Studio 2017 provides a powerful JavaScript editing experience right out of the box. Powered by a TypeScript based language service, Visual Studio delivers richer IntelliSense, support for modern JavaScript features, and improved productivity features such as Go to Definition, refactoring, and more.
It works off Typescript type annotations for packages and the Typescript compiler's type inference. VS Code's Javascript editing does not seem to be evidence for tooling around dynamic languages so much as it's evidence that if you have a lot of money and Anders Hejlsberg you can write a compiler for a statically typed language with type inference that looks like a specific dynamic language.
>vscode seems to figure out the types in javascript without any static typing.
There are limits to type inference. And if you're going to rely on type inference to prevent runtime bugs you might as well double-down on static typing since you're giving up on some of the 'features' (insanity) of dynamic languages anyway.
Dart 2.0 now mandates strict typing but will allow you syntactic shortcuts as long as the compiler can infer the type (if it can't, you get a compile-time error) - that's a great compromise. I wish more people would love Dart. It's such a great, well-designed, language.
>Searching for strings isn't that much worse.
There are very real limits with what you can do with 'strings'. And yes, it is that much worse.
>When I was working in c# on the server and javascript on the client, I really hated having to go back into c#.
I do not understand that view. You are an alien to me. C# is a beautiful language that fixes a lot of syntactic problems in Java. It is much more pleasurable to write C# code than JS code (outside of dinky 50 line programs).
>I think static typing is necessary when you need performance because all of the fast languages are statically typed.
That's not the only reason but it is one of them. JIT and AOT compilers can do more with strongly typed code.
>There are a ridiculous amount of tech companies that have used dynamic languages to go from nothing to the biggest companies in the world and only switched to static languages well and truly after that occurred.
Sure. PHP (pre-5) and JavaScript made a ton of money for a ton of people. Both languages were integral in the Web revolution. Doesn't change the fact that PHP was a terrible language and JavaScript is still a terrible language.
The vast majority of development time is spent finding and fixing bugs. Small startups got huge often because they hit the sweet spot of features before anyone else, not because their code was high quality. Once they get large installed bases (and large valuations) they get religion about the value of more strict typing.
The unknowable question is, would they have hit that sweet spot anyways by engineering their product more rigorously, and had less pain later? Or would it have impeded them in the exploratory phase of writing and rewriting their code until they hit that spot?
> vscode seems to figure out the types in javascript without any static typing.
It is actually using TypeScript's engine for this. It uses TypeScript's type definitions where it is available (e.g. most popular libraries and built-ins), and some inference rules where it has to work with plain JavaScript.
While this does give you decent auto-complete in a lot of cases (and still getting better), it's not quite as good as using TypeScript directly.
> Searching for strings isn't that much worse.
I'm busy with a large refactoring project, and TypeScript has been amazing for this. After restructuring code, you can just keep on fixing things until there's no more red. This is not just about reducing bugs - it removes almost any thinking/mental overhead required for the refactoring process.
> Also, when it comes to web development, you cross into the client-side and suddenly you can't refactor. So you can only refactor the server-side and end up with a mismatch.
TypeScript also works very well for client-side. Of course, if you change the API between the client and server, that's a different story.
> There are a ridiculous amount of tech companies that have used dynamic languages to go from nothing to the biggest companies in the world and only switched to static languages well and truly after that occurred.
This is a biased sample though. You're saying 'ridiculous number', but the truth is most startups (using static or dynamic languages) fail and we don't actually know if their language choice had much impact on their success or failure.
If Visual Studio is your example, then you're making the same argument as the author: there's a sweet spot. From the python world, c# may look statically typed, but from the Haskell/Idris point of view, the java/c# type systems look really sloppy and ambiguous.
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, EJB2 world sucked) but then it went completely off-the-rails. Typing in Java could be better, sure, but even with its quirks it's way better than the nothing you get with dynamic languages. There are a class of bugs you just never need to worry about when the compiler does some compile-time checks for you ... like worrying that you passed the wrong type into a function, or the wrong number of arguments.
This is the #1 reason I leaned away from static typing. Typescript and Swift have changed my mind. I now see typing as a helpful tool that can solve a lot of problems.
>>There are a class of bugs you just never need to worry about when the compiler does some compile-time checks for you ... like worrying that you passed the wrong type into a function, or the wrong number of arguments.
People always say this and it baffles me. Bugs like that should be caught immediately by your test cases. You shouldn't rely on the compiler to catch them for you.
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.
Why would I write test-cases for something the compiler can catch for me? Yes, I need to write tests for all the correctly-typed cases, but there are a whole class of bugs that I don't need to test for any more because I can't even write the failing case.
You don't write test cases specifically to check types. Your existing cases, if they are robust and thorough, will simulate your runtime and check those for you as a side effect.
My existing test cases, robust and thorough though they are, only test what happens when I feed in a correctly typed object. Because I can't write a test that exercises my code on an incorrectly typed input: the type system prevents that.
you're already writing the test cases to ensure correct behavior with typical input, and predictable exceptional input. putting in one more assert for predictable exceptional input (wrong type) doesn't really add a noticeable amount of overhead to writing the tests you were already writing.
Well if you don't need to write that particular test you have more time writing tests that are actually useful, like validating your logic (and dare I say: more fun to write).
I worked on a small Python project some years ago and we had a type error in production despite having tests.
We traced it back to a call to a third party library. It was supposed to return a list of results, and all of the test cases around it worked and always got a list back. In production however we encountered an error because if there was only one value to return, the library would not return a list of one element, as we expected, but a scalar value. So the rest of the code was expecting a list and when it encountered a scalar it blew up.
You can blame it on us for having insufficient test cases, or not coding defensively enough, or not reading the source code of the library we used, or the author of the library for bad design, but ultimately, this bug would not have been possible in a statically typed language.
So just saying "have test cases" is not good enough. Your test cases can be not exhaustive, but a good static type system and type checker is.
Yeah and a static type system refuses to let you make such a stupid decision. When interoperating with code I didn't write, knowing that the code is guaranteed to conform to some specification is valuable.
I cannot reply to cdoconnor (probably some downvotes), so I'll write here:
That's the whole point: as it's often said "type checking keeps you honest"
I stumbled time and time again upon badly designed libraries... With a static type system, the painfulness will be obvious and felt the first time you'll try to build your code
with dynamic types, the pain might not be felt at all, until a crazy bit of code will be invoked, sometimes at the most unfortunate of times
and not just that, but for every possible case for the line you can think of. Like the post above, testing the results of a function returns a list for 1 item, or many items...
I see all too often, java bad, just look at how many lines you need to write to get "hello world". Who cares, the IDE generates that for you, but if you don't understand static void main as a beginner... again who cares, just put it in and ignore it until you need to understand it. Also read that dynamic languages are so productive, but they never mention you need to then write tests to detect what the compiler would catch for free. Yes good code needs tests, but the compiler IMO is a damn good built in test suite for catching many classes of errors
Bugs like that should be caught immediately by your test cases. You shouldn't rely on the compiler to catch them for you.
What's wrong with relying on the compiler? Bugs like that will be caught immediately by a good static type system, so you don't have to rely on your test cases to catch them for you.
Relying on a test suite to verify basic properties that could be enforced automatically through a type system means you're only checking some cases instead of all cases. It also means you're cluttering your test suite with boilerplate about language mechanics instead of writing high value tests that verify the real operational behaviour of your system.
There are pros and cons to static vs. dynamic typing in general, but in this particular respect, static typing is strictly more powerful, less verbose and more efficient.
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 after I discovered Haskell (and more recently Idris), did I realize that static typing can actually be worthwhile.
Agreed, every time I had to patiently explain to javac that shockingly, my new ArrayList<T> was a List<T>, 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.
Generics in Java have well known limitations stemming from type erasure (a design decision made to preserve backwards compatibility). Things aren't quite as dire as you made them out to be and in the general case, they work quite well.
While it may be frustrating to novice programmers, the distinction between interfaces (List) and implementation classes (ArrayList) is quite valuable, especially when dealing with huge code bases that have to be maintained over decades. Those declarations help to establish an internal design contract and clarify the developer's intent. In this particular case, a future maintenance programmer could switch from ArrayList to any other class which implements the List interface without breaking the program.
Which happens exactly how often? I've been writing java code for the better part of two decades and basically never needed to swap my list/set/map types around. Also, one of the purported benefits of java's typing is your editor can find and refactor / swap all usages, so it doesn't seem to me like this distinction has much value. It instead makes me think it's a fetish for object orientedness...
In fact, the only cases I've ever swapped even a HashMap has been to trove, which implements data structures for builtin types rather than reference types. In which case using interfaces everywhere doesn't help.
True, but there are more elegant solutions. For example, Rust's traits allow you to define a trait (somewhere in between an interface and an abstract class in Java), and then methods can be generic over any object that implements that trait. And structs and traits have a many-to-many relationship.
This allows you implement patterns like duck typing which are idiomatic in languages like javascript, but impossible to implement in java.
Those things are indeed obnoxious, but they are truly _Java_ issues rather than static typing issues. For instance, C# will figure that stuff automatically in many cases using the _var_ keyword. The Lombok plugin can add something like that into Java, although it's only about 80% as good because of other Java limitations, primarily type erasure.
I agree. While I have never used C# in anger I have played with enough other (non-Java staticky typed) languages to know that it doesn’t have to be this bad :D
Types, especially those that could easily be inferred and that provide no value to the programmer. Writing types down can be useful - Python programmers do it too. Having to tell the compiler every little thing is crap.
Like what?
Type erasure. Having to treat primitives and arrays differently from other types. No first class functions or classes. I won't go on, the arguments are easy to find.
I won't deny that Java had some quirky design decision that the language is paying for (though some of those have been mitigated). But I can't find your criticisms very persuasive in a world where languages like JavaScript and PHP are popular. Even C and C++ have their own idiosyncrasies to contend with.
I am surprised though that you were completely ignorant of the benefits of static typing outside of Java. I would think that simply out of curiosity you would do a language survey just to get an idea of what else is out there.
II can't find your criticisms very persuasive in a world where languages like JavaScript and PHP are popular.
Persuading you on the general demerits of Java wasn't really my intention; my point was that if you want get more people on the static typing train, Java is a bad ambassador and might work against you.
I am surprised though that you were completely ignorant of the benefits of static typing outside of Java. I would think that simply out of curiosity you would do a language survey just to get an idea of what else is out there.
Well, back then (early 2000s) I was a self-taught teenager with a poorer grasp of English (I'm not a native speaker), so while my curiosity did lead me to discover a few languages (JavaScript, PHP, Python, Lua and C), anything remotely approaching "academic" - Haskell, OCaml, Oberon, etc - was out of bounds for me.
Since C was the only other statically-typed language I knew, and I also knew it was much older and designed for much slower machines, I assume static typing was mostly for efficiency, like manual memory management.
The type systems of Java and C/C++ are the most commonly encountered ones and by far the most widespread in industry programming (as opposed to academia/research) and they are actually awful and really add a lot of friction and inertia to developing. Being free of that kind of type system when using a language like Python really does feel like a big upgrade.
There is a different problem with the more powerful and useful type systems in more modern statically typed languages though: learning curve. Haskell is dysfunctionally hard to learn and other languages do a little bit better but there's still friction in the learning curve that gets in the way of widespread adoption in projects that want to be able to hire rapidly.
There are no senses to come to. Static and dynamic typing each have their own benefits, and there are genuine tradeoffs to choosing one over the other. That we are even having this debate in 2017 shows that the world of typing is not a "solved problem" and there are still good reasons to use one over the other for various reasons.
Cheap and plentiful dev talent. Grab any random guy (and at these shops it's always guys) off the street and bang you've got a python dev.
There's always going to be an agility multiplier so long as VC is flowing and getting an mvp and a high head count is worth more than any kind of sustainable product.
>Grab any random guy (and at these shops it's always guys) off the street and bang you've got a python dev.
I expect any programmer to be able to transfer their skillet to a new programming language - especially when we're talking about mainstream languages with a GC.
>There's always going to be an agility multiplier so long as VC is flowing and getting an mvp and a high head count is worth more than any kind of sustainable product.
What kind of agility multiplier? Maybe it makes a difference during a hackathon where you have 24 hours to put something together or maybe if you're putting together shell scripts ... but taking something to MVP takes weeks or months - mainstream dynamic languages simply don't have any edge in development speed in those instances.
>I struggle to think of any benefits of dynamic typing on a reasonably sized code-base
Being able to define and initialize types at runtime offers more flexibility and it's quicker to develop in.
I'm frankly surprised nobody brings it up more often but the prototypical example of "static typing done right" - Haskell - is talked about nearly constantly but when I look for actual software I might use that's written using it.... there's so little it's almost embarrassing. One obscure window manager, one obscure VCS, facebook's spam filter and some tool for converting markup.
Given a sprinkling of asserts, a decent linter and a high level of test coverage I don't see much of a benefit to adding static typing.
Decent programmers compose code bases of "significant size" from many small, loosely coupled single purpose applications.
Yes, IME it's still quicker.
OTOH, if you're using "codebase of significant size" as code for "big ball of mud", static typing certainly helps, but integration tests are the real lifesaver.
>OTOH, if you're using "codebase of significant size" as code for "big ball of mud", static typing certainly helps, but integration tests are the real lifesaver
No. I mean when the codebase is of a certain size, new features require some thought and planning. Features may span multiple-modules. They may require partial or full rewrites or the refactoring of any number of sub-components to support the new behaviour. This means that you proceed carefully because you may not want to introduce regression bugs. This costs time. At that point, you're not limited by your typing speed as you may be putting in net 10 lines of code a day. There is just no benefit to dynamic typing at that point. Worse for dynamic languages, this is where improved tooling and static type constraints start paying extreme dividends.
>No. I mean when the codebase is of a certain size, new features require some thought and planning. Features may span multiple-modules. They may require partial or full rewrites or the refactoring of any number of sub-components to support the new behaviour. This means that you proceed carefully because you may not want to introduce regression bugs. This costs time.
Yes. And all equally true for statically typed languages.
Refactoring without tests is easier in a statically typed language, but still stupid. If you assume a decent body of tests, the benefit dissipates quickly.
If you prototype faster, as you usually will in a dynamically typed language, your design mistakes cost less. Since in large software systems I tend to find that the two biggest sources of bugs are a) errors in specification and b) poorly designed APIs, not obscure edge case bugs, quicker prototyping helps in large projects too.
And, if your design is solid, you can still achieve similar benefits as static typing by "locking down" your boundary code with asserts so that future development that interacts with that boundary code will fail quickly if it interacted with in the wrong way.
>At that point, you're not limited by your typing speed as you may be putting in net 10 lines of code a day. There is just no benefit to dynamic typing at that point.
This is fallacious. You're never limited by your typing speed in any language at any point. The cost of "extra typing" is cognitive, not a finger speed limitation.
The benefit of dynamic typing is more flexibility in the code you write (especially useful for writing frameworks and such) and quicker turnaround when prototyping because you do not have to prespecify as much up front.
>Yes. And all equally true for statically typed languages.
>Refactoring without tests is easier in a statically typed language, but still stupid. If you assume a decent body of tests, the benefit dissipates quickly.
We're not arguing whether dynamic language+extensive integration/unit test is better than static typing and no tests.
>And, if your design is solid ...
Yes, if you have a very solid architecture, strict coding guidelines, extensive integration and unit test coverage, experienced developers (etc. etc. etc.) you will mitigate a lot of problems with dynamic typing. So if you do everything right, avoid the pitfalls, you can have something solid. A similar argument is made to me when I assert JavaScript is a terrible language. I don't disagree with either but it doesn't prove anything.
>The cost of "extra typing" is cognitive, not a finger speed limitation.
>We're not arguing whether dynamic language+extensive integration/unit test is better than static typing and no tests.
I am, because that's the way I'd work in any language, because I'm not a hack.
>Yes, if you have a very solid architecture, strict coding guidelines, extensive integration and unit test coverage, experienced developers (etc. etc. etc.) you will mitigate a lot of problems with dynamic typing.
Eliminate.
>A similar argument is made to me when I assert JavaScript is a terrible language.
No, javascript is different. The weird and fucked up implicit type conversions render even a high level of testing insufficient to achieve a high level of confidence in the code. There's way too many edge case behaviors where it should be throwing exceptions and it does something weird instead. C suffers from this problem too despite being statically typed.
I've worked with, statically typed languages, dynamically typed languages, and my day job involves a dynamically typed language with optional annotations (dynamically enforced) and static analysis tools.
In my experience, the cost of static typing feels roughly constant per line of code, while the benefits of static typing feel roughly O(N log N) in lines of code or O(N) in number of cross-type interactions. These are just wild guesses based on gut feelings, but they feel about right. The constant factors are affected by individual coder preference, experience, and ability, but also specifics of thy type systems involved and the strength of type inference in the tools being used.
In any case, I think often times dynamic typing proponents and static typing proponents have vastly different notions of what a large code base is, or at least the size code bases they typically use.
One problem is that many code bases start out where the advantages of static typing aren't readily apparent, but re-factoring into a statically typed language is often not realistic, even/especially when a project starts groaning under its own weight.
I'd love to see more mainstream use of gradual typing/optional typing/hybrid typing languages, especially something like a statically typed compiled subset of a dynamically typed interpreted language, where people could re-factor portions of their quick-and-dirty prototypes into nice statically typed libraries.
There's not only tooling and reliability. Don't forget performance, too. Knowing at runtime that a memory word represents, for instance, an integer rather than a reference to a struct that contains both a type tag and a reference to the actual value, makes a huge difference. And I'm not even mentioning the inlining possibilities.
It does (though admittedly not very explicitly), it just rolls it into the "benefit" (i.e. not shipping broken code is a benefit) and the "weight given to stability". If a bug discovered in prod (or even qa/canary) has a significantly higher cost than a bug discovered early, that will influence the weight you are putting on stability. In that way, this factor is subsumed in one of the other graphs.
As you might've noticed, I have been intentionally light on the details and only talked pretty abstractly about the specific scales and factors involved.
Isn't static typing a requirement when writing an algorithm and data structures for "every bit and clock cycle counts" situations? How can a 0-compute overhead for dynamic typing exist in a dynamic typed environment?
I always thought dynamic typing is a feature for situations where the code needs an extreme amount of flexibility to adapt to a wide variety of data; even at the expense of performance.
A good static type system will give you the ability to be able to control the level of dynamism in various parts of you code. For example you could create tagged unions to create mini dynamic type systems within parts of your codebase.
Assembly is typed. The types are machine words and usually floating point types are also available. Basically, the machine types are the types of data that the register files can hold.
Sure, but to bring it back to the original question, the fact that you can trivially distinguish floating point from word types already means statically typed languages are easier to optimize than dynamically typed languages for numerical programs.
And there are all sorts of optimizations like this that simply aren't available to dynamically typed languages. Tracing JIT can only take you so far.
The original question asked whether static typing is needed when maximal performance is required. If we understand "maximal" to mean literally, "no more performance can possibly be squeezed out", then it simply is. Static typing might not be sufficient for this case, but it is necessary.
I think those few, crucial pieces of hand-written assembly language one sees from time to time disagree with you. (Modulo your observation that assembly languages are trivially statically typed.)
> I think those few, crucial pieces of hand-written assembly language one sees from time to time disagree with you.
I still don't think so. For example, plenty of silicon is spent on branch predictors simply because addresses and integers aren't distinguished, in general, thus permitting more expressive but costlier code.
Execution would be much faster if integers and addresses were forced to be distinct. Static typing pretty much always improves performance.
That's not a useful notion of type. If I cannot tell statically by inspecting a register name nor dynamically by inspecting a bit pattern whether a given register holds a pointer or an integer or a floating-point value, that's pretty much the definition of "untyped".
Dynamic type testing or introspection is not an essential feature of type systems. The fact is, your computing machine is typed. You can not deference a floating point register as an address, for instance.
> Dynamic type testing or introspection is not an essential feature of type systems.
I didn't say so. An essential feature of type systems is being able to determine the types of (many) values, statically or dynamically.
> You can not deference a floating point register as an address, for instance.
So you'd agree that architectures that don't make a distinction between integer and floating point registers are untyped? But sure, call this a type system if you must. It's just a very very weak one, so weak as to be almost entirely useless. (And the reason floating point registers are often separate from integer registers is not to provide this kind of "type safety", it's due to history and architecture.)
> It's just a very very weak one, so weak as to be almost entirely useless.
Weak and strong aren't meaningful terms. A machine ISA might have an inexpressive type system and/or an unsound type system (because it conflates addresses and integers).
> And the reason floating point registers are often separate from integer registers is not to provide this kind of "type safety", it's due to history and architecture.
No, the reason is performance. And we get performance by making statically known distinctions between datatypes, which is what the original poster asked about.
Intermingling the integer and floating point circuitry so they access the same register file would never improve performance over keeping them separate. You'd need longer wires to place them both near the same register files to minimize signal latency, an the added signal delay alone ensures lower performance.
"Architectural reasons" is nonsense. "Architecture" isn't a set of reasons justifying anything, rather it's the other way around: we design architecture for specific reasons. Your claims that we do things for "architectural reasons" don't have any clear meaning. I said the actual reasons are performance. I don't think I'm the one being unclear.
For optimal performance, the absence of unnecessary dynamic checks is a requirement. The presence of static checks is not, although they are useful for your sanity's sake.
Advanced compilation techniques can transform (input data, input program) into a statically typed program, so the at the limit the answer is strictly "no". See partial evaluation, futamura projections, etc- or JS JITs for more down to earth stuff (though sidestepping data transformations).
> Isn't static typing a requirement when writing an algorithm and data structures for "every bit and clock cycle counts" situations?
Not necessarily. The phrase "dynamic language" actually bundles together a lot of related but distinct ideas: some of those add performance overhead, others don't. "Dynamic" features which are most notable for performance overhead are tagged unions and dynamic dispatch.
Imagine a dynamically typed language which provides types like int, bool, list, functions, etc. and we're free to assign (and reassign) any of those values to any variable we like:
x = 5 # An int
y = true # A bool
y = 3 # An int
z = square(x + y) # An int
It's very common to store such values as a tagged union: a "union" meaning that the data could represent an int, or a bool, or whatever, and "tagged" meaning that there's some extra data which tells us which one it is. For example, we might store `5` as a pair of machine words: `1` to indicate that it's an int, and `5` to represent the data. The boolean `true` might be the pair `2` to indicate bool and `1` for the data. And so on.
This tagging adds overhead. We can reduce it in some cases, e.g. using "tagged pointers" where we use some of the bits in a word for the tag and some for the data. But it's still overhead.
However, there's nothing fundamental about using tagged unions. We could just as easily use 'unboxed' values, i.e. store the int `5` as the machine word `5`; the bool `true` as the machine word `1`; etc. There is no overhead, no metadata, etc. Whilst this is a perfectly reasonable implementation strategy, it means that we cannot tell what type a value is intended to have: e.g. if a value is stored as the machine word `1`, we have no way of knowing if that's the boolean `true`, or the integer `1`, or the character `SOH`, or whatever. This would probably lead to very buggy programs, since we have no type checker to enforce correct usage, and (since there's literally no difference between data of different types) we can't even do runtime assertions like `assert(isInt(x))`.
Likewise, many dynamic languages use dynamic dispatch to choose which functions to call based on the type of data we have. In the above example, we might have `x + y` running an integer addition function when `x` and `y` are integers, or a string concatenation function when `x` and `y` are strings, and so on. That's what Python and Javascript both do. Yet, again, there is no fundamental reason to do this! We can have a dynamic language which uses static dispath everywhere: consider that in PHP, `+` is only used for numerical addition, whilst `.` is only used for string concatenation. Dynamic dispatch adds overhead, since we need to chase pointers, etc. whilst static dispatch doesn't. This is simply a question of programmer convenience: do we want every function to have a distinct name, and write them out in full each time?
Note that both of these features: tagged unions and dynamic dispatch, can be used in static languages too. It's just that, historically, they tend to be default (and hence unavoidable) in dynamic languages, and something we must explicitly create in static languages. Hence when we compare static languages to dynamic ones, we tend to compare statements like `x + y` in Python to `x + y` in C, which are actually quite different semantically. A fairer comparison would be to compare `x + y` in Python with `callWith(lookUpSymbolFromType("+", lookUpType(x)), x, y)` in C (I've made up those function names, but the point is that the same functionality is there if we want it, but it will be just as slow as if we'd used Python)
This is really true. I was a complete Java newbie and knew some Python when I joined Google. Yet I found working in an unfamiliar Java code base much, much easier here.
Large Python code bases are really hard to understand and work in (here).
A lot of the same refactoring is possible in dynamic languages as in static ones. I recommend reading up on Term to see what's possible to do with JavaScript http://marijnhaverbeke.nl/blog/tern.html
I use Cursive https://cursive-ide.com/ for working with Clojure, and it can do safe refactoring for symbols by doing static analysis of the source. It can show all usages of a symbol, rename it, do automatic imports, and so on.
I find that the REPL driven workflow found in Lisps is simply unmatched. When you have tight integration between the editor and the application runtime, you can run any code you write within the context of the application immediately. This means that you never have to keep a lot of context in your head when you're working with the application. You always know what the code is doing because you can always run and inspect it.
Having the runtime available during development gives you feedback much faster than the compile/run cycle. I write a function, and I can run it immediately within the context of my application. I can see exactly what it's doing and why.
The main cost of static typing is that it restricts the ways you can express yourself. You're limited to the set of statements that can be verified by the type checker. This is necessarily a subset of all valid statements you could make in a dynamic language.
Finally, dynamic languages use different approaches to provide specification that have different trade offs from static typing. For example, Clojure has Spec that's used to provide runtime contracts. Just like static typing, Spec provides a specification for what the function should be doing, and it can be used to help guide the solution as seen here https://www.anthony-galea.com/blog/post/hello-parking-garage...
Spec also allows trivially specifying properties that are either difficult or impossible to encode using most type systems. Consider the sort function as an example. The constraints I care about are the following: I want to know that the elements are in their sorted order, and that the same elements that were passed in as arguments are returned as the result.
Typing it to demonstrate semantic correctness is impossible using most type systems. However, I can trivially do a runtime verification for it using Spec:
The above code ensures that the function is doing exactly what was intended and provides me with a useful specification. Just like types I can use Spec to derive the solution, but unlike types I don't have to fight with it when I'm still not sure what the shape of the solution is going to be.
For someone only passingly familiar with Spec, what's the benefit of Spec over just using a property based testing framework like Haskell's QuickCheck (and I think Clojure's test.check)?
I can encode all those invariants as QuickCheck properties and have them automatically tested against random inputs on every test run. It's still all runtime verification, but with random inputs I actually have more confidence of hitting a corner case than with just asserting during regular program runs or hand written example tests.
Also, with enough heavy lifting you can actually encode all of that in the types in a dependantly typed language like Idris [1]. And while a machine checked proof of your sorting algorithm is nice, it might be hitting the diminishing returns point the article mentions over just using property tests.
To add to what sheepmullet said, I think the insertion sort example is exactly the problem with advanced type systems. It takes nearly 300 lines of code to provide the specification.
Somebody has to be able to read that specification and understand that it's correct in a semantic sense. Ultimately, the specification itself becomes a full blown program that the type checker executes. So, now you run a program to try and verify aspects of your original program, but how do you verify that the specification itself is correct?
At some point a human has to be able to read the code and decide that it matches the intent. This step can't be automated, and I certainly don't think the Idris example improves things. I'd argue that it's far easier to tell that this version is correct:
fun insertionSort(arr, int n)
{
var i, key, j;
for (i = 1; i < n; i++)
{
key = arr[i];
j = i-1;
while (j >= 0 && arr[j] > key)
{
arr[j+1] = arr[j];
j = j-1;
}
arr[j+1] = key;
}
}
I have been doing some elm, and refactoring is a MAJOR bonus. You can refactor your entire project, and when it compiles it usually works. It's funny how dynamic languages are seen as beginner friendly, while in reality they are not (ruby, js, python...).
One of my favorite parts of Powershell is optional typing. Variables are a generic "Object" type by default, which can hold anything from a string to array to "Amazon.AWS.Model.EC2.Tag" or other custom types.
Or, type can be specified when setting the variable:
[String]$myString = "Hello World!"
This would generate a type error:
[Int]$myString = "Hello World!"
Often, typed and untyped variables will sit together:
And you get a deserialized version of the XML text.
Also the fact that you can use types when declaring function arguments, removing the need to manually test if an object of the desired type was passed.
Powershell definitely strikes a good balance on type safety for a scripting language.
When I went from working at Apple to a language implementation group at another company, my views on Objective-C's duck typing + warnings for classes being useful and good was pretty heretical. It's nice to see other people agree with me.
Especially when it comes to GUI programming, I really don't care if a BlueButton.Click() got called instead of RedButton.Click().
The biggest benefit of static typing is not a reduction of bugs...It's the speed and confidence with which one can accomplish a given task. IDE support, code completion, etc are so much better in a static environment. Take a random file from a pure JS codebase and compare it to something in Typescript. The first would require digging around to even begin to understand what the file is doing. Whereas TS, the code documents itself.
The counterarguemnt - "it's slow to write" - hasn't been true for years with modern type inference and other features.
> So year, static typing doesn't buy you much, but in some languages it's at least cheap.
I think this is key. The benefit of static typing isn't that they provide safety, it's that they provide _low-cost_ safety. For a large class of problems, types are cheaper than tests are. For other classes, tests are cheaper than types. The main downside of nonstatic languages is that you have to use tests for everything, even that class where types are a better choice.
I think what's often missing from these arguments is that statically checking (or inferring) homogenous lists is probably one of the most superficial uses of the type system in Haskell (and indeed not the interesting feature most power-users of Haskell are interested in as far as I can tell).
What is interesting is using the type system to specify invariants about data structures and functions at the type level before they are implemented. This has two effects:
The developer is encouraged to think of the invariants before trying to prove that their implementation satisfies them. This approach to software development asks the programmer to consider side-effects, error cases, and data transformations before committing to writing an implementation. Writing the implementation proves the invariant if the program type checks.
(Of course Haskell's type system in its lowest-common denominator form is simply typed but with extensions it can be made to be dependently typed).
The second interesting property is that, given a sufficiently expressive type system (which means Haskell with a plethora of extensions... or just Idris/Lean/Agda), it is possible to encode invariants about complex data structures at the type level. I'm not talking about enforcing homogenous lists of record types. I'm talking about ensuring that Red-Black Trees are properly balanced. This gets much more interesting when embedding DSLs into such a programming language that compile down to more "unsafe" languages.
List typing isn't as superficial as it seems. The following has happened to me multiple times, perhaps in the last month:
I have a large code base. I want to replace a fundamental data structure to support more operations/invariants/performance guarantees. I change the type at the roots of the code base. My instance of ghcid notifies me of the first type error. I fix it. This repeats until the program compiles again. I run the tests. All the tests pass.
This is insane in Python/C/Ruby. I've had to do it in C and Python. In Haskell I do it with impunity.
The type system doesn't just check what my program does, it is the compass, map, and hiking gear that gets me through the wilderness.
Yup, love that about statically typed languages. This happens all the time for me in C#. I have several libraries I like that do a lot of code generation. When the project is young, directly handling the generated classes works well but as the project grows, I inevitably want to wrap the handling of the generated classes. It's awesome to be like, welp... it's time to handle this one type differently. Change the return type of an interface or the type of a container and just have the compiler tell you everything you broke.
I’d argue that code generation is an anti—pattern that is only necessary because of static typing. A dynamic language would let you change the implementation of all generated objects simultaneously.
Code generation by macros is an important feature of Lisps, which tend to be dynamically typed. Maybe it feels less like code generation when you don't also have to produce the correct type annotations, but a good inference engine can eliminate most of those from statically typed languages as well.
Code generation is, in essence, the ultimate static construct since it allows you to compile any feature you would achieve through late binding and reflection, but with a static code path. Which in turn lets you leverage the compiler toolchain more and bring more errors towards compile time(where they're cheap to resolve).
Dynamic languages can always lean on runtime features, but that's also their peril. Late binding deprives you of leveraging the tools in favor of "trust me".
In both cases you can get a maintenance nightmare, of course. The point as I see it is to move things toward the runtime when the error case is not troublesome, and towards the compiler when automating in more safeguards would help.
That may be entirely true and everything you can achieve with Roslyn and T4 templates may be achievable through some more elegant construct in another language.
But I've never had the luxury of choosing a tech stack for it's purity of design. So the feature is wonderful in my day to day regardless.
I'd love to build 3D experiences in a language like lisp or scheme. It'd be great fun to learn but I don't currently have the luxury of the time it would take to ramp.
And I certainly don't have the political capital to convince my entire dev team to change.
You can actually do a huge amount of metaprogramming in dependent type systems and still have the the power of static checking. We're still figuring out how to improve the ergonomics to the level that it matches macros and other code-gen methods, but it's super exciting stuff.
I don't really the lumping of C in with Python and Ruby here. The C compiler picks up on that, too. All over this comment section people are calling C weakly typed, I don't get it. Is it because void* exists? Every language has something like that.
void * is part of it, but you can also implicitly cast from between integer types, and also between integers and enums. Think of passing an enum or an int into a function which takes a long as an argument.
I suspect most people which state that C has a weak type system are really talking about the fact that C has a weakly _enforced_ type system. You can break the type system's rules rather easily (or perhaps it's more accurate to say, the type system is too permissive), either way it doesn't provide you the same guarantees a stronger type system provides). At least that's my take on it.
I would say it's mostly a matter of use: In C you deal with void* or typecasts all the time, whereas in higher level languages it's much less common, either because the type system is smarter, or the constraints that it does have are more strictly enforced. For example: you can happily compare a char* and an int in C, but other languages like python might error at the thought.
/t/tmp.1q8r9dZAtX > cat test.c
int main() {
char *test = "test";
int i = 10;
return test == i;
}
/t/tmp.1q8r9dZAtX > cc test.c
test.c: In function ‘main’:
test.c:4:14: warning: comparison between pointer and integer
return test == i;
^~
C is incredibly permissive with regard to its types which are themselves very anemic. With the exception of the numeric primitives, C really only has a single type, the pointer, everything else is just syntactic sugar for various forms of pointer arithmetic. For instance arrays in C are just a shortcut for some pointer plus an offset multiplied by a constant determined at compile time based on what you've claimed is the underlying struct or primitive of the array. Importantly C is perfectly happy to take any random pointer into arbitrary memory and allow you to map any set of offsets into it. It's worth looking at for instance Rust that at least in theory allows the same thing to be done, but only by explicitly opting out of static checks via unsafe declarations. In normal safe code Rust will statically verify that a given reference (pointer more or less) is in fact referring to the type you're code is expecting it to, rather than the C approach of simply assuming the program is correct. Looked at another way, as far as the C compiler is concerned nearly everything is a pointer, and one kind of pointer is entirely exchangeable with another kind of pointer (with at most a cast being required, but probably not even that if it's the entirely too common case of being a void pointer). This is in contrast to nearly every other statically typed language that will either at compile or runtime verify that any given reference is the appropriate type before dereferencing it. C++ nominally at least has a more powerful type system, but since it was designed (in theory at least) as a superset of C, C's permissivity blows a giant gaping hole in its type system.
It's not just that void * exists, but that it's basically mandatory.
C's built-in arrays are super weak, so you need some library to do proper resizable arrays. Since C doesn't have generics, such a library will use void * as the type for putting values into the array and getting them back out again. You'll be casting at every point of use, and nothing will check to make sure you got the cast right, other than running the code and crashing.
> C's built-in arrays are super weak, so you need some library to do proper resizable arrays. Since C doesn't have generics, such a library will use void * as the type for putting values into the array and getting them back out again. You'll be casting at every point of use, and nothing will check to make sure you got the cast right, other than running the code and crashing.
There are other options though like macros and code generation. Code gen in particular can give you more options than generics without sacrificing any type safety.
I don't know why macro-based containers aren't more popular. You can have a quite usable interface, and even the implementation isn't that ugly. Example:
This approach isn't just more strongly typed than using void * for everything, it's also typically more efficient. For an array, you can put larger structs directly in the array rather than being forced to use a pointer. For a hash table, the same applies, plus you can avoid expensive indirect calls to compute hashes. (There are alternative non-macro approaches that trade off that overhead for other types of overhead, but you can't do as well as with a specialized container.)
I guess you could ask, at that point why not just use C++? And a lot of people do, and the people left writing new C programs are often traditionalists who don't want to switch to new approaches. And to be fair, there are disadvantages to macro-based containers, like increasing build time. But I still think there's room for them to see more adoption.
I use a code generator. It has a great type system, it's composable, mature and it can even compile pretty fast with the right tooling. It's called C++!
Templates are good for some things but they only do a fraction of what code generators can do. With code generation you can generate types from database tables, web APIs, etc. You can do things like declaratively declaring database views and generate huge chunks of an application. It can handle all sorts of boiler plate code that you can't do with templates alone.
Except when it's not. Just five days ago I was debugging an error in my Erlang
port driver that was caused by me passing receiver (ErlDrvTerm, an int in
disguise) in the place where I wanted number of iterations. The funnier thing
was that the declaration of the function had the arguments in correct order
(and that's what guided me), but definition had them swapped. The compiler did
not catch that bug, because, well, both are ints, so apparently the
declaration and definition match, don't they?
That’s why people should use one-element structs instead of typedefs for that kind of use case. A struct is a distinct type that can’t be accidentally mixed up with random integers, but its memory representation and efficiency will generally be identical; and you can add one-liner conversion functions to minimize syntactic overhead when you do need to convert to/from raw integers. Same idea as ‘newtype’ in Haskell; it works pretty much just as well in C, at least for ‘ID number’ sorts of types where you’re usually just shuttling values from place to place rather than doing any arithmetic. (For types where you do need arithmetic, it gets pretty ugly in languages without operator overloading. Except Go, which doesn’t have operator overloading but does have builtin support for defining distinct versions of integer types.)
In this thread, a.lot of people are conflating strong/weak typing with static/dynamic typing.
Static typing versus dynamic typing is fairly binary: if your types are checked at compile time they're probably static, while if they're checked at run time they are probably dynamic. Haskell, C are statically typed, Python, JavaScript are dynamically typed.
Strong/weak typing is more of a spectrum. A strong type system can check many properties of programs and accommodate many patterns as types. A weak type system, on the other hand, can't check many properties of programs, and has to be bypassed to accommodate common patterns. JavaScript has probably the weakest type system, because it checks almost nothing ("hi" + 42 returns "hi42" even though this is nonsensical, {}.foo returns undefined rather than throwing a type error). C is fairly weakly typed because you can add disparate types (int* + int returns int* even if you intended to add two integers) and the type system has to be bypassed with void* to do anything sizeable. Python, ironically, is slightly stronger, in that applying operators to objects of types with no defined relationship throws exceptions ("hi" + 42 errors). A spectrum from weakest to strongest might look something like: JavaScript, C, Go, Ruby, Python, Java, C#, OCaml, Haskell.
My personal experience is that the difference between static and dynamic types isn't very important to my development process or code quality. I have to run and unit test my code to verify it, so the checks happen regardless of whether they happen at compile time or run time. But the difference between strong and weak typing is huge. Strong types catch more bugs, but perhaps more importantly, they catch those bugs where they occur. A type error when adding "hi" + 42 is far more useful for debugging than a mysterious unit test failure on a completely different function where it's returning "Hi42username" instead of "Hi Username" because you added the wrong variable. A segfault 30 lines later is harder to debug than an error when trying to add an int to the value at an int*.
I find that people doing these claims have seldomly really worked in large Python codebases...
Personally, I find it pretty workable in Python with a big codebase (but you have to respect the rules like having a good test suite -- you change the time from compiling to running your test suite -- which you should have anyways)...
I find that the current Python codebase I'm working on (which has 15 years and around 15k modules -- started back in Python 2.4, currently in Python 2.7 and going to 3.5) pretty good to work in -- there's a whole class of refactoring that you do on typed languages to satisfy the compiler that you don't even need to care about in the Python world (I also work on a reasonably big Java source codebase and refactorings are needed much more because of that).
I must say I'm usually happier on the Python realm, although, we do use some patterns for types such as the adapter protocol quite a bit (so, you ask for a type and expect to get it regardless of needing a compiler to tell you it's correct and I remember very few cases of errors related to having a wrong type -- I definitely had much more null pointer exceptions on java than typing errors on Python) and we do have some utilities to specify an interface and check that another class implements all the needed methods (so, you can do light type checking on Python without a full static checking language and I don't really miss a compiler for doing that type checking...).
I do think about things such immutability, etc, but feel like the 'we're all responsible grown ups' stance of Python easier to work with... i.e.: if I prefix something with '_' you should not access it, the compiler doesn't have to scream that it's private and I don't need to clutter my code -- you do need good/responsible developers though (I see that as an advantage).
> I definitely had much more null pointer exceptions on java than typing errors on Python
Null pointers are a type error. The fact that several nominally "statically" typed languages don't differentiate between nullable and non-nullable types is a significant source of failure in their type systems. Using a modern language that properly identifies nullable values as a distinct type from non-nullable ones goes a long way towards eliminating a whole host of problems. It will be interesting to see what things look like in 10 years or so once Rust has had time to really displace a significant portion of the C and C++ code in the wild, and hopefully Kotlin has killed off Java (and if we're really lucky Typescript has done the same more or less with Javascript).
I'd worked in OpenStack for 4 years and with Python in general for about 10 years.
I can say from my experience it is definitely possible to maintain large codebases in Python. The type errors of the superficial variety that the OP refers to were usually caught before they made it to production (and were rare besides if you were experienced enough to avoid them). It requires discipline to maintain tests and write code in a way that avoids errors.
I've been learning OCaml and Haskell for a couple of years along with formal methods using TLA+ and Lean. I used to think type theory was the accounting of maths. I still think that's at least partly true but the power it brings you as a programmer is quite powerful.
I find working with Haskell or OCaml to be much more productive. Instead of stepping through a debugger or following tracebacks (a descriptive error) I get prescriptive errors as I make changes to a Haskell codebase. The propositions in the type system form a much better specification than unit tests alone.
I still like Python and C for many reasons and will continue using them where appropriate. However I think Haskell/OCaml offer quite enough power that everyone should at least consider what they bring to the table.
I do the exact same thing on large codebases of Ruby, but instead of the compiler type-checking errors, it's the test suite errors.
It's true that static type-checking proves the absence of an entire class of errors. But it doesn't prove that the code does the correct thing; it could be well-typed but completely wrong. On the other hand, tests prove that the code does the correct thing in certain cases. ...Of course, it's up to the developers to actually write a good test suite.
The faster we can all accept that there are pros and cons to both, the faster we can come up with a solution that takes advantage of the best of both worlds. That's the whole point of this OP.
I, personally, have always wondered about ways to dial in to the sweet-spot over time as a project matures. At the start of a project, shipping new features faster is often more important. But if the project survives, maintenance (by new developers) and backward compatibility become more and more of a priority.
Testing is not the answer to the problem of knowing if I refactored everywhere necessary. In a statically typed language I don't even have to worry about what do I do if my function is passed a var of the wrong type, it won't compile.
> The developer is encouraged to think of the invariants before trying to prove that their implementation satisfies them. This approach to software development asks the programmer to consider side-effects, error cases, and data transformations before committing to writing an implementation. Writing the implementation proves the invariant if the program type checks.
I really wish more languages took this to the logical conclusion and implemented first-class contract support. It seems work on contracts stopped with Eiffel (although I've heard that clojure spec is _kinda_ getting there).
Contracts are useless. They merely describe what you want your code to be, not what your code actually is. Just grab a pen and a piece of paper, and start proving things about your programs.
1. If the code doesn't conform to the contract, it will fail on the contract boundary, with a well-defined error. If this is useless, then `assert` is also useless, which it is, of course, not.
2. With a sufficiently well-designed language and sufficiently smart compiler, you can move some contract checks to compile-time. See Racket.
3. If your language supports both static and dynamic typing, the contracts are a dual of static types, which lets you interface the static and dynamic parts of the code seamlessly and automatically (in both directions). Again, see Racket.
Meta: I wonder, why it's mostly static-typing proponents who aggressively evangelize, insult the other side, are 110% sure they're right even though there is no scientific evidence and so on. Could it be the bondage&discipline approach of static typing just appeals to people with a certain mindset, who are statistically more probable to engage in such behaviors, no matter the subject?
But why? You were able to "comment" on the work of Felleisen and colleagues on contracts, declaring their effort of many years useless, yet you can't answer why did you do it?
Your utter lack of respect for people who happen to hold an opinion different than yours is typical, in my experience, for static-typing fans; as is your apparent - and wrong - belief that static typing was proven to be "better" (for some value(s) of "better") than dynamic typing.
There are certain groups of people where the above traits are overrepresented. I think there is a high probability that preference for static-typing correlates positively with belonging to these groups - and I wrote that much. Is that really a "slander"?
Sorry for focusing on that part, but your 0-2 points are too wrong to correct in a few paragraphs, and I don't have the time for writing more than this.
Yeah, actually I'm gonna go ahead and roll my eyes at the idea that parametric polymorphism is on the wrong side of the "diminishing returns of static typing". Less than ONE percent of Go code would benefit from type-safe containers?
The biggest issue with claims like "there are only diminishing results when using a type system better than the one provided in my blub language" is that it assumes people keep writing the same style of code, regardless of the assurances a better type system gives you.
"I don't see the benefit of typed languages if I keep writing code as if it was PHP/JavaScript/Go" ... OF COURSE YOU DON'T!
This is missing most of the benefits, because the main benefits of a better type system isn't realized by writing the same code, the benefits are realized by writing code that leverages the new possibilities.
Another benefit of static typing is that it applies to other peoples' code and libraries, not only your own.
Being able to look at the signatures and bring certain about what some function _can't_ do is a benefit that untyped languages lack.
I think the failure of "optional" typing in Clojure is a very educational example in this regard.
The failure of newer languages to retrofit nullabillity information onto Java is another one.
The article makes two main points: a) static typing has a cost and b) thus, any benefit it brings should be examined against that cost.
I am sorry, but I don't really see how you stating more benefits of static typing really counters either of them.
I recommend reading the article again. But this time, try not to read it as defending a specific language (I only mentioned my blub language so that it's a more specific and extensive reference in the cases where I use it - if you are not using my blub language, you should really just ignore everything I write about it specifically) and more as trying to talk on a meta-level about how we discuss these things. Because your comment is an excellent example of how not to do it and the kind of argument that prompted me to this writeup in the first place.
Those are not really 'points', though; they are far too trivial. Obviously, nothing counters them, because they are tautologies that could just as well apply to any subject.
The point is to explore a comparative difference in value, and that is realized through mastery of the tool, not merely living in a world where it exists.
> This is missing most of the benefits, because the main benefits of a better type system isn't realized by writing the same code, the benefits are realized by writing code that leverages the new possibilities.
The inverse is also true; you don't really get the benefits of dynamic typing until you start doing things differently to take advantage of that difference. If you still code like you're in a static language, you'll miss the benefits of a dynamic one.
These graphs really mean nothing. There is no data behind them. I might as well make a graph that conveys a non-descript correlation between how much an article bashes static typing & assertion and how high it is on HN.
They're just sketches. That's part of the point, and the article says that directly. The point isn't the exact shape or slope of the curves, but just their asymptotic behavior and the relationship of "correct features/day" to the other two. I.e. As long as the two curves have that general shape, then the "sweet spot" exists somewhere between 0-100%, the exact location of which depends on language, developer experience, and business priorities. The exact numbers are irrelevant to the article's point.
More realistically, it's an educated guess based off the author's personal experience as well as their understanding of the experiences of other developers operating under different constraints.
The author makes it clear that the analysis is not perfectly rigorous. There is a very wide landscape between perfectly rigorous and completely useless.
Do you think the article fails to hint at any of the fundamental dynamics of how type systems affect software development? How so?
I'm not who you're replying to, but for me the charts didn't make sense either.
For one example, I don't think it's a given that the green line (velocity vs % type-checked) should have a negative slope. Maybe in some cases, for some projects or some people, but certainly not universally. At least part of it would have been positive on almost all projects that I've worked on, and I'm not doing rocket science.
Then, the combined chart just looks at the amount of bug-free output, completely ignoring the amount of bug-ridden output. That latter part doesn't just get discarded, it needs fixing, and bugs that were only discovered in production are expensive to discover, debug and fix.
This is in addition to pretty much every other top level comment in this thread, a lot of which bring up important points that are unaccounted for even conceptually in the charts.
You beat me to the same comment. It's pseudoscience. I guess they're measuring the anxiety at HN that people's sunk-costs in stringly-typed runtimes won't keep guarenteeing obscene salaries.
Quote -- "The answer of course is simple (and I'm sure many of you have already typed it up in an angry response). The curves I drew above are completely made up."
Think again--since when do graphs depict only cold, dry data? Graphs have always been useful for depicting relationships--real or proposed. Line graphs in particular are often found depicting proposed relationships rather than real data (though often inferred from data,) since for all cases where the real data is discrete, this would result in a scatter plot rather than a line.
I just don’t buy that go is some sort of sweet spot because it doesn’t have generics. Generics pretty much exist for maps and slices, because they are needed in real programs. The language designers just don’t let you make your own generic collections.
Yeah far from finding a sweet spot, Go exists in some kind of type system ghetto, because its type system is so crippled users have to resort to code generation (go generate).
Neither Python nor Java programmers have to do that.
Yeah Go is weird in that its static type system doesn't to provide you with great static typing power but instead it's just there as a sort-of sanity checker. If there's logic, they say write it with data structures and functions. Have invariants? Enforce them yourself.
If Go is annoying with how little power it provides, that's fair, but other type systems can be just as annoying then, because when given the ability to, type astronauts will blast off into space, purely as a matter of honor or instinct.
Besides, code generation isn't all that bad. Java programmers will eventually find some kind of code generation in their build setup (serialization/schema tools).
Yeah, I've noticed that Go APIs are very stringly typed. The APIs are not very self documenting, and it is hard to figure out whether something is nullable or not. Libraries often require you to initialised data in a partially invalid state and the whole thing feels quite error-prone and flaky.
There's nothing wrong if users independently choose to use code generation. However when a programming language starts to rely on it, it becomes a major problem.
We've been here before with the C preprocessor. There's nothing wrong with having a preprocessor, but in C it is necessary to use the preprocessor and that causes a lot of problems, like making it especially difficult to write tools.
The fact that maps/slices/channels already exist generically is what puts Go into the sweet spot. You have generic containers for the vast majority of use-cases, so the value-added consideration of being able to cover more use-cases with generic containers becomes a lot smaller.
In a hypothetical world where the designers never added the specific containers they did, you'd get a whole lot more value out of generics for containers. But it turns out, the designers used what seems on the surface like a kludge to get most of the benefits, while saving most of the cost. It's a perfect embodiment of the kinds of tradeoffs I'm talking about.
You have containers for all the use cases the designers thought of, but then you have it worse than Python for all the other use cases, and you are stuck doing code generation or type erasure. It is impractical to expect go’s designers to have foreseen the best trade off for every codebase.
Architecture astronauting can be prevented with best practices and code review, not with language limitations. It’s a fools errand to try, code generation allows you to get all the complexity and more of generics.
> It is impractical to expect go’s designers to have foreseen the best trade off for every codebase.
Which is not the argument made by anyone. Indeed, I explicitly acknowledge that there is a certain fraction of use-cases not covered by the builtins. So there isn't really any disagreement about this.
The question is how large this fraction is, how much it would benefit and how inconvenient/costly the existing workarounds are. Like all engineering questions, these are impossible to talk about when dealing in absolutes. And once you actually talk about these questions quantitatively, I achieved the goal I had with the post - to change the debate into a quantitative one explicitly acknowledging the tradeoffs involved.
> Architecture astronauting can be prevented with best practices and code review, not with language limitations.
I work at a company which has probably one of the highest standards in regards to code review in the industry. As such, I disagree with you that it is effective in addressing this.
> It’s a fools errand to try, code generation allows you to get all the complexity and more of generics.
If that's the case, where do the complaints come from about the lack of generics? It seems that Go really has generics then, in your opinion?
Of course, that's a strawman and a misrepresentation of your argument. But what makes this a strawman, the difference between the existing workarounds and actual generics, is just as effective an argument for your side as it is one for my side. Because codegen is made so inconvenient, people bias heavily towards using the builtins, away from custom data structures, if they can at all get away with it. Thus greatly reducing the overall complexity of the codebase.
So it would seem to me, that this argument is logically flawed. Either codegen is a poor replacement, thus leading to people using less generic code, thus there is an effective reduction in complexity. Or codegen has the same effect on complexity, which would mean it is used just as much, meaning it can't be that bad a workaround.
Code generation achieves the same effect with more work and without a standard abstraction in the language it takes more effort to understand. Using general purpose primitives that are blessed to be generic similarly takes more work to understand when it exposes too many underlying implementation details. A nice wrapper class would work much better.
I don’t agree that using piles of built in objects makes the code easier to understand. If I want a Tree<Node, Node, Value>, how is using lists of lists and integer pairs making my code easier to reason about? Or using code generation to make reams of classes that create a Tree for everything I want, and anyone who uses my functions? How is encouraging either of those things a positive?
There's a point beyond which you spend more time proving things about your code than writing it, all the way up to the point where your ability to prove things about your code in your chosen type system starts to affect the kinds of solutions you can construct, and a different kind of complexity creeps in; representational complexity rather than implementation complexity. This can be a source of error, not just inefficiency.
Just a technical point that hints at a significant philosophical idea: The asymptote cannot reach 100% of program behavior in any finitary way. That would solve the halting problem. The x-axis should go off to infinity. Also, it's not a smooth progression. There are huge jumps in expressivity involved here. Going from Java-style types to Hindley-Milner to full System F are all massive jumps in expressivity. There are also incompatible features of type theories. Type theories are a fractal of utility and complexity.
A type system doesn't only describe the behavior of the program you write. It also informs you of how to write a program that does what you want. That's why functional programming pairs so well with static typing, and in my opinion why typed functional languages are gaining more traction than lisp.
How many ways are there to do something in lisp? Pose a feature request to 10 lispers and they'll come back with 11 macros. God knows how those macros compose together. On the other hand, once you have a good abstraction in ML or Haskell it's probably adhering to some simple, composable idea which can be reused again and again. In lisp, it's not so easy.
A static type system that's typing an inexpressive programming construct is kind of a pain because it just gets in the way of whatever simple thing you're trying to do. A powerful programming construct without a type system is difficult to compose because the user will have to understand its dynamics with no help from the compiler and no logical framework in which to reason about the construct.
So, a static type system should be molded to fit the power of what it's typing.
The fact that every Go programmer I talk to has something to say about their company's boilerplate factory for getting around the lack of generics tells me something. This is only a matter of taste to a point. In mathematics there are a vast possibility of abstract concepts that could be studied, but very few are. It's because there's some difficult to grasp idea of what is good, natural mathematics. The same is in programming: there are a panoply of programming constructs that could be devised, but only some of them are worth investigating. Furthermore, for every programming construct you can think of there's only going to be a relatively small set of natural type systems for it in the whole space of possible type systems.
Generics are a natural type system for interfaces. The idea that interfaces can be abstracted over certain constituents is powerful even if your compiler doesn't support it. If it doesn't, it just means that you have to write your own automated tools for working with generics. It's not pretty.
> The asymptote cannot reach 100% of program behavior in any finitary way. That would solve the halting problem.
There are languages that enforce termination. They only accept programs that can be shown to terminate through syntactic reasoning (e.g., when processing lists, you only recurse on the tail), or where you can prove termination by other means.
Coq is like this, as is Isabelle, as is F* , as are others. They also provide different kinds of escape hatches if you really want non-terminating things, like processing infinite streams.
This "we can never be sure of anything, because the halting problem" meme is getting boring. Yes, you cannot write the Collatz function in Coq. No, that is not a limitation in the real world.
> This "we can never be sure of anything, because the halting problem" meme is getting boring. Yes, you cannot write the Collatz function in Coq. No, that is not a limitation in the real world.
How about, say, a video game? That's something where we reasonably _want_ it to not terminate, because we're primarily interested in its side effects.
That's what the escape hatches are for. In Coq, for instance, you can also write functions processing infinite streams, provided that they also produce something regularly. For example, in a game, you could write a function from an infinite stream of inputs to an infinite stream of frame updates. You can not write functions that would not terminate while computing the updates for some given frame.
Alternatively, you just write a function to iterate your game world update N times, where you choose N large enough to ensure that your game can run until the heat death of the universe. That's not a nonterminating function, but it's long-running enough for all practical purposes.
I'm aware of strongly normalizing systems and the escape hatch of coinductive programming. But when we're talking about the space of all programs, the fundamental limit of incompleteness is important. How else do we judge the merit of a type system except by seeing how it fits into the overall space of computable processes?
There are two ways to see type systems. In the first way you construct terms along with their types, this is called Church style. In the second way, the terms exist before their types and you use types to describe their behavior, this is called Curry style. In particular take System F. In Church style the terms of System F come with their types. In Curry style we see System F types as a way to describe the behavior of untyped lambda terms.
I used to think Church style was more important but lately I've been more partial to Curry style. Programs exist before you type them, type systems tell you how they behave. They also tell you how to construct programs but this is subordinate to the more fundamental descriptive capacity.
> But when we're talking about the space of all programs, the fundamental limit of incompleteness is important.
I agree with this. But I think that usually we are not really talking about all programs. We are talking about useful programs, and those are usually terminating. In theory, not always, see first-order theorem provers; but in practice, we always call a prover with a time limit because nontermination isn't useful.
> Programs exist before you type them, type systems tell you how they behave. They also tell you how to construct programs but this is subordinate to the more fundamental descriptive capacity.
That's an interesting point, and I agree in many respects. I think when programming in a dynamically typed language, I approach things in one style, and in statically typed languages in another style. But specifically for termination, I don't think so. I never want to write a nonterminating program; the termination property for my programs exists (as a requirement) before the program does.
> Pose a feature request to 10 lispers and they'll come back with 11 macros.
What a ridiculous stereotype. Clojure community typically maintains the belief that macros are the last resort for things that genuinely justify them. You really shouldn't spread hyperbole like this.
In all honesty that was reckless for me to include. I meant it as gentle ribbing between functional comrades. In truth I admire Scheme-like lisps very much.
On the other hand, once you have a good abstraction in ML or Haskell it's probably adhering to some simple, composable idea which can be reused again and again.
The catch there, as is often the case, is hidden in the word "good". Working with text data in Haskell is almost as painful as working with text data in C++, and for much the same reason: the original abstraction is far from ideal for most practical purposes, but became the least common denominator. Everyone and his brother has written a better string abstraction or more powerful regex library or whatever since then, but they're all different.
Consequently, even with the power of generics or typeclasses, you still often see developers just converting to and from the primitive default representation for interoperability. Static typing will at least stop you from screwing that up, which certainly is an advantage over dynamically-typed languages in some situations. However, it apparently hasn't made it any easier for the developer community as a whole to migrate to a better abstraction as the default.
In short, we often don't know what will turn out to be a good abstraction until we've gained a lot of experience, and in the face of changing requirements on most projects, we probably never can know from the start because what works as a useful abstraction might change over time. So while types are useful for checking whatever abstractions we have at any given time, until we've also got techniques for migrating from one to another much more smoothly and on much larger scales than anything I've yet encountered, I think we shouldn't oversell the benefits, particularly in terms of composability.
Many. That's the whole point -- to let you choose "the way to do something" that applies the best to your circumstances (development time, performance, allowable complexity, etc.)
So you are limited by your own mind and skills -- not by the language.
Also depends on your problem domain. If you have good test coverage but you're parsing strings found in the wild, you're going to spend a lot more time "debugging" your assumptions than AttributeErrors which would be caught by typing. Bug free code is not always the same as working code.
Disclaimer: Python user scarred by email header RFC violations
"I don't think it's particularly controversial, that static typing in general has advantages"
That's not really true, just a belief. I give you an example to start understanding these things: the exact same program written in a very high level and very expressive language, like Perl, instead of Go, is going to have at least 3 times less code and since defect rates per line of code are comparable, you would end up with at least 3 times less bugs. Suddenly reliability argument of static typing doesn't make any sense. That's because in PL research there is a huge gap in understanding of how programmers actually think.
I think you are right, but you only cover producing code. For maintaining code, it is another story. If you have to take over an unknown code base, I think static typing will prevent bugs to be deployed, because the typing system will detect errors you might not be aware of due to your incomplete knowledge of the code.
I was in favour of dynamic typed, but lean more and more towards static typing, like ocaml.
That's an argument for higher level languages over lower level ones rather than against dynamic typing.
And I'm not sure you should expect the number of bugs per line to remain constant across languages. Extra lines required because you have to do your indexing by hand as you're iterating over a list certain increases the chances of an error but the extra '}' required to end the block in some languages increases line count with very little chance of causing an error.
The effort to fix a defect is proportional to the time between introduction of a defect and it's discovery.
This is a basic intuition behind all good practices, including CI, QA, etc.
Types allow one to discover program defects (even generalized ones, when using some of the programming languages) in (almost) shortest possible amount of time.
Types also allows one to constrain effects of various kind (again, use good language for this), which constraintment can make code simpler, safer and, in the end, more performant.
Also, retaining dynamic types at runtime enables you to find type errors that the static type system could not discover, or that were worked around. Language implementations that discard dynamic types make it harder to find defects.
In this thread: people will bring out the same tired arguments for or against static typing, without commenting on the actual content of the post, which was quite good!
I have come to see type systems, like many pieces of computer science, can either be viewed as a math/research problem (in which generally more types = better) or as an engineering challenge, in which you're more concerned with understanding and balancing tradeoffs (bugs / velocity / ease of use / etc., as described in the post). These two mindsets are at odds and generally talk past each other because they don't fundamentally agree on which values are more important (like the great startups vs NASA example at the end).
I think this post was extremely hand wavy. It stated the same divide that is already known, but doesn’t actually make any arguments to why Go or whatever lies on some part of the curve, because it assumes that the way you program at different points on the curve are roughly the same but with more type boilerplate. Higher kinded types offer entirely new ways to program, and stuff like optional typing in Python makes it all much more complex than just “how long do I spend writing and reading type declarations”. I was left with an impression that the author was content with go, and that’s pretty much it.
I agree. The graph of static checking vs. lines of code should really be factored into static checking vs. amount of annotations to achieve that level, amount of annotations to write vs. how much that slows you down, and amount of annotations that are already written (in your own code or libraries you use) vs. how much that speeds you up. And those will vary wildly depending both on the language and the programmer.
Having programmed in languages ranging from Ruby to Coq, for web apps and games, I feel the sweet spot is somewhere in the neighborhood of Java/C#, i.e. include generics but maybe leave out stuff like higher kinds and super-advanced type inference (and null!).
The main use case of generics, making collections and datastructures convenient and readable, is more than enough to justify the feature in my view, since virtually all code deals with various kinds of "collections" almost all of the time. It's a very good place to spend a language's "complexity budget".
I wrote an appreciable amount of Go recently, with advice and reviews from several experienced Go users, and the experience pretty much cemented this view for me. An awful lot of energy was wasted memorizing various tricks and conventions to make do with loops, slices and maps where in other languages you'd just call a generic method. Simple concurrency patterns like a worker pool or a parallel map required many lines of error-prone channel boilerplate.
> An awful lot of energy was wasted memorizing various tricks and conventions to make do with loops, slices and maps where in other languages you'd just call a generic method.
I feel the same way going from languages with HKTs back to Java/C#...
Not sure why you think they're not as useful, it sounds like you're making the same argument as OP but just moving the bar one notch over...
I am. I think the OP is fundamentally right about the sweet spot being pretty far from either extreme, I just disagree slightly about where exactly :)
Subjectively, I use ordinary generics all the time, but see the need for HKTs only occasionally. It's entirely possible I'm not experienced enough to see most of their possible use cases, but then I'd wager most programmers aren't.
In my subjective opinion, Haskell has taken abstraction way past the point of diminishing returns, at least for the problems I tend to work on.
A large portion of advanced Haskell type system features seem to be about emulating things you could do with side-effects. I guess I prefer Rust's approach to managing side-effects, or even just Scala's implied convention of: use 'var' very sparingly, and mostly locally. Yes, some guarantees get traded away, but so much simplicity is gained.
I'm not very experienced with Haskell, but I've written a fair bit of Scala and I've utterly failed to see the value in scalaz and similar libraries, despite trying them a few times. They always seem to add lots of complexity without a tangible benefit.
Coming at it from another angle, I just don't see many cases where I feel I have to repeat myself due to a shortcoming of, say, Java's or C#'s type system. If I could add one feature to either, it'd actually be support for variadic type parameters.
As a counterexample, C# needed expensive language extensions to accommodate both LINQ and Async/await. Both can be implemented in Haskell purely as a library, thanks to HKTs.
Both Java and C# tend to rely heavily on frameworks such as Spring to workaround issues with the expressivity of the languages. This causes problems when one needs two frameworks (they don't in general compose).
In Haskell, HKTs allow one to write polymorphic programs that are parametric with respect to certain behaviours and dependencies, no dependency injection framework needed.
Please don't judge Haskell using Scala and scalaz.
I'm not sure what Java expressivity problem Spring is meant to solve. XML configs are basically just a duplication of what would be done in a static initializer, except you lose type-checking and get to find your wiring mistakes at startup time instead of compile time. Autowiring annotations can be nice when you first use them, but become inscrutable magic once some other poor sap has to come along and make changes to the original project setup.
I just don't understand what is so horrible and inexpressive about a static initialization block.
The only possible purpose I see to Spring is if for some reason you really need to be able to change how your dependencies are injected at runtime. (90% of Spring apologists point to this, and 99% of them never use it in practice.) Even then, I don't see how a Spring XML config file (which I have seen run to 4000+ lines, to my horror) is better than just reading some settings out of a properties file to pick an implementation in your static initializer.
Not sure about LINQ, I thought that was "just" syntactic sugar for a bunch of collection methods. Are you refering to extension methods as an unfortunate prerequisite?
But I think I get your general point: things like 'Control.Concurrent.Async' ('async'/'await') and 'Control.Monad.Coroutine' ('yield') are libraries that implement some and very generic type classes: 'Functor', 'Applicative', 'Monad'. This then lets you use features that are generic over those type classes ('do' syntax, 'fmap', ...).
It's been many years since I had a proper look at Haskell. Maybe it just takes more practice than I had back then to fully "get it". But I still don't see those abstractions being that useful in everyday programming. They seem to have huge potential for hard to follow code as you need to mentally unpack and remember more layers of abstraction, and the gain is not clear to me. Even the features that have trickled down to C# are not _that_ crucial I feel. The way mainstream languages pick the most useful use cases of those abstractions seems pretty OK to me.
(Also, macros and compiler plugins are another interesting avenue towards very powerful abstractions, with a different set of problems.)
As for Spring and dependency injection, I don't follow how HKTs would help there. Could you give an example? Aren't DI frameworks mostly about looking things up with reflection magic to automate, and arguably just obfuscate, the task of wiring things up in 'main'?
>They seem to have huge potential for hard to follow code as you need to mentally unpack and remember more layers of abstraction
That's the beauty of abstraction without side effects, you don't need to unpack anything. If you know what the inputs are and the outputs are, you don't need to know how it works or what type classes are even used to transform certain things.
People use
sequence
all the time in Scala, not realizing it's only able to be implemented with HKTs of Applicative and Traverse. FYI, sequence flips a list of Futures to a Future of List, or a vector of Trys to a Try of Vector, etc.
Fair point about 'sequence'. There are probably a bunch of these I use regularly in Scala without realizing it. Though as a counterpoint, 'Future.sequence' wouldn't really lose _that_ much if it didn't return a collection of the same type. And I haven't yet felt the need for a generic `sequence`, which I'm sure scalaz has.
I don't buy your point about not needing to unpack side-effectless code, however. There are _always_ reasons to dig into code, be it bugs, surprising edge cases, poor documentation, insufficient performance, or even just curiosity. And those high-level abstractions tend to be visible in module interfaces too. I remember some Haskell libraries being very hard to figure out how to use if you didn't know your category theory :)
It's a pretty typical symptom I've seen a lot of hardcore FP developers exhibit: they forget how much time it took them to reach their level of mastery.
It's like spending ten years learning to speak Russian and then criticizing anyone who says that learning Russian is difficult.
Puzzling out scalaz code is difficult and requires an enormous investment in hours and practice, investment that a lot of people prefer to put into different learnings.
Mainstream developers forget just how much time they invest in learning the latest fad frameworks with new ad-hoc concepts and terminology. I guess "Hardcore FP developers" are fed up with this state of affairs and are looking towards mathematics to provide guidance and common patterns/names.
At least any knowledge of mathematics will not become outdated!
Yea, puzzling out some scalaz code takes investment. On the other hand, the library is used for web apps, network servers, database based applications, streaming libraries etc.
It's incredibly multipurpose, more so than even Spring or Guava or LINQ, and these are things that developers regularly have to invest serious time in.
The argument is just that FP libraries (like Scalaz) have a bigger payoff in the investment.
At Verizon Labs were have 20+ microservices that I have touched/looked at. Some use Akka, some use Play, some use Jetty, some use Http4s but everyone makes use of Scalaz somehow.
> The argument is just that FP libraries (like Scalaz) have a bigger payoff in the investment.
It depends on the people, not everybody has the inclination to dive so deep into hard core FP and they will be more productive using a different approach.
Don't make the mistake of thinking you've found the only software silver bullet that exists and that people who don't use it "don't get it", which is another attitude I've seen a lot of hardcore FP advocates embrace.
Just like async/await, LINQ (and even enumerators) are tied to special syntax in the C# language. HKTs allow Haskell to provide very general resuable syntax, such as do notation.
What I meant by "polymorphic programs" as an alternate to DI, is something like this:
doStuff :: HasLogger m => Input -> m Output
The effectful function "doStuff" above is polymorphic with respect to which logging implementation is used, it could even be one that uses IO. All made possible with HKTs.
Ok, the point about special syntax is fair, but as I said, I'm happy with the use cases that have trickled down to mainstream, and I'd argue there aren't _that_ many truly useful ones. I realize this is very analogous to how the Go programmer is somehow happy with the few generic collections they are granted :)
Your DI example seems to be an example of my earlier point about "emulating things you could do with side-effects". No HKTs are needed when you just pass an impure side-effectful Logger object. Or, as discussed in another subthread, you could do side-effect management with Rust-style uniqueness typing, which results in a less elegant but arguably easier to use type system. It's debatable, but it seems people struggle less with the borrow checker than with advanced Haskell.
I don't see how passing in a logger object explicitly is the same, this is what OO DI frameworks try to avoid, otherwise you'd also have to pass it down to other functions used inside. The example above works just like a Reader Monad, but we are not tied to any specific logging implementation.
I guess the side effecting version is just to use some global registry to look up the logging implemention to use. But such code does not compose.
Looks like we reached maximum thread depth so replying here.
I agree, the side-effectful choices are either a global, some DI container, or just passing it down.
For loggers, I think global lookup from some (pluggable) logging library is justified because logging is probably the most ubiquitous cross-cutting concern ever. For pretty much everything else, I think passing as a parameter is actually the best option. It's explicit and simple, and you don't even need to explicitly pass it around _that_ much if you store it in a field of a class that plays the role of a module. Most uses of the dependency will be in non-static methods, lambdas, or inner classes.
I dislike Reader because it's similar to a DI container (or a global) in that it's more work to figure out, for a given call site, what the last value written to it was. With parameters, you just climb the call chain.
Don't mutable and immutable references with lifetimes count? Sure, one could argue whether the borrow checker is really part of the type system, but it's a compile-time check either way.
Yes, in the standard library, an immutable object can hide mutable state in e.g. a 'Mutex', and effects to the external system aren't wired through anything like monads or unique objects.
I see those as compromises Rust makes in the name of pragmatism and being a system'ey language. I don't necessarily like all of them, but I find the general uniqueness typing based approach interesting.
See articles comparing Clean and Haskell for an interesting historical perspective, including how both approaches could be used to model side-effects in a purely functional language. Haskell "won", possibly because it was seen as more generic and composable. I always felt Clean's approach had merit too, so I was really glad to see Rust bring the idea, or a closely related idea, to prominence.
The standard library doesn't, and most crates don't, but I'm pretty sure nothing prevents you from writing libraries in a style where all IO requires mutable access to some explicit unique "World" object, similar to Clean.
Passing a unique world object around is effectively the same as composing with the IO monad, and borrowing 'f(&mut world)' is basically equivalent to 'let world = f(world)'.
Maybe someone will one day write a standard library in that style.
It is not going to be convenient because rust doesn't have higher kinds. I see people making this argument in other language contexts e.g. Ocaml; but they have no typeclasses, which make writing monadic style code extremely inconvenient.
> I think the OP is fundamentally right about the sweet spot being pretty far from either extreme, I just disagree slightly about where exactly :)
And I think an important take-away should be, that this perception is entirely subjective and colored by both of our experiences, preferences and the kinds of problems we work on :)
They emphatically do not. Ignoring types doesn't give you a type system "for free"; much the same way that building a shelf doesn't make you a librarian.
Like other commenters, I disagree there are diminishing returns to static typing itself, but rather diminishing returns to proper engineering in certain cases (i.e. do something as perfectly as possible).
By adding types (and in the extreme, dependent types), you're allowing compiler to prove more things about the code (to check correctness or generate more optimal code). If you actually need to prove more things, then it's better to leave that for a compiler rather than human.
Of course, if you're writing e.g. web scraping script, you don't need these guarantees and then you don't have to care about types. But the better engineering you want, the more static typing will help and there is no diminishing returns.
I really enjoyed how the analysis shows that different developers can have different equally valid opinions on this topic. It's where you place your values and preferences of programming, modified by what you are programming. The failure state of a cat photo sharing web app likely isn't as dramatic or important as that of a financial system or driverless car code. Great article.
Static typing reduces the time you spend on debugging. Automatically reducing errors in code is not just for reducing errors in the resulting program. It also greatly reduces the time you spend on hunting bugs, especially if you have a poorly designed type systems where errors are reported far from their origin. Null, interface{}, NaN etc. propagates errors and thus gives you a stacktrace that is worthless when it finally fails. It's a waste of time.
In my experience, the time saved from writing in a statically typed language where the compiler catches the bugs for you is made up by having to work more closely with the compiler, typically write more code (type annotations and other things) and in general spend that same time on compile-time rather than run-time bug hunting. Dynamically typed languages typically involve a lot less code, which is time gained.
That both forms of languages are popular shows that there are benefits in overall productivity to each; they are just different benefits.
The thing is that errors at compile time get reported almost instantly, but errors at runtime might be reported hours after you started your program if you are unlucky.
That's entirely correct, and one of the tradeoffs.
However, in a statically-typed language, you must satisfy the type checker for everything, which adds development time. In reality, there might be a small percentage of functions in your code base for which errors (either compile-time or run-time) would likely crop up, yet you must pay that cost for 100% of them.
So that's really where the debate comes from.
Dynamically typed languages can get around this problem by generative testing (in Clojure's case) which allow very fine-tuned aspects of your system's requirements to be automatically tested before run-time without writing tests, which offers some of the same confidence as a compiler.
May I ask what your experience of statically-typed languages has been? I find that most people have had a common experience where they didn't get to work in tandem with a fast compiler and a succinct language which inferred most or all types for them, and so their perceptions are coloured by that.
May I recommend giving ReasonML a try? Trust me when I say, you've never seen a faster compiler (except maybe C). Try writing a little experiment in ReasonReact and seeing the speed for yourself: https://reasonml.github.io/reason-react/
My theory is that there are different psychologies of developers. I always liked how C++ (now C#) checked a lot of stuff at compile time and I rely heavily on the compiler. On the other hand I know very good devs who hate this and prefer dynamic languages. Their whole style is geared towards dynamic languages where mine is geared towards as strict as possible typing.
I think the key is not to confuse both approaches and leverage the strengths of each to the max.
Time and time again I can make a well written functioning program in Java or C# at least twice as fast than using js and brothers. Sure it might have more "lines". Who freaking cares. My team and I square off all the time. "K, you use node I will use java" And the Java dev always wins. Its just so much faster, cleaner and mature. Its NO CONTEST.
There's one huge benefit to static typing people often forget: self documentation.
While, yes, top-quality dynamic code will have documentation and test cases to make up for this deficiency, it's often still not good enough for me to get my answer without spelunking the source or StackOverflow.
I feel like I learned this the hard way over the years after having to deal with my own code. Without types, I spend nearly twice as long to familiarize myself with whatever atrocity I committed.
Many dynamically typed languages offer excellent runtime contract systems (Racket, Clojure) that serve as an implicit documentation at least as well as a statically-type language. Often more so, because you can express a lot of things in contracts that are not easily expressed in type systems.
you can put arbitrary functions in a contract. with static typing that requires dependent types. and while i'm a fan, that's an enormous can of complexity to bust open.
say you've got a function that takes a list of numbers, and some bounds, and gives you back a number from the list that is within the bounds (and maybe meets other criteria, whatever). your contract for the function could require not only that the list be comprised of numbers, and the bounds are numeric, but also that the lower bound is <= the upper bound, and that the return value was actually present in the input list.
I consider Reading the source code to see what something does is a feature, if you can understand the code that is. If the code is easy to understand, there will be less bugs.
631 comments
[ 5.0 ms ] story [ 355 ms ] threadAnd I disagree with the barrier to entry argument. Static typing, by enabling rich tooling, helps a beginner (like it helped me) a lot more by giving live feedback on your code, telling you immediately where you have a problem and why, telling you through a drop down what other options are available from there, etc. Basically makes the language way more self-discoverable than having to RTFM to figure out what you can do on a class.
This isn't to say that static typing isn't good at this. Just, even with that, there is a lot of effort that goes into making the rich tooling. A lot of very smart and capable folks work hard to make Visual Studio.
Of course there are cases where dynamic languages do worse, but it balances out I think.
For OO languages and methods it does get a little guesswork-y, and tools often offer a wider range of guesses than is correct for completion. But you can show the class along with the offered completion, so it's not too bad.
C# has a very weak version of this with the auto keyword. Languages like Crystal take it much further by tracing the flow of data through the entire program. It generally works quite well, though there are a few edgecases that require explicit type annotations.
As for auto-completion, some languages feature designs that make it easy to offer auto completion even without type information. For instance, Elixir doesn’t have methods. You only have functions defined on modules, and it’s trivially easy to know what functions are defined on a module.
So it’s possible, but there are some limitations.
> C# .... Crystal
Both are fully statically typed languages with type inference. Those are unrelated to the argument the parent comment is making.
I can and have built a totally untyped language within a fully statically typed language - nostrademons' Scheme-in-haskell exercise is a lot of fun.
You just have to define a Universal type and then back out of all that nasty compile-time nonsense. Everything is Univ and Univ is everything.
That would imply there's no type inference possible with dynamic languages - either at "compile" time or run time.
(Wouldn't it also imply that static typing and strong typing are synonymous?)
Unless you think original means Bill Opdyke's thesis work, where the tooling was written for C++ and written in CLOS.
http://www.laputan.org/pub/papers/opdyke-thesis.pdf
In general though, the more you can formally reason about the program, the more you can automate program transformations (refactoring). Programmers in dynamic languages will argue that the amount of code is far less than the equivalent code in a mainstream statically-typed language, so while the cost of refactoring may be higher per unit, the number of units is less, so the overall cost is the same (or less).
I believe in using the best tool for the job...some use cases would benefit more from static typing, while others would benefit more from using a dynamic language. One of the most important factors is the team and its engineers' backgrounds, preferences, styles, etc.
Yes. PHP developers.
:)
...but there's plenty of sales charlatans out there who will say "I intend to get the manager of that IT dept to make its developers use my tool for the job, and I don't care if my tool is the right one or the wrong one."
The realization that with types, smart enough compiler can implement interfaces for me, was amazing.
Unfortunately, I am afraid that it will take a while for these techniques to go mainstream. A.f.a.i.k most a mainstream language can do, is to fill in the method stubs for you.
You can pretty much use any language in that scenario. But the chickens come to roost around day 30+ or so.
Meanwhile real-world non-trivial projects tend to be large projects.
Nice to be prepared for that instead of gambling on "surely we'll extract out smaller projects that fall on the right abstraction boundaries in the face of unknown future requirements."
How big are the "real-world codebases" you're talking about, and how many programmers are working on the code? Once you hit 5-10 million lines of code and/or thousands of developers, static typing really helps manage complexity.
Well that's provably false, because there exist properties that you can type check that literally can't be verified via unit tests, even in principle. For instance, race and deadlock freedom.
Are you kidding? Python programming's my day job but Haskell is an order of magnitude easier to refactor.
There are no diminishing returns. Defining types is easy and enhances code readability.
Getting a language to the point where it's workable for serious projects is a lot of work. Rust is getting there with the backing of Mozilla, Haskell has made some decent strides too (but still has a way to go, and I think has some pretty fundamental flaws entirely apart from the type system). It'll be probably another decade at least before we see any dependently-typed languages getting a serious foothold, but I do think they're going to become a lot more common eventually.
IMO, machine assistance is useful to the extent it relieves us humans from work. In particular, types are useful to the extent they can be inferred. Beyond that, you still need to prove the correctness of your programs on your own, so there is no point to the ceremony of writing down those proofs in a machine-checkable format.
It's also self-evidently wrong. Agda was first released in 1999, ten years before Go. If you use a wallclock interpretation of "maturity", Agda is twice as old as Go and Idris is roughly as old as Go. Both are used significantly less (by several orders of magnitude), though. Despite them having a far stronger type-system.
If you, on the other hand, you are using a "developers' time" interpretation of maturity, on the other hand, you are making a circular argument, i.e. "Agda is seeing less use, because it has been used less", as resources invested in a language ecosystem tend to be strongly correlated with it's usage.
Essentially the types being used as so complex the type checker cannot automate the decision about two types being compatible so you have to write maths proofs to help. The types used in mainstream languages are simple enough that the type checker never needs help like that.
The cost of formal verification right now is immense but the benefit is close to bug free code. Mainstream strong statically languages require nowhere near the same amount of effort and give clear benefits over dynamic types.
I don't think they enhance code readability - I think they make it worse. I never look at the type when I am reading code, it just gets in the way.
Yes, you can find all references to a method in Smalltalk -- but those references are not separated-out from all the references to other methods that happen to have the same method name but are defined on a different class.
With type information for the receiver and method arguments, we can find just the references we're looking for.
Automated refactoring was invented in Smalltalk, claiming it's a benefit only static typing provides is to not know history.
History: In Bill Opdyke's thesis work, the tooling was written for C++ and written in CLOS.
http://www.laputan.org/pub/papers/opdyke-thesis.pdf
Incidentally, what's your source for "Ralph Johnson… was the creator of the first Smalltalk refactoring browser" ?
We still don't know if you simply confabulated your other claim.
Not just, "who the hell uses this", but "where the hell is this defined" as well.
On Common Lisp, a dynamic language, I can also get this answered instantly. I just press a key combination on a method call and i jump to the definition.
So this isn't exclusive to statically typed languages.
It is not. A language feature is either amenable to static analysis (not necessarily type checking) or it is not.
> Consider dynamic class loading in Java, dlopen / reinterpret_cast in C++ etc.
This actually emphasizes my point. Features that are not amenable to static analysis are problematic for tooling.
How can it be a niche language, if it's an ANSI standard, has more than 8 or 10 fully feature, standard-conformant implementations, runs on most CPU types, and has been proven to work in production systems for spaceship guiding, worldwide airfare reservation and credit card transaction verification?
You use Js and Python because you choose to use it, but it's not the only choice. Not only Common Lisp, you could also be working in Clojure with many benefits.
Maybe good tools are able to perform some static analysis and rule out some of the methods with the same name but impossible types, but the language doesn't rule out situations where the best the tool will be able to do is show you all of the function definitions with the same name as the (dynamically dispatched) function call site you're looking at.
Let's say you have seven different type hierarchies having dynamically dispatched functions named "run", with 5 definitions in each hierarchy, for a total of 35 functions named "run". In a statically typed language, if the code compiles, it's possible to narrow down the type for a given call site to either one of the hierarchies or one definition, meaning you have to look at either 1 or 5 definitions. In a dynamically typed language, there are situations where legal code results in the tool having to throw up its hands and show you all 35 definitions.
The flip side is that if you really have a spot where you'll need to dispatch to any of the different hierarchies, then in a strong statically typed language, you'll need to either create an algebraic sum type covering all 7 hierarchies, or you'll need something like a typecase / typeswitch statement to enumerate out your possibilities.
And even in a statically-typed language there will be cases where the tooling can only determine fairly generic things statically.
I don't see anyone advocating for abandoning static typing over that occasional limitation. Yet I do see people proposing similarly-infrequent issues as cause to abandon dynamic typing.
When $problem happens in $language_I_dislike, it's a clear sign that the language itself is inherently broken.
Well, usually. It gets a little confused when you start using dependency injection containers, or dynamic requires, or anything like that.
And that's really all I care about, I'm not about to start writing production code in Lisp.
And the other way around: Statically typed languages without module systems, such as C, exhibit this problem too.
The 99% stat is quite likely a big exaggeration.
Refactoring is far far harder to do reliably, and more straining as so much more responsibility on the programmer.
Usually I use normal keywords for throwaway or glue code, but anything important (my actual domain entities) will be namespaced, allowing (relatively) pain free refactoring.
Cursive has a few good refactoring tools/shortcuts, but I would also like to see extract/inline/move for functions.
Its not a huge problem, just something I miss from the static languages.
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 true is that the requirement to name types means that a textual grep is way more reliable than it is in C. If I want to find all places where a Python class is used in a large codebase, I might as well give up.
Also they are backed by Clang and muuuuuuuuuuuch faster than in Visual Studio + whatever paid extension
A very nice feature it has and that I didn't see elsewhere is the optional case-sensitive renaming. eg renaming Foo to Bar will also change foo to bar and FoO to BaR.
In smalltalk the parameter names are part of the function name to reduce the likelyhood of name clashes. You still have the same problem when you have two functions with the same name and parameters.
Nobody ever talks about that little horror when they bring up how Smalltalk could to refactoring JUST FINE without static types. It wasn't just fine, turns out.
For four days, I spent debugging a python production script because in one place I had typo'd ".recived=true" on an object and just couldn't understand why my state machine wouldn't work.
And very quickly, the whole team became fans of __slots__ in Python.
I still write 90% of my useful code in python, but that one week of debugging was exhausting & basically wouldn't have even compiled in a statically declared language. Even in python, the error is at runtime, after I got the __slots__ in place.
nothing stops you from using static typing with python3
The typing spec provides for supplementary "stub files" that can be provided for third-party dependencies without their own annotations. The typeshed project provides these for a fair and quickly increasing number of common dependencies, and is plugged into pycharm and mypy by default: https://github.com/python/typeshed
Can we stop pretending that adding type annotations to a 'dynamic' language solves the "good static typing" problem? It's just silly.
(About as silly as pretending that static types solve all problems.)
Is that really a dynamic typing problem or a language that allows you to create instance members anywhere? It seems like that is a flaw in the declaration model of the language and not a static / dynamic issue.
The diagnostics after the warnings are then from evaluation.
Those are nothing; TXR Lisp will get better diagnostics over time. I'm just starting the background work for a compiler.
There is dynamic and then there is crap dynamic.
Don't confuse the two.
There is crap static too. Shall we use C as the strawman examples of static? Hey look, two argument function called with three arguments; and there's a buffer overrun ...
Excellent. My point exactly. I have no fear of using a static or dynamic language, as long as it is a good implementation of a statically (or dynamically) typed language.
Good "dynamics": All the Lisp-family languages. Smalltalk. Julia. Lua. Tcl.
I mean, we can argue the semantics of what, exactly "static type checker" means, but...
A "static language" occurs when we have a model of program execution that involves erasing all of the type info before run-time. Or most of it. (Some static languages support OOP, and so stuff some minimal type info into objects for dispatch.)
Note how above, my expression executes anyway; the checks produce only warnings. The warning for the lack of a binding for the a variable is confirmed upon execution; the non-existence of the slot isn't since evaluation doesn't get that far.
If we retain the type info, we have dynamic typing. There is no limit to how much checking we can do in a dynamic setting. The checking can be incomplete, and it can be placed in an advisory role: we are informed about interesting facts that we can act on if we want, yet we can run the program anyway as-is.
For example, these days it's quite possible to ask GHC to defer type errors to runtime. Does that mean that the GHC dialect of Haskell is dynamically typed? This is basically a command line switch away, btw.
Retention of type information does not "dynamic typing" make. As a trivial example, consider C++ RTTI.
You really have just reinvented static (type) checking and a good runtime. There's no shame in that, but let's not pretend that these are opposing forces.
I still think you're just arguing semantics.
EDIT: Incidentally, the statically typed crowd can even go the "other way", namely from runtime -> compile time. For example, it's quite possible to derive a static proof/type from a runtime value in e.g. Idris by pattern matching as long as you're meticulous about building up the proof.
You would think by looking at the code that the creators had a 30 word vocabulary, because 80% of the code uses the same six nouns and four verbs to pass data around and what you use those for depends on the context of who is calling it.
Oh, but the entire thing is written using promises, so most of your function calls have no context. It's hell, and I'm starting to worry that Node has dug itself a reputation hole it will never get out of.
vscode seems to figure out the types in javascript without any static typing.
>But it is great for refactoring
Searching for strings isn't that much worse. Also, when it comes to web development, you cross into the client-side and suddenly you can't refactor. So you can only refactor the server-side and end up with a mismatch.
>finding all references to a function or a property or navigating through the code at design time
You can do that without static typing in many cases as well.
>Basically all the features visual studio excels at for .net languages.
When I was working in c# on the server and javascript on the client, I really hated having to go back into c#.
>telling you through a drop down what other options are available from there
vscode seems to be able to figure this out most of the time as well.
I think static typing is necessary when you need performance because all of the fast languages are statically typed.
I think a lot of these things are about organisational complexity and making sure new and average programmers don't screw up the software. It is about large companies trying to manage their organisation, it isn't about the complexity of the code itself.
There are a ridiculous amount of tech companies that have used dynamic languages to go from nothing to the biggest companies in the world and only switched to static languages well and truly after that occurred.
Doesn't it do this by treating Javascript as a statically-typed language (Typescript) and using type inference?
Are there not definitions written by someone or a tool that vscode looks at?
That is what I saw using some npm packages with typescript: http://definitelytyped.org/
https://github.com/Microsoft/TypeScript/wiki/JavaScript-Lang...
> Visual Studio 2017 provides a powerful JavaScript editing experience right out of the box. Powered by a TypeScript based language service, Visual Studio delivers richer IntelliSense, support for modern JavaScript features, and improved productivity features such as Go to Definition, refactoring, and more.
It works off Typescript type annotations for packages and the Typescript compiler's type inference. VS Code's Javascript editing does not seem to be evidence for tooling around dynamic languages so much as it's evidence that if you have a lot of money and Anders Hejlsberg you can write a compiler for a statically typed language with type inference that looks like a specific dynamic language.
There are limits to type inference. And if you're going to rely on type inference to prevent runtime bugs you might as well double-down on static typing since you're giving up on some of the 'features' (insanity) of dynamic languages anyway.
Dart 2.0 now mandates strict typing but will allow you syntactic shortcuts as long as the compiler can infer the type (if it can't, you get a compile-time error) - that's a great compromise. I wish more people would love Dart. It's such a great, well-designed, language.
>Searching for strings isn't that much worse.
There are very real limits with what you can do with 'strings'. And yes, it is that much worse.
>When I was working in c# on the server and javascript on the client, I really hated having to go back into c#.
I do not understand that view. You are an alien to me. C# is a beautiful language that fixes a lot of syntactic problems in Java. It is much more pleasurable to write C# code than JS code (outside of dinky 50 line programs).
>I think static typing is necessary when you need performance because all of the fast languages are statically typed.
That's not the only reason but it is one of them. JIT and AOT compilers can do more with strongly typed code.
>There are a ridiculous amount of tech companies that have used dynamic languages to go from nothing to the biggest companies in the world and only switched to static languages well and truly after that occurred.
Sure. PHP (pre-5) and JavaScript made a ton of money for a ton of people. Both languages were integral in the Web revolution. Doesn't change the fact that PHP was a terrible language and JavaScript is still a terrible language.
The unknowable question is, would they have hit that sweet spot anyways by engineering their product more rigorously, and had less pain later? Or would it have impeded them in the exploratory phase of writing and rewriting their code until they hit that spot?
It is actually using TypeScript's engine for this. It uses TypeScript's type definitions where it is available (e.g. most popular libraries and built-ins), and some inference rules where it has to work with plain JavaScript.
While this does give you decent auto-complete in a lot of cases (and still getting better), it's not quite as good as using TypeScript directly.
> Searching for strings isn't that much worse.
I'm busy with a large refactoring project, and TypeScript has been amazing for this. After restructuring code, you can just keep on fixing things until there's no more red. This is not just about reducing bugs - it removes almost any thinking/mental overhead required for the refactoring process.
> Also, when it comes to web development, you cross into the client-side and suddenly you can't refactor. So you can only refactor the server-side and end up with a mismatch.
TypeScript also works very well for client-side. Of course, if you change the API between the client and server, that's a different story.
This is a biased sample though. You're saying 'ridiculous number', but the truth is most startups (using static or dynamic languages) fail and we don't actually know if their language choice had much impact on their success or failure.
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, EJB2 world sucked) but then it went completely off-the-rails. Typing in Java could be better, sure, but even with its quirks it's way better than the nothing you get with dynamic languages. There are a class of bugs you just never need to worry about when the compiler does some compile-time checks for you ... like worrying that you passed the wrong type into a function, or the wrong number of arguments.
Thank God people are coming to their senses.
This is the #1 reason I leaned away from static typing. Typescript and Swift have changed my mind. I now see typing as a helpful tool that can solve a lot of problems.
People always say this and it baffles me. Bugs like that should be caught immediately by your test cases. You shouldn't rely on the compiler to catch them for you.
None of those things are true.
Yes. We call that 'typing'.
By adding sanity checking asserts in a dynamically typed language you can achieve more or less the same result.
I worked on a small Python project some years ago and we had a type error in production despite having tests.
We traced it back to a call to a third party library. It was supposed to return a list of results, and all of the test cases around it worked and always got a list back. In production however we encountered an error because if there was only one value to return, the library would not return a list of one element, as we expected, but a scalar value. So the rest of the code was expecting a list and when it encountered a scalar it blew up.
You can blame it on us for having insufficient test cases, or not coding defensively enough, or not reading the source code of the library we used, or the author of the library for bad design, but ultimately, this bug would not have been possible in a statically typed language.
So just saying "have test cases" is not good enough. Your test cases can be not exhaustive, but a good static type system and type checker is.
That's the one. That's a damned stupid decision.
That's the whole point: as it's often said "type checking keeps you honest"
I stumbled time and time again upon badly designed libraries... With a static type system, the painfulness will be obvious and felt the first time you'll try to build your code
with dynamic types, the pain might not be felt at all, until a crazy bit of code will be invoked, sometimes at the most unfortunate of times
I see all too often, java bad, just look at how many lines you need to write to get "hello world". Who cares, the IDE generates that for you, but if you don't understand static void main as a beginner... again who cares, just put it in and ignore it until you need to understand it. Also read that dynamic languages are so productive, but they never mention you need to then write tests to detect what the compiler would catch for free. Yes good code needs tests, but the compiler IMO is a damn good built in test suite for catching many classes of errors
What's wrong with relying on the compiler? Bugs like that will be caught immediately by a good static type system, so you don't have to rely on your test cases to catch them for you.
Relying on a test suite to verify basic properties that could be enforced automatically through a type system means you're only checking some cases instead of all cases. It also means you're cluttering your test suite with boilerplate about language mechanics instead of writing high value tests that verify the real operational behaviour of your system.
There are pros and cons to static vs. dynamic typing in general, but in this particular respect, static typing is strictly more powerful, less verbose and more efficient.
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 after I discovered Haskell (and more recently Idris), did I realize that static typing can actually be worthwhile.
In fact, the only cases I've ever swapped even a HashMap has been to trove, which implements data structures for builtin types rather than reference types. In which case using interfaces everywhere doesn't help.
This allows you implement patterns like duck typing which are idiomatic in languages like javascript, but impossible to implement in java.
What crap? Types?
>deal with a lot of dumb restrictions
Like what?
Types, especially those that could easily be inferred and that provide no value to the programmer. Writing types down can be useful - Python programmers do it too. Having to tell the compiler every little thing is crap.
Like what?
Type erasure. Having to treat primitives and arrays differently from other types. No first class functions or classes. I won't go on, the arguments are easy to find.
I am surprised though that you were completely ignorant of the benefits of static typing outside of Java. I would think that simply out of curiosity you would do a language survey just to get an idea of what else is out there.
Persuading you on the general demerits of Java wasn't really my intention; my point was that if you want get more people on the static typing train, Java is a bad ambassador and might work against you.
I am surprised though that you were completely ignorant of the benefits of static typing outside of Java. I would think that simply out of curiosity you would do a language survey just to get an idea of what else is out there.
Well, back then (early 2000s) I was a self-taught teenager with a poorer grasp of English (I'm not a native speaker), so while my curiosity did lead me to discover a few languages (JavaScript, PHP, Python, Lua and C), anything remotely approaching "academic" - Haskell, OCaml, Oberon, etc - was out of bounds for me.
Since C was the only other statically-typed language I knew, and I also knew it was much older and designed for much slower machines, I assume static typing was mostly for efficiency, like manual memory management.
There is a different problem with the more powerful and useful type systems in more modern statically typed languages though: learning curve. Haskell is dysfunctionally hard to learn and other languages do a little bit better but there's still friction in the learning curve that gets in the way of widespread adoption in projects that want to be able to hire rapidly.
There are no senses to come to. Static and dynamic typing each have their own benefits, and there are genuine tradeoffs to choosing one over the other. That we are even having this debate in 2017 shows that the world of typing is not a "solved problem" and there are still good reasons to use one over the other for various reasons.
I struggle to think of any benefits of dynamic typing on a reasonably sized code-base (e.g. 50k+ LOC).
There's always going to be an agility multiplier so long as VC is flowing and getting an mvp and a high head count is worth more than any kind of sustainable product.
I expect any programmer to be able to transfer their skillet to a new programming language - especially when we're talking about mainstream languages with a GC.
>There's always going to be an agility multiplier so long as VC is flowing and getting an mvp and a high head count is worth more than any kind of sustainable product.
What kind of agility multiplier? Maybe it makes a difference during a hackathon where you have 24 hours to put something together or maybe if you're putting together shell scripts ... but taking something to MVP takes weeks or months - mainstream dynamic languages simply don't have any edge in development speed in those instances.
Being able to define and initialize types at runtime offers more flexibility and it's quicker to develop in.
I'm frankly surprised nobody brings it up more often but the prototypical example of "static typing done right" - Haskell - is talked about nearly constantly but when I look for actual software I might use that's written using it.... there's so little it's almost embarrassing. One obscure window manager, one obscure VCS, facebook's spam filter and some tool for converting markup.
Given a sprinkling of asserts, a decent linter and a high level of test coverage I don't see much of a benefit to adding static typing.
Quicker if you're writing shell scripts or a small single-purpose applications. Not quicker if you're adding to a codebase of any significant size.
Yes, IME it's still quicker.
OTOH, if you're using "codebase of significant size" as code for "big ball of mud", static typing certainly helps, but integration tests are the real lifesaver.
No. I mean when the codebase is of a certain size, new features require some thought and planning. Features may span multiple-modules. They may require partial or full rewrites or the refactoring of any number of sub-components to support the new behaviour. This means that you proceed carefully because you may not want to introduce regression bugs. This costs time. At that point, you're not limited by your typing speed as you may be putting in net 10 lines of code a day. There is just no benefit to dynamic typing at that point. Worse for dynamic languages, this is where improved tooling and static type constraints start paying extreme dividends.
Yes. And all equally true for statically typed languages.
Refactoring without tests is easier in a statically typed language, but still stupid. If you assume a decent body of tests, the benefit dissipates quickly.
If you prototype faster, as you usually will in a dynamically typed language, your design mistakes cost less. Since in large software systems I tend to find that the two biggest sources of bugs are a) errors in specification and b) poorly designed APIs, not obscure edge case bugs, quicker prototyping helps in large projects too.
And, if your design is solid, you can still achieve similar benefits as static typing by "locking down" your boundary code with asserts so that future development that interacts with that boundary code will fail quickly if it interacted with in the wrong way.
>At that point, you're not limited by your typing speed as you may be putting in net 10 lines of code a day. There is just no benefit to dynamic typing at that point.
This is fallacious. You're never limited by your typing speed in any language at any point. The cost of "extra typing" is cognitive, not a finger speed limitation.
The benefit of dynamic typing is more flexibility in the code you write (especially useful for writing frameworks and such) and quicker turnaround when prototyping because you do not have to prespecify as much up front.
>Refactoring without tests is easier in a statically typed language, but still stupid. If you assume a decent body of tests, the benefit dissipates quickly.
We're not arguing whether dynamic language+extensive integration/unit test is better than static typing and no tests.
>And, if your design is solid ...
Yes, if you have a very solid architecture, strict coding guidelines, extensive integration and unit test coverage, experienced developers (etc. etc. etc.) you will mitigate a lot of problems with dynamic typing. So if you do everything right, avoid the pitfalls, you can have something solid. A similar argument is made to me when I assert JavaScript is a terrible language. I don't disagree with either but it doesn't prove anything.
>The cost of "extra typing" is cognitive, not a finger speed limitation.
Exactly.
I am, because that's the way I'd work in any language, because I'm not a hack.
>Yes, if you have a very solid architecture, strict coding guidelines, extensive integration and unit test coverage, experienced developers (etc. etc. etc.) you will mitigate a lot of problems with dynamic typing.
Eliminate.
>A similar argument is made to me when I assert JavaScript is a terrible language.
No, javascript is different. The weird and fucked up implicit type conversions render even a high level of testing insufficient to achieve a high level of confidence in the code. There's way too many edge case behaviors where it should be throwing exceptions and it does something weird instead. C suffers from this problem too despite being statically typed.
And yet, it's done all the time with great results.
In my experience, the cost of static typing feels roughly constant per line of code, while the benefits of static typing feel roughly O(N log N) in lines of code or O(N) in number of cross-type interactions. These are just wild guesses based on gut feelings, but they feel about right. The constant factors are affected by individual coder preference, experience, and ability, but also specifics of thy type systems involved and the strength of type inference in the tools being used.
In any case, I think often times dynamic typing proponents and static typing proponents have vastly different notions of what a large code base is, or at least the size code bases they typically use.
One problem is that many code bases start out where the advantages of static typing aren't readily apparent, but re-factoring into a statically typed language is often not realistic, even/especially when a project starts groaning under its own weight.
I'd love to see more mainstream use of gradual typing/optional typing/hybrid typing languages, especially something like a statically typed compiled subset of a dynamically typed interpreted language, where people could re-factor portions of their quick-and-dirty prototypes into nice statically typed libraries.
As you might've noticed, I have been intentionally light on the details and only talked pretty abstractly about the specific scales and factors involved.
I always thought dynamic typing is a feature for situations where the code needs an extreme amount of flexibility to adapt to a wide variety of data; even at the expense of performance.
Perhaps I should have written "... nontrivially statically typed."
And there are all sorts of optimizations like this that simply aren't available to dynamically typed languages. Tracing JIT can only take you so far.
(There are also all sorts of optimizations that can't be done statically, so I guess there's that.)
I still don't think so. For example, plenty of silicon is spent on branch predictors simply because addresses and integers aren't distinguished, in general, thus permitting more expressive but costlier code.
Execution would be much faster if integers and addresses were forced to be distinct. Static typing pretty much always improves performance.
I didn't say so. An essential feature of type systems is being able to determine the types of (many) values, statically or dynamically.
> You can not deference a floating point register as an address, for instance.
So you'd agree that architectures that don't make a distinction between integer and floating point registers are untyped? But sure, call this a type system if you must. It's just a very very weak one, so weak as to be almost entirely useless. (And the reason floating point registers are often separate from integer registers is not to provide this kind of "type safety", it's due to history and architecture.)
Weak and strong aren't meaningful terms. A machine ISA might have an inexpressive type system and/or an unsound type system (because it conflates addresses and integers).
> And the reason floating point registers are often separate from integer registers is not to provide this kind of "type safety", it's due to history and architecture.
No, the reason is performance. And we get performance by making statically known distinctions between datatypes, which is what the original poster asked about.
Intermingling the integer and floating point circuitry so they access the same register file would never improve performance over keeping them separate. You'd need longer wires to place them both near the same register files to minimize signal latency, an the added signal delay alone ensures lower performance.
> No, it's for architectural reasons.
You win, I guess?
Not necessarily. The phrase "dynamic language" actually bundles together a lot of related but distinct ideas: some of those add performance overhead, others don't. "Dynamic" features which are most notable for performance overhead are tagged unions and dynamic dispatch.
Imagine a dynamically typed language which provides types like int, bool, list, functions, etc. and we're free to assign (and reassign) any of those values to any variable we like:
It's very common to store such values as a tagged union: a "union" meaning that the data could represent an int, or a bool, or whatever, and "tagged" meaning that there's some extra data which tells us which one it is. For example, we might store `5` as a pair of machine words: `1` to indicate that it's an int, and `5` to represent the data. The boolean `true` might be the pair `2` to indicate bool and `1` for the data. And so on.This tagging adds overhead. We can reduce it in some cases, e.g. using "tagged pointers" where we use some of the bits in a word for the tag and some for the data. But it's still overhead.
However, there's nothing fundamental about using tagged unions. We could just as easily use 'unboxed' values, i.e. store the int `5` as the machine word `5`; the bool `true` as the machine word `1`; etc. There is no overhead, no metadata, etc. Whilst this is a perfectly reasonable implementation strategy, it means that we cannot tell what type a value is intended to have: e.g. if a value is stored as the machine word `1`, we have no way of knowing if that's the boolean `true`, or the integer `1`, or the character `SOH`, or whatever. This would probably lead to very buggy programs, since we have no type checker to enforce correct usage, and (since there's literally no difference between data of different types) we can't even do runtime assertions like `assert(isInt(x))`.
Likewise, many dynamic languages use dynamic dispatch to choose which functions to call based on the type of data we have. In the above example, we might have `x + y` running an integer addition function when `x` and `y` are integers, or a string concatenation function when `x` and `y` are strings, and so on. That's what Python and Javascript both do. Yet, again, there is no fundamental reason to do this! We can have a dynamic language which uses static dispath everywhere: consider that in PHP, `+` is only used for numerical addition, whilst `.` is only used for string concatenation. Dynamic dispatch adds overhead, since we need to chase pointers, etc. whilst static dispatch doesn't. This is simply a question of programmer convenience: do we want every function to have a distinct name, and write them out in full each time?
Note that both of these features: tagged unions and dynamic dispatch, can be used in static languages too. It's just that, historically, they tend to be default (and hence unavoidable) in dynamic languages, and something we must explicitly create in static languages. Hence when we compare static languages to dynamic ones, we tend to compare statements like `x + y` in Python to `x + y` in C, which are actually quite different semantically. A fairer comparison would be to compare `x + y` in Python with `callWith(lookUpSymbolFromType("+", lookUpType(x)), x, y)` in C (I've made up those function names, but the point is that the same functionality is there if we want it, but it will be just as slow as if we'd used Python)
Large Python code bases are really hard to understand and work in (here).
I use Cursive https://cursive-ide.com/ for working with Clojure, and it can do safe refactoring for symbols by doing static analysis of the source. It can show all usages of a symbol, rename it, do automatic imports, and so on.
Another piece of tooling that's not available in any statically typed languages at the moment is REPL integration with the editor seen here http://vvvvalvalval.github.io/posts/what-makes-a-good-repl.h...
I find that the REPL driven workflow found in Lisps is simply unmatched. When you have tight integration between the editor and the application runtime, you can run any code you write within the context of the application immediately. This means that you never have to keep a lot of context in your head when you're working with the application. You always know what the code is doing because you can always run and inspect it.
Having the runtime available during development gives you feedback much faster than the compile/run cycle. I write a function, and I can run it immediately within the context of my application. I can see exactly what it's doing and why.
The main cost of static typing is that it restricts the ways you can express yourself. You're limited to the set of statements that can be verified by the type checker. This is necessarily a subset of all valid statements you could make in a dynamic language.
Finally, dynamic languages use different approaches to provide specification that have different trade offs from static typing. For example, Clojure has Spec that's used to provide runtime contracts. Just like static typing, Spec provides a specification for what the function should be doing, and it can be used to help guide the solution as seen here https://www.anthony-galea.com/blog/post/hello-parking-garage...
Spec also allows trivially specifying properties that are either difficult or impossible to encode using most type systems. Consider the sort function as an example. The constraints I care about are the following: I want to know that the elements are in their sorted order, and that the same elements that were passed in as arguments are returned as the result.
Typing it to demonstrate semantic correctness is impossible using most type systems. However, I can trivially do a runtime verification for it using Spec:
The above code ensures that the function is doing exactly what was intended and provides me with a useful specification. Just like types I can use Spec to derive the solution, but unlike types I don't have to fight with it when I'm still not sure what the shape of the solution is going to be.I can encode all those invariants as QuickCheck properties and have them automatically tested against random inputs on every test run. It's still all runtime verification, but with random inputs I actually have more confidence of hitting a corner case than with just asserting during regular program runs or hand written example tests.
Also, with enough heavy lifting you can actually encode all of that in the types in a dependantly typed language like Idris [1]. And while a machine checked proof of your sorting algorithm is nice, it might be hitting the diminishing returns point the article mentions over just using property tests.
[1] https://github.com/davidfstr/idris-insertion-sort
This makes it much more likely to be used but it's fundamentally the same set of ideas.
A really cool idea I'm playing with at the moment is using fuzzing/static analysis based generators to feed spec/test.check.
I think it will help get past the, imo, biggest issue with generators in that they can miss exceptional cases in the code.
E.g. If (x=="jack and Jill) {exceptional case} is unlikely to be triggered with standard generators but "easy" for static analysis tools to solve.
> Also, with enough heavy lifting you can actually encode all of that in the types in a dependantly typed language like Idris [1]
In theory. In practice it is multiple orders of magnitude harder to prove properties in Idris than it is to spec them using property based testing.
Somebody has to be able to read that specification and understand that it's correct in a semantic sense. Ultimately, the specification itself becomes a full blown program that the type checker executes. So, now you run a program to try and verify aspects of your original program, but how do you verify that the specification itself is correct?
At some point a human has to be able to read the code and decide that it matches the intent. This step can't be automated, and I certainly don't think the Idris example improves things. I'd argue that it's far easier to tell that this version is correct:
Or, type can be specified when setting the variable:
[String]$myString = "Hello World!"
This would generate a type error:
[Int]$myString = "Hello World!"
Often, typed and untyped variables will sit together:
[Int]$EmployeeID,[String]$FullName,$Address = $Input -split ","
Also the fact that you can use types when declaring function arguments, removing the need to manually test if an object of the desired type was passed.
Powershell definitely strikes a good balance on type safety for a scripting language.
If no, then what is the use of the typesystem?
If yes, isn't that cumbersome, since I suppose most library functions have typed arguments?
Especially when it comes to GUI programming, I really don't care if a BlueButton.Click() got called instead of RedButton.Click().
The counterarguemnt - "it's slow to write" - hasn't been true for years with modern type inference and other features.
So year, static typing doesn't buy you much, but in some languages it's at least cheap.
I think this is key. The benefit of static typing isn't that they provide safety, it's that they provide _low-cost_ safety. For a large class of problems, types are cheaper than tests are. For other classes, tests are cheaper than types. The main downside of nonstatic languages is that you have to use tests for everything, even that class where types are a better choice.
What is interesting is using the type system to specify invariants about data structures and functions at the type level before they are implemented. This has two effects:
The developer is encouraged to think of the invariants before trying to prove that their implementation satisfies them. This approach to software development asks the programmer to consider side-effects, error cases, and data transformations before committing to writing an implementation. Writing the implementation proves the invariant if the program type checks.
(Of course Haskell's type system in its lowest-common denominator form is simply typed but with extensions it can be made to be dependently typed).
The second interesting property is that, given a sufficiently expressive type system (which means Haskell with a plethora of extensions... or just Idris/Lean/Agda), it is possible to encode invariants about complex data structures at the type level. I'm not talking about enforcing homogenous lists of record types. I'm talking about ensuring that Red-Black Trees are properly balanced. This gets much more interesting when embedding DSLs into such a programming language that compile down to more "unsafe" languages.
I have a large code base. I want to replace a fundamental data structure to support more operations/invariants/performance guarantees. I change the type at the roots of the code base. My instance of ghcid notifies me of the first type error. I fix it. This repeats until the program compiles again. I run the tests. All the tests pass.
This is insane in Python/C/Ruby. I've had to do it in C and Python. In Haskell I do it with impunity.
The type system doesn't just check what my program does, it is the compass, map, and hiking gear that gets me through the wilderness.
Dynamic languages can always lean on runtime features, but that's also their peril. Late binding deprives you of leveraging the tools in favor of "trust me".
In both cases you can get a maintenance nightmare, of course. The point as I see it is to move things toward the runtime when the error case is not troublesome, and towards the compiler when automating in more safeguards would help.
There's a good reason people generate code instead (in statically and dynamically typed languages!): performance.
But I've never had the luxury of choosing a tech stack for it's purity of design. So the feature is wonderful in my day to day regardless.
I'd love to build 3D experiences in a language like lisp or scheme. It'd be great fun to learn but I don't currently have the luxury of the time it would take to ramp.
And I certainly don't have the political capital to convince my entire dev team to change.
C's built-in arrays are super weak, so you need some library to do proper resizable arrays. Since C doesn't have generics, such a library will use void * as the type for putting values into the array and getting them back out again. You'll be casting at every point of use, and nothing will check to make sure you got the cast right, other than running the code and crashing.
There are other options though like macros and code generation. Code gen in particular can give you more options than generics without sacrificing any type safety.
http://attractivechaos.github.io/klib/#Khash%3A%20generic%20...
This approach isn't just more strongly typed than using void * for everything, it's also typically more efficient. For an array, you can put larger structs directly in the array rather than being forced to use a pointer. For a hash table, the same applies, plus you can avoid expensive indirect calls to compute hashes. (There are alternative non-macro approaches that trade off that overhead for other types of overhead, but you can't do as well as with a specialized container.)
I guess you could ask, at that point why not just use C++? And a lot of people do, and the people left writing new C programs are often traditionalists who don't want to switch to new approaches. And to be fair, there are disadvantages to macro-based containers, like increasing build time. But I still think there's room for them to see more adoption.
Except when it's not. Just five days ago I was debugging an error in my Erlang port driver that was caused by me passing receiver (ErlDrvTerm, an int in disguise) in the place where I wanted number of iterations. The funnier thing was that the declaration of the function had the arguments in correct order (and that's what guided me), but definition had them swapped. The compiler did not catch that bug, because, well, both are ints, so apparently the declaration and definition match, don't they?
Static typing versus dynamic typing is fairly binary: if your types are checked at compile time they're probably static, while if they're checked at run time they are probably dynamic. Haskell, C are statically typed, Python, JavaScript are dynamically typed.
Strong/weak typing is more of a spectrum. A strong type system can check many properties of programs and accommodate many patterns as types. A weak type system, on the other hand, can't check many properties of programs, and has to be bypassed to accommodate common patterns. JavaScript has probably the weakest type system, because it checks almost nothing ("hi" + 42 returns "hi42" even though this is nonsensical, {}.foo returns undefined rather than throwing a type error). C is fairly weakly typed because you can add disparate types (int* + int returns int* even if you intended to add two integers) and the type system has to be bypassed with void* to do anything sizeable. Python, ironically, is slightly stronger, in that applying operators to objects of types with no defined relationship throws exceptions ("hi" + 42 errors). A spectrum from weakest to strongest might look something like: JavaScript, C, Go, Ruby, Python, Java, C#, OCaml, Haskell.
My personal experience is that the difference between static and dynamic types isn't very important to my development process or code quality. I have to run and unit test my code to verify it, so the checks happen regardless of whether they happen at compile time or run time. But the difference between strong and weak typing is huge. Strong types catch more bugs, but perhaps more importantly, they catch those bugs where they occur. A type error when adding "hi" + 42 is far more useful for debugging than a mysterious unit test failure on a completely different function where it's returning "Hi42username" instead of "Hi Username" because you added the wrong variable. A segfault 30 lines later is harder to debug than an error when trying to add an int to the value at an int*.
Personally, I find it pretty workable in Python with a big codebase (but you have to respect the rules like having a good test suite -- you change the time from compiling to running your test suite -- which you should have anyways)...
I find that the current Python codebase I'm working on (which has 15 years and around 15k modules -- started back in Python 2.4, currently in Python 2.7 and going to 3.5) pretty good to work in -- there's a whole class of refactoring that you do on typed languages to satisfy the compiler that you don't even need to care about in the Python world (I also work on a reasonably big Java source codebase and refactorings are needed much more because of that).
I must say I'm usually happier on the Python realm, although, we do use some patterns for types such as the adapter protocol quite a bit (so, you ask for a type and expect to get it regardless of needing a compiler to tell you it's correct and I remember very few cases of errors related to having a wrong type -- I definitely had much more null pointer exceptions on java than typing errors on Python) and we do have some utilities to specify an interface and check that another class implements all the needed methods (so, you can do light type checking on Python without a full static checking language and I don't really miss a compiler for doing that type checking...).
I do think about things such immutability, etc, but feel like the 'we're all responsible grown ups' stance of Python easier to work with... i.e.: if I prefix something with '_' you should not access it, the compiler doesn't have to scream that it's private and I don't need to clutter my code -- you do need good/responsible developers though (I see that as an advantage).
Null pointers are a type error. The fact that several nominally "statically" typed languages don't differentiate between nullable and non-nullable types is a significant source of failure in their type systems. Using a modern language that properly identifies nullable values as a distinct type from non-nullable ones goes a long way towards eliminating a whole host of problems. It will be interesting to see what things look like in 10 years or so once Rust has had time to really displace a significant portion of the C and C++ code in the wild, and hopefully Kotlin has killed off Java (and if we're really lucky Typescript has done the same more or less with Javascript).
I can say from my experience it is definitely possible to maintain large codebases in Python. The type errors of the superficial variety that the OP refers to were usually caught before they made it to production (and were rare besides if you were experienced enough to avoid them). It requires discipline to maintain tests and write code in a way that avoids errors.
I've been learning OCaml and Haskell for a couple of years along with formal methods using TLA+ and Lean. I used to think type theory was the accounting of maths. I still think that's at least partly true but the power it brings you as a programmer is quite powerful.
I find working with Haskell or OCaml to be much more productive. Instead of stepping through a debugger or following tracebacks (a descriptive error) I get prescriptive errors as I make changes to a Haskell codebase. The propositions in the type system form a much better specification than unit tests alone.
I still like Python and C for many reasons and will continue using them where appropriate. However I think Haskell/OCaml offer quite enough power that everyone should at least consider what they bring to the table.
It's true that static type-checking proves the absence of an entire class of errors. But it doesn't prove that the code does the correct thing; it could be well-typed but completely wrong. On the other hand, tests prove that the code does the correct thing in certain cases. ...Of course, it's up to the developers to actually write a good test suite.
The faster we can all accept that there are pros and cons to both, the faster we can come up with a solution that takes advantage of the best of both worlds. That's the whole point of this OP.
I, personally, have always wondered about ways to dial in to the sweet-spot over time as a project matures. At the start of a project, shipping new features faster is often more important. But if the project survives, maintenance (by new developers) and backward compatibility become more and more of a priority.
So prove it yourself. Proving things about programs that rely on dynamism is invariably much harder than proving things about programs that don't.
It's only insane if you don't have test cases with good coverage, in which case you are very-very-very screwed, statically typed or not.
I really wish more languages took this to the logical conclusion and implemented first-class contract support. It seems work on contracts stopped with Eiffel (although I've heard that clojure spec is _kinda_ getting there).
No, they are not.
1. If the code doesn't conform to the contract, it will fail on the contract boundary, with a well-defined error. If this is useless, then `assert` is also useless, which it is, of course, not.
2. With a sufficiently well-designed language and sufficiently smart compiler, you can move some contract checks to compile-time. See Racket.
3. If your language supports both static and dynamic typing, the contracts are a dual of static types, which lets you interface the static and dynamic parts of the code seamlessly and automatically (in both directions). Again, see Racket.
Meta: I wonder, why it's mostly static-typing proponents who aggressively evangelize, insult the other side, are 110% sure they're right even though there is no scientific evidence and so on. Could it be the bondage&discipline approach of static typing just appeals to people with a certain mindset, who are statistically more probable to engage in such behaviors, no matter the subject?
1. With pencil and paper, you don't need to wait for a smart compiler - you can get started proving things about your programs today!
2. I can totally see what's coming next: “Being wrong is dual to being right, so being wrong is another possibility worth exploring”. Right?
> Meta: (slander)
No comment.
But why? You were able to "comment" on the work of Felleisen and colleagues on contracts, declaring their effort of many years useless, yet you can't answer why did you do it?
Your utter lack of respect for people who happen to hold an opinion different than yours is typical, in my experience, for static-typing fans; as is your apparent - and wrong - belief that static typing was proven to be "better" (for some value(s) of "better") than dynamic typing.
There are certain groups of people where the above traits are overrepresented. I think there is a high probability that preference for static-typing correlates positively with belonging to these groups - and I wrote that much. Is that really a "slander"?
Sorry for focusing on that part, but your 0-2 points are too wrong to correct in a few paragraphs, and I don't have the time for writing more than this.
"I don't see the benefit of typed languages if I keep writing code as if it was PHP/JavaScript/Go" ... OF COURSE YOU DON'T!
This is missing most of the benefits, because the main benefits of a better type system isn't realized by writing the same code, the benefits are realized by writing code that leverages the new possibilities.
Another benefit of static typing is that it applies to other peoples' code and libraries, not only your own.
Being able to look at the signatures and bring certain about what some function _can't_ do is a benefit that untyped languages lack.
I think the failure of "optional" typing in Clojure is a very educational example in this regard.
The failure of newer languages to retrofit nullabillity information onto Java is another one.
I am sorry, but I don't really see how you stating more benefits of static typing really counters either of them.
I recommend reading the article again. But this time, try not to read it as defending a specific language (I only mentioned my blub language so that it's a more specific and extensive reference in the cases where I use it - if you are not using my blub language, you should really just ignore everything I write about it specifically) and more as trying to talk on a meta-level about how we discuss these things. Because your comment is an excellent example of how not to do it and the kind of argument that prompted me to this writeup in the first place.
The point is to explore a comparative difference in value, and that is realized through mastery of the tool, not merely living in a world where it exists.
You'd have thunk I didn't have to make them than. But I did, judging from literally every argument I had about this.
The inverse is also true; you don't really get the benefits of dynamic typing until you start doing things differently to take advantage of that difference. If you still code like you're in a static language, you'll miss the benefits of a dynamic one.
The author makes it clear that the analysis is not perfectly rigorous. There is a very wide landscape between perfectly rigorous and completely useless.
Do you think the article fails to hint at any of the fundamental dynamics of how type systems affect software development? How so?
For one example, I don't think it's a given that the green line (velocity vs % type-checked) should have a negative slope. Maybe in some cases, for some projects or some people, but certainly not universally. At least part of it would have been positive on almost all projects that I've worked on, and I'm not doing rocket science.
Then, the combined chart just looks at the amount of bug-free output, completely ignoring the amount of bug-ridden output. That latter part doesn't just get discarded, it needs fixing, and bugs that were only discovered in production are expensive to discover, debug and fix.
This is in addition to pretty much every other top level comment in this thread, a lot of which bring up important points that are unaccounted for even conceptually in the charts.
Neither Python nor Java programmers have to do that.
If Go is annoying with how little power it provides, that's fair, but other type systems can be just as annoying then, because when given the ability to, type astronauts will blast off into space, purely as a matter of honor or instinct.
Besides, code generation isn't all that bad. Java programmers will eventually find some kind of code generation in their build setup (serialization/schema tools).
It is the number one thing that makes C++ templates unusable: semantics defined by means of code generation.
We've been here before with the C preprocessor. There's nothing wrong with having a preprocessor, but in C it is necessary to use the preprocessor and that causes a lot of problems, like making it especially difficult to write tools.
In a hypothetical world where the designers never added the specific containers they did, you'd get a whole lot more value out of generics for containers. But it turns out, the designers used what seems on the surface like a kludge to get most of the benefits, while saving most of the cost. It's a perfect embodiment of the kinds of tradeoffs I'm talking about.
Architecture astronauting can be prevented with best practices and code review, not with language limitations. It’s a fools errand to try, code generation allows you to get all the complexity and more of generics.
Which is not the argument made by anyone. Indeed, I explicitly acknowledge that there is a certain fraction of use-cases not covered by the builtins. So there isn't really any disagreement about this.
The question is how large this fraction is, how much it would benefit and how inconvenient/costly the existing workarounds are. Like all engineering questions, these are impossible to talk about when dealing in absolutes. And once you actually talk about these questions quantitatively, I achieved the goal I had with the post - to change the debate into a quantitative one explicitly acknowledging the tradeoffs involved.
> Architecture astronauting can be prevented with best practices and code review, not with language limitations.
I work at a company which has probably one of the highest standards in regards to code review in the industry. As such, I disagree with you that it is effective in addressing this.
> It’s a fools errand to try, code generation allows you to get all the complexity and more of generics.
If that's the case, where do the complaints come from about the lack of generics? It seems that Go really has generics then, in your opinion?
Of course, that's a strawman and a misrepresentation of your argument. But what makes this a strawman, the difference between the existing workarounds and actual generics, is just as effective an argument for your side as it is one for my side. Because codegen is made so inconvenient, people bias heavily towards using the builtins, away from custom data structures, if they can at all get away with it. Thus greatly reducing the overall complexity of the codebase.
So it would seem to me, that this argument is logically flawed. Either codegen is a poor replacement, thus leading to people using less generic code, thus there is an effective reduction in complexity. Or codegen has the same effect on complexity, which would mean it is used just as much, meaning it can't be that bad a workaround.
I don’t agree that using piles of built in objects makes the code easier to understand. If I want a Tree<Node, Node, Value>, how is using lists of lists and integer pairs making my code easier to reason about? Or using code generation to make reams of classes that create a Tree for everything I want, and anyone who uses my functions? How is encouraging either of those things a positive?
A type system doesn't only describe the behavior of the program you write. It also informs you of how to write a program that does what you want. That's why functional programming pairs so well with static typing, and in my opinion why typed functional languages are gaining more traction than lisp.
How many ways are there to do something in lisp? Pose a feature request to 10 lispers and they'll come back with 11 macros. God knows how those macros compose together. On the other hand, once you have a good abstraction in ML or Haskell it's probably adhering to some simple, composable idea which can be reused again and again. In lisp, it's not so easy.
A static type system that's typing an inexpressive programming construct is kind of a pain because it just gets in the way of whatever simple thing you're trying to do. A powerful programming construct without a type system is difficult to compose because the user will have to understand its dynamics with no help from the compiler and no logical framework in which to reason about the construct.
So, a static type system should be molded to fit the power of what it's typing.
The fact that every Go programmer I talk to has something to say about their company's boilerplate factory for getting around the lack of generics tells me something. This is only a matter of taste to a point. In mathematics there are a vast possibility of abstract concepts that could be studied, but very few are. It's because there's some difficult to grasp idea of what is good, natural mathematics. The same is in programming: there are a panoply of programming constructs that could be devised, but only some of them are worth investigating. Furthermore, for every programming construct you can think of there's only going to be a relatively small set of natural type systems for it in the whole space of possible type systems.
Generics are a natural type system for interfaces. The idea that interfaces can be abstracted over certain constituents is powerful even if your compiler doesn't support it. If it doesn't, it just means that you have to write your own automated tools for working with generics. It's not pretty.
There are languages that enforce termination. They only accept programs that can be shown to terminate through syntactic reasoning (e.g., when processing lists, you only recurse on the tail), or where you can prove termination by other means.
Coq is like this, as is Isabelle, as is F* , as are others. They also provide different kinds of escape hatches if you really want non-terminating things, like processing infinite streams.
This "we can never be sure of anything, because the halting problem" meme is getting boring. Yes, you cannot write the Collatz function in Coq. No, that is not a limitation in the real world.
How about, say, a video game? That's something where we reasonably _want_ it to not terminate, because we're primarily interested in its side effects.
Alternatively, you just write a function to iterate your game world update N times, where you choose N large enough to ensure that your game can run until the heat death of the universe. That's not a nonterminating function, but it's long-running enough for all practical purposes.
There are two ways to see type systems. In the first way you construct terms along with their types, this is called Church style. In the second way, the terms exist before their types and you use types to describe their behavior, this is called Curry style. In particular take System F. In Church style the terms of System F come with their types. In Curry style we see System F types as a way to describe the behavior of untyped lambda terms.
I used to think Church style was more important but lately I've been more partial to Curry style. Programs exist before you type them, type systems tell you how they behave. They also tell you how to construct programs but this is subordinate to the more fundamental descriptive capacity.
I agree with this. But I think that usually we are not really talking about all programs. We are talking about useful programs, and those are usually terminating. In theory, not always, see first-order theorem provers; but in practice, we always call a prover with a time limit because nontermination isn't useful.
> Programs exist before you type them, type systems tell you how they behave. They also tell you how to construct programs but this is subordinate to the more fundamental descriptive capacity.
That's an interesting point, and I agree in many respects. I think when programming in a dynamically typed language, I approach things in one style, and in statically typed languages in another style. But specifically for termination, I don't think so. I never want to write a nonterminating program; the termination property for my programs exists (as a requirement) before the program does.
What a ridiculous stereotype. Clojure community typically maintains the belief that macros are the last resort for things that genuinely justify them. You really shouldn't spread hyperbole like this.
The catch there, as is often the case, is hidden in the word "good". Working with text data in Haskell is almost as painful as working with text data in C++, and for much the same reason: the original abstraction is far from ideal for most practical purposes, but became the least common denominator. Everyone and his brother has written a better string abstraction or more powerful regex library or whatever since then, but they're all different.
Consequently, even with the power of generics or typeclasses, you still often see developers just converting to and from the primitive default representation for interoperability. Static typing will at least stop you from screwing that up, which certainly is an advantage over dynamically-typed languages in some situations. However, it apparently hasn't made it any easier for the developer community as a whole to migrate to a better abstraction as the default.
In short, we often don't know what will turn out to be a good abstraction until we've gained a lot of experience, and in the face of changing requirements on most projects, we probably never can know from the start because what works as a useful abstraction might change over time. So while types are useful for checking whatever abstractions we have at any given time, until we've also got techniques for migrating from one to another much more smoothly and on much larger scales than anything I've yet encountered, I think we shouldn't oversell the benefits, particularly in terms of composability.
Many. That's the whole point -- to let you choose "the way to do something" that applies the best to your circumstances (development time, performance, allowable complexity, etc.)
So you are limited by your own mind and skills -- not by the language.
Disclaimer: Python user scarred by email header RFC violations
https://github.com/fthomas/refined
not only for the static checking,
but the expressive descriptions of a domain model.That's not really true, just a belief. I give you an example to start understanding these things: the exact same program written in a very high level and very expressive language, like Perl, instead of Go, is going to have at least 3 times less code and since defect rates per line of code are comparable, you would end up with at least 3 times less bugs. Suddenly reliability argument of static typing doesn't make any sense. That's because in PL research there is a huge gap in understanding of how programmers actually think.
I was in favour of dynamic typed, but lean more and more towards static typing, like ocaml.
And I'm not sure you should expect the number of bugs per line to remain constant across languages. Extra lines required because you have to do your indexing by hand as you're iterating over a list certain increases the chances of an error but the extra '}' required to end the block in some languages increases line count with very little chance of causing an error.
Given a million line codebase written in Perl vs a three million line codebase written in Go, which do you think most engineers would prefer?
That's not really true, just a belief. A naive belief, if you ask me.
This is a basic intuition behind all good practices, including CI, QA, etc.
Types allow one to discover program defects (even generalized ones, when using some of the programming languages) in (almost) shortest possible amount of time.
Types also allows one to constrain effects of various kind (again, use good language for this), which constraintment can make code simpler, safer and, in the end, more performant.
Have you familiarized yourself with Haskell?
I have come to see type systems, like many pieces of computer science, can either be viewed as a math/research problem (in which generally more types = better) or as an engineering challenge, in which you're more concerned with understanding and balancing tradeoffs (bugs / velocity / ease of use / etc., as described in the post). These two mindsets are at odds and generally talk past each other because they don't fundamentally agree on which values are more important (like the great startups vs NASA example at the end).
The main use case of generics, making collections and datastructures convenient and readable, is more than enough to justify the feature in my view, since virtually all code deals with various kinds of "collections" almost all of the time. It's a very good place to spend a language's "complexity budget".
I wrote an appreciable amount of Go recently, with advice and reviews from several experienced Go users, and the experience pretty much cemented this view for me. An awful lot of energy was wasted memorizing various tricks and conventions to make do with loops, slices and maps where in other languages you'd just call a generic method. Simple concurrency patterns like a worker pool or a parallel map required many lines of error-prone channel boilerplate.
I feel the same way going from languages with HKTs back to Java/C#...
Not sure why you think they're not as useful, it sounds like you're making the same argument as OP but just moving the bar one notch over...
Subjectively, I use ordinary generics all the time, but see the need for HKTs only occasionally. It's entirely possible I'm not experienced enough to see most of their possible use cases, but then I'd wager most programmers aren't.
A large portion of advanced Haskell type system features seem to be about emulating things you could do with side-effects. I guess I prefer Rust's approach to managing side-effects, or even just Scala's implied convention of: use 'var' very sparingly, and mostly locally. Yes, some guarantees get traded away, but so much simplicity is gained.
I'm not very experienced with Haskell, but I've written a fair bit of Scala and I've utterly failed to see the value in scalaz and similar libraries, despite trying them a few times. They always seem to add lots of complexity without a tangible benefit.
Coming at it from another angle, I just don't see many cases where I feel I have to repeat myself due to a shortcoming of, say, Java's or C#'s type system. If I could add one feature to either, it'd actually be support for variadic type parameters.
Both Java and C# tend to rely heavily on frameworks such as Spring to workaround issues with the expressivity of the languages. This causes problems when one needs two frameworks (they don't in general compose). In Haskell, HKTs allow one to write polymorphic programs that are parametric with respect to certain behaviours and dependencies, no dependency injection framework needed.
Please don't judge Haskell using Scala and scalaz.
I just don't understand what is so horrible and inexpressive about a static initialization block.
The only possible purpose I see to Spring is if for some reason you really need to be able to change how your dependencies are injected at runtime. (90% of Spring apologists point to this, and 99% of them never use it in practice.) Even then, I don't see how a Spring XML config file (which I have seen run to 4000+ lines, to my horror) is better than just reading some settings out of a properties file to pick an implementation in your static initializer.
Java's static initialiser blocks are too dangerous whenever one has threads.
But I think I get your general point: things like 'Control.Concurrent.Async' ('async'/'await') and 'Control.Monad.Coroutine' ('yield') are libraries that implement some and very generic type classes: 'Functor', 'Applicative', 'Monad'. This then lets you use features that are generic over those type classes ('do' syntax, 'fmap', ...).
It's been many years since I had a proper look at Haskell. Maybe it just takes more practice than I had back then to fully "get it". But I still don't see those abstractions being that useful in everyday programming. They seem to have huge potential for hard to follow code as you need to mentally unpack and remember more layers of abstraction, and the gain is not clear to me. Even the features that have trickled down to C# are not _that_ crucial I feel. The way mainstream languages pick the most useful use cases of those abstractions seems pretty OK to me.
(Also, macros and compiler plugins are another interesting avenue towards very powerful abstractions, with a different set of problems.)
As for Spring and dependency injection, I don't follow how HKTs would help there. Could you give an example? Aren't DI frameworks mostly about looking things up with reflection magic to automate, and arguably just obfuscate, the task of wiring things up in 'main'?
That's the beauty of abstraction without side effects, you don't need to unpack anything. If you know what the inputs are and the outputs are, you don't need to know how it works or what type classes are even used to transform certain things.
People use sequence
all the time in Scala, not realizing it's only able to be implemented with HKTs of Applicative and Traverse. FYI, sequence flips a list of Futures to a Future of List, or a vector of Trys to a Try of Vector, etc.
I don't buy your point about not needing to unpack side-effectless code, however. There are _always_ reasons to dig into code, be it bugs, surprising edge cases, poor documentation, insufficient performance, or even just curiosity. And those high-level abstractions tend to be visible in module interfaces too. I remember some Haskell libraries being very hard to figure out how to use if you didn't know your category theory :)
It's like spending ten years learning to speak Russian and then criticizing anyone who says that learning Russian is difficult.
Puzzling out scalaz code is difficult and requires an enormous investment in hours and practice, investment that a lot of people prefer to put into different learnings.
It's incredibly multipurpose, more so than even Spring or Guava or LINQ, and these are things that developers regularly have to invest serious time in.
The argument is just that FP libraries (like Scalaz) have a bigger payoff in the investment.
At Verizon Labs were have 20+ microservices that I have touched/looked at. Some use Akka, some use Play, some use Jetty, some use Http4s but everyone makes use of Scalaz somehow.
It depends on the people, not everybody has the inclination to dive so deep into hard core FP and they will be more productive using a different approach.
Don't make the mistake of thinking you've found the only software silver bullet that exists and that people who don't use it "don't get it", which is another attitude I've seen a lot of hardcore FP advocates embrace.
What I meant by "polymorphic programs" as an alternate to DI, is something like this:
doStuff :: HasLogger m => Input -> m Output
The effectful function "doStuff" above is polymorphic with respect to which logging implementation is used, it could even be one that uses IO. All made possible with HKTs.
Your DI example seems to be an example of my earlier point about "emulating things you could do with side-effects". No HKTs are needed when you just pass an impure side-effectful Logger object. Or, as discussed in another subthread, you could do side-effect management with Rust-style uniqueness typing, which results in a less elegant but arguably easier to use type system. It's debatable, but it seems people struggle less with the borrow checker than with advanced Haskell.
I guess the side effecting version is just to use some global registry to look up the logging implemention to use. But such code does not compose.
I agree, the side-effectful choices are either a global, some DI container, or just passing it down.
For loggers, I think global lookup from some (pluggable) logging library is justified because logging is probably the most ubiquitous cross-cutting concern ever. For pretty much everything else, I think passing as a parameter is actually the best option. It's explicit and simple, and you don't even need to explicitly pass it around _that_ much if you store it in a field of a class that plays the role of a module. Most uses of the dependency will be in non-static methods, lambdas, or inner classes.
I dislike Reader because it's similar to a DI container (or a global) in that it's more work to figure out, for a given call site, what the last value written to it was. With parameters, you just climb the call chain.
Yes, in the standard library, an immutable object can hide mutable state in e.g. a 'Mutex', and effects to the external system aren't wired through anything like monads or unique objects.
I see those as compromises Rust makes in the name of pragmatism and being a system'ey language. I don't necessarily like all of them, but I find the general uniqueness typing based approach interesting.
See articles comparing Clean and Haskell for an interesting historical perspective, including how both approaches could be used to model side-effects in a purely functional language. Haskell "won", possibly because it was seen as more generic and composable. I always felt Clean's approach had merit too, so I was really glad to see Rust bring the idea, or a closely related idea, to prominence.
Passing a unique world object around is effectively the same as composing with the IO monad, and borrowing 'f(&mut world)' is basically equivalent to 'let world = f(world)'.
Maybe someone will one day write a standard library in that style.
And I think an important take-away should be, that this perception is entirely subjective and colored by both of our experiences, preferences and the kinds of problems we work on :)
By adding types (and in the extreme, dependent types), you're allowing compiler to prove more things about the code (to check correctness or generate more optimal code). If you actually need to prove more things, then it's better to leave that for a compiler rather than human.
Of course, if you're writing e.g. web scraping script, you don't need these guarantees and then you don't have to care about types. But the better engineering you want, the more static typing will help and there is no diminishing returns.
That both forms of languages are popular shows that there are benefits in overall productivity to each; they are just different benefits.
However, in a statically-typed language, you must satisfy the type checker for everything, which adds development time. In reality, there might be a small percentage of functions in your code base for which errors (either compile-time or run-time) would likely crop up, yet you must pay that cost for 100% of them.
So that's really where the debate comes from.
Dynamically typed languages can get around this problem by generative testing (in Clojure's case) which allow very fine-tuned aspects of your system's requirements to be automatically tested before run-time without writing tests, which offers some of the same confidence as a compiler.
I think the key is not to confuse both approaches and leverage the strengths of each to the max.
While, yes, top-quality dynamic code will have documentation and test cases to make up for this deficiency, it's often still not good enough for me to get my answer without spelunking the source or StackOverflow.
I feel like I learned this the hard way over the years after having to deal with my own code. Without types, I spend nearly twice as long to familiarize myself with whatever atrocity I committed.
Can you give an or some example(s) of this?
say you've got a function that takes a list of numbers, and some bounds, and gives you back a number from the list that is within the bounds (and maybe meets other criteria, whatever). your contract for the function could require not only that the list be comprised of numbers, and the bounds are numeric, but also that the lower bound is <= the upper bound, and that the return value was actually present in the input list.