Lisp

Hello
I have tried to scratch the surface of Lisp. It seems to me that Lisp is a
nice experience. Paul Graham has written extensively on its productivity
and that motivated me to give it a shot. Now I use C. I have used Java
which is productive but at the cost of performance and I find that if I am
careful (and with practice) C feels really nice with its performance at
power over Java. What I want to know is that can I get performance with
Lisp as it is already productive due to the bottom-up scheme. Also C is
well suited for low level programming. How well is Lisp suited for it?
Please feel free to share your experiences to guide me.

Thank you.

(Note: I am OK with the parentheses.)

On Thu, 2008-09-11 at 20:23 +0000, Cross_AM wrote:
> Hello
> I have tried to scratch the surface of Lisp. It seems to me that Lisp is a
> nice experience. Paul Graham has written extensively on its productivity
> and that motivated me to give it a shot. Now I use C. I have used Java
> which is productive but at the cost of performance and I find that if I am
> careful (and with practice) C feels really nice with its performance at
> power over Java. What I want to know is that can I get performance with
> Lisp as it is already productive due to the bottom-up scheme. Also C is
> well suited for low level programming. How well is Lisp suited for it?
> Please feel free to share your experiences to guide me.
>
> Thank you.
>
> (Note: I am OK with the parentheses.)

The beauty is probably in the interpretive nature of LISP.

I mean you can program in a very functional oriented paradigm using
C or whatever.

But LISP makes no distinction between data and code… so you
do some pretty nice things that would be more difficult to do
with other languages.

I like LISP… but I don’t have a practical need for it
right now. You can imagine how easy it would be to create
a parallel machine using LISP. It may not perform as fast
as another language, but it makes writing programs easier
(if you can master its ways).

You’re not going to easily manipulate bits and bytes
with LISP (scheme).

In general is a funtcional, interpretive, high level language.

cjcox wrote:

> You can imagine how easy it would be to create
> a parallel machine using LISP.
Well with multi-core processors, may be Lisp can be more useful in present
context. (just my opinion)

On Thu, 2008-09-11 at 22:43 +0000, Cross_AM wrote:
> cjcox wrote:
>
> > You can imagine how easy it would be to create
> > a parallel machine using LISP.
> Well with multi-core processors, may be Lisp can be more useful in present
> context. (just my opinion)

Hmmm… not nearly as “neato”. With lisp you can shuttle
data (i.e. programs) as streams for execution across disparate
platforms on a network.

On interesting example is SBCL’s implementation. Its has a minimal number of C files (to connect with the operating system in matters like threads, sockets, etc) Ohloh, CVS]. Check this file to see how the primitive arithmetic operations are defined. I find it very interesting :slight_smile:

Nevertheless I agree that Common Lisp was meant for a more higher level used although it was already design with performance in mind. Scheme is even harder to optimize due to it’s academic/research/less pragmatical nature.

m4ktub wrote:

