Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why didn't Common Lisp fix the world?

quora.com

Post reply on HN
Print view View original

81–90 of 127 posts

Re: Why didn't Common Lisp fix the world?

#81

Post by sklogic »

dunkelheit wrote: post #77
sklogic wrote: post #62

Earlier quoted context omitted.

> No. Why would you say so? There is nothing simpler than compilers. They can be broken down into pieces as small as you like which are still independent and fully sequential. Most of the rewrites you'll ever need to do can be done in a total language - i.e., you don't even need Turing-completeness for most of your code. > Any complexity? Really? I have not met a kind of complexity that cannot be decomposed into triv…

That is a brave statement to make. How about you write a Lisp program that (serving as a perfect embodiment of "code is data" philosophy) takes another Lisp program as input and determines whether it would terminate? That would be just a handful of Lisp macros, right?

Now you're talking about an infinite complexity. It cannot be reduced no matter how hard you try. It has nothing to do with the kind of complexity that software engineering have to deal with.

But, for all things practical, yes, it's just a handful of Lisp macros. Because in most cases it worth designing your DSLs as total languages, and totality proof is totally trivial, as well as a proof of an opposite.

Re: Why didn't Common Lisp fix the world?

#82

Post by znpy »

I bought Graham's "Ansi Common Lisp" book and read it briefly, and tried to write some code as well.

I also read "Successful Lisp" briefly.

Hoping to give constructive feedback and not to start a flame, here are some opinions/impressions.

Please note that :

1. These are mostly impressions, not complete opinions.

2. I am only talking about Common Lisp. I am not talking about Scheme, Clojure or other stuff.

Ok then:

1) Lisp feels... Messy. Expecially when you're learning it.

2) Maybe... Too many implementations? This is not a problem per se, but sometime it happens that not all the implementation implement all of the features, or implement them differently enough that you have to write the same code for different interpreters.

Example: https://github.com/stumpwm/stumpwm/blob/master/make-image.li... see the various #+clisp, #+sbcl and stuff.

3) Batteries not included. The ANSI standard defines the language and pretty much nothing more. Yeah you have libraries and quicklisp, but it feels fragile and quite "opaque". Also, I always used SBCL and I am not 100% sure all the libraries work with all of the interpreters/compilers.

I feel it would be nice to have a new standard that defines a set of additional API that implementors should implement.

Ideally, it would be nice to have common lisp to be "batteries included" like Python. But please let's avoid the Scheme SRFI mess.

Consider this: it is a fact that MIT introductory programming class switched from Scheme to Python because among other things, students were spending too much time reading libraries manuals and implementation references instead of writing code.

5) The Common Lisp HyperSpec. Let's say I find it to have a poor usability.

4) Stuff is generally poorly documented, and fragmented. While things like quicklisp work, it's visible that those are basically one-man projects. This isn't reassuring.

5) Given the heritage, there is not such thing as a "Lisp community" and the lack of governance is quite evident in the sense of lack of direction and lack of uniformity in pretty much everything.

6) Emacs. "It's lisp!". Well actually emacs lisp and common lisp are different languages, and differences will come up.

Emacs is my editor of choice, but I' starting to grow worried about it.

These are some of the reasons why I decided not to "invest" in Common Lisp.

Re: Why didn't Common Lisp fix the world?

#83

Post by DonaldFisk »

keymone wrote: post #45
nabla9 wrote: post #29

Earlier quoted context omitted.

>i feel like a lot of lisps are trying to drag this "everything is a list" I think you are speaking out of ignorance here. "everything is a list" is just a metaphor. Everything is either list or atom and almost everything is atom.

> Everything is either list or atom and almost everything is atom. how can you both say this and that i'm talking out of ignorance? you're basically confirming my words. larger point i was making is that "everything is a list" abstraction/metaphor influenced the decision to not include native representation of other data structures into the language. because parens are enough to represent everything. well they aren't…

Atoms in Lisp aren't what you think they are. All data structures except dotted pairs (from which lists are made) are atoms. For example, arrays and hash tables are atoms.

Re: Why didn't Common Lisp fix the world?

#84

Post by sklogic »

chvid wrote: post #44
pjc50 wrote: post #20

Earlier quoted context omitted.

C++ templates are also turing complete, executed at compile time, and can result in extremely high compile times: http://cpptruths.blogspot.co.uk/2005/11/c-templates-are-turi... I don't think that failure to terminate compiles is too big a problem in practice; treat it as just another form of compile-time error and fix your program.

It is a problem for tool support; one of the reasons why Java and C# has better editors.

It's only a problem if your tools are done the wrong way. The proper tools can benefit from the macros instead. Of course, some discipline in how macros are implemented is required.

Re: Why didn't Common Lisp fix the world?

#85

Post by dunkelheit »

sklogic wrote: post #81
dunkelheit wrote: post #77

Earlier quoted context omitted.

That is a brave statement to make. How about you write a Lisp program that (serving as a perfect embodiment of "code is data" philosophy) takes another Lisp program as input and determines whether it would terminate? That would be just a handful of Lisp macros, right?

Now you're talking about an infinite complexity. It cannot be reduced no matter how hard you try. It has nothing to do with the kind of complexity that software engineering have to deal with. But, for all things practical , yes, it's just a handful of Lisp macros. Because in most cases it worth designing your DSLs as total languages, and totality proof is totally trivial, as well as a proof of an opposite.

Now that's moving the goal posts. You then claim that I am nitpicking and Lisp eliminates not all complexity but only the complexity software engineers care about (not true either: even Lisp programs don't write themselves and someone still has to type in the letters). After that the conversation moves into wishy-washy domain of opinions which can be debated forever without ever reconciling them.

Re: Why didn't Common Lisp fix the world?

