7 ms·

It continues to be amazing to me that a new generation of developers is discovering that, yes, static checking adds a lot of value (for non-trivial-sized projec

It continues to be amazing to me that a new generation of developers is discovering that, yes, static checking adds a lot of value (for non-trivial-sized projects). Of course, if you were tasked with delivering web apps -- until recently -- you didn't really have any choice. The older I get, the more the whole "everything moves in cycles" thing appears to be true -- almost regardless of what particular subject matter is under consideration.

stephen 10y ago
Agreed; if you're looking for a tldr (edit: for sharing with others, e.g. I know you're convinced), I recently made a few edits to my pontification from awhile ago: http://www.draconianoverlord.com/2010/11/24/why-im-a-static-typing-bigot.html http://www.draconianoverlord.com/2010/11/24/why-im-a-static-... I really like the OP's point about "types make abstractions explicit". That is a great articulation that I'm going to add to my post as well, with attribution.
reboog711 10y ago
Cycles... It doesn't seem too long ago when Java Developers rushed to Ruby because it wasn't statically typed. Now, TypeScript is better than JavaScript because of the opposite reason... I've seen this sort of pendulum swing a few times in my career.
- 67726e 10y ago
  I don't think it's fair to say "Java Developers" rushed to Ruby. Cargo-Culting, fad-chasing developers do. The fact is statically typed code eliminates whole classes of errors. There are some trade-off but I can't begin to consider the trade-off for anything non-trivial I want to survive for more than a year.
- kmiroslav 10y ago
  Pretty sure that pendulum is never swinging back in the dynamically type side. The simple truth is that today, statically typed languages have all the advantages that once used to be the exclusivity of dynamically typed languages, while the reverse is still not true. In 2016, there is really very little reason to pick a dynamically typed language for any serious project. Javascript is going to be around for a while because of inertia, but it's pretty much the last mainstream dynamically typed language we'll see.
  - d0vs 10y ago
    Curious to hear why this is being downvoted.
    - kmiroslav 10y ago
      There are still a lot of Javascript developers around :-)
  - wlesieutre 10y ago
    >Javascript is going to be around for a while because of inertia, but it's pretty much the last mainstream dynamically typed language we'll see. Python's still pretty popular too
  - mcphage 10y ago
    > it's pretty much the last mainstream dynamically typed language we'll see I partially agree. I think as type inferencing gets smarter, we're going to end up with languages that are statically typed by the compiler or interpreter, but that there will be few-to-no type annotations in the code. So yes, I think the future is static typing, but I think it's going to end up a compiler feature and not part of the language at all.
  - seanmcdirmid 10y ago
    Subtyping combined with paramtericity is still a problem with good (I.e. doesn't suck) type inference. Unless you are will to live without either, it isn't true that static thong has all the advantages of dynamic, yet.
  - eyelidlessness 10y ago
    > In 2016, there is really very little reason to pick a dynamically typed language for any serious project. I wish this were true. I wholeheartedly agree that, all other things being equal, static typing is better than dynamic typing. If there were no other factors, I would choose static typing without a second thought. But there are other factors, and all other things are not equal. I write ClojureScript every day. Its lack of static typing is a genuine source of pain. Every day. But when I compare it to Elm, which I'm quite interested in: - JS interop. Maybe I suck at google, but it looks like it's not a first-class concern of the language or the community. - Macros. Defining language features is great. It's the reason that a lisp can be small in terms of core language constructs (even if its standard library is enormous cough Clojure). In 2016, there is really very little reason to design a language without metaprogramming in mind. - Community, which admittedly could and should and will grow in size and sophistication for Elm. When I compare it to TypeScript? - State. Welp. - No seriously, why is everything mutable? It's 2016 and a language that was designed with concurrency and functional programming in mind from the start still hasn't caught on to mutability by default as a serious problem, and TypeScript inherits all this baggage. - There's no simple clear path to even set up a TypeScript project. There's a million different ways with different tooling choices, and that fractured environment is evident whenever searching for answers. The world of JavaScript constantly bleeds through. If I want to know how to use TS, I need to know WebPack and NPM and Bower and who knows how many other things that are not even for TS. - Forget metaprogramming. - What is the TS community? Microsoft and a weird has-been cult team at Google? (Sorry guys, I did the Angular thing, and I watched it become a circus from the time Angular 2 was announced to the time your weird conference was more like a dance club than a tech conference.) I could simplify this by calling out your last line. JavaScript rules the roost. You better play nicely with it, if you want to build a web app. Honestly the web is going to be an increasingly fractured thing for many years. There's just too many ways to do things and they're all compromised in awful ways. Postscript: I'm sorry this is so ranty. I mean no harm and I mean none of my criticisms to be taken as attacks. I want very much to do good work as a web dev and I'm just heartbroken that it's such a pain.
- ken47 10y ago
  They're not exactly comparable. Java's type system gets in your way. Typescript only gets in the way when you ask it to. The dev experience can be quite different.
- GFK_of_xmaspast 10y ago
  You may be interested in: https://en.wikipedia.org/wiki/Dialectic#Hegelian_dialectic https://en.wikipedia.org/wiki/Dialectic#Hegelian_dialectic
- mcphage 10y ago
  > It doesn't seem too long ago when Java Developers rushed to Ruby because it wasn't statically typed. Java has a particularly bad type system.
- stephen 10y ago
  > It doesn't seem too long ago when Java Developers > rushed to Ruby because it wasn't statically typed. IMO they were rushing away from: 1) Java's verbose syntax (not the type system itself; static typing and verbose syntax are technically orthogonal), 2) The J2EE + FooFactoryFactory mess that infected the Java ecosystem at the time, and 3) Enterprise software in general (a lot of Ruby was in startups, so fun greenfield development, away from the J2EE/enterprise mess). For Java itself, the syntax is finally getting better (Sun really screwed that up, and let C# get way ahead in innovation), and J2EE is finally over AFAIU, so Java development is generally/in theory not as bad as it was when everyone left. </Stockholm syndrome>
