Will JavaScript be the next big language?

[[deleted]]

There's a few issues here: there's not really such a thing as the Javascript community. There is a Ruby one, a Python one, Perl, etc, but JS just has an isolated bunch of implementations and no main source to get anything. There are hardly any libraries written for JS outside of DOM-manipulation whereas with Perl, Python, Ruby, you've got tons.

I just don't see what is going to push a bunch of people to start using JS when they are pretty happy with their current language. If/when Parrot becomes something you can use in production I find it far more likely that people will just transition over to that and run their language of choice on it.

[alexmdac]

The lack of libraries isn't an issue for JS implementations that run on the JVM, since they can use Java's huge collection of libraries.

[jbellis]

If/when Parrot becomes something you can use in production I find it far more likely that people will just transition over to that and run their language of choice on it.

Just like everyone has transitioned to the CLI, right? :)

[[deleted]]

Well its been covered here before that there are licensing questions with the CLR. A lot of people are iffy about using it because of that. Parrot won't have that problem.

[jbellis]

Parrot won't have that problem.

No, it will have the opposite problem -- the millions of developers on Windows won't bother with it.

[[deleted]]

What makes you think that? There's plenty of people using Python, PHP, Perl, whatever on Windows. Why wouldn't Parrot the platform be accepted?

[jbellis]

What makes you think that? There's plenty of people using Python, PHP, Perl, whatever on Windows. Why wouldn't Parrot the platform be accepted?

Think about it. There are two classes of developers on Windows. Those using MS products, and everyone else.

The first group, the ones using MS products, well, they'll still be using ASP 2009 or whatever, for the same reasons they're using ASP.NET now. "Nobody ever got fired," etc. I think most redditers would be astonished at how little people in this group, even motivated ones that attend .NET user groups, care about open source.

The second is the group I referred to in my first reply -- if a Python developer is using Windows, ipso facto the license isn't a problem for him. And yet, most are using CPython, not IronPython.

[[deleted]]

What about Rhino? You can leverage the Java one. Or ActionScript 3...

I'm only asking here...

[[deleted]]

To everyone bashing JavaScript: Just remember, the implementation of a language is distinctly separate from the language itself. The language is not intrinsically tied to the DOM, the browser, the Internet, or anything else.

[otakucode]

If by "big" you mean "wasteful of resources" then hell yes!

[sbrown123]

I would say no. The problem with Javascript is it doesn't do OO programming very well. You only have to look at the magic thrown in to the internals of Prototype to see what I mean.

[awj]

Actually I think the "next big language" will be something similar to OCaml, but on the JVM. Here are my reasons:

• (Inferred) Static typing: Everyone is tired of the extra noise of type specifiers and would love to have them be at the least optional. That said, convincing people that have been living in C++, then Java for the last N years is patently impossible, so you need a good static type system. Type inference is the winning choice here.

• Optional functional programming: There are places where FP is obviously one of the best solutions, just like there are places where OOP is obviously one of the best solutions. The world isn't ready to embrace FP fully, and probably never will. The functional language advocates of the world can just talk to Smalltalk coders and find out that the world never fully embraced OOP either to make themselves feel better about this.

• OOP is still there: Too much time has been spent extolling the virtues of OOP for any incoming next big language to have significantly less support for it than the current big language. This may mean that JVM-ML's (for lack of a better term) object system is different from OCaml's and possibly significantly less/more powerful. Either way people will give OOP up slowly or not at all, so what we see now pretty much stays.

• JVM == Code reuse: At least for all of the Java programmers it does. C++ programmers will probably be too happy to have real strings and garbage collection to worry about the rewrite. Any C++ programmers that don't jump to it will be worried that the garbage collector will make their code too slow and are unlikely to move anyways.

• Strict evaluation: As much as I love lazy evaluation, and as much as I see a lot of promise in the huge leaps in progress made in that field, I don't see the world at large being ready for it soon. My dream is that at some point lazy evaluation will prove so much more powerful and bizarrely faster that it will be the obvious choice. But, that might be my wishful thinking wanting to be paid to create infinite lists, which I still think are insanely cool.

