4 ms·

(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 p

by 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 ago
Thanks 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 ago
  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 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 )-:.
  - 616c 12y ago
    Don't worry, I recognized your name from the PAPL book and I think some Racket stuff. But anyway, I know who you are. :-) If I get it to crash again, I will definitely contact you and file a bug report. I guess the self-hosting compiler blurb on the GH repo did not really hit me. I will definitely try it offline and give it a whirl. So what is the recommended browser then?
    - shriramkmurthi 12y ago
      Go with Chrome, Safari, or IE 10 for now. There's a very complicated interaction with how Firefox handles the stack.
- jpolitz 12y ago
  Thanks for the feedback. (EDIT: I should note that my only substantial contribution to Racket proper is bug reports and one blog post. I'm mostly just a fanboy.) The load problem definitely doesn't jive with my experience, so I'd like to hear about it if it happens again. I do a lot of Pyret work on a many years-old Acer Aspire Timeline X, and the slowest loads (in powersaver mode) take 25ish seconds. The lab machines my students work on take about 5-10 seconds, their laptops differ widely in (guessing a bit here) the 5-30s range, and many do work on their laptops. Students are somewhat annoyed by the load time, but this is actually not out of the ballpark for how long it takes, say, DrRacket to start (just now it took 5s on my lab machine, ~11s on my piddly laptop). So in our experience it hasn't been prohibitive, but that doesn't mean there aren't classes of machine/browser combinations that screw it up that I don't know about. I recommend Chrom[e|ium] to my class at Swarthmore (Chromium is installed by default on department machines here), though Safari and modern IE (IE10+) have worked totally fine in practice, too. Firefox has some unfortunate interactions with the way Pyret does stack management that can make it really slow. I do have a few students who stick by Firefox and do all their work in it, despite the slowdown, so it's not unusable for them, but it is annoying. For some assignments I do imports from Google Drive for black-box support code, and that requires connectivity, so I've gotten some minor complaints from students doing a lot of air travel (for e.g. job and grad school interviews) about that. But my students are used to having some assignments that require access to machines in the department, so it isn't a huge deal. With a Chrome App, or even just upcoming standards like ServiceWorkers, we should start to be able to cache enough/do more in the browser to make this a non-issue, even across tabs closing and browser restarts. There's more we could be doing right now with localStorage to get around this, even, but just haven't done the engineering required. So no fundamental obstacles to a better offline experience for the browser-based editor, "just" substantial engineering work. The CLI and packaging up Pyret as an installable "binary" (really a JS blob + Node) are works in progress, but having a good CLI repl is an explicit goal.

by jpolitz 12y ago

616c 12y ago

Thanks 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 ago
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 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 )-:.
- 616c 12y ago
  Don't worry, I recognized your name from the PAPL book and I think some Racket stuff. But anyway, I know who you are. :-) If I get it to crash again, I will definitely contact you and file a bug report. I guess the self-hosting compiler blurb on the GH repo did not really hit me. I will definitely try it offline and give it a whirl. So what is the recommended browser then?
  - shriramkmurthi 12y ago
    Go with Chrome, Safari, or IE 10 for now. There's a very complicated interaction with how Firefox handles the stack.
jpolitz 12y ago
Thanks for the feedback. (EDIT: I should note that my only substantial contribution to Racket proper is bug reports and one blog post. I'm mostly just a fanboy.) The load problem definitely doesn't jive with my experience, so I'd like to hear about it if it happens again. I do a lot of Pyret work on a many years-old Acer Aspire Timeline X, and the slowest loads (in powersaver mode) take 25ish seconds. The lab machines my students work on take about 5-10 seconds, their laptops differ widely in (guessing a bit here) the 5-30s range, and many do work on their laptops. Students are somewhat annoyed by the load time, but this is actually not out of the ballpark for how long it takes, say, DrRacket to start (just now it took 5s on my lab machine, ~11s on my piddly laptop). So in our experience it hasn't been prohibitive, but that doesn't mean there aren't classes of machine/browser combinations that screw it up that I don't know about. I recommend Chrom[e|ium] to my class at Swarthmore (Chromium is installed by default on department machines here), though Safari and modern IE (IE10+) have worked totally fine in practice, too. Firefox has some unfortunate interactions with the way Pyret does stack management that can make it really slow. I do have a few students who stick by Firefox and do all their work in it, despite the slowdown, so it's not unusable for them, but it is annoying. For some assignments I do imports from Google Drive for black-box support code, and that requires connectivity, so I've gotten some minor complaints from students doing a lot of air travel (for e.g. job and grad school interviews) about that. But my students are used to having some assignments that require access to machines in the department, so it isn't a huge deal. With a Chrome App, or even just upcoming standards like ServiceWorkers, we should start to be able to cache enough/do more in the browser to make this a non-issue, even across tabs closing and browser restarts. There's more we could be doing right now with localStorage to get around this, even, but just haven't done the engineering required. So no fundamental obstacles to a better offline experience for the browser-based editor, "just" substantial engineering work. The CLI and packaging up Pyret as an installable "binary" (really a JS blob + Node) are works in progress, but having a good CLI repl is an explicit goal.