Dr_tldr 10y ago
I feel exactly the opposite. I'm continually amazed that Java devs have still not acclimated themselves to Javascript after all this time. If you notice that the style you're used to coding in is causing a lot of problems and that people coding in other styles have few-to-none of these problems, maybe it's worth questioning your approach. I maintain a medium-sized (50k lines) codebase with frequent requirement changes that uses a functional style, and the closest we've come to ever needing a type-check is null checks. Type errors are maybe 2% of total errors when developing, and because our code doesn't have too many layers of indirection, they've all been trivial to fix way before production. I'd much rather spend 30 seconds every week fixing a type error than spend hundreds of hours writing type files and code in a dialect of Javascript that doesn't provide 100% coverage. If you embrace functional programming with mostly immutable data structures and avoid mutation, side-effects, and gross mixins/polymorphism, you reduce the size of your codebase significantly, which makes it much easier to keep documentation terse and up-to-date. On the other hand, if your team is so undisciplined and untrustworthy that you need to throw errors on compilation because you don't trust them to update comments and docs or name variables descriptively and your entire team knows Java but not Javascript, I could see the huge amount of boilerplate involved in Typescript being well worth it. As someone who's primarily a Javascript developer who does Clojure on the side, I feel that the Java approach is fundamentally impoverished. I've never met anyone who chose to develop in Typescript whose background wasn't enterprise Java, just like I've never met anyone using Ramda (before lodash replicated it) whose background wasn't in FP.
- adamnemecek 10y ago
  > I'd much rather spend 30 seconds every week fixing a type error than spend hundreds of hours... I'll take "unrealistic estimates" for $500, Alex.
  - Dr_tldr 10y ago
    http://games.greggman.com/game/dynamic-typing-static-typing/ http://games.greggman.com/game/dynamic-typing-static-typing/ So we've got data plus my experience plus my team's experience in a large, very successful enterprise on one side, and we've got snark and defense of existing habits on the other? I'll take the risk, I think.
orgomon 10y ago
Where is the evidence that static typing results in a net benefit? There's some evidence that points in the opposite direction: http://games.greggman.com/game/dynamic-typing-static-typing/ http://games.greggman.com/game/dynamic-typing-static-typing/ When a language imposes static types, it also imposes a development cost, possibly negating all the value it brings. Typescript is a little in the middle in that static typing is optional, but then you also don't reap the supposed benefits wherever you don't use it. Any "tool-based" refactoring is now less reliable than a simple text search. As for catching type errors, those are usually caught very early. If they aren't, that points to a lack of test coverage. As for the "documenting" aspect: The article claims that by static typing, the documentation need not be consulted, which is rather irresponsible. If you use a function, you had better read the documentation. I know that's a bit much to ask from actual developers, but it's true.
- PeCaN 10y ago
  Maybe it's because I'm lazy and sloppy, but I'd rather the language catch type mistakes than having to write tests for that. Plus, domain modelling with types is nice in ML dialects.
  - orgomon 10y ago
    You're not writing tests to catch type errors. You write tests that actually use your code, where a type error will almost certainly be picked up. Chances are however, your type error will already occur the first time you run your code.
