8 ms·

Rebuilding Racket on Chez Scheme Experience Report [pdf]

98 points by hencq 7y ago

hencq 7y ago
Very cool to see that this is getting ready for prime time. It seems they succeeded in achieving the primary goal of making the implementation more maintainable and easier to work with. But the lesser goal (or perhaps non goal, but something some people might have secretly hoped for) of inheriting some of Chez's speed hasn't really panned out (yet).
darkpuma 7y ago
> "The main Racket distribution now consists of roughly 1.2M lines of Racket (including 270k lines of documentation source), but that code is still supported by roughly 200k lines of C. Large parts of Racket’s implementation remain in C only because the original interpreter was in C, and all of that C code is relatively difficult to maintain." For context, cloc says that Chez Scheme has ~100k lines of scheme code and 16k of C (plus 15k of C headers.) I didn't know Chez was that much smaller than racket/base; that's pretty cool. 16k instead of 200k is a huge difference.
- dleslie 7y ago
  I think that is fair to say that Chez is something of a marvel; though gambitc/gerbil is nipping at its heels.
threepio 7y ago
I've been hearing nothing but good things about Racket for the last few years. I finally downloaded it last month. It really just puts a silly smile on your face. The language-oriented programming is terrific too. I really want to find ways to integrate Racket into my work.
- gnulinux 7y ago
  > I really want to find ways to integrate Racket into my work. Normally engineers search for tools to solve their problems. Somehow, when it comes to programming languages, software engineers start a search for problems for their cute tools. Please don't get me wrong, I'm not making a snarky comment against lisp. I'm very much in love with lisp, but I do understand how people see us lisp people like bunch of gray wizards in some remote castle. What needs to be shown is a set of problems that can adequately be solved by racket that cannot be solved as well with competing languages. We should really stop treating programming languages anything other than tools. I use GNU grep for 20 years, one day I realize ripgrep is better, I switch. Again, I want to underscore that I'm not saying that particularly disagrees with you. I just don't think this rhetoric is helpful. We should be thinking about what makes racket that puts a smile on our face, and discuss whether we can use these tools in other languages. Not that this is not being discussed, of course.
  - waterhouse 7y ago
    What do you think of this line of thought: This tool is not currently the best, but because of its design, it has the potential to become the best tool with some refinement (which may consist of improving the tool itself, your own understanding of it, or its integration into your development processes)—specifically, there exists some cutoff period T where, if you're using the tool for shorter than T, then the "current best practice" tool is better, but if you're using it for longer than T, then the payoffs from your favored tool exceed the costs of the refinement. Then it's a matter of (a) one's estimate of T and (b) one's planning horizon. This generates the hypothesis that a developer's desired planning horizon may be "the rest of my career", which is likely to be longer than the planning horizon of whatever project the developer is being paid to work on.
  - darkpuma 7y ago
    Have you ever heard the expression "When all you have is a hammer, every problem looks like a nail"? The phenomenon you're describing is definitely not a unique characteristic of developers. It's a general trait of people that when they learn something cool, they look for opportunities to use it.
  - threepio 7y ago
    > What needs to be shown is a set of problems that can adequately be solved by racket that cannot be solved as well with competing languages I thought the piece "Why Language-Oriented Programming? Why Racket?" covered that question pretty well. https://news.ycombinator.com/item?id=19232068 https://news.ycombinator.com/item?id=19232068 Perhaps there's another modern programming language that can do these things as easily as Racket. I haven't come across it, however.
  - trabant00 7y ago
    > Normally engineers search for tools to solve their problems. Somehow, when it comes to programming languages, software engineers start a search for problems for their cute tools Most of the tools I now use to do my work (devops) I found just playing around with them out of curiosity. Yes, when doing work you should start with the problem and then search for the right tool, but it's a lot better to have wide arrays of tools in your belt than starting to tour the shops after the deadlines are set. I don't want to be condescending but I find it hard not to given the obvious catch-22 in your line of reasoning. Even more so as this trope is posted quite often.
- agumonkey 7y ago
  Wonder how many people wrote translator to output python|javascript|java ?
- openfuture 7y ago
  You can look at the biggest DSLs in Racket for tools that solve specific problems (sort of responding to sibling here). I think Racket is probably the best tool for writing static sites for example (using pollen).
