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?"

Going down in flames

[Anonymous Coward]

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!).

Adapt or die

[Telek]

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.

Well..

[stevenfuzz]

I'm a c++ / Java guy that has worked with dhtml for around 10 years. The answer is both simple and complicated. For the most part, as you have realized, JS is a very dumbed down Java like language. It is about as strict as PHP (not as forgiving), and you can easily get going in the wrong direction trying to do seemingly simple things (like, getting the value of a select box). For the most part you can fake OO and more or less port over best practices from it's stricter big brother. I more often than not attempt to take the same approaches for JS as I would Java (albeit, it is not always possible or correct in the ways you are used to). Obviously you are not going to be setting up abstract classes or casting complex integers, but the pragmatics of programming are non-the-less the same. In fact, as a simple scripting mechanism over the dom, you shouldn't have to do any complicated data structure work (this is what the back end if for). So, the simple answer is to keep it simple, the complex answer is to attempt to follow best practices and use as little javascript as possible to achieve the desired effect. Just be glad you are not learning this 5-10 years ago, you would be spending half your time testing between browsers and the other half making your JS code look hideous.

should get you started...

[VoidEngineer]

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.

My tip

[bonch]

My tip is to never let yourself remain attached to a particular subset of languages for 20 years. Absorb all crazy things, because it makes you better in all languages.

Try LISP sometime.

Dynamic typing is paradise. As is static typing.

[Qbertino]

I'm just going the other way. Building my first app in C++ using Qt. Which basically goes like this: OMG you piped a literal string without it being a genuine QString into my label ... KERNEL PANIC! CRASH! 10 bazillion compiler errors. ... WTF?
Of course this sucks. However I'm well seasoned enough to know that when building a non-trivial application, it's exactly this sort of thing that will save my sanity in the long run.

With dynamically typed languages it's the exact opposite. Try building an IDE in JS. It has been done, but it need a solid amount of thorough planning and the one or other hack/stunt. However, writing a little script in JS is like having awesome sex compared to doing the same 'three-liner' in C++ which is like masturbating with a cheese grater in comparison. And still uses 30 lines.

All I can say is go with the flow. Wrap your head around dyn typing if you are not used to thinking in it and eventually you'll see the beauty in JS which blows C++ out of the water in the areas it is meant for.

Keep up with the spirit and good luck. ... And now excuse me, I have to set up my little QWidget 20-something lines of code with 20 typecasts strewn about just to get the bloody label to show a simple literal when I click a menu entry.

My 2 cents.

Go with the flow, my man

[multipartmixed]

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.

Re:Adapt or die

[Threni]

That's why he asked the question.. Do you have an answer?

Here's an example

[gr8_phk]

How does the code look that much different? Besides some syntax differences, they're all almost *exactly* the same. Some languages force you to format your declarations and types differently, but a for loop is a for loop

for (x=0; x lessthan 10; x++) //sorry, can do lt in comment
{
square[x] = x*x;
}

That's a for loop, while this:

square = [x*x for x in range(10)]

is a list comprehension in Python.

You can write it like a for loop - and I did when I was first learning Python - but it sucks to do that. This is probably what the GP was alluding to. If you really know a language you don't want to read crap written by people who think they're all the same with different syntax. This of course is but a single small example.

Re:Dart?

[Lord of the Fries]

Interesting term. I can clear up the guesswork on why the type system is the way it is a little bit. Lars Back and Gilad Bracha, two of the primaries for Dart, came out of the Self group. Self was an interesting Sun funded experiment where they took the "pure objects all the time, all the way down" ideas behind Smalltalk and took them to a new level by throwing out the classes as well. One of the things pursued was a dynamic method dispatching system, that while dynamically typed (this is different than untyped), could get as much mileage as possible out of run time navel gazing to dynamically optimize the execution. There are some good papers describing how cool some of the stuff they did was/is. This group already liked the idea/value of dynamic languages, and have since been involved in various projects all built around this idea: take a dynamic typed system and make it go fast. Strongtalk was what followed. And then Sun bought them back and their work became the HotSpot VM. And Lars built an embedded Smalltalk along the same ideas in the meantime. While doing prison time with Java, Gilad began Newspeak (a module happy variant of Self/Smalltalk/etc). And Lars helped with the V8 JS engine that everyone knows well about. Along with all of this, all the way back to Strongtalk, they've always held that while a runtime system should be entirely dynamic (e.g. no hints required from a static type system), they see great value in being able to express types from a documentation/communication pov within the code. So the type systems, that any of these languages have had (which all share these similar values) have always been for expressiveness only. Personally I don't agree with this, but it's an interesting position that I've always tried to appreciate.

