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]

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

and then there's the Ouzo. No beer or single malts for Opa programmers!

I welcome our Greek inspired programming overlords!

Re:very expensive to implement

[Trepidity]

ti les re; den apogoreuetai oi mpura!

malista, einai upoxrewtiko to ouzo, alla den eimaste fanatikoi k'olas

Re:very expensive to implement

[St.Creed]

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

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

[Anonymous Coward]

Cool!

Maybe as a joke to the rest of the World (computer languages seem to all come from the US), a programming language name that translates to "Fuck You" in another spoken language. So, when the boss asks, "What language are you implementing this in?" you can respond in all seriousness, "Fuck You boss. Why do you ask?"

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

[Guillermito]

And in (south american) Spanish it means "stupid", "idiot".

Re:very expensive to implement

[Jaxoreth]

aka The Chevy Nova Effect

Whereby it's assumed that speakers of other languages are stupid? Would you refuse to buy a Notable-brand dining room furniture set on the belief that it didn't in fact include a table?

Then again, Apple's second lineup of iMacs came in five 'flavors' (grape, blueberry, strawberry, tangerine, and lime) -- one for each color of the (old) Apple logo except yellow. I guess they didn't want to be selling a lemon. :-P

Re:very expensive to implement

[Anonymous Coward]

aka The Mythical Chevy Nova Effect

FTFY!

http://www.snopes.com/business/misxlate/nova.asp

Re:very expensive to implement

[Anonymous Coward]

mcgrew, is that you?

Re:very expensive to implement

[CastrTroy]

I agree. This makes me think of stuff like Linq. SQL is a much nicer language for representing this stuff. Now, they could have added support for some kind of inline sql that could work on objects. Instead, they tried to shoehorn the functionality of SQL into C#/VB.Net syntax, creating something that is just more difficult to use. It's not that hard to learn 3 languages to do web development. Most web developers already know at least 3, languages such as SQL, PHP, and Javascript. Most serious web developers probably know SQL, Javascript, and 3 or 4 different server side languages. Languages are easy once you have the concepts down.

Re:very expensive to implement

[Concerned Onlooker]

There's really no need to invent a language to justify that response, you know.

Re:very expensive to implement

[pmontra]

Among the major computer languages PHP is Danish with a Canadian citizenship, Python is Dutch, LUA is Brazilian and Ruby is Japanese despite its English name.

Even C++ would be Danish but Stroustrup was working at the Bell Labs when he invented it, furthermore it's an enhancement of C so let's say that the language comes from the US.

Re:very expensive to implement

[pmontra]

OPA is the Italian acronym for a takeover bid. The Opa language looks good for finance! :-)

Re:very expensive to implement

[Pikoro]

Along these same lines, There is a Toyota van here in Japan called a HOMY. In the local language (Okinawan), it means.. ahem.. female genitalia. Even so, the van sells fairly well.

Re:very expensive to implement

[Anonymous Coward]

Look at Nintendo's Wii, Wii U ... they don't care about the name ;)

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?

Re:very expensive to implement

[Anonymous Coward]

Luby [wikipedia.org] is Japanese

- FTFY

Re:very expensive to implement

[StripedCow]

Grandfather isn't even the right translation. "Grampa" would come closer. LOL

Re:very expensive to implement

[Anonymous Coward]

Along these same lines, There is a Toyota van here in Japan called a HOMY. In the local language (Okinawan), it means.. ahem.. female genitalia. Even so, the van sells fairly well.

Interesting. Honda had the same problem with the Honda Fitta. Same part of the female anatomy, but in Swedish. According to Wikipedia, they chose to rename it.

Re:very expensive to implement

[Seferino]

Believe it or not, roughly half of the Opa team speaks German, at least one (me) speaks Argentine Spanish and at least one speaks Greek.

And guess what? We decided that the puns were funny.

Re:very expensive to implement

[Anonymous Coward]

Yes, this was my first thought (I'm a bloody frog but work in a germanic country), but at least we can remember the name. I don't think the name would be so inconvenient. What bother me very much are performance and ease of use, especially when we try to things not specifically included in the tool (language or framework). Another very important point is the database, how is it handled ? mystery for now.

Re:very expensive to implement

[Anonymous Coward]

(the frog)
I've read the licence. Well, this is unacceptable for many startups: AGPL : this means you have to provide the source of your app OR use a different licensing scheme, that is: pay a license (unknown amount)

C analogy : it's like your were required to distribute the source code of your very own project just because you used gcc to compile it. ...
PHP analogy: provide the source of your PHP web site ...
DB analogy: provide the schema of your database ...
etc.
Thank you very much, I prefer a good BSD, MIT, Apache, CCDL , LGPL license.

Re:very expensive to implement

[mr_mischief]

AKA the urban legend effect?

"Nova" and "no va" mean two entirely different things in Spanish. Try both in your favorite translation software to see.

With so many confirmed international naming issues, it's odd that what must have started out as a joke is the one most people cite. "Nova" in Spanish, BTW, translates in English to... "nova".

Now, go to Snopes and check out Coca-Cola, Sting, the Rolls Royce Silver Mist, the slogan "Nothing sucks like an Electrolux"...

Re:very expensive to implement

[anomaly256]

Even that it means 'ulcer' in Lithuanian? :P

Re:very expensive to implement

[jonadab]

> This is why commercial entities do a namecheck before choosing names

Sure. That's why nobody would ever try to market, for example, a car called Nova ("it doesn't go" in Spanish and possibly other Romance languages), a soft drink called "Pee Cola", or a mustard called Grey Poupon. (Heck, I think that last one was even perpetrated by native speakers of English.)

Re:very expensive to implement

[Seferino]

Yeah, well, nobody in the team speaks Lithuanian :)

Re:very expensive to implement

[Eponymous Hero]

either you think spanish speakers are stupid or that they have no imagination/sense of humor. or maybe it's just you. it doesn't take much effort, as a spanish speaker, to separate the syllables into "no va," a funny joke name for an object that is indeed supposed to "va." seriously, did you never hear any tampon jokes about the iPad when it first came out?

Re:very expensive to implement

[mr_mischief]

What a very imaginative claim you make.

At no point did I say no Spanish speakers made the same joke that many English speakers with cursory knowledge of Spanish made. What I said was that nobody saw the name "Nova", read it as "doesn't go", and refused to buy the car for that reason.

Now, when you're done criticizing me for you not knowing what the hell you're talking about, read the Snopes page about this urban legend as you could have assumed I would say after reading the post to which you haphazardly balked at trying to respond.

needs time

[danbuter]

Let me know if it's still around in five years. I hope it works for these guys, but there are so many options already around, they are running uphill.

Re:needs time

[modmans2ndcoming]

Is there any reason that a language like Java, C#, C++, Python, Perl or Ruby, or with the appropriate framework and compiler couldn't do the same thing that Opa is aiming to do?

