[philly-lambda] Re: Yearning for a Practical Scheme

Just saw this over on LtU: http://lambda-the-ultimate.org/node/936

Given all of the Scheme talk on this list lately, I thought you all
might have some interesting commentary on this guy's complaints.
Personally, I think his definition of "practical" might need some
work, but there are some interesting points in there.

The complaint about the lack of real-world architecture information
for Scheme apps rings true for me; its very easy to find tons of apps
to use as templates/reference/howtos for a wide array of languages
(C,C++,Java,Perl,Python,Ruby,VB,etc) but Scheme/CL are definitely
lacking in this area compared to their imperative brethren.

I agree with his sentiment that there is no widely accepted way to organize lots of code in Scheme - in Java, there is are clearly accepted practices which are for the most part encoded in the package/class naming system. My senior dev asked me about how we should organize the JScheme code since we've got a descent amount of it. JScheme has a module system which works ok (no macros if you 'use-module, only if you 'load, which is kind of a strange difference), but to a Java programmer it all looks (and in many cases acts) very scary - so much is deferred until runtime. (the deference until runtime of several classes of errors is something I also wish Perl [5] could deal with differently, though good unit tests make up for a good bit of this yearning)

I wish scheme had a module system. I know that was a goal for R6RS, but that train seems to have derailed.

As far as practicality and portability, I think that new platforms have emerged: the JVM and the .NET CLR. These now exist in addition to, not necessarily in stead of, the web (which is a mish-mash of several things), Windows (which looks like it will become the synonymous with .NET) and the Unixes. The Unixes drop out for the most part if you look at the front end.

The lack of libraries can be mitigated if you're on one of these two new platforms since you then have access to the entire platform. Graham was kinda right that if you're building a web-app you can do it in whatever you want to, but web-apps today have to integrate front-end interactivity (it may not be ubiquitous, but it will be soon enough).

Personally I'd like to see scheme all the way through from the back end, very low level (chicken?) to the back/middle tier (SISC or JScheme on the JVM) and into the browser (instead of _javascript_). Even though GWT was a restricted sub-set, I still like the _idea_ that you can do Java on the back end and on the front end. The pendulum may swing back the other way when we have the bandwidth (and figure out cleanly how) to project richer user interfaces, but it doesn't look like that'll happen for a bit

I also want to do without the kinds of errors that static type checking can catch - and there is no reason why a Scheme or a Lisp couldn't do that if it were built into the core and most libraries. It would just catch so many issues before they became runtime debugging problems. It doesn't have to be 100% comprehensive like Java/C++ or even Haskell, Ocaml or Qi, just doing as much as it could (eval/funcall/apply not withstanding) could help a lot. I know CL supports type declarations, but as far as I can tell they're not commonly used in the community and its libraries. I like refactoring my code, things like renaming methods and changing argument lists - but I have to resort to find/xargs/grep to look for code whenever I change the arity or argument order on existing functions. I have higher confidence in the Java code's run-time robustness due to the compilation phase catching function signatures, then I do in my Lisp/Scheme/Perl code.

Maybe I'm doing it wrong. I'm not convinced I have it figured out, I'm still trying to learn new ways of thinking and approaches.

Finally, isn't this kind of concern what Arc
< http://paulgraham.com/arc.html> was supposed to address, at least in
part? It would be awesome if that was released at some point...

I don't know that I see PG as focusing on those issues - I'd think he'd be concerned with power. With expressibility and possibly performance allowing your smart programmer to scale themselves as far as possible and not on the types of things that allow teams to work more productively.

Kyle