Slashdot Mirror
Google To Introduce New Programming Language — Dart
An anonymous reader sends this excerpt from El Reg:
"Google has built a brand-new programming language for 'structured web programming,' one that appears to be suited to browser-based apps. Two of the search giant's engineers will discuss Dart, Google's new language, at the Goto international software development conference next month. News of the new language was posted to the Goto website. There aren't yet any technical details on Dart but the bios of the two Googlers presenting at Goto strongly suggest a bent towards programming for the web and browser."
Those other 22 could all go away.
https://www.xkcd.com/927/
You think?
Some apps are WYSIWYG. Some others are WYSIWTF.
I'm kind of confused as to where google is going these days.
Is this just a side effect of hiring too many bored CS graduates -- put enough in a room together and they come up with their own languages?
I just can't see this being used outside of google -- Web Programming is largely a solved problem, and there are already a plethora of options. Since MS and Apple won't touch anything that comes out of Google, it'll only ever be relevant on the server side -- which is where there are already too many options.
Unless this does something radical -- and judging by what Go was, I doubt it -- this will probably be a niche thing they use internally.
I thought Google have been doing this the whole time, ie 20% projects. Nothing wrong with releasing the ones that come to fruition. It's not detracting from other parts of their business, and it's bringing cool stuff into the community - some of which might be really useful. Google are one of the companies that actually has a chance of making a replacement to JS "stick", though convincing MS would be a very tall order indeed.
which is totally what she said
So you wannabe coders keep saying, all of javascript is documented on google searches, its so easy to copy paste those functions and input your own field names and just seem them work.
Well, I've lately been experimenting with HTML5 canvases, which involves a lot of JS, and I've found that it isn't always quite that easy. Yes, there are zillions of examples that do cute things in a canvas. But they all seem to be made up of lots of hard-coded numbers that aren't explained anywhere in any coherent fashion. So to use them to draw your figures, you spend long hours tweaking the numbers, trying to grok what the relation might be between the numbers and what appears on the screen.
Similarly, there's lots of online HTML5 docs on zillions of sites, but it all seems to involve "handwaving", i.e., it describes what's going on in a "10-km view" fashion, using lots of undefined terms. When you try googling those terms, you find that you're searching through millions of ghits that are mostly about totally unrelated topics that happen to use the same words (with different meanings).
So you try asking in a forum. And you find that there are zillions of HTML5 forums, each of which has maybe 2 or 5 messages per month, and the people (or person ;-) there are oh-so-friendly, but don't quite know how to answer your question. You try asking in multiple forums, and it takes forever, due to the fact that people don't like usenet any more; they prefer zillions of forums, each of which has its own GUI that takes days to learn to use effectively.
The "cargo cult" (google it) approach to web programming is widespread. But it can be a recipe for a very long, slow, drawn-out process of coming to some partial understanding of WTF is going on in the code that doesn't quite do what you need, and responds bizarrely to tiny tweaks. Getting downloaded code to do what you need done can take up a rather large chunk of your lifespan. And you are forever plagued by bugs due to your lack of understanding what it does in cases that you haven't tested.
The only way to produce code that actually works correctly is to understand (in every detail, to the bit level) all the things you're working with. Cut-and-paste sounds like a useful idea, but it's much of the reason for the widespread coding disasters that we're plagued with.
Learning to use "New! Improved!" Web tools has a history of being a lot like swimming in molasses. The intro examples look cool, but doing anything even slightly different from the examples tends to lead you down a maze of twisted passages, all alike. So there are reasons to be skeptical of this one, until we've seen some evidence of what it's like, and how much of a time sinkhole learning it will be.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
If the Dart language is intended to replace something like the buggy, slow and badly designed PHP language,
I was rather hoping it was intended to replace the buggy, slow (although progress has been made), and badly designed ECMAScript language, which you may also know as JavaScript.
JavaScript is not actually that bad compared to PHP. I know it can be used to create a complete mess, but in the hands of a competent developer it can be used to produce a decent end result.
PHP on the other hand seems to have hit a wall recently. I have to admit though I am a little jaded at the moment after a recent project exposing an existing PHP web application via web services. PHP has truly awful WSDL support, even if you try using the Zend Framework addons. Since more and more projects seem to involve some level of interworking with other systems that fact that PHP fail so badly in this regard is pretty inexcusable.
Just to explain why I am so jaded and not at all as a cathartic experience I am probably now going to rant about some of the issues :)
Firstly, the SOAP functions built into the latest verion of PHP only support rpc/literal WSDL. Since every other platform (.NET, JAVA, Axis2) wants document/literal this makes PHP only useful for talking to PHP.
Then you think Zend Framework might be better. Unfortunately although this lets you generate and expose WSDL2 files using document/literal, you cannot use them as a basis for your service. This means that you can't actually let anyone talk to the service without some awful compatibility layer that translates what a rpc/literal service would expect into document/literal by doing some crazy unravelling of arrays of parameters.
And then when you finally think you are done you discover there is a bug that means booleans are just broken and always get returned as false. You file a bug report but it looks like the maintainer of this part of the Zend Framework has died as he hasn't been on their bug tracker for months.
So I might have worked round all these issues and delivered a working service but it took far longer than expected and that costs money. For a server side language that is supposed to be an established heavy weight this is not acceptable. It's enough to make you learn .NET :)
I dont read