Re:A language that compiles to JS

[Belial6]

That would contradict the point of his request. The only real answer is the first one given. Don't try to make it what you know. If you want to have skills in a language, learn the language. I could say that I can write code in Machine Code because my because my C compiler outputs machine code, but that doesn't make it true. If DocDyson learns HaXe and compiles to JS, he doesn't know JS he knows HaXe. His request for a good IDE is a valid one. His request for some good libraries that will smooth the learning curve is valid. A request for libraries that will make JS more like C is not valid, as it will not only prevent him from actually learning JS, but it will be useless in an environment that he doesn't have primary control of. If you want to be competent in JS, you have to learn the JS way.

Re:Going down in flames

[Anonymous Coward]

I use Javascript as an Object Oriented Language.

While in Rome, do as Romans do. Unless you are stupid.

Then there are the lack of proper IDEs, good debuggers (Firebug pales compared to a real C++ or Java debugger), and the many other tools that a C++ or Java programmers expects to use.

Lack of a good debugging and testing environment is the only reason Javascript is goddamn annoying.

Sure ... The first thing you should do is

[hey!]

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.

You have a clear anti-JS bias.

[Static]

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.

Re:Going down in flames

[Anonymous Coward]

The most telling thing about JavaScript as a language, and the community that surrounds it, is that the most widely-respected book is "JavaScript: The Good Parts". It's a book that basically tells you what parts of JavaScript never to use!

Compare this to the most respected books about other programming languages. I'm talking about "The C Programming Language" for C, "The C++ Programming Language" for C++, and even "Programming Perl" for goddamn Perl. They're the complete opposite. They explain each and every feature the language offers, and how to use them effectively.

Something is seriously wrong with a programming language when the most useful books about it are those telling you to not use large portions of the language!

Re:You have a clear anti-JS bias.

[Anonymous Coward]

Your post reads a lot like all those people who hate PHP.

So he's an experienced professional software developer who cares about the reliability, performance, maintainability, correctness, portability, and the overall quality of the code he writes. That's not a bad thing at all. You should listen to him. What he wrote is absolutely right.

Your are clearly too rational to be here...

[snowgirl]

Please get off the intarwebs... your clear and concise explanations of matters is undesired here in this wretched hives of memes and flamewars.

Seriously though, you're totally right. It's different. It's not inferior, it's different.

People who complain about this or that language being a piece of crap because of X and Y, are usually deadset in one particular mode of thinking, and cannot adapt. The question the original author should have been asking was not "how can I make this tolerable", but rather, "how can I best learn the correct way to use this tool?"

To put things in perspective, I was already doing a lot of crazy command-line parsing before I ever started using C. And when I started using C, I was upset, because I knew what I wanted to do, and I could easily accomplish it in BASIC, but C was different. The whole paradigm was new to me, and I had to learn to adapt. I haven't forgotten that, and I try to keep myself from becoming entrenched in any particular mode of thinking... it leads to inflexibly dictating that all else is inferior.

B0rked closures is enough for JS loving?

[Anonymous Coward]

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.

Re:Your are clearly too rational to be here...

[shutdown -p now]

It makes no sense to claim that programming languages can't be meaningfully compared with respect to things like efficiency, conciseness, level of abstraction etc. It may be politically correct (towards VB/PHP/JS crowd), but it's still false.

Yes, languages differ. Yes, there's no single one that's the best. No, that doesn't mean that your favorite language is just as good as mine (unless your favorite language is Common Lisp).

