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

61–70 of 125 posts

Re: Lisp: More is less

#61

Post by d0m »

Myk267 wrote: post #59
d0m wrote: post #26

Earlier quoted context omitted.

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…

"Part of it is due to the very strict Python standard of coding." I don't know about that. Good code is good code. It's sort of one of those, "I'll know it when I see it" things. The ease of which you can code classes for the sake of classes in Python can make some really hairy code out of what should be simple programs. Was that necessarily the 'one right way to do it'? Who's to say. And all the static analysis tool…

Take Javascript, if you want to iterate over a list, you have dozen of ways. One could hardly argue that one is better. Some prefer using built-in foreach, some .map, some underscore, some the native for(). As you say, great code is great code and as long as it's well written and understandable, it's good Javascript.

In python things are a bit different. There are agreed-on ways to do certain patterns. If someone uses a different method, I.e. [1,2,3].foreach(lambda x: something(x)) pythonist will all agree that this is no pep-8 standard and that for readability and maintenability's sake it should be changed to for x in [1,2,3]: something(x).

Another way to say that.. very good pythonists will agree on a "best way to do it", whereas in Lisp, very good lispers will agree that "both ways are very good and clean".

With all that being said, that's why I prefer to jump into a large python project (considering that pep 8 is strictly being used).

Re: Lisp: More is less

#62

Post by rtpg »

innguest wrote: post #60
rtpg wrote: post #56

Earlier quoted context omitted.

didn't even know that. BTW the people on #haskell are quite active, and nice :) (maybe a pointless counter-example, I once went onto #ruby, and asked about an easy way to make a function name refer to a function( to be able to do things like list map f easily, without the superflous do |x| f x end ), and I got yelled at because I was trying to write "non-ruby code".

The Ruby community is very close-minded. I've been a victim of that behavior in #ruby as well. If you asked an equivalent question on #ror (the Rails channel) you'd get more than yelled at - no one would take you seriously from that point on. To answer your question, because methods aren't first-class in Ruby, you can't pass them around the way you want to. I've decided I don't want my languages telling me what I can…

I figured that out later on, that I should probably not think of ruby as functional ( my brain hardwires no parentheses languages to functional languages I think). After which the experience becomes slightly less frustrating

Re: Lisp: More is less

#63

Post by drblast »

What I value most in a programming language:

1. I'm able to concisely express what I'm trying to do.

2. I never, never have to copy/paste or otherwise do repetitive work because one case is slightly different than another.

Number 2 is probably more important to me. It's why I'm happy when a language has first class functions and closures, and why I'm unhappy when the language is Java.

I think the cases where you can't modularize things enough such that you have to essentially include two version of the same thing is a programming language expressiveness failure.

Finally, I strongly disagree that programmers aren't or shouldn't be language designers. Nearly every worthwhile program I've written that people have used has needed an API or scripting/query language. So any language had damn well be suited to writing a parser. LISP fills that bill too.

If LISP has shortcomings, its expressiveness and power are not them. If you want to complain about a lack of consistent implementations, lack of libraries, difficulty interoperating with any other language, lack of a canonical free implementation, no decent supported GUI toolkit, or the impossibility of distributing binaries real people can use without spending thousand of dollars on a professional LISP environment, go right ahead.

Re: Lisp: More is less

#64

Post by wwkeyboard »

As a tangent, we still don't have a good definition of 'large' software project. Clojure hasn't been around for 8 years, so we don't have 10 or 15 year projects to look at. And I think we'd have heard if there was a 1500 developer team using it. It sounds absurd, but there have been plenty of projects this size and they 'work' insomuch as they generate enough revenue the sponsoring companies paid for them to get that size.

Re: Lisp: More is less

#65

Post by m0skit0 »

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…

By "simplicity" they mostly mean "what I'm used to". Same applies for people calling "Windows simpler than Linux". It's the same argument over and over: illegibility (because you're not used to it), too much power to handle (because you're not used to it)...

Re: Lisp: More is less

#66

Post by m0skit0 »

"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" I don't see how OOP is "fairly simple", "modeling reality" and "compatible with how beings do it". How inheritance, polymorphism, interfaces, classes, objects, types is a "simple" model of reality? You're simply used to think OOP way, that's all.

Re: Lisp: More is less

#68

Post by vorg »

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…

> > just restrict the use of macros

> Precisely.

Enabling macros is the sole justification for the homoiconic syntax, which is often cited as the most offputting feature of lisps for uptake by large programmer teams. If you're going to have two "editions" of Clojure, one with the full feature set for language designers, and the other a more restricted sans-defmacro one for more general programmer use, then why not give that restricted one a more friendly syntax as well, or even just get them to use Java, Python, or whatever.

Re: Lisp: More is less

#69

Post by brandonbloom »

vorg wrote: post #68
brandonbloom wrote: post #22

Earlier quoted context omitted.

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

> > just restrict the use of macros > Precisely. Enabling macros is the sole justification for the homoiconic syntax, which is often cited as the most offputting feature of lisps for uptake by large programmer teams. If you're going to have two "editions" of Clojure, one with the full feature set for language designers, and the other a more restricted sans-defmacro one for more general programmer use, then why not gi…

1) I genuinely prefer variadic prefix notation, even in the absence of homoiconicity.

2) Restricted does not mean "banned". It means that they need to be justified and subject to expert scrutiny.

3) Even if you never write a macro of your own, you're a beneficiary of the syntactic sugar and can leverage macroexpand to demystify otherwise opaque language constructs.

Re: Lisp: More is less

#70

Post by 147 »

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…

How are you liking Racket instead of Rails? I'm assuming you're using it for web development.

I was a Rails dev that moved to Clojure and I don't know much about Racket at all, but how is the library situation? Of course in Clojure if I ever need something I can count on being able to find it in Java and interop with it.

Post reply on HN