6 ms·

>If you feel like the type system fights against you, chances are that you are doing something wrong. Like most things, I think this depends on context. Doing

>If you feel like the type system fights against you, chances are that you are doing something wrong. Like most things, I think this depends on context. Doing exploratory data analysis in a static, strongly-typed language, for example, is extremely painful. And writing quick, one-time scripts in such languages is usually more trouble than it's worth. For this reason, Python is a wonderful language for doing data analysis and writing quick one-time data munging scripts (and yes, I realize that Python can be considered strongly-typed). On the other hand, I've now been exposed to languages like OCaml and Rust, and have had time to think about Java, and I now have a different attitude when I'm building a large application that will have to be maintained. I'm beginning to feel extremely vulnerable when I use a language like Python or (worse yet) Javascript to build such applications. It's not that I'm not a Javascript hater. I like Javascript in general -- it has a kind of functional feel to it, it's easy to prototype quickly, you can use it client and server, nice ecosystem, and unlike so many I actually enjoy async programming. And I've long enjoyed Python for similar reasons. But for building a robust application that will have to be maintained a long-time, you have to religiously write tests in these languages or you'll be buried in bugs. And even then, you still may be buried in bugs that a static, strongly-typed language would have detected. For this reason, I'm looking hard for an static, strongly-typed alternative to Javascript for the browser (i.e., a language compiling to JS) for building large applications. And Ocaml's js_of_ocaml is definitely on my list of things to evaluate. So the programming language philosophy that I adhere to now is encapsulated in the hackneyed old saying "use the right tool for the job".

