The Opa Language
opalang.org
opalang.org
Reading the different comments, I must say that Opa is still active (although we lack resources to animate the community). We are a small French startup meaning that I get to spend 50% of my time struggling with administration, and our evangelism resources are not compatible to those of companies like Meteor (and btw, Opa predates Meteor by a while).
Currently, we use Opa to build a secure communication application, named PEPS :
https://github.com/MLstate/PEPS
which is a good example of a "big" and open source application written in Opa. Note also that bringing a new language (or framework) from toy examples to real apps is definitely not easy.
Overall, quite glad to see that many things we introduced in Opa ("JSX" syntax, CPS-transforms, etc.) are becoming more prevalent, especially thanks to ES6. Indeed, adapting Opa to ES6, which we are looking at right now, would enable existing applications to use the latest ES6 features without changing the app code.
That was one of the goal of the project: Opa was meant to be a "good way" to write applications, letting the compiler choose a target platform and write code for it.
Opa is still relevant today, as a "good quality" (especially in terms of safety -- and if you are interested in certified applications like common criteria, please contact me: Opa is relevant in that space) "one-stop shop" to build develop web apps or services. Remind that when we started a few years ago, many were criticizing that we use a functional programming language, were telling us that nobody wants static typing, etc. (that was before Hack which helped a lot in popularizing the feature -- and Opa too is written in OCaml).
And Opa has a future. The way the compiler is written, it's not that hard to have it compile the same application code into cloud platforms, including a lot of Amazon Lambdas...
We maintain a roadmap: https://github.com/MLstate/PEPS/wiki/Roadmap
Thanks to Opa (possibly due to that fact that we know how to use it at its best), we are able to develop features very quickly. I would say that what we need most is to optimize the UX and little details that matter to refine them over time. But overall, I think we can go technically much farther that Zimbra/Roundcube. But to achieve more popularity, we will need to beef up some marketing aspects!
Your main competition, that I see, are Ur/Web and the Ocaml/Haskell frameworks. I recommend that you continue doing what you're doing while copying any great things you see in those communities along the way. Especially ways to leverage type system to prevent problems. I think just good marketing, library support, fixing some of what people are griping about, and some major success stories in the media is all you need. Best wishes on your work as it's one of rare few that leans toward a Correct-by-Construction approach to web applications. Need more of those.
Note that we have other experimental backends available, although not in the open source release (yet). I am also interested in compiling to MirageOS -- we have all the mechanisms in place in Opa to do that easily, namely one called the "Bypass Standard Library" (BSL). I just uploaded one draft paper written at MLstate about the BSL: https://www.scribd.com/doc/271277920/Opa-BSL-Bypass-Standard...
I'm not Korean, but my understanding is one reading might be "Mister Language". Several of my Korean friends address me as "Karl Oppa" or just "Oppa". (Yes, "opa" isn't the standard Romanization, and the word order isn't correct.)
In Korean "oppa" is the word for older brother used by a younger sister, and by extension, an honorific used by a younger woman to show respect for an older man. (When my Korean friends meet someone new, they quickly figure out who's older, even by just one year, in order to figure out who's supposed to use the honorific addresses.)
Imagine if in English, we only used Mr. and Ms. when talking to someone who's chronologically older, and had different forms depending on if the speaker is male or female, and furthermore it was considered very rude not to use the title where appropriate. Oppa is kind of the word for "mister" used by women, but is mandatory in many more cases than would be expected in English.
So I get grossed out when a Korean girl calls me oppa and I have expressed my discomfort which was met with a cold response (I guess they really like calling older men oppa), part of the reason I never date younger Korean women. That and the whole 'mister' or aekyo (adult women emulating an infant) shit I find very creepy and unattractive. There's this national inclination for young women, sort of like Japan's obsession with schoolgirls.
On the other hand, being called 'ajusshi' which doesn't carry the same affection as 'oppa' and intended for much older men and some Korean men take offense when addressed as 'ajusshi' but less so than Korean women who go apeshit when I made the mistake of calling them 'ajumma'.
on an offtopic side note, Oppai in Japanese means tits.
In parts of the South, you’re still expected to use “sir” and “ma’am”, particularly with strangers. Most speakers find this a bit old-fashioned or excessively polite, though.
- Seems like the language forgot about objects (they seem to be used as collections or namespaces) - which is surprising given it's JavaScript underneath.
- It also seems like the database functionality is so embedded within the language that using it would sacrifice a lot of control and would become a huge lock-in liability.
- Everything is too abstracted. I must admit my first real programming experience was in PHP, and now that I've done a lot of things in Node.js and other languages I really appreciate being able to do some more things at a lower-level of abstraction (PHP ends up being a glorified templating language usually).
- Edit: Oh, and please can someone find a way to nicely get rid of these JSX-esque syntax additions and just start using ES6 template strings instead. All these extra compilation steps make things so much more complicated and third-party reliant than they need be.
Simple pre-processing and code-to-code transformation is typical in many different languages and environments. Pretty much every time you start a Java or C++ project within some IDE you're essentially generating a lot of code automatically.
And in the case of various JS preprocessors/transpilers it's not even that complicated. It's mostly trivial transformations, which in more capable languages would be expressed as macros, f-exprs or something like that. Maybe try writing your transpiler sometime? It'll take a weekend, and you'll see how easy and simple it is.
> Everything is too abstracted.
That's only because of your background. ASP.NET or GWT guys would not agree, I imagine.
> it would sacrifice a lot of control and would become a huge lock-in liability.
Control over what exactly? You still have an external database you need to manage. You handle backups, schema migrations and so on. I'd say Opa's abstraction of data storage is on par with "normal" ORMs (like Django ORM) in terms of flexibility/power ratio.
I don't see a lock-in potential here, as long as data store used by Opa is available to other languages and environments. You can always just load the raw data directly from DB and do anything you want with them. Would be another story if Opa used in-memory, built-in in-process data storage (which is an approach I quite like) but it doesn't.
True, but I suppose it's still nice to avoid as many unnecessary steps in deployment as possible.
> That's only because of your background. ASP.NET or GWT guys would not agree, I imagine.
Well, there are good and bad abstractions. Many abstractions get in the way eventually if you're doing anything non-trivial.
Even if they do commit to working on this language - and it offers advantages over Meteor (which it looks to be inspired a lot from) - they have a lot of design choices I don't understand:
- Inventing a new language over JS is problematic, a dependency, and you don't get goodies as they land in JS.
- The fact IO is implicit and not explicit means you don't know where you're paying - and is a very leaky abstraction.
- jQuery as a default part of the standard library? Really?
- Anything that "automates the database" terrifies me, anything that wraps PostgreSQL and MongoDB with the same wrapper means I'm paying for impedence mismatch _somewhere_ but they're not telling me where.
- Their "MVC support" section is really about scaffolding, and MVC on the server doesn't make sense anyway in this scenario.
I like the JSXish'ness of some of it but honestly not sure why anyone would use it - the fact there are no strong backing companies is also worrying.
That said - that's just my impression so as always I recommend you try it yourself rather than take my criticism :)
I think having XHTML as a defined type is a stroke of genius, at the risk of hyperbole. No quoting html fragments?! Damn. Wish I'd thought of that.
I'd say it's because of this requirement that they couldn't use Javascript. And inventing a new language over JS is problematic. I won't even learn coffeescript and that's everywhere. You're not going to get me to learn Opa, sorry. Maybe they should have made it a very thin preprocessor where you get to inspect the JS...
Object Relational Mapping and Object Document/Graph Mapping is fine so long as they're not the same mapping :) and so long as you get to inspect the SQL or MongoDB QL...
Not sure what you mean by "and MVC on the server doesn't make sense anyway in this scenario" We're all familiar with MVC scaffolding from Rails by now, aren't we?
Could you please explain why is that? I'm honestly asking - my hobby of learning languages (https://klibert.pl/articles/langs.html) makes me completely unable to understand opinions such as yours here.
Opa once implemented an ML-like language, which I liked better than the current JS-like thing. They moved to JS because of two reasons, IIRC: to get a runtime for free (Node) and to be "more familiar to more developers".
Besides syntax, Opa offers quite a lot of benefits on a language level. Static typing with inference and statically typed HTML - this means that code that isn't safe in terms of HTML injections does not compile at all! Executing the same code on both backend and frontend, built-in database layer and a whole lot of helpers and tools for creating SPAs.
At first I thought Opa is something like Seaside in Smalltalk or Nagare in Python, but it is unique in that it lets you write client-side code without much hassle, which is rather hard in other frameworks.
I'm not interested in learning Coffeescript because it doesn't do anything that javascript can't do, by definition, and it seems to me that my time would be better spent practicing more javascript (10,000 hours and all that).
I get that there's some benefit to hopping around languages, learning from the different paradigms, but there's also benefit from going deep on a single language. Some of the stuff I've seen people do in js is amazing and I'd like to get that kind of mastery. I don't think learning Coffeescript will help with that.
I also find that whole "I can code in 12 different languages" a bit shallow. Yes, I can code in 12 different languages, but can I do it well? Have I mastered those languages, or am I just surfing the shallows of each, unable to really get the most out of them?
I'd prefer to pick, say, three languages, at most, and really learn them. JS is going to be one of those languages because browser, I'm still trying to work out the others but Coffeescript is definitely out.
:)
EDIT: and some assembly variant (ARM,x86,...)? so five?
C definitely, if only to be able to read *nix source and do low-level stuff on devices
Then I'd say Clojure, probably, because it covers the JVM as well as the functional group.
It's 83 in my case... (I'm joking: obviously I didn't write much code in most mentioned languages. But I wrote at least something in the 100-1000 loc range in most of them, I think).
> Have I mastered those languages, or am I just surfing the shallows of each, unable to get the most out of them?
That's only a question you ask yourself at the beginning. You stop doubting your skills and knowledge in different languages around a decade into learning about them. Well, that's how it worked for me.
> and it seems that my time would be better spent practicing more javascript (10,000 hours and all that).
Been there, done that (metaphorical 10000 hours). Four times over with C++, PHP, Python, JavaScript. Then Erlang, and after that, the time needed to learn most of almost any language was significantly reduced.
> I'd prefer to pick, say, three languages, at most, and really learn them.
Again, been there, years ago. Programming - for me - is a life-long career choice, which means I still have 3-4 decades of coding ahead of me. With a solid 10+ years of experience already I know that staying too long with one tech causes boredom; the issue is how to pick the next tech? I figured I'd need to learn quite a lot of them to make informed choices, and so I focused on this. I don't want to stay with a single tech for too long.
It sort of went downhill from there :)
#msg = <div>Thank you, user number {/counter}!</div>
It's a classic DSL; it's more readable and easier to write than equivalent HTML/JS mix (it's both shorter and has less tokens). Such DSLs are used in some languages extensively, I think the most related is xexpr DSL, for example, http://docs.racket-lang.org/web-server/servlet.html#%28def._... (the part in the code snipped starting with "response/xexpr"). It's in Lisp, which means they could write it without messing with language parser, but the idea is pretty much the same.
That said, Opa has a lot of competition. I am thinking of Clojure + Clojurescript, Meteor, Dart, etc. I don't much use Dart, but C+C and Meteor are amazing productive.