21–30 of 140 posts
Still, the basic eval command looks remarkably similar in lisp vs TCL.
The thing is that trying to understand "the power of Lisp" via the toy interpreter from The Roots of Lisp[0] is like trying to understand "the beauty of the sea" after seeing a single five-minute YouTube video explaining it. It will give you the basic idea, but it won't tell you about macros, reader macros, compiler macros, and having the whole language always available to build your abstractions on; it won't tell yo…
here's how to leverage the pretty printer to transpile lisp into pascal https://merl.com/publications/docs/TR93-17.pdf
Note that the examples in the "cdr" section are incorrect. (cdr '(x a)) ; does not return a, it returns (a) (cdr '((x a) y)) ; does not return y, it returns (y) (cdr '((x a) (y b))) ; does not return (y b), it returns ((y b))
The author might be new to Lisp, and I hope what I write doesn't discourage him. There are some other mistakes: ((ab . c) . d . nil) isn't a valid s-expression. Maybe it should be ((ab . c) d . nil) Also, (eq '(a b) '(a b)) ; (a b) is a list and cannot be evaluated by eq eq works fine on lists. It returns T iff its arguments are the same object (i.e. are at the same memory location, or are small enough integers or fl…
The thing is that trying to understand "the power of Lisp" via the toy interpreter from The Roots of Lisp[0] is like trying to understand "the beauty of the sea" after seeing a single five-minute YouTube video explaining it. It will give you the basic idea, but it won't tell you about macros, reader macros, compiler macros, and having the whole language always available to build your abstractions on; it won't tell yo…
Truly asking for help: can you help explain what can I do with macros that I cannot do with functions? Or, maybe, cannot do with high quality or low complexity using functions?
While I don’t disagree with Josh’s blog, concentrating on just language features leaves out the style of Lisp development: bottom up REPL style development. When I have to use Haskell or Python, I find myself working as if I were using Lisp: I still favor the REPL and building up from primitive functions to the top level application. This is probably a bad habit but it is the way I work. BTW, using the standard Emacs…
I feel like the bottom up style is possible in static languages like C++ too, except instead of manually testing small functions in the repl, you can write small unit tests for them instead. In a way it's even better because a test written once can be run many times, while testing in the repl requires a manual test with every change.
C++17 made this minimally useful, and things got spectacularly better with C++20 and constexpr vector/string. 23 is shaping up to move even more of the standard library to constexpr.
The thing is that trying to understand "the power of Lisp" via the toy interpreter from The Roots of Lisp[0] is like trying to understand "the beauty of the sea" after seeing a single five-minute YouTube video explaining it. It will give you the basic idea, but it won't tell you about macros, reader macros, compiler macros, and having the whole language always available to build your abstractions on; it won't tell yo…
I've learned Clojure. Tried and failed to see this unique power of macros. Truly asking for help: can you help explain what can I do with macros that I cannot do with functions? Or, maybe, cannot do with high quality or low complexity using functions?
[1]
Some other languages support similar, if not more powerful, compile-time facilities (such as Lisp macros), but those are outside the scope of this article.
Earlier quoted context omitted.
I feel like the bottom up style is possible in static languages like C++ too, except instead of manually testing small functions in the repl, you can write small unit tests for them instead. In a way it's even better because a test written once can be run many times, while testing in the repl requires a manual test with every change.
constexpr and static_assert make this a ton easier in C++. If your "unit tests" are static_asserts, the IDE will just highlight the broken parts. C++17 made this minimally useful, and things got spectacularly better with C++20 and constexpr vector/string. 23 is shaping up to move even more of the standard library to constexpr.
The thing is that trying to understand "the power of Lisp" via the toy interpreter from The Roots of Lisp[0] is like trying to understand "the beauty of the sea" after seeing a single five-minute YouTube video explaining it. It will give you the basic idea, but it won't tell you about macros, reader macros, compiler macros, and having the whole language always available to build your abstractions on; it won't tell yo…
I've learned Clojure. Tried and failed to see this unique power of macros. Truly asking for help: can you help explain what can I do with macros that I cannot do with functions? Or, maybe, cannot do with high quality or low complexity using functions?
While I don’t disagree with Josh’s blog, concentrating on just language features leaves out the style of Lisp development: bottom up REPL style development. When I have to use Haskell or Python, I find myself working as if I were using Lisp: I still favor the REPL and building up from primitive functions to the top level application. This is probably a bad habit but it is the way I work. BTW, using the standard Emacs…
Earlier quoted context omitted.
I've learned Clojure. Tried and failed to see this unique power of macros. Truly asking for help: can you help explain what can I do with macros that I cannot do with functions? Or, maybe, cannot do with high quality or low complexity using functions?
My impression, and I hope I'm wrong, is that macros and meta programming were powerful ideas 30 years ago, but now most modern languages have generics, template meta programming [1] and reflection. I'm a curious amateur and probably out to lunch, but there you go. [1] Some other languages support similar, if not more powerful, compile-time facilities (such as Lisp macros), but those are outside the scope of this arti…