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

Ask HN: Could a Lisp be Blub?

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 30 posts

Re: Ask HN: Could a Lisp be Blub?

#11

Post by mark_h »

iman wrote: post #8

There are languages that have useful features that lisp lacks. For example, Haskell has lazy evaluation and automatic compiler generated program correctness proofs (a decent type system). Then there are languages that try to be even more powerful than Haskell, for example Epigram, which has dependent types. Lazy evaluation is probably the language feature that is most mainstream that lisp lacks. For those not familia…

Clojure has lazy versions of most of the collections API (or possibly it defaults to laziness now, it has been a little while since I last played with it). They're implemented using macros of course, but they get you surprisingly far. I have a bit of a Haskell background, and was doing the Project Euler problems in Clojure frequently using the lazy stream processing idiom you just described.

Re: Ask HN: Could a Lisp be Blub?

#12

Post by thunk »

pg wrote: post #10
iman wrote: post #8

There are languages that have useful features that lisp lacks. For example, Haskell has lazy evaluation and automatic compiler generated program correctness proofs (a decent type system). Then there are languages that try to be even more powerful than Haskell, for example Epigram, which has dependent types. Lazy evaluation is probably the language feature that is most mainstream that lisp lacks. For those not familia…

I occasionally think of adding lazy evaluation to Arc. I could make news.arc about 5 lines shorter if I had it. It could be that there are other types of code where it would make a more significant difference, though.

The biggest benefit of having it would probably turn out to be being able to say Arc has it in conversations like this. That might be a bigger deal than it seems, although I feel dirty suggesting the "nitpick preemption" philosophy of language design.

Re: Ask HN: Could a Lisp be Blub?

#13

Post by jerf »

