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

91–100 of 127 posts

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

#91

Post by sklogic »

adwf wrote: post #66
chvid wrote: post #41

Earlier quoted context omitted.

If a language has an eval construct it is hard/impossible to reason about types, security and correctness. It also makes it hard to compile it to machine code.

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.

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

#92

Post by escherize »

jordigh wrote: post #59
escherize wrote: post #46

Earlier quoted context omitted.

I agree it's hard to write lisp without a proper editor. Having seen the light I just can't go back now. The power, ease, and simplicity are not something I've experienced with non lisps.

I don't know much about Lisp, but at ILC 2014 [1] there were about 40 participants. In a show of hands, absolutely all of them used Emacs to write their Lisp. I've never seen Emacs unanimity anywhere else. -- http://ilc2014.iro.umontreal.ca/

Incedentally I also use Emacs for editing lisp. (emacs lisp and Clojure.) Learning the hotkeys/concepts behind structural editing of lisp code was life changing metamorphasis, but quite difficult overall. There's been some fantastic work done by the Parinfer [1] team to bring the awesomeness of structural editing of lisp to the masses. The basic idea is that your parenthesis should infer where they belong by way of your indentation.

I installed Parinfer it on my project: CLJSFiddle[2], and it's not what I'm used to and doesn't have everything but for a novice it is highly usable - check it out!

[1] https://shaunlebron.github.io/parinfer/ [2] http://cljsfiddle.com

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

#93

Post by jeffreyrogers »

sklogic wrote: post #63
jeffreyrogers wrote: post #52

Earlier quoted context omitted.

Honestly, I don't get the fuss about macros. I haven't seen many (any?) use cases for them, where they don't make the code harder to understand while doing something that isn't already straightforward in the base language.

> Honestly, I don't get the fuss about macros. DSLs are an ultimate solution. And DSLs are best implemented with macros. > where they don't make the code harder to understand Macros are there to make code easier to understand. I just explained it in detail elsewhere: https://news.ycombinator.com/item?id=11705170

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

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

#94

Post by sklogic »

jeffreyrogers wrote: post #93
sklogic wrote: post #63

Earlier quoted context omitted.

> Honestly, I don't get the fuss about macros. DSLs are an ultimate solution. And DSLs are best implemented with macros. > where they don't make the code harder to understand Macros are there to make code easier to understand. I just explained it in detail elsewhere: https://news.ycombinator.com/item?id=11705170

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.

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

#95

Post by _ph_ »

starseeker wrote: post #26

It lacks a graphical application development framework that's portable and usable. Java eventually solved this problem (more or less) but neither Garnet nor CLIM ever reached a level where most Gtk/Qt/* programmers would seriously consider using them. Web front ends are find for certain things, but for a lot of the application domains where you might consider Lisp you want a proper desktop GUI application. (This woul…

For portable and easy to use there is LTk, and of course there are bindings to Gtk and Qt. I think though, if the Lisp community were a bit larger, these bindings would see more development and more refinement.

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

#97

Post by _ph_ »

sklogic wrote: post #32
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.

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.

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

#98

Post by _ph_ »

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 types for a function call, it usually can infer the function result type and use that for further type reasoning.

Common Lisp of course has defined name spaces. They are called packages.

Yes it has eval, but I have not seen a Lisp program in years which used it. And it would be easy to lint programs so it is not used, if you had a reason to be afraid of it.

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

#99

Post by nabla9 »

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…

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

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

#100

Post by _ph_ »

chvid wrote: post #14
adwf wrote: post #11

Earlier quoted context omitted.

Eval? The entire point of Lisp macros is toying around with evalulation in a safe fashion. It's other languages that do it so dangerously that gives eval a bad name. Lisp is the shining example of how to do it right.

AFAIK macros in Lisp are turing complete and executed at compile time. This means (in principle) that there is no guarantee that a Lisp compile will ever terminate. I don't know why the OP is been down voted. Lisp is not for everyone and every application; I think that is a perfectly reasonable point of view.

It is even better. Common Lisp macros are not a special macro language, but rather plain Lisp functions, which are run at compile time. This is important, because it means, you can write proper code in your development language for macro expansion instead of some obscure macro expansion language. This makes the process of writing macros rather robust and of course powerful. But of course, this means that like any program you write, you cannot guarantee that they terminate. For real-life macros that is rather a non-issue as they usually contain just a rather few lines of mostly simple code.
Post reply on HN