> In 1960, John McCarthy published a remarkable paper in which he did for programming something like what Euclid did for geometry.
One could argue that Church's (1930s) lambda calculus, which underlies LISP, is a closer analogue to Euclid's distillation of the essence of Geometry.
With the minimal addition of pure binary IO, the lambda calculus is easily transformed into an untyped programming language [1]. On the other hand, full blown and richly typed pure functional programming languages like Haskell remain semantically faithful to their lambda calculus underpinnings.
lambda calculus was a tool, but it seems godel and turing's work on computing machines and recursive functions were more fundamental to the original lisp.
Recently had a conversation on how functional programming and declarative programming were somewhat linked, and how i observed that languages that started to go down the functional road slowly tried to add more and more capabilities for DSLs, and then slowly moved toward becoming a lisp. But that was just my feeling.
is this theorized somewhere ? Or am i just dreaming ?
(dynamic) functional programming enables very 'easy' succinct abstractions through combing out concretions and composing functions out of a general tool-set. Think code-reuse in the small.
With some discipline you naturally end up with a very data-oriented codebase, where the specificity of your application/library ends up in your data-structures.
Now these data-structures are really just plain data, without specific behavior attached to them, so they embody the (maybe almost) declarative part of your program/system. The next step would be to polish them to make them more human readable.
An additional feature of Lisps is their homoiconicity and macros. These come into play when plain data-structures are not the right fit anymore. Typically you want to handle some user/client defined behavior. You can now transform the syntax of the language itself to clean up your API to reduce boilerplate and increase readability.
McCarthy wasn’t just interested in making Lisp for AI, he was thinking about the possible applications AI, with Lisp as a platform to get to more advanced states of understanding. An example of this is in his paper “Computer Control of a Machine for Exploring Mars." Stanford Artificial Intelligence Project, Memo N. 14, June 15, 1964, Author: McCarthy, John, 1927-2011; Stanford University Library collections.
Funny to see this after all these years. I read this paper just before starting college in 2003 and it inspired me to spend most of the summer writing a rudimentary Lisp interpreter in rudimentary C++. That was my first piece of my code that actually worked, and was more than a dozen or so lines. Good memories.
I get that Lisp is popular because of its meta-programming abilities, ie its macro system. And the reasoning was that you didn’t have to wait for the language writers to implement the feature you wanted, since you could implement it yourself as a macro.
But this presented other problems, namely that you might end up coding your libraries on an island, and no one else could understand your code. This is probably why Lisp is mostly more powerful when there is only one or a few programmers working on the code base.
But with the increase in other programming languages, and the massive amounts of other libraries out there, then is this macro system really all that necessary anymore?
Clojure is a lisp that runs on top of Java, JavaScript and a couple of others and has access to all of those libraries via npm and maven
Having more libraries than most languages doesn't nullify the use of macros, macros are usually discouraged in application code because they don't compose well, don't make a macro if a function will do
However having macros meant that when go popularised CSP concurrency at the language level it meant we didn't need to change the language (for all variants of Clojure) it just meant we could make a library with macros to do CSP concurrency and it works on the browser on the server etc
Completely opt in, well documented as a library and we didn't weigh down the language with this feature, if or when the next big concurrency thing comes along we won't be looking to deprecate go channels from the language
Macros are incredibly powerful and you probably won't need them often but for those small cases of scratching a particular itch they're a get out of jail free card
I'm electronics and embedded software developer,
but I took a pause from that and founded a small web business startup with few guys two years before PG founded Viaweb. The product was very similar to PG
's Viaweb. Viaweb was more general and consumer market oriented. We had narrow focus with b2b trough our connections.
It's hard to describe how easy it was to make money in the late 90's with even little technical skill and tiniest amount of business understanding. We were making money hand over fist knowing next to nothing.
PG sold his company for $50 million, we sold ours for $5 million after we took the mountain of cash out of it (another $5 million). After reading how PG did it, I think his genius was paying $16,000 a month for a PR firm. He understood the value of PR, we didn't. http://www.paulgraham.com/submarine.html
His essays, HackerNews and Y combinator are expression of this understanding. He has created expanding self-reinforcing network of affordable PR and connections for startups. That's the real scarcity in the startup scene. Being accepted into a batch is valuable.
Instead of hiring PR firm, PR firm accepts you and stamps you with the Y Combinator brand.
Yet some of the most successful business people seem to be good at tech. I heard that half of the CEOs of the top 500 fortune companies have a STEM degree.
Often times it's a matter of just listening to customers. Even if you don't have a knack for the domain, if you get enough feedback and react to it, you can "organically" fit it well. It's sort of comparable to a genetic algorithm. Of course, having a knack for a domain could mean fewer iterations of rework.
Lisp is ideal for changing on a dime, at least for a small team.
It's not very common for anyone to be good at business. But for some reason when people are good at tech, suddenly that becomes the reason they are bad at business.
On Lisp is an advanced text about Lisp macros, not recommended as an introduction (but highly recommended if you've written Common Lisp).
SICP is great but not really about Lisp.
I recommend Norvig's PAIP [1] or Graham's ANSI Common Lisp [2].
Another book that's often recommended is Practical Common Lisp but I think it's dated and hasn't aged well. It's also nowhere near as mind expanding as PAIP/Graham's books.
SICP is not about Lisp, Scheme was chosen because of its simplicity, but the book is not about Scheme. If you always wanted to go through the book, maybe also take a look at "How to design programs." It's a bit like a SICP, but it's written in a different style, you may prefer that one instead.
- If you want something practical - do try Clojure. Don't listen to JVM haters and Lisp "purists". JVM is a pretty robust piece of tech and Clojure is a proper Lisp dialect. Besides, Clojurescript is a lot of fun.
- If you like Lua, and want to make simple, fun games try Fennel. If you're into math and enjoy playing with fractals and such, do try Racket.
- If you are serious about Lisp, sooner or later you may want to learn Common Lisp. Especially if you already using Emacs and want to improve your emacs-lisp skills.
Clojure is always the wrong option to get into the principles of Lisp.
* Clojure utilizes non-standard Lisp syntax like []{}, weird function declaration and differ semantics of some forms (like cond usage, a powerful specie of switch-case of Lisp);
* Clojure don't have cons pairs, neither car and cdr operators. Cons pairs are fundamental Data Structures to build compound data, very well explored in SICP and any LISP text book.
* Clojure has the batteries of Java, so you will own a giant ecosystem to build complex software, but the evil parts of jvm will be inherited too. For the first contact with Lisp, this can be a unnecessary pain in the ass.
I would recommend to start a LISP journey with Land of Lisp or Practical Common Lisp (PCL), both focused in Common Lisp. Land of Lisp has a lot of history about the beginning of Lisp and the author write the book in a fun way, lot of charges and xkcd-like humor. The book has a collection of game projects per chapter, one at time, teaching principles of the language. PCL it's very useful for understanding specific parts of the language, I used as complement when Land of Lisp was not sufficient (loop topic on PCL is very good).
Clojure is a better language, and a better Lisp, and a better tool for making software, but not "really" a Lisp. If you want to learn about Lisp, I think you should zero in on Scheme, Common Lisp, and Emacs Lisp. But this of course depends on what you want.
The cons cell thing is a big deal. Cons cells are a stupid language construct. But that's baked into the identity of what Lisp is.
I'd personally avoid SICP unless you have an interest in writing programming languages or solving math problems. I personally found it really boring, and couldn't get through it.
My own personal taste also leans towards Scheme (especially Chicken Scheme), so that's what I'd recommend. To me it feels more elegant, more modern, and of lighter weight than Common Lisp. I'm also kind of allergic to the JVM and Clojure's non-lispy innovations in syntax, so I'd personally avoid it too.
That said, I myself started with Common Lisp and then moved on to Scheme and then Emacs Lisp (which is a decent choice of Lisp to learn, in that, despite some shortcomings, it puts the entire Emacs ecosystem at your fingertips). Once I'd learned Common Lisp, I found learning the rest to be quite easy.
It was the first language to add "if/else" constructs, GC, closures, first class functions, reference semantics, and recursion.
It took between 5 to 40 years before these became available in mainstream languages (conditionals like if/else were adopted early, GC not so much, closures took even more). Add to that macros and the flexibility of runtime evaluation / code creation, which most mainstream languages still lack.
And of course, Lisp's rules remain (and will always be) the most succinct way to define a full blown programming language with meta-programming facilities to boot -- as opposed to a mere Turing machine like thing or assembler.
>IMO Lisp is just overrated, it lacks visual clues, reads right to left with horrible nesting etc..
This doesn't make any sense...
The nesting is the same as in almost any language.
> But fanboys on internet make it seem like some God tier thing
Lisp is based on math and logic. And if there's a God, he probably speaks Math. So, maybe those fanboys onto something here.
But, seriously, once you learn a bit of Lisp, you realize that Lisp has influenced every single modern programming language. Essentially, no matter what PL you are programming in - we are all programming in a Lisp. Sometimes your language of choice adheres to core principles of Lisp, sometimes that connection is loose. Nevertheless, there's plenty of Lisp in every modern programming language. So, no. Lisp is not overrated.
No, Lisp does not lack visual clues. But yes, very often people complain about Lisp readability. And that stems from the lack of familiarity, most people are familiar with the infix notation, but not prefix, used in Lisp. But I have seen many times, people who pick up Lisp (Clojure, Racket, etc.) as their first programming language - they do just fine, a matter of fact - they later find code written in other languages harder to read.
Unlike other languages, Lisp sometimes is difficult to read by just looking at it. Staring at Lisp code, examining its "static" properties without prior training indeed may pose a challenge. But there is a way to learn how to parse Lisp code mentally. And the best way of learning that is by editing it.
First, you need to find an IDE that supports structural editing of symbolic expressions (or s-exps). Basically, it would help if you learned a few operations:
Depending on the IDE you use, they may be called differently, and there may be more, these are the basic ones.
Once you learn those basic operations, you are now ready to untangle "unreadable" Lisp. The trick is to change the code while you read it.
Similar to how Tony Stark looks at the hologram of a model and moves his hands outward, forcing the hologram to expand, then he picks one of the parts, studies it, maybe completely removes it. He then would move his hands in a closing motion, and hologram would "assemble." That's how you work with Lisp.
So, for example, you read a function, if necessary, extract things, pick an expression, evaluate it, etc. Once you gain a good understanding of what the function does, you can undo all the changes, or if you think you have improved it - do save.
In other languages, when the structure of the code is settled, it's more challenging to pick it apart, move things in and out. You are forced to read the code "top to bottom." But in Lisp, code is a living, breathing thing. You basically feel like performing a surgery - you can tweak things, try them, and see instantaneous feedback in the REPL.
In other languages, code is "dead," until you save it, (re)compile it and execute it. And REPL in those languages is "crippled" and not a fully-fledged "true" REPL like in Lisp. Being able to pick any [sub]expression and evaluate it, without any kind of prior ceremony is truly liberating and empowering.
It takes time, for some it's hours, for others - weeks, but eventually you will stop seeing parentheses, and instead, you will see structure, consistency, and meaning. And Lisp becomes more readable than any other language you've used before.
[+] [-] tromp|6 years ago|reply
One could argue that Church's (1930s) lambda calculus, which underlies LISP, is a closer analogue to Euclid's distillation of the essence of Geometry.
With the minimal addition of pure binary IO, the lambda calculus is easily transformed into an untyped programming language [1]. On the other hand, full blown and richly typed pure functional programming languages like Haskell remain semantically faithful to their lambda calculus underpinnings.
[1] https://tromp.github.io/cl/Binary_lambda_calculus.html
[+] [-] lisper|6 years ago|reply
http://www.flownet.com/ron/lambda-calculus.html
[EDIT] Heh, I just realized that we corresponded on this back when I wrote it in 2014! Small world.
[+] [-] nikofeyn|6 years ago|reply
certainly lambda calculus was used to define functions in lisp, as seen in the original lisp paper (or the most famous one).
http://jmc.stanford.edu/articles/recursive.html
lambda calculus was a tool, but it seems godel and turing's work on computing machines and recursive functions were more fundamental to the original lisp.
[+] [-] bsaul|6 years ago|reply
is this theorized somewhere ? Or am i just dreaming ?
[+] [-] dgb23|6 years ago|reply
(dynamic) functional programming enables very 'easy' succinct abstractions through combing out concretions and composing functions out of a general tool-set. Think code-reuse in the small.
With some discipline you naturally end up with a very data-oriented codebase, where the specificity of your application/library ends up in your data-structures.
Now these data-structures are really just plain data, without specific behavior attached to them, so they embody the (maybe almost) declarative part of your program/system. The next step would be to polish them to make them more human readable.
An additional feature of Lisps is their homoiconicity and macros. These come into play when plain data-structures are not the right fit anymore. Typically you want to handle some user/client defined behavior. You can now transform the syntax of the language itself to clean up your API to reduce boilerplate and increase readability.
In a sense you have now programmed your own DSL.
[+] [-] try_again|6 years ago|reply
[+] [-] deepaksurti|6 years ago|reply
[1] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
[+] [-] TruffleLabs|6 years ago|reply
https://stacks.stanford.edu/file/druid:qh147kq8662/SC1041_SA...
[+] [-] yters|6 years ago|reply
(func var0 var1 ... varn)
Could it be that the design of LISP is inspired by the structure of the genetic code?
[+] [-] abhiyerra|6 years ago|reply
[+] [-] ctkrohn|6 years ago|reply
[+] [-] blackrock|6 years ago|reply
But this presented other problems, namely that you might end up coding your libraries on an island, and no one else could understand your code. This is probably why Lisp is mostly more powerful when there is only one or a few programmers working on the code base.
But with the increase in other programming languages, and the massive amounts of other libraries out there, then is this macro system really all that necessary anymore?
[+] [-] slifin|6 years ago|reply
Having more libraries than most languages doesn't nullify the use of macros, macros are usually discouraged in application code because they don't compose well, don't make a macro if a function will do
However having macros meant that when go popularised CSP concurrency at the language level it meant we didn't need to change the language (for all variants of Clojure) it just meant we could make a library with macros to do CSP concurrency and it works on the browser on the server etc
Completely opt in, well documented as a library and we didn't weigh down the language with this feature, if or when the next big concurrency thing comes along we won't be looking to deprecate go channels from the language
Macros are incredibly powerful and you probably won't need them often but for those small cases of scratching a particular itch they're a get out of jail free card
[+] [-] coder1001|6 years ago|reply
To me it is not very common for (very) technical people to be good at both tech and business!
[+] [-] Nokinside|6 years ago|reply
It's hard to describe how easy it was to make money in the late 90's with even little technical skill and tiniest amount of business understanding. We were making money hand over fist knowing next to nothing.
PG sold his company for $50 million, we sold ours for $5 million after we took the mountain of cash out of it (another $5 million). After reading how PG did it, I think his genius was paying $16,000 a month for a PR firm. He understood the value of PR, we didn't. http://www.paulgraham.com/submarine.html
His essays, HackerNews and Y combinator are expression of this understanding. He has created expanding self-reinforcing network of affordable PR and connections for startups. That's the real scarcity in the startup scene. Being accepted into a batch is valuable. Instead of hiring PR firm, PR firm accepts you and stamps you with the Y Combinator brand.
[+] [-] coldtea|6 years ago|reply
Bill Joy co-founded SUN - but also wrote ex, vi, the BSD UNIX tcp/ip stack, and other things.
Marc Andreessen wrote Mosaic and Netscape - and is a famous VC person now (of Andreessen Horowitz fame).
Bill Gates, also very technical (wrote early MS programs, BASIC interpreters etc).
Eric Schmidt (ex Google CEO) wrote Lex (the lexer, now more known by its GNU port, flex) and was SUN's first programmer.
[+] [-] fouc|6 years ago|reply
[+] [-] tabtab|6 years ago|reply
Lisp is ideal for changing on a dime, at least for a small team.
[+] [-] LanceH|6 years ago|reply
[+] [-] jammygit|6 years ago|reply
Or is it better to just go straight to Clojure these days?
[+] [-] armitron|6 years ago|reply
SICP is great but not really about Lisp.
I recommend Norvig's PAIP [1] or Graham's ANSI Common Lisp [2].
Another book that's often recommended is Practical Common Lisp but I think it's dated and hasn't aged well. It's also nowhere near as mind expanding as PAIP/Graham's books.
[1] https://github.com/norvig/paip-lisp
[2] PDFs can be found on Google
Clojure is not recommended as it is very different to Lisp.
Lisp code needs to be entirely rewritten before it will run on Clojure. That is not true for Common Lisp, Emacs Lisp and even Scheme.
[+] [-] iLemming|6 years ago|reply
- If you want something practical - do try Clojure. Don't listen to JVM haters and Lisp "purists". JVM is a pretty robust piece of tech and Clojure is a proper Lisp dialect. Besides, Clojurescript is a lot of fun.
- If you like Lua, and want to make simple, fun games try Fennel. If you're into math and enjoy playing with fractals and such, do try Racket.
- If you are serious about Lisp, sooner or later you may want to learn Common Lisp. Especially if you already using Emacs and want to improve your emacs-lisp skills.
[+] [-] lerax|6 years ago|reply
* Clojure utilizes non-standard Lisp syntax like []{}, weird function declaration and differ semantics of some forms (like cond usage, a powerful specie of switch-case of Lisp);
* Clojure don't have cons pairs, neither car and cdr operators. Cons pairs are fundamental Data Structures to build compound data, very well explored in SICP and any LISP text book.
* Clojure has the batteries of Java, so you will own a giant ecosystem to build complex software, but the evil parts of jvm will be inherited too. For the first contact with Lisp, this can be a unnecessary pain in the ass.
I would recommend to start a LISP journey with Land of Lisp or Practical Common Lisp (PCL), both focused in Common Lisp. Land of Lisp has a lot of history about the beginning of Lisp and the author write the book in a fun way, lot of charges and xkcd-like humor. The book has a collection of game projects per chapter, one at time, teaching principles of the language. PCL it's very useful for understanding specific parts of the language, I used as complement when Land of Lisp was not sufficient (loop topic on PCL is very good).
[+] [-] SamReidHughes|6 years ago|reply
The cons cell thing is a big deal. Cons cells are a stupid language construct. But that's baked into the identity of what Lisp is.
[+] [-] pmoriarty|6 years ago|reply
My own personal taste also leans towards Scheme (especially Chicken Scheme), so that's what I'd recommend. To me it feels more elegant, more modern, and of lighter weight than Common Lisp. I'm also kind of allergic to the JVM and Clojure's non-lispy innovations in syntax, so I'd personally avoid it too.
That said, I myself started with Common Lisp and then moved on to Scheme and then Emacs Lisp (which is a decent choice of Lisp to learn, in that, despite some shortcomings, it puts the entire Emacs ecosystem at your fingertips). Once I'd learned Common Lisp, I found learning the rest to be quite easy.
[+] [-] terminaljunkid|6 years ago|reply
Sure it has some good concepts. But fanboys on internet make it seem like some God tier thing.
[+] [-] coldtea|6 years ago|reply
It was the first language to add "if/else" constructs, GC, closures, first class functions, reference semantics, and recursion.
It took between 5 to 40 years before these became available in mainstream languages (conditionals like if/else were adopted early, GC not so much, closures took even more). Add to that macros and the flexibility of runtime evaluation / code creation, which most mainstream languages still lack.
And of course, Lisp's rules remain (and will always be) the most succinct way to define a full blown programming language with meta-programming facilities to boot -- as opposed to a mere Turing machine like thing or assembler.
>IMO Lisp is just overrated, it lacks visual clues, reads right to left with horrible nesting etc..
This doesn't make any sense...
The nesting is the same as in almost any language.
"reads right to left" - huh?
You know that Lisp code can be indented right?
[+] [-] iLemming|6 years ago|reply
Lisp is based on math and logic. And if there's a God, he probably speaks Math. So, maybe those fanboys onto something here.
But, seriously, once you learn a bit of Lisp, you realize that Lisp has influenced every single modern programming language. Essentially, no matter what PL you are programming in - we are all programming in a Lisp. Sometimes your language of choice adheres to core principles of Lisp, sometimes that connection is loose. Nevertheless, there's plenty of Lisp in every modern programming language. So, no. Lisp is not overrated.
[+] [-] iLemming|6 years ago|reply
Unlike other languages, Lisp sometimes is difficult to read by just looking at it. Staring at Lisp code, examining its "static" properties without prior training indeed may pose a challenge. But there is a way to learn how to parse Lisp code mentally. And the best way of learning that is by editing it.
First, you need to find an IDE that supports structural editing of symbolic expressions (or s-exps). Basically, it would help if you learned a few operations:
slurp, barf, transpose, raise, kill s-exp, yank s-exp
Depending on the IDE you use, they may be called differently, and there may be more, these are the basic ones.
Once you learn those basic operations, you are now ready to untangle "unreadable" Lisp. The trick is to change the code while you read it.
Similar to how Tony Stark looks at the hologram of a model and moves his hands outward, forcing the hologram to expand, then he picks one of the parts, studies it, maybe completely removes it. He then would move his hands in a closing motion, and hologram would "assemble." That's how you work with Lisp.
So, for example, you read a function, if necessary, extract things, pick an expression, evaluate it, etc. Once you gain a good understanding of what the function does, you can undo all the changes, or if you think you have improved it - do save.
In other languages, when the structure of the code is settled, it's more challenging to pick it apart, move things in and out. You are forced to read the code "top to bottom." But in Lisp, code is a living, breathing thing. You basically feel like performing a surgery - you can tweak things, try them, and see instantaneous feedback in the REPL.
In other languages, code is "dead," until you save it, (re)compile it and execute it. And REPL in those languages is "crippled" and not a fully-fledged "true" REPL like in Lisp. Being able to pick any [sub]expression and evaluate it, without any kind of prior ceremony is truly liberating and empowering.
It takes time, for some it's hours, for others - weeks, but eventually you will stop seeing parentheses, and instead, you will see structure, consistency, and meaning. And Lisp becomes more readable than any other language you've used before.