61–70 of 339 posts
So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? And the abstractions provided by modern languages are woefully incomplete?
> Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation
You could say the same about Java and 20 years.
Appreciating what Lisp is capable of doing (think macros), and having worked through SICP some twenty years ago, and after having tried to make a deep dive in CL and Emacs Lisp two years ago, I come to the conclusion that there is no silver bullet in Lisp-land. Python is a good enough Lisp, as Peter Norvig has concluded. And it’s got all batteries included. Ain‘t nothing it can’t do. Building websites, doing maths, a…
I wouldn't say that. https://coalton-lang.github.io/20211010-introducing-coalton/
> The developers of Lisp give you the full powers that they had to develop the language. So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? And the abstractions provided by modern languages are woefully incomplete? > Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation You could say the same about Java and 2…
Or even COBOL and 40 or 50 years. What does that even prove.
Edit: Typo
> The developers of Lisp give you the full powers that they had to develop the language. So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? And the abstractions provided by modern languages are woefully incomplete? > Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation You could say the same about Java and 2…
I think this tends to hold true for all complex systems past certain point. Especially web frameworks. They just tend to circumvent the language so much (via macros, type system, etc.) so it's no longer like a bare language that was before. But I appreciate your point that macros can add cognitive burden in many cases where less powerful (and more easily understandable) mechanisms would suffice.
> When you have a running program you can compile functions, redefine classes, etc. all while the program is running. You are changing the internal state of the image. This can surely be convenient in certain cases, however most of the times I find myself playing around with unit tests rather than with a single running process. Unit tests are small and fast so I don't even notice any inconvenience with the traditiona…
I find the repl invaluable for writing unit tests. I think about what I want to test, try it out in the repl, refine it for better generality, and then basically copy/paste it into a file full of unit tests.
Appreciating what Lisp is capable of doing (think macros), and having worked through SICP some twenty years ago, and after having tried to make a deep dive in CL and Emacs Lisp two years ago, I come to the conclusion that there is no silver bullet in Lisp-land. Python is a good enough Lisp, as Peter Norvig has concluded. And it’s got all batteries included. Ain‘t nothing it can’t do. Building websites, doing maths, a…
After learning Python, I wanted to take the next step and find what was better. I looked into a lot of languages reading books on Haskell and Lisp and many others. At least for my use cases (desktop scripting, numerical work... etc) I didn't find Lisp to be superior. Most of what I actually needed to do could be done simpler in Python. Python's REPL isn't near as good as CL, but it's good enough. Then the batteries i…
Appreciating what Lisp is capable of doing (think macros), and having worked through SICP some twenty years ago, and after having tried to make a deep dive in CL and Emacs Lisp two years ago, I come to the conclusion that there is no silver bullet in Lisp-land. Python is a good enough Lisp, as Peter Norvig has concluded. And it’s got all batteries included. Ain‘t nothing it can’t do. Building websites, doing maths, a…
I almost agree, but Python fails in one area, which happens to be my current area of interest. It doesn't have sufficiently strict encapsulation to support object capabilities[0] at the language level.
JavaScript, on the other hand, does[1] - so you don't necessarily need Lisp for this, but I do enjoy the parentheses. :)
[0] http://habitatchronicles.com/2017/05/what-are-capabilities/
[1] https://medium.com/agoric/pola-would-have-prevented-the-even...
A point the authors didn't make is that Common Lisp compilers are quite fast compared to e.g. C++ compilers. So even in rare cases where you do need to recompile everything, the cycle time is short. CCL's compiler is lightning-fast. I can recompile an entire system in CCL almost as fast as I can load the compiled object code. SBCL's compiler is slower (while often generating faster code because it does more work at c…
There is PyPy, and apparently Mojo will change the world, but still not something to rely on like on Lisps.
I guess there is always Julia.
> The developers of Lisp give you the full powers that they had to develop the language. So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? And the abstractions provided by modern languages are woefully incomplete? > Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation You could say the same about Java and 2…