LispForum

Posted: **Fri May 14, 2010 6:52 pm**

Gerenuk wrote:
gugamilare wrote: Now, there are a couple of ways you would do it in, e.g., Python:
I'd say there is only one straightforward way.

Actually, you got the wrong problem. Creating the closure, ok, that is easy and has nothing to do with macros. The macros which are created are macros that make it possible to store a function into a file. In my particular case, I would have a program that generated code (using lists) that would be evaluated (compiled) and produce various functions. Those functions would be lost around objects (class objects), many would be substituted by other functions, ans so on. Then, at some point, I would like to be able to save everything into a file and close the application in such a way that I could continue computation later when opening the program again.

There my macros come into place. There is already many libraries that are able to store any kind of objects into files. I chose one that was extensible, cl-store, and extended it to allow storage of functions. How, you ask? Creating macros that would remember the code of the functions and variables in their creation, associating them with their code (in a hash-table) and free variables.

Gerenuk wrote: That's absolutely true - before iterators/generators were introduced there was a really useful part missing. But OK: can you think of a feature that isn't implemented in Python yet?
Iterators and generators are, but beyond that there isn't much special. So is anything missing in Python?

A MetaObject Protocol and... macros

I think you are viewing this the wrong way. Of course Python has every general-purpose tools available today. But, in Lisp, you can create not-so-general tools, specific for your problems. It is a common concept that libraries in Lisp are actually DSLs created for their specific purpose. So it is hard to say which tools Python does not have, except the meta-tools that allow you to create your own tools as you need them. Whether each specific problems need their own tool or not, that varies with the problems themselves.

Try reading ANSI Common Lisp from Paul Graham, it has a neat explanation about what is Lisp all about, The Art of MetaObject Protocol, that explains what is MOP and why it is so useful, or Practical Common Lisp, which is a gentle and yet deep introduction into Common Lisp.

Posted: **Fri May 14, 2010 7:01 pm**

This might suit your needs a bit: http://rosettacode.org/wiki/Playing_cards (note: lisp is lableled as "common lisp).

Pretty darn honest comparisons between languages. If I still had access to an iSeries server* I'd be tempted to add a COBOL example

*type was sever, very Freudian.

Posted: **Fri May 14, 2010 11:23 pm**

Gerenuk wrote:Iterators and generators are, but beyond that there isn't much special. So is anything missing in Python?

As gugamilare said, while most common patterns might have been already implemented, in Lisp you can use the same method to implement uncommon patterns strongly coupled to your problem domain. This doesn't appear that often if your problem domain is not very complex and very similar to what is already common.

Gerenuk wrote:What's crippled? You mean you cannot put commands in the lambda? So far it seemed fine, because as soon as your lambda is so big as to include statements, you rather write a full function definition. "def f():" isn't that much to write.

I rather wouldn't, because this, in my opinion, breaks the flow, especially since Python forces indentation, and introduces irrelevant names. There are also some issues with scope handling, which also affects more complicated closures. Not that, as I think about it, I know what those issues exactly are... but I find conflating setting and creating variables confusing anyway.

Gerenuk wrote:I'd highly appreciate real, short examples in this thread.

As has been said multiple times, for powerful features there aren't any examples which would be short and real at the same time. Special variables are, essentially, properly composable global variables. It is not that easy to use that in non-contrived way in anything short. I suggest that you spend some time learning basics of Lisp and then read some real code. Librariers by Edi Weitz are usually held up as examples of quality code.

In general, Lisp features which hadn't been already reimplemented in other languages (remember that Lisp is about fifty years old, and Common Lisp over fifteen) are most useful for longer programs in complex problem domains. Unless you consider the regular syntax as a major feature, which I do, but apparently most people don't. Also, there is no magic. Remember that whatever the program is written in, they are all executed on the same hardware, so there is not anything which some language can do which other cannot.

Posted: **Sat May 15, 2010 3:36 am**

Maybe one important question which comes to my mind:
What is an example for a software project which is based on Lisp programming code *exclusively*?

gugamilare wrote: Actually, you got the wrong problem. Creating the closure, ok, that is easy and has nothing to do with macros. The macros which are created are macros that make it possible to store a function into a file.

Well OK. In that case I really would need to define a new class.

Code: Select all

class makeAdder:
  def __init__(self,n):
    self.n=n
  def __call__(self,x):
     return self.n+x
a=makeAdder(10)
print a(20)

Any object can be stored with "pickle" even though there might be some caveats necessary.
Just my impression is that all these alternative ways to write code all at least as good as macros for all practical reasons. Of course I haven't programmed any Lisp, but that's why I'm asking for code examples here to convince myself.

gugamilare wrote: I think you are viewing this the wrong way. Of course Python has every general-purpose tools available today. But, in Lisp, you can create not-so-general tools, specific for your problems. It is a common concept that libraries in Lisp are actually DSLs created for their specific purpose. So it is hard to say which tools Python does not have, except the meta-tools that allow you to create your own tools as you need them.

The "wrong way" argument doesn't convince me

