shriramkmurthi

I agree! We're acutely conscious of it. This is precisely where, as you note, the education focus puts our resources elsewhere. Once those things settle down, this is something we're going to want very much even for ourselves.

Good question!

The compiler is definitely the main application that's been written. We're not aware of any standalone Pyret applications on the order of more than a few KLOC, but those are quite different in flavor, like course infrastructure.

The next largest chunk of Pyret code out there is assignments for various courses and curricula, which are our major users and macro-scale test cases. In fact, this is a useful perspective on what we get feedback from: a broad and shallow set of use cases in education. This leads us to focus on the first-time use cases, especially on the first time seeing an error message, the first time writing a test, the English vocabulary that lines up with explaining code to a number of different audiences (especially at different age levels), and the snags and inconsistencies in syntax in even extremely short programs.

Of course, it's been _used_ by plenty of students and their teachers, who have written now thousands of their own interpreters and video games and graph algorithms and image-generation programs and type-checkers and data structures in Pyret.

Finally, the design of Pyret is intentionally conservative. Pyret is not a research experiment in some particular new and untested language feature; in fact, such features are almost by definition kept out of the language. Therefore, we believe we're building on a long tradition of crisp, clear language definitions inspired by the lambda-calculus, with little by way of weirdness or frippery.

I'm really delighted to hear your boss's daughter is having so much fun. That's a great outcome.

I don't expect everyone using Pyret to turn into a professional programmer. In fact, I don't want everyone to do so, because the world also needs electrical engineers and materials scientists and poets and painters and plumbers and everything else. So I'm not out to create a planet full of nothing but nerds (in your sense).

But I do think computing is a fundamentally different way of approaching problems. It is not universal, and even where it applies, it is not the only approach. But it's a powerful and new one. I still think nobody has put it better than Abelson and Sussman, who called this “procedural epistemology”. I would like as many people as possible to have access to this epistemology.

Bringing computing to a wide population requires designing something that works for them. I don't claim we have the perfect answer; maybe assembly would work well too, though I have serious doubts (but hey, there's an easy way to prove me wrong: I'm not standing in anyone's way…).

Over a decade ago, long before “big data” was a thing, I created a course called “Introduction to Computing for Humanities and Social Sciences” that was essentially an intro to big data. It's been a very successful course at Brown, and part of its successes, I believe, was my stubborn adherence to teaching the first month entirely in Excel. That attracted, retained, and empowered a whole group of students who by their own admission did not dream of taking computing.

