Announcing Opa: Making Web Programming Transparent

phy_si_kal writes "Opa, a new open source 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 logic, 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."

Comments

very expensive to implement

[Tumbleweed]

Every time you do something in Opa that is successful, you have to break a plate. Opa simply isn't economical to scale.

Re:very expensive to implement

[Anonymous Coward]

In German too. So Germany, Austria, half of Switzerland and Luxemburg are already going WTF or laughing before they even check if itâ(TM)s useful.

(It's not. There is a reason there are different languages: The right tool for the right job. Trying to auto-translate e.g. JavaScript into SQL or regular expressions, is bound to result in a horrible frankenstein monster [which luckily is as slow as a glacier]. And for those languages where itâ(TM)s easy, like PHP, Python, Java, C++, it's not worth it since they are so easy that if you know one, you can learn the other one in a single day.
The real problem are the different libraries. Those are the ones that need unification. [But there should still be at least 3 competing unified libraries, so no monopoly or duopoly can ever happen.] Provided they don't ignore the language differences.)

Re:very expensive to implement

[Tumbleweed]

This is why commercial entities do a namecheck before choosing names :)

aka The Chevy Nova Effect

Re:very expensive to implement

[Jaxoreth]

Hehehe... and in Dutch, it means "grandfather".

"Yeah, I wrote this program in grandfather and..." (voice trails off under whithering stare of boss)

This is why commercial entities do a namecheck before choosing names :)

But if the name was chosen before the checking policy was instituted, then they get to keep it. I think there's even a word for this practice...

Re:very expensive to implement

[Seferino]

You do realize that we could use the exact same reasoning to pretend that, say, compiling C++ to assembly language is pointless, just because both languages are so different, do you?

How is it different from, say, Wicket or ZK?

[Cyberax]

How is it different from, say, Wicket or ZK, or even GWT?

I can write complete AJAX-y webapps in Wicket or ZK, including database. They both store state of pages on server side, so AJAX becomes trivial (just rerender the page and send the difference in DOM trees using JSON).

Then there's GWT which compiles static Java code into JavaScript.

Re:How is it different from, say, Wicket or ZK?

[icebraining]

How is it different from, say, Wicket or ZK, or even GWT?

Not having to use Java?

Re:How is it different from, say, Wicket or ZK?

[Seferino]

Nope, it doesn't (note: I'm the architect-in-chief for Opa). Java is used only in the compilation process to run the Google Closure Compiler as a sanity check on our JavaScript libraries. Thanks for the great work by the Google team, by the way, this saved us literally months of JS debugging.

Re:How is it different from, say, Wicket or ZK?

[Seferino]

Why yet another language, though, I don't understand. We already have plenty that could be readily used for something like that (C# 5 with "async" feature would be very handy, for example), or you could take one and add some minor extensions.

Well, that's simple: when we started working on Opa, most the languages available today and that could be used to achieve similar features were simply not available. For the automated and secured client-server distribution scheme, we needed some advanced static checking, which ruled out Erlang — or which would have required us to largely reinvent that language. For client-server distribution and for handling many clients, we needed some advanced concurrency mechanisms, which ruled out most other languages.

But yes, if we had to restart Opa from scratch today, we could possibly base it on Akka, for instance (using either Java or Scala), or on some comparable .Net technology.

Caveat I'm part of the Opa team. Well, worse than that, I'm the architect-in-chief.

Re:How is it different from, say, Wicket or ZK?

[shutdown -p now]

Well, looking through the docs more closely (rather than just the chat example), it sure does look a lot like a dialect of ML to me now, so my earlier comment on "taking an existing language and adding extensions" was redundant. Well, thank God it's statically typed - I'm a bit tired of all the dynamic typing around lately, esp. when its evangelists bring forth arguments which made sense with Java, but don't anymore when you have pervasive type inference.

One thing there that made me wary is the built-in database. So far as I can see, it is essentially just a hierarchy of typed key/value stores? i.e. no way to do e.g. fast multi-field look-ups, joins etc? I understand that's the most common case for the Web, and that you need a specialized DB there to pull off that magic transparent distribution... but it's still kinda limited.

