3 ms·

The implication is pretty clear: If you're able to not make such silly mistakes and enjoy the power and expression of a dynamic language, then use th

The implication is pretty clear: If you're **able to not make such silly mistakes** and enjoy the power and expression of a dynamic language, then use them, you won't miss types much at all. If you **pay attention to what you're writing**, you don't make such silly mistakes often. Bolting a home-brew type system on a dynamic language just seems rather pointless, if you need it, **you're not really ready to be using a dynamic language.** As an intelligent software engineer I do pay attention to the code that I write and have come to the conclusion that advanced type systems, as a tool for writing concise and correct code, provides me with an overall win. Your mileage may vary. That said, I'd be very willing to bet that a Ruby type checker/static analyzer will find bugs (some of them serious) in your codebase, despite pervasive unit tests. That has certainly been my experience with Python+pylint, and Erlang+dialyzer.

gnaritas 17y ago
No offense was meant though I see how you could take it that way. The difference lies in what type system we're talking about. You're talking about powerful type systems, I'm talking about most type systems. The kinds of mistakes a Java'ish type system prevents you from making are fairly trivial; we're not talking about Haskell here where type system can actually encode most of the biz rules. The home brew system being bolted onto Ruby here is not a powerful type system, it only prevents trivial mistakes that are easily avoided by most who like and use dynamic languages to begin with. Static type advocates are always telling us about all the mistakes their type systems prevent, and then go on to describe scenario after scenario that we just don't actually run into. They're solving problems that really just aren't problems for us. They seem to really believe you can't write a correct program without such a system, but experience tells me otherwise because I do it all the time. I'm not against static typing, I'm against thinking it's the only approach that works; it isn't. When I said you're not ready to be using a dynamic language I wasn't implying they're better, only that your mindset wasn't ready, it's a different style of programming and you can't do it thinking about types all the time. If a type system seems important to someone, they shouldn't be using a dynamic language in the first place and trying to fix it. There are things I do in Smalltalk that I simply wouldn't or couldn't attempt in C# and I have to adjust my programming style when switching between the two. However, there are things I do in C# that I don't do in Smalltalk like overloading that take advantage of the type system more. Overall, I find the Smalltalk experience superior for me because of things like real meta-classes and #doesNotUnderstand: and the superior development environment that simply let me get more work done with less and simpler code and a runtime system that frees me from the compile/run/debug cycle.

The implication is pretty clear: If you're **able to not make such silly mistakes** and enjoy the power and expression of a dynamic language, then use th

gnaritas 17y ago

No offense was meant though I see how you could take it that way. The difference lies in what type system we're talking about. You're talking about powerful type systems, I'm talking about most type systems. The kinds of mistakes a Java'ish type system prevents you from making are fairly trivial; we're not talking about Haskell here where type system can actually encode most of the biz rules. The home brew system being bolted onto Ruby here is not a powerful type system, it only prevents trivial mistakes that are easily avoided by most who like and use dynamic languages to begin with. Static type advocates are always telling us about all the mistakes their type systems prevent, and then go on to describe scenario after scenario that we just don't actually run into. They're solving problems that really just aren't problems for us. They seem to really believe you can't write a correct program without such a system, but experience tells me otherwise because I do it all the time. I'm not against static typing, I'm against thinking it's the only approach that works; it isn't. When I said you're not ready to be using a dynamic language I wasn't implying they're better, only that your mindset wasn't ready, it's a different style of programming and you can't do it thinking about types all the time. If a type system seems important to someone, they shouldn't be using a dynamic language in the first place and trying to fix it. There are things I do in Smalltalk that I simply wouldn't or couldn't attempt in C# and I have to adjust my programming style when switching between the two. However, there are things I do in C# that I don't do in Smalltalk like overloading that take advantage of the type system more. Overall, I find the Smalltalk experience superior for me because of things like real meta-classes and #doesNotUnderstand: and the superior development environment that simply let me get more work done with less and simpler code and a runtime system that frees me from the compile/run/debug cycle.