Various Topics on Lisp

..m ..adsh..

Bulent Murtezaoglu wrote:

> Whoa. Huh? Maybe you could elaborate?

No, not really.

> I wonder to what extent putting the net between programmers helps
this?
> I would ***ume truly difficult people, unless they had talent/luck to

> compensate, would eventually have to reconsider their attitude due to

> financial pressures.

Well, you can live for a long time in doing academic / research stuff,
it turns out.

..t.. ..ib..

"Thomas Schilling" <tjs_ng@yahoo.de> writes:

> Pascal Costanza <costanza@web.de> wrote:
>
>> See http://www.sdmagazine.com/do***ents/s=8993/sdm0405h/ in this context.
>
> From the above article:
>
> In Lisp, almost every position is evaluated, so, for a number
> of years, Lisp macros used only evaluated-position tags. But
> in the 1980s, the declare syntax was added, providing a
> nonevaluated position for tags.
>
> Huh? Declare syntax?

I think he's talking about DECLARE, as in:

(defun foo (x)
(declare (fixnum x)) ;; <--- this
(stuff x))

His point is the (fixnum x) expression is not evaluated.

> There's also an image stating
>
> (with-transaction
> ...)
>
> being equivalant to
>
> (declare transactional)
> ...
>
> Never heard of this. Can someone explain?

I think those are just examples of how you might use different kinds
of "tags" (his term) to accomplish the same goal. That is, you could
have a WITH-TRANSACTION macro or (in some hypothetical Lisp) a
TRANSACTIONAL declaration that causes a function body to be compiled
in some way that gives you more or less the same behavior as if it was
wrapped in a WITH-TRANSACTION macro.

-Peter

--
Peter Seibel peter@javamonkey.com

Lisp is the red pill. -- John Fraser, comp.lang.lisp

..sc.. ..stan..

Thomas Schilling wrote:

> Huh? Declare syntax? There's also an image stating
>
> (with-transaction
> ...)
>
> being equivalant to
>
> (declare transactional)
> ...
>
> Never heard of this. Can someone explain?

There is a discussion about a DEFINE-DECLARATION macro in CLtL2 (Section
8.5). This was dropped for ANSI Common Lisp.


Pascal

--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."

..n.. ..lt..

Tim Bradshaw wrote:
> Kenny Tilton wrote:
>
>>Our rather hairy/huge clinical trial data management system excelled
>
> in
>
>>each of those areas precisely because we were using Lisp. I confess I
>
>
>>was surprised when, for example, the daunting
>>configuration/release/change management problem simply disappeared in
>
>
>>the face of some nifty Lisp created to solve an unrelated problem, so
>
> I
>
>>am not surprised you got this wrong.
>>
>
>
> I'd be interested to hear more about stuff to do, for instance,
> configuration and deployment of systems that run across many machines
> (including machine allocation, OS build, network configuration, test,
> logging and so on) done in Lisp.

Plug: Hire me and I'll tell you. But see below.

On-topic: the trick is to use more Lisp, not less. Then problems which
seem to be language-neutral suddenly turn out to be perfect for Lisp.
[Cue the bit about how being developed to solve an intractably hard
problem (AI) made Lisp turn out so cool.]

> If you have a system which will
> actually do this, you should be out there getting seriously rich,
> because it is *the* problem that people want to solve at the moment
> (look at all the stuff on virtualisation / grid computing for
> instance).

I lack the domain expertise. The network maintenance problem I solved
was harder but different. You seem to know the issues. Hmmm... make that
"exchange some NDAs and we'll tell each other." Now where are those
investors' business cards I collected during the CliniSys years...

kenny


--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

..sc.. ..urguign..

Pascal Costanza <costanza@web.de> writes:

> Thomas Schilling wrote:
>
> > Huh? Declare syntax? There's also an image stating
> > (with-transaction
> > ...)
> > being equivalant to
> > (declare transactional)
> > ...
> > Never heard of this. Can someone explain?
>
> There is a discussion about a DEFINE-DECLARATION macro in CLtL2
> (Section 8.5). This was dropped for ANSI Common Lisp.

