Linked by hbbio on Thu 25th Aug 2011 22:14 UTC
General Development "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...
Thread beginning with comment 486956
To read all comments associated with this story, please click here.
What are the benefits?
by ndrw on Fri 26th Aug 2011 04:37 UTC
Member since:

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.

Reply Score: 3

RE: What are the benefits?
by henrikmk on Fri 26th Aug 2011 08:09 in reply to "What are the benefits?"
henrikmk Member since:

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.

Reply Parent Score: 3

RE[2]: What are the benefits?
by ndrw on Fri 26th Aug 2011 10:38 in reply to "RE: What are the benefits?"
ndrw Member since:

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.

Reply Parent Score: 3

RE: What are the benefits?
by lambdaterm on Fri 26th Aug 2011 13:42 in reply to "What are the benefits?"
lambdaterm Member since:

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

Reply Parent Score: 1

RE: What are the benefits?
by opadikt on Fri 26th Aug 2011 15:09 in reply to "What are the benefits?"
opadikt Member since:

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 ?

Reply Parent Score: 2

RE: What are the benefits?
by modmans2ndcoming on Sun 28th Aug 2011 13:27 in reply to "What are the benefits?"
modmans2ndcoming Member since:

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.

Reply Parent Score: 2