Your point is well taken; I know some who hate JS because, well, it's JS. I doubt Google is trying to cater to THAT crowd as such, but if Gilad Bracha is involved in it I think it will at least be worth looking at.
Maybe in much the same way as CoffeeScript differs from JS. It doesn't need to be that much different to be better. Of course this depends on how you define "better" and "different."
I wonder how many of (quite a few) unique newspeak features will Dart sport. My gut feelings are that Google will try to please mainstream instead. That'd be unfortunate but if things like no namespace or modularity were alike it'd be still cool as a wider scale experiment.
Systems programming, very explicitly. Go is basically aiming at C, whereas it sounds like this is going to be aiming at trendier languages like Python and JavaScript.
I got all excited that this was the "Spot" we've been hearing about... but alas, something even newer. I have dreams of a Go-like language that could be used for both web server and web client programming.
I know this sounds a little coarse, but I really don't care about yet another new programming language. There are too many already with so many distinct use cases and niches.
I think a simple, general purpose programming language is good enough(1) for the web and I'd rather have one tool for all jobs versus another edge case language. In fact I'd rather have someone concentrate on one good "multi-tool" than provide me with a hundreds of cheap short-lived screwdrivers with different shaped heads.
Innovation should be about making the status-quo better, not introducing a new status-quo every 5 minutes with new promises.
(1) - "Good enough" is an under-used term these days.
I have to completely disagree, there isn't enough innovation in the programming language space. The more people we have writing languages and the more people using them, the more quickly we'll discover new patterns and improved ways of doing things. Improved programming languages with better abstractions, better guarantees can allow whole new classes of programs to be written. Of course, they could be written using traditional techniques but the complexity and difficulty involved can make them almost impossible.
There is plenty of innovation in the programming language space. There is too much. We're too busy working out how to talk to the machines versus how to get problems solved. We're here to solve problems, not serve the machines.
In fact, the shortage is in computer-science research. There has been NOTHING as fundamentaly important as Knuth's work in the last couple of decades. It's an innovation standstill. Nothing fundamentally better than the UNIX and LISP paradigms is out there for example.
Until something fundamental changes, most of what we have will do the job fine.
> There has been NOTHING as fundamentaly important as Knuth's work in the last couple of decades.
What work of Knuth's? TOACP? TeX? I'm a huge Knuth fan, but I don't see his work as fundamental to computer science, rather mostly as an amazing gatherer and editor of such work.
He formalised it which is the one thing everyone else had failed before. Plus don't forget things like KMP algo, METAFONT, TeX, literate programming etc.
"In 1961, the National ACM meeting was held in Los Angeles. The keynote speaker was Tom Watson, the Chairman of the Board Of IBM. Bob Barton was the second or third speaker after Watson. don and Lloyd and I were in the audience of approximately 1200 people. [...] "There are only three people in this room that really know how to write a compiler and I would like for them to stand up now. They are don knuth, Lloyd Turner and Richard Waychoff."
Language innovation is tightly tied into computer science innovation. There are plenty of paradigms that are fundamentally different and quite potentially better than UNIX and LISP out there- you just need to get out of that rut.
Mozilla's language [Rust](https://www.github.com/graydon/rust/wiki) is working on static verification (using typestate) and concurrency in a C/C++ level language.
The Haskell community has several people ([Conal Elliot](http://conal.net), [Luke Palmer](http://lukepalmer.wordpress.com)) who are working on new models of functional I/O such as functional reactive programming.
There is a lot of programming language innovation in parallel/concurrent programming that's just hitting mainstream- actor model, asynchronous programming, CUDA/OpenCL, etc.
The way you talk to the machine is an extremely important part of "how to get problems solved." If you can't express something without absurd amounts of overhead, you're not going to solve the problem that way.
The reason there is a lot of fragmentation is that there is a lot of different problems out there to solve. There are no pana cea that solves every problem at once.
It should start with a problem and then formulating abstractions to make the problem easier to solve. Or in other words with defining a language and then see what properties it has. Starting with the verifications gives you very well defined properties, but it doesn't solve your problems because you will then optimize your language for the wrong thing.
Do you honestly expect every PL researcher to all work on the same magical super-language? No- they're going to work on the problem in their area of expertise and create/modify a language to show off their ideas. Then a language like Scala or Haskell or Clojure can come along and improve on them or combine them.
Every field works this way. That's why there is more than one particle collider, more than one drug for each problem, more than one theory of particle physics, more than one programming language.
Your link talks about radical change over gradual change in computer science. It seems to support the idea of creating new and dramatically programming languages. The idea that "small" changes have large effects discourages the gradual modification of existing paradigms and languages.
You should read more of the links provided before just snarkily assuming that nobody in that set has a math background. To the contrary, it's hard to find people in that list who aren't coming at things from a formal angle.
Also, trying to beat people doing real work about the ears with ancient Dijkstra quotes stopped being helpful about 30 years ago. He's not the ultimate authority on how a programming language should look in 2011. If you're so sure you've got a good bead on the problem, why don't you go solve it for us then?
What do you think a formal language is if not mathematical? Researchers invent little languages to distill the problem to its simplest components so its solvable, and then they generalize to other domains, if possible. That's how math is done.
Agreed. Right now the only significant research breakthrough I've seen is the work on formal analysis of programs.
I have read hundreds of computer science papers from the 60s, 70s and 80s as part of my academic work, and frankly, everything I'm seeing today was conceptualized and/or invented then. It's staggeringly obvious if you read the sweep of history as written by journal article titles in, say, Software Practice & Experience, between 1970 and 2010. Somewhere in the late 80s things just peter out.
I strongly suspect a few things have come into play here.
* Disdain for formal mathematics by software writers. Mathematics is so absolutely key to heavy-duty breakthroughs in computer science.
* Increasing percentages of academics who never worked in the real world (and consequently knew how to get stuff done or what really matters).
* Lack of the academic industrial research labs such (Hi MS Labs! You are awesome! Keep it up please!). Also, lack of massive DARPA/DoD/DoE & NASA funding.
* The general decline of academic research quality, sacrificed on the altar of metrics (e.g., papers per year) & budget cuts.
* Friction caused by standards and legacy data & code. It's easy to innovate in a greenfield world. When you have to support five gazillion things & have 'batteries included', barriers to adoption are a lot higher.
I suspect major seminal work in the next decade will come from the Haskell crowd, since they are the most mathematics-heavy writers, and it is gaining traction in Microsoft and Google, which have the budget to support offbeat research.
So... you're given a blank check, either as a industrial research lab manager or DARPA program manager. What "revolutionary" research in CS would you champion?
It's easy to be critical from the sidelines. There are very smart people still working in this space, including Knuth himself.
Well, that's a good challenge. As it so happens, I do do research for my Master's, although sadly, it's just evolutionary, due to me not being bright enough, time & funds. Fortunately for my graduation date, I don't have to come up with something seminal. :-) I am working on some parallel debugging technology for an XMOS XCore chip. It's mostly a rehash of techniques...from the 80s. :-)
If I had a really revolutionary idea, I would have dug up a PhD program to sponsor me and be working on it, telling it everyone who would listen. I don't have that class of ideas right now. Research is hard, and takes a lot of very bright people collaborating for years and creating a good tribal knowledge to come up with really strong results. The MIT lab is a good example, as is the Bell labs.
For an evolutionary approach, I would like to revisit the on-demand compilation to native code of dynamic languages. Getting Python/Ruby/Perl to compile native on the fly would provide an efficiency boost. (Please note, Steel Bank Common Lisp already does this).
Another needed research area is a usable and robust certificate authority system. Diginotar/Comodo-style hacks need to stop, ASAP.
Yet another evolutionary approach would be to work on a provably secure/levels of trust style system for phones operating systems (c.f. early 80s DARPA research).
A more revolutionary research program would be to revisit the WIMP metaphors for computer use. Review the early Stanford/PARC research and take a different jumping off point. I strongly suspect there's a local maximum of awesome between pure CLI and pure WIMP, and we've not gotten there yet.
A more ambitious (possibly physically impossible?) project would be to determine how to create massive WiFi ranges: single WiFi hubs that easily cover a mile. Determining how to create, say, 10Gbit Wifi would provide a very nice public good.
I've had good success working with CSP-style parallelism, and would love to see more parallel constructions that use it (c.f. occam). That avenue may be the 'normal' way forward for parallel code.
None - NONE - of the above technologies is more than a rehash of old tech.
SCADA systems are sickeningly insecure/fragile. I would fund heavy-duty research into how to put together secure SCADA systems (Protocols, operating systems, control centers, etc, etc), and have them be a straightforward upgrade. I suspect that satisfying the constraints of SCADA systems would result in some interesting new knowledge.
Possibly a distributed yet authoritative CA system would induce some groundbreaking algorithms relating to trust and efficient distributed systems.
Automatic testing, verification, and reliability analyses based on Software Contracts instead of HM typing seems like it'd be fruitful to me, but I don't know the state of the art there.
Thank you. You've almost single-handedly convinced me that it might be worth my time to do real research during my CS education. A lot of those sound interesting.
Nearly everything in the software/computer science world can be an area of active research if you start looking into it. It takes a lot of digging to get to the point of active research in some areas, particularly in the ones that have been well studied. Most of a typical undergraduate course will only prepare you for reading the research; most of a master's is about getting you ready to actually contribute something (the thesis). The PhD is where the real action starts happening for most people.
Why is that? The '10000 hours' in computer science is usually needed to get you to the point where you can start contributing significant work. It is absolutely worth your time to spend time working on real research. The caveat is the place of research determines the coolness. Some places... you run tests. Some places... you do some really awesome work. Look into REUs if you're still an undergraduate. Those are essentially internships for academics. They are paid. :-)
I would be happy to communicate further with you; my email address is in my profile.
Good list. There is also interesting work that could be done starting where Strongtalk and/or Self left off (well, Strongtalk is still alive afaik but progressing slowly). Image based programming is very different than "cult of the dead" programming and I think it still has a lot to teach us.
I'd also like to see more effort going into generic functions. This is clearly a superset of message passing and is more powerful (e.g. no need for the visitor or related patterns).
I'd also like to see effort put into exploring the CL conditions systems. Exceptions already made programming more robust, conditions give the developer full control over error handling.
> I'd also like to see effort put into exploring the CL conditions systems. Exceptions already made programming more robust, conditions give the developer full control over error handling.
In my opinion, almost every language I've worked with could be improved with a CL style condition system. (every language that already has exceptions could :P) I'd love to see a more popular language pick this up and run with it. Especially if there's been research/improvements beyond what you get in CL.
I would put together a team of super hero's that doesn't care so much about languages and goes straight for the guts of the systems, the 1's and 0's. That is what is holding everything back, it's a very primitive system. The future is in 3-d, literally. Multi-valued, multi-relationship, multi-patterned, the math is there, but no one has figured out how to make it into an actual machine yet.
For the field of programming language design ask yourself this question: what will programming be like in 50 years? Will we still be typing characters into VIM? I don't think so. Looking a little forward can go a long way.
Well . . . what they said 25 years ago was probably about Berkeley vi, not Vim, so I guess in 50 years we'll be using something two generational advances forward from Vim.
Honestly, I think that in 50 years either we'll still be doing textual programming, just at a higher and more dynamic level, or we won't be doing any programming at all because the machines will have left our ability to contribute well behind.
I disagree with your disagreement of the original disagreement.
Plenty of languages does not mean plenty of innovation; in the web programming there's certainly too less of it. Every new or currently fashioned language evolves to a point where community implements its own Rails in it. I hope you don't call this trend innovation because it's not.
There were some promising trends in web programming like use of delimited continuations, but they didn't make a breakthrough. Today's web dev still is a hack around stateless http protocol, requires you to know at least 3 languages and there are no composable components you could easily reuse. World definitely needs innovation in this area.
Definitely agree. Mainstream language design seems to be stuck on endless variations of Ruby, JavaScript, and Java. I would love to see as many new languages as we have now, but focused on more significant changes than "Lisp without macros and a slightly tweaked generics system."
You should really check Opa, which has been discussed several times here. The syntax does not please everyone (and can evolve) but at least it is built on original concepts.
See http://opalang.org. An alternative is Ur/Web if you're that curious.
Like AI, if you define innovation as something large enough then we'll never get there.
I think there's a lot in the small steps. It's only by implementing a framework ten times that it'll be done really well. In one language you'd never get traction for the later frameworks. If each community does one with knowledge of the ones before them eventually a great implementation will be created.
> In fact, the shortage is in computer-science research.
and
> There is plenty of innovation in the programming language space.
Are at odds with each other. All of the programming languages that we use today can trace their roots back to computer-science research, either in the dark ages or in the immediate past.
Things like software transactional memory and other goodies are the pay-offs from that research and those things are only now making their way into programming languages.
You can't have the one without the other. And that goes both ways, computer-science research needs to have people that try the concepts it comes up with in the marketplace to see what survives in an adversarial context, so that it will be able to make the next step based on what survived and what didn't. So that's two birds with one stone, it's a proving ground and the foundation for the next generation of concepts.
Most people I know consider programming languages and compilers a part of computer science. This set of people is mostly computer science researchers, some of whom (including myself) who do work in the area.
That's at a very high level. It's part of, but it's not the driving force behind what is possible. That is the constraints of the universe and consequentially mathematics, on which there is little focus these days.
Programming languages and compilers are the easy part of the problem. Translation is almost completely solved. However, the abstractions over the top at both the conceptual and structural level (logic->machine) are definitely not solved.
I disagree. I think the most pressing issue facing computer science right now is how to express and exploit parallelism in a way that most programmers can benefit in most applications that they write. The expression part of that problem is languages and compilers. The exploitation part of that problem is compilers and systems.
Anyway, it sounds like when you say "computer science" you mean what most of us call "theoretical computer science." You're free to define words however you want, but you should expect confusion when you try to communicate with other people using those words.
Theoretical computer science is still actively researched. You seem pretty confident that not much is going on, but do you keep up with their conferences and journals?
I do keep on top of things, but unfortunately the academic "industry" doesn't like to really push the boat out. Radicalism and original thought are frowned upon in the scientific community. Everything is the same ideas recycled and repackaged slightly differently.
both, similar in some concepts, just kills UNIX on the design stand point.
None of them are really used. Sad :(
Eventually we will merge toward them tho, they're the future somehow. Not because they're "new" (compared to UNIX) but because they solve resource and security issues we have today. Also solves a lot of the complexity.
Completely disagreed. There is a lot of language creation, but little language innovation. Ruby, Python, Perl, Lua, JavaScript are essentially all the same language. Java and C# are the same, and very similar to the scripting languages just adding static typing. C++ is similar to the previous 2, just removing memory safety. What was so innovative about any of these languages? They are the same old imperative OO paradigm that first appeared in Simula and Ada back in the 80s.
Examples of languages that are innovative are Mozart/Oz, Haskell, Alice ML, Coq, Agda and Mercury. These completely redefine what it means to program, and all of them were created in the last 15-20 years. And if you think there haven't been great strides in each of these domains, then you're simply not familiar with them.
> There is plenty of innovation in the programming language space. There is too much.
No such thing. Innovation is a good thing, period. Perhaps what you find objectionable is the proliferation of stuff that people call "innovation", but really isn't very innovative.
Imagine Microsoft announcing a browser different than IE...
That's what Google is doing: a company famous for closing fast projects that don't get immediate traction launches a new programming language when they have Go out there already...
Programming languages are like platform APIs: they effectively lock-in you into their environment. If you're in academia or doing research, you're free to throw out there whatever you want, but I'm not switching my development into this, at this stage there's too much risk and no proven benefits.
So don't switch your development to it. It's an experiment- academia, hobbyists, and other people who don't care about getting locked in will try it out and learn from it. Then either the language will succeed and you can switch if it turned out well, or it will fail and the programming community will learn from it.
Just because Google is doing it doesn't mean it can't be an academic experiment. Experimentation with new programming languages is very much more useful than with new browsers, because you can't easily slap on new features to a programming language whereas you can on browsers.
Paradox: how can a language become successful if it is only ever used in academia and hobbies? Look at perl, javascript, php, coffeescript, scala, etc. These languages became successful precisely because people started using them for production projects more or less on day 1.
Example: some hobbyist will write an amazing web app with it and then some small studio will pick it up and it can grow from there. A lot of hobbyists are also professionals.
I can't find details on Dart, but it sounds like it addresses a different need than Go.
Go is a systems programming language. Its goal is to supplant C and C++. I'm not sure what exactly they mean by "structured web programming," but it does not sound like a systems programming language would naturally fill that goal.
That's the definition of Go, but I've been using it, and I wouldn't mind at all writing a web backend using it. Its very pleasant and high level, despite having low level features. The static duck typing definitively helps.
There is a lot of innovation in the programming language space, see what node.js is doing with javascript (I still remember the days when everyone let all the JS code to juniors programmers because no one liked JS).
Google should focus on fixing what's already done, not re-inventing the wheel again.
It created a new world to work with in JS... by copying the async frameworks that already existed in numerous other languages. Innovative within Javascript, sure. Innovative, without further qualifications? Decades too late for that.
Call me crazy, but I don't consider forcing users to manually transform their code into hard-to-read continuation passing form much of a language innovation.
> node.js created a new world to work with JS, making it more powerful.
Sure, it gave it a new environment to run in, but it didn't make the language any more powerful than applets made Java the language more innovative.
Node's primary innovation is in terms of A) unifying JS on a single high-performance platform and B) creating an ecosystem from the ground up where thread-safety is required at all times.
These innovations are significant, especially at the boots-on-the-ground level. That said, when people speak about lack of innovation in programming languages I think they are looking for more fundamentally new ideas. I don't want to be a cynic—all ideas are derivative after all—but I don't think Node qualifies.
Hmm, I would reckon node.js is popular because of its inherent simplicity and tapping the greater javascript community, which is by far the most vibrant and energetic I have seen.
The things that it introduced - asynchronous, modelling as events, single thread execution - are not really new and already exist as libraries/frameworks [varying in increasing complexity] in Python, Java and Ruby.
Not that I am knocking node. If anything, its good more people are opening up to alternative, sometimes better, ways of modelling and execution.
Granted, Node.js is nice and all, but it's hardly innovative. It's built on an old language using ancient async tricks running on a VM built using old performance techniques learned during the development of an old language.
If your universe has a mere 400 old software ideas, and you choose 4 (e.g. JS, async, VM, hidden objects) your combination is one out of 1 050 739 900. That is the mathematics of innovation.
What's worse is this is fragmentation of the programming economy. I've found awesome bits of code written in Python that I can't use in PHP/Ruby/C++/etc, and various other combinations. There are great programmers working on great projects, but if they're not using the language of choice for my particular project, they are essentially useless to me.
It also makes it difficult to find new talent because there is less of a chance they'll be able to work in the language we've chosen. And yes, a good programmer should be a polyglot, but it's an attraction issue. If I'm advertising a Ruby job and looking for skills with Ruby-specific tools, there may be a great Python programmer that could switch over but who doesn't apply because they don't want to deal with switching gears to another language.
Let's keep it to 3 or 4 major languages. I think that's all I can take right now...
Library support is a big deal, and obviously a new programming language won't have a whole lot of that. That issue gets a lot smaller, if the language allows an easy way to abstract away a lot of those issues, making it quick and easy to deal with whatever you'd look for a library for. If your main goal is to find lots of library support, this new language won't appeal to you.
I'm reserving judgement until I actually see it. Maybe it's a great, fun to use language that gives significant performance advantages over other high level languages. If I need half the servers, that could be a big win. If threading and concurrency are abstracted away in a way that's performant and I don't have to worry about it, that's a big win. I don't know what it will be, but if it's useful it's useful. Seems a bit silly to judge it before it's out, especially criticizing it simply for being a "new" language.
Obvioulsy not, there are a few good good solutions to that, like running on the JVM or some other similar platform. It is not all about performance, languages can introduce new abstractions that can make a lot of difference.
who doesn't apply because they don't want to deal with switching gears to another language.
In my experience, a good developer doesn't care about the language, and, in fact, would be excited to learn a new one. However, our industry has the mantra of "find someone with perfect proficiency or hire nobody," leaving those good developers afraid to apply unless their skill-sets match exactly.
The keyword here is "learn". Don't underestimate the amount of time it takes to become truly proficient in any language. Not to mention the huge cultural differences between the communities, and therefor companies, around those languages. Even with someone with a proven track record, it is still a considerable risk and investment on the part of the employer.
It is an interesting problem of the "new economy" though. Companies won't hire anyone unless they are absolutely one hundred percent perfect, leaving business with thousands upon thousands of open positions unable to be filled and just as many crying for work.
We hear statements like "the people aren't well educated enough," or "not smart enough" time and time again, but it misses the real mark. Jobs of the past were tied to time-based constraints, such as deteriorating products, so hiring anyone to get the job done, no matter how poor of an employee, was better than losing everything.
Coming from an agriculture-based background, farmers are always complaining about the quality of help, more-so than technology companies. However, you cannot afford to wait until someone good at the job comes along. When the crops are ready, you have to harvest them no matter what. That means taking on sub-par labour.
In the information industries, time does not matter. If it takes decades to find the right person, it is better to wait for that person because of the risks you state. Educating the masses isn't going to change anything. Changing the attitudes of business is the only solution if we want to see employment numbers rise again.
I think the problem is that people are finding that having that top 10% kind of person is basically required to stay competitive. There's considerable effort on the other side of the coin too, in designing systems from foolproof patterns that 80% of the job market can learn. The fact of the matter is that this is an industry where 5 people from the top 2% of the market can disrupt and displace 500 from the middle 50%. In my opinion that's why YCombinator is so successful.
Still worse is all the weaknesses in the existing dynamic language runtimes. It seems even harder to build a really solid language runtime than to design the language itself. For a long time I was hoping that the Parrot VM would solve these problems but it seems to have stalled out.
If I'm advertising a Ruby job and looking for skills with Ruby-specific tools, there may be a great Python programmer that could switch over but who doesn't apply
Solution: don't advertise 'a Ruby job'. Advertise 'a programming job'. What it is you really want in your applicant?
> In fact I'd rather have someone concentrate on one good "multi-tool" than provide me with a hundreds of cheap short-lived screwdrivers with different shaped heads.
They can be sued on (largely bogus) patent claims regardless of language/toolset. Even if they completely wrote their own language and implemented every feature from scratch, that doesn't give them any meaningful patent protection.
I studied VHDL extensively at university as well as semiconductor physics (I did microelectronics). I'd like to go back to that level - it's great fun but too many problems are utterly abstract now for anyone to care about it any more.
However, always make time for stuff that's interesting :)
Actually you can jump back up the ladder a bit by using MyHDL, a Python module which compiles your Python down to either Verilog or VHDL. http://www.myhdl.org/doku.php
I prefer the crippled lambda. If you need more than a simple expression, you should write another function anyways. The restriction leads towards easier to read/maintain code.
I would say Python is my favorite language at the moment too. But gosh can it be improved. You seem to imply in your post that Dart is gonna be a specialized niche language. Not necessarily. Just because they announce it as a PL for web programming doesn't mean it couldn't be a general purpose PL.
The only real server-side web language is PHP (and Microsoft's ASP). Sure, you can do a decent job with Python or Ruby, plus some wacky hack of a templating language (there's a wide range, but they have never gotten the care and affection that a fully blow language would get), but PHP is really king of the hill for web work.
I think that PHP could be replaced by something just as specific, and without the warts. You could also look into typing and compilation (optional static typing, with implicit declarations where possible?).
Now, I don't use PHP, but you have to admit it's useful and productive for a lot of people. If Google can improve it, and I think it can, it would be a boon.
That said, every time I try to guess what the implications of Google's next big thing is, I'm completely off track. I think a PHP replacement would be the most useful thing they can do in this space, but they will no doubt have a different plan.
Gimme a mix of harmony and coffeescript on the server and I'm sold. Btw, no static typing please, the web is definitely dynamic, oh one last thing, remember the hobbyists.
Most data sent over HTTP that's parsed by scripts is either XML or JSON, both of which are highly structured. XML in particular has a rich type system.
You are leaving out simple urlencoded data sent with GET and POST. I'd say that is a huge chunk of what's parsed by scripts. Also XML and JSON are, at the bottom of it all, text, with (perhaps) type metadata.
Everything "at the bottom of it all" is just "text", a sequence of octets. The point of a type system is to make sure you adhere to the structure inherent in that series of octets.
Since there is already a very nice, albeit quirky, dynamically typed langauge for the web, I think there is room for something different. If you want to build robust applications with larger teams - as is increasingly the case with JavaScript - it would be really nice to have features of a statically typed language. Same goes with the performance overhead for processor-intensive apps, which we are also seeing more of with JavaScript. We are learning enough about the potential for powerful browser-based apps that we could conceivably start to come up with something better.
On the other hand, and to your point, nobody wants to reinvent SOAP.
I think CSS is fine for documents. Your style rules will be pretty simple and consistent.
The problem is when you try to shoehorn an application onto HTML. Then I agree, CSS is an abomination. I have taken a liking to using Javascript widgets that manage their own styles, inspired by the OpenStep view model. But then I start to question why use the browser at all?
Perhaps there is some good reason for developing a whole new language. However my gut tells me that they should instead put their weight behind a new promising language that's still evolving.
I would say that it depends entirely on what aspect(s) of the problem of web programming Dart is trying to solve. It may be that the decision to make a new language stemmed from new ideas about type systems or new semantics that didn't really fit with any existing language.
Obviously I'm speculating here, but since we don't know what Dart is, we're all speculating here.
I specifically didn't want to give an example. I thought it might appear that I was merely cheer-leading my language of choice and undermine the point I was making.
However since you've asked I was thinking that perhaps something Javascript based, like Coffeescript or perhaps Clojure/Clojurescript or perhaps even Links http://groups.inf.ed.ac.uk/links/
There are probably another 100 reasonable candidates. I guess this leads me to the point I should have outright stated, that given that so many languages have already been written, it is highly likely that any new language will spend a lot of time covering ground that has already been covered by some other language. Surely it makes most sense to start off hunting through all these languages to find something that most closely matches what you need and continue from there.
Who knows, perhaps that's exactly what they've done.
Well, the thing is that it's not necessarily easier to improve an existing language than to create a new one from scratch. There is a big advantage in starting all over - no backward compatibility headaches. Honestly I can't think of any existing language that's worth putting anyone's weight behind. Coffeescript - js has some horrible semantics and Coffeescript can't really hide all of them. Clojure - it's infinitely cool but it will never ever become the mainstream.
I would really like to see a typed programming language to build web apps on App Engine. Most of the bugs I track down could be caught at compile-time.
I'm dreaming of something that runs on V8 that intelligently compiles to server-side and client-side JS as well as HTML and CSS from better higher level languages (something like, say, CoffeeScript + LESS + HAML).
I'd be very interested in a content authoring language that included the ability to assemble and create webm container files. Something that takes direction from a source file and "compiles" to webm (mkv+vorbis).
Go is not gaining enough traction, while Scala takes off. GAE is losing steam, while AWS takes off. I guess it was about time for Google to make yet another attempt to remain relevant.
A non-crappy language to build internal systems? There's a strong culture of NIH at Google, so I doubt there is any sneaky hidden strategy in their opening Go: they get widespread peer review and the chance to prime candidates on the language before they ever reach the hiring process. I guess even that is justification enough.
I have a hard time attributing a new language coming out of Google as NIH syndrome. If you take a look at some of the people employed at the big G (Gosling, Kernighan, Pike, Guido, Thompson, etc.) who were responsible for creating and nurturing some very big languages being used today, I would be surprised if new languages weren't being created.
For more perspective, Ruby appeared in 1995 and Python in 1991, and yet those just became really popular in the past 5-10 years. It takes a while for languages to gain maturity. Go wasn't going to "take off" after two years.
Google has had a horrible track record in seeing things through. So there are two issues here. One, there are already too many programming languages out there. Two, you just can't trust google to make it into a mature and viable language that you would invest time in learning. As of now, I'm hoping javascript and Node.js become the dominate language of choice.
I would classify Python and C# as languages that have improved considerably over time. So I would say that it is, in fact, possible to get better languages without developing more.
I don't disagree with that, as a language that is actively maintained should (hopefully) get better over time.
The key thing is to develop new techniques for solving problems - think iterative versus recursive, or functional programming versus logic programming.
A given language is most likely targeted (or has least resistance) towards one style of programming, which means that new abstractions are likely to work better in a new language, one that has been developed with these blocks as starting points rather than added later.
It might be nice to focus development of specific key languages to avoid too much fragmentation by picking best-of-breed, but everyone's got their own itch... and for some that is developing new languages.
C# hasn't just improved itself considerably, C# put pressure on Java to improve as well.
That's why I welcome the creation of any and all new languages. I don't need to be on the cutting edge and try to learn all of them, I can wait until the early adopters see value in them and then learn from the things that work.
I think you don't understand what Google intends when they release a new product.
Do you want a company to 1) only brew products (with a business model) internally until it is ready to ship, or 2) develop and release lots of things and see what works or not?
Google leans towards #2. They don't really care if they can make money off of something, if one of their engineers is interested in something they're allowed to take that risk. They put lots of stuff in the wild and if it doesn't stick then they kill it (or in most cases leave the source to the public - see wave) - or try to make it profitable (look at gapps).
Yes, a lot of things coming out of Google die, but that's only because they're putting out lots of things all the time. The day they stop putting out unproven stuff and only release v1.0 products is the day they lose their innovation edge.
First take: Oh, Google, what are you doing this time? Second take: Wait, the guy behind V8 is working on this... Hm, I'll have to take a look.
It sounds like Lars himself may not have tons of expertise creating a language, but teaming up with someone who does and throwing in his own expertise getting it to run fast in a browser... might be interesting.
However, is there a concern here that only Chrome will support it for a while? Then anything you write in it will be Chrome only. Isn't that kind of like the bad old days when each browser had its own tags and whatnot?
If it's good and the spec is open, I don't see anything wrong with that. If it's really that great and becomes popular, other browsers will be able to add support easily.
New language couldn't solve our problem even its inventor comes from Google or not. Take for example go language, what the go language achives to us, just nothing. Same rule could be applied to this unknown super start language. Startups and freelance developer could use that toy language to implement their worthless and crap 'todo web app' but real world dont have free time to play with these toy languages. Technology is not consist with web apps, we need scalable, easy to learn, easy to read, easy to maintain languages. And finally look from broad perspective, all of the new web languages doesnt have a mature ide like Eclipse or Visual Studio, dont suggest me to use vim or emacs, i dont have enough time, i am not an idiot to fuck my brain with those useless shortcut keys.
> hat the go language achives to us, just nothing.
Maybe for you, but not for the hundreds-thousands of people using it.
> Technology is not consist with web apps
What?
> all of the new web languages doesnt have a mature ide like Eclipse or Visual Studio
I'm going to assume be "web languages" you are talking about Python, Ruby, Javascript (on nodejs), and Perl. Most people get along fine with the existing tools. Many people don't even like ides like VS.
> me to use vim or emacs, i dont have enough time, i am not an idiot to fuck my brain with those useless shortcut keys.
Not sure how learning fast, easy shortcut keys would 'fuck your brain'.
> but real world dont have free time to play with these toy languages.
False. Developers in the 'real world' work with cool new languages, frameworks and tools every day. If you're not willing to learn them that's your own problem.
This sounds a lot like my side project of three years and counting. I'm half-hoping it hasn't been in vain, and half-hoping they've done all the hard work for me. Steeeeeve!
Was this leaked some time ago? see http://markmail.org/message/uro3jtoitlmq6x7t
(although the language is here called "Dash", but they could have changed its name since last November which the mail apparently dates from) From the supposed internal email:
Javascript has fundamental flaws that cannot be fixed merely by evolving the
language. We'll adopt a two-pronged strategy for the future of Javascript:
- Harmony (low risk/low reward): continue working in conjunction with
TC39 (the EcmaScript standards body) to evolve Javascript
- Dash (high risk/high reward): Develop a new language (called Dash) that
aims to maintain the dynamic nature of Javascript but have a better
performance profile and be amenable to tooling for large projects. Push for
Dash to become an open standard and be adopted by other browsers. Developers
using Dash tooling will be able to use a cross-compiler to target Javascript
for browsers that do not support Dash natively.
[...]
Javascript has been a part of the web platform since its infancy, but the
web has begun to outgrown it. The web development community has been
backed into using large amounts of JS largely to work around the
deficiencies in the platform. Complex web apps--the kind that Google
specializes in--are struggling against the platform and working with a
language that cannot be tooled and has inherent performance problems.[...]
The emergence of
compelling alternative platforms like iOS has meant that the web platform
must compete on its merits, not just its reach. Javascript as it exists
today will likely not be a viable solution long-term. Something must
change.[...]
The “clean break” option is extremely high risk--it will be a huge challenge
to convince other browser vendors to rally around a new language--but is the
only way to escape the historic problems with Javascript. Thus, its high
risk is matched by the potential for a very high reward--a classic leapfrog
strategy.
[...]
Dash is designed with three perspectives in mind:
- Performance -- Dash is designed with performance characteristics in
mind, so that it is possible to create VMs that do not have the performance
problems that all EcmaScript VMs must have.
- Developer Usability -- Dash is designed to keep the dynamic,
easy-to-get-started, no-compile nature of Javascript that has made the web
platform the clear winner for hobbyist developers.
- Ability to be Tooled -- Dash is designed to be more easily tooled (e.g.
with optional types) for large-scale projects that require
code-comprehension features such as refactoring and finding callsites.
Dash, however, does not require tooling to be effective--small-scale
developers may still be satisfied with a text editor.
Dash is also designed to be securable, where that ability does not seriously
conflict with the three main goals.
Dash will be designed to be consumed in a number of locations:
- Browser VM -- Our aspiration is that Dash will ultimately be a viable
substitute for Javascript as the native client-side language of choice
across all browsers.
[...]
I actually ran into this a long time ago but couldn't find any comments on it anywhere (either backing it up, or debunking it as a hoax).
I'm hoping so. Well, here's how I interpret it: A structural (non-textual) environment that hosts code in a distributed graph. Less string schlepping and more semantic manipulation of data.
205 comments
[ 2.8 ms ] story [ 227 ms ] threadSounds promising - will be interesting to compare to Io/Ioke/Seph...
In what practical sense would that differ from JS?
Your point is well taken; I know some who hate JS because, well, it's JS. I doubt Google is trying to cater to THAT crowd as such, but if Gilad Bracha is involved in it I think it will at least be worth looking at.
Although, I wonder if the language may be more suited to Google's needs (which are pretty specific) than the general web programming world.
Since they also love Java a lot, I am not that optimistic.
I think a simple, general purpose programming language is good enough(1) for the web and I'd rather have one tool for all jobs versus another edge case language. In fact I'd rather have someone concentrate on one good "multi-tool" than provide me with a hundreds of cheap short-lived screwdrivers with different shaped heads.
Innovation should be about making the status-quo better, not introducing a new status-quo every 5 minutes with new promises.
(1) - "Good enough" is an under-used term these days.
There is plenty of innovation in the programming language space. There is too much. We're too busy working out how to talk to the machines versus how to get problems solved. We're here to solve problems, not serve the machines.
In fact, the shortage is in computer-science research. There has been NOTHING as fundamentaly important as Knuth's work in the last couple of decades. It's an innovation standstill. Nothing fundamentally better than the UNIX and LISP paradigms is out there for example.
Until something fundamental changes, most of what we have will do the job fine.
What work of Knuth's? TOACP? TeX? I'm a huge Knuth fan, but I don't see his work as fundamental to computer science, rather mostly as an amazing gatherer and editor of such work.
http://ed-thelen.org/comp-hist/B5000-AlgolRWaychoff.html#7
here is the conclusion of the chapter:
"In 1961, the National ACM meeting was held in Los Angeles. The keynote speaker was Tom Watson, the Chairman of the Board Of IBM. Bob Barton was the second or third speaker after Watson. don and Lloyd and I were in the audience of approximately 1200 people. [...] "There are only three people in this room that really know how to write a compiler and I would like for them to stand up now. They are don knuth, Lloyd Turner and Richard Waychoff."
http://www-cs-faculty.stanford.edu/~uno/vita.pdf
You're talking about the guy who invented LR parsing.
Mozilla's language [Rust](https://www.github.com/graydon/rust/wiki) is working on static verification (using typestate) and concurrency in a C/C++ level language.
The Haskell community has several people ([Conal Elliot](http://conal.net), [Luke Palmer](http://lukepalmer.wordpress.com)) who are working on new models of functional I/O such as functional reactive programming.
There is a lot of programming language innovation in parallel/concurrent programming that's just hitting mainstream- actor model, asynchronous programming, CUDA/OpenCL, etc.
The way you talk to the machine is an extremely important part of "how to get problems solved." If you can't express something without absurd amounts of overhead, you're not going to solve the problem that way.
It should start with math and formal verification (top down) rather than with the language (bottom up).
Start here: http://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1036.PDF
It should start with a problem and then formulating abstractions to make the problem easier to solve. Or in other words with defining a language and then see what properties it has. Starting with the verifications gives you very well defined properties, but it doesn't solve your problems because you will then optimize your language for the wrong thing.
Do you honestly expect every PL researcher to all work on the same magical super-language? No- they're going to work on the problem in their area of expertise and create/modify a language to show off their ideas. Then a language like Scala or Haskell or Clojure can come along and improve on them or combine them.
Every field works this way. That's why there is more than one particle collider, more than one drug for each problem, more than one theory of particle physics, more than one programming language.
Your link talks about radical change over gradual change in computer science. It seems to support the idea of creating new and dramatically programming languages. The idea that "small" changes have large effects discourages the gradual modification of existing paradigms and languages.
Also, trying to beat people doing real work about the ears with ancient Dijkstra quotes stopped being helpful about 30 years ago. He's not the ultimate authority on how a programming language should look in 2011. If you're so sure you've got a good bead on the problem, why don't you go solve it for us then?
I have read hundreds of computer science papers from the 60s, 70s and 80s as part of my academic work, and frankly, everything I'm seeing today was conceptualized and/or invented then. It's staggeringly obvious if you read the sweep of history as written by journal article titles in, say, Software Practice & Experience, between 1970 and 2010. Somewhere in the late 80s things just peter out.
I strongly suspect a few things have come into play here.
* Disdain for formal mathematics by software writers. Mathematics is so absolutely key to heavy-duty breakthroughs in computer science.
* Increasing percentages of academics who never worked in the real world (and consequently knew how to get stuff done or what really matters).
* Lack of the academic industrial research labs such (Hi MS Labs! You are awesome! Keep it up please!). Also, lack of massive DARPA/DoD/DoE & NASA funding.
* The general decline of academic research quality, sacrificed on the altar of metrics (e.g., papers per year) & budget cuts.
* Friction caused by standards and legacy data & code. It's easy to innovate in a greenfield world. When you have to support five gazillion things & have 'batteries included', barriers to adoption are a lot higher.
I suspect major seminal work in the next decade will come from the Haskell crowd, since they are the most mathematics-heavy writers, and it is gaining traction in Microsoft and Google, which have the budget to support offbeat research.
It's easy to be critical from the sidelines. There are very smart people still working in this space, including Knuth himself.
If I had a really revolutionary idea, I would have dug up a PhD program to sponsor me and be working on it, telling it everyone who would listen. I don't have that class of ideas right now. Research is hard, and takes a lot of very bright people collaborating for years and creating a good tribal knowledge to come up with really strong results. The MIT lab is a good example, as is the Bell labs.
For an evolutionary approach, I would like to revisit the on-demand compilation to native code of dynamic languages. Getting Python/Ruby/Perl to compile native on the fly would provide an efficiency boost. (Please note, Steel Bank Common Lisp already does this).
Another needed research area is a usable and robust certificate authority system. Diginotar/Comodo-style hacks need to stop, ASAP.
Yet another evolutionary approach would be to work on a provably secure/levels of trust style system for phones operating systems (c.f. early 80s DARPA research).
A more revolutionary research program would be to revisit the WIMP metaphors for computer use. Review the early Stanford/PARC research and take a different jumping off point. I strongly suspect there's a local maximum of awesome between pure CLI and pure WIMP, and we've not gotten there yet.
A more ambitious (possibly physically impossible?) project would be to determine how to create massive WiFi ranges: single WiFi hubs that easily cover a mile. Determining how to create, say, 10Gbit Wifi would provide a very nice public good.
I've had good success working with CSP-style parallelism, and would love to see more parallel constructions that use it (c.f. occam). That avenue may be the 'normal' way forward for parallel code.
None - NONE - of the above technologies is more than a rehash of old tech.
SCADA systems are sickeningly insecure/fragile. I would fund heavy-duty research into how to put together secure SCADA systems (Protocols, operating systems, control centers, etc, etc), and have them be a straightforward upgrade. I suspect that satisfying the constraints of SCADA systems would result in some interesting new knowledge.
Possibly a distributed yet authoritative CA system would induce some groundbreaking algorithms relating to trust and efficient distributed systems.
Automatic testing, verification, and reliability analyses based on Software Contracts instead of HM typing seems like it'd be fruitful to me, but I don't know the state of the art there.
Nearly everything in the software/computer science world can be an area of active research if you start looking into it. It takes a lot of digging to get to the point of active research in some areas, particularly in the ones that have been well studied. Most of a typical undergraduate course will only prepare you for reading the research; most of a master's is about getting you ready to actually contribute something (the thesis). The PhD is where the real action starts happening for most people.
Why is that? The '10000 hours' in computer science is usually needed to get you to the point where you can start contributing significant work. It is absolutely worth your time to spend time working on real research. The caveat is the place of research determines the coolness. Some places... you run tests. Some places... you do some really awesome work. Look into REUs if you're still an undergraduate. Those are essentially internships for academics. They are paid. :-)
I would be happy to communicate further with you; my email address is in my profile.
http://healthcare-robotics.com/
http://www.hizook.com/blog/2010/10/16/pr2-robot-autonomously...
http://youtube.com/watch?v=c2JChnwv2Ws
I'd also like to see more effort going into generic functions. This is clearly a superset of message passing and is more powerful (e.g. no need for the visitor or related patterns).
I'd also like to see effort put into exploring the CL conditions systems. Exceptions already made programming more robust, conditions give the developer full control over error handling.
In my opinion, almost every language I've worked with could be improved with a CL style condition system. (every language that already has exceptions could :P) I'd love to see a more popular language pick this up and run with it. Especially if there's been research/improvements beyond what you get in CL.
Plenty of languages does not mean plenty of innovation; in the web programming there's certainly too less of it. Every new or currently fashioned language evolves to a point where community implements its own Rails in it. I hope you don't call this trend innovation because it's not.
There were some promising trends in web programming like use of delimited continuations, but they didn't make a breakthrough. Today's web dev still is a hack around stateless http protocol, requires you to know at least 3 languages and there are no composable components you could easily reuse. World definitely needs innovation in this area.
I think there's a lot in the small steps. It's only by implementing a framework ten times that it'll be done really well. In one language you'd never get traction for the later frameworks. If each community does one with knowledge of the ones before them eventually a great implementation will be created.
and
> There is plenty of innovation in the programming language space.
Are at odds with each other. All of the programming languages that we use today can trace their roots back to computer-science research, either in the dark ages or in the immediate past.
Things like software transactional memory and other goodies are the pay-offs from that research and those things are only now making their way into programming languages.
You can't have the one without the other. And that goes both ways, computer-science research needs to have people that try the concepts it comes up with in the marketplace to see what survives in an adversarial context, so that it will be able to make the next step based on what survived and what didn't. So that's two birds with one stone, it's a proving ground and the foundation for the next generation of concepts.
Programming languages and compilers are the easy part of the problem. Translation is almost completely solved. However, the abstractions over the top at both the conceptual and structural level (logic->machine) are definitely not solved.
Anyway, it sounds like when you say "computer science" you mean what most of us call "theoretical computer science." You're free to define words however you want, but you should expect confusion when you try to communicate with other people using those words.
Theoretical computer science is still actively researched. You seem pretty confident that not much is going on, but do you keep up with their conferences and journals?
both, similar in some concepts, just kills UNIX on the design stand point.
None of them are really used. Sad :( Eventually we will merge toward them tho, they're the future somehow. Not because they're "new" (compared to UNIX) but because they solve resource and security issues we have today. Also solves a lot of the complexity.
http://www.faqs.org/docs/artu/plan9.html
Examples of languages that are innovative are Mozart/Oz, Haskell, Alice ML, Coq, Agda and Mercury. These completely redefine what it means to program, and all of them were created in the last 15-20 years. And if you think there haven't been great strides in each of these domains, then you're simply not familiar with them.
No such thing. Innovation is a good thing, period. Perhaps what you find objectionable is the proliferation of stuff that people call "innovation", but really isn't very innovative.
That's what Google is doing: a company famous for closing fast projects that don't get immediate traction launches a new programming language when they have Go out there already...
Programming languages are like platform APIs: they effectively lock-in you into their environment. If you're in academia or doing research, you're free to throw out there whatever you want, but I'm not switching my development into this, at this stage there's too much risk and no proven benefits.
Just because Google is doing it doesn't mean it can't be an academic experiment. Experimentation with new programming languages is very much more useful than with new browsers, because you can't easily slap on new features to a programming language whereas you can on browsers.
Go is a systems programming language. Its goal is to supplant C and C++. I'm not sure what exactly they mean by "structured web programming," but it does not sound like a systems programming language would naturally fill that goal.
Not exactly a surprise for a language whose announcement has only just been announced.
Google should focus on fixing what's already done, not re-inventing the wheel again.
How is node.js innovating in the language space?
node.js created a new world to work with JS, making it more powerful.
Call me crazy, but I don't consider forcing users to manually transform their code into hard-to-read continuation passing form much of a language innovation.
> node.js created a new world to work with JS, making it more powerful.
Sure, it gave it a new environment to run in, but it didn't make the language any more powerful than applets made Java the language more innovative.
These innovations are significant, especially at the boots-on-the-ground level. That said, when people speak about lack of innovation in programming languages I think they are looking for more fundamentally new ideas. I don't want to be a cynic—all ideas are derivative after all—but I don't think Node qualifies.
The things that it introduced - asynchronous, modelling as events, single thread execution - are not really new and already exist as libraries/frameworks [varying in increasing complexity] in Python, Java and Ruby.
Not that I am knocking node. If anything, its good more people are opening up to alternative, sometimes better, ways of modelling and execution.
It also makes it difficult to find new talent because there is less of a chance they'll be able to work in the language we've chosen. And yes, a good programmer should be a polyglot, but it's an attraction issue. If I'm advertising a Ruby job and looking for skills with Ruby-specific tools, there may be a great Python programmer that could switch over but who doesn't apply because they don't want to deal with switching gears to another language.
Let's keep it to 3 or 4 major languages. I think that's all I can take right now...
I'm reserving judgement until I actually see it. Maybe it's a great, fun to use language that gives significant performance advantages over other high level languages. If I need half the servers, that could be a big win. If threading and concurrency are abstracted away in a way that's performant and I don't have to worry about it, that's a big win. I don't know what it will be, but if it's useful it's useful. Seems a bit silly to judge it before it's out, especially criticizing it simply for being a "new" language.
In my experience, a good developer doesn't care about the language, and, in fact, would be excited to learn a new one. However, our industry has the mantra of "find someone with perfect proficiency or hire nobody," leaving those good developers afraid to apply unless their skill-sets match exactly.
We hear statements like "the people aren't well educated enough," or "not smart enough" time and time again, but it misses the real mark. Jobs of the past were tied to time-based constraints, such as deteriorating products, so hiring anyone to get the job done, no matter how poor of an employee, was better than losing everything.
Coming from an agriculture-based background, farmers are always complaining about the quality of help, more-so than technology companies. However, you cannot afford to wait until someone good at the job comes along. When the crops are ready, you have to harvest them no matter what. That means taking on sub-par labour.
In the information industries, time does not matter. If it takes decades to find the right person, it is better to wait for that person because of the risks you state. Educating the masses isn't going to change anything. Changing the attitudes of business is the only solution if we want to see employment numbers rise again.
Solution: don't advertise 'a Ruby job'. Advertise 'a programming job'. What it is you really want in your applicant?
"Here try these tools."
hands you a python
hands you a linux
No. Not really. I keep promising myself I'll learn it, but, so far, the goodness of the excuse to learn it does not outweight the lack of time.
However, always make time for stuff that's interesting :)
Help making the present language better, if you really want to!
I think that PHP could be replaced by something just as specific, and without the warts. You could also look into typing and compilation (optional static typing, with implicit declarations where possible?).
Now, I don't use PHP, but you have to admit it's useful and productive for a lot of people. If Google can improve it, and I think it can, it would be a boon.
That said, every time I try to guess what the implications of Google's next big thing is, I'm completely off track. I think a PHP replacement would be the most useful thing they can do in this space, but they will no doubt have a different plan.
And since when did innovation become about preserving the status-quo? It's exactly the opposite of it.
Could you explain what you mean with that?
On the other hand, and to your point, nobody wants to reinvent SOAP.
The problem is when you try to shoehorn an application onto HTML. Then I agree, CSS is an abomination. I have taken a liking to using Javascript widgets that manage their own styles, inspired by the OpenStep view model. But then I start to question why use the browser at all?
Obviously I'm speculating here, but since we don't know what Dart is, we're all speculating here.
However since you've asked I was thinking that perhaps something Javascript based, like Coffeescript or perhaps Clojure/Clojurescript or perhaps even Links http://groups.inf.ed.ac.uk/links/
There are probably another 100 reasonable candidates. I guess this leads me to the point I should have outright stated, that given that so many languages have already been written, it is highly likely that any new language will spend a lot of time covering ground that has already been covered by some other language. Surely it makes most sense to start off hunting through all these languages to find something that most closely matches what you need and continue from there.
Who knows, perhaps that's exactly what they've done.
http://golang.org
http://blog.golang.org/2011/07/go-for-app-engine-is-now-gene...
https://github.com/socketstream/socketstream#readme
It's nice to see where a link goes before you click on it.
Go appeared in 2009 Scala appeared in 2003
For more perspective, Ruby appeared in 1995 and Python in 1991, and yet those just became really popular in the past 5-10 years. It takes a while for languages to gain maturity. Go wasn't going to "take off" after two years.
The key thing is to develop new techniques for solving problems - think iterative versus recursive, or functional programming versus logic programming.
A given language is most likely targeted (or has least resistance) towards one style of programming, which means that new abstractions are likely to work better in a new language, one that has been developed with these blocks as starting points rather than added later.
It might be nice to focus development of specific key languages to avoid too much fragmentation by picking best-of-breed, but everyone's got their own itch... and for some that is developing new languages.
That's why I welcome the creation of any and all new languages. I don't need to be on the cutting edge and try to learn all of them, I can wait until the early adopters see value in them and then learn from the things that work.
Do you want a company to 1) only brew products (with a business model) internally until it is ready to ship, or 2) develop and release lots of things and see what works or not?
Google leans towards #2. They don't really care if they can make money off of something, if one of their engineers is interested in something they're allowed to take that risk. They put lots of stuff in the wild and if it doesn't stick then they kill it (or in most cases leave the source to the public - see wave) - or try to make it profitable (look at gapps).
Yes, a lot of things coming out of Google die, but that's only because they're putting out lots of things all the time. The day they stop putting out unproven stuff and only release v1.0 products is the day they lose their innovation edge.
It sounds like Lars himself may not have tons of expertise creating a language, but teaming up with someone who does and throwing in his own expertise getting it to run fast in a browser... might be interesting.
However, is there a concern here that only Chrome will support it for a while? Then anything you write in it will be Chrome only. Isn't that kind of like the bad old days when each browser had its own tags and whatnot?
Maybe for you, but not for the hundreds-thousands of people using it.
> Technology is not consist with web apps
What?
> all of the new web languages doesnt have a mature ide like Eclipse or Visual Studio
I'm going to assume be "web languages" you are talking about Python, Ruby, Javascript (on nodejs), and Perl. Most people get along fine with the existing tools. Many people don't even like ides like VS.
> me to use vim or emacs, i dont have enough time, i am not an idiot to fuck my brain with those useless shortcut keys.
Not sure how learning fast, easy shortcut keys would 'fuck your brain'.
> but real world dont have free time to play with these toy languages.
False. Developers in the 'real world' work with cool new languages, frameworks and tools every day. If you're not willing to learn them that's your own problem.
Javascript has fundamental flaws that cannot be fixed merely by evolving the language. We'll adopt a two-pronged strategy for the future of Javascript:
[...] Javascript has been a part of the web platform since its infancy, but the web has begun to outgrown it. The web development community has been backed into using large amounts of JS largely to work around the deficiencies in the platform. Complex web apps--the kind that Google specializes in--are struggling against the platform and working with a language that cannot be tooled and has inherent performance problems.[...] The emergence of compelling alternative platforms like iOS has meant that the web platform must compete on its merits, not just its reach. Javascript as it exists today will likely not be a viable solution long-term. Something must change.[...] The “clean break” option is extremely high risk--it will be a huge challenge to convince other browser vendors to rally around a new language--but is the only way to escape the historic problems with Javascript. Thus, its high risk is matched by the potential for a very high reward--a classic leapfrog strategy. [...] Dash is designed with three perspectives in mind: Dash is also designed to be securable, where that ability does not seriously conflict with the three main goals.Dash will be designed to be consumed in a number of locations:
[...]I actually ran into this a long time ago but couldn't find any comments on it anywhere (either backing it up, or debunking it as a hoax).