On Hanselminutes, Scott Hanselman interviewed a guy who made the statement "Javascript is the machine language of the Internet", alluding to the fact that it is better from a productivity and performance perspective to develop in a lot of other languages (C# in this case) and have compilers that know how to create optimized, minimized, and cross browser javascript.

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.

Re:needs time

[jbolden]

Seems to me QT and GCC were both successful with that sort of licensing.

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:needs time

[Richard_at_work]

I spent about 5 minutes on their site before I found that little gem in their blog, and from that point onward Opa wasnt something I was considering further investigation of.

A language with a forced license on your code before it's even written? No thanks.

Re:needs time

[Anonymous Coward]

Seems to me you're a fucking idiot. No way does GCC claim any code you compile with it.

Re:needs time

[Anonymous Coward]

Objective-C(iPhone/iPad app language), take a look at some of the absurd requirements for testing/publishing code.

Re:needs time

[Entrope]

There are two reasons that GCC does not cover that kind of code. One is that the mere act of compilation (a mechanical translation of the code from one form to another) does not implicate copyright. The other is that GCC includes a specific exception for standard header files and things that it compiles or links into your code as a result of the language features you use. The Opa developers explicitly reject that approach.

Re:needs time

[jbolden]

OK I just read the link.

That license is less bad than the QT Free license (mid 90's). Which basically said you had to give your application away, or make source available or you needed to use the commercial QT. As an aside, this was the whole problem with KDE. While KDE (GPL) qualified under the QT license just fine. QT didn't qualify under the GPL. Thus the opinion of Debian legal was that no one but the KDE foundation could legally distribute KDE since a licensee (but not the copyright holder) cannot join GPL code to non GPL comparable code.

So yes I think my analogy holds on the old QT license and up until fairly recently using a GPL library would toss your cose into GPL land. I agree the GCC analogy doesn't hold as well.

As far as the AGPL in general... I could see that going either way. The use of AGPL frameworks could require lots of websoftware to be released under the AGPL which starts to create a community of freely available code that anyone can use that's quite good but all encumbered by the AGPL. The same thing that happened in many areas like programming languages themselves. 20 years ago most compilers were commercial and most libraries were fully commercial.

On the other hand I do see your point about Opa and the AGPL. This is the reason the LGPL was created for languages since the GPL linking was considered too restrictive.

Re:needs time

[jbolden]

Actually compilation may impact copyright. You need to be licensed for various media. So for example if you have a music license for casette that doesn't permit CD redistribution. The courts do not look upon purely mechanical processes as not creating a new derived work.

Compilers on the other hand almost always explicitly state they aren't invoking those rights. GCC makes sure all libraries that are distributed standard (i.e. dynamic) are LGPL. But... there are GPLed 3rd party libraries and they would create GPLed code

Re:needs time

[Anonymous Coward]

oh, no, I might get "infected" or "fired" if I use this tool, I'd better avoid it rather than learn about it and make a decision for myself since the Anonymous Brave Guy is here to scare me away.

You'd make a great Public Relations guy for an amoral corporation. You're FUD skills are excellent.

Re:needs time

[BotnetZombie]

At my company, we use something similar called Direct Web Remoting for creating Javscript client code that communicates seamlessly with a Java server.

Re:needs time

[Seferino]

Is there any reason that a language like Java, C#, C++, Python, Perl or Ruby, or with the appropriate framework and compiler couldn't do the same thing that Opa is aiming to do?

Frameworks definitely would not suffice. Reaching the level of features of Opa, even without security, requires quite complex static analysis that strictly eliminates Python, Perl or Ruby, and in practice, even C++. Now, it might just be possible with Java or C#, with non-trivial changes to the language and compiler.

On Hanselminutes, Scott Hanselman interviewed a guy who made the statement "Javascript is the machine language of the Internet", alluding to the fact that it is better from a productivity and performance perspective to develop in a lot of other languages (C# in this case) and have compilers that know how to create optimized, minimized, and cross browser javascript.

Unsurprisingly, we agree.

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

Re:needs time

[modmans2ndcoming]

A framework would simply provide useful constructs to use in the language the framework is built for... the heavy lifting would have to take place in a separate compiler. I do not see a reason why such a compiler could not be created for any other language.

Re:needs time

[Seferino]

Interesting question. Let's forget about the framework for the moment and concentrate on what the compiler should do:

• analyze statically the whole code and determine what goes on the client and what goes on the server (I tend to believe that this is not feasible with a dynamic language, but of course, feel free to prove me wrong);
• compile client-side code to JavaScript or to code that can be interpreted by a JS-based VM (lots of work, but no theoretical barrier, emscripten can even make your life somewhat easier at least for C++);
• inject Ajax entry points on the server (no real problem there);
• inject Comet re-entry points on the server (requires a server-side language that supports either CPS or tens of thousands of lightweight non-blocking threads – theoretically possible with custom implementation of the languages).

That's without security or distribution, without database, without a syntax for css or html, but it looks somewhat possible for some languages, with considerable effort. Say, if you attempt to do this, don't hesitate to ping me, it might be interesting.

Re:needs time

[synthespian]

Are you trolling? Or are you really clueless? QT and GCC used the GPL, not Affero GPL.
Seems to me you don't understand the differences between the GPL and Affero GPL.

Re:needs time

[jbolden]

Reread the thread. The discussion is not what QT uses now but what it used in the mid 90s.

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?

[mellon]

It's an integrated solution. You write one piece of code, and the compiler manages the AJAX interface. So you don't have to write your app in two languages and deal with communication between the server side and client side: the language hides that.

It seems like a good deal in a number of ways, and I think for a new application it might be a good choice. However, there are some problems—they have chosen to define a new language, rather than extending an existing language, so you have to learn and be current in another language. They require that you use their database, so if you already have your data in another database, you have to migrate. And of course you still have to know HTML and CSS, so really you're still programming in three different languages. But 34, so I guess it's a start.

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

[mellon]

That was 3 < 4, not Rule 34, in case anyone was wondering...

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

[shutdown -p now]

It's different in that network communication is more or less transparent - you write a single program, not two clearly separated client and server parts (and then those in different languages).

Simply put, it's a lot like Volta, except that, apparently, didn't get anywhere - even though the CTP was neat (it even let you do integrated debugging, like "step in" on client and it would get you into the corresponding server entrypoint). I think there's something like that for Java also. So this isn't exactly new, but they may be the first one to ship a production version of such a tool.

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.

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

[Kagetsuki]

Check the documentation, Opa runs on Java....

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

[Kagetsuki]

*I understand you were talking about the language, just pointing out we're not free form the clutches of Java on this one.

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?

[Kagetsuki]

Oops, sorry for misunderstanding that and thank you for taking the time to clarify.

I'm thinking of something to make to try out Opa by the way. I looked through some samples and I must admit I like how it handles things like Canvas and "live" apps.

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

[terjeber]

They require that you use their database

and from the Opa page

A hierarchical database

and poof, another silly student project vanishes into irrelevant oblivion long before it is born.

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

[synthespian]

For one thing, ML-oid languages have Hindley-Milner type inference.

This is a formal ("mathematical") guarantee at code safety/correctness (in the web scenario it means code injection attacks do not type-check). All C-oid languages (and Java, Python, etc.) cannot offer a true (i.e., *formal* guarantee), simply because, compared to the theoretical background of ML-oid languages, they are merelly hacks, with lots of corner cases, ad-hoc "featuritis" and many loopholes - which, BTW, spawned a whole industry (anti-virus software). Talk about giving you a problem and then selling the solution...

Even though ML-oid languages were developed by true brainiacs, we're now witnessing inroads at mainstream programming (F#, for example, from Microsoft, or the use of OCaml in the financial sector (*))

Being statically-typed, these systems are also good for performance (**)

For a nice layman-friendly explanation of Hindley-Milner you may like: http://www.codecommit.com/blog/scala/what-is-hindley-milner-and-why-is-it-cool
-------
(*) Many years before these new commercial uses of ML-oid languages, the French Aerospace industry used OCaml to formally verify C programs that were deployed in at least one model of Airbus aircrafts. Also, the makers of Matlab (Mathworks) sell a code-checking tool that relies on SML (Standard ML) (see: http://www.mathworks.com/products/polyspace/index.html)
(**) This guy claims his OpenGL bindings for MLTon whole code optimizing compiler yielded faster than C++ performance at 10% of the code. MLTon may be found here: http://mlton.org/.

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

[Seferino]

Actually, it's a graph database and one of the most powerful database engines I have seen on the net. With this engine, you store complete data structures, thinking in terms of references instead of keys – except when you want to think of keys, of course. What is the problem with that?

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?

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

[terjeber]

This would make the platform relevant. Changing paradigms are for silly student projects. In the real world, pragmatism is far more important. Pragmatically my software needs access to my data. In the real world, the vast majority of data is stored in Oracle and a few other areas. In the real world COBOL is still more important than Apache.

yes!

[Anonymous Coward]

I was just thinking: this is exactly what we need! Yet another programming language. And even more "web apps". Yay!

Re:yes!

[interval1066]

I was just thinking: this is exactly what we need! Yet another programming language. And even more "web apps". Yay!

You're not getting it. Don't think of web apps as some separate application layer, think "web". This is where its going, its already there to be honest. If you're not prepared for that simple fact you're in for a bumpy ride as its only going to get more "webby" in the future. And a new language that ties all that in a more comprehensive way is going to be a good thing.

Re:yes!

[aztracker1]

We already have a language that ties it all together in a comprehensive way... Front end (HTML+CSS+JS), Middle tier (Node+Express+JS), Backend (MongoDB+JS) ...

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:yes!

[paxcoder]

There are Scheme implementations in JavaScript. Not sure what your point is.

Re:yes!

[mellon]

So you think you know what my point is, but you don't want to put a stake in it? Javascript is Turing-complete, so you can implement anything in it. The question is, will it perform. The answer is that if you implement a full scheme in Javascript, it probably won't perform well. If you do a javascript-limited subset of Scheme, it will fail to completely suck. But it will suck a lot, because it will be fairly limited. More to the point, it won't be Scheme, so you will still have to program in two different languages, only they'll look really similar, so you'll forget. That way lies madness. *Madness*, I tell you.

Re:yes!

[Seferino]

Well, in my experience, most of Scheme (i.e. not call/cc) ports quite well to JavaScript and performs quite well once compiled to JS. Performing a CPS transform on JS cuts performances by roughly 50%, which is not *that* bad.

Re:yes!

[mellon]

Thank you for playing. If we were talking about native speed, you might be right, but the performance multipliers people got out of Javascript recently were necessary and hard won. Throwing away half of them (and I think you're being extraordinarily optimistic here) to get a crippled Scheme is not going to make you any friends in a production development environment.

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.

Re:I don't like the look of them colons

[deniable]

Actually, the colons give me a Pascal vibe. The indents remind me of Python. So, I've got a language that looks a bit like Pascal and Python, runs in Java and generates HTML + JavaScript. The documentation must be a fun read.

Obigtory.....

[Anonymous Coward]

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

Re:Obigtory.....

[Anonymous Coward]

First thing I thought of as well!

Re:Obigtory.....

[Anonymous Coward]

Except that in their website, they have mentioned that Opa is going to useful mostly for those clients which make a lot of real time interaction with the server. They never claimed it to be a standard to solve all the standards problems.

But, all I can think of right now is, "Sigh... another language to learn. Will it be worth spending time on it?".

Re:Obigtory.....

[phy_si_kal]

Opa is not a new standard. It's a new language based on existing standards.

Re:Obigtory.....

[http]

I think you may well have intended something previous.

Opa?

[Anonymous Coward]

Well, i assume for sure that these guys know that 'opa' means 'grandfather' in German ?

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

Re:Which open-source license?

[93 Escort Wagon]

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

Whether I'm a commercial user or not... why would I - or anyone - ever want web visitors to be able to grab the SQL username and password I'm using in the back end?

Re:Which open-source license?

[Anonymous Coward]

So in other words, yes, you have to release the user name and password, since it's part of the source and compiled into the binary

Someone's never heard of configuration files!

Re:Which open-source license?

[mellon]

Oh please, you're just being difficult. If you want an entirely closed-source application, you can pay them the licensing fee. If you want to go the open source route, but don't want to reveal your passwords, don't put them in the source code: store them in the database.

Re:Which open-source license?

[tomhudson]

Oh please, you're just being difficult. If you want an entirely closed-source application, you can pay them the licensing fee. If you want to go the open source route, but don't want to reveal your passwords, don't put them in the source code: store them in the database.

And how, pray tell, are you supposed to get the password out of the database without the password?

Re:Which open-source license?

[a_n_d_e_r_s]

Whether I'm a commercial user or not... why would I - or anyone - ever want web visitors to be able to grab the SQL username and password I'm using in the back end?

Are saying that people actually write username and password in the source code ?

Thats a no no.

Use a configuration file containing secret information so you can protect it. Don't hardcode parameters that might change.
Put the SQL information needed in a configuration file that you read before opening the database. Then its easy to change
database, username and password if you need to.

Re:Which open-source license?

[tomhudson]

You might want to look at the original post, and RTFA (a href=http://opalang.org/#slides=1>in particular, this slide). The "application" is a single executable, containing everything needed to run, including the data store. An additional problem is that the resulting application is itself a server, not code called by a server, so each instance of your app needs to have it's own port. Not very useful at all compared to today's setups:

http://opalang.org/resources/book/index.html#_setting_up_storage

The following command line distributes 6 instances of Hello, chat on albertson, with user jeff. Each instance will be listening to a port between 7000 et 7005 included.

opa-cloud --host jeff@albertson:7000,6 hello_chat.exe

So unless you control the physical server, including the right to run stand-alone executable content as well as use ports outside of the standard ones, forget it.

Re:Which open-source license?

[deniable]

You want me to keep the key to the safe inside the safe?

Re:Which open-source license?

[Seferino]

Whether I'm a commercial user or not... why would I - or anyone - ever want web visitors to be able to grab the SQL username and password I'm using in the back end?

Well, that's an awful practice, regardless of the language.

In Opa, since the binary automatically generates the database, scheme, etc. the first time it is run, the way we generally handle this is to have the binary generate random username/password and somehow display it to the console, where only the administrator can see it. There are other schemes, of course, but this one has served us nicely so far.

Re:Which open-source license?

[BlortHorc]

So in other words, yes, you have to release the user name and password, since it's part of the source and compiled into the binary, and the AGPLv3 requires that it all be released.

The GNUstapo strikes again. Last week it was FUD to try to get people to encourage Linux to move to the AGPLv3, which would kill Android on mobile devices, and now this. No thanks. Keep chipping away at the various freedoms - you just end up making the *BSDs look better and better.

Dude.

AGPL3 != GPL3

I mean, yes, the difference in name is slight, the difference in license is not. Indeed, the difference between the two is essentially what is being discussed here.

If you are actually interested and not simply *BSD license trolling, you can read about it here.

Re:Which open-source license?

[phy_si_kal]

Indeed, there's no such thing as the database passwd in Opa. The database is only accessed by a single application, which logics controls the access. For instance, your application code allows to create one admin user, who can choose a passwd which is stored in the database. Then, this user has the credentials to change all things when other users don't. And of course, the database content is not covered by the AGPL license.

Re:Which open-source license?

[Anonymous Coward]

The "application" is a single executable, containing everything needed to run, including the data store.

But the reason for having a database password in more conventional systems is that the database server is separate from the application and therefore can't assume that it's trusted without some sort of authentication. If the database is integrated there's no need for a password in the first place.

Re:Which open-source license?

[tomhudson]

Sorrt for the tyo, but it doesn't change the fact that the FSF post is anti-Android FUD.

Re:Which open-source license?

[tomhudson]

But the reason for having a database password in more conventional systems is that the database server is separate from the application and therefore can't assume that it's trusted without some sort of authentication. If the database is integrated there's no need for a password in the first place.

That really needs to be tagged "whatcouldpossiblygowrong".

Re:Which open-source license?

[Anonymous Coward]

If you're writing usernames and passwords in source code, you're doing it very very wrong.

Re:Which open-source license?

[erc]

People do all kinds of crazy things in commercial environments when their boss says "I need this app written today!" Throwing sanctimonious rocks at them makes you feel superior, but makes you look like a jerk to the people who actually have to do this crazy stuff for a living.

Using a config file isn't even a good idea, since anyone with enough access to get to your code may have enough access to get to the config file, and the auditors will certainly frown on that when you have to undergo the torture of a SOX audit. We add another layer of security onto this by serving up certain host/login/password via a web service, but for most applications, the database layer is isolated by using web services that serve up the data via XML/JSON rather than letting applications or clients have direct access to the database. It also gives a single point of control for logging, security, and auditing purposes.

We have multiple web servers in the enterprise - it would be a hassle to change all of their config files if we moved the server from, say, SQL Server to Oracle - so we have everyone talk to the web services server - and we have only one point that needs to be changed, and the changes propagate to the clients and applications automatically.

Another advantage of using web services to isolate everything is that for desktop apps you no longer need to install database-specific drivers on everyone's desktop, a fact that has made Operations very happy.

Re:Which open-source license?

[erc]

Not a good idea from a SOX-compliant point of view, since once you generate the random login/password, you lose control. See my previous post.

Using a simplified tool for a complex problem...

[blippo]

I thought that it was proven that languages with less complexity will make simple problems simpler, and the rest of the problems impossible.

Re:Using a simplified tool for a complex problem..

[blippo]

Or maybe this *is* a complicated language, and I should just go back to idle.

 

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

Re:For me as a German

[Anonymous Coward]

I know that being /. there's an anti-windows ideology for all sorts of reasons aiming from a hatred of capitalism to wanting openness from others on demand to the security issues (in spite of being brought about by the ease of development for business applications) - but how can they even be remotely serious about deploying this when there is no Windows version around? They include Apple and Ubuntu, I suppose there is something to be said for catering to the least talented of all developers - and non-developers - for the sake of cheap labor - but not for serious development work - guess I'm sticking to LAMP for all my AJAX needs.

Javascript as assembly

[SharpFang]

Am I the only one scared by the new trend of "languages that compile to Javascript"?

Coffeescript, Opa, there were some more.

I understand first compiling to Asembler and only then to machine code. I understand early C++ compiling to C. Various languages to bytecode...
But really, while I love Javascript for many features it provides, creating yet another layer of indirection on top of it seems to serve only one purpose: boost sales of faster hardware...

Re:Javascript as assembly

[Anonymous Coward]

My own solution to this issue was actually to learn JavaScript, but this is apparently too difficult for some.

Re:Javascript as assembly

[Herkum01]

There are guys doing this at my company, and the reasoning for it is that web developers know JavaScript. They don't necessarily know the back end language that is used to generate web pages (Perl, Java, PHP, etc...).

Rather than have web developers spend time learning the back end, they display a blank div and use AJAX to request the data that they want. Then they can create the web page in JavaScript. I am not sure that this will be good way to go, but I do understand why the business wants to explore the idea.

Re:Javascript as assembly

[icebraining]

It depends on how cleanly it maps to Javascript's concepts. I don't really see almost anything in the core Opa language that doesn't map reasonably well to JS. It shouldn't be particularly slower than JS by itself.

Re:Javascript as assembly

[TD-Linux]

I think you missed what the parent was talking about. He didn't mean implementing more things in Javascript, he meant allowing developers to use non-Javascript languages to generate Javascript. It's so people don't have to use Javascript or learn it, not the other way around.

What you mention, the pattern of generating pages using AJAX, is still fairly new. I use it a lot for data that is updated in real time, and some websites are using it for static data as well. I very much like it for cleanly separating the presentation from the backend server side code, even though some NoScript using purists hate it.

Re:Javascript as assembly

[aztracker1]

I think you have thisbackwards... This is another language that generates JS, rather than JS being leveraged more... For that, Node + Mongo are a great pair of options.

Re:Javascript as assembly

[qxcv]

I'm more scared of libraries that try and force class-based OO into Javascript, but the mere existence of such libraries does show that people have a LOT of trouble efficiently getting around OO problems in Javascript. I don't mind Coffescript, etc because they make Javascript what it should have/could have been. There are so many neat little things that could make Javascript less tiresome, but almost none of them have been pushed out into the real world yet. Think array comprehensions, getElementsBySelector (if we had this a decade ago it could have saved insane amounts of money and bandwidth), default arguments (Javascript arguments are HORRIBLE), a less braindead DOM model, etc.
 
Opa OTOH is a different kettle of fish. In 98% of cases tying your frontend to your backend is a Bad Thing (tm). There is a very real difference between the client and the server, and I'm not sure what transparent environments are trying to achieve by ignoring it.

Re:Javascript as assembly

[tomhudson]

No other language, aside from PHP, fucks up so badly

perl?

Re:Javascript as assembly

[Anonymous Coward]

What you essentially want is Lua embedded in web browsers.

Re:Javascript as assembly

[WillKemp]

[......] For those of us who are good programmers, this is very difficult to do.

Perhaps you're not as good a programmer as you think you are then.

Re:Javascript as assembly

[Anonymous Coward]

Hyperbole is the WORST thing in the entire world.

Re:Javascript as assembly

[shutdown -p now]

Perl at least compensates for its ugliness with a wealth of useful features, and the ability to write terse code.

Re:Javascript as assembly

[SharpFang]

OTOH, I've seen one line of Coffeescript create a dozen of JS lines. Sure it means writing faster. But the problem with writing faster is that you spend the same amount of effort to create the same amount of lines of source, and suddenly you have five times as much of actual runtime code.

Re:Javascript as assembly

[Seferino]

Well, for one line of C++ (or of one of the compiled-to-native dialects of Python, if you prefer), how many lines of ASM do you get? And is that so bad?

Re:Javascript as assembly

[erc]

Only for those who haven't been using Ajax and JQuery/Moo/whatever for a while. This is old hat, and there are a *lot* of websites doing some very cool stuff with this idea.

Again, if you use web services on the back-end, you don't have to care what the back-end is written, since they all use the same interface layer language - XML or JSON.

Re:Javascript as assembly

[erc]

Absolutely. You *want* a separation between your front-end and your back-end, for audit compliance as well as security. If you tie your front-end to your back-end, you go right back to the problem that monolithic applications have - what happens if your boss decides he doesn't like whatever database you've got the corporate jewels in and wants to move to something with a track record, like Oracle, SQL Server or DB/2? If you have a clean separation, you can swap out the back-end with little if any changes needed on the front-end. What is it about this flexibility that people don't get?

Re:Javascript as assembly

[SharpFang]

Even if I get 100 or 1000 lines, it runs on the CPU at maximum speed, if I get a 2GHz CPU, it will run at roughly 2 billion "lines" per second.

Now if the code compiled to Javascript had then the Javascript run at 2,000,000,000 lines per second, as opposed to... maybe 1000? I wouldn't mind.

Now if you write clean Javascript, you can achieve miracles in 1000 lines of code. It will be a minor bump for the awesome results.
But if you compile some meta-code to JS, you will achieve the same result in 300 lines of meta-code and 3000 lines of Javascript. Which will introduce a serious hiccup in user experience.

Obligatory

[Anonymous Coward]

http://imgs.xkcd.com/comics/standards.png

Re:Obligatory

[deniable]

And now we have one more competing post pointing to that XKCD strip.

Re:Obligatory

[znerk]

...and this one isn't even a clickable link. Oops.

Hierarchical database???

[Anonymous Coward]

They lost me at "A hierarchical database and web server are integrated with the language." Hierarchical? Really? I thought, outside of LDAP, that hierarchical databases had already suffered a much deserved death.

Re:Hierarchical database???

[Tablizer]

Every 5 years it gets reinvented with a new name

Why a new language and not an existing one?

[Anonymous Coward]

Compiling an existing language into JS cuts down the learning curve and makes more tools available. For example Java to JS using GWT

Documentation = Weird

[platypusfriend]

Reading the documentation and how-to's on the Opa website reminds me of talking to the Orz in Star Control II / Ur-Quan Masters.

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?

[MeddlesomeKids]

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

I see it the other way round. When you are dealing with all the languages and formats we have now there is a huge amount of wasted duplication. Look at how you concatenate strings in Javascript versus PHP. Or calculate a random number. Or iterate an array. obj->method() or obj.method() or obj->val or obj.val ? How about encode a non-ascii character in a URI, or in XML, or in HTML? Which characters are reserved in HTML or XML or JSON or a URI or SQL or a regular expression? How do you walk a DOM in Javascript versus PHP (versus Ruby/JSP/NET/etc.) ? Frankly, I have better things to do with my limited time on this planet that memorize all these little conventions over and over again slightly differently each time.

If I can learn and use Opa and not have to meddle with the others, then it's a win. But if I have to use Opa to perform string concatenation to construct javascript or SQL. then it's a loss. I can live with having to concatenate HTML and CSS (but I'd rather not).

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.

Re:Integrating everything into one thing?

[erc]

The problem is that you've just created a monolithic application that ties one single database to one single front-end. What happens when you want to swap out databases? Opa only runs on Mac or Linux, how about all those corporate applications that need to be written on Windows and talk to SQL Server or Oracle? It's just another language that corporate developers not only need to learn, but need to sell to management - a very hard sell when there is a huge codebase in ASP, ASP.NET, VB6, VB.NET, etc., and I can find ASP or ASP/NET or VB6 developers almost anywhere. I'm not going to mention Java because not only is it dog slow, but Java developers tend to want a huge amount of cash to create what usually is slow, buggy code. Corporate shops want proven technologies - now, if you want to use Opa to generate JS/HTML front-end apps, ASP/ASP.NET apps on the back-end, and a web service layer to let them talk to each other, then maybe you'd have Corporate America sitting up and taking notice. But as it is, it's an interesting idea, nothing more - I'd never let it in my development shop, and even if I did, the architectural committee would hang me out to dry.

And "compiling to JavaScript" is just ignorant - there's no such thing. Maybe the author means "translating to JavaScript"?

Re:Integrating everything into one thing?

[Seferino]

The problem is that you've just created a monolithic application that ties one single database to one single front-end. What happens when you want to swap out databases?[...] It's just another language that corporate developers not only need to learn, but need to sell to management [...] But as it is, it's an interesting idea, nothing more - I'd never let it in my development shop, and even if I did, the architectural committee would hang me out to dry.

I can understand the issue. Would this calm your concerns if I told you that

• on the Opa git, there is an Opa version for Windows – it's not quite ready for prime-time, but it's there;
• Opa is designed to be able to link with other server-side technologies – for the moment, OCaml and C, other technologies will arrive in time;
• at low-level, the Opa database can access other, mainstream, database – the feature is not quite exported at high-level yet, because we are not quite satisfied with it yet, but in time, it will;
• and of course, there is always the option of modularizing your code through the use of web services, which is a nice way of allowing [hot]swapping of components.

And "compiling to JavaScript" is just ignorant - there's no such thing. Maybe the author means "translating to JavaScript"?

Of course, what do I know about compilation? I only have a PhD on the topic and 9 years of professional experience.

Re:Integrating everything into one thing?

[erc]

I've got 30 years of processional experience, so does that make me more of an expert? Snarky comments aside:

The name "compiler" is primarily used for programs that translate source code from a high-level programming language to a lower level language (e.g., assembly language or machine code).

This is from Wikipedia, and is the most commonly-accepted definition in the industry, academia notwithstanding. I hardly think that JavaScript qualifies.

I'm still not sure why you chose to create monolithic applications, when the clear industry trend is towards more flexibility, particularly by using web services.

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)

Five years? Ruby on Rails barely lasted that long.

[Anonymous Coward]

Even Ruby on Rails, which was first released during the summer of 2004, barely lasted that long. As anyone who does even the slightest bit of web development knows, RoR was hyped, hyped, and then hyped some more for years. It got a huge amount of attention, more so than basically every other web framework out there.

However, by the end of 2010 it was on its way out. People found out that the hype wasn't deserved. Rails apps performed horribly, they were unmaintainable, they couldn't scale well, and the community had some pretty serious misogynistic tendencies. The few good Rails users fled, and it has thus stagnated. Today, we hear very little hype about Rails, and nobody who knows what they're doing uses it for new projects.

Sure, it's still around, but it's a ghost town. It's looking like there won't even be a 10th anniversary at this point. Or if there is, it'll be a pretty sad affair. More like a funeral, if anything.

Working at such a high level

[Anonymous Coward]

IMHO, anything that works at such a high level is going to have problems. For example, quoting their doc page, "As for deciding which html version to use, Opa handles this behind-the-scenes".

Now what happens when browser X handles HTML 5 just fine, but browser Y doesn't?

It still works fine if the "behind the scenes" thingy has a fantastic knowledge base of all the browser variations. That's a big "if".

Aside from that, looking at their examples it reminds of MFC, where it was really easy to roll applications if you wanted to do it their way. As soon as you got an idea that didn't conform to what they had in mind, you were in a world of hurt.

Finally, I think web services are fine as a library in a langauge, but integrated at the language level? OK fine, but you can't call it a general purpose language anymore. Then it becomes a DSL. I'd rather have a general pupose language with a well documented API into a library that handles the doman than a DSL.

Re:Working at such a high level

[aztracker1]

The biggest issue here is integrating with a legacy system... I can't see this as anything but painful...

In argentinian spanish...

[buanzo]

.... opa means 'idiot'. Yes, offtopic. Now onto some ontopic stuff: It definitely sounds good for security at least. I'm giving it a try.

Re:In argentinian spanish...

[MadMaverick9]

From TFA:

Opa automatically generates client-side JavaScript

From http://www.amazon.com/Stealing-Network-How-Own-Box/dp/1931836876

Client-Side Security Doesn't Work

Appendix - "The Laws of Security by Ryan Russell"

ergo - this is bad for security.

Re:In argentinian spanish...

[Anonymous Coward]

ergo - this is bad for security.

No it isn't, unless you consider the existence of anything at all on the client side to be "Client-Side Security".

Re:Five years? Ruby on Rails barely lasted that lo

[danbuter]

That's why I said 5 years. It takes that long for people to figure out if the thing will actually work over time. As you so aptly said, Rails wasn't worth the hype.

Standards

[Anonymous Coward]

http://xkcd.com/927/

Re:Standards

[MurukeshM]

Situation: There are now 3 competing obligatory xkcd posts.

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

[MeddlesomeKids]

Wt is cool, but compare the listings for the Wt chat application versus that of Opa. How many orders of magnitude are there between the lengths of the two listings? 1? 2? The Opa listing would fit on a t-shirt. So I think that is at least a partial answer to your question of "why a new programming language required". Personally, I also find that most new language announcements are unnecessary. There are already many great languages available, could not a tool or library accomplish the same thing? However, in this particular space I'm less opposed to the introduction of a new language. The whole web app thing is already a rotten stinking soup of languages, protocols and formats (SQL, PHP/JSP/NET/Ruby/Python, HTML, CSS, XML, Javascript etc etc etc) and I am very sympathetic to any one-language-to-rule-them-all solution. If I can worry about one instead of legion I'll be better off. However, though I have not yet used Opa or Wt yet, looking through their example code listings I see HTML strings being constructed in the Opa listing, and Javascript code being concatenated in Wt. And for both CSS files seem to also be BYO. That isn't necessarily unreasonable, but you can see the slope we are on. So now I'm using Opa/Wt to write HTML (or Javascript) and I have to provide the CSS myself. Am I really ahead of the curve, or wearing mittens? How is this different than (gulp) PHP? What about the database? Does my Opa/Wt code need to construct SQL query strings? If I, or my designer, wants to add some new jQuery plugin that will be announced tomorrow, how is that approached? I've been fairly impressed with Opa from what I've read on its site. I'm hoping to get some time to actually play with it and maybe get to the bottom of some of these questions.

Re:Wt

[Lord_Naikon]

Thank you for that link, Wt seems really useful.

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

[paugq]

Wt is also for writing webapps. My main gripe with Opa (which I have looked into :-) ) is the need to write HTML, XHTML, CSS, etc With Wt, I do not need to care about that. I do not even need to care about the browser supporting AJAX, SVG, or whatever. Wt takes care of everything.

Re:Wt

[synthespian]

inventing a new programming language for that end is unnecessary and, in fact, will become a burden

Skimming through the language ref (*), this is very much ML-oid (SML, OCaml, F#).

So it doens't seem to be "new", bizarre, or some gratutitous stupidity (like Javascript, for example).

That is, except if you haven't ever looked at these functional languages. Which means that around a decade and a half of programming language state-of-the-art tech whisked right by you.

(*) http://doc.opalang.org/index.html#_the_core_language

Re:Wt

[znerk]

I was told by your chief architect to ping you for info on the licensing, so...

What's up with your insanely infectious, ridiculously restrictive licensing?
How much does it cost to keep from having to open-source my code, just because it's written in your language?
Do you really expect to achieve a legitimate user base, with an absurd license like that?

Your boy Sephiroth^W Seferino told me that he couldn't answer that question, after he went all astroturf on us, telling us how cool the coding is... passed the baton to you for "technical questions about licensing".

So, the ball's in your court. Tell us why we should even consider using your language, when anything we ever make with it becomes public domain unless we pay you for "protection". Tell us how it's not like the Greek Software Mafia.

Oh, and explain why your "Architect-in-Chief" can't spell your name. You might also want to talk to him about posting your COO's email address in the clear.

Good point. Unfortunately, as the CSO, I have strictly no say in the license. If you wish to discuss it with someone who does, you should ping phy_si_cal, our CEO and the OP of this thread, or send an e-mail to Mathieu Baudet, our COO.

Also, as I replied to him, openly admitting that you're slashvertising is bad form.

--
Batting a thousand today, aren't ya?

Re:Wt

[paugq]

It's not the "style", or the "keywords". Learning a new language is easy for developers (i. e. the users of Opa) I has talking about maintaining that, the work that the people developing Opa itself will need to do: compiler, multiplatform, optimizations, incompatibilities, etc That is a lot of work. IMHO, for no good reason. If they like ML, fine: just take ocaml, F#, Haskell or any other and develop Opa as a library.

Re:Wt

[phy_si_kal]

We have many comments about the license and we listen, and we thank you for them. We listen, and will engage a discussion with our community soon to see how we could make things better. However, please note that you don't have to make your code "public domain". Of course, you retain the full copyright to your code -- what we currently ask is that you make the code of the application available to your users.

Re:Wt

[znerk]

"Open source" pretty much means "giving up your copyright"... I mean, honestly... how can you argue that we are keeping our copyright, if the code must be made public?

This, more than any other shortcoming of Opa, is what will kill you in the end. Requiring users to pay you some extortionate licensing fee or release their code into the wild is retarded, if you actually want to get anywhere.

Any arguments you might have about your fees not being extortionate are rendered null and void, completely moot, by your refusal to provide even a hint of your pricing scheme.

If you don't want people to shoot wide, gaping holes in your pet project, don't bring it to slashdot where all the geeks and nerds can see all of its flaws in the suddenly bright lights of internet fame (or infamy, as the case may be). Slashvertisement is sometimes tied closely to the Streisand effect, especially when you and your team of (non-)PR goons come on here to follow it up with apologetic gymnastics.

Better yet, you guys responded to valid criticisms and constructive comments with sarcasm and insults, while failing to actually answer any of it with anything approaching a valid response. We internet trolls absolutely love stuff like that.

Thanks for playing.

Re:Wt

[Anonymous Coward]

I cannot comment on Opa, but you seem to miss the point of Wt: it's not implement web components, but rather entire web applications, although you can also use it to implement widgets ala Google Maps that host in a third party site.

Wt does not at all handle everything as strings. Wt's API is modeled after Qt's API: it's entirely object oriented and type safe. And it does provide mitigation built-in for the top 10 of OWASP security threats, including XSS, CSRF, application state, etc... (I guess in an entirely similar way as opa). It's not just to add a "web touch" to existing C++ desktop apps, it has many different use-cases of which this is just one.

Let's reverse the question though: why is Opa not a library in Java/.NET/C++/whatever language ? What prevents opa to be implemented as a library ?

Re:Five years? Ruby on Rails barely lasted that lo

[anomaly256]

If this were even remotely close to being true, I'd be out of a job right now. And I'm not, so it isn't. :)

Clearly this is an attempted troll post..

I don't know about this.

[Anonymous Coward]

It sounds like a mechanic throwing out his toolbox in favor of a Swiss army knife.

CGI.pm

[Aighearach]

You write one piece of code, and the compiler manages the AJAX interface. So you don't have to write your app in two languages

Sounds like CGI.pm to me! I never went for that. With a code generator you have to be thinking about what it generates all the time, or else restrict yourself to the lowest common denominator... on every feature. And still have a brittle result.

Template systems for the dynamic parts win for a reason. And it isn't because of any shortcoming of Perl, Ruby, or that Aelfinn one.

Re:CGI.pm

[moonbender]

Sounds like CGI.pm to me!

Huh? How so? It doesn't seem to be at all like CGI.

Re:CGI.pm

[Seferino]

I confirm, no relation to CGI.pm that I can see (and I'm the architect-in-chief for Opa). That and we offer quite a nice templating system, too.

Re:Five years? Ruby on Rails barely lasted that lo

[taxman_10m]

I'm a newbie and slowly learning RoR right now, so I'm interested to learn that it is on it's way out. What has replaced it? What do you suggest learning for web development currently?

i don't get it

[Anonymous Coward]

i get this, we are going to a lot of folks try and improve the client/server side programming of distributed web application -- and that's a good thing -- but this one will need to significantly evolve to be a game-changer

I prefer Opa Opa

[Dutchmang]

http://www.opaopabrewing.com/

Re:Five years? Ruby on Rails barely lasted that lo

[modmans2ndcoming]

if you want to be in the web dev game, you need to know everything. RoR, Some PHP frameworks, some Python ones, Catalyst for perl would be good, Javascript (the good parts) JQuery, HTML 5, XHTML.

The Web Dev world is very complex and sucks.

Epic fail

[pongo000]

Opa automatically generates client-side JavaScript

Just what we need, more sites spewing out poorly-designed client-side script badly rendered by any number of JS browser implementations. Like many others, I do everything possible to block JS...why does anyone think the future lies in more client-side code?

Re:Epic fail

[Seferino]

Well, perhaps because almost everything you see on the web these days (including /.) requires way more features than what JavaScript-less HTML+CSS can provide.

Re:Epic fail

[pongo000]

Name one single must-have feature that HTML+CSS can't provide, and the browsing public can't live without.

Re:Epic fail

[Seferino]

Angry Birds :)

Re:Epic fail

[Anonymous Coward]

Like many others, I do everything possible to block JS...why does anyone think the future lies in more client-side code?

Um, because they aren't fucking LUDDITES who are still doing shit that stopped making sense a decade ago? I know you may think that you and your neckbeard buddies are "many others", but they aren't...

Re:Epic fail

[Anonymous Coward]

You block JS as much as possible?

Jeez. Ditch the tinfoil hat, Einstein, and get with the times.

Also, almost all webapps nowadays use (and often require) JS. What makes Opa so "evil"?

But wait, there's more! I don't think Opa has much of an overhead in "client-side code."

Re:Epic fail

[imroy]

Name one single must-have feature that HTML+CSS can't provide, and the browsing public can't live without.

AJAX. Almost any large website will include dynamic content to some extent. Haven't you noticed?

Re:Epic fail

[phy_si_kal]

You don't use Google? You don't use Twitter? You don't use Facebook? Honestly, the web is evolving towards applications. And the truth behind applications is that they need to run some code on the client side. You may not like it, but with or without this new technology, there will be probably few sites which will work without JS code running on the client in a few years.

Re:Epic fail

[Anonymous Coward]

AJAX can be a nice enhancement, but it's almost never required.

Re:Epic fail

[truthsearch]

Google search, gmail, twitter, and facebook could all function perfectly fine without JS. Of course the UI wouldn't be as elegant, but JS is not at all a requirement for their functionality.

Re:Epic fail

[Seferino]

Well, they could sort of work, but with reduced UI and reduced features (no drag&drop, no disconnection warnings, no offline reading, no real-time chat, etc.). I do not believe that may people would like to return to this age.

Re:Epic fail

[erc]

Actually, client-side code is useful for a number of things: input validation and web page changes without having to reload the web page immediately come to mind. But you don't want to put all your eggs into one basket - client-side code is notoriously bad at security and any sort of serious processing. You *want* to push your database lookups and security and heavy-lifting processing to the back-end.

They both have their uses, and they can both be useful.

Re:Epic fail

[erc]

That was funny! Bravo!

Re:Epic fail

[Anonymous Coward]

Even GMail has an "HTML-Only" version. You can get by without JS.

Re:Five years? Ruby on Rails barely lasted that lo

[Kagetsuki]

Uh, what? I'm guessing you posted as AC because you didn't want to get modded down for posting flaming bullshit. Let me guess, you're a Perl developer who's still pissed Perl* doesn't offer a comparable framework and still won't accept the fact that Perl 6 will likely take another 5 years and all the shiny new functionality has been available in Ruby since you first heard about it. Rails is still very alive and well and is used in quite a lot of major sites. Rails 3.1 has some really nice improvements as well. As for speed I'd bet on a Rails app over something like Drupal any day.

Twitter still heavily uses Rails by the way. If I'm not mistaken they are the ones who did all the work to combine Rails and Unicorn - and now you can bind your Rails app to unicorn with about one line of code.

*I very much like Perl - it does many things very well and it has it's place. For plain CGI scripts, shell scripts, and a variety of other tasks it's great. Though I really wish Perl 6 was out 5 years ago so we could stop fussing with this Perl 5 object modoki BS.

Re:Five years? Ruby on Rails barely lasted that lo

[Anonymous Coward]

Clearly this is an attempted troll post..

Rails = COBOL. It's dead tech. You need to get your head back in the game and switch to ASP.Net

Now this is a troll post, bitch.

Are you sure?

[xyourfacekillerx]

Just what we need, more sites spewing out poorly-designed client-side script badly rendered by any number of JS browser implementations. Like many others, I do everything possible to block JS...why does anyone think the future lies in more client-side code?

While I agree that client-side code is not the proper direction for web focus (it amounts to circumventing doc structure standards with a scripting standard to do things neither standard planned for, the habit of doing this is REALLY why we have "Web Development Language/System of the Day") ... I don't know how Opa determines its JS output, and though my glance through the documentation turned up nothing, I imagine its claim to being transparent means there might be some control to what quality of JS is output.

While I am currently merrily digging into its grammar and the more technical details of the language itself, I don't really want to mess around with this language platform, though, because its "integration" of database, server, and client side means a nightmare for development when you traditionally have database team, design team, server-side team, etc. this puts all the eggs into one basket, how do you manage that? This sounds like it'd requiere a whole change in the development methodologies and programming practices, or would only be adopted by cowboy programmers working for small outfits. Our brains can only hold so much information, and getting familiar to this "language" would displace more practical knowledge. Where are the white papers, case studies, best practices, cost analysis, migration analysis... ? The things that would motivate the business minded to adopt, you know?

A new programming language

[Anonymous Coward]

"... a new programming language ..."

Oh for chrissakes. Kill it with fire now.

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:Dear Creators of Opa...

[Anonymous Coward]

My comment probably won't be visible to anyone, but I'd like to state that I personally agree with your view of object and functional paradigms. Being long time fan of Scheme and OCaml and recently having learned Erlang I can only say that OOP is just not enough. I want to believe that every programmer out there is prepared to learn something new every day and I think that Opa is worth learning - especially for those who don't speak any functional language. Type inference (is it Hindley-Milner?) is especially nice touch and guarantees that Opa makes are much appreciated.

I can only feel ashamed that some of my fellow programmers are unable to grasp anything beyond their area of expertise and are users of single "golden hammer". But I believe that what counts for most of us is - apart from mastery of using them - diversity of our tools, which allows for quicker and more scalable solving of different kind of problems.

So, please continue your work and don't be discouraged by those who can't appreciate what your doing. I may not have used Opa yet, but I will remember to try it next time I get some opportunity :)

Re:Dear Creators of Opa...

[fartrader]

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

More experience would tell you that these technologies evolved organically to meet a rapidly changing market need - thats why they were "bolted on" to also-emerging OO server-side platform. There was no attempt at central planning. A single cohesive OO approach could just be as scalable.

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.

Uhhh the Java lesson, which like it or not is widely adopted demonstrates the opposite. Erlang and Scala at the moment remain in the realm of the hobbyist or bleeding edge experiment - Java saw rapid widespread adoption because it was so similar to the oh-so popular C++ - it both syntax and semantic terms.

Good luck! ...and change the license ouch!

Re:Dear Creators of Opa...

[Seferino]

[...] 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

More experience would tell you that these technologies evolved organically to meet a rapidly changing market need - thats why they were "bolted on" to also-emerging OO server-side platform. There was no attempt at central planning. A single cohesive OO approach could just be as scalable.

That's an interesting claim. Do you have any example to back it?

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.

Uhhh the Java lesson, which like it or not is widely adopted demonstrates the opposite. Erlang and Scala at the moment remain in the realm of the hobbyist or bleeding edge experiment - Java saw rapid widespread adoption because it was so similar to the oh-so popular C++ - it both syntax and semantic terms.

Er... the opposite of what? Still, I think I understand your point – see a past discussion on my blog on the topic of syntax.

Good luck! ...and change the license ouch!

Not my call, unfortunately. You may wish to convince phy_si_cal (our CEO) or Mathieu Baudet (or COO), though.

Re:Dear Creators of Opa...

[drgroove]

Mathieu, I'll take this up with you over email then. I appreciate the response. - DrGroove

Re:Dear Creators of Opa...

[Seferino]

Just for clarity: I'm David, the Chief Scientific Officer. Mathieu is the Chief Of Operations.

Re:Dear Creators of Opa...

[Anonymous Coward]

We are slowly entering the age of functional programming anyway. OO is yesterday's technology and does not really fit the new multi core and cloud hardware platforms. You better start learning or you will be left behind. I do not know if opa is the future standard but it does reflect the direction programming is moving to so it is at least interesting to try and research.

Re:Dear Creators of Opa...

[znerk]

Your security is probably horrible, since you're cheerfully posting your project lead's email address unobfuscated in a public forum (in multiple places, even! Whoo!). That's alright, though, he doesn't actually use his mlstate.com email address for anything important, does he? He probably wanted a good hard test case for that new antispam software, anyway, and your mail server should hold up well to the flood.

Compound this with sarcastic remarks in response to what looks like legitimate feedback, and I'm wondering how long you guys have been out of the garage.

Nice Idea, but...

[davesque]

I like the idea behind this: that web programming should become less like the herculean task of juggling several syntactically different languages. But why did they need to use that word "transparent"?? This is one of those silly buzz words that means very little (like cloud this and that) and smacks of sales talk.

Re:Nice Idea, but...

[phy_si_kal]

My fault. The word transparent comes from the original article, but not from opalang site. As for cloud, it clearly lacks a meaning ;) I take it as distributed+easy to deploy, so Opa will be the cloud language once it can automatically deploy apps on EC2, Rackspace, etc.

Opa = OCaml + "rails"

[Anonymous Coward]

Compiled their 76-line hello_chat.opa into a 30M executable ... 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.

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

Re:Five years? Ruby on Rails barely lasted that lo

[Anonymous Coward]

Gotta admit you made me laugh.

Re:Five years? Ruby on Rails barely lasted that lo

[sycodon]

COBOL runs the world.

Re:Five years? Ruby on Rails barely lasted that lo

[thePuck77]

Clearly this is an attempted troll post..

Rails = COBOL. It's dead tech. You need to get your head back in the game and switch to ASP.Net

Now this is a troll post, bitch.

Impressive! (in Mortal Kombat announcer voice)

Re:Five years? Ruby on Rails barely lasted that lo

[pmontra]

Don't worry, RoR is well alive. I'm paying my bills by writing RoR web apps. I'm sending another invoice to a customer for a RoR project next week.

targeting javascript?

[StripedCow]

So they're targeting javascript. This is going to be, uhm, not the most efficient approach.

What should happen, imho, is for W3C to develop a (non-garbage collected, as in no garbage collection) low level language, which can serve as a platform for other languages, like this one. Current compiler and virtualization technology can easily and efficiently translate such low level language into something native. And as a result, we could have a much richer web environment, and we'd not be dependent on that one strange little language we've been having to put up with. Open up the web-computing environment, and open-source languages could proliferate here.

Re:targeting javascript?

[phy_si_kal]

Targeting Javascript is just a small portion of the Opa code, as you can see at the Opa repo.
Indeed, should the language you mention exist, it would be easy for Opa to target it.

Re:targeting javascript?

[StripedCow]

That's good, but then it still is an important part, since building web-apps nowadays is getting more and more important.

Well, I guess we'll first need to have a bunch of languages targeting javascript, before W3C sees the light. Sigh.

Re:targeting javascript?

[Seferino]

Well, if Google Native Client/NaCl becomes mainstream, we will certainly start working on a compiler targeting this platform.

Re:targeting javascript?

[opadikt]

I wanted to comment about efficiency of the code compiled to JS. In most cases, an excellent JS-hacker would not have been written a better code by hand. As an example, here's a simple function written in Opa (iterating a function on a list):

iter(f, list) =
match list with
| [] -> void
| [ hd | tl ] ->
do f(hd)
iter(f, tl)

And it gets compiled to this (before renaming and minimization):

function iter(f, list){
var tmp;
while (c = list.tl) {
f(list.hd);
list = tmp;
}
return js_void;
}

If you want to look at your generated code, launch your compiled server with -d --js-renaming no, and look at all.js somewhere in a directory opa-debug.

In the name of humanity, stop.

[luis_a_espinal]

Whether I'm a commercial user or not... why would I - or anyone - ever want web visitors to be able to grab the SQL username and password I'm using in the back end?

You are doing it wrong. Please turn your geek card. Seriously. This is one of the stupidest things I've ever seen, typically done only within the bowels of them most incompetently written software ever. Configuration parameters of any kind are never, ever, ever, ever put in code. It's like Jesus Christ man, this is shit that is taught in in freaking sophomore-level programming classes (seriously.)

Poor unexpected victims the ones who pay crappy, shit-flinging code monkeys for developing their software after reading "Be a Quickass PHP/Java/VB/C#/Whatever Cowboy in 12 Hours" (and end up receiving *this*). This is 2011, not the 1960's. There is no excuse for anyone to do this kind of things while working on software for a living.

No windows port?

[Anonymous Coward]

No windows port? seriously?
I like the fact that it is not object oriented. Maybe mere mortals will finally be able to develop with this. OOP should die already!

Re:No windows port?

[cedrics]

No windows port? seriously?

We did have a working Windows version and we may have it again. Now OPA is open source, maybe there are some volunteers to help us :) ? Note that we will soon launch something that allows *everyone* to try OPA. Keep in touch!

Re:No windows port?

[znerk]

No windows port? seriously?

We did have a working Windows version and we may have it again. Now OPA is open source, maybe there are some volunteers to help us :) ?

Note that we will soon launch something that allows *everyone* to try OPA. Keep in touch!

Not just Open Source, but virulently so.
And just how many of you OPA guys are trolling this thread?

Re:Five years? Ruby on Rails barely lasted that lo

[Hognoxious]

a Perl developer who's still pissed Perl* doesn't offer a comparable framework

That would be like a gazelle getting annoyed because it can't ride a bike.

Another one - Ur.

[Anonymous Coward]

Someone mentioned WT (witty) already: similar in concept solution for C++. I'd like to point out Ur - while it seems to be (slightly) older it leverages the same principles and works similarly.

What I think is the most remarkable feat of Opa and Ur is that they aim to be purely functional and statically, strongly typed. In such a setting it would be very hard to work without integrating everything to conform to some (functional) standard - I think that's why Opa and Ur try to integrate all layers of webapp into one language. It's different from previous approaches, where integration was the goal - I think here it is just a side-effect (hehe) of purely functional mindset.

That's just my impression - I love functional languages and more so pure ones, so I may be biased. And I prefer statically typed ones (with type inference) and safety they bring to the development (although I'm primarily Python developer).

Re:Another one - Ur.

[Seferino]

There's a quick comparison on Ur/Web vs. Opa on the Lambda the Ultimate OA.

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:AGPL makes Opa dead on arival

[opadikt]

I've never cared for indentation defining blocks.

You mean like in Haskell ? Opa does not do that: you can indent as you like.

Re:AGPL makes Opa dead on arival

[Seferino]

Plus I've never cared for indentation defining blocks.

Well, neither does Opa.

(Note: Your other points are valid)

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

Re:AGPL makes Opa dead on arival

[Anonymous Coward]

As a side note, indentation is not meaningful in Opa.
Examples are indented just for the sake of clarity.

so many buzzwords ...

[Anonymous Coward]

... in TFR and their homepage

Seriously, where is the slashvertisment tag when you need it ?

threads

[StripedCow]

How does opa handle multiple threads of execution? Any decent server nowadays just needs to have multiple threads of execution, sometimes even thousands of them to work in a non-blocking way. Opa seems to be "non-blocking" (I read from the tutorial), but you have non-blocking and non-blocking... One version simply uses one thread and an event-loop (aka non-preemptive multitasking). This is not truly non-blocking, as large I/O operations in one task still prevent other tasks from working. And does opa allow us to control the priority of different threads?

Also, does Opa have support for fallback to the underlying systems (javascript/databases etc.)? If something is not supported by Opa (very likely in the beginning), I sure want to be able to fix it myself without having to understand all the opa internals.

Re:threads

[opadikt]

There's a now popular alternative to using threads, through epoll (or kqueue, /dev/poll, etc.). It's for instance the mechanism behind node.js. It's also the one behind Opa. About compatibility, yes, it is easy to plug external libs/tools inside Opa. At the moment, iIt's particularly easy with JavaScript, OCaml and C, and the supported languages will grow bigger with time. It's also very easy to cooperate with external programs through REST (we may also implement support for communication through Unix pipe.

Re:threads

[cedrics]

Hi StripedCow, I'm one of the guys who wrote the OPA scheduler so I'll try to answer your scheduler-related questions. It uses fibers (co-operative light threads). The compiler transforms your code to a CPS representation, so our scheduler can balance the pool of computation stuff and I/O operations (we use epoll on Linux, kqueue on Mac OS). The developer can explicitly push asynchronous tasks with a simple Scheduler.push https://opalang.org/resources/doc/index.html#scheduler.opa.html/!/value_stdlib.core.rpc.core.Scheduler.push
OPA doesn't yet offer to the developer the control of the priorities.

So as you can understand, it doesn't rely on the OS-scheduler, there is only one main OS-thread for all computations and I/O clients (our scheduler does the job). A common question is how to use all cores of a multi-cores machine? Well, just launch the app one more time and use your load balancer (or use our cloud tool).

The code is open-source, scheduler included ;)