- crypto5 10y ago
  > it also imposes a development cost, Very very small cost.
  - rtpg 10y ago
    Historically this cost was a lot higher though. It's only fairly recently that mainstream languages had type inferencing. Before it could be quite costly (and affect code legibility too)
seanmcdirmid 10y ago
It has never been determined if static checking is the killer app of static checking, or feedback say in the form of code completion is. Anyways, the story is not as simple as ideologues on either side of the debate would have us believe.
codexon 10y ago
It doesn't amaze me at all. Before tooling was very poor with no autocomplete so using a typed language meant you had to type maybe 20% more (and cluttering the code) on top of having to add everything to a struct in exchange for catching runtime type errors. Now with type inference and intelligent autocomplete, these features add back efficiency to the point of making them as fast, if not faster to develop non-enterprise sized programs.
rtpg 10y ago
I think there's a couple of steps here that make it not a cycle: - Lots of languages used static typing for implementation ease/ no need for VM (probably not as much for safety issues, given the many failures of C's type system). Also, lack of GC meant that memory management is a big deal, and types and memory management are pretty linked. - It's verbose though, and you can still easily make mistakes, so dynamic languages offer both cleaner code and the safety checks weren't that useful anyways (again, this is from C/Java land. Null pointer exceptions!). - Newer static languages offer even better type systems that catch an order of magnitude more bugs. And type inference means that it doesn't affect legibility nearly as much. So we're basically progressing on all axes at once. Language design isn't zero-sum, luckily.
gedy 10y ago
Problem I have with this is web UI work doesn't greatly benefit from typing - and when it's introduced in whichever way - the apps frequently start using type in conditionals, and generally leads to extra code for no clear benefit.
tracker1 10y ago
By the same note, people are discovering that classical OO doesn't always add value at all... Similarly, depending on your environment static enforcement doesn't really add much and may detract. Though it takes discipline in either case. I think with both class-based OO, and static type checking, they can offer some benefits, mostly in IDE integration. Beyond that, they don't stop developers from being sloppy and/or using object patterns that are crushingly slow.

stephen 10y ago

Agreed; if you're looking for a tldr (edit: for sharing with others, e.g. I know you're convinced), I recently made a few edits to my pontification from awhile ago: http://www.draconianoverlord.com/2010/11/24/why-im-a-static-typing-bigot.html http://www.draconianoverlord.com/2010/11/24/why-im-a-static-... I really like the OP's point about "types make abstractions explicit". That is a great articulation that I'm going to add to my post as well, with attribution.

reboog711 10y ago

Cycles... It doesn't seem too long ago when Java Developers rushed to Ruby because it wasn't statically typed. Now, TypeScript is better than JavaScript because of the opposite reason... I've seen this sort of pendulum swing a few times in my career.

67726e 10y ago
I don't think it's fair to say "Java Developers" rushed to Ruby. Cargo-Culting, fad-chasing developers do. The fact is statically typed code eliminates whole classes of errors. There are some trade-off but I can't begin to consider the trade-off for anything non-trivial I want to survive for more than a year.
kmiroslav 10y ago
Pretty sure that pendulum is never swinging back in the dynamically type side. The simple truth is that today, statically typed languages have all the advantages that once used to be the exclusivity of dynamically typed languages, while the reverse is still not true. In 2016, there is really very little reason to pick a dynamically typed language for any serious project. Javascript is going to be around for a while because of inertia, but it's pretty much the last mainstream dynamically typed language we'll see.
- d0vs 10y ago
  Curious to hear why this is being downvoted.
  - kmiroslav 10y ago
    There are still a lot of Javascript developers around :-)
- wlesieutre 10y ago
  >Javascript is going to be around for a while because of inertia, but it's pretty much the last mainstream dynamically typed language we'll see. Python's still pretty popular too
- mcphage 10y ago
  > it's pretty much the last mainstream dynamically typed language we'll see I partially agree. I think as type inferencing gets smarter, we're going to end up with languages that are statically typed by the compiler or interpreter, but that there will be few-to-no type annotations in the code. So yes, I think the future is static typing, but I think it's going to end up a compiler feature and not part of the language at all.
