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

Lisp: More is less

jameso.be

Post reply on HN
Print view View original

21–30 of 125 posts

Re: Lisp: More is less

#21

Post by vezzy-fnord »

nickik wrote: post #17

> OOP is widely-used and easily comprehended because it is a fairly simple way of modeling reality that is compatible with how human beings do it. Have we not learn by now that these systems are not easy to reason about. Are not all the things one first learns (ie Animal -> Dog) bullshit and should be avoided. Why is it in every good OO book that, composition is better then inheritance. Why is every OO book full of e…

To add on to the OO counterargument, here's a thorough debunking of object-oriented programming: http://www.geocities.com/tablizer/myths.htm

Note that this refers to the Nygaard interpretation of OOP, which is also the most widely used: rigorously class-based and in many ways retaining a procedural nature.

Smalltalk and Eiffel are different beasts, but they never really made it.

Re: Lisp: More is less

#22

Post by brandonbloom »

lkrubner wrote: post #5

Most of the complaints in this article boil down to "macros are too powerful." I think this is the key part of the argument: "A smart programmer is not necessarily an empathetic language designer; they are occupations that require different skillsets. Giving any programmer on your team the ability to arbitrarily extend the compiler can lead to a bevy of strange syntax and hard-to-debug idiosyncrasies." There are at l…

> just restrict the use of macros

Precisely. The problem with the lisps of old was entirely cultural. People would go do crazy wild things and then not bother to interoperate with the rest of the world. Meanwhile, the Clojure community has lots of experimentation, but ultimately produces a large number of stable, quality, reusable libraries.

Large scale C++ teams often require approval for operator overloading or "dangerous" features. Can easily do the same for macros. Moreover, we now have distributed version control and can utilize lieutenant workflows, so we can dispatch with this silly "commit bit" notion that means bad code sneaks in past domain experts with ease.

Re: Lisp: More is less

#23

Post by gleenn »

gruseom wrote: post #3

This post repeats two memes that float around the programming language space. One is: "it's so powerful that it's bad". The other is: "it's ok, but not for large projects". I don't think I've ever seen any evidence attached to either. (If the OP contains any, I missed it.) But they're the sort of things that sound plausible and have more gravitas than "Here are my current preferences", so they get repeated, and no do…

> it's so powerful that it's bad

I had the pleasure of using Cascalog in production at work, which is written in Clojure. While it was in fact written by some very smart people, we had a very difficult time using some of its constructs that were very cleverly abstracted away behind macros.

The problem was that it felt nearly impossible to debug problems we had because of the long, impossible stack traces. Further, trying to get another very smart programmer to understand why some functions behaved in one way and some behaved in very different was very hard to convey. I'll reiterate that I thought the other guy I was working with was really smart, and I'm at least not an idiot, and we both felt like we had a really hard time unwrapping what the code was doing.

On the flip side, if it were written in Java (I think some parts are actually but more under the hood), you could point at the code and say "That's where the map function gets called on all the workers" (Cascalog is for Hadoop), or run the code and get some kind of stack trace where you could even begin to start figuring out what was going on. We weren't even doing anything cutting edge.

For me, I love the academic/fun endeavor. I have wasted countless hours playing and learning. But if you asked me if I would base any critical part of my production app on Clojure, especially when there are more than a couple people who weren't Lisp experts, I would have a really hard time justifying it after what I saw when I tried.

Re: Lisp: More is less

#24

Post by philh »

_delirium wrote: post #9
lkrubner wrote: post #5

Most of the complaints in this article boil down to "macros are too powerful." I think this is the key part of the argument: "A smart programmer is not necessarily an empathetic language designer; they are occupations that require different skillsets. Giving any programmer on your team the ability to arbitrarily extend the compiler can lead to a bevy of strange syntax and hard-to-debug idiosyncrasies." There are at l…

I mostly agree but fwiw, the usual counterargument on #2 is that those should be language facilities instead, which allows them to be carefully designed and then taken advantage of by the compiler. For example, in Racket (formerly PLT Scheme) you have: http://docs.racket-lang.org/guide/contracts.html

I'm not sure how well that specific example works. Are contracts built in to the language on a fundamental level, or are they just part of the standard library? Given that they're not included in racket/base, and given how flexible racket's core is, I would guess the latter, but I'm not sure.

Re: Lisp: More is less

#25

Post by lmkg »

lkrubner wrote: post #5