Re:threads

[Seferino]

How does opa handle multiple threads of execution? Any decent server nowadays just needs to have multiple threads of execution, sometimes even thousands of them to work in a non-blocking way. Opa seems to be "non-blocking" (I read from the tutorial), but you have non-blocking and non-blocking... One version simply uses one thread and an event-loop (aka non-preemptive multitasking). This is not truly non-blocking, as large I/O operations in one task still prevent other tasks from working.

We have lightweight threads can be preempted any time they are not in (Opa) kernel mode, and rely on asynchronous I/O (epoll/kqueue/completion ports) to achieve non-blocking I/O. Does this answer your question?

And does opa allow us to control the priority of different threads?

Not at the moment.

Also, does Opa have support for fallback to the underlying systems (javascript/databases etc.)? If something is not supported by Opa (very likely in the beginning), I sure want to be able to fix it myself without having to understand all the opa internals.

I am not certain I understand the question. Does this chapter answer your question? There's the same thing server-side, of course.

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

Re:threads

[StripedCow]

Hmmm, fibers may not be the right tool for making low-latency (highly responsive) multi-user applications. The problem is that when one fiber is doing a lengthy task, the other fibers are sleeping until the first fiber yields. That's why the popular web-servers go through all the trouble of spawning multiple threads instead of just using an event-loop approach (using select, epoll and kqueue). Sure, you will not have any additional context-switching overhead that way, but today low-latency is what counts.

