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?
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:)
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.
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.
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.
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.
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.
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.
Have you considered using Opa? I may be biaises on this topic (I'm a member of the Opa team), but it sounds to me like it's a very good match for your issue. It's an open-source web development platform designed for security - it's an Owasp project, btw. Among other things, it guarantees that your application is invulnerable to XSS and SQL injection, and it performs a large number of analyses on your code, on the inputs, etc. to greatly improve security.
Depending on the current status of your code, you can either use this as a foundation for the whole application, or just as a front-end.
More info on the teaser website, on my blog, or on IRC (freenode, channel #opalang).
I'm curious. I mean, I've used Erlang but not for industrial work. While Erlang itself is fully message-passing/functional, its libraries are full of side-effects. Does anyone know what actual implementations use ?
Good for us. Get the rabble away from Slashdot. Only true nerds should understand the contents. Let me add a few keywords to get rid of the softies: monads, higher-order type systems, return type, genericity.
Your turn.
This is interesting indeed. When reading the summary, it made me think about BSPML, although the slides make it clear that there are a number of differences. Essentially
BSPML doesn't limit itself to FSM but has full expressive power, including exceptions -- some implementations of BSPML use monads to solve things that this work solves by scaling down to a FSM
BSPML doesn't support dynamic changes to the number of threads
many BSPML algorithms are provable
BSPML is typically compiled to fully native code
BSPML doesn't use processor-specific concurrency-specific optimizations
BSPML works on distributed systems.
Despite the differences, both models work by sharing code and operating on a high-speed concurrent pseudo-vector, in a completely lock-free model (although locks can be implemented on top of the model, as usual).
Just my.02 â.
I won't get caught in this flame. I'll just note that it's a far cry between "blocking a road" and the "terrorism" implied by the post I was replying to.
Seems I've already lost one point for trying to avoid this variant of Godwinism. That's unfortunate.
That's a joke, right ?
The APL Jade boarding was an attempt at (peaceful) demonstration. Now, you may like Greenpeace or not (although I'm not a big fan, I personally prefer a world with Greenpeace to the same world without Greenpeace), but you're just trolling.
It's a simple thing, really. I'm a university lecturer and I have explicit instructions to grant the degree to as many people as possible, 100% ideally -- and that's independent from their actual skill level, because some of them are barely able to understand simple questions or simple mathematics. The only solution is to lower down the expectations for the whole class -- and single out the brightest students to teach them more advanced topics whenever the mass is still trying to solve the easy exercises. Not very flattering, but then, I don't have much of a choice.
Re:The best fliers
on
Flying Humans
·
· Score: 2, Funny
This kind of law has been voted in France about one year ago. I've followed that one quite closely as, well, I'm a French researcher in the field of security. So far, the law hasn't been applied, but if it is ever makes it to a court with a judge who decides to apply it literally, I might well:
Go to jail because I've tinkered with a web site (playing with POST or GET) -- because I've actively been looking for a security breach.
Go to jail because I've taught my students that things like eval() (in JS or PHP) are unsafe -- this may be assimilated to teaching piracy techniques. Same thing goes for buffer overflows, nm, ldd, gdb, cryptographic attacks...
Go to jail because I've disassembled a binary, put it through nm, ldd or anything similar to determine if it was safe to run it on my system, as that is reverse engineering. Same thing goes for writing a SELinux policy for a binary. Too bad my job is actually to design and implement tools to perform automatic analysis and/or watchdogging of third-party software.
Etc. As I mentioned, this law hasn't been applied yet, much less tested in court. I believe that, in the case of security researchers, they couldn't hold against a sensible lawyer. But I'm still somewhat anxious whenever I teach something to my students or whenever I write a paper about security analysis.
What I understand from your answer is that Vista is (or might be) the right choice for technology consumers. Nothing wrong with that, but I'll stick with Linux. I don't fancy myself a consumer.
P.S.:
IE 6 works under my Linux, I assume it works as well on Mac OS X / x86, or will do so shortly.
Slashdot Mirror
There's a quick comparison on Ur/Web vs. Opa on the Lambda the Ultimate OA.
Well, if Google Native Client/NaCl becomes mainstream, we will certainly start working on a compiler targeting this platform.
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?
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.
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.
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.
Angry Birds :)
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.
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.
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.
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.
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.
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.
Have you considered using Opa? I may be biaises on this topic (I'm a member of the Opa team), but it sounds to me like it's a very good match for your issue. It's an open-source web development platform designed for security - it's an Owasp project, btw. Among other things, it guarantees that your application is invulnerable to XSS and SQL injection, and it performs a large number of analyses on your code, on the inputs, etc. to greatly improve security.
Depending on the current status of your code, you can either use this as a foundation for the whole application, or just as a front-end.
More info on the teaser website, on my blog, or on IRC (freenode, channel #opalang).
:)
I admit I've only browsed quickly through TAPL. But I work in the field, so that's probably a major sin.
Amb. Calculus of constructions. Higher-order barbed bisimulation. Stochastic processes. :)
And you're cheating with your signature
I'm curious. I mean, I've used Erlang but not for industrial work. While Erlang itself is fully message-passing/functional, its libraries are full of side-effects. Does anyone know what actual implementations use ?
One implementation here, another, more recent, there. I remember there is an Haskell version somewhere, but I can't remember its name.
Good for us. Get the rabble away from Slashdot. Only true nerds should understand the contents. Let me add a few keywords to get rid of the softies: monads, higher-order type systems, return type, genericity.
Your turn.
Just my
I won't get caught in this flame. I'll just note that it's a far cry between "blocking a road" and the "terrorism" implied by the post I was replying to. Seems I've already lost one point for trying to avoid this variant of Godwinism. That's unfortunate.
That's a joke, right ? The APL Jade boarding was an attempt at (peaceful) demonstration. Now, you may like Greenpeace or not (although I'm not a big fan, I personally prefer a world with Greenpeace to the same world without Greenpeace), but you're just trolling.
It's a simple thing, really. I'm a university lecturer and I have explicit instructions to grant the degree to as many people as possible, 100% ideally -- and that's independent from their actual skill level, because some of them are barely able to understand simple questions or simple mathematics. The only solution is to lower down the expectations for the whole class -- and single out the brightest students to teach them more advanced topics whenever the mass is still trying to solve the easy exercises. Not very flattering, but then, I don't have much of a choice.
Of course not, it's Intelligent Design !
Etc. As I mentioned, this law hasn't been applied yet, much less tested in court. I believe that, in the case of security researchers, they couldn't hold against a sensible lawyer. But I'm still somewhat anxious whenever I teach something to my students or whenever I write a paper about security analysis.
What I understand from your answer is that Vista is (or might be) the right choice for technology consumers. Nothing wrong with that, but I'll stick with Linux. I don't fancy myself a consumer.
P.S.: IE 6 works under my Linux, I assume it works as well on Mac OS X / x86, or will do so shortly.