[philly-lambda] Re: Projects people are working on...

["Andrew Gwozdziewycz" <apgwoz@gmail.com>]

> I'd like to share some of my thoughts on the current state of Magic.
> In specific senses, I wholeheartedly agree with you that Magic is
> not generalized enough. It's currently for Scheme48 only, and
> there's nothing motivating me to make it more portable. Second, it
> uses SCGI to speak to web servers, making deployment straightforward
> only on Lighttpd AFAIK.

I don't think there's an issue that it's being targetted at a single
implementation. My take on the Scheme world is that the number of
implementations surviving is due to the nature of the many different
views hundreds of people have on a very small spec. I don't think this
is generally a bad thing, but an inconvenience in many cases. As
someone new to Scheme (loving it), but wishing I could have it all in
one implementation, stumbling upon a piece of software in it's early
stages that looks promising, yet seeing that it doesn't work in such a
way you can go and get your feet wet with it right away, makes me
question those previous statements. Will Scheme ever have a "killer"
app which gets it the praise it deserves? Is the abundance of choice
holding Scheme back from gaining wide popularity? I know none of my
co-workers would ever give it a shot because of the "number of
parenthesis," but a few years ago, they never would have looked at
Ruby either.

Certainly there is a ton of code written in Scheme targeting 1, and in
some cases 2 or 3 implementations, but none of it that I've seen
sticks out as something to make people want to try out Scheme. When I
saw Magic for the first time, I thought damn, this might be able to
shut people up about Rails and maybe even gain some popularity.

> But in other ways, Magic is too generalized. It uses an Emacs hook-
> procedure approach to processing requests, which makes adding
> features such as session support very straightforward. It's about
> equally easy to do just about anything, which leads me to wonder how
> easy it is to do anything.

There's no question that Magic is neat, and has some really good
ideas, I can't dispute that. What is lacking though is documentation,
and _more_ good examples to show off what it can do, how easily said
things can be done and maybe even more importantly illustrate why
you'd want to use Magic over Django, or Rails (implementation language
aside). It's straightforward to those of us who are into Scheme and
things, but like I said, not everyone else is.

But, wide adoption of Magic, may not be your goal, and that's cool
too. I am just more or less explaining my outsiders view of it. Take
whatever I say however you like.

> It should be easy to deploy Magic. Ideally it should speak HTTP
> natively, allowing it to service requests directly or be proxied
> behind another server. The downside of such an approach is my desire
> to avoid writing a fully compliant HTTP/1.1 server. I do not want to
> reinvent the wheel.

I think ideally, you follow Python's lead here and create something
like WSGI for Magic that allows you to create a function that knows
how to accept and return the request to the client. Then it's up to
the programmer how they want to deploy it, assuming they have a layer
to handle FastCGI requests, or mod_lisp, or whatever. The point is,
the main entry point to a Magic application is the same regardless of
how it's deployed. If you then want to write an HTTP/1.1 web server,
create it in such a way that you can attach a Magic application to it.

> Magic, but I'd like to make a clean break with the legacy Magic 2
> code. I am aware of what Joel Spolsky would say about that[1], and I
> may to a more evolutionary approach to evolving Magic i.e. I may
> never do a ground up re-write.

First of all, though I believe that Joel Spolsky sometimes has some
clever things to say, I don't consider him a god, or all knowing. In
this particular case, he has a point, but I fail to see why people put
him on this pedestal. Have you ever used Fogbugz? I wasn't a fan. I
say, do what it takes to make it something you want to use. If that
means iteratively rewriting it until none of Magic 2 exists, than so
be it.

> It should support the development of contemporary web-based
> applications. I'm interested in doing things like creating
> Javascript proxies for server-side Scheme procedures and data
> structures. I'm writing a new version of the Transmogrify Resource
> Repository[2] as an exercise to help me figure out what Magic needs
> to support to make developing ajax web apps a breeze.

But how does it do with regular requests and form handling? You're
definitely right, you need to gracefully handle AJAX, but don't forget
about the other important things.

> It should be i18n-friendly. I am a 7-bit ASCII guy at heart, and I
> have a lot of trouble embracing this Unicode stuff, but it's here to
> stay, so I better deal with it. Sigh.

How is Scheme48's handling of Unicode? I've never much been a fan of
Unicode. I don't read other languages, nor do I write them. But, I of
course do realize that I *should* start thinking about making stuff I
write more friendly to all.

Regarding Scheme48, I had a brief stint where I was using it, but it
was a bit awkward for a newbie such as myself. I should eventually
give it another shot. For now though, I've been using Gauche, and it
handles unicode quite well. Of course it's author is Japanese, so that
more than likely is the major reason for that.

> It should be porting-friendly. Because *I* do not want to port it.

I think any piece of software that has a chance in hell of being
successful in the Scheme world, *must* be porting-friendly. The same
goes for CL code too, as far as I can tell.


-- 
Andrew Gwozdziewycz
apgwoz@gmail.com
http://www.apgwoz.com  | http://www.photub.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Philly Lambda" group.
To unsubscribe from this group, send email to philly-lambda-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/philly-lambda?hl=en
-~----------~----~----~----~------~----~------~--~---