Note that you can always use declarations like this (perhaps with
another name for the operation), and "expand" them with a compiler
macro, if you've got the luck to work with an implementation that
honors them.

--
__Pascal Bourguignon__ http://www.informatimago.com/

Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.

..k..

Kenny Tilton wrote:
>
>
> Tim Bradshaw wrote:
>
>> Kenny Tilton wrote:
>>
>>> Our rather hairy/huge clinical trial data management system excelled
>>
>>
>> in
>>
>>> each of those areas precisely because we were using Lisp. I confess I
>>
>>
>>
>>> was surprised when, for example, the daunting
>>> configuration/release/change management problem simply disappeared in
>>
>>
>>
>>> the face of some nifty Lisp created to solve an unrelated problem, so
>>
>>
>> I
>>
>>> am not surprised you got this wrong.
>>>
>>
>>
>> I'd be interested to hear more about stuff to do, for instance,
>> configuration and deployment of systems that run across many machines
>> (including machine allocation, OS build, network configuration, test,
>> logging and so on) done in Lisp.
>
>
> Plug: Hire me and I'll tell you. But see below.
>
> On-topic: the trick is to use more Lisp, not less. Then problems which
> seem to be language-neutral suddenly turn out to be perfect for Lisp.
> [Cue the bit about how being developed to solve an intractably hard
> problem (AI) made Lisp turn out so cool.]
>
>> If you have a system which will
>> actually do this, you should be out there getting seriously rich,
>> because it is *the* problem that people want to solve at the moment
>> (look at all the stuff on virtualisation / grid computing for
>> instance).
>
>
> I lack the domain expertise. The network maintenance problem I solved
> was harder but different. You seem to know the issues. Hmmm... make that
> "exchange some NDAs and we'll tell each other." Now where are those
> investors' business cards I collected during the CliniSys years...

He's right that there is money to be made in it; I made a little of it
myself.

I worked for a company that built and spun out other companies. One of
our successes was a business that built a knowledge-based product that
automated the process of installing and configuring servers on a
network. I wrote the knowledge-representation bits in Lisp and then
ported them to Java (because that was the required target). It was
certainly an easier problem to solve in Lisp than in Java, and the code
got bulkier and more restrictive as it was ported.

Sun bought the company and made the folks who had chosen to spin out
with it reasonably wealthy. (that doesn't include me; I chose to stay
with the mothership. I did receive a windfall, but it was smaller than
it would have been had I accepted the invitation to spin out.)

.... ..ni..

In article <10kri8h62t6a3fa@corp.supernews.com>, Chris Capel wrote:
>
> I have a special interest in PHP. It's been proved to be able to reliably
> handle the traffic for very large sites. I'm programming a web site in
> lisp, but I keep having this nagging worry that I'm going to regret
> choosing the language if/when my site's membership grows to be 5,000-50,000
> or so. Will lisp be able to handle that sort of load without me having to
> know how to hack a webserver, or debug socket issues, or something esoteric
> like that, or depend on project maintainers to do them? I guess it would
> re***ure me to see a really big site that runs mainly on lisp.

As someone else in this thread mentioned, this should be fairly easy
to find out, using "ab" or equivalent. Unfortunately this is all I can
say as I haven't had a chance to use Lisp for web applications.

[...]
> PHP does handle those kind of loads (though it does need things like
> precompilers and such) and does it regularly. (According to Troutgirl at
> Friendster, it does it better than java.) Lisp is sort of a question mark
> here for me, though. I've heard a lot about Lisp the Language's wonders,
> but not about /implementations'/ performance and reliability in these
> situations.

For some values of "those kind of loads". PHP (and other interpreted
languages) limit your design descisions. 6 months ago I wrote a slightly
large application for my comany's site in PHP. Each page load involved
loading 16,000 lines of PHP, instantiating maybe 100 objects, and making
about 1000 method calls.

I wasn't amused when I realized that each page would consume 2 or 3
seconds of CPU time. This was on an old 300MHz processor, but still. In
the end I managed to trim the time to 1 second in some cases using a php
precompiler and making my code a bit more efficient.

