I get emacs, but WOW... the LISP learning curve ... and WHY LISP?

[eti]

(Attached photo)
Literally how I’ve felt, and still a little now.

I get the beauty and endless flexibility of emacs, but as regards LISP, since I've barely scratched the surface of the surface, I still don't "get" why it is so amazing, or why I should use it; they say "It makes you a better programmer". Is it one of those things which will suddenly "click" one day? I am not sure I want to sink a whole swathe of my time into something, just because it teaches me better ways, if the process is one of utter frustration. If someone could articulate this well (and in a newcomer sense - make ZERO assumptions please!) - what is it about LISP that is "better"? I don't mind the parens, but they do make code legibility a nightmare (as the old memes show).

With C, C++, Python etc, I can clearly discern different code blocks; in LISP, it kinda all looks the same! What's with the single quote, (the-hyphenated-functions-and-whatever-this-is-P) and all that? If you'd explain in a brief way so I can be encouraged, because a few people have told me "It's amazing", but the "why" is sinking in VERRRRRRRRY slowly!

Also, how does one compile/port/USE LISP? As far as I see, it's only used inside a REPL or inside emacs - how does it escape those bubbles and get USED.. compiled... please be gentle, I am new to all this, and the wrong approach might put me off for life 

Thanks ever so much!

[eti]

