14 replies to this topic

[Guest]

I haven't really looked into Lisp yet, but I read some web pages that say "Lisp is the language God uses" (or something like that). I have also stumbled upon this document that acts like Lisp is the best thing ever thought of. It is an interesting read, and I want some of you programming professionals (you know who you are) to evaluate it and maybe take a look at Lisp. Feel free to post any opinions you have, I really just want to know what everyone thinks.

I would also like to clear up any possible confusion ahead of time: When this document speaks of hackers, it means free software programmers not security breakers.
Edit: Some info on the guy who wrote it, Paul Graham.

Here is a comic for some laughs:

Edited by Guest, 12 October 2009 - 10:12 PM.

[Guest]

I was thinking about Lisp and the Blub example while taking a shower, and I thought of a connection with one of ZekeDragon's blog entries. The Following text is from this blog entry:

"ZekeDragon" said:

A lot of people will say these things are simple concepts, and I suppose now that OOP is so ingrained in my psyche, they are. However there always felt like there was a ceiling, some kind of mental barrier that prevented me from fully grasping everything that happened. My vision of the software lacked depth, I suppose you could say. I used to prefer C over C++ because higher C++ constructs felt confusing, now I can't live without the C++ constructs and C feels like being gimped. I wish there was some way I could describe what this feeling is... and the best way I can right now is that it's like I bridged a mental gap, from understanding logically to understanding conceptually. I changed from knowing how to write the code itself to understanding why it's written that way!

Now here is a quote from Paul Graham's Beating the Averages page:

Quote

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.
By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.

So I think Paul Graham makes a good point, but here is something I find flawed on that page:

Quote

Few would dispute, at least, that high level languages are more powerful than machine language. Most programmers today would agree that you do not, ordinarily, want to program in machine language. Instead, you should program in a high-level language, and have a compiler translate it into machine language for you.

I think this whole thing just contradicts itself. The first sentence says that high level languages are the most powerful. The third says you should translate your high level language into machine language. This says to me:A machine language can do everything a high level language can. That is true, so a machine language must be just as powerful. Now, a high level language can't do everything a machine language can do. Doesn't that make the machine language more powerful? Or is having features more powerful?
I think the power of a language is in the eye of the beholder (As long as it's Turing Complete). Assembly language does not have special features, but it gets down to the bare memory. That gives you power. Of course Python has things that make it much more convenient and efficient to code in. That also gives you power.
Well, those were just some things I was thinking about, this stuff will probably make more sense when I'm older and have taken classes on programming.

[ZekeDragon]

Stating a language as 'powerful' is in itself a nebulous term, and subject to individual interpretation. I actually do take issue with Paul Graham's concept of a "power continuum" in itself, and I think what he was referring to in this continuum was actually what I would refer to as 'fluidity'. It's difficult to obtain an objective measure of 'poweful' simply because he doesn't define what he means by powerful. If 'powerful' is defined as getting the most processing out of the least clock cycles than he is absolutely wrong about Lisp. If, however, he's talking about a language that does not get in the way of the programmer, easily allows the programmer to build upon previous code, and allows the programmer to express an individual solution in the shortest amount of time, then Lisp may be just what he's talking about.

Then again, each of these measures I listed is based on the experience of that programmer in that language. Lisp simply isn't the end-all, an experienced C programmer is going to write faster programs in a shorter time than an inexperienced Lisp one. However, assuming both of these programmers were relatively equally proficient in their chosen languages (let's assume capable of writing any program with the chosen language, 5-10 years of experience), the Lisp programmer could very well complete a program in a shorter amount of time.

Choosing a language, however, isn't just a reflection of the three criteria I listed above. An important aspect of choosing a language is knowing the host machine you're programming for can run the written program. This is a significant stumbling block for Lisp on Windows (Linux comes with the Common-Lisp interpreter, clisp), and it's just as big for Python. People have been (reluctantly) taught to go get the JRE, though, so this is much less of an obstacle since you can mostly trust that the end user will have the runtime environment. In contrast to programs that run on end-user machines, Lisp could be a perfectly wonderful language for a server, since only the server would actually need a Lisp interpreter and the end user will still gain the advantages of the program.