if for all practical reasons clean alternatives can be found just work just as well.
Of course I don't want to talk about "tools" related to libraries, because in any language you can add the missing libraries yourself. And actually that's what's the thread for: an example from your experience as programmers for the surprising "not-so-general tools" for a specific problem.

gugamilare wrote: Try reading ANSI Common Lisp from Paul Graham, it has a neat explanation about what is Lisp all about

Actually this page my friend was refering me to. I read a couple of paragraphs and got the impression he is a fanatic who lost the ability to judge freely. His essays are long, with many repeats, mostly vague and he rarely refers to real facts which could convince me. He makes many manipulative reinterpretations of concepts as to suit his own needs.
So I tried googling other comparisons, because I cannot trust Paul a word since he seems so much polarized.

gugamilare wrote: The Art of MetaObject Protocol, that explains what is MOP and why it is so useful, or Practical Common Lisp, which is a gentle and yet deep introduction into Common Lisp.

I'll read that. It could be a good answer to my question... Maybe...

lithos wrote:This might suit your needs a bit: http://rosettacode.org/wiki/Playing_cards (note: lisp is lableled as "common lisp).

That's a great page and I had already looked at some example. However Lisp does not beat Python for length in the examples.

Ramarren wrote:As gugamilare said, while most common patterns might have been already implemented, in Lisp you can use the same method to implement uncommon patterns strongly coupled to your problem domain. This doesn't appear that often if your problem domain is not very complex and very similar to what is already common.

So can you describe an example with a more complex problem?

Ramarren wrote: Remember that whatever the program is written in, they are all executed on the same hardware, so there is not anything which some language can do which other cannot.

Oh sure. But I'm thinking about speed of software development. Lines of code are probably similar to python. So the last factor is code readability and natural problem solutions. I think most people agree that purely readability is better in python.
And here I was searching for code examples which solve problem in a way which is more natural to human thinking than equivalent solutions in python.

Posted: **Sat May 15, 2010 4:46 am**

Gerenuk wrote:What is an example for a software project which is based on Lisp programming code *exclusively*?

Gerenuk wrote:So can you describe an example with a more complex problem?

I am not sure what exactly are you asking, but some examples of large software open-source projects written in Lisp are: ACL2 (which, among other things, had been used for formal verification of processors by AMD) and Maxima. There are also quite many proprietary application using commercial implementations, this page lists some using Allegro Common Lisp. Generally applications from the domain formerly known as Artificial Intelligence are usually where Lisp is useful.

Gerenuk wrote:And here I was searching for code examples which solve problem in a way which is more natural to human thinking than equivalent solutions in python.

The problem is since you obviously already know Python, and you internalized it, solutions in Python appear "natural" to you. There is nothing natural about programming, since the necessity of this mode of thinking did not exist in natural environment. Therefore any differences between languages which are relatively similar in expressiveness are swamped by preexisting knowledge. So what you want to be shown is impossible for you to see. You have to learn Lisp at least as well as you know Python, and then decide which do you want to use.

Or if you are just looking for an excuse for your friend to not learn Lisp, then: no, there is no magic and no silver bullet and Lisp will not write your program for you. If you don't care about performance, syntax and those features listed at the page I linked some time ago, then Lisp is just another rather nice language, but not obviously superior to Python.

Posted: **Sat May 15, 2010 5:27 am**

Gerenuk wrote: As with the first Lisp example, I cannot fully translate the way to intermix code and data, but it seems I can write a program just as short and clear which has the same functionality.

That's true when comparing any reasonably high-level turing- complete language with another thus classifiable language.
Different idioms that result in the same result.

Posted: **Sat May 15, 2010 5:36 am**

Ramarren wrote: The problem is since you obviously already know Python, and you internalized it, solutions in Python appear "natural" to you. There is nothing natural about programming, since the necessity of this mode of thinking did not exist in natural environment.

Oh there is. You should try http://www.muppetlabs.com/~breadbox/bf/
And end, to me it only matters in which language I have the most success. So I won't start something completely new if the success per learning time ratio is just the same as for other languages.

Ramarren wrote: You have to learn Lisp at least as well as you know Python, and then decide which do you want to use.

Not necessarily. If my hypothesis that almost all languages are equivalently comfortable seems plausible, then I can judge by something superficial like the looks of the code.

Ramarren wrote: Or if you are just looking for an excuse for your friend to not learn Lisp, then: no, there is no magic and no silver bullet and Lisp will not write your program for you.

It's not about excuses. He doesn't know Lisp either. It's rather that on the Internet I often read "Lisp actually has the silver bullet and it's a shame that no-one sees it. But I cannot tell you what it is"
This reminded me of religions which try to save their view by shouting out claims, but disallowing investigations.

Ramarren wrote: If you don't care about performance, syntax and those features listed at the page I linked some time ago, then Lisp is just another rather nice language, but not obviously superior to Python.

That's a useful statement. So I will look into the mentioned features. I hoped to get a first impression from some example here.
Macros don't convince me so far. Maybe the Metaobject scheme will. In my view the syntax is rather a disadvantage. Storing bits 0 or 1 only is even a more "simple" scheme, yet it doesn't mean it's more convenient to think this way. So simplicity or universality is not an arguement.

