Lambda the Ultimate

Sometimes I just despair that people will ever learn to see beyond surface syntax...

And even though everyone can use Scheme to build OOP features, they are not going to be compatible with each other. Same goes to other features, like a module system.

But wait a minute, was that a troll!?

People keep re-inventing the wheel because they feel they need better wheels not simply out of ego. Besides people who re-invent the wheel get to focus on the things that matter to them like built-in object orientation, or similarity to another language.

An interesting question would be: how do you get the best aspects of languages like Scheme into the mainstream? Do we need yet another new language or extension of an existing language?

Too vague for me.

I like something a bit more explicit like:
Encapsulating state and procedures that work on this state in an object allows procedures (methods) to be called with fewer parameters (compare C) which makes procedure calls more readable.

Or:
Scheme makes encapsulation explicit. Methods and data are encapsulated within the lexical scope of Scheme closures.

As in SICP's circuit simulator (see (make-wire)):
http://sicp.arsdigita.org/text/sicp/section/64/

Scheme:
A *uniform syntax* of *s-expressions* maps to
*cons-cell structures* in the underlying
implementation language (e.g. C)
that mirror *list recursion* directly:
process (car x) and recurse on (cdr x)

Therefore:
Lua's do-everything-with-hash-tables does not seem to be as powerful as Scheme's do-everything-with-cons-structures because the later strategy allows a simple and straightforward mapping from syntax to semantics to implementation. But...

S-expressions make *run-on sentences* easy to write that is: functions that are too long to be readable....so no one does read them....or *re-use* them much...

The significant-white-space/indentation strategy of Python syntax makes run-on sentences almost impossible (unless you're going to carry on off the screen to the right...therefore: Python syntax is eminently readable..

What I want to know:
How can the principles (or similar principles) of readability enunciated in Martin Fowler's "Refactoring" be applied to Scheme to make it more readable and re-usable?

( http://www.refactoring.com/ )

IMHO Scheme is often hard to read. Is there a way to make it more readable?

Thanks in advance,

Jon Fernquest

First, no, it was not a troll, just an (if I may be so alliterative) earnest expression of exasperation.

Syntax pertain to readbility, which is an important factor from a SE perspective if not from a PL theory perspective - so I wouldn't dismiss it altogether.

Scheme syntax is an acquired taste, but so is Algol-like syntax. Both kinds of syntaxes take a few weeks to get used to for a newcomer. After that, I don't think there is a huge difference. Obviously, Algol-like syntaxes have more internal cues, and perhaps on that score they are more readable, but less writeable (you have to learn more syntax productions). Personally, I think everyone has a brain big enough to accomodate both without noticeable cognitive burden. There are thousands of active Scheme programmers; they seem to manage just fine.

BTW, I don't like Scheme for its syntax. In fact, I don't think there is much value in the so-called syntactic incidence of Scheme programs and Scheme data, because programs are not simply lists (i.e., trees); they have a great deal more structure, such as the binding, and functions on lists do not preserve that structure as they should. So the programs-as-data approach in Scheme only goes part of the way, and that can be misleading.

And even though everyone can use Scheme to build OOP features, they are not going to be compatible with each other. Same goes to other features, like a module system.

I'm not saying that "because you can build it Scheme, it's good enough." Indeed, the design decisions involved in building module systems and OOP extensions are best left to language designers, not language users.

What I'm saying is that if you have a module system or an OOP feature which is so great that you think everyone should use it, but the rest of your dynamically typed language is no better than Scheme, then why not add it to Scheme and see if people agree with you? If they do, then it ought to eventually become a de facto standard.

Now you might say, "But people have tried that before, and we now have tens of module systems, etc. for Scheme and no clear winner." I think there are three reasons for that.

First, maybe there is no clear winner in popularity because there is no clear winner in functionality. So maybe none of the extensions are adequate and we need to go back to the drawing board.

Second, lots of people release extensions but only write a few programs with them. People seem to like scripting languages because they have big libraries, so the best way to make an extension popular is to take a big part in writing programs for it.

Third (and most tentative), though have we many extensions, hardly any of them are specified with the same rigor as Scheme itself. If they were, it would be easy to write translations between them, and that would reduce the compatibility problems.

Anyway, you complain about lack of compatibility among Scheme extensions, yet look at the situation in the world of scripting languages: Perl, Python, Ruby, Pike, Lua, Javascript, Nickle, Rexx, TOM, etc., etc. It's even worse. At least Scheme extensions can share Scheme code! And can you imagine trying to write a translator from one language to another? None of them is defined in a rigorous implementation-independent manner, except Scheme.

People keep re-inventing the wheel because they feel they need better wheels not simply out of ego.

I think it is out of ignorance or contempt. There is a large body of literature out there on programming language theory, but scripting language designers are either unaware of it or purposefully disregard it because they claim it has no relevance to practical matters.

And then there is the issue of types. When I read the synopsis of a new scripting language, I invariably see this statement: "and best of all, because language X is dynamically typed, you don't waste time declaring the types of variables!" No one with even a passing acquaintance with PL theory would make such a bald statement, not when there are so many typed languages with full type inference and powerful type systems. I'm not saying there aren't arguments in favor of dynamic typing (though I don't subscribe to them), but claiming that static typing = explicit typing is just plain wrong. (Well, granted, that statement does not actually make that claim, but it sure hints at it strongly, and I have little doubt that most people read it that way.)

Besides people who re-invent the wheel get to focus on the things that matter to them like built-in object orientation, or similarity to another language.

That's fine for a hobby project or an experiment. But before you develop language X maybe you should be thinking about why you can't write X programs in Scheme. Are your only reasons that you hate the syntax and that people wouldn't use your language-as-extension because of compatibility issues? Those are not language issues, they are pragmatic ones. You should look for pragmatic solutions, not language ones. Write an alternative Scheme parser. Write an extension translator. Lobby the Scheme committee. Write a Scheme addendum. Write your extension using syntax macros. Whatever. Do something, but don't pollute the language space even further unless you have some good language issues to resolve.

I think one of the reasons for the popularity of scripting languages is the speed with which you can get started writing code that has some effect of the environment. Examples of renaming files, processing directories etc. are always given. It's the same with commercial software, you're going to be much more successful selling it if after installation you can very quickly demonstrate something happening, and people can start working with it themselves. Perhaps a few "scheme for scripting" pages showing how to "catalog your mp3 collection using scheme" would help.

As to why people write new languages instead of modify existing ones, I think it's for the same reason that people rewrite from scratch rather than modify any software. For most people it's just more interesting to start with a blank slate than to try to understand the decisions and compromises that other people made. So, if I'm interested in dabbling in languages and I want a particular feature I could either spend some boring time understanding the internals of perl (for example) so that I can add the feature there, or I can start from scratch in the belief, probably mistaken, that that would be quicker.

This is (also) related to the problem of reuse: simply finding the right components to use can be a complicated and lengthy process.