So I came up with a nice, object oriented design for my application, but
in doing so I reached the scalability limit of my web server. Had I used
a compiled implementation of Common Lisp (or any compiled language, I
guess), I wouldn't have had this problem.

> I think this is a special case of the more general "Microsoft anxiety" that
> particularly affects developers, like me, that have grown up using
> Microsoft software--OS, dev. tools, etc. The perception is, with MS, /or/
> any other widely used platform, that even if something doesn't work, it's
> either /your/ fault, or a hundred people have already had the problem and
> have posted workarounds on the web, so you're never going to be screwed (at
> least by the software itself). But, in me, it's a very deep-rooted
> attitude, and it manifests itself as a fear of doing anything substantial
> in a language that isn't already doing something substantial is substantial
> cir***stances. I'm disappointed in myself, because Lisp is the greatest,
> and I'd love to have a site running in lisp, and I don't think I really
> have any /rational/ fears concerning it.

The advantage of a Lisp web platform is that it's all written in Lisp :-)
Therefore at the same time you learn the language, you should be able to
master the implementation of the web platform.

Finally, note that the web server itself doesn't need to be written in
lisp. Check out mod_lisp: an Apache module that forwards requests to a
simple non-HTTP Lisp server. Using ths should reduce your unknowns to a
minimum.

--
Eric Daniel

..n.. ..lt..

mikel wrote:

> Kenny Tilton wrote:
>
>>
>>
>> Tim Bradshaw wrote:
>>
>>> Kenny Tilton wrote:
>>>
>>>> Our rather hairy/huge clinical trial data management system excelled
>>>
>>>
>>>
>>> in
>>>
>>>> each of those areas precisely because we were using Lisp. I confess I
>>>
>>>
>>>
>>>
>>>> was surprised when, for example, the daunting
>>>> configuration/release/change management problem simply disappeared in
>>>
>>>
>>>
>>>
>>>> the face of some nifty Lisp created to solve an unrelated problem, so
>>>
>>>
>>>
>>> I
>>>
>>>> am not surprised you got this wrong.
>>>>
>>>
>>>
>>> I'd be interested to hear more about stuff to do, for instance,
>>> configuration and deployment of systems that run across many machines
>>> (including machine allocation, OS build, network configuration, test,
>>> logging and so on) done in Lisp.
>>
>>
>>
>> Plug: Hire me and I'll tell you. But see below.
>>
>> On-topic: the trick is to use more Lisp, not less. Then problems which
>> seem to be language-neutral suddenly turn out to be perfect for Lisp.
>> [Cue the bit about how being developed to solve an intractably hard
>> problem (AI) made Lisp turn out so cool.]
>>
>>> If you have a system which will
>>> actually do this, you should be out there getting seriously rich,
>>> because it is *the* problem that people want to solve at the moment
>>> (look at all the stuff on virtualisation / grid computing for
>>> instance).
>>
>>
>>
>> I lack the domain expertise. The network maintenance problem I solved
>> was harder but different. You seem to know the issues. Hmmm... make
>> that "exchange some NDAs and we'll tell each other." Now where are
>> those investors' business cards I collected during the CliniSys years...
>
>
> He's right that there is money to be made in it; I made a little of it
> myself.
>
> I worked for a company that built and spun out other companies. One of
> our successes was a business that built a knowledge-based product that
> automated the process of installing and configuring servers on a
> network. I wrote the knowledge-representation bits in Lisp and then
> ported them to Java (because that was the required target). It was
> certainly an easier problem to solve in Lisp than in Java, and the code
> got bulkier and more restrictive as it was ported.

And that was my point: more Lisp, not less.

kenny

--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

..n....

Stefan Ram schrieb:

> To me, it sometimes is amazing how the "Lisp-Difference" has
> changed. I mean, what makes Lisp or LISP different from the
> mainstream languages of its time.

Well, other language designers looked at lisp to see the end of the
line. They say: That is makeable there, how can I get it in my language.
The difference becomes smaller, kind of a natural trend. The point is,
have a look at the way other languages do that, sometimes they rebuild
large parts to enable this or that (and the programming folks have to
follow unasked).

