I've been toying with the idea of coming up to speed with
various hot trends in the unix world: tcl, perl, whatnot.
I'm finding this difficult because I'm an old lisp enthusiast and it
irks me to distraction that these peculiar little languages do neat
little tricks that could be easily accomplished in lisp -- without
having to learn a different syntax for each functionality, and without
the weird hobbled type system limitations, and with polymorphism
and macros etcetera etcetera etcetera....
Is there any *real* reason that a combination of GCL+CLX+GLUE+POSIX
hooks with some neat add-on packages couldn't replace all this gunk?
Maybe you can never get around the C-syntax chauvinism problem
but if the only other problem is program size or speed, can't we
expect the difficulty to go away as hardware cheapens?
Comments? -aaron
PS: I don't mean to detract from the accomplishments of the developers
of tcl, perl, and company -- congratulations guys, quite impressive
-- but do we really need a new language paradigm every time?
From: C. Titus Brown
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <306lfk$efl@gap.cco.caltech.edu>
In article <·····················@njitgw.njit.edu>,
Aaron Watters <·····@funcity.njit.edu> wrote:
>
>I've been toying with the idea of coming up to speed with
>various hot trends in the unix world: tcl, perl, whatnot.
>
>I'm finding this difficult because I'm an old lisp enthusiast and it
>irks me to distraction that these peculiar little languages do neat
>little tricks that could be easily accomplished in lisp -- without
>having to learn a different syntax for each functionality, and without
>the weird hobbled type system limitations, and with polymorphism
>and macros etcetera etcetera etcetera....
LISP isn't ideal for everything, either; the reasons all of these languages
proliferate is because people like them and use them (sorry, that was
probably too obvious :). I've seen LISP, and I'm planning to delve into
it soon, but it can be a fairly annoying language to work with (from
reports, at least).
Competition is good :). If we all stuck with LISP-like languages, then
we'd have a pretty non-diverse set of languages...
>Is there any *real* reason that a combination of GCL+CLX+GLUE+POSIX
>hooks with some neat add-on packages couldn't replace all this gunk?
>Maybe you can never get around the C-syntax chauvinism problem
>but if the only other problem is program size or speed, can't we
>expect the difficulty to go away as hardware cheapens?
This is one reason I chose Tk/Tcl for my application; quick prototyping speed,
fast runtime, easy integration into speedy C (OK, I just threw the last in :).
While in the future computers may become fast enough, I really would like
to get something done *now*. 'sides, we can expect things to grow ever more
hoggy and slower as hardware gets faster... It's been the nature so far.
Cheers,
--titus
--
C. Titus Brown <- http://www.krl.caltech.edu/~brown/plan.html -> ·····@reed.edu
--> ········@d--,-p+,c++++,l,u(++),e+,m+,s+/,n+,h+,f+,g+,w+,t-,r-,y? <--
Sysadmin at Caltech KRL / Guest sysadmin at Reed College
Member of the Avida Artificial Life research group
From: Logan Shaw
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <Ct09y7.B0z@taligent.com>
In article <·····················@njitgw.njit.edu>, ·····@funcity.njit.edu (Aaron Watters) writes:
> I'm finding this difficult because I'm an old lisp enthusiast and it
> irks me to distraction that these peculiar little languages do neat
> little tricks that could be easily accomplished in lisp
What does the "p" in "perl" stand for? "Practical". For the tasks it's
geared towards, perl is danged practical. It's in the Unix idiom, so those
familiar with Unix can learn to use it relatively easily. It lets you screw
around with text really easily. It's concise. It's efficient -- efficient
enough that you can generally use a decently written perl program without
frequently thinking "Maybe I should re-write this in C."
Perl is a tool. It's well suited for a particular task. Maybe it's
possible to do all that stuff in lisp, but all the convenient stuff like
formats, associative arrays, sockets, split(), join(), s/foo/bar/, `foo`,
dbmopen(), system(), and die() are already in perl. Is there a version of
lisp that has all the convenience features that perl already has? (Actually,
this is an honest question. If there is, it might be interesting.)
> -- without
> having to learn a different syntax for each functionality,
Agreed. This is annoying. It might be worth it, though.
> and without
> the weird hobbled type system limitations,
What limitations? Perl is really pretty good about not imposing arbitrary
limitations.
Adios,
Logan
--
The genius of France can be seen at a glance
And it's not in their fabled fashion scene
It's not that they're mean, or their wine, or cuisine
I refer of course to the guillotine
(the French knew how to lynch)
T-Bone Burnett, "I Can Explain Everything"
From: Wayne A. Christopher
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <30jmso$ga3@agate.berkeley.edu>
I think the reason that Lisp hasn't caught on where Tcl and Perl have
must be 90% psychological and only 10% technical, if that. The one
big problem I can think of with Lisp is that I have never seen one
that interfaces well with C, both because of data representation issues
and garbage collection, but this doesn't seem an insurmountable problem.
What is it about Lisp that makes "normal people" shy away from it? I think
this is a question that programmers can't answer -- I would have been
just as happy using Lisp as Tcl, but that's probably because Lisp was
my first language after Basic (C a close third). I wonder if anybody
has done a psycholgical study about this...
Wayne
In article <··········@agate.berkeley.edu> ·······@remarque.berkeley.edu (Wayne A. Christopher) writes:
: I think the reason that Lisp hasn't caught on where Tcl and Perl have
: must be 90% psychological and only 10% technical, if that. The one
: big problem I can think of with Lisp is that I have never seen one
: that interfaces well with C, both because of data representation issues
: and garbage collection, but this doesn't seem an insurmountable problem.
: What is it about Lisp that makes "normal people" shy away from it? I think
: this is a question that programmers can't answer -- I would have been
: just as happy using Lisp as Tcl, but that's probably because Lisp was
: my first language after Basic (C a close third). I wonder if anybody
: has done a psycholgical study about this...
Perl IS a psychological study.
Larry Wall
·····@netlabs.com
In article <······················@netlabs.com>, ·····@netlabs.com (Larry Wall) writes:
|> In article <··········@agate.berkeley.edu> ·······@remarque.berkeley.edu (Wayne A. Christopher) writes:
|> : I wonder if anybody has done a psycholgical study about this...
|>
|> Perl IS a psychological study.
|>
|> Larry Wall
|> ·····@netlabs.com
So what does that make us --- the guinea pigs? ;-)
Frank
From: Jacob Hallen
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <307cdd$gmd@nyheter.chalmers.se>
In article <·····················@njitgw.njit.edu>,
Aaron Watters <·····@funcity.njit.edu> wrote:
>
>I've been toying with the idea of coming up to speed with
>various hot trends in the unix world: tcl, perl, whatnot.
>
>I'm finding this difficult because I'm an old lisp enthusiast and it
>irks me to distraction that these peculiar little languages do neat
>little tricks that could be easily accomplished in lisp -- without
>having to learn a different syntax for each functionality, and without
>the weird hobbled type system limitations, and with polymorphism
>and macros etcetera etcetera etcetera....
There is (if I may say so (and I really hope I may)) a small disadvantage
(maybe not so small either (in fact rather large (not to say huge))) in the
usage of lisp (or scheme (or any other lookalikes)) that readbility is
rather low (very low (if you want my opinion)).
Jacob Hallen
From: Jonathan Badger
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <badger.774321865@phylo>
>In article <·····················@njitgw.njit.edu>,
>Aaron Watters <·····@funcity.njit.edu> wrote:
>>
>>I've been toying with the idea of coming up to speed with
>>various hot trends in the unix world: tcl, perl, whatnot.
>>
>>I'm finding this difficult because I'm an old lisp enthusiast and it
>>irks me to distraction that these peculiar little languages do neat
>>little tricks that could be easily accomplished in lisp -- without
>>having to learn a different syntax for each functionality, and without
>>the weird hobbled type system limitations, and with polymorphism
>>and macros etcetera etcetera etcetera....
Well, another reason is that LISP isn't very popular as a general purpose
language any more. Not that there aren't cases where it is still useful, but
the typical '90s programmer is much more comfortable with C and languages
which try to provide a C-like syntax such as awk, perl, and tcl.
From: Brian Blackmore
Subject: Re: Readablity (was Re: Unix tower of babble tcl/awk/perl -- why not just lisp?)
Date:
Message-ID: <1994Jul20.103232.283@gryphon.demon.co.uk>
Mark S. Riggle (······@zinfande.unx.sas.com) wrote:
[...]
: Come on, Perl is just about the only language that remains
: as readable under ROT_13 as before.
As with any langauge its not the language that is the primary fault of
unreadable code its the person that wrote the code. Perl like any other
language lets you write unreadable code (regex's being the primary fault
here), but with a little care and thought readable code is quite possible.
--
Brian Blackmore (···@gryphon.demon.co.uk) Phone: +44 81 391 1116
They gave it me,-- for an un-birthday present.
* Jacob Hallen wrote:
* Jacob Hallen wrote:
> There is (if I may say so (and I really hope I may)) a small disadvantage
> (maybe not so small either (in fact rather large (not to say huge))) in the
> usage of lisp (or scheme (or any other lookalikes)) that readbility is
> rather low (very low (if you want my opinion)).
No one comparing lisp and perl can complain about lisp's readability.
SENDMAIL config files are more readable than perl. Considerably more
readable, in fact.
Anyway, just why do people think lisp is unreadable (complex
arithmetic expressions apart)?
--tim
From: Jonathan Badger
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <badger.774716781@phylo>
···@cogsci.ed.ac.uk (Tim Bradshaw) writes:
>No one comparing lisp and perl can complain about lisp's readability.
>SENDMAIL config files are more readable than perl. Considerably more
>readable, in fact.
>Anyway, just why do people think lisp is unreadable (complex
>arithmetic expressions apart)?
I think the more relevant question is why you think Perl is unreadable. It's
a very straightforward structured language, much like C, and very readable
to C programmers. I can't imagine why you think Perl is unreadable, unless
you think C is also unreadable.
I think many people find LISP unreadable because its philosophy is so
different from other languages (I don't count Scheme as a language in its
own right), while awk and perl share the same structured philosophy as C,
Pascal, Algol, etc.
In article <················@phylo> you write:
>···@cogsci.ed.ac.uk (Tim Bradshaw) writes:
[deleted stuff about readability of lisp as compared to Perl]
>I think the more relevant question is why you think Perl is unreadable. It's
>a very straightforward structured language, much like C, and very readable
>to C programmers. I can't imagine why you think Perl is unreadable, unless
>you think C is also unreadable.
Stupid thread. Everyone finds some languages easier than others. I
find it extremely difficult to read C (among others), but very simple
to read both Perl and Lisp (and half a dozen other languages).
Who gives a toss?
--
Jack ··@biu.icnet.uk
If you only have a hammer, you tend to see every problem as a nail.
-- Maslow
In article <·················@burns.cogsci.ed.ac.uk> ···@cogsci.ed.ac.uk (Tim Bradshaw) writes:
: * Jacob Hallen wrote:
:
: > There is (if I may say so (and I really hope I may)) a small disadvantage
: > (maybe not so small either (in fact rather large (not to say huge))) in the
: > usage of lisp (or scheme (or any other lookalikes)) that readbility is
: > rather low (very low (if you want my opinion)).
:
: No one comparing lisp and perl can complain about lisp's readability.
: SENDMAIL config files are more readable than perl. Considerably more
: readable, in fact.
I'll bet you have trouble with Greek and Arabic too.
: Anyway, just why do people think lisp is unreadable (complex
: arithmetic expressions apart)?
Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in.
Larry Wall
·····@netlabs.com
From: Martin Rodgers
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <774958764snz@wildcard.demon.co.uk>
In article <······················@netlabs.com>
·····@netlabs.com "Larry Wall" writes:
> Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in.
Which Lisp do you mean? One of the first Lisps I remember reading about
was MuLisp. It included an Algol-like front end call MuSimp, and this
was used to write the MuMath pachage. It didn't look a bit like what
most people would call "Lisp", which is really just a collection of
dialects. These days we could talk about Dylan, which also uses as
Algol-like syntax _as_standard_. In fact, this isn't even an option.
--
Martin Rodgers, WKBBG, London UK AKA "Cyber Surfer"
If "One likes to believe in the freedom of email", email
················@cpsr.org and tell them you oppose Clipper.
This is a shareware .signature -- please pass it on!
From: Peter da Silva
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <id.HLMB1.XBH@nmti.com>
In article <··········@lgc.com>, Pat Martin <···@Advance.COM> wrote:
> |> Anyway, just why do people think lisp is unreadable (complex
> |> arithmetic expressions apart)?
> Too many ()'s for my taste, however one dialect I used had a ] which said
> close all open parens.
The biggest problem is that Lispers have this annoying paper-saving habit
that hides control structure:
( ( (( ) ( ))
(( ( ( ) ( )))) ( ( ) ( )))
(( ) ( ))))
Instead of:
(
(
(( ) ( ))
(( ( ( ) ( )) )
(
( )
( )
)
)
(( ) ( ))
)
)
After enough re-training you can see the structure of the first set of
parens at a glance, but to the novice it looks like gibberish. A true
Lisper will barf at my second example, but it *does* let you see the
nesting at a glance, and tell control constructs from expressions.
You can read the code without being in an editor that does paren matching.
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Hast Du heute schon Deinen Wolf umarmt?"
In article <············@nmti.com>, ·····@nmti.com (Peter da Silva) wrote:
;; The biggest problem is that Lispers have this annoying paper-saving habit
;; that hides control structure:
[nice, well-formed parens]
;; Instead of:
[ugly, C-style formatted parens]
;; After enough re-training you can see the structure of the first set of
;; parens at a glance, but to the novice it looks like gibberish. A true
;; Lisper will barf at my second example, but it *does* let you see the
;; nesting at a glance, and tell control constructs from expressions.
;;
;; You can read the code without being in an editor that does paren matching.
Are you saying you would rather see this:
(
defmethod draw-ports ((view rview) dir)
"in: view, dir {:input, :output}"
(
let (
(fn (
if (equal dir :input)
'n-in
'n-out)
)
)
(
unless (= (funcall fn view) 0)
(
with-focused-view view
(
dotimes (
n (funcall fn view)
)
(draw-port view n dir)
)
)
)
)
)
over this:
(defmethod draw-ports ((view rview) dir)
"in: view, dir {:input, :output}"
(let ((fn (if (equal dir :input) 'n-in 'n-out)))
(unless (= (funcall fn view) 0)
(with-focused-view view
(dotimes (n (funcall fn view))
(draw-port view n dir))))))
The second example "*does* let you see the nesting at a glance, and
tell control constructs from expressions.". The first example is a
horrid example of formatting which would only be written by a C
programmer being forced to use Lisp. Judging by the formatting and the
parens, your example is a function call which gets its first argument from
a cond statement. Simple, easy to read, and completely unambiguous.
The biggest problem is that C-ers have this annoying habit of spreading
their code over as much space as possible, in an attempt to make it look
like more code. ;-)
Cheers, Adam
--
Adam Alpern. HCC Group, University of Colorado at Boulder
···@cs.colorado.edu
···@neural.hampshire.edu
In article <··················@lemur.cs.man.ac.uk>, ·····@cs.man.ac.uk (Stephen J Bevan) wrote:
;; In article <··········@nz12.rz.uni-karlsruhe.de> ······@ma2s2.mathematik.uni-karlsruhe.de (Bruno Haible) writes:
;; > (defmethod draw-ports ((view rview) dir)
;; > "in: view, dir {:input, :output}"
;; > (let ((fn (if (equal dir :input) 'n-in 'n-out)))
;; > (unless (= (funcall fn view) 0)
;; > (with-focused-view view
;; > (dotimes (n (funcall fn view))
;; > (draw-port view n dir))))))
;; >
;; No. It is difficult to see where the (unless...) form ends.
;;
;; Why is it difficult? Isn't the scope of the unless is clear from the
;; indentation?
In this particular caser, everything after the unless line is within
the scope of the (unless ... ). If something else followed
and was indented to the same level as the openiong of the unless,
that would be the first piece of code outside its scope.
adam
--
Adam Alpern. HCC Group, University of Colorado at Boulder
···@cs.colorado.edu
···@neural.hampshire.edu
From: Jim McDonald
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <1994Aug1.194601.4147@kestrel.edu>
In article <··········@nz12.rz.uni-karlsruhe.de>, ······@ma2s2.mathematik.uni-karlsruhe.de (Bruno Haible) writes:
|> Adam Alpern <···@cs.colorado.edu> wrote:
|> >
|> > (defmethod draw-ports ((view rview) dir)
|> > "in: view, dir {:input, :output}"
|> > (let ((fn (if (equal dir :input) 'n-in 'n-out)))
|> > (unless (= (funcall fn view) 0)
|> > (with-focused-view view
|> > (dotimes (n (funcall fn view))
|> > (draw-port view n dir))))))
|> >
|> > The second example "*does* let you see the nesting at a glance, and
|> > tell control constructs from expressions.".
|>
|> No. It is difficult to see where the (unless...) form ends. (Need to
|> see this for example if you want to insert another form after it.)
Working within emacs is a tremendous win here, and I can imagine
this would be frustrating in an editor that did not match parens.
My usual tactic in such cases is to simply go to where I think
the form ends, insert a newline and then tab for indentation
(two keystrokes). If the closing parens move over to where I
expect (true 95% of the time), I just enter the new code. If not,
I move one or two parens as appropriate. Others may have
different, even better, methods or editor features.
|>
|> How about this layout?
|>
|> (defmethod draw-ports ((view rview) dir)
|> "in: view, dir {:input, :output}"
|> (let ((fn (if (equal dir :input) 'n-in 'n-out)))
|> (unless (= (funcall fn view) 0)
|> (with-focused-view view
|> (dotimes (n (funcall fn view))
|> (draw-port view n dir)
|> ) ) ) ) )
Personally (after writing hundreds of thousands of lines of lisp code
and reading several times more), blech. I think the problem is that
my eye is drawn to the ") ) ) ) )" only to discover that it conveys
zero useful information (unless perhaps I'm editting in something
other than emacs). It's like having speed bumps in the road.
Normally I don't even see the parens at any conscious level--the
keywords, functions, and formatting convey almost everything. (Again,
auto-indenting in emacs keeps things in a consistent form so there is
a good correlation between the formatting I see and the structure of
the code.)
For what it's worth, when I write C code, the same habit of ignoring
delimiting punctuation gets me into trouble, so I have to pay conscious
attention to delimiting punctuation, doing the kinds of things you
suggested for lisp. But I've only written a few tens of thousands of
lines of C code, and my eyes and fingers are not as trained there, so
I don't know if it is C itself or my unfamiliarity with it that
encourages that style.
|>
|> To insert something after the (unless...) form, split the parentheses line
|> appropriately
|>
|> ) ) )
|> ) )
|>
|> and then insert the stuff. You need *not* count parentheses, only obey
|> the vertical lines.
I don't know anyone experienced with lisp who counts parentheses
explicitly. Rather, there are (perhaps fuzzy) patterns you recognize,
and editors to do precise matching for you. You could remove all the
parens and many lisp hackers would barely notice.
--
James McDonald
Kestrel Institute ········@kestrel.edu
3260 Hillview Ave. (415) 493-6871 ext. 339
Palo Alto, CA 94304 fax: (415) 424-1807
From: Mike McDonald
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <CtvKo1.4o1@jabba.ess.harris.com>
In article <····················@kestrel.edu>, ········@kestrel.edu (Jim McDonald) writes:
|>
|> In article <··········@nz12.rz.uni-karlsruhe.de>, ······@ma2s2.mathematik.uni-karlsruhe.de (Bruno Haible) writes:
|> |> Adam Alpern <···@cs.colorado.edu> wrote:
|> |> >
|> |> > (defmethod draw-ports ((view rview) dir)
|> |> > "in: view, dir {:input, :output}"
|> |> > (let ((fn (if (equal dir :input) 'n-in 'n-out)))
|> |> > (unless (= (funcall fn view) 0)
|> |> > (with-focused-view view
|> |> > (dotimes (n (funcall fn view))
|> |> > (draw-port view n dir))))))
|> |> >
|> |> > The second example "*does* let you see the nesting at a glance, and
|> |> > tell control constructs from expressions.".
|> |>
|> |> No. It is difficult to see where the (unless...) form ends. (Need to
|> |> see this for example if you want to insert another form after it.)
|>
|> Working within emacs is a tremendous win here, and I can imagine
|> this would be frustrating in an editor that did not match parens.
|> My usual tactic in such cases is to simply go to where I think
|> the form ends, insert a newline and then tab for indentation
|> (two keystrokes). If the closing parens move over to where I
|> expect (true 95% of the time), I just enter the new code. If not,
|> I move one or two parens as appropriate. Others may have
|> different, even better, methods or editor features.
Why not go to the opening paren and hit Meta Control Forward? It'll take you
straight to the matching paren. I let the computer count parens for me. It ought
to be good for something! :-)
Mike McDonald Advanced Technology Dept.
Harris Corp.
Email: ···@trantor.harris-atd.com M.S. 16-1912
Voice: (407) 727-5060 P.O. Box 37
Fax: (407) 729-3363 Melbourne, Florida 32902
In article <············@nmti.com>, ·····@nmti.com (Peter da Silva) writes:
> After enough re-training you can see the structure of the first set of
> parens at a glance, but to the novice it looks like gibberish. A true
> Lisper will barf at my second example, but it *does* let you see the
> nesting at a glance, and tell control constructs from expressions.
What does this obsession with the "to the novice it's too difficult"
style reasoning, which seems to permeate all of the computer industry
these days, have to do with LISP?
What is the justification for this great fear of how productive the
beginner will be, even if once the experience sets in (a few months
maybe?) productivity will surpass what it could have been starting out
on a novice-proof system?
Frankly, i *like* the density of LISP syntax. I can put more on the
screen and don't have to dart around so much when piecing parts of the
program together... But that's because after months of experience, i
can see the structure of COND at a glance. Oh my... what a skill this
is!
rodrigo vanegas
··@cs.brown.edu
In article <················@monaco.cs.brown.edu>, ··@cs.brown.edu (rodrigo vanegas) wrote:
;; In article <············@nmti.com>, ·····@nmti.com (Peter da Silva) writes:
;;
;; > After enough re-training you can see the structure of the first set of
;; > parens at a glance, but to the novice it looks like gibberish. A true
;; > Lisper will barf at my second example, but it *does* let you see the
;; > nesting at a glance, and tell control constructs from expressions.
;;
;; Frankly, i *like* the density of LISP syntax. I can put more on the
;; screen and don't have to dart around so much when piecing parts of the
;; program together... But that's because after months of experience, i
;; can see the structure of COND at a glance. Oh my... what a skill this
;; is!
Agreed. I've often wished that C had something as elegant as COND, which
allows a switch (C) / case (LISP) like form, but with any number of
arbitrary conditions, instead of the limitation to testing equality
against an int. True, it did take about 2 months for me to get the
hang of lisp, but once I did, I found it much easier to delve into the
language and further my knowledge of it than was possible when I first
learned C.
--
Adam Alpern. HCC Group, University of Colorado at Boulder
···@cs.colorado.edu
···@neural.hampshire.edu
From: Christopher Hoover
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <CtpnIB.7Gw.3@cs.cmu.edu>
In article <············@nmti.com>, Peter da Silva <·····@nmti.com> wrote:
>A true Lisper will barf at my second example, but it *does* let you see the
>nesting at a glance, and tell control constructs from expressions.
> [ Second example. ]
Barf.
I do agree with you to a point: some lispers don't hit the LF key
often enough. For instance:
(if (oddp n) (complex (expression (here))) (different (expression)))
vs.
(if (oddp n)
(complex (expression (here)))
(different (expression)))
The later shows the structure more clearly.
However I don't believe that putting opening and closing parens on
separate lines increases readability at all -- in fact I think it does
the opposite. If nothing else it wastes valuable screen real estate.
-- Chris.
(··@lks.csi.com)
You can lead a C++'er to water, but if you don't tie him up you can't
make him drown. (Apologies to the Psychodots.)
* In article <············@cs.cmu.edu>
* ···@cs.cmu.edu (Christopher Hoover) writes:
<...>
> I do agree with you to a point: some lispers don't hit the LF key
> often enough. For instance:
> (if (oddp n) (complex (expression (here))) (different (expression)))
> vs.
> (if (oddp n)
> (complex (expression (here)))
> (different (expression)))
> The later shows the structure more clearly.
>
> However I don't believe that putting opening and closing parens on
> separate lines increases readability at all -- in fact I think it does
> the opposite. If nothing else it wastes valuable screen real estate.
A year or so ago, I read an article in, lessee, coulda been
comp.std.c?, where a guy suggested this improvement to C formatting
(this is my own paraphrase):
type function (type argument, ...)
{
control {
control {
control {
blah (blah, blah, "blah!");
blab (blah);
} } } } // <- this line is It
His own comment to this was something like, "First, you kind of go
yikes, then, you realize it doesn't work the way you thought it
would, and then you realize it still does work, only the other way
around".
I don't know. I like it.
The general public was disgusted.
--
/* era */
--
era eriksson .obMantra: Fest alla dagar .obDiscl: Kibo didn't approve this
From: Colas Nahaboo
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <31tcv5$g2e@sophia.inria.fr>
In article <············@nmti.com>, ·····@nmti.com (Peter da Silva) writes:
|> The biggest problem is that Lispers have this annoying paper-saving habit
|> that hides control structure:
|> Instead of:
I agree (I use a C-like indentation in lips too). If other lispers would
like to try a more C-like indentation method, use the amc-lisp emacs
indentation package by Alan M. Carrol (one of the first epoch authors)
(I have put it on ftp as avahi.inria.fr:/pub/amc-lisp.el)
--
Colas Nahaboo, Koala (Bull Research)
Mosaic Info: <A HREF="http://zenon.inria.fr:8003/koala/colas.html"></A>
From: Dave Mitchell
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <325hm2$ie8@gate1.dcs.shef.ac.uk>
[ various stuff about indentation and layout in C and lisp deleted ]
The best idea I've seen so far for indentaion comes from the Occam
language. Here, the indentation actually *defines* the program structure,
so theres no need for zillions of () or {} or BEGIN/END, and it has the
huge advantage that the structure as understood by the compiler matches
how it appears visually - in most languages these only coincide if you're
lucky - otherwise it's hours of enless fun trying to work out why the
compiler has just complained of an unexpected EOF.
For example, the traditional C construct
if (e1) {
s1.1;
s1.2;
} else if (e2) {
s2.1;
s2.2;
s2.3;
} else {
s3.1;
s3.2;
}
becomes in occam (roughly speaking)
if
e1
s1.1
s1.2
e2
s2.1
s2.2
s2.3
true
s3.1
s3.2
(in this case, the if statement evaluates each expression in turn
til it finds that comes out true, then executes all statements in that branch.)
personally I think this is a lot cleaner and less error-prone, but
perhaps people will disagree with me???
Dave.
* David Mitchell, Systems Administrator, email: ··········@dcs.shef.ac.uk
* Dept. Computer Science, Sheffield Uni. phone: +44 114-282-5573
* 211 Portobello St, Sheffield S1 4DP, UK. fax: +44 114-278-0972
*
* Standards (n). Battle insignia or tribal totems
From: Mike Stok
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <325sgg$2os@hibbert.meiko.com>
In article <··········@gate1.dcs.shef.ac.uk>,
Dave Mitchell <···@dcs.shef.ac.uk> wrote:
>[ various stuff about indentation and layout in C and lisp deleted ]
>
>The best idea I've seen so far for indentaion comes from the Occam
>language. Here, the indentation actually *defines* the program structure,
>so theres no need for zillions of () or {} or BEGIN/END, and it has the
>huge advantage that the structure as understood by the compiler matches
>how it appears visually - in most languages these only coincide if you're
>lucky - otherwise it's hours of enless fun trying to work out why the
>compiler has just complained of an unexpected EOF.
>personally I think this is a lot cleaner and less error-prone, but
>perhaps people will disagree with me???
I'll disagree! I thought I'd seen the last of Occam, it has too many
memories of the absolutely "different" TDS environment and a folding
editor that let you replicate any amount of code in a single fold... Yuck!
In perl would that mean that a string I wanted to eval later would also
have to be indented properly internally?
If you look at comp.lang.python you'll see people coming from the other
direction, asking that the indentation not be so significant.
There are lots of issues with this sort of argument, and alas most of
them boil down to taste & personal preferance. I'd rather have a
flexible language and reasonably enforced local coding standards ("Smith,
there's a space missing from this line... That's the third time this
month... Here's yout P45!" :-).
Mike
--
The "usual disclaimers" apply. | Meiko
Mike Stok | 130C Baker Ave. Ext
·········@meiko.concord.ma.us | Concord, MA 01742
Meiko tel: (508) 371 0088 x124 |
In article <··········@gate1.dcs.shef.ac.uk> ···@dcs.shef.ac.uk (Dave Mitchell) writes:
so theres no need for zillions of () or {} or BEGIN/END, and it has the
huge advantage that the structure as understood by the compiler matches
how it appears visually - in most languages these only coincide if you're
lucky - otherwise it's hours of enless fun trying to work out why the
compiler has just complained of an unexpected EOF.
huh? hours?
what sort of editor *do* you use?
even in vi (which is what i seem to remember that you use),
automatic indentation is only a few keystrokes away.
shoot, even on the pc, most of the editors will let you jump to the
matching bracket.
of course, if you have a language which doesn't have much redundancy
in terms of visually presenting structure (i.e. indentation *and*
bracketing) then you are pretty well screwed in trying to implement an
auto-indenter. even there, though, unexpected EOF doesn't figure as a
time waster.
From: Tuan Doan
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <326q6t$3ct@crchh404.bnr.ca>
In article <··········@gate1.dcs.shef.ac.uk>,
Dave Mitchell <···@dcs.shef.ac.uk> wrote:
>[ various stuff about indentation and layout in C and lisp deleted ]
>
>The best idea I've seen so far for indentaion comes from the Occam
>language. Here, the indentation actually *defines* the program structure,
>so theres no need for zillions of () or {} or BEGIN/END, and it has the
>huge advantage that the structure as understood by the compiler matches
>how it appears visually - in most languages these only coincide if you're
>lucky - otherwise it's hours of enless fun trying to work out why the
>compiler has just complained of an unexpected EOF.
>
>For example, the traditional C construct
>
>if (e1) {
> s1.1;
> s1.2;
>} else if (e2) {
> s2.1;
> s2.2;
> s2.3;
>} else {
> s3.1;
> s3.2;
>}
>
>becomes in occam (roughly speaking)
>
>if
> e1
> s1.1
> s1.2
> e2
> s2.1
> s2.2
> s2.3
> true
> s3.1
> s3.2
>
>(in this case, the if statement evaluates each expression in turn
>til it finds that comes out true, then executes all statements in that branch.)
>
>personally I think this is a lot cleaner and less error-prone, but
>perhaps people will disagree with me???
>
>Dave.
>
>* David Mitchell, Systems Administrator, email: ··········@dcs.shef.ac.uk
>* Dept. Computer Science, Sheffield Uni. phone: +44 114-282-5573
>* 211 Portobello St, Sheffield S1 4DP, UK. fax: +44 114-278-0972
>*
>* Standards (n). Battle insignia or tribal totems
Python also stresses correct indentation style. As a matter of fact, like
occam, the syntax of some of its statement require indentation.
Regards,
__ __/ / / __ / | / Tuan T. Doan
/ / / / / / | / IEC Layer Testing and Advance Technology
/ / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871
__/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871
"It's a kind of magic" -Highlander Phone: 6-444-4575/214-684-4575
Internet: ·····@bnr.ca Fax: 6-444-3716/214-684-3716
In article <··········@crchh404.bnr.ca> ·····@bnr.ca (Tuan Doan) writes:
: Python also stresses correct indentation style. As a matter of fact, like
: occam, the syntax of some of its statement require indentation.
Outlines have their place, and give at least the appearance of
organization. But real life tends to be be a little more tangled
than that. I doubt you write love letters in outline form.
The basic problem of outlines from a psychological point of view is
that they violate the Aristotelian notion that things should have a
beginning, a middle, and an end. Implicit terminations confuse the end
of one thing with the beginning of the next. You have to start
understanding the next thing before you can put the previous thing out
of your mind. For instance, if at the end of one screen I see
while something:
foo
I don't know whether the next screen is going to start with
bar
or with
bar
But if I see
while (something) {
bar;
then I know darn well that the next page is going to start inside
that block, and if I see
while (something) {
bar;
}
then I know it darn well isn't.
You won't find many dangling structures in Perl for this reason. Lisp
also gets this right, though the typical Lisp indenting style throws
the advantage away.
Larry Wall
·····@netlabs.com
From: Steve Mitchell
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <CuFyLx.4xK@zimmer.CSUFresno.EDU>
In article <··········@gate1.dcs.shef.ac.uk> ···@dcs.shef.ac.uk (Dave Mitchell) writes:
>
>becomes in occam (roughly speaking)
>
>if
> e1
> s1.1
> s1.2
> e2
> s2.1
> s2.2
> s2.3
> true
> s3.1
> s3.2
>
>(in this case, the if statement evaluates each expression in turn
>til it finds that comes out true, then executes all statements in that branch.)
>
>personally I think this is a lot cleaner and less error-prone, but
>perhaps people will disagree with me???
>
It would be really neat if it required that the code be in all caps..
Let's see... "OCCAM" Swap the 'O' and the first 'C'.. "COCAM"
Change the second 'C' to a 'B'.. "COBAM" The 'M' to a 'L'.. "COBAL"
And the 'A' to an 'O'.. "COBOL"
Yep, just as I thought..
>Dave.
>
--steve
--
Steve Mitchell KD6BET TIP#168 ··············@csufresno.edu
"Everything in this message may be wrong." / "Make love, not Perl code."
From: Brian Blackmore
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <32i4u5$2t@gryphon.demon.co.uk>
In article <··········@gate1.dcs.shef.ac.uk>,
Dave Mitchell <···@dcs.shef.ac.uk> wrote:
>[ various stuff about indentation and layout in C and lisp deleted ]
>
>The best idea I've seen so far for indentaion comes from the Occam
>language. Here, the indentation actually *defines* the program structure,
>so theres no need for zillions of () or {} or BEGIN/END, and it has the
>huge advantage that the structure as understood by the compiler matches
>how it appears visually - in most languages these only coincide if you're
>lucky - otherwise it's hours of enless fun trying to work out why the
>compiler has just complained of an unexpected EOF.
>
>For example, the traditional C construct
>
>if (e1) {
> s1.1;
> s1.2;
>} else if (e2) {
> s2.1;
> s2.2;
> s2.3;
>} else {
> s3.1;
> s3.2;
>}
>
>becomes in occam (roughly speaking)
>
>if
> e1
> s1.1
> s1.2
> e2
> s2.1
> s2.2
> s2.3
> true
> s3.1
> s3.2
>
>(in this case, the if statement evaluates each expression in turn
>til it finds that comes out true, then executes all statements in that branch.)
>
>personally I think this is a lot cleaner and less error-prone, but
>perhaps people will disagree with me???
I've worked with Occam (and Miranda which has a similar problem) and have
found that having indentation significant is a pain in the neck. The main
problem is that humans can not match vertically any more than they can match
brackets. Its far too easy not to be able to visualise that something at the
bottom of the screen matches with something at the top, and its not easy to
get the ruler out on the screen, with brackets at least you can count them.
You also can't tell where a block ends, you look at the statement that starts
a block, look downwards and the statement that terminates it is way to the
left (something like a new IF statement).
Languages like C,Perl and Lisp have two methods of matching. The brackets
provide the first method, the one that the compiler uses, while the global
indentation convention provides the second. Most of the time I find I use
indentation, but to find out where a block ends the closing bracket is most
useful.
The Occam system I used compensated for this to some extent by using a
folding editor, but all this actually did was provide the brackets!!
--
Brian Blackmore.
From: Marco Antoniotti
Subject: Re: Readablity (was Re: Unix tower of babble tcl/awk/perl -- why not just lisp?)
Date:
Message-ID: <MARCOXA.94Jul20130155@mosaic.nyu.edu>
In article <············@early-bird.think.com> ······@think.com (Barry Margolin) writes:
From: ······@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp,comp.lang.perl,comp.lang.tcl,comp.lang.clos
Date: 19 Jul 1994 16:42:26 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 15
In article <·········@unx.sas.com> ······@zinfande.unx.sas.com (Mark S. Riggle) writes:
>Come on, Perl is just about the only language that remains
>as readable under ROT_13 as before.
True, but no one in this thread has suggested using APL or TECO as a
scripting language. The closest thing in any of the languages under
discussion is Common Lisp's FORMAT control string (which is almost Turing
complete -- it can call arbitrary functions as subroutines, but I'm not
sure the order of calls is specified).
You are forgetting INTERCAL :)
Happy Lisping
--
Marco Antoniotti - Resistente Umano
-------------------------------------------------------------------------------
Robotics Lab | room: 1220 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
Bertholdt Brecht
From: Logan Shaw
Subject: Re: Readablity (was Re: Unix tower of babble tcl/awk/perl -- why not just lisp?)
Date:
Message-ID: <Ct9qtu.LH5@taligent.com>
In article <·········@unx.sas.com>, ······@zinfande.unx.sas.com (Mark S. Riggle) writes:
> Come on, Perl is just about the only language that remains
> as readable under ROT_13 as before.
Lisp remains just about as readable after being piped through 'fmt'.
Adios,
Logan
--
The genius of France can be seen at a glance
And it's not in their fabled fashion scene
It's not that they're mean, or their wine, or cuisine
I refer of course to the guillotine
(the French knew how to lynch)
T-Bone Burnett, "I Can Explain Everything"
In my opinion, this whole thread is silly. The premise is (see subject line)
that everything can be done in lisp, as if one screwdriver could fit every
screw.
Wake up, boys and girls! What makes Unix so programmer friendly is that it
is a swiss army knife - comes with two screwdrivers and one of everything else.
Lots of little tools, all custom made for a different nich.
To me it sounds like sour grapes. "I can't learn all this, there's too much!
Who needs all this crud anyway?" BTW, Unix doesn't have tool bloat. My
Linux machine has swap space, the kernel, utilities, a developer's environment
and a desk-top publishing system sitting on a 120Meg disk. It DOES have
kernel bloat, which will only get worse as everybody clammers to get their
firm's bell and whistle into COSE. G-d I miss version 7.
In article <·····················@njitgw.njit.edu> ·····@funcity.njit.edu (Aaron Watters) writes:
Sounds like a job for HIERARCHICAL STORAGE: put all those silly tools
written by MIT undergrads in the seventies off onto a robotic tape
farm where they belong, but be able to get them back transparently in
case you accidentally hire a guy/gal who wrote one as a consultant.
Or someone wha has used them for the past 15 years.
About changing `vi'. I'm used to it. I'd like to see something more powerfull,
perhaps with a scripting language (imbeddible Perl? :-), and some X
power. Don't throw them away, improve them.
No. Let's not replace awk. But it seem to me that all this stuff
that is being crammed into perl is a bit beyond the scope of the
language: do we really want to be writing client/server db
applications over Oracle on an ad-hoc language that doesn't support complex
data types?
I do most of my scripting in tkSybPerl. I like being able to read a row into
an array and not worry about binding, converting, et al. I love having Perl's
"format" and "write" on a dB script. I also like being able to query the user
using GUI's.
About not supporting complex data types, two answers:
1- Oracle doesn't either.
2- I write s-expressions ("Nested Lists") in Perl 5 regularly. I think,
although I haven't tried it, that an associative array of references
to lists might be very usefull in handeling relations db's.
--
Micha Berger Ron Arad, Zechariah Baumel, Zvi Feldman, Yehudah Katz:
·······@lehman.com May the Omnipresent have mercy on them and take them from
(212) 464-6565 restraint to openness, from dark to light, from slavery
(201) 916-0287 to salvation.
From: Frank Deutschmann
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <30jlcf$i6k@panix.com>
In <·····················@mbsdev24.lehman.com> ·······@mbsdev24.lehman.com (Micha Berger) writes:
>In my opinion, this whole thread is silly. The premise is (see subject line)
>that everything can be done in lisp, as if one screwdriver could fit every
>screw.
In my opinion, this "screwdriver" argument is silly; Lisp is not a
screwdriver, but rather more of a "screwdriver representation
language." In other words, you are comparing screwdrivers to a
language capable of representing (and therefore building) any kind of
screwdriver you can imagine.
>Wake up, boys and girls! What makes Unix so programmer friendly is that it
>is a swiss army knife - comes with two screwdrivers and one of everything else.
>Lots of little tools, all custom made for a different nich.
Wake up, Micha! What makes Lisp so programmer friendly is that it is
capable of representing any Swiss Army knife you would like! And all
such Swiss Army knives can be "interoperable" and "open" and all those
other wonderful buzz words!
>To me it sounds like sour grapes. "I can't learn all this, there's too much!
>Who needs all this crud anyway?" BTW, Unix doesn't have tool bloat. My
>Linux machine has swap space, the kernel, utilities, a developer's environment
>and a desk-top publishing system sitting on a 120Meg disk. It DOES have
>kernel bloat, which will only get worse as everybody clammers to get their
>firm's bell and whistle into COSE. G-d I miss version 7.
Guess what? Lisp doesn't have kernel bloat (perhaps feature bloat for
Common Lisp, but certainly not kernel bloat). An important difference
between Lisp and Unix is that every tool in Unix has its own
quirkiness, its own special syntax for args, etc. This is not sour
grapes, it's a serious point: when using the more obscure Unix tools,
life is hell without the man pages. In contrast, I seldom refer to
CLtL, though (of course) I do use 'describe'. Lisp is simply more
"unified", more consistent. It is easier to "wire together" diverse
tools.
Case in point: a few months ago, I had a need for a desk calculator
capable of doing algebraic manipulation, and I really wanted a GUI
interface and PostScript output. Graphs would be a big plus, and I
also wanted to process a large quantity of tabular data coming from
Sybase. So, using CMU Lisp, Garnet, and a Macsyma-like package, I
wired one up with a little "glue" code and some nice window stuff.
The hardest part was the Lisp-Sybase interface, pain which could have
been avoided by actually (*horrors*) spending money.
Net development time a week of my spare time. As they say on Saturday
Night Live, "No big whoop." I ended up with the world's most powerful
desk calculator for free.
The consistency issue is what made this all possible; I didn't have to
learn the insides of 3 tools to get them all hooked up. Look at Perl
as an example of inconsistency: while I agree that it is a neat tool,
the syntax is not entirely consistent, and the division between what
is built-in versus what is in external libraries seems rather
arbitrary. I would, in fact, say that Perl itself has kernel bloat.
Another major criticism I have of the Unix "many tools" approach is
that code written for the tools mentioned on the subject line is
typically reused via the "cut and paste" route -- not the most
effective software development strategy! While all of these tools
support load "modules", this feature is rarely used, in my experience.
I have seen numerous windows developed in Tk, only to be cut and
pasted to numerous other applications, in order to achieve common
"look and feel"; unfortunately, when the time comes to make a change,
all hell breaks loose.
One of the reasons for the failure to use the load module features
seems to be desire for total portability accross Unix (and even
sometimes DOS) systems. None of the named tools supports a
comprehensive module facility that makes up for the lack of
compatability between the target environments. In all fairness, Lisp
also lacks such a comprehensive facility (so long old 'require'), but
the difference seems to be that Lisp developers generally include a
fairly general loader for their software. It is generally easy to
take the provided loader and make it functional on your platform.
Perhaps the Lisp situation is skewed towards using load modules (even
if it requires some development) because we Lisp'ers really abhor cut
and paste reuse. In contrast to the named tools, Lisp is the only
tool which provides a really comprehensive namespace conflict
avoidance and resolution facility (Perl is the only one which come
close, and Perl's namespace is much less sophisticated).
>About changing `vi'. I'm used to it. I'd like to see something more powerfull,
>perhaps with a scripting language (imbeddible Perl? :-), and some X
>power. Don't throw them away, improve them.
Gee, I guess you've never used Emacs (especially V19, or Lucid-Emacs).
>I do most of my scripting in tkSybPerl. I like being able to read a row into
>an array and not worry about binding, converting, et al. I love having Perl's
>"format" and "write" on a dB script. I also like being able to query the user
>using GUI's.
That's 3 programming languages right there! (TCL, SQL, and Perl) I
can't even fathom doing anything resembling serious development in
such an environment. And to think that with the three languages you
don't even achieve a diversity of programming paradigms (imperative vs
logical, for example)!
>About not supporting complex data types, two answers:
> 1- Oracle doesn't either.
> 2- I write s-expressions ("Nested Lists") in Perl 5 regularly. I think,
> although I haven't tried it, that an associative array of references
> to lists might be very usefull in handeling relations db's.
Gee, what an answer: because Oracle doesn't support it, I don't need
it (implying that complex data types will not make the application any
easier to develop). As for #2, knowing Perl, I say Blechhh.
>--
>Micha Berger Ron Arad, Zechariah Baumel, Zvi Feldman, Yehudah Katz:
>·······@lehman.com May the Omnipresent have mercy on them and take them from
>(212) 464-6565 restraint to openness, from dark to light, from slavery
>(201) 916-0287 to salvation.
-frank
--
···@panix.com | Just another bumper sticker on the
1 212 559 5534 | Information Superhighway.
1 917 992 2248 |
1 718 746 7061 |
From: Mike Stok
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <30jscq$se5@hibbert.meiko.com>
In article <··········@panix.com>, Frank Deutschmann <···@panix.com> wrote:
>In <·····················@mbsdev24.lehman.com> ·······@mbsdev24.lehman.com (Micha Berger) writes:
>>In my opinion, this whole thread is silly.
I agree...
>In my opinion, this "screwdriver" argument is silly; Lisp is not a
>screwdriver, but rather more of a "screwdriver representation
>language." In other words, you are comparing screwdrivers to a
>language capable of representing (and therefore building) any kind of
>screwdriver you can imagine.
Oops, I thought I used languages to represent my thoughts to other people
or machines, and the language I choose to use depends on the situation.
The more languages you know the more freedom you have in that choice, I
*think* I can assert that anything I can do in Perl, lisp, basic, pascal,
or whatever could also be done in assembler, but that's no reason to dump
them.
>>About changing `vi'. I'm used to it. I'd like to see something more powerfull,
>>perhaps with a scripting language (imbeddible Perl? :-), and some X
>>power. Don't throw them away, improve them.
>
>Gee, I guess you've never used Emacs (especially V19, or Lucid-Emacs).
Please, not content with a language skirmish let's bring editors into it
as well to make it a "proper" war :-(
>>I do most of my scripting in tkSybPerl. I like being able to read a row into
>>an array and not worry about binding, converting, et al. I love having Perl's
>>"format" and "write" on a dB script. I also like being able to query the user
>>using GUI's.
>
>That's 3 programming languages right there! (TCL, SQL, and Perl) I
>can't even fathom doing anything resembling serious development in
>such an environment. And to think that with the three languages you
>don't even achieve a diversity of programming paradigms (imperative vs
>logical, for example)!
...but alas it probably does the job well enough and quickly enough to
keep the user happy :-) This is usually the point of the exercise, the
end is usually what the person paying me cares about, the means are
incidental.
I find that the language I use affects the way I see a task, and I am
grateful for the diversity of languages available, it would be a sad day
were someone to say X is the only language and Y is the only editor and
all others are hereby banned.
Mike
--
The "usual disclaimers" apply. | Meiko
Mike Stok | 130C Baker Ave. Ext
·········@meiko.concord.ma.us | Concord, MA 01742
Meiko tel: (508) 371 0088 x124 |
Have a look at your case in point. You got the world's most powerful
desk calculator in a week, congratulations. Now can you pass your
code onto me so I can run it on my PC? NO. Can I run that code on the
Mac? NO. Can I even run it under another lisp? Probably not! So what
you have created is a very platform specific tool.
Trying to do *everything* in lisp is just plain silly! Use the tools
that are right for the problem.
Yusuf
Ps: I do almost all my programming in lisp, but I would write a perl
script, a shell script or anything else if I thought it could solve my
problem quicker.
>>>>> " " == Frank Deutschmann <···@panix.com> writes:
In article <··········@panix.com> ···@panix.com (Frank Deutschmann) writes:
> ....[deleted]...
> Case in point: a few months ago, I had a need for a desk calculator
> capable of doing algebraic manipulation, and I really wanted a GUI
> interface and PostScript output. Graphs would be a big plus, and I
> also wanted to process a large quantity of tabular data coming from
> Sybase. So, using CMU Lisp, Garnet, and a Macsyma-like package, I
> wired one up with a little "glue" code and some nice window stuff.
> The hardest part was the Lisp-Sybase interface, pain which could
> have been avoided by actually (*horrors*) spending money. Net
> development time a week of my spare time. As they say on Saturday
> Night Live, "No big whoop." I ended up with the world's most
> powerful desk calculator for free.
> ....[deleted]...
--
--
Yusuf Pisan
·······@nwu.edu
Qualitiative Reasoning Group
The Institute for the Learning Sciences
Northwestern University
From: Frank Deutschmann
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <30m15d$kal@panix.com>
In <·····················@SPD-13.ils.nwu.edu> ·······@nwu.edu (Yusuf Pisan) writes:
>Have a look at your case in point. You got the world's most powerful
>desk calculator in a week, congratulations. Now can you pass your
>code onto me so I can run it on my PC? NO. Can I run that code on the
>Mac? NO. Can I even run it under another lisp? Probably not! So what
>you have created is a very platform specific tool.
First, I checked, and I am not permitted to pass on this code (it was
developed on my employer's time).
But, yes, it should run on a mac, with the new (alpha) version of
Garnet. The only problem on the mac would be the Sybase interface,
but that could be changed to some other DB.
The PC would be a problem, as Garnet has not been ported to windows.
However, the non-GUI parts could be used on the PC, using the
Lisp-interaction mode.
Other Lisp's should not present much of a problem: the symbolic
package has been written with portability to many Lisps, as has
Garnet. I might need to rebuild the loader, but nothing major.
Note that with the alternative of Tk/Perl/etc this would 1) not be
possible at all (would you seriously consider writing a symbolic
algebra package in Perl, or even C for that matter), and 2) would not
be portable to PC/Mac either (is Tk available for PC/Mac -- and
moreover, is it compatible with X?). If we throw Mathematica into the
equation, we get portability, but is there a Sybase (or other RDB)
interface avialable for Mathematica? And can I use a logic
programming style in Mathematica (backtracking)?
>Trying to do *everything* in lisp is just plain silly! Use the tools
>that are right for the problem.
Well, I suppose that you could have saved the various Lisp machine
companies lots of grief had you only told them this 15 years ago...
:-) (Breaking my no-smileys vow, lest this ignite an all-out flame war...)
>Yusuf
>Ps: I do almost all my programming in lisp, but I would write a perl
>script, a shell script or anything else if I thought it could solve my
>problem quicker.
Me too, but generally it can't. I'm not above the occaisional Perl
script, or even a Tk window. But those apps have to be very small to
make the Perl or Tk route pay off. None of this Perl/Tk/Sybase/etc
development -- it gets to be a mess, quickly.
>Yusuf Pisan
>·······@nwu.edu
>Qualitiative Reasoning Group
>The Institute for the Learning Sciences
>Northwestern University
-frank
--
···@panix.com | You never step into the same river twice.
1 212 559 5534 | -- Heraclitus
1 917 992 2248 |
1 718 746 7061 |
I have a somewhat simple-minded list of features that I require of
script languages and their implementations:
1) Regular expression matching a-la Perl and Awk.
2) A fairly decent general purpose programming language.
3) At least one free and reasonably portable implementation.
4) Modestly sized executables that can be
made to behave as filters in a UNIX pipe.
5) "One-liner" capability.
All of these features have to be available at the same time, in the
same implementation!
As far as I know, features 1) and 4) are the main problems as far as
Common Lisp is concerned. Both of these problems _could_ be solved, 1)
more easily than 4).
--
(Rmz)
Bj\o rn Remseth !Institutt for Informatikk !Net: ···@ifi.uio.no
Phone:+47 22855802!Universitetet i Oslo, Norway !ICBM: N595625E104337
From: Logan Shaw
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <Ct9q3I.L3G@taligent.com>
In article <··········@panix.com>, ···@panix.com (Frank Deutschmann) writes:
> In <·····················@mbsdev24.lehman.com> ·······@mbsdev24.lehman.com (Micha Berger) writes:
> >Wake up, boys and girls! What makes Unix so programmer friendly is that it
> >is a swiss army knife - comes with two screwdrivers and one of everything
> >else.
> >Lots of little tools, all custom made for a different nich.
>
> Wake up, Micha! What makes Lisp so programmer friendly is that it is
> capable of representing any Swiss Army knife you would like! And all
> such Swiss Army knives can be "interoperable" and "open" and all those
> other wonderful buzz words!
[ Just being the devil's advocate here... ]
The same is true for assembly. What's your point?
> One of the reasons for the failure to use the load module features
> seems to be desire for total portability accross Unix (and even
> sometimes DOS) systems. None of the named tools supports a
> comprehensive module facility that makes up for the lack of
> compatability between the target environments.
What is it about perl's "require" that you don't like?
> >About changing `vi'. I'm used to it. I'd like to see something more powerfull,
> >perhaps with a scripting language (imbeddible Perl? :-), and some X
> >power. Don't throw them away, improve them.
>
> Gee, I guess you've never used Emacs (especially V19, or Lucid-Emacs).
Please - all we need is to add a vi-versus-emacs religious war to this
discussion! In case you haven't noticed, it has been done before. To
paraphrase Sting,
There's no such thing as a winnable editor flame war
It's a lie we don't believe anymore
Adios,
Logan
--
The genius of France can be seen at a glance
And it's not in their fabled fashion scene
It's not that they're mean, or their wine, or cuisine
I refer of course to the guillotine
(the French knew how to lynch)
T-Bone Burnett, "I Can Explain Everything"
Frank Deutschmann (···@panix.com) wrote:
: In my opinion, this "screwdriver" argument is silly; Lisp is not a
: screwdriver, but rather more of a "screwdriver representation
: language." In other words, you are comparing screwdrivers to a
: language capable of representing (and therefore building) any kind of
: screwdriver you can imagine.
Yeah, a 300-lb screwdriver that's about 10 feet long. Not real good
for tightening up my sunglasses is it?
: That's 3 programming languages right there! (TCL, SQL, and Perl) I
: can't even fathom doing anything resembling serious development in
: such an environment.
I get paid to do that every day and have little or no trouble doing it
because all of those tools work so incredibly well together. Doing my
job in Lisp would be insane. Today I wrote an awk program in about 1
minute, 45 seconds that parse a 5 meg file perfectly the first time and
generated a C header file from it. It ate up around 125K of RAM and
completed in just over 10 minutes. The same thing in Lisp, besides
being near impossible, would have been HUGE, taken too long to write,
and would have been slow and a memory hog.
Of course, I would like to learn Lisp because there are things it is
very good at. I just have a hard time imagining a Lisp machine as
your do-all general purpose computer system. It's probably possible,
but not really all that desirable.
: -frank
: --
: ···@panix.com | Just another bumper sticker on the
: 1 212 559 5534 | Information Superhighway.
: 1 917 992 2248 |
: 1 718 746 7061 |
--
csh
---------------------------------------------------------------------------
········@escape.widomaker.com (UUCP) | Amd486/40 Linux system
········@pcs.cnu.edu (Internet) | Christopher Newport University
From: Thomas M. Breuel
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <TMB.94Jul29163031@arolla.idiap.ch>
In article <·················@polaris.ih.att.com> ···@polaris.ih.att.com (Lawrence G. Mayka) writes:
| Today I wrote an awk program in about 1
| minute, 45 seconds that parse a 5 meg file perfectly the first time and
| generated a C header file from it. It ate up around 125K of RAM and
| completed in just over 10 minutes.
|
|I daresay the Common Lisp program would have:
|
|- Taken a bit longer to write, since the CL community hasn't
|standardized as complete a text-manipulation and pattern-matching
|library as one might like.
|
|- Taken either more or less memory, depending on the CL
|implementation's generational GC and awk's memory management style.
|
|- Been either faster or slower, depending on the awk program's ratio
|of interpreted computation (which CL would greatly improve upon) to
|library computation and I/O (which awk may well do faster than CL--I
|don't know).
Well, I have to write awk-like stuff in CL every now-and-then because
I have to grind through large text files and perform 3D geometrical
computations, which is just too painful in awk.
In my experience:
-- regular expression matching in CL is inefficient;
I don't know whether that's because CL regular expression
matchers have not been hacked on long enough (C
implementations tend to be old and mature),
or because they can't be optimized well by the compiler;
FFI-based implementations are a hassle to use...
-- text I/O is slow compared in all CL
implementations I have tried (compared to good awks)
-- built-in hash tables tend to be slow and memory hungry
compared to those found in good awks
-- a lot of garbage is generated that could probably
be reclaimed statically or using very simply local
tests ("compile-time garbage collection"); I suspect
that awk memory management strategies have the important
special cases for strings hard-wired in
Also, apart from efficiency, writing that kind of code could be a
whole lot less painful if there was a standard set of powerful and
useful string manipulation functions (like "split") and common
programming paradigms (like "loop-over-fields-of-file").
|I'm not arguing that CL would necessarily have been a better choice;
|I'm simply maintaining that CL would have been a reasonable choice
|too.
Well, none of these are profoundly difficult things to implement or
standardize. But the CL community seems to be collectively lost in
MOP-space and ErrorSystem-land...
Thomas.
From: Logan Shaw
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <Ct9pFC.Ksp@taligent.com>
In article <·····················@mbsdev24.lehman.com>, ·······@mbsdev24.lehman.com (Micha Berger) writes:
> About changing `vi'. I'm used to it. I'd like to see something more powerfull,
> perhaps with a scripting language (imbeddible Perl? :-), and some X
> power. Don't throw them away, improve them.
Of course, when you do write it, you have to call it '16' (for 'xvi'),
unless you make a Motif version, in which case you have to call it
'1006' (for 'mvi'). Finally, object-oriented vi would be '7' ('vi++' ==>
'6++' ==> '7').
Adios,
Logan
--
The genius of France can be seen at a glance
And it's not in their fabled fashion scene
It's not that they're mean, or their wine, or cuisine
I refer of course to the guillotine
(the French knew how to lynch)
T-Bone Burnett, "I Can Explain Everything"
From: William Paul Vrotney
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <vrotneyCtA48A.F9G@netcom.com>
In article <·····················@mbsdev24.lehman.com> ·······@mbsdev24.lehman.com (Micha Berger) writes:
> In my opinion, this whole thread is silly. The premise is (see subject line)
> that everything can be done in lisp, as if one screwdriver could fit every
> screw.
>
Did you ever use a Symbolics or a Xerox D-Machine? Everything IS done in
Lisp and it is WONDERFUL. Lisp is one of the few high level languages that
is elegant enough to serve as a basis for a machine language.
--
Bill Vrotney - ·······@netcom.com
I think the LISP programmers have better things to worry about than Perl.
There's a new language out called Concurrent Clean, and from what I read
in the last issue of Byte - it would kick the crap out of LISP. Concurrent
Clean acts like both a functional language and a concurrent programming
language and it compilies just about as small as C does.
Perl is in another league -- one in which it has become one of the most
powerful, though not as easy as awk. Hopefully, it becomes apart of standard
distribution and becomes what BASIC was to all those microcomputers in the
early 80's!!
LONG LIVE PERL!!!
In article <·····················@mcs.drexel.edu> ········@mcs.drexel.edu (/\/\_i_k_e Brzycki) writes:
...
There's a new language out called Concurrent Clean, and from what I read
in the last issue of Byte - it would kick the crap out of LISP.
...
I suggest you read something other than Byte, the documentation in the
Concurrent Clean distribution would be a good start.
In article <·····················@mcs.drexel.edu> ········@mcs.drexel.edu (/\/\_i_k_e Brzycki) writes:
From: ········@mcs.drexel.edu (/\/\_i_k_e Brzycki)
Organization: Drexel University
Date: Thu, 21 Jul 94 21:57:58 GMT
Lines: 13
I think the LISP programmers have better things to worry about than Perl.
There's a new language out called Concurrent Clean, and from what I read
in the last issue of Byte - it would kick the crap out of LISP. Concurrent
Clean acts like both a functional language and a concurrent programming
language and it compilies just about as small as C does.
I too read BYTE and find that recently:
a) they hyped way tooooo much Windows and similar stuff. They have no
balance toward UNIX systems or OS/2 and practically never mention PD
or GPL software. (They could at least run a service on LINUX).
b) the article on functional languages is just a nice way to say that
they are keeping track of "nice things"
From what I gathered from the glimpse of Clean from that article
ConcClean looks like a nifty thing, but:
- the "compile to C technology" is something that was out in 1985 with
the first release of (guess what?!?) Kyoto CL.
- ConcClean is claimed to leave out some of the "more functional"
aspects of functional programming.
- Type Inference technology *has* been incorporated in at least one
Common Lisp COMPILER (for those out there who do have not used a Lisp
system in the last 15 years :-) )
On top of that, (and I might be wrong) the author does not seem to be
really familiar with Common Lisp at all.
Finally, the "goodness" of a concurrent language is entirely dependent
on the underlying (or lackness of) operating system. The ADA story
tells us that. Any ConcClean implemeentation on a "standard" UN*X or
MS-Windows (not NT) system is going to simulate concurrent processes
(or a similar concept) in the run time environment. Again, this is
what most Common Lisp implementations do in order to manage
thereads. What a novel idea.
Perl is in another league -- one in which it has become one of the most
powerful, though not as easy as awk. Hopefully, it becomes apart of standard
distribution and becomes what BASIC was to all those microcomputers in the
early 80's!!
LONG LIVE PERL!!!
I never use PERL. I guess I do no need it. You never used Common Lisp,
you might need it instead. :)
Happy Lisping
--
Marco Antoniotti - Resistente Umano
-------------------------------------------------------------------------------
Robotics Lab | room: 1220 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
Bertholdt Brecht
From: Kirk Rader
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <CtCLvI.D5o@triple-i.com>
In article <·················@netcom.com> ·······@netcom.com (William Paul Vrotney) writes:
>In article <·····················@mbsdev24.lehman.com> ·······@mbsdev24.lehman.com (Micha Berger) writes:
>
>> In my opinion, this whole thread is silly. The premise is (see subject line)
>> that everything can be done in lisp, as if one screwdriver could fit every
>> screw.
>>
>
>Did you ever use a Symbolics or a Xerox D-Machine? Everything IS done in
>Lisp and it is WONDERFUL. Lisp is one of the few high level languages that
>is elegant enough to serve as a basis for a machine language.
>
>
>--
>Bill Vrotney - ·······@netcom.com
As long as the machine, as in the cases you cite, was designed to
use lisp as its machine language to start with....
------------------------------------------------------------
Kirk Rader ····@triple-i.com
In article <··········@triple-i.com> ····@triple-i.com (Kirk Rader) writes:
As long as the machine, as in the cases you cite, was designed to
use lisp as its machine language to start with....
Not really. You can turn your 486 into the equivalent of a D-machine
just by running Interlisp (er, Medley) on it. It's available for a
couple of hundred bucks, I believe.
Bill
--
Bill Janssen <·······@parc.xerox.com> (415) 812-4763 FAX: (415) 812-4777
Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
URL: ftp://parcftp.parc.xerox.com/pub/ilu/misc/janssen.html
From: Martin Rodgers
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <774707928snz@wildcard.demon.co.uk>
In article <··········@ef2007.efhd.ford.com>
·······@cands1.srl.ford.com "Michael Tiller" writes:
> Well, I went out and got the clisp binaries from gatekeeper.dec.com.
> 4.5Mb is not scarcely a megabyte. Now I don't know whats needed you
> might be able to trim it, but I wouldn't know what I can trim (and
> shouldn't need to). In addition, the text mentions says...
For which platform? I have a recent (but not the latest) version of
CLISP. The .EXE file is 638K, and the image file is 536K. I'll agree
that this is not a complete Common Lisp, but I'm told that some other
CL systems are far smaller than others.
It's easy to play games with the figures, like suggesting that a C
program takes up more than 50 MB, simply coz you want the complete
development system included. That would be more powerful, but it's
almost unrealistic for most people.
One of the problems that I see with CL is that too many CL programmers
insist that the development system should be available to the user.
I've yet to see any figures for a stand alone app written in CL, or
a CL app that has been translated into C and then compiled.
Another issue that rarely gets mentioned is the use of shared libs
for stand alone CL code. Does anyone have figures for a 10,000+
CL app written in Allegro CL for Windows?
--
Martin Rodgers, WKBBG, London UK AKA "Cyber Surfer"
If "One likes to believe in the freedom of email", email
················@cpsr.org and tell them you oppose Clipper.
This is a shareware .signature -- please pass it on!
From: Martin Rodgers
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <774708863snz@wildcard.demon.co.uk>
In article <··········@ibch50.inf.tu-dresden.de>
··@ibch50.inf.tu-dresden.de "Wittenberger" writes:
> LISP is very good for programming close to some theorie. But doesn't
> check the syntax (except for the balanced "()").
Define what you mean by "syntax". There're a difference between a
Lisp expression and an expression read by the Lisp parser. Both
use the same "syntax", but there's another level of "syntax" used
by Lisp code.
It's similar in some ways to Forth, where the parser only knows about
one "level" of the syntax (the lexical level). The semantic level is
something else. The parser in Forth isn't usually implemented in the
same way as in most languages - tools like lex and yacc might not work
for many Forth.
> Moreover LISP is interpreted --> relativ slow. That will never go away
> when hardware gets cheaper. Cause than someone will write somthing
> more complex with a full or half-compiled system. This srew never ends.
Which Lisp? XLISP? Sure, but many others are compiled, interpreted,
or whatever. There are many different ways of implemented a language,
and just refering to "Lisp" doesn't name a dialet, never mind a single
implementation.
There are also interpreted C systems. :-)
> So we better select the best language for a particular problem.
And then select the "best" implementation? That's not easy, when
there are so many choices. I could use a "Lisp" with the samantics
of C if I wanted. In fact, I might do that, as I've always wanted
an "ideal" language in which to re-write my Lisp interpreter. It
would be a "C" like "Lisp" and compile directly into C.
> The only importend thing in this sence is:
>
> All these languages reinvent the wheel.
All languages perform a useful function: they allow programmers to
write code that will run on a computer. Some languages are no longer
with us, and many implementations no longer have machines to run on.
Most languages beat using hex switches on a front panel. :-)
Everything else is just relogious war. I don't give a shit about
which languages other people use, which dialects, or which vendor
they get their implementation(s) from. The only time when it might
be useful to compare different langauges and language systems might
be when there are useful ideas to exchange.
Mind you, people can get killed for expressing the "wrong" ideas.
Anyone who wants to change my mind can do it very easily. Just pay
to me think something else, and use your favourite language. You
don't have to kill me.
--
Martin Rodgers, WKBBG, London UK AKA "Cyber Surfer"
If "One likes to believe in the freedom of email", email
················@cpsr.org and tell them you oppose Clipper.
This is a shareware .signature -- please pass it on!
From: Peter da Silva
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <id.CCEB1.8LJ@nmti.com>
In article <·················@polaris.ih.att.com>,
Lawrence G. Mayka <···@polaris.ih.att.com> wrote:
> I think the original question that started this thread was, "Why did
> people go to the trouble of designing a whole new language for these
> operations when it would have been so much easier to just graft them
> into Lisp?"
They did, and then discovered a 1.5 megabyte executable to search through
a file was a bit of a drag on the system.
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Hast Du heute schon Deinen Wolf umarmt?"
In article <············@nmti.com> ·····@nmti.com (Peter da Silva) writes:
In article <·················@polaris.ih.att.com>,
Lawrence G. Mayka <···@polaris.ih.att.com> wrote:
> I think the original question that started this thread was, "Why did
> people go to the trouble of designing a whole new language for these
> operations when it would have been so much easier to just graft them
> into Lisp?"
They did, and then discovered a 1.5 megabyte executable to search through
a file was a bit of a drag on the system.
About 700KB of CLISP is object-file text and could perhaps go into a
shared library. A large portion of the remainder is, I think,
byte-compiled Lisp text and could perhaps go into shared memory.
Perhaps someone will look into these possibilities?
--
Lawrence G. Mayka
AT&T Bell Laboratories
···@ieain.att.com
Standard disclaimer.
·····@nmti.com (Peter da Silva) writes:
Newsgroups: comp.lang.lisp,comp.lang.perl,comp.lang.tcl,comp.lang.clos
From: ·····@nmti.com (Peter da Silva)
Organization: Network/development platform support, NMTI
Date: Wed, 20 Jul 1994 18:59:12 GMT
In article <·················@polaris.ih.att.com>,
Lawrence G. Mayka <···@polaris.ih.att.com> wrote:
> I think the original question that started this thread was, "Why did
> people go to the trouble of designing a whole new language for these
> operations when it would have been so much easier to just graft them
> into Lisp?"
They did, and then discovered a 1.5 megabyte executable to search through
a file was a bit of a drag on the system.
You're wedded to an image of individual executable files(!) rather than
individual subroutines. In support of your one executable file you have
megabytes and megabytes of other files as well as resident RAM programs,
such as the kernel. If your executable files need to pass data in a way
more sophisticated than Unix pipes, you lose. Of course, you could always
write things to file or shared memory pipes for sockets or whatever to get
the job done. (However, discarding history and installed base, this is far
from natural.)
If you started your Lisp today and kept it running forever your 'searching a
file' program might have been only a few kbytes?
Imagine what Unix would be like if instead of a shell you entered
'commands' to a C Interpreter.
Conjecture: The only reason the Unix kernel exists is to provide a level of
protection for the system resources. The only reason protection is needed
is because the kernel was written in C and C has progammer-visible
pointers? (Sure it is not quite right... but if you've not thought about
it, do.)
-- Ed
From: Peter da Silva
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <id.VKJB1.73J@nmti.com>
In article <·················@hoshi.hip.atr.co.jp>,
Ed Gamble <···@hip.atr.co.jp> wrote:
> You're wedded to an image of individual executable files(!) rather than
> individual subroutines.
You're right. If you want to enforce discretionary access controls you have
to have some minimum protection domain. In UNIX this unit is the file. In a
lisp machine this unit is the machine. It's a fundamental design decision
that invariably ends up with different environments.
Note that I wrote the above paragraph *before* reading the following:
> Conjecture: The only reason the Unix kernel exists is to provide a level of
> protection for the system resources. The only reason protection is needed
> is because the kernel was written in C and C has progammer-visible
> pointers? (Sure it is not quite right... but if you've not thought about
> it, do.)
Oh, I have. (see above... grin)
The reason protection is needed is because there is no requirement that
a single language be used for all application programs. What language that
is is irrelevant.
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Hast Du heute schon Deinen Wolf umarmt?"
In article <············@nmti.com> ·····@nmti.com (Peter da Silva) writes:
... The reason protection is needed is because there is no requirement that
a single language be used for all application programs. What language that
is is irrelevant.
I agree in theory, but the practice seems to be somewhat different
i.e. what percentage of UNIX apps aren't written in C, a derivative of
C or an interpreter written in C?
From: Richard A. O'Keefe
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <31kkrl$8b9@goanna.cs.rmit.oz.au>
·····@nmti.com (Peter da Silva) writes:
>UNIX, as a design goal, allows you to program in any language, including
>assembler. This means you can *not* use language based protection mechanisms.
>It's just plain impossible, without massive performance impacts once you
>leave that language (see Burroughs and Algol). The fact that C includes
>pointers is irrelevant.
I have seen the Burroughs B6700, and it is simply not true that there were
"massive performance impacts" once you left Algol. Burroughs also supplied
Fortran and COBOL compilers which were quite pleasant to use, and the
Tasmania Pascal compiler was also reasonable. PL/I "knew" it was running
on an "unstructured" machine and suffered correspondingly, and BCPL had big
trouble. I am not saying that Fortran and COBOL programs ran as fast as
could have been achieved with that level of hardware technology (ferrite
cores, massive head-per-track disc, main memory < 6Mbytes and ours a lot
less than that), only that security-via-the-compiler was not the major
factor. (Not a RISC machine. Instructions ranged from 8 to 96 bits, and
the normal "load" instruction would also index arrays and call procedures.)
Using those machines was a real pleasure, _if_ you were using Algol-COBOL-
or-Fortran (or any mix of them). If I could get that level of run-time
checking on UNIX without running an interpreter like codecenter I'd be happy.
--
30 million of Australia's 140 million sheep
suffer from some form of baldness. -- Weekly Times.
In article <···················@liasg5.epfl.ch> ·····@lia.di.epfl.ch (Simon Leinen) writes:
> Wittenberger> Moreover LISP is interpreted --> relativ slow.
>
> Common myth. Repeating it over and over doesn't make it true.
> Most Lisp implementations these days include a compiler.
Ok. Ok. Sorry for that.
But half the way compiled or not - it makes a difference, but not too
much.
But how tells me the following is not true:
Whenever you have something written in LISP, there will be a way to
write it with another languages so the other program is faster?
--
-----------------------------------------------------------------------------
Joerg Wittenberger
Rietzstr. 32b
01139 Dresden
Germany
email: ··@ibch50.inf.tu-dresden.de
···@mail.inf.tu-dresden.de
WWW: <a href=http://www.inf.tu-dresden.de:8002/people/jw6/top.html>jerry</a>
PGP PUBLIC KEY: available on request or by finger
Wittenberger <··@ibch50.inf.tu-dresden.de> wrote:
>
> But half the way compiled or not - it makes a difference, but not too
> much.
For a fixed program, the ratio
execution time of interpreted program : execution time of compiled program
is usually 5 : 1 for CLISP
and 10 : 1 or 20 : 1 for other
CL implementations.
> But how tells me the following is not true:
> Whenever you have something written in LISP, there will be a way to
> write it with another languages so the other program is faster?
Whenever you have something written in C, there will be the possibility
to rewrite it in assembly language, doing global register allocation by
hand. I have done this for some time, and the outcome is usually twice
as fast. You just need a bit more manpower than for the simple C version.
Whenever you have something written in assembly language, you can still
design a custom chip that will perform the same operations in hardware,
much faster.
So, what's your point?
Bruno Haible
······@ma2s2.mathematik.uni-karlsruhe.de
In article <··········@nz12.rz.uni-karlsruhe.de> ······@ma2s2.mathematik.uni-karlsruhe.de (Bruno Haible) writes:
> For a fixed program, the ratio
>
> execution time of interpreted program : execution time of compiled program
>
> is usually 5 : 1 for CLISP
> and 10 : 1 or 20 : 1 for other
> CL implementations.
That's far from my point.
> Whenever you have something written in C, there will be the possibility
> to rewrite it in assembly language, doing global register allocation by
> hand. I have done this for some time, and the outcome is usually twice
> as fast. You just need a bit more manpower than for the simple C version.
>
> Whenever you have something written in assembly language, you can still
> design a custom chip that will perform the same operations in hardware,
> much faster.
>
> So, what's your point?
You meet it! My point is the absurd religios war this thread has been
obvious hope to break that fact by LISP.
--
-----------------------------------------------------------------------------
Joerg Wittenberger
Rietzstr. 32b
01139 Dresden
Germany
email: ··@ibch50.inf.tu-dresden.de
···@mail.inf.tu-dresden.de
WWW: <a href=http://www.inf.tu-dresden.de:8002/people/jw6/top.html>jerry</a>
PGP PUBLIC KEY: available on request or by finger
In article <··········@ibch50.inf.tu-dresden.de> ··@ibch50.inf.tu-dresden.de (Wittenberger) writes:
Path: info-server.bbn.com!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!Germany.EU.net!netmbx.de!zib-berlin.de!irz401!not-for-mail
From: ··@ibch50.inf.tu-dresden.de (Wittenberger)
Newsgroups: comp.lang.lisp,comp.lang.perl,comp.lang.tcl,comp.lang.clos
Date: 20 Jul 1994 19:18:25 +0200
Organization: Dept. of Computer Science, TU Dresden, Germany
Lines: 31
References: <·····················@njitgw.njit.edu> <··········@ibch50.inf.tu-dresden.de>
<···················@liasg5.epfl.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Xref: info-server.bbn.com comp.lang.lisp:13349 comp.lang.perl:30887 comp.lang.tcl:15340 comp.lang.clos:2451
In article <···················@liasg5.epfl.ch> ·····@lia.di.epfl.ch (Simon Leinen) writes:
...
Ok. Ok. Sorry for that.
But half the way compiled or not - it makes a difference, but not too
much.
But how tells me the following is not true:
Whenever you have something written in LISP, there will be a way to
write it with another languages so the other program is faster?
This is another myth. Lisp can be as fast as C, even faster. Well
written, comparable C and Lisp programs should have comparable performance.
I have a draft paper, Courage in Profiles, that makes a comparison of two
program written in C and Lisp: ftp from wheaton.bb.ncom:
pub/profile/profile.ps.
k
--
Ken Anderson
Internet: ·········@bbn.com
BBN ST Work Phone: 617-873-3160
10 Moulton St. Home Phone: 617-643-0157
Mail Stop 6/4a FAX: 617-873-2794
Cambridge MA 02138
USA
In article <··········@ibch50.inf.tu-dresden.de> ··@ibch50.inf.tu-dresden.de (Wittenberger) writes:
But how tells me the following is not true:
Whenever you have something written in LISP, there will be a way to
write it with another languages so the other program is faster?
First, this is not true if the Lisp program implements a highly
efficient but complex algorithm whose implementation in the other
language is simply not feasible and reasonable (typically, because
expressing the algorithm in that other language would exceed the
complexity that a human programmer can deal with sensibly). The other
language must then resort to a slower, simpler algorithm.
Second, high-quality Common Lisp compilers can often generate code
just as efficient as C compilers when they are given the same amount
of information about the program (e.g., type declarations) and are
allowed to make the same assumptions and impose the same restrictions
(e.g., no incremental update of a running program).
--
Lawrence G. Mayka
AT&T Bell Laboratories
···@ieain.att.com
Standard disclaimer.
In article <·················@polaris.ih.att.com> ···@polaris.ih.att.com (Lawrence G. Mayka) writes:
> But how tells me the following is not true:
> Whenever you have something written in LISP, there will be a way to
> write it with another languages so the other program is faster?
>
> First, this is not true if the Lisp program implements a highly
> efficient but complex algorithm whose implementation in the other
> language is simply not feasible and reasonable (typically, because
> expressing the algorithm in that other language would exceed the
> complexity that a human programmer can deal with sensibly). The other
> language must then resort to a slower, simpler algorithm.
>
> Second, high-quality Common Lisp compilers can often generate code
> just as efficient as C compilers when they are given the same amount
> of information about the program (e.g., type declarations) and are
> allowed to make the same assumptions and impose the same restrictions
> (e.g., no incremental update of a running program).
> --
Thats what I mean.
For your first you need a specialized system to talk in. Just a
specialized language. (Where language may be native LISP together with
some functions made befor or may be a complete different language no
matter.)
For your second: That's what optimization is good for. (And what real
optimization is.) It's nothing more or less than to drag someting from
the system you are in in the mata system you use.
And so long these things can be called a fact, there will ever be a
way to optimize something if you can effort the pain to drag it into
the meta system.
--
-----------------------------------------------------------------------------
Joerg Wittenberger
Rietzstr. 32b
01139 Dresden
Germany
email: ··@ibch50.inf.tu-dresden.de
···@mail.inf.tu-dresden.de
WWW: <a href=http://www.inf.tu-dresden.de:8002/people/jw6/top.html>jerry</a>
PGP PUBLIC KEY: available on request or by finger
Wittenberger (··@ibch50.inf.tu-dresden.de) wrote:
: In article <···················@liasg5.epfl.ch> ·····@lia.di.epfl.ch (Simon Leinen) writes:
: > Wittenberger> Moreover LISP is interpreted --> relativ slow.
: >
: > Common myth. Repeating it over and over doesn't make it true.
: > Most Lisp implementations these days include a compiler.
: Ok. Ok. Sorry for that.
: But half the way compiled or not - it makes a difference, but not too
: much.
: But how tells me the following is not true:
: Whenever you have something written in LISP, there will be a way to
: write it with another languages so the other program is faster?
The inverse is also true. I can write someting in assembly which is MUCH
slower than the perl/LISP/COBOL .. whatever .. version. It all depends on
what you set out to achieve.
Besides, sometimes speed does not matter .. just getting the job done :)
Personally, I try to use a language which suits the problem, rather than
fitting a language to the problem (If I get any choice, that is :)
: --
: -----------------------------------------------------------------------------
: Joerg Wittenberger
: Rietzstr. 32b
: 01139 Dresden
: Germany
: email: ··@ibch50.inf.tu-dresden.de
: ···@mail.inf.tu-dresden.de
: WWW: <a href=http://www.inf.tu-dresden.de:8002/people/jw6/top.html>jerry</a>
: PGP PUBLIC KEY: available on request or by finger
src
--
Steven R. Clark, BSc(Hons) ·····@(cs.flinders.edu.au|cleese.apana.org.au)
<=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-|-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=>
I am returning this otherwise good typing paper to you because someone has
printed gibberish all over it and put your name at the top.
-- English Professor, Ohio University
<=-|-=> <=-|-=> <=-|-=> <=-|-=> <=-|-=> <=-|-=> <=-|-=>
In article <··········@ibch50.inf.tu-dresden.de> ··@ibch50.inf.tu-dresden.de (Wittenberger) writes:
Wittenberger> Moreover LISP is interpreted --> relativ slow. That will
Wittenberger> never go away when hardware gets cheaper. Cause than
Wittenberger> someone will write somthing more complex with a full or
Wittenberger> half-compiled system. This srew never ends.
LISP can be interpreted or compiled. It is _not_ a purely interpreted
language family. For example, most commercial Common Lisp
implementations compile source to NATIVE MACHINE INSTRUCTIONS.
Jason
--
_____________________________________________________________________________
| Jason Trenouth, | EMAIL: ·····@uk.co.harlequin |
| Harlequin Ltd, Barrington Hall, | TEL: (0223) 872522 |
| Barrington, Cambridge CB2 5RG, UK | FAX: (0223) 872519 |
In article <··········@ef2007.efhd.ford.com> ······@solace.me.uiuc.edu (Michael Tiller) writes:
Michael> 4) Tcl (at least to my knowledge) isn't picky about how big
Michael> my "int"s are. Several lisps I've seen are picky.
Common Lisp isn't. It supports _arbitrary precision_ integer
arithmetic. Can Tcl do that?
Jason
--
_____________________________________________________________________________
| Jason Trenouth, | EMAIL: ·····@uk.co.harlequin |
| Harlequin Ltd, Barrington Hall, | TEL: (0223) 872522 |
| Barrington, Cambridge CB2 5RG, UK | FAX: (0223) 872519 |
From: Marty Cohen
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <18152@amsaa-cleo.brl.mil>
In article <··········@sbi.sbi.com> ···@std.sbi.com (Bennett Todd) writes:
-In article <··········@zikzak.apana.org.au>,
-Bill Birch <····@zikzak.apana.org.au> wrote:
Much skipped here
-It's possible that there's a standard Unix utility out there that is
-actually useless, in the sense that it isn't currently being used to get
-useful work done. But I doubt it.
-
I notice that reverse(1) seems to be disappearing from some unix-es.
--Marty
--Bennett
····@sbi.com
--
Marty Cohen, AMSAA-LAD ······@arl.mil Custom House Rm 800,
Phila. PA 19106-2976 (215)597-8377 Fax (215)597-2240
Simon Leinen (·····@lia.di.epfl.ch) wrote:
: Wittenberger> Moreover LISP is interpreted --> relativ slow.
: Common myth. Repeating it over and over doesn't make it true.
: Most Lisp implementations these days include a compiler.
Which produces slow code of course. Same basic result. Now, there
are Lisp compilers that produce pretty fast code, or so I've been
told. But nothing I've been able to get my hands on. All of it
is pretty hefty when the program is compiled.
: --
: Simon.
--
csh
---------------------------------------------------------------------------
········@escape.widomaker.com (UUCP) | Amd486/40 Linux system
········@pcs.cnu.edu (Internet) | Christopher Newport University
[posting to comp.lang.perl and comp.lang.tcl newsgroups removed]
In article <·················@polaris.ih.att.com> ···@polaris.ih.att.com (Lawrence G. Mayka) writes:
Yes, CLISP doesn't support all of ANSI Common Lisp yet. The most
obvious omission appears to be the extended LOOP macro (which,
fortunately, is available elsewhere as a free-of-charge add-on). But
as far as image size is concerned, the missing constructs shouldn't
add much bulk percentagewise.
Actually the latest CLISP for Solaris 2.3 includes the extended LOOP
macro. The most important omissions from CLISP now appear to be class
redefinition, method combination other than standard, and logical
pathnames.
--
Lawrence G. Mayka
AT&T Bell Laboratories
···@ieain.att.com
Standard disclaimer.
In article <···················@monty.harlqn.co.uk> ·····@harlequin.co.uk (Jason Trenouth) writes:
In article <··········@ef2007.efhd.ford.com> ······@solace.me.uiuc.edu (Michael Tiller) writes:
Michael> 4) Tcl (at least to my knowledge) isn't picky about how big
Michael> my "int"s are. Several lisps I've seen are picky.
Common Lisp isn't. It supports _arbitrary precision_ integer
arithmetic. Can Tcl do that?
Tcl doesn't support a lot of things. But if you are willing to use a
Tcl extension (which is the point of the language), yes, you can do
arbitrary precision integer arithmetic. It's trivial.
Tcl doesn't know about X windows either, yet a lot of Tcl scripts do
it anyway. It's amazing what you can do with Tcl considering how
little it does.
Don Libes <·····@nist.gov>
Stephen J Bevan (·····@cs.man.ac.uk) wrote:
: In article <·····················@escape.widomaker.com> ········@escape.widomaker.com (Shannon Hendrix) writes:
:
: ... Today I wrote an awk program in about 1
: minute, 45 seconds that parse a 5 meg file perfectly the first time and
: generated a C header file from it. It ate up around 125K of RAM and
: completed in just over 10 minutes. The same thing in Lisp, besides
: being near impossible, would have been HUGE, taken too long to write,
: and would have been slow and a memory hog.
: Could you post the AWK script so we can judge for ourselves whether a
: Lisp version would be "near impossible ... etc."
Nope, it's gone. But I have another one at work I can put up here later
tonight. It was also a quickie but it's going to be around for awhile
because it's used to generate NLS catalogs for some current software
project. I'm sure it can be done in Lisp but not as quick, small, and
easy. To give you an idea what it does, it's like:
BEGIN {
<print the header for a C file>
<print catalog header if any>
}
/^SECTION/ {
print "#define", $2, section++ > $headerfile
print "$set", section > $catalogfile
}
...and so on. There are about 5 keywords to lookup, 3 procedures to
handle a few odd things, and an END section that finishes up writing the
C source header and prints out some stats about what all it did. It
took me 30 minutes to do this one and it was the first awk script I've
ever written. Perfect tool for the job. 'sed' would be too ugly and
hard for others to maintain, perl is just too much for the job, Lisp is
too much for it (too big, we don't run it, innappropriate for the work
we do), Bourne scripts would be slightly harder to write and maintain,
same for a C program, etc. awk was a perfect match for the job.
Now, if you ran a Lisp machine I guess you could make the above a
subroutine and just jump to it whenever. But then, in that case you
wouldn't be running this script either.
--
csh
---------------------------------------------------------------------------
········@escape.widomaker.com (UUCP) | Amd486/40 Linux system
········@pcs.cnu.edu (Internet) | Christopher Newport University
Stephen J Bevan (·····@cs.man.ac.uk) wrote:
: In article <·····················@escape.widomaker.com> ········@escape.widomaker.com (Shannon Hendrix) writes:
:
: ... Today I wrote an awk program in about 1
: minute, 45 seconds that parse a 5 meg file perfectly the first time and
: generated a C header file from it. It ate up around 125K of RAM and
: completed in just over 10 minutes. The same thing in Lisp, besides
: being near impossible, would have been HUGE, taken too long to write,
: and would have been slow and a memory hog.
: Could you post the AWK script so we can judge for ourselves whether a
: Lisp version would be "near impossible ... etc."
OK... at work now. As I said in a previous post, I don't have that
script any more. But here is one I'm currently using in a project.
First one I ever wrote, took 30 minutes because I was learning as I
went.
--- begin ---
#!/bin/nawk -f
#
# nawk script to generate catalog files and C header files
# for error catalogs
#
# 19940718 csh
#
#
# create a define for this
#
function adddef(lineno,newdef,number)
{
if (defines[$2] != 0)
{
print "***** ERROR *****"
print "Line: ",lineno," ",$2,"was already defined in line",defines[$2]
exit
}
defines[$2] = lineno
print "#define",newdef,number > headerfile
return 0
}
#
# print out something to make for more human readable output
#
function anothersection(section)
{
print "" > headerfile
print "/*" > headerfile
print " *",section > headerfile
print " */" > headerfile
}
BEGIN {
print "Generating C header and nls catalog"
headerfile = "catalog.h"
catalogfile = "errors.english"
}
# set a line number counter
# counting lines with anything
/./ {
tlines++
}
# and lines with nothing
/^$/ {
tlines++
}
#
# generate the main comment for the C header file here
#
/^BEGIN/ {
print "/*" > headerfile
print " * AUTOMATICALLY GENERATED FILE, DO NOT EDIT" > headerfile
print " * " > headerfile
print " * Header for error message catalogs " > headerfile
print " * " > headerfile
print " * Generated: " > headerfile
print " * " > headerfile
print " */ " > headerfile
print "" > headerfile
print "#ifndef CATALOG.H" > headerfile
print "#define CATALOG.H" > headerfile
print "" > headerfile
}
#
# section command found
#
/^SECTION/ {
section++
entry = 0
anothersection($2)
adddef(tlines,$2,section)
print "" > headerfile
print "$set",section > catalogfile
}
#
# entry command found
#
/^ENTRY/ {
entry++
tentry++
adddef(tlines,$2,entry)
getline
tlines++
print entry,$0 > catalogfile
}
#
# file processing finished, do a few little knick-knack things
#
END {
print "Processed",section,"sections",tentry,"entries",tlines,"lines"
print "" > headerfile
print "#endif" > headerfile
}
--- end ---
I'm sure this can be done in Lisp. However, why would I care to do that?
It would take forever to load and run. awk is on all of the systems I
need to run this on, Lisp is not. awk is small and fast and this script
is easy to maintain. Perl, Bourne, C, and sed would not be as good for
this particular job.
I guess if you have Lisp loaded all the time then you would disagree.
However, you wouldn't need this script in that case so the point is
moot.
Anyway, the above is a perfect example of something where "Gosh, I need to
do this real quick but it needs to be easy to come back to later... what
should I use." Of course, I could have done it in Perl but Perl isn't
everywhere and awk/nawk usually are (at least on all the systems we need
to use). No reason to writ it in C, Bourne would be harder, sed is a
bitch to do something like this, etc.
Nope, don't want to see a one-tool system... I like having the different
utils.
--
csh
---------------------------------------------------------------------------
········@escape.widomaker.com (UUCP) | Amd486/40 Linux system
········@pcs.cnu.edu (Internet) | Christopher Newport University
From: Michael James Gebis
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <3197sd$1cv@vixen.cso.uiuc.edu>
········@escape.widomaker.com (Shannon Hendrix) writes:
[Code deleted]
>Perl, Bourne, C, and sed would not be as good for
>this particular job.
I don't know awk, so I can't give a definive answer, but I'll bet
dollars to doughnuts that Perl would have been as good, if not better.
>Of course, I could have done it in Perl but Perl isn't
>everywhere and awk/nawk usually are (at least on all the systems we need
>to use).
Okay, that's a valid excuse for not using Perl, I guess; of course, it's
your fault for not DEMANDING Perl be available on all the systems. :)
--
Mike Gebis ·······@uiuc.edu Mean people suck.
http://www.cen.uiuc.edu/~mg7932/mike.html
In article <·····················@escape.widomaker.com> ········@escape.widomaker.com (Shannon Hendrix) writes:
[ awk program deleted ]
I'm sure this can be done in Lisp.
It can, I've appended an UNTESTED version in (R4RS) Scheme at the end of
this message.
However, why would I care to do that?
In most cases you probably wouldn't. However, what do you turn to
when AWK can't deal with the problem (see the use of a trie I
mentioned in another post)?
It would take forever to load and run.
The Scheme system I generally use (SCM) loads the script in some
small fraction of a second on a SPARCstation, which doesn't count as
"forever" in my book. I can't comment on the runtime since I don't
have any data to test it with, though I don't doubt that AWK would
probably be faster since all the mawk stuff is written in Scheme and
running in an interpreter. However, if the Scheme version was too
slow, then a reasonable performance boost can be had by using the
Scheme specific version of mawk (e.g. if READ-LINE is built in, it
uses that rather than the portable version of READ-LINE).
-------
; All the following libraries are available from the Scheme Repository,
; though I don't guarantee they are the same versions as I'm using :-)
(require 'mawk)
(require 'bawk:table)
(require 'format)
;
(define (echo str . rest)
(apply display str rest)
(apply newline rest))
; Gobal vars
(define header-file (open-output-file "catalog.h"))
(define catalog-file (open-output-file "errors.english"))
(define defines (bawk:table))
(define section 0)
(define entry 0)
(define tentry 0)
(define tlines 0)
;
(define (add-def line-no new-def number)
(if (bawk:table:at defines new-def)
(error "***** ERROR *****~%Line: ~a ~a was already defined in line" line-no (bawk:table:at defines new-def)))
(bawk:table= new-def line-no defines)
(format header-file "#define ~a ~a~%" new-def number))
(define (another-section section)
(format header-file "/*~% *~a~%*/" section))
(define section-pattern (mawk:pattern:make (mawk:pattern:match "SECTION")))
(define (section-action line line-num next-line state)
(lambda ()
(let ((section-name (mawk:$2 (mawk:split line))))
(set! section (+ section 1))
(set! entry 0)
(another-section section-name)
(add-def tlines section-name section)
(echo "" header-file)
(format catalog-file "$set ~a~%" section))))
(define entry-pattern (mawk:pattern:make (mawk:pattern:match "ENTRY")))
(define (entry-action line line-num next-line state)
(lambda ()
(let ((entry-name (mawk:$2 (mawk:split line))))
(set! entry (+ section 1))
(set! tentry (+ tentry 1))
(add-def tlines entry-name entry)
; does the "getline" here do anything useful?
(set! tlines (+ tlines 1))
(format catalog-file "~a~a~%" entry line))))
(define process-line
(mawk:pattern-match
(mawk:pattern/action section-pattern section-action)
(mawk:pattern/action entry-pattern entry-action)))
(define (prologue)
(echo "/*" header-file)
(echo " * AUTOMATICALLY GENERATED FILE, DO NOT EDIT" header-file)
(echo " * " header-file)
(echo " * Header for error message catalogs" header-file)
; ... etc.
)
(define (epilogue)
(format #t "Processed ~a sections ~a entries ~a lines~%" section tentry tlines)
(echo "" header-file)
(echo "#endif" header-file))
(prologue)
(mawk:awk process-line)
(epilogue)
From: Richard A. O'Keefe
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <31khpj$5l3@goanna.cs.rmit.oz.au>
········@escape.widomaker.com (Shannon Hendrix) writes:
>Stephen J Bevan (·····@cs.man.ac.uk) wrote:
>: The Scheme system I generally use (SCM) loads the script in some
>: small fraction of a second on a SPARCstation, which doesn't count as
>: "forever" in my book.
>I don't buy that. You mean you loaded scheme and this script in a
>fraction of a second? I don't believe it.
Why don't you believe it? Have you _tried_ it?
I use xlispstat (a version of Xlisp + graphics package (DOS, Mac, and UNIX-X
versions exist) + statistics computations. When I do
xlispstat </dev/null
it - runs a shell script, which sets some environment variables
and then execs
- a SPARC binary, which connects to the X server and then loads
- 3000 lines of Lisp source code
*I HAVE TIMED THIS*. It takes under a second.
For interest's sake, I decided to try 'scm', as specifically mentioned.
When scm runs, it loads a 500-line Init.scm file. I wrote a C program
that did fork/exec scm/wait 100 times in a loop, and reported the total
tms_cutime + tms_cstime (user + system time for all children). The
total was 26 seconds, i.e. 0.26 seconds for running scm once. For
comparison, running /usr/bin/awk the same number of times took 10 seconds.
awk nawk scm
Time to run 0.098 sec 0.104 sec 0.26 sec
total 'size(1)' 146k 188k 192k
There is a difference, certainly. (The awk script was a one-line null
script, while scm was reading 550 lines of Scheme.) But it is very far
from being as gross as some people have suggested.
>Runtime wouldn't be a big deal anyway since even a large catalog
>file should be done in a matter of seconds. The awk script was called
>in a makefile. Calling scheme/Lisp and a program within the makefile
>would be pretty bad.
You have no justification whatsoever for saying that.
If you were talking about some *specific* Lisp system which you had
*measured*, you would be telling us something useful.
When one *does* measure scm, one finds that
'scm' is not noticeably larger than a modern AWK (nawk).
'scm' is not the only Scheme, not the smallest, and not the fastest.
--
30 million of Australia's 140 million sheep
suffer from some form of baldness. -- Weekly Times.
In article <··········@goanna.cs.rmit.oz.au> ··@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
········@escape.widomaker.com (Shannon Hendrix) writes:
>Stephen J Bevan (·····@cs.man.ac.uk) wrote:
>: The Scheme system I generally use (SCM) loads the script in some
>: small fraction of a second on a SPARCstation, which doesn't count as
>: "forever" in my book.
>I don't buy that. You mean you loaded scheme and this script in a
>fraction of a second? I don't believe it.
Why don't you believe it? Have you _tried_ it?
I use xlispstat (a version of Xlisp + graphics package (DOS, Mac, and UNIX-X
versions exist) + statistics computations. When I do
xlispstat </dev/null
it - runs a shell script, which sets some environment variables
and then execs
- a SPARC binary, which connects to the X server and then loads
- 3000 lines of Lisp source code
*I HAVE TIMED THIS*. It takes under a second.
For interest's sake, I decided to try 'scm', as specifically mentioned.
When scm runs, it loads a 500-line Init.scm file. I wrote a C program
that did fork/exec scm/wait 100 times in a loop, and reported the total
tms_cutime + tms_cstime (user + system time for all children). The
total was 26 seconds, i.e. 0.26 seconds for running scm once. For
comparison, running /usr/bin/awk the same number of times took 10 seconds.
awk nawk scm
Time to run 0.098 sec 0.104 sec 0.26 sec
total 'size(1)' 146k 188k 192k
>Runtime wouldn't be a big deal anyway since even a large catalog
>file should be done in a matter of seconds. The awk script was called
>in a makefile. Calling scheme/Lisp and a program within the makefile
>would be pretty bad.
Lisp is imperialistic. It is used as a shell, I start it up and after
that what it counts is function calls.
Just for the fun of it here are the sturtup times for my setup of
CMULISP. The machine is a Sun Sparc 2 with 16MB of memory.
My setup does some small things in the init file and load a byte
compiled version of MK DEFSYSTEM.
I am running tcsh.
·······@mosaic 11> time lisp < quit
; Loading #p"/robust.a/student/marcoxa/.cmucl-init.lisp".
;; Loading #p"/robust.a/student/marcoxa/cl/lisp-utilities/defsystem.bytef".
CMU Common Lisp 17e, running on mosaic
Send bug reports and questions to your local CMU CL maintainer,
Marco Antoniotti (·······@cs.nyu.edu), or to
··········@cs.cmu.edu.
Loaded subsystems:
Python 1.0, target SPARCstation/Sun 4
CLOS based on PCL version: September 16 92 PCL (f)
CLX X Library MIT R5.01
Motif toolkit and graphical debugger 1.0
* 0.580u 1.140s 0:05.42 31.7% 0+1077k 8+5io 299pf+0w
·······@mosaic 12> time lisp < quit
...
* 0.600u 0.510s 0:01.70 65.2% 0+1067k 0+5io 2pf+0w
·······@mosaic 13> time lisp < quit
...
* 0.560u 0.520s 0:01.56 69.2% 0+1052k 0+3io 0pf+0w
·······@mosaic 14> time lisp < quit
...
* 0.490u 0.550s 0:01.54 67.5% 0+1042k 0+3io 0pf+0w
·······@mosaic 15> time lisp < quit
...
* 0.650u 0.440s 0:01.55 70.3% 0+1068k 0+3io 0pf+0w
It looks like the first time it is run, CMUCL takes more time to start
up. This should be explainable by the need of the underlying OS to
ensure a proper region of the VM for the ENVIRONMENT functioning.
Happy Lisping
--
Marco Antoniotti - Resistente Umano
-------------------------------------------------------------------------------
Robotics Lab | room: 1220 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
Bertholdt Brecht
Marco Antoniotti (·······@mosaic.nyu.edu) wrote:
: ········@escape.widomaker.com (Shannon Hendrix) writes:
: >I don't buy that. You mean you loaded scheme and this script in a
: >fraction of a second? I don't believe it.
: Why don't you believe it? Have you _tried_ it?
Not Scheme, Lisp. Yeah, Scheme can do it.
: I use xlispstat (a version of Xlisp + graphics package (DOS, Mac, and UNIX-X
: versions exist) + statistics computations. When I do
: xlispstat </dev/null
: it - runs a shell script, which sets some environment variables
: and then execs
: - a SPARC binary, which connects to the X server and then loads
: - 3000 lines of Lisp source code
: *I HAVE TIMED THIS*. It takes under a second.
Sure, on an unloaded machine. Jeez, I can do a lot of things given the
memory. But try loading some Lisp program during a heavy make and vs
running awk to do the same job. Awk allocates less RAM and will not
increase swapping as heavily.
Also, if you can load 3000 lines of Lisp and connect to the server etc
in under a second then you have one hell of a machine. Mine at work
won't do that and neither will the machine I have at home. Have a ball
because you are lucky. At work my Sparcstation 1 has 8 megs of RAM.
: Lisp is imperialistic. It is used as a shell, I start it up and after
: that what it counts is function calls.
Yeah, that works out pretty good... if you want it loaded all the time
like that. Kind of like using a real Lisp machine. But, few people can
function in that environment, especially if you are selling something to
other people.
: Just for the fun of it here are the sturtup times for my setup of
: CMULISP. The machine is a Sun Sparc 2 with 16MB of memory.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
We are supposed to get an SS10 at work this year. Until then you
can forget it on my 8mb Sparc 1.
: It looks like the first time it is run, CMUCL takes more time to start
: up. This should be explainable by the need of the underlying OS to
: ensure a proper region of the VM for the ENVIRONMENT functioning.
I'm usually OK with Lisp on my Linux box provided I have lot's of
free RAM. If it has to swap it really works the system.
--
csh
---------------------------------------------------------------------------
········@escape.widomaker.com (UUCP) | Amd486/40 Linux system
········@pcs.cnu.edu (Internet) | Christopher Newport University
From: Jeff Dalton
Subject: Re: Unix tower of babble tcl/awk/perl -- why not just lisp?
Date:
Message-ID: <CuA94G.K0y@cogsci.ed.ac.uk>
In article <····················@escape.widomaker.com> ········@escape.widomaker.com (Shannon Hendrix) writes:
>Marco Antoniotti (·······@mosaic.nyu.edu) wrote:
>: ········@escape.widomaker.com (Shannon Hendrix) writes:
>
>: >I don't buy that. You mean you loaded scheme and this script in a
>: >fraction of a second? I don't believe it.
>
>: Why don't you believe it? Have you _tried_ it?
>
>Not Scheme, Lisp. Yeah, Scheme can do it.
What do you mean? Scheme is a subclassification of Lisp.
In article <··················@lemur.cs.man.ac.uk>,
Stephen J Bevan <·····@cs.man.ac.uk> wrote:
>[ I've directed followup's to comp.lang.misc - bevan ]
>
>In article <············@nmti.com> ·····@nmti.com (Peter da Silva) writes:
> ... If you want to make a language attractive to a novice, you have to
> lay it out it so a novice can understand it ...
>
>Ok, so what layout can a novice understand?
That's the point isn't it? If I'm a novice then lisp will look
like a bowl of oatmeal with fingernail clippings on top. Perl will look
like a bowl of granola with flys (or whatever the annalogy was).
Algol and it's friends will look like some other breakfast food with
something else disgusting on top.
The point is that indentation schemes make sense in a context.
The novice context is provided by someone else.
chris
PS. Oh... That was a retorical question.
Take a look at the litterate programming stuff.