I'm turning into a Lisp snob
briancarper.net
I'm turning into a Lisp snob
1–10 of 94 posts
Re: I'm turning into a Lisp snob
#2OTOH the Go authors made it clear that it's intended to replace C for the basic system programs & libs. I think that's step in the right direction.
I started to earn money using Erlang & Clojure, so looks like I'm not only fan of new exciting high-level langs but also quite an adopter of them in the so-called real world. Still there are some uses when a VM of your Chosen One language brings an unacceptable overhead. Imagine your daily work using vi, grep, find as they were compiled into jars and each running via JVM. Nightmare with that 2 seconds delay of starting each little proggy, isn't it? (Have you ever used the original Amazon's EC2 commandline tools written in Java? You'd know what I mean).
Of course it could be solved by some kind of injecting of program to be run to some VM already running, but that's not an established practice of working with basic programs in your system. At some level fast binaries are needed.
Personally I think it's a pity that some language of SML family didn't get to the mainsteam for such system programming. Haskell is fun and people write things like text editors and window managers in it; but is still perceived as too academic for real tasks which isn't completely true.
Re: I'm turning into a Lisp snob
#3> "Programming language quality is usually inversely proportional to the number of special forms"
Programming language obscurity is also usually inversely proportional to the number of special forms. Church numerals?
The happy place is somewhere in the middle, where there's enough language such that you don't have to build it out of other pieces - and this also helps with performance, static analysis, tooling, debugging and lots of other areas - but there isn't so much that you end up with lots of methods to do the same thing, in similar but incompatible ways.
Re: I'm turning into a Lisp snob
#4"I could show these poor imperative programmers how their problems could be solved much easier in Lisp if I wanted to." That to me (as an outsider) seems to be the main message of these Lisp blogs. But at some point, nobody will believe you could do it, unless you actually do.
Re: I'm turning into a Lisp snob
#5> "Programming language quality is usually inversely proportional to the number of special forms" Programming language obscurity is also usually inversely proportional to the number of special forms. Church numerals? The happy place is somewhere in the middle, where there's enough language such that you don't have to build it out of other pieces - and this also helps with performance, static analysis, tooling, debugg…
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. --Antoine de Saint Exupéry
Re: I'm turning into a Lisp snob
#6> "Programming language quality is usually inversely proportional to the number of special forms" Programming language obscurity is also usually inversely proportional to the number of special forms. Church numerals? The happy place is somewhere in the middle, where there's enough language such that you don't have to build it out of other pieces - and this also helps with performance, static analysis, tooling, debugg…
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. --Antoine de Saint Exupéry
My point is that with programming language abstractions, you can in fact remove things without hurting the theoretical power of the language, but actually harming the practical power of the language.
You do have to leave things in that you could take away.
Re: I'm turning into a Lisp snob
#7If you're truly passionate about hacking it would be hard to avoid becoming a LISP snob at some point in your development. But if you're pragmatic, you'd be able to transfer what you've learned from LISP to other environments, that may be better suitable for today's technological landscape. Is Google Go the way to go? Only time will tell. But there's little you can usefully do with LISP these days (unless the scope of the program you're working on is so restricted that you really only need the language purely).
Re: I'm turning into a Lisp snob
#8> "Programming language quality is usually inversely proportional to the number of special forms" Programming language obscurity is also usually inversely proportional to the number of special forms. Church numerals? The happy place is somewhere in the middle, where there's enough language such that you don't have to build it out of other pieces - and this also helps with performance, static analysis, tooling, debugg…
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. --Antoine de Saint Exupéry
And yet Antoine is famous for book-length works, not poetry, and certainly not minimalist poetry.
Don't take the lesson too literally. You can, in fact, take too much away. How much you need to put in depends on your artistic goals and, of course, on your audience.
Re: I'm turning into a Lisp snob
#9If you're truly passionate about hacking it would be hard to avoid becoming a LISP snob at some point in your development. But if you're pragmatic, you'd be able to transfer what you've learned from LISP to other environments, that may be better suitable for today's technological landscape. Is Google Go the way to go? Only time will tell. But there's little you can usefully do with LISP these days (unless the scope o…
[deleted]
Re: I'm turning into a Lisp snob
#10If you're truly passionate about hacking it would be hard to avoid becoming a LISP snob at some point in your development. But if you're pragmatic, you'd be able to transfer what you've learned from LISP to other environments, that may be better suitable for today's technological landscape. Is Google Go the way to go? Only time will tell. But there's little you can usefully do with LISP these days (unless the scope o…
If you get into compilers and language design, all languages turn into more formalized versions of Lisp mixed with some libraries and macros. Lisp in many ways is little more than a serialization format for a syntax tree, with a DSL for converting that tree into an executable program.
That's both its biggest advantage and disadvantage. It's an advantage in that it can be stretched and flexed to cover any problem domain, by rigging up a language suited to the domain. On the other hand, the fact that it's so flexible means there's less common points of reference for composition in the large. Learning a language for a domain is usually more work than learning a library that uses familiar idioms, even if it is more flexible in the long term. If that domain isn't your bread and butter, a library suits you better.
It comes down to an economic argument, I believe. Some level of centralization is necessary to overcome the transaction costs of fitting lots of little languages together, which each have their own ideas about how things should work. It helps hugely in tooling, debugging, analysis, etc. Syntactic transformation via macros from a high-level language to a lower level isn't enough to create a practical modern language in the large. You need more.
As to the practical applicability of Lisp, I think you can get most of what you need with something like Clojure.