5 ms·

If you're a new programmer, remember that most programmers aren't trying to figure this out. They're already substantially invested in the language they chose

by drblast 16y ago

If you're a new programmer, remember that most programmers aren't trying to figure this out. They're already substantially invested in the language they chose years ago, with a large base of knowledge and already written code. Static vs. dynamic typing is nearly orthogonal to my programming language choice. Much more important to me are functional features. And all other things being equal, I'd rather have the flexibility of the dynamic languages than the performance and compiler-checking of static ones. Haskell has some killer features that make me want to use it more. Static types are not on the list. Maybe it's because all of my projects are small and I don't have to program defensively, but I've never been bitten by a type error that took anywhere near as long to fix than I would have spent using a static type system. I'm sure in some circumstances there are dynamic language projects that are plagued by type errors, but in my case static typing is a solution looking for a problem.

gclaramunt 16y ago
I wonder what features do you like from Haskell, as everything seems to be tied to its type system
- drblast 16y ago
  I've only written a few small programs in Haskell; one was a basic parser. The pattern matching syntax made a lot of things trivial to express that would require switch statements or if/else chains in just about any other language, so I loved that. Actually, once I got used to the function definition syntax, I like that too and felt it was very concise. I like the flexibility that strings are lists (arrays?) of characters, which was incredibly useful for implementing a parser. I'm sure that would come in handy in just about any project. The type system...eh. I did a bit of fighting with it which apparently is normal for newbies, and I can see the advantage of having it during the compilation stage from a performance perspective. It just didn't grab me by the collar like the other features did.
p4bl0 16y ago
+1 for "static typing is a solution looking for a problem".
- cageface 16y ago
  I don't think I can completely agree with this. There are tradeoffs and the issue isn't that simple. Dynamic typing is better than bad static typing but so far I'm finding my Scala code is every bit as expressive as Ruby and a lot easier to maintain.
  - KirinDave 16y ago
    Why is it easier to maintain? What specifically about static typing makes it easier to maintain?
    - cageface 16y ago
      I think it's three things: First, it's a lot easier to quickly figure out what a function does when it has a type signature. It's strongly self-documenting. Second, it's easier to figure out what kinds of datastructures are used in a program, because you can see the types of the variables and functions you're working with. For me understanding the underlying datatypes is a big help in getting to grips with a codebase. Third, the compiler catches a lot of dumb mistakes early. It's no substitute for testing, but a quick compile cycle will rule out a common class of errors and helps me make changes with more confidence. It's not all roses and there is a price to be paid but I do thing there's a strong benefit.
      - KirinDave 16y ago
        > First, it's a lot easier to quickly figure out what a function does when it has a type signature. It's strongly self-documenting. I submit to you that I can show just as many examples where the type signature is of no help. Self-documenting functions existing in all paradigms, and it is a stylistic choice rather than one enforced by any technical considerations. > Second, it's easier to figure out what kinds of datastructures are used in a program, because you can see the types of the variables and functions you're working with. For me understanding the underlying datatypes is a big help in getting to grips with a codebase. Interesting point. In languages like Ruby and Clojure, you tend to use a standardized set of highly-optimized and standard structures as opposed to using generics to spin out a lot of them. They tend to conform to high level protocols (interfaces) much like statically typed languages do. The flipside to this is that dynamic languages tend to have a lot more ease changing data structures down the road. > Third, the compiler catches a lot of dumb mistakes early. It's no substitute for testing, but a quick compile cycle will rule out a common class of errors and helps me make changes with more confidence. This is true, but I'd like to point out that lots of Lisp compilers already do this. They use optional static type inference for optimization and error checking but do not enforce those constraints, merely observe them and react to them. Personally, I think that's the best of both worlds.
Groxx 16y ago
>Maybe it's because all of my projects are small and I don't have to program defensively, but I've never been bitten by a type error that took anywhere near as long to fix than I would have spent using a static type system. One of my projects for school turned into a 9k LOC Ruby project. I had precisely zero errors during the entire development cycle that static typing would've detected. Meanwhile, attempting a bit of dynamic code in VB.Net recently resulted in easily a couple hours worth of total waste dodging types while not going totally type-less. And then there's the crappy lambdas and total lack of anonymous or inner functions, so you end up polluting your namespace massively in many cases. (stuck in 3.5 + VS 2008, 2010 adds those) Gah! I do occasionally miss IDE hinting, which is drop-dead easy in statically-typed languages. But dynamically typed languages allow such ridiculously simple APIs I find it's rarely necessary.
- shadowfox 16y ago
  Not to argue. 9K is comparatively small.
  - Groxx 16y ago
    As compared to a lot of commercial products, absolutely. But it was still a significantly larger project than I'd attempted before, and I probably ended up writing a good 30k or 40k through the whole time (attempting lots of new things). It's also still over 10x larger than the .Net project with which I've been fighting. And given my patterns of code, I see no reason why making my previous project 10x larger would have any more difficulties with typing than I had before. In a few years of Ruby coding, I can only recall a few immediately-identified type problems. Static typing seems to me to cost significantly more than its value.
  - gaius 16y ago
    You can get a lot done in 9 kLOC Ruby/Python/etc. Possibly 10x what you could get done in as much Java.
