Why I Hate Scheme
jlongster.com
jlongster.com
(P.S. I love Scheme and did everyday things in Scheme when I had the opportunity to for a while. But right now I'm really enjoying Clojure and I think that Clojure might replace Scheme for me, because of Java libraries, and because of the really concise, consistent, and pleasant syntax, especially for maps and functions.)
But: “Objective-C is a great example of what is going on. Obj-C is a cool language that implements fancy message passing, but it has ugly syntax and doesn't really offer anything new to the average programmer (Python works just fine without message passing, doesn't it?).”
What I can't stand is people who don't really understand their underlying languages start to talk about them. I mean, are you kidding me jlongster? Objective-C's system is bad but Python's system is okay? Why not say you love the taste of chocolate but hate the taste of cocoa? They're performing the same function for the runtime!
I want to like Python, but its community of people who just refuse to understand how other languages relate to their favorite language really frustrates me. I'm not sure I can even count how many times a pythonista has challenged me, “What do you mean Python doesn't have real lambdas? _You don't even know Python!_” Given how important a community is to a language (see also: common lisp), it's difficult to overlook stuff like this.
What is written in PLT, and who uses it? I'm not talking about great technology, I'm talking about putting that into practice. I use Gambit Scheme and I think it's the best system out there. But I'm challenging Scheme programmers to make great things, and put them to use, and give people a reason to learn Scheme.
I put up a blog post last night with some troubles I was having in Gambit (my site with the post: http://etherplex.org) I'm very new to non-JVM hosted languages, so I'm not yet sensitive to where the performance pitfalls are.
Essentially, a professor of mine gave me a program in C that boiled down to a for loop doing 144 million iterations with a check inside of it, and an increment if the check passes. The C program runs in 1 second, and the straight port to Gambit I attempted runs in about 8 minutes.
I posted code, in hopes someone might spot my error. Are nested do statements or let statements particularly expensive, or did I make some bone-headed mistake somewhere when I ported it over? It's not meant to be functional (yet), I thought I'd just start with an imperative implementation and go from there, since that was what the original code was. Thoughts?
(declare (block) (standard-bindings) (extended-bindings))
These are statements to let the compiler optimize things, losing some dynamicism. That should increase it a lot. When it comes to tight loops, Gambit doesn't usually do as good of a job because of its garbage collector (it doesn't optimize for lots of small short-lived objects), which is planned to be fixed in the future.
Instead of pouring a lot of effort into Scheme, let it stay an academic language. It's fine for learning about functional programming.
I moved from Scheme to Ruby and haven't missed Scheme. Sure, Scheme macros are very powerful, but I found that the DSLs that you can create in Ruby are adequate. Ruby also has the advantage of being a multiparadigm programming language.
You should try Clojure. It's cleaner than Scheme except for the pains that come along with the JVM, but those redeem themselves by giving you access to zillions of libraries (which was your other complaint). And it has a good community and an awesome benevolent dictator.
Too late; I'm in the Ruby community and things are just fine here. :) But thanks for mentioning Clojure; I didn't realize its syntax was so Scheme-like. That's news to me. :)
> too much variation among the various flavors of Scheme which fragments the community
> lacks good language constructs for managing large software projects
It seems that those points are being recognized and worked on very seriously in R7RS. See http://www.scheme-reports.org/
> Instead of pouring a lot of effort into Scheme, let it stay an academic language.
Well, the "Little" Scheme (working group 1) should still fit that bill. And the "Big" Scheme (working group 2) is supposed to fix the above problems you mentioned.
- ITA Software does airline scheduling in Lisp.
- Naughty Dog Software created a Lisp-derived scripting language for several of its games, including Crash Bandicoot. After they were acquired by Sony, their underlying technology was rewritten in more mainstream languages.
- Paul Graham built ViaWeb in Lisp. (also rewritten after acquisition)
- AutoCAD uses Lisp as its scripting language, and several other CAD providers have followed suit.
But you are right: it isn't particularly popular. To use it commercially, you either need to be working alone, or you need to stumble into one of the few pockets of industry where it is used -- usually established by someone working alone. :)
Here's an old-ish discussion on the subject:
http://news.ycombinator.com/item?id=75126
Clojure is probably too new to find many companies using it. They do have a jobs page, though: http://clojure.org/Jobs
As a bare minimum, it needs proper modules, it needs to be properly multithreaded and it needs more than about 6 people on the planet writing libraries for it.
I've since switched to Haskell which has proper modules, proper multithreading and lots of libraries and may even be a better language than Scheme - if I could only understand what a monad is :-)
Unfortunately, the language is really fucking slow. I wish I had an interpreter written in C.
Of course, if I did have a problem with multiple http+eval calls, in many cases I could probably write what I wanted to do in the other language in batch, so the overhead would be quite small.
At that point I'd ask myself whether it was worth the trouble.
Could you give me some examples of what you mean? Are you talking about something like perl's cpan?
Everyone wishes their language could have something analogous to the CPAN. But before you can have that you need some standardization and community agreement in place regarding how modules are to work and be packaged up.
I like python's approach better. The standard library is robust and broad enough to handle most things.
Do you mean "R7"? Because R6 seems to have actually done the opposite.
> Personally I'm not a real fan of cpan. The qualilty is sort of hit and miss.
The hit-or-miss quality is a necessary "evil" for having something as good as the CPAN. Yes, it's got a lot of crap, but there are a lot of gems that save many people a lot of work.
> I like python's approach better. The standard library is robust and broad enough to handle most things.
It has been said that the Python standard lib is where modules go to die. Guido himself has implied [^1] that modules in the std lib already have one foot in the grave.
[^1]: http://tarekziade.wordpress.com/2010/03/03/the-fate-of-distu...
The future of successful general purpose languages is to have a small core with a vibrant external "CPAN". There just aren't enough core developers to maintain a large high-quality batteries-included standard library of modules. Much better is a dedicated loosely-coupled mostly active community of maintainers -- maintaining the bits that they are personally interested in (which is exactly what the CPAN has).