Home

Schematics Scheme Cookbook

The Schematics Scheme Cookbook is a collaborative effort to produce practical documentation for using the Scheme language, particularly in commercial environments. It is focused on PLT Scheme, although other Scheme dialects are supported as far as possible.

A nice attempt by several of lambda's friends to provide practical help for people trying to solve real problems using Scheme.

I think the community around any non-mainstream language must encourage and support such efforts for the language to have any chance of gaining momentum.

This is somewhat related to our discussion of real life programming using Haskell, and about the success of so-called scripting languages.

I must admit that I use Python for my scripting work. Tried to use Scheme but it was too much of a bother. Guess it's time to try again.

By Ehud Lamm at 2004-09-01 13:24 | General | other blogs | 9953 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Scooped!

Ehud, you're too quick. I was going to contribute this but was scooped.

I generally use Python for scripting tasks as well, but it may interest LtU readers to know that there were a few scriting tasks from the weblogs.com conversion that involved using Scheme as a scripting tool. Lisp seems to be in a funny place, too much of a "serious" language to do scripting, but not rigid enough for commercial developers.

The idea behind the cookbook is the ASPN cookbooks, though they aren't wikis. One difference with the ASPN cookbooks is that they have strong ownership of recipes, while the Scheme cookbook doesn't have that. I hope that the Wiki format will encourage people to contribute where they feel they have something to add. In its current state, lots of things have been stubbed out - I literally went through the Python Cookbook and stubbed out recipes for Strings and Files. So there are lots of stubs to fill out. Remember it's a wiki - sign up and contribute!

By GordonWeakliem at Wed, 2004-09-01 17:06 | login or register to post comments

there were a few scriting tas

there were a few scriting tasks from the weblogs.com conversion that involved using Scheme as a scripting tool.

I should have mentioned that.

And since we are talking about adding things, I don't remember seeing anything about unicode. My last scripting "project" really needed unicode support. I am not sure about the status of unicode support in PLT.

By Ehud Lamm at Wed, 2004-09-01 17:25 | login or register to post comments

Unicode

Unicode support is the impetus for PLT's next major revision, version 300, which will be coming out in a few months or so.

By Jacob Matthews at Wed, 2004-09-01 17:51 | login or register to post comments

Unicode in PLT

I've tiptoed around Unicode for now because it is slated for version 300, which is due Real Soon. If you care to build from the CVS EXP tag, you can get it. Actually, I think I mentioned the Latin-1 limitation in the intro to the XML chapter.

By GordonWeakliem at Wed, 2004-09-01 17:47 | login or register to post comments

I guess I'll wait

This goes to show you, by the way, the real ways people make decisions when it comes to small, quick and dirty scripting jobs. My PLT installation has unicode, great. No? I'll use Python.

Not really an in depth language analysis, but quite rational when it comes to small programming tasks.

By Ehud Lamm at Wed, 2004-09-01 17:49 | login or register to post comments

tradeoffs

...the real ways people make decisions when it comes to small, quick and dirty scripting jobs.

In a former job, I was once vainly trying to convince my department to change tools. A colleague who was full of little pearls of wisdom pointed out that to get people to change tools, you can't just convince them that your tool is better, you have to show them that it's ten times better. This is partly due to people's fear of the unknown, but it's actually pretty sensible: given the amount of time and effort it takes to learn a new technology, a small improvement will be dwarfed by the overhead.

On the other hand, you can't accurately predict how useful a technology you don't yet understand will be.

By Dave Herman at Wed, 2004-09-01 19:18 | login or register to post comments

Good point

On the other hand, you can't accurately predict how useful a technology you don't yet understand will be.

This is a good poin which is often overlooked. However, you can (and should) learn new tools (including cognitive tools) without betting you company's future on them. Play at home, take a university course etc. etc.

This is one reason good programmers (dare I say hackers?) try to learn non-mainstrean (and dare I say esoteric) languages. They may pick up something useful even if they continue to work in Java/C++/what have you.

Regarding what I said about rational choice. Taking into consideration the effort required to gather information, experiment with new tools etc. is not only rational, it can also be formalized using models like bounded rationality. Rational choices are not always best choices. A programmer may make a wrong language choice (i.e, not use Haskell for everything) without proving to be irrational if, for example, the costs in learning the new language and tools either seem very high (since calculating costs is itself expensive) or if it's impossible to make required investment (i.e., the programmer isn't smart enough to learn the new techniques).

By Ehud Lamm at Wed, 2004-09-01 19:37 | login or register to post comments