When a lisp programmer is playing with his favorit something new will
come out as a sort of side effect. And there is always the fact that
lisp had things 20 years before other languages can imagine that this
can be done so easy. Also, what is wrong, when someone tries to realize
his impossible software dream, using the best tool he can reach for
that...

> So, Lisp programmers nowadays have to look for other areas
> that make Lisp different from other languages. Often, I hear
> about macros in this regard.

Why not sitting in a java office, dreaming from a macro heaven written
in pure java. I'm sure there is more than one person doing so (sometimes
they get money doing so). And yes, there is the "boring low", it is
large and we all use it when we turned on a PC, but there are also
shining stars. We know there is one language called the best in the
world, it is good when every language try to become that title even when
it is a newcomer in beta 0.5. What makes me angry is realising that kind
of copy features from other wolrds instead of thinking how to improve
the own finest.

As long as one can choose what he wants, as long the world is round.

stefan

.... ..rtu..

"Chris Capel" <ch.ris@iba.nktech.net> wrote in message
news:10kri8h62t6a3fa@corp.supernews.com...
> Ever since Dan B. mentioned it on his diary, I've been really wondering
what
> some experienced Lispers thought of the PHP language. Wait. Take that
back.
> I know what Lispers will say about PHP. It's a joke. Not worth mentioning.
> As Dan said, (paraphrasing) "it doesn't even have a good Emacs mode".
> Except...
>
> I have a special interest in PHP. It's been proved to be able to reliably
> handle the traffic for very large sites. I'm programming a web site in
> lisp, but I keep having this nagging worry that I'm going to regret
> choosing the language if/when my site's membership grows to be
5,000-50,000
> or so. Will lisp be able to handle that sort of load without me having to
> know how to hack a webserver, or debug socket issues, or something
esoteric
> like that, or depend on project maintainers to do them? I guess it would
> re***ure me to see a really big site that runs mainly on lisp.

WAY back (5 years?? It's been a while) when John Fedaro released
AllegroServe, he was benchmarking it at being pretty competitive with Apache
for static content. Apache "won" but not by a large margin.

It's worth coming up with some set of statistic that will make you
comfortable and testing. Not just a Lisp system, but even a PHP system. Just
because PHP is popular, doesn't mean that to get it to actually work on high
load servers doesn't take an extra bit of effort, and it's best to know that
earlier than later. Besides, you'll need to load test it when the site is
done anyway, and it's best to test it while in development as well,
regardless of the environment.

Also, you need to decide if you're absolutely committed to running a single
machine or going towards some kind of load balancer. Once you drag in a load
balancer, hardware costs are pretty minute compared to development costs and
an extra machine running Lisp may be "cheaper" and as performant as PHP
overall.

> Viaweb doesn't count. I'm probably not nearly as smart as Paul Graham.
> Orbitz doesn't count. It's just a backend. It deals with entirely
different
> issues that something like Cliki does. And Cliki doesn't have (as far as I
> know) lots and lots of traffic.
>
> PHP does handle those kind of loads (though it does need things like
> precompilers and such) and does it regularly. (According to Troutgirl at
> Friendster, it does it better than java.) Lisp is sort of a question mark
> here for me, though. I've heard a lot about Lisp the Language's wonders,
> but not about /implementations'/ performance and reliability in these
> situations.

PHP may well "do it" better than Java or Lisp, but Java and Lisp give you an
orthogonal platform from the front to back end that lets you pretty much
design your application however you want. The beauty of Java is that once
the request hits your application, it's "pure Java" all the way back to the
pipes to the database, and that mystical blob of Java can do anything you
want. Similar with Lisp (save perhaps there aren't many DB Drivers in Lisp
as there are in Java).

This, IMHO, leads to a much better design than a system tied to "pages" or
other forced organizations based on platform, or the multitude of languages
and environments that plague ASP/.NET development.

It's nice to have a consistent system handling the entire transaction
without having to continually jump and marshal across boundaries to
different environments.

