I'm really quite drawn to lisp (in general) but I keep bouncing off it. I think the main reason is I just don't know how to effectively work with a dynamically typed programming language. I think for me the affordances that a language provides to change a program over time matter much more than the features that aid in writing programs. I want to know before I run my program whether my program is sound. I appreciate what other people are able to do with lisp(s) and I want to experience that for myself. But I think what I need is to let go of having a compiler yell at me when I remove a field from a type but that I still have functions that expect that field (for example). Is it just more tests? Live REPL editing? It seems like this can only cover so much surface area compared to compile time type checking. I don't think statically typed languages are better than dynamic ones or vice-versa. I just am not as effective with the dynamic ones.
A Road to Lisp: Which Lisp
131–140 of 180 posts
Re: A Road to Lisp: Which Lisp
#132I'm going to take the opposite position that there is much less special about Lisp than people think. Like I have met so many programmers that travel around like itinerant martial artists looking for true functional programming and they never find it. To be specific, you can work all of the examples in Graham's On Lisp in Python except for one of the last chapters where he implements continuations that really need ma…
> the techniques in the Dragon Book for writing compilers are the real magic.
Can confirm; got a few hints from the 1988 edition when working on the TXR Lisp compiler.
Oh, and also when implementing regexes, not to forget!
However, the Lisp compiler has its own magics that are not exactly covered in the Dragon Book. Some really nice way of doing things.
Re: A Road to Lisp: Which Lisp
#133I'm going to take the opposite position that there is much less special about Lisp than people think. Like I have met so many programmers that travel around like itinerant martial artists looking for true functional programming and they never find it. To be specific, you can work all of the examples in Graham's On Lisp in Python except for one of the last chapters where he implements continuations that really need ma…
There's nothing "special" about Lisp and Lisp dialects, yes. Similar features can be or already have been implemented in other languages. Yet, after touching, using and experiencing working with a bunch of different stacks, I cannot simply ignore the enormous pragmatic level of Lisps. Working with Clojure is an absolute delight. It strips down all the dogma and let's you deal with the "business logic" as if you're co…
1. Languages that have all the Lisp features are in the Lisp family. Thus languages that are not in the Lisp familly are ones that don't have all the Lisp features. Once a langauge disappears behind the event horizon of the Lisp family, outsiders no longer distinguish it from any other member of the Lisp family; it's just Lisp.
2. Having some features of Lisp is not the same thing as having those features in that form and integrated in that way.
It's not just the roster of features, but how they blend!
If two features have to speak with each other through some interpretation layer, that spoils everything.
Re: A Road to Lisp: Which Lisp
#134Since this is the largest gathering of LISP users I have seen, I have a question. Why prefer lisp-1 over lisp-2 or vice-versa?
Lisp-1 has the wart that it models special operators as bindings in a variable name space. So a form like (print let) actually resolves let to a binding to a special operator, and then has to be somehow pronounced as nonsense. And you can block let from working by binding that as a variable name. Allowing variables to shadow the basic operators of the language is quirky.
Would you want to use a weird POSIX shell in which "for x in *.jpg; ..." stopped working because you assigned "for=42"?
Yet Lisp-1 has a notational advantage for programs that work with functional values; programs that indirect upon functions are more succinct, free of "shim" operators for lifting values out of the function binding space, or requesting application of a function value.
In the TXR Lisp dialect, I worked out a way to have the notational convenience, without bringing in the Lisp-1 issue.
1. The substrate, including macro-expansion logic, is thoroughly Lisp-2.
2. When a compound form is written in square brackets, it indicates that immediate elements (those constituents that are symbols) are to be looked up in a single namespace that is a merger of the function and variable namespaces according to precisely documented rules. This is not recursively applied to the form; its arguments that are compound forms are not treated this way unless they use square brackets.
3. Macros are not affected. In a form [a b c ...], the element a is neither recognized as a special operator or as an operator macro. If it is a symbol, it is either a variable, or a symbol macro.
4. [ ... ] is a surface syntax with a straightforward representation: the (dwim ...) operator. The above semantics is thoroughly baked into the macro expander and correctly treated at all necessary levels of the language: the handling of lexical scopes at expansion time and compilation/evaluation.
This system leaves mainly just one small infelicity. The merged 1+2 namespace is not available in certain contexts when it would be handy. Like say we are writing a function that takes a functional argument, that we would like to default:
(defun my-sort (sequence : (test-fn equal)) ...) ;; nope!
(defun my-sort (sequence : [test-fn equal]) ...) ;; nope!
(defun my-sort (sequence : (test-fn (fun equal))) ...)
Re: A Road to Lisp: Which Lisp
#135Since a few folks here recommended Common Lisp to me as the language that would "tick all my boxes", I've been doing a deep dive. Right now, I'm working through SICP again with DrRacket. The first time I worked through it with MIT Scheme MANY years ago. It's shocking how much I've forgotten. What I like about this article is that it walks through the different "camps" of Lisp. Scheme is so intriguing to me because of…
The Scheme Programming Language by R. Kent Dybvig is very much worth reading after you finish SICP. Truly the same caliber as K&R's C Programming Language, and more up-to-date (R6RS). The earlier exercises aren't too tricky (except call/cc headaches), but the final chapter has some good meaty Scheme projects that will teach you a ton.
It's free online: https://scheme.com/tspl4/
Re: A Road to Lisp: Which Lisp
#136From my experience, to be happy I would need the perf of sbcl, the syntax, litterals and data structure of clojure, the begginer-friendlyness of drracket, the type system of ocaml, and the dev experience of rust. Does that exist somewhere ? I hope jank gets there. Or maybe roc will. At this point, given the progress and expectations of using LLM, writing code is going to be purely a hobby concern, like carving wood f…
Please say more about the "dev experience of rust." As a long time Lisper and not much of a Ruster, I found the dev experience very painful. Granted, I expect had I continued using Rust that would have abated in tjme. I also disliked Clojure at first until I became comfortable with it and productive, before coming to like and appreciate it.
[deleted]
Re: A Road to Lisp: Which Lisp
#137Earlier quoted context omitted.
That's just crazy! (in a good way) I've been in software since 1998 and it's like I've just uncovered a whole new world.
What about this one? https://github.com/dotcl/dotcl > Common Lisp implementation on .NET. Lisp source is compiled to CIL (Common Intermediate Language) and runs on the .NET JIT — so the same Lisp image runs on Windows, macOS, and Linux across x86-64 and ARM64 without per-platform porting work.
Thanks! I don't think I've seen that one.
Re: A Road to Lisp: Which Lisp
#138The funny thing about Lisp is that writing a Lisp interpreter is significantly fewer keystrokes than correctly installing Common Lisp and its tooling. The ratio of lisps to lisp programmers may actually be above 1.
Literally a comment I wrote then decided not to post. > The best LISP is the one you create yourself. You learn so much about programming by implementing your own language, and LISP is brilliant for this purpose thanks to its simple syntax and homoiconicity (code is data, data is code). It's also a great way to learn a new existing language, like Rust or Go, by writing a LISP interpreter with it.
Thank you for not posting it
Re: A Road to Lisp: Which Lisp
#139Really should include Emacs lisp, as it's a something many in academia happen upon for LaTeX or some other side use.
While Emacs Lisp is confined to the editor, it also shows that the Editor is not that, and much has been said of it as an OS, an Application Platform, and so on.
Since about 1992, I've used it as platform for many things as well as a general purpose text editor I couldn't initially figure out how to quit.
I'm sure many here are more fervent about Emacs, living in the terminal switched to living in Emacs for a lot of folks... that's really a testament to the usability gravity of an integrated computing platform with Lisp as it's only scripting language.
ymmv of course
Re: A Road to Lisp: Which Lisp
#140Earlier quoted context omitted.
Literally a comment I wrote then decided not to post. > The best LISP is the one you create yourself. You learn so much about programming by implementing your own language, and LISP is brilliant for this purpose thanks to its simple syntax and homoiconicity (code is data, data is code). It's also a great way to learn a new existing language, like Rust or Go, by writing a LISP interpreter with it.
Thank you for not posting it
Ceci n'est pas une pipe. (: