This obsession with boiling everything down to strings of symbols is how folk wind up making fun of Perl and OCaml.
What's this do?
$$&[%]
Or this?
?:>
Buggered if I know. Only a professional Perl or OCaml programmer could tell you -- and indeed I made those up. Only a professional Perl or OCaml programmer could tell if they do anything at all.
But pretty much anyone from any language background can eyeball an Algol-family syntax and tell you what's going down.
I wonder why you got OCaml involved... from my experience, OCaml is one of the cleanest languages known, sure there are a few special symbols and operators, like :=, :: and +., but there are relatively few, so you just learn them like you would in any other language (e.g. C has ?:, == and ++).
Sure, OCaml allows you to specify new operators, but the rules are pretty simple, and you cannot arbitrarily fuck up the syntax.
I must be, but here's how I remember it (bearing in mind that memory is faulty).
A few years ago I took a unit in my comp sci degree, "Programming Paradigms". The language used for teaching was F#, which is heavily inspired by OCaml. At one point we were given readings on OCaml programs and a particular operator popped up -- something like "is subtype of", I fail to recall exactly -- and it looked like :>? or :?> or similar.
I bitched loudly in the unit forum about this operator, whereupon the professor politely informed me that he, in fact, had invented that little bit of syntax when he was a PhD student at INRIA.
He didn't flunk me! Dr Rowan Davies, still the most scary-smart computer scientist I've met.
I haven't ever seen that in OCaml. Probably an F# extension.
If you're going to complain about OCaml's syntax, I would start with having to use different arithmetic ops for int vs. floating point (+ vs. +.) and different indexing operators for strings and arrays ( s.(0) vs. s.[0] ).
You get used to it pretty quickly, and OCaml more than makes up for it in other ways, but it is a bit annoying.
He mentioned that he did a bunch of work object-system work on Caml that was published, but the INRIA guys didn't put it into the main version when they developed OCaml. It's possible it got transmitted into F# that way. Next time I see him I'll ask about it.
On rereading, I realized this might give a false impression. OCaml does allow the user to define an operator, but a confluence of the type system (which doesn't allow overloading and makes abstracting types sufficiently difficult that it doesn't justify the minor syntactic nicety of a custom operators) and precedence rules means that most OCaml code you'll see does not use a lot of weird operators like you'll find in advanced Haskell code. I'm not an OCaml guru, but that's what I've seen.
Not OCaml per se, but at least one F# library makes liberal and very effective use of custom operators: FParsec, Stephan Tolksdorf's parser combinator library (http://www.quanttec.com/fparsec/reference/primitives.html). Of course, FParsec is adapted from the Haskell Parsec library, so maybe that just makes your point for you!
> But I love OCaml, I don't why it isn't more hacked/forked.
Because it has a fucked-up licence - you're not allowed to "fork" it in the usual sense of the word, you can only distribute the original source, and your modifications in a patch. The "free-for-all" licence is only available to commercial users.
That's quite a bit of an exaggeration in this case. Look at the simple syntax for OOP or default argument values. That's a lot of cruft removed compared to Lua. The less you need to read the better, as long as it's readable.
Hi, I'm the author. You're right about the resemblance to CoffeeScript. I added some recognition at the bottom. Thanks for pointing it out, I just got the site up within the last hour so there are still finishing touches to be made.
I am curious about why didn't you just implement the CoffeeScript syntax outright? Learning just one syntax would make it easier for people wanting to deploy to JavaScript and to Lua.
Imagine that C on the PDP-11 had a slightly different syntax from C on x86, and the syntax were different from that on C on ARM, etc.
Wow, yeah. I wouldn't complain personally, since I love CoffeeScript syntax, but it is pretty odd that it's not mentioned at all. Edit: As seen above, it's mentioned now, so I'm happy :)
It's still a little irritating that they've changed things that CS handles quite elegantly to be less expressive, presumably just out of a desire to be different. I understand changes to the syntax are necessary for various reasons, but something like ! for argumentless function calls instead of () just seems like needless divergence. Was that extra character really killing you? Is the confusion with other meanings of ! really worth it?
Indeed. It also saddens me that it does not stick to CS conventions - lots of extra cruft ( the ! for zero-arity method invocation -- instead # for comments etc )
Are you actually claiming that "#" is a computer science convention for comments? It's not used in C, C++, Fortran, Lua, or many other languages. For example, comments in OCaml are ( * ... * ) (I've put extra spaces to thwart HN's formatting.
Language using "--" for comments include Lua and Haskell.
You've made me curious - what languages to you use/know that make you think "#" is a "CS convention" for comments?
Further edit: In response to the clarification that CS meant CoffeeScript and not Computer Science (nor the riot control gas), the point, I guess, then follows other commentators, who observe that Lua, to which this compiles, uses "--".
But you're after the right point— the languages are bash, Perl, Python, Ruby. It's a scripting language convention, hence why CoffeeScript adopted it over JavaScript's `//`, hence the confusion as to why MoonScript didn't.
In all honesty, what's the point of this? I understand the point of compiling to JavaScript simply because that's the only language that runs on the most ubiquitous platform in the world. Why compile to any other high-level language?
Are there so many similar places where users are forced to use Lua, to warrant an extra layer? (with all the complexities such as debugging, a compile step, tracing errors back to MoonScript code, etc)
Note, I'm not commenting about the language's choices. Maybe coding in MoonScript rocks big time. I just don't get why it compiles to Lua.
I can understand your doubt. After writing a decent amount of Lua I really started to notice it lacking succinct ways to express things that I've become used to in other languages.
So I wrote the language for myself to use, but I've opened it up for other people because I think there is some potential for it. The use case for MoonScript is the same as the use case for Lua.
Also I have done a lot of mitigate the pains of compiling and debugging. It's actually pretty seamless, I've done stuff like automatic code compilation on require, and error line number rewriting. I urge you to check out the documentation: <http://moonscript.org/reference/#moonscript_api>;
Lua wins for in-game scripting and embedded devices. In these places, it's Lua, or hacking onto the C/C++ engine/framework code. Or, now, MoonScript with some extra fuss. Mind, Lua isn't terrible, so I think I'd stick to Lua and avoid the fuss. But others will disagree.
It'd make more sense to me if it were compiling a very different kind of language, such as a Constraint/Logic programming language. I really like Lua for scripting, as-is.
Lua's portability & smooth C integration make it an interesting code generation target (not to mention LuaJIT's performance). And however you feel about working in Lua, its code is straightforward to generate - the syntax is refreshingly free of odd corner cases.
It is odd the designer decided to compile to lua. It's probably because it's easier to knock out the language fast that way. Although usually when someone wants to do this they compile to C and use gcc from there (this is what go did in the beginning), but they also usually admit this is a hack, not a feature and that they will later compile directly to assembly.
Lua is significantly faster than most dynamic languages (LuaJIT is faster than most static languages as well), and the Lua runtime is small, portable, flexible and easily embeddable. Creating a runtime from scratch with these properties would be difficult, while targeting Lua makes it nearly free.
Many languages compile to an intermediate format of some kind. The complexities you cite are easily be hidden. MoonScript already makes compiling and error traceback invisible, and I expect direct debugging of MoonScript files will be doable at some point as well.
This is the first I've heard of MoonScript, but I've long wondered why more languages don't use Lua as a target.
I think it being difficult to read is entirely subjective. I don't know Haskell, and if I were to look at the code for a Haskell project I wouldn't understand it, but that doesn't mean that those who use it find it difficult to read.
After writing the majority of the compiler in MoonScript itself, and some other scripts, I've actually grown to like it and I find it perfectly readable. More readable than Lua in fact, because half of the text on my screen isn't the keyword `local` :). Try it out, if you code Lua then I think you might like it.
If this compiles into Lua/JIT bytecode then there might be a use for it, if this transforms into Lua code then what is the point? Lua is a great and simple language, so this would seem useless
Not everyone thinks that Lua is great. It's certainly a nice language, and it's popular in some niches, but some people like implicit variable declarations, classes (at times), and comprehensions.
Also, I can see it compiling into JavaScript as well. I'm not sure if that would be a good idea, or a really horrible one, though.
'Lua bytecode' does not really exist -- i.e. it has no public definition -- the developers can change it in any way at any time -- only the Lua language itself is 'defined'.
Lua's compiler adds very little overhead, compared to loading directly from luac's precompiled bytecode. It has a really fast, single pass compiler, which is optimized for reading in data serialized as Lua tables. Lua was designed with JSON-like use cases in mind.
Its compiler doesn't do much analysis / optimization, but the performance of individual Lua constructs is usually easy to reason about.
What's the point of locking yourself to a bytecode when Lua code JITs just fine on LuaJIT? Lua is a great language and this looks like another alternative. I doubt we're looking at exclusion here.
Very cool. I confess I'm not likely to use it anytime soon, since I am conversant with how Lua works today and not so much with Coffeescript, but I'm glad for the aid to adoption!
> If only objc would remove the square brackets (and stay true to smalltalk), the syntax would be so much nicer:
Objective C is (or at least it used to be, not sure ATM) a strict superset of C. One of the ways this is achieved is through having orthogonal syntax for the smalltalk-ish bits compared to classic C.
This looks very promising. Congrats on the launch.
I am enjoying this wave of new programming languages that compile down to existing ones in a human readable way. They are pleasant to write and read and yet performant and don't require a special runtime, making them easy to integrate anywhere in their parent language.
I hope someone talented will build one of these for C/C++. Mobile an game developers could use it.
Lua is fast as scripting languages go, but saying it's in the same performance ballpark as native code is a stretch [1]. Game developers that use Lua commonly rely on C/C++ for low level routines.
There's a space for innovation there. ooc [2] has been a step in that direction, although its usage of garbage collection makes it much less flexible than CoffeeScript or MoonScript. I don't think developers need to be abstracted from memory management at low level. What they could use is getting rid of a lot of cruft, to be able to write/read/think more quickly.
Still don't understand the fad for "programmer-friendly" languages. Why on earth would you even start learning to program if you didn't find something diabolically fascinating about learning a new syntax for symbolic computation?
C, C++, APL, etc. all seem perfectly "programmer-friendly" to me, once you've learned them...
No one said it wasn't. The author claims that MoonScript is programmer friendly, but he never said that Lua isn't. It's an alternative, but not necessarily an improvement.
Some of this is a definite improvement over Lua, but I'm getting really tired of some of these cute little syntaxes showing up everywhere, like '->' and '=>' for creating functions, and what's with this:
! operator can be used to call a function with no arguments
Seriously?
I feel like people are coming up with these things just to be "different". Programming language syntax is a UI, and needs to be treated like one -- you don't make major changes to basic UI paradigms without convincing reason.
Edit: Maybe more to the point, you don't add random buttons to a UI that do non-obvious things. Language syntax should be self-evident and quickly readable, and shouldn't require careful parsing of individual characters.
If this were somebody's toy or research language, I wouldn't be complaining, but when a language is clearly being marketed as something people would want to use in the real world, I expect it to be based on real evidence and real experience, not just somebody playing around.
It's human readable as far generated code goes. It's not always practical to read (specially with classes), but you can if you have to. It's one of the philosophies behind CoffeeScript. As you can see its translation of OOP is verbose too, but readable [1], and the verbosity of the generated code is balanced by the power added on the CoffeeScript side.
My point/question was: it doesn't add a runtime or new libraries/routines, you can read the generated code if something goes wrong, so why wouldn't it be ok to use in production?
"Nice" is relative, I think the site is a colorblind monstrosity (it actually looks better when I invert the colors!), but someone clearly put some effort into it, as well as the reference manual, and there is no indication given anywhere that it should be treated as anything other than a serious entry into the world of production programming languages.
On the contrary, at the very top of the page, albeit in extremely poor contrast, it says "A programmer friendly language". That certainly implies the author considers it to be good for something other than "playing with new syntax".
It's simple, predictable and easy to read.
This obsession with boiling everything down to strings of symbols is how folk wind up making fun of Perl and OCaml.
What's this do?
Or this? Buggered if I know. Only a professional Perl or OCaml programmer could tell you -- and indeed I made those up. Only a professional Perl or OCaml programmer could tell if they do anything at all.But pretty much anyone from any language background can eyeball an Algol-family syntax and tell you what's going down.