Hello!
I have looked through the archives of this newsgroup and in some
documentation and I have found one reason why I should use LISP. `cons'
replace the task of making a `struct' in the C language and adding all the
neccessary variables and routines to handle linked lists, while also reducing
the overhead needed for linked lists. Am I correct?
How is the overhead reduced?
Are there other reasons why I should use LISP instead of C for some things?
--
Stephen
Please do not email me at ············@my-deja.com
Sent via Deja.com
http://www.deja.com/
Stephen <············@my-deja.com> writes:
> I have looked through the archives of this newsgroup and in some
> documentation and I have found one reason why I should use
> LISP. `cons' replace the task of making a `struct' in the C language
> and adding all the neccessary variables and routines to handle
> linked lists, while also reducing the overhead needed for linked
> lists. Am I correct?
No, not quite correct.
The "task of making a C struct" is replaced by "the task of using
DEFSTRUCT" to make a Lisp structure. :-).
Effectively, all of the major data structures available in C are
available in Lisp, _and more_. For instance, C does not natively
provide you with hash tables; Lisp has MAKE-HASH-TABLE as a native
function for that purpose.
> How is the overhead reduced?
Overhead is _added to_ insofar as the Lisp runtime does work
concerning memory management and garbage collection on your behalf,
typically without you paying attention to it.
The corresponding flip side of this is that you no longer write code
to do malloc() or free(), and the time that would have been taken to
run those should get deducted, to be fair :-).
> Are there other reasons why I should use LISP instead of C for some
> things?
The _bigger_ reason to use Lisp is if it allows you to spend your time
more wisely either:
a) Solving the _real problems_ for which you wanted to write
software, or
b) Expressing more sophisticated algorithms that may perform better.
A whole lot of C programming takes place to try to tune this and that
via attaching a declaration here and there. Anything that allows you
to pay more attention to building better algorithms will result in
_even bigger improvements._
Paul Graham describes it as "Lisp allows you to quickly develop
software that is slow," and indicates that it is almost impossible to
do that with languages like C. Generally because the "quickly" part
is highly unlikely to happen.
The merit that follows is that once you've got a slow piece of
software, it tends to be practical to tune it to make it faster.
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
<http://www.ntlug.org/~cbbrowne/lisp.html>
"If I could find a way to get [Saddam Hussein] out of there, even
putting a contract out on him, if the CIA still did that sort of a
thing, assuming it ever did, I would be for it." -- Richard M. Nixon
On Thu, 18 Jan 2001 01:29:52 GMT, Stephen <············@my-deja.com> wrote:
> Are there other reasons why I should use LISP instead of C for some things?
This paper by Richard Fateman may be a relevant reading:
Software Fault Prevention by Language Choice
http://www.cs.berkeley.edu/~fateman/papers/software.pdf
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Stephen <············@my-deja.com> writes:
>I have looked through the archives of this newsgroup and in some
>documentation and I have found one reason why I should use LISP. `cons'
>replace the task of making a `struct' in the C language and adding all the
>neccessary variables and routines to handle linked lists, while also reducing
>the overhead needed for linked lists. Am I correct?
No. Neither the overhead is reduced, nor is 'cons' a replacement for
struct. That's non-Lisper's Lisp teaching, complete crap.
>How is the overhead reduced?
It isn't. A linked List in a good Lisp compiler is as fast as a
linked List in a good C compiler.
Exception: A Common Lisp compiler is allowed to know about the list
data type and may replace a List used in the source code by a more
appropriate data type if it can prove that all accesses in the source
code behave as if it was a list and/or its knowledge about the list
data types allows it to inline or otherwise optimize accesses to a
variable declared to be type list.
Exception more general: It is easier to write Lisp code that may
quickly be switched between different data collection types that it is
to do the same thing in C.
>Are there other reasons why I should use LISP instead of C for some things?
Look up these concepts, either in the hyperspec or in more explanative
example books or code:
unwind-protect mapcar getf restart-case
funcall loop destructuring-bind with-open-file
typep format handler-bind with-output-to-string
[List shamelessly stolen from KMP]
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
* Martin Cracauer
[snip]
> >Are there other reasons why I should use LISP instead of C for some
> >things?
[snip list]
I was under the impression that 'read' alone would be a good enough
reason...
ivr, started on the "Wrong Side" of the Force
--
Much of this software was user-friendly, meaning that it was intended
for users who did not know anything about computers, and furthermore
had absolutely no intention whatsoever of learning.
-- A. S. Tanenbaum, "Modern Operating Systems, ch 1.2.4"
Igor V. Rafienko wrote:
>
> [snip]
>
>>>Are there other reasons why I should use LISP
>>>instead of C for some things?
>
> [snip list]
>
> I was under the impression that 'read' alone
> would be a good enough reason...
>
The C 'read' function? How so?
Stephen Kittelson
--
Please do not email me at ············@my-deja.com
Sent via Deja.com
http://www.deja.com/
Stephen <············@my-deja.com> writes:
> Igor V. Rafienko wrote:
> >
> > [snip]
> >
> >>>Are there other reasons why I should use LISP
> >>>instead of C for some things?
> >
> > [snip list]
> >
> > I was under the impression that 'read' alone
> > would be a good enough reason...
> >
>
> The C 'read' function? How so?
*What* C `read' function? Common Lisp *has* a `read' function,
C does not.
--
Raymond Wiker
·············@fast.no
Raymond Wiker <·············@fast.no> writes:
> >
> > The C 'read' function? How so?
>
> *What* C `read' function? Common Lisp *has* a `read' function,
> C does not.
C has a read function. It's even part of the POSIX standard
Regards
Friedrich
Friedrich Dominicus wrote:
>
> C has a read function. It's even part of the POSIX standard
Though not part of the C standard. You're thinking of fread(), perhaps?
Ian Wild <···@cfmu.eurocontrol.be> writes:
> Friedrich Dominicus wrote:
> >
> > C has a read function. It's even part of the POSIX standard
>
> Though not part of the C standard. You're thinking of fread(),
> perhaps?
`fread' is part of the standard library, which is not part of
the C language proper. `read' is a system call (or something similar),
and is *definitely* not part of the language standard.
Just trying to shift the focus to a new, off-topic subject :-)
--
Raymond Wiker
·············@fast.no
In article <··············@raw.grenland.fast.no>, Raymond Wiker wrote:
> ...
> `fread' is part of the standard library, which is not part of
>the C language proper. `read' is a system call (or something similar),
but the standard library is part of the C standard
hs
Hartmann Schaffer <··@paradise.nirvananet> wrote:
> In article <··············@raw.grenland.fast.no>, Raymond Wiker wrote:
>> ...
>> `fread' is part of the standard library, which is not part of
>>the C language proper. `read' is a system call (or something similar),
> but the standard library is part of the C standard
But read is not part of the C-library.
Ciao,
Oliver
--
Thus inexactness is a contagious property of a number.
(R5RS)
* Hartmann Schaffer wrote:
> In article <··············@raw.grenland.fast.no>, Raymond Wiker wrote:
>> ...
>> `fread' is part of the standard library, which is not part of
>> the C language proper. `read' is a system call (or something similar),
> but the standard library is part of the C standard
Who cares, read in C doesn't do anything *like* what READ in Lisp
does!
--tim
In article <··············@raw.grenland.fast.no>,
Raymond Wiker <·············@fast.no> wrote:
> Ian Wild <···@cfmu.eurocontrol.be> writes:
>
> > Friedrich Dominicus wrote:
> > >
> > > C has a read function. It's even part of the POSIX standard
> >
> > Though not part of the C standard. You're thinking of fread(),
> > perhaps?
>
> `fread' is part of the standard library, which is not part of
> the C language proper. `read' is a system call (or something similar),
> and is *definitely* not part of the language standard.
>
> Just trying to shift the focus to a new, off-topic subject :-)
I'm pretty sure he meant the read function in lisp, as an oblique reference
that you can use the same function to read code and data because code is
represented as data in lisp.
--
Glauber Ribeiro
··········@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com
http://www.deja.com/
In article <··············@raw.grenland.fast.no>,
Raymond Wiker <·············@fast.no> wrote:
>Ian Wild <···@cfmu.eurocontrol.be> writes:
>
>> Friedrich Dominicus wrote:
>> >
>> > C has a read function. It's even part of the POSIX standard
>>
>> Though not part of the C standard. You're thinking of fread(),
>> perhaps?
>
> `fread' is part of the standard library, which is not part of
>the C language proper. `read' is a system call (or something similar),
>and is *definitely* not part of the language standard.
>
fread is part of the C language proper, although there is a standard-
defined subset that does not include it. You can use it portably
on any hosted implementation (and anything actually useful that
can be done on a freestanding implementation is not portable).
read is part of the Posix standard, which is not part of C, but can
be viewed as an add-on package. (I believe the Posix standard is
actually incompatible with the C standard in ways that usually don't
matter much. Things like putting additional things into header files.)
read is part of the Common Lisp standard, and in there does a whole
lot more than fread or POSIX read.
If we want to talk about other ways Common Lisp is superior to C,
one of my favorites is that you worry about implementation details
a lot later in Common Lisp than in C. In C, if you write a function
to do something, you've already defined the types of things in a way
that you will find awkward to change later. You have to make more
little decisions in C before you have something you can test than
you do in Common Lisp.
(For efficiency junkies, this means you can profile a Common Lisp
program at an earlier stage than a C program, which means that you
can find out where the performance problems are earlier, which means
it's easier to make it run fast. This advantage does not apply to
the toy programs that everybody always runs as benchmarks, but is
very important to any worthwhile project.)
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
There was a study done last year (or 1999) that suggested Lisp is a more
economical
language/environment than Java or C/C++. The variables included
programmer efficiency, implementation time, and execution economics.
In general, well-written C was always the quickest and Java the slowest.
Java could be really bad if an algorithm was not written well. Learning
and development time tended to be best for Lisp, and it could hold its own
with C/C++ in terms of speed when comparing average-skilled programmers,
and definitely beat Java. While both Java and Lisp are burdened with the
overhead of a garbage-collecting run-time environment, well-written Lisp
could use significantly less resources than Java even though no
type-declarations
are made.
David Thornley wrote:
> In article <··············@raw.grenland.fast.no>,
> Raymond Wiker <·············@fast.no> wrote:
> >Ian Wild <···@cfmu.eurocontrol.be> writes:
> >
> >> Friedrich Dominicus wrote:
> >> >
> >> > C has a read function. It's even part of the POSIX standard
> >>
> >> Though not part of the C standard. You're thinking of fread(),
> >> perhaps?
> >
> > `fread' is part of the standard library, which is not part of
> >the C language proper. `read' is a system call (or something similar),
> >and is *definitely* not part of the language standard.
> >
> fread is part of the C language proper, although there is a standard-
> defined subset that does not include it. You can use it portably
> on any hosted implementation (and anything actually useful that
> can be done on a freestanding implementation is not portable).
>
> read is part of the Posix standard, which is not part of C, but can
> be viewed as an add-on package. (I believe the Posix standard is
> actually incompatible with the C standard in ways that usually don't
> matter much. Things like putting additional things into header files.)
>
> read is part of the Common Lisp standard, and in there does a whole
> lot more than fread or POSIX read.
>
> If we want to talk about other ways Common Lisp is superior to C,
> one of my favorites is that you worry about implementation details
> a lot later in Common Lisp than in C. In C, if you write a function
> to do something, you've already defined the types of things in a way
> that you will find awkward to change later. You have to make more
> little decisions in C before you have something you can test than
> you do in Common Lisp.
>
> (For efficiency junkies, this means you can profile a Common Lisp
> program at an earlier stage than a C program, which means that you
> can find out where the performance problems are earlier, which means
> it's easier to make it run fast. This advantage does not apply to
> the toy programs that everybody always runs as benchmarks, but is
> very important to any worthwhile project.)
>
> --
> David H. Thornley | If you want my opinion, ask.
> ·····@thornley.net | If you don't, flee.
> http://www.thornley.net/~thornley/david/ | O-
Steve Long <·········@isomedia.com> writes:
> There was a study done last year (or 1999) that suggested Lisp is a
> more economical language/environment than Java or C/C++. The
> variables included programmer efficiency, implementation time, and
> execution economics. In general, well-written C was always the
> quickest and Java the slowest. Java could be really bad if an
> algorithm was not written well. Learning and development time tended
> to be best for Lisp, and it could hold its own with C/C++ in terms
> of speed when comparing average-skilled programmers, and definitely
> beat Java.
One problem with studies of this kind is that they often don't factor
in those programs that don't run. Sure a well-written C program can
perform fairly well, but writing a C program that works correctly on
all reasonable input, fails gracefully on all erroneous input, and
degrades gracefully under unusual system conditions is actually a
quite difficult task; it certainly appears beyond the skill of an
average programmer.
So is a program that runs five times as fast but crashes on 5% of
the input cases better or worse than one that runs slower but solves
them all? (or one that runs twenty times faster, but crashes on 10%
of the input?)
> While both Java and Lisp are burdened with the overhead of a
> garbage-collecting run-time environment, well-written Lisp
> could use significantly less resources than Java even though no
> type-declarations are made.
I would guess that this has less to do with GC overhead than it has to
do with sandboxing and virtual machine implementations. JIT compiling
is impressive, but it doesn't have the source-code information to
allow it to do as good a job as a Java to native code compiler might
do.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Joe Marshall <···@content-integrity.com> writes:
>
> One problem with studies of this kind is that they often don't factor
> in those programs that don't run.
The specification of that comparison were quite clear. There was no
special error handling necessary.
> Sure a well-written C program can
> perform fairly well, but writing a C program that works correctly on
> all reasonable input, fails gracefully on all erroneous input, and
> degrades gracefully under unusual system conditions is actually a
> quite difficult task; it certainly appears beyond the skill of an
> average programmer.
I agree it's hard, but it's the C way. And you might have read the
worse is better articles in which the different mindsets were nicely
shown.
Regards
Friedrich
Steve Long <·········@isomedia.com> writes:
> ... While both Java and Lisp are burdened with the
> overhead of a garbage-collecting run-time environment, ...
Sorry -- for what I do I'm sure Lisp's memory management is a whole
lot superior (including speed) to manual memory management in
C. That's because I do a lot of dynamic memory allocation/deallocation
in C and malloc/free is too universal to be good at it.
Just my opinion.
Janis Dzerins
--
If million people say a stupid thing it's still a stupid thing.
Janis Dzerins <·····@latnet.lv> wrote:
> Steve Long <·········@isomedia.com> writes:
>> ... While both Java and Lisp are burdened with the
>> overhead of a garbage-collecting run-time environment, ...
> Sorry -- for what I do I'm sure Lisp's memory management is a whole
> lot superior (including speed) to manual memory management in
> C. That's because I do a lot of dynamic memory allocation/deallocation
> in C and malloc/free is too universal to be good at it.
It's implkementation-dependend; but you can malloc bigger chunks
of memory and then manage it in a way you can choose by your own.
That's very efficient, if you are an experienced C-Programmer
and not drunken while designing your program.
Ciao,
Oliver
--
Thus inexactness is a contagious property of a number.
(R5RS)
Oliver Bandel wrote:
>
> Janis Dzerins <·····@latnet.lv> wrote:
> > Steve Long <·········@isomedia.com> writes:
>
> >> ... While both Java and Lisp are burdened with the
> >> overhead of a garbage-collecting run-time environment, ...
>
> > Sorry -- for what I do I'm sure Lisp's memory management is a whole
> > lot superior (including speed) to manual memory management in
> > C. That's because I do a lot of dynamic memory allocation/deallocation
> > in C and malloc/free is too universal to be good at it.
>
> It's implkementation-dependend; but you can malloc bigger chunks
> of memory and then manage it in a way you can choose by your own.
> That's very efficient, if you are an experienced C-Programmer
> and not drunken while designing your program.
...though very rarely as efficient as the experienced C
programmer thinks it is, and even more rarely as efficient
as it could be if C didn't /require/ experienced programmers.
Ian Wild <···@cfmu.eurocontrol.be> writes:
> Oliver Bandel wrote:
> >
> > Janis Dzerins <·····@latnet.lv> wrote:
> > > Steve Long <·········@isomedia.com> writes:
> >
> > >> ... While both Java and Lisp are burdened with the
> > >> overhead of a garbage-collecting run-time environment, ...
> >
> > > Sorry -- for what I do I'm sure Lisp's memory management is a whole
> > > lot superior (including speed) to manual memory management in
> > > C. That's because I do a lot of dynamic memory allocation/deallocation
> > > in C and malloc/free is too universal to be good at it.
> >
> > It's implkementation-dependend; but you can malloc bigger chunks
> > of memory and then manage it in a way you can choose by your own.
> > That's very efficient, if you are an experienced C-Programmer
> > and not drunken while designing your program.
>
> ...though very rarely as efficient as the experienced C
> programmer thinks it is, and even more rarely as efficient
> as it could be if C didn't /require/ experienced programmers.
And experienced C programmers are rarer than they think.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Oliver Bandel <······@first.in-berlin.de> writes:
> Janis Dzerins <·····@latnet.lv> wrote:
> > Steve Long <·········@isomedia.com> writes:
>
> >> ... While both Java and Lisp are burdened with the
> >> overhead of a garbage-collecting run-time environment, ...
>
> > Sorry -- for what I do I'm sure Lisp's memory management is a whole
> > lot superior (including speed) to manual memory management in
> > C. That's because I do a lot of dynamic memory allocation/deallocation
> > in C and malloc/free is too universal to be good at it.
>
> It's implkementation-dependend; but you can malloc bigger chunks
> of memory and then manage it in a way you can choose by your own.
> That's very efficient, if you are an experienced C-Programmer
> and not drunken while designing your program.
And then comes Greenspun's Tenth Rule of Programming: any sufficiently
complicated C or Fortran program contains an ad hoc
informally-specified bug-ridden slow implementation of half of Common
Lisp.
Janis Dzerins
--
If million people say a stupid thing it's still a stupid thing.
Janis Dzerins <·····@latnet.lv> wrote:
> Oliver Bandel <······@first.in-berlin.de> writes:
>> Janis Dzerins <·····@latnet.lv> wrote:
>> > Steve Long <·········@isomedia.com> writes:
>>
>> >> ... While both Java and Lisp are burdened with the
>> >> overhead of a garbage-collecting run-time environment, ...
>>
>> > Sorry -- for what I do I'm sure Lisp's memory management is a whole
>> > lot superior (including speed) to manual memory management in
>> > C. That's because I do a lot of dynamic memory allocation/deallocation
>> > in C and malloc/free is too universal to be good at it.
>>
>> It's implkementation-dependend; but you can malloc bigger chunks
>> of memory and then manage it in a way you can choose by your own.
>> That's very efficient, if you are an experienced C-Programmer
>> and not drunken while designing your program.
> And then comes Greenspun's Tenth Rule of Programming: any sufficiently
> complicated C or Fortran program contains an ad hoc
> informally-specified bug-ridden slow implementation of half of Common
> Lisp.
Hey, guys.
It's ok, when you think lisp is a good language.
I'm not in this newsgroup to tell you all, that
C is the best; I'm here, because I think lisp
is very interesting.
When you all have to defend yourself and Lisp, because
one says: "If you want your C-Programs faster than with
frequently calling malloc, then invoke it less frequently..."
I think, that's the Lisp-programmers residual fear of
losing a benchmark with well-designed C-programs. :->
Well, I like layers of abstraction and have no problem,
using C for fast special lower-leveled things and Lisp for the
big and complex programs.
But maybe most Lisp-ers are like most C-programmers,
like most perople at all and think: One size fit's all.
Ciao,
Oliver
P.S.: Where can I find Greenspun's other Rules?
And: Who is "Greenspun"?
--
Thus inexactness is a contagious property of a number.
(R5RS)
Rene Kyllingstad <······@hamspam.stud.ntnu.no> writes:
> Oliver Bandel <······@first.in-berlin.de> writes:
>
> > And: Who is "Greenspun"?
>
> Check out http://philip.greenspun.com/
And if you don't, a quote:
"Lisp developers have the satisfaction of knowing that they got it right 30
years before anyone else. But that's about all they have to show for 40
years of hard work and hundreds of millions of dollars in government and
private funding. These days, most former Lisp programmers are stuck using
Unix and Microsoft programming environments and, not only do they have to
put up with these inferior environments, but they're saddled with the
mournful knowledge that these environments are inferior."
-- http://www.arsdigita.com/books/tcl/introduction.adp
Oliver Bandel <······@first.in-berlin.de> writes:
> Janis Dzerins <·····@latnet.lv> wrote:
> > Oliver Bandel <······@first.in-berlin.de> writes:
>
> >> Janis Dzerins <·····@latnet.lv> wrote:
> >> > Steve Long <·········@isomedia.com> writes:
> >>
> >> >> ... While both Java and Lisp are burdened with the
> >> >> overhead of a garbage-collecting run-time environment, ...
> >>
> >> > Sorry -- for what I do I'm sure Lisp's memory management is a whole
> >> > lot superior (including speed) to manual memory management in
> >> > C. That's because I do a lot of dynamic memory allocation/deallocation
> >> > in C and malloc/free is too universal to be good at it.
> >>
> >> It's implkementation-dependend; but you can malloc bigger chunks
> >> of memory and then manage it in a way you can choose by your own.
> >> That's very efficient, if you are an experienced C-Programmer
> >> and not drunken while designing your program.
>
> > And then comes Greenspun's Tenth Rule of Programming: any sufficiently
> > complicated C or Fortran program contains an ad hoc
> > informally-specified bug-ridden slow implementation of half of Common
> > Lisp.
>
> Hey, guys.
>
> It's ok, when you think lisp is a good language.
That's just what we do.
> I'm not in this newsgroup to tell you all, that
> C is the best; I'm here, because I think lisp
> is very interesting.
C is not the best. We all know that. It's just that it fits _some_
tasks more than any other programming language.
>
> When you all have to defend yourself and Lisp,
This time it was only me.
> because one says: "If you want your C-Programs faster than with
> frequently calling malloc, then invoke it less frequently..."
The point I was trying to make is: Common Lisp already gives me that.
> I think, that's the Lisp-programmers residual fear of losing a
> benchmark with well-designed C-programs. :->
Nobody is afraid of that, I suppose, since we know that Common Lisp is
partly implemented in C. And here comes my point again: why would I
want to do it again (poorly)?
> Well, I like layers of abstraction and have no problem,
> using C for fast special lower-leveled things and Lisp for the
> big and complex programs.
I have no problems with that too. I have increasing headache when I
have to write something that's more than trivial in C.
> But maybe most Lisp-ers are like most C-programmers,
> like most perople at all and think: One size fit's all.
I think Lisp people know better that that's not true (at least they
know that there are more programming languages than
C/C++/Java/Python/Perl/PHP in the world).
> P.S.: Where can I find Greenspun's other Rules?
I think this is the only one :)
> And: Who is "Greenspun"?
I don't quite know but can suggest to look at this site:
http://philip.greenspun.com/research/
Janis Dzerins
--
If million people say a stupid thing it's still a stupid thing.
"Steve Long" <·········@isomedia.com> wrote in message
······················@isomedia.com...
> There was a study done last year (or 1999) that suggested Lisp is a more
> economical
> language/environment than Java or C/C++.
The study can be found at
http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html. It was done by
Erran Gat of JPL.
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Raymond Wiker <·············@fast.no> writes:
>
> > >
> > > The C 'read' function? How so?
> >
> > *What* C `read' function? Common Lisp *has* a `read' function,
> > C does not.
> C has a read function. It's even part of the POSIX standard
What does POSIX standard to do with C standard?
Janis Dzerins
--
If million people say a stupid thing it's still a stupid thing.
In article <··············@asaka.latnet.lv>,
Janis Dzerins <·····@latnet.lv> wrote:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> > Raymond Wiker <·············@fast.no> writes:
> >
> > > >
> > > > The C 'read' function? How so?
> > >
> > > *What* C `read' function? Common Lisp *has* a `read' function,
> > > C does not.
> > C has a read function. It's even part of the POSIX standard
>
> What does POSIX standard to do with C standard?
It's part of the incestuous relationship between C and Unix.
> If million people say a stupid thing it's still a stupid thing.
Maybe, but it will sell a lot better!
:-)
g
--
Glauber Ribeiro
··········@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com
http://www.deja.com/
Friedrich Dominicus <·····@q-software-solutions.com> wrote:
> Raymond Wiker <·············@fast.no> writes:
>> >
>> > The C 'read' function? How so?
>>
>> *What* C `read' function? Common Lisp *has* a `read' function,
>> C does not.
> C has a read function. It's even part of the POSIX standard
C has no read-function.
Unix/POSIX provides a read-function with C-API.
Ciao,
Oliver
--
Thus inexactness is a contagious property of a number.
(R5RS)
* ············@my-deja.com
> >>>Are there other reasons why I should use LISP
> >>>instead of C for some things?
> >
> > [snip list]
> >
> > I was under the impression that 'read' alone
> > would be a good enough reason...
>
> The C 'read' function? How so?
The other way around. One of the strikingly elegant points that even
utter novices as I am could see in Lisp is the read function. In all
the languages that I am familiar with, storing the data structure used
to take some planning and peculiar restrictions even for the first
sketch of a system. IMVHE, dumping somewhat simple data structures in
Common Lisp was alarmingly simple.
As to C's read function (btw, it's is NOT part of the C language as
others have pointed out: it is a feature of certain platform and a
feature of a number of implementations): it simply tranfers whatever
is on an input device into memory without any knowledge (or
possibility thereof) of what is being trasferred. That is not an
indication of strength or superiority (or, at least, that is what I
was referring to in my comment).
ivr
--
Much of this software was user-friendly, meaning that it was intended
for users who did not know anything about computers, and furthermore
had absolutely no intention whatsoever of learning.
-- A. S. Tanenbaum, "Modern Operating Systems, ch 1.2.4"
Hi!
Stephen <············@my-deja.com> wrote:
[...]
> Are there other reasons why I should use LISP instead of C for some things?
Welll, I'm new to the Lisp-Language-family, learning Scheme, when
my time allows it.
But I'm very firm in C and Perl.
Now, where I'm exploring the Lisp-like-world, I see: It's
a very elegant language-family, allowing to concentrate
on the things one want to program; there is no distraction
from the implementing-work, like in C, where a lot of
energy goes into selecting the right data-type and writing
libraries, that do things, which the lisp's bring you
without any implemtning-work you have to do.
Ok, when programming a lot in C, that's not a very big
problem to choose the right data-type (experience is helpful)
like beginners of programming have.
But it's more elegant in Scheme/Lisp.
It doesn't matter if it's an int or a long int in C.
In Lisp-like languages you think in the problems, you want
to solve and in problem-solving; you think in data-structures.
In C you have to think in the problem-solving area but
also have to choose the right data-type in a very machine-
near manner. In scheme/Lisp it doesn't matter, how the
integer-variable is implemented. It may be a string, an
int or a long int, or so.
That's a very big advantage of the lisp-families.
If you want fast programs and think lisp does not
bring it to you (as I thought very long time too),
then look at this study:
=> http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html
Ciao,
Oliver
--
Thus inexactness is a contagious property of a number.
(R5RS)