For some time, I've daydreamed about implementing R in Racket ("Arket"?) as a means of shining a flashlight in all the dark corners of my R knowledge. Then I realize this would take me a heap of time and it goes back to being a daydream.
The Racket Manifesto
31–40 of 51 posts
Re: The Racket Manifesto
#32Earlier quoted context omitted.
(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…
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…
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.
Re: The Racket Manifesto
#33Earlier quoted context omitted.
The problem with Lisp-like DSL construction, is that the interface doesn't play well with many populations of domain experts. Even Smalltalk, with its syntax designed to be usable by children can fulfill the technical side of constructing DSLs easily, but still leaves something to be desired when it comes to domain expert use. (Various Smalltalks had their rough equivalent to #lang.) (I know there is at least one Rub…
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…
I really liked the following article, which creates a text adventure language in Racket that looks like this:
===PLACES===
---desert---
"You're in a desert."
[cactus, key]
north start
south desert
Re: The Racket Manifesto
#34Earlier quoted context omitted.
Thank you, that is good to know. Also, please know that I am sincerely grateful for all of your work. Without the software and materials that you and your team labored to create -- and which you provide freely -- I might not be a professional programmer today.
Wow, thanks. I passed this remark on to the rest of the team. Totally made our day!
I'm teaching my kids how to program using the 2nd edition because it's the introduction to programming that I always wish I had received. They love it! Thanks.
Re: The Racket Manifesto
#35Earlier quoted context omitted.
> 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 l…
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.
Cobra 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.
Re: The Racket Manifesto
#36Earlier quoted context omitted.
I 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 du…
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 pro…
I think tooling is only theoretically surmountable under the current incarnation of PLT and its culture [and I am not saying that this is a bad thing because that culture is extremely valuable].
By which I mean that PLT culture does not spin off the right tooling in the right direction relative to typical production operations. Racket works well with DrRacket and sorta with Emacs: compare Geiser or Hendershott's M-x racket-mode to Cider. Good luck finding out of the box integration of Racket with Eclipse, Visual Studio etc.
The reasons include, I think, the fact that consultants on mutli-million dollar contracts are not going to start with Racket. This means that 1000 hours building a tool for Eclipse that saves 10% on a $4,000,000 contract never happens. What happens instead, and it is a good thing, is that people tend write tools that solve the problems of academia, including implementation of research topics at one end and producing well formatted text on the other, and of course pedagogy on the third end [maths are not my strength, apparently].
As an example, listening to the Flatt interview, the sub-module system makes sense. The extra level of indentation for namespace construction though feels kludgey from a typing code into a box perspective because top-level concepts from the perspective of the enclosing namespace are indented - I look and ask myself, did I miss a right-banana?: The sub-module syntax is at odds with the core principles of pretty-printing as a tool. That sort of design engineering isn't a priority for PLT [and I am not saying it should be, only that it makes moving out of education less likely].
Re: The Racket Manifesto
#37The book How to Design Programs [1], with its "student languages", is an excellent example of how languages created with Racket can be used to achieve specific goals (or solve specific problems). In the book's case, the goal is to provide a programming environment for explaining and exploring a successively refined software design recipe. Also, the Manifesto and Racket's documentation (and HtDP) are written in Scribb…
I can't praise HtDP enough (disclaimer: I've only done through chapter 4 of the first edition). Still, what I did was sufficient to fundamentally change me as a programmer. When I first began learning how to program I started off with Python using some courses on Udacity. But somehow I found HtDP (I think via HN) and it really taught me, well, how to design programs. It also made thinking functionally my default mode…
Oh my yes. I've half played with the idea of aping it for beginning R programmers, replacing some of the examples with suitably analogous data-y examples.
Book has definitely improved my coding.
Re: The Racket Manifesto
#38Earlier quoted context omitted.
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…
I really liked the following article, which creates a text adventure language in Racket that looks like this: ===PLACES=== ---desert--- "You're in a desert." [cactus, key] north start south desert http://queue.acm.org/detail.cfm?id=2068896
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.)
Re: The Racket Manifesto
#39For some time, I've daydreamed about implementing R in Racket ("Arket"?) as a means of shining a flashlight in all the dark corners of my R knowledge. Then I realize this would take me a heap of time and it goes back to being a daydream.
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.
Re: The Racket Manifesto
#40Earlier quoted context omitted.
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.
Cobra 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.
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!