hey,
It was no wonder that with the proliferation of online ecommerce
companies, building websites became a huge portion of the overall
programming that was being done in the world. Sun and MS have shaped
their products and specifications around these needs, to a large
extent. There products offer libraries and features designed around
making scalable and robust ecommerce systems. I don't know that CL has
done this.
At the Lisp conference I listened to what was involved in creating the
HotDispatch site, in making it perform some of the basic ecommerce
features (e.g. financial transactions, caching, etc.), and it was
anything but easy. It seemed like it was a major chore -- they had to
build a lot of basic stuff from scratch; they rolled their own O/R
mapper for objects; they have their own webserver (IIRC), etc. This is
a lot of work. I was sitting there...almost surprised that they were
able to get everything working.
On the other hand, I recently had the pleasure of overseeing the
construction of an ecommerce website. I considered using Common Lisp,
but then decided against it for several reasons. I hired a single
Java/Python/Jython developer to do it, and he blew my mind. We did it
in a mostly unconvention way, since the standard way Sun suggests using
Java for such projects (JSP) is nasty. We were able to get the most out
of Java's libraries, ability to scale with J2EE/EJB2, and yet do so with
a small amount of code in Jython. Many of the dynamic features of CL
are available in Jython (not all...but many).
For this class of problems, at the current time, I would say that CL is
not the ultimate way to go. I have worked with some spectacular CL
developers, but don't know that any one of them could output so much
productivity in such little time.
If CL were put to the challenge, I believe that it could potentially
generate an amazing implementation of the Pet Store, faster, more
readable, and in fewer lines of code than the existing ones offered by
Sun, MS, and others like Ibatis:
http://www.ibatis.com/jpetstore/jpetstore-1.html
Of course, if this were done in CL, it would most probably be tied to a
particular Lisp (vendor), and probably to some extend a database, or at
least ODBC driver. But this is another issue, and not the main thrust
of this post.
I think that it would be beneficial for the Lisp community to
participate in the "Pet Store" exercise, and show that we can develop
such a system. The important decisions of which Lisp implementation,
which platform, which webserver, database interface, etc., would have to
be decided.
In the process of doing this exercise, I believe that the details as to
the shortcomings of the implementations and utilities would surface, and
could be fixed one by one.
I don't know of any open source Lisp implementations that would be ideal
for this work. The one that's chosen should work on both Linux and
Win32, should support multiprocessing, be able to run Portable
AllegroServe (possibly with some work), and have a working ODBC
interface...at the very least.
dave
From: Howard Stearns
Subject: Re: CL version of (Java) Pet Store?
Date:
Message-ID: <3DEBD648.6080005@attbi.com>
I didn't quite follow what you want to ultimately achieve. I'd like to
ask "Why", but not to shoot down the idea. My intent is to focus your
effort and give you some way to measure your success.
I agree that building a site like the pet store will highlight missing
J2EE features from AllegroServe-or-CL-HTTP + database, etc. But why
would you want to duplicate commercial grade Java architecture in Lisp?
I also agree that the result would, to our eyes and ways of accounting,
be smaller, faster, prettier, more comprehensible. But to what end?
For example, do you want Java and .NET developers to do the same things
they do now, in the same way, but using Lisp as the glue language? If
so, I would submit that such an effort might have better hope of being
achieved by giving these developers a way to incrementally incorporate
Lisp stuff into their existing mechanisms, tools, platforms, libraries,
processes, etc.
Conversely, maybe you don't care about Java and .NET developers, but you
know that there are ecommerce application in which you want to use Lisp
for whatever reason. Here you just need some basic core functionality
that you don't want to have reproduce from scratch. An open source
project is good for this. Maybe you haven't identified that
functionality yet, and want to take the pet shop as a wild stab starting
point. OK. But it's not clear to me how you would decide which parts
should be in Lisp and which should reuse existing J2EE or other
functionality.
Alternatively, maybe you want to show that Lisp is clearly better for
some class of problem. In that case, I would suggest identifying what
you think Lisp's core benefit is for the given domain, and pick an
example in which it really shines and illustrates that value.
Dave Bakhash wrote:
> hey,
>
> It was no wonder that with the proliferation of online ecommerce
> companies, building websites became a huge portion of the overall
> programming that was being done in the world. Sun and MS have shaped
> their products and specifications around these needs, to a large
> extent. There products offer libraries and features designed around
> making scalable and robust ecommerce systems. I don't know that CL has
> done this.
>
> At the Lisp conference I listened to what was involved in creating the
> HotDispatch site, in making it perform some of the basic ecommerce
> features (e.g. financial transactions, caching, etc.), and it was
> anything but easy. It seemed like it was a major chore -- they had to
> build a lot of basic stuff from scratch; they rolled their own O/R
> mapper for objects; they have their own webserver (IIRC), etc. This is
> a lot of work. I was sitting there...almost surprised that they were
> able to get everything working.
>
> On the other hand, I recently had the pleasure of overseeing the
> construction of an ecommerce website. I considered using Common Lisp,
> but then decided against it for several reasons. I hired a single
> Java/Python/Jython developer to do it, and he blew my mind. We did it
> in a mostly unconvention way, since the standard way Sun suggests using
> Java for such projects (JSP) is nasty. We were able to get the most out
> of Java's libraries, ability to scale with J2EE/EJB2, and yet do so with
> a small amount of code in Jython. Many of the dynamic features of CL
> are available in Jython (not all...but many).
>
> For this class of problems, at the current time, I would say that CL is
> not the ultimate way to go. I have worked with some spectacular CL
> developers, but don't know that any one of them could output so much
> productivity in such little time.
>
> If CL were put to the challenge, I believe that it could potentially
> generate an amazing implementation of the Pet Store, faster, more
> readable, and in fewer lines of code than the existing ones offered by
> Sun, MS, and others like Ibatis:
>
> http://www.ibatis.com/jpetstore/jpetstore-1.html
>
> Of course, if this were done in CL, it would most probably be tied to a
> particular Lisp (vendor), and probably to some extend a database, or at
> least ODBC driver. But this is another issue, and not the main thrust
> of this post.
>
> I think that it would be beneficial for the Lisp community to
> participate in the "Pet Store" exercise, and show that we can develop
> such a system. The important decisions of which Lisp implementation,
> which platform, which webserver, database interface, etc., would have to
> be decided.
>
> In the process of doing this exercise, I believe that the details as to
> the shortcomings of the implementations and utilities would surface, and
> could be fixed one by one.
>
> I don't know of any open source Lisp implementations that would be ideal
> for this work. The one that's chosen should work on both Linux and
> Win32, should support multiprocessing, be able to run Portable
> AllegroServe (possibly with some work), and have a working ODBC
> interface...at the very least.
>
> dave
Howard Stearns <··············@attbi.com> writes:
> I didn't quite follow what you want to ultimately achieve. I'd like to
> ask "Why", but not to shoot down the idea. My intent is to focus your
> effort and give you some way to measure your success.
ecommerce application development is the source of a huge chunk of all
programming that goes on in the world. Breaking into that market might
be late now, but not necessarily _too_ late. It would have been nice,
for example, if the Lisp community had responded to the Java Pet Store
the way MS did with .NET. Also, you can see how much business decided
to go with .NET as well: it's a lot, and a lot of executive decisions
were made when people compared MS's .NET solution with the corresponding
Java solution to the Pet Store, offered by SUN...it was the difference
of ~10K LOC...not a joke.
Does that help?
> I agree that building a site like the pet store will highlight missing
> J2EE features from AllegroServe-or-CL-HTTP + database, etc. But why
> would you want to duplicate commercial grade Java architecture in
> Lisp?
First off, the Web is completely platform- and language-independent from
the perspective of what's creating the content (we'll call it XHTML).
So I wouldn't even say that we need to reproduce the exact same exact
functionality (i.e. "duplicate" as you wrote), but rather that we need
to be able to solve similar problems.
I like the solution of trying to link CL to existing Java systems,
though that's not so easy either, it seems.
I didn't like jLinker (ACL), though JiL might be cool. And that
CL->Java translator from the conference might also be a way to get some
Java functionality.
> I also agree that the result would, to our eyes and ways of
> accounting, be smaller, faster, prettier, more comprehensible. But to
> what end?
To the end that we could have people here capable of providing solutions
for companies who want them.
Do you not see this? Do you not realize that if Lisp programmer can't
feed themselves, then we lose?
It's not about whose stuff is prettier...it's about being able to solve
the problems at all, in a reasonable way.
> For example, do you want Java and .NET developers to do the same
> things they do now, in the same way, but using Lisp as the glue
> language? If so, I would submit that such an effort might have better
> hope of being achieved by giving these developers a way to
> incrementally incorporate Lisp stuff into their existing mechanisms,
> tools, platforms, libraries, processes, etc.
I'm not suggesting that at all. The Pet Store is basically an ecommerce
site. It doesn't matter what the framework is, really. it's about the
results, not what technology was used to get there.
> Conversely, maybe you don't care about Java and .NET developers, but
> you know that there are ecommerce application in which you want to use
> Lisp for whatever reason. Here you just need some basic core
> functionality that you don't want to have reproduce from scratch. An
> open source project is good for this. Maybe you haven't identified
> that functionality yet, and want to take the pet shop as a wild stab
> starting point. OK. But it's not clear to me how you would decide
> which parts should be in Lisp and which should reuse existing J2EE or
> other functionality.
I would suggest a pure Lisp play first, and if that's too much work,
then using the other crap.
> Alternatively, maybe you want to show that Lisp is clearly better for
> some class of problem. In that case, I would suggest identifying what
> you think Lisp's core benefit is for the given domain, and pick an
> example in which it really shines and illustrates that value.
I don't care to show people that Lisp is better for X, and hope that
they just assume that therefore it's better for Y. I love CL, and even
I don't buy that.
What you need to show is that "You want X" and "We can do X". That
simple -- I'm not suggesting anything too crazy here. Just that we
offer comprable solutions, or rather that our solution space overlaps
with what these companies want.
I almost feel like writing this in all caps, just so I don't have to
re-explain it: I am a Lisp programmer, and yet rejected using CL for
ecommerce site development because it was lacking in that department.
So it's not about selling Lisp, or getting people to love Lisp. If it
helps you think about it, it's about giving Lisp developers the ability
to solve this class of problems, given that they already love Lisp, and
would love to use it if possible.
dave
Dave Bakhash <·····@alum.mit.edu> writes:
> What you need to show is that "You want X" and "We can do X". That
> simple -- I'm not suggesting anything too crazy here. Just that we
> offer comprable solutions, or rather that our solution space overlaps
> with what these companies want.
>
> I almost feel like writing this in all caps, just so I don't have to
> re-explain it: I am a Lisp programmer, and yet rejected using CL for
> ecommerce site development because it was lacking in that department.
> So it's not about selling Lisp, or getting people to love Lisp. If it
> helps you think about it, it's about giving Lisp developers the ability
> to solve this class of problems, given that they already love Lisp, and
> would love to use it if possible.
>
> dave
have you looked at imho and the like? http://alpha.onshored.com
marc
Marc Spitzer <········@optonline.net> writes:
> have you looked at imho and the like?
I have, though I havn't used it. It seems like it's got a long way to
go.
dave
On Tue, Dec 03, 2002 at 12:13:08AM -0500, Dave Bakhash wrote:
> Marc Spitzer <········@optonline.net> writes:
>
> > have you looked at imho and the like?
>
> I have, though I havn't used it. It seems like it's got a long way to
> go.
Perhaps you should give it another look. I started using IMHO and
UncommonSQL about 1.5 years ago and put it successfully into production
then. Onshore makes extensive use of both for their commercial web
applications. I was rather puzzled that you hadn't found the web
application development software you were looking for in CL, but now it
seems you were simply passing it by.
[Portable] AllegroServe and Araneida are two other options; I've found
the former to be extremely flexible and will be using it in upcoming
applications to forego the overhead of Apache. CL-SQL was the first
major application to use UFFI and is widely ported.
You may not find the equivalents of all the J2EE/etc functionality
pre-packaged as libraries, but I think you'll find most of it is fairly
trivial to implement. I don't think the state of CL in web applications
is as poor as you make it out to be, pet shop or not.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> writes:
> Perhaps you should give it another look. I started using IMHO and
> UncommonSQL about 1.5 years ago and put it successfully into
> production then. Onshore makes extensive use of both for their
> commercial web applications. I was rather puzzled that you hadn't
> found the web application development software you were looking for in
> CL, but now it seems you were simply passing it by.
It's not that far off from what we use at Portus, which is a combination
of Common SQL and PortableAserve. We added some session management
stuff to it, and there were were, we had a website.
I will look into IMHO to see how they deal with transactions, SSL,
shopping carts, session management, and XHTML.
> [Portable] AllegroServe and Araneida are two other options; I've found
> the former to be extremely flexible and will be using it in upcoming
> applications to forego the overhead of Apache. CL-SQL was the first
> major application to use UFFI and is widely ported.
I agree. Havn't used Araneida, but Portable AllegroServe works pretty
well right now. Havn't pushed it too hard yet, but so far so good.
> You may not find the equivalents of all the J2EE/etc functionality
> pre-packaged as libraries, but I think you'll find most of it is
> fairly trivial to implement. I don't think the state of CL in web
> applications is as poor as you make it out to be, pet shop or not.
J2EE does quite a bit...esp. wrt remote handling of objects
(RMI/Corba). Using the CMP 2 stuff, Java generates local and remote
interfaces for the objects, which comes in useful.
dave
"Dave Bakhash" <·····@alum.mit.edu> wrote in message
····················@nerd-xing.mit.edu...
> J2EE does quite a bit...esp. wrt remote handling of objects
> (RMI/Corba). Using the CMP 2 stuff, Java generates local and remote
> interfaces for the objects, which comes in useful.
Now, this gets into the realm that streches a little outside of the
ecommerce niche I think.
Many folks using J2EE dance, moan and complain about Entity beans due to
performance. In the J2EE vs. .NET articles many respondents want to toss
EJBs out completely and go solely with Servlets and perhaps JDO.
Depending on you application, this can limit scalability, but one thing I
seem to have learned from looking at the Yahoos and Googles of the world, is
that scalability is all relative. These guys toss out elegant solutions like
RMI and CORBA and do their work through design and simple raw horsepower.
EJBs make it easier to scale your conventional application, but it appears
to me that a lot of applications can be redesigned using "cruder" methods
and still scale. However, Remote EJBs also enact a penalty and I still see a
lot of applications NOT taking advantage of things like clustering etc
because of the performance cost and that server licensing costs.
I look at Weblogic, for example. CPU License runs ~ $10K, and CLUSTERABLE
CPU License run an extra $7K. So, two 4 CPU, clusterable machines runs $136K
in license fees alone. You can get almost 3 racks stuffed with 1U PCs for
that money. Almost 90 CPUs, and you don't have to worry about sophisticated
GC contention or any of that. (yes it's an extreme example).
Certainly not every application can fit a model such as Googles or The
Wayback Machine, but I also think that a lot of developers haven't
necessarily tried to fit these models.
Having a farm of CL servers tossing S-Expression back and forth seems like a
lot of untapped power to me.
There's a difference between what is available and what is required. Using
tech for the sake of tech isn't necessarily correct for every application.
Regards,
Will Hartung
(·····@msoft.com)
>
> It's not that far off from what we use at Portus, which is a combination
> of Common SQL and PortableAserve. We added some session management
> stuff to it, and there were were, we had a website.
>
If you don't mind, would you please say which Lisp implementation are
you running PortableAS on amd how's the multithreading (or lack of) is
doing on these?
jls
·········@netscape.net (Jules F. Grosse) writes:
> > It's not that far off from what we use at Portus, which is a
> > combination of Common SQL and PortableAserve. We added some session
> > management stuff to it, and there were were, we had a website.
> If you don't mind, would you please say which Lisp implementation are
> you running PortableAS on amd how's the multithreading (or lack of) is
> doing on these?
LWL 4.2 enterprise, from Xanalys.
dave
Jan Rychter <···@rychter.com> writes:
> This thread is very interesting. I agree with Dave Bahkash -- I'll be
Maybe old news, but the Franz online store is now open and runs on
AllegroServe: https://secure.franz.com/store
AllegroServe is not even listed on the NetCraft servers page at:
http://www.netcraft.com/Survey/servers.html
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petter
Jan Rychter <···@rychter.com> writes:
> Some people in this thread have mentioned that you can actually easily
> implement most functionality required for web applications in CL. That
> might be true, but it's not a very valid argument.
It is, if your application does much besides the boilerplate code. If
it's going to take you 2 months to write the core of your app in Java,
or 2 weeks in CL, you have 1.5 months saved. Even if you spend
another couple weeks replacing what you'd have gotten with Java,
you're still ahead.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> Jan Rychter <···@rychter.com> writes:
>
>
>>Some people in this thread have mentioned that you can actually easily
>>implement most functionality required for web applications in CL. That
>>might be true, but it's not a very valid argument.
>
>
> It is, if your application does much besides the boilerplate code.
exactimundo. and that is why a universal CL gui should /not/ be built
atop some C++ framework just to save you lazy bastards the effort of
re-inventing the wheel of mastering win32, clx and the mac and wrapping
a neutral framework around it.[1] in the spirit of the Lisp OS, just
think what we could do if it was CL all the way down. I mean, yeah, the
/universe/ is Lisp atwd, now if only the OSes were.
--
1. well, ok, I am exploring starting Cello on the GLUT in the hope of
/deferring/ the effort, but if it gives me any trouble it sleeps with
the fishes. SDL (an even more helpful package for which there is a
smashing CL-SDL project underway) was dandy, but I had enough issues
that I decided I better make sure GLUT could not be hacked into being
Lisp-friendly.
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
> exactimundo. and that is why a universal CL gui should /not/ be built
> atop some C++ framework just to save you lazy bastards the effort of
> re-inventing the wheel of mastering win32, clx and the mac and
> wrapping a neutral framework around it.[1] in the spirit of the Lisp
> OS, just think what we could do if it was CL all the way down. I mean,
> yeah, the /universe/ is Lisp atwd, now if only the OSes were.
If you want a starting point, then consider LispWorks's CAPI. I'm sure
there's some room in there for improvement, but CAPI supports a good bit
of what people want. You don't get the source code, but if you have
your own GUI system, and want a good interface for it, then it makes
good sense to go with (and then extend) CAPI:
o it's simple and easy to learn
o it's been around for some time, and has been used successfully
o it's been designed in a way that people can write GUIs by hand
Again, we've had good success with it. I think there are some good
opportunities in CAPI for cleanup, though.
dave
> ecommerce application development is the source of a huge chunk of all
> programming that goes on in the world. Breaking into that market might
> be late now, but not necessarily _too_ late.
Ideally it's never too late, the magic of the market is that there's always
room for some innovation.
> It would have been nice, for example, if the Lisp community had responded
> to the Java Pet Store the way MS did with .NET. Also, you can see how
> much business decided to go with .NET as well: it's a lot, and a lot of
> executive decisions were made when people compared MS's .NET solution
> with the corresponding Java solution to the Pet Store, offered by
> SUN...it was the difference of ~10K LOC...not a joke.
A lot of decisions may have been made, but you'd like to hope that they
weren't made solely on the J2EE vs .NET Pet Store as both platforms are a
lot deeper than that. A lot of folks would like to rewrite the Pet Store, in
Java, and stomp the .NET version. They just wouldn't use the full J2EE suite
simply for the sake of using the J2EE suite (which the J2EE Pet Store does).
I, too, however, was amazed at the LOC # for .NET, and what it told me is
that they're bundling a heck of a lot more boiler plate into their server
than a J2EE server is. That's good because I have to write less stuff.
That's bad because if what they're doing is not the way I want it done, it I
have to throw even more away to get it done.
> > I agree that building a site like the pet store will highlight missing
> > J2EE features from AllegroServe-or-CL-HTTP + database, etc. But why
> > would you want to duplicate commercial grade Java architecture in
> > Lisp?
Why duplicate a commercial grade Java architecture in Lisp? For the same
reason MS is duplicating a commercial grade Java architectire in C# and CLR!
Granted, they have a few more resources for it, but...
> First off, the Web is completely platform- and language-independent from
> the perspective of what's creating the content (we'll call it XHTML).
> So I wouldn't even say that we need to reproduce the exact same exact
> functionality (i.e. "duplicate" as you wrote), but rather that we need
> to be able to solve similar problems.
This is a very key part to fixate upon, because J2EE is more than an
ecommerce suite. Many will tell you that it's really overkill for simply
ecommerce applications. Its real depth is in integration and such.
So, what parts do you want to duplicate? Dynamic web pages? The Servlet
model? The EJB Model? The REMOTE EJB Model? Session, CMP and BMP Entity
Beans? Declarative transaction boundaries? JMS? There's an awful lot of
stuff here, and not all of it is necessary for ecommerce.
A heck of a lot of ecommerce can be done with the servlet model alone. I
like the servlet model, I think it's pretty good. Lots of functionality in
there, but I think something like AllegroServe must already offer something
like this.
The most basic form is having a container manage your sessions for you
"automagically", and perhaps declarative security.
> I like the solution of trying to link CL to existing Java systems,
> though that's not so easy either, it seems.
>
> I didn't like jLinker (ACL), though JiL might be cool. And that
> CL->Java translator from the conference might also be a way to get some
> Java functionality.
I really don't know what this kind of interaction would truly buy you. I
would see it the other way around, by having Java interact well with a Lisp
image vs Lisp interacting with the JVM. Most of the boiler plate utility
stuff is in Java, and the Hard Part would be in Lisp. And today, this can be
done using CORBA.
> > I also agree that the result would, to our eyes and ways of
> > accounting, be smaller, faster, prettier, more comprehensible. But to
> > what end?
>
> To the end that we could have people here capable of providing solutions
> for companies who want them.
>
> Do you not see this? Do you not realize that if Lisp programmer can't
> feed themselves, then we lose?
>
> It's not about whose stuff is prettier...it's about being able to solve
> the problems at all, in a reasonable way.
And there's the rub.
To me, there is one severe problem that is difficult to address in the
dynamic content area. The communication and integration of the web page
author and the logic author. These people tend to be completely different.
The web page author tends to be more graphic artsy, used to working in the
limited domain of HTML and CSS, whereas the logic author comes from
computing background thinking in terms of abstractions and such.
These two people are not necessarily compatiable, and when you have one
doing the others task, you end up with a disaster.
> > For example, do you want Java and .NET developers to do the same
> > things they do now, in the same way, but using Lisp as the glue
> > language? If so, I would submit that such an effort might have better
> > hope of being achieved by giving these developers a way to
> > incrementally incorporate Lisp stuff into their existing mechanisms,
> > tools, platforms, libraries, processes, etc.
>
> I'm not suggesting that at all. The Pet Store is basically an ecommerce
> site. It doesn't matter what the framework is, really. it's about the
> results, not what technology was used to get there.
Oh, I disagree, it is about the technology. If it wasn't about the
technology, then there are a LOT of tools out there that get results.
There's a LOT of wonderful websites backed by really crappy code.
If you don't care about the technology, then you might as well go LAMP
(Linux, Apache, MySQL, PHP).
So, yes, the technology does matter. It matters because the technology is
what gives you such quick turn around. The technology gives you the
flexiblity to mold the application to the whim of the client, quickly and
safely.
We have an application. It has over 3000 JSPs in it. Know what? That is a
REAL burden when you want to port to another app server. Yup, the JSPs may
not have been the best way to go, but the problem isn't the JSPs per se,
it's that we have 3000 of them, and no way to doing any automated changes to
them with more sophistication than sed(1).
> > Conversely, maybe you don't care about Java and .NET developers, but
> > you know that there are ecommerce application in which you want to use
> > Lisp for whatever reason. Here you just need some basic core
> > functionality that you don't want to have reproduce from scratch. An
> > open source project is good for this. Maybe you haven't identified
> > that functionality yet, and want to take the pet shop as a wild stab
> > starting point. OK. But it's not clear to me how you would decide
> > which parts should be in Lisp and which should reuse existing J2EE or
> > other functionality.
>
> I would suggest a pure Lisp play first, and if that's too much work,
> then using the other crap.
The only thing I can see reusing is Apache, frankly. Follow the Tomcat
model.
AllegroServe, however, was designed specifically to skip this step.
AllegroServe, as I recall, works pretty competetivily with Apache as a
static web server, so if you like you can start there instead.
> > Alternatively, maybe you want to show that Lisp is clearly better for
> > some class of problem. In that case, I would suggest identifying what
> > you think Lisp's core benefit is for the given domain, and pick an
> > example in which it really shines and illustrates that value.
>
> I don't care to show people that Lisp is better for X, and hope that
> they just assume that therefore it's better for Y. I love CL, and even
> I don't buy that.
>
> What you need to show is that "You want X" and "We can do X". That
> simple -- I'm not suggesting anything too crazy here. Just that we
> offer comprable solutions, or rather that our solution space overlaps
> with what these companies want.
>
> I almost feel like writing this in all caps, just so I don't have to
> re-explain it: I am a Lisp programmer, and yet rejected using CL for
> ecommerce site development because it was lacking in that department.
> So it's not about selling Lisp, or getting people to love Lisp. If it
> helps you think about it, it's about giving Lisp developers the ability
> to solve this class of problems, given that they already love Lisp, and
> would love to use it if possible.
My understanding is that AllegroServe currently gives you a lot of the basic
functionality. From what I can tell (after quickly glancing through it) is
that it does NOT have any session management functionality, so that's
probably the most necessary tid bit.
So, given that as a framework, a CL application that generates dynamic
content, you must ask what does it not do that compelled you to go to
another platform?
Platform portability? It seems reasonably portable to different CLs, but
either way this is more of an implementation issue than an engine issue. But
I don't know why CMUCL or Corman Lisp wouldn't be able to run this with
minor hacks.
And, ideally, all that basic plumbing that shouldn't prevent the final apps
from being portable. Heck, besides the fact that it may only service one
request at a time, there's no reason why the AllegroServes (publish ...)
function/macro couldn't run on CLISP, right? There's no reason that at this
level, a WebApp (to steal a J2EE term) couldn't be made portable with no
tweaks, while the hosting container code fulfills that burden. Distribute
the WebApp in source form, container compiles it into its FASL form, and
viola!
Are you missing a way to embed logic into web pages? That's a real nut to
crack. Embedded crap into HTML is easy. Writing HTML in Lisp is easy. Its
the seperation of tasks that's difficult, and I think that WebObjects may
have solved it best by using a few custom tags. I think that it can be more
simply done by using named SPAN tags to tie into the back end logic.
My thinking is simply <SPAN> tags are used to surround bits of logic. The
web page author fills in the "blanks" with fake content for formatting, and
the <SPAN> tags are replaced by a filter or compiler. This lets the author
see "real pages" with "real links", but they all "go away" and are replaced
with dynamic content by a pre-processor. Works with any HTML editor to boot!
Database connectivity? That can be done, I understand, from most CLs, to at
least SOME databases. Perhaps someone can port the Java JDBC native drivers
for PostgreSQL to CL, then you don't have to go through any layers (save
your own).
So, it's really important to focus on what was missing in your last project,
and even then don't fixate on "it's doesn't connect to Oracle running on
AS/400s". If you can run reliably on A platform, to A database, then what's
the problem? After that it's mostly fine tuning to give options. CL doesn't
benefit from the "WORA" binary features of Java, nor by the massive 3rd
party support of Java. I don't think Oracle is going to be handing out
Native CL DB drivers any time soon.
Going back to the LOC argument earlier, what's always hidden from these
numbers is the code backing it all up. There are a gazillion lines of code
behind that .NET Pet Store, a lot of it in C++ and NOT C#, unlike the J2EE
apps which have 99+% of their code in Java (Weblogic, for example, uses some
native libraries to speed up I/O, but even that may not be necessary with
JDK 1.4 today).
Here's what *I* like about J2EE, specifically Servlets. I like the WebApp
WAR concept. I like the idea that I can (theorectically) take this
"self-contained" blob of stuff and drop it into a compatable container, and
have it Just Work. It's not there yet, but it's getting better.
I like the declarative bits in the WebApp, like filters, JNDI resources, and
security, even the Servlet mappings. I like that JSPs ARE Servlets, that's
the best thing about JSPs IMHO. XML can rot, all of this stuff can be
declared with Lispy expressions. We get XML for free :-).
There's certainly a place for thing like O/R mapping, but I don't think
that's an absolute necessity.
So, what was missing that made you switch over? And could you prioritize the
list to make "CL Pet Store" more realistic?
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung wrote:
> I, too, however, was amazed at the LOC # for .NET, and what it told me is
> that they're bundling a heck of a lot more boiler plate into their server
> than a J2EE server is. That's good because I have to write less stuff.
> That's bad because if what they're doing is not the way I want it done, it I
> have to throw even more away to get it done.
Right. Exactly why 4GLs turned out to be 0GLs.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
·····················@nyc.rr.com...
> Will Hartung wrote:
> > I, too, however, was amazed at the LOC # for .NET, and what it told me
is
> > that they're bundling a heck of a lot more boiler plate into their
server
> > than a J2EE server is. That's good because I have to write less stuff.
> > That's bad because if what they're doing is not the way I want it done,
it I
> > have to throw even more away to get it done.
>
> Right. Exactly why 4GLs turned out to be 0GLs.
Funny you should mention that. I'm a big fan of 4GLs.
The interesting tidbit of this observation is that 4GLs, IN THEIR DOMAIN,
can be VERY productive. As long as your application can fit within the
framework of the 4GL, you can do "remarkable" things. The 4GL frameworks,
while quite rigid, can be quite powerful. But I agree that should you try
and drift away from its task, they can collapse quite quickly.
The trick, of course, is to find the right balance. If your system is too
flexible, then the 4GLness of you system goes right out because it seems
that what some call flexibilty, others call complexity. Flexibility AND
complexity can slow down development. When you're locked in to automating a
rigid framework, there's not a lot of thinking about what to do next and how
to do it. If there's just One Way, then it's done That Way, and that's
actually a part of the benefit of the 4GL. Is this the most optimal way? The
cleanest way? The way it SHOULD be done? Doesn't matter if the 4GL only
offers the One Way. Do it and be happy in your work rather than second
guessing every line of code.
I continue to use awk(1) instead of perl because it's so limited. 99% of the
time I don't need perls power, so why should I pay for it every single time
with detail? I just work within awks limitations, leverage its strengths,
and it is much easier.
In Lisp, of course, we get the benefit of both worlds, however. We get the
ability to create our own 4GLs, and rather efficiently as well. Technically,
there is one limitation. If your Lisp based 4GL just happens to use
S-Expressions, then you're off and running with no muss or fuss. But, as
soon as you break that one little rule, all of a sudden things can get very
complicated very quickly. And, frankly, that's usually needless complexity
for some other purpose than simply getting the job done quickly and well.
For example, defining application properties for a Lisp based application in
XML -- Just Because. Contrived, but still representative of the concept.
(How about rather than storing the properties in XML, and parsing the XML,
we write a simple utility to covert our properties into an XML file! WOW!)
When developers can get what they need to do done within the 4GL, they can
really fly along. 80+% of an IT application is mundane stuff. However, stock
4GLs tend to not be able to expand as necessary to accomodate the
application demands, and systems like Java keep having itsy boiler plate
bits getting in the way of the abstractions. Detail that's not important 99%
of the time to the application, but it is to the Java compiler.
Lisps problem, of course, is that many of the mundane, classic drone coder
IT applications are NOT written in Lisp, so there isn't much (public) code
that implements this basic framework available, and apparently not much of a
demand for it from Lisp vendors customers (that they're telling us about,
mind you). Same can be said for web apps ;-).
Regards,
Will Hartung
(·····@msoft.com)
"Will Hartung" <·····@msoft.com> wrote
[...]
> Funny you should mention that. I'm a big fan of 4GLs.
>
> The interesting tidbit of this observation is that 4GLs, IN THEIR DOMAIN,
> can be VERY productive. As long as your application can fit within the
> framework of the 4GL, you can do "remarkable" things. The 4GL frameworks,
> while quite rigid, can be quite powerful. But I agree that should you try
> and drift away from its task, they can collapse quite quickly.
[...]
> In Lisp, of course, we get the benefit of both worlds, however. We get the
> ability to create our own 4GLs, and rather efficiently as well.
[...]
This is these kind of reasons that made me write an application framework in
Lisp for web applications.
I can send the ILC2002 paper on this framework to interested people. The
abstract is here:
http://www.international-lisp-conference.org/Speakers/People/Marc-Battyani.h
tml
Marc
"Will Hartung" <·····@msoft.com> writes:
> To me, there is one severe problem that is difficult to address in the
> dynamic content area. The communication and integration of the web page
> author and the logic author. These people tend to be completely different.
> The web page author tends to be more graphic artsy, used to working in the
> limited domain of HTML and CSS, whereas the logic author comes from
> computing background thinking in terms of abstractions and such.
>
> These two people are not necessarily compatiable, and when you have one
> doing the others task, you end up with a disaster.
Have you looked at openacs.org? The way they do it is to have 2
"pages" per page. There is the programmer's page that sets up the data
sources and the web guy's page where he does all the html layout and
has access to a simple text generation language(for loop, if, variable
substitution and can call functions) that is geared for non programmer
types.
>
> Are you missing a way to embed logic into web pages? That's a real nut to
> crack. Embedded crap into HTML is easy. Writing HTML in Lisp is easy. Its
> the seperation of tasks that's difficult, and I think that WebObjects may
> have solved it best by using a few custom tags. I think that it can be more
> simply done by using named SPAN tags to tie into the back end logic.
>
> My thinking is simply <SPAN> tags are used to surround bits of logic. The
> web page author fills in the "blanks" with fake content for formatting, and
> the <SPAN> tags are replaced by a filter or compiler. This lets the author
> see "real pages" with "real links", but they all "go away" and are replaced
> with dynamic content by a pre-processor. Works with any HTML editor to boot!
You can do stuff like this in enhydra.
marc
Marc Spitzer <········@optonline.net> writes:
> "Will Hartung" <·····@msoft.com> writes:
>
> > Are you missing a way to embed logic into web pages? That's a real nut to
> > crack. Embedded crap into HTML is easy. Writing HTML in Lisp is easy. Its
> > the seperation of tasks that's difficult, and I think that WebObjects may
> > have solved it best by using a few custom tags. I think that it can be more
> > simply done by using named SPAN tags to tie into the back end logic.
> >
> > My thinking is simply <SPAN> tags are used to surround bits of logic. The
> > web page author fills in the "blanks" with fake content for formatting, and
> > the <SPAN> tags are replaced by a filter or compiler. This lets the author
> > see "real pages" with "real links", but they all "go away" and are replaced
> > with dynamic content by a pre-processor. Works with any HTML editor to boot!
>
> You can do stuff like this in enhydra.
I spent a couple years writing Enhydra apps, and rather liked it
(better than the servlet/JSP model). It gives you two nice things:
DODS, a database design tool that generates SQL and boilerplate Java
code to create and access the database (it has a horribly slow Java
GUI that generates an XML description file, so we eventually just
wrote the XML by hand), and XMLC, which lets you compile HTML and XML
files into a Java class that, when instantiated, results in a DOM
tree. By attaching 'id' attributes to a tag, you could pull a
reference to that node directly out of the tree, and
substitute/replicate/etc to your heart's content. When done modifying
the tree, you just called a built-in method that walked it and wrote
out the corresponding *ML.
The nice thing was that we could get HTML from the client's chosen
design shop, add a few ID attributes to it and be good to go. We
could later ship it back to the designer for modification, and their
tools generally preserved the tags. As long as they didn't modify the
structure in the wrong way (a definite gotcha), the modified HTML just
dropped in with a recompile.
Now, DOM is quite exceedingly nasty, but we didn't have to use that
much of it, and the whole thing was a reasonably usable system as
Java-based stuff goes, and fairly quick to develop with.
The Python-based Zope application framework has what it calls Page
Templates that also preserve the HTML structure, but instead of
walking the tree, you add "template attributes" that embed a simple
language for substitution and replication of elements. At page-view
time, the code in the template attributes is evaluated within the
context of the current Zope namespace (which has all the form and
session variables, and allows calls to Zope or Python methods for
other stuff like database queries). Again, the HTML generation tools
should preserve the tags you add (since they generally just ignore and
preserve unknown attributes, as do browsers) and the uncompiled page
template is completenly valid static HTML.
I've tried to "get into" Zope several times, as I like its design in
many ways, but never succeeded--I don't cotton to Python much, and
there's no really workable way to use Emacs to develop in Zope; you do
everything through a web interface, which (a) is a crap editing
environment, and (b) just totally disrupts the flow of programming as
far as I'm concerned.
So (to get on topic) I've been thinking a lot of writing a ZPT-like
system for Lisp--ideally, it would compile templated HTML into a Lisp
function that would be passed a namespace (probably a hashtable) and
execute the Lisp fragments in the template tags, substituting and
replicating as directed, and writing the regenerated HTML to an
arbitrary stream.
But, round tuits have been scarce, and my current job is slowly
sucking the life and creativity out of me...
-Doug
Doug McNaught <····@mcnaught.org> writes:
> there's no really workable way to use Emacs to develop in Zope;
Fortunately, this is wrong.
> you do everything through a web interface, which (a) is a crap
> editing environment, and (b) just totally disrupts the flow of
> programming as far as I'm concerned.
I do use Emacs with Zope. The source to Zope components (called
"Products") is stored in the file system, so there's no difference
to the mainstream way of doing things. And using a Zope component
called "ExternalEditor" you can click on a widget in Zope's
web UI to load content in your favourite text editor. The
ZODB, Zope's object database, also offers access via ftp
or WebDAV. There's plenty of stuff not to like in Zope but
not being able to use Emacs is not one of them :-)
From: Howard Stearns
Subject: Re: CL version of (Java) Pet Store?
Date:
Message-ID: <3DEF4B53.1000807@attbi.com>
For what it's worth, I'm still getting a mixed picture of what Dave
wants to achieve, and how to measure his success.
Maybe this is the crux:
Dave Bakhash wrote:
> I almost feel like writing this in all caps, just so I don't have to
> re-explain it: I am a Lisp programmer, and yet rejected using CL for
> ecommerce site development because it was lacking in that department.
> So it's not about selling Lisp, or getting people to love Lisp. If it
> helps you think about it, it's about giving Lisp developers the ability
> to solve this class of problems, given that they already love Lisp, and
> would love to use it if possible.
So if Dave rejected CL for a pet-store-like project, then doing the
project anyway would certainly fix whatever problems prevent its use BY
HIM for future such projects.
But that doesn't mean that other people -- even other Lisp developers --
will want to use Lisp for similar such projects. Demonstrating that it
can be done in Lisp does remove one obstacle, but it doesn't remove all
business and social obstacles, and more importantly, it doesn't
necessarily provide motivation.
For example, one could make a list of why to use Lisp for a given
project. Maybe:
1. familiarity
2. flexibility rapid development for ill-defined problems
Whatever. So, by relieving the need to recreate, say, session
management, etc., Lisp might be good for a Lisp developer to explore
options in a prototype. If the application is owned, operated, and
maintained by you, then I see no reason not to deliver it (to yourself)
in this form. So if this is the only intent that matters, the project
sounds great and should be a lot of fun.
But if you're delivering to someone else, or embedding the architecture
into some commercial product, then the two motivitors above are moot.
And there may be other serious obstacles (technical and social).
[Aside: The ecommerce world thinks in terms of multiple tiers, in which
data, business logic, and presentation concerns are dogmatically
separated. The Web may be platform and language independent, but that's
just the presentation part of the ecommerce story, and even that is
changing. There's a lot of dead bodies on the path to ignoring or
changing this technical and social infrastructure. It's not even given
that Microsoft can do it. And even with their resources, their strategy
is really to embrace the existing model and extend it only slightly in
an incompatible way.]
Regards,
Howard
"Will Hartung" <·····@msoft.com> writes:
> My thinking is simply <SPAN> tags are used to surround bits of logic. The
> web page author fills in the "blanks" with fake content for formatting, and
> the <SPAN> tags are replaced by a filter or compiler. This lets the author
> see "real pages" with "real links", but they all "go away" and are replaced
> with dynamic content by a pre-processor. Works with any HTML editor to boot!
A nice solution to this problem is Zope's PageTemplate system.
Dave Bakhash <·····@alum.mit.edu> writes:
> I don't know of any open source Lisp implementations that would be ideal
> for this work. The one that's chosen should work on both Linux and
> Win32, should support multiprocessing, be able to run Portable
> AllegroServe (possibly with some work), and have a working ODBC
> interface...at the very least.
I recently made a small scale system to keep track of time spent on
various projects at a small company (BTW I'm an ASIC designer, not an
application programmer) and it was remarkebly easy. I used CMUCL,
Portable AllegroServe, and CLSQL (which is using UFFI).
Here is an example of a function to generate a table from an sql query:
(defun query-to-table (qry)
"convert the response of a select query into a html table"
(html
((:table border 1)
(dolist (row (query qry))
(html
(:tr
(dolist (field row)
(html
(:td (:td (:princ field)))))))))))
Writing HTML code in Lisp is also easy due to the strong macro
capabilies of Lisp:
(defmacro header (&rest hforms)
"common header for all pages"
`(html
(:head (:title (:princ *title*)))
(:body )
(:h1 (:princ (concatenate 'string "Welcome to " *title*)))
((:table border 1)
(:tr
(:td ((:a :href "http://www/local") "DOLPHIN"))
(:td ((:a :href "codes") "CODES"))
(:td ((:a :href "enter") "ENTER"))
(:td ((:a :href "report") "REPORT"))
(:td ((:a :href "delentry") "DELETE"))
(:td ((:a :href "dump") "DUMP"))
(:td ((:a :href "about") "ABOUT"))))
:p
:hr
:p
(html ,@hforms)))
;; show the welcome page
(defun welcome (req ent)
"user welcome page"
(with-http-response (req ent)
(with-http-body (req ent)
(header
"Use the above buttons to select task. Please request a username "
"and password from Petter (·····@dolphinics.no) if you don't have "
"one. Please notify Petter regarding any errors"
:p
"-- Good Luck."))))
However, this application has only been in use for a short period of
time by a couple dozen users with a small number of different
browsers. The response time is very good compared to Apache based
servers with static HTML files. I don't know how this setup would
perform with a large numbers of users on the Internet.
Anybody else using the CMUCL, Portable Allegroserve, CLSQL combination
out there?
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petter
Petter Gustad <·············@gustad.com> writes:
> Anybody else using the CMUCL, Portable Allegroserve, CLSQL combination
> out there?
Almost, and I may someday :-) My `production' system is ACL + aserve +
aodbc + PostgreSQL, but just to see if it could be based on free
stuff, I've recently ported it to CMUCL + Portable aserve + CLSQL +
PostgreSQL. It took me days, and even uncovered a bug in CMUCL (which
the CMUCL maintainers fixed in less then 24 hours!), but now it works
and performs better then the ACL version (which is already faster than
Apache), though this may be due to leaving out the odbc layer.
Last year I used Java + Tomcat (I didn't have a choice) for a
commercial site, and, frankly, there was nothing there that I couldn't
have done much much more easily with CL and aserve. Aserve may be
lacking some important things that come free with Java servlets, but I
have yet to see one.
Andras