How is using Pepper different than ActiveX with Internet Explorer?
One word: sandbox.
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.
[...] 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!
Not my call, unfortunately. You may wish to convince phy_si_cal (our CEO) or Mathieu Baudet (or COO), though.
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.
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.
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.
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.
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.
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.
It is impossible to enjoy idling thoroughly unless one has plenty of work to do. -- Jerome Klapka Jerome