jshen 12y ago
"But for building a robust application that will have to be maintained a long-time, you have to religiously write tests in these languages or you'll be buried in bugs. And even then, you still may be buried in bugs that a static, strongly-typed language would have detected." People make this sort of claim all the time, but my personal experience has not borne it out, and I have seen no data to backup this claim which would override my personal experience. First, I find I have to write tests nearly as religiously in statically types languages, so I don't find that a convincing argument. Second, most bugs I've experienced in large code bases using a dynamic language are not the sort that would be caught by most typed languages. On this point there is even some data that backs up my personal experience (http://vimeo.com/74354480 http://vimeo.com/74354480). Third, writing code with a static language takes more time in my experience. Maybe it prevents a tiny fraction of bugs, but for most things I'll take saving significant time and cost over preventing 3% of bugs (I made up that number). In short, I'm not sold on these arguments for static typing.
- MetaCosm 12y ago
  I agree with you on one part, writing static language INITIAL code, does generally take more time. Depending on the language, it can vary from slightly more in something like Go (where composition is valued over type hierarchies) to a great deal longer in languages that encourage lots of castle building and type relationships. That said, I have been in industry for over a decade in a half, and the most miserable, hellish experience I ever had was dealing with a large (100k+) non-trivial consumer facing Python application. It was a special type of pain, with novel errors happening in production on a regular basis 4+ years into the project. Refactoring was horrifically risky, and the analysis tooling stack is AWFUL... to the point that when used, it was often outright wrong. I will gladly give up those cost savings on the leading edge, to have a product I can actually maintain in the long term. I suspect this inability to maintain apps writing in certain dynamic languages is why they have culture bias towards starting over (and being proud of it, "version 2.0, rewritten from scratch!")... which I found a bit shocking at first versus C, which would trend far more toward refactoring.
  - rdtsc 12y ago
    I have also been in the industry for about as much and noticed: * Sometimes, the time it takes to build something in a statically typed language is much longer. Long enough that by the time it is built it might not matter because somebody would have built it in node.js, ruby, or python. I really depends on the market. * Type mismatches in a Python program are not the biggest and deadliest bugs. Unit tests and integration tests (that should be there anyway) should catch those well. * Often static type languages that have pointers (C, C++) hide much deadlier and dangerous types of bugs -- pointer bugs like "wild pointers". * Static type language that don't offer protocol checks also can't easily detect bugs where you open a file handle, close it, then read from it. It knows it is a FILE or some iostream but it doesn't help much there. I've heard other more advanced languages have something in place to handle that. * The above point coupled with being able to use the REPL on a production system and code has saved significant debugging time. In a complex system there could be an interaction that is hard to reproduce and this one system is in that funky state. Can log in via SSH into it, edit the code to add some debug statements and reproduce it again. In summary, I would like Python to have a standard type annotation syntax that good linters will be able to check for and IDEs will know how to read and use. But it would not be at the top of the list of features I would like Python to have next. EDIT: (sorry, last sentence should have said "it would not be" instead of "it would be")
keypusher 12y ago
Dart is a language worth considering if you want something with static types that compiles to js.
- eric_bullington 12y ago
  Alas, Dart is pretty much a dynamic language with optional (and intentionally unsound) static typing. I understand why they've made some of the decisions they did, but it doesn't appeal to me much as a Javascript alternative, since it's not going to catch most of the errors that a proper statically-typed language would. It is a very nice Javascript-without-all-the-weirdness, however.
tel 12y ago
> Doing exploratory data analysis in a static, strongly-typed language, for example, is extremely painful. As bullish as I normally am on static typing, I agree with that wholeheartedly—today. I'm also completely convinced that a language with good enough record row-subtyping will take over as being far better for EDA than any dynamic language within the next 5 years. That's the thing about research in types—it's almost always about discovering new techniques to appropriately structure and represent more complex programming techniques. It can lag for reasons of sophistication, but once it's in place it'll be hard to beat. Already I feel it's absolutely the case that good static types (Haskell I'm most familiar with, but I imagine it's the case with Scala, OCaml, F#) are a win for short, one-off scripts. The difference is that the types you use are looser than the ones you'd use for a super robust application. The typing ends up looking a lot more like the typing you'd implicitly apply to a Python program [0]. So, "use the right tool for the job" applies to typing technology as well. Static types, I believe, will eat the use cases of dynamic types. [0] This is essentially an extension of the "unityped argument". If you program in Haskell in a "always IO, frequently ambiguous" fashion then you can get all the flexibility you're used to in scripting in Python with little overhead.
Joeri 12y ago
In my opinion the trick to large-scale software architecture is to build small software systems tied together by strictly defined interfaces. There are many ways to ensure the strictness of the interface: having strict typing and a compilation step, unit tests, static code validation (compiling without compiling), and even hungarian notation and systematic code reviews. Those are not mutually exclusive tools; quality improves with each one added, but none are mandatory. My personal experience working on large systems without unit tests (among others a 200.000 line javascript codebase) is that as long as you adopt good coding practices around how you define clearly typed interfaces the lack of unit tests doesn't hurt you that badly and there is no wild-growth of bugs. Using the jetbrains IDE's also made a big difference for me due to the static code checking. I want to see the little code quality box at the top of the scrollbar turn green, and the process of doing that tends to weed out a lot of those bugs that a unit test or a strict type system would catch. I do think that if you're building large-scale or long-lived systems, it is not any faster to use a dynamically typed language. I've written lots of code in both strictly typed and loosely typed languages, and I find that while I enjoy a loosely typed language more, I am equally productive in the strictly typed environment because strict typing makes it easier to write reliable code from the outset.

jshen 12y ago

"But for building a robust application that will have to be maintained a long-time, you have to religiously write tests in these languages or you'll be buried in bugs. And even then, you still may be buried in bugs that a static, strongly-typed language would have detected." People make this sort of claim all the time, but my personal experience has not borne it out, and I have seen no data to backup this claim which would override my personal experience. First, I find I have to write tests nearly as religiously in statically types languages, so I don't find that a convincing argument. Second, most bugs I've experienced in large code bases using a dynamic language are not the sort that would be caught by most typed languages. On this point there is even some data that backs up my personal experience (http://vimeo.com/74354480 http://vimeo.com/74354480). Third, writing code with a static language takes more time in my experience. Maybe it prevents a tiny fraction of bugs, but for most things I'll take saving significant time and cost over preventing 3% of bugs (I made up that number). In short, I'm not sold on these arguments for static typing.

MetaCosm 12y ago
I agree with you on one part, writing static language INITIAL code, does generally take more time. Depending on the language, it can vary from slightly more in something like Go (where composition is valued over type hierarchies) to a great deal longer in languages that encourage lots of castle building and type relationships. That said, I have been in industry for over a decade in a half, and the most miserable, hellish experience I ever had was dealing with a large (100k+) non-trivial consumer facing Python application. It was a special type of pain, with novel errors happening in production on a regular basis 4+ years into the project. Refactoring was horrifically risky, and the analysis tooling stack is AWFUL... to the point that when used, it was often outright wrong. I will gladly give up those cost savings on the leading edge, to have a product I can actually maintain in the long term. I suspect this inability to maintain apps writing in certain dynamic languages is why they have culture bias towards starting over (and being proud of it, "version 2.0, rewritten from scratch!")... which I found a bit shocking at first versus C, which would trend far more toward refactoring.
- rdtsc 12y ago
  I have also been in the industry for about as much and noticed: * Sometimes, the time it takes to build something in a statically typed language is much longer. Long enough that by the time it is built it might not matter because somebody would have built it in node.js, ruby, or python. I really depends on the market. * Type mismatches in a Python program are not the biggest and deadliest bugs. Unit tests and integration tests (that should be there anyway) should catch those well. * Often static type languages that have pointers (C, C++) hide much deadlier and dangerous types of bugs -- pointer bugs like "wild pointers". * Static type language that don't offer protocol checks also can't easily detect bugs where you open a file handle, close it, then read from it. It knows it is a FILE or some iostream but it doesn't help much there. I've heard other more advanced languages have something in place to handle that. * The above point coupled with being able to use the REPL on a production system and code has saved significant debugging time. In a complex system there could be an interaction that is hard to reproduce and this one system is in that funky state. Can log in via SSH into it, edit the code to add some debug statements and reproduce it again. In summary, I would like Python to have a standard type annotation syntax that good linters will be able to check for and IDEs will know how to read and use. But it would not be at the top of the list of features I would like Python to have next. EDIT: (sorry, last sentence should have said "it would not be" instead of "it would be")

keypusher 12y ago

Dart is a language worth considering if you want something with static types that compiles to js.

eric_bullington 12y ago
Alas, Dart is pretty much a dynamic language with optional (and intentionally unsound) static typing. I understand why they've made some of the decisions they did, but it doesn't appeal to me much as a Javascript alternative, since it's not going to catch most of the errors that a proper statically-typed language would. It is a very nice Javascript-without-all-the-weirdness, however.

tel 12y ago

> Doing exploratory data analysis in a static, strongly-typed language, for example, is extremely painful. As bullish as I normally am on static typing, I agree with that wholeheartedly—today. I'm also completely convinced that a language with good enough record row-subtyping will take over as being far better for EDA than any dynamic language within the next 5 years. That's the thing about research in types—it's almost always about discovering new techniques to appropriately structure and represent more complex programming techniques. It can lag for reasons of sophistication, but once it's in place it'll be hard to beat. Already I feel it's absolutely the case that good static types (Haskell I'm most familiar with, but I imagine it's the case with Scala, OCaml, F#) are a win for short, one-off scripts. The difference is that the types you use are looser than the ones you'd use for a super robust application. The typing ends up looking a lot more like the typing you'd implicitly apply to a Python program [0]. So, "use the right tool for the job" applies to typing technology as well. Static types, I believe, will eat the use cases of dynamic types. [0] This is essentially an extension of the "unityped argument". If you program in Haskell in a "always IO, frequently ambiguous" fashion then you can get all the flexibility you're used to in scripting in Python with little overhead.

Joeri 12y ago

In my opinion the trick to large-scale software architecture is to build small software systems tied together by strictly defined interfaces. There are many ways to ensure the strictness of the interface: having strict typing and a compilation step, unit tests, static code validation (compiling without compiling), and even hungarian notation and systematic code reviews. Those are not mutually exclusive tools; quality improves with each one added, but none are mandatory. My personal experience working on large systems without unit tests (among others a 200.000 line javascript codebase) is that as long as you adopt good coding practices around how you define clearly typed interfaces the lack of unit tests doesn't hurt you that badly and there is no wild-growth of bugs. Using the jetbrains IDE's also made a big difference for me due to the static code checking. I want to see the little code quality box at the top of the scrollbar turn green, and the process of doing that tends to weed out a lot of those bugs that a unit test or a strict type system would catch. I do think that if you're building large-scale or long-lived systems, it is not any faster to use a dynamically typed language. I've written lots of code in both strictly typed and loosely typed languages, and I find that while I enjoy a loosely typed language more, I am equally productive in the strictly typed environment because strict typing makes it easier to write reliable code from the outset.