rurban 7y ago
I would recommend either a change to lazy jit compilation, or dumping the jitted image, for the startup-time problem.

98 points by hencq 7y ago

Very cool to see that this is getting ready for prime time. It seems they succeeded in achieving the primary goal of making the implementation more maintainable and easier to work with. But the lesser goal (or perhaps non goal, but something some people might have secretly hoped for) of inheriting some of Chez's speed hasn't really panned out (yet).

darkpuma 7y ago

> "The main Racket distribution now consists of roughly 1.2M lines of Racket (including 270k lines of documentation source), but that code is still supported by roughly 200k lines of C. Large parts of Racket’s implementation remain in C only because the original interpreter was in C, and all of that C code is relatively difficult to maintain." For context, cloc says that Chez Scheme has ~100k lines of scheme code and 16k of C (plus 15k of C headers.) I didn't know Chez was that much smaller than racket/base; that's pretty cool. 16k instead of 200k is a huge difference.

dleslie 7y ago
I think that is fair to say that Chez is something of a marvel; though gambitc/gerbil is nipping at its heels.

threepio 7y ago

I've been hearing nothing but good things about Racket for the last few years. I finally downloaded it last month. It really just puts a silly smile on your face. The language-oriented programming is terrific too. I really want to find ways to integrate Racket into my work.

gnulinux 7y ago
> I really want to find ways to integrate Racket into my work. Normally engineers search for tools to solve their problems. Somehow, when it comes to programming languages, software engineers start a search for problems for their cute tools. Please don't get me wrong, I'm not making a snarky comment against lisp. I'm very much in love with lisp, but I do understand how people see us lisp people like bunch of gray wizards in some remote castle. What needs to be shown is a set of problems that can adequately be solved by racket that cannot be solved as well with competing languages. We should really stop treating programming languages anything other than tools. I use GNU grep for 20 years, one day I realize ripgrep is better, I switch. Again, I want to underscore that I'm not saying that particularly disagrees with you. I just don't think this rhetoric is helpful. We should be thinking about what makes racket that puts a smile on our face, and discuss whether we can use these tools in other languages. Not that this is not being discussed, of course.
- waterhouse 7y ago
  What do you think of this line of thought: This tool is not currently the best, but because of its design, it has the potential to become the best tool with some refinement (which may consist of improving the tool itself, your own understanding of it, or its integration into your development processes)—specifically, there exists some cutoff period T where, if you're using the tool for shorter than T, then the "current best practice" tool is better, but if you're using it for longer than T, then the payoffs from your favored tool exceed the costs of the refinement. Then it's a matter of (a) one's estimate of T and (b) one's planning horizon. This generates the hypothesis that a developer's desired planning horizon may be "the rest of my career", which is likely to be longer than the planning horizon of whatever project the developer is being paid to work on.
- darkpuma 7y ago
  Have you ever heard the expression "When all you have is a hammer, every problem looks like a nail"? The phenomenon you're describing is definitely not a unique characteristic of developers. It's a general trait of people that when they learn something cool, they look for opportunities to use it.
- threepio 7y ago
  > What needs to be shown is a set of problems that can adequately be solved by racket that cannot be solved as well with competing languages I thought the piece "Why Language-Oriented Programming? Why Racket?" covered that question pretty well. https://news.ycombinator.com/item?id=19232068 https://news.ycombinator.com/item?id=19232068 Perhaps there's another modern programming language that can do these things as easily as Racket. I haven't come across it, however.
- trabant00 7y ago
  > Normally engineers search for tools to solve their problems. Somehow, when it comes to programming languages, software engineers start a search for problems for their cute tools Most of the tools I now use to do my work (devops) I found just playing around with them out of curiosity. Yes, when doing work you should start with the problem and then search for the right tool, but it's a lot better to have wide arrays of tools in your belt than starting to tour the shops after the deadlines are set. I don't want to be condescending but I find it hard not to given the obvious catch-22 in your line of reasoning. Even more so as this trope is posted quite often.
agumonkey 7y ago
Wonder how many people wrote translator to output python|javascript|java ?
openfuture 7y ago
You can look at the biggest DSLs in Racket for tools that solve specific problems (sort of responding to sibling here). I think Racket is probably the best tool for writing static sites for example (using pollen).

rurban 7y ago

I would recommend either a change to lazy jit compilation, or dumping the jitted image, for the startup-time problem.