Most of the complaints in this article boil down to "macros are too powerful." I think this is the key part of the argument: "A smart programmer is not necessarily an empathetic language designer; they are occupations that require different skillsets. Giving any programmer on your team the ability to arbitrarily extend the compiler can lead to a bevy of strange syntax and hard-to-debug idiosyncrasies." There are at l…

The quote you pulled out boils down to something even simpler than that: People who are good at programming aren't necessarily good at designing API's.

I think there's a kernel of a valid point underneath. A macro necessarily has a larger (potential) interface surface than a function, because there's less you can take for granted about how it interacts with the rest of your code. And I agree, API design is a specialized skill that requires quite a bit of thought.

But I agree with your conclusion more than his: This is to take care with macros, not a reason to shun them altogether.

Re: Lisp: More is less

#26

Post by d0m »

mildtrepidation wrote: post #2

[edit: While I was typing this the title was changed. It was previously Why Lisp isn't (and shouldn't be) widely used in industry , which colors my comment.] This points out some very real potential dangers of large-scale collaboration with Clojure (and presumably some or many other Lisps/Lisp-likes). However, I think the conclusion is overstated. Yes, based on what's provided, it may take more discipline and better,…

Although I love lisps, I'd rather jump in a very large Python project than a lisp one. Jumping into someone else Lisp code feels like a jungle to me. Jumping into someone else's Python code feels like my old good slipper. Part of it is due to the very strict Python standard of coding. But I think it's primarily because of the "One good way to do it" mentality. On the other hand, I feel telling a lisp programmer "This is the right way to do this" would be like an insult to their creativity. Obviously, it's not as much black and white, but hopefully you understand what I mean.

Re: Lisp: More is less

#27

Post by [deleted] »

lmkg wrote: post #25
lkrubner wrote: post #5

Most of the complaints in this article boil down to "macros are too powerful." I think this is the key part of the argument: "A smart programmer is not necessarily an empathetic language designer; they are occupations that require different skillsets. Giving any programmer on your team the ability to arbitrarily extend the compiler can lead to a bevy of strange syntax and hard-to-debug idiosyncrasies." There are at l…

The quote you pulled out boils down to something even simpler than that: People who are good at programming aren't necessarily good at designing API's. I think there's a kernel of a valid point underneath. A macro necessarily has a larger (potential) interface surface than a function, because there's less you can take for granted about how it interacts with the rest of your code. And I agree, API design is a speciali…

[deleted]

Re: Lisp: More is less

#28

Post by lispm »

brandonbloom wrote: post #22
lkrubner wrote: post #5

Most of the complaints in this article boil down to "macros are too powerful." I think this is the key part of the argument: "A smart programmer is not necessarily an empathetic language designer; they are occupations that require different skillsets. Giving any programmer on your team the ability to arbitrarily extend the compiler can lead to a bevy of strange syntax and hard-to-debug idiosyncrasies." There are at l…

> just restrict the use of macros Precisely. The problem with the lisps of old was entirely cultural. People would go do crazy wild things and then not bother to interoperate with the rest of the world. Meanwhile, the Clojure community has lots of experimentation, but ultimately produces a large number of stable, quality, reusable libraries. Large scale C++ teams often require approval for operator overloading or "da…

Lisp has had widely different uses:

* a teaching language

* a research tool

* an application programming language

Lisp has been already in times when the technology you are using today was still under invention. Lisp existed before Smalltalk, C, C++, Java, ... thus often technology was developed in an unstable surrounding where inventions are just being made. Lisp also had to keep track of the changing IT landscape. During the 70s people were using DEC PDP computers.

Thus you find evidence for everything.

There are well-documented stable, nicely reusable, code bases in Lisp.

Clojure is most of the time married to a small eco-system: Java/JVM.

Lisp has seen and supported many more eco-systems and will see even more in the future.

Re: Lisp: More is less

#29

Post by lispm »

d0m wrote: post #26
mildtrepidation wrote: post #2

[edit: While I was typing this the title was changed. It was previously Why Lisp isn't (and shouldn't be) widely used in industry , which colors my comment.] This points out some very real potential dangers of large-scale collaboration with Clojure (and presumably some or many other Lisps/Lisp-likes). However, I think the conclusion is overstated. Yes, based on what's provided, it may take more discipline and better,…

Although I love lisps, I'd rather jump in a very large Python project than a lisp one. Jumping into someone else Lisp code feels like a jungle to me. Jumping into someone else's Python code feels like my old good slipper. Part of it is due to the very strict Python standard of coding. But I think it's primarily because of the "One good way to do it" mentality. On the other hand, I feel telling a lisp programmer " Thi…

I hear a lot of bad things about large Java code bases.
Post reply on HN