>
> cjcox;1870128 Wrote:
>>
>> You’re not going to easily manipulate bits and bytes
>> with LISP (scheme).
>>
>
> On interesting example is SBCL’s implementation. Its has a minimal
> number of C files (to connect with the operating system in matters like
> threads, sockets, etc) ‘Ohloh’
> (http://www.ohloh.net/projects/sbcl/analyses/latest), ‘CVS’
> (http://sbcl.cvs.sourceforge.net/sbcl/sbcl/src/runtime/)]. Check ‘this
> file’ (http://tinyurl.com/4m63n7) to see how the primitive arithmetic
> operations are defined. I find it very interesting :slight_smile:
>
> Nevertheless I agree that Common Lisp was meant for a more higher level
> used although it was already design with performance in mind. Scheme is
> even harder to optimize due to it’s academic/research/less pragmatical
> nature.
>
>
Thanks for your input. They are going to be quite useful.

m4ktub wrote:

> (http://www.ohloh.net/projects/sbcl/analyses/latest), ‘CVS’
> (http://sbcl.cvs.sourceforge.net/sbcl/sbcl/src/runtime/)]. Check ‘this
> file’ (http://tinyurl.com/4m63n7) to see how the primitive arithmetic
> operations are defined. I find it very interesting :slight_smile:
I found that Lisp can call assembly instructions much like C. Could you tell
me where to find more about that? Please suggest good books on Lisp as
well.

What I know is that low level feature is not part of the CL specification and therefore each implementation may have different takes on it or none at all. You can always rely on the foreign function interface which is present in most implementations (CFFI). That allows you to delegate anything to C and therefore almost bend metal within Common Lisp :slight_smile:

About calling assembly instructions, I’ve only red about SBCL’s VOPs. Now that I look at it again it may have just what you want (check this). Don’t know anything about support for that in other implementations. Corman Lisp looks like a promising implementations but don’t know much about it.

About books. I’ve never worked professional with any Lisp. My introduction to the family was with SICP of the Sussmans. Apart from that I’ve essentially red the HyperSpec and online books like Pratical Common Lisp.

m4ktub wrote:

> About books. I’ve never worked professional with any Lisp. My
> introduction to the family was with ‘SICP’
> (http://mitpress.mit.edu/sicp/) of the Sussmans. Apart from that I’ve
> essentially red the HyperSpec and online books like Pratical Common
> Lisp.
>
I also started with this book by Sussmans, then by porting Scheme to CL.

Gradually, I am feeling that C has a monopoly in low level programming. Is
there any other language that allows this so much, left aside FORTRAN, as
it for purely mathematical purposes?

Well, I’ve heard of the D programming language. If I recall it correctly, they put it in the “systems programming” category so it must have much of what the C language has in terms of low language constructs. But there are many other programming languages. Maybe some programming language lists could help you better after you find out how popular each language really is.

m4ktub wrote:
> Well, I’ve heard of the D programming language. If I recall it
> correctly, they put it in the “systems programming” category so it must
> have much of what the C language has in terms of low language
> constructs. But there are many other programming languages. Maybe some
> programming language lists could help you better after you find out how
> popular each language really is.
>
I didn’t know of D. It is a multi-paradigm language and uses garbage
collection as Lisp does. I find Lisp quite close to normal thought.
However, C is unmatched in speed. I would like to attain C speed in Lisp.

Well, that’s life … and the reason there are so many languages. :wink:

Hmmmmm. You should check out the language shootout. As any other language comparison, it only shows numbers and most absolutist conclusions are wrong. The fun about it is that you control the bias (with the numbers on the right) of the comparison.

Anyway, as you can see in the graph most top languages are very close and you can find Java 6 and Haskell very close to C (gcc).

Real world scenarios are different from this controlled comparison. In many of these real world scenarios the best language is not the one that can compute an infinite loop under 2 seconds :). For example, when programming a user interface, the program spends so much time waiting for the user that most languages have acceptable performance.

However, C is unmatched in speed.

False.Objective Caml is as fast as C.
Ruby, Io, PHP, Python, Lua, Java, Perl, Applescript, TCL, ELisp, Javascript, OCaml, Ghostscript, and C Fractal Benchmark
Using OCaml 3.09.x.

lambda geek wrote:
> False.Objective Caml is as fast as C.
> ‘Ruby, Io, PHP, Python, Lua, Java, Perl, Applescript, TCL, ELisp,
> Javascript, OCaml, Ghostscript, and C Fractal Benchmark’
> (http://www.timestretch.com/FractalBenchmark.html)
> Using OCaml 3.09.x.
>
Thank you for enlightening me.

m4ktub wrote:

> You should check out the ‘language shootout’
> (http://shootout.alioth.debian.org/). As any other language comparison,
> it only shows numbers and most absolutist conclusions are wrong. The fun
> about it is that you control the bias (with the numbers on the right) of
> the comparison.
>
> Anyway, as you can see in the graph most top languages are very close
> and you can find Java 6 and Haskell very close to C (gcc).
Nice information. Thank you. My ideas are being refined in this discussion.
Let me present another to test. I thought Linux was written in C because C
is good at low-level jobs and because it has speed. Now, I think you can
modify my statement to reflect more closely on reality.

“C has speed” needs some consideration. What C has is a structure that allows the relatively easy implementation of compilers that produce efficient code for many hardware architectures. The fact that it has many low level concepts helps because these concepts can be mapped almost directly to what the hardware supports. And it’s not assembly, which is nice.

The reason I’m mentioning this is because I’ve personally had to revise my notions of “speed” when programming in C. If you use the wrong algorithms and data types no language can save you.

Anyway, the Internet must be full of articles about Linux/Linus history. You can check them out. IMO C was used because it was the best tool for the job that Linus knew at the time (not saying it isn’t now).

Lisp can also be compiled, and compiled lisp is quite fast. Many apps that you wouldn’t think are or were originally written in lisp, and the ones that have been ported from lisp into C have been done so more because it’s easier to find C programmers than for speed improvements.

incognito9 wrote:

> compiled lisp is quite fast
Are there any benchmarks comparing speed gain of compiled Lisp versus
interpretted Lisp?

m4ktub wrote:

> not saying it isn’t now
That is the interesting part: it still is.

Not quite the article I was looking for, but here’s a nice write up on how fast lisp can be when it’s optimized

www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf

The punch-line is that on a relatively small subset of algorithms analysed, it’s as fast as C

There was an article published by somebody out of amherst a few years ago that was more extensive but I can’t find it.