5 ms·

It's a herculean effort. I heard about Opa about a year or two ago, amazed he's still at it. Kind of like Haxe. I doubt they will go anywhere, like Coffescri

It's a herculean effort. I heard about Opa about a year or two ago, amazed he's still at it. Kind of like Haxe. I doubt they will go anywhere, like Coffescript, because any language that simply abstracts another is just cruft and doomed to be obsoleted.

gmac 14y ago
IMHO the CoffeScript analogy is a poor one. CoffeeScript actually abstracts very little from the JS base, being mainly about a lighter-weight, more productive, more enjoyable syntax. Opa is far more ambitious in its abstraction.
chc 14y ago
By that logic, Ruby and Python are just as doomed because they're ultimately just elaborate abstractions on top of C (or at least their reference implementations are). The implementation language and output target of a programming language are not material to the language itself. C targets a wide array of machine codes, but you'd be remiss in saying it's "just an abstraction on top of x86," and thus doomed to fail. Likewise, Java can target JVM bytecode or Dalvik, but it is not "just an abstraction" on top of either of those. Clojure can target a dizzying array of output languages — JVM, CLR, JavaScript, Scheme, Lua, Python… It just boggles my mind that because a language compiles to JavaScript, it's "just an abstraction on top of JavaScript" or "just sugar" or whatever. Like if you took the same language with the same semantics but didn't target JavaScript as your object code, the language would become more legitimate. How is that in any way a useful view of the world? Is Clojure also just an abstraction on top of JavaScript because it can target JavaScript?
- ma2rten 14y ago
  I would go so far to say that any programming language is an abstraction over another language and/or hardware instructions. Also any API is an abstraction over another API and/or hardware instructions. EDIT: I realized that technically my first statement is not correct: Any Turing complete language can be language can be compiled to any other Turning complete programming language. So it not an abstraction, but equivalent.