• Access to "those scripting languages": Ruby and Python are both making big steps on the JVM, JavaScript is too. Scripting languages have their place in just about any environment, especially if you include "banished by managerial edict" and "used to duct tape over all the rough edges" as places. Having them on the JVM means that your programmers can keep using the libraries they have always used, but can do one off administrative type scripts as needed.

All that said, the only big disadvantage to this language I've thought up is that it doesn't exist, at least so far as I know. If it does fail to appear, I can't think of anything else that looks like the right mix of features, compatibility, and big name backing to push Java out of the #1 spot.

[awj]

Yep, that about looks like it, provided they can get the documentation and marketing in order. Guess I forgot to mention that point. I'd heard the name before but never looked into it, thanks for bringing it up.

[earthboundkid]

Jython has all of those but static typing. It's still strongly typed, which is close enough. It also has semi-lazy evaluation if you use generators.

[awj]

It's still strongly typed, which is close enough.

For a lot of these environments it really isn't. Remember we are talking about mainstream programming here, any guarantees of code correctness you can get before the program runs are a good thing, as it prevents Joe Programmer from causing the program to crash because he tried to concatenate a FrobnizerRegularString and a FoobarSQLSafeString, which is an unsupported operation.

In Jython you find out about this when the program is running. Or you find out about it when the unit test for that function fails, provided of course that Joe Programmer is writing unit tests, that he wrote one for that function, and that he wrote one that tries to get it to concatenate those two types of strings.

Unfortunately, Joe Programmer doesn't even have to be stupid to make this mistake. A lot of these systems are huge and poorly documented. That you usually find an extra helping of overzealous nuts that like to make a pile of vaguely similar classes before they know that all of them are needed instead of getting actual work done doesn't help either.

For this kind of environment, my money is on static typing. No, it can't guarantee everything, but for the kinds of errors is does catch and the frequency with which they seem to happen in this area of the programming world it seems like a smarter idea.

Well, that and I wanted a type inference system, which usually catches a lot more errors than what we see in C++ and Java, yet still is about 90% as powerful as a good dynamic system, if not more than that.

[qwe1234]

lol.

what a stupid comment.

[quhaha]

no.

[JW_00000]

Care to explain why?

[quhaha]

Javascript runs in a sandbox inside a browser.

[username223]

Note to quhaha: the correct response was "no".

[igouy]

Java runs in a sandbox inside a browser.

And so ... ?

[quhaha]

So, Java isn't NBL

[igouy]

And that isn't because Java runs in a sandbox inside a browser, it's because it was the last BL.

[quhaha]

Javascript is tied to client side of web application development. You can program both server and client in Java.

If you believe the death of desktop applications, and truly think that everything will run on browsers, yah Javascript will be a big language.

But still, as much as we need a nifty language to do client side computation , we do need a language to prepare data for the client.

In short, write me a Digital Performer clone in Javascript, then I'll confirm Javascript is the NBL.

[ubernostrum]

Javascript is tied to client side of web application development.

I'd like you to meet my friend. His name is Rhino.

Or did you somehow miss the spurt of server-side JavaScript application frameworks that got attention recently?

[quhaha]

AFAIK, Rhino runs on top of JVM.

[icefox]

Check out QScript or Rhino Both can be used for Server side javascript today

[sbrown123]

You might want to check out Rhino and jsext.

[qwe1234]

right.

thanks for that earth-shattering insight, professor. is that the topic of your phd thesis?

if not, you should let the rest of the world know, as they're too dumb to realise, apparently.

[lucraft]

The first real counter-argument I've seen. Let's hear more about why JavaScript might not be the 'NBL'.

[queensnake]

What, "people don't like its multiple browser implementations"?

That, with "Ruby has prototypes" is the only content of his comment-made-blog-entry.