- Confusion 16y ago
  I had precisely zero errors during the entire development cycle that static typing would've detected. You never get a NoMethodError: undefined method `[]' for :foo:Symbol or similar? Then you are either a much better programmer than me, or we are dealing with confirmation bias[1]. I get such errors regularly. They are trivial to fix and are caught early by tests/specs, but they are still there on a first iteration. [1] http://en.wikipedia.org/wiki/Confirmation_bias http://en.wikipedia.org/wiki/Confirmation_bias

by drblast 16y ago

gclaramunt 16y ago

I wonder what features do you like from Haskell, as everything seems to be tied to its type system

drblast 16y ago
I've only written a few small programs in Haskell; one was a basic parser. The pattern matching syntax made a lot of things trivial to express that would require switch statements or if/else chains in just about any other language, so I loved that. Actually, once I got used to the function definition syntax, I like that too and felt it was very concise. I like the flexibility that strings are lists (arrays?) of characters, which was incredibly useful for implementing a parser. I'm sure that would come in handy in just about any project. The type system...eh. I did a bit of fighting with it which apparently is normal for newbies, and I can see the advantage of having it during the compilation stage from a performance perspective. It just didn't grab me by the collar like the other features did.

p4bl0 16y ago

+1 for "static typing is a solution looking for a problem".

cageface 16y ago
I don't think I can completely agree with this. There are tradeoffs and the issue isn't that simple. Dynamic typing is better than bad static typing but so far I'm finding my Scala code is every bit as expressive as Ruby and a lot easier to maintain.
- KirinDave 16y ago
  Why is it easier to maintain? What specifically about static typing makes it easier to maintain?
  - cageface 16y ago
    I think it's three things: First, it's a lot easier to quickly figure out what a function does when it has a type signature. It's strongly self-documenting. Second, it's easier to figure out what kinds of datastructures are used in a program, because you can see the types of the variables and functions you're working with. For me understanding the underlying datatypes is a big help in getting to grips with a codebase. Third, the compiler catches a lot of dumb mistakes early. It's no substitute for testing, but a quick compile cycle will rule out a common class of errors and helps me make changes with more confidence. It's not all roses and there is a price to be paid but I do thing there's a strong benefit.
    - KirinDave 16y ago
      > First, it's a lot easier to quickly figure out what a function does when it has a type signature. It's strongly self-documenting. I submit to you that I can show just as many examples where the type signature is of no help. Self-documenting functions existing in all paradigms, and it is a stylistic choice rather than one enforced by any technical considerations. > Second, it's easier to figure out what kinds of datastructures are used in a program, because you can see the types of the variables and functions you're working with. For me understanding the underlying datatypes is a big help in getting to grips with a codebase. Interesting point. In languages like Ruby and Clojure, you tend to use a standardized set of highly-optimized and standard structures as opposed to using generics to spin out a lot of them. They tend to conform to high level protocols (interfaces) much like statically typed languages do. The flipside to this is that dynamic languages tend to have a lot more ease changing data structures down the road. > Third, the compiler catches a lot of dumb mistakes early. It's no substitute for testing, but a quick compile cycle will rule out a common class of errors and helps me make changes with more confidence. This is true, but I'd like to point out that lots of Lisp compilers already do this. They use optional static type inference for optimization and error checking but do not enforce those constraints, merely observe them and react to them. Personally, I think that's the best of both worlds.

Groxx 16y ago

>Maybe it's because all of my projects are small and I don't have to program defensively, but I've never been bitten by a type error that took anywhere near as long to fix than I would have spent using a static type system. One of my projects for school turned into a 9k LOC Ruby project. I had precisely zero errors during the entire development cycle that static typing would've detected. Meanwhile, attempting a bit of dynamic code in VB.Net recently resulted in easily a couple hours worth of total waste dodging types while not going totally type-less. And then there's the crappy lambdas and total lack of anonymous or inner functions, so you end up polluting your namespace massively in many cases. (stuck in 3.5 + VS 2008, 2010 adds those) Gah! I do occasionally miss IDE hinting, which is drop-dead easy in statically-typed languages. But dynamically typed languages allow such ridiculously simple APIs I find it's rarely necessary.

shadowfox 16y ago
Not to argue. 9K is comparatively small.
- Groxx 16y ago
  As compared to a lot of commercial products, absolutely. But it was still a significantly larger project than I'd attempted before, and I probably ended up writing a good 30k or 40k through the whole time (attempting lots of new things). It's also still over 10x larger than the .Net project with which I've been fighting. And given my patterns of code, I see no reason why making my previous project 10x larger would have any more difficulties with typing than I had before. In a few years of Ruby coding, I can only recall a few immediately-identified type problems. Static typing seems to me to cost significantly more than its value.
- gaius 16y ago
  You can get a lot done in 9 kLOC Ruby/Python/etc. Possibly 10x what you could get done in as much Java.
Confusion 16y ago
I had precisely zero errors during the entire development cycle that static typing would've detected. You never get a NoMethodError: undefined method `[]' for :foo:Symbol or similar? Then you are either a much better programmer than me, or we are dealing with confirmation bias[1]. I get such errors regularly. They are trivial to fix and are caught early by tests/specs, but they are still there on a first iteration. [1] http://en.wikipedia.org/wiki/Confirmation_bias http://en.wikipedia.org/wiki/Confirmation_bias