Either way, I don't have any "religious attachment" to any particular language as asserted by Paul Graham. I'm now looking into Lisp, pulled out my interpreter, and have started playing with the language to see where I could go with it. I may just find it to be extremely pleasant, like I currently do Python. Then again, I may feel the same with Ruby if I learned that. The only question I have is, and I quote:

Paul Graham said:

But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up.

How is he, as a Lisp programmer, to know that any language he isn't familiar with yet, perhaps Ruby, isn't more 'powerful' than Lisp if it's impossible to see from lower on the "power continuum"?

[BlaineSch]

I think John knows a bit about it. I have not looked much into it besides after seeing some of his source code. I saw a quick 5 line program that could get a word say "animal" and rearrange it to every single possible combination. Which is obviously a very amazing tool especially if it can do it in like 5 lines.

I like the comic, made me laugh.

[ZekeDragon]

@BlaineSch: Like randomly placed the letters in all of the possible letter sequences of "animal" or every anagram of "animal", like from a dictionary?

[BlaineSch]

This might clear it up ^_^

http://forum.codecal...rmutations.html

[WingedPanther]

Here's my thought on the subject, having never learned Lisp: it's a good idea to learn every style of language out there. I haven't learned Haskell yet, but it's on my radar. Lisp and Scheme are both on my radar as well. Becoming familiar with a variety of languages means you can think in a variety of ways.

I code in Delphi a LOT. It's a nice language, sort of the best features of C++ and VB: pleasant syntax that compiles to a stand-alone .exe, RAD development, the whole nine yards. However, because I know C++, I'm not amazed by the RAD interface. I know the whole thing is just code, and can actually open the .dfm files to see the code that makes the RAD interface happen. Anyone who's used gtkmm, wxWidgets, etc will look at the full Delphi code and understand what's being presented. Someone who hasn't will be amazed and intimidated.

We get locked into modes of thinking. C++ and Java, I know we've seen enough arguments about them recently, have very few differences compared to some of the languages out there. Try teaching a C++ or Java programmer Haskell and you'll get a very similar reaction: "WTF?" Functional programming just isn't part of their paradigm.

I suspect learning Lisp would help me understand the Boost::Lambda library for C++. Anything that lets you think differently about problems is a good thing. You may not be able to apply it immediately, but it will come :)

[Guest]

I just found out that there is a Lisp operating system. I haven't tried it, but it is a cool idea.

[todavies]

