Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming The Internet Technology

MIT Unifies Web Development In Single, Speedy New Language 194

Posted by Soulskill from the write-once-run-somewhere dept.
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."
This discussion has been archived. No new comments can be posted.

MIT Unifies Web Development In Single, Speedy New Language More

MIT Unifies Web Development In Single, Speedy New Language

Comments Filter:

  • Haxe (Score:3)

    by wisnoskij ( 1206448 ) on Friday December 26, 2014 @10:23AM (#48675143) Homepage
    If I am not mistaken you can do the same thing in Haxe, and that includes Flash development as well.

    • Re: (Score:2, Funny)

      by Anonymous Coward

      If I am not mistaken you can do the same thing in Haxe, and that includes Flash development as well.

      Is that a feature, or a bug?

  • Finally! A single language! (Score:5, Funny)

    by Anonymous Coward on Friday December 26, 2014 @10:26AM (#48675161)

    Obligatory XKCD. [xkcd.com]

    • 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.

  • W3C, please. (Score:2, Interesting)

    by Anonymous Coward

    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, sema

    • I'm really sick of languages that are going to solve all our so-called problems.

      Languages have already solved for us the problems of numerically addressed storage, register allocation, memory allocation, compound data types, structured control flow, genericity/polymorphism of pieces of code etc. etc. Virtually all - if not all - pesky problems in day-to-day programming have been solved by appropriate language design. Why shouldn't a language solve the problem of concurrency and distributed applications?

      • Re:W3C, please. (Score:4, Insightful)

        by WaffleMonster ( 969671 ) on Friday December 26, 2014 @01:27PM (#48675953)

        Why shouldn't a language solve the problem of concurrency and distributed applications?

        Because this can only be effectively answered by the application?

        Language does not enable non-trivial problems to scale out... application architecture enables this and concurrency is of the same coin.

        • Except that both languages and "application architectures" are, so as to speak, both based on usefully constraining the set of valid programs. In the long run, though, stuff tends to move into languages, among other things because it allows checking of correctness at the earliest possible moment during development.

          • Except that both languages and "application architectures" are, so as to speak, both based on usefully constraining the set of valid programs.

            Sorry I don't understand what this means. If you design a data schema that can't scale no language selection, amount of clustering, sharding, money or associated BS is going to be of much help... this is just reality.

            Only when machines become smart enough to do the designing will this ever change. Computers can do a lot on the margins but ultimately if you want scalability and performance in a non-trivial problem space YOU will have to work for it.

            In the long run, though, stuff tends to move into languages, among other things because it allows checking of correctness at the earliest possible moment during development.

            What does constraint validation have to do with scalabilit

            • Except that both languages and "application architectures" are, so as to speak, both based on usefully constraining the set of valid programs.

              Sorry I don't understand what this means. If you design a data schema that can't scale no language selection, amount of clustering, sharding, money or associated BS is going to be of much help... this is just reality.

              This is true, but it does not lead to what you are claiming. A data schema (in a very general sense that goes beyond relational schema or XML data schema or whatever) might or might not scale (either by poor design choice, or by design).

              But that schema will depend on specific concepts and assumptions that will be best realized with a specific family of technologies (or even a single one.) It would be possible (but very hard and stupid) to try to implement a relational data schema with a document-oriented

        • app specific problem =/= app specific solution (Score:4, Interesting)

          by luis_a_espinal ( 1810296 ) on Friday December 26, 2014 @04:17PM (#48676827)
          I typically side with the camp that thinks concurrency and distribution (and other things like security or fault/partition tolerance) are application-specific problems because it is the set of application (or domain) specific requirements dictate how much or how little they require from each capability.

          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.

    • Re: (Score:3)

      by Livius ( 318358 )

      I'm really sick of languages that are going to solve all our so-called problems.

      I'm sick of languages that were going to solve all problems but then didn't.

      In web development, there's still room for one language that's half-ways good.

  • The bigger question IMHO (Score:5, Interesting)

    by popo ( 107611 ) on Friday December 26, 2014 @10:34AM (#48675197) Homepage

    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?

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      Compiled web pages are coming one way or another. All web servers are working on it in the next version of http protocol for binary implementation and all web browsers are concurrently working on this as well. It should speed up the net substantially as less traffic will be needed. The issue I have with it is the development of it in that they would have to setup half of their code to make sure it works in all client web browsers. I love and hate javascript for that very reason. JQuery is making it a bit b

    • The compiler could easily create a search engine friendly file that presents the page information for indexing and browsers are being presented with standard HTML so accessibility is not an issue.

      Gains in productivity from development teams, middleware that will compile and publish all released code, the obvious benefits from compile time checking of variables, arrays, etc. will probably offset the loss of flexibility of the development channel.

  • Ooh, I Have An Idea! (Score:5, Insightful)

    by Greyfox ( 87712 ) on Friday December 26, 2014 @10:45AM (#48675231) Homepage Journal
    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!

    • Re:Ooh, I Have An Idea! (Score:4, Funny)

      by Trepidity ( 597 ) <delirium-slashdot@@@hackish...org> on Friday December 26, 2014 @10:53AM (#48675255)

      But then how would you run it in a browser?

  • 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.

  • Well thank goodness (Score:5, Insightful)

    by DrXym ( 126579 ) on Friday December 26, 2014 @10:57AM (#48675267)
    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.

  • Frameworks (Score:3)

    by corychristison ( 951993 ) on Friday December 26, 2014 @11:15AM (#48675339)

    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.)

    • Re: (Score:3, Insightful)

      by Intrepid imaginaut ( 1970940 )

      I really hate using frameworks. They're fine as long as you use them for their limited purpose-set, but step outside the walled garden and your delving into a wilderness of minified spaghetti coded black boxyness whipped together over a weekend by people who weren't really interested or most likely able to envision different requirements.

      And yes I include JQuery in this. Just learn friggin javascript already, it's not that hard.

      • And I don't like people who do not grasp the difference between a framework and a library.
        Hint: JQuery is not a framework.

      • Re: (Score:2)

        by pr0nbot ( 313417 )

        I recommend Django to you. It seems to be written by clueful folk who care about things like backwards compatibility and fixing the small broken things rather than throwing it all away for the next version. As a bonus, it's not PHP.

  • 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.

  • Don't try to abstract a web page (Score:4, Insightful)

    by Parker Lewis ( 999165 ) on Friday December 26, 2014 @11:17AM (#48675359)
    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.
    • Could you explain what you mean by "old desktop program flow"? And what you mean by "working way different than that"? Since the only way I'm aware of doing web applications that work in the way that the web itself works is continuation-based frameworks, and those really don't get used by a lot of people. Most people aren't even aware of them, I'd think.

  • Frames in 2014 (Score:5, Informative)

    by Lobo42 ( 723131 ) on Friday December 26, 2014 @11:21AM (#48675377) Journal

    The demo site uses frames. FRAMES. I think this is unlikely to catch on.

  • speed is good (Score:5, Interesting)

    by e**(i pi)-1 ( 462311 ) on Friday December 26, 2014 @12:11PM (#48675595) Homepage Journal
    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.

  • Cures whatever ails ya (Score:4, Funny)

    by Marginal Coward ( 3557951 ) on Friday December 26, 2014 @12:12PM (#48675605)

    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.

  • Anyone here qualified to comment? (Score:5, Interesting)

    by Chelloveck ( 14643 ) on Friday December 26, 2014 @12:33PM (#48675693)

    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?

    • Re: (Score:2)

      by Shados ( 741919 )

      Its nothing special. The language itself is just yet another functional language variant, like ML, Scala, F#... hell, a lot of it can be done in C# or Ruby if you wanted to code that way. So thats pretty sound, more and more programming is going that way (you can even do a lot of it with the newer C++ specs)

      The specs are in math formulas because functional languages tend themselves well to that. I don't have a CS background either, but I've done enough functional programming to be able to infer what they m

    • Re: (Score:2)

      by bjk002 ( 757977 )

      I'm qualified. No, it's not useful at all. Just another abstraction...

    • Re: (Score:3)

      by NoKaOi ( 1415755 )

      The language definition is complete gibberish to me...I do see some red flags, though

      You don't need a CS background to see the red flags. You don't even have to get as far as the summary.
      "Unifies Web Development" - red flag #1
      "Single, Speedy New Language" - red flag #2

  • 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 language

  • 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.

  • Death by Manual (Score:5, Insightful)

    by fhage ( 596871 ) on Friday December 26, 2014 @01:15PM (#48675901)
    This language/framework has all the signs of an academic exercise.

    As someone who's been programming since the 1970's, I find it pretty hard to get past this statement in the Manual [impredicative.com]' "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.

    • Re: (Score:3)

      by Matheus ( 586080 )

      This.^

      I can't believe I just read that. New debugging cycle including your code might not work because the compiler doesn't like you that day? I felt like that when i was learning to code in C honestly but I'm sure it was rarely true ;-)

      A non-deterministic compiler can suck my big fat one and go far far away before the dribble drops.

  • 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.

    • Re: (Score:2)

      by PPH ( 736903 )

      Sounds like what you are saying is that thhis is a s/w development methodology that is even cheaper than sending out the coding work to a job shop in India.

      The next step is a language/compiler that can take chicken-scratches off a whiteboard in a brainstorming session and build production code from it.

  • 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?

  • From someone who's actually used it... (Score:2, Interesting)

    by Anonymous Coward

    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 t

    • 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.)

      That's a problem with sql, no matter what language you use. There are other ways to design a dbms that don't use sql ...

  • 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.

    • Re: (Score:2)

      by dbc ( 135354 )

      Riiiight. That's why we still use FORTRAN for so much new code.

      New programming languages succeed when they:
      1. Provide compelling beneifts to some group of developers.
      2. Are freely licensed (Java tried to break this rule for a while).
      3. Are well documented with both reference and tutorial information in many forms.
      4. Are delivered with a stable reference implementation.
      5. Are correctly marketed.

      I'm old enough that I did CS homework on punch cards, and I've probably learned and forgotten more languages than

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close