- seanmcdirmid 10y ago
  Subtyping combined with paramtericity is still a problem with good (I.e. doesn't suck) type inference. Unless you are will to live without either, it isn't true that static thong has all the advantages of dynamic, yet.
- eyelidlessness 10y ago
  > In 2016, there is really very little reason to pick a dynamically typed language for any serious project. I wish this were true. I wholeheartedly agree that, all other things being equal, static typing is better than dynamic typing. If there were no other factors, I would choose static typing without a second thought. But there are other factors, and all other things are not equal. I write ClojureScript every day. Its lack of static typing is a genuine source of pain. Every day. But when I compare it to Elm, which I'm quite interested in: - JS interop. Maybe I suck at google, but it looks like it's not a first-class concern of the language or the community. - Macros. Defining language features is great. It's the reason that a lisp can be small in terms of core language constructs (even if its standard library is enormous cough Clojure). In 2016, there is really very little reason to design a language without metaprogramming in mind. - Community, which admittedly could and should and will grow in size and sophistication for Elm. When I compare it to TypeScript? - State. Welp. - No seriously, why is everything mutable? It's 2016 and a language that was designed with concurrency and functional programming in mind from the start still hasn't caught on to mutability by default as a serious problem, and TypeScript inherits all this baggage. - There's no simple clear path to even set up a TypeScript project. There's a million different ways with different tooling choices, and that fractured environment is evident whenever searching for answers. The world of JavaScript constantly bleeds through. If I want to know how to use TS, I need to know WebPack and NPM and Bower and who knows how many other things that are not even for TS. - Forget metaprogramming. - What is the TS community? Microsoft and a weird has-been cult team at Google? (Sorry guys, I did the Angular thing, and I watched it become a circus from the time Angular 2 was announced to the time your weird conference was more like a dance club than a tech conference.) I could simplify this by calling out your last line. JavaScript rules the roost. You better play nicely with it, if you want to build a web app. Honestly the web is going to be an increasingly fractured thing for many years. There's just too many ways to do things and they're all compromised in awful ways. Postscript: I'm sorry this is so ranty. I mean no harm and I mean none of my criticisms to be taken as attacks. I want very much to do good work as a web dev and I'm just heartbroken that it's such a pain.
ken47 10y ago
They're not exactly comparable. Java's type system gets in your way. Typescript only gets in the way when you ask it to. The dev experience can be quite different.
GFK_of_xmaspast 10y ago
You may be interested in: https://en.wikipedia.org/wiki/Dialectic#Hegelian_dialectic https://en.wikipedia.org/wiki/Dialectic#Hegelian_dialectic
mcphage 10y ago
> It doesn't seem too long ago when Java Developers rushed to Ruby because it wasn't statically typed. Java has a particularly bad type system.
stephen 10y ago
> It doesn't seem too long ago when Java Developers > rushed to Ruby because it wasn't statically typed. IMO they were rushing away from: 1) Java's verbose syntax (not the type system itself; static typing and verbose syntax are technically orthogonal), 2) The J2EE + FooFactoryFactory mess that infected the Java ecosystem at the time, and 3) Enterprise software in general (a lot of Ruby was in startups, so fun greenfield development, away from the J2EE/enterprise mess). For Java itself, the syntax is finally getting better (Sun really screwed that up, and let C# get way ahead in innovation), and J2EE is finally over AFAIU, so Java development is generally/in theory not as bad as it was when everyone left. </Stockholm syndrome>

Dr_tldr 10y ago

I feel exactly the opposite. I'm continually amazed that Java devs have still not acclimated themselves to Javascript after all this time. If you notice that the style you're used to coding in is causing a lot of problems and that people coding in other styles have few-to-none of these problems, maybe it's worth questioning your approach. I maintain a medium-sized (50k lines) codebase with frequent requirement changes that uses a functional style, and the closest we've come to ever needing a type-check is null checks. Type errors are maybe 2% of total errors when developing, and because our code doesn't have too many layers of indirection, they've all been trivial to fix way before production. I'd much rather spend 30 seconds every week fixing a type error than spend hundreds of hours writing type files and code in a dialect of Javascript that doesn't provide 100% coverage. If you embrace functional programming with mostly immutable data structures and avoid mutation, side-effects, and gross mixins/polymorphism, you reduce the size of your codebase significantly, which makes it much easier to keep documentation terse and up-to-date. On the other hand, if your team is so undisciplined and untrustworthy that you need to throw errors on compilation because you don't trust them to update comments and docs or name variables descriptively and your entire team knows Java but not Javascript, I could see the huge amount of boilerplate involved in Typescript being well worth it. As someone who's primarily a Javascript developer who does Clojure on the side, I feel that the Java approach is fundamentally impoverished. I've never met anyone who chose to develop in Typescript whose background wasn't enterprise Java, just like I've never met anyone using Ramda (before lodash replicated it) whose background wasn't in FP.

