Live data from Hacker News

Dynamic Languages are Unmaintainable

williamedwardscoder.tumblr.com

11–20 of 71 posts

Re: Dynamic Languages are Unmaintainable

#11
post #3

Earlier quoted context omitted.

Submitter here: Yes, and some of the claims are simply factually incorrect: the original work on refactoring OO programs was done in the context of Smalltalk, the code navigation we now have in IDEs was taken from Smalltalk (in fact, Eclipse started out as Visual Age Smalltalk) etc. So I find the post "debatable"...

(blog author) Well I thought refactoring went all the way back to Forth. I'm sure that with some language xyz it worked out very well for some project abc and that obviously disproves my whole point and you can move on... I found writing large projects in Python - a language I was very familiar with, expert even - to become very difficult to extend aka maintain after a long time. My post should be seen in the bigger…

> Well I thought refactoring went all the way back to Forth.

The original refactoring browser was in Smalltalk. Forth programmers don't go about that type of thing the same way as other language since the goal is really to write good "words" that express your program. It is more building a better language than traditional refactoring.

Re: Dynamic Languages are Unmaintainable

#12
I use dynamically typed languages maybe 90% of the time, and completely agree. But here's the thing: for most projects - including ones in production - it doesn't matter because the app won't be large enough to not completely fit in a mental model.

If the app starts getting too large, then by all means rewrite it in a statically typed language. If you're getting to that point, a rewrite is probably warranted anyways; regardless of the language you choose, first versions are usually awkwardly structured and difficult to maintain anyways since features evolve faster than architecture.

Re: Dynamic Languages are Unmaintainable

#13
post #7

I use a strongly, statically typed functional language. Because my code has no mutable state, the type system of the program proves the program correct. So I don't have to write any tests at all and maintenance is easy.

Which type system proves program correctness? A good type system can guarantee that your program doesn't suffer from certain classes of errors but that's very very far from correctness. Unless you only write programs that don't have any goal at all besides being memory safe: Behold MemSafe 2.9: it doesn't do anything at all, and most importantly, it doesn't do it in a memory safe way!

All safe type systems provide proofs that implementations fulfil specifications, but most type systems aren't expressive enough to create interesting specifications. The notable exceptions being type systems in dependently typed languages.

Re: Dynamic Languages are Unmaintainable

#14
post #7

I use a strongly, statically typed functional language. Because my code has no mutable state, the type system of the program proves the program correct. So I don't have to write any tests at all and maintenance is easy.

Now and then I get to deal with development groups who have built their software systems using a language like Ruby or PHP. Many of them are proud of their extensive automated tests.

They'll brag about how they have 45,000 or more unit tests, for instance. Yet when we actually look at these tests, many of them just end up implementing a half-baked type system.

Even if they don't realize it, or don't want to acknowledge it, users of dynamic languages do want strong, static typing. It is one of the most useful tools there is when it comes to helping detect or avoid various problems. Rather than doing it in a sensible matter, by letting the computer (via a compiler, for example) efficiently do the hard or tedious work, they just choose to do it themselves manually.

Re: Dynamic Languages are Unmaintainable

#15
post #7

I use a strongly, statically typed functional language. Because my code has no mutable state, the type system of the program proves the program correct. So I don't have to write any tests at all and maintenance is easy.

(define square ((a number)) :out number (+ a 2))

This program is arguably incorrect, even though the types match up and there is no mutable state.

Re: Dynamic Languages are Unmaintainable

#16
post #9

Earlier quoted context omitted.

(blog author) Well I thought refactoring went all the way back to Forth. I'm sure that with some language xyz it worked out very well for some project abc and that obviously disproves my whole point and you can move on... I found writing large projects in Python - a language I was very familiar with, expert even - to become very difficult to extend aka maintain after a long time. My post should be seen in the bigger…

Isn't "some language xyz worked out very well..." and "I found writing large projects in Python..." basically the same (anecdotal) argument?

Yes, but its a subjective post. If someone wants to say or blog "I use xyz and I can successfully maintain and extend large projects and it hasn't collapsed under a cognitive burden and too-specific unit testing" that'd be a cool counter data point.

Re: Dynamic Languages are Unmaintainable

#17
post #4
post #3

Earlier quoted context omitted.

Submitter here: Yes, and some of the claims are simply factually incorrect: the original work on refactoring OO programs was done in the context of Smalltalk, the code navigation we now have in IDEs was taken from Smalltalk (in fact, Eclipse started out as Visual Age Smalltalk) etc. So I find the post "debatable"...

Given that the second paragraph makes factually incorrect claims about what you can detect at compile time in dynamic languages, I think "debatable" is rather kind :) Of course, sweeping generalizations about static versus dynamic languages tend to fall flat.

> I think "debatable" is rather kind :)

Well, I think he has an interesting data-point, and makes some interesting points despite maybe making a somewhat incorrect generalization.

But even that generalization points to something I find interesting, which is that Python and JavaScript (maybe Ruby as well) possibly form a separate group with the characteristics he describes.

I also found the observation that Mock object testing doesn't seem to respond well to changes in the underlying code interesting.

It's that mix that makes it "debatable" ;-)

Re: Dynamic Languages are Unmaintainable

#18
post #4

Earlier quoted context omitted.

Given that the second paragraph makes factually incorrect claims about what you can detect at compile time in dynamic languages, I think "debatable" is rather kind :) Of course, sweeping generalizations about static versus dynamic languages tend to fall flat.

Could you elaborate. Which claims are incorrect?

One example would be this:

> If you misspell a variable [...], you discover this at run time. Ouch.

CL-USER> (defun square (n) (* nn n)) ;; Ouch! nn isn't defined!

; in: DEFUN SQUARE ; (* NN N) ; ; caught WARNING: ; undefined variable: NN ; ; compilation unit finished ; Undefined variable: ; NN ; caught 1 WARNING condition SQUARE

Re: Dynamic Languages are Unmaintainable

#19
>> And here is that insidious problem; all your unit tests have frozen the interaction of your components. They have copied the API of your components and distributed it all over your test code base.

This is what I hate about the unit-test everything approach. There seems to be a class of developers recently that believe robustness is more important than anything else.

Often speed bumps in changing API contracts is a higher price to pay [0] than the kind of bugs which unit testing uncovers.

There are lots of things which are good in small quantities and very bad in large quantities [1].

Better to be able to iterate quickly, spot a few bugs with sparse unit tests and completely rewrite your small components if they no longer fit the bill. There is a tendency (perhaps with those too familiar with large corporates) to try to de-risk with more and more robustness tests. With all of this robustness monolithic software flourishes, and you eventually lose the ability to iterate quickly; the ability to destroy and start anew.

[0] Form does not follow function, form is interdependent with function. Make the functionality robust and you make the form rigid! How will you find product-market fit when you are unable to move?!

[1] http://en.wikipedia.org/wiki/Hormesis

Re: Dynamic Languages are Unmaintainable

#20
post #7

I use a strongly, statically typed functional language. Because my code has no mutable state, the type system of the program proves the program correct. So I don't have to write any tests at all and maintenance is easy.

Not sure if you're trolling or just don't understand what tests are actually supposed to test.
Post reply on HN