3 ms·

Types for Ruby, types for JavaScript, types for Python. Why didn't we all just stick with Java?

by tootie 5y ago

ecshafer 5y ago
I've worked with Ruby + Sorbet, and also with Java. I would rather write Ruby + Sorbet than Java right now. Ruby is a really nice language. Though Java still has some great strengths, especially the 8+ functional programming features and the concurrency library is great. If I could use Rails with Java it might be a different story though, since I hate Spring.
- agotterer 5y ago
  You could use JRuby
  - zingar 5y ago
    JRuby is a really cool project! Unfortunately it's fairly far behind mainstream Ruby. They are still working on Ruby 2.7 compatibility, but Ruby 2.6 end-of-life is 2022/03/31 (tomorrow).
- zingar 5y ago
  I started my career in Java and although I loved IntelliJ and was perplexed by how poor RubyMine seemed by comparison (circa 2012) that's not enough for me to go back from Ruby to Java. What I'm realising now is that Java has (had?) a really clunky type system and that there are other languages that do types better, so I shouldn't use Java as my reason for avoiding them.
- tootie 5y ago
  If I put together my top ten language features it would include documentation (both for the core language but also the doc framework for coders), legible stack traces, tight IDE integration (this typically requires strong+strict typing), easy debugging, first class build tools for perfectly reproducible builds and dependency management, and easy version management. Java ticks all those boxes. In fact, I think the thing that launched Java in the first place was not nonsense like checked exceptions, it was javadoc. In terms of syntax and semantics, I've never felt any more or less comfortable coding in anything in the Algol family. Anyone who's been coding long enough knows that 98% of the complexity in building software is people. And anything that helps you understand other people's code is 10X more valuable than anything that helps you code faster.
xtracto 5y ago
Young people are coming around ... I used to write code in C, C++ then Java, C# (.NET v1). I could never understand how people could implement large systems with dynamically typed languages such as Ruby or Python. They are great for smallish scripts, but once your codebase (and team) grows, they become a nightmare to maintain. In my experience, large codebases of those types of languages have a lot of "magic" thing happen. There's a lot of implicit stuff that one has to guess or spend time "following the code" to understand what it is doing. And I say this after having built a major lending platform from scratch in Ruby, including a major Machine Learning scoring system in Python, having to maintain with a good sized payment system in pure JavaScript, and nowadays dealing with a major trading/liquidity system in Ruby. They are fun languages, but once the code and systems start to scale, static typing really helps. For that reason I've seen a lot of these endeavours try to move to TypeScript or other typed languages.
klibertp 5y ago
I was asked a version of this question by a colleague at work, namely: "if types are so great, why didn't Python/Ruby/JS include them from the start (ie. early '90s)?" That's because the theory of gradual type systems was only worked out in the '00s. Before that, you could have a static or dynamic type system, not anything in between. Common Lisp did have type annotations, but they were hints for optimization, without any guarantees. They were also local to subroutines only. Dylan[3] is an example of an early implementation of the idea, but Dylan was several years late and, without being able to compete with Java, died without ever being widely used. The proper theory was first established by J. Siek[1] and W. Taha in 2006. It's distinct from nominal static typing which uses a single top type (like Object in Java) or generics, and obviously it's different from both purely static and dynamic typing. It took almost a decade for the idea to start gaining practical implementations - I think the original was a made for Scheme, and one of the first implementations was Typed Scheme for PLT Scheme, which continues on as Typed Racket[2] today. Typed Racket is unique in that it enforces the types even on the untyped side, by wrapping values and exports in contracts. The idea proved to be useful in practice, and started being adopted in various (non-Scheme) dynamically typed languages, starting with TypeScript for JS and Hack for PHP. On the other hand, some statically typed languages also became gradually typed, most notably C#. The implementations continued to improve, shrinking the parts of their respective languages that could not be statically typed. In dynamic languages there are still features that cannot be practically expressed in static type systems - most metaprogramming and code generation falls into this category - but they are generally "good enough" for day to day coding. Gradual typing is useful in the same way static type systems are useful: it can prevent certain kinds of errors by marking known-invalid expressions without the need to run the code (so, for example, can help you find errors even in code that's not covered by tests); it helps in writing tooling for the language (eg. go to definition, find references); it helps make the code clearer for the reader (no need to break into a debugger to see what kind of value a given identifier refers to); in some implementations it may also help in optimizing the runtime performance, but that's rare. The "gradual" aspect makes it easier to adopt when the codebase grows larger - the bigger the codebase, the more useful static types are, but by the time the codebase grows large enough to justify static typing it's too big to rewrite in a different, statically typed language. In short: writing small projects or prototypes in a dynamically typed language is faster while maintenance and expansion of large projects is easier in statically typed one. Gradual typing lets you go from one to the other without a huge cost of a full rewrite. [1] https://wphomes.soic.indiana.edu/jsiek/what-is-gradual-typing/ https://wphomes.soic.indiana.edu/jsiek/what-is-gradual-typin... [2] https://docs.racket-lang.org/ts-reference/index.html https://docs.racket-lang.org/ts-reference/index.html [3] https://opendylan.org/index.html https://opendylan.org/index.html
rco8786 5y ago
It’s not like Java is the first or only language with types…
sethrin 5y ago
Why stick with Java when Crystal exists?
paxys 5y ago
Whether it has types or not isn't the only differentiating factor between languages
neilwilson 5y ago
Typing can be seen as just a way of creating automatically some unit tests you probably haven't bothered creating. Types are useful when they don't get in the way. As are method contracts.

