81–88 of 88 posts
Christ on a cracker. Web browsers don't understand Opa. They understand HTML. They understand CSS. They understand JavaScript. Who do you want on your team? Someone who understands Opa? Or someone who knows what browsers know, in detail? If I know only Opa I'm limited to what the Opa developers know about these technologies. I'm limited by what they know. By mastering these technologies I'm only limited by what I can…
Earlier quoted context omitted.
Can you please tell me why you changed you syntax to JS-like syntax? The previous syntax was good enough, at least from my point of view.
I don't work on or speak for the Opa team, but I assume they adopted JS-like syntax for the same reason Dart did -- familiarity is important when it comes to language adoption. Regardless of whether or not you think this is a good thing or whether programmers worry too much about superficial syntax issues, this is a practical issue you have to worry about if doing PL design for the real world.
Earlier quoted context omitted.
I don't work on or speak for the Opa team, but I assume they adopted JS-like syntax for the same reason Dart did -- familiarity is important when it comes to language adoption. Regardless of whether or not you think this is a good thing or whether programmers worry too much about superficial syntax issues, this is a practical issue you have to worry about if doing PL design for the real world.
Changing syntax for marketing reasons seems bad from my point of view, I like pythonish syntaxes, like in haml, CoffeScript etc. So changing to JS was a back step.
Earlier quoted context omitted.
It doesn't -- C is analogous to the coffeescript case; it's not at all like Opa. It's the minimal portable abstraction over digital computers. Given some C code, it's not hard to predict roughly what instructions it compiles into. It precisely illustrates the point, because there were dozens of more complicated abstractions (languages) that failed. They claimed to do more for you, but what they did conflicted with re…
Doesn't the C compiler do all sorts of optimization magic that makes the output of the compiler sometimes hard to predict? C is also not the only language that succeeded; C++ and Java are doing pretty well, and I've used them quite alot without delving into the sausage factory of GCC/javac. Scala is doing pretty well too, with it's 20 stage compilation process! I disagree that anything trying to abstract away network…
I think this is an important point -- systems that last have to start really simple.
The Web was laughably simple at first. HTTP 1.0 was roughly: open a TCP connection, send a URL, get the document back, close the connection. It was WAY simpler than many contemporary hypertext solutions.
Unix was also WAY simpler than its contemporaries. Linux is old and hairy now, but that's just how things age without falling apart. They have to accomodate many different people's (sometimes broken) mental models under one roof. A system like Opa seems like it can only accomodate the mental model of its creators, and thus won't age gracefully.
C++ despite being huge has some modesty: it respected people's existing C code and didn't "cover it up". Plenty of people write C with classes still and that's actually a feature. Opa seems like it "covers up" what's underneath.
Java is kind of an exception to the adoption curve because it had huge marketing behind it like no other language did. But I think Java 1.0 was still pretty darn simple. It was a very small language. I'll grant that Java did try to cover up the OS. I think this limited its widespread application, but it's admittedly still massively popular for certain things. You couldn't do async I/O in Java for awhile, nor could you do things like make a Windows shortcut on the desktop.
Hadoop, being based on the MapReduce abstraction, does indeed pretty successfully allow the programmer to ignore the network. The fairly large restriction of being able to write 2 pure functions -- map and reduce -- is what allows this (it allows retries without affecting correctness, etc.). In a way this proves the point. You can't write arbitrary procedural/stateful code (in Opa or any other language) and distribute it over the network at scale. I'll go as far as to claim that this problem is unsolvable in a fundamental sense, like the halting problem is unsolvable.
Now maybe Opa introduces some restrictions in their model that help with distribution that I don't know about, but in general I am skeptical of the "write all your code in this one clean language with our nice model and we'll figure out the rest automatically with our hyper-optimized advanced technology". We've heard it before.
I honestly don't know why as a programmer you would want to ignore the distinction of code running on the client or the server. I'm all for sharing (some) code, as Node.js allows, but it should be obvious in any application whether a code path is running on the client or the server, and you shouldn't need a compiler to figure it out. That kind of coupling is crazy.
Earlier quoted context omitted.
Computers don't understand HTML, or CSS, or JavaScript. They only understand opcodes.
Opcodes!? Real programmers carefully etch silicon into a shape that exploits the various physical properties of flowing electrons to perform computations. Logic gates and opcodes are just an ultra-high-level lossy abstraction above this. Kids today...
Opa is neat, but the two license options of AGPL or "talk to us for a price" basically ensure it will never achieve anything close to mainstream usage.
Agreed. This 'but we wanna make millions with a dual license as that 0.000001% of open source products do' attitude is definitely the largest barrier for this. And it's incredibly short sighted; just open up (L)GPL and do services + support. All big companies WILL buy support as that's what they do. AGPL is crap and will stop your growth; you have an uphill battle already, so don't do stupid things like that.
Earlier quoted context omitted.
Agreed. This 'but we wanna make millions with a dual license as that 0.000001% of open source products do' attitude is definitely the largest barrier for this. And it's incredibly short sighted; just open up (L)GPL and do services + support. All big companies WILL buy support as that's what they do. AGPL is crap and will stop your growth; you have an uphill battle already, so don't do stupid things like that.
Eh, they don't need to just let everyone use it for free. I would say: put it under an open-source (LGPL, for example) license, but charge people for the downloads (including for updates). Nobody likes using software that never updates nowadays, so with low update-prices you could get reasonable amounts of revenue-per-user over time.