[HN Gopher] Tutorial Series to learn Common Lisp quickly
___________________________________________________________________
Tutorial Series to learn Common Lisp quickly
Author : oumua_don17
Score : 227 points
Date : 2022-04-27 11:48 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| [deleted]
| xaxaxb wrote:
| Racket is another dialect of lisp.
| greymalik wrote:
| This is a true statement.
| solarmist wrote:
| Rabbibotton has created the CLOG framework and it is fantastic.
| It supports a full desktop gui experiences over websockets all
| the way down to static webpages and any combination in between
| that you could want.
|
| It's really impressive work. I guess it's a reimplementation of a
| framework he wrote in ADA years ago, so it's really well
| developed and thought through.
| usgroup wrote:
| Feels appropriate to say that Hylang is in version 1.0 alpha:
|
| https://github.com/hylang/hy/releases/tag/1.0a4
|
| That's Lisp over Python -- you can do data science properly in
| Lisp now using all you favourite Python packages.
|
| I repeat you can do data science properly in Lisp now.
| Keyframe wrote:
| zqkamp wrote:
| Well, Mathematica is lispy, and there is:
|
| https://www.wolfram.com/data-science-platform/
|
| I suppose Hylang is quite slow (and possibly has leaky
| abstractions). Ideally the main C/C++ libraries like libtorch
| should be wrapped in Common Lisp and not Python.
| mark_l_watson wrote:
| You have a few options for this: The TH package wraps Blas,
| etc., and has MINST, GAN, etc. examples.
|
| My preference is using py4cl to use pre-trained TensorFlow
| models in Common Lisp.
|
| I wrote a short book on Hy that has some deep learning
| examples, but I don't use Hy that often any longer. I am
| looking forward to the 1.0 changes.
| V1ndaar wrote:
| Maybe things have changed over the years. I've played around
| with Hy in 2017 and in the end felt like it combines the bad
| parts of Python with the bad parts of a Lisp.
|
| If you're forced to use Python it's usually because of one of 2
| reasons: Either you need to work with colleagues on something
| (in which case almost certainly they wouldn't accept a
| lispified version of it) or because you need some of the
| libraries that are already implemented.
|
| In the latter case, you might say Hy is a good option. But why
| bind yourself to the slowness of Python when you could just as
| well use some fast Lisp (e.g. Common Lisp) that interacts with
| a Python interpreter similar to nimpy [0] from Nim? Not sure if
| such a thing already exists for CL, but it should be quite
| feasible to write and then you get access to all your Python
| library needs while actually using a better language for the
| rest of your code.
|
| But I'm all ears on the real advantages Hy provides aside from
| being neat.
|
| [0]: https://github.com/yglukhov/nimpy
| medo-bear wrote:
| > Not sure if such a thing already exists for CL
|
| couple of solutions exist for this
|
| https://github.com/bendudson/py4cl
|
| https://github.com/pinterface/burgled-batteries
| portroyal wrote:
| Shining light on another; https://github.com/lem-
| project/async-process
| rich_sasha wrote:
| For me the sad thing was that there is no equivalent of let,
| progn and so on. It really felt like Python with a funny
| syntax (plus macros).
|
| I'm not lisp enough to make a macro, but supposedly, isn't
| let under the hood making a lambda function and calling it?
| That's within the confines of possibility in Python.
| medo-bear wrote:
| the point of the tutorial is to give you enough knowledge of
| common lisp in order to use the author's clog gui-web-framework,
| which btw is pretty neat
| latenightcoding wrote:
| Practical Common Lisp gets you up to speed very fast.
|
| I wish there was something similar for scheme. Most scheme books
| focus on teaching you compsci with the language and not on
| teaching you how to build practical things with it.
|
| It's quite hard to onboard someone to a scheme codebase, despite
| scheme's reputation of being a simple language.
| leobg wrote:
| ,,The Little Schemer"?
| wk_end wrote:
| The Little Schemer is a great book but it's in no way
| practical and very much focuses on teaching you comp sci -
| it's been a while but IIRC doesn't it culminate in
| constructing the Y combinator?
|
| Realm of Racket [0] seems like it might be more OP's speed.
|
| [0] https://www.amazon.ca/Realm-Racket-Learn-Program-
| Game/dp/159...
| vivab0rg wrote:
| Upvote for a Practical Scheme book.
| solarmist wrote:
| He links to that near the top
| nekomorphism wrote:
| Rabbibotton is really motivated and putting in a lot of effort
| with CLOG and with these tutorials. I think he's even offering
| monetary rewards for others to write tutorials. Its nice to see
| his efforts make it to the front page here. :)
| solarmist wrote:
| I agree. And he's putting tons of work and evangelism into his
| CLOG framework. It's pretty fantastic.
| rayiner wrote:
| Great to see a chapter on LOOP:
| https://docs.google.com/document/u/0/d/1L9jdKE-XrCU0VhdsmO5w...
|
| If you're unfamiliar with Common Lisp, it's important to
| understand that it's a multi-paradigm language. The presence of
| closures, key functions in the standard library, and the syntax
| often push you naturally to a functional solution. But you
| shouldn't feel bad about writing a LOOP that mutates a bunch of
| state under the hood. This isn't scheme!
| eadmund wrote:
| > But you should feel bad about writing a LOOP that mutates a
| bunch of state under the hood.
|
| I think you omitted a word there: one should _not_ feel badly
| about writing a state-mutating LOOP. That 's okay, and often
| the best solution to a problem.
|
| Heck, I wrote a state-mutating TAGBODY just yesterday ...
| rayiner wrote:
| Thanks! TAGBODY is another non-Schemish part of Common Lisp
| that has its uses.
| taude wrote:
| What are people using LISP for? Other than the Emacs flavor, and
| some companies using Clojure, I'm not really sure what I'd use it
| for? Would I use it to replace Python or Shell scripting for my
| custom CLI tooling? Anyway, I've seen a lot of people talking
| about the Lisps lately, and trying to figure out what I'm
| missing.
| llanowarelves wrote:
| You can use Guile Scheme for using Guix so you get a more
| transferrable language for your reproducible OS/package manager
| instead of Nix/Nix Language.
| vindarel wrote:
| Some companies: https://github.com/azzamsa/awesome-lisp-
| companies/ An interview: https://lisp-
| journey.gitlab.io/blog/lisp-interview-kina/
|
| Hint: all Quantum computing companies, Google for ITA Software,
| the NASA for James-Webb's planning and scheduling system,
| smaller companies (Kina), solo devs that find they are more
| productive than in Python (like myself).
| mikelevins wrote:
| I've used it for a lot of stuff over the years: a constraint-
| based GUI framework, a knowledge-based automated testing system
| that ran tests remotely on fleets of target machines, a model-
| building-by-demonstration system for the aforementioned testing
| system, an experimental operating system for Apple hardware, a
| direct-manipulation rapid-application-development system, a
| WYSIWIG programmable word processor, an artificial life
| simulator, a help and online-documentation compiler, a
| commercial graph database, a full-stack embedded control system
| with GUI for a forensic fingerprint-scanning machine, a syntax-
| aware diff program for code, a series of name and vocabulary
| generators for use in fiction and games, a list manager,
| several versions of a Lisp interpreter and compiler, a file-
| browsing program, several games, a knowledge-based machine-
| control program for laser-sintering machines, an anomaly-
| discovery system for various kinds of data, and a radar image
| analysis and classification system.
|
| Plus a whole bunch of supporting libraries, tools, and random
| toys.
|
| I've used it in preference to anything else since 1988. Lisp is
| an exotic niche option in the programming language space, so a
| Lisper needs to be prepared to work in other languages, and I
| often have. I've been fortunate, though, in that I've been able
| to work mainly in Lisp for more than half my career since 1988.
| I use it every day in my current job (working on the radar
| stuff and some other projects at the same employer).
| roenxi wrote:
| Good to see, but at this point in its lifecycle I don't really
| believe a lack of good tutorials is a barrier or even impediment
| for CL.
|
| The problem is after the tutorial is done, all the libraries
| (look (like (this))) and the language is so powerful it is
| difficult to know if this 10kb contains a life-changing insight
| into the nature of programming or a half-hearted implementation
| of half of something that was a bad idea to start with. Knowing
| the syntax and technical semantics of the language doesn't help
| with that.
|
| The topic has been done to death, but the lisps seem to have a
| social organisation problem that the community never quite
| managed to get a grip on.
| dunefox wrote:
| The problem with Java is after the Tutorial tutorial = new
| Tutorial() is done, all the public static void libraries
| look(like<this>) {
| trenchgun wrote:
| That is why everybody hates Java.
| outworlder wrote:
| > all the libraries (look (like (this))
|
| Right. Some people prefer them to (asd) look(int a, bool b,
| char *c,int[] d) { &like->this;};
| agentultra wrote:
| Ooo! The cache-miss operator. Sweet.
| agentultra wrote:
| Glad to see this old horse is still being pulled out and beaten
| every now and then.
|
| I think this is the worst part of learning to program in CL:
| the self-flagellating, cynical CL users and the haters that
| parrot this old, barnacle-ridden trope: it's too powerful!
| Macros! Nobody can understand it but gods and strange people on
| the Internet! You will have to listen to these people
| constantly invade every forum, discussion group, and chat room
| on the Internet to tell you how you shouldn't be learning CL.
|
| I like powerful languages. They have neat ideas. If they help
| you get more done in less time with less code, great. Not every
| software project needs to be a tedious, boring slog that takes
| 30 developers 8 months to do what you can with CL in a week.
|
| Keep learning CL if that floats your boat. I had a blast
| learning it and it's a great tool to have and a constant source
| of inspiration for ideas.
| gjvc wrote:
| Amen.
| watmough wrote:
| Yes, it's great to experience the 10x or 100x developer
| syndrome sometimes.
|
| Using Clojure changed my life somewhat, as at some point I
| rewrote 2000 lines of C++ (to handle splitting and coalescing
| NAESB cycle pipeline nominations) in about 27 lines of
| pattern-matching Clojure, and just no one, no one would take
| it seriously. A usable UI in Swing to manage it wasn't much
| more, and was _cross-platform_. Not a fun experience overall,
| I ended up quitting that company, doing iPhone dev for a bit,
| then moved back into G &G.
|
| Other than that rewrite experience, I just used Clojure like
| I used to use Perl. Easy to bang something out in, and
| performant _native Java_ libraries for things you might not
| expect, like low-level SQL Server (2005 at the time!) and
| Oracle (8 at the time) drivers.
|
| I'm back mainly as a C++ developer now in visualization and
| HPC.
| outworlder wrote:
| That's also the problem with Lisp (and other powerful
| languages). They are far too malleable. They can be changed
| into unrecognizable blobs by people with lots of
| intelligence but low wisdom (I include myself in that
| group).
|
| They don't _have_ to. They can lead (and often do) to clean
| implementations. But we tend to like 'cleverness'. The
| larger the team, the more detrimental the effect.
|
| That's why we ended up with Java. And more recently,
| golang. As much as I like Go on its niche, it's a
| straightjacket. I'd often think to myself "this whole file
| I've been working for a week on would be 5 lines of scheme
| or lisp". But then if I get run over by a bus the company
| could theoretically replace me the next day (they couldn't
| because there's far more knowledge required than coding,
| but they think they could).
| agentultra wrote:
| Ah yes, the "we should be able to hire anyone off the
| street and replace you instantly," fallacy. I've never in
| all my career ever been asked to walk out into the street
| and grab a random stranger and pull them into our office
| to fix this code now _because Jerry just got hit by a bus
| and won 't be making it into the office ever again_. We
| can barely hire other programmers.
| watmough wrote:
| Great point!
|
| Maybe not so much of a fallacy when you look at how
| developer management currently works in most mainstream
| companies.
|
| It really does seem more geared to going slowly, and
| making each tiny step be recorded in some system.
| leprechaun1066 wrote:
| > the haters that parrot this old, barnacle-ridden trope:
| it's too powerful! Macros! Nobody can understand it but gods
| and strange people on the Internet! You will have to listen
| to these people constantly invade every forum, discussion
| group, and chat room on the Internet to tell you how you
| shouldn't be learning CL.
|
| These people are actually the reason I went and learned CL. I
| couldn't understand why some programmers would hate a
| programming language so much. Now it's one of my favourite
| languages.
| plaguepilled wrote:
| This is a great idea - I'm looking forward to trying it.
|
| One nitpick: the Google Docs code does not display favourably on
| mobile. It might help to publish in HTML if you're interested in
| targeting those readers.
| pronoiac wrote:
| The table of contents is on GitHub; I was honestly surprised
| the individual posts weren't too. Turning t into markdown would
| be fairly quick, I think?
| unionpivo wrote:
| The only Lisp I know of is Emacs Lisp. I thought It was
| implementation of common lisp, but according to Wikipedia I am
| wrong.
|
| So If primarily Linux user (sysadmin/devops/ occasional embedder
| programmer), wanted to learn lispy like language, that is useful
| which one would you pick?
|
| Emacs one? some common lisp or scheme ?
| vindarel wrote:
| Well CL is pretty useful, lightweight, featureful... and Emacs
| Lisp is very similar to it, so you won't be lost.
| ilrwbwrkhv wrote:
| Steel Bank Common Lisp has been one of the most enjoyable,
| performant, powerful languages I have ever used.
|
| Till now when I hack on something I use Steel Bank Common Lisp.
|
| Only for the most basic of web apps do I switch to Rails.
|
| These set of tutorials are excellent. Thanks for sharing.
| shadowgovt wrote:
| My favorite common lisp thing is the special operator `the`.
| http://clhs.lisp.se/Body/s_the.htm
|
| `the value-type form) => result*`
|
| Looking at its use, you might think it lets you declare types of
| things for type-checking purposes. i.e.
|
| (the integer (operate-on 1))
|
| ... would make the program assert-fail if (operate-on 1) were
| somehow not an integer.
|
| The real story is it _can_ do that, but the spec actually says
| behavior is undefined if the value is not the specified type. So
| check-failing is one of the many things it 's allowed to do.
|
| In practice, depending on your compiler settings, `the` can act
| like asserts or it can act like places the compiler's allowed to
| paint racing-stripes on your code to make it go faster by
| skipping dynamic type checks and letting data structures mangle
| up if the types are wrong. ;)*
| pcr910303 wrote:
| I've never did anything serious with Common Lisp, but my light
| experience on it was that
|
| - the idea that almost all language constructs are user-
| implementable with macros is quite impressive (but I don't buy
| the argument that "real" macros are only able in s-exprs)
|
| - and the REPL-driven development model was a really beautiful
| and seamless experience.
|
| But... every time I try to use it on some code, I find too many
| warts and inconsistencies that I just didn't want to spend too
| much effort in making it work. It's a beautiful language in it's
| own ways, but the other parts are too ugly (to me, of course).
|
| I'm fine with it being a lisp or not; I just want a clean
| language with macros baked in (and becomes the basis of most
| language features), and with a REPL-driven development model as a
| first class citizen (with interactive restarts and all).
|
| Unfortunately it seems a pipe dream... so I'm stuck here.
|
| [0]: https://mikelevins.github.io/posts/2020-12-18-repl-driven/
| the_duke wrote:
| Janet [1] is a clean, modern LISP.
|
| Clojure is also an option, but of course that comes with a
| heavy JVM burden.
|
| [1 ]https://janet-lang.org
| ogogmad wrote:
| > Janet is a clean, modern LISP.
|
| This does seem cleaner. I have some questions though:
| - What about the interactive environment like the one in
| Common Lisp? It's not enough to only have a "REPL", I think.
| - There are so many Lisp dialects. Is this one going to
| remain obscure? - What's the library situation?
| db65edfc7996 wrote:
| >What about the interactive environment like the one in
| Common Lisp?
|
| Never used a "real" Lisp REPL, but Conjure[0] seems like it
| ticks a lot of boxes.
|
| >Is this one going to remain obscure?
|
| There are only a ~dozen mainstream languages. Once you get
| outside of the popular zeitgeist, you have to appreciate
| exactly what you are getting. It takes a lot of dedication
| to become fluent in a language/ecosystem, so it is no
| surprise that people are reluctant to switch to a novel
| platform. Clojure is far more likely to ever become
| mainstream (owing to the huge JVM ecosystem), but even that
| seems to have only limited industry penetration.
|
| [0] https://github.com/Olical/conjure
| fuzzythinker wrote:
| Clojure doesn't need JVM. You can run it with GraalVM either
| directly [1] or via Babashka [2]. Both are great options for
| get into Clojure since there's almost no startup time like
| JVM and you don't have to be burdened with learning and
| heaviness of JVM stack.
|
| [1] https://github.com/oracle/graal
|
| [2] https://github.com/babashka/babashka
| avmich wrote:
| > Clojure doesn't need JVM. You can run it with GraalVM...
|
| Hm.
|
| https://en.wikipedia.org/wiki/GraalVM
|
| "GraalVM is a Java VM and JDK based on HotSpot/OpenJDK,
| implemented in Java..."
|
| https://en.wikipedia.org/wiki/Clojure
|
| "Other implementations of Clojure on different platforms
| include: - Babashka,[82] Native Clojure scripting language
| leveraging GraalVM native image and Small Clojure
| Interpreter.."
|
| I guess you mean that some particular implementation of JVM
| isn't needed. But in general Clojure has "j" in its name,
| it wouldn't make sense without JVM at all.
| fuzzythinker wrote:
| "a Java VM" =/= the JVM most people's understanding of
| the word.
| LesZedCB wrote:
| well, there's also ClojureScript and recently,
| ClojureDart - neither dependent on the JVM
| momentoftop wrote:
| I don't like REPL driven development. REPLs are celebrated as
| some sort of achievement in interactivity, but they're
| hopelessly puny, barely imitating a UNIX shell.
|
| When I write Emacs Lisp, I don't have a REPL. I just put point
| at the end of a random s-expression in a random Emacs-mode
| buffer, hit C-x C-e, and it gets evaluated. Or I do "eval-
| print-last-sexpression" to get the output on the next line. If
| I put my emacs in an org-mode code block, I'll get the output
| nicely formatted by org-mode. I can get close to this in Common
| Lisp with SLIME, but I've never found it as tight as Emacs
| Lisp.
|
| But Emacs lisp is still puny. Common Lisps had much higher
| aspirations than SLIME and a crappy UNIX-based Lisp executable.
| Allegro and Lispwerks still run on the philosophy that your IDE
| is just some live code in your lisp image, and you extend that
| image via the GUI. The same philosophy pervades (non-GNU)
| Smalltalk implementations.
|
| This is the sort of thing that still makes Lisp (and Smalltalk)
| absolutely stand out among programming languages, and it will
| be a crime when it is inevitably forgotten and we are left
| dumbfounded by the banality of REPL driven development.
| mickeyp wrote:
| Emacs does have a REPL (`M-x ielm'), and it works well.
| submeta wrote:
| Didn't know about that, although I have been using Emacs
| for over ten years! Tried `M-x ielm`, `(help) RET`, wow!
| Will explore it. Been only using the _scratch_ buffer and
| `C-x C-e` to evaluate sexpressions.
| mickeyp wrote:
| I wrote about all the way of doing this here:
|
| https://www.masteringemacs.org/article/evaluating-elisp-
| emac...
| submeta wrote:
| Ah, it's you Mickey! Got your book. Excellent! Thank you
| for writing it, and thank you for all the valuable stuff
| you put out there re learning Emacs.
| mikevin wrote:
| I wish GNU Emacs had better introspection, It's probably
| because it values user experience more but it saddens me when
| I see "You shouldn't use this from a lisp program, it's
| intended for users" or something like it. I understand the
| reasoning but having seen the power of introspection in
| Symbolics Genera makes me long for an Emacs that makes Elisp
| as much a feature as "Text-editing/browsing/etc".
|
| I should look into contributing I guess
| st3fan wrote:
| > When I write Emacs Lisp, I don't have a REPL. I just put
| point at the end of a random s-expression in a random Emacs-
| mode buffer, hit C-x C-e, and it gets evaluated.
|
| That actually is repl driven development. It does not mean
| that you type everything in on a repl prompt. It means you
| interactively and incrementally work on a program.
| TacticalCoder wrote:
| Yup I was going to comment basically the same: in this case
| Emacs itself _is_ the REPL environment (Emacs user here).
| Jtsummers wrote:
| Also, unless their configuration has changed things, C-x
| C-e will print out the results in the mini buffer at the
| bottom. So it retains each of the read, eval, and print
| parts of the read, eval, print loop. And since the program
| doesn't terminate (unless the expression you provided
| causes that), you're still in the loop part until you close
| emacs.
| lispm wrote:
| Allegro CL and LispWorks have very capable REPL experiences.
| They provide a mostly object-oriented implementation of
| Common Lisp with excellent support for the Condition system
| to interactively deal with errors, including hierarchical
| debug break loops and source level interpreters.
| giraffe_lady wrote:
| I don't necessarily recommend it as a general purpose language
| across many uses right now, but I've been working in lua a lot
| and fennel has really impressed me.
|
| It only adds special forms and doesn't change the runtime
| semantics at all, so you can drop it into any lua runtime for a
| strictly better dev experience, or target luajit or whatever
| but that's not relevant to me.
|
| I haven't used its macro system yet but it looks fine and
| pretty much like clojure's. I only ever wrote a handful of
| macros over years of working in clojure so ymmv anyway. Also it
| has pattern matching, which is ridiculously powerful and smooth
| in lisps, and it still boggles my mind that clojure doesn't
| seem aware of that.
|
| Again I haven't used this language yet for anything that didn't
| require lua, so I'm not sure how that'll go. I'll definitely
| consider it next time I need a lightweight scripting language
| though.
| jrvarela56 wrote:
| You can use this library to get pattern matching in Clojure:
| https://github.com/clojure/core.match/wiki/Overview
| HerrMonnezza wrote:
| Julia [1] has macros (not necessarily based on s-exprs though
| you can use s-exprs if you want) and a REPL [2] with some
| decent tooling (e.g., [3] [4])
|
| [1]: http://julialang.org/ [2]:
| https://www.youtube.com/watch?v=CRiD12Y75wM [3]:
| https://timholy.github.io/Revise.jl/stable/ [4]:
| https://kristofferc.github.io/OhMyREPL.jl/latest/
| lispm wrote:
| > (but I don't buy the argument that "real" macros are only
| able in s-exprs)
|
| There are macros in non-s-expr languages. Usually then one
| needs to manipulate an AST data structure. That has
| consequences in those cases:
|
| a) the macro forms need to be parsed according to a syntax,
| usually a predefined syntax
|
| b) the AST data structure adds some complexity, which makes
| simple things more complex, but can also be a help
|
| For Common Lisp a) means that the code enclosed in a macro does
| not need to conform to a predefined syntax and the macro is
| responsible to parse it. A typical example is the LOOP macro:
| (LOOP for i from a to b by 2 when (> a (foo b)) maximize (sin
| b)). That's a whole different sublanguage, which does not look
| like the typical nested lists based notation. It uses symbols
| as syntactic words in a complex syntax, which otherwise would
| not be valid Lisp.
|
| You can see what it does: one can add arbitrary syntax. Which
| is good and bad at the same time.
|
| b) means for Common Lisp that there is certain meta-level
| model, where the language can be used to program itself via
| procedural macros. Now one has to deal with code, where one can
| program on a meta-level which looks like the normal level.
| That's also good and bad. Good because one can apply all the
| knowledge and tools on the meta-level, too. Bad because it
| means that a programmer may see in a debugger code-generating
| code and the programmer sees code constructs which have code
| generators behind it. In a Lisp interpreter (one which
| processes Lisp source code at runtime), this will also be
| visible at runtime. In a language which uses AST data
| structures, the code in AST representation looks very different
| from the written code. In Lisp the code as data looks the same
| as the written code.
|
| The experience is widely different from programming in other
| programming languages and not that easy to learn: programming a
| language on a meta-level in itself.
|
| Most programming we see seems to happen without that self-
| programmability capability.
| Decabytes wrote:
| > (but I don't buy the argument that "real" macros are only
| able in s-exprs)
|
| The Rhombus project in Racket^1 is an attempt to fix a lot of
| things about Racket and S-exprs but one of the goals is
| creating a syntax that is able to be manipulated as easily a
| s-exprs.
|
| > By "macro-extensible," we mean that Rhombus users should be
| able to extend the syntax of Rhombus in much the same way that
| Racket users can extend the syntax of Racket. Complex syntactic
| extensions such as object and class systems, static type
| checkers, and pattern matching should be implemented as
| libraries while still providing a surface syntax familiar to
| users of these features in other languages.
|
| 1. https://github.com/racket/rhombus-
| prototype/blob/master/reso...
| Kototama wrote:
| > but I don't buy the argument that "real" macros are only able
| in s-exprs
|
| Metaprogamming can be done also semantically in other
| languages. Elixir for example has also macros and a good part
| of the core of the language is written with them. When writing
| a macro you then get an AST in input (represented with tuples
| in Elixir) and give another AST as output. I think Rust has
| something similar.
|
| The reason why s-exps are better to write macros is that the
| AST has the same form has the code you write in the editor.
| This way textual code and code as data have the same
| representation, making it easier to reason and manipulate the
| code.
| buggythebug wrote:
| rtz121 wrote:
| Wrong.
| stnmtn wrote:
| I'm a software engineer interested in getting more productive
| at my job, which namely involves the current React/typescript
| ecosystem. I have no interest in lower-level programming as a
| career path.
|
| What benefits would learning Lisp provide me so that I "Need"
| to learn it?
| lispm wrote:
| Some people recommend to learn some basics of Lisp to
| better understand JavaScript.
|
| Though one of the core Lisp/Scheme books now has a
| JavaScript edition:
| https://mitpress.mit.edu/books/structure-and-
| interpretation-...
| dunefox wrote:
| Reading a couple chapters of SICP
| (https://xuanji.appspot.com/isicp/) or these articles might
| give you an idea: https://michaelnielsen.org/ddi/lisp-as-
| the-maxwells-equation...
| https://queue.acm.org/detail.cfm?id=1039523
| https://www.defmacro.org/ramblings/lisp.html
| Veen wrote:
| Perhaps not, but need is not the only reason to learn; people
| also learn things because they are fun, pleasurable,
| interesting, challenging, entertaining, beautiful, revelatory,
| creative, inspiring etc. It'd be a dull life if we only learn
| what we need to know.
| __oh_es wrote:
| Take a look at this -
| https://www.defmacro.org/ramblings/lisp.html, it may give you a
| different perspective :)
| goatlover wrote:
| What's the point of this comment? If you don't care about Lisp,
| skip the thread.
| pfdietz wrote:
| Need for... what? To survive? To get a job?
|
| Need is always relative to a goal, so what you are saying there
| is there is no legitimate goal for which learning Lisp would be
| an appropriate step.
| Rerarom wrote:
| Indeed, I've been told countless times I don't "need" to
| learn some branch of math I was interested in (by
| mathematicians no less).
|
| Also, I've been told I "can't avoid" some branch of algebra
| (I've never touched it since).
| t-3 wrote:
| Those aren't necessarily incompatible. Nobody can avoid
| linear algebra, but almost nobody actually needs to use or
| know linear algebra. Heavily symbolic fields like math are
| probably not great examples though - different methods can
| be used to reach the same results because it's all
| fundamentally the same, just differing representations.
| juliend2 wrote:
| Come on, this is HN, you're not even allowed to _think_ that
| here.
| amar-laksh wrote:
| Okay but everyone needs to think deeply about lisp.
| Zababa wrote:
| No, I think most people don't need to think deeply about
| lisp. I'd even argue no one "needs" to think deeply about
| lisp.
| tmountain wrote:
| Some people want to. It's good for those people to have
| resources.
| teddyh wrote:
| " _LISP is worth learning for a different reason -- the
| profound enlightenment experience you will have when you
| finally get it. That experience will make you a better
| programmer for the rest of your days, even if you never
| actually use LISP itself a lot._ "
|
| -- http://www.catb.org/~esr/faqs/hacker-howto.html#skills1
| jstx1 wrote:
| Honestly, "just because I want to" sounds like a more
| compelling argument than talking about enlightenment. Mainly
| because the latter implies that people who don't know lisp
| are somehow unenlightened or lacking in some way - that comes
| across as really arrogant and it's clearly false since there
| are many successful and highly skilled programmers who don't
| know or care about lisp.
|
| I kind of agree with the GP comment - nobody needs to learn
| lisp. The main reason to learn it is some personal interest
| or curiosity.
| lispm wrote:
| There is some enlightenment experience, when you get _it_.
| This _it_ is when one figures out why Lisp is how it is: a
| language programmed in a data structure, programmable in
| itself. One can live without that enlightenment. One can
| also live without understanding recursion, but it was a
| small enlightenment for me when I understood recursion and
| how to use that in programming. There are a bunch of
| enlightenment experiences one can have. I had another one
| when I first read the Smalltalk books and later saw a
| Smalltalk system - I thought that was the end of
| programming, everything was done.
|
| Alan Kay (the 'Alan Kay' of OOP and Smalltalk ) had an
| enlightenment experience with Lisp:
|
| https://queue.acm.org/detail.cfm?id=1039523
|
| "AK Yes, that was the big revelation to me when I was in
| graduate school--when I finally understood that the half
| page of code on the bottom of page 13 of the Lisp 1.5
| manual was Lisp in itself. These were "Maxwell's Equations
| of Software!" This is the whole world of programming in a
| few lines that I can put my hand over."
|
| For background on this:
|
| https://michaelnielsen.org/ddi/lisp-as-the-maxwells-
| equation...
|
| > false since there are many successful and highly skilled
| programmers who don't know or care about lisp
|
| Still they unknowingly may use a lot of things that were
| once pioneered in Lisp, like these: conditionals,
| functional programming, managed memory and garbage
| collection, evaluator/interpreters, read-eval-print-loops,
| image-based programming, ...
| PheonixPharts wrote:
| > Mainly because the latter implies that people who don't
| know lisp are somehow unenlightened or lacking in some way
|
| But if you haven't learned Lisp you _are_ absolutely
| lacking in some way as far as understanding programming
| languages. One obvious example is don 't really understand
| what the url of this website is referring to (though I do
| suspect a huge number of today's HNers have never
| implemented the y-combinator).
|
| To be clear, you can be an excellent software engineer and
| never touch or understand lisp, but if you are seriously
| interested in _programming languages_ you really are
| missing a major part of picture if you don 't know a lisp.
|
| Anyone who is seriously interested in _programming_ ,
| beyond just creating software, absolutely must have
| experience in a lisp. It's completely fine if you aren't
| interested in programming other than solving a specific
| problem, but the idea that "nobody needs to learn lisp" is
| false.
| lubesGordi wrote:
| What is it about lisp that's so important? Is it just the
| functional programming side? Metaprogramming?
| PheonixPharts wrote:
| The several important things about lisp that you won't
| find in other languages without learning lisp include
| (I'm considering all lisps here, including schemes):
|
| - it's essentially a working implementation of the
| untyped lambda calculus, an essential model for thinking
| about computing outside of the Von Neumann architecture.
|
| - It is a symbolic programming language which allows for
| unique ways of manipulating code as data. The only other
| programming language that I know of that offers symbolic
| programming to the same degree is Prolog (outside of
| computer algebra systems).
|
| - The parens and prefix notation really are a powerful
| feature, despite being off putting to beginners. You are
| essentially programming an Abstract syntax tree. All
| programming language spend some of their time in this
| form, you just don't usually get to play with the code
| this way. This makes it incredibly easy to prototype
| ideas for languages and compilers in Lisps
|
| The functional programming and meta-programming benefits
| naturally fall out of all of these. The reason
| metaprogramming is so powerful in Lisp is because of a
| combination of writing code in a tree structures and
| being a symbolic programming language.
|
| The big picture reason that lisp is so great for people
| interested in better understanding programming is that it
| is a language that encourages you to write domain
| specific languages to solve your problems.
|
| I'll be the first to admit that this is not great for
| real world software engineering, but if you want to
| understand programming better, it is essential.
| lubesGordi wrote:
| Fantastic response, highly appreciated.
|
| I've found more recently I want to solve problems with
| domain specific languages, so I'm totally on board with
| that. I would say that making dsls to solve problems is a
| great way to engineer software, as the code is usually
| testable and you don't need to modify it. Sort of where
| functional programming meets solid. Maybe not the best
| approach if you're in a startup though.
| rfrey wrote:
| No one needs to learn anything.
| DerArzt wrote:
| Need, maybe not, but want to yes some folks do.
|
| Even though Common Lisp isn't used widely it never hurts to
| learn new things (especially when those things can be quite
| different than what you normally use).
| __del__ wrote:
| >ball of goop
|
| can you please talk to us like programmers? your audience is
| programmers.
| pfdietz wrote:
| One of the salient features of Lisps is that they are dynamic
| languages designed so they can be compiled into very efficient
| code. The details of how this works are interesting (for example,
| the use of low order bits as tags to efficiently detect common
| error cases, and also to allow types like characters, fixnums,
| and some floats to be represented without allocation.) A downside
| of this is that lisp implementations may not be ABI compatible
| with other language implementations.
|
| The macros are orthogonal to this. Macros are really just an
| example of a more general thing: features that are used to
| effectively implement parts of the language definition are often
| lifted up and also made available to users. This effectively
| allows the language to be extended in a way that very closely
| resembles the language's built-ins. (This is not always the case;
| lifting more such things would be a good avenue for extending
| Lisps.)
| qwerty456127 wrote:
| Looks really cool (because classic GUI pictures, desktop or
| desktop-like GUI is what I want). Feels like I'm going to learn
| it finally. Thanks!
___________________________________________________________________
(page generated 2022-04-27 23:01 UTC)