Hacker News new | past | comments | ask | show | jobs | submit login

What was the motivation to start from scratch rather than compile at least a subset of Racket to JS? I imagine Pyret was a massive amount of work. Same effort could've brought Racket to the browser.

--- Big thank you to the PLT group for HTdP that introduced me to programming and PLAI class that taught me PL hacking and ultimately landed me a job writing compilers




Congrats on the job!

We've already compiled a very good chunk of Racket to JS. It's called Whalesong (http://cs.brown.edu/~sk/Publications/Papers/Published/yk-wha...). The initial version of Pyret was in fact built as a #lang in Racket, and used Whalesong to obtain an in-browser implementation.

We ran into two major problems with this.

1. It was really slow. Whalesong faithfully implements Racket, including delimited continuations and all sorts of other fun stuff. But it suffers in performance. See the paper—we went through three different implementation strategies. But for all of them, Pyret proved to be too slow.

2. We wanted an entirely in-browser experience. The earlier Pyret implementation used Racket to do initial compilation, and Racket itself is not designed to run in the browser (it depends on its own virtual machine). Though Whalesong went a long way, it could not go all the way without substantially reimplementing Racket, which is an enormous enterprise. Absent all that, we would always have to rely on a "compile server". This was an obstacle for us in a previous system (http://www.wescheme.org/) so we didn't want to repeat that experience.

Ultimately, however, bringing Racket to the browser was not what we were setting out to achieve in Pyret. Rather, we were out to build a new language based on what we've learned from (a) teaching, (b) building systems, and (c) doing various projects on scripting languages. Pyret is our attempt to condense all that experience into a language that represents our needs well (it's still a work in progress). It just so happens that one of our (externally-imposed) constraints is to run in the browser with minimal server support.

In terms of effort, Whalesong was about four years of work by primarily one person, and it's still nowhere near done (because of how big Racket is). The initial Pyret was about 1.5 person years (though some of that was also spent building a peer-review system: http://cs.brown.edu/~sk/Publications/Papers/Published/ppkf-c...). The new Pyret is about two person years, and much farther along than the original #lang-based Pyret was. Indeed, the new Pyret is solid enough to be used in several classes without noticeable problems. So no, I would not agree with your assertion that the "same effort" would have brought Pyret to the browser.


Effort stats for both Whalesong and Pyret are impressive and humbling. Manifesto actually touches the importance of tackling "assemblers" including JavaScript, so I hope someone's actively researching the problem: performant Whalesong perhaps, or an entirely different approach.


Whalesong is moribund for now. The Pyret intermediate language is actually a really good compilation target for functional languages. The problem is that Racket has a lot more stuff than Pyret (some of which are discussed in the paper, others are things like delimited continuations). There's certainly a Racket-lite that drops these features, is still a very full language, and would compile very nicely to Pyret. Anyone want to help us build that? (-:


That was my suspicion as well: there could be a very usable and rich subset of Racket that could target JS without significant performance degradation. Sidestepping the deeper darker corners like I think ClojureScript does with Clojure? Herculean effort already it becomes even more daunting when you start picking up features to drop only to discover just how much of Racket depends on say delimeted control machinery. After all Racketeers have been eating their dog food so most if not all their PL research found its way into the design. Bitten by their own success :) The manifesto takes admirably healthy stance here: problems offer opportunity for research. Alas, when u consider the time it takes to build smth like Pyret or Whalesong your pool of researchers and implementers narrows pretty much to academia. Unless of course there's some benefactor who's willing to assume the expense and allow the time




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: