All these languages compiling to javascript makes me think we really need a more low level language to compile to for the web. A C for the web, if you will (like how a lot of Lisp implementations will generate C to compile). Not necessarily byte-code per se, but something at a low enough level that provides enough guarantees that it can be compiled into something that performs well without the need for exotic jit compilers and so on. Javascript is not that language.
(Obviously C can't be that language for the web (NaCl possibly excluded), but when I say C, I mean in the general profile: extremely simple and maps very closely to what the hardware is actually doing)
Absolutely. I think a concatenative language would be great for this. It’d be easy to target for a wide variety of languages, statically typable if you like, amenable to analysis and optimisation, and much less inherently complex than JavaScript to parse and evaluate.
Moreover, it’d be trivial for browser authors to implement, so for a very low investment there could be a huge return. You can write a basic runtime for a full-featured concatenative language in a few hundred lines of C, and a compiler for it in a few dozen lines of Haskell.
'Ease of implementation' is a very low-ranking, I would almost say irrelevant, factor for the utility or uptake of a programming language. So what if there are only a couple of hundred lines of C, you'd still need tens of thousands at the least to provide a useful standard library.
I tend to think the usefulness of a (standard) library tend to decrease with the size of its interface. Because with more functions, it is harder to learn, harder to find the function you need, and makes programs less accessible because there are so many ways to do the same job.
My bet would be a minimal standard library, based on empirically most useful functionality. I very much doubt you'd need more than a thousand lines to implement that (not counting a possibly crap-load of optimizations).
In my experience, what matters more than the size of the interface of the standard library, is its organization. For example, I can't really read Clojure code, mainly because I have no idea what the various functions do. On the other hand, Python has a huge standard library, but usually the name of the function, in the context of the module (as in urllib2.urlopen or json.loads) or the name of the method in the context of the class of the object it belongs to (e.g. [1, 3, 2].sort()) is enough to figure out what the functionality is.
Though I wish I didn't have to type `from datetime import datetime` all the time...
It’s relevant because it’d be much easier to get the major browsers to implement a minimalistic language than another JavaScript. Simpler implementation means fewer security concerns and more time to focus on things that are directly relevant to programmer experience, such as that standard library.
In my opinion, it's a little too late. JavaScript is it. If you consider how Chrome runs some JavaScript as machine instructions then it isn't that far off from the situation you describe.
This would be interesting if the meta-language weren't JavaScript. By choosing JS as the ML, you lose static typing and type inference in the compiler and severely restrict the target platforms and future growth and metaprogramming.
I would love to see a formal specification for the language mapping Roy's syntax to a subset of JS. It would also be nice if the primary implementation were written in OCaml or Haskell. Both of these languages now have very reliable ML->JS compilers and support algebraic data types allowing you to precisely model your object language.
I would love to write Roy in a language with static typing (I'm definitely up for writing Roy in Roy).
But I think CoffeeScript has shown that in-browser compilation and execution is very useful. For example, if I wrote Roy in Haskell, I wouldn't have been able to easily write this demo site:
I will actively contribute to your language implementation and use of these tools should you adopt them. With a proper type system, you can change the world. Without a proper type system, we will all suffer and kill ourselves by a thousand cuts.
I know that compiling languages with completely different semantics to JavaScript is possible (I even maintain http://altjs.org/). But they present two problems:
1. They output to ugly JavaScript that is hard to interop with and/or people can't reason about
2. They need a huge runtime
The resultant JavaScript you linked to was ~300K.
Roy takes a different approach and tries to stay semantically close to JavaScript when possible. This is to combat both of the above problems. I'd love to see a Roy example of that demo - I imagine the JavaScript would be a lot more readable and smaller.
Please excuse me, perhaps I was not clear in my language objection. I am very excited about Roy! I am concerned about the language that you have chosen to define it in and what it means for the future of the Roy community.
> I know that compiling languages with completely different semantics to JavaScript is possible (I even maintain http://altjs.org/). But they present two problems:
> 1. They output to ugly JavaScript that is hard to interop with and/or people can't reason about
As I am suggesting that you change your metalanguage for Roy's implementation to something with stronger type safety than JavaScript, I am proposing that you increase the ability for both humans and computers to reason about it. Will you commit to implementing Roy in Roy? Will Roy offer a subset or a superset of the type system of the metalanguage (JavaScript)?
I am super-excited about having a thin, HM type system on top of JS. If I could reason about, contribute, and extend the type-checker and compiler, I would adopt Roy in a heartbeat.
> 2. They need a huge runtime
> The resultant JavaScript you linked to was ~300K.
This is not very big for a 3-D game or a compiler. Most of this is runtime and libraries (type-checked JSON, perhaps?) so application code will increase size relatively slowly.
Again, I am not advocating js_of_ocaml as a replacement for Roy. It fulfills a different role. I would love to write type-checked DOM manipulations in Roy natively and produce tiny JS or HTML!
> Roy takes a different approach and tries to stay semantically close to JavaScript when possible. This is to combat both of the above problems. I'd love to see a Roy example of that demo - I imagine the JavaScript would be a lot more readable and smaller.
Do you support persistent objects? Exhaustive case analysis and polymorphic variants? Will you be able to implement the type-checker correctly and safely in JavaScript? Will your users ever be able to compile their pure Roy code into another functional language? Even if Roy is a subset?
I think this would satisfy your objections: hopefully the core semantics are so small that writing a JavaScript version from them wouldn't be so scary.
I should try that as soon as possible. Simon Peyton-Jones has said multiple times that defining a core intermediate-language for Haskell was very important as it meant they wouldn't add things that didn't make complete sense. Working on Roy doesn't give such a strong sense.
My worry about separating the semantics out into an IR is that we might lose information that makes outputting readable JavaScript possible. But we'll never know until I try.
>> you lose static typing and type inference in the compiler
It doesn't matter what the target language is if you want to do static typing or type inference. For example, Haskell compiles down to assembly, but still has an extremely robust type system with inference and all.
>> severely restrict the target platforms and future growth
Are you serious? JavaScript is supported on every platform and is experiencing crazy growth.
You have also misunderstood my concerns. I am not making any statement regarding the choice of target or object or source language (JS, JS, Roy). I am am objecting to the choice of metalanguage (JS). Haskell compiles to assembly but is not written in assembly!
I am very serious. JavaScript is terrible for analysis and a huge waste on the server-side or mobile. Choosing JavaScript as the metalanguage for an implementation of an HM type system is strange. Why have an HM type system itself written in a type-unsafe way? Why artificially limit the analyzability of the language implementation which is pure and simply string(Roy) -> string(JS)? Roy looks like it has great potential and one of the reasons for that potential is its nascent type system. I want to take my pure Roy function library to ObjC, OCaml, C--, etc.
I think the GitHub project page is fine for someone interested in the development and the technical side of the language. The fun is at http://roy.brianmckenna.org/ =D
(Obviously C can't be that language for the web (NaCl possibly excluded), but when I say C, I mean in the general profile: extremely simple and maps very closely to what the hardware is actually doing)