This is a really great little guide for people that want to try out a Scheme but are paralyzed by the options. This will help those in need find a starting point. I highly recommend GNU Guile, the implementation that the author co-maintains.
Please don't do this on HN. Even if it's true, the health points it knocks out of the discourse are more valuable than the truth that it adds. The thing to do with comments that suck is downvote them. If you have a factual correction to add, that's great, but let it stand on its own. ("Guile uses the LGPL, note the 'L'." is just fine.)
I've never used it myself, but fwiw Gauche also advertises support for native threads. SRFI-18 threads are wrapped around pthreads on Unixy platforms, and Windows threads on Windows. http://practical-scheme.net/gauche/man/gauche-refe_106.html
Ah, I was not clear enough: native SMP threads, as in each thread accessing the same shared memory heap. Gauche allocates a new VM for each thread ... ah, but I see it has data synchronization primitives. I believe it has moved forward since the last time I checked it, years ago.
Thanks for the tip!
Repeated from the other reply on Guile: Hmmm, now I'll have to narrow the statement to "The only native code compiling Scheme that I know of" (which is harder to do).
If you play Philip Glass' Einstein on the Beach while using it, it will not be happy!
(We were roommates when he launched the GNU project, and he did not like that title, it would wake him out of a sound sleep. Which, if you've listened to it, is perfectly understandable, it's very minimalist, an acquired taste he did not share :-).
Hmmm, so it does, and as suiting its niche, at a low level. See above WRT Gauche; from a skim of the manual, Guile's VM may be reentrant or it hides that level of detail.
Thanks for the tip!
Hmmm, now I'll have to narrow the statement to "The only native code compiling Scheme that I know of" (which is harder to do).
A bit of googling turned up this pricing sheet where Chez Scheme is listed on page 88 (it says $65 per unit or $325 for 10, so buy your Chez's in bulk!):
From whom can you go to buy a copy, and is it still under development?
The web site doesn't look like it's been touched since 2011, and Google searches constrained by site:cisco.com turn up nothing. Other searching showed no signs of life.
What about implementing your own Scheme or Lisp if you want to embed an interpreter for your C/C++ project (the first scenario discussed in the blog)? I recently decided to roll my own Prolog interpreter for my project. With C++11 and shared pointers it is really a breeze (of course I've thought about doing this for a long time so the actual implementation part was smooth sailing but not the only story). The advantage of rolling my own:
1. No GC. Ref counting is sufficient for my own use.
2. Integrating with the C/C++ libraries I want to use is a lot easier. I designed my implementation for the purpose of embedding in my project and gluing libraries.
> What about implementing your own Scheme or Lisp if you want to embed an interpreter for your C/C++ project (the first scenario discussed in the blog)?
I've done this for a Java project many years ago, where it sort of grew out of a config file format, as so many Lisps do. I would probably take the trouble to add a standard embeddable interpreter if I did it again. Otherwise, you end up with yet another 80%-ass Scheme with its own quirks and no libraries, and the world has too many of those already.
I forgot to emphasize that this is not a real problem. You will likely have good C/C++ libraries for most things. The real issue really is to expose these libraries to your embedded language on a as-needed basis. To me the effort is better spent in creating my own targeted solution that makes interfacing easier and that is under my control than learning the minutia of the FFI of a third party implementation, after taking into account the following:
1) we are talking about effort on the scale of one or a few KLOC to roll one's own, and comparing that against the effort needed to truly master the FFI of a third party implementation;
2) my interface is no longer limited to the lowest denominator that a standard implementer would face (e.g. most use C but I can use multiple inheritance and templates of C++ to make the interfacing a lot easier);
3) supporting FFI users is typically not the highest priority on the standard implementers' agenda (if there is any support at all).
> You will likely have good C/C++ libraries for most things.
For most things in your domain. Then someone wants regexps, or Windows path handling, or what-not, and you find that you didn't really implement Scheme macros, or some particular style of modules, so you lose.
I agree that if you want C++ integration, you're probably going to want to roll your own. The first person to write an easy FFI that groks C++ name mangling will do a tremendous service to mankind.
There's no "someone" in this context, because you're not designing a language for the masses, you're making your personal language. At best, if you put it on Github you'll maybe find a bunch of people wanting the exact same thing so you'll have a bunch of users&co-implementors that know that they're basically on their own if they choose to use your language. This is where small and simple languages such as Scheme, Forth or Lua shine: you can master and hack everything from the first byte to the last.
The real issue with this approach is that, if you need a particular library you have to do the bindings yourself first. You have to deal with the delay required to design, implement and test it. On the other hand, the difference between learning the API for an another popular language and learning the native API so you can make the bindings for your language tends to zero as the complexity and size of said library goes up.
"Then someone wants regexps, or Windows path handling, or what-not"
I think you would be hard pressed to find something that is available in Scheme but not C/C++. Take regex, you have std::regex, many pcre wrappers and Google re2, which has strong linear time guarantee. If you go with chibi as recommended by the blog, does it come with a good regex binding? What if you want to use Google's library? By the time you figure out how to bind iterators or coroutines in c the effort may well have been used to roll your own c++ solution in the first place.
"you didn't really implement Scheme macros"
I agree that is a more serious barrier. One has to honestly assess one's own true understanding and ability in implementing the target language. I am not an expert in Scheme and I couldn't tell you how easy or hard this is. I did study Prolog and its implementations extensively so I knew exactly what I needed to do. There are so many good resources out there that if one is willling to put in the effort one will be richly rewarded for the learning experience.
What specifically are your reservations? - I haven't played around with many Scheme implementations besides DrScheme/DrRacket so I'm not questioning your judgement, I'm just genuinely curious.
To expand a bit on "bloat," DrRacket does use a lot of memory for a text editor (don't have it installed ATM but I remember 100s of megabytes of memory in use in a typical light session of 1 file + 1 REPL), crashes somewhat frequently (a couple times in my test run, usually when trying out some of the crazier features hidden in the menus), and becomes less than responsive due to very frequent GC pauses (that are helpfully indicated by a little recycling icon in the corner of the window).
I still think it's a far superior way to introduce newbies to Scheme than emacs, but it's definitely flawed.
The old DrScheme editor was quite light, enough for me not to ever complain on underpowered AMD Sempron machine we had in college. The rewritten DrRacket really feels sluggish sometimes. I ended up using Emacs/Geiser for a MOOC.
It comes with 'batteries included', and the defaults work fine on most modern machines.
If you are really resource constrained it's easy to go to the settings and restrict memory use, and turn off tools you don't intend to use. If you have a really slow machine there is even a minimal DrRacket.
My Ivy Bridge i7 with 16 gigs of RAM is not exactly resource constrained. I'll take your word for it that you can disable features to get the resource usage down, but it's kinda sad that the default config can't run without stuttering on a machine like that, especially since the program is intended to be used in education where the average machine is significantly less powerful than that.
Well, first, I'm talking about DrRacket the IDE here, not the Racket language. For context, at the moment I'm just using DrRacket in Racket mode as I try to bash out naive turnip-truck Scheme to generate some XHTML. DrRacket is certainly not bad, and it's perfectly usable for my purposes, but it has obvious shortcomings.
Most naive users complain about "bloat" for stuff like program file sizes on disk, not knowing that most of it is assets (icons, etc).
Others think that having two many options in the menus, features etc slow the program down, not realizing that in most programs stuff is run and loaded dynamically, and a features you don't use don't affect the speed at all.
Others yet think that only 20% of the features is needed (those that THEY use, of course) ignoring the fact that while a core set of features is common to all users, a large part of them are in non-overlapping set. E.g.: "Who needs a word-counter in Word?" -- well, if you're a journalist, it's your #1 more useful function.
[Disclaimer: I also like the idea of RSR7S small.]
Just now there is a major reorganization in the Racket repository. The idea is to split it in a core part and may small packages. The objective is one day having many installers. For example one with only the minimal support for racket, one with everything including the kitchen sink, ...
While indeed we are doing a major refactoring of the repository, the split into many packages has already happened. And you can download the Minimal Racket installer today!
I love racket, but DrRacket is just too slow and memory heavy for my machines.
My most powerful personal computer being a laptop with an 1.8GHz i5, and 4GB of ram. Yeah, that's very modest by 2014 standards, but I really think that it should be able to handle DrRacket better than it does. As it is, it is just too slow for me to put up with. I think that something that at least somewhat targets the education niche should be able to perform well on old hardware (the type of machine you might typically find in a university computer lab).
I have an even wimpier computer (2GB ram, 1.4GHz Core 2 Duo). The start up time is large, and it will happily use a couple of hundred megs of RAM, but I never felt that it was too slow. Maybe I'm using an old version (5.1), but I doubt it's gotten much worse lately.
I had racket 5 running fine on an atom based eee pc. The most important thing is to turn off unused 'tools'. you can also restrict memory use by DrRacket. These days Minimal Racket does all the for you.