Re:Why?

[hibiki_r]

Dynamically typed languages almost demand a large unit test suite to minimize quality issues. TDD and all that. If you are going to do that anyway, the dynamic language's weaknesses don't come into play as much, and you get the advantages, like typically needing a whole lot less code to get the same thing done. Look at Groovy, for instance: You can typically reproduce a Java program in half the code, and that if you are not facing one of those problems where dynamic typing really makes your life dramatically easier.

Re:Going down in flames

[justforgetme]

I have learned to program in about a dozen programming languages over the years plus many frameworks for some of them. I can;t claim to be proficient (or efficient) in all of them but what I can claim is this: The only languages/frameworks I have no headaches about are the ones I have drilled down on and put an effort into understanding at the most involved level they allow.

In most cases it's not the language but the attitude/predisposition that creates problems.

Re:Any rational programmer is anti-JS

[rmstar]

Actually, C++ has it since C++11... but with typed arguments of course:

C++ closures are what happens to a beautiful abstraction after it goes through mordor. It becomes an orkish, vile thing more fit to hurt the user and confuse him than to achieve something of good and beauty.

I mean, where's your GC?

Re:Going down in flames

[elp]

Jquery is simple to use and "just plain works"(tm). Trying to manage ajax queries on multiple browsers or work the DOM yourself sounds way too much like advanced masochism to me.

Re:Going down in flames

[somersault]

If you think JQuery overcomplicates things, maybe you're using it wrong?

The whole idea of having to put browser-dependent fixes into my JavaScript was what turned me off of doing any fancy UI stuff for a long time. I first looked at it around 2002 and was sickened by the whole incompatible browser DOM mess such that I didn't look again for years. Having all that crap hidden away behind JQuery helps to make it almost like "normal" programming again. Though even then there are still things that IE messes up..

If you feel that JQuery is making things less readable, why not wrap the JQuery stuff in your own functions? That's what I did for the AJAX functionality that I've built up.

Re:Going down in flames

[julesh]

Stop using jquery and you'll find that half of your headaches are gone automatically. Javascript can brain-dead simple if you know how to use it -- and it can be a gigantic headache when you use it incorrectly. If you think jquery makes your life easier, you're clearly using it wrong.

Sorry. I cannot agree here. Jquery enables some of the most elegant web programming I have ever seen. It allows, among other things, almost total separation of program logic from content -- I can use an entirely declarative approach on content elements that I want to be active, and then have a separate .js file to hook up the declarations and the actual logic behind them, trivially:

$(".hideable").before(function () {
    var hideableElement = this;
    return $("#showhidecontrol").clone().click(function () { hideableElement.toggleClass("hidden"); })});

(doing this from memory, untested, but I'm pretty sure it'll work)

Do that in three lines of code without jquery or another of the libraries you claim to despise. Hell, do it in 30. For reference -- it finds the element with id 'showhidecontrol' from the existing document and places deep copies of it before each element with class 'hideable', adding an onclick event handler to it that adds the class 'hidden' to the element with class 'hideable' if it isn't already present, or removes it if it is.

Re:Going down in flames

[narcc]

That makes my point, doesn't it? It's non-obvious what the code does, even if you're familiar with jQuery.

To really understand it, you need a practical knowledge of jQuery, html, css, and ... (wait for it) ... the hard parts of javascript that you're trying to avoid learning about and using in the first place!

(Oh, and if you let me make my own versions of the before and toggleClass functions I can do that in javascript in well under 30 lines of much more readable code.)

Re:Going down in flames

[Assmasher]

$(".hideable").before(function () {
        var hideableElement = this;
        return $("#showhidecontrol").clone().click(function () { hideableElement.toggleClass("hidden"); })});

I'm sorry, but you're simply giving credence to what he's saying with something like that.

I would never let one of my engineers check code in that looked like that (much less do it myself.) Talk about a lack of clarity, lol...

Re:Your are clearly too rational to be here...

[Alex Belits]

web

