8 ms·

And now have those 10k programmers work on a single project. I bet the 10000 Ruby guys are gonna create a big, unmaintainable, broken mess. Even Java's primiti

by pka 10y ago

And now have those 10k programmers work on a single project. I bet the 10000 Ruby guys are gonna create a big, unmaintainable, broken mess. Even Java's primitive type system would be a big help when it's about software development at scale. Yes yes, TDD :)

twblalock 10y ago
This is a big advantage of static typing that people miss -- the restrictions it puts on developers help them to learn the codebase they are working with. In the real world, where engineers contribute to existing codebases more often than they start projects from scratch, this is a pretty important benefit.
- majewsky 10y ago
  A thousand times this. When I was assigned to an existing Ruby on Rails project of about 30 kLOC, I needed around a month to get productive because it was nearly impossible to follow calls around the system because of auto-generated, not properly typed methods all over the place.
krisdol 10y ago
I felt like I spent roughly the same amount of time working around Java's type system with copious amounts of boilerplate as I did fixing wrapping my head around type-related bugs in ruby, especially at scale because of how inflexible every Java architecture seems to become after 5 years. Java's types give you so, so little additional real world "safety" but easily require 10x the verbosity to express the same logic as a dynamic language. You still end up getting hit with null pointers and invalid argument errors. I think Rust and Swift and Elm strike the right balance between developer productivity and a strict type system that actually improves the quality of production software.
- twblalock 10y ago
  > You still end up getting hit with null pointers and invalid argument errors. Those are not the kinds of problems a type system is intended to solve. Those are problems of data, not of types. The amount of boilerplate in a Java program is pretty low if you aren't trying to abuse or work around the type system. It certainly is not 10x what you end up with in Ruby or Python. Java 8 has made significant improvements, but it wasn't that bad before in many cases. Instead of trying to work around Java's type safety, you should learn to use it properly. Good programmers think about types whether or not they are forced to by the language, so the restrictions imposed by Java should not be burdensome -- in general, you should already be mentally applying some of those restrictions to your code so you can avoid passing the wrong types around.
  - hibikir 10y ago
    They are problems type systems are intended to solve: It just happens that Java's is too weak to deal with it well: They best you can do is use an option type, but even then, Java's Option type is far weaker than in other languages. Languages where null doesn't exist are far nicer. Java's boilerplate comes from lacking type inference and from having a type system that is too weak, not one that is too strong: I'd argue that people's love for dynamic languages without type systems is cause by how people's idea of what types are, and what they do for you, come from Java and old C++, as opposed to something more powerful.
    - jay-anderson 10y ago
      http://types.cs.washington.edu/checker-framework/ http://types.cs.washington.edu/checker-framework/ - there is work going on in the java world to deal with nulls in the type system.
    - twblalock 10y ago
      Nulls are not a problem type systems are intended to solve -- they are a feature of type systems that was created on purpose. You might not like them, but that doesn't mean they constitute an oversight or omission on the part of the designers of the type system -- they wanted them there. They are useful. Many people misunderstand the option type in Java. It was created to make stream processing easier. It was not intended for general use, as in other languages. Regarding illegal arguments, they are unavoidable in any type system. Suppose you defined a function that splits a string into an array of n-grams, to which you pass the string as well as int n. If you pass an n which is greater than the length of the string, no type system will help you figure out what to do. It's just an invalid/illegal argument, and you will either have to decide what to return for that case (maybe an empty array, or even... null), or throw some kind of exception.
      - Decade 10y ago
        The inventor of the null pointer considers them to be a mistake: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare https://www.infoq.com/presentations/Null-References-The-Bill...
xentronium 10y ago
Maintainability is tricky to measure and tricky to achieve. My experience is it's more dependent on proper management, processes, discipline than on language traits, however, I agree that it's much easier to shoot yourself in the foot using highly expressive languages.

by pka 10y ago

twblalock 10y ago

This is a big advantage of static typing that people miss -- the restrictions it puts on developers help them to learn the codebase they are working with. In the real world, where engineers contribute to existing codebases more often than they start projects from scratch, this is a pretty important benefit.

majewsky 10y ago
A thousand times this. When I was assigned to an existing Ruby on Rails project of about 30 kLOC, I needed around a month to get productive because it was nearly impossible to follow calls around the system because of auto-generated, not properly typed methods all over the place.

krisdol 10y ago

I felt like I spent roughly the same amount of time working around Java's type system with copious amounts of boilerplate as I did fixing wrapping my head around type-related bugs in ruby, especially at scale because of how inflexible every Java architecture seems to become after 5 years. Java's types give you so, so little additional real world "safety" but easily require 10x the verbosity to express the same logic as a dynamic language. You still end up getting hit with null pointers and invalid argument errors. I think Rust and Swift and Elm strike the right balance between developer productivity and a strict type system that actually improves the quality of production software.

twblalock 10y ago
> You still end up getting hit with null pointers and invalid argument errors. Those are not the kinds of problems a type system is intended to solve. Those are problems of data, not of types. The amount of boilerplate in a Java program is pretty low if you aren't trying to abuse or work around the type system. It certainly is not 10x what you end up with in Ruby or Python. Java 8 has made significant improvements, but it wasn't that bad before in many cases. Instead of trying to work around Java's type safety, you should learn to use it properly. Good programmers think about types whether or not they are forced to by the language, so the restrictions imposed by Java should not be burdensome -- in general, you should already be mentally applying some of those restrictions to your code so you can avoid passing the wrong types around.
- hibikir 10y ago
  They are problems type systems are intended to solve: It just happens that Java's is too weak to deal with it well: They best you can do is use an option type, but even then, Java's Option type is far weaker than in other languages. Languages where null doesn't exist are far nicer. Java's boilerplate comes from lacking type inference and from having a type system that is too weak, not one that is too strong: I'd argue that people's love for dynamic languages without type systems is cause by how people's idea of what types are, and what they do for you, come from Java and old C++, as opposed to something more powerful.
  - jay-anderson 10y ago
    http://types.cs.washington.edu/checker-framework/ http://types.cs.washington.edu/checker-framework/ - there is work going on in the java world to deal with nulls in the type system.
  - twblalock 10y ago
    Nulls are not a problem type systems are intended to solve -- they are a feature of type systems that was created on purpose. You might not like them, but that doesn't mean they constitute an oversight or omission on the part of the designers of the type system -- they wanted them there. They are useful. Many people misunderstand the option type in Java. It was created to make stream processing easier. It was not intended for general use, as in other languages. Regarding illegal arguments, they are unavoidable in any type system. Suppose you defined a function that splits a string into an array of n-grams, to which you pass the string as well as int n. If you pass an n which is greater than the length of the string, no type system will help you figure out what to do. It's just an invalid/illegal argument, and you will either have to decide what to return for that case (maybe an empty array, or even... null), or throw some kind of exception.
    - Decade 10y ago
      The inventor of the null pointer considers them to be a mistake: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare https://www.infoq.com/presentations/Null-References-The-Bill...

xentronium 10y ago

Maintainability is tricky to measure and tricky to achieve. My experience is it's more dependent on proper management, processes, discipline than on language traits, however, I agree that it's much easier to shoot yourself in the foot using highly expressive languages.