Is this the best moment for scheme ever? First of all, I have to admit that although I quite studied the language in the last years, I'm a bit outside the spirit of the community. My impressions basically come from some discussions I have with more experienced schemer friends and reading stuff on the web.
I have often wrote about my difficulties with finding a satisfactory scheme environment. Essentially problems boil down to two things:
- I have very high expectations for programming environment (batteries included, etc.)
- I have very high expectations on Lisps, probably because every lisper I met spent a great deal of his non-programming time saying how lisp did this and that 30 years ago. So I expect to do it now, to do it fast and to do it well.
The issue with the first point is that I'm mostly used to programming environments which are mostly unique. Python is just Python. I use the very same interpreter everywhere, I know what it does, which features are supported and which ones are not. Same thing for Clojure or Erlang and nowadays mostly true for Haskell. I avoided the issue with C/C++ being rigorously adherent to the standards or to very minor gcc extensions (and by the way, I'm always using gcc).
On the other hand in Scheme there are many implementations and there is not a clear winner. There are implementations which are "worse" than others, but among the good ones it is hard to choose.
The problem is especially significant because I somewhat got into a period of transition between R5RS and R6RS (which are two standards). I somewhat lived something like that with C++, but at least back then there was clear consensus that pre-standard C++ was unarguably worse than post-standard C++.
Essentially, R6RS came out in the mid 2007 and I started learning Scheme not much afterwards. Moreover (here discussions with my friend kick in) a large part of the Scheme community did not like the standard, feeling that the new language was too large (plus strictly speaking it should lack a REPL).
After reading Dybvig's 4th edition Scheme book I found that mostly I like the new stuff. However, for some unfathomable reason I sticked with Gambit, which does not implement it. So, while I like the idea that Scheme was a little language which you use to build your language, I missed lots of R6RS features which just make to much sense for me (as an "application/library" programmer, instead than a "language programmer"). That, and the fact that if you want to toy with a new language, you do not want to re-implement merge-sort (unless you are are explicitly choosing that example to learn the language).
So there were lots of incomprehensions between me and the my scheme learning process. But I'm afraid that lots of non schemer may be feeling the very same stuff about it (and perhaps jump to clojure, which fixes that issues by default).
Some time later, the other scheme implementation I used became another language (and I'm looking forward to read the new No Starch Press book about it). So the more "batteries included" tool I knew in scheme, ceased to be scheme.
I think things would have been easier if I just picked up an R6RS implementation and stick with it. However, things went differently. Not that I do not like Racket, still I find ackward to code in Racket when I want to grok Scheme and code written in Racket is so often not very portable to other schemes (and that is why Racket is Racket). I'm not complaining about Racket: I think they did the right thing.
However, nowadays the Racket book is scheduled. And there is going to be a new standard R7RS. And they decided to define a "small" and a "big" language. And I really do believe this is wonderful because it would make clear exactly what to expect from either language also to newbies. Moreover, perhaps some of the more reasonable improvements with less reaching implication which R6RS will be added to the small language as well. E.g., how to define libraries and generic information about what to expect from the "platform". Or maybe "values" related stuff.
So, in essence, I think in the future it will be a great time to learn scheme. Maybe I will have the courage (and the time) to re-learn it from scratch and fix all my miscomprehensions which came from the way I originally learned the language.
7 comments:
Sorry for interrupting your dream.
But if you did not realised it yet ... clojure is better than scheme.
But if you want a programming language to write less , efficient and fast code.
That gets less memory and run the same as fast like Gambit.
Then try "Factor" , it also has great tools , which are even better than SBCL.
Believe me , it will change the view of programming.
Sorry for interrupting your dream.
But if you did not realised it yet ... clojure is better than scheme.
You're welcome. No dreams here, however. By the way I'm kind of missing the part where I claimed that scheme was better than clojure.
I'm not claiming the opposite either. There are good languages and ill conceived languages. That is basically all the ordering you can do rationally on programming languages. Good languages have strengths and weaknesses.
We can argue whether a given language is better than another for a given task and even in such case many times the individual programmer or team which has to actually use the language is quite more relevant.
But if you want a programming language to write less , efficient and fast code.
That gets less memory and run the same as fast like Gambit.
Then try "Factor" , it also has great tools , which are even better than SBCL.
Believe me , it will change the view of programming.
About "changing the view of programming" do you mean "my view"? In the last twenty years my view of programming changed quite lots of times, so it may be possible that it will change again.
I'm sure that factor is a very interesting language. Still, the idea of concatenative programming is not new (and not new to me). Writing forth interpreters/compilers was quite a common exercise once and one I indulged in.
I will surely give Factory a try. It looks extremely interesting, even though I'm not a huge fan of concatenative programming.
@rik0: you may be interested in Klio:
http://mbenelli.github.com/klio
that contains some batteries for Gambit. I don't think it will satisfies your requirement, thought.
It is designed for a quite static model of compilation (for embedded systems)and it has some very rought edges. Feedback and contributions are welcome.
@Cran1988: I find quite surprising your claim about Clojure running as fast as gambit using less memory. Any evidence, please?
I am indeed interested. It may not be exactly what I'm looking for, but it gets damn close. Probably is just a matter of a few libraries missing.
About Cran's post, I believe that his claim is that factor is as fast as gambit, not clojure.
According to my experience assessing the performances of Clojure has even more problems than doing that for a regular Java program. Generally speaking, you can do it essentially just on the effective problem. Hand coded micro-benchmarks just do not work (i.e., work worse than usual) because of the GIT.
As far as I can tell from Alioth Shootout benchmarks it appears that Java can be damn fast (less than 3 times slower than C).
Among the functional languages, Haskell is very fast (though I expect OCaML to be faster). SBCL has a huge spread: sometimes is very fast, sometimes very slow (relatively speaking). It is mostly comparable with Haskell, however the variance of Haskell's results is much slower.
I do not know if this is because SBCL programs have very different quality (i.e., some implementations are poor) or because the benchmarks involve some of SBCL weak spots.
On 64 bit Racket and Clojure are comparable (with clojure results having a larger variance), on 32 bits racket is definitely faster than Clojure.
IIRC gambit should be quite faster than Racket, probably in the Haskell range. If I was asked, I would say that Gambit is quite faster than clojure.
However, I also believe that:
1. in time Clojure will become almost as fast as Java, in the sense that with years of optimization and considering the built-in possibility of type hinting things should improve a lot
2. Java is going to become faster and faster and hopefully Clojure will benefit as well
In fact, I think these are excellent results which prove that:
1. My Haskell sucks. My Haskell programs tend to be 10 or more times slower than the analogue C programs. It has to be seen if these benchmarks use the same old trick of using non-idiomatic code, tailored for speed on the specific tasks
2. My Lisp/Scheme results are consistent with what I see here (which proves that a relatively natural style is well rewarded from the implementations)
3. They are all damn fast: being in the < 10x range from C is something wonderful.
http://shootout.alioth.debian.org/u32q/which-programming-languages-are-fastest.php?calc=chart&gcc=on&java=on&ghc=on&sbcl=on&racket=on&clojure=on
http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php?gcc=on&java=on&sbcl=on&ghc=on&racket=on&clojure=on&calc=chart
Sorry for having misunderstood Cran1988 comment, my bad.
BTW, could I ask what libraries did you miss in klio tools?
I try to explain what I meant with "probably".
As far as I can tell Klio is a distribution of libraries and scheme programs which essentially add functionality to the Gambit core.
Some of these libraries are quite standard stuff (e.g., as far as I can tell lists is basically srfi-1, I haven't checked if it misses something or if it offers something more).
However, it is not *also* a packaging system for Gambit. I.e., something like Planet; which means that sooner or later I may find some library which is not there *and* it does not provide ways to "install and distribute" my libraries (a part from pull request to you).
This is not, strictly speaking, a problem. What I was mostly concerned about was having a slightly larger core than the one offered by Gambit, and as far as I can tell is what klio offers.
Any plans in having that integrated directly with Gambit?
Ok, I understand.
Actually Klio can be integrated with Gambit, compiling it with Gambit sources. So you have an interpreter and a compiler that are basically Gambit with the Klio libraries built in.
I'm planning to put gambit's C files in a 'vendor' directory so it can be compiled with Klio even without having a gambit installation.
I have a script that do this work, but I haven't pubblished it yet because I'm working on a more complete build system.
Well, to be honest, I'm not sure on the best way to follow: if I use a Makefile it will need mingw on Windows machines, I if write my own build system in Gambit, it will need Gambit already installed and so on.
Also, it's not clear to me the best way to install and find the libraries: environment variable, initialization scripts ...
So, I have a lot of prototypes (including a near complete r7rs module system), but nothing that satisfy me completely.
Since the main point of Klio is to have something usable *now*, this task has quite low priority for me, and I doubt I will have something *good* in the foreseable future.
Also, as I suggest in README file (that is a little obsolete) it is possible to load the most useful libraries at Gambit's startup.
On the other hand, I think that a condition to have as usable code repository is social consensus, and the scheme community is already planning an r7rs repository.
And, yes, lists is srfi-1, charsets is srfi-14, strings is srfi-13 and so on.
They have been modified to take advantage of gambit's built-in features (notably optional arguments and declaration).
Post a Comment