Slashdot Mirror
The Great JavaScript Debate: Improve It Or Kill It
snydeq writes "Recent announcements from Google and Intel appear to have JavaScript headed toward a crossroads, as Google seeks to replace the lingua franca of the client-side Web with Dart and Intel looks to extend it with River Trail. What seems clear, however, is that as 'developers continue to ask more and more of JavaScript, its limitations are thrown into sharp relief,' raising the question, 'Will the Web development community continue to work to make JavaScript a first-class development platform, despite its failings? Or will it take the "nuclear option" and abandon it for greener pastures? The answer seems to be a little of both.'"
In my opinion... kill it! Kill it with fire!
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Because it's awesome.
Leave the web for documents. Run applications natively. Why is this so hard?
Give me Classic Slashdot or give me death!
Please, kill it with fire! And maybe some brimstone too.
What failings? I believe that there are some, but why not mention what they are, instead of just throwing it out there as an abstract concept?
Also, it's clearly a reasonable programming language. It's not logically broken and it's quite usable, so how can there be actual limitations? It can modify the DOM in any way a programmer could imagine. What's the problem? Performance?
Kill it, bury it, salt the earth.
If someone wants to add to its mission, or write a client-side language with a different mission, go for it.
But a lot of the web is running nicely with JavaScript, and pulling out the JavaScript rug from web developers and website owners is really not an option.
Let's call for some pragmatism here, shall we?
Steve Magruder, Metro Foodist
B L O O D !
This summery throws into sharp relief the typical misconception of Javascript. The language is not the limiting factor, its the browsers that implement it. Dart will do nothing more then fragment this even further.
Patching it is the easier route and the one that will happen, because it is what people will accept. Look at nearly all Internet standards that we will see that is the case. SSL/TLS, IPv4, HTML, SMTP, WEP (is still supported by nearly all wireless APs) etc. Has an Internet standard EVER been successfully killed?
Now we can all switch to using Javascri... oh. Crap.
This signature can save you $400 on your car insurance!
If there's a greener pasture, someone with resources similar to those possessed by the original javascript developers would be seeding it.
Now, knowing what we know about how fugly Javascript is, the question is: why hasn't anyone replaced it yet?
I like Javascript, it allowed me to code without having to install big fancy development platform. Given how widespread it has become, I fail to see how killing it make any sense. I don't care about dogma, I care about reality.
Replace it with some kind of VM. It's ridiculous that the entirity of the web should be forced to be written in some baroque monstrosity (or, in the "best" case, get compiled to that monstrosity).
JavaScript was meant to manipulate documents, and is used to make those documents into applications.
Lets just throw out HTML altogether and come up with a new language to make the client side section of web apps with. HTML was never envisioned to do this.
Why back in my day when we discussing whether or not we should increase our websites standard aspect ratio from 640X480 to 800X600, we hated flash then too...but designers loved it cause it was pretty.
I know I'm going to get banned from /. for all time, but can we talk about something like Silverlight please? It's a dream to program for and it does all the stuff that we wish javascript did. Ok, begin anti-M$ rhetoric.......now
HTML with CSS is nice if you want formatted documents, but it's a horrible GUI kit.
If you want to replace JS for the sake of its limitations, then use java or C#. Both are fully grown languages with all mechanisms and tools you would ask for, a huge programmer base, good JIT implementations and an awesome amount of code already written.
If you have another agenda, i cant help you.
I decided it would be a neat hack to flood my living room and turn it into an indoor pool. Boy, did that reveal some serious shortcomings in my home's electrical system. Can any recommend an electrician who doesn't suck as bad as the guy who installed the one I have now?
I've always been a fan of JavaScript, so I'm all in favour of giving the language a few minor updates to squeeze more functionality out of it. Frankly, I've never understood why some people have such a hate-on for the language. It does what it was designed to do and, in my opinion, it does its job well. I've written tens of thousands of lines of JS over the years and have yet to run into any serious problems.
Fuck you! You can't tell me what to do!
People keep figuring out how to do even more with JavaScript, forgetting that just because you can, doesn't mean you should.
With the rise of several good frameworks in recent years, such as jQuery and MooTools, working with javascript has become much much easier. But still the language itself is a freaking mess.
Take out JavaScript and take out the browser entirely, replace it with a Swing Applet.
At this point buy a gun and lots of ammo, because you'll need it to fight off the zombies.
You can't handle the truth.
I used to hate javascript. I'd disable it in my browsers up until a few years ago and avoid it like the plague in all of my web development tasks. A year and a half ago I became a full time web developer.
I had to shut up and learn to love javascript, and I really do. There's nothing wrong with it.
A language like PHP3 lacks enough features to make many common patterns possible. Progressing to PHP4, and PHP5, more and more patterns became possible. PHP can now house proper code, though it frequently doesn't because people still hack away like it's PHP3 or PHP4
To me, javascript feels much the same way. I never come across a pattern I can not implement, though I see a lot of coding that ignores standard patterns to it's own demise. linq.js, underscore.js, jquery, and some in-house libraries make classes, objects, collections, DOM work, etc, amazingly simple. The standard library is very poor, but that's ok because the 3rd party libraries are fantastic. Outside of IE8 and under, the speed is FAST too.
A lot of times there's a function that will be implemented by a library but can optionally wrap to a native function if available, making support for everything universal.
Let's throw out everything in the world which has become something it was never envisioned to be.
It can stay as long as it gets the OpenGL ES treatment where it is stripped down to only the essentials. There are some very good things about ECMAscript but there are also horrible fire breathing dragons hiding just out of sight...
Clojure has excellent language design and parallelism and the team recently released ClojureScript. A video introduction can be found here.
I wouldn't mind if they added Lua to web browsers.
There comes a time when you adapt something so far, that it is clunky and frustrating to use in its new role. Its time to throw it out and make something that is designed to do what we want it to.
Rocks worked well enough to hammer things for a long time.
Then we invented hammers.
Give us a static strongly typed alternative/extension without the literally hundreds of known design flaws.
How about a Javascript that's more Java-like?
We could just program javascript on the client and the server. Then no programmers ever need to learn new languages, and we can try to dumb-down Computer Science as a whole. That means cheaper programmers, simpler outsourcing, and less management headaches.
If anyone sees a problem with this, please stop forcing javascript into the server-side. Can't we improve server-side development, not make it worse?
Fork it. Fork a compiled version specifically for web apps.
Mix in some of the abilities of Java and JavaScript, compiled, problem solved. Just don' tell Oracle...
The real problem is the idiots designing and implementing the spec taking a god damn decade to get stuff done. IF THAT.
W3C, even WhatWG, the problem is there. JavaScript is completely capable as a language. Just because idiots complain, doesn't mean it is terrible.
But the very structure of HTML itself is the worst part. Filled with a bunch of nonsense that doesn't need to be there due to terrible specs being attribute-complete rather than not storing things at all and just parsing that as "default".
This has resulted in relatively simple pages reaching ungodly filesizes as more and more attributes get added.
Seriously, what is the deal with that?
I don't entirely see the problem here though.
Web workers, WebGL, they can run games at decent speeds with fairly decent graphics and FPS. (see quake 2 JS)
Web pages are also being hardware accelerated now.
JavaScript itself is a fine language. Very extendable.
The only annoyance is its inability to store binary data, resulting in the next best thing, Base64* encoding at 133% ~filesize per binary chunk, to be used.
If you don't care so much for portability, binary data can be stored pretty well in media files and opened and scanned.
* on that note, hasn't anyone came up with a larger encoding system that takes advantage of countless other characters that can be represented in pretty much all languages without screwing around with escape characters, or differing language sets lacking those files or whatever?
Why did we settle on Base64? Surely those 2 extra characters aren't the only characters left that are useful for encoding in plaintext?
Who needs javascript now that every website ends up being rewritten in Objective-C?
lucm, indeed.
It would be great if they could evolve it in the direction Adobe did with Actionscript 3.0. That is a nice little language.
The biggest problem, though, isn't Javascript; it's the horrible API and document model it has to struggle with when doing anything in a web browser. That would make programming in any scripting language a nightmare.
I am hoping for another Google project: Native Client (NaCl).
What we need is not yet another language with a new set of limitations. Instead we need a system that allows any language, even ones not invented yet. And without waiting for every single browser out there to update to the most recent language specification. Without having to program for every bug in every browser.
Native Client solves this by allowing binary executables and a standardized byte code (LLVM) as alternative. You can code in assmbly, C, C++ or any other language you prefer. And it is still as secure as JavaScript. The execution environment is double sandboxed and secure in a very robust way.
I think many people are missing the point of Javascript.
The new spec includes the ability for Javascript to open sockets. Once that takes hold, you'll have the ability to completely control the browser window from the home server.
When that happens, it will be big. The browser is essentially a rendering machine which makes it trivially easy to show things and is largely machine independent. Instead of selling a huge monolithic program, companies can simply sell time on their servers to run their programs.
Imagine that you want to use a big engineering program - Orcad or Altium Designer, for example.
Instead of paying $10,000 for a copy of the program and taking a chance that it's as good as it's marketing claims, you can buy a month of usage for $100, and the executable will run on the company's servers while using your browser to paint the screens. Sort of like how World of Warcraft runs on servers, but paints the screens locally.
This has many advantages for the user:
1) You don't have to risk an enormous sum of money to try something out
2) You don't pay for the product more than you need it
3) You have NO installation issues
4) You are always using the most up-to-date version
5) The vendor can keep backups of your files for you
6) You can access your files and the application from anywhere on the net
And for the vendor:
1) The code is never given out (only runs on the server): no piracy!
2) You don't need multiple versions for different architectures (reduced engineering)
3) You don't have to push updates to the users all the time
4) You can tune the compilation/installation to make the best use of the server
5) Rendering is much easier - the bulk of the code is written for you by others (reduced engineering)
There are some disadvantages - the vendor has access to the document, which means that they can also sell the document to spammers (designs to China, for example). This can be dealt with by using a trust model; ie - the company will have an online reputation which will get quickly tarnished once this happens.
That's the promise of Javascript, and the real potential of the cloud. Companies supplying online services to compete for customers.
The design flaws are terminal. It deserves to be replaced with something that is statically typed.
If you want to keep it around for a few years as a legacy thing, fine. But it really is the VB5 of the 21st century.
We want something else.*
*Ripped off from a great MASH episode.
I doubt very much a language syntactically and stylistically optimized for light-duty GUI event scripting can be a good language for implementing OS-like features and vice-verse. Leave JS alone and create a new language that's a better fit for "deep guts" programming.
What's next, ADA-Script?
Table-ized A.I.
Remember when we thought SQL was so much slower and not fit for the big work? Well it was'n SQL, it were the early implementations that were slow.
Now the Javascript specs are very powerfull. And the engines (implementations) are getting faster all the time. I see SproutCore and Objective-J pushing the envelope, amongst others. Javascript has only just arrived.
Anyways, that's only my impression.
--------
* Sigh *
Javascript is a helper language, I don't get where this debate is originating, if you need advanced functionality, you need server code, it's been available for a bit now in various flavors: .NET, JSP, & php to name a few big ones. Javascript nor html are not even remotely close to replacing server side coding languages. If you kill javascript, here's what will happen: people who's website already have javascript, won't care, people developing websites needing javascript functionality will google that functionality and find the decade old jscript that runs like it should as search result #1.
What debate? lol... technologies get phased out, they don't just die, and there will always be jscript developers even if every IT entity created its own client side scripting language because most of the web will still be using jscript. The only way jscript can die is if the other languages prove to be clearly superior and there is a benefit to businesses to switch. If you tell me to recode my websites cause google came out with a new language, I will probably physically rofl and tell you where to shove it.
In terms of functionality, thats more a question of what is the browser willing to support as the browser is what handles the jscript.
Dunno, I read a lot of the posts in this thread shaking my head, does anybody posting in these threads actually do web development that doesn't involve a geocities successor a blog / feed in a box? I guarantee having a wordpress website doesn't quality you as a web developer, or even an IT tech.
Python!
The history of the Internet and examples like IPv6, HTTP, SMTP, etc have shown us over and over that "good enough" + evolution trumps replace almost every time.
The path forward is clear: improve JavaScript, extend it, improve HTML, and keep on trucking. Neither will ever be replaced on a wide scale, only evolved.
The reason we don't already have worldwide IPv6 deployment is they redesigned IP instead of just extending the addresses.
Natural != (nontoxic || beneficial)
(Responding to my own comment)
I'm waiting for someone to come up with a simple transport layer in JavaScript that does nothing but make the DOM visible to the other end. All you would need is
1) Interrogate the DOM, send back value
2) Set DOM variable to passed value
2) Pass back messages based on the user actions ("button X was clicked").
I'd *love* to see a python or perl interface for this. Making a GUI for something would be almost trivial.
http://www.c2.com/cgi/wiki?GuiMarkupProposal
...but it does look like google are determined to replace javascript - and who can blame them, it's becoming pretty clear that it has structural problems that cannot be solved by evolving the language. It's only a matter of time before this realisation spreads to the all the other browser vendors.
The bottom line is that if you're learning either javascript or html5, then it's starting to look like you are wasting your time.
Just hold-tight for a huge shake-up, things are about to get very interesting!
If Google would actually get around to releasing some details on Dart, rather than just trying to shoot down an established language, then maybe this could be a rational discussion.
"My God...it's full of trolls!"
Debugging JavaScript is nightmarish. Code with flaws just fails to work. JavaScript's weak typing allows lots of errors to pass silently and create hours of frustrating work. Yes, it is the lingua franca of the web. But it can be frustrating, surly and opaque to work with.
Specifications? A Benjamin Franklin List would be useful. Benchmarks? Working ... Demos?
Hay Intel! How about a Metaphysical Interface?
Hay Google, How about a Protocol Definition?
If Google, and Intel could combine a Metaphysical Interface with a Protocol Definition, maybe there would be something new to march around the breakfast table about?
Lyke thu Eenglish langwej spailing.
Table-ized A.I.
We need an option to compile web apps to something like IL from a variety of languages (*exactly* like .NET), and these need to target a common browser object model that's defined by a rigorous set of unit tests. HTML? Fine. JavaScript? Fine. Just leave them above the real browser standard so developers who like them stay happy but let rest of us move on.
The whole IE6-problem and now probably IE-whatever on Windows XP (there is only IE9 for Vista and higher) means things had to be compatible for far to long, without any swift upgrade path.
This has let to stagnation of the language and many related API.
That is where the real problem is, the language had no way to evolve.
Just let it evolve and finally solve the old problems that exists.
Many, many webdevelopers already use just the 'good parts' and it has already given us a lot of new ideas and piece by piece these new ideas are added to the browsers with a small compatibility layer for those that do not support it. Just an example: native json support.
New things are always on the horizon
Add an optional compile directive (attribute) to the script object to enable compilation as weakly typed code. :)) LOL
An IDE could help out with typing issues.
Compiled JS would do the crunching while regular JS would handle UI events and talk to JSON services.
Killing JS would be like trying to strangle yourself with your bare hands.
Be my guest
We already have Java. We just it already installed in the browsers.
Is it a coincidence that Google wants you to move to a new programming language at the same time that Mozilla has essentially caught up to Google Chrome in JavaScript performance? And when Mozilla has tons of new performance improvements on the way in IonMonkey engine?
Google wants their competitors and other developers on a HTML ("continuously evolving standard"), HTTP (replace with SPDY), JavaScript (replace with Dart) treadmill.
Javascript's it's deliverer online!
http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/page2.html
FACE IT - Like many programming languages, Javascript CAN be a "double-edged sword", but, unlike many programming languages, it's being used rampantly online and is not secure and imo @ least, it needs work in its DOM!
Face this too: Any scriptable document format has potentially bogus consequences!
(Yes - my statement includes HTML webpages online, not just typically "local file" formats Office Docs & autoexec macros, & .pdf files in Adobe Acrobat Reader have shown us this for decades now)...
APK
P.S.=> Anyhow/anyway - per my subject-line above, what is the "deliverer" of "The BEAST"? Javascript (and it's been doing that job for malware makers countless times, in countless exploits, for decades now)...
... apk
The only reason anyone gives a shit about Javascript now is that the routines have already been written. You need something, you cut and paste. Only a select few 'poor bastards' are having to write the code anymore. Writing javascript code still sucks big time
What we need is a standard VM and bytecode format for the web. Then both JavaScript and other languages can compile for the same VM, and voila! Suddenly it doesn't matter what language you use. Happiness all around! (Emscripten is great, but using JavaScript as "bytecode" is hardly ideal.)
Well, that, and a standard API for interfacing with the browser. Preferably something better designed than the current JavaScript mess, with an optional compatibility layer on top for older JavaScript code.
The direction of web standards seems to be one of adding more and more functionality to Javascript, enabling access to successively lower levels of abstraction, e.g. web sockets, web workers, 3D canvas. Why not cut to the chase and use a actual OS to provide these?
The browser I want to see is one where the tabs are virtual machines that run any operating system supported by the virtualized hardware. For current web applications, the guest OS could look a lot like current browsers (minus the tabs, since the über-browser would manage them). For more sophisticated applications, the guest OS could be Linux, for example. The über-browser would need to provide for instant cloning of a guest OS template, and efficient sharing of resources between guest OS's using copy-on-write semantics. The über-browser would allow tabs to be closed (deleting the guest VM) or suspended. It also would provide mechanisms for the user to manually import/export files between the host OS and a tab and between two tabs.
Hopefully this would lead to a new era of OS research leading to better designs for the guest web OS. For example, it would be good if a guest VM could swap out to the cloud, and swap in on another host.
please please please please please.
I'm not holding my breath for that (anymore), but it would be nice.
NeWS was superior, but patented. Those patents are now expired. I would like to see an open source NeWS take off.
Unlike an application written in C, an application written in JavaScript can run on a computer that you don't own. You may not have the privileges to install arbitrary native applications, but computer labs allow JavaScript because it's sandboxed.
Unlike an application written in C, an application written in JavaScript can run on more than one kind of computer as long as it has a web browser with JavaScript.
What's "a cumbersome install process"?
Anything that involves writing an executable to the local user account and executing it from there. Consider what would happen if /home were mounted noexec on UNIX and its clones. Windows has likewise supported disallow-by-default Software Restriction Policies for a long time.
I hate those helpful suggestions Google wants to pop up.
You can disable Suggest in your Google profile.
Show me a native word processor that can allow multiple people to edit a single file as easily as Google docs. No service fees
Advertisements are a service fee. You pay with the distraction.
I find myself agreeing with both the parent and grandparent.
WHAT DO I DOoooooooooooooohhhhhhhhhhhh????????????????
(Sorry for the shouting. I'll go find a corner by myself where I can breath deeply for a few minutes.)
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Microsoft's quality has greatly improved in the last decade. I think Silverlight has a good architecture. Unfortunately, Microsoft can not be trusted.
I'm not really sure how serious I am, but the primary reason my project which I think might replace javascript (and many other things) is sitting on sourceforge without updates for a long time is my lack of resources.
People with the resources to do the job have mostly forgotten why.
People (crackpots, like me) who can remember why we want something else are likely to have been shunted aside by people with less patience. (And cut off from the jobs that would get us access to the resources.)
(Oh. The current shards of my project, if you're curious, are here. Not very self-explanatory, and I can't even scrape up the time to chart the course from that to a proper scripting language, but you might find it amusing.)
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
This happens all the time. When I think of it, I've spent the last 25 years working in different flooded living rooms. (Things are drier for me now, though, than ever before. But there's one wall where the 'drywall' is just a mushy paste.)
Somebody ignores the decades of experience in coming up with general-purpose programming languages, because "they're overkill," and introduces a toy language that happens to deal with a very limited situation fairly well, or concisely, or maybe "just because." (And to fair to javascript, as much as I hate it (and I mostly do, though different amounts at different times), it is the least toy-like and least let's-ignore-the-last-50-years one of these that I've dealt with.) Then somebody gets the idea of building entire applications based on that limited situation premise. Amazingly, it doesn't fit.
It sucks, but it could be worse:
"Hey! I can implement logic gates in Dwarf Fortress! Let's build a computer for fun!"
"Hey! My computer knows 25 op-codes now!"
"Hey! I used those op-codes to build a FORTRAN compiler. No more thinking in terms of op-codes, for me!"
"Hey, I ported a commonly-used functions library to DF77."
"Hey, I used your functions library to write a database."
"Hey, I used your dfsql to build an insurance billing system."
"Hey, I'm having trouble debugging why our system's claims are being rejected. I think I've narrowed it down to .. well .. can someone tell me what SIEGE means?"
I'd kill it with great passion. die javascript, die!
There is no "great javascript debate", Javascript has proven itself a fine language, The only debate is over the competence of programmers.
You don't stop using a language for a particular purpose while it is the best-supported, most widespread and most evolved language for the job. You kill it when you have a better alternative and everyone is starting to use that. Google (and others) are just trying to spread FUD about JS to get people to use something they control, not because JS is so terrible ... (in fact, it has become a very decent language both for server-side work with CommonJS/RingoJS and NodeJS and recent client-side implementations are already competing with Flash performance-wise).
"I love my job, but I hate talking to people like you" (Freddie Mercury)
self explanatory
Maybe they should specify an open VM API next time, rather than a language. The LLVM VM instruction set is open. What's the downside of that?
stay frosty and alert
NodeJs ?
JavaScript is not a perfect language by far: it desperately needs a good packaging system, semicolon insertion was a poor solution to a non-problem, overloading is a mess, and any number of other things. But the people trying to replace it are usually more concerned not so much with fixing the problems as enforcing archaic programming paradigms, replacing JavaScript's best features -dynamic typing, prototypal OO, and so on- with things that have been driving people away from programming for decades. Dash is no different.
The Web needs something better than JS as-is, but what people tend to try to replace it with is no improvement. Incremental improvement to JS is far preferable.
This bit of the article is intriguing:
What are the ways in which HTML/CSS+JavaScript is not an effective platform v. native apps? What can be done about it?
And replace it with what? What system/ecosystem provides everything you get from the Java environment?
You really need to read Crockford's "Javascript: the good parts". You absolutely do make private methods and vars (ever noticed that you can't directly call jQuery's internal methods? Or TinyMCE's? Or any other major library/framework?)
He also makes the case that actually JS has more patterns to allow code re-use. That's why things like Mootools can even fake things that look like classical class inheritance patterns for you, if you really want to do that.
Check out http://www.crockford.com/javascript/inheritance.html and http://javascript.crockford.com/prototypal.html and http://www.slideshare.net/douglascrockford/javascript-the-good-parts-3292746
NT
Earth?
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
And if you don't explicitly deal with every special case, your strongly typed language will quit working, leaving the user with a cryptic error message and a unusable broken web page. Yes, this is obviously the way to get all browser creators to jump on your bandwagon. Just make their products less reliable and make it much more difficult to write client side code that is robust.
JavaScript has some truly evil parts, but soft run time typing is not one of them. I believe that this is one of the features that has kept it dominant in the browser software domain. If the code encounters something unexpected in the data, it can just keep running. A feature on a web page can not work, or the wrong thing will be displayed, but the rest of the page will be useful. This is critically important to browser usability.
There are clearly problems with this approach. There is a huge amount of bad code out there that is just plain wrong and works badly. Other aspects of JavaScript make it very had to debug code and fix errors. The fact that things still work under these conditions just proves that my position is valid.
The information that passes into you browser is incredibly ill formed. This will not change. To process it correctly, your code has to deal with a lot of bizarre special cases. This is independent of strong or weak typing in the client side language. A strongly typed language makes this problem insurmountable, and a weakly typed language means that you can get useful results even when bugs are present. The choice is between having a useful result, or encountering major malfunctions at every turn.
So do you want to make the Internet work, or do you want to break it?
Why is Snark Required?
I think it deserves a cool name. How about something like 'X'?
they just stop getting executed.
If we want to deliver these "cloud apps" there could be a system designed from ground up for applications instead of these horrible AJAX hacks. Make it have a real API for GUI components (pulled from network) instead of drawing some boxes with HTML. This way we don't have to have thick clients running native software but we would get a saner interface for this type of stuff. What do you think?
So in your lovely theoretically pure strongly typed language, what do you do when live data doesn't correctly follow the strongly typed paradigm that is part of the language design?
I prefer to use "pragmatically typed" languages instead - ones which let you opt into duck typing when you want, but default to static typing because it's preferable in most cases.
or you have exception handlers that catch all data type exceptions and keep the code running under all conditions.
That doesn't really make sense, since you don't have "data type exceptions" in statically typed languages - you have compiler errors from type mismatches. You can get an error from an incorrect downcast (in some statically typed languages, not all of them - e.g. OCaml simply doesn't have downcasts), but I don't see how this would be of any help to you in a scenario where data is so vaguely shaped that it cannot be properly typed.
You also underestimate the versatility of static typing, probably because GP mentioned Java specifically, and you use it as an example. We can do much better. For example, in OCaml - which is statically and strongly typed, more so than Java - you can define a function thus:
"#" is a method call operator. The type of function "f" in the above snippet is statically inferred to be "function taking one argument of any object type that has a no-argument method 'foo'". This is still different from duck typing because the constraint is actually verified at compile-time - you can't pass just any random object to it, you can only pass something that is statically known to have "foo". But, with flexibility like that, type inference just walks its way through the entire chain of method calls, starting from the point(s) where "foo" originates - and even if you have two completely unrelated classes which both have "foo", it'll be able to figure it out.
Indeed, most code written in duck-typed languages can be written almost identically in a statically-typed, structurally-typed language with pervasive type inference.
Just give us a language IN which somebody can implement javascript. Problem solved.
I guessed that because Google has ads on so many other services, and its primary source of revenue is ads, it must have ads on Google Docs. I now admit that I had guessed wrong. How does Google recover the cost of providing the Google Docs service?
I want to spend my time programming the solution, not fighting the language.
The future will be where any app or api can go global, interchat with remote apps/services/apis/devices.
strong types belong to hardware specs even those are getting more dynamic and flexible.
Liberty freedom are no1, not dicks in suits.
Javascript has some very poor aspects and a bunch of cruft/inclusions that should not exist. As part of the (existing) move toward standards, the client-side processing language should become more "standard" and "one way works for everyone" and "incorporates the characteristics of a successful language of today" and "meets the intent of its use on the client-side."
This may actually involve multiple languages for different use-cases....
Try: + + "y";
This is valid syntax in JavaScript. Kill it with fire.
Disagree != mod troll.
I'm going into construction.
You can have .net, c, c++, c+++, c#, f#, VB, VB.net, flash, java, javascript, html[#1-100], DART, FART, all those stupid animal book languages and all the rest of the crap.
You can't debug half of this shit because you need admin rights to the servers, the tools don't exist and/or you need $10,000 worth of Microsoft products. And even if you do have all that, half the crap is on the server, half in the browsers (which are not compatible and do crazy weird shit all the time) and this whole "stateless" things essentially makes it all behave like an Alzheimer's patient.
I.T. is polluted with half assed ideas and implementations and fanboys of every nature. Nobody can fucking figure out anything. You can't get a job unless you have 20 years experience in a 10 year old technology and even then they want someone who knows every technology out there and, BTW, they want you to move to some shit hole place where an apartment cost $4000 a month and you really can't own a car.
Fuck all of y'all, I'm going to go dig ditches.
Great. Where can i download it ? Do you have a tutorial ?
Slipping shoelaces ?
A stupid, sparse language that does nothing out of the box! Oh? There's a gazillion of libraries, and people have been taught how to avoid most of its traps for 3 decades? Well, you don't say!
My opinion is to kill JavaScript. As a prototype object language it's like driving a car with levers instead of a steering wheel and pedals (remember many of the first cars built used a series of levers) It wasn't done right in the fist place and trying to continue to improve it won't get past many of it's fundamental faults. It has only been made usable lately because of frameworks like jQuery.
Prototypal object models are just different from class-based object models. Neither is particularly better/worse than the other, just different. If you want to you can even implement "classical" object orientation in Javascript if you want.
You can almost get strong typing (not static) in Javascript if you always use the "===" and "!==" operators instead of "==" and "!=". (See "JavaScript: The Good Parts" by Crockford and JSLint.com.)
This was more or less what happened with the DOM... one the (rightly) most maligned APIs of all. You may think you want an API designed by a committee, but you really don't. If DOM isn't example enough, I don't know what would be.
HAND.
Indeed, most code written in duck-typed languages can be written almost identically in a statically-typed, structurally-typed language with pervasive type inference.
Amen
Jehovah be praised, Oracle was not selected
The genius of Brendan Eich's language is that its so flexible you define new features and redefine existing ones.
There's a (Japanese) implementation of the Java JVM in JavaScript and someone else ported Apple's Objective C in JavaScript
Now personally I don't really care to use either of those (I'd rather stick closer to the actual language being used, and in this case JavaScript is the web), but I think JavaScript is more than adequate as it is
It's unlimited supply of modeling clay: don't complain just because you can't decide what to make!
http://ejohn.org/blog/running-java-in-javascript/
All source codes are stuck in the 80s, based on files and directories.
What we need is a new better organization.
Yes IDEs rule, but they dont share 'project' files. They should, it should be open and standard.
All functions n classes should be each in a different 'object' or file.
Let the IDE Hide how it looks.
The idiotic management needed by coders to decide what function goes in what file and what dir, is a nightmare, because it makes it difficult to move functions around and restructure and share parts.
Its so 1980s!! Someone please redesign the code editing ecosystem.
Besides having compilers accessing files constantly is garbage, if its all in ram, it should compile with zero disk IO.
Flash IDE is part way there, hiding the files/objects on disk and manage it all as a project.
Liberty freedom are no1, not dicks in suits.
They left school early, did that hurt their abilities?
Why do people still use COBOL? Its an engineering failure.
Liberty freedom are no1, not dicks in suits.
Nah, the specs are shit, probably best to do a re-write ;)
http://www.gibby.net.au
Why not replacing javascript by python?
No, NaN and Infinity are not sane responses, and yes this is JS specific, any other language that does it doesn't exist for me
In that case, any language without exceptions as a language primitive and with IEEE 754 arithmetic doesn't exist. This means C doesn't exist. Good luck booting a modern PC, tablet, or smartphone without at least some code written in C.
raise an exception which *is* the sane thing to do when dividing by zero or doing other invalid math operations.
When dealing with coordinates and projection, sometimes it is useful to have a number x such that any nonzero number divided by x is zero. For example, ray-casting an infinite floor plane will return infinite distance at the horizon. Or did you want two division operators, one that raises an exception and one that produces these non-real numbers?
JS is workable, but the list of things that I would change in it is large enough that I would rather drop it for any other of the major scripting languages out there
You could always build a compiler from "any other of the major scripting languages out there" to JavaScript.
How exactly is it still problematic if the user has to click a "Turn On Camera and Microphone" button on the page?
What if they don't? Why would a malicious website put such a button on their website?
With Javascript having access to hardware, the website has the power to take over the user's hardware, assuming the browser allows it. Obviously, some browsers would be able to add in a feature disallowing this except for certain websites (just as some browsers now allow you to disable Java and Javascript for certain websites, or to block certain Javascript features like pop-up windows), but we can't assume that all browsers would do this.
Why would a malicious website put such a button on their website?
Because until the user has activated such a button, all attempts to access the camera or microphone input would raise a security exception.
With Javascript having access to hardware, the website has the power to take over the user's hardware
Access to input devices != direct access to hardware. JavaScript already has access to keypresses and mouse movements, yet that doesn't give web sites "the power to take over the user's hardware". Why would audio from a microphone or video from a camera be any different?
Because until the user has activated such a button, all attempts to access the camera or microphone input would raise a security exception.
You're assuming the browser doesn't just grant access to these devices willy-nilly. IE's track record on this stuff hasn't exactly been stellar; does IE even have a pop-up blocker these days? What about Safari? Large corporations have proven time and time again that you can't trust them to protect your privacy; just look at Facebook: the people running that don't even believe you should have any privacy!
JavaScript already has access to keypresses and mouse movements, yet that doesn't give web sites "the power to take over the user's hardware"
It gives JS access to that information while the user is on that web page and looking at that tab. Same goes for camera and microphone, except that the information there is potentially more damaging than your mouse movements.
Of course, none of this would be such a big deal if webcams were required by law to have an LED indicator light that showed any time the cam was on, but unfortunately that's not the case, and many of them don't.
i remember those days. back then guys like you would complain about the file size over dialup, but didn't bother to learn enough to break out your content into external swf files, and lazy load only what you need. you also had retarded clients who insisted on skip intro pages, but you never acknowledged your own fault in either not being an expert or not positioning yourself as an expert, to advise against such stupid practices. you were a yes-man.
anyone who really knows flash well knows that the only true fault it has (still today) is a buggy compiler that sometimes interprets your coding errors in unrelated ways that make it difficult to debug. accidentally pasting a special character into actionscript might cause the timeline to ignore all stop commands, or something like that. any other "fault" is really just more of an annoyance. the truth is every language has those kinds of faults, especially whatever language you prefer. if you knew enough about the tool and the language, you wouldn't care if the aspect ratio was 640x480 or 1920x1080.
and any attitude a developer has against faithfully reproducing the designer's vision is counter productive. if you were trained to communicate visually the client wouldn't hire a designer. you're trained to design and build systems (at least, i hope). so quit bitching and do it. to complain about designers makes about as much sense as construction workers complaining about the architect and how s/he wants a building to look (omg this material is expensive and easy to ruin!). it's your fucking job to make it look the way it was designed.
no one who's ever stated they "hate" flash ever had a rational, well thought-out, or even accurate reason for it. it's all just excuses from the least able in the field (especially you steve jobs). boo fucking hoo.
insensitive clod overlords obligatory xkcd car analogy russian reversals whoosh pedant fanbois ftfy in 3...2...1..PROFIT