“Opa, a new opensource programming language aiming to make web development transparent has been publicly launched. Opa automatically generates client-side Javascript and handles communication and session control. The ultimate goal of this project is to allow writing distributed web applications using a single programming language to code application logics, database queries and user interfaces. Among existing applications already developed in Opa, some are worth a look. Best place to start is the project homepage which contains extensive documentation while the code of the technology is on GitHub. A programming challenge ends October 17th.” This is weird. ‘Opa’ is the nickname my friends gave me 6 years ago. It’s still used more often than my actual name…
For all the non-germanic speakers out there.
Opa (Oupa) translation (Literal): Old Dad (Real) Grand Dad
<pedantic>
Non-germanic speakers won’t be able to understand that comment.
</pedantic>
Edited 2011-08-26 00:15 UTC
Opa equals the english “Grampa” (grandpa, grandfather), i. e. the father of your mother or your father. This should be precise and pedantic enough for now. 🙂
[EDIT] Sorry misread
ead the comment.
Edited 2011-08-26 07:49 UTC
Sorry for a skeptical comment but I can’t help the feeling that Opa is a yet another language designed to unify all languages and frameworks (like most of these languages and frameworks).
Perhaps it’s a great new thing and in a couple of years we will be talking about it like we talk about JS, Python or Ruby. But the chances are it will fail like many of its predecessors. Sometimes less is better. Could someone briefly list what we can do with Opa and can’t do with other languages?
Also, the application itself is rather narrow and doesn’t add much value. What does “transparent web programming” mean and why it is better than “opaque web “programming”? Could anyone give a scenario in which that would be a “killer feature”?
I can give a couple of reasons why it is worse:
– it takes away flexibility in choosing server-side or client-side technology we use,
– it has fewer features (unless Opa wraps every possible framework and does it perfectly),
– it affects performance,
– it violates rule of separation of concerns – many developers want to keep server and client side separate – if only for security or keeping the server-side part private, perhaps even these parts are developed by different people who don’t know much about the other side of the fence.
The language REBOL allows similar use in both client and server side applications.
There are big advantages to this as applications become much smaller and cleaner. My own website has no HTML source and so is described in about 50% less code than would normally be used and I can stay entirely within the mindset of REBOL.
But OPA doesn’t seem to get rid of HTML, as far as I can tell in the source for the various examples on github.
Perhaps OPA is too stringently designed to be specifically used for this purpose by simply mashing these parts into the language, and it’s not pretty.
Why not simply use the best available “native” toolkits for both server and client side? Is it worth sacrificing all these tools and libraries for some elusive uniformness.
The only reason, I can think of, for using the same language and toolkit for both sides is you can juggle some of the components back and forth during deployment or even in runtime. That seems cool but it is almost always a bad idea in practice.
I’m actually not a web guy but a few years ago there was a lot of discussion about merging development of software and hardware (HDLs) – I don’t want to say that this approach has failed – there are people using it. But they do it almost exclusively for verification – unification at the test level and modeling. Implementation still has to be done in a domain specific manner if you want to get competitive results.
I use a tool called Script# that “compiles” c# code into JavaScript. Actually it kind of facelifts JavaScript to look and behave like c# because it doesn’t try to hide that you’re ultimately writing JS code.
The reason for that? Maintaining a large project with tens of thousands of lines of JavaScript scattered in many files is quite the nightmare. That language is fine for adding blinking stuff on a page real quick but anything medium to large scale will become difficult. Google does that too with their GWT.
The news is probably not very well written in putting forward the “unified” paradigm. The project website is better at explaining what Opa does well.
But I don’t think your arguments hold since:
– You can choose (if you want) whether a given piece of code runs on the client or the server using @client and @server directives. Thus, it’s more flexible as changing the design does not imply recoding.
– Opa has JS and C bindings.
Edited 2011-08-26 13:48 UTC
Skepticism is the beginning of interest, so don’t apologize 😉
I don’t believe in the “one language for everything” approach. You may love Haskell, but sometimes you still have to write a bash script or a Makefile. See what I mean ?
So Opa does not claim to unify all languages and framework, it only intends to become the best option for many usages. These usages are web applications in general, and more particularly those with rich client-side effects, and/or which need high scalability (the “cloud” aspect of Opa). As it’s a new language, it will also be better for new applications, although there are many way to integrate smoothly with other languages (either natively or via REST).
One of the key features discussed in your comment is “transparency”. That means that the same piece of code you write gets compiled both to native server code and to JavaScript, and that communication between the client and the server are handled automatically. Yes, it takes away flexibility, but most of the time you don’t care about this flexibility. If you do, it means you are concerned with low-level behavior, and Opa may not be your best option. The performance issue does not hold: there’s no reason why hand-written communication code would be better (again, in general, I imagine you can find specific examples where it would be false).
About the features, yes Opa is young and its library is growing rapidly but does not have “everything”. However, it has a very smooth mechanism to integrate external code in JavaScript, OCaml or C. The supported languages might be extended in the future.
About security, it was in fact one of the main concern and motivation for Opa. What are SQL and XSS injections ? They are the result of a mismatch between two languages, that is not handled properly by application developers. In Opa, there’s only one language, and all communication is handled by the language. We’ve done our best, but imagine there’s still a security flaw there: when it gets corrected, it will be corrected for every Opa applications at once. Do you see the power of handling security at the language level ?
unify? no… it is a language and framework meant to compile to optimized (i.e. not very human readable, but highly efficient) Javascript, CSS, and HTML 5 code.
The idea is sound and makes a hell of a lot of sense. I there is, however, nothing special about Opa that prevents other common languages from being used for the same purpose. The compilation tools simply need to be built for them.
Why is a new programming language required to “make web development transparent”?
Opa automatically generates client-side Javascript and handles communication and session control. The ultimate goal of this project is to allow writing distributed web applications using a single programming language to code application logics, database queries and user interfaces
Wt http://webtoolkit.eu does exactly the same but in C++. You develop webapps like desktop apps: widgets, ORM, etc. No need to care about Javascript, HTML, etc. Compilers available on all platforms. The result is a single binary which includes an embedded HTTP(S) server.
While I agree with what Opa wants to achieve, inventing a new programming language for that end is unnecessary and, in fact, will become a burden: they will need to maintain both the language and the library. But actually the value lies in the library, which is the one that needs to deal with HTTP, Javascript, AJAX, etc
I tried Wt and yes, you don’t have to worry about HTML5 or Javascript or whatever. Good for me!
“Opa” is not a new concept.
Edited 2011-08-26 11:37 UTC
Have been looking into Wt (aka witty) myself so you are right the concept isn’t entirely new.
There were, however, tablets before the iPad and MP3 players before the iPod. Being first isn’t a substitute for getting it right.
Not at all sure Opa has it right but I’ll take a good look.
Way too much web development has involved 4+ languages in a single source file (HTML, CSS, JS and (say) PHP) which has to be crazy for any developer focussing on a real application task.
Furthermore I would love to have my web development underpinned with tools that sort out the multiplicity of browser foibles out there without me tearing my hair out. A recompile with the latest tool edition, I can handle but working around each bug in each version of each browser saps my will to live.
The language is not even really new. They claim it, but it looks more like ML with some new keywords
Well ML is not itself really new, as it is inspired by LISP.
But just as LISP type system was too week for Robin Milner, the main idea behind Opa is to create a new, richer, type system for web applications.
Seems new “enough”.
Any press-release is going to hype up its topic.
I’ve been programming with Opa for all of 24 hours now, but it has some neat ideas. There is an artificial dividing line between client and server in most apps, and often significant boiler-plate in keeping them in sync. I’ve used common javascript code on client and server before to mitigate this, but it isn’t painless. Opa so far does that quite nicely.
It is vaguely ML-like and written in Ocaml.
But I don’t really get why the resistance to ‘another language’. I say bring it on. Every language is another attempt to build a grammar around a problem space, and that encourages different thinking patterns. You might not use Opa for anything but experiments (actually because of its license, I definitely won’t). But its design might influence how you build other apps in the future. And if not, at the very least, it means you’ve learned another language. And the more you learn, the faster you learn them. The first couple of dozen are definitely the hardest….
@idmillington: thanks for your candid interest in Opa. I understand you don’t like its licence, though. We may be open to changing it. What would you advocate instead ?
Maybe LGPLv3? Allows linking/using the framework without ‘infecting’ the code ‘linking’ against it. It also solves the Tivoization problem which is obviously a concern with server side code that gets deployed but not distributed in the traditional sense.
The problem with the license is that it doesn’t fit with the commercials of how I do the web.
Typically I grind away for a couple of months, building something neat, then release it, and it either flops or gets some traction. If the latter I find some money to throw at taking it more seriously.
The license as I read it is incompatible with this. Either I have to release my source code from day 1, or I have to pay from day 1. If the former, then I’ve got virtually no defendability, if the latter then I can’t afford to use it. So it just doesn’t work out for me beyond messing about.
Although AGPL is used for Mongo, this is a different kettle of fish, because with a DB, there is a fire-break at the interface (and the Mongo interfaces are Apache licensed). I don’t have to share my application code with the world, only stuff I do to Mongo itself (which I’d imagine almost nobody ever does).
In short AGPL for a programming language is always going to seriously hurt, if not totally torpedo adoption. But obviously a BSD-style license isn’t painful enough to encourage many to pay you. Its a catch-22. But I suspect you’ll probably end up being forced to use a more liberal license in due course, to encourage great apps to be written which in turn will raise Opa’s profile. The ultimate aim has to be for a big-huge-web-success-story to say “We built our system on Opa”, and a company that you can provide vast amounts of training, consultancy and support for – that, I think, is a numbers game, ubiquity is more important than incremental revenue at this stage, imho.
Now a few more days into playing with Opa, and I do think it has some very strong points. I also very much like the effort that has gone into documentation. It is an impressive package.
Anyone interested in this kind of unifying language should also look at http://haxe.org which is more C-like and has back-ends for Javascript, Flash, C++ and the Neko VM.
I personally do find this paradigm useful for writing Javascript because having a strongly typed language like HaXe (or Java/GWT) helps catch a lot of errors in the compilation phase.
HaXe is an interesting project, but I think it’s quite different.
Opa is about web apps, while HaXe is mostly for programming multiplatform games.
They have some overlap (generating JS code) but that’s not much compared to the many non-overlapping features of both projects.
Isn’t that basically like GWT?
There’s a good comment on Lambda the Ultimate comparing the new web programming approaches w/ Opa:
“Hop
Hop is a dialect of Lisp, interpreted, highly-dynamic. IIRC, the project does not care much for security, concurrency, distribution. Opa is compiled, with static type inference, guarantees numerous security properties, plus offers a nice paradigm for concurrency, distribution.
Volta
IIRC, Volta is dead since 2008. From my recollection of the Volta paper, they had huge security concerns and no real idea on how to solve them. Opa solves the problems they mention. I’m afraid I do not remember much more about Volta.
Ur/web
Ur/web is focused largely on meta-programming and functional reactive programming for concurrency and user interface manipulation. By opposition, Opa does not really care about meta-programming, and is more focused on Join-calculus-style concurrency and distribution. Also, the storage mechanism of Ur/web is based on PostgreSQL, whereas Opa’s storage mechanism is immediate storage of data structures, with maximal sharing.
Hilda
I am not too familiar with Hilda. However, from what I understand, the language is very much data-driven, while the core of Opa is much more like a concurrency-oriented.
GWT
GWT itself essentially covers the client-side. Vaadin, which is an extension of GWT to the server, seems closer to Opa. Also, GWT is based on Java, whereas Opa is functional+agent programming.
Links
Links and Opa are based on quite similar ideas. Similar concurrency model, similar type system, both implemented in OCaml. The main differences appear in the standard library (considerably larger in Opa), in the database (relational in Links, graph-based in Opa), and in the effort towards distribution (non-existent in Links). Also, I am under the impression that the Links project is currently on hold.
WebSharper
WebSharper and Opa are based on rather similar ideas. However, WebSharper uses F#’s type system, whereas Opa uses a structural type system, client-server distribution does not appear to be automated in WebSharper by opposition to Opa. I have no idea what the concurrency model of WebSharper is, or even if there is concurrency or server-side distribution in WebSharper.
ML5
The ML5 compiler has a very nice client/server distribution scheme that is quite similar to that of Opa, possibly more powerful at the expense of being less automated and harder to learn. Beyond this, it is hard to judge, as IIRC, ML5 is currently at the state of a (very promising) prototype, whereas Opa has been used to develop commercial applications.”
this should have been a URL link