^ (setq post-updated-for-clearer-intention #unclear) ^

[sokoloff]

Emacs lisp is a somewhat gimped lisp, mostly useful for extending and configuring emacs.

The power of lisp's homoiconic nature is that you can operate on code as data (rather than on the string representation of code). This makes extending the language to fit your problem space more possible because you have the power of the language available in the language itself. You can write extensions to the language that feel and behave like the native parts of the language.

Separately, there's value in pure functional approach for some problems (lisp supports, but does not enforce, a functional style if you want to use it).

As for how to "escape" emacs and run lisp programs standalone, I'd recommend either:
Common Lisp (and a common lisp compiler, several free ones are available) -or-
clojure, which is in the lisp family of languages, but isn't common lisp. The major advantage of clojure is that it runs on the jvm, giving you easy access to tons of Java libs and functionality and a closely related language, clojurescript [cljs] compiles down to javascript, given you access to that ecosystem and the web.

emacs lisp should stay inside of emacs, IMO.

[ledtester]

Why LISP? From Wikipedia...

* John McCarthy developed Lisp in 1958 while he was at the Massachusetts Institute of Technology (MIT). ...

* Emacs development began during the 1970s at the MIT AI Lab...

Indeed, up until 2009 or so the introductory course in computer programming at MIT used Scheme, a variant of LISP, in the famed textbook _Structure and Interpretation of Computer Programs_.

The other reason is that it is relatively simple to implement a LISP interpreter.

If you really want to go down the rabbit hole, I can recommend:

http://landoflisp.com/

(follow the arrows)

[eti]

Dear both, above, thank you for your replies. I am currently in possession of a copy of "Land of LISP", and its amusing comical drawings. I am getting there, but I am still as confused as a fish on stilts; oops! Many thank you's!

[sokoloff]

Don't feel bad if you don't grasp lisp immediately. I "bounced off it" several times over the last decades, staying at the "matching patterns while configuring emacs" level, while understanding almost none of what was happening under the covers.

F# (ML-based, not a lisp) and Haskell (also not a lisp) exercises got me part of the way to understanding some of the functional fundamentals, then clojure and clojurescript got me to the point where I could do productive exercises and I used it to solve Advent of Code 2021. (I pick a different language each year for those exercises, though I've repeated javascript in two years).

If you're at the place where I think you are, I'd try a mix of approaches:
1. A modern lisp book with exercises (and really slow down your pace of reading the text; maybe 30 minutes of reading per day max, followed by some time doing the exercises, but don't try to crush the book like it's a fictional novel)
2. Solving lisp koans: https://github.com/google/lisp-koans

then, if you can get yourself comfortable with the basics of the language, consider doing a prior year or current year Advent of Code. (The first half or so of AoC tends to be quite a bit easier than the later days.)

[newbrain]

I struggled a bit with emacs-lisp more than 30 years ago, to automatically generate FORTRAN77 FORMAT and PRINT statements for tabular data output of a simulator.
Lisp is definitely not for me. I understood it and wrote it, but was it pleasant? I don't think so.

In fact, when I implemented my emacs clone in x86 assembler, I added a Forth compiler (native, not threaded), not a Lisp interpreter.

We even had, at the time, an expert system of sorts, written in Lisp - never had the bravery to confront its code, I stayed on FORTRAN77, and then C.

[SiliconWizard]

LISP was once the Python of scripting languages for embedding scripting capabilities into programs. emacs was certainly not the only application with an embedded LISP.

Now it's Python everywhere.

While I never liked LISP much either, it was at least simple, lightweight and consistent.

Not sure why you would inflict this pain on yourself these days though - except for learning purposes, which is always good - there are much better functional programming languages out there, if functional is your thing.

[eti]

I find it a VERY oddball, strange language (bear in mind I know little of its workings, but knew about it back in 2005 when I was binging Richard Stallman lectures and buying Linux magazines; having heard RMS evangelise emacs SO much, it put it in my subconscious "You must discover more... one day"

It's like going into the kitchen to make everyone a coffee; 4/5 people just want ordinary coffee, instant coffee, but that one exception wants freshly imported, freshly roasted SPECIALITY beans, and then wants you to grind it a certain way, over a precise time, and brew it at a VERY crucial temp. Yes, it can be done, but I think maybe going along with what the industry uses most, is more prudent. However, I am all about learning... but my interest in LISP has peaked and troughed 2-3 times now, and I am not sure I can "do" anything with this, IF I learn it.

I read a snippet about why CAR & CDR were named, and then shortly after, they tried to rename them more sensibly, but it was too late; people had adopted them too deeply. My reasoning is, if the people in charge of LISP made such GLARINGLY poor naming decisions, what else did they screw up - "NIL" and "T" - REALLY? What's that about? "T" and "F" make more sense, surely?

I can program arduinos, I can do BASH in my sleep, I can do Python (stil learning) but LISP... I see no defined purpose for, apart from "just because", and I am unsure if it's worth a time investment.

[sokoloff]

I read a snippet about why CAR & CDR were named, and then shortly after, they tried to rename them more sensibly, but it was too late; people had adopted them too deeply. My reasoning is, if the people in charge of LISP made such GLARINGLY poor naming decisions, what else did they screw up -

Common Lisp supports first and rest as alternate names for car and cdr, respectively.
One of the beautiful aspects of lisp is it's usually easy to inspect the environment. The first function in SBCL is defined in list.lisp (as describe will tell you). That source is:

Code: [Select]

(defun first (list)
  "Return the 1st object in a list or NIL if the list is empty."
  (car list))
I think car and cdr "won" because of their composability. Want to get the car of the cdr? There's a function for that: cadr. Want to get the car of the cdr of the cdr? caddr. That's a lot nicer than writing (first (rest (rest foo))). The choices of a language community often reflect the experience of the experienced practitioners over the experience of the students of the language. Arguably, the ternary operator in C is difficult to understand (and several modern languages omit it, including golang). Yet, it's incredibly useful for C programmers.

"NIL" and "T" - REALLY? What's that about? "T" and "F" make more sense, surely?

I find it more helpful to think of False and True being: nil and "everything, except nil"
 
Here again, I'm not trying to apologize for the lisp language designers (I just think they got it right from the worldview of LISt Processing).

It's common to loop over a list until you get to the end of the list. What's another way to talk about the part of the list you haven't processed? rest (or cdr). When do you have no more items in the list? When the rest of the list is empty. If we call that empty list nil and treat it as the only false-y value, the language feels slightly more comfortable and elegant [rather than having to write (not (eq foo '())), we can just write foo].

I can program arduinos, I can do BASH in my sleep, I can do Python (stil learning) but LISP... I see no defined purpose for, apart from "just because", and I am unsure if it's worth a time investment.

It's probably not monetarily useful. It's probably not going to let you solve a programming problem that you couldn't otherwise solve. I found it immensely pleasurable to climb the learning curve, and I believe it's made me a better programmer overall, though I've never shipped a single line of common lisp any farther than my own machines.

[eti]

@sokoloff Thank you for the reply

Yeah, aside from it being an academic exercise of sorts, I see it a little like going for a walk, just for the sake of doing so, or, as a friend used to say "Do a puzzle, if you want to exercise your brain" - I didn't see much point; if I want a puzzle, I could at least learn a transferable skill (programming), whereas slotting together a perfectly nice picture that's been chopped up... why? No thanks 

I get this constant nagging sense in my mind "where is this leading you?" and the answer is "not very far", in the context of it being a transferable skill. But, nevertheless, it's still fun!

