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

101–110 of 125 posts

Re: Lisp: More is less

#101

Post by nickik »

Ygg2 wrote: post #96
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…

OOP isn't be all end all, and it isn't really easy to get into. But, that doesn't mean that modelling hierarchies is not necessary in some domains. E.g. DOM was a very big reason why Rust was considering adding OOP. The performance and the readability is hurt when you don't have to represent hierarchy. Article simply says that giving ALL programmers power to design language leads to bad things. Lisp, Clojure, etc. An…

Two points

1. > But, that doesn't mean that modelling hierarchies is not necessary in some domains.

Agree but the addition of full OOP seams overkill to reach this goal. Look at this clojure code:

>(derive ::rect ::shape) >(derive ::square ::rect) > (parents ::rect) -> #{:user/shape} (ancestors ::square) -> #{:user/rect :user/shape} (descendants ::shape) -> #{:user/rect :user/square}

Clojure gives you hierarchy 'À la carte'. This means that you know longer tie the two things together, it easy in clojure for example to have many diffrent hierarchy that are independent but still dont get in each others way. Modeling the same with objects is hard. Just a example, for often good reasons multiple inheritance is not allowed in most languages, however if you use hierarchy as a domain model and not as programming model you generally want it.

2.

I agree with the articles point, people should not invent there own langauges for everything, however that is a terrible reason to discard the language for 'large scale' production use. Every language has features that generally should be avoided, every language make it easy to do the wrong thing. Macros are relatively easy to understand, compared some other language features I could name. Also the effect of macros is generally local, unlike say monkey patching.

Re: Lisp: More is less

#102

Post by nickik »

gleenn wrote: post #23
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, tr…

It seams to me that if you give somebody Cascalog and native Java or any other Hadoop query language you will quickly see why macros are great.

Lets be honest nobody want to write hadoop jobs directly with Java. Clojure has a query language built in that feels natural and has the full power of the language.

Other people build things like Hive or Pig that come as comply different languages.

Re: Lisp: More is less

#103

Post by nickik »

coldtea wrote: post #95
innguest wrote: post #48

Earlier quoted context omitted.

"Well, were are the sucesfull large projects written in Lisp[...]? How many are they compared to other languages?" In our field, tools get chosen not by merit but by what's the current fad. It's unfortunate, but this fact makes those two questions unhelpful in moving the discussion forward.

> In our field, tools get chosen not by merit but by what's the current fad. It's unfortunate, but this fact makes those two questions unhelpful in moving the discussion forward. That's an idealistic and elitist response. Very removed from the empirical and scientific spirit, which would suggest that if people use other languages for large projects (say C/C++) there are reasons for this, besides them being "fashion v…

The idea that the core language is not what drives adoption is clear. There are a ton of other things that go into this kind of thing.

Tooling, Library, Schooling, existing base of people that know the language, CPU architecture, Memory constraints and so on. And of course all the nontechnical things like marketing.

So saying that there is not as much lisp as c++ code is not a argument that c++ is a better language.

Re: Lisp: More is less

#104

Post by Ygg2 »

nickik wrote: post #101
Ygg2 wrote: post #96

Earlier quoted context omitted.

OOP isn't be all end all, and it isn't really easy to get into. But, that doesn't mean that modelling hierarchies is not necessary in some domains. E.g. DOM was a very big reason why Rust was considering adding OOP. The performance and the readability is hurt when you don't have to represent hierarchy. Article simply says that giving ALL programmers power to design language leads to bad things. Lisp, Clojure, etc. An…

Two points 1. > But, that doesn't mean that modelling hierarchies is not necessary in some domains. Agree but the addition of full OOP seams overkill to reach this goal. Look at this clojure code: >(derive ::rect ::shape) >(derive ::square ::rect) > (parents ::rect) -> #{:user/shape} (ancestors ::square) -> #{:user/rect :user/shape} (descendants ::shape) -> #{:user/rect :user/square} Clojure gives you hierarchy 'À la…

> however that is a terrible reason to discard the language for 'large scale' production use

