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

101–110 of 127 posts

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

#101

Post by adwf »

sklogic wrote: post #91
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 `(…

Macros do not need to be implemented with eval, unless they're lexically scoped macros. They're just normal function, normally complied just like anything else. What is important is an incremental compilation, one top level statement at a time.

Yes, I didn't mean to imply that you needed to explicitly eval with macros. Rather that the nature of macros themselves is saying, eval this bit at compile time and that bit at run time. You are implicitly and safely doing what most languages would need an explicit eval call to do.

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

#102

Post by sklogic »

_ph_ wrote: post #97
sklogic wrote: post #32

Earlier quoted context omitted.

I don't even remember when was the last time I saw eval being used outside of the macros. And the latter is also quite a specific and rare use case.

And I don't remember when I saw an "eval" used inside a macro either. There are almost no reasons to use "eval" in any Common Lisp program.

A use case for eval inside a macro is, for example, when you want to evaluate into a constant some part of a code constructed by this macro, but you do not want to do macro staging for whatever reason.

I only did it a couple of times.

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

#103

Post by muflax »

_ph_ wrote: post #98
euske wrote: post #10

Common Lisp doesn't have type checking and well defined namespace. And it has eval. That's certainly a no go for people like me. Most programmers in the world don't have to invent/implement a radical new idea in five minutes.

Common Lisp both has strong dynamic type checking as well as optional static type checking. For example, you can declare the static types of function parameters and the return results. For a good compiler using static type declarations, look at SBCL, which makes excellent use of type information to get up to C like performance of the compiled code. It also is very good about type inferencing. So if it knows the input…

How does static type checking work in CL?

One of the most important use cases for static typing is safe modification of existing code, like during refactoring. So a typical example: I have some struct with a field of one type, say a string. I use it in a few functions, reading and writing it. Now I change the field to a different type, say an array of strings instead. I want the compiler to tell me about all the code that's now invalid. How do I do that?

I quickly wrote up a simple example of the (statically) untyped code I mentioned: http://pastebin.com/f7KWETvT (I can also write a matching example in some common static language (like C or ML), but I think it's clear what I mean.)

What type annotations do I add to make that basic use case work? So what do I add such that it first type-checks when name is just a string, then change the annotation to make name an array of strings, and get two compile-time errors because the functions are now wrong.

(Unfortunately, I only know a little bit of CL (and even then mostly due to familiarity with Emacs Lisp), so my example might be a bit un-idiomatic. Feel free to turn it into idiomatic CL if something is too weird!)

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

#104

Post by _ph_ »

muflax wrote: post #103
_ph_ wrote: post #98

Earlier quoted context omitted.

Common Lisp both has strong dynamic type checking as well as optional static type checking. For example, you can declare the static types of function parameters and the return results. For a good compiler using static type declarations, look at SBCL, which makes excellent use of type information to get up to C like performance of the compiled code. It also is very good about type inferencing. So if it knows the input…

How does static type checking work in CL? One of the most important use cases for static typing is safe modification of existing code, like during refactoring. So a typical example: I have some struct with a field of one type, say a string. I use it in a few functions, reading and writing it. Now I change the field to a different type, say an array of strings instead. I want the compiler to tell me about all the code…

If you wanted to define a type-safe person struct, you could do it with:

(defstruct person (age 0 :type fixnum) (name "" :type string))

Now every access to that person structure should be checked by the compiler. You can create a person like:

(setf p (make-person :age 7 :name "fred")) => #S(PERSON :AGE 7 :NAME "fred")

But not with: (setf p (make-person :age 7 :name 8))

which causes SBCL to error with: The value 8 is not of type STRING. [Condition of type TYPE-ERROR]

Equally, if you tried wrongly to define

(defun print-hello (person) (let ((name (string-upcase (person-age person)))) (format t "Hallo ~a!~%" name)))

You get at least a warning you should heed: ; caught WARNING: ; Asserted type (OR (VECTOR CHARACTER) (VECTOR NIL) BASE-STRING SYMBOL CHARACTER) ; conflicts with derived type (VALUES FIXNUM &OPTIONAL).

So, for refactoring, you would change the type signatures of your struct and then recompile all code to see whether the compiler generates errors/warnings.

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

#105

Post by keymone »

Grue3 wrote: post #79
keymone wrote: post #45

Earlier quoted context omitted.

> 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…

No, you're wrong. Common Lisp has hash-tables, arrays and pretty much any data structure you need. But they are not lists, they are atoms. Hence why almost everything is an atom. It's well known that linked lists are inefficient in many ways. Nobody writes programs using only lists.

absence of data literals. i'm not sure how can i state it clearer.

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

#106

Post by wry_discontent »

jeffreyrogers wrote: post #49
nabla9 wrote: post #17

"And you're right: we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren't you happy?" -- Guy Steele, Sun Microsystems Labs (about Java) http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

If Java is halfway to Lisp it's no surprise Lisp didn't take over the world.

In what world is Java halfway to lisp?

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

#107

Post by keymone »

nabla9 wrote: post #99
keymone wrote: post #45

Earlier quoted context omitted.

> 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…

It's the Lisp nomenclature that confuses you. In list everything is either atom or a list. `atom` type is equivalent to `(not cons)`. CL has plenty of native data structures including hash tables, streams, files, functions, arrays, strings, numbers, characters, structures, ... http://clhs.lisp.se/Front/Contents.htm

having functions to manipulate some data structures doesn't mean it's native to language. by that standard everything is native everywhere.

lisp stretches the meaning of "native" by power of macros, but something being possible still doesn't make it practical or convenient.

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

#108

Post by wry_discontent »

sklogic wrote: post #94
jeffreyrogers wrote: post #93

Earlier quoted context omitted.

Yes, I get theory, but I haven't seen much use for them in practice.

It puzzles me too, that people are not using the most powerful development technique. I cannot imagine not using macros for pretty much everything I do.

I've written a handful of Clojure and Emacs Lisp, but I don't get macros. How is a macro different than passing a quoted list to a function?

Maybe I just need to start slinging more lisp, but I don't see how they're particularly different from functions.

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

#109

Post by rodgerd »

hack37 wrote: post #58

Having recently been introduced to the lisp world (~1 year) it has been a revelation to me. It really changed the way I see programming and my expectations of it. I do not understand how it has not taken over the world. Background: I have ~15 years of experience in programming. In my spare time I learn new languages.

> I do not understand how it has not taken over the world.

> In my spare time I learn new languages.

A moment's reflection on the latter would explain the former.

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

#110

Post by lcall »

While Lisp had big, influential ideas, it wasn't at any time the shortest path to getting their immediate task done, for "enough" programmers. The successful languages managed to be the shortest path to "done", for more use cases.

(Which makes me think about my project for managing the world's knowledge, http://onemodel.org and how to be more practical like fortran or cobol were in their prime, and not primarily idealistic like Lisp in its prime. Hmm.)

Post reply on HN