chubot 14y ago
Agreed, the law of leaky abstractions is pretty brutal. When you're writing serious systems you always have to peek under the hood -- e.g. you have to reason about data structure sizes in the JVM, or check out the code that GCC outputs, or look at the Python interpreter source code. Having a bunch of monolithic magic with its own world view sitting between you and the machine is a big barrier. I'm skeptical of anything that tries to present a grand unified model. GWT is another example of where this strategy fails IMO. As noted below, CoffeeScript is a different case that illustrates the point. It seems moderately successful (I haven't used it) precisely because it's a such a modest abstraction. It aims to be a 1-to-1 with JavaScript, and keeps the semantics of JavaScript, rather than imposing its own semantics which are inevitably at odds with what browsers/servers are really doing.
- lihaoyi 14y ago
  We've heard this all before, though. 40 years ago, Machine Code was where it was it, and people scoffed at those who were lazy enough to use an assembler. Then Assembly was where it was at, and the abstraction that C provided was leaky and poor, and compiled code could never be as good as hand-written assembly coded directly against the individual processor instruction set. The problem with this argument is that it applies just as much in the two above examples as it does in this one, and it's clear that C has really taken off. Making good abstractions is damn hard, and the law of leaky abstractions is brutal, but the success of C, and even Java (a virtual machine on top of a compiler on top of a assembler on top of the machine!) shows that it can be done. I'm pretty happy I can write code in C and can't imagine worrying about things like different instruction sets, registers, L1/L2 caches, etc. just for a basic "hello world". Perhaps in the future, people will think it equally crazy that we had to worry about details like what database we use, how we serialize data over the wire, manually creating ajax endpoints, etc.. Perhaps they'll let the compiler do all this work and only dive into manually fiddle with this stuff when they need to squeeze the last 10% performance out of the system, just as C programmers sometimes drop into ASM today.
  - chubot 14y ago
    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 reality and failed (in that era, usually because it was hard to reason about performance). C is humble and makes few assumptions. "Abstraction is layering ignorance on top of reality" -- Richard Gabriel My opinion is that anything which tries to abstract network communication and make it "transparent" is going to run in to problems at scale. For some reason there is this endless desire of programmers to extend their type system across the wire. It's been tried so many times. The goal of Opa appears to be "transparency" as discussed here -- making distributed computing look like single-machine computing. This was also the goal of GWT. http://scholar.google.com/scholar?cluster=7009698499164949721&hl=en&as_sdt=0,5 http://scholar.google.com/scholar?cluster=700969849916494972... Also related: http://scholar.google.com/scholar?cluster=17011909832902326140&hl=en&as_sdt=0,5 http://scholar.google.com/scholar?cluster=170119098329023261...
novalis 14y ago
Haxe is a complete multi target compile system that just put out a service rolling server compiler. At present I do Android and C++ (both windows and linux) compiles out of it from the same code base. I really don't see how this has anything to do with Haxe or why both would be joined at the hip for longevity.

gmac 14y ago

IMHO the CoffeScript analogy is a poor one. CoffeeScript actually abstracts very little from the JS base, being mainly about a lighter-weight, more productive, more enjoyable syntax. Opa is far more ambitious in its abstraction.

chc 14y ago

By that logic, Ruby and Python are just as doomed because they're ultimately just elaborate abstractions on top of C (or at least their reference implementations are). The implementation language and output target of a programming language are not material to the language itself. C targets a wide array of machine codes, but you'd be remiss in saying it's "just an abstraction on top of x86," and thus doomed to fail. Likewise, Java can target JVM bytecode or Dalvik, but it is not "just an abstraction" on top of either of those. Clojure can target a dizzying array of output languages — JVM, CLR, JavaScript, Scheme, Lua, Python… It just boggles my mind that because a language compiles to JavaScript, it's "just an abstraction on top of JavaScript" or "just sugar" or whatever. Like if you took the same language with the same semantics but didn't target JavaScript as your object code, the language would become more legitimate. How is that in any way a useful view of the world? Is Clojure also just an abstraction on top of JavaScript because it can target JavaScript?

ma2rten 14y ago
I would go so far to say that any programming language is an abstraction over another language and/or hardware instructions. Also any API is an abstraction over another API and/or hardware instructions. EDIT: I realized that technically my first statement is not correct: Any Turing complete language can be language can be compiled to any other Turning complete programming language. So it not an abstraction, but equivalent.

chubot 14y ago

Agreed, the law of leaky abstractions is pretty brutal. When you're writing serious systems you always have to peek under the hood -- e.g. you have to reason about data structure sizes in the JVM, or check out the code that GCC outputs, or look at the Python interpreter source code. Having a bunch of monolithic magic with its own world view sitting between you and the machine is a big barrier. I'm skeptical of anything that tries to present a grand unified model. GWT is another example of where this strategy fails IMO. As noted below, CoffeeScript is a different case that illustrates the point. It seems moderately successful (I haven't used it) precisely because it's a such a modest abstraction. It aims to be a 1-to-1 with JavaScript, and keeps the semantics of JavaScript, rather than imposing its own semantics which are inevitably at odds with what browsers/servers are really doing.

lihaoyi 14y ago
We've heard this all before, though. 40 years ago, Machine Code was where it was it, and people scoffed at those who were lazy enough to use an assembler. Then Assembly was where it was at, and the abstraction that C provided was leaky and poor, and compiled code could never be as good as hand-written assembly coded directly against the individual processor instruction set. The problem with this argument is that it applies just as much in the two above examples as it does in this one, and it's clear that C has really taken off. Making good abstractions is damn hard, and the law of leaky abstractions is brutal, but the success of C, and even Java (a virtual machine on top of a compiler on top of a assembler on top of the machine!) shows that it can be done. I'm pretty happy I can write code in C and can't imagine worrying about things like different instruction sets, registers, L1/L2 caches, etc. just for a basic "hello world". Perhaps in the future, people will think it equally crazy that we had to worry about details like what database we use, how we serialize data over the wire, manually creating ajax endpoints, etc.. Perhaps they'll let the compiler do all this work and only dive into manually fiddle with this stuff when they need to squeeze the last 10% performance out of the system, just as C programmers sometimes drop into ASM today.
- chubot 14y ago
  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 reality and failed (in that era, usually because it was hard to reason about performance). C is humble and makes few assumptions. "Abstraction is layering ignorance on top of reality" -- Richard Gabriel My opinion is that anything which tries to abstract network communication and make it "transparent" is going to run in to problems at scale. For some reason there is this endless desire of programmers to extend their type system across the wire. It's been tried so many times. The goal of Opa appears to be "transparency" as discussed here -- making distributed computing look like single-machine computing. This was also the goal of GWT. http://scholar.google.com/scholar?cluster=7009698499164949721&hl=en&as_sdt=0,5 http://scholar.google.com/scholar?cluster=700969849916494972... Also related: http://scholar.google.com/scholar?cluster=17011909832902326140&hl=en&as_sdt=0,5 http://scholar.google.com/scholar?cluster=170119098329023261...

novalis 14y ago

Haxe is a complete multi target compile system that just put out a service rolling server compiler. At present I do Android and C++ (both windows and linux) compiles out of it from the same code base. I really don't see how this has anything to do with Haxe or why both would be joined at the hip for longevity.