I think article by `large scale` means something that needs lots of people working on it. I can see how several programming departments might form their own lisp-tribes that can't speak to each other because they disagree over tiny details (or engaged in power play).

Re: Lisp: More is less

#105

Post by poppingtonic »

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 agree wholeheartedly, and would add: The usage of macros is something that can (and should) be avoided in most cases, but in order for you to learn when one should or should not write macros, you should write programs large (or complex) enough that you would need to develop a domain-specific language for the problem at hand. The creation and use of small utility functions which reflect your growing understanding of the problem will remove some of the need to write macros, until you need to perform syntactic transformations. (Note that this is the case where writing a syntactic transformation is the simplest and fastest solution to whatever problem you're working on at the time). You usually don't know when this will happen until you need to do so, but it seems to be the safer option to use a Lisp, which allows you to do that very quickly.

Re: Lisp: More is less

#107

Post by mattfenwick »

nonrecursive wrote: post #7

I remember seeing the same kind of arguments about Ruby when it began to become popular. "Ruby is too dynamic. You shouldn't use it on large-scale projects." Learning a language involves more than just learning syntax and semantics. You also need to learn how to write for maintainability. It sounds like the author is less certain about how to do that with Lisp, but instead of seeing it as a chance to learn more he wr…

Exactly. I think it's part of a larger learning pattern that people go through: one starts learning about a new tool, library, or approach, and at some point, realizes that it's not perfect -- there are some cons.

I guess there are several ways to respond at that point: one is to persevere, learning more and coming to a better understanding of what advantages and disadvantages are, as well as the appropriate use cases.

Another is to just give up and write a proscriptive blog post, possibly also with a biased, incomplete comparison of the new thing to an old thing.

The latter approach is extremely frustrating for several reasons: 1) often, the authors ignore or fail to grasp both the pros of the new thing as well as the cons of the old; 2) the proposed solution is to throw out the baby with the bathwater, instead of to figure out how to improve the new thing; 3) it provides fuel for others' confirmation bias.

Re: Lisp: More is less

#108

Post by samth »

_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

This is a terrible example for your argument, because contracts in Racket are entirely implemented as a library, thanks to the power of -- you guessed it -- macros. In fact, just about everything in Racket: the class system, the generic function system, the unit system, the type system, the serialized continuations, the pattern matcher, keyword arguments -- all of those are implemented with macros.

Re: Lisp: More is less

#109

Post by innguest »

Ygg2 wrote: post #98
innguest wrote: post #34

The author of the blogpost is pretending to be "one of us" (people that get lisp) - in "Lisp devotees (myself once included)" - but apparently they never understood it if they're still thinking that lisps' advantages "make Lisp into an unweidly, conceptual sledgehammer that’s often out of scale with the problem being solved.". The word "often" there also makes me think they're making a point without experience or pro…

> Complaints like "Clojure has nine different ways to define a symbol" are moot. Pick one that your team likes and go with it. On to the next thing. Also, to argue against Lisps by arguing against Clojure is like arguing against democracy by arguing against the Democratic Republic of the Congo. It's a valid complaint. I think the quote by John Carmack: "Everything that compiler will allow will at some point be writte…

> When you look at Lisp function, it might do what you want, or it might not. There are no guarantees it does what it claims to do.

Tests, contracts, type checking - those are the guarantees. It's not unlike any other language.

Re: Lisp: More is less

#110

Post by samth »

innguest wrote: post #51
codygman wrote: post #46

Earlier quoted context omitted.

Is your team hiring?

We're a team of 6 programmers, 3 of which code Typed Racket. We all started here as Rails devs and got tired of it. I'm always pushing to invest time in research for better solutions and our team seems to be open to that (after weeks of discussion, though - we're no heaven). Typed Racket is the solution we found after surveying the field. Our management has recently told us they believe we're now a good-sized team gi…

Since you don't have any contact info in your profile, I'd love to talk to you about your use of Typed Racket, and whether there's anything you can tell us about how to improve it. Feel free to email me at samth@cs.indiana.edu

Always happy to hear of people using my software. :)

Post reply on HN