So, the tool does make a difference. Pyret is a tool to tackle our goals. We as a discipline are in the midst of a huge explosion of computing education interest in many countries. A lot of these are _losing track_ of who they are for and what it takes to get there [http://cacm.acm.org/blogs/blog-cacm/200936-qualify-your-quan...]. That's a problem we're deep in the midst of trying to address, and Pyret is central to how we are going about it. Others who think they can get to “all” [modulo the above article] can and will take other bets. It's all good so long as they are actually clear about their goals and then honestly evaluate them later.

Good question re. Web Assembly. The problem is we need much more than tail calls. Just as important is deep stacks, to enable a _functional_ style of “functional programming”. And that has definitely been a headache. Our current (clever) implementation strategy actually gives us tail calls as a consequence of the deep stacks, using a variant of Henry Baker's "Cheney on the MTA" (for those old enough to remember that) combined with the "stack reconstitution" technique we published in ICFP a decade ago [http://cs.brown.edu/~sk/Publications/Papers/Published/pcmkf-...] and a few other things. But tail calls by themselves wouldn't be enough.

What _could_ we use help with? Obviously, we could use infrastructure help or porting to “platforms” (e.g., a REPL on top of Node), but those are huge commitments and require a lot of special knowledge. But I think a person with only a little time can still help.

Right now, I feel the language is still a bit impoverished. We want to make it really easy to get working with data, and that's still too hard. But pretty soon we're going to be putting out better support for tabular data manipulation. Actually use it to do some fun things with data; share your successes (when things work) and your experiences (when they don't)!

Thanks. This is where our “education first” emphasis comes in. I'd like that too, but it's just not our most critical need. Since it can be run on top of Node from a shell, what it mainly lacks is a REPL. One of our students took a shot at that and had half an implementation, but didn't finish it. So for someone interested in hacking on that, there is a starting point, and a REPL atop Node would a big win. I'd use it every day (-:.

We started out as a Racket `#lang`. That is in principle always an option. However: the in-browser support is non-negotiable. We have many users in schools, which have very locked-down machines. Many of them cannot install new software. This is a real obstacle for many curricula, and our ability to run just off the browser has been a huge prerequisite for adoption of Bootstrap's [http://www.bootstrapworld.org/] curricula.

No. I think the best illustration is the continuation-based Web programming work we did several years ago: http://cs.brown.edu/~sk/Publications/Papers/Published/khmgpf... If you don't have the right underlying language (in this case, with continuations), you _can't_ have a similar API. Similarly, the reactive APIs we had in Flapjax [http://cs.brown.edu/~sk/Publications/Papers/Published/mgbcgb...] enabled entirely new kinds of primitive “library” operations; see, for instance, the drag-and-drop example in that paper.

There's absolutely nothing in Pyret forcing you to write `where` blocks with immediate tests. You can also put your tests in a `check` block, which can float anywhere, and in another module.

What we find valuable is to write a _small_ number of _illustrative_ examples, which we call the “sweep”, that summarize the main behavior of the function. Think of it as essential, runnable documentation. When you come to a new codebase (including your own, six months later!), these help you quickly page back in what the function was supposed to do.

The sweep is also really useful for peer-review, which is another especially valuable technique in both education and industry. We have done some nice studies on its effectiveness: http://cs.brown.edu/~sk/Publications/Papers/Published/pcgfk-...

The official AE site is here: http://www.artifact-eval.org/ . It details the process and the design behind it. People who want to understand the philosophy are welcome to contact me (http://cs.brown.edu/~sk/).

The continuation-based libraries are the simplest, easiest, quickest way to get a program off the ground. They make interactive Web programming just as easy as writing “scanf” or its equivalent, _and_ are safe in the face of various browser interactions. Therefore, they're a good default for prototyping. However, I agree that they also have issues, and the documentation should not over-emphasize them, but rather indicate what they are suitable for and what not and make clearer to readers a transition path out of there.

Racket and Python aren't even remotely comparable as languages. Python is a far less sophisticated language with far richer libraries, and Racket is vice versa.

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? (-:

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.

By the way: Racket is not at all for "programming basics only". Racket, the language, is as rich a programming language as you'd like. Even the Racket team's pedagogy is wide-ranging, from middle-schools to introductory collegiate to upper-level programming languages to graduate-level programming language research.

Calling out and criticism is fine! But to answer your question: for the foreseeable future, our "metal" is JavaScript, so that's what we will be finding ways to expose. We have already designed our stack mechanism to enable decent JS interop (e.g., no CPS). We want to make it possible to import JS libraries without hurting security, for instance. We've got some students right now working on integrating graphing and other functionality that we'd like to make widely usable.

The platform is a pretty big difference. One of the major problems we run into in the education space is that many schools _cannot_ install any new software. Running on the browser is pretty much the only thing they can do. We created WeScheme (http://www.wescheme.org/, http://cs.brown.edu/~sk/Publications/Papers/Published/yk-wha...) precisely for this reason, and Pyret is also engineered around this need. If you require a compiler and/or runtime download/install, you are excluding yourself from numerous schools, _especially_ poorer ones. We're really concerned about not amplifying these problems!

Look at how we've structured the semantics of JavaScript, Python, etc. (E.g.: http://cs.brown.edu/~sk/Publications/Papers/Published/pclpk-..., http://cs.brown.edu/~sk/Publications/Papers/Published/pmmwpl..., http://cs.brown.edu/~sk/Publications/Papers/Published/gsk-es...). This is how you should go about creating a core of R, followed by an elaboration from the full language into the core. Steal an existing parser to get ASTs, then most of your time goes into desguaring.

Scribble is another great example. It's amazing in its own right, and by being embedded into Racket, gets all the Racket benefits: for instance, separate compilation! (Thirty years and waiting, LaTeX.)

This is a criticism of Lisp-based DSLs but not of Racket-based DSLs. Racket actively enables you to impose different, non-parenthetical surface syntaxes on the DSL. It is not a "this sort of works if you arrange it carefully _and nobody screws anything up_" thing like in Ruby, it really is an explicit language definition.

The easiest way to understand this in action is to read about Danny Yoo's Brainfuck embedding in Racket: https://www.hashcollision.org/brainfudge/

Absolutely. To be honest, we don't want Pyret to stay in the "education cellar" forever. But, we need a set of coherent design constraints, and education is a good one because it prevents premature cruft.

The current stack treatment is pretty elaborate for pedagogic reasons. There's absolutely no reason we can't just turn it off for programmers who are willing to write short-running computations, for instance (as production developers are willing to do)—that would be a "#lang"-style configuration. The tooling would, of course, be the bigger issue.

Overall, I'm happy for all good altjs projects. The core Pyret team burnt their fingers on a lot of aspects of JavaScript and see clearly its difficulties for education and even for development.

By the way, this is one of the reasons we're putting a lot of effort into JS interop. This isn't really important for education but it is for development—and in particular, development for education.

Go with Chrome, Safari, or IE 10 for now. There's a very complicated interaction with how Firefox handles the stack.

Wow, thanks. I passed this remark on to the rest of the team. Totally made our day!

Thanks for the kind comments. Sorry to hear about the crash, etc. We haven't gotten many reports about this; if you could file a bug report the next time (https://github.com/brownplt/pyret-lang/issues/new) we'd appreciate it! [But Firefox is _really problematic_ for various reasons. That may be half the issue.]

Pyret's compiler is actually written in Pyret itself, so that it can run entirely offline. Once you have the initial page (which could be offline), you can literally turn off all networking and continue to work forever. Of course, saving files is then a problem—but I actually do this when I'm on planes (I copy my code to another file to backup).

The _first_ load is indeed a bit of a problem. We're looking into various ways to reduce that. However, you should not have had delays on any subsequent runs. We have students in other universities, and even high schools, using it, so I don't think there's anything Brown-specific at work here. So I'm afraid it may be something to do with your particular laptop )-:.

It's awesome in its own way. Our emphasis was on

• allowing arbitrarily deep call stacks (e.g., deep recursion)

• allowing computation to be interrupted

• turning async interfaces into sync ones

This means you can't just compile altjs function calls to JavaScript function calls. That's the work that @jpolitz is referring to. The last we checked, ClojureScript did not address these issues as well (though it does other awesome things!).

Butterick is _awesome_. Thanks for calling this out!

Thanks! Why don't you get on the announcement list (http://www.pyret.org/discuss/) so you'll find out when the CLI is ready.

First time I'm seeing Cobra. Of course, there's a 100 altjs languages out there. It's certainly cute. But every Cobra file seems to begin with "class". I have no idea why I'd want to subject a poor child to that nonsense.

Just to be clear, the flip side of Racket's 20 years of work is it is _very sophisticated_. Pyret has nowhere near the same sophistication.

We have long-term plans for integrating some kind of rewriting system. Justin Pombrio is doing really interesting work in this direction (e.g., http://cs.brown.edu/~sk/Publications/Papers/Published/pk-res...). We are rethinking what it means to be “hygienic”, so it'll be a while, probably. But it's a thing we're taking very seriously.

Indeed, the first edition is draggy at the beginning. The second edition is meant precisely to dive right in and get cracking, without sacrificing any principles. I recommend people read the second edition instead of the first one. [Why should you trust me? My name's on the cover. <-;]

To _Racket's_ logo.