#86

Post by hga »

sklogic wrote: post #74
hga wrote: post #69

Earlier quoted context omitted.

Well, one thing I can tell you is that I've heard that much of the woe that came from the Common Lisp standard started with the line "any sufficiently advanced compiler..." in a discussion.

Are we talking about optimisations now? Or still about a compilation ? Optimisations are a totally different story. They can bring some complexity in, but the nice part is that they're totally optional and not required for solving the problem.

Minimally acceptable optimizations, because if your implementation is too slow, they're not optional.

The examples are legion; to go to another domain, look at one of the reasons the VLIW Itanium failed, except for some numeric code the compiler(s) couldn't schedule enough operations for those Very Long Instruction Words.

(Perhaps a more primary reason was that x86 code ran too slow, denying customers an easy upgrade path that due to volume sales might have resulted in more effort being put into the VLIW compilers.)

Re: Why didn't Common Lisp fix the world?

#87

Post by hga »

znpy wrote: post #82

I bought Graham's "Ansi Common Lisp" book and read it briefly, and tried to write some code as well. I also read "Successful Lisp" briefly. Hoping to give constructive feedback and not to start a flame, here are some opinions/impressions. Please note that : 1. These are mostly impressions, not complete opinions. 2. I am only talking about Common Lisp. I am not talking about Scheme, Clojure or other stuff. Ok then: 1)…

Consider this: it is a fact that MIT introductory programming class switched from Scheme to Python because among other things, students were spending too much time reading libraries manuals and implementation references instead of writing code.

Nope, the decision was entirely political, driven by panic when post-dot.com crash enrollment dropped by more than half after being a steady 40% of the undergraduates for decades.

And I believe your specifics are entirely wrong, but I don't know exactly how the course evolved, e.g. they threw in a couple of weeks of OO that isn't in SICP as that became popular. But at least in the beginning of the course, it's all self-contained in the book.

Much of the rest of what you say is spot on, and are some of the reasons I gave up on mainline/Common Lisp 30+ years ago.

Re: Why didn't Common Lisp fix the world?

#88

Post by sklogic »

dunkelheit wrote: post #85
sklogic wrote: post #81

Earlier quoted context omitted.

Now you're talking about an infinite complexity. It cannot be reduced no matter how hard you try. It has nothing to do with the kind of complexity that software engineering have to deal with. But, for all things practical , yes, it's just a handful of Lisp macros. Because in most cases it worth designing your DSLs as total languages, and totality proof is totally trivial, as well as a proof of an opposite.

Now that's moving the goal posts. You then claim that I am nitpicking and Lisp eliminates not all complexity but only the complexity software engineers care about (not true either: even Lisp programs don't write themselves and someone still has to type in the letters). After that the conversation moves into wishy-washy domain of opinions which can be debated forever without ever reconciling them.

Pay attention to what you're answering to. It was you who moved the goal posts.

> there are well known techniques for eliminating any complexity you can find in a chain of compiler transforms,

Can you imagine finding a working termination proof in a compiler pipeline and finding yourself in a dire need of simplifying this complexity down to something manageable?

Re: Why didn't Common Lisp fix the world?

#89

Post by sklogic »

hga wrote: post #86
sklogic wrote: post #74

Earlier quoted context omitted.

Are we talking about optimisations now? Or still about a compilation ? Optimisations are a totally different story. They can bring some complexity in, but the nice part is that they're totally optional and not required for solving the problem.

Minimally acceptable optimizations, because if your implementation is too slow, they're not optional. The examples are legion; to go to another domain, look at one of the reasons the VLIW Itanium failed, except for some numeric code the compiler(s) couldn't schedule enough operations for those Very Long Instruction Words. (Perhaps a more primary reason was that x86 code ran too slow, denying customers an easy upgrade…

Remember, we're not talking about high performance C compilers and all that here.

We're talking about the programming paradigm where everything is a compiler. Network protocol parsing is a form of compilation, all file formats parsing is a form of compilation, reacting to the UI events is a form of a compilation, processing data in whatever ways is a form of a compilation.

Yet, you can only invent any optimisations at all for a small subset of compiler transformations, so for most of the cases optimisation is just totally irrelevant.

As for the minimally acceptable optimisations, they're all trivial anyway. What you'd normally expect to see in most of the IRs is: constant propagation/folding (trivial), ADCE (trivial), algebraic simplification (trivial, no matter how ugly it is in, say, instcombine pass in LLVM - they're just doing it wrong), partial evaluation (trivial), inlining (trivial), backtracking for the latter two (trivial, but rarely seen, most would resort to awfully complex heuristics instead), CSE (trivial), escape analysis (trivial).

What is not trivial is the stuff you'd rarely need in the high level languages, and this paradigm is all about the high level languages indeed.

Not trivial: loop fusion, polyhedral analysis, vectorisation, and, finally, everything related to the code generation: instruction selection, register allocation, instruction scheduling, VLIW packing, all that.

You'll never see this stuff in any high level domain specific language - you already have a common low level backend to take care of it for you anyway.

Re: Why didn't Common Lisp fix the world?

#90

Post by sklogic »

chvid wrote: post #73
adwf wrote: post #66

Earlier quoted context omitted.

That would be true if we were talking about normal languages eval'ing strings. Lisp on the other hand treats the code as data and has the full compiler available at runtime. It can check types at both runtime and compile time, and it will still compile it down to nice machine code on the fly. Lisp eval is not the same as other languages, you use it implicitly all the time. Any occurence of macros or something like `(…

Parsing Lisp is not so hard, but as you said. It requires a JIT compiler or an interpreter. There are still some platforms/scenarios where that is not wanted.

sbcl has `eval`, but it does not have a JIT compiler or an interpreter.
Post reply on HN