5 ms·

This is more of a rant against dynamically typed languages than against javascript itself, and making the argument that dynamically typed languages are not suit

This is more of a rant against dynamically typed languages than against javascript itself, and making the argument that dynamically typed languages are not suitable for large web apps is a difficult (not impossible) one to make. The author also complains about some javascript projects being split up into enough files, which is hardly a side-effect of using javascript. The author inherited what sounds like a pretty disorganized javascript application and is using it as their real world example for why javascript shouldn't be used to write large web apps. In fact, almost everything in the post is anecdotal or subjective.

Graphon 14y ago
The OP seems to be very willing to draw general conclusions when none are warranted. When faced with a project in which code modularization was a problem, his proposed solution was to port the code? Seriously? Port Javascript to Actionscript because the .js was organized into too few modules? mmmm-okay.
_delirium 14y ago
Yeah, this doesn't add a whole lot to the debate imo. I'm vaguely sympathetic to the argument that languages with more/better static analysis are better for large-scale development, but that particular argument has a whole lot written about it, and is probably still inconclusive.
- mixitup12 14y ago
  Also, define large scale. Plenty of large scale applications can and are written in languages like Python.
TazeTSchnitzel 14y ago
And it's an Adobe blog. Their employees are quite likely to be biased in favour of their statically-typed variant, ActionScript 3 (well, it has a lot of changes, but it's essentially a JS variant at heart)
- millions 14y ago
  Not exactly - ActionScript3 is pretty much as close as you can get to what JavaScript2 would have been - Ecmascript 4.
  - cnp 14y ago
    ...yeah, what was to be a beautiful language. So unfortunate that that proposal was squashed.
    - arcos 14y ago
      No, thank Thor that mutant was aborted. ECMAScript 4 got everything wrong, just like AS3 did.
      - cnp 14y ago
        An optionally dynamic, yet also statically typed language? Umm... no. It's hard to even imagine arguing about this.
        TazeTSchnitzel 14y ago
        No. The problem with ES4 was that JavaScript is at heart not a traditional procedural OOP language. It's a functional language, and ES4 was trying to change that, a huge step in the wrong direction. They wanted more Java and less Script, but thankfully ES5 has gone the other direction, and given use more Script and less Java.
- codebearded 14y ago
  I find it very difficult to swallow anything written by the OP from the obstructed view at Adobe. After spending nearly every billable hour for more than three years buried in AS3's woeful inconsistencies, undocumented (or un-addressed) compiler issues, seemingly infinite application-crippling bugs, schizophrenic deprecation- any dev who had the misfortune of being relegated to work primarily in AS3 (and god help you if you had to support AS2 and AS3 applications simultaneously) the mere suggestion that Adobe has an opinion that is anything but a head up its own ass probably makes you break out in hives like i just did.
kaonashi 14y ago
Dynamic typing isn't the problem; weak typing is the problem.
mistercow 14y ago
I also find objections like the "createBunnyOrToaster" antipattern to be really, really uncompelling. You don't need a static type system to make sure that your functions are sane and consistent, and you don't have to be John Resig either. First of all, put a comment at the top of your function that says what to expect about the return value. You should be doing this anyway because the return type alone is often not sufficient for future programmers reading your code. Secondly, every time you write the word "return", look up at the top of your function and make sure you are in accordance with what you said the function would do. If you end up with a paragraph comment about what the return value will be like, refactor.
- munificent 14y ago
  > You don't need a static type system to make sure that your functions are sane and consistent, and you don't have to be John Resig either. Right, and you can do structured programming in assembly. But when the language or tools don't help you do that, there are examples like the one the author points out where developers don't. Don't mistake utility (what can be done) for usability (what is easy to do). Usability always matters. > First of all, put a comment at the top of your function that says what to expect about the return value. I want a language that gives me a nice pleasant syntax for doing that. > Secondly, every time you write the word "return", look up at the top of your function and make sure you are in accordance with what you said the function would do. As a programmer, you should be trained that when you see "every time", you think "automate this". If you and everyone on your team and everyone who has ever been on your team has to remember to do something every single time, your code will accumulate a pile of instances of forgetting. Fixing that is exactly what tools and languages are for. It's a hell of a lot easier to make a disciplined tool than a more disciplined programmer. (And when you have made a more disciplined programmer, they typically evidence that by asking for more disciplined tools.)
  - lucisferre 14y ago
    Unfortunately static typing doesn't really fix the automation problems that are most common in software development any better than anything else. I wouldn't mistake a personal preference for static type systems and large complex IDEs for superiority of language or productivity.
