9 ms·

Personally, I disagree. I find JavaScript to be the most "write-able" language, and switching to Node + frontend JS as my main language (I've done Python, Ruby,

Personally, I disagree. I find JavaScript to be the most "write-able" language, and switching to Node + frontend JS as my main language (I've done Python, Ruby, PHP, Java and C++ as jobs) has been the best thing I've done in a long time. Express and Angular are amazing. Sure, it has a bunch of quirks. Sure, it's not good for everything (I do mostly relatively simple CRUD apps). Sure, in the browser, it gets slow when the DOM is involved. Sure, this is hardly a rebuttal of the points in the original article. But, still, I love JavaScript. I think the problem is that the author is writing JavaScript as though it's Ruby. A JS developer switching to Ruby would have similar problems.

Peaker 13y ago
How do you handle Javascript ignoring wrong numbers of function arguments? Do you use a linter to catch this sort of thing? This part of Javascript sounds the most absolutely insane to me: Silencing an error like that is catastrophic.
- gkoberger 13y ago
  It's just never been a problem for me, I guess? I know how it works in JS, so I either ignore it or use it to my advantage (the JS equivalent of overloading). You seem to come from a more strongly-typed background, but I've never once found the way JS handles it to be "catastrophic".
  - Peaker 13y ago
    How do you ignore it? Ignoring it means accepting cryptic bugs that result from signature changes. You say "use to your advantage", but what's the advantage? You could have a "*args" like Python, and get the benefits without the (huge) drawback. The typing debate is mostly about how much effort we should exert to catch errors at compile time rather than run time. In JS, it is much worse: It defers error catching forever, and never even catches them at all! It converts them to silent bugs, instead :(
- powatom 13y ago
  Is this so much of a problem that we need to re-design JS to handle it? Why not just avoid making this mistake in the first place by reading the code? Not to sound dismissive - but if you're making these kinds of mistakes regularly enough to irritate you, it's not the language that's at fault. Javascript's squishiness is the thing I like the most about it. It's far from perfect, just like any other language out there - but it's fun.
  - gumballhead 13y ago
    This. People complaining about what JavaScript lets you do just need to learn how to exploit its strengths while being aware of its dangers. It's like someone complaining that git let them make a mess after they merged master into their feature branch and then merge it back into master.
    - Peaker 13y ago
      No, it's much more like git ignoring wrong command syntax and just using undefined instead. git commit - m"Hi" && git push Let's push a commit with an undefined message, and ignore the m"Hi" argument. Error messages are annoying.
  - Peaker 13y ago
    > Why not just avoid making this mistake in the first place by reading the code? We're talking about programming errors. Are you suggesting the solution to human error is to just not make errors?? Note, of course, that wrong arguments will frequently not arise from a function call you just wrote -- but from changes in the code. Say you merge in a trivial merge of some code, which changed a function's signature/parameters. The merge succeeds trivially. Now every single function call is a bug that is not only uncaught by a compiler. It won't even necessarily be caught at runtime. Instead, it may escalate to catastrophic, undefined/unexpected behavior.
    - powatom 13y ago
      > We're talking about programming errors. Are you suggesting the solution to human error is to just not make errors?? Not at all, I'm simply suggesting that people take care to acknowledge and operate within the rules of the language. If you're making changes to a function signature in JS without assessing the impact for code elsewhere, then you're doing a bad job - and that's all there is to it. JS allows you to do something which when ignored or fucked up, results in problems. This is not a JSism - this is just the way things work. Every language has 'features' like this. If you don't know what you're doing, then stop doing it. "A bad workman blames his tools" and all that jazz. > Note, of course, that wrong arguments will frequently not arise from a function call you just wrote -- but from changes in the code. So JS has a (potentially) higher maintenance cost. This doesn't mean that JS is badly designed - it's just a trade-off. Some people don't care, others do. Clearly to some people, it's an unacceptable cost - but all that means is that those people have a lower tolerance for that kind of thing than others. > Say you merge in a trivial merge of some code, which changed a function's signature/parameters. The merge succeeds trivially. Now every single function call is a bug that is not only uncaught by a compiler. It won't even necessarily be caught at runtime. Instead, it may escalate to catastrophic, undefined/unexpected behavior. This is just a case for good documentation and release notes. Don't merge in changes that you don't understand.
- Wintamute 13y ago
  Generally speaking, in the JS world at least, if you're passing more than a few parameters into a function you might have code complexity problems. If you need to pass in a bunch of data to a function you tend to do it in a single options object with some runtime checking to work out what to do with it. Any remaining problems should be caught with good test coverage. Being able to flexibly and clearly handle variable numbers of function arguments without getting entangled in an involved function overloading syntax and methodology is actually sometimes pretty nice. It's a feature not a problem. Haha :P
  - forgottenpass 13y ago
    >>How do you handle Javascript ignoring wrong numbers of function arguments? >if you're passing more than a few parameters into a function I didn't know you had to have "more than a few parameters" before you could make a coding error related to the number of parameters you pass something.
- arethuza 13y ago
  I think the way libraries like jQuery use this behaviour to define their own undefined that is indeed undefined is rather neat, the whole of jQuery is wrapped in: (function(window, undefined) {...})(window);
- callum85 13y ago
  Silencing an error like that is catastrophic. Silencing an error would be a problem, but in JS, it's not an error, because there's no concept of "wrong numbers of function arguments" built into the language. That's not to say you can't inspect the number of arguments yourself and throw an error, if some situation warrants it. But you don't have to do this. It's a very flexible, dynamic language. In some ways this flexibility makes things easier and more expressive, in other ways it necessitates more manual checking (or slower debugging). There's no catastrophe, just design differences.
  - anon1385 13y ago
    It's still a programmer error when they accidentally call a function with 2 arguments when they meant to call it with 3. The fact that the language can't inform them of the error doesn't change that.
    - marrs 13y ago
      So do some error checks. The first unit test I write for any function is that it handles arguments correctly.
      - prof_hobart 13y ago
        That's great if it's your function that's the problem. Less so if it's someone else's. And it's not only these kinds of errors that can cause silent failure. I've had it on missing brackets, on missing commas, on failure to include/require the right source file etc, etc. No error message, no warning, no log entry, no nothing. Just silence. And a blank output. Not overly helpful.
      - anon1385 13y ago
        But you do see why people are complaining, right? You are having to manually write thousands of tests to check something that is trivial for a compiler to check.
        gnaritas 13y ago
- potch 13y ago
  In JS, sending the "wrong" number of arguments is frequently a feature. There's no concept of language-level function overloading, and it allows for the authorship of functions that take a variable or unbounded number of arguments (useful when coding in a functional paradigm).
  - admnor 13y ago
    That "feature" would be better with an explicit language construct such as *args or params args[], though. As with so many complaints about JavaScript, it's the default behaviour that is a problem.
    - Peaker 13y ago
      I'd say it's worse than a default behavior, since there's no sane way to reverse the default. Are explicit arg list checks really an option, when you want to opt out of the default? I'd say that's not practical at all -- so it's really worse, as there's no practical opt out of this.
    - jakub_g 13y ago
      ES6 brings "rest parameter" [0]. function(param1, param2, ...rest) {} [0] http://ariya.ofilabs.com/2013/03/es6-and-rest-parameter.html http://ariya.ofilabs.com/2013/03/es6-and-rest-parameter.html
drakaal 13y ago
I see this all the time. JS is slow because of the dom. No. JS is slow because JS is slow. Yes, I know V8 makes it faster than it used to be. Yes I know it is neck and neck for computation, but because of the way memory is handled it is slow for loading large dictionaries. But I could forgive all of that. JavaScript is not well designed for work in a team environment, nor is it well designed for Large Code Bases. But I could forgive all of that. All the best languages have a group of scientists that have chosen that language to be their defacto language. That is why we see Python, LISP, Fortran (yes still), MatLab, all living on long beyond the "trendy" languages. JS only picked up steam because Flash died. Not because it was a great language. If it were a great language people would have started optimizing it 5 years ago. It isn't. So they didn't. The new optimizations are out of necessity. And because it lets front end pretend to be backend. That may sound snobby, and it is, but JS for backend is like writing in Visual Basic. These days you can do anything in it, it will be fast, but that doesn't make it the right choice.
- pmelendez 13y ago
  >"JS is slow." In comparison to what? JS is one of the faster script languages out there. V8 is way faster that Ruby and outperform python a lot of time as well. It's regex is blast fast as well.
  - Mikeb85 13y ago
    It outperforms Python at everything except where Python just calls a C function. Ruby (especially the recent releases) is on par with Python speed, if not faster. But neither is close to JS.
    - oscargrouch 13y ago
      "My pet is fast because it can beat a turtle and a slug in a race"
      - Mikeb85 13y ago
        Lol. Seriously though, show me a dynamic language (other than Lisp) that's even half as fast as Javascript...

Peaker 13y ago

How do you handle Javascript ignoring wrong numbers of function arguments? Do you use a linter to catch this sort of thing? This part of Javascript sounds the most absolutely insane to me: Silencing an error like that is catastrophic.

gkoberger 13y ago
It's just never been a problem for me, I guess? I know how it works in JS, so I either ignore it or use it to my advantage (the JS equivalent of overloading). You seem to come from a more strongly-typed background, but I've never once found the way JS handles it to be "catastrophic".
- Peaker 13y ago
  How do you ignore it? Ignoring it means accepting cryptic bugs that result from signature changes. You say "use to your advantage", but what's the advantage? You could have a "*args" like Python, and get the benefits without the (huge) drawback. The typing debate is mostly about how much effort we should exert to catch errors at compile time rather than run time. In JS, it is much worse: It defers error catching forever, and never even catches them at all! It converts them to silent bugs, instead :(
powatom 13y ago
Is this so much of a problem that we need to re-design JS to handle it? Why not just avoid making this mistake in the first place by reading the code? Not to sound dismissive - but if you're making these kinds of mistakes regularly enough to irritate you, it's not the language that's at fault. Javascript's squishiness is the thing I like the most about it. It's far from perfect, just like any other language out there - but it's fun.
- gumballhead 13y ago
  This. People complaining about what JavaScript lets you do just need to learn how to exploit its strengths while being aware of its dangers. It's like someone complaining that git let them make a mess after they merged master into their feature branch and then merge it back into master.
  - Peaker 13y ago
    No, it's much more like git ignoring wrong command syntax and just using undefined instead. git commit - m"Hi" && git push Let's push a commit with an undefined message, and ignore the m"Hi" argument. Error messages are annoying.
- Peaker 13y ago
  > Why not just avoid making this mistake in the first place by reading the code? We're talking about programming errors. Are you suggesting the solution to human error is to just not make errors?? Note, of course, that wrong arguments will frequently not arise from a function call you just wrote -- but from changes in the code. Say you merge in a trivial merge of some code, which changed a function's signature/parameters. The merge succeeds trivially. Now every single function call is a bug that is not only uncaught by a compiler. It won't even necessarily be caught at runtime. Instead, it may escalate to catastrophic, undefined/unexpected behavior.
  - powatom 13y ago
    > We're talking about programming errors. Are you suggesting the solution to human error is to just not make errors?? Not at all, I'm simply suggesting that people take care to acknowledge and operate within the rules of the language. If you're making changes to a function signature in JS without assessing the impact for code elsewhere, then you're doing a bad job - and that's all there is to it. JS allows you to do something which when ignored or fucked up, results in problems. This is not a JSism - this is just the way things work. Every language has 'features' like this. If you don't know what you're doing, then stop doing it. "A bad workman blames his tools" and all that jazz. > Note, of course, that wrong arguments will frequently not arise from a function call you just wrote -- but from changes in the code. So JS has a (potentially) higher maintenance cost. This doesn't mean that JS is badly designed - it's just a trade-off. Some people don't care, others do. Clearly to some people, it's an unacceptable cost - but all that means is that those people have a lower tolerance for that kind of thing than others. > Say you merge in a trivial merge of some code, which changed a function's signature/parameters. The merge succeeds trivially. Now every single function call is a bug that is not only uncaught by a compiler. It won't even necessarily be caught at runtime. Instead, it may escalate to catastrophic, undefined/unexpected behavior. This is just a case for good documentation and release notes. Don't merge in changes that you don't understand.
Wintamute 13y ago
Generally speaking, in the JS world at least, if you're passing more than a few parameters into a function you might have code complexity problems. If you need to pass in a bunch of data to a function you tend to do it in a single options object with some runtime checking to work out what to do with it. Any remaining problems should be caught with good test coverage. Being able to flexibly and clearly handle variable numbers of function arguments without getting entangled in an involved function overloading syntax and methodology is actually sometimes pretty nice. It's a feature not a problem. Haha :P
- forgottenpass 13y ago
  >>How do you handle Javascript ignoring wrong numbers of function arguments? >if you're passing more than a few parameters into a function I didn't know you had to have "more than a few parameters" before you could make a coding error related to the number of parameters you pass something.
arethuza 13y ago
I think the way libraries like jQuery use this behaviour to define their own undefined that is indeed undefined is rather neat, the whole of jQuery is wrapped in: (function(window, undefined) {...})(window);
callum85 13y ago
Silencing an error like that is catastrophic. Silencing an error would be a problem, but in JS, it's not an error, because there's no concept of "wrong numbers of function arguments" built into the language. That's not to say you can't inspect the number of arguments yourself and throw an error, if some situation warrants it. But you don't have to do this. It's a very flexible, dynamic language. In some ways this flexibility makes things easier and more expressive, in other ways it necessitates more manual checking (or slower debugging). There's no catastrophe, just design differences.
- anon1385 13y ago
  It's still a programmer error when they accidentally call a function with 2 arguments when they meant to call it with 3. The fact that the language can't inform them of the error doesn't change that.
  - marrs 13y ago
    So do some error checks. The first unit test I write for any function is that it handles arguments correctly.
    - prof_hobart 13y ago
      That's great if it's your function that's the problem. Less so if it's someone else's. And it's not only these kinds of errors that can cause silent failure. I've had it on missing brackets, on missing commas, on failure to include/require the right source file etc, etc. No error message, no warning, no log entry, no nothing. Just silence. And a blank output. Not overly helpful.
    - anon1385 13y ago
      But you do see why people are complaining, right? You are having to manually write thousands of tests to check something that is trivial for a compiler to check.
      - gnaritas 13y ago
potch 13y ago
In JS, sending the "wrong" number of arguments is frequently a feature. There's no concept of language-level function overloading, and it allows for the authorship of functions that take a variable or unbounded number of arguments (useful when coding in a functional paradigm).
- admnor 13y ago
  That "feature" would be better with an explicit language construct such as *args or params args[], though. As with so many complaints about JavaScript, it's the default behaviour that is a problem.
  - Peaker 13y ago
    I'd say it's worse than a default behavior, since there's no sane way to reverse the default. Are explicit arg list checks really an option, when you want to opt out of the default? I'd say that's not practical at all -- so it's really worse, as there's no practical opt out of this.
  - jakub_g 13y ago
    ES6 brings "rest parameter" [0]. function(param1, param2, ...rest) {} [0] http://ariya.ofilabs.com/2013/03/es6-and-rest-parameter.html http://ariya.ofilabs.com/2013/03/es6-and-rest-parameter.html

drakaal 13y ago

I see this all the time. JS is slow because of the dom. No. JS is slow because JS is slow. Yes, I know V8 makes it faster than it used to be. Yes I know it is neck and neck for computation, but because of the way memory is handled it is slow for loading large dictionaries. But I could forgive all of that. JavaScript is not well designed for work in a team environment, nor is it well designed for Large Code Bases. But I could forgive all of that. All the best languages have a group of scientists that have chosen that language to be their defacto language. That is why we see Python, LISP, Fortran (yes still), MatLab, all living on long beyond the "trendy" languages. JS only picked up steam because Flash died. Not because it was a great language. If it were a great language people would have started optimizing it 5 years ago. It isn't. So they didn't. The new optimizations are out of necessity. And because it lets front end pretend to be backend. That may sound snobby, and it is, but JS for backend is like writing in Visual Basic. These days you can do anything in it, it will be fast, but that doesn't make it the right choice.

pmelendez 13y ago
>"JS is slow." In comparison to what? JS is one of the faster script languages out there. V8 is way faster that Ruby and outperform python a lot of time as well. It's regex is blast fast as well.
- Mikeb85 13y ago
  It outperforms Python at everything except where Python just calls a C function. Ruby (especially the recent releases) is on par with Python speed, if not faster. But neither is close to JS.
  - oscargrouch 13y ago
    "My pet is fast because it can beat a turtle and a slug in a race"
    - Mikeb85 13y ago
      Lol. Seriously though, show me a dynamic language (other than Lisp) that's even half as fast as Javascript...