Or am I missing something?

Re:threads

[StripedCow]

We have lightweight threads can be preempted any time they are not in (Opa) kernel mode, and rely on asynchronous I/O (epoll/kqueue/completion ports) to achieve non-blocking I/O. Does this answer your question?

Could you explain this a little further? In my understanding, the epoll based approaches are all synchronous, non-preemptive. That is, in such a method you wait in an event-loop for events, and when an event arrives, you perform some action, effectively keeping other events in the queue. This means that if one event triggers a lengthy computation, then other users of the system may experience non-responsiveness.

Re:threads

[cedrics]

Don't forget that the compiler transform your code to a CPS representation. So in practice, your OPA function is "cut" into many very very small fibers. So, even if we are talking about non-preemptive fibers, the high-level user function can be stopped by the scheduler at any time to take car of new I/O events.

It's the scheduler job to balance all those small fibers (that belong to several high-level functions) to optimize the latency level. And the web-specific scheduler does this job better than the generic OS-scheduler.

Re:threads

[cedrics]

I hope my message above answers this question too. http://developers.slashdot.org/comments.pl?sid=2401364&cid=37234382

Re:threads

[StripedCow]

Even if the fibers are small, they may invoke kernel calls which take a long time to complete (for example a large I/O operation). How do you ensure that other fibers can continue their work in such cases?