mixitup12 14y ago
Glad you wrote it so I didn't have to. If you have programmers making bad decisions in any language a project quickly becomes unmaintainable. I say take it back.
drivebyacct2 14y ago
>making the argument that dynamically typed languages are not suitable for large web apps is a difficult (not impossible) one to make Is it? And even if it is, why? Because dynamically typed languages are in vogue? Java does fine as a server-side webapp language, as does Dart (on the client too!), as does Go, etc.

Graphon 14y ago

The OP seems to be very willing to draw general conclusions when none are warranted. When faced with a project in which code modularization was a problem, his proposed solution was to port the code? Seriously? Port Javascript to Actionscript because the .js was organized into too few modules? mmmm-okay.

_delirium 14y ago

Yeah, this doesn't add a whole lot to the debate imo. I'm vaguely sympathetic to the argument that languages with more/better static analysis are better for large-scale development, but that particular argument has a whole lot written about it, and is probably still inconclusive.

mixitup12 14y ago
Also, define large scale. Plenty of large scale applications can and are written in languages like Python.

TazeTSchnitzel 14y ago

And it's an Adobe blog. Their employees are quite likely to be biased in favour of their statically-typed variant, ActionScript 3 (well, it has a lot of changes, but it's essentially a JS variant at heart)

millions 14y ago
Not exactly - ActionScript3 is pretty much as close as you can get to what JavaScript2 would have been - Ecmascript 4.
- cnp 14y ago
  ...yeah, what was to be a beautiful language. So unfortunate that that proposal was squashed.
  - arcos 14y ago
    No, thank Thor that mutant was aborted. ECMAScript 4 got everything wrong, just like AS3 did.
    - cnp 14y ago
      An optionally dynamic, yet also statically typed language? Umm... no. It's hard to even imagine arguing about this.
      - TazeTSchnitzel 14y ago
        No. The problem with ES4 was that JavaScript is at heart not a traditional procedural OOP language. It's a functional language, and ES4 was trying to change that, a huge step in the wrong direction. They wanted more Java and less Script, but thankfully ES5 has gone the other direction, and given use more Script and less Java.
codebearded 14y ago
I find it very difficult to swallow anything written by the OP from the obstructed view at Adobe. After spending nearly every billable hour for more than three years buried in AS3's woeful inconsistencies, undocumented (or un-addressed) compiler issues, seemingly infinite application-crippling bugs, schizophrenic deprecation- any dev who had the misfortune of being relegated to work primarily in AS3 (and god help you if you had to support AS2 and AS3 applications simultaneously) the mere suggestion that Adobe has an opinion that is anything but a head up its own ass probably makes you break out in hives like i just did.

kaonashi 14y ago

Dynamic typing isn't the problem; weak typing is the problem.

mistercow 14y ago

I also find objections like the "createBunnyOrToaster" antipattern to be really, really uncompelling. You don't need a static type system to make sure that your functions are sane and consistent, and you don't have to be John Resig either. First of all, put a comment at the top of your function that says what to expect about the return value. You should be doing this anyway because the return type alone is often not sufficient for future programmers reading your code. Secondly, every time you write the word "return", look up at the top of your function and make sure you are in accordance with what you said the function would do. If you end up with a paragraph comment about what the return value will be like, refactor.

munificent 14y ago
> You don't need a static type system to make sure that your functions are sane and consistent, and you don't have to be John Resig either. Right, and you can do structured programming in assembly. But when the language or tools don't help you do that, there are examples like the one the author points out where developers don't. Don't mistake utility (what can be done) for usability (what is easy to do). Usability always matters. > First of all, put a comment at the top of your function that says what to expect about the return value. I want a language that gives me a nice pleasant syntax for doing that. > Secondly, every time you write the word "return", look up at the top of your function and make sure you are in accordance with what you said the function would do. As a programmer, you should be trained that when you see "every time", you think "automate this". If you and everyone on your team and everyone who has ever been on your team has to remember to do something every single time, your code will accumulate a pile of instances of forgetting. Fixing that is exactly what tools and languages are for. It's a hell of a lot easier to make a disciplined tool than a more disciplined programmer. (And when you have made a more disciplined programmer, they typically evidence that by asking for more disciplined tools.)
- lucisferre 14y ago
  Unfortunately static typing doesn't really fix the automation problems that are most common in software development any better than anything else. I wouldn't mistake a personal preference for static type systems and large complex IDEs for superiority of language or productivity.

mixitup12 14y ago

Glad you wrote it so I didn't have to. If you have programmers making bad decisions in any language a project quickly becomes unmaintainable. I say take it back.

drivebyacct2 14y ago

>making the argument that dynamically typed languages are not suitable for large web apps is a difficult (not impossible) one to make Is it? And even if it is, why? Because dynamically typed languages are in vogue? Java does fine as a server-side webapp language, as does Dart (on the client too!), as does Go, etc.