Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dynamic Languages are Unmaintainable

williamedwardscoder.tumblr.com

Post reply on HN
Print view View original

51–60 of 71 posts

Re: Dynamic Languages are Unmaintainable

#51

Post by kyllo »

The thing about dynamic languages is that they have a type system too, but it's called "inheritance." When literally everything in your language is an object that ultimately inherits from Object, as it is in Ruby or Python or Javascript, it doesn't matter what "type" each of your objects is, it just matters that your objects define the fields you want to access and respond to the methods you want to call on them (And Ruby even lets you fail up the object tree with method_missing). Fixating on types is focusing on the wrong thing. You need to understand the object inheritance tree, not the types.

Whether or not that makes your code unmaintainable is up to you, it helps if you keep your classes small and give each of them a well-defined and documented purpose. But that's just good coding practice in general.

Also, static code analysis is nice, but it can't determine everything about your code; Turing proved that in 1936.

Meanwhile, by skipping the the compiler and linker, you can deploy enhancements and bug fixes to a running program without shutting it down and restarting it. For a rather long but enjoyable read on why this is important for long-lasting software, see: http://steve-yegge.blogspot.com/2007/01/pinocchio-problem.ht...

Re: Dynamic Languages are Unmaintainable

#52

Post by programminggeek »

Hey, you might not know this, but if you use a dynamic language with types you can actually use them to your benefit!

I've wrote a system in ruby that does clean type checking when I want it to and it cleans up the code and tests a lot.

Just because you're not taking full advantage of your language tools doesn't mean that "dynamic languages are unmaintainable"

Re: Dynamic Languages are Unmaintainable

#53

Post by JunkDNA »

gnuvince wrote: post #35
JunkDNA wrote: post #26

One thing I've only come to appreciate during my professional development is that there are huge differences in the kinds of software people write and what's good in one scenario isn't necessarily good in another. A lot of people around here fall into the trap (myself included) of thinking that web programming is the entire universe of programming. That's not so, and the difference matters greatly. If you're going to…

> What is the type system providing you in that scenario? Though the data flowing in and out of a web application is usually in string form, that doesn't mean that it needs to be treated as such in your application. You'll convert the string to a richer, more specific datatype and the static type system will help you correctly manipulate the data. A nice blog post on the subject is [1] where the author explains how y…

Thanks for that post, I think the point I was making was slightly different. I'm arguing that with web programming you lack the end to end control you might have in a closed system. You depend on all sorts of input from users, your data is stored in a database or nosql store that is outside your program's (and compiler's) complete control. It can change underneath you at any time. The argument that static typing can help you know that your code is correct is weakened in this environment. Internally you of course construct your code in a way that uses types and can verify that you are internally consistent. However, I'm saying that at a fundamental level, in a data-driven web app, the system as a whole is only marginally improved by this because your whole universe starts out with a bunch of typecast operations as the gateway to your codebase. These always are happening at runtime and are one "ALTER TABLE" (to pick just one example) away from failing spectacularly in production.

I'm not arguing one way or another that static typing is/is not good in this scenario. I'm just pointing out that the foundation of the system as a whole is not as solid as other programming scenarios where you have much more control.

Re: Dynamic Languages are Unmaintainable

#54

Post by manfredzab »

First of all, there are no silver bullets and no overall "better" languages. It depends on the situation, and a good software _engineer_ should be able to reason about the trade-offs of using statically/dynamically typed languages in each situation.

In this case, it is about shifting the costs to different stages of the projects lifecycle. Statically typed languages require more mental effort while developing, and, by definition, catch more bugs early in the process (compiler has more information to play with, and the programmer is required to be more thorough). Pushing it even further, formal proof systems require exponentially more effort at development time, and, in some cases, rewards it with the proof of software correctness (i.e. no bug-fixing costs at maintenance stage). On the other end of spectrum, dynamically typed languages allow for much faster development (which can be mission critical), but a rapid release comes with a price of long-term maintenance difficulties.

It's up to the developer to choose which approach is the most appropriate for the situation (amongst the myriad of other trade-offs, like performance, scalability, user requirements, existing infrastructure and so on).

Re: Dynamic Languages are Unmaintainable

#55

Post by MostAwesomeDude »

mpweiher wrote: post #3
PaulHoule wrote: post #2

The argument between dynamic and static languages has gone one for years and there's been no conclusive answer that one is better than the other. People have written 500kloc C++ systems and they've written 500kloc of TCL.

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"...

I politely submit that you have not heard of E.

Re: Dynamic Languages are Unmaintainable

#56

Post by tome »

angersock wrote: post #40
lbarrow wrote: 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.

>> don't have to write any tests at all That is, until you find out that your state-machine matches incorrectly on an input text file... >> maintenance is easy. ...and you are the only person your company can find to maintain your codebase. You're zero for two, my friend. :(

> ...and you are the only person your company can find to maintain your codebase.

Why should this be? Plenty of companies have teams of functional programmers.

Re: Dynamic Languages are Unmaintainable

#57

Post by gnuvince »

shangaslammi wrote: post #28
m0th87 wrote: post #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;…

I would also argue that you can get the benefits of a static type system with hardly any cost. Usually when people talk about dynamic vs static typing they imagine something like Ruby or Python vs Java, but there's no reason why you can't have a high-level, expressive language with static types. All you need is a sophisticated type-system and smart type-inference that works everywhere (not just locally) and you'll be…

OCaml, F#, Haskell all come to mind. Regarding total type inference, I am not sure though that any of those can do completely away without some manual type annotations. I still like to declare type annotations (especially in Haskell, the syntax in ML is a bit too ugly) for top-level functions.

Re: Dynamic Languages are Unmaintainable

#58

Post by gnuvince »

programminggeek wrote: post #52

Hey, you might not know this, but if you use a dynamic language with types you can actually use them to your benefit! I've wrote a system in ruby that does clean type checking when I want it to and it cleans up the code and tests a lot. Just because you're not taking full advantage of your language tools doesn't mean that "dynamic languages are unmaintainable"

How can you implement a static typing system in a language that is dynamically typed?

Re: Dynamic Languages are Unmaintainable

#60

Post by gizmo686 »

gnuvince wrote: post #57
shangaslammi wrote: post #28

Earlier quoted context omitted.

I would also argue that you can get the benefits of a static type system with hardly any cost. Usually when people talk about dynamic vs static typing they imagine something like Ruby or Python vs Java, but there's no reason why you can't have a high-level, expressive language with static types. All you need is a sophisticated type-system and smart type-inference that works everywhere (not just locally) and you'll be…

OCaml, F#, Haskell all come to mind. Regarding total type inference, I am not sure though that any of those can do completely away without some manual type annotations. I still like to declare type annotations (especially in Haskell, the syntax in ML is a bit too ugly) for top-level functions.

I can only speak about Haskell here, but how often do you need to provide a type annotation. I have never been in a situation (outside of the interactive prompt) where the compiler failed to infer the type. I do provide many type annotations for the sake of readability, but as far as I am aware the only effect these actually have on the code is providing additional restrictions on where a function can be used (that is to say, intentionally making the type signature less generic than it could be).
Post reply on HN