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
reassure me to see a really big site that runs mainly on lisp.
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.
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
circumstances. 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.
Hmm.
Chris Capel
--
"Even my anxieties have anxieties." --Charlie Brown
On Sun, 19 Sep 2004 12:58:32 -0500, Chris Capel <······@iba.nktech.net>
wrote:
> 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.
> 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
> reassure me to see a really big site that runs mainly on lisp.
Been a while since I looked but I believe Library of Congress uses
the MIT Lisp HTTP server. They easily take loads of 5000-50000 and
can perform advanced queries on a large database. http://www.loc.gov
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> wrote:
> Been a while since I looked but I believe Library of Congress uses
> the MIT Lisp HTTP server. They easily take loads of 5000-50000 and
> can perform advanced queries on a large database. http://www.loc.gov
the web server says "web" as server name in the HTTP header of the main
page and the search engine returns "Inktomi Search 4.3.1".
I'm interested, too, in Lisp based web servers, because it would be nice
to generate interactivly dynamic web pages with Lisp code (I've tried it
with Portable AllegroServe and clsql under CMU CL, see
http://groups.google.de/groups?selm=chv0t2%24ir%241%40newsreader2.netcologne.de ),
but I didn't found an example of a big traffic site and not very much
Lisp web servers at all. For example a Lisp web server page at
http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html lists
many links (last updated in december 2003) which should run a Lisp
server, but I've tested the first 5 links and no link worked with
CL-HTTP. There were only 3 links which worked, but returned Apache as
the server name. I hope the reason is not that the servers crashed. With
Apache I can start the server and even if some worker threads crashs,
they are started again and it runs for months without maintanance.
Simulating traffic is a good idea, but would be nice to see a high
traffic or long running production system running a Lisp webserver.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
>>>>> "CC" == Chris Capel <······@iba.nktech.net> writes:
CC> .... I'm
CC> programming a web site in lisp, but I keep having this nagging
CC> worry that I'm going to regret choosing the language if/when
CC> my site's membership grows to be 5,000-50,000 or so. Will lisp
CC> be able to handle that sort of load without me having to know
CC> how to hack a webserver, or debug socket issues, or something
CC> esoteric like that, or depend on project maintainers to do
CC> them? I guess it would reassure me to see a really big site
CC> that runs mainly on lisp. ...
Even if that were the case, I'd think that you'd test it under load that
you artificially created and see how it does? Or am I missing the point
here?
I understand the unease, but it seems possible -- if not easy -- to
alleviate it. I'd start with something simple like apache bench (man
ab if you have apache installed), and if your server can handle that
move on to app-specific floggers that you'd create.
cheers,
BM
"Chris Capel" <······@iba.nktech.net> 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
> reassure me to see a really big site that runs mainly on lisp.
With Lispworks + mod_lisp 2.38 + my framework, I get this on my server (Dual
P4 2.8GHz):
ab -n 1000 -c 20 http://www.fractalconcept.com/asp/debug
This is ApacheBench, Version 1.3d <$Revision: 1.73 $> apache-1.3
Benchmarking www.fractalconcept.com (be patient)
[...]
Finished 1000 requests
Server Software: Apache/1.3.26
Server Hostname: www.fractalconcept.com
Server Port: 80
Document Path: /asp/debug
Document Length: 617 bytes
Concurrency Level: 20
Time taken for tests: 2.248 seconds
Complete requests: 1000
Failed requests: 0
Broken pipe errors: 0
Non-2xx responses: 1000
Total transferred: 817000 bytes
HTML transferred: 617000 bytes
Requests per second: 444.84 [#/sec] (mean)
Time per request: 44.96 [ms] (mean)
Time per request: 2.25 [ms] (mean, across all concurrent requests)
Transfer rate: 363.43 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 14 6.4 14 38
Processing: 8 30 7.9 29 62
Waiting: 6 29 7.9 28 61
Total: 8 44 8.1 43 77
Percentage of the requests served within a certain time (ms)
50% 43
66% 46
75% 49
80% 50
90% 55
95% 58
98% 65
99% 69
100% 77 (last request)
This URL: http://www.fractalconcept.com/asp/debug generates a debug page
with a table that shows the different apache variable values. Here is the
lisp code:
(defun http-debug-request (request)
(log-message (format nil "http-debug-request ~%"))
(with-output-to-request (request)
(html::html-to-stream *request-stream*
"<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\">"
(:html (:head)
(:body
((:table "bgcolor" "#c0c0c0")
((:tr "bgcolor" "yellow") (:th "Key") (:th "Value"))
((:tr "bgcolor" "#F0F0c0")
(:td "apache-nb-use-socket")(:td *apache-nb-use-socket*))
(loop for (key . value) in (command request)
do (html::html ((:tr "bgcolor" "#F0F0c0")
(:td key)(:td value))))))))
(push-header "Log-Error" (format nil "request ~s not processed." (url
request)) request)))
If I remove the text generation to send a constant string as a reply, the
times are the same, so the bottleneck is probably not the html generation
part.
As I have never written any web application with anything else than Lisp
(like Java, PHP, etc.), I don't know if it is good or bad but I would be
interested to know.
Anyway I'm sure you can support a lot of simultaneous users.
Marc
Your concerns seem to center around issues dealing with heavy load.
I think one should be concerned, but concerned in a rational way.
There is more to be concerned about than Lisp when it comes to heavy
loads. There are things like:
1) The quality of your hardware. Memory, Hard Drives, Back up systems,
Power Supplies, UPS, ...
Poor hardware will fail under load, and the worst part is that you will
probably not know why.
2) The quality of your OS and its drivers. Some operating systems will
just fail under heavy utilization.
3) The interaction between your OS and hardware. (And unless you
are willing to shell out some serious dough it is likely you
will have or develop problems). For a relatively inexpensive system
my recommendation would be FreeBSD and some good PC hardware, good
motherboard (ASUS, Gigabyte), memory cooling, and other quality parts.
Then use some good Lisp (CMUCL runs on FreeBSD).
4) The design of your application. These are bugs you introduce
by making mistakes or having incomplete code.
Many of the Lisp implementations have been around for a least a
decade, used by people in heavy load situations (Viaweb and Orbitz)
for a few. It seems to take at least a decade to shake bugs out
of any significant application (this includes OSes).
Lisp meets that criteria.
One of the best features of Lisp in any application is:
HANDER-CASE/HANDLER-BIND.
When in doubt wrap everything within one of these, record any errors
that are caught and fix them.
Oh yes. Make sure you thoroughly test everything.
I really have no comments about PHP, my only experience with it
was in a project where the person delivering some functionality
was unable to deliver. Whether it was the person or PHP or
some combo of the two I am not sure.
Wade
Wade Humeniuk <····································@telus.net> writes:
>
> 3) The interaction between your OS and hardware. (And unless you
> are willing to shell out some serious dough it is likely you
> will have or develop problems). For a relatively inexpensive system
> my recommendation would be FreeBSD and some good PC hardware, good
> motherboard (ASUS, Gigabyte), memory cooling, and other quality parts.
> Then use some good Lisp (CMUCL runs on FreeBSD).
>
If you do go with FreeBSD, and it is a great choice, make sure to get
network cards that are able to use the polling interface, Intel cards
come to mind. The difference is instead of generating an interrupt
for each network packet as it come in every so often(configurable
interval) the kernel get any traffic outstanding and processes it.
This should make the box much happier under high load.
marc
Chris Capel wrote:
> 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
> circumstances. 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 think these worries are completely reasonable. If you use some
left-field system, then there will be much less information around on
how well it works and so on, so your risk of it not working at all, or
failing under load, is much higher. On the other hand, the `risk'
that it will help you do something radically better than the
competition is much higher too, and that's a good thing.
I think the choice depends on how risk-averse you are, how confident
you are in your ability to check that there are no show-stopper issues
without actually implementing the whole system, and how confident you
are in your ability to work-around any non show-stopper issues.
In my case I have decided not to push Lisp on at least a couple of
occasions because of what I suspected would be show-stopper issues
(once lack of an implementation that would support the large (> 32bit)
data sets we needed, and once worries about threading issues - we
needed native threads and I wasn't convinced that any of the
implementations had them in a usable form, or that we'd not run into
some horrible issue on the implementation(s) that did). I think these
were reasonable decisions, but I am pretty risk averse.
That being said, I think the whole `language supremacist' thing that
Lisp people are so keen on is really a bit of a red herring. Well, a
lot of a red herring in fact. Programming language choice makes less
difference than you might think, especially for large systems.
For instance, I'm currently working on a fairly large e-commerce
system: I think there are many tens (possibly several hundred)
machines, multiple database backends, interfaces to many suppliers and
so on. 90% of this is in Java. Arguably some benefit could be gained
by using Lisp (especially now that there are good Lisp<->Java
interfaces so it wouldn't be necessary to reimplement all the random
database & other crap: existing and reasonably good Java APIs could be
used for all the boring low-level stuff).
However changing to Lisp would only solve a tiny part of the problems
of this system. There are *much* more significant problems concerning
configuration and release management, testing, reliability, coherent
logging and auditing, debuggability, documentation, replicability and
so on. These problems are really nothing to do with language choice,
they're just the standard `fucked up system' issues. In fact, my
guess is that Lisp would make these problems *worse*. Doing the system
in Lisp (assuming that it could be started from scratch, so there
wouldn't be some crippling reimplementation cost) would make it,
perhaps 4 times smaller (only 4 because I only partly believe the
factor-of-10-better stuff in the first place, and because even if
that's true there is still an awful lot of boring interface-to-x stuff
which would still be large). A system that was a quarter of the size
of the current one would still be large: in particular it would still
be large enough to require serious, if boring, software engineering
stuff. But, being in Lisp, it would need Lisp programmers and,
frankly, yes, they do tend to be primadonnas, and that is absolutely
the last sort of people you want in a large project like this.
To put it concisely: you can't do large systems the same way you do
small ones: boring software engineering stuff is more important than
cool programming. Lisp (or any language) can't make large systems
into small ones if they are large enough (and `large enough' isn't
very large unfortunately). In my experience, Lisp programmers are
*less* good at the boring SW engineering stuff than, say, Java
programmers.
--tim
Tim Bradshaw wrote:
> But, being in Lisp, it would need Lisp programmers and,
> frankly, yes, they do tend to be primadonnas, and that is absolutely
> the last sort of people you want in a large project like this.
>
> To put it concisely: you can't do large systems the same way you do
> small ones: boring software engineering stuff is more important than
> cool programming. Lisp (or any language) can't make large systems
> into small ones if they are large enough (and `large enough' isn't
> very large unfortunately). In my experience, Lisp programmers are
> *less* good at the boring SW engineering stuff than, say, Java
> programmers.
I'd be interested in knowing a little bit more about peoples'
experiences working with lisp programmers. The nice thing about
nowadays is there's less lisp fundamentalism preempting any interesting
dissections on the flaws of the lisp world. (The only way to improve is
to be honest...)
MfG,
Tayssir
Tayssir John Gabbour wrote:
>
> I'd be interested in knowing a little bit more about peoples'
> experiences working with lisp programmers.
I live in hope that the proportion that are recognisably human beings
is increasing (and it does seem to be). It's low enough for
programmers of any kind, of course, but Lisp programmers certainly
used to be well below average (although I suspect there are enormous
numbers of really, really, difficult programmers who I've been lucky
enough to avoid, in areas like functional programming).
--tim
Tim Bradshaw wrote:
> Tayssir John Gabbour wrote:
>
>>I'd be interested in knowing a little bit more about peoples'
>>experiences working with lisp programmers.
>
>
> I live in hope that the proportion that are recognisably human beings
> is increasing (and it does seem to be). It's low enough for
> programmers of any kind, of course, but Lisp programmers certainly
> used to be well below average
This is lousy science, and leads to the self-fulfilling decision against
using Lisp.
The right choice would have been to take the best of the java herd you
have over there, throw Lisp saddles on them and turn them into proper
ranch work horses: faster, more nimble, and better for trips into town
for R&R.
Lisp programmers tend to be (a) very good programmers and (b) "don't
fence me in" types. I guess they also come from academia for the most
part. What a prescripion for assinity! Of course we are useless in a
group situation -- well, worse than useless because we are also
insubordinate and actively foment discontent and rebellion -- but that
is not because of the Lisp.
I mean, what about Lisp could possibly explain why I am such a jerk[1]?
destructuring-bind? eql specializers on generic methods? I have always
suspected VALUES...
:)
kenny
[1] Actually I also like COBOL and C, so I can function in corporate
settings if my cubicle is sufficiently far from the others' and I am not
told about meetings.
k
>>>>> "TimB" == Tim Bradshaw <··········@tfeb.org> writes:
Tayssir John Gabbour wrote:
>> I'd be interested in knowing a little bit more about peoples'
>> experiences working with lisp programmers.
TimB> I live in hope that the proportion that are recognisably
TimB> human beings is increasing (and it does seem to be).
Whoa. Huh? Maybe you could elaborate?
TimB> It's
TimB> low enough for programmers of any kind, of course, but Lisp
TimB> programmers certainly used to be well below average
TimB> (although I suspect there are enormous numbers of really,
TimB> really, difficult programmers who I've been lucky enough to
TimB> avoid, in areas like functional programming).
I wonder to what extent putting the net between programmers helps this?
I would assume truly difficult people, unless they had talent/luck to
compensate, would eventually have to reconsider their attitude due to
financial pressures. Probably not on a timescale of a single project
though. But then again, (applying one possible interpretation of the
'human' reference above to myself), if you don't spend much, a lucky
break does last a long time.
I'd like to hear more of this if you don't mind.
cheers,
BM
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 assume 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.
Stefan Ram wrote:
> Macros, IIRC, where not present in historic variants
> of LISP, so the "Lisp-Difference" of today might have not
> much in common with the "LISP-Difference" of 30 years ago.
I'm not sure how old macros are (someone will know) but they must be
effectively as old as sexps are - the moment you can easily read Lisp
sources with lisp and build a low-commitment structure, macros are
really only a tiny step away.
--tim
Tim Bradshaw wrote:
> Stefan Ram wrote:
>
>> Macros, IIRC, where not present in historic variants
>> of LISP, so the "Lisp-Difference" of today might have not
>> much in common with the "LISP-Difference" of 30 years ago.
>
> I'm not sure how old macros are (someone will know) but they must be
> effectively as old as sexps are - the moment you can easily read Lisp
> sources with lisp and build a low-commitment structure, macros are
> really only a tiny step away.
I think the birthdate is October 1963:
Timothy Hart, MACRO Definitions for LISP, AIM-057
See ftp://publications.ai.mit.edu/ai-publications/0-499/AIM-057.ps
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Stefan Ram wrote:
> 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. What is accomplished with macros
> roughly correspond to building special purpose languages,
> which might be implemented in other languages, too, when
> required. This might still be more effort than using Lisp-
> macros, but when the language is XML-based, tools to parse
> it to an object are already given.
See http://www.sdmagazine.com/documents/s=8993/sdm0405h/ in this context.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> wrote:
> See http://www.sdmagazine.com/documents/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? There's also an image stating
(with-transaction
...)
being equivalant to
(declare transactional)
...
Never heard of this. Can someone explain?
"Thomas Schilling" <······@yahoo.de> writes:
> Pascal Costanza <········@web.de> wrote:
>
>> See http://www.sdmagazine.com/documents/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 ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
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."
Pascal Costanza <········@web.de> wrote:
+---------------
| > (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.
+---------------
Actually, there *is* a trace of it left in ANSI CL. See the
CLHS "Declaration DECLARATION":
(declaration name*)
...
Advises the compiler that each name is a valid but
potentially non-standard declaration name. The purpose
of this is to tell one compiler not to issue warnings
for declarations meant for another compiler or other
program processor.
So if one were to say:
(declaim (declaration transactional))
then it becomes legal to later write things such as this:
(defun foo (x)
(declare transactional)
...code...)
or even something like this [for SQL fans]:
(defun foo (x)
(declare (transactional "ISOLATION LEVEL SERIALIZABLE")
...code...)
so that, as someone else noted, you could have a compiler macro
for FOO that reached in, parsed the declaration, and rewrote the
function, perhaps into this:
(defun foo (x)
(with-transaction (:isolation-level :serializable)
...code...))
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Pascal Costanza <········@web.de> wrote:
> +---------------
> | > (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.
> +---------------
>
> Actually, there *is* a trace of it left in ANSI CL. See the
> CLHS "Declaration DECLARATION":
>
> (declaration name*)
> ...
> Advises the compiler that each name is a valid but
> potentially non-standard declaration name. The purpose
> of this is to tell one compiler not to issue warnings
> for declarations meant for another compiler or other
> program processor.
I would argue against that being evidence of "a trace".
If you look at the CLtL2 description of define-declaration
(p 213, second paragraph from the botttom), you see that it
is defined _in_ _terms_ of a declaration proclamation (and thus
also a declamation). It is clear from the text that the intention
was to define one of the actions of define-declaration as being
the declaration declaration, and that they are distinct. Also,
P 236 describes the declaration declaration without change bars
(i.e. it's in CLtL1). I can't verify this, since my CLtL1 version
is not accessible currently. But if that is so, then the
declaration declaration is less of a trace than a precursor to
declaration-information.
[I actually reimplemented the declaration declaration using
define-declaration in our new environments access system; in
other words, there is a line in the declarations definitions
that looks like
(define-declaration declaration (&rest declarations)
...
I hesitated to mention it, since it could confuse things, but it
is precicely why I'm not arguing that define-declaration is
higher-level than declaration; in fact, it is the opposite. But
for this thread, the declaration declaration was never _described_
in terms of define-declaration; it was the other way around]
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Also, P 236 describes the declaration declaration without
> change bars (i.e. it's in CLtL1). I can't verify this,
> since my CLtL1 version is not accessible currently. But if
> that is so, then the declaration declaration is less of a
> trace than a precursor to declaration-information.
Verified. The declaration declaration is on pages 160 and
161 of CLtL1
(proclaim '(declaration author
target-language ....
(defun strangep(x)
(declare (author "Harry Tweeker")) ...
etc
Alan Crowe
Edinburgh
Scotland
····@rpw3.org (Rob Warnock) writes:
> or even something like this [for SQL fans]:
>
> (defun foo (x)
> (declare (transactional "ISOLATION LEVEL SERIALIZABLE")
> ...code...)
>
> so that, as someone else noted, you could have a compiler macro
> for FOO that reached in, parsed the declaration, and rewrote the
> function, perhaps into this:
>
> (defun foo (x)
> (with-transaction (:isolation-level :serializable)
> ...code...))
Uh, I'm not sure how a compiler macro is going to help--it's not going
to see the definition of FOO, it's going to see the call to FOO, no?
Seems more like you'd need to shadow DEFUN. But at that point you
don't need to declare your declaration because the declaration is just
data to your macro that will, presumably, never be seen by the
compiler.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) writes:
| > (defun foo (x)
| > (declare (transactional "ISOLATION LEVEL SERIALIZABLE")
| > ...code...)
| >
| > so that, as someone else noted, you could have a compiler macro
| > for FOO that reached in, parsed the declaration, and rewrote the
| > function, perhaps into this:
| >
| > (defun foo (x)
| > (with-transaction (:isolation-level :serializable)
| > ...code...))
|
| Uh, I'm not sure how a compiler macro is going to help--it's not going
| to see the definition of FOO, it's going to see the call to FOO, no?
| Seems more like you'd need to shadow DEFUN. But at that point you
| don't need to declare your declaration because the declaration is just
| data to your macro that will, presumably, never be seen by the compiler.
+---------------
D'oh!! What an oversight! (*blush*) Thanks for the catch!
By the way, I was just about to write a self-followup suggesting
shadowing DEFUN, but not for the reason you note. Even if I hadn't
been so wrongheaded about using compiler macros, I was going to
suggest shadowing DEFUN anyway so you could automatically define
a compiler macro for every DEFUN that contained one of those magic
declarations in it... whereupon, as you note, the need for compiler
macros goes away completely.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Peter Seibel <·····@javamonkey.com> writes:
> ····@rpw3.org (Rob Warnock) writes:
>
> > or even something like this [for SQL fans]:
> >
> > (defun foo (x)
> > (declare (transactional "ISOLATION LEVEL SERIALIZABLE")
> > ...code...)
> >
> > so that, as someone else noted, you could have a compiler macro
> > for FOO that reached in, parsed the declaration, and rewrote the
> > function, perhaps into this:
> >
> > (defun foo (x)
> > (with-transaction (:isolation-level :serializable)
> > ...code...))
>
> Uh, I'm not sure how a compiler macro is going to help--it's not going
> to see the definition of FOO, it's going to see the call to FOO, no?
> Seems more like you'd need to shadow DEFUN. But at that point you
> don't need to declare your declaration because the declaration is just
> data to your macro that will, presumably, never be seen by the
> compiler.
Oops! Right, compiler macros are not the right tool for this job.
You'll have to transform the function source before
compiling/interpreting, overriding DEFUN.
--
__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.
Pascal 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.
Tim Bradshaw wrote:
> Chris Capel wrote:
>
>
>>I think this is a special case of the more general "Microsoft
>
> anxiety" that
>
> .... Programming language choice makes less
> difference than you might think, especially for large systems.
>
> For instance, I'm currently working on a fairly large e-commerce
> system: I think there are many tens (possibly several hundred)
> machines, multiple database backends, interfaces to many suppliers and
> so on. 90% of this is in Java. Arguably some benefit could be gained
> by using Lisp (especially now that there are good Lisp<->Java
> interfaces so it wouldn't be necessary to reimplement all the random
> database & other crap: existing and reasonably good Java APIs could be
> used for all the boring low-level stuff).
>
> However changing to Lisp would only solve a tiny part of the problems
> of this system. There are *much* more significant problems concerning
> configuration and release management, testing, reliability, coherent
> logging and auditing, debuggability, documentation, replicability and
> so on. These problems are really nothing to do with language choice,
> they're just the standard `fucked up system' issues. In fact, my
> guess is that Lisp would make these problems *worse*.
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. :)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
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. 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).
--tim
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
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.)
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
Kenny Tilton wrote:
>
>
> mikel wrote:
>> 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.
Sure.
You're right: it was far easier to write the app in Lisp.
He's right: ease of writing the app was much the smaller part of the
problem.
Kenny Tilton wrote:
>
> I lack the domain expertise. The network maintenance problem I solved
> was harder but different.
I doubt it was harder in any real sense, because I'm fairly sure I can
frame it as a subproblem of the general problem I'm interested in .
Yes, I don't know what it is, but I'm willing to make `the general
problem' pretty general (note, I haven't specified it, and this
article is way too small to do so...)
> You seem to know the issues.
yes, I do. And that's my point. There are two issues: understand what
the problems *are* (this is hard, almost no-one has any kind of idea,
developers least of all), and then formulate some kind of solution to
it (this is also hard, and great chunks of the solution are not to do
with programming but to do with `social' issues, particularly the
social issue of taking about 90% of your developers outside and
shooting them). Then there might be some minor issues like
programming language choice and so on but, frankly, the difference
between using Java (say) and Lisp might be a factor of 10 of 5% of the
problem, so that's 4.5% easier, maybe.
Programming language choice is like deciding on metric signature or
whether touse natural units in relativity or something: yes, it does
matter. If you don't understand relativity it can look like it
matters a lot because signs change everywhere and things like c and G
vanish in natural units. But when you do understand GR, these choices
turn out to be completely in the noise.
Understanding the problem is the hard bit.
--tim
Tim Bradshaw wrote:
> Kenny Tilton wrote:
>
>>I lack the domain expertise. The network maintenance problem I solved
>
>
>>was harder but different.
>
>
> I doubt it was harder in any real sense, because I'm fairly sure I can
> frame it as a subproblem of the general problem <snip> (note, I haven't specified it, and this
> article is way too small to do so...)
Then suffice it to say I had a nightmare of a network configuration
management problem sitting as yet unaddressed in the corner like a 600
pound (270kg) gorilla and when I hit upon a decent solution to a
performance issue I looked up and the gorilla was gone.
>
>
>>You seem to know the issues.
>
>
> yes, I do. And that's my point...
And my point is that it sounds like Mikel already solved the problem
which you believed would be the same no matter what language you used.
By using Lisp to write an application to solve what you believed was a
sys admin task.
More Lisp, not less! It is a failure of imagination not to realize that
network configuration, testing, et al is just another application. Write
it with Lisp (and Cells and persistent CLOS) and watch what happens.
> ... There are two issues: understand what
> the problems *are* (this is hard, almost no-one has any kind of idea,
> developers least of all), ...
I thought that was a prescription for Lisp. As Paul Graham (whose
English teachers apparently never told him not to use contractions in
writing) said: "And if you're not sure yet what kind of program you're
writing, it's a safe bet to write it in Lisp." Let us tidy up that and
convert to adspeak: "Lisp. When you do not know what you are doing." But
I digress.
> developers least of all), and then formulate some kind of solution to
> it (this is also hard, and great chunks of the solution are not to do
> with programming but to do with `social' issues, particularly the
> social issue of taking about 90% of your developers outside and
> shooting them)...
So now the objection to Lisp is that it will work too well on this
problem? We are making progress! But it sounds like your firm will be so
successful with your new automated network configuration tool that you
will have enough new business to keep the java monkeys busy as bees.
> ... Then there might be some minor issues like
> programming language choice and so on but, frankly, the difference
> between using Java (say) and Lisp might be a factor of 10 of 5% of the
> problem, so that's 4.5% easier, maybe.
>
> Programming language choice is like deciding on metric signature or
> whether touse natural units in relativity or something: yes, it does
> matter. If you don't understand relativity it can look like it
> matters a lot because signs change everywhere and things like c and G
> vanish in natural units. But when you do understand GR, these choices
> turn out to be completely in the noise.
> Understanding the problem is the hard bit.
Let's get back to the basics. The original issue was advice to a newbie
to dump Lisp for a hard problem because most of the problem was not a
matter of application programming. Mikel solved that hard problem by
writing a Lisp application (what I had in mind). Nothing is not
potentially an application problem.
And I made the point that, precisely because I was using Lisp and Cells
and even a persistent Lisp DB, a scary hard network configuration and
maintenance problem disappeared. ie, Lisp did not help me find a way to
solve something I did not know how to solve, it exposed the problem as a
faulty view of the required functionality. A solution to a performance
issue forced a clearer view in which the problem did not exist. The
solution was in Lisp and relied crucially on qualities exclusive to Lisp.
There's an old saying. Think you can or think you cannot, either way you
will be right. Something like that.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
> And my point is that it sounds like Mikel already solved the problem
> which you believed would be the same no matter what language you
used.
> By using Lisp to write an application to solve what you believed was
a
> sys admin task.
Well, as he said:
You're [Kenny] right: it was far easier to write the app in Lisp.
He's [tfb] right: ease of writing the app was much the smaller
part of the problem.
That's the point I'm trying to make in a nutshell.
Or, to put it another way: the problems I'm describing are technical
to only a small degree. A technical fix can only fix that small
degree. It is a classic programmer mistake to assume that *most* of
the problems of large systems are programming-related: they aren't.
--tim
"Tim Bradshaw" <··········@tfeb.org> writes:
> Programming language choice is like deciding on metric signature or
> whether touse natural units in relativity or something: yes, it does
> matter. If you don't understand relativity it can look like it
> matters a lot because signs change everywhere and things like c and G
> vanish in natural units. But when you do understand GR, these choices
> turn out to be completely in the noise.
> Understanding the problem is the hard bit.
But I think you've just shown that language choice is very important.
Using natural units allows one to focus on the real problems at hand
instead of being saddled with fiddling around with constants. The choice
may be in the noise, but the choice is to get RID of the noise created
by those constants. Then the problem becomes much easier to see.
Likewise, Lisp allows one to abstract over the details of how some
iteration is done and focus on what end result is desired. The tasks can
even be split up: one person can describe what he wants the system to do
and communicate with the business analysts to explore the possible
behaviors and the other can figure out how to implement the operators
used to create that description as Lisp code.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
>
> But I think you've just shown that language choice is very important.
> Using natural units allows one to focus on the real problems at hand
> instead of being saddled with fiddling around with constants. The
choice
> may be in the noise, but the choice is to get RID of the noise
created
> by those constants. Then the problem becomes much easier to see.
No. It makes some difference, but not very much, and possibly not
always in a good direction (it's way easier to make dimension errors).
I used to use natural units because they were cooler and more macho,
but eventually I found myself putting in explicit constants again
because I made less mistakes. But in either direction, the difference
wssn't large, compared to, say, understanding what intrinsic curvature
was, or what `sufficiently smooth' meant. No one failed as a
relativist because they didn't use natural units.
--tim
Stefan Ram wrote:
> "Tim Bradshaw" <··········@tfeb.org> writes:
>
>>That being said, I think the whole `language supremacist' thing
>>that Lisp people are so keen on is really a bit of a red
>>herring. Well, a lot of a red herring in fact. Programming
>>language choice makes less difference than you might think,
>>especially for large systems.
>
>
> 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.
>
> It used to be the garbage collector and the ease with which
> dynamic data structures, such as trees, can be built. What was
> called "AI programming" often needed such features.
>
> Nowadays, a mainstream language, such as Java, has support for
> garbage collection and several kinds of dynamic collections.
You are holding the wrong end of the spear. The above translates to
"Other languages are getting better as they painfully, slowly, halting
become more like Lisp". That just translates to "Lisp is better", and in
turn "Use Lisp".
>
> Then, LISP had support for a kind of literal of trees or
> graphs, i.e., S-expressions. So the datastructures could not
> only be programmed using lisp, but the constant data needed
> could also be written as S-expressions. Nowadays, XML is often
> used for the same purpose in Java, for example, to configure
> the tool "Ant", which fulfills a purpose similar to the UNIX
> "make" tool.
Whoa, nelly! How about writing source code qua sexprs?
>
> So, Lisp programmers nowadays have to look for other areas
> that make Lisp different from other languages.
One swallow does not a summer make. Copying GC or GFs or any detail does
not make Java into Lisp.
Often, I hear
> about macros in this regard. What is accomplished with macros
> roughly correspond to building special purpose languages,
> which might be implemented in other languages, too, when
> required. This might still be more effort than using Lisp-
> macros, but when the language is XML-based, tools to parse
> it to an object are already given.
Nah. The whole point of macros is that they are part of Lisp and written
in Lisp. This reminds me of Norvig's hand-waving when he tried to turn
regex parsing into Lisp macros because it could be used to create an
embedded language.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
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
"Tim Bradshaw" <··········@tfeb.org> wrote in message news:<························@k26g2000oda.googlegroups.com>...
> lot of a red herring in fact. Programming language choice makes less
> difference than you might think, especially for large systems.
If programming language choice is a minor issue, at least in large
systems, why isn't Lisp used more often?
Paolo
Paolo Amoroso wrote:
> "Tim Bradshaw" <··········@tfeb.org> wrote in message news:<························@k26g2000oda.googlegroups.com>...
>
>
>>lot of a red herring in fact. Programming language choice makes less
>>difference than you might think, especially for large systems.
>
>
> If programming language choice is a minor issue, at least in large
> systems, why isn't Lisp used more often?
A great Lisp ignorance!
Lisp is not new, and not hyped. It simply works. Little hypesters trying to sell
you Lisp as snake oil.
This leads to:
Lack of qualified Lisp programmers.
Lack of Lisp-educated management.
Lack of Lisp-related "mainstream" literature.
Managers think: "Everybody uses J2EE, it must be the right choice."
Coders think: "Java and C++ give me a job anywhere."
And, IMHO, being a good Lisp coder takes more understanding in programming than
churning out code in C/C++ and Java. So there are automatically likely to be
less Lisp programmers than those for those other languages.
Structured programming, object-orientation, etc., all those techniques can lead
to more reliable quality code, but it takes better programmers/designers to get
it right. Likewise with Lisp, especially since it is a multi-paradigm language.
With kind regards,
Oliver
Paolo Amoroso wrote:
> "Tim Bradshaw" <··········@tfeb.org> wrote in message news:<························@k26g2000oda.googlegroups.com>...
>
>
>>lot of a red herring in fact. Programming language choice makes less
>>difference than you might think, especially for large systems.
>
>
> If programming language choice is a minor issue, at least in large
> systems, why isn't Lisp used more often?
Because the comfort of people working together is not a minor issue, and
everyone knows that Lisp is a failure.
(Never mind that Lisp is not a failure; it is often the case that
everyone knows something that is untrue.)
mikel <·····@evins.net> writes:
> Because the comfort of people working together is not a minor issue,
> and everyone knows that Lisp is a failure.
>
> (Never mind that Lisp is not a failure; it is often the case that
> everyone knows something that is untrue.)
The average programmer will probably know that "Lisp" is some kind of
weird programming language, but probably know nothing about it. This
includes whether it failed or not. :)
Regards,
--
____________________________
Julian Stecklina / _________________________/
________________/ /
\_________________/ LISP - truly beautiful
·······@mclink.it (Paolo Amoroso) wrote in message news:<····························@posting.google.com>...
>
> If programming language choice is a minor issue, at least in large
> systems, why isn't Lisp used more often?
Change is expensive, so you want to concentrate on the things that do
make a large difference, when you have the ability to make changes at
all.
--tim
Paolo Amoroso wrote:
> "Tim Bradshaw" <··········@tfeb.org> wrote in message news:<························@k26g2000oda.googlegroups.com>...
> > lot of a red herring in fact. Programming language choice makes less
> > difference than you might think, especially for large systems.
>
> If programming language choice is a minor issue, at least in large
> systems, why isn't Lisp used more often?
I realize you're making a clever point. But it reminds me of
something. Perhaps you know what it is, so feel free to skip this
message.
In that Barstow/Shrobe book _Interactive Programming Environments_,
what lispers tend not to mention is that Kernighan/et al paper's
conclusion about why unix was successful. Not technical reasons,
though it had to fulfill a minimum technical bar. Rather, it was able
to take root in an organization on orphaned machines, since it was
cheap and pirate copies of the sourcecode were floating around, and it
could start to grow like a tumor.
People tend to think of Technical Dominance as some grand arc, that
lords over the unwashed masses. To the contrary, there's specifics
involved.
I claim that lispers have always known how to make lisp successful in
the metric of marketshare. They just weren't willing to do it.
There was one other "tech" which survived from that book. Not the
visual Smalltalk or Interlisp systems. Instead it was described in
Stallman's paper; Emacs. And that programming "language" is used quote
often in large systems.
From what I hear, K and Rebol are profitable. They're just not
successful in the marketshare metric as well. If they simply changed
to focus on marketshare, it's quite possible they'd see a predictable
tradeoff occur.
I still think the biggest issue that people don't get past is the fact
that a programming language is just another program, like an OS or
word processor. The term "programming language" should lose some of
its luster, despite it being perhaps an especially rewarding program.
MfG,
Tayssir
--
Observations of a circus which travelled to Iraq (note the left
sidebar):
http://www.circus2iraq.org/updates.asp
On 24 Sep 2004 00:42:31 -0700, ···········@yahoo.com (Tayssir John Gabbour) wrote:
> From what I hear, K and Rebol are profitable.
Do you have more details about that? Just curious.
Thanks,
Edi.
--
"Lisp doesn't look any deader than usual to me."
(David Thornley, reply to a question older than most languages)
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On 24 Sep 2004 00:42:31 -0700, ···········@yahoo.com (Tayssir John
Gabbour) wrote:
> > From what I hear, K and Rebol are profitable.
>
> Do you have more details about that? Just curious.
Since I can't find any evidence on that in a few minutes of googling,
I'll have to retract that. I guess that leaves my message as nearly a
pure rant.
MfG,
Tayssir
"Tayssir John Gabbour" <···········@yahoo.com> wrote in message
·····························@k26g2000oda.googlegroups.com...
> Edi Weitz wrote:
> > On 24 Sep 2004 00:42:31 -0700, ···········@yahoo.com (Tayssir John
> Gabbour) wrote:
> > > From what I hear, K and Rebol are profitable.
> >
> > Do you have more details about that? Just curious.
>
> Since I can't find any evidence on that in a few minutes of googling,
> I'll have to retract that. I guess that leaves my message as nearly a
> pure rant.
Also, neither is selling a a programming language simply for programming.
Rebol is selling a specific style of applications developed in their
language, and K is the backend of their other products.
You could argue that this is similar to what Xanalys does with LispWorks.
Beings as it is central to their other products, they are maintaining
LispWorks both for their owns sakes as well as their LispWorks customers.
But if they had to rely solely on LispWorks sales, perhaps it would be
profitable at all.
Also, you could observe Sun and Java, where the language is given away while
they focus on the actual products developed on top of the platform. It is
the tool set, application servers and frameworks that make Java particularly
attractive today.
Java found its "killer app", Rebol is trying to make their own. Lisp had its
Killer App Back In The Day. LispWorks Killer App is their own product line.
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung wrote:
> Also, neither is selling a a programming language simply for
programming.
> Rebol is selling a specific style of applications developed in their
> language, and K is the backend of their other products.
Yes, Apple doesn't just sell a computing box and MSFT isn't just in the
OS business. Regardless, both of those are strategic to the companies
involved.
The only reason I retracted was because... I suspect I was posting
under an emotional influence and I'm not interested in reviewing my
points for correctness. I'll delete my messages from Google tomorrow.
MfG,
Tayssir
"Chris Capel" <······@iba.nktech.net> wrote in message
····················@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
> reassure 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
> circumstances. 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 crappy 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 assumptions 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
(·····@msoft.com)
Chris Capel wrote:
> "Even my anxieties have anxieties." --Charlie Brown
Thanks, everyone, for the great advice. Load testing isn't very familiar to
me--it hadn't occurred, but it does sound like a great way to increase my
confidence in my code and platform. Because in any project, the vast
majority of problems are your own. And for the ones that aren't, with the
smaller size of the Lisp community, I'll get personal attention for them I
would never get from a larger project or company.
And I guess part of it is guts--having faith that the advantages of the
language will empower me once I learn it well. Now that I think about it,
that's probably the root of my hesitation, and probably the source of
many's rejection of Lisp in favor of their own status quo.
I do think lisp is the best choice for this project. It's something I'm
working on for myself, so I have complete control and responsibility for
everything.
It warms me to know there's such a nice newsgroup here to reassure me. (And
Kenny is elated.)
Chris Capel
In article <···············@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
> reassure 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
> circumstances. 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
On Mon, 20 Sep 2004 23:54:06 -0000, Eric Daniel <···········@barberic.org> wrote:
> 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 can second that. I had to investigate PHP code written by someone
else because it was much too slow for our app. It turned out that this
happened because he had used PHP's joke of "OOP" (this was PHP4, I
guess this might have changed a bit in PHP5) extensively. His code
didn't have any bugs, he just made the (wrong) decision to trust PHP
to be fast enough - it wasn't. Rewriting his code by throwing out the
OOP stuff and hand-tune some other parts solved the performance
problem but for me it was just another nail in my private PHP coffin.
Edi.
--
"Lisp doesn't look any deader than usual to me."
(David Thornley, reply to a question older than most languages)
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
"Edi Weitz" <········@agharta.de> wrote
> I can second that. I had to investigate PHP code written by someone
> else because it was much too slow for our app. It turned out that this
> happened because he had used PHP's joke of "OOP" (this was PHP4, I
> guess this might have changed a bit in PHP5) extensively. His code
> didn't have any bugs, he just made the (wrong) decision to trust PHP
> to be fast enough - it wasn't. Rewriting his code by throwing out the
> OOP stuff and hand-tune some other parts solved the performance
> problem but for me it was just another nail in my private PHP coffin.
People interested in real-life web development in Common Lisp should come to
the Amsterdam Lisp meeting (Sept 26 2004).
There will be 3 presentations related to web applications.
From the meeting schedule:
Peter van Eynde will talk about building dynamic web sites with Araneida.
Edi Weitz will talk about TBNL and mod_lisp.
Marc Battyani (that's me ;-) will talk about his web application
framework.
I will also show some real life applications that can't be done in PHP nor
in Java. :)
More info here:
http://www.xs4all.nl/~alemmens/lisp/meetings/september-2004.html
Marc
Some of those of us who can't attend will greatly appreciate presentations,
notes, and slides. I know audio is difficult to capture and deliver but it
would be nice on my end if it were possible :) It sounds like you will have
a terrific meeting, good luck.
Jeff
"Marc Battyani" <·············@fractalconcept.com> wrote in message ...
> People interested in real-life web development in Common Lisp should come
to
> the Amsterdam Lisp meeting (Sept 26 2004).
>
> There will be 3 presentations related to web applications.
> From the meeting schedule:
> Peter van Eynde will talk about building dynamic web sites with
Araneida.
> Edi Weitz will talk about TBNL and mod_lisp.
> Marc Battyani (that's me ;-) will talk about his web application
> framework.
>
> I will also show some real life applications that can't be done in PHP nor
> in Java. :)
>
> More info here:
> http://www.xs4all.nl/~alemmens/lisp/meetings/september-2004.html
>
> Marc
>
>
>>>>> "JC" == Jeff Caldwell <·········@yaSPhooAM.com> writes:
JC> Some of those of us who can't attend will greatly appreciate
JC> presentations, notes, and slides. [...]
I was thinking about the same thing. Is there a way to capture both the
slides and the person in a movie? (SMIL?) If it is just a matter of
hiring a student and giving him a camera for a day, I am sure those of
us who are saving the airfare by not going would chip in. Bandwidth is a
solvable problem, I think. (bittorrent etc.)
cheers,
BM
Bulent Murtezaoglu wrote:
> >>>>> "JC" == Jeff Caldwell <·········@yaSPhooAM.com> writes:
>
> JC> Some of those of us who can't attend will greatly appreciate
> JC> presentations, notes, and slides. [...]
>
> I was thinking about the same thing. Is there a way to capture both
the
> slides and the person in a movie? (SMIL?) If it is just a matter of
> hiring a student and giving him a camera for a day, I am sure those
of
> us who are saving the airfare by not going would chip in. Bandwidth
is a
> solvable problem, I think. (bittorrent etc.)
Intelligent idea. Let me add a little direction to the discussion,
though. The significant problem is not technical, but social. (And a
little financial too. ;) This is an informal meeting (despite having
20-30 people) and the big question is about peoples' desires not to
have their words spread all over the internet. For a formal lecture,
this is no problem; but lispers tend to think impolitic thoughts which
the mainstream programming world considers heretical.
So it would help if the brainstorming included thoughts on how to
respect the speakers' natural desire for privacy.
The shitcanning of Troutgirl, as reported on lemonodor, is a cautionary
tale. Especially the semipermeable blogging paper. The reluctance of a
certain poster on this thread to expand on his point is perfectly
reasonable in that light.
Incidentally, some may have have a natural motivation to release
recordings/slides. Say, to help their consulting firm. That's certainly
no problem to worry about.
MfG,
Tayssir
--
Observations of a circus which travelled to Iraq (note the left
sidebar):
http://www.circus2iraq.org/updates.asp
Hi Tayssir,
Ignoring the "social problem" for now (we can always think about
that after the meeting, before releasing anything), I can probably
get hold of a digital video camera. I don't know anything about
cameras though (never touch the bloody things), so technically
speaking you'll be on your own.
Please let me know if you would like to do this,
Arthur
(with-my-alu-hat-on ()
"If things go well, we could make a product out of the recordings that
could be sold by the ALU for a couple of bucks. This would be a great
way of getting the ALU a bit more into the picture.")
Arthur Lemmens <········@xs4all.nl> wrote in message news:<················@news.xs4all.nl>...
> (with-my-alu-hat-on ()
> "If things go well, we could make a product out of the recordings that
> could be sold by the ALU for a couple of bucks. This would be a great
> way of getting the ALU a bit more into the picture.")
I would definitely be willing to pay something for a copy of the
video. It sounds like a great meeting (more like a mini-conference
than a user group meeting) and I wish I could attend.
--
Bill Clementson
Tayssir John Gabbour wrote:
> So it would help if the brainstorming included thoughts on how to
> respect the speakers' natural desire for privacy.
I think it's probably good enough if we warn all participants
that they'll be recorded and give the speakers the right to
censor the publication of their own presentation.
Arthur
Arthur Lemmens wrote:
> Tayssir John Gabbour wrote:
> > So it would help if the brainstorming included thoughts on how to
> > respect the speakers' natural desire for privacy.
>
> I think it's probably good enough if we warn all participants
> that they'll be recorded and give the speakers the right to
> censor the publication of their own presentation.
Oh, definitely. In case I wasn't clear here on usenet:
1) I will not release to anyone but the speaker.
2) I will not ask about releasing it.
3) The speaker has 100.2% control over distribution.
Plus I'm fine doing whatever censorship.
Just thought if people are talking about it, I'd add some input,
because I personally was surprised at this being a factor. I hope no
one got the impression I was blowing this all up into something messy
and difficult. It's pretty simple, really.
MfG,
Tayssir
--
Observations of a circus which travelled to Iraq (note the left
sidebar):
http://www.circus2iraq.org/updates.asp
Arthur Lemmens schrieb:
> Tayssir John Gabbour wrote:
>
>> So it would help if the brainstorming included thoughts on how to
>> respect the speakers' natural desire for privacy.
>
>
> I think it's probably good enough if we warn all participants
> that they'll be recorded and give the speakers the right to
> censor the publication of their own presentation.
One thing which could be seen as a little disadvantage is, that when the
participants know they will be on film, then it can create some pressure
on them. In two ways. First, speaking will not be so free anymore, as
one gets the feeling one has to be really good cause so many others will
see the video.
And about the censorship... if most participants give away their okay
for publicising the material it gets harder for others (without NDA) to
say no.
Just some ideas.
Andr�
--
Bulent Murtezaoglu <··@acm.org> wrote:
> I was thinking about the same thing. Is there a way to capture
> both the slides and the person in a movie?
Tayssir John Gabbour is going to make audio recordings of the
presentations in Amsterdam. Maybe he can switch to video. Of course,
the speakers themselves will have the final word about releasing
any recordings (some of them need to be careful with NDA's and
other legalities that I'd rather not think about ;-).
Thanks for the suggestion.
Arthur
On Tue, 21 Sep 2004 09:50:13 +0200, "Marc Battyani" <·············@fractalconcept.com> wrote:
> People interested in real-life web development in Common Lisp should
> come to the Amsterdam Lisp meeting (Sept 26 2004).
>
> There will be 3 presentations related to web applications.
> From the meeting schedule:
> Peter van Eynde will talk about building dynamic web sites with Araneida.
> Edi Weitz will talk about TBNL and mod_lisp.
> Marc Battyani (that's me ;-) will talk about his web application
> framework.
>
> I will also show some real life applications that can't be done in
> PHP nor in Java. :)
>
> More info here:
> http://www.xs4all.nl/~alemmens/lisp/meetings/september-2004.html
Note that my talk is announced to be about "mod_lisp and TBNL (or
maybe something else)" - it currently looks like I'll talk about
"something else," whatever that means... :)
If people are interested in a talk about the basics of mod_lisp and
TBNL I might do that for the next Hamburg Lispers meeting. But I think
Marc's and Peter's approaches will be much more interesting from a
Lisp point of view anyway.
Cheers,
Edi.
--
"Lisp doesn't look any deader than usual to me."
(David Thornley, reply to a question older than most languages)
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Henry Lenzi <····@void.org> wrote:
> Do some Google searching on this group.
> IIRC, Howard Dean's web site ran on CL-HTTP.
the server HTTP-header field says "Apache/1.3.28 (Unix) PHP/4.3.4
mod_perl/1.28".
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Henry Lenzi <····@void.org> wrote in message news:<··············@samadhi.i-did-not-set--mail-host-address--so-shoot-me>...
> Hi Chris --
>
> Do some Google searching on this group.
> IIRC, Howard Dean's web site ran on CL-HTTP.
>
> Cheers.
> Henry L.
No, some internal application for the campaign
was written with CL-HTTP.
Before that, the publications server (not the default website!)
for the Whitehouse (Clinton/Gore) ran on Open Genera with CL-HTTP.
Plus there were some other applications in that area like "Open Meeting"
(Vice President AL Gore's Open Meeting on the National Performance Review.)
were written with CL-HTTP.
Orbitz seemed to use some HTML generation from CL-HTTP.
(http://www.itasoftware.com/acknowledgements/)
www.booble.com (adult search engine, be careful) seems to
use CL-HTTP's template engine. (See the HTML source of the homepage).
Etc.
······@corporate-world.lisp.de (Rainer Joswig) writes:
> Henry Lenzi <····@void.org> wrote in message news:<··············@samadhi.i-did-not-set--mail-host-address--so-shoot-me>...
>> Hi Chris --
>>
>> Do some Google searching on this group.
>> IIRC, Howard Dean's web site ran on CL-HTTP.
>>
>> Cheers.
>> Henry L.
>
> No, some internal application for the campaign
> was written with CL-HTTP.
>
> Before that, the publications server (not the default website!)
> for the Whitehouse (Clinton/Gore) ran on Open Genera with CL-HTTP.
Speaking of which, is it just me or are many of the links at
<http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html>
broken? Such as all the links to ftp.ai.mit.edu and wilson.ai.mit.edu.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> wrote:
> Speaking of which, is it just me or are many of the links at
>
> <http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html>
>
> broken? Such as all the links to ftp.ai.mit.edu and wilson.ai.mit.edu.
Nearly no link worked, and the few external links which worked looks like
they are served by Apache (see my posting in this thread:
http://groups.google.de/groups?selm=cikm9j%24l4l%241%40newsreader2.netcologne.de )
Perhaps the server is as mature as described on the page, but the
broken links doesn't look good.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> Peter Seibel <·····@javamonkey.com> wrote:
>
>
>>Speaking of which, is it just me or are many of the links at
>>
>> <http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html>
>>
>>broken? Such as all the links to ftp.ai.mit.edu and wilson.ai.mit.edu.
>
> Nearly no link worked, and the few external links which worked looks like
> they are served by Apache (see my posting in this thread:
> http://groups.google.de/groups?selm=cikm9j%24l4l%241%40newsreader2.netcologne.de )
>
> Perhaps the server is as mature as described on the page, but the
> broken links doesn't look good.
The MIT AI Lab doesn't exist anymore but has merged with another lab.
See http://www.ai.mit.edu/ - maybe this explains why some of their pages
don't work correctly anymore.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
In article <··············@javamonkey.com>,
Peter Seibel <·····@javamonkey.com> wrote:
> ······@corporate-world.lisp.de (Rainer Joswig) writes:
>
> > Henry Lenzi <····@void.org> wrote in message news:<··············@samadhi.i-did-not-set--mail-host-address--so-shoot-me>...
> >> Hi Chris --
> >>
> >> Do some Google searching on this group.
> >> IIRC, Howard Dean's web site ran on CL-HTTP.
> >>
> >> Cheers.
> >> Henry L.
> >
> > No, some internal application for the campaign
> > was written with CL-HTTP.
> >
> > Before that, the publications server (not the default website!)
> > for the Whitehouse (Clinton/Gore) ran on Open Genera with CL-HTTP.
>
> Speaking of which, is it just me or are many of the links at
>
> <http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html>
>
> broken? Such as all the links to ftp.ai.mit.edu and wilson.ai.mit.edu.
Yeah, the department moved to another building plus the AI lab
and the CS lab joined. Some stuff just didn't survive.
Dunno when this will change... After ten years and some
alternatives, interest in CL-HTTP is a bit lower now. But it still
works nicely, though parts of the code are ten years old. ;-)
If you were interested to download CL-HTTP you could
do that from my home Macintosh G4 running CL-HTTP
on LispWorks. Please understand that the machine is
behind a simple ADSL line and may not be available
all the time:
http://lispm.dyndns.org/cl-http/distribution/
The latest published version is 70.190a (which I have
running on my Mac).
This is a screenshot of LispWorks for Macintosh running
CL-HTTP on my home Mac:
http://lispm.dyndns.org/osx-lisp-env/lwm-panther-2.jpg
For me this combination has a high fun factor. LispWorks
and CL-HTTP has been used for some production stuff
and should run quite nicely. CL-HTTP bug reports are
welcome (to the mailing list). The port of CL-HTTP
to LispWorks is supported by the fine people from
Xanalys /http://www.lispworks.com).
They are making sure that especially the low-level
bits are in place. ;-) But CL-HTTP should also be working on CMUCL
(less often used), ACL should work, MCL should work (though
MCL's TCP/IP interface is less stable). And of course
it works in Genera and Open Genera. In the last years
I have been able to check CL-HTTP on all these platforms.
Still LispWorks and Open Genera are the best platforms for
deploying production level CL-HTTP servers and for development
of those.
I use it also as a proxy and a web client (not a browser, though).
I sometimes read my mail with the mail-archive functionality
and do some of my mail maintenance with its POP3 code.
In case of an error it sends backtraces via mail.
There is also an remote listener and remote log window.
Plus the home page of my home machine: http://lispm.dyndns.org/
······@corporate-world.lisp.de (Rainer Joswig) writes:
> Henry Lenzi
> > Hi Chris --
> >
> > Do some Google searching on this group.
> > IIRC, Howard Dean's web site ran on CL-HTTP.
> >
> > Cheers.
> > Henry L.
>
> No, some internal application for the campaign
> was written with CL-HTTP.
>
Was that internal application under heavy load?
Or was that just for the office people?
I believe the point was the load a lisp server can support.
Any info on this, under this particular case?
Regs,
Henry
Henry Lenzi <·······@but.reply.to.newsgroup.org> wrote in message news:<··············@but.reply.to.newsgroup.org>...
> ······@corporate-world.lisp.de (Rainer Joswig) writes:
>
> > Henry Lenzi
> > > Hi Chris --
> > >
> > > Do some Google searching on this group.
> > > IIRC, Howard Dean's web site ran on CL-HTTP.
> > >
> > > Cheers.
> > > Henry L.
> >
> > No, some internal application for the campaign
> > was written with CL-HTTP.
> >
> Was that internal application under heavy load?
I don't think so.
The CL-HTTP-based whitehouse publications server was probably under
much more
heavy load. Especially during the time of the Clinton/Lewinsky
thing. ;-)
My guess is anyway that performance for Lisp-based web servers
nowadays is not much of a problem. Lisp is fast enough and
there are enough ways you can scale these. My current
work is for a Java-based website which does some pretty
hefty computing with just two SPARCs for the application (plus some
other machines), and which delivers all in all over Apache frontend
servers
about 800 MB data a day (which is not that much, given that there are
some other sites here, which should have MUCH more traffic).
A Lisp-based web server should be comparable. GC-tuning is an issue.
If one machine is not enough, add some more machines plus a load
balancer,
which is not that expensive anymore, given that you use BSD/Linux/...
and
some Intel/AMD/PowerPC hardware.
I haven't tried to really compute the performance of CL-HTTP (or some
other Lisp-based webserver), but that would not be that hard
(given that you do some basic tuning like setting some resource
pool sizes, number of threads, ...). Btw., CL-HTTP has some code,
called 'flogger', to do performance testing.
see http:client;flogger.lisp
Rainer Joswig
> Or was that just for the office people?
> I believe the point was the load a lisp server can support.
> Any info on this, under this particular case?
>
> Regs,
>
> Henry
Chris Capel <······@iba.nktech.net> wrote in message news:<···············@corp.supernews.com>...
> 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.
I don't know what your definition of "lots and lots" is, but here's a
couple of numbers for Araneida apps that I do know. Back in February
2004 (the latest time I have a report for), CLiki was serving around
20Mb a day, fairly evenly spread out over those 24 hours. Another
Lisp site on the same machine was doing 70Mb, mostly to UK customers
(most traffic served at UK lunchtime and evenings). That's average,
and the uptime on those apps is ... well, indefinite. (Sometimes I
restart CLiki when I've deleted a bunch of pages because it's the
easiest way to get them out of the indexes.) The other day we had a
sudden rush and were serving about 10-20 requests a second at 10% cpu
utilisation.
What does this say about Lisp in high load situations? Well, even
assuming that you consider 10-20 requests a second as "high", still
not very much -
- every page in the site (aside from graphics) is programmatically
generated, but
- there's a cache/proxy in front of the Araneida, and we go to
reasonable lengths to ensure that all our pages have sensible
Last-Modified and Expires headers. So, programmatically generated but
infrequently updated pages are cached "for free". Whatever your
"scripting" language, a page which doesn't use it at all is probably
going to be served faster than one that does.
- and the database interface is still the bottleneck. (Actually,
literally so: there's a bug in the installed version of SBCL that
means the stream connected to the database is unbuffered and we do a
syscall per character)
This is all on a single Athlon 2600 with half a gig of ram: perhaps
not a machine you can find in a cornflake packet yet, but hardly
difficult or expensive to obtain either.
> 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
That's not what Troutgirl said. I point you especially at
http://troutgirl.com/blog/index.php?/archives/34_Udell_column.html :
"He makes exactly the right point: the programming language itself was
not really the issue". Oddly enough, this is the same point as most
people in this thread have made.
> 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).
I wish this were true, but my experience has been more along the lines
of "three people have already had the problem and nobody could help
them with it, unless that post in (some language that neither I or
Babelfish speaks) contained a solution". Maybe I have weird problems.