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?"
Probably gonna get flamed for this, but my advice.. don't fight it! When in Rome.. etc.
Javascript isn't meant to be done like c++ or Java, so don't try! Think about the mess you get when an assembly guy tries his hand at Java. It's the same deal. It's a whole different mindset, and if you fight it you'll just end up with a big mess and a lot of wasted time.
That said, some stuff does transfer over. You can still go through proper requirements, design and testing. Basic principles like encapsulation and reuse still sorta apply (and are highly recommended imo). Before doing anything that seems like a common use case, check to see if someone has already done it (but don't blindly use it.. a lot of really shitty stuff out there.. but some gems too!).
I suggest reading this book, it's gotten a lot of good reviews, I've seen a lot of people recommend it to people starting out with JS.
It explains a subset of Javascript that's simple to use, and also the most used in practice.
My advice?
Scotch.
Lots and lots and lots of scotch.
Preferably something that burns horribly on the way down and leaves you with a miserable hang over. Only because you've got to look forward to something that hurts less than JS development at the end of the day.
Non impediti ratione cogitationus.
This depends - are you looking to learn the new coding methods to remain competitive in the workplace, or just for fun?
Honestly if you make a living doing this then you need to adapt. You need to get over your preconceptions and accept the changes to the way computing works. There are millions of programmers out there, if you want to stay employed you need to show that you're adaptable to the new technologies while applying all of the tried-and-true knowledge and experience from your past. It's hard enough to get a job when you're more than a decade out of school.
Trust me, I understand where you're coming from. I hate the inefficiencies of the languages these days. I dislike the general idea of doing anything other than a script in a scripted language. However my (perhaps anachronistic) viewpoints don't have many applicable places anymore. Unfortunately the tradeoff between RAD and proper coding often leans a little too far to the RAD side, necessitating the use of many types of languages and tools that you will undoubtedly not enjoy.
Not only will you be a lot more productive, but you'll be a lot more marketable if you just succumb to the "dark side" that is today's trend in programming languages.
If God gave us curiosity
While it won't get you over the loosely typed nature of the language, it will make things a bit more manageable. You can write nice terse code which accomplishes oodles, as opposed to hand rolling everything. There is something nice to javascripting. I find it a nice respite. JQuery makes it beautiful.
First, get thee Aptana for development.
Second, download thee jQuery. I would also recommend jQuery Mobile and jQuery.tools.
Third, dig around in jquery until you find qunit for unit testing.
Fourth, do a refresher on Lisp and functional languages. They say that javascript got it's fathers curly braces and it's mothers lexical scope. It may *look* like C/C++/Java, but under the hood is ActionScript ala Scheme ala Lisp. And it a very real difference which gets played out in copious usage of events and callback functions. As a refresher, the HTML5 paradigm is basically an MVC paradigm, where HTML is handling the Model, CSS is handling the View, and Javascript is handling all the controller functions. Phrased differently, the HTML is describing the What is displayed; CSS is describing How it should be displayed, and Javascript is describing When it should be displayed. And the When gets implemented as callbacks and events. And it just so happens that functional languages are ideally suited for that kind of work (ala lambda calculus, etc).
Lastly, if you're brave, check out Node.js.
On the topic of languages that complile to JS, GWT is very nice, especially if you're using a Java back-end.
Nan-in, a Japanese master during the Meiji era (1868-1912), received a university professor who came to inquire about Zen.
Nan-in served tea. He poured his visitor's cup full, and then kept on pouring.
The professor watched the overflow until he no longer could restrain himself. "It is overfull. No more will go in!"
"Like this cup," Nan-in said, "you are full of your own opinions and speculations. How can I show you Zen unless you first empty your cup?"
I have 20 years of C under my belt, 15 of those paid. I currently spend the vast majority of my time writing JS, and I love it.
Back in the good old days, we didn't pick C because of it's great syntax, or the warnings from the compilers (which have gotten much better in the last 20 years!). We picked it because it fast, portable (enough), available, and you could use it to do the stuff we were interested in.
Well, times have changed. JS and CPUs are now fast enough that execution time is not were "fast" usually matters: *developer* time is. JS syntax is good enough. Runtime warnings are getting good enough if you're writing ES5 strict code. Most importantly, if you're writing code for the web, you pretty much have to pick JavaScript. (Just like writing X11 code 15 years ago pretty much meant C++).
Syntax -- "go with the flow, my man". It's juicy, delicious. Don't be limited by the lack of types: embrace the flexibility. Prototypal inheritance is awesome in its simplicity, shallow object hierarchies make for easy reasoning. Make you *get* closures.
Functions are first-class members, like strings and arrays and objects. Sure, their literal syntax is longer than "", [] or {}, but function(){} is still a literal.
Just as the developer who thinks GNU make is some kind of super-shell is doomed to failure, so will the developer who thinks JS is a variation of something else.
JS isn't the new C. It's not the new Java. Or C++. Or Scheme. Or Perl. Or Python. Or Logo. Or BASIC. It's JS.
I currently write a LOT of day-to-day mundane code in JS. Some exciting code, too. I write web pages, validate forms, load modules (CommonJS), and design object exchange protocols and the applications which use them. That's on the web browser.
On the web server, I'm using it kinda like 1995's PERL. I query databases, do CGIs. I can call into POSIX. I write daemons, and "shell scripts". Some week I'll spend a few days and make my CGIs faster than CGIs. Remember mod_perl? Same deal. Mast fast_cgi. I dunno, performance metrics say I don't need to quite yet.
It's a hell of a language. But if you really want to work with it, you have to "get it". Be comfortable with it's multi-faceted layer. Understand that it's "functional", "object oriented", and "imperative", all at the same time.
In C, the Zen boils down to "everything is just a number". That's why string operations are so easy in C once you "get it". In C, the Zen boils down "everything is just a jsval". So, it's IS typed -- everything is the same variadic type. Get over writing reams of code to make your little soldiers walk the goose step, and just tell them where to go. They'll get there.
Do daemons dream of electric sleep()?
This is book is worth every penny and more (~$18 on amazon).
,closures, etc.)
Like the submitter, I come from C/C++/Java background and always despised Javascript whenever I had to deal with it. I picked up this book a few months ago and can confidently say that this book completely changed my view of Javascript. Javascript is a quirky language, and has some really bad parts (the book has a chapter dedicated to the bad parts). This book clearly explains common misconceptions about the language, as well as all the things a programmer used to a more traditional language needs to look out for. The book explains how Javascript works under the hood in great detail (the prototype-chain, functional scope, type conversion and equality, first class objects/functions
This is a book for programmers, it's not a cookbook or how-to, and you need a good understanding of programming for it to be useful. That being said, for programmers coming from more traditional languages to Javascript, this book is exactly what you're looking for. I can honestly say that in a few short months Javascript has gone from one of my most hated languages to one of my favourites. The language is incredibly powerful and expressive once you get a good understanding of how it works and why.
"Have you tried Dart? It's like JavaScript but with optional typing, and it compiles down to JavaScript."
If the typing is optional how do you actually program it? Voice recognition?
http://www.rootstrikers.org/
Stop building narratives like "I'm an X type of guy trying to do Y." That's bound to increase your frustration with what are most likely going to be the normal road bumps in learning to do things differently. Think "different tools and methods for different jobs."
Instead of asking "how do I make working in toy language like Javascript tolerable for *real* programmer like me," you should be asking "how do the very best Javascript programmers do what they do?"
And don't think of yourself as "dyed in the wool" anything. Think of yourself as a versatile person who likes learning about new ways of doing things, because you've got a *lot* more to learn than just the Javascript *language* if you want to actually *use* Javascript. You've got to learn about DOM and CSS and HTTP and web application architecture and security. Once you learn about those things and learn how to actually do something useful with Javascript, you'll be in a much better position to make an *informed* critique the design of the language, popular libraries and frameworks like JQuery, and common Javascript idioms. It makes no sense to approach mastering the whole Javascript ecosystem with preconceived notions about its shortcomings. You aren't qualified to judge yet.
Learning a new kind of tool means learning new kinds of skills and strategies. Some aspects of the tool will seem like major problems with the tool until those good habits become second nature. For example novice Java programmers tend to create code that allocates unnecessary strings inside loops, when they should be using a StringBuilder. The result is the programmer thinks that it's Java that's slow, when it's really their ignorance of efficient Java programming idioms that's to blame.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Your post reads a lot like all those people who hate PHP. "It has all these things wrong with it!" Well, actually, no it doesn't - because most of them aren't a problem to the people busy using it effectively. JavaScript doesn't have 'inferior' abstractions: it has *different* ones.
I have programmed a lot over the decades in both strongly typed and weakly typed languages - too many to name. I've come to Java in the last few years after a much longer time in JavaScript and PHP (and others) and have experienced the reverse of the OP's problem. But it's only a problem if you let it be a problem. Solving problems in an untyped language has some fundamental differences to a typed language. Get over that and a lot of the perceived 'problems' Just Go Away.
Java has better closures. Clunky, sure, but not broken.
Scala has better closures. Closures you can love.
Haskell has total awesomeness oozing out of its handling of closures.
Javascript is retarded in all ways. It's just flabbergasting that anyone defends it.
Javascript has closures and none of the other languages have them
All mainstream languages except for Java have lambdas/closures (and Java is getting them in the upcoming release).
For that matter, most languages that do have lambdas, provide syntax for them that is considerably less verbose than that of JS - which makes a lot of sense when you actually start using lambdas heavily. To give an example with fold used to sum a sequence (assuming fold is a member function in all cases, for the sake of uniformity, and ignoring the ability to treat operator itself as a binary function in languages that support it):
I guess C++ isn't a mainstream language anymore. Go figure.
Actually, C++ has it since C++11... but with typed arguments of course:
# C++
xs.fold( [](int x, int y) { return x + y; } );
Of course, both Javascript and C++ are still much less powerful than any variant of LISP.
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.