[westfw]

Emacs development began during the 1970s at the MIT AI Lab...

However, the original EMACS extension language was TECO.  (MIT-extended TECO, at that.  Which in turn was written in PDP-10 assembly language.)

The current C EMACS was developed at a time when LISP was "hot" - multiple start-ups were building "LISP Machines" and standardizing/writing "Common LISP."  Python and Java didn't exist, C wasn't particularly popular yet, and computers were relatively slow.  Be thankful that the extension language didn't end up being Pascal-like.
(Although the first C EMACS was from Gosling while he was at CMU.)

I sort-of liked TECO.  Very easy to type tiny-but-useful "programs" in the minibuffer.

Code: [Select]

<.-j;l1a-13"Ek$>$$

[brucehoult]

Code: [Select]

(setq 'mary-had-a-little-lamb-p))))


Ummm ... it's really not that hard!  Kids these days seem to learn JavaScript in their sleep, and that's basically identical to Lisp.

A few things wrong with your code:

- unbalanced parens, obviously. wtf?

- set and setq need two arguments, not one. What are you trying to set the variable to? mary-had-a-little-lamb-p = ?? The fact you ended the name with -p suggests that it should be true or false, i.e. t or nil.

- you need either (setq the-answer 42) or (set `the-answer 42). If you use "set quote" then you don't quote the name yourself!

Why quote?

Because:

Code: [Select]

(set `foo `bar)
(set foo 42)

If you now print (or insert into your document, or show a dialog) bar then you'll get 42. Or if you print foo then you'll get "bar".
 

[eti]

Code: [Select]

(setq 'mary-had-a-little-lamb-p))))


Ummm ... it's really not that hard!  Kids these days seem to learn JavaScript in their sleep, and that's basically identical to Lisp.

A few things wrong with your code:

- unbalanced parens, obviously. wtf?

- set and setq need two arguments, not one. What are you trying to set the variable to? mary-had-a-little-lamb-p = ?? The fact you ended the name with -p suggests that it should be true or false, i.e. t or nil.

- you need either (setq the-answer 42) or (set `the-answer 42). If you use "set quote" then you don't quote the name yourself!

Why quote?

Because:

Code: [Select]

(set `foo `bar)
(set foo 42)

If you now print (or insert into your document, or show a dialog) bar then you'll get 42. Or if you print foo then you'll get "bar".

My “code”, lol,  was a parody of my knowing almost nothing about lisp. 😁

You mention unbalanced parentheses, but you must understand that is how an unseasoned newcomer sees lisp, and also what it is famed for.

I greatly appreciate your help, once my TV program has finished I’ll give that a go. God bless you

[radar_macgyver]

A colleague used a Scheme interpreter to create a domain-specific language to define radar timing parameters (trigger transmitter here, enable data acquisition here, turn on noise sampling after x nanoseconds, etc). Elegant, but making any changes is an exercise in frustration since nobody can remember the syntax. We have three Scheme source files (for three operating modes) that nobody dares touch, except to modify constants.

[eti]

A colleague used a Scheme interpreter to create a domain-specific language to define radar timing parameters (trigger transmitter here, enable data acquisition here, turn on noise sampling after x nanoseconds, etc). Elegant, but making any changes is an exercise in frustration since nobody can remember the syntax. We have three Scheme source files (for three operating modes) that nobody dares touch, except to modify constants.

I concur. That’s more truth than comedy.

[tggzzz]

However, the original EMACS extension language was TECO.  (MIT-extended TECO, at that.  Which in turn was written in PDP-10 assembly language.)

I'm sure you remember why two of the most basic LISP functions are still CAR and CDR

[jfiresto]

A colleague used a Scheme interpreter to create a domain-specific language to define radar timing parameters (trigger transmitter here, enable data acquisition here, turn on noise sampling after x nanoseconds, etc). Elegant, but making any changes is an exercise in frustration since nobody can remember the syntax....

That is a pity, because a good DSL can really prune the code and let you concentrate on the problem. I would be curious what a typical parameter file looks like. I favor nearly "internal" DSLs because otherwise I would forget the syntax.

[brucehoult]

You mention unbalanced parentheses, but you must understand that is how an unseasoned newcomer sees lisp, and also what it is famed for.

No one forces you to write more than one closing paren on a line. It's just a convention to do that to save screen space and indicate the nesting visually using indentation. It's like something between C and Python, except that you CAN count the parens, and that includes tools. You can write your Lisp all in one line (and it works written that way, unlike Python) and then use a pretty-print function to format it nicely on multiple lines with indentation (which, again, you can't do with Python).

Lisp has about the same number of parens as C has ({[]}), it's just that in Lisp they are traditionally all () and the function/macro name is inside them not outside.

[brucehoult]

A colleague used a Scheme interpreter to create a domain-specific language to define radar timing parameters (trigger transmitter here, enable data acquisition here, turn on noise sampling after x nanoseconds, etc). Elegant, but making any changes is an exercise in frustration since nobody can remember the syntax. We have three Scheme source files (for three operating modes) that nobody dares touch, except to modify constants.

That is a little bit silly, because the whole point of Lisp syntax is that it is so simple and consistent there is almost nothing to learn or remember!

[brucehoult]

However, the original EMACS extension language was TECO.  (MIT-extended TECO, at that.  Which in turn was written in PDP-10 assembly language.)

I'm sure you remember why two of the most basic LISP functions are still CAR and CDR

"Basic" in an academic sense, maybe, but I would very rarely write Lisp code that uses them.

If you're writing code that uses CAR and CDR to recursively walk through a list then you could have been using MAPCAR instead for 60 years, or (loop for elt in my-list ...) for 40 years.

[bpiphany]

The first thing you learn in emacs, during your first introductory university CS course, which of course is given in LISP, using the above mentioned Structure and Interpretation of Computer Programs

Code: [Select]

M-x show-paren-mode

[sokoloff]

A colleague used a Scheme interpreter to create a domain-specific language to define radar timing parameters (trigger transmitter here, enable data acquisition here, turn on noise sampling after x nanoseconds, etc). Elegant, but making any changes is an exercise in frustration since nobody can remember the syntax. We have three Scheme source files (for three operating modes) that nobody dares touch, except to modify constants.

That is a little bit silly, because the whole point of Lisp syntax is that it is so simple and consistent there is almost nothing to learn or remember!

For that exact reason, I read the problem as remembering the syntax of the DSL, not the syntax of Scheme itself.

[tggzzz]

A colleague used a Scheme interpreter to create a domain-specific language to define radar timing parameters (trigger transmitter here, enable data acquisition here, turn on noise sampling after x nanoseconds, etc). Elegant, but making any changes is an exercise in frustration since nobody can remember the syntax....

That is a pity, because a good DSL can really prune the code and let you concentrate on the problem. I would be curious what a typical parameter file looks like. I favor nearly "internal" DSLs because otherwise I would forget the syntax.

There are far more awful Domain Specific Languages than good DSLs. Almost always they start out small, but then grow like a cancer until nobody, including the designer, understands all the syntax and semantics. Then add the difficulty of recruiting staff that are prepared to work on non-transferrable skills and then training them, and the absence of tool support for comprehending and debugging the code.

Before proposing a DSLanguage, it is necessary to accurately define its advantages over a DSLibrary. The DSLibrary doesn't require special tools; all the existing IDEs etc can be used. Staff knowing a tandard language can be (more) easily recruited and they only have to be trained in your library, not a whole language.

[brucehoult]

A colleague used a Scheme interpreter to create a domain-specific language to define radar timing parameters (trigger transmitter here, enable data acquisition here, turn on noise sampling after x nanoseconds, etc). Elegant, but making any changes is an exercise in frustration since nobody can remember the syntax....

That is a pity, because a good DSL can really prune the code and let you concentrate on the problem. I would be curious what a typical parameter file looks like. I favor nearly "internal" DSLs because otherwise I would forget the syntax.

There are far more awful Domain Specific Languages than good DSLs. Almost always they start out small, but then grow like a cancer until nobody, including the designer, understands all the syntax and semantics. Then add the difficulty of recruiting staff that are prepared to work on non-transferrable skills and then training them, and the absence of tool support for comprehending and debugging the code.

Before proposing a DSLanguage, it is necessary to accurately define its advantages over a DSLibrary. The DSLibrary doesn't require special tools; all the existing IDEs etc can be used. Staff knowing a tandard language can be (more) easily recruited and they only have to be trained in your library, not a whole language.

Given the flexibility of modern languages with classes, function calls with parameterizable types, positional arguments, keyword arguments, ability to define and pass in closures etc I have trouble seeing any practical difference in a DSL and a library as far as ease of learning goes. A DSL can be easier to *use*. Or it can be awful, if designed badly. Libraries can be designed badly too. So can functions.

With great power comes great responsibility.