5 ms·

The same can be said for any statically typed language. Any language that binds types as late as possible is infinitely more enjoyable to work with than one tha

by ddkrone 16y ago

The same can be said for any statically typed language. Any language that binds types as late as possible is infinitely more enjoyable to work with than one that fixes types at compile time. Short of developing missile guidance systems I don't think static types are warranted for anything.

DougBTX 16y ago
For me type inference changes the picture, since it reduces the duplication you see throughout Java-style statically typed code, but doesn't give up all the benefits.
- ddkrone 16y ago
  The only benefit I'm aware of is slightly faster code and even then the dynamic version is almost always more readable and easier to maintain and refactor. The ideal would be a dynamic language with optional static typing but I have yet to see a language like that.
  - SapphireSun 16y ago
    Perl 6? http://en.wikipedia.org/wiki/Perl_6 http://en.wikipedia.org/wiki/Perl_6
  - siika2000 16y ago
    > The ideal would be a dynamic language with optional static typing but I have yet to see a language like that. That would be Common Lisp.
    - davidk0101 16y ago
      I'm waiting for perl 6.
    - stcredzero 16y ago
      That would be Common Lisp. There was such a version of Smalltalk called Strongtalk, but it never got a community behind it.
      - igouy 16y ago
        Actually - "but then the Java phenomenon happened and we eventually had to switch to Java before ever releasing it". http://www.strongtalk.org/history.html http://www.strongtalk.org/history.html
  - overgard 16y ago
    "slightly faster" is a bit understated, you're usually talking about statically typed languages being an order of a magnitude faster for things that are computationally expensive. Granted most things aren't, so for a web page or whatnot, it probably doesn't matter; and certainly the expressive ability you gain from dynamic languages might be worth the trade off. But the trade off is undeniably there. (Try comparing various languages here: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=python&lang2=gcc http://shootout.alioth.debian.org/u32/benchmark.php?test=all... if you don't believe me) Some dynamically typed languages can approach the speed of static languages, like Lisp, but they generally do that by introducing voluntary static typing hints, or having a JIT compiler introduce speculative code paths that guess the types coming in after some analysis.
  - kanak 16y ago
    You should look into typed racket.
- gnosis 16y ago
  The main thing that make programming in statically typed languages painful isn't the additional type declarations (which, as you rightly point out, need not even exist in languages that do competent type inference), but with the constant need to wrestle with the type system to get your code to compile at all. This is made doubly painful by the incredibly obtuse error messages spat out by some compilers, like: This expression has type ((int * int) * string * string * channel) list but is here used with type ((int * int) * string * string * channel) list or even more baroque and confusing monstrosities. Programming in OCaml made me feel like I'd need to take years of type theory classes in order to feel really comfortable in the language. In comparison, programming in Lisp is a joy, and very easy. But, in defense of the modern statically typed languages like OCaml and Haskell, I'll have to admit that once you've finished wrestling with the type system and actually gotten your program to compile, you've probably eliminated whole classes of bugs that might still exist in a similar dynamically typed language program. Not to mention that it will save you the writing a ton of unit tests.
  - mquander 16y ago
    That's a very optimistic error message! error: conversion from std::_Rb_tree_const_iterator<std::pair< const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > to non-scalar type std::_Rb_tree_iterator<std::pair< const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > requested
  - shadowfox 16y ago
    Interestingly enough, the sort of error messages that you mention in OCaml occurs partly due to the inference itself. Because inference is essentially a unification between implicit constraints, once it finds an anomaly, the engine can't always predict correctly which among the conflicting constraints is the actual error from a user point of view. Anyway just an aside

by ddkrone 16y ago

DougBTX 16y ago

For me type inference changes the picture, since it reduces the duplication you see throughout Java-style statically typed code, but doesn't give up all the benefits.

ddkrone 16y ago
The only benefit I'm aware of is slightly faster code and even then the dynamic version is almost always more readable and easier to maintain and refactor. The ideal would be a dynamic language with optional static typing but I have yet to see a language like that.
- SapphireSun 16y ago
  Perl 6? http://en.wikipedia.org/wiki/Perl_6 http://en.wikipedia.org/wiki/Perl_6
- siika2000 16y ago
  > The ideal would be a dynamic language with optional static typing but I have yet to see a language like that. That would be Common Lisp.
  - davidk0101 16y ago
    I'm waiting for perl 6.
  - stcredzero 16y ago
    That would be Common Lisp. There was such a version of Smalltalk called Strongtalk, but it never got a community behind it.
    - igouy 16y ago
      Actually - "but then the Java phenomenon happened and we eventually had to switch to Java before ever releasing it". http://www.strongtalk.org/history.html http://www.strongtalk.org/history.html
- overgard 16y ago
  "slightly faster" is a bit understated, you're usually talking about statically typed languages being an order of a magnitude faster for things that are computationally expensive. Granted most things aren't, so for a web page or whatnot, it probably doesn't matter; and certainly the expressive ability you gain from dynamic languages might be worth the trade off. But the trade off is undeniably there. (Try comparing various languages here: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=python&lang2=gcc http://shootout.alioth.debian.org/u32/benchmark.php?test=all... if you don't believe me) Some dynamically typed languages can approach the speed of static languages, like Lisp, but they generally do that by introducing voluntary static typing hints, or having a JIT compiler introduce speculative code paths that guess the types coming in after some analysis.
- kanak 16y ago
  You should look into typed racket.
gnosis 16y ago
The main thing that make programming in statically typed languages painful isn't the additional type declarations (which, as you rightly point out, need not even exist in languages that do competent type inference), but with the constant need to wrestle with the type system to get your code to compile at all. This is made doubly painful by the incredibly obtuse error messages spat out by some compilers, like: This expression has type ((int * int) * string * string * channel) list but is here used with type ((int * int) * string * string * channel) list or even more baroque and confusing monstrosities. Programming in OCaml made me feel like I'd need to take years of type theory classes in order to feel really comfortable in the language. In comparison, programming in Lisp is a joy, and very easy. But, in defense of the modern statically typed languages like OCaml and Haskell, I'll have to admit that once you've finished wrestling with the type system and actually gotten your program to compile, you've probably eliminated whole classes of bugs that might still exist in a similar dynamically typed language program. Not to mention that it will save you the writing a ton of unit tests.
- mquander 16y ago
  That's a very optimistic error message! error: conversion from std::_Rb_tree_const_iterator<std::pair< const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > to non-scalar type std::_Rb_tree_iterator<std::pair< const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > requested
- shadowfox 16y ago
  Interestingly enough, the sort of error messages that you mention in OCaml occurs partly due to the inference itself. Because inference is essentially a unification between implicit constraints, once it finds an anomaly, the engine can't always predict correctly which among the conflicting constraints is the actual error from a user point of view. Anyway just an aside