Further, the smaller your fibers get, the more overhead you introduce for context-switching, right? Because I can imagine that after execution of each fiber you need to do some scheduling (even if the current fiber remains active). Is this context-switching faster than the kernel can do it?

Finally, I'm interested in what makes scheduling for the web such a specialized task, but that may be related to the previous question.

Re:threads

[cedrics]

Even if the fibers are small, they may invoke kernel calls which take a long time to complete (for example a large I/O operation). How do you ensure that other fibers can continue their work in such cases?

For example, to write a large file over the network, the scheduler write small piece of data at a time. And all socket are on non-blocking mode. So if the read/write operation would block, the OS just raise an "would block" error, and the scheduler use epoll to check back later.

To call synchronous function, there are solutions like forking the operation into on an other process. And there are different solutions for the process-communication : pipes, sockets, hlnet (our home made protocol used by our distributed DB), rest, soap...

Further, the smaller your fibers get, the more overhead you introduce for context-switching, right? Because I can imagine that after execution of each fiber you need to do some scheduling (even if the current fiber remains active). Is this context-switching faster than the kernel can do it?

Finally, I'm interested in what makes scheduling for the web such a specialized task, but that may be related to the previous question.

By "specialized", I mean it's better that fibers are scheduled by the application-scheduler itself, that knows the logic of the application and the purpose of each fibers, rather than the OS-scheduler. About context-switching, there is the small context-switching between fibers inside the main-thread, and the bigger context-switching between this mean thread and the others thread of the OS. So it really depends here on what we are trying to compare (and if it's comparable).

