Lisp and "symbols": difference with Python or other script!

Started by ale870, June 03, 2010, 02:46:12 AM

Previous topic - Next topic

ale870

Hello,



lisp dialects work with the concept of "symbol": well, practically speaking, what's the difference between newLisp and Python?

Ok, ok, I know the difference (I use newLisp from several years ;-), but, maybe, I'm not able to "get" some key-differences.

I mentioned Python, but the concept is similar for other scripting languages.

See the following code:


(setq newlisp-code '(println "Hello world!"))

Well, I can evaluate it and I get:



>> (eval newlisp-code)
Hello world!
>>


I can do the same using (almost) any other script language:



a = "print 'Hello world'"
eval(a)


So, I know that in the second case the code is a string, instead in newLisp the code inside the list are symbols. But practically speaking, in the real-world, what's the real difference? Why newLisp is "better" than another script language?



In both languages I wrote some code then I evaluated it (and real-time parsing and "compilation" was required). Ok, we can talk about the "contexts" where the code is executed, but the main concept is the same.



(I don't know if my question is clear, but I hope so).



Thank you!
--

xytroxon

This Paul Graham piece: "Revenge of the Nerds", gives a good over view...



http://www.paulgraham.com/icad.html">http://www.paulgraham.com/icad.html
QuoteSo the short explanation of why this 1950s language is not obsolete is that it was not technology but math, and math doesn't get stale. The right thing to compare Lisp to is not 1950s hardware, but, say, the Quicksort algorithm, which was discovered in 1960 and is still the fastest general-purpose sort.


Even Lisp creator John McCarthy didn't understand how profound his discovery of eval was!



In some ways, Lisp-like languages are like working (programming) in clay... You add here... Take away over there... Push it this way... And push it that way... Until it is just so... Then you fire (compile) it to achieve it's final form and fullest strength... In the end, you either have achieved a useful form, or an ugly lump of hardened clay... While you can make Lisp clay pots, jugs and plates today, it is a lot of work... Python plastic, is of course more utilitarian and mass producible... But it is in the artistic sculpting potential of the (new)Lisp clay that continues to hold the allure...



newLISP is of course Silly Putty... The polydimethylsiloxane of the Lisp world...



http://en.wikipedia.org/wiki/Silly_Putty">http://en.wikipedia.org/wiki/Silly_Putty



-- xytroxon
\"Many computers can print only capital letters, so we shall not use lowercase letters.\"

-- Let\'s Talk Lisp (c) 1976

cormullion

There may be fewer differences than you think.


Quote"Basically, Python can be seen as a dialect of Lisp with "traditional" syntax"


see http://norvig.com/python-lisp.html">//http://norvig.com/python-lisp.html



although the comparisons are with Lisp rather than newLISP. And you could read http://www.prescod.net/python/IsPythonLisp.html">//http://www.prescod.net/python/IsPythonLisp.html too.

Kazimir Majorinc

If you like eval, i.e. using code as data then you need other half - the code in form that is easily processed as data. That is the advantage of Lisp - important one - if one wants to use eval alot. Surely, it is not that important if eval is only of marginal use. However, my impression is that Lisp community - or at least three most popular dialects - neglected whole paradigm.
http://kazimirmajorinc.com/\">WWW site; http://kazimirmajorinc.blogspot.com\">blog.

ale870

I think that people talk about symbols, about mutual-exchange between code and data, but I think almost everyone does not arise the real "power" of this!

Some people think that CODE<->DATA means I can write a script as data then I can execute it as code. But if the "power" would be only this one.... well... every script language with "eval" function could accomplish this! Not only Python.

Maybe we should not forget that a lot of languages implement "eval" since Lisp was [the first?] language which implemented it. So a lot of imperative languages implement lisp functionalities.

I think someone should have to highlight the power of this fact: "in lisp data and code are practically the same thing". We need more real-world examples.

When I talk about lisp with my friend/colleagues, a lot of them ask me: "why lisp is different"? The answer is not so easy, since these guys always used imperative languages, so sometimes they do not understand the advantage of using "math-like" functions, advantage to avoid to use "the left operand" and "assignement operators", advantage to use "map" functionalities, advantage to use lists and pieces of code<->data, etc...

(this is the reason I made the question about "eval" function).
--

m i c h a e l

John McCarthy wrote in the LISP 1.5 programmer's manual that LISP differs from most programming languages in three ways:


Quote from: "John McCarthy"The first way is the data. In the LISP language, all data are in the form of symbolic expressions usually referred to as S-expressions.


Quote from: "John McCarthy"The second important part of the LISP language is the source language itself which specifies in what way the S-expressions are to be processed. This consists of recursive functions of S-expressions.


Quote from: "John McCarthy"Third, LISP can interpert and execute programs written in the form of S-expressions. Thus, like machine language, and unlike most other higher level languages, it can be used to generate programs for further execution.


m i c h a e l

ale870

Nice explanation!

Maybe the problem, in our days (John talked about Lisp on 1960) there are many languages that grabbed some functionalities of lisp self! So a new programmer (newbie) cannot "detect" all these differences. This is reason some friends of mine sometimes do not understand the "philosophy"  behind Lisp.



I think we can even add some other examples/characteristics:


QuoteIn Lisp every function returns a value. This is important, since many languages make a difference between procedures (do not return a value) and functions (return value).
.


QuoteLisp can return many values, using LIST notation (and using the concept of S-expressions). many languages still return a single value (unless they must use some tricks, like the pointers or other complex objects like HashMap, etc...).


QuoteLisp does not use the left-operand (e.g.: myVariable = 100). It means the language is more "linear", since everything appears like an homogeneous structure.


Quote Thanks to the S-Expressions, Lisp eliminates the difference between variables, functions, tokens, etc... since everything is managed as a SYMBOL. The programmer makes a formal difference between a variable, a function, etc... by assigning specific behaviors to every symbol.


QuoteLisp includes all these functionalities! Instead it is difficult to find another language that includes all of them.
--

itistoday

Fundamentally LISPs are different in that expressions are based on the list data structure, and this structure is directly accessible to the executing code. The syntax and various other features are really just extraneous stuff that people throw on top of this fact.



Other languages can interpret strings as code at runtime, but that's a wholly different matter from CODE=DATA. Other languages can do closures like Scheme and CL, but as we see with newLISP, these extraneous features aren't what make LISP unique.



It is the fact that your code is a list that's significant, and newLISP takes this quite literally. In Python, as far as I understand, you cannot chop up and manipulate code, whereas in LISP, you can. In other languages, code doesn't have access to itself, whereas in LISP, it does, and thus you have lovely capabilities like those provided by the newLISP function letex.
Get your Objective newLISP groove on.

cormullion

I wonder how many of us actually use many of these advanced features in daily work, or whether we're mostly just glad that they're there... Depends what you're using newLISP for, I suppose.



Even though i don't see myself as a 'high level' programmer, I've had mixed success. The code profiling exercise was more successful than my attempt at getting SXML lists to evaluate themselves... I never got as far as finding out why it didn't work.

ale870

I used many scripting languages in the past, but for newLisp I noticed a funny thing: usually I use script languages to make something quick (reach a result in a short amount of time), and sometimes the code becomes "dirty". This is the reason why I sometimes use script languages: I make a short procedure, quickly and dirt (but I reach the result much faster than in other languages, like C, Java, delphi, etc...).

In newLisp I start to make my script, then I start to spend a lot of time to "constrain" myself to use more "functional" concepts than classic "imperative" programming. It means I spend much time to make a script! But I'm very happy for this, since I'm starting to move my mind again, and I'm pushing myself to see a problem from different points-of-view!

So now, I make a dirty newLisp program, and I use it. Then I start to work on it to make it perfect!

I think one can reach this level of programming only if you make the programmer for passion, and not only for work. So I think only really programming-lovers can really appreciate functional languages (and newLisp). This is the reason I cannot really explain to other people why newLisp is a great language: they simply make programs, they do not "love" programs! :-)
--