5 ms·
And on that note, be sure to take a look at Pyret, another programming language designed by this group, to address some of these student-oriented programming is
by 616c 12y ago
And on that note, be sure to take a look at Pyret, another programming language designed by this group, to address some of these student-oriented programming issues.
https://github.com/brownplt/pyret-lang/ https://github.com/brownplt/pyret-lang/
It is written all in JS (using Node) and can be completely run in a web browser apparently. I am not the first one here to mention it but it is very cool.
- klibertp 12y ago> It is written all in JS (using Node) and can be completely run in a web browser apparently. Wow, I didn't know this. I thought it's another "compiler frontend" for Racket - essentially just a parens-free syntax for people allergic to Lisps. Instead it's a standalone language with self-hosted compiler and JS based runtime, which is even more impressive. The features of Pyret make it the most advanced compile-to-JS language I know of. Built in unit testing and contracts, algebraic data types, pattern matching, optional typing, immutability by default - no other altjs language provides all of them at the same time (I think). It reminds me of Cobra (http://cobra-language.com/ http://cobra-language.com/) a bit. Does it support AST-based macros? That would go way beyond awesome :) It looks like Pyret is the result of some 20 years of work on PLT Scheme/Racket - most of the good and advanced parts of Racket but without any historic cruft. It's very impressive. I think it will need some time to mature, but I can totally see myself using it in production one day.
- 616c 12y ago> Wow, I didn't know this. I thought it's another "compiler frontend" for Racket - essentially just a parens-free syntax for people allergic to Lisps. Instead it's a standalone language with self-hosted compiler and JS based runtime, which is even more impressive. You know, I was really surprised too. I had just assumed it was another language compiled out with a Racket compiler like Arc or a specialized subset learning languages built into Racket, like one of the Schemes (I mean like the lang/rsr6 or lang/plai) that are a subset for study. Keep in mind though, after reading this article, I read the mailing list and it appears they just finishing up a functional CLI REPL. It could be fun, but they are still working on the basics of making it fun for neckbeards, who would prefer, by way of stereotype, their terminals and REPLs. At least that is what I am waiting for. https://groups.google.com/forum/?_escaped_fragment_=topic/pyret-discuss/dOLiVXtUdxQ#!topic/pyret-discuss/dOLiVXtUdxQ https://groups.google.com/forum/?_escaped_fragment_=topic/py...
- shriramkmurthi 12y agoThanks! Why don't you get on the announcement list (http://www.pyret.org/discuss/ http://www.pyret.org/discuss/) so you'll find out when the CLI is ready.
- jpolitz 12y ago(I'm a Pyret core designer/developer.) Pyret started its life as a #lang, which was delightful as a prototyping tool. The demands of running with reasonable performance in a browser led us to switch to a direct-to-JS approach, and we haven't looked back since. The original Pyret-to-JS compiler has been up and running for around a year now; we're still learning how to improve and tune its performance, but it's proven quite robust. No macros are planned, though it's not set in stone that they'll never happen. Just not a priority, and not something that Pyret's use in classrooms has caused huge demand for. Pyret does indeed have a number of Racket's good ideas in it (especially from the teaching languages, and especially with respect to testing), along with a few new ones. However, I'd like to temper the comment "most of the good and advanced parts of Racket..." A number of Racket's advanced features, for example #lang and powerful macros, the super-expressive class/mixin/trait system, and OS-level resource management, aren't things that Pyret handles right now, and won't come right away. Pyret's development will continue to be driven by classroom usage and curricular demands first, so it eschews, for example, the "everything should be in the language" part of Racket's manifesto. That's just a case of differing goals, which means that if you're, say, prototyping a new language from scratch, it will likely always be a safe bet to do it in Racket rather than in Pyret. (But if you're prototyping an algorithm over algebraic datatypes and want a web-based editor to try it out, just hop on over to https://code.pyret.org/editor https://code.pyret.org/editor and dive in.) As a note on where we're maturing to, Pyret will accommodate gradual typing to mix static and dynamic checking of annotations, which is an area of active development, and something that Typed Racket is pioneering. Another thing we're thinking hard about is native JavaScript interop, to bring the lovely libraries of the Web to Pyret programmers, without forcing beginners to grok the intricacies of JS and the browser's evaluation model.
- 616c 12y agoThanks for your work in the Racket world. Thanks for Pyret too, I just do not use it ... yet. I check out your site often enough bc your work comes up a lot here. I am curious how are you typically advising (Brown?) students to use this. I have a work computer, Windows 7, and 8GB of RAM with SSD disk and running Firefox 38.02a Developer Edition. After disabling NoScript, it took somewhere 2-3 mintues to run. This is an improvement over my last attempt, which crashed my browser a few months back, and I did not try it sense. Is this normal? Did kids have trouble loading it up in class on less powerful commodity machines, or is there something messed up with my laptop in particular? It is super impressive you have a whole PL toolchain in browser, but does this not actually cause a barrier for your kids? I know I am a FOSS/terminal/off-the-net type and an outlier, but not having offline access would be a bummber to me. Granted, I will evenutally get around to attempting to compiling the different compiler phases on my personal laptop, bc I do not want to do Node on Windows right now. Haha. Still, I wish tools like this were around when I had to learn in C++ in uni, as running g++ on a Solaris box helped me along in my eventual love of Unix environments, but really distracted me with a focus on tools and less on theory and real experimentation with languages. Somewhere in between was later use of Python and REPLs. I can see why hardcore instructors like yourselves argue for Schemes, because the early focus on interactive REPLs does indulge a certain curiosity and playfulness that would have really helped me consider CS earlier in life. Again, I am not sure if inverting the order (start with theory, then focus on tools) would have made a difference in the end, but you NEU and Brown Racket guys have shown some real intensive work on CS and PL pedagogy. Thanks for your work. I browse your books often and I hope your passion continues to rub off on me. :-)
- shriramkmurthi 12y agoWe 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-resuarging/ 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.
- shriramkmurthi 12y agoFirst 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.
- klibertp 12y agoCobra compiles to CIL and runs on Mono/.Net runtimes. I think its philosophy is close to Pyret: they both seem to be taking the best ideas from different languages and trying to integrate them into one nice package. There are some similarities in features chosen, but I'm not working with either, so I can't do a deeper comparison.
- shriramkmurthi 12y agoThe 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://www.wescheme.org/, http://cs.brown.edu/~sk/Publications/Papers/Published/yk-whalesong-racket-browser/ 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!
- brudgers 12y agoThe features of Pyret make it the most advanced compile-to-JS language I know of. ClojureScript is pretty sophisticated since it is considered production ready for commercial work and leverages much of Clojure's ongoing library development directly. https://github.com/clojure/clojurescript/wiki https://github.com/clojure/clojurescript/wiki Not to take anything away from Pyret.
- shriramkmurthi 12y agoIt'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!).
- brudgers 12y agoI think the PLT group does amazing work in general and in education in particular. The well designed teaching languages hide complexity while providing power for expressing important concepts. And nobody makes installing a full blown IDE and versatile tool chain easier for beginners. My emphasis was on an a Blub->JS alternative for production. I am not sure Pyret is a priority alternative for a green field project due to the language's intended purpose and the directions in which that purpose is likely to drive and not drive its development and tooling. That is to say that features are likely to flow Pyret->Clojure faster than Clojure->Pyret.
- shriramkmurthi 12y agoAbsolutely. 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.
- acjohnson55 12y agoI read about that a couple years ago when I saw it on the front page. It's a really beautiful language, and a lot of work seems to have gone into forgetting crufty patterns that don't serve newcomers to programming. It's a real breath of fresh air!