Still, interesting stuff - got me excited as much as WebSharper back in the day, and definitely more interesting than today's run-of-the-mill web frameworks. I do foresee some troubles with tooling, though - it seems that you don't have an IDE yet, for example? and what about live debugging? WebSharper has an easier story in that regard - they can use VS for F# editing & project handling, and only hook up their own build system and debugging. Since you have your own language, you'd need to do the whole thing from scratch - and that's where it'd help to have backing of a major software company. I wonder if Google has looked your way yet..

Re:How is it different from, say, Wicket or ZK?

[Seferino]

One thing there that made me wary is the built-in database. So far as I can see, it is essentially just a hierarchy of typed key/value stores?

Well, it is a bit more sophisticated than that. The database is a (typed) graph, so wherever a relational database or a key/value store would store keys as references, the database can store pointers, for instance. This is very powerful and this covers most cases. We also have plans for multi-field look-ups, joins, etc., much of which is actually implemented (but not activated in the released binaries/default config), but finalizing it will have to wait until we find some time and manpower.

it seems that you don't have an IDE yet, for example?

Actually, we have the prototype of one. Not an active project at the moment, but hopefully, we will eventually find time to finish it, eventually.

I wonder if Google has looked your way yet..

Well, if they have/had, I would not be a liberty to discuss it.

Re:How is it different from, say, Wicket or ZK?

[terjeber]

Blah, blah, blah, blah, blah... more irrelevant nonsense

Business data is stored in Oracle and in various IBM systems. So, if you want to be more than a toy project for funny student work, you can pull data from those. It's as simple as that. That is, of course, unless you are going to create yet another cool thing from scratch and do not care. As I said, a toy with such limited usability that it can only be characterized as a student fun project.

Re:How is it different from, say, Wicket or ZK?

[Seferino]

Ah, I think I finally understand your point. It is about compatibility, not about paradigm, is it?

If so, you may be happy to learn that the low-level layers of Opa can already access other databases. The feature is not accessible at high-level yet because we are going to make a number of breaking changes before long, but eventually, we do intend to give access to most mainstream databases. Would this solve your problem?

I don't like the look of them colons

[mfearby]

I don't know about you but I've never really liked the look of programming languages that use colons. Semi-colons are OK but two dots, one on top of the other? That's just craziness! And "do" statements remind me of BASIC... yuck.

Obigtory.....

[Anonymous Coward]

This seems to be getting some use lately.....

Which open-source license?

[93 Escort Wagon]

If I write a web application using Opa, and the server end accesses a database - am I required to release the sql username and password?

Re:Which open-source license?

[ludwigf]

AGPL 3

Probably the most important implication of AGPL is that it requires you to provide a way for your users to download the sources of the application. In fact Opa facilitates that by automatically enriching the server (in release mode) to serve the source code of the application at a special /_internal_/src_code URL.

But this is not the end of the story. We believe in free software (hence the AGPL license) but we also understand that it may not be very suitable for commercial users of Opa. Such users will be able to obtain a private license (paid). This will allow them to keep their sources closed if they wish to do so and will provide us with funds to further develop and improve Opa — win-win situation :). If you are interested in more details about obtaining such a license, do not hesitate to contact sales@mlstate.com, where we will try to answer all your questions (including pricing).

http://blog.opalang.org/2011/08/opa-license-contributions.html

For me as a German

[Anonymous Coward]

this language seems to be obsolete from the beginning.

Re:For me as a German

[St.Creed]

It was grandfathered in with an older browser :P

Integrating everything into one thing?

[lattyware]

Integrating everything into one thing seems like a poor idea. Sure, it makes it a little easier for the dev, but in the end, you are just learning 5 times the amount of Opa when you could learn each thing. Not only that, but can one thing really do all those tasks the other things do, and do it as well? Even if it can, it's harder to keep all of those on a level, you can't replace those parts if you find something better. It just seems to me that splitting things down into the parts seems like something we should be doing, not reversing. I also really don't like the whole compiling to JavaScript behaviour. Maybe just because I don't like JavaScript.

Re:Integrating everything into one thing?

[Seferino]

Integrating everything into one thing seems like a poor idea. Sure, it makes it a little easier for the dev, but in the end, you are just learning 5 times the amount of Opa when you could learn each thing.

Well, that's not quite true. Having the same language for database manipulation and for in-memory manipulation is a huge time-saver. Having the same language (indeed, the same piece of code) for server-side validation and for client-side validation is more efficient and less bug-prone. And you have only learnt one thing.