Re:threads

[Seferino]

Well, cedrics answer should help answer your question. I will try and add a few details.

Indeed, epoll et al. are based on polling and as such are non-preemptive. However, with proper language/runtime support, they can be coupled with a scheduler and turned effectively into lightweight preemptive multi-tasking. In Opa, the compiler inserts CPS breaks (i.e. opportunities for the scheduler to perform context-switching and/or to poll for the completion of lengthy I/O) wherever appropriate, with guarantees that any lengthy computation will be thus broken on a regular basis.

By opposition to pthreads/system threads, this mechanism lets us scale to millions of lightweight threads, all of them effectively executed concurrently. By opposition to the Node.js-style event-based approach, we are certain that no task will block and the style is more natural.

Re:threads

[znerk]

Well, cedrics answer should help answer your question. I will try and add a few details.

Indeed, epoll et al. are based on polling and as such are non-preemptive. However, with proper language/runtime support, they can be coupled with a scheduler and turned effectively into lightweight preemptive multi-tasking. In Opa, the compiler inserts CPS breaks (i.e. opportunities for the scheduler to perform context-switching and/or to poll for the completion of lengthy I/O) wherever appropriate, with guarantees that any lengthy computation will be thus broken on a regular basis.

By opposition to pthreads/system threads, this mechanism lets us scale to millions of lightweight threads, all of them effectively executed concurrently. By opposition to the Node.js-style event-based approach, we are certain that no task will block and the style is more natural.