> The perception is, with MS, /or/ any other widely used platform, that even
> if something doesn't work, it's either /your/ fault, or a hundred people
> have already had the problem and have posted workarounds on the web,
> so you're never going to be screwed (at least by the software itself).

Yeah, you'd like to think that. My experience has been different. It seems
everything that I'm interested in ends up with a lot of 1 post USENET
entries, where there's a lot of folks asking the question and nobody
answering them.

All of these tools rely on a solid, supportive community. I don't frequent,
say, the CMUCL mailing lists, but barring smacking right up against some
deep, internal design decision made 10 years ago that seems to be holding up
your thread scheduling or something, I'm pretty confident that there are
smart enough folks available there that can get you around any bottleneck
that you may encounter.

> But, in me, it's a very deep-rooted
> attitude, and it manifests itself as a fear of doing anything substantial
> in a language that isn't already doing something substantial is
substantial
> cir***stances. I'm disappointed in myself, because Lisp is the greatest,
> and I'd love to have a site running in lisp, and I don't think I really
> have any /rational/ fears concerning it.

I understand your fear. I've been there, done that.

Back In The Day, I had to make the same decision, and I picked the as then
"less than tested" Java platform. I did it mostly because I didn't have Lisp
folks available to me and didn't have time to train them. My one programmer
dabbled in Java. He could spell it, compile it, etc. More than I could at
the time. I truly went into it pretty blind, relying on the rising tide of
adoption on the platform, and the fact that once we learned Java, we learned
the whole system. And I can safely say that it completely saved the project
by making that choice.

How?

Before it was even deployed, this application got ported between 3 different
containers and bounced back and forth between Unix and Windows and back
again. We also had to switch from Oracle to SQL-Server (and back,
thankyouverymuch...)

Our first container locked up on us one day, and we couldn't get it figured
out, even with vendor support. So, we dumped them and a day later were
running on Apache/Tomcat. Later, we migrated to Apache/JRun (Tomcat had a
lot of fits and starts in the early days). Then my grand Unix design got
ordered from "on high" that "we do Windows now", and over to the darkside we
went. Then our CTO got fired 2 weeks from live date, so we ported back to
Unix.

Our ports were not "painless", but not overly painful. Most of the changes
were in the fringe, system setup and what not, and not in the core of the
system. That stayed stable.

Lisp and Java offer a high level of portability. If I had picked a more
proprietary platform, we would have been just dead in the water. We simply
didn't have time to "figure out" the problems we were having, and it was
easier to just jump ship and move wholesale than debug other folks
systems...and it let our core development continue, even though we were
bouncing from container to container and platform to platform.

PHP is used for all sorts of things, and I have no direct experience with
it. But I would suggest that IF (big IF) PHP ends up stonewalling you in
some way, then you will probably be stonewalled hard and painted in a corner
with a lot of momentum pushing you deeper into it.

PHP is a single (or, maybe there's two, dunno really) implementation system,
ported to Unix and Windows. It is very popular, notably because every
hosting provided on the planet provides it for free. Lots of benefits with
that.

Lisp and Java have several implementations on both Unix and Windows, and
your code will pretty much port between them. That leaves you with several
options as you move forward. It also lets you design your system however you
want, because the languages themselves are so flexible.

What I've learned at the most base level of system design is Abstraction is
the key to flexibility. That flexibility lets you weather the storms that
are thrown at you far better than a more rigid system. That flexibility lets
you tune in optimizations much more easily after you've got the system up
and running and start to test it. Lisp and Java let you abstract to quite
high levels not just the code you write, but where it runs. It lets you more
easily avoid the "pre-optimization" trap, without paying the price for it
later by tearing out code. Lisp and Java give you the flexibility to right
really ****py code and make it better later without tossing the baby out
with the bathwater.

Your predisposition towards PHP is based on hearsay. If you read this and it
sways you, it's still hearsay.

Check you ***umptions at the door, and invest some time in better evaluating
the platforms you wish to try. Set some things up, throw some load testers
at them, and let 'em run for a couple of days to see what happens.

Regards,

Will Hartung
(willh@msoft.com)