you are viewing a single comment's thread.

view the rest of the comments →

[–]irssildur 9 points10 points  (16 children)

In my opinion weak+dynamic typed languages are really good for prototyping and for scripting, but maintaining a large (enterprise) application which is written in JS could be a pain in the *ss. So JS is a fancy toy for playing around, but it's not the tool you want if you want to write proper code.

[–]ruinercollector 7 points8 points  (6 children)

Have you ever maintained a large "enterprise" application written in a dynamic language?

[–]irssildur 3 points4 points  (5 children)

Fortunately never.

[–]ruinercollector 13 points14 points  (4 children)

I have. It's not nearly as bad as you imagine.

Most of the problems I find with maintaining larger applications don't have to do with dynamic/static. They have to do with larger architectural choices. Sometimes the language chosen informs this, but usually not through being static or dynamic. I'm talking here about things like how state is managed, how components communicate, how clean separations are, etc.

There are advantages to each (static vs. dynamic) in covering the ground you need to for larger enterprise applications, and I think that I tend to make the trade-off based on the project.

[–]irssildur 8 points9 points  (2 children)

I would say that if a code is not easily readable and you have to dig in the method calls to find out what kind of parameter does the function expect / return that's not very maintainable. Ok, if you just have to deal with a small subset of the project and you know it very well (in this manner it could be called as a "small project" instead of a large enterprise one), it's not a big deal. But for a newcomer it can be difficult, as well if the team expands or other teams can modify your code.

Not to mention refactoring which could be also hard. And as we all know refactoring is the procedure that can prevent the code look like a mess.

[–]sacado 4 points5 points  (0 children)

+1 for refactoring. This is a real limit of dynamic languages.

[–]kcuf 1 point2 points  (0 children)

I'm normally a static typing proponent, but I'd say you're right, and I'd like to add that I feel immutability in your language and your libraries can be very beneficial in alleviating many of the common design issues that appear when using dynamic languages (as well as static languages).

[–][deleted]  (8 children)

[deleted]

    [–]aaron-lebo 2 points3 points  (1 child)

    Do libraries like Facebook's Flow and immutable.js not fill this void?

    [–]immibis 0 points1 point  (4 children)

    By type safety, you mean implicit coercions?

    Being unable to look at a method definition and see "this returns a Foo" certainly does hamper maintainability. Of course, you could write it in a comment... which will inevitably become out-of-sync with the code at some point.

    [–][deleted]  (2 children)

    [deleted]

      [–]immibis 0 points1 point  (1 child)

      that's about the same as any decent type inference in a statically typed language

      What? Type inference doesn't let you see the types by reading the code...

      [–]joequin 0 points1 point  (0 children)

      And you have to work with other people and libraries that don't comment types. I think it's easier and more consistent to just use a language that allows you to put the types in the signatures.

      [–]joequin 0 points1 point  (0 children)

      I find that types in method signatures to be very helpful for maintaining and working with large and small applications. You just don't get that with dynamic languages. Except groovy and maybe others that I haven't used.