Am I understanding correctly that you have reimplemented threads on an application level, instead of the OS level? So your application's threads (fibers, whatever) can be pre-empted by the OS, because the OS doesn't care about your scheduler when it's handling its own processes?

Am I also understanding correctly that there's no priority system for your threading implementation?

The more and more of this thread I read, the less and less I think you guys are ready for prime time.

Re:threads

[Seferino]

Am I understanding correctly that you have reimplemented threads on an application level, instead of the OS level? So your application's threads (fibers, whatever) can be pre-empted by the OS, because the OS doesn't care about your scheduler when it's handling its own processes?

This is absolutely correct. And, if you check, this is what any system that wants to be able to manage tens of thousands of threads does (not necessarily with the exact same techniques). Including all major databases, all large scale virtual machines, etc. Recent versions of MacOS X even provide system libraries to simplify the implementation of such user-level threading (under the name of Grand Central Dispatch).

Am I also understanding correctly that there's no priority system for your threading implementation?

Actually, there is one. It is just not exported to userland yet.

Re:threads

[StripedCow]

Hi Seferino,

Thanks for all the explanations. Your approach to multi-threading looks very interesting. I'm still wondering if you can always guarantee that fibers will never take more time than you give them, but I suppose you have all those cases covered.

Further, I'm wondering, since your project is so large, if you considered splitting it up into smaller projects. For example, your distributed database could possibly be useful to the C++ community as well. And that fiber/CPS approach could be useful in other (non-web-related) contexts too (why don't we have that GCD system in Linux yet, for example?) :)

