Why I have high hopes for Roy
Michael Lorton
- the language, by itself, is sufficient to write the entire webapp;
- the language is strongly and statically typed, ideally with strong type inference;
- if the language is compiled, that compiler is written in itself;
- the language is well-connect to the browser-DOM, to HTTP as a client and as server, and to databases, both SQL and NoSQL;
- the language has a workable debugger.
(1) is the big one. Basically, webapp development teams tend to fracture into the Javascript guys, the backend guys, and the ops guys, each with their own language, their own tests, their own tools. While you'll never eliminate the need for different skills, having one language that works everywhere is a big step in that direction.
(1) necessarily implies (at least for the foreseeable future) that the language either be Javascript or be compilable into Javascript. There are three billion web-browsers installed out there and they all run Javascript. I can install Node.js or V8 or something on my server.
(2) I think is obvious. Without strong static typing, you're just crossing your fingers when it comes to reliability. Incredibly thorough testing can make up for dynamic typing, although I would rather not do something stupid than do something stupid and be caught reasonably soon.
(3) might be controversial. Some people like (or at least don't dislike) a development environment where every user has an identical parallel universe of IDE, continuous compiler, etc. Personally, I find that means that every time I bring someone knew on the team, there's three days of set-up while they download and configure everything, and two days every time you get a new computer. If the compiler runs on the browser, all you need are Git credentials, Chrome, and your favorite editor. (If my facts are correct, this requirement excludes Fay.)
Roy covers (1) and (2) easily. Someone told me Brian is re-writing the compiler. I hope he is re-writing in Roy, it's the right thing to do. Even if not, I'll count it as passing (3) because it serves the purpose: I can compile on the browser.
(4) I assume is no big deal. (5), I understand, is on the way with SourceMap support.
Once Roy is "there" -- and it's close right now-- I have about 20 projects I'd like to do in it.
Dirk Detering
Hello together,
First of all: would it be possible to put a tag like [roy] into the subject line of mails from this list?
It is the only list I get mails from that are not distinguishable from direct mails by looking at the subject.
Now to the topic:
Am 21.12.2012 03:38 schrieb "Michael Lorton" <mich...@gablit.com>:
> Over the summer, a friend and I made a list of the requirement for the perfect language for web development. They were
> the language, by itself, is sufficient to write the entire webapp;
> the language is strongly and statically typed, ideally with strong type inference;
Interesting. While I support this last requirement, it is interesting to watch what happens in the Dart area, where the designers believe that optional typing may be a good thing.
I never found a real debate between the camps so far.
Otherwise it seems that your requirements match with that of the Dartisans.
Preferring Roy over Dart would then be a more general debate between FP and modern OO:
* Structural typing vs. Classes
* type classes vs interface/implementation/inheritance
* overall functional thinking vs imperative plus a bit of FP
* not so popular haskell like syntax vs. another C heir.
> if the language is compiled, that compiler is written in itself;
> the language
This seems more an internal thing. E.g. running ghc on a windows machine is an exe. Doesn't matter if this is a compiled haskell, C, C++ or whatever.
> is well-connect to the browser-DOM, to HTTP as a client
> and as server, and to databases, both SQL and NoSQL;
> the language has a workable debugger.
>
> (1) is the big one. Basically, webapp development teams tend to fracture into the Javascript guys, the backend guys, and the ops guys, each with their own language, their own tests, their own tools. While you'll never eliminate the need for different skills, having one language that works everywhere is a big step in that direction.
>
> (1) necessarily implies (at least for the foreseeable future) that the language either be Javascript or be compilable into Javascript. There are three billion web-browsers installed out there and they all run Javascript. I can install Node.js or V8 or something on my server.
>
But OTOH if the language is _only_ usable by compiling to JS, you are fixed to node.js/V8 and the properties of the target language. Especially on server side a dedicated VM seems to make absolutely sense.
This is an enormous plus of Dart.
> (2) I think is obvious.
That is an opinion not shared by everyone. So this point _is_ controversial.
>Without strong static typing, you're just crossing your fingers when it comes to reliability. Incredibly thorough testing can make up for dynamic typing, although I would rather not do something stupid than do something stupid and be caught reasonably soon.
>
This is an interesting field of debate, and I am eager to follow discussions here. (I definitely like Scala, so you can assume where I am positioned ;-) ).
> (3) might be controversial. Some people like (or at least don't dislike) a development environment where every user has an identical parallel universe of IDE, continuous compiler, etc. Personally, I find that means that every time I bring someone knew on the team, there's three days of set-up while they download and configure everything, and two days every time you get a new computer. If the compiler runs on the browser, all you need are Git credentials, Chrome, and your favorite editor. (If my facts are correct, this requirement excludes Fay.)
>
That the compiler is written in itself doesn't necessarily make compiling in the browser a good thing. So this seems at least partly orthogonal to me.
> Roy covers (1) and (2) easily. Someone told me Brian is re-writing the compiler. I hope he is re-writing in Roy, it's the right thing to do. Even if not, I'll count it as passing (3) because it serves the purpose: I can compile on the browser.
>
> (4) I assume is no big deal. (5), I understand, is on the way with SourceMap support.
>
> Once Roy is "there" -- and it's close right now-- I have about 20 projects I'd like to do in it.
So "there" means: the mentioned topics are solved?
For me "there" would contain more things:
Mainly: when compiling to JS is a requirement, very good integration of the languages is a must. It is essential to be able to use any JS library and call any JS API easily. I had at least one issue a while ago, IIRC related to JS object literals.
Beside that: good libraries for the language itself, a good module concept, a package manager, IDE support (syntax highlighting et al). A coherent and informative main website, tutorials and documentation.
For professional/business scenarios: a strong community with a critical mass of users and a foreseeable future for the language, best a company behind it, ensuring that the language isn't bound to the health of its designer.
So as fascinating as Roy is, for me it remains a thing of personal interest. In its current state I would not even try to convince anyone in my company to use it for some serious tasks. But I hope it will find more people interested in it in the future, perhaps see even some killer app?
KR
Det
Maxime Lévesque
> languages is a must. It is essential to be able to use any JS library and
> call any JS API easily.
JavaScript, it is a
severe handicap to not play nice with existing JS libs.
I don't know how well Roy does in that area, I'm just an observer that
wish I had
strong typing on the JS platform but didn't have the time to play with Roy.
I'm pretty sure however that in order to satisfy the "play nice with
existing libs"
criteria, there must be a way to escape the type system when interfacing with
other libs, in other words some form of "optional typing" is required
to "play nice with other".
One necessary condition for "playing nice" is to not have to write a
wrapper for objects from
external libs.
Cheers
Michael Lorton
But OTOH if the language is _only_ usable by compiling to JS, you are fixed to node.js/V8 and the properties of the target language. Especially on server side a dedicated VM seems to make absolutely sense.
This is an enormous plus of Dart.
That the compiler is written in itself doesn't necessarily make compiling in the browser a good thing. So this seems at least partly orthogonal to me.
For professional/business scenarios: a strong community with a critical mass of users and a foreseeable future for the language, best a company behind it, ensuring that the language isn't bound to the health of its designer.
So as fascinating as Roy is, for me it remains a thing of personal interest. In its current state I would not even try to convince anyone in my company to use it for some serious tasks. But I hope it will find more people interested in it in the future, perhaps see even some killer app?
Maxime Lévesque
> that everyone uses it always.
> And I'm not particularly open to disagreement on this one. I've used
> dynamically typed languages for 20 years and I know the problems they cause.
> The only authentic problem of statically typed language -- its comparative
> verbosity -- can be largely address by smart type inference.
analyzing a program to
detect as many errors as possible is a huge win.
As with any engineering problem, one has to make a cost vs benefit
analysis. Static typing is a gain, but not being able to utilize existing libs
adds to the costs, so is writing wrappers.
Optional typing requires that the programmer make a conscious decision
every time he "cheats" on the type system, like when invoking an external lib,
and knowing that it can return any possible junk. If he were to write
a type safe wrapper, no extra safety would be gained, since the external
loosely typed lib has no enforcement on what it can return.
I don't see it as a question of if type safety is beneficial, I
strongly believe it is.
The question is, how can one get the maximum benefits of type safety
writing for a
platform where every thing is written in a loosely typed, and incur
the minimum cost.
Maxime Lévesque
allows the programmer to discard type checking, it is a
form of optional typing. Odersky et al. are not finding optional
typing a useless option...
I think I have read somewhere that Roy does has an
"type system escape" mechanism, it might just be what
is needed to "play nice" with existing JS libs.
Dirk Detering
Am 21.12.2012 21:21 schrieb "Michael Lorton" <mich...@gablit.com>:
>
> First, wasn't "Dirk Detering" the secret identity of the first Green Arrow?
>
What?
>> But OTOH if the language is _only_ usable by compiling to JS, you are fixed to node.js/V8 and the properties of the target language. Especially on server side a dedicated VM seems to make absolutely sense.
>> This is an enormous plus of Dart.
>
> Meh. What do you get from a dedicated VM? Maybe a performance improvement. If it works, great; if not, also fine.
>
Maybe I am wrong here, but beside performance due to more specific runtime knowledge about the types (without compile tricks) and other meta stuff, also more dedicated memory management, monitoring, more direct runtime support for low level APIs, esp. concurrency and parallelisation concepts come to my mind.
The VM can do meta stuff that is otherwise compiled as additional bloat into the target language.
Am I wrong here?
And: I consider performance on server side always a win.
Michael Lorton
On Saturday, December 22, 2012 2:52:42 AM UTC-8, Dirk Detering wrote:
Am 21.12.2012 21:21 schrieb "Michael Lorton" <mich...@gablit.com>:
> First, wasn't "Dirk Detering" the secret identity of the first Green Arrow?What?
Maybe I am wrong here, but beside performance due to more specific runtime knowledge about the types (without compile tricks) and other meta stuff, also more dedicated memory management, monitoring, more direct runtime support for low level APIs, esp. concurrency and parallelisation concepts come to my mind.
And: I consider performance on server side always a win.
Brian McKenna
> Over the summer, a friend and I made a list of the requirement for the
> perfect language for web development. They were
>
> the language, by itself, is sufficient to write the entire webapp;
> the language is strongly and statically typed, ideally with strong type
> inference;
> if the language is compiled, that compiler is written in itself;
> the language is well-connect to the browser-DOM, to HTTP as a client and as
> server, and to databases, both SQL and NoSQL;
> the language has a workable debugger.
a pretty good start.
> (1) is the big one. Basically, webapp development teams tend to fracture
> into the Javascript guys, the backend guys, and the ops guys, each with
> their own language, their own tests, their own tools. While you'll never
> eliminate the need for different skills, having one language that works
> everywhere is a big step in that direction.
>
> (1) necessarily implies (at least for the foreseeable future) that the
> language either be Javascript or be compilable into Javascript. There are
> three billion web-browsers installed out there and they all run Javascript.
> I can install Node.js or V8 or something on my server.
on your phone, your desktop and (possibly) your servers. It achieved
Java's #1 goal without even having it as a goal.
The lucky language.
> (2) I think is obvious. Without strong static typing, you're just crossing
> your fingers when it comes to reliability. Incredibly thorough testing can
> make up for dynamic typing, although I would rather not do something stupid
> than do something stupid and be caught reasonably soon.
actually form a proof. Testing is a "for some" relationship where
types form a "for all". I prefer the latter when I need correctness.
> (3) might be controversial. Some people like (or at least don't dislike) a
> development environment where every user has an identical parallel universe
> of IDE, continuous compiler, etc. Personally, I find that means that every
> time I bring someone knew on the team, there's three days of set-up while
> they download and configure everything, and two days every time you get a
> new computer. If the compiler runs on the browser, all you need are Git
> credentials, Chrome, and your favorite editor. (If my facts are correct,
> this requirement excludes Fay.)
haven't gotten around to it but it should just be a couple of lines to
get the following working:
<script src="roy.js"></script>
<script language="text/roy">
console.log "Hello world!"
</script>
Now, installing GHC isn't usually a huge task, but it can't really get
much easier than above, right? :)
> Roy covers (1) and (2) easily. Someone told me Brian is re-writing the
> compiler. I hope he is re-writing in Roy, it's the right thing to do. Even
> if not, I'll count it as passing (3) because it serves the purpose: I can
> compile on the browser.
>
> (4) I assume is no big deal. (5), I understand, is on the way with
> SourceMap support.
>
> Once Roy is "there" -- and it's close right now-- I have about 20 projects
> I'd like to do in it.
Take a look at the roadmap I just published:
https://github.com/pufuwozu/roy/wiki/Roadmap
Hopefully we'll see Roy 1.0 by end of March.
Thanks for your interest!
Brian McKenna
Without any compiler flags, when Roy encounters something it doesn't
know about, it will implicitly coerce it into the type it needs. For
example, Roy doesn't know about "document", "console" or any of their
properties:
let brian = document.getElementById "brian"
console.log (brian.getAttribute "name")
Those identifiers get assigned variables which unify with whatever
they need to be unified against. I'm going to add a compiler flag to
disable that behavior. If you want to write code that interops with
JS, then use the default mode. If you have written a "safe" wrapper,
disable the coercion behavior.
This can also be a way of enforcing purity! Write the IO monad, write
wrappers around JS which return IO and disable the coercion (via the
flag) for modules which you want to be pure. Almost sounds too easy.
For people that are on the "easy" side, you get unsafe by default. I
don't want to call it "optional typing" because there's no way to
disable type inference and checking.
For people that are on the "correctness" side, you get safety in a
couple of senses, once you enable a flag.
What do people think of this behavior?
Maxime Lévesque
>
> Without any compiler flags, when Roy encounters something it doesn't
> know about, it will implicitly coerce it into the type it needs. For
> example, Roy doesn't know about "document", "console" or any of their
> properties:
>
> let brian = document.getElementById "brian"
> console.log (brian.getAttribute "name")
>
> Those identifiers get assigned variables which unify with whatever
> they need to be unified against. I'm going to add a compiler flag to
> disable that behavior. If you want to write code that interops with
> JS, then use the default mode. If you have written a "safe" wrapper,
> disable the coercion behavior.
something in Roy against a very JS centric stack, a good pick would be :
http://meteor.com
http://angularjs.org
that would probably be the most difficult stack for a JS based language
to "play nice" with. The fact that you have a MongoDB in the mix
(meteor's back end),
makes it even harder. It's important to test against a worst case scenario.
Angular/meteor is pretty much a worst case, but at the same time
AngularJS is a brilliant lib, it is IMO the state of the art of client side
dev.
Playing nice with others in the JS world is probably the most
difficult challenge
for a typesafe language, and there are no existing solutions to copy from
(well, there would be typescript, but to follow this route you have to
be a superset of JS,
then you loose the interesting parts of Roy)
Typescript does have an interesting way to benefit from statical
analysis while "playing nice"
with others, interfaces can be defined for any lib :
https://github.com/rarous/AngularJS-TypeScript/blob/master/Angular.d.ts
https://github.com/soywiz/typescript-node-definitions
such an interface is much easier to write than a wrapper, so it is a
superior alternative IMO.
The fact that typescript interfaces for every major JS lib have been
contributed in such a short time is a proof of this.
A counter example would be GWT : how many GWT wrappers exist for JS
libs after years of existence ?
Wrappers are just too hard to write.
I have the impression that Roy could do something clever for inter
operability, unfortunately it's just an
intuition, so not very valuable.
I am convinced however that a good solution is more likely to be found
while trying to write Roy code
against a "difficult to play with" stack, like angularJS/meteor.
I do think that Row is already a brilliant piece of software and I
really wish it can meet the inter operability challenge.
Where would Scala be today if it did not inter operate with Java as
well as it does ?
--Max
Michael Lorton
Definitely. JavaScript is the only platform that is everywhere. It's
on your phone, your desktop and (possibly) your servers. It achieved
Java's #1 goal without even having it as a goal.
The lucky language.
I disagree that testing can make up for dynamic typing.
Static types
actually form a proof. Testing is a "for some" relationship where
types form a "for all". I prefer the latter when I need correctness.
Now, installing GHC isn't usually a huge task, but it can't really get
much easier than above, right? :)
> Someone told me Brian is re-writing the
> compiler. I hope he is re-writing in Roy, it's the right thing to do.
I agree it's the Right Thing to Do but sadly, not possible at the moment.
> Once Roy is "there" -- and it's close right now-- I have about 20 projects
> I'd like to do in it.
And I have about 50 :)
Hopefully we'll see Roy 1.0 by end of March.
Michael Lorton
Without any compiler flags, when Roy encounters something it doesn't
know about, it will implicitly coerce it into the type it needs.
What do people think of this behavior?