5 ms·

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 h

by 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.
- 616c 12y ago
  Yeah, because those like me who mooch off of the free and open brilliance of Racket (I mean, except for paying for a copy of Realm of Racket, but that is indirect; the author has a Scheme/Lisp crush like me, but we all know that goes back to community enthusiasts and not Racket itself) get to write blog posts on the official blog while we navel gaze. You clearly contribute enough to talk semi-officially even, so thank you for your work. :-) Jokes aside, maybe I am just conflating you academic creds with other NEU/Brown people, but maybe it is just the blog post. Your last name reminded me of Racket when I saw it; not sure why though. Kudos to your group, or just you personally, for recommending Chromium, and NOT Chrome. I work for a university IT department, and our inventory confirms even after lecturing co-workers, I am the only one to have installed it on Windows laptops, or even Mac or Linux if you can believe the latter. Mostly everyone has no idea you can download the FLOSS fork of Chrome without the nasty proprietary bits. In the future, it would be cool to see you guys package a more focused IDE with the rage, node-webkit or nw.js or whatever is called now. You guys seem like a great example of a lang that could shine here, much like Dr. Racket is a pretty wonderful example of the robustness of Racket (although I still prefer Geiser myself). I also see shriramkmurthi talks about university requirements about minimal install and configuration overhead. This is a great, if not just good, thing. Again, as a university IT guy thank you. However, I still have mixed feelings. I worked for kids in a very spoiled institution with expensive new laptops, complete with full admin control for students. I get my fair share of novice programmers install a full Stata stack for the econometrics class, and along with professors, hose a 4GB or 8GB RAM laptop which "needs more drive space and RAM because my 1GB CSV dataset is so big." We tell them to write tighter code and they are incensed (seriously had students demand a more expensive version because one version of Stata had an arbitrary limit of variables in a given program, IIRC correctly, and the group of students and professors were told to us less variables, less than 60,000! I cannot imagine production distributed systems code needing that many, haha). So, I bring up that last anecdote as a warning. I would love to help any way I can. Damned with compiled binary LLVM and Java toolchains that need admin privs and 10GB of space for library source and various dependencies, also damned with in-browser JS bootstrapped compilers that sit on an increasingly over-generalized OS in an OS. How do you plan to handle the abstractions moving further and further away from the metal? I assume this is to teach programming basics only, right? Like Racket is, kind of? Do you worry about pushing this farther down into systems programming, or are you staying focused? I do not intend to call out or criticize one way or the other, just curious to pick your brains.

by 616c 12y ago

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.

616c 12y ago
Yeah, because those like me who mooch off of the free and open brilliance of Racket (I mean, except for paying for a copy of Realm of Racket, but that is indirect; the author has a Scheme/Lisp crush like me, but we all know that goes back to community enthusiasts and not Racket itself) get to write blog posts on the official blog while we navel gaze. You clearly contribute enough to talk semi-officially even, so thank you for your work. :-) Jokes aside, maybe I am just conflating you academic creds with other NEU/Brown people, but maybe it is just the blog post. Your last name reminded me of Racket when I saw it; not sure why though. Kudos to your group, or just you personally, for recommending Chromium, and NOT Chrome. I work for a university IT department, and our inventory confirms even after lecturing co-workers, I am the only one to have installed it on Windows laptops, or even Mac or Linux if you can believe the latter. Mostly everyone has no idea you can download the FLOSS fork of Chrome without the nasty proprietary bits. In the future, it would be cool to see you guys package a more focused IDE with the rage, node-webkit or nw.js or whatever is called now. You guys seem like a great example of a lang that could shine here, much like Dr. Racket is a pretty wonderful example of the robustness of Racket (although I still prefer Geiser myself). I also see shriramkmurthi talks about university requirements about minimal install and configuration overhead. This is a great, if not just good, thing. Again, as a university IT guy thank you. However, I still have mixed feelings. I worked for kids in a very spoiled institution with expensive new laptops, complete with full admin control for students. I get my fair share of novice programmers install a full Stata stack for the econometrics class, and along with professors, hose a 4GB or 8GB RAM laptop which "needs more drive space and RAM because my 1GB CSV dataset is so big." We tell them to write tighter code and they are incensed (seriously had students demand a more expensive version because one version of Stata had an arbitrary limit of variables in a given program, IIRC correctly, and the group of students and professors were told to us less variables, less than 60,000! I cannot imagine production distributed systems code needing that many, haha). So, I bring up that last anecdote as a warning. I would love to help any way I can. Damned with compiled binary LLVM and Java toolchains that need admin privs and 10GB of space for library source and various dependencies, also damned with in-browser JS bootstrapped compilers that sit on an increasingly over-generalized OS in an OS. How do you plan to handle the abstractions moving further and further away from the metal? I assume this is to teach programming basics only, right? Like Racket is, kind of? Do you worry about pushing this farther down into systems programming, or are you staying focused? I do not intend to call out or criticize one way or the other, just curious to pick your brains.