Types for Ruby, types for JavaScript, types for Python. Why didn't we all just stick with Java?

by tootie 5y ago

Types for Ruby, types for JavaScript, types for Python. Why didn't we all just stick with Java?

I've worked with Ruby + Sorbet, and also with Java. I would rather write Ruby + Sorbet than Java right now. Ruby is a really nice language. Though Java still has some great strengths, especially the 8+ functional programming features and the concurrency library is great. If I could use Rails with Java it might be a different story though, since I hate Spring.

agotterer 5y ago
You could use JRuby
- zingar 5y ago
  JRuby is a really cool project! Unfortunately it's fairly far behind mainstream Ruby. They are still working on Ruby 2.7 compatibility, but Ruby 2.6 end-of-life is 2022/03/31 (tomorrow).
zingar 5y ago
I started my career in Java and although I loved IntelliJ and was perplexed by how poor RubyMine seemed by comparison (circa 2012) that's not enough for me to go back from Ruby to Java. What I'm realising now is that Java has (had?) a really clunky type system and that there are other languages that do types better, so I shouldn't use Java as my reason for avoiding them.
tootie 5y ago
If I put together my top ten language features it would include documentation (both for the core language but also the doc framework for coders), legible stack traces, tight IDE integration (this typically requires strong+strict typing), easy debugging, first class build tools for perfectly reproducible builds and dependency management, and easy version management. Java ticks all those boxes. In fact, I think the thing that launched Java in the first place was not nonsense like checked exceptions, it was javadoc. In terms of syntax and semantics, I've never felt any more or less comfortable coding in anything in the Algol family. Anyone who's been coding long enough knows that 98% of the complexity in building software is people. And anything that helps you understand other people's code is 10X more valuable than anything that helps you code faster.

xtracto 5y ago

Young people are coming around ... I used to write code in C, C++ then Java, C# (.NET v1). I could never understand how people could implement large systems with dynamically typed languages such as Ruby or Python. They are great for smallish scripts, but once your codebase (and team) grows, they become a nightmare to maintain. In my experience, large codebases of those types of languages have a lot of "magic" thing happen. There's a lot of implicit stuff that one has to guess or spend time "following the code" to understand what it is doing. And I say this after having built a major lending platform from scratch in Ruby, including a major Machine Learning scoring system in Python, having to maintain with a good sized payment system in pure JavaScript, and nowadays dealing with a major trading/liquidity system in Ruby. They are fun languages, but once the code and systems start to scale, static typing really helps. For that reason I've seen a lot of these endeavours try to move to TypeScript or other typed languages.

klibertp 5y ago

I was asked a version of this question by a colleague at work, namely: "if types are so great, why didn't Python/Ruby/JS include them from the start (ie. early '90s)?" That's because the theory of gradual type systems was only worked out in the '00s. Before that, you could have a static or dynamic type system, not anything in between. Common Lisp did have type annotations, but they were hints for optimization, without any guarantees. They were also local to subroutines only. Dylan[3] is an example of an early implementation of the idea, but Dylan was several years late and, without being able to compete with Java, died without ever being widely used. The proper theory was first established by J. Siek[1] and W. Taha in 2006. It's distinct from nominal static typing which uses a single top type (like Object in Java) or generics, and obviously it's different from both purely static and dynamic typing. It took almost a decade for the idea to start gaining practical implementations - I think the original was a made for Scheme, and one of the first implementations was Typed Scheme for PLT Scheme, which continues on as Typed Racket[2] today. Typed Racket is unique in that it enforces the types even on the untyped side, by wrapping values and exports in contracts. The idea proved to be useful in practice, and started being adopted in various (non-Scheme) dynamically typed languages, starting with TypeScript for JS and Hack for PHP. On the other hand, some statically typed languages also became gradually typed, most notably C#. The implementations continued to improve, shrinking the parts of their respective languages that could not be statically typed. In dynamic languages there are still features that cannot be practically expressed in static type systems - most metaprogramming and code generation falls into this category - but they are generally "good enough" for day to day coding. Gradual typing is useful in the same way static type systems are useful: it can prevent certain kinds of errors by marking known-invalid expressions without the need to run the code (so, for example, can help you find errors even in code that's not covered by tests); it helps in writing tooling for the language (eg. go to definition, find references); it helps make the code clearer for the reader (no need to break into a debugger to see what kind of value a given identifier refers to); in some implementations it may also help in optimizing the runtime performance, but that's rare. The "gradual" aspect makes it easier to adopt when the codebase grows larger - the bigger the codebase, the more useful static types are, but by the time the codebase grows large enough to justify static typing it's too big to rewrite in a different, statically typed language. In short: writing small projects or prototypes in a dynamically typed language is faster while maintenance and expansion of large projects is easier in statically typed one. Gradual typing lets you go from one to the other without a huge cost of a full rewrite. [1] https://wphomes.soic.indiana.edu/jsiek/what-is-gradual-typing/ https://wphomes.soic.indiana.edu/jsiek/what-is-gradual-typin... [2] https://docs.racket-lang.org/ts-reference/index.html https://docs.racket-lang.org/ts-reference/index.html [3] https://opendylan.org/index.html https://opendylan.org/index.html

rco8786 5y ago

It’s not like Java is the first or only language with types…

sethrin 5y ago

Why stick with Java when Crystal exists?

paxys 5y ago

Whether it has types or not isn't the only differentiating factor between languages

neilwilson 5y ago

Typing can be seen as just a way of creating automatically some unit tests you probably haven't bothered creating. Types are useful when they don't get in the way. As are method contracts.