Here is your problem. Javascript is an awful language, it just by the whim of Netscape it is the only one available in a browser. This does not mean, Javascript is good, it means that Netscape fucked up, and no one was around to fix the problem because everyone was busy fending off Microsoft and Adobe, who tried to "standardize" everyone on things that make Javascript look good.

A good solution would be to use Java or C++ with Qt, and distribute the application with sources (and everyone who opens his mouth about revealing the source code is welcome to shut up because Javascript is always distributed in source anyway). This may be an overkill for something as simple as a widget for displaying lists/icons/graphs..., but for a complex application Javascript is still a bad language.

Same applies to writing "for consumer PC" and Win32/.NET/other horrible things from my "favorite" company.

Re:Your are clearly too rational to be here...

[TheRaven64]

I'll prefix this by saying that Javascript is not my favourite language, although I have written a compiler for a dialect of it and an Objective-C compiler that emits JavaScript.

A lot of what you're talking about has nothing to do with the language and everything to do with the libraries. Given a DOM binding and a function for generating asynchronous HTTP requests, everything that you request is pretty trivial in most high(ish)-level languages and would almost certainly perform better. Writing a fast implementation of JavaScript is insanely hard. One of the big reasons why it is easier to make Java perform faster than Smalltalk - in spite of the fact that the two have a lot in common in terms of memory and object models - is that Java has integer types, so a + b can be compiled to a single add instruction by a naive compiler, while doing the same thing in Smalltalk requires you to perform some nontrivial type inference. In JavaScript, it's even worse because integers must transparently overflow to double-precision floating point values.

It would almost certainly be more maintainable too. JavaScript was intended for scripting, not for writing large applications. It lacks any module feature - or even classes. You can split a JavaScript program into multiple files, but then including them in a different order can significantly alter the semantics of the program. In other languages, you can separate independent parts into separate components and not, for example, pollute the global namespace with local concerns.

Re:Going down in flames

[Assmasher]

Why not?

Well, it is unsafe, is anti-reusability, unclear, and impossible to debug without rewriting it to see why it doesn't work or suddenly stopped working. Defining a function inline to your statement, and in that function performing evaluations in your return call that are based upon objects that may be null when you execute an operation on them?

There's no need to go verbose for verbositys sake, and that piece of script is pretty neat.

There is a need to go verbose for the sake of everyone else who may ever have to work in the same codebase.

If you place a completely green web-developer in front of it, sure, he might have a hard time reading it, but if jQuery is a tool you use, and webdevelopment what you do, then this really shouldn't be much of a problem at all.

I'm not trying to denigrate you in any way, but this type of attitude is the difference between programming and software engineering. It is the discipline to do extra work that is tangibly less fun than doing clever or fun things.

I don't enjoy long variable names.
I don't enjoy modified Hungarian notation.
I don't enjoy seeing an obfuscating and clever way to manipulate something but then do it a more plodding and clear (if equally efficient) way.
I enjoy software architecture, but I don't enjoy writing up the design.
I don't enjoy the ridiculously long meetings involved in matching up the design to the spec to the requirements.
I don't enjoy putting in long comments to make absolutely sure someone coming in to fix a bug in the future is aware of the caveats of the possible changes they could make.

I do these things because I need to do them for the sake of the codebase/product/Company/Investors.

Re:Your are clearly too rational to be here...

[shutdown -p now]

Now how easily would you create an asynchronously interactive web site without javascript and how would it perform?

You need to define what a "website" is for this to work.

The problem is that "website" is, effectively, defined by W3C. And W3C, in their infinite wisdom, standardized on JavaScript as the scripting language for the web. So, as of today, the definition of website essentially includes JS, and excludes other languages, making any such comparisons irrelevant.

We came up with some workarounds for that, like X-to-JS compilers. Unfortunately, because the end result is still JS, this approach doesn't let you actually realize the performance benefits of a statically typed PL on VM level, since all types are erased by the time code is running.

However, it is perfectly possible to do a "what if?" - take some other PL, and see how well it would fit into the niche occupied by JS today. And if you do that, you suddenly realize that practically any mainstream dynamic language, excepting possibly PHP, would do all the same things better.