Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Racket Manifesto

ccs.neu.edu

Post reply on HN
Print view View original

41–50 of 51 posts

Re: The Racket Manifesto

#41

Post by 616c »

jpolitz wrote: post #32
616c wrote: post #14

Earlier quoted context omitted.

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 machine…

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.

Re: The Racket Manifesto

#42

Post by shriramkmurthi »

616c wrote: post #41
jpolitz wrote: post #32

Earlier quoted context omitted.

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 machine…

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 than…

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.

Re: The Racket Manifesto

#43

Post by shriramkmurthi »

616c wrote: post #41
jpolitz wrote: post #32

Earlier quoted context omitted.

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 machine…

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 than…

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.

Re: The Racket Manifesto

#44

Post by 616c »

shriramkmurthi wrote: post #42
616c wrote: post #41

Earlier quoted context omitted.

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 than…

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 o…

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.

Re: The Racket Manifesto

#45

Post by 616c »

shriramkmurthi wrote: post #43
616c wrote: post #41

Earlier quoted context omitted.

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 than…

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.

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.

Re: The Racket Manifesto

#46

Post by zeRusski »

shriramkmurthi wrote: post #27
brudgers wrote: post #24

Earlier 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…

What was the motivation to start from scratch rather than compile at least a subset of Racket to JS? I imagine Pyret was a massive amount of work. Same effort could've brought Racket to the browser.

--- Big thank you to the PLT group for HTdP that introduced me to programming and PLAI class that taught me PL hacking and ultimately landed me a job writing compilers

Re: The Racket Manifesto

#47

Post by matthewflatt »

brudgers wrote: post #36
shriramkmurthi wrote: post #27

Earlier quoted context omitted.

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…

On the subject of tools: I'd like to clarify that Scribble was not designed to solve academic text-formatting problems; it was designed for Racket documentation. It's fair to say that we subsequently improved Scribble in academic-friendly paper- and book-writing directions, but like so much of what the current Racket developers do, it was motivated by programmer experience rather than academic tasks or credit. The current developers can only work so fast, but I hope Racket continues to attract more contributors who build more tools.

On the topic of parentheses and submodules: I can understand why some consider parentheses to be an obstacle, but I'm puzzled that you've singled out their use for submodules. Syntactic forms in `#lang racket` use parentheses, and I think they've worked well in practice for submodules. That said, submodules are most powerful when you don't use them directly and instead use (or create) constructs that are implemented as submodules. For the example you have in mind, a new syntactic form may well fit better --- and maybe should be one of the many constructs that are available out of the box.

Re: The Racket Manifesto

#48

Post by shriramkmurthi »

zeRusski wrote: post #46
shriramkmurthi wrote: post #27

Earlier quoted context omitted.

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…

What was the motivation to start from scratch rather than compile at least a subset of Racket to JS? I imagine Pyret was a massive amount of work. Same effort could've brought Racket to the browser. --- Big thank you to the PLT group for HTdP that introduced me to programming and PLAI class that taught me PL hacking and ultimately landed me a job writing compilers

Congrats on the job!

We've already compiled a very good chunk of Racket to JS. It's called Whalesong (http://cs.brown.edu/~sk/Publications/Papers/Published/yk-wha...). The initial version of Pyret was in fact built as a #lang in Racket, and used Whalesong to obtain an in-browser implementation.

We ran into two major problems with this.

1. It was really slow. Whalesong faithfully implements Racket, including delimited continuations and all sorts of other fun stuff. But it suffers in performance. See the paper—we went through three different implementation strategies. But for all of them, Pyret proved to be too slow.

2. We wanted an entirely in-browser experience. The earlier Pyret implementation used Racket to do initial compilation, and Racket itself is not designed to run in the browser (it depends on its own virtual machine). Though Whalesong went a long way, it could not go all the way without substantially reimplementing Racket, which is an enormous enterprise. Absent all that, we would always have to rely on a "compile server". This was an obstacle for us in a previous system (http://www.wescheme.org/) so we didn't want to repeat that experience.

Ultimately, however, bringing Racket to the browser was not what we were setting out to achieve in Pyret. Rather, we were out to build a new language based on what we've learned from (a) teaching, (b) building systems, and (c) doing various projects on scripting languages. Pyret is our attempt to condense all that experience into a language that represents our needs well (it's still a work in progress). It just so happens that one of our (externally-imposed) constraints is to run in the browser with minimal server support.

In terms of effort, Whalesong was about four years of work by primarily one person, and it's still nowhere near done (because of how big Racket is). The initial Pyret was about 1.5 person years (though some of that was also spent building a peer-review system: http://cs.brown.edu/~sk/Publications/Papers/Published/ppkf-c...). The new Pyret is about two person years, and much farther along than the original #lang-based Pyret was. Indeed, the new Pyret is solid enough to be used in several classes without noticeable problems. So no, I would not agree with your assertion that the "same effort" would have brought Pyret to the browser.

Re: The Racket Manifesto

#49

Post by zeRusski »

shriramkmurthi wrote: post #48
zeRusski wrote: post #46

Earlier quoted context omitted.

What was the motivation to start from scratch rather than compile at least a subset of Racket to JS? I imagine Pyret was a massive amount of work. Same effort could've brought Racket to the browser. --- Big thank you to the PLT group for HTdP that introduced me to programming and PLAI class that taught me PL hacking and ultimately landed me a job writing compilers

Congrats on the job! We've already compiled a very good chunk of Racket to JS. It's called Whalesong ( http://cs.brown.edu/~sk/Publications/Papers/Published/yk-wha... ). The initial version of Pyret was in fact built as a #lang in Racket, and used Whalesong to obtain an in-browser implementation. We ran into two major problems with this. 1. It was really slow. Whalesong faithfully implements Racket, including delimit…

Effort stats for both Whalesong and Pyret are impressive and humbling. Manifesto actually touches the importance of tackling "assemblers" including JavaScript, so I hope someone's actively researching the problem: performant Whalesong perhaps, or an entirely different approach.

Re: The Racket Manifesto

#50

Post by shriramkmurthi »

zeRusski wrote: post #49
shriramkmurthi wrote: post #48

Earlier quoted context omitted.

Congrats on the job! We've already compiled a very good chunk of Racket to JS. It's called Whalesong ( http://cs.brown.edu/~sk/Publications/Papers/Published/yk-wha... ). The initial version of Pyret was in fact built as a #lang in Racket, and used Whalesong to obtain an in-browser implementation. We ran into two major problems with this. 1. It was really slow. Whalesong faithfully implements Racket, including delimit…

Effort stats for both Whalesong and Pyret are impressive and humbling. Manifesto actually touches the importance of tackling "assemblers" including JavaScript, so I hope someone's actively researching the problem: performant Whalesong perhaps, or an entirely different approach.

Whalesong is moribund for now. The Pyret intermediate language is actually a really good compilation target for functional languages. The problem is that Racket has a lot more stuff than Pyret (some of which are discussed in the paper, others are things like delimited continuations). There's certainly a Racket-lite that drops these features, is still a very full language, and would compile very nicely to Pyret. Anyone want to help us build that? (-:
Post reply on HN