Slashdot Mirror
MIT Unifies Web Development In Single, Speedy New Language
itwbennett writes: A new programming language out of MIT, called Ur/Web, provides a way for developers to write pages as self-contained programs. It incorporates many of the most widely-used web technologies, freeing developers from working with each language individually. Ur/Web's author, Adam Chlipala, an MIT computer science assistant professor, will present his work next month at the Association for Computing Machinery's Symposium on Principles of Programming Languages. He says, "In Ur/Web, everything is based on transactions, where a single client request is handled by what looks like an uninterrupted execution of a single function. The language implementation has optimizations in it to support running many requests in parallel, on real servers. But the programmer can pretend everything is a transaction and think in a simpler concurrency model."
Lemme guess: it's called PHP!
If I am not mistaken you can do the same thing in Haxe, and that includes Flash development as well.
Troll is not a replacement for I disagree.
Obligatory XKCD.
http://xkcd.com/927/ Obligatory.
I'm really sick of languages that are going to solve all our so-called problems. We can't even get web developers to properly adhere to W3C standards. Now, you expect developers to implement stuff in the browser that's effectively a massive JavaScript runtime? The problem with web development isn't the languages we use, it's the way in which they're used. People are trying to hijack the browser to be an application delivery platform and failing to adhere to the W3C specifications. This breaks the open, semantic web. Get back to me when they come up with a "language" that lets me turn off JavaScript, cookies, and plug-ins in my browser and still have useful, dynamic content that can be understood by computers and machines.
Ur/Web is a Functional Programming language like Haskell, F# and the like. The performance gains are real -- both in numbers of coders and execution, but the larger questions remain:
Do we want compiled web languages? Why exactly? Not only does this introduce a compilation layer to the development workflow, but it introduces millions of "black boxes" into a once open and readable landscape. While there may be gains in code protection, there will also likely be losses in flexibility.
And of course, is it all worth the effort?
------ The best brain training is now totally free : )
The provided examples from the creator's PDF look like the typical spaghetti code you get out of academia. I can't imagine how awful it would be to maintain this as well as the limited skill level you are going to get vs. finding people specialized in each layer in the stack.
0 job postings for a new language is fine. I bet that if you go back far enough, you'll find a time with 0 job postings for Node.js. You could probably go back and find 0 postings for C# at some point. They all started somewhere.
The issue, imo, isn't the start... it's the "one stop shop" that is some how going to "Magically" going to combine at a minimum layers: Database, server, html, css, javascript.
I'd like to see how they handle Chrome vs IE and other incompatibility issues.
Oblig KXCD: http://xkcd.com/927/
HR people are just waking up. By the end of the day, you'll see some looking for 5 years Ur/Web experience.
What if, instead of doing that, we came up with a language that you could use to build your program without a browser? Now stay with me here, I know this sounds crazy, but it could work! Since you're not working with a fundamentally stateless protocol, this language wouldn't need to maintain state externally to itself! All its variables and state would be self-contained! But since you might want to pull data in from the network or a database or something, you could add interfaces to that functionality to your language! Wouldn't that be something? I know, I know, this suggestion has been made, like 12648430 times before, but I think it's a really good idea that could work!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Don't hold your breath...
If we could take the ego out of invention the profs might realize that *another language* is not what is needed.
Understanding the languages we're using... that's what's needed.
Looking over the official tutorial pages, the syntax is really different than anything I've done before. It looks hard to learn. It looks like the functions are just called "fun". Let's go have some FUN!
I know it is not fair, but the tutorial pages have no styling at all. It kind of takes away from the supposed "new hotness".
I always thought that the one thing web programming needed was YET ANOTHER PROGRAMMING LANGUAGE. One that seems to reinvent cgi programming combining business logic and structure into a single file and tosses the lot into a functional programming blender so nobody has a fucking clue what's going on.
This is what frameworks are for.
There are thousands of different frameworks for various languages to accomplish effectively the same thing with the benefit of using an already established web language (PHP, Node, Python, Java, etc. etc.)
Will this work with IE? Or will they release, i/Web a new API that is designed to write pages as self-contained programs by incorporating many of the most widely-used web technologies, freeing developers from working with each language individually in a very similar fashion as Ur/Web, but without the key API functions that would allow it to be compatible with any other browser. .... Not that this has ever happened before.
Select from tblFriends where interesting >= 4;
How does this differ from Smalltalk's Seaside? It, too, has coroutine-ish interaction with the client.
There's also a Perl module implementing the same sort of client-server discussion.
This is fundamentally wrong: the're not only trying to abstract all technologies and flows involved in web page development. Most of these languages and frameworks want to provide the old desktop program flow. And the way web applications works is a way different than that. A good web programmer need to know all the flow and involved technologies.
The demo site uses frames. FRAMES. I think this is unlikely to catch on.
Are you being stupid on purpose or what?
"Ur" is a fairly common way to represent an origin or prototypical item of a set, as in a "ur-language" would be the mother tongue from which other languages spring. It seem to be being used in this context to mean more "all-encompassing", or a back to roots type thing, but the meaning still applies.
Why am I responding to an AC troll....
No, that link you posted to a web comic we've all seen a hundred times is not "obligatory."
having on the server side fast and efficient code is nice but there are a plethora of webserver technologies out there and they can interact with virtually any programming language in the background having various technologies working together and having them developed indpendently has lots of advantages. Why bake everything together? Having sepearte entities (server, authoring language, scripting languages, databases) allows more flexibility. Efficiency and simplicity is nice but one can also overdo it. I learned real programming in Pascal, but Wirth soon started to develop the more efficient Modula, then Oberon flavors. Pascal started to stall. Oberon was great, everything, the compiler, operating system, everything fitted on one floppy. From the application and developer point of view it is a disaster to know that the shelf life of a programming language is only a few years, until the developer loses interest finds a better way to rewite the entire thing. This is especially the case for creative guys like Wirth. At one point, (oberon I) he even thought it would be nicer to have no FOR loop, as FOR loops leads to bad programs. Well, he had to reintroduce it in Oberon II. Academic elegance and theory not always goes parallel with the real world.
From TFA:
Not only do they not crash during particular page generations, but they also may not:
- Suffer from any kinds of code-injection attacks
- Return invalid HTML
- Contain dead intra-application links
- Have mismatches between HTML forms and the fields expected by their handlers
- Include client-side code that makes incorrect assumptions about the "AJAX"-style services that the remote web server provides
- Attempt invalid SQL queries
- Use improper marshaling or unmarshaling in communication with SQL databases or between browsers and web servers
Cures whatever ails ya. Works even better than snake oil! But wait, there's more. For just $19.95, we'll design two new web programming languages. Just pay separate shipping and processing.
I'd really like to hear from someone outside of academia who thinks this is useful. I've been programming in C-like languages ever since I graduated college 25 years ago, but my degree is in EE, not CS. The language definition is complete gibberish to me, containing solid pages of a mathematical notation that I've never before seen. Likewise, I have a very hard time following the demo code. I don't really feel qualified to evaluate it.
I do see some red flags, though. First, since the language spec is given in such an abstract notation I have a feeling that it's going to be very difficult for code monkeys like me to refer back to. I normally reach for the language spec or the official docs when I have a question, but neither are going to do me any good here. Similarly, the tutorial starts out by describing the similarities and differences between Ur and ML or Haskell. That'd be a lot more useful if I'd ever used either of those two languages. The tutorial is incomplete, and what's there never describes Ur on its own without comparing it to the other languages.
Second, the trivial demos look like some PHP variant, while the complicated demos are, well... Complicated. "Hello, World" simply returns a chunk of what appears to be free-form XML; some others return a chunk of XML with a few embedded Ur statements, similar to PHP. The SQL demos show embedded SQL statements. Are the XML and SQL chunks syntactically part of the Ur language thus checked for well-formedness, or are they just free-form text which get minimally processed to substitute variables before they're emitted? Or is there something else fundamental going on here that I'm missing completely due to my lack of familiarity with functional programming?
Third, the official web site looks like something out of 1995. That's not necessarily a bad thing. It is clean and functional, just really, really utilitarian. I assume the site is done in Ur/Web, and it's clear that the author of the language learned HTML back when Mosaic was the hot new browser. Is the utilitarian look just how the author or site designer does things, or is it baked into the language? How hard would it be to implement something that looks modern? In the same vein it looks like Ur/Web produces xhtml as its output, and it looks like Ur/Web pretty much relies on well-formed XML embedded in the Ur source code. Will it have access to any of the new goodies in HTML5? Or is it going to be obsolete before the first Dummies book can be written?
So if there's anyone here who does real-world web development and has the academic chops to evaluate Ur/Web for what it is, would you please post a summary for us code-troglodytes?
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
Ur could be:
You Are
Your
An acient city in the Sumarian region of the middle east
University of Rochester (New York, not MN)
Might be something to do with bears too (Ursa)
In my view presence of domain specific languages throughout data, application and presentation tiers is the source of the platforms power. It's what makes it not suck.
Yes annoying for beginners to have to learn w,x,y and z just to do anything... what is even more annoying is consequences when it comes time to stand up non-trivial systems.
In my view the future of programming will be about the rise of domain specific languages where very little room remains for lies and assumptions generated by glue languages.
It's trying to abstract away things like the database and the separation between client and server side. Every attempt to abstract away real things that I have seen has been crap. When you abstract away the HTML and the SQL and the AJAX, it means you can't dig into it for the nitty-gritty. If they finally got it right, congrats, but I doubt they have.
Democracy Now! - your daily, uncensored, corporate-free
As someone who's been programming since the 1970's, I find it pretty hard to get past this statement in the Manual' "We give the Ur language definition in LATEX math mode, since that is prettier than monospaced ASCII".
The author's choice precludes anyone cutting and pasting difficult syntax from the reference manual into their program. Look at page 26. Does any programmer find this useful? Scanning down to the more practical bits, I find;
"The Ur/Web compiler is unconventional in that it relies on a kind of heuristic compilation. Not all valid programs will compile successfully. Informally, programs fail to compile when they are “too higher order.” Compiler phases do their best to eliminate different kinds of higher order-ness, but some programs just won’t compile."
Really? Valid programs may not compile. I wouldn't spend a second learning any programming framework with this fatal flaw.
Inherent in the transactional paradigm is tokenization emergent as the exchange currency needed for efficiency. SO this is a first step toward monetization platforms abstracting out the software labor component.
the concepts behind Clojure and its sibling ClojureScript are exactly what they are describing. Maybe the time would be better spent popularizing a language with immutable structures and software transactional memory as opposed to creating yet another one?
Your pizza just the way you ought to have it.
""Ur" is a fairly common way to represent an origin or prototypical item of a set,"
Oh yeah , in which niche arena is this? I've never heard of it. Seems to me it was meant to be a hipster way of saying Your Web. And it failed. Miserably.
Ur/Web isn't easy to use. It's a huge pain to get any program past the type-checker, not just because the compilation errors are hard to understand (though this is a fixable problem, and one that Prof. Chlipala has been working on since I used it, if I'm not mistaken), but because it's always going to be an order of magnitude harder to develop in Ur/Web than in a dynamic language like Ruby etc., especially when you need to use stuff like higher-order polymorphism and functors and other concepts from type theory which I confess I don't understand.
So what's the benefit? The point is "provable correctness". In C, if you write outside the bounds of a buffer, you get no help from the language in preventing bad things from happening. In Ruby, if you try the same then the language catches the error at runtime, but you have the overhead of an array-bounds check on every write. In Ur/Web, you get the best of both worlds: since the compiler /proves/ that no buffer overflows can occur, then there need be no checks at runtime, so you get better performance.
And the same concept applies to pretty much any concept of "correctness" you'd like to express. Ur/Web has an entire SQL type, rather than representing SQL as strings, so that the compiler can prove that no SQL injection attacks are possible. (It's not possible to accidentally coerce a string to SQL---you'd have to really try.) It's possible, in principle, to express any kind of invariant you'd like using a type system like Ur/Web's. (Ur/Web doesn't include some constructs, e.g. dependent types, for reasons of language simplicity, but you can envision a similar language which would). In a dynamic language, you have to create more and more complicated (and slower) tests in order to show that your program has the same properties---and of course, your tests could always miss an edge case.
So who should use Ur/Web? Anyone for whom security is a bigger concern than ease-of-coding: banks, the military, hospitals, etc. If you want to whip up a quick web app, then Ur/Web is probably not for you. But if you need security, and you need to be certain you have it, then you should consider Ur/Web.
Hearing a disturbance, the master programmer went into the novice's cubicle.
"Curse these personal computers!" cried the novice in anger, "To make them do anything I must use three or even four editing programs. Sometimes I get so confused that I erase entire files. This is truly intolerable!"
The master programmer stared at the novice. "And what would you do to remedy this state of affairs?" he asked.
The novice thought for a moment. "I will design a new editing program," he said, "a program that will replace all these others."
Suddenly the master struck the novice on the side of his head. It was not a heavy blow, but the novice was nonetheless surprised. "What did you do that for?" exclaimed the novice.
"I have no wish to learn another editing program," said the master.
And suddenly the novice was enlightened.
This lesson from The Zen of Programming is as relevant today as it was 30 years ago.
Not that there's anything inherently wrong with these technologies, but when your language seems to be based on that way of doing things ... I think the 1990's called.
This is what I have been saying all along as holding the web back - two few programming languages.
Now that we have this new language, we can finally move forward.
The idea is good. But please, this is not hard to understand. NOBODY is going to learn a brand new language and new syntax unless they're under 22 or they've never learned another language and just stumbled into your new wunderkind.
Make a version of c, basic or Javascript that does the same thing and you have a remote chance of adoption. Make a new version of web erlang and you might as well be jacking off on Mount everest in the dark. You're safe because nobody will ever see it.
Please do not read this sig. Thank you.
Luckily I have 10/yrs experience developing enterprise grade Ur/Web applications for modern, agile, development studios with a range of clients from small, quick, engagements for marketing campaigns up to enterprise applications that have grown form multiple frameworks and stacks being used across an entire horizontal market.
Yeah , I'm suuuure thats why they chose Ur. Nothing like retrofitting a reason is there? Also someone should tell them the difference between ancestor and descendent because clearly they have no idea.
I thought people were pretty much ignoring IE these days.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
HR people are just waking up. By the end of the day, you'll see some looking for 5 years Ur/Web experience.
You're just jealous... there's 1000's of H1-Bs over in India with at *least* 5 years of Ur/Web experience.
I think we have some working for us. The price was right.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Besides, everyone knows you should be using Emacs.
No, wait...
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
This particular xkcd strip has been referenced so often at this point that I think we can just write "xkcd 927" without even linking to it.
Get free satoshi (Bitcoin) and Dogecoins
With that said, I disagree with this:
Why shouldn't a language solve the problem of concurrency and distributed applications?
Because this can only be effectively answered by the application?
An application can only effectively address such challenges when using the appropriate levels of abstraction. And by *appropriate* we mean not just appropriate in the level of high (or low) level features, but also in the amount of resources that are required to construct a system with the right synergies between application and supporting (underlying) platforms.
For instance, having an actor model supported as a language feature help application domain developers exploit (or create) the necessary abstractions for concurrency far more economically than using an actor model developed from scratch (or as an add-on framework)... at least for applications whose concurrency requirements are best served with an actor model over more low-level constructs (locks and shared resources)
Or think fault-tolerance. A language that has concepts such as a valves as actual language or run-time features is far more valuable for developing certain classes of fault tolerance systems than languages or runtimes that do not have any (a reason why most systems are not equipped with any means of throttling to cope with partial failures.)
Language does not enable non-trivial problems to scale out... application architecture enables this and concurrency is of the same coin.
Resource-efficient realization of an application architecture into a design and implementation are highly dependent on the language and run-times of choice.
What isn't a Node.js replacement?
Actually you can use Emacs now indeed, with current memory sizes 'eight megs and continiously swapping' won't happen anymore :)
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
If it is then it is DOA. ;) Sorry all you php fans, but seriously?!
;)
But seriously seriously: I don't believe that is the approach he is talking about. PHP is a very different beast.
Their choice of a functional programming language is an eyebrow raiser but I understand the reasons why and can even applaud the sentiment for high volume transactional websites. (speaking as an architect with experience of such in the CC industry) I do sort of lament the lack of any OO framework within this (my assumption from article) but perhaps it is not needed as much since most data is from a relational DB. The incongruence between relational data and OO design has always caused problems anyway - obvious in the complexity of frameworks like "hibernate" etc.
And for those that think that OO and functional languages cannot mix need to do a course on multi-paradigm programming like I did.
The CONCEPT has real potential and it will be interesting if and how these (assumedly MIT-smart) researchers deal with the main problem that any "do lots for you behind the scenes" (I am inventing a new architectural pattern here!) frameworks: Sacrificing flexibility of solution for ease of use.
This is where limits are introduced because frameworks are forced to make choices about implementations and those choices have consequences. Implementing an elegant and simple solution with a huge amount of flexibility, easy extension and power is one of those holy grails that I have yet to see ANY framework in existence reach to any degree - there are ALWAYS trade-offs.
Many of these frameworks start off with the claim of "really simple!!" but over time their lack of forethought and the punishing reality of REAL project development (as opposed to the dreams of researchers) causes the language to either be wholly inadequate or to mutate over time into an absolute nightmare.
e.g. Auto hot key STILL makes the claim on their website that they are so easy to use, despite what their language has turned into: http://www.autohotkey.com/
A very good example of this principle in action.
e.g. VB was very productive (for its time) when all you did was use the out of the box stuff the language was designed for. Go off road (which inevitably happens in real projects) and you could enter VB hell very very quickly. Fixing said problem was usually possible but at the cost of a HUGE increase in skill and knowledge which is beyond many of those who picked it for its easy of use.
So the questions I would be interested to find out are:
- How far can you get before the above happens?
- What percentage of typical advanced web app functionality is covered?
- How HARD is it to extend (I assume its possible) and what skills are required to do so?
There are of course thousands of others to answer before I would even consider using this in a real product!
Actually you can use Emacs now indeed, with current memory sizes 'eight megs and continiously swapping' won't happen anymore :)
That's actually true. Very good point. And considering there's an Emacs plugin to do pretty much anything and Emacs runs on pretty much every platform, there's really no reason (anymore) to use a different editor for anything. Ow, I think the master just struck me on the side of the head. The master speaks: "Emacs is not an editor, Emacs is an operating system".
(Before the editor wars start anew, this was written somewhat in jest. As a sysadmin I had to support Emacs, but I remain a VI user. And yes, I know there's an Emacs plugin to emulate VI. Which is precisely like mounting Volkswagon Beetle controls in a Mack truck.)
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Haven't you heard? Frames are the solution to every technical problem that you will have in the future. After all, frames securely mediate, by design. Secure multi-mediation is the future of all webbing.
Of course Emacs is an operting system! However it lacks a decent editor!
That is why I use vi/vim as well!
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Of course Emacs is an operting system! However it lacks a decent editor!
That is why I use vi/vim as well!
I always thought that was the real reason Emacs had a VI emulator plugin -- because every OS needs an editor.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
So kind of like Zope, but less portable.
It takes 2 clicks on Haxe's site to see it can be used with lots of different kinds of client and server code. Flash is mentioned as an "also, haxe can make swfs" http://haxe.org/use-cases/web/ (despite Flash being a huge part of Haxe's maturing development) http://en.wikipedia.org/wiki/H...
Flash development and ActionScript as a language were never "shit". It certainly was abused and mismanaged, but technologically Flash/AS was amazingly useful -- especially in tying animation to code.
If you ever are willing to challenge your own beliefs you should take some time and checkout Haxe, and Apache Flex. Try keeping an open mind to technologies that greatly shaped the web we have today. A lot of ECMAScript was based on lessons learned from ActionScript. A lot of web games and comics were brought to you by Flash. YouTube, Twitch, Hulu, Yahoo Maps (formerly), and thousands of games, all were built on the backs of Flash. Firefox's original JIT was based on Flash 9 and donated by Adobe and is the second largest open source code donation ever to Mozilla.
Does Flash have problems? Definitely.
Should you dismiss a huge part of the web out of hand? Only if you want to make yourself look like a fool.
meep
I've seen it used in archeology and linguistics.
Ur welcome.
His ignorance covered the whole earth like a blanket, and there was hardly a hole in it anywhere. - Mark Twain
Come on guys! Framesets in 2014, seriously?
Any German will know. It's use stems from a time when you were just as likely to find a scientific text in German - the 99.99% English dominance (in international scientific publications) happened after 1933...
http://www.word-detective.com/...
http://en.wiktionary.org/wiki/...
http://en.wikipedia.org/wiki/U...
Microsoft tried the compiled web page idea with .net, it was called a "Smart Client". You wrote a desktop app, basically, that was "served" through the browser (which, of course, had to be IE). In essence it was the "browser as MSI delivery system on the fly". Managed a team of guys who wrote a large, complicated labor tracking/payroll system in it. When it worked, it was awesome. Sadly that wasn't as often as management liked...
.net guys never talked to each other. So as long as you had .net run time version 1.2.6.9982 and MDAC version 2.8.9.3345 and IE6 version 6.0.22.3.44.54588 it worked great! Otherwise nobody got paid, sorry.
Remember the versioning issues all these compiled solutions had? The "Smart Client" solution (compiled web pages) didn't account for different versions of IE, and of course the IE guys and the
So if we could just get everyone to run the same, exact browser on desktops & mobile devices... then Url would be a grand and glorious solution, provided we had a single entity who controlled it... that we paid the requisite licensing fee too... and we all upgraded en masse. Oh, wait a minute, isn't this the same, exact state of the world before the Internet came along? That we never quite achieved, because no one company could ever dominate anything?
So if the government just mandated that we all use Url, on a specific hardware configuration, all using the same everything... this could work! I'd wager that's the dream of the ivory tower Gruberist folks at M.I.T.....
Murphy was an optimist
Another language that is similar to, but not quite resembling, an existing language. Honestly I am finding it difficult to keep up with all the different frameworks and languages and such. Bootcamps churning out web developers who learn how to make pretty pages but have no foundation to build upon, like data structures and algorithms. A seamstress goes to a web developer bootcamp and now all of a sudden she thinks she is a rockstar software developer. She may be awesome with her HTML, killer using CSS, but does she know how to get data from a database? Then you have the marketing guys who will want to use this new language. First it was the cloud, everything was about the cloud. Then it was Big Data, yes lets do that, lets do big data. They jump on every new trendy hip thing out there. Then the IS directors and HR managers try to hire someone with experience in the new language that just came out. How are you going to find someone with 1-2 years experience in it unless it is the person who wrote it? What we really need is for the existing languages to enforce good programming practices. Not to be picking on anyone, however, have you ever looked at some of the code out there? So many of these so-called programmers can't seem to use a newline character, or an indent. And adding comments in their code is like giving away information to the enemy. I would like to see more standardization and less new baubles and shiny bits.
Karma, We don't need no stinkin' karma!
It's nice to see the pendulum swing back to static analysis of your code. If you want static code analysis, GWT is very stable and all the issues worked out, which there will be in a 1.0 release. GWT's UIBinder is one 2.0 feature that cleans up your code quite a bit while keeping static code analysis. The compiler will error when Java code refers to UIBinder's HTML markup that doesn't exist.