How could you cripple such things? Well, first, culture. The primary difference between Ruby and Python is culture; the languages enable virtually identical styles of programming in practice (spelled slightly differently, but basically the same), but the cultures encourage different practices, such as how they feel about monkeypatching. Neither of these cultures "cripples" the language, I just use this as an example of the power of culture. You could cripple a powerful language with some sort of powerful pedagogical culture that made the powerful idioms verboten (because they're "too complicated", "unmaintainable", etc.).

A good language should make the right thing easier than the wrong thing. You could cripple a language that has all those bullet-point features by making putting hoops to jump through in the way of using macros or first-class functions. A klunky syntax, some sort of extra typing information to be manually added at every macro invocation, extra-verbose S-expressions, etc.

A REPL could be crippled by making it less than a full REPL, such that there are things that you still have to build modules for. See Erlang's REPL, which is mostly nice, except you can't define new records or do a handful of other useful things.

The most likely way this could happen is a language that tries to be LISP while still looking as much like C(++/#) as possible, and bringing over impedance-mismatched concepts better left in C(++/#). The second-most likely would be in some way constraining the power so as not to scare programmers or so as to avoid some "trap"; for instance, see Java's dropping of multiple inheritance. Thus, even though Java has "OO", it is less powerful than a Java that had MI too. You might have a "first class function" that is somehow limited to be less useful. (Perhaps you get first-class functions, but themselves are not allowed to return functions, only "values".)

Do not underestimate the power of language implementors to cripple a language, both intentionally and otherwise.

Re: Ask HN: Could a Lisp be Blub?

#14

Post by jerf »

iman wrote: post #8

There are languages that have useful features that lisp lacks. For example, Haskell has lazy evaluation and automatic compiler generated program correctness proofs (a decent type system). Then there are languages that try to be even more powerful than Haskell, for example Epigram, which has dependent types. Lazy evaluation is probably the language feature that is most mainstream that lisp lacks. For those not familia…

Lazy evaluation is neat, but I can see it going into a lisp without really "breaking" the lisp.

What I see breaking in a lisp are the language features that come from limitations in the language. There's two ways to look at a language's power: What it enables you to do directly, and what it enables you to do by taking things away (in the form of constraints that are enforced on your code) and what it builds on top of that.

Looked at the second way, there are powerful things that can be built in some languages that Lisp is actually less-well suited for, because it is practically and philosophically opposed to constraints. Haskell's type system is actually the thing I see that would be the hardest to implement in Lisp. Haskell's type system allows the type system to say not just what a function returns, but in many ways, exactly what the function does and how it does it. If you have a function of type Int -> Int, then you know, with only a shadow of a doubt (unsafePerformIO), that the function does no IO, or, in fact, anything else except somehow manipulate an Int. (And as the doubt's name implies, you are taking your fate into your hands if you use that.)

Upon this foundation of constraints, Haskell can build in some features that Lisps can not, such as its safe implementation of STM. It's not that Lisp couldn't have something like a STM system, it's that it lacks the ability to make and use such strong guarantees about what is in an STM transaction that Haskell could, and I think you end up seeing a "reversion to the mean" effect where if the constraints are not enforced, they end up violated both accidentally and deliberately.

Similarly, almost every cute trick the Haskell type system allows, while certainly abstractly doable in Lisp, is not enforcable and therefore abstractions further layered on top of that are correspondingly less safe.

It is a viable opinion to say that you trust your programmer and that you feel that you should not care about such things; I'm not actually advocating these features in this post. (I'm still ambivalent myself, still gathering the data to have an opinion.) It's just that unless I'm very much mistaken, it's effectively impossible to get guarantees about the properties of closures passed in to your code in Lisp in the way that Haskell does. (You can examine the code before executing it, but along with the general tediousness of trying to prove these properties, I wouldn't be surprised you run afoul of Rice's theorem. It certainly seems unlikely it could be practical.)

When features are built on doing powerful things in arbitrary combinations, Lisp is one of the go-to languages. When you have features that have to be built on restrictions in the language (and not trivial ones, but tricky ones), Lisp has a problem. (Again, unless I'm very much mistaken.)

I don't think Haskell "blubs" Lisp, but I think it makes a very good case that the ordering of language power doesn't have a single apex in Lisp. Lisp may dominate in the "more power" arena, but that's not the only arena around.

Re: Ask HN: Could a Lisp be Blub?

#15

Post by gruseom »

thunk wrote: post #12
pg wrote: post #10

Earlier quoted context omitted.

I occasionally think of adding lazy evaluation to Arc. I could make news.arc about 5 lines shorter if I had it. It could be that there are other types of code where it would make a more significant difference, though.

The biggest benefit of having it would probably turn out to be being able to say Arc has it in conversations like this. That might be a bigger deal than it seems, although I feel dirty suggesting the "nitpick preemption" philosophy of language design.

This is a significant psychological point that comes up in a lot of different contexts (sales contexts, mostly). But in the programming language context, I think it's a symptom of the dysfunction that the vast majority of discussions are at a superficial level (code snippets and theoretical features) and have little to do with building real systems over time.

Re: Ask HN: Could a Lisp be Blub?

#16

Post by gruseom »

jerf wrote: post #14
iman wrote: post #8

There are languages that have useful features that lisp lacks. For example, Haskell has lazy evaluation and automatic compiler generated program correctness proofs (a decent type system). Then there are languages that try to be even more powerful than Haskell, for example Epigram, which has dependent types. Lazy evaluation is probably the language feature that is most mainstream that lisp lacks. For those not familia…

Lazy evaluation is neat, but I can see it going into a lisp without really "breaking" the lisp. What I see breaking in a lisp are the language features that come from limitations in the language. There's two ways to look at a language's power: What it enables you to do directly, and what it enables you to do by taking things away (in the form of constraints that are enforced on your code) and what it builds on top of…

There are (at least) two good points here: language power is a partial ordering not a total one, and Hindley-Milner type systems are probably the most prominent candidate for a purely language-level construct that Lisp wouldn't naturally extend to.

Re: Ask HN: Could a Lisp be Blub?

#17

Post by mahmud »

Clojure risks heading that way; for all its beauty, clojure is losing its culture fast! You can already see Design Patterns being shoehorned on top of it, Java programmers will embrace it and extend it in earnest.

The sort of applications being written with the language are a huge factor in making it attractive to other users. All the truly beautiful languages had operating systems or huge desktop applications written in them; you used the language to extend something already powerful. It rewards your programming. Clojure will most likely become a server-side programming language, with little user interaction.

Re: Ask HN: Could a Lisp be Blub?

#19

Post by thunk »

gruseom wrote: post #15
thunk wrote: post #12

Earlier quoted context omitted.

The biggest benefit of having it would probably turn out to be being able to say Arc has it in conversations like this. That might be a bigger deal than it seems, although I feel dirty suggesting the "nitpick preemption" philosophy of language design.

This is a significant psychological point that comes up in a lot of different contexts (sales contexts, mostly). But in the programming language context, I think it's a symptom of the dysfunction that the vast majority of discussions are at a superficial level (code snippets and theoretical features) and have little to do with building real systems over time.

That's true, although before we get too smug about those "out of touch with the realities of building software systems" academics, we should remember that often those seemingly absurd and fanciful little corners turn out to be serious game changers. Lisp itself, for instance.

Re: Ask HN: Could a Lisp be Blub?

#20

Post by prospero »

mahmud wrote: post #17

Clojure risks heading that way; for all its beauty, clojure is losing its culture fast! You can already see Design Patterns being shoehorned on top of it, Java programmers will embrace it and extend it in earnest. The sort of applications being written with the language are a huge factor in making it attractive to other users. All the truly beautiful languages had operating systems or huge desktop applications writte…

for all its beauty, clojure is losing its culture fast! You can already see Design Patterns being shoehorned on top of it, Java programmers will embrace it and extend it in earnest.

Can you give an example of this?

Post reply on HN