5 ms·

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

by 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.
- shriramkmurthi 12y ago
  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.
  - 616c 12y ago
    Very cool, Well, I am still very much intrigued. This has been one of the most fruitful HN conversations I have had. Frankly, JS is metal is not my cup of tea, but I really like where your heads are at, so I will start reading PAPL and really playing with this. Thanks for something beautiful.
- shriramkmurthi 12y ago
  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.
  - 616c 12y ago
    Hmm, I should rephrase. That was, not so ironically, an over-simplification of what I mean. When I say basics, I mean you guys get to core CS principles and notions, not basic in the simpleton sense. I see Racket as a very impressive extension of SICP wizardry, and not just the #lang/sicp. I mean building an extensible series of interoperable Lisp and non-Lisp languages for so many disciplines and domain-specific requirements is a ridiculous, daunting. PLT/Scheme Racket is something I stumbled upon when I started to research "Scheme, but modern and coherent" and "natively compiling Clojure." I have been nothing but impressed with the return to basics means building blocks for everything, from advanced GUI toolkit and continuation based web servers. I wish more people were in the Racket community to light my way with more libraries, but that is really just my laziness.

by jpolitz 12y ago

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.

shriramkmurthi 12y ago
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.
- 616c 12y ago
  Very cool, Well, I am still very much intrigued. This has been one of the most fruitful HN conversations I have had. Frankly, JS is metal is not my cup of tea, but I really like where your heads are at, so I will start reading PAPL and really playing with this. Thanks for something beautiful.
shriramkmurthi 12y ago
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.
- 616c 12y ago
  Hmm, I should rephrase. That was, not so ironically, an over-simplification of what I mean. When I say basics, I mean you guys get to core CS principles and notions, not basic in the simpleton sense. I see Racket as a very impressive extension of SICP wizardry, and not just the #lang/sicp. I mean building an extensible series of interoperable Lisp and non-Lisp languages for so many disciplines and domain-specific requirements is a ridiculous, daunting. PLT/Scheme Racket is something I stumbled upon when I started to research "Scheme, but modern and coherent" and "natively compiling Clojure." I have been nothing but impressed with the return to basics means building blocks for everything, from advanced GUI toolkit and continuation based web servers. I wish more people were in the Racket community to light my way with more libraries, but that is really just my laziness.