TheGZeus wrote: That's true when comparing any reasonably high-level turing- complete language with another thus classifiable language.
Different idioms that result in the same result.

I mean not theoretically, but considering that it should be easy to program. It's not hard to show why Python is much more convenient than C for programming.

Posted: **Sat May 15, 2010 6:07 am**

Gerenuk wrote:Oh there is. You should try http://www.muppetlabs.com/~breadbox/bf/

Just because two things are both not natural doesn't mean they are equally hard or equally easy. I am not saying that two languages cannot handle complexity better or worse, but it still doesn't have that much to do with natural human thinking. Although I guess there are different capacities for unnatural thinking... Also, human brains are quite variable. In fact I think affinity for Lisp syntax must be at least partially neurologically determined... something about syntactic and semantic reasoning.

Gerenuk wrote:It's rather that on the Internet I often read "Lisp actually has the silver bullet and it's a shame that no-one sees it. But I cannot tell you what it is"

Well, most of that is inertia. Lisp is somewhat of a silver bullet when compared to Fortran, C and other Algol-derived languages, like Java. At the time Common Lisp was standardized by ANSI (1994) it was way ahead of most widely used languages. Most of that "silver-bulletness" has already been acquired since then by languages like Python or Ruby. The primary objective advantage of Lisp remaining is that compilation has been mostly figured out, unlike for Python where it is still at best experimental, or Ruby which I believe cannot be usefully compiled at all due to its semantics.

Most of the rest is either personal preference, or features that are hard to explain. Macros especially, since any simple macro is easy to translate by hand, and then of course it appears as it would be easier just to write out the translation. And it is not as writing macros happens that often, I think the most complex I have written was this. Or maybe the formula unit verification thing.

Although through all this it might be worth noting, I am not a professional programmer, so most of my programming is more-or-less recreational, and so my opinions, not to mention code, might not be representative for serious Lisp programmers.

Gerenuk wrote:He doesn't know Lisp either.

Why would someone advise doing something which they themselves have not done, or learning something they do not know?

Posted: **Sat May 15, 2010 6:23 am**

Ramarren wrote: Most of the rest is either personal preference, or features that are hard to explain. Macros especially, since any simple macro is easy to translate by hand, and then of course it appears as it would be easier just to write out the translation. And it is not as writing macros happens that often, I think the most complex I have written was this. Or maybe the formula unit verification thing.

Thanks for the references. I noticed I can best examine the difference by trying to replicate code in Python. Can you recommend a specific other high-quality macro I could attempt? (as I don't know much Lisp it's hard for me to judge suitable macros myself)

Ramarren wrote: Why would someone advise doing something which they themselves have not done, or learning something they do not know?

He has read Paul Grahams essays, and believes every word of it. He says if he wanted to start learning a comfortable language, he'd chose Lisp.

Posted: **Sat May 15, 2010 6:26 am**

Gerenuk wrote:
gugamilare wrote: Try reading ANSI Common Lisp from Paul Graham, it has a neat explanation about what is Lisp all about
Actually this page my friend was refering me to. I read a couple of paragraphs and got the impression he is a fanatic who lost the ability to judge freely. His essays are long, with many repeats, mostly vague and he rarely refers to real facts which could convince me. He makes many manipulative reinterpretations of concepts as to suit his own needs..
So I tried googling other comparisons, because I cannot trust Paul a word since he seems so much polarized.

Actually, Paul Graham is one of the most successful Lispers around. He is quite a good programmer, mind you, much better than anyone here in this forum. If you decide to read more than two paragraphs of the book, you will also see that he has a great ability to abstract and simplify problems. He also made a couple of articles explaining simple yet clever ideas in algorithms. So, don't think he is just a random "mindless fanatic". But of course he is fanatic. Everyone who is very good at something is fanatic.

Gerenuk wrote:
gugamilare wrote: Actually, you got the wrong problem. Creating the closure, ok, that is easy and has nothing to do with macros. The macros which are created are macros that make it possible to store a function into a file.
Well OK. In that case I really would need to define a new class.[...]

Ok, that would work, but it is a workaround. Substituting functions with classes is a very known method to avoid "needing" functions or closures, but they are not as flexible. You would be forcing users of your library create classes and methods instead of functions if they want to store them in a file. You might be satisfied with this, but I wouldn't. Forcing you to do workarounds is very common in other languages, but AFAIK they are quite rare in CL.

Just to summarize, I wouldn't be able to find a small example where Lisp supersedes Python greatly. Python developers make sure that doesn't happen. If I show a small Lisp program, you add some bits of code here, other there and transport that program to Python in a satisfactory way. However, both Lisp and Python have their strong and weak points which tend to be more and more apparent as your programs grows in size and complexity. Lisp is very good in general when your problem or idea to solve it is complex, abstract or goes far from common approaches. It is defective in modern tools like multiple threading, sockets and so on.

LispForum

Only in Lisp

Re: Only in Lisp

Re: Only in Lisp

Re: Only in Lisp

Re: Only in Lisp

Re: Only in Lisp

Re: Only in Lisp

Re: Only in Lisp

Re: Only in Lisp

Re: Only in Lisp

Re: Only in Lisp