adamnemecek 10y ago
> I'd much rather spend 30 seconds every week fixing a type error than spend hundreds of hours... I'll take "unrealistic estimates" for $500, Alex.
- Dr_tldr 10y ago
  http://games.greggman.com/game/dynamic-typing-static-typing/ http://games.greggman.com/game/dynamic-typing-static-typing/ So we've got data plus my experience plus my team's experience in a large, very successful enterprise on one side, and we've got snark and defense of existing habits on the other? I'll take the risk, I think.

orgomon 10y ago

Where is the evidence that static typing results in a net benefit? There's some evidence that points in the opposite direction: http://games.greggman.com/game/dynamic-typing-static-typing/ http://games.greggman.com/game/dynamic-typing-static-typing/ When a language imposes static types, it also imposes a development cost, possibly negating all the value it brings. Typescript is a little in the middle in that static typing is optional, but then you also don't reap the supposed benefits wherever you don't use it. Any "tool-based" refactoring is now less reliable than a simple text search. As for catching type errors, those are usually caught very early. If they aren't, that points to a lack of test coverage. As for the "documenting" aspect: The article claims that by static typing, the documentation need not be consulted, which is rather irresponsible. If you use a function, you had better read the documentation. I know that's a bit much to ask from actual developers, but it's true.

PeCaN 10y ago
Maybe it's because I'm lazy and sloppy, but I'd rather the language catch type mistakes than having to write tests for that. Plus, domain modelling with types is nice in ML dialects.
- orgomon 10y ago
  You're not writing tests to catch type errors. You write tests that actually use your code, where a type error will almost certainly be picked up. Chances are however, your type error will already occur the first time you run your code.
crypto5 10y ago
> it also imposes a development cost, Very very small cost.
- rtpg 10y ago
  Historically this cost was a lot higher though. It's only fairly recently that mainstream languages had type inferencing. Before it could be quite costly (and affect code legibility too)

seanmcdirmid 10y ago

It has never been determined if static checking is the killer app of static checking, or feedback say in the form of code completion is. Anyways, the story is not as simple as ideologues on either side of the debate would have us believe.

codexon 10y ago

It doesn't amaze me at all. Before tooling was very poor with no autocomplete so using a typed language meant you had to type maybe 20% more (and cluttering the code) on top of having to add everything to a struct in exchange for catching runtime type errors. Now with type inference and intelligent autocomplete, these features add back efficiency to the point of making them as fast, if not faster to develop non-enterprise sized programs.

rtpg 10y ago

I think there's a couple of steps here that make it not a cycle: - Lots of languages used static typing for implementation ease/ no need for VM (probably not as much for safety issues, given the many failures of C's type system). Also, lack of GC meant that memory management is a big deal, and types and memory management are pretty linked. - It's verbose though, and you can still easily make mistakes, so dynamic languages offer both cleaner code and the safety checks weren't that useful anyways (again, this is from C/Java land. Null pointer exceptions!). - Newer static languages offer even better type systems that catch an order of magnitude more bugs. And type inference means that it doesn't affect legibility nearly as much. So we're basically progressing on all axes at once. Language design isn't zero-sum, luckily.

gedy 10y ago

Problem I have with this is web UI work doesn't greatly benefit from typing - and when it's introduced in whichever way - the apps frequently start using type in conditionals, and generally leads to extra code for no clear benefit.

tracker1 10y ago

By the same note, people are discovering that classical OO doesn't always add value at all... Similarly, depending on your environment static enforcement doesn't really add much and may detract. Though it takes discipline in either case. I think with both class-based OO, and static type checking, they can offer some benefits, mostly in IDE integration. Beyond that, they don't stop developers from being sloppy and/or using object patterns that are crushingly slow.