Slashdot Mirror
Ask Slashdot: Making JavaScript Tolerable For a Dyed-in-the-Wool C/C++/Java Guy?
DocDyson writes "I'm a dyed-in-the-wool C/C++/Java developer with over 20 years of experience. I'm making a good living and having fun doing back-end Java work right now, but I strongly believe in being a generalist, so I'm finally trying to learn the HTML5/CSS3/JavaScript future of the Web. However, I find JavaScript's weak typing and dynamic nature difficult to adapt to because I'm so used to strongly-typed, compiled languages with lots of compile-time error-checking and help from the IDE. Does anyone out there who has made this transition have any tips in terms of the best tools and libraries to use to make JavaScript more palatable to us old-school developers?"
Simple: clear, debuggable, logically organized, and debuggable code.
Don't define functions inline of your statement.
Don't perform evaluations in your return statements.
Avoid calling methods/functions on objects via the return of another evaluator.
The code sample he provided is counter to reusability, readability, unsafe in that it doesn't evaluate possible nulls, and arguably impossible to debug.
It has nothing to do with being a JavaScript guy or not. It has everything to do with the difference between being a programmer and a software engineer. They are two different things.
Loading...
JS's problem is not dynamic typing, it's that it is not strict enough. If you try fetching a property or method that doesn't exist on an object in Python or Ruby, which are dynamic languages, you get a runtime error. In JavaScript you get undefined, in Lua you get nil. But even Lua doesn't allow you to do freaking *arithmetic* on nil, and fetch arbitrary properties on numbers and strings. In JavaScript, undefined + 0 is valid and yields NaN, and then you can happily keep operating on that value until you crash and burn. And then you can do {} + [], giving 0, and [] + {}, giving "[object Object]". It is ridiculous. All of these additions should be errors, plain and simple, and ideally, x.y, when y is not a field of x, should be an error. Maybe x.?y and x[?y] could return undefined or nil in these situations, as a handy syntactic sugar.