Finally, all these technical explanations you are giving here should really be on your website, I think (in more detail than the white-paper). Attracting the attention of skilled people to your project requires this level of detail, especially since your project has such a great impact on the overall way of working (and thinking) of your developers.

And while you're at it :) you could include information on how you handle garbage collection (are you using a concurrent collector, or one that occasionally halts execution of the program), and on how your distributed database works. And perhaps you could include some benchmarks (a la the great programming language shootout) to make it all really convincing.

Bests,
StripedCow

This license is poison

[Paeva]

I think the concept of Opa is neat. Other projects may have tried and failed at this, but maybe the Opa authors could make it work.

However, the choice of license completely precludes me from even trying it. Sure, I release source code for some of the stuff I make (even though nobody looks at it). Here's why:

Let's say I try out Opa, make some side projects with it, fall in love with it, and I get good at it.

Now, either at my day job, or on my own, I come up with super awesome project X that I want to build and release as some sort of money-making venture. We may even want to open-source the code for the site eventually, but we're not sure yet.

If I were to leverage Opa to do this, however, I will have to *pay* to keep my source closed. That's just not acceptable.

Opa = Grandpa

[Anonymous Coward]

In German. ;)

File Uploads?

[Anonymous Coward]

The ultimate web language with no file uploads?

https://mlstate.com/forum/feedback_on_opa/feedback/1#5

Re:File Uploads?

[cedrics]

The ultimate web language with no file uploads?

https://mlstate.com/forum/feedback_on_opa/feedback/1#5

This thread is one year old. Now, we do have an upload component in our stdlib : https://opalang.org/resources/doc/index.html#upload.opa.html/!/value_stdlib.upload.Upload

Re:Five years? Ruby on Rails barely lasted that lo

[Anonymous Coward]

How long did it take people to get over the Java hype? And yet it continues to have widespread use. Hype only lasts so long. At one time COBOL was all the rage. Now it's a "dead" language to many programmers, despite the billions of lines of code still running, despite the big salaries COBOL programmers pull down, despite the language being updated to keep up with the times.

Re:Five years? Ruby on Rails barely lasted that lo

[anomaly256]

Dead tech that runs all the big business logic and demands a 120k~200k salary of it's technicians ;)

Please give me more of THAT kind of dead tech :)

yeah let's build a castle on a base of sand

[PJ6]

because html, javascript, and browsers are soooo robust and versatile

Re:yeah let's build a castle on a base of sand

[Patman64]

Yeah, why not just reinvent the internet. Simple project, I'm sure a small group of obscure OSS developers should have no troubles.

Re:yeah let's build a castle on a base of sand

[Seferino]

because html, javascript, and browsers are soooo robust and versatile

Good point. We had really hard times tweaking the compiler until it produced JavaScript that worked on all browsers (note: in our books, IE7 is not a browser), or html that worked in all browsers, and with linking with all mainstream JS libraries (note: thanks Facebook for the nice code provided, that explicitly depends on server misconfigurations and/or browser bugs and suddenly stops working when confronted to a standards-compliant web browser and a well-configured server), and with getting our Comet to work with all the different possible interpretations of "asynchronous".

But that is not the point. The point is that this is a problem that *every* non-trivial web application needs to face. The point is that we faced it and we beat it, so that Opa developers do not need to. Should a new browser version arise and cause new incompatibilities, *we* will be the ones doing the heavy debugging until we can produce a new version of the compiler and runtime that lets developers forget about the incompatibilities.

So yes, these brittle bases made our work difficult (and interesting :) ). But they also constitute an important part of the interest of Opa.

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

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

[znerk]

Mr Seferino, aka "Opa Architect-in-Chief"... you're doing a lot of astroturfing, but I haven't seen anything from you on the copious number of comments concerning your infectious and controlling license... even just a little pricing info would calm that kettle, and yet you haven't said word one about the licensing nightmare you're attempting to unleash, just how very cool your code is.

Until you decide to show us you're not gonna rape us with licensing, you're not gonna get much in the way of legitimate users.

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

[Seferino]

Good point. Unfortunately, as the CSO, I have strictly no say in the license. If you wish to discuss it with someone who does, you should ping phy_si_cal, our CEO and the OP of this thread, or send an e-mail to Mathieu Baudet, our COO.

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.

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

[znerk]

And I didn't think about it before I hit submit, but did you just openly admit that this entire thread is a slashvertisement?

Bad form, sir. Bad form.

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

[Seferino]

Self-promotion on Slashdot? Nah, this never happens.

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

[znerk]

Nah, it happens all the time, we just usually troll it into the ground.

A little light reading for next time you're thinking about throwing yourself under a bus.

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

[Seferino]

I think that you are missing the obvious: it worked.

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

[znerk]

I think that you are missing the obvious: it worked.

Yes, yes it did. And now most of Slashdot is convinced you have a non-starter.

Good job!

Very interesting...now find a "home"

[Rob.Darwin]

Opa seems interesting, and I'd like to join the well-wishers in errm...wishing you well.

Talking about wishes, I'd be very interested in how you sell to the some of the key "stakeholders"
I'm slightly firing from the hip, so I would welcome any corrections and input (especially stuff that is not too abrasive...pretty please!)

(1) Developer
- Quick to learn
- Easy access to useful libraries
- Good debugging
- Ability to use favourite tools
- No nasty surprises

(2) Program manager
- Stuff that can be developed real quick (grumble..."why is it that developing for the web, seems so much slower that old VB was many years ago" ...put away rose tinted specs)
- A clear architecture to buy into...
- ...that can be used for a clear set of uses
- That integrates into other systems
- That does not require too much investment prior to delivering some initial useful results

(3) Operations
- Reliable
- Monitorable (I know my spell check doesn't like the word either!)
- Auto deployable
- Scalable
- Runs on our standard Linux Image (in our case Ubuntu, but everyone has their own preferences, which are without doubt RIGHT)
- Detectable and graceful degradation
- Some clear benchmarks, and optimisation techniques

(4) Users
- attractive
- easy to use
- responsive

And in a couple of apps that we are considering
(1) A real-time dash board
(2) some web components that our dealers can plug into their websites to sell our stuff
- something that can fit within other session models
- Something that we can embed into some javascript so that our dealers can copy and paste it into their sites
- Allows for good css restyling

Hope that this helps, and maybe you might do a FAQ post given some of the issues that are raised here!