10 ms·

This claim: "Python/Ruby/Javascript: my experience is that large systems are difficult to maintain in these languages, as the dynamic typing makes it difficult

by dvt 13y ago

This claim: "Python/Ruby/Javascript: my experience is that large systems are difficult to maintain in these languages, as the dynamic typing makes it difficult to refactor large codebases without introducing errors in poorly tested areas of a repository" -- is unfounded. Even though there may be some good reasons why one might use Go instead of C/C++, I find it hard to justify using Go instead of Python/Ruby/JS/Java (the only criticism of Java - that it's verbose and hard to tune - is questionable as well). I've said this before. I like Go. I contributed to Go. I've used Go and I still use it from time to time. But much like D, I don't think it has a niche. There are magnitudes more libraries and resources available for Python/Ruby/JS/Java -- thus far, it's been more than enough to sway me into using those languages (mostly JS/Java) instead of Go.

pron 13y ago
I share the sentiment. People often mention that Go is less verbose than Java like they were talking about Clojure or something. Go is just a little less verbose than Java (other than in a hello world example), and targets the same conceptual "level" (same order of abstractions, same "distance" from the metal, although Java can get closer to metal than Go). So, sure, it feels a little more modern in some respects (and less modern in others), but when considering both languages carefully, I find I really need a magnifying to tell the two apart. If Go had offered everything that Java does, I still wouldn't have had a compelling reason to switch because the differences are just too small. But Go doesn't offer everything Java does. Like you said, Java's ecosystem dwarfs Go's. Java has dynamic linking, runtime code instrumentation, unparalleled tooling, and better performance than Go. The only advantage I see Go has over Java is a shorter startup time, which makes it a reasonable choice for writing command-line programs. As for concurrency constructs, Java is far more flexible than Go, and because goroutines and channels are easy, I've ported them to Java[1] (and Clojure). Go sure is easy to get started with, but it would have to be 20 times better than it is to make me give up the JVM. In reality, it's just a recent, beginner-friendly Java without the awesomeness of the JVM. (P.S. I'm not sure Java's often mocked factory-factories aren't simply a result of the huge number of multi-million LOC programs that have been written in Java. It's just experience, and Go sure doesn't have the necessary abstractions to make engineering large systems any easier. Other recent languages -- sure -- but not Go) [1] https://github.com/puniverse/quasar https://github.com/puniverse/quasar
- dvt 13y ago
  With cgo, Go can get "just as close" to the metal too. But I don't even think a cgo vs. JNI benchmark would be substantive. Most people don't use a "medium-"level programming language to write low-level code, anyway. Like you say, Java is barely less verbose and arguably just as powerful as Go with many more times over the documentation and resources.
  - pron 13y ago
    Oh, I would say Java is much, much more powerful than Go. Other than dynamic code loading and runtime instrumentation, even when it comes to concurrency you have your choice of schedulers and control over OS threads.
    - dvt 13y ago
      I agree, but I think fans of Go would not :P Hence my tentative "arguably."
- jeremyjh 13y ago
  You have "ported" a green threads implementation for Java? I'd really like to know more about that.
  - pron 13y ago
    I call them fibers. Or lightweight threads. They're like Erlang processes or goroutines. You can read more about it here: http://blog.paralleluniverse.co/post/49445260575/quasar-pulsar http://blog.paralleluniverse.co/post/49445260575/quasar-puls... The library is very much in active development.
    - dvt 13y ago
      You mention Kilim (but perhaps not in a very good light)! Very cool. To be honest, I was surprised what you could do with Kilim (and the awesome robustness of the system). Unfortunately, I don't think Kilim has been updated for ASM 4.0 -- your library looks interesting though, I will certainly take a look at it.
fixxer 13y ago
> There are magnitudes more libraries and resources available for Python/Ruby/JS/Java Those languages have been out longer. I think Go will get there. EDIT: cgo dramatically expands the libraries. I hear a lot of people say "Go doesn't have X", but if X is already implemented in C (assuming some conditions are met), then you need not reinvent the wheel. I've been using Go as a concurrent parent over C functions for my geospatial research... really nice fit when you need to do 100 gigs worth of XYZ coordinate transforms.
- dvt 13y ago
  I guess my extended argument is -- okay, so Go will get there eventually (I'll concede that) -- but then what? IMO, Go will still not be attractive enough to warrant a major migration. cgo is interesting, but we already have a Java analog - the JNI.
  - freyr 13y ago
    > Go will still not be attractive enough to warrant a major migration One of pron's concessions above is that Go is much easier to learn. That could be its killer feature: a new generation of developers and founders may choose to use Go for their projects because of the lower barrier to entry. A common theme with these write-ups is that the developer felt comfortable with Go after about a week. That's pretty incredible. I had the same experience. Coming from a scientific computing background, I wanted to get my feet wet with a an application level or system level language. I chose Go, and I felt like I was off and running in about a week. I've since looked at Java, and I'd rather not get involved with it unless absolutely necessary. If that turns out to be the experience of many others, it won't be a matter of migration. It'll be a matter of growth from the ground level.
    - pron 13y ago
      That is a good point, and it just might be that way, but I'm not so sure for several reasons. First, languages like Python and Ruby (and I think Clojure, too) are as easy to learn and Go, and most would say are more productive. And if you want a system level language, then you're probably not a beginner. Yes, Go is easier to learn than Java, but certainly not by much (it is, granted, much easier to get a small program running in Go). On the other hand, Java (or Kotlin) are more versatile. Someone once said that easy always wins, and this might be the case with a system level language, too, but maybe when people specifically look for power then easy is not their top priority? I don't know.
danieldk 13y ago
This claim: [...] -- is unfounded. Actually, most of that enumeration consists of shallow clichés. For instance, take the description of Java: Java: too verbose, Having written a fair share of Go and Java code, I have to say that difference is not all that profound. The usual boilerplate that people come up with is the construction of a BufferedReader/Writer. But Go has its share of boilerplate as well (e.g. error handling). Java currently has the advantage that IDEs can quickly generate whatever boilerplate is necessary. Given that Go is easy to parse and has a simple module system, there'll probably fairly complete IDEs for Go as well. too many FactoryFactories That very much depends on what libraries or frameworks you use. I have written lots of ML and NLP code in Java the last half year or so. I can count the number of insane 'FactoryBuilderProxy'-like classes that I encountered on one hand. Wait a bit and the architecture astronauts will also be writing Go packages ;).
- stcredzero 13y ago
  > Actually, most of that enumeration consists of shallow clichés. You can apply this to most of the writing about programming languages out there. My view might be skewed on HN, but it seems like the majority of this stuff is put out by programmers trying to promote themselves.
ionforce 13y ago
It's weird. You mention that the claim is unfounded, and then you have all this text that follows, but none of it seems related to supporting your point. How is the claim that [X at large is difficult to maintain] unfounded? I happen to agree. I am (was?) a Perl/JavaScript developer. I find both to be sorely lacking at a certain size. And by extension I assume Python and Ruby to be the exact same (under the shared umbrella of lacking static type safety).
davesims 13y ago
I was about to post the exact same comment, with the above quote from OP in my clipboard. In my experience, this claim is made by (many times really good, experienced, intelligent) coders who have a lot of previous experience in static typing and aren't comfortable -- either because of a lack of time and sheer LOC, or because of some mental block they've doubled-down on ("where's my 'extract method' menu option???") with the techniques and peculiar challenges of dynamic type refactorings. I work on a very large application/system of applications in a dynamic environment, and I've never encountered refactoring or maintenance issues that I thought would have been any easier in my previous life, 10 yrs in static typing. The other thing to keep in mind is that -- at least when comparing something like, for instance Rails to Java, there will be a lot less code, and this is a significant contribution to code management. That factor, plus just experience and acclimation to the techniques for dynamic-type editing/replacing/finding/greping and so on, plus solid TDD practices -- maintenance has never been an issue for me, and I've had a decent amount of time in large codebases in both dynamic and static environments.
- ionforce 13y ago
  With a static language, you get more with less. If you didn't have any testing framework, the compiler would tell you where you messed up. So, there's that, barring "well you should have had testing code to begin with". Grepping is ghetto, second-class. Whereas an IDE with built-in refactorings has a much higher guarantee of hitting the right artifacts, especially with shared substring collision. Again, barring "well you should have named things better". Having spent the majority of my career as dynamic and now a recent convert to static, I fail to see the allure of dynamic languages at a certain scale. You can shoot yourself in any language, but I think it is easier and safer to crawl out of a static mess than it is a dynamic one. And, I would argue the majority of applications do not demand the level of dynamism that dynamic languages are capable of, making it a waste.
  - masklinn 13y ago
    > Grepping is ghetto, second-class. Whereas an IDE with built-in refactorings has a much higher guarantee of hitting the right artifacts, especially with shared substring collision. Of course that only works when the tooling exists, which for instance it does not for Go but does for Python. Doesn't for Haskell but does for Ruby (Jetbrains has done a pretty good job there).
btilly 13y ago
This claim: "Python/Ruby/Javascript: my experience is that large systems are difficult to maintain in these languages, as the dynamic typing makes it difficult to refactor large codebases without introducing errors in poorly tested areas of a repository" -- is unfounded. Not necessarily unfounded, you simply don't have access to data on it. I am not at liberty to share details, but I have in fact seen data from a large company based on many internal projects that found that initial development was faster but long-term maintenance costs were much higher for stuff written in dynamic languages like Python and Ruby than in static languages like Java and C++. The cost difference was both large and real. As someone who mostly does dynamic languages I didn't like the conclusion, but I couldn't argue with the numbers.
- stcredzero 13y ago
  > I have in fact seen data from a large company based on many internal projects that found that initial development was faster but long-term maintenance costs were much higher for stuff written in dynamic languages like Python and Ruby than in static languages like Java and C++. A big part of this is the shortsightedness of the companies themselves. There are steps you can take to ensure that you can manage types in dynamic languages. Very often, companies simply don't take these steps. It's not programmers that need babysitting by tools. It's big enterprise.
  - pron 13y ago
    > It's not programmers that need babysitting by tools. It's big enterprise. If one language is easier for "big enterprise" to maintain than another, then what's the problem? Obviously different languages have different strengths.
    - steveklabnik 13y ago
      The claim 'big enterprise is better served by a statically typed language' is a different claim than 'dynamically typed languages cannot be used for large projects.'
burntsushi 13y ago
> This claim: "Python/Ruby/Javascript: my experience is that large systems are difficult to maintain in these languages, as the dynamic typing makes it difficult to refactor large codebases without introducing errors in poorly tested areas of a repository" -- is unfounded. Why is it unfounded? The author clearly qualifies his claim with "my experience". That's my experience too. I wouldn't extrapolate it to all programmers and in all scenarios, but dynamic typing just has never worked that well for me in larger projects. It could be because I'm not as diligent about writing unit tests or it could be because I'm not intelligent enough to reason about large amounts of code without static types. Regardless of whether it is, it's my experience and it certainly isn't "unfounded."
- ionforce 13y ago
  I don't think reasoning about types is a matter of intelligence. I happen to share your experience. It is more of a cognitive burden, exacerbated by less diligent coworkers. No amount of "convention within dynamism" can compete with first class compile time type safety. If I were to babysit a codebase by myself, maybe I would not feel this way. But with regards to professional team development on a large code base, the ship has sailed on dynamic languages.
  - pjmlp 13y ago
    I fully agree. Dynamic languages don't scale on the typical enterprise Fortune 500 with three development sites and 50+ developers, as an example of the typical project sizes I work on. The main reasons tend to be: - Lack of unit testing, yes even in 2013 most enterprise managers would rather that time is spent on "real" coding - Massive code size, hard to navigate with just grep/find - Skill set varies too much across teams, specially if seen as cogs
sprash 13y ago
Dynamic typing has advantages and disadvantages. E.g. Static typing violates the DRY ("Don't repeat yourself") principle concerning code reuse whereas compile time type checking reduces the effort for testing (but for very simple cases only).
- asdasf 13y ago
  >Static typing violates the DRY ("Don't repeat yourself") principle concerning code reuse How did you come to that conclusion? I can't see any way that static typing "violates" DRY.
  - foobarbazqux 13y ago
    I think it's because you're declaring the type, which is obvious from context, when you could save characters and have the runtime system figure it out for you.
    - asdasf 13y ago
      That isn't an issue of static typing, it is an issue of explicit typing. I program in a statically typed language. When I don't feel something warrants a type signature, I simply don't write one. Type signatures are compiler enforced documentation.
      - foobarbazqux 13y ago
        Sometimes type declarations are required for disambiguation in statically typed languages, no? The 'auto' keyword in C++ doesn't always work. Anyway, I believe this is the source of the DRY claim.
        Peaker 13y ago
        In Haskell, for example, you only need type declarations for disambiguation when the information is actually missing from the program. That is, if the program were dynamic, you'd also need to write that down. For example, the type of: show . read is ambiguous, because "read" parses a String into some "Readable" type, and "show" converts a "Showable" type into a String. Which type? It could be anything, so the compile complains it is an ambiguous type. You could say something like: (show :: MyType -> String) . read To resolve the ambiguity. In a dynamic language, a function like "read" is not possible at all, since it uses static types to determine which type to parse into. So in Python, this would look like: lambda x: MyType.parse(x).show() Same information, same DRY violation/non-violation. Note that in some other cases, where the type can be determined, I can write: [1, 2, read "3", 4] Whereas in a dynamic language I'd need: [1, 2, Int.parse("3"), 4] So it is actually dynamic typing that violates DRY here.
el_bhs 13y ago
@dvt, this is the OP here. I was hoping that those who already agree with me about dynamic languages would come to understand that Go is different in this respect. I did a lousy (i.e., nonexistent) job making a case to those who don't agree with me [yet! :)] about dynamic languages, though. I will write a followup post later this week about the long-term maintenance problems associated with languages in the python/ruby/javascript family. I don't think they're "bad" (I was known to advocate for python in certain situations when I was at Google), but they're often inappropriate, and it is my sense that many developers haven't had the requisite large-dynamic-language-project trauma yet to understand that from firsthand experience. (The toughest part about those traumas is that they happen so late in a project's lifecycle that there's no quick way back to safety...) So I will try to make that case in a future post. Thanks for your thoughts.
- Peaker 13y ago
  Dynamic languages work out great when code coverage is ~100% at every run, and runs are short. Virtually all programs start out that way, so dynamic languages feel great. As they grow, the pain creeps in very slowly. As you said, by the time the programmer realizes he's in hell, it's too late to fix it.
  - el_bhs 13y ago
    Exactly. With proper discipline and true 100% test coverage, dynamic languages work well. But over time, that ideal is a challenge for most software organizations to actually live by. Or that's been my experience... it's one of those theory vs. practice situations.
  - stcredzero 13y ago
    > by the time the programmer realizes he's in hell, it's too late to fix it. From what I've seen, it's more that management doesn't want to take resources from fighting fires to move some gasoline. A disciplined group can even take rat's nest code and whip it into shape: but only if management is clueful enough to make that a priority. Usually, they're making decisions on a short-term basis.
- 13y ago
asdasf 13y ago
I think go does have a niche, and it is "python/ruby devs". Yes, its niche is a set of people, not a particular role. Because go is so simple for a typeless developer to learn, and has essentially no downsides and a massive upside (performance) compared to python and ruby, I see a lot of ruby and python devs upgrading to go. I also think you are being unfair to D. D is basically just what go initially claimed to be: a new systems language. D is a fantastic replacement for C++, go doesn't really enter the world C++ lives in.
- stcredzero 13y ago
  > Because go is so simple for a typeless developer to learn, and has essentially no downsides and a massive upside (performance) compared to python and ruby I think that's a brilliant observation! It's all of the duck typing goodness with far less of the static typing overhead. It's static types "lite" for duck typing lovers.

by dvt 13y ago

pron 13y ago

I share the sentiment. People often mention that Go is less verbose than Java like they were talking about Clojure or something. Go is just a little less verbose than Java (other than in a hello world example), and targets the same conceptual "level" (same order of abstractions, same "distance" from the metal, although Java can get closer to metal than Go). So, sure, it feels a little more modern in some respects (and less modern in others), but when considering both languages carefully, I find I really need a magnifying to tell the two apart. If Go had offered everything that Java does, I still wouldn't have had a compelling reason to switch because the differences are just too small. But Go doesn't offer everything Java does. Like you said, Java's ecosystem dwarfs Go's. Java has dynamic linking, runtime code instrumentation, unparalleled tooling, and better performance than Go. The only advantage I see Go has over Java is a shorter startup time, which makes it a reasonable choice for writing command-line programs. As for concurrency constructs, Java is far more flexible than Go, and because goroutines and channels are easy, I've ported them to Java[1] (and Clojure). Go sure is easy to get started with, but it would have to be 20 times better than it is to make me give up the JVM. In reality, it's just a recent, beginner-friendly Java without the awesomeness of the JVM. (P.S. I'm not sure Java's often mocked factory-factories aren't simply a result of the huge number of multi-million LOC programs that have been written in Java. It's just experience, and Go sure doesn't have the necessary abstractions to make engineering large systems any easier. Other recent languages -- sure -- but not Go) [1] https://github.com/puniverse/quasar https://github.com/puniverse/quasar

dvt 13y ago
With cgo, Go can get "just as close" to the metal too. But I don't even think a cgo vs. JNI benchmark would be substantive. Most people don't use a "medium-"level programming language to write low-level code, anyway. Like you say, Java is barely less verbose and arguably just as powerful as Go with many more times over the documentation and resources.
- pron 13y ago
  Oh, I would say Java is much, much more powerful than Go. Other than dynamic code loading and runtime instrumentation, even when it comes to concurrency you have your choice of schedulers and control over OS threads.
  - dvt 13y ago
    I agree, but I think fans of Go would not :P Hence my tentative "arguably."
jeremyjh 13y ago
You have "ported" a green threads implementation for Java? I'd really like to know more about that.
- pron 13y ago
  I call them fibers. Or lightweight threads. They're like Erlang processes or goroutines. You can read more about it here: http://blog.paralleluniverse.co/post/49445260575/quasar-pulsar http://blog.paralleluniverse.co/post/49445260575/quasar-puls... The library is very much in active development.
  - dvt 13y ago
    You mention Kilim (but perhaps not in a very good light)! Very cool. To be honest, I was surprised what you could do with Kilim (and the awesome robustness of the system). Unfortunately, I don't think Kilim has been updated for ASM 4.0 -- your library looks interesting though, I will certainly take a look at it.

fixxer 13y ago

> There are magnitudes more libraries and resources available for Python/Ruby/JS/Java Those languages have been out longer. I think Go will get there. EDIT: cgo dramatically expands the libraries. I hear a lot of people say "Go doesn't have X", but if X is already implemented in C (assuming some conditions are met), then you need not reinvent the wheel. I've been using Go as a concurrent parent over C functions for my geospatial research... really nice fit when you need to do 100 gigs worth of XYZ coordinate transforms.

dvt 13y ago
I guess my extended argument is -- okay, so Go will get there eventually (I'll concede that) -- but then what? IMO, Go will still not be attractive enough to warrant a major migration. cgo is interesting, but we already have a Java analog - the JNI.
- freyr 13y ago
  > Go will still not be attractive enough to warrant a major migration One of pron's concessions above is that Go is much easier to learn. That could be its killer feature: a new generation of developers and founders may choose to use Go for their projects because of the lower barrier to entry. A common theme with these write-ups is that the developer felt comfortable with Go after about a week. That's pretty incredible. I had the same experience. Coming from a scientific computing background, I wanted to get my feet wet with a an application level or system level language. I chose Go, and I felt like I was off and running in about a week. I've since looked at Java, and I'd rather not get involved with it unless absolutely necessary. If that turns out to be the experience of many others, it won't be a matter of migration. It'll be a matter of growth from the ground level.
  - pron 13y ago
    That is a good point, and it just might be that way, but I'm not so sure for several reasons. First, languages like Python and Ruby (and I think Clojure, too) are as easy to learn and Go, and most would say are more productive. And if you want a system level language, then you're probably not a beginner. Yes, Go is easier to learn than Java, but certainly not by much (it is, granted, much easier to get a small program running in Go). On the other hand, Java (or Kotlin) are more versatile. Someone once said that easy always wins, and this might be the case with a system level language, too, but maybe when people specifically look for power then easy is not their top priority? I don't know.

danieldk 13y ago

This claim: [...] -- is unfounded. Actually, most of that enumeration consists of shallow clichés. For instance, take the description of Java: Java: too verbose, Having written a fair share of Go and Java code, I have to say that difference is not all that profound. The usual boilerplate that people come up with is the construction of a BufferedReader/Writer. But Go has its share of boilerplate as well (e.g. error handling). Java currently has the advantage that IDEs can quickly generate whatever boilerplate is necessary. Given that Go is easy to parse and has a simple module system, there'll probably fairly complete IDEs for Go as well. too many FactoryFactories That very much depends on what libraries or frameworks you use. I have written lots of ML and NLP code in Java the last half year or so. I can count the number of insane 'FactoryBuilderProxy'-like classes that I encountered on one hand. Wait a bit and the architecture astronauts will also be writing Go packages ;).

stcredzero 13y ago
> Actually, most of that enumeration consists of shallow clichés. You can apply this to most of the writing about programming languages out there. My view might be skewed on HN, but it seems like the majority of this stuff is put out by programmers trying to promote themselves.

ionforce 13y ago

It's weird. You mention that the claim is unfounded, and then you have all this text that follows, but none of it seems related to supporting your point. How is the claim that [X at large is difficult to maintain] unfounded? I happen to agree. I am (was?) a Perl/JavaScript developer. I find both to be sorely lacking at a certain size. And by extension I assume Python and Ruby to be the exact same (under the shared umbrella of lacking static type safety).

davesims 13y ago

I was about to post the exact same comment, with the above quote from OP in my clipboard. In my experience, this claim is made by (many times really good, experienced, intelligent) coders who have a lot of previous experience in static typing and aren't comfortable -- either because of a lack of time and sheer LOC, or because of some mental block they've doubled-down on ("where's my 'extract method' menu option???") with the techniques and peculiar challenges of dynamic type refactorings. I work on a very large application/system of applications in a dynamic environment, and I've never encountered refactoring or maintenance issues that I thought would have been any easier in my previous life, 10 yrs in static typing. The other thing to keep in mind is that -- at least when comparing something like, for instance Rails to Java, there will be a lot less code, and this is a significant contribution to code management. That factor, plus just experience and acclimation to the techniques for dynamic-type editing/replacing/finding/greping and so on, plus solid TDD practices -- maintenance has never been an issue for me, and I've had a decent amount of time in large codebases in both dynamic and static environments.

ionforce 13y ago
With a static language, you get more with less. If you didn't have any testing framework, the compiler would tell you where you messed up. So, there's that, barring "well you should have had testing code to begin with". Grepping is ghetto, second-class. Whereas an IDE with built-in refactorings has a much higher guarantee of hitting the right artifacts, especially with shared substring collision. Again, barring "well you should have named things better". Having spent the majority of my career as dynamic and now a recent convert to static, I fail to see the allure of dynamic languages at a certain scale. You can shoot yourself in any language, but I think it is easier and safer to crawl out of a static mess than it is a dynamic one. And, I would argue the majority of applications do not demand the level of dynamism that dynamic languages are capable of, making it a waste.
- masklinn 13y ago
  > Grepping is ghetto, second-class. Whereas an IDE with built-in refactorings has a much higher guarantee of hitting the right artifacts, especially with shared substring collision. Of course that only works when the tooling exists, which for instance it does not for Go but does for Python. Doesn't for Haskell but does for Ruby (Jetbrains has done a pretty good job there).

btilly 13y ago

This claim: "Python/Ruby/Javascript: my experience is that large systems are difficult to maintain in these languages, as the dynamic typing makes it difficult to refactor large codebases without introducing errors in poorly tested areas of a repository" -- is unfounded. Not necessarily unfounded, you simply don't have access to data on it. I am not at liberty to share details, but I have in fact seen data from a large company based on many internal projects that found that initial development was faster but long-term maintenance costs were much higher for stuff written in dynamic languages like Python and Ruby than in static languages like Java and C++. The cost difference was both large and real. As someone who mostly does dynamic languages I didn't like the conclusion, but I couldn't argue with the numbers.

stcredzero 13y ago
> I have in fact seen data from a large company based on many internal projects that found that initial development was faster but long-term maintenance costs were much higher for stuff written in dynamic languages like Python and Ruby than in static languages like Java and C++. A big part of this is the shortsightedness of the companies themselves. There are steps you can take to ensure that you can manage types in dynamic languages. Very often, companies simply don't take these steps. It's not programmers that need babysitting by tools. It's big enterprise.
- pron 13y ago
  > It's not programmers that need babysitting by tools. It's big enterprise. If one language is easier for "big enterprise" to maintain than another, then what's the problem? Obviously different languages have different strengths.
  - steveklabnik 13y ago
    The claim 'big enterprise is better served by a statically typed language' is a different claim than 'dynamically typed languages cannot be used for large projects.'

burntsushi 13y ago

> This claim: "Python/Ruby/Javascript: my experience is that large systems are difficult to maintain in these languages, as the dynamic typing makes it difficult to refactor large codebases without introducing errors in poorly tested areas of a repository" -- is unfounded. Why is it unfounded? The author clearly qualifies his claim with "my experience". That's my experience too. I wouldn't extrapolate it to all programmers and in all scenarios, but dynamic typing just has never worked that well for me in larger projects. It could be because I'm not as diligent about writing unit tests or it could be because I'm not intelligent enough to reason about large amounts of code without static types. Regardless of whether it is, it's my experience and it certainly isn't "unfounded."

ionforce 13y ago
I don't think reasoning about types is a matter of intelligence. I happen to share your experience. It is more of a cognitive burden, exacerbated by less diligent coworkers. No amount of "convention within dynamism" can compete with first class compile time type safety. If I were to babysit a codebase by myself, maybe I would not feel this way. But with regards to professional team development on a large code base, the ship has sailed on dynamic languages.
- pjmlp 13y ago
  I fully agree. Dynamic languages don't scale on the typical enterprise Fortune 500 with three development sites and 50+ developers, as an example of the typical project sizes I work on. The main reasons tend to be: - Lack of unit testing, yes even in 2013 most enterprise managers would rather that time is spent on "real" coding - Massive code size, hard to navigate with just grep/find - Skill set varies too much across teams, specially if seen as cogs

sprash 13y ago

Dynamic typing has advantages and disadvantages. E.g. Static typing violates the DRY ("Don't repeat yourself") principle concerning code reuse whereas compile time type checking reduces the effort for testing (but for very simple cases only).

asdasf 13y ago
>Static typing violates the DRY ("Don't repeat yourself") principle concerning code reuse How did you come to that conclusion? I can't see any way that static typing "violates" DRY.
- foobarbazqux 13y ago
  I think it's because you're declaring the type, which is obvious from context, when you could save characters and have the runtime system figure it out for you.
  - asdasf 13y ago
    That isn't an issue of static typing, it is an issue of explicit typing. I program in a statically typed language. When I don't feel something warrants a type signature, I simply don't write one. Type signatures are compiler enforced documentation.
    - foobarbazqux 13y ago
      Sometimes type declarations are required for disambiguation in statically typed languages, no? The 'auto' keyword in C++ doesn't always work. Anyway, I believe this is the source of the DRY claim.
      - Peaker 13y ago
        In Haskell, for example, you only need type declarations for disambiguation when the information is actually missing from the program. That is, if the program were dynamic, you'd also need to write that down. For example, the type of: show . read is ambiguous, because "read" parses a String into some "Readable" type, and "show" converts a "Showable" type into a String. Which type? It could be anything, so the compile complains it is an ambiguous type. You could say something like: (show :: MyType -> String) . read To resolve the ambiguity. In a dynamic language, a function like "read" is not possible at all, since it uses static types to determine which type to parse into. So in Python, this would look like: lambda x: MyType.parse(x).show() Same information, same DRY violation/non-violation. Note that in some other cases, where the type can be determined, I can write: [1, 2, read "3", 4] Whereas in a dynamic language I'd need: [1, 2, Int.parse("3"), 4] So it is actually dynamic typing that violates DRY here.

el_bhs 13y ago

@dvt, this is the OP here. I was hoping that those who already agree with me about dynamic languages would come to understand that Go is different in this respect. I did a lousy (i.e., nonexistent) job making a case to those who don't agree with me [yet! :)] about dynamic languages, though. I will write a followup post later this week about the long-term maintenance problems associated with languages in the python/ruby/javascript family. I don't think they're "bad" (I was known to advocate for python in certain situations when I was at Google), but they're often inappropriate, and it is my sense that many developers haven't had the requisite large-dynamic-language-project trauma yet to understand that from firsthand experience. (The toughest part about those traumas is that they happen so late in a project's lifecycle that there's no quick way back to safety...) So I will try to make that case in a future post. Thanks for your thoughts.

Peaker 13y ago
Dynamic languages work out great when code coverage is ~100% at every run, and runs are short. Virtually all programs start out that way, so dynamic languages feel great. As they grow, the pain creeps in very slowly. As you said, by the time the programmer realizes he's in hell, it's too late to fix it.
- el_bhs 13y ago
  Exactly. With proper discipline and true 100% test coverage, dynamic languages work well. But over time, that ideal is a challenge for most software organizations to actually live by. Or that's been my experience... it's one of those theory vs. practice situations.
- stcredzero 13y ago
  > by the time the programmer realizes he's in hell, it's too late to fix it. From what I've seen, it's more that management doesn't want to take resources from fighting fires to move some gasoline. A disciplined group can even take rat's nest code and whip it into shape: but only if management is clueful enough to make that a priority. Usually, they're making decisions on a short-term basis.
13y ago

asdasf 13y ago

I think go does have a niche, and it is "python/ruby devs". Yes, its niche is a set of people, not a particular role. Because go is so simple for a typeless developer to learn, and has essentially no downsides and a massive upside (performance) compared to python and ruby, I see a lot of ruby and python devs upgrading to go. I also think you are being unfair to D. D is basically just what go initially claimed to be: a new systems language. D is a fantastic replacement for C++, go doesn't really enter the world C++ lives in.

stcredzero 13y ago
> Because go is so simple for a typeless developer to learn, and has essentially no downsides and a massive upside (performance) compared to python and ruby I think that's a brilliant observation! It's all of the duck typing goodness with far less of the static typing overhead. It's static types "lite" for duck typing lovers.