Not only that, but can one thing really do all those tasks the other things do, and do it as well? Even if it can, it's harder to keep all of those on a level, you can't replace those parts if you find something better. It just seems to me that splitting things down into the parts seems like something we should be doing, not reversing.

Ok, on this, you may have a point.

I also really don't like the whole compiling to JavaScript behaviour. Maybe just because I don't like JavaScript.

Well, that's part of the point: with Opa, you do not need to write any JavaScript.

Caveat I'm part of the Opa team. Well, worse than that, I'm the architect-in-chief.

So here's some example code

[moonbender]

No idea whether it's viable long-term, but I thought it's really interesting. It does way more than GWT does, for example. It's also statically typed, yay.

Here's some example code from the tutorial. This is a chat room. Apart from CSS, this is the entire soure code required to create the chat room server. Yikes. Had to get rid of the comments to appease the spam filter, unfortunately.

type message = {author: string /**The name of the author (arbitrary string)*/
              ; text: string /**Content entered by the user*/}
 
@publish room = Network.cloud("room"): Network.network(message)
 
user_update(x: message) =
  line = <div class="line">
            <div class="user">{x.author}:</div>
            <div class="message">{x.text}</div>
        </div>
  do Dom.transform([#conversation +<- line ])
  Dom.scroll_to_bottom(#conversation)
 
broadcast(author) =
  do Network.broadcast({~author text=Dom.get_value(#entry)}, room)
  Dom.clear_value(#entry)
 
start() =
  author = Random.string(8)
  <div id=#header><div id=#logo></div></div>
  <div id=#conversation onready={_ -> Network.add_callback(user_update, room)}></div>
  <div id=#footer>
        <input id=#entry onnewline={_ -> broadcast(author)}/>
        <div class="button" onclick={_ -> broadcast(author)}>Post</div>
  </div>
 
/* Main entry point. */
server = Server.one_page_bundle("Chat",
      [@static_resource_directory("resources")],
      ["resources/css.css"], start)

Wt

[paugq]

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

Re:Wt

[phy_si_kal]

You're the debian packager for Wt, so you must know Wt much better than I do. However, both projects are very different and you should probably have a real look at Opa before popping up on every story about Opa (followed by another comment by someone else saying the link was useful, history repeats ;). Opa is high-level language for writing web apps. Wt is a toolkit for writing web components in C++. There is an order of magnitude between the length of application code in Opa and in Wt. Wt handles everything as strings and does not perform any verification on the soundness of the application -- it's a way simpler project. But on the other hand it is useful to add a web touch to existing C++ desktop apps.

Re:yes!

[mellon]

Yes, and if Javascript weren't so bloody limited, that would be a great solution. Why, oh why, couldn't they just have embedded Scheme, which has all the wins of Javascript, and none of the limitations? Sigh.

Re:needs time

[Anonymous Brave Guy]

The developers are strongly backing a particularly virulent licence, Affero GPL. That requires that not only are the Opa tools open source, but any software you write using Opa is infected as well .

The claimed alternative is to buy a commercial licence for Opa, which lifts the open source conditions, but costs an as-yet-unconfirmed amount of money.

To my knowledge, there is no programming language that is even moderately successful today that does not have a good quality, free-as-in-beer, no-strings-attached tool chain readily available.

I suspect Opa is about to become a textbook example of a project that was be stillborn because its developers were too greedy; they're just demanding too much control over other people's work instead of too much cash.

Dear Creators of Opa...

[drgroove]

Dear Creators of Opa - Honestly, what were you thinking? Opa is basically another crack at the same approach that ColdFusion tried years ago, and failed at. Opa isn't Object Oriented, meaning that developers working in an OOP language (Java, .NET, Python, PHP, Ruby, Perl, etc) will have a tougher time making the transition - it also means that Opa can't implement or support standard Design Patterns, which is a huge mistake IMnsHO. The sample code on the Opa site shows a mix of Opa functions, database interaction, markup language, CSS, Javascript... what a mess. Haven't we all learned that clean separation of functional application concerns is the only way to write scalable, enterprise-class programs yet? Opa doesn't appear to support any database beyond it's own build-in, slightly obfuscated one, meaning it will gain no enterprise/business traction. As much as I like to see new programming languages succeed, I have to agree w/ a lot of the other posters on /. - Opa is dead on arrival.

Re:Dear Creators of Opa...

[Seferino]

Dear drgroove,

Thank you for your considerate feedback.<sarcasm mode="off"/>. While we understand very well the drawbacks of Opa not being Object-Oriented (at least not in the usual meaning of the term), there are several reasons for this choice. The first and most important of these reasons is that experience from 15+ years of experienced developers writing scalable systems with Object Oriented Programming Languages, and concluding that OO is not the right paradigm for the task, and that other paradigms need to be hammered upon OO languages to make them scalable. Rather, when designing Opa, we decided to choose a paradigm not on its popularity, but rather on its suitability for the task of writing highly-scalable, highly-secure, highly-dynamic web applications. This paradigm is comparable to that of Erlang or Scala. Certainly, this requires leaving the comfort zone of OO and putting all these learning neurons back to work, and certainly not all developers who have tried Opa have liked it, but direct and indirect feedback seems indicates that most did – a lot.

The second reason is more complex. We have experimented with OO in Opa and our experience shows that, to obtain the same level of security guarantees we achieve at the moment in an OO language, we would have had to abandon either lightweight programming (and require type annotations in many places), automated client-server distribution (and require site annotation just about everywhere) – theoretical sidenote: if you wonder, a large part of the problem is related to open recursivity in a structural setting, a nasty topic in particular when some methods depend on untrusted code.

Haven't we all learned that clean separation of functional application concerns is the only way to write scalable, enterprise-class programs yet?

We have worked very hard to permit separation of functional application concerns in Opa. Our tutorials and samples focus on conciseness, which is why it is a bit hard to see, but it is possible, and if we find time and resources to proceed in this direction, future versions of Opa will go much further along the way. However, I concur that this is one of the areas we could improve most (other ones being error-handling, the default UI toolkit, and expanding the database access primitives). So if you have any suggestion, really, we are quite interested. The current project lead can be reached at Mathieu.Baudet@mlstate.com and I am certain that he will be eager to hear about your ideas.

Opa doesn't appear to support any database beyond it's own build-in, slightly obfuscated one, meaning it will gain no enterprise/business traction.

Actually, at low-level the current version of Opa does support a few additional databases, but this is something that we do not publicize yet as we are certainly going to make changes before we are satisfied with the feature. As for enterprise/business traction, well, let's start with non-enterprise/business developers and work our way up :)

Yours truly,

the architect-in-chief of Opa.

Re:needs time

[Anonymous Brave Guy]

I think you're misunderstanding the concern. If I build my code using GCC, then GCC itself may be open source under whatever licence, but my code is mine to license as I wish. If you follow the link I gave above, you'll find that the Opa guys think that not only Opa itself but also anything you write with it should be forced open (by their definition of open, which is different to almost anyone else's). That's the kind of policy that gets abrupt from corporate lawyers saying "Put this within 50 miles of our network and you're fired". It's also incompatible with many other popular OSS licence policies.

Re:Opa = OCaml + "rails"

[cedrics]

Compiled their 76-line hello_chat.opa into a 30M executable

In those 30Mo you have just everything (the web server, the database engine, the scheduler, the page engine, the session engine, your webpages source, css, the generated js, etc) ! It's a standalone binary that just works on your server without having to install anything more. Did you check the size of the LAMP / Java / Ruby packages?

I would love to see some eCom or other complex sites written in opa to convince me that this is a viable alternative to Ruby, Java, PHP, etc.

MLstate did launch an eCom-like site : http://jetleague.com/ And I just check the binary on our server: 17Mo (yes, I guess it has been upx-ed)!

AGPL makes Opa dead on arival

[LunaticLeo]

I don't mind making any and all my code available to others. And I understand the "give-back" qualities of GPL. But a GPL language that makes every program written in it have the GPL License?!? Good grief. I am laid back about the whole License Wars, but AGPL gives me pause.

I probably won't even bother learning a little bit of this language to understand it's good qualities. Plus I've never cared for indentation defining blocks.

Re:I don't mean to be the one to burst your bubble

[znerk]

... and my point is made.

Nice sidestep.

Looking forward to seeing what replaces you.