Hi everybody,
excuse me if this sounds kind of blasphemous, but I'm asking myself what
the advantages of Lisp are, compared e.g. with Java. I have to say that
I use Lisp just for a couple of days, and I can already see that lists
are supported very nicely. I also like the fact that I can use functions
as parameters in Lisp (and I probably don't see all the consequences out
of this fact). But still?
Maybe someone can point me to a website or faq where this is pointed out
a little bit...
Thanks,
Christian
Christian Soltenborn wrote:
> Hi everybody,
>
> excuse me if this sounds kind of blasphemous, but I'm asking myself what
> the advantages of Lisp are, compared e.g. with Java. I have to say that
> I use Lisp just for a couple of days, and I can already see that lists
> are supported very nicely. I also like the fact that I can use functions
> as parameters in Lisp (and I probably don't see all the consequences out
> of this fact). But still?
>
> Maybe someone can point me to a website or faq where this is pointed out
> a little bit...
http://www.pascalcostanza.de/lisp/guide.html might be helpful.
http://alu.cliki.net is a very good starting point to find links to
Lisp-related stuff.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Christian Soltenborn wrote:
> Hi everybody,
>
> excuse me if this sounds kind of blasphemous, but I'm asking myself what
> the advantages of Lisp are, compared e.g. with Java. I have to say that
> I use Lisp just for a couple of days, and I can already see that lists
> are supported very nicely. I also like the fact that I can use functions
> as parameters in Lisp (and I probably don't see all the consequences out
> of this fact). But still?
>
> Maybe someone can point me to a website or faq where this is pointed out
> a little bit...
Sounds like you are writing the comparison now. :) Just keep going and
every day you fill find something new and better: Dynamic typing,
macros, special variables, multiple inheritance, multi-methods, native
compilation, and even the parentheses to help with editing in
semantically meaningful chunks.
Also, think "design intent", not just features: in the end, IIUC, Java
and Lisp stand at polar extremes, with Java trying to keep the
programmer from shooting themself (hence the strait jacket) while Lisp
does everything it can to stay out of the developer's way.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Christian Soltenborn <···················@web.de> writes:
> Hi everybody,
>
> excuse me if this sounds kind of blasphemous, but I'm asking myself
> what the advantages of Lisp are, compared e.g. with Java.
Having just spent^H^H^H^H^H wasted an entire day fighting with Java
and JBOSS, I've come to the conclusion that the main advantage of Lisp
is that it allows you to not use Java. The baroqueness of those
systems never ceases to astound me.
Alain Picard <·································@memetrics.com> wrote in message news:<··············@memetrics.com>...
> Having just spent^H^H^H^H^H wasted an entire day fighting with Java
> and JBOSS, I've come to the conclusion that the main advantage of Lisp
> is that it allows you to not use Java. The baroqueness of those
> systems never ceases to astound me.
I think you've misdiagnosed the problem. JBOSS is indeed a seething
nightmare. But I don't think that's because of Java, it's because
it's 2004, and we're a good way down the software complexity
catastrophe. If you want to write some system which talks to a lot of
other systems now, you're going to spend an enormous amount of time
implementing enormous amounts of stuff which is just there because the
stuff you have to talk to is, well, complicated, and there's a lot of
it. I'm fairly sure that a big lisp middleware framework would *also*
be a seething nightmare: the *world* (of software) is a seething
nightmare, and interfacing with it is naturally nightmarish.
Of course, as this progresses, more and more time is spent just
managing complexity, and less and less doing useful work, until
eventually the complexity event horizon is passed, and all further
work is managing complexity. We may already be past that point - as
with event horizons in physics you may not know when you've passed
through one (actually in physics you do, at least in the simple cases,
because the sky goes white and you fry, but you don't get crushed to
death as you pass the horizon).
··········@tfeb.org (Tim Bradshaw) writes:
> But I don't think that's because of Java, it's because
> it's 2004, and we're a good way down the software complexity
> catastrophe.
I don't think you're quite right, some of the complexity is created by
trying to brute-force solve difficult problems without the proper
understanding and with the wrong tools. I glimpsed through some RDF
stuff the other day, and my impression was: boy, are these people
creating a lot of mess with their bloated xml machinery without
bringing _any_ insight into the problem of knowledge representation
which hasn't been there for at least 20 years (or 2000 years. There
hasn't been that many great discoveries in semantics since Aristotle
;-)).
(side note: somebody used the term RDF and I thought he was referring
to the XML stuff, but of course he was thinking of "Reality
Distortion Field". But then, is there much of a difference ;-)?)
--
(espen)
"Espen Vestre" <·····@*do-not-spam-me*.vestre.net> wrote in message
···················@merced.netfonds.no...
> ··········@tfeb.org (Tim Bradshaw) writes:
>
> > But I don't think that's because of Java, it's because
> > it's 2004, and we're a good way down the software complexity
> > catastrophe.
>
> I don't think you're quite right, some of the complexity is created by
> trying to brute-force solve difficult problems without the proper
> understanding and with the wrong tools. I glimpsed through some RDF
> stuff the other day, and my impression was: boy, are these people
> creating a lot of mess with their bloated xml machinery without
> bringing _any_ insight into the problem of knowledge representation
> which hasn't been there for at least 20 years
What bothers me most about RDF is all the stuff they aren't bringing into
the problem of KR which HAS been there for at least 20 years.
Doesn't anyone read Barwise and Perry anymore?
Gorbag wrote:
> "Espen Vestre" <·····@*do-not-spam-me*.vestre.net> wrote in message
> ···················@merced.netfonds.no...
>
>>··········@tfeb.org (Tim Bradshaw) writes:
>>
>>
>>>But I don't think that's because of Java, it's because
>>>it's 2004, and we're a good way down the software complexity
>>>catastrophe.
>>
>>I don't think you're quite right, some of the complexity is created by
>>trying to brute-force solve difficult problems without the proper
>>understanding and with the wrong tools. I glimpsed through some RDF
>>stuff the other day, and my impression was: boy, are these people
>>creating a lot of mess with their bloated xml machinery without
>>bringing _any_ insight into the problem of knowledge representation
>>which hasn't been there for at least 20 years
>
>
> What bothers me most about RDF is all the stuff they aren't bringing into
> the problem of KR which HAS been there for at least 20 years.
>
> Doesn't anyone read Barwise and Perry anymore?
>
>
I think that XML is the new cobol. Bloated, slow, uniformative and
using it gives the appearance of ability
mark wrote:
> Gorbag wrote:
>
>> "Espen Vestre" <·····@*do-not-spam-me*.vestre.net> wrote in message
>> ···················@merced.netfonds.no...
>>
>>> ··········@tfeb.org (Tim Bradshaw) writes:
>>>
>>>
>>>> But I don't think that's because of Java, it's because
>>>> it's 2004, and we're a good way down the software complexity
>>>> catastrophe.
>>>
>>>
>>> I don't think you're quite right, some of the complexity is created by
>>> trying to brute-force solve difficult problems without the proper
>>> understanding and with the wrong tools. I glimpsed through some RDF
>>> stuff the other day, and my impression was: boy, are these people
>>> creating a lot of mess with their bloated xml machinery without
>>> bringing _any_ insight into the problem of knowledge representation
>>> which hasn't been there for at least 20 years
>>
>>
>>
>> What bothers me most about RDF is all the stuff they aren't bringing into
>> the problem of KR which HAS been there for at least 20 years.
>>
>> Doesn't anyone read Barwise and Perry anymore?
>>
>>
> I think that XML is the new cobol. Bloated, slow, uniformative and
> using it gives the appearance of ability
I really have to disagree here. XML is extremely handy for
unambiguously representing small to medium amounts of information in a
way that is easy for both computers and people to parse.
Bloated? Most of the DTDs/Schema that have been created are bloated,
but XML itself is not a horribly inefficient way of storing data.
Slow? Only if you keep things in XML form too long. Parse, process,
and re-encode.
Uninformative, I presume you mean? You've been looking at the wrong XML
if you find this to be the case.
Gives the appearance of ability? Yeah, this may be true. The problem
is more that it's way too easy to claim mad XML skillz and have none.
To me, the main problem with XML is that it is overused in inappropriate
places. Jabber is an example of an appropriate use (even if the
protocol was designed based on a flawed understanding of XML
namespaces). XML-RPC is another good example, except that XML-RPC
itself is overused in inappropriate places - it's not highly responsive
but Microsoft et al. would have you believe it is.
On Fri, 20 Feb 2004 00:06:27 -0700, Ari Johnson <·····@hotmail.com> wrote:
> I really have to disagree here. XML is extremely handy for
> unambiguously representing small to medium amounts of information in a
> way that is easy for both computers and people to parse.
>
> Bloated? Most of the DTDs/Schema that have been created are bloated,
> but XML itself is not a horribly inefficient way of storing data.
>
> Slow? Only if you keep things in XML form too long. Parse, process,
> and re-encode.
>
> Uninformative, I presume you mean? You've been looking at the wrong XML
> if you find this to be the case.
>
> Gives the appearance of ability? Yeah, this may be true. The problem
> is more that it's way too easy to claim mad XML skillz and have none.
>
> To me, the main problem with XML is that it is overused in inappropriate
> places. Jabber is an example of an appropriate use (even if the
> protocol was designed based on a flawed understanding of XML
> namespaces). XML-RPC is another good example, except that XML-RPC
> itself is overused in inappropriate places - it's not highly responsive
> but Microsoft et al. would have you believe it is.
I think in the lisp community there is less enthusiasm for XML than in the
java community.
The real reason is that lisp l-expressions provide the same expressive
power in a form that is
easier to process in lisp.
Note that (command data #|...|#) looses the 'echo' effect you get in XML.
( <mycommand>data</mycommand> )
You might argue that XML allows better error recovery but then most XML is
machine generated anyhow.
The only real reson to use XML I can think of is to communicate withe
other programs that
use of write XML.
John
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
John Thingstad <··············@chello.no> writes:
> You might argue that XML allows better error recovery but then most XML is
> machine generated anyhow.
There is redundancy for sure, but that doesn't mean ipso facto better
error recovery. With an XML expression such as this:
<foo>a<bar>b</foo>
It is impossible to tell whether there is an extraneous <bar> tag or a
missing </bar> tag (or even a missing /> in the bar tag).
With this:
<fox>a</foz>
Which is misspelled?
> The only real reson to use XML I can think of is to communicate withe
> other programs that use of write XML.
yep
--
~jrm
* Joe Marshall wrote:
> It is impossible to tell whether there is an extraneous <bar> tag or a
> missing </bar> tag (or even a missing /> in the bar tag).
But it's possible to tell that *something* is wrong.
--tim
John Thingstad <··············@chello.no> writes:
> I think in the lisp community there is less enthusiasm for XML than
> in the java community. The real reason is that lisp l-expressions
> provide the same expressive power in a form that is easier to
> process in lisp. Note that (command data #|...|#) looses the 'echo'
> effect you get in XML. ( <mycommand>data</mycommand> ) You might
> argue that XML allows better error recovery but then most XML is
> machine generated anyhow. The only real reson to use XML I can
> think of is to communicate withe other programs that use of write
> XML.
it could have been <mycommand myarg="data"/>
what could have been lisp for (i'm just curious):
<foo bar="1" baz="blabla">
some loose text
<program>
<![CDATA[
// this is cool embedded program
some_program()
{
if (a > b) {
do_this_and_that("hello, worlds\n");
}
}
// this is the end of cool embedded program
]]>
</program>
again loose text
</foo>
--
gr{oe|ee}t{en|ings}
artm
Artem Baguinski <····@v2.nl> writes:
> <foo bar="1" baz="blabla">
> some loose text
> <program>
> <![CDATA[
> // this is cool embedded program
> some_program()
> {
> if (a > b) {
> do_this_and_that("hello, worlds\n");
> }
> }
> // this is the end of cool embedded program
> ]]>
> </program>
> again loose text
> </foo>
There are a couple of choices. How about something like:
(foo (bar 1)
(baz "blabla")
"some loose text"
(lambda () (if (> a b) (do-this-and-that "Hello, World~%")))
"again loose text")
If you want to keep the tag structure more formally, you could have
something like
(foo (:bar 1 :baz "blabla")
"some loose text"
(lambda () (if (> a b) (do-this-and-that "Hello, World~%")))
"again loose text")
Note in particular that the Lisp S-Expression syntax allows you to
indicate whether the value of bar should be the integer 1 or the string
"1", something that XML is really bad at. (And something I'm currently
struggling with -- sigh).
--
Thomas A. Russ, USC/Information Sciences Institute
Artem Baguinski wrote:
> what could have been lisp for (i'm just curious):
>
> <foo bar="1" baz="blabla">
> some loose text
> <program>
> <![CDATA[
> // this is cool embedded program
> some_program()
> {
> if (a > b) {
> do_this_and_that("hello, worlds\n");
> }
> }
> // this is the end of cool embedded program
> ]]>
> </program>
> again loose text
> </foo>
(foo (:bar "1" :baz "blabla")
"some loose text"
(defun some-program (a b)
(when (> a b)
(do-this-and-that "hello, worlds~%")))
"again loose text
we can even span several lines")
...and by the way, here is a little program that gives this form some
semantics:
(defmacro foo (options text1 form text2)
(unless (and (listp options)
(stringp text1)
(listp form)
(stringp text2))
(error "There's something wrong."))
`(progn
(format t "~A: ~A~%" :bar ,(getf options :bar))
(format t "~A: ~A~%" :baz ,(getf options :baz))
(format t "~A~%" ,text1)
,form
(format t "~A~%" ,text2)))
See an example interaction with a Common Lisp listener:
CL-USER 1 > (foo (:bar "1" :baz "blabla")
"some loose text"
(defun some-program (a b)
(when (> a b)
(do-this-and-that "hello, worlds~%")))
"again loose text
we can even span several lines")
BAR: 1
BAZ: blabla
some loose text
again loose text
we can even span several lines
NIL
CL-USER 2 > (some-program 5 6)
NIL
CL-USER 3 > (some-program 6 5)
Error: Undefined function DO-THIS-AND-THAT called with arguments
("hello, worlds~%").
1 (continue) Try invoking DO-THIS-AND-THAT again.
2 Return some values from the call to DO-THIS-AND-THAT.
3 Try invoking something other than DO-THIS-AND-THAT with the same
arguments.
4 Set the symbol-function of DO-THIS-AND-THAT to another function.
5 (abort) Return to level 0.
6 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other
options
CL-USER 4 : 1 > (defun do-this-and-that (arg)
(format t arg))
DO-THIS-AND-THAT
CL-USER 5 : 1 > :c 1
hello, worlds
NIL
The "1 >" in "CL-USER 4" means that we are in an error handler.
The ":c 1" in "CL-USER 5" means that we want to continue with the first
option presented when the error occurred. ("Try invoking
DO-THIS-AND-THAT again.")
What could have been XML for that? (You're allowed to make use of Java
or C# to make this work.)
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> writes:
> Artem Baguinski wrote:
>
>> what could have been lisp for (i'm just curious):
>>
>> <foo bar="1" baz="blabla">
>> some loose text <program>
>> <![CDATA[
>> // this is cool embedded program
>> some_program() {
>> if (a > b) {
>> do_this_and_that("hello, worlds\n");
>> }
>> }
>> // this is the end of cool embedded program
>> ]]>
>> </program>
>> again loose text
>> </foo>
>
> (foo (:bar "1" :baz "blabla")
> "some loose text"
> (defun some-program (a b)
> (when (> a b)
> (do-this-and-that "hello, worlds~%")))
> "again loose text
> we can even span several lines")
i really meant to have some ugly java in CDATA.
i meant "how do you include in lisp a chunk of text which might
contain large number of confusing characters and combinations?" and
not "how do you embed a program in data?". sorry for my laconism that
caused confusion ;)
> ...and by the way, here is a little program that gives this form some
> semantics:
>
> (defmacro foo (options text1 form text2)
> (unless (and (listp options)
[...]
yes, that looked like a lot of fun ;)
> What could have been XML for that? (You're allowed to make use of Java
> or C# to make this work.)
no idea. my knowledge of in XML/Java field is just as tiny as in
lisp's. i'd like to improve the latter, that's why i asked. thank you
for the answer.
--
gr{oe|ee}t{en|ings}
artm
Artem Baguinski wrote:
> Pascal Costanza <········@web.de> writes:
>
>>Artem Baguinski wrote:
>>
>>>what could have been lisp for (i'm just curious):
>>>
>>><foo bar="1" baz="blabla">
>>> some loose text <program>
>>> <![CDATA[
>>> // this is cool embedded program
>>> some_program() {
>>> if (a > b) {
>>> do_this_and_that("hello, worlds\n");
>>> }
>>> }
>>> // this is the end of cool embedded program
>>> ]]>
>>> </program>
>>> again loose text
>>></foo>
>>
>>(foo (:bar "1" :baz "blabla")
>> "some loose text"
>> (defun some-program (a b)
>> (when (> a b)
>> (do-this-and-that "hello, worlds~%")))
>> "again loose text
>> we can even span several lines")
>
> i really meant to have some ugly java in CDATA.
OK:
(foo (:bar "1" :baz "blabla")
"some loose text"
(progam
"some_program() {
if (a > b) {
do_this_and_that(\"hello, worlds\\n\");
}
}")
"again loose text
we can even span several lines")
Giving this thing semantics is left as an exercise to the reader. ;)
However, the real question is: Why would anyone want to embed a string
of Java code into a Lisp program?!?
> i meant "how do you include in lisp a chunk of text which might
> contain large number of confusing characters and combinations?" and
> not "how do you embed a program in data?". sorry for my laconism that
> caused confusion ;)
No problem. ;)
>>What could have been XML for that? (You're allowed to make use of Java
>>or C# to make this work.)
>
> no idea. my knowledge of in XML/Java field is just as tiny as in
> lisp's. i'd like to improve the latter, that's why i asked. thank you
> for the answer.
You're welcome.
The point is: Lisp has the unique feature that code and data are the
same. That's why I can embed Lisp code in data sections of my program,
and convert it to code on the fly. No explicit processing of this thing
is required. In the XML world there are no predefined semantics what it
means to have data represent code. So you have to add lots of additional
technology in order to make this work.
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> writes:
> Artem Baguinski wrote:
>> i really meant to have some ugly java in CDATA.
>
> OK:
>
> (foo (:bar "1" :baz "blabla")
> "some loose text"
> (progam
> "some_program() {
> if (a > b) {
> do_this_and_that(\"hello, worlds\\n\");
> }
> }")
> "again loose text
> we can even span several lines")
so there's no way to say <<<EOF
bla bla "quoted bla"
EOF
or something?
> Giving this thing semantics is left as an exercise to the reader. ;)
;)
> However, the real question is: Why would anyone want to embed a string
> of Java code into a Lisp program?!?
the keyword was "ugly", not "java" ;) i was wondering if there was a
way to avoid escaping too much.
--
gr{oe|ee}t{en|ings}
artm
Artem Baguinski <····@v2.nl> writes:
> so there's no way to say <<<EOF
> bla bla "quoted bla"
> EOF
>
> or something?
Check out "reader macros" in your favorite Lisp reference.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
From: Marco Baringer
Subject: Re: Advantages of Lisp?
Date:
Message-ID: <m2oert1zd2.fsf@bese.it>
Artem Baguinski <····@v2.nl> writes:
> so there's no way to say <<<EOF
> bla bla "quoted bla"
> EOF
>
> or something?
there's no way to say something without having to escape the end
marker, but this is true in every quoting mechanism (except the
obscenly broken "<!CDATA" which can not, in any way what so ever,
contain the string "]]>").
if you want perl like here docs a simple read macro could be written
for it:
(defun read-here-doc (stream sub-char prefix)
(declare (ignore sub-char prefix))
(with-output-to-string (doc)
(loop
with end-marker = (read-line stream t nil t)
for line = (read-line stream t nil t)
until (string= line end-marker)
do (write-line line doc))))
(set-dispatch-macro-character #\# ··@ #'read-here-doc)
now you can use ·@EOF in place of the <<<EOF.
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
On Fri, 20 Feb 2004 17:31:52 +0100, Artem Baguinski <····@v2.nl> wrote:
> so there's no way to say <<<EOF
> bla bla "quoted bla"
> EOF
Others have already mentioned reader macros. Another cool aspect of
Common Lisp: You can significantly change its syntax if you wish
without being an implementor.
For an example of what can be done with reader macros see
<http://weitz.de/cl-interpol/>.
CL-INTERPOL doesn't provide the syntax you've asked for above but it's
a little hack to have a string syntax similar to Perl's. Also note
that this happens at read time, i.e. something like
(defun frob (x)
(let ((a (foo x)))
#?"foo: ${a}"))
is translated to, say,
(defun frob (x)
(let ((a (foo x)))
(with-output-to-string (s)
(write-string "foo: " s)
(princ a s))))
and then optionally compiled. At run time the strange "string" is gone
and there's no need to translate it again.
Edi.
Artem Baguinski schrieb:
>
> ...
>
> i meant "how do you include in lisp a chunk of text which might
> contain [expressions in a syntax other than common-lisp's default].
> sorry for my laconism that caused confusion ;)
>
as has been pointed out in other responses, the common-lisp reader can
accommodate much more than s-expressions. as two additional examples,
take a look at meta[0] or the cl-xml xml-rpc example[1,2], which
demonstrates integrated lisp, xml templates, and xhtml-based documentation.
...
[0] http://www.cliki.net/Meta
[1]
http://home.arcor.de/james_anderson/setf/library/de/setf/xml/xml-rpc/index.html
(css required)
[2] http://home.arcor.de/james_anderson/setf/library/de/setf/xml/xml-rpc/index.lisp
* Artem Baguinski wrote:
> i meant "how do you include in lisp a chunk of text which might
> contain large number of confusing characters and combinations?" and
> not "how do you embed a program in data?". sorry for my laconism that
> caused confusion ;)
A good way to do this (which is easy to implement) is to have a reader
macro which looks for its next character, and then will look for that
sequence backwards to terminate the form, before handing it to
whatever you want. You probably want something hairier which
indicates to what to hand it, of course. But, assuming we use #\[ as
the reader macro:
(foo (bar ...
[! anything but ! followed by ] is not magic here !])
[~ and in here it's ~ then ] ... ~]))
We use a modified form of this for literal text in our `dtml' markup system:
<document :title "foo"
<p|hello there>
<|" literal text "|>>
Here <| is the magic sequence, and it looks at the next character,
then looks for the appropriate reverse sequence.
You can obviously extend this as far as you like if you are worried
about completely random 2-char sequences occurring...
--tim
John Thingstad <··············@chello.no> wrote in message news:<················@news.chello.no>...
> The only real reson to use XML I can think of is to communicate withe
> other programs that
> use of write XML.
There is a tendency for lispers to overintellectualize the argument.
Just ask the next rabid XML fan you meet, "S-expressions are such a
good data format, lispers want to write all their programs in it. Can
that be said about the XML contingent?"
I am sure they'll say, "Well some things are data and others are
code." But the germ of the idea will spread, and they'll notice they
store their code on the hard drive just as they would "data." And
they grep through it and write tools to treat it just like data...
And despite all that, they'd never rewrite their Java and Python code
into XML. Because XML is not readable, and all those people who claim
it is are perverting the truth into doublespeak. You can get anyone
to say bad is good and worse is better.
Tayssir John Gabbour:
| There is a tendency for lispers to overintellectualize the argument.
| Just ask the next rabid XML fan you meet, "S-expressions are such a
| good data format, lispers want to write all their programs in it. Can
| that be said about the XML contingent?"
|
| I am sure they'll say, "Well some things are data and others are
| code." But the germ of the idea will spread, and they'll notice they
| store their code on the hard drive just as they would "data." And
| they grep through it and write tools to treat it just like data...
| And despite all that, they'd never rewrite their Java and Python code
| into XML. Because XML is not readable, and all those people who claim
| it is are perverting the truth into doublespeak. You can get anyone
| to say bad is good and worse is better.
I am not so sure of that...
<http://sys-con.com/linux/article.cfm?id=936>
<http://www.sys-con.com/xml/article.cfm?id=788>
--
Sebastian Stern
"Freedom is the freedom to say (= (+ 2 2) 4). If that is granted, all else
follows."
"Sebastian Stern" <··············@wanadoo.nl> writes:
> <http://www.sys-con.com/xml/article.cfm?id=788>
From above article:
> Basic S-Expressions syntax does not support argument keys, and there
> is no one standard for adding keys, although there are several
> different ways people have attempted to add keys to S-Expressions.
Well this comes as a surprise to me. I could have sworn I saw
mention of keyword arguments for functions in Common Lisp.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber <·············@verizon.net> writes:
> "Sebastian Stern" <··············@wanadoo.nl> writes:
> > <http://www.sys-con.com/xml/article.cfm?id=788>
> From above article:
> > Basic S-Expressions syntax does not support argument keys, and
> > there is no one standard for adding keys, although there are
> > several different ways people have attempted to add keys to
> > S-Expressions.
> Well this comes as a surprise to me. I could have sworn I saw
> mention of keyword arguments for functions in Common Lisp.
That'd probably be an "attempt". (Not every Lisp is Common Lisp;
therefore it's not successful, obviously. What the other attempts are,
I can't tell, and the author doesn't seem to. Using symbols� is one
possibility; using SYMBOL-NAMEs, like LOOP, is another. It could
probably reasonably be argued that that isn't "basic S-Expressions
syntax" nor a "one standard".)
1) Like CL; some people seem not to be aware that that's what &key
arguments are, given the overwhelming preference for symbols in
the keyword package.
Regards,
'mr
--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_
"Sebastian Stern" <··············@wanadoo.nl> writes:
> Tayssir John Gabbour:
> | There is a tendency for lispers to overintellectualize the argument.
> | Just ask the next rabid XML fan you meet, "S-expressions are such a
> | good data format, lispers want to write all their programs in it. Can
> | that be said about the XML contingent?"
> |
> | I am sure they'll say, "Well some things are data and others are
> | code." But the germ of the idea will spread, and they'll notice they
> | store their code on the hard drive just as they would "data." And
> | they grep through it and write tools to treat it just like data...
> | And despite all that, they'd never rewrite their Java and Python code
> | into XML. Because XML is not readable, and all those people who claim
> | it is are perverting the truth into doublespeak. You can get anyone
> | to say bad is good and worse is better.
>
> I am not so sure of that...
> <http://sys-con.com/linux/article.cfm?id=936>
> <http://www.sys-con.com/xml/article.cfm?id=788>
The author of that article does not know that sexps support "keyed"
arguments as well as (or better than) the alternatives:
(book :isbn "0764525360" :year 2002 :title "Water Language")
Perhaps he did not present enough of ConciseXML to contrast it with
normal XML, or there really isn't much difference between the two;
which is ConciseXML, which is XML?
<book isbn="0764525360" title="Water Language" copyright="2002"/>
<book "0764525360" title="Water Language" copyright=2002/>
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
>> <http://www.sys-con.com/xml/article.cfm?id=788>
>
> The author of that article does not know that sexps support "keyed"
> arguments as well as (or better than) the alternatives:
>
> (book :isbn "0764525360" :year 2002 :title "Water Language")
Ouch, reading that article was physically painful :-(
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Pascal Bourguignon <····@thalassa.informatimago.com> writes:
>
>>> <http://www.sys-con.com/xml/article.cfm?id=788>
>>
>> The author of that article does not know that sexps support "keyed"
>> arguments as well as (or better than) the alternatives:
>>
>> (book :isbn "0764525360" :year 2002 :title "Water Language")
>
> Ouch, reading that article was physically painful :-(
Must be the pointy brackets.
--
~jrm
I forgot an important point.
Security.
l-exp are more powerfull than XML.
This is a problem in a secure environment.
I have a user that uses a configure file to run code as root.
This needs to be prevented.
Is it cheaper to use l-exp than compiling XML to l-exp and providing the
same integrity?
sorry
I need to ask
JOHN
(espen ?)
"John Thingstad" <··············@chello.no> wrote in message
·····················@news.chello.no...
> I forgot an important point.
> Security.
>
> l-exp are more powerfull than XML.
> This is a problem in a secure environment.
> I have a user that uses a configure file to run code as root.
> This needs to be prevented.
> Is it cheaper to use l-exp than compiling XML to l-exp and providing the
> same integrity?
Huh?
Security has nothing to do with either XML or SExprs.
And for a vast number of domains, SExprs aren't particularly more "powerful"
than XML. CL itself make SExprs powerful, as I can gurantee you that the
crude SExpr reader I wrote for Java doesn't make them any more powerful, we
just wanted something more compact to represent strucured data, specifically
unlabled strcutured data.
Security boils down you what you do with the data, regardless of format.
Regards,
Will Hartung
(·····@msoft.com)
* Will Hartung wrote:
> Security has nothing to do with either XML or SExprs.
It has something to do with it. It's fairly hard in CL to avoid
spurious symbols being interned in fairly arbitrary packages. You can
do so, but it's not that easy. A real industrial
read-arbitrary-input reader (which is *not* what the CL reader was
designed for!) would have better features to control the conversion of
strings to objects I think.
--tim
> From: Tim Bradshaw <···@cley.com>
> It's fairly hard in CL to avoid spurious symbols being interned in
> fairly arbitrary packages. You can do so, but it's not that easy. A
> real industrial read-arbitrary-input reader (which is *not* what the
> CL reader was designed for!) would have better features to control
> the conversion of strings to objects I think.
I agree, assuming you mean a bunch of parameters similar to *read-eval*
which control whether colons or double-colons are allowed for referring
to external or internal symbols in other packages (and in the latter
case to actually create a new symbol in another package), to limit the
number of characters in a symbol's print-name, to limit the number of
digits in a literal number, to limit the number of characters in a
literal string, etc.
Does any vendor's implementation of READ and READ-FROM-STRING already
include this parameterization? Does anybody know of a privately
modified version of READ and/or READ-FROM-STRING which do this?
Note that for CGI applications, except for *read-eval* there's not
really any problem, since the CGI process can simply crash upon
exhausting resources or upon discovering that READ-FROM-STRING has
maliciously mentionned a symbol in another package from the allowed
one, and all who is hurt is the person who tried to breach security,
not any other CGI users. Still it'd be nice to have READ-FROM-STRING do
all the work instead of having to traverse the resultant s-expression
after that before EVALuating it.
> Date: Sun, 22 Feb 2004 17:51:12 +0000
(I didn't see your article when it first appeared, because I didn't
have any efficient method for finding all followups (to stuff I had
posted) until just a few nights ago when I finally found your article
and put it in the queue to compose a followup myself. Sorry for very
belated response.)
"Gorbag" <·············@nospam.mac.com> writes:
> What bothers me most about RDF is all the stuff they aren't bringing into
> the problem of KR which HAS been there for at least 20 years.
Sure!
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote in message news:<··············@merced.netfonds.no>...
> I don't think you're quite right, some of the complexity is created by
> trying to brute-force solve difficult problems without the proper
> understanding and with the wrong tools. I glimpsed through some RDF
> stuff the other day, and my impression was: boy, are these people
> creating a lot of mess with their bloated xml machinery without
> bringing _any_ insight into the problem of knowledge representation
> which hasn't been there for at least 20 years (or 2000 years. There
> hasn't been that many great discoveries in semantics since Aristotle
> ;-)).
>
yes, I think that is clearly correct: there seems to eb a completely
astonishing rerun of something that happened in the 60s going on: `now
we have a decent data representation formalism (sexps in the 60s and
xml now) we have solved the hard problems and can now create thinking
machines in 5 years'. The amazing thing is that it's *so accurately*
a rerun: XML really *is* sexps in all but surface syntax! The people
doing this stuff are either just lying their heads off to get funding,
or are appallingly badly read.
But that kind of thing wasn't really what I meant. I just means that
there is now a huge amount of crap which you need to do to talk to the
huge number of `standards' out there for databases, GUIs, web servlet
application enterprise bean java net container xml interoperability
orientated systems, and so on.
--tim
··········@tfeb.org (Tim Bradshaw) writes:
> The people doing this stuff are either just lying their heads off to
> get funding, or are appallingly badly read.
The latter.
··········@tfeb.org (Tim Bradshaw) writes:
> The people doing this stuff are either just lying their heads off
> to get funding, or are appallingly badly read.
The latter, I think. Those who do not know logic are doomed to try
reinventing it (and will fail badly).
> But that kind of thing wasn't really what I meant. I just means that
> there is now a huge amount of crap which you need to do to talk to the
> huge number of `standards' out there for databases, GUIs, web servlet
> application enterprise bean java net container xml interoperability
> orientated systems, and so on.
OK, so you're talking about the Brazil plumbing kind of complexity :-)
Some days I think that's going to flush us all down the toilet. But
some days I think positively about it: Since such an enormous amount
of money and time is wasted on this, the need for solutions that are
both simpler and better-founded will naturally emerge. And that's when
the guerilla army of underground plumbers, armed with linux (and bsd)
and lisp, will have their way. Or actually, they can just stand aside
and watch while the comittee members collapse of exhaustion in front
of their uncooperative palladium-equipped computers storing a scrambled
version of their newest gigabyte-sized proposal :-)
--
(espen)
··········@tfeb.org (Tim Bradshaw) writes:
> But that kind of thing wasn't really what I meant. I just means that
> there is now a huge amount of crap which you need to do to talk to the
> huge number of `standards' out there for databases, GUIs, web servlet
> application enterprise bean java net container xml interoperability
> orientated systems, and so on.
It is often said that Lisp has an "isolationist" approach, which might
not look like a bad thing after all :)
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
On Fri, 20 Feb 2004 04:12:32 -0800, Tim Bradshaw wrote:
> The amazing thing is that it's *so accurately*
> a rerun: XML really *is* sexps in all but surface syntax! The people
> doing this stuff are either just lying their heads off to get funding,
> or are appallingly badly read.
I vote for both. We software people are an industry/social group that
seems to discount history to a great degree *and* has far too little
scepticism about the new (It's TWO, TWO... TWO flaws in one!)
Right now the easiest way to get funding is to be so unread that you can
stumble upon a topic from the last generation of computing, letting
you unknowingly target this topic with a new syntax/environment/area of
use, and write your grant. I'm not sure if it's due to intellectual
dishonesty or just the normal amount of inertia, but it sure is a lot
easier to hit the bong and think about the same, still unsolved big
problems without doing the requisite background research. And, of course,
the result is that we duplicate the same (mediocre, incomplete, bad, or
useless) solutions to these problems tried before.
My question is, "What are the people administering grants and
supervising research smoking?" I mean, I could see this sort of thing
going on in industrial research - after all, industries live and die based
on their ability to make the "same old stuff" look shiny and new - but in
environments where the whole idea is to generate new approaches to
problems, the incompentence of oversight is appalling.
I have heard that one definition of insanity is to continuing doing the
same thing, expecting a different outcome. If this is indeed true, we
can only infer that our entire industry is insane...
faa
"Frank A. Adrian" <·······@ancar.org> writes:
> My question is, "What are the people administering grants and
> supervising research smoking?"
I guess a lot of them are still smoking "new economy" grass, or
whatever it is rebranded as these days :-(
--
(espen)
Tim Bradshaw <··········@tfeb.org> wrote:
+---------------
| But that kind of thing wasn't really what I meant. I just means that
| there is now a huge amount of crap which you need to do to talk to the
| huge number of `standards' out there for databases, GUIs, web servlet
| application enterprise bean java net container xml interoperability
| orientated systems, and so on.
+---------------
In another response to this thread I present a somewhat cynical view
that all of this is in some sense deliberate, a way of raising the bar
against newcomers or other competitors. (*sigh*)
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Tim Bradshaw <··········@tfeb.org> wrote:
> +---------------
> | But that kind of thing wasn't really what I meant. I just means that
> | there is now a huge amount of crap which you need to do to talk to the
> | huge number of `standards' out there for databases, GUIs, web servlet
> | application enterprise bean java net container xml interoperability
> | orientated systems, and so on.
> +---------------
>
> In another response to this thread I present a somewhat cynical view
> that all of this is in some sense deliberate, a way of raising the bar
> against newcomers or other competitors. (*sigh*)
Another opportunity for Lisp entrepreneurs who are free to develop apps
with the bare minimum of interface to outside crud. Sure, it means we
have to re-invent the wheel, but with Lisp that is easy.
See 2-21-2004 entry in:
http://home.comcast.net/~bc19191/blog/
...for more on the Lisp advantage.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
* Kenny Tilton wrote:
> Another opportunity for Lisp entrepreneurs who are free to develop
> apps with the bare minimum of interface to outside crud. Sure, it
> means we have to re-invent the wheel, but with Lisp that is easy.
Yes. This is something I keep banging on about: if you want to
succeed with Lisp (or, really, if you want to get off the treadmill at
all: this isn't really to do with language choice), you have to find
something *new* to do, and, you have to do it *fast*, before someone
else does it. Because it's new, it won't be complicated yet, and you
will get to set what standards there are to your advantage. Although
it's likely that other people are thinking of the same thing (you're
not a lone genius in other words), because you can choose a language
which lets you do stuff very fast (so long as `stuff' isn't `keeping
up in an exponentially exploding standards race') you can get there
before the other people do.
A good example would be writing a sufficiently-good web server: how
long would this take in Lisp, given sockets? in 1990? today? Well, I
wrote a simple web server in an afternoon which used nothing but
sockets and threads, and did stuff which would have seemed *really*
cool in 1990, like completely computed pages from a language
well-designed to support that. But today you'd have to compete with a
million standards, as well as apache and all its add-ons - you're
basically never going to win, however good Lisp is.
The saddest thing about Lisp is that many of its users seem to be
intent on redoing stuff that's already been done, only doing it
better: this is a forlorn task.
--tim
Tim Bradshaw wrote:
> * Kenny Tilton wrote:
>
>
>>Another opportunity for Lisp entrepreneurs who are free to develop
>>apps with the bare minimum of interface to outside crud. Sure, it
>>means we have to re-invent the wheel, but with Lisp that is easy.
>
>
> Yes. This is something I keep banging on about: if you want to
> succeed with Lisp (or, really, if you want to get off the treadmill at
> all: this isn't really to do with language choice), you have to find
> something *new* to do,...
I don't want to destroy their markets by sending in a horde of Lispnik
poachers, but Lisp-nyc has met two folks selling the most mundane of
"old" applications, but in a very precise, vertical niche. Bill Gates
they are not, but surviving yes. what I take from this is that
(surprise, surprise) most apps are crud, but because they are in weird
niches (health club mgmt, auto dealership mgmt, dentist's office) they
survive for sheer lack of competition.
So find a domain expert (or take some domain expertise of your own) and
seize the niche. (carpe nichum?)
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> So find a domain expert (or take some domain expertise of your own)
> and seize the niche. (carpe nichum?)
ALL YOUR NICHE ARE BELONG TO US.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
In article <··············@david-steuber.com>, David Steuber
<·············@verizon.net> wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > So find a domain expert (or take some domain expertise of your own)
> > and seize the niche. (carpe nichum?)
>
> ALL YOUR NICHE ARE BELONG TO US.
No no no, wrong meme. The correct version is as follows:
MORE NICHE!
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Brian Mastenbrook <····················@cs.indiana.edu> writes:
> In article <··············@david-steuber.com>, David Steuber
> <·············@verizon.net> wrote:
>
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>> > So find a domain expert (or take some domain expertise of your own)
>> > and seize the niche. (carpe nichum?)
>>
>> ALL YOUR NICHE ARE BELONG TO US.
>
> No no no, wrong meme. The correct version is as follows:
>
> MORE NICHE!
>
Lisp ain't for NICHE eaters!
--ap
Alain Picard <············@memetrics.com> writes:
>>> ALL YOUR NICHE ARE BELONG TO US.
>>
>> No no no, wrong meme. The correct version is as follows:
>>
>> MORE NICHE!
>>
>
> Lisp ain't for NICHE eaters!
NICHE to see you; to see you ... NICHE
(I don't know how widely exported Bruce is: this may make little sense
outside the UK)
-dan
--
"please make sure that the person is your friend before you confirm"
Daniel Barlow <···@telent.net> writes:
> (I don't know how widely exported Bruce is: this may make little sense
> outside the UK)
�h. Which Bruce is this? (and isn't Bruce an australian name ;-)?)
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Daniel Barlow <···@telent.net> writes:
>
> > (I don't know how widely exported Bruce is: this may make little sense
> > outside the UK)
>
> �h. Which Bruce is this?
Forsythe.
Daniel Barlow <···@telent.net> writes:
> NICHE to see you; to see you ... NICHE
Oh Knights that say, "NICHE!", where do you expect me to find a
continuation?
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
* David Steuber wrote:
> ALL YOUR NICHE ARE BELONG TO US.
This is what annoys me about Lisp people, you see. That's just *so*
pass\'e now. We should be inventing *new* catchphrases, not trying to
reverse engineer old ones.
--tim (do I need a smiley?)
> --tim (do I need a smiley?)
Don't bother, Stefan will just delete it.
:)
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> I don't want to destroy their markets by sending in a horde of Lispnik
> poachers, but Lisp-nyc has met two folks selling the most mundane of
> "old" applications, but in a very precise, vertical niche. Bill Gates
Lisp applications? If so, they might consider adding an entry to the
industrial applications page at the ALU CLiki site.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
"Tim Bradshaw" <···@cley.com> wrote:
> A good example would be writing a sufficiently-good web server: how
> long would this take in Lisp, given sockets? in 1990? today? Well, I
> wrote a simple web server in an afternoon which used nothing but
> sockets and threads, and did stuff which would have seemed *really*
> cool in 1990, like completely computed pages from a language
> well-designed to support that. But today you'd have to compete with a
> million standards, as well as apache and all its add-ons - you're
> basically never going to win, however good Lisp is.
The best Apache add-on is mod_lisp ;-)
The answer it to write complex web applications and then Lisp is alone. No
Java, no C# and no Python on sight. Well they are there trying to catch up
but very far away.
Sure it's worthless to try to compete for simple apps because customers
generally prefer to pay 10 java dev days rather than 1 lisp day. But when
it's 100 days for a Lisp app they don't take the 1000 days of the java app.
Especially when the Java guys explain that they can't do the same level of
interface because the Java frameworks can't do it.
> The saddest thing about Lisp is that many of its users seem to be
> intent on redoing stuff that's already been done, only doing it
> better: this is a forlorn task.
Hmm, I do this all the time ;-)
mod_lisp it like mod_jserv.
cl-pdf is like clibpdf.
cl-typesetting is already doing stuff that TeX can't do though it's still not
finished.
My web app framework is still without equivalent in the Java/C# world.
I don't think it's a forlorn task. It's even on the fun side IMHO. At least I
prefer earning money writing Lisp code (and designing electronics) rather
than Java/C# code.
Marc
>>>>> "Marc" == Marc Battyani <·············@fractalconcept.com>:
Marc> "Tim Bradshaw" <···@cley.com> wrote:
>> A good example would be writing a sufficiently-good web server: how
>> long would this take in Lisp, given sockets? in 1990? today? Well,
>> I wrote a simple web server in an afternoon which used nothing but
>> sockets and threads, and did stuff which would have seemed *really*
>> cool in 1990, like completely computed pages from a language
>> well-designed to support that. But today you'd have to compete with
>> a million standards, as well as apache and all its add-ons - you're
>> basically never going to win, however good Lisp is.
Marc> The best Apache add-on is mod_lisp ;-)
Which reminds me -- is anyone working on making mod_lisp work with
Apache 2.0?
Most systems these days include Apache 2.0 and downgrading that to 1.3.x
isn't really such a great option...
--J.
Jan Rychter <···@rychter.com> writes:
> Which reminds me -- is anyone working on making mod_lisp work with
> Apache 2.0?
This would probably be a good idea.
I've not looked at mod_lisp in depth, but it looks kind of like a
fast-cgi thing for Lisp. Would that be roughly accurate?
> Most systems these days include Apache 2.0 and downgrading that to 1.3.x
> isn't really such a great option...
Are you sure? Debian has both. In the past month or so, the conf
files were rearranged so that the transition from 1.3 to 2.0 would be
easier. However, there are still a lot more choices of modules for
1.3. The 2.0 features do look nice though.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
On Wed, 25 Feb 2004 14:47:23 GMT, David Steuber
<·············@verizon.net> wrote:
> Jan Rychter <···@rychter.com> writes:
>
>> Which reminds me -- is anyone working on making mod_lisp work with
>> Apache 2.0?
>
> This would probably be a good idea.
>
> I've not looked at mod_lisp in depth, but it looks kind of like a
> fast-cgi thing for Lisp. Would that be roughly accurate?
>
>> Most systems these days include Apache 2.0 and downgrading that to 1.3.x
>> isn't really such a great option...
>
> Are you sure? Debian has both. In the past month or so, the conf
> files were rearranged so that the transition from 1.3 to 2.0 would be
> easier. However, there are still a lot more choices of modules for
> 1.3. The 2.0 features do look nice though.
>
I remeber that I had the same problem (windows XP version).
I think I settled for mod_fastcgi which works with any language
and is more flexible that mod_lisp. And of course it works with
apache 2.0.
Under windows apache 1.3 is not an option.
It performs like a pig compared to 2.0.
John
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
On Wed, 25 Feb 2004 09:30:31 GMT, Jan Rychter <···@rychter.com> wrote:
> Most systems these days include Apache 2.0 and downgrading that to
> 1.3.x isn't really such a great option...
mod_perl 2.0, which might be regarded as one of the most important
Apache modules, is still in development, i.e. there's no stable
release for Apache 2. Don't know how well recent versions of PHP cope
with Apache 2. The essence is, though, that most production websites
which do non-trivial things still use Apache 1.3.
Edi.
"Jan Rychter" <···@rychter.com> wrote
"Marc" == Marc Battyani <·············@fractalconcept.com>:
> Marc> "Tim Bradshaw" <···@cley.com> wrote:
> >> A good example would be writing a sufficiently-good web server: how
> >> long would this take in Lisp, given sockets? in 1990? today? Well,
> >> I wrote a simple web server in an afternoon which used nothing but
> >> sockets and threads, and did stuff which would have seemed *really*
> >> cool in 1990, like completely computed pages from a language
> >> well-designed to support that. But today you'd have to compete with
> >> a million standards, as well as apache and all its add-ons - you're
> >> basically never going to win, however good Lisp is.
>
> Marc> The best Apache add-on is mod_lisp ;-)
>
> Which reminds me -- is anyone working on making mod_lisp work with
> Apache 2.0?
I currently have 2 betas versions of mod_lisp2 contributed by users (many
thanks to them:)
I've already sent those versions to several persons who asked for them. And I
am ok to send them to everybody who asks me. Though I would like that poeple
managing to fix and/or improve them report the modifications to me so that I
can eventually make a public release.
> Most systems these days include Apache 2.0 and downgrading that to 1.3.x
> isn't really such a great option...
Well probably but, as Edi wrote, Apache 1.3.x is still the one mostly used in
production.
Marc
Marc Battyani wrote:
> The best Apache add-on is mod_lisp ;-)
> The answer it to write complex web applications and then Lisp is alone. No
> Java, no C# and no Python on sight. Well they are there trying to catch up
> but very far away.
> Sure it's worthless to try to compete for simple apps because customers
> generally prefer to pay 10 java dev days rather than 1 lisp day. But when
> it's 100 days for a Lisp app they don't take the 1000 days of the java app.
> Especially when the Java guys explain that they can't do the same level of
> interface because the Java frameworks can't do it.
What you wrote sounds very interesting. As I am still new to Lisp I had
no chance to experience myself what you said. At the moment it looks to
me as if Lisp has in some cases slight advantages.
I would be very interested in getting very detailed information what
tasks you are talking about and if you can show some code.
Maybe you have 200-500 LOC for that a very experienced Java programmer
would need 1000-5000 LOC.
So many people are talking about these big development advantages Lisp
has over Java. However, I have not seen any explicit proof for it yet. I
would be happy if you could provide much more information.
Regards,
Andr�
Andr� Thieme <······································@justmail.de> writes:
> Marc Battyani wrote:
> > The best Apache add-on is mod_lisp ;-)
> > The answer it to write complex web applications and then Lisp is alone. No
> > Java, no C# and no Python on sight. Well they are there trying to catch up
> > but very far away.
> > Sure it's worthless to try to compete for simple apps because customers
> > generally prefer to pay 10 java dev days rather than 1 lisp day. But when
> > it's 100 days for a Lisp app they don't take the 1000 days of the java app.
> > Especially when the Java guys explain that they can't do the same level of
> > interface because the Java frameworks can't do it.
>
> What you wrote sounds very interesting. As I am still new to Lisp I
> had no chance to experience myself what you said. At the moment it
> looks to me as if Lisp has in some cases slight advantages.
> I would be very interested in getting very detailed information what
> tasks you are talking about and if you can show some code.
> Maybe you have 200-500 LOC for that a very experienced Java programmer
> would need 1000-5000 LOC.
>
> So many people are talking about these big development advantages Lisp
> has over Java. However, I have not seen any explicit proof for it
> yet. I would be happy if you could provide much more information.
In many language communities you will find a consensus that their
respective language is about a factor of 10 times more productive than
alternatives. Unfortunately, there's not much scientific evidence to
support these claims. (There are success stories and anecdotes which
might qualify as "evidence" to some people).
In a controlled setting there is Lutz Prechtel's famous comparison "An
empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl for
a search/string-processing program" (published in IEEE Software and
available here [1]). The outcome of this study was (if I recall
correctly) that the scripting languages require about a factor of 2
lesser development time & LOC than C/C++/Java.
Erann Gat did a followup study "Lisp as an Alternative to Java" in
Intelligence [2]. His results are statistically a bit more
questionable as he correctly points out in his paper (relatively few,
self-selected participants), but w.r.t. LOC one can say that it also
support that Java requires about twice the amount of code to solve the
given problem.
Now, the Prechtel/Gat study compares performance on a relatively small
scale project. People will argue that Lisp's advantages show up on
large projects (for which controlled experiments are unrealistic).
One figure reported by Richard P. Gabriel, who once ran a Lisp
company, in "Pattern of Software", p. 205, is that "Lisp guys who
where turned into C++ developers suffered about a factor of three
decline in productivity for about the first six months to a year,
which improved to about a 30% loss in a steady state".
So, the message is: It's probably a good idea to take figures as 10x
improvement in productivity not literally, but as an emotional
statement showing how much developers like their respective languages.
Learning Lisp is valuable in any case.
Matthias
[1] http://citeseer.nj.nec.com/547865.html
[2] http://www.flownet.com/gat/papers/lisp-java.pdf
[3] http://www.dreamsongs.com/NewFiles/PatternsOfSoftware.pdf
Matthias <··@spam.pls> wrote in message news:<···············@goya03.ti.uni-mannheim.de>...
> In many language communities you will find a consensus that their
> respective language is about a factor of 10 times more productive than
> alternatives.
But not *all* alternatives! Every community has its list of
alternatives to which their language is superior in terms of
productivity. By and large, they are right.
For example, in the C community, people might be found claiming that
using C is ten times more productive than assembly language. They are
right. Except for a lunatic fringe, C programmers would not claim that
C is more productive for application development than, say, Python.
Similarly, reasonable Common Lisp users don't claim to be ten times
more productive in Lisp than in *all* other alternatives.
Just because more than one community makes such claims doesn't mean
that they are mutually contradictory.
Languages are arranged, roughly, on a power lattice. At a given point
in the lattice, users know what is below them.
> One figure reported by Richard P. Gabriel, who once ran a Lisp
> company, in "Pattern of Software", p. 205, is that "Lisp guys who
> where turned into C++ developers suffered about a factor of three
> decline in productivity for about the first six months to a year,
> which improved to about a 30% loss in a steady state".
But that's about how long it takes to reimplement enough of Lisp in
C++.
It would be interesting to know how much of productivity decline they
would suffer upon leaving for a C++ job at some other company, without
being able to take with them any of the libraries they developed.
Another thing to consider: would new hires understand their code?
There is a wide variety in how C++ can be used. Two C++ programmers
sitting in adjacent cubicles can be doing completely different things,
although to the manager they both appear to be cranking out code using
the same tools. One can be spinning out utterances in a functional
language with higher-order functions, albeit a clumsy ones. The other
might be writing in C that compiles as C++.
> So, the message is: It's probably a good idea to take figures as 10x
> improvement in productivity not literally, but as an emotional
> statement showing how much developers like their respective languages.
When developers experienced in two languages, A and B, consistently
claim that A has made them more productive than B, and are rarely, if
ever, contradicted by reverse claims, I'd tend to believe them.
Also, you can infer a lot about productivity by actually considering
the features of the languages being compared. Suppose it is observed
that just about every program in B can be expressed in A, only more
succinctly, but the only way to make most A programs run in B is to
write an A interpreter in B? What does that say? To me it says I'd
rather be a user of A, without waiting for productivity statitics from
the field.
···@ashi.footprints.net (Kaz Kylheku) writes:
> Also, you can infer a lot about productivity by actually considering
> the features of the languages being compared. Suppose it is observed
> that just about every program in B can be expressed in A, only more
> succinctly, but the only way to make most A programs run in B is to
> write an A interpreter in B? What does that say? To me it says I'd
> rather be a user of A, without waiting for productivity statitics from
> the field.
I'm still going through Paul Graham's ACL book, so this question may
be premature. But could an application like ImageMagick be written
in pure Lisp? I know that would mean reinventing a lot of libs
written in C.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
>>>>> On Fri, 27 Feb 2004 01:39:14 GMT, David Steuber ("David") writes:
David> I'm still going through Paul Graham's ACL book,
David> so this question may be premature.
David> But could an application like ImageMagick be written in pure Lisp?
ImageMagick is not an application, but rather "a collection of tools
and libraries" for manipulating graphical images in many formats.
Yes, you could write all of that stuff in Lisp.
In fact, it's been done before, but I don't know exactly what happened
to the software product I'm thinking of, or if it's still for sale.
I think maybe it was acquired by a graphics production company that is
only interested in using it internally to their competitive advantage.
If by "like", you mean to include the idea that ImageMagick has bindings
in a variety of languages including C, C++, Perl, Java, Python, and Ruby:
Yes, you could do that in Lisp as well. There are Common Lisp compilers
that will create standard shared library binary files (eg. DLL and .so),
and bindings to those libraries could be written in Perl or whatever.
You can also create command-line executable programs, of course.
David> I know that would mean reinventing a lot of libs written in C.
That would be the whole point, wouldn't it?
Or if you are referring to some subroutines that ImageMagick uses,
Lisp can also use them. This would not be "pure Lisp", because
it's a cross-language issue --- it's a linker issue. Practically
every Lisp implementation has a way to link in such libraries.
That mechanism is not part of the Common Lisp standard, but there
is a portable compatability package called UFFI (Universal Foreign
Function Interface). This is all beyond the scope of the book
that you mentioned you're reading.
But if you don't want to rewrite all that code, why not instead just
write Lisp bindings for ImageMagick, as has been done for all those
other languages?
Christopher C. Stacy wrote:
>>>>>>On Fri, 27 Feb 2004 01:39:14 GMT, David Steuber ("David") writes:
>
> David> I'm still going through Paul Graham's ACL book,
> David> so this question may be premature.
> David> But could an application like ImageMagick be written in pure Lisp?
A newbie left in a basket outside lisp-nyc once hit us with the same
question. Having just spent several years on a rather intense
"enterprise" app for the pharma industry, my first thought was "of
course!". But then I remembered that the same misconception had delayed
by several months my adoption of CL as a development language.
I think the short answer is: don't let the parentheses and incredible
expressive power and weird things like macros fool you, Lisp really is
just another (incredibly good) programming language.
> But if you don't want to rewrite all that code, why not instead just
> write Lisp bindings for ImageMagick, as has been done for all those
> other languages?
because any day now you could just download them from the FTP area
connected to Cello, aka "Libraries 'R Us":
http://www.common-lisp.net/project/cello/
Also FreeGlut, OpenGL, and FTGL.
I know open software drives Kent nuts, but I think it is time we stopped
fighting over this low-level crap and started working on (and competing
over) vertical apps. Case in point: pretty soon, thx to Cello, Xanalys
will be able to mothball CAPI, Franz can stop worrying about Common
Graphics, the Garnet project can be allowed to die with dignity, the
Cliki GUI page can be recycled, CLisp and CormanCL and CMUCL and SBCL
will have great GUIs...I know I'm forgetting something.
:)
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
······@news.dtpq.com (Christopher C. Stacy) writes:
> >>>>> On Fri, 27 Feb 2004 01:39:14 GMT, David Steuber ("David") writes:
> David> I'm still going through Paul Graham's ACL book,
> David> so this question may be premature.
> David> But could an application like ImageMagick be written in pure Lisp?
>
> ImageMagick is not an application, but rather "a collection of tools
> and libraries" for manipulating graphical images in many formats.
>
> Yes, you could write all of that stuff in Lisp.
OK, that's all I need to know. I will also assume a pure Lisp MD5
checksum algorithm exists. More generally, the ability to manipulate
binary data at the bit level as with C but in a Lisp way is important
to me.
> David> I know that would mean reinventing a lot of libs written in C.
>
> That would be the whole point, wouldn't it?
It would indeed. And hopefully it would be done just the one time
and made available to everyone under a free license so that everyone
who needed such mundane functionality could use it and perhaps feed
back improvements to it.
> But if you don't want to rewrite all that code, why not instead just
> write Lisp bindings for ImageMagick, as has been done for all those
> other languages?
Because I do not want to have a dependency on ImageMagick (as good a
tool as it is).
FFI is nice and all. It is necessary to deal with system libs.
However the more I can do in pure Lisp, the more happy I will be.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber <·············@verizon.net> writes:
> OK, that's all I need to know. I will also assume a pure Lisp MD5
> checksum algorithm exists. More generally, the ability to manipulate
> binary data at the bit level as with C but in a Lisp way is important
> to me.
There are even several ways to do it.
logand, logor, lognot, logbitp, ash / boole
dpb, ldb, ldb-test, bit, byte / deposit-field, mask-field
integers, bytes, bit vectors, bit arrays.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> David Steuber <·············@verizon.net> writes:
> > OK, that's all I need to know. I will also assume a pure Lisp MD5
> > checksum algorithm exists. More generally, the ability to manipulate
> > binary data at the bit level as with C but in a Lisp way is important
> > to me.
>
> There are even several ways to do it.
>
> logand, logor, lognot, logbitp, ash / boole
> dpb, ldb, ldb-test, bit, byte / deposit-field, mask-field
> integers, bytes, bit vectors, bit arrays.
Neat.
I was reading the intro to PAIP the other day and considering the
statement that CL has over 700 words. I don't know if '(car first)
gets counted as two seperate words or not. Still it is a bit
sobering when C has just a handful (not counting the library
functions that make it useful).
Just as an excercise, I want to implement the MD5 algorithm from the
K&R C example in RFC-1321 (hope I got that right) in Lisp and see how
well I do. I did once convert the K&R C into ANSI so that it would
compile under C++ (Microsoft VC++) a while back before finding out
that it was all over the place.
Oddly enough, I knew exactly what it was doing each step of the way
but not why it worked.
Anyway that excercise will wait until I finish Graham's ACL book.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber <·············@verizon.net> writes:
> Pascal Bourguignon <····@thalassa.informatimago.com> writes:
>
> > David Steuber <·············@verizon.net> writes:
> > > OK, that's all I need to know. I will also assume a pure Lisp MD5
> > > checksum algorithm exists. More generally, the ability to manipulate
> > > binary data at the bit level as with C but in a Lisp way is important
> > > to me.
> >
> > There are even several ways to do it.
> >
> > logand, logor, lognot, logbitp, ash / boole
> > dpb, ldb, ldb-test, bit, byte / deposit-field, mask-field
> > integers, bytes, bit vectors, bit arrays.
>
> Neat.
>
> I was reading the intro to PAIP the other day and considering the
> statement that CL has over 700 words. I don't know if '(car first)
> gets counted as two seperate words or not. Still it is a bit
> sobering when C has just a handful (not counting the library
> functions that make it useful).
But that's exactly what you should count. It is not a crazy way to
look at Common Lisp as 25 special operators, a handful of important
built in data types (functions and conses spring to mind) and the rest
is just a vast library.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> David Steuber <·············@verizon.net> writes:
>
> > Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> >
> > > David Steuber <·············@verizon.net> writes:
> > > > OK, that's all I need to know. I will also assume a pure Lisp MD5
> > > > checksum algorithm exists. More generally, the ability to manipulate
> > > > binary data at the bit level as with C but in a Lisp way is important
> > > > to me.
> > >
> > > There are even several ways to do it.
> > >
> > > logand, logor, lognot, logbitp, ash / boole
> > > dpb, ldb, ldb-test, bit, byte / deposit-field, mask-field
> > > integers, bytes, bit vectors, bit arrays.
> >
> > Neat.
> >
> > I was reading the intro to PAIP the other day and considering the
> > statement that CL has over 700 words. I don't know if '(car first)
> > gets counted as two seperate words or not. Still it is a bit
> > sobering when C has just a handful (not counting the library
> > functions that make it useful).
>
> But that's exactly what you should count. It is not a crazy way to
> look at Common Lisp as 25 special operators, a handful of important
> built in data types (functions and conses spring to mind) and the rest
> is just a vast library.
That is a very good point. I think it would apply even more strongly
to Java with its myriad packages, classes, and methods. Java's C
like syntax seems simple enough on the surface but the APIs are a
mind boggling nightmare. I guess that's true of any large class
library. Apple's Cocoa has also given me the cold sweats.
If we were to compare Java's vocabulary size to deal with X features
to Lisp's vocabulary size, who would come out with more words? I
know it is a difficult comparison to make because we have to pick
among the various extension librarys for Lisp to do networking, GUI,
etc, depending on what feature sets or subsets we want to compare.
I shall speculate that the way Lisp is structured gives it a smaller
vocabulary to perform the same number of features and thus makes it
easier to learn well. The Lisp words are more expressive. MAPCAR
would be a good example unless it is no more than foreach.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber <·············@verizon.net> writes:
[Story about writing MD5 algorithm in C elided]
> Oddly enough, I knew exactly what it was doing each step of the way
> but not why it worked.
I don't find this to be unusual in C.
--
~jrm
David Steuber <·············@verizon.net> writes:
> Just as an excercise, I want to implement the MD5 algorithm from the
> K&R C example in RFC-1321 (hope I got that right) in Lisp and see how
> well I do.
As long as you're aware that it's an exercise. There already exist
two lisp implementations of md5, one of which is distributed with SBCL
as the sb-md5 contrib.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
···@ashi.footprints.net (Kaz Kylheku) writes:
> Also, you can infer a lot about productivity by actually considering
> the features of the languages being compared. Suppose it is observed
> that just about every program in B can be expressed in A, only more
> succinctly, but the only way to make most A programs run in B is to
> write an A interpreter in B? What does that say? To me it says I'd
> rather be a user of A, without waiting for productivity statitics from
> the field.
For me, it can be measured as the number of LOC and of module you can
throw when you convert from one language to another. Even converting
from emacs lisp to Common-Lisp I leave behind a significant size of
code. So with other languages such as Modula-2 or C, it's whole
source files that are deleted and uneeded, even before trying to
change the design of the translated program. For example, of a
library of 31 Modula-2 "reusable" mdoules, I kept only two modules
when converting it into Common-Lisp packages. And if I had redesigned
it from scratch in lisp instead of converting, I would further have
cut in half the LOC.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
···@ashi.footprints.net (Kaz Kylheku) writes:
> There is a wide variety in how C++ can be used. Two C++ programmers
> sitting in adjacent cubicles can be doing completely different
> things, although to the manager they both appear to be cranking out
> code using the same tools. One can be spinning out utterances in a
> functional language with higher-order functions, albeit a clumsy
> ones. The other might be writing in C that compiles as C++.
At the moment, this has to be my least favorite aspect of having to
program in C++ (from time to time) for pay. I have grow quite tired
of arguing with either C++ compilers or with co-workers who seem to
think that the language is still C with Classes. Whether or not one
agrees with the idea that C++ should have moved past C with Classes,
there is an ISO standard for C++ now and it does define the language.
If I never again have to debate in a code inspection, for example,
whether or not "operator new" throws an exception or returns a null
pointer, even after producing some example code to show what happens
when it ran out of memory, and why "auto_ptr" is so useful/necessary
in C++ in the presence of exceptions, I will die a happy code grunt.
And forget about attempting to introduce some code that might use
something like a binder, adapter, let alone something esoteric like
C++ Boost's attempt at lambda expressions
<http://www.boost.org/libs/lambda/doc/index.html>; agruably, probably
deserving of a nomination for Outstanding Example of the Year of
Greenspun's 10th Rule of Programming. I mean, I can understand if one
were to make objections based on factual measures of performance or an
application's memory footprint, if these things were not meeting
requirements, etc., especially when using a compiler released in the
early 90s, but these never ending fscking debates about what is and is
not C++. Argh!! I'm *almost* happy to have wound up being reorged
into something in which I'm working with Tcl... <pause>
But I'm ranting about this in comp.lang.lisp, aren't I?
ObLisp : Well, at least I never have to argue about what is or is not
CL with coworkers <laugh>. I'm beginning to get the impression that
I'm the only one in my building that knows anything about Lisp beyond
it being that vaguely remembered thing with all the parenthesis that
only had lists and recursion and could, therefore, be forgotten. Or
Emacs. Whenever I mention Lisp, somebody invariably wants to know if
I'm doing stuff for/with Emacs. I know for a fact that there are
Lispnik Masters out there in my corporative universe but they live in
a department far, far away. See, if CL was C++, an Important
Language, a Language About Which One Must Have Knowledge and Opinions,
my attempt to explain that CL has far more than simply lists,
recursion, etc. would turn into a sadly quixotic exercise in
frustration. However, since Lisp is a Thing That Can Be Easily
Forgotten, making no distinctions between Common Lisp, Emacs Lisp,
Scheme, or any other language with lots of parenthesis, my potential
opponent quickly shrugs and wanders away, mumbling some uninterested
variation on "whatever". This makes me momentarily happy. At least
it wasn't yet another *fscking* *fracking* *sassafrashin* debate about
what is or is not *flumux* *sassafrizzle* "real C++"!!! Then I
remember that I still have some assignment waiting to be completed in
Tcl and I become sad again.
Which leads me to a question. Does anyone know of some existing Tcl
in Lisp implmentation? I don't mean something like lisp2wish
<http://www.cliki.net/lisp2wish> but rather something that would do
something like the following.
(macroexpand-1
'(with-tcl
proc foo {x y} {
list [list $x $y] [list $x $y]
}))
=> (defun foo (x y)
(list (list x y) (list x y)))
Damien Kick <······@email.mot.com> writes:
> And forget about attempting to introduce some code that might use
> something like a binder, adapter, let alone something esoteric like
> C++ Boost's attempt at lambda expressions
> <http://www.boost.org/libs/lambda/doc/index.html>; agruably, probably
> deserving of a nomination for Outstanding Example of the Year of
> Greenspun's 10th Rule of Programming.
Not only that, but it could be nominated for Outstanding Example of
the Year of the Intercal Impact on Computing World:
For example, the C++ version of the definition
lambda x y.x+y
is
_1 + _2
That's ludicrous!
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> > Greenspun's 10th Rule of Programming.
I finally tried to find the first nine rules. Instead, I found this:
http://philip.greenspun.com/bboard/q-and-a-fetch-msg?msg_id=000tgU
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
Pascal Bourguignon wrote:
[about the Boost Lambda Library:]
> Not only that, but it could be nominated for Outstanding Example of
> the Year of the Intercal Impact on Computing World:
>
> For example, the C++ version of the definition
>
> lambda x y.x+y
>
> is
>
> _1 + _2
>
> That's ludicrous!
I think it's rather elegant, myself. There are some obvious
and important drawbacks, but why "ludicrous"?
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> Pascal Bourguignon wrote:
>
> [about the Boost Lambda Library:]
> > Not only that, but it could be nominated for Outstanding Example of
> > the Year of the Intercal Impact on Computing World:
> >
> > For example, the C++ version of the definition
> >
> > lambda x y.x+y
> >
> > is
> >
> > _1 + _2
> >
> > That's ludicrous!
>
> I think it's rather elegant, myself. There are some obvious
> and important drawbacks, but why "ludicrous"?
In Intercal, you don't use letters to name variables, you use digits.
Intercal represent a local maximum in obfuscated languages (unlambda
being another one quite different).
http://www.muppetlabs.com/~breadbox/intercal-man/s03.html#1
So, having to use only digits (be them prefixed with a '_'), is quite
a step toward Intercal "expressive power", IMO.
The developers of Boost should rather spend their time programming in
Lisp, if they want lambda.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
"Matthias" <··@spam.pls> wrote :
>
> In many language communities you will find a consensus that their
> respective language is about a factor of 10 times more productive than
> alternatives. Unfortunately, there's not much scientific evidence to
> support these claims. (There are success stories and anecdotes which
> might qualify as "evidence" to some people).
Yes but there are no anecdotes or success stories telling that a 10x
improvement have been ever seen while going from Lisp to Java or C++ ;-)
The problem is that we are already busy enough to not have time to conduct
scientific studies. But we effectively see what arrives when a software
written in Lisp is re-written in another language (and the reverse). I've
always seen a 5 to 20 factor between Lisp and Java/C++. Once a client who
have seen such a factor (20x) said that it was not due to Lisp but rather to
the fact that a Lispnik is worth 10 java guys. But I've seen a 10x
improvement when converting my own C++ software to Lisp.
If you want to conduct a scientific experiment, take a few Java guys who
don't know the PDF file format, give them the PDF Ref manual and make them
write the equivalent of the first version of cl-pdf. It took me less than 6
hours (most of them spent to read the PDF Ref) and the resulting Lisp source
code had only 326 lines. It's an easy one, not too long. I'm pretty sure that
you will end up closer to 3260 lines of Java rather than to 32... (Of course
using external libraries or ABL is considered as cheating :)
[...]
> So, the message is: It's probably a good idea to take figures as 10x
> improvement in productivity not literally, but as an emotional
> statement showing how much developers like their respective languages.
I don't program only in Lisp but also in VHDL, ASM, C, C++, Lisp. One
language for each level.
> Learning Lisp is valuable in any case.
Sure.
Marc
Marc Battyani escreveu:
> "Matthias" <··@spam.pls> wrote :
>
>> In many language communities you will find a consensus that their
>> respective language is about a factor of 10 times more productive
>> than alternatives. Unfortunately, there's not much scientific
>> evidence to support these claims. (There are success stories and
>> anecdotes which might qualify as "evidence" to some people).
>
>
> Yes but there are no anecdotes or success stories telling that a 10x
> improvement have been ever seen while going from Lisp to Java or C++
> ;-)
Yes. Because the ones who 'decide' a project need to be done in these
languages do need to make points. They're using 'mainstream' languages
and nobody would questions their decisions!
The use of 'maverick' or 'weird' languages that requires careful written
reporst, ROI analysis, risk assessments, etc. :-D
>
> The problem is that we are already busy enough to not have time to
> conduct scientific studies.
Probably this issue had to be tackled by vendors of the Lisp technology,
who would have resources to fund and conduct this studies.
> But we effectively see what arrives when a software written in Lisp
> is re-written in another language (and the reverse). I've always seen
> a 5 to 20 factor between Lisp and Java/C++. Once a client who have
> seen such a factor (20x) said that it was not due to Lisp but rather
> to the fact that a Lispnik is worth 10 java guys. But I've seen a 10x
> improvement when converting my own C++ software to Lisp.
Two aspects here: the average (in general not only the language)
experience of the programmres (a.k.a. 'seniority') and the problem
domain. These can make a lot of difference.
>
> If you want to conduct a scientific experiment, take a few Java guys
> who don't know the PDF file format, give them the PDF Ref manual and
> make them write the equivalent of the first version of cl-pdf. It
> took me less than 6 hours (most of them spent to read the PDF Ref)
> and the resulting Lisp source code had only 326 lines. It's an easy
> one, not too long. I'm pretty sure that you will end up closer to
> 3260 lines of Java rather than to 32... (Of course using external
> libraries or ABL is considered as cheating :)
This consideration of 'cheating' on the (re-)use of libraries or
components also does not help in scientific experiment: productivity
should be considered in the ecosphere, otherwise will arrive at the so
despised 'academic exercises' ;-)
>
> [...]
>
>> So, the message is: It's probably a good idea to take figures as
>> 10x improvement in productivity not literally, but as an emotional
>> statement showing how much developers like their respective
>> languages.
>
>
> I don't program only in Lisp but also in VHDL, ASM, C, C++, Lisp. One
> language for each level.
>
Yes! I agree in full on this! The main point which presently is being
forgotten is how advantageous it would be is the correct mixing of the
appropiate languages in a project.
--
Cesar Rabak
Cesar Rabak <······@acm.org> writes:
> > If you want to conduct a scientific experiment, take a few Java guys
> > who don't know the PDF file format, give them the PDF Ref manual and
> > make them write the equivalent of the first version of cl-pdf. It
> > took me less than 6 hours (most of them spent to read the PDF Ref)
> > and the resulting Lisp source code had only 326 lines. It's an easy
> > one, not too long. I'm pretty sure that you will end up closer to
> > 3260 lines of Java rather than to 32... (Of course using external
> > libraries or ABL is considered as cheating :)
>
> This consideration of 'cheating' on the (re-)use of libraries or
> components also does not help in scientific experiment: productivity
> should be considered in the ecosphere, otherwise will arrive at the so
> despised 'academic exercises' ;-)
But if you allow it, I would just fetch cl-pdf and get it done with 0
line of code. The one with the fastest ADSL line will win!
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Pascal Bourguignon escreveu:
> Cesar Rabak <······@acm.org> writes:
>
>> > If you want to conduct a scientific experiment, take a few Java guys
>> > who don't know the PDF file format, give them the PDF Ref manual and
>> > make them write the equivalent of the first version of cl-pdf. It
>> > took me less than 6 hours (most of them spent to read the PDF Ref)
>> > and the resulting Lisp source code had only 326 lines. It's an easy
>> > one, not too long. I'm pretty sure that you will end up closer to
>> > 3260 lines of Java rather than to 32... (Of course using external
>> > libraries or ABL is considered as cheating :)
>>
>>This consideration of 'cheating' on the (re-)use of libraries or
>>components also does not help in scientific experiment: productivity
>>should be considered in the ecosphere, otherwise will arrive at the so
>>despised 'academic exercises' ;-)
>
>
> But if you allow it, I would just fetch cl-pdf and get it done with 0
> line of code. The one with the fastest ADSL line will win!
>
>
Yes! And even d/l'ing pure code, 326 lines ought to be much smaller
filesize than competition ;-D
--
Cesar Rabak
Matthias <··@spam.pls> writes:
> Erann Gat did a followup study "Lisp as an Alternative to Java" in
> Intelligence [2]. His results are statistically a bit more
> questionable as he correctly points out in his paper (relatively few,
> self-selected participants), but w.r.t. LOC one can say that it also
> support that Java requires about twice the amount of code to solve the
> given problem.
And Bill Joy says that Java is 2.5 times better than C, therefore Lisp
should be at least 5 times better than C :-)
> So, the message is: It's probably a good idea to take figures as 10x
> improvement in productivity not literally, but as an emotional
> statement showing how much developers like their respective languages.
Right, it's probably more important how the developres like their
language and development environment that the particulars of it.
Since programmers prefer lisp, why not let them program in lisp?
> Learning Lisp is valuable in any case.
>
> Matthias
>
> [1] http://citeseer.nj.nec.com/547865.html
> [2] http://www.flownet.com/gat/papers/lisp-java.pdf
> [3] http://www.dreamsongs.com/NewFiles/PatternsOfSoftware.pdf
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
"Andr� Thieme" <······································@justmail.de> wrote
> Marc Battyani wrote:
> > The best Apache add-on is mod_lisp ;-)
> > The answer it to write complex web applications and then Lisp is alone.
No
> > Java, no C# and no Python on sight. Well they are there trying to catch
up
> > but very far away.
> > Sure it's worthless to try to compete for simple apps because customers
> > generally prefer to pay 10 java dev days rather than 1 lisp day. But when
> > it's 100 days for a Lisp app they don't take the 1000 days of the java
app.
> > Especially when the Java guys explain that they can't do the same level
of
> > interface because the Java frameworks can't do it.
>
> What you wrote sounds very interesting. As I am still new to Lisp I had
> no chance to experience myself what you said. At the moment it looks to
> me as if Lisp has in some cases slight advantages.
> I would be very interested in getting very detailed information what
> tasks you are talking about and if you can show some code.
> Maybe you have 200-500 LOC for that a very experienced Java programmer
> would need 1000-5000 LOC.
For instance in cl-pdf I have stuff like that :
(make-instance 'dictionary
:dict-values `(("/Type" . "/Pages")
("/Count" . ,#'(lambda ()(length (pages obj))))
,@(when *root-page* `(("/Parent" . ,*root-page*)))
("/Kids" . ,(pages obj))))
Here the number of pages in not yes known so instead of the value I put a
closure that will compute it when needed.
This is then used when generating the pages by a #'write-object generic
function with a method that handle it like this:
(defmethod write-object ((obj function) &optional root-level)
(declare (ignorable root-level))
(write-object (funcall obj)))
That's very cool and you can't do that in Java. Of course you can fake it
with anonymous classes and code to emulate this but you will need much more
lines of code to do it. And it will be ugly and not in Java style.
Another very good example is the HTML generation macros. There have been a
lot of examples posted here so just use google if you are interested.
> So many people are talking about these big development advantages Lisp
> has over Java. However, I have not seen any explicit proof for it yet. I
> would be happy if you could provide much more information.
There are no real proofs, just a lot of success stories and anecdotes (see
the other post on the subject) giving a 10x improvement in favor of Lisp vs.
Java and none of the reverse. ;-)
Marc
Andr� Thieme <······································@justmail.de> writes:
> So many people are talking about these big development advantages Lisp
> has over Java. However, I have not seen any explicit proof for it
> yet. I would be happy if you could provide much more information.
If you are interested in some more opinions and anecdotes, you may
check this page:
http://alu.cliki.net/Evaluate%20Lisp
No explicit proofs, but a lot of food for thought.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Tim Bradshaw wrote:
>
> Of course, as this progresses, more and more time is spent just
> managing complexity, and less and less doing useful work, until
> eventually the complexity event horizon is passed, and all further
> work is managing complexity. We may already be past that point - as
> with event horizons in physics you may not know when you've passed
> through one (actually in physics you do, at least in the simple cases,
> because the sky goes white and you fry, but you don't get crushed to
> death as you pass the horizon).
There is such a thing as emergent simplicity. We do not, in fact,
live in a technosphere of ever-increasing complexity; the lower
levels, which we're building new stuff on, get compressed and
crystallized and, almost magically, become simple. There can
never more complexity, at any one time, than we can manage; but
the limitation does not mean progress has to stop.
When the (computing) world was young, every machine had its own
idiosyncratic way of representing its own idiosyncratic set of
characters. "byte" meant, literally, "the distance in bits between
two adjacent memory addresses", and might be anything from 4 to 36
bits. There was a fairly strong 5-bit standard for transmission
protocol in newswire services (The Baudot character set) and a
fair fraction of machines needed to understand different punched
tape formats or communicated with each other via telegraphy.
Communication, in fact, went by a bewildering variety of protocols,
and we're talking about a bewildering variety of *line-level*
protocols, not a bewildering variety of application layers implemented
on top of different line-level protocols. There was no agreement about
how even basic alphabetic characters ought to be encoded, or even
the *kind* of facilities an operating system ought to provide, and
VMS (?) machines with record-based 80-column text files (which you
could not access any other way at all) competed with Unixoids that
used stream-based I/O models for all files. When I first connected to
the Labyrinth BBS, (at 150 baud using, as I recall, a 5-bit protocol
with a three-bit hamming code and two stop bits, which the sysop
selected because the lines there were too noisy for the more common
7-e-2 protocols) the first thing that came over the line was "how
many nulls do you need?" -- remember that? systems used to have
to insert nulls after each newline character to give the remote host
time to process the newline.
On top of this seething mass of character encodings and line-level
protocols, dozens of brave souls implemented email and news protocols
- none of which was compatible with each other, none of which filled
precisely the same needs. PC pursuit was not internet email was not
CISmail, nor is Fidonet a usenet feed. Which one you used depended
on what was available and what you needed to do and who you needed to
talk to. "Gateways" and "tunnels" between these systems were all
homebrews, and each had its own idiosyncracies and different command
sets that the users had to know.
All of these things, which once were real and vital concerns and
complexities that existed for good reasons and represented choices
that we had to make for engineering reasons, have fallen beneath our
notice. We standardized things where we had more important things
to spend our time thinking about or needed to build or take advantage
of infrastructure, or just dropped alternatives as we overcame
hardware limitations. And so today, all of that former complexity has
dropped into simplicity.
Today's complexity is merely the stuff that we haven't got around
to standardizing and forgetting yet, and it will pass into simplicity
as the next generation of complexities grow and disgruntled businessmen
realize that once it becomes a commodity they can't profit from it
anymore. Profit is only made in the complex parts of the technosphere.
Bear
Ray Dillinger <····@sonic.net> wrote in message news:<·················@sonic.net>...
> There is such a thing as emergent simplicity. We do not, in fact,
> live in a technosphere of ever-increasing complexity; the lower
> levels, which we're building new stuff on, get compressed and
> crystallized and, almost magically, become simple. There can
> never more complexity, at any one time, than we can manage; but
> the limitation does not mean progress has to stop.
>
This is empirically falsifiable. The way you falsify it is by looking
at the amount (in pages, words or some other easy measure) of
standards being published per unit time. By `standards' I don't mean
`formal standard' but something suitably looser. All of this activity
is overhead: every standard is something that someone had to produce,
and during that time they weren't getting anything else done. If this
rate is increasing, then complexity is going up.
Without any proof (or even bothering to look: I'm not about to incur
the wrath of the usenet Gods by checking my facts before posting) I
claim it's increasing pretty rapidly.
--tim
> Ray Dillinger <····@sonic.net> wrote in message news:<·················@sonic.net>...
>
>> There can
>> never more complexity, at any one time, than we can manage; but
>> the limitation does not mean progress has to stop.
>>
··········@tfeb.org (Tim Bradshaw) writes:
> The way you falsify it is by looking at the amount (in pages, words
> or some other easy measure) of standards being published per unit
> time. All of this activity is overhead: every standard is something
> that someone had to produce, and during that time they weren't
> getting anything else done. If this rate is increasing, then
> complexity is going up.
That only increases complexity if someone bothers to read it.
* Joe Marshall wrote:
> That only increases complexity if someone bothers to read it.
But it increases the *overhead* regardless, because someone has to
write it. Eventually all anyone will do is write standards.
--tim
Ray Dillinger <····@sonic.net> writes:
> Today's complexity is merely the stuff that we haven't got around
> to standardizing and forgetting yet, and it will pass into simplicity
> as the next generation of complexities grow and disgruntled businessmen
> realize that once it becomes a commodity they can't profit from it
> anymore. Profit is only made in the complex parts of the technosphere.
Well, when I'm in a pessimistic mood, today's complexity bears a
striking resemblance to the plumbing in Terry Gilliam's Brazil :-(
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote:
+---------------
| Well, when I'm in a pessimistic mood, today's complexity bears a
| striking resemblance to the plumbing in Terry Gilliam's Brazil :-(
+---------------
*YES!!* And three guesses who the jokers from Central Services are... ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Ray Dillinger <····@sonic.net> wrote:
+---------------
| There is such a thing as emergent simplicity. We do not, in fact,
| live in a technosphere of ever-increasing complexity; the lower
| levels, which we're building new stuff on, get compressed and
| crystallized and, almost magically, become simple.
+---------------
That would only be true if everyone were cooperating. The reality is
that there are strong economic reasons for certain large companies to
*NOT* want things to get simpler, but instead for complexity to continue
to increase at a rate at which *they* can barely keep up but with which
competitors with lesser resources cannot.
[This is, loosely speaking, perhaps the economic warfare equivalent of
cryptography expert Ron Rivest's notion of "winnowing and chaffing" --
attaining confidentiality without encryption by filling the environment
with sufficient needless complexity to overload attackers' ability to
discriminate "the good stuff".]
Otherwise, simple XML-RPC would never have metasticized into SOAP, etc.
+---------------
| There can never more complexity, at any one time, than we can manage;
| but the limitation does not mean progress has to stop.
+---------------
Again, "we" is not a singleton, atomic "thing". There are many competing
"we"s in the world. Some "we"s can well be ovewhelmed by complexity which
other "we"s (perhaps better-funded) are able to handle (barely).
+---------------
| Today's complexity is merely the stuff that we haven't got around
| to standardizing and forgetting yet, and it will pass into simplicity
| as the next generation of complexities grow and disgruntled businessmen
| realize that once it becomes a commodity they can't profit from it
| anymore. Profit is only made in the complex parts of the technosphere.
+---------------
I cynically, perhaps, fear you are mistaken, that the economic pressure
is *not* towards a "crystalline simplicity" that would benefit all of us,
but instead towards "just enough simpler that *my* company can handle it"
[for various values of "me"]...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On 2004-02-24 08:15:52 -0500, ····@rpw3.org (Rob Warnock) said:
> I cynically, perhaps, fear you are mistaken, that the economic pressure
> is *not* towards a "crystalline simplicity" that would benefit all of us,
> but instead towards "just enough simpler that *my* company can handle it"
> [for various values of "me"]...
I would agree, and point out that the world in which the standards Ray
Dillinger speaks of became standardized, was largely a world where
vendors competed in the hardware and support arenas, and software,
often included free with the hardware and support contract, was not yet
where the big money was. Vendors differentiated their hardware and
support, but recognized that having common communications standards and
protocols benefited them by making their hardware that much more useful
for being interoperable with other hardware that was out there (so
called "network effects.")
Microsoft has succeeded in reversing this economic focus of the
computer industry - software, not hardware, is where the greatest
profits are made now, both in direct software sales, and as a
differentiator of hardware. The result is the economic pressure towards
increasing complexity and incompatibility of software. This is often
characterized as "embrace and extend." I don't mean to suggest that MS
is the only practitioner, just the most adept. Sun's Java, for example,
can be viewed as an attempt to embrace and extend C++, and move that
standard language in a direction that favors Sun's server side and
network strengths. C#/.NET is Microsoft's counter attack on this front.
Apple's repeated attempts to create its own private little
hardware/software fiefdom, though less broadly successful, are another
example - their proprietary stuff interoperates with standards very
well, but if you want to use their hardware as intended, you have to
wrap your head around various constantly shifting frameworks that are
essentially useless with anybody else's hardware.
No software vendor, or hardware/software vendor, with significant
resources has much incentive to make their software completely
standardized, for then it would become a commodity - a class of product
the instances of which are completely substitutable. The existence of
open source software means that any purely standards based, commodity
software must compete with zero cost alternatives.
Ray Dillinger may be correct in the long run, however, if price
pressure causes the eventual dominance of open source software at all
levels (OS, middleware, database, desktop environment, applications -
even drivers). Indeed, IBM seem to be betting on this eventuality,
because it plays to their strengths - support and hardware. However, in
the short term, most large firms that produce software, even if it is
only to support their hardware sales, will use their not inconsiderable
resources to differentiate their product offerings by maintaining and
increasing software incompatibilities. This often means adding
unnecessary complexity as well.
raf
··········@tfeb.org (Tim Bradshaw) writes:
> Alain Picard <·································@memetrics.com> wrote in message news:<··············@memetrics.com>...
>
>> Having just spent^H^H^H^H^H wasted an entire day fighting with Java
>> and JBOSS, I've come to the conclusion that the main advantage of Lisp
>> is that it allows you to not use Java. The baroqueness of those
>> systems never ceases to astound me.
>
> I think you've misdiagnosed the problem. JBOSS is indeed a seething
> nightmare. But I don't think that's because of Java, it's because
> it's 2004, and we're a good way down the software complexity
> catastrophe.
Well, okay, maybe I should have said the "Java Mindset (TM)", but
it's all the same to me.
I thought the whole point of all this J2EE nonsense was that
you developed your application, then could drop the .war files
in any compliant J2EE server. Hah!
To be fair, JBOSS may just be particularly awful; this stuff
worked pretty much as advertised on Jakarta and Weblogic.
Still, I was pretty darn happy the next day to return to
CLOS + allegroserve.
OT: In physics, if the black hole is sufficiently large,
crossing the event horizon doesn't lead to any obvious
local effects (i.e. you don't die from tidal forces, etc).
Maybe the software complexity is already so large that we
don't notice the effect, and _that_'s the main problem.
Today I had to hack some ASP VB script (don't ask), and discovered
that their idea of "error handling" is you can either raise errors or
you can ignore them (no---I'm not making this up). This felt more
like a small black hole (a few solar masses): I felt I was imploding
in infinite pain the entire day. :-/
"Alain Picard" <·············································@memetrics.com>
wrote in message ···················@memetrics.com...
> I thought the whole point of all this J2EE nonsense was that
> you developed your application, then could drop the .war files
> in any compliant J2EE server. Hah!
It's a lofty goal, but that doesn't mean it shouldn't be a goal at all. One
of CLs strengths is its portability, along with Java. CL strives for source
level portability, while Java strives for both source and binary
portability. Why not leverage that portability at a higher level for larger
components?
I've had decent success moving Webapps (war files) from container to
container. While it's not perfect every time and some are more horrible than
others, they typically disagree at a fuzzy point in the spec rather than
being grossly non-compliant. And when it does work, it's really magic.
EJBs are different because they're implicitly non-portable in some specific
areas, but even then porting is a high level (though perhaps detailed)
configuration exercise rather than a drudge through the source code to fix
things.
> To be fair, JBOSS may just be particularly awful; this stuff
> worked pretty much as advertised on Jakarta and Weblogic.
Yes, precisely.
> Still, I was pretty darn happy the next day to return to
> CLOS + allegroserve.
Where you will have less portability (specifically it's not like you can
drop your application into CL-HTTP for example). Instead you get to carry
the actual plumbing around with your application.
Regards,
Will Hartung
(·····@msoft.com)
* Alain Picard wrote:
> OT: In physics, if the black hole is sufficiently large,
> crossing the event horizon doesn't lead to any obvious
> local effects (i.e. you don't die from tidal forces, etc).
> Maybe the software complexity is already so large that we
> don't notice the effect, and _that_'s the main problem.
That's what I meant. Actually, I think you *do* notice passing
through the horizon, at least for a Schwarzschild solution. When you
reach the horizon, then essentially everything out at infinity happens
at once (or to put it the other way: looking in from outside, you
never quite reach the horizon). So as you get very close to the
horizon, then you see the entire future history of the universe as you
look out: in particular all the radiation that will ever reach you
does so in a finite (and short) proper time. So although you're not
torn apart by tidal forces or anything, you get very cooked indeed.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Alain Picard wrote:
>
>> OT: In physics, if the black hole is sufficiently large,
>> crossing the event horizon doesn't lead to any obvious
>> local effects (i.e. you don't die from tidal forces, etc).
>> Maybe the software complexity is already so large that we
>> don't notice the effect, and _that_'s the main problem.
>
> That's what I meant. Actually, I think you *do* notice passing
> through the horizon, at least for a Schwarzschild solution.
In a large enough black hole you don't.
> When you reach the horizon, then essentially everything out at infinity happens
> at once (or to put it the other way: looking in from outside, you
> never quite reach the horizon). So as you get very close to the
> horizon, then you see the entire future history of the universe as you
> look out: in particular all the radiation that will ever reach you
> does so in a finite (and short) proper time. So although you're not
> torn apart by tidal forces or anything, you get very cooked indeed.
This is only from the outside frame of reference. When you are
falling in there is nothing particularly interesting going on.
* Joe Marshall wrote:
> This is only from the outside frame of reference. When you are
> falling in there is nothing particularly interesting going on.
Yes there is, that's what I meant by `proper time': time in the frame
of the person falling in. Of course, I may have missed something, and
it's a long time since I did GR.
--tim
Tim Bradshaw wrote:
> * Joe Marshall wrote:
>
>
>>This is only from the outside frame of reference. When you are
>>falling in there is nothing particularly interesting going on.
>
>
> Yes there is, that's what I meant by `proper time': time in the frame
> of the person falling in. Of course, I may have missed something, and
> it's a long time since I did GR.
The interesting thing that's going on in the falling reference frame is
the _process_ of getting incinerated, torn to shreds and crushed to a
singular point in finite time, but not the _moment_ of falling through
the event horizon. That moment isn't really distinguishable from the
moments before and after it. In fact, if you consider sufficiently large
or small holes, you'll see that cooking, shredding and crushing are only
coincidentally associated with the neighborhood of the horizon.
paul
From: Tim Bradshaw
Subject: Re: [OT] event horizons Re: Advantages of Lisp?
Date:
Message-ID: <ey3r7wkhvqg.fsf@cley.com>
* Paul Wallich wrote:
> The interesting thing that's going on in the falling reference frame
> is the _process_ of getting incinerated, torn to shreds and crushed to
> a singular point in finite time, but not the _moment_ of falling
> through the event horizon.
Yes, I understand this. The only thing that's interesting about
passing through the horizon is that it's the moment when your entire
future light cone is inside the horizon. What I'm confused about is
what happens to your past light cone at the moment you go through the
horizon, because that explains what you see, and if you see enough,
you cook.
The naive point of view is that the horizon is some magic place where
you get squashed. It's not, it's just the point of no return: when
you pass through it your entire future is inside it too (and for a
schwarzschild solution, your entire future is the singularity).
The semi-naive point of view (which I held) is that we know that if
you look in from infinity, then someone falling in never quite reaches
the horizon, they get infinitely red-shifted and essentially hover for
ever just outside it (in fact things are more complex, because you
very quickly get to the point where you've seen the last photon you'll
ever see from them, so they become unobservable (except possibly
gravitationally, but I think for any of it to work you need to assume
their gravitational effect is tiny anyway)). So semi-naively, in the
frame of the person falling in, everything out at infinity becomes
blue shifted arbitrarily far, and you see an awful lot of radiation.
This is nothing to do with being crushed by gravitational effects.
The article that Christophe Rhodes pointed me at (and I think
equivalently the stuff Joe Marshall pointed out) implies that this is
wrong, although without the maths. I think I was wrong (so the
semi-naive view above is wrong), but I'd need to see the maths to
really convince myself (and it would take me a long time to understand
the maths again after all this time!).
(Incidentally, I should point out that I started (and gave up) a PhD
dealing with causality violation in rotating solutions in GR, and I've
read & mostly understood the Hawking & Ellis book, so although it's a
long time ago now - and I now think I'm wrong! - I'm not making the
naive mistake, or not quite!)
--tim
On Wed, 25 Feb 2004 00:02:31 +0000, Tim Bradshaw <···@cley.com> wrote:
>So semi-naively, in the
>frame of the person falling in, everything out at infinity becomes
>blue shifted arbitrarily far, and you see an awful lot of radiation.
I thought the infinite blueshift applied only to an observer _standing
still_ at the event horizon? (Which would be the equivalent of
travelling at the speed of light in normal space, so it's not too
surprising.) An observer _falling through_ the event horizon [1] will
AFAIK only see finite blueshift?
[1] How fast would said observer be going anyway (in the frame of
reference in which the black hole isn't moving)? Would they be moving
at the speed of light?
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
From: Joe Marshall
Subject: Re: [OT] event horizons Re: Advantages of Lisp?
Date:
Message-ID: <ishvi7dl.fsf@ccs.neu.edu>
················@eircom.net (Russell Wallace) writes:
> I thought the infinite blueshift applied only to an observer _standing
> still_ at the event horizon? (Which would be the equivalent of
> travelling at the speed of light in normal space, so it's not too
> surprising.) An observer _falling through_ the event horizon [1] will
> AFAIK only see finite blueshift?
That seems to be what that web site was implying.
> [1] How fast would said observer be going anyway (in the frame of
> reference in which the black hole isn't moving)?
Um... Which frame of reference in which the black hole isn't moving?
Tim Bradshaw wrote:
> Yes, I understand this. The only thing that's interesting about
> passing through the horizon is that it's the moment when your entire
> future light cone is inside the horizon. What I'm confused about is
> what happens to your past light cone at the moment you go through the
> horizon, because that explains what you see, and if you see enough,
> you cook.
But what about Hawking-Unruh radiation? Doesn't the infalling
observer see this blue-shifted to infinity as he approaches
the event horizon?
Paul
* Paul Dietz wrote:
> But what about Hawking-Unruh radiation? Doesn't the infalling
> observer see this blue-shifted to infinity as he approaches
> the event horizon?
I don't think so (at least the same refs that various people pointed
me to earler say not, I think. But anyway, for the sake of argument
we could stick to classical stuff where it doesn't happen.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Joe Marshall wrote:
>
>> This is only from the outside frame of reference. When you are
>> falling in there is nothing particularly interesting going on.
>
> Yes there is, that's what I meant by `proper time': time in the frame
> of the person falling in. Of course, I may have missed something, and
> it's a long time since I did GR.
See http://casa.colorado.edu/~ajsh/schw.shtml
In particular on this page:
http://casa.colorado.edu/~ajsh/singularity.html
``At exactly 1 Schwarzschild radius, the horizon, the Schwarzschild
surface. The point of no return.
An observer outside the black hole cannot see us beyond this point
- we would appear to take an infinite amount of time to pass
through, becoming slower and more redshifted as time goes by. But
from our own point of view space and time continue normally.''
and this:
http://casa.colorado.edu/~ajsh/schwp.html
``Free-fall coordinates reveal that the Schwarzschild geometry looks
like ordinary flat space, with the distinctive feature that space
itself is flowing radially inwards at the Newtonian escape
velocity''
Tim Bradshaw <···@cley.com> writes:
> * Joe Marshall wrote:
>
>> This is only from the outside frame of reference. When you are
>> falling in there is nothing particularly interesting going on.
>
> Yes there is, that's what I meant by `proper time': time in the frame
> of the person falling in. Of course, I may have missed something, and
> it's a long time since I did GR.
I think <http://antwrp.gsfc.nasa.gov/htmltest/gifcity/bh_pub_faq.html>
may be of interest, in particular question 4.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christian Soltenborn <···················@web.de> writes:
> excuse me if this sounds kind of blasphemous, but I'm asking myself
> what the advantages of Lisp are, compared e.g. with Java.
Lisp has no advantages, it is all the other languages that have
*disadvantages*.
--
~jrm
On 2004-02-13 09:22:44, Christian Soltenborn wrote:
> excuse me if this sounds kind of blasphemous, but I'm asking myself what
> the advantages of Lisp are, compared e.g. with Java.
By the way: Lisp was there first. Why don't the users of the other
languages explain why they use them? :-)
On Sat, 14 Feb 2004 00:45:06 +0100, Stefan Scholl <······@no-spoon.de>
wrote:
>On 2004-02-13 09:22:44, Christian Soltenborn wrote:
>
>> excuse me if this sounds kind of blasphemous, but I'm asking myself what
>> the advantages of Lisp are, compared e.g. with Java.
>
>By the way: Lisp was there first. Why don't the users of the other
>languages explain why they use them? :-)
Because managers mistrust tools that make life easier for their
subordinates?
--
Christopher
Stefan Scholl <······@no-spoon.de> wrote in message news:<·················@parsec.no-spoon.de>...
> By the way: Lisp was there first. Why don't the users of the other
> languages explain why they use them? :-)
Greetings:
Back in the good 'ol days each machine had its own assembler. Then
came higher level languages of which Fortran was the first. Lisp is
number two. Everyone else comes after that. However, I still agree
with the basic premise.
Best regards,
Randyl Kent Plampin
Randyl Kent Plampin wrote:
> Back in the good 'ol days each machine had its own assembler. Then
> came higher level languages of which Fortran was the first. Lisp is
> number two. Everyone else comes after that. However, I still agree
> with the basic premise.
Fortran was not the first, nor was Lisp the second. They're just the
first and second *still in use today*. Check out
http://en.wikipedia.org/wiki/Timeline_of_programming_languages for some
extinct dinosaur languages.
Dirk Gerrits
Christian Soltenborn wrote:
> Hi everybody,
>
> excuse me if this sounds kind of blasphemous, but I'm asking myself what
> the advantages of Lisp are, compared e.g. with Java.
Looking back on it, when I went over to Java from C-double-plus as my
main language, the killer features were garbage collection and, when
using one of the early versions of the VisualCafe IDE, the ability to
alter and recompile a running application on the fly. Somehow Java lost
the latter for a while, whereas C++ gained it on Win32 (I think I first
saw it as a feature of SGI's C++).
In lisp these come as standard.
Currently at work I manipulating the abstract syntax trees of Modelica
(which is rapidly becoming my favorite programming language, despite
never having written any programs in it) to express relationships
between properties of the modelled systems. If I don't end up doing it
in lisp (politics, politics, though it's an R+D project so I might get
away with using a 'non-industry-standard' language) and end up doing it
in XSLT and RDF, I think the amount of work that I have to implement on
top of the base technology will double.
Pete
pete kirkham <·················@cafemosaic.co.uk> wrote in message
> Currently at work I manipulating the abstract syntax trees of Modelica
> (which is rapidly becoming my favorite programming language, despite
> never having written any programs in it) to express relationships
> between properties of the modelled systems. If I don't end up doing it
> in lisp (politics, politics, though it's an R+D project so I might get
> away with using a 'non-industry-standard' language) and end up doing it
> in XSLT and RDF, I think the amount of work that I have to implement on
> top of the base technology will double.
May I ask what the background and aim of your work with Modelica is?
I'm a heavy user of Modelica in my work, and as part of a part-time
PhD I'm doing some manipulation of the equation AST's using a mixture
of Java and Scheme (compiled into Java bytecode using JScheme). I'm
interested in any work being done on Modelica in the UK, most research
work on it is Sweden or Germany-based.
Pete
> Currently at work I manipulating the abstract syntax trees of Modelica
> (which is rapidly becoming my favorite programming language, despite
> never having written any programs in it) to express relationships
> between properties of the modelled systems. If I don't end up doing it
> in lisp (politics, politics, though it's an R+D project so I might get
> away with using a 'non-industry-standard' language) and end up doing it
> in XSLT and RDF, I think the amount of work that I have to implement on
> top of the base technology will double.
Cool. What compiler are you using for generating the AST, if I may
ask? Is there any other compiler than the OpenModelica compiler from
Link�ping University in which you can access the AST?
But this is probably getting a little bit OT.
/Kaj Nystr�m
Modelica compiler developer
·····@ida.liu.se
Kaj Nystr�m wrote:
> Cool. What compiler are you using for generating the AST, if I may
> ask? Is there any other compiler than the OpenModelica compiler from
> Link�ping University in which you can access the AST?
>
> But this is probably getting a little bit OT.
>
> /Kaj Nystr�m
> Modelica compiler developer
> ·····@ida.liu.se
I'm using the grammar from OpenModelica to generate it.
Pete