31–40 of 52 posts
I'd like to see a statically typed language available. There is relatively little I do that requires dynamic typing, but so much of my experience would be better with static typing. I'm not saying to get rid of JS, but it would be nice to have a first class alternative.
Frankly I really like JavaScript. I don't want the language to change, even though it has its flaws. I just love the ability to have data-structures as simple as objects and arrays which have evolved into a standard data exchange format (JSON). Then you can also have functions inside objects and everything becomes really flexible and really easy to design. I've tried many different languages, including the real prett…
However, people are now using JavaScript for development that far exceeds those uses. JavaScript is just not suitable for larger applications.
Once your application starts exceeding a few thousands of lines of code, the problems become very clear. You soon wish you were using a language like C++, Java, C#, Python, or Ruby. Toss in a development team made up of at least several people, if not more, and the pain becomes far greater.
Frankly I really like JavaScript. I don't want the language to change, even though it has its flaws. I just love the ability to have data-structures as simple as objects and arrays which have evolved into a standard data exchange format (JSON). Then you can also have functions inside objects and everything becomes really flexible and really easy to design. I've tried many different languages, including the real prett…
That flexibility is indeed useful for scripts and adding minor interactivity to an otherwise static web page. However, people are now using JavaScript for development that far exceeds those uses. JavaScript is just not suitable for larger applications. Once your application starts exceeding a few thousands of lines of code, the problems become very clear. You soon wish you were using a language like C++, Java, C#, Py…
http://npmjs.org/ is a list of solid software (also large software) written in JavaScript.
So I don't think your statement, about maintainability being connected with how flexible a language is, can be proven to be true.
That said, Apple is making it really hard for developers to choose it for all but intranet apps (for which it's really well suited).
I second GWT and the responses here have prompted me to look into CoffeeScript, so thanks for asking this!
Earlier quoted context omitted.
That flexibility is indeed useful for scripts and adding minor interactivity to an otherwise static web page. However, people are now using JavaScript for development that far exceeds those uses. JavaScript is just not suitable for larger applications. Once your application starts exceeding a few thousands of lines of code, the problems become very clear. You soon wish you were using a language like C++, Java, C#, Py…
I was never able to personally judge that statement. My experiences show that the flexibility of JavaScript only improved maintainability of the software written in it. http://npmjs.org/ is a list of solid software (also large software) written in JavaScript. So I don't think your statement, about maintainability being connected with how flexible a language is, can be proven to be true.
I'm talking about real software systems with, at a very minimum, tens of thousands of lines of code. More realistically, we're talking systems with hundreds of thousands, if not several million, lines of code.
C++ can scale up to codebases that large. Java and C# can handle it, as well. Even Python and Ruby can, if care is taken. JavaScript cannot. You'll be hitting numerous maintenance barriers far before then, when you're still well under 10,000 lines of code.
Earlier quoted context omitted.
An example that shows that Javascript wasn't designed for performance: it doesn't support integers. They can be used in some Javascript implementations that do smart tricks to convert float arithmetic to integer arithmetic, but it is not reliable. If you were designing a language for performance in the first place, this would be a ridiculous method to get access to integers. Same for dense arrays. Yeah, JS is pretty…
Dense arrays are coming in Harmony, thanks to WebGL. (JS.next) CoffeeScript incurs no penalty when compiling to Javascript; in fact, in many cases it's faster than handwritten code.
Why is JS not "reliable"? Any language can be a JS alternative. Do you mean you want an alternative language that runs natively in browsers?
"alternative language that runs natively in browsers" That's already been done: http://code.google.com/chrome/nativeclient/
Earlier quoted context omitted.
I was never able to personally judge that statement. My experiences show that the flexibility of JavaScript only improved maintainability of the software written in it. http://npmjs.org/ is a list of solid software (also large software) written in JavaScript. So I don't think your statement, about maintainability being connected with how flexible a language is, can be proven to be true.
By "larger applications", I wasn't talking about jQuery, Node.js or anything built upon them. I'm talking about real software systems with, at a very minimum, tens of thousands of lines of code. More realistically, we're talking systems with hundreds of thousands, if not several million, lines of code. C++ can scale up to codebases that large. Java and C# can handle it, as well. Even Python and Ruby can, if care is t…
I think your experience with JavaScript comes from reading code made by bad developers. If your software is written by good people it will be maintainable even in JavaScript.
To run compiled binaries from such languages you'll use Native Client http://code.google.com/p/nativeclient/ and Pepper APIs which let you access HTML5.
Go gets rid of some insecure low level things like pointers, keeps such things in an unsafe package to discourage its use. They intend to make it seamlessly compatible with NaCl. C/C++ code needs to be modified to work there.
JS is already not suitable for lots of stuff. Vendors are stretching its capabilities with big teams of fancy programmers implementing fancy VMs with big chunks written in assembler. At Google I/O they mentioned V8 is about as fast as it will get. Then bigger teams are writing massive APIs because even with fast VMs the language isn't fast enough to roll your own CSS/XAML/MXML/HTML parsers or 2D rendering contexts. So you're forced to wait or hack together things like LESS, CoffeeScript, Stylus in an attempt to communicate with the overlords.
With the browsers becoming the operating system for many users, you need a runtime that's as powerful as a regular operating system. Google and Mozilla are major players and it's nice to see them exploring alternatives.
But even if NaCl/Go is superior technologically, it may not overcome JavaScript's business and political momentum. As usual, technology is not chosen based on technological merit, but business considerations like legacy, lock in, etc. Perhaps NaCl/Go approach will succeed but it will be too little too late. Kinda feels that way with Flash and Browsers, they're finally serious platforms but might be too far behind Objective-C, C# and Java on mobiles.
I would like to see an alternative to the WWW altogether. WWW is no longer a collection of hyperlinked documents, which was its initial purpose but a multitude of technologies running on browsers that use HTTP in nonstandard ways because it's ubiquitous. HTML is getting obsolete, with the most popular websites being essentially javascript apps. Maybe it's time for a new system like Java to create cross platform GUI a…
HTML is not a bad layout engine for GUI apps. It may not have been initially been designed as one, but after 15 years of development it seems to be pretty pleasant to work with as there are people who want to build their desktop apps with HTML.
Obviously, the standard request-response model of HTTP is limiting for interactive apps. Bi-directional communication within request isn't possible and handshaking is a bit too expensive. But hey, this problem is actually solved: http://dev.w3.org/html5/websockets/.