As a lisp nut (i've been coding in lisp for two or three years now) I'd like to throw my two cents in here, If i remember correctly PG does define 'power' (albeit nebulously) as increased abstraction rather than either of the other two definitions of power - the formal one being largely useless as all programming languages are turing complete. And the other being performance. I take issue with the idea that graham would be 'dead wrong' about lisp having good performance. The worlds fastest web server is written in common lisp (teepee2) handling 12,000 requests per second on a mediocre laptop (iirc, google it, the guy [yes, it is written by one guy] has benchmarks against a C server that can do ~10,000 per second) and bluntly if you can't out perform C in (common) lisp, you know C too well :P Lisp is compiled, and importantly for large systems it allows you to use closures which are a fantastic tool if you need to be fast and not make your head explode.

This is a little beside the point, so back on task: why is it justified to say that Lisp is on top of the power continum if graham admits no one can see up it? Because of meta-programming - Lisp can be any language and support any paradigm you can be bothered to write macros to implement. You can know it is at the top because it can implement any abstraction that can be imagined. (incidently all the cool stuff in ruby/python - metaobjects and so on has been in CL since it was standardized in the 80s, the only thing that is iritating is that CL is not 'objects to the core' but since methods are defined based on types [which include integers and floats etc] not classes it doesn't matter much)

[marwex89]

Interesting! Seems like I should maybe learn some lisp.. Just one question: One talks about a lisp interpreter, but you (todavies) says it is compiled?

[ZekeDragon]

@marwex89: It's either one. Lisp, similarly to many other languages, can be interpreted or compiled.

@todavies: Comparing one program written in Lisp with what is abstractly an equivalent program written in C is all fine and good, but has nothing to do with the language speed in itself. You can write bad C code just as easily as you can write bad Lisp code. The particular flavor of Lisp I'm talking about is Scheme, which is what I'm looking into, but I have a Common-Lisp implementation and it's more than fast enough to do things. I never said "Lisp is inefficient", I said that I believe a well-written C program will be faster than a well-written Lisp program, and the very simple reason behind this is that abstraction. You're abstracted away from bignum precision, string maintenance, bitwise operations, etc. and allowed to think more about design than implementation. This is a perfectly virtuous goal, but not without its costs. What's more, things are usually described using hundreds of other described beforehand functions, that are sort of retrofitted to perform different purposes, often with recursion (and I'm not talking about tail recursion). This can lead to very deeply nested hierarchies, which are inefficient, and is one of Lisp's pitfalls to be avoided.

todavies said:

bluntly if you can't out perform C in (common) lisp, you know C too well

I disagree entirely. To simply write off a programmer's ability to use C in a way that leads to more efficient algorithms as "They know C too well" is ignorant and kind of dogmatic. Being skilled at something should not be a fault unless you've got some kind of emotional penchant toward the alternative. Whether or not the efficiency gain was worth the expense in programmer time is a matter of debate, one that I am actually firmly on the side of "less-efficient, quicker programming times", but nonetheless I believe that the best written C program will exceed in speed and resource consumption than that of the best written Lisp program. I have no way to objectively measure that yet, but I'd like to.

todavies said:

why is it justified to say that Lisp is on top of the power continum if graham admits no one can see up it? Because of meta-programming - Lisp can be any language and support any paradigm you can be bothered to write macros to implement.

That's certainly an interesting language feature, but in no way does this insinuate that, as a language, it is the end-all to beat all. Perhaps natural readability is more important, which Python advocates, and all of those parenthesis simply are getting in the way. As long as you subscribe to Pretty printing rules for Lisp, you should be able to generally understand what the algorithm is supposed to do, but without having context it's very difficult to see how something could be relating to your problem. I'll continue my learning of Lisp, no doubt, but I refuse to believe that every other language is worthless in the face of Lisp's "awesome power".

[todavies]

Yes, the most efficient C programs usually do outperform lisp ones, the :P was there for a reason, i know C quite well, and i quite like the language, but it just takes longer to get things done, oh, and segfaults, dangling pointers and all the other junk to do with the lack of gc just irritates me...

Things to note - while common lisp is, by default dynamically typed which causes a performance hit, you can give a common lisp compiler type hints through declarations such as (declare (fixnum i)) so yes, you do get the abstraction/safety but you can choose to throw it away if you know you won't need it...

Scheme is less efficient because as far as i know there are no decent native compilers for scheme

I stand by the fact that you can write ANY paradigm in lisp, if you want python style syntax you can hack the reader, and if you think this is cheating (cause i have to admit the api for the reader is hideous) then you can do what the loop macro does and define your own mini-grammar, the following is a completely contrived example but ANSI common lisp none the less:

(loop

  for x = 1 then (1+ x)

  for foo in some-long-list

  for y being the hash-keys of some-hash-table

  collecting y into keys 

  do (print foo)

  when (numberp y) average (+ x y) into key-avg

  when (and (> key-avg 3) (stringp y))  count y into string-count

  finally return (list keys key-avg string-count))

Looks a lot like python doesn't it? This example doesn't enforce nice indentation like python, you'd have to hack the reader for that, but it looks 'nicer' to the non-lisper.

I'm actually working on a nicer api to the lisp reader as part of my research on extensible programming languages,

The reason lispers don't hack out the parens is that they are a feature not a wart (being able to see the syntax tree is nice when you are manipulating them so much of the time), but you need to understand meta-programming before you can realize this so most new-comers/casual-observers dislike them... In fact many lispers hate the loop macro because you can't use other macros to extend it it - has its own fixed grammar where you can't explicitly see all the bindings etc.

No one is saying anything other than lisp is useless, because it takes work to mould lisp into being good at the same things as another language. Often its just not worth it - i use php/python all the time for my own projects, maybe not as much as lisp, but quite frequently, mostly because they are 'batteries included' languages that come with massive sets of libraries, but when you are writing a big project most of the time you are going to write 80+% of the code from scratch anyway, so why not use lisp which is missing a library or 2 you'd like, 9 times out of 10 you can at least find a binding for a C library that does the same thing