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

On Lisp

paulgraham.com

Post reply on HN
Print view View original

91–100 of 107 posts

Re: On Lisp

#91

Post by drcode »

arohner wrote: post #36
drcode wrote: post #23

Earlier quoted context omitted.

The Clojure inventor (Rich Hickey) took most of the good ideas from arc and all the arc enthusiasts have pretty much changed horses long ago to Clojure. I think arc still has some good points related to code brevity that noone else has fully duplicated yet.

No. Clojure's first public release was before Arc's first public release. Rich was also working on Clojure for two years before release.

I stand corrected.

(and besides, most of the best ideas of Clojure are certainly due to Rich's insights)

Re: On Lisp

#92

Post by dpritchett »

minikomi wrote: post #90
dpritchett wrote: post #79

Earlier quoted context omitted.

Here's a link to an example of that coping strategy from some bad Clojure I wrote last night [1]. I sometimes use an accumulation of lets for a similar effect, but only when describing simpler transformations. The lets might look like so (warning- silly example): (defn n-squared-over-two-plus-three-as-str [n] (let [squared (* n n) halved (/ squared 2.0) added (+ halved 3)] (str added))) > (n-squared-over-two-plus-thr…

That looks like a good place to use the arrow macro http://clojuredocs.org/clojure_core/clojure.core/-%3E

Yep, that's what the link in my original post was hoping to demonstrate. I find rolling up a few lets one after the other more natural in some other situations.

Re: On Lisp

#93

Post by drcode »

unz wrote: post #25
drcode wrote: post #24

Earlier quoted context omitted.

Sounds like you're an "anything that doesn't have static compile-time typing is dangerous" kind of guy.

That's basically the consensus among professional academics on the matter. Also among well respected programmers in senior roles like Joshua Bloch and John Carmack.

The problem is static typing is applicable to only a subset of any particular programming task (in other words, even a Haskell or ML program that compiles is not necessarily guaranteed to be correct, insofar as it still may not produce the output desired by the programmer.)

Because of this, it introduces incidental complexity into a program, because it subdivides the programming task into a part that can be addressed via static typing and a part which is not purely an issue of typing.

Admittedly, in most cases this extra complexity is worth the cost (especially with the type of high performance code written by Bloch/Carmack) but at the end of the day the job of a modern computer is to make things easy for humans and not make things easy for the computer, so in the long run it's foolish to say humans need to "think like a computer" and use a static type system, instead of allowing humans to use a more natural, dynamic programming model that is more natural for us to use.

Re: On Lisp

#94

Post by dpritchett »

dpritchett wrote: post #92
minikomi wrote: post #90

Earlier quoted context omitted.

That looks like a good place to use the arrow macro http://clojuredocs.org/clojure_core/clojure.core/-%3E

Yep, that's what the link in my original post was hoping to demonstrate. I find rolling up a few lets one after the other more natural in some other situations.

Although I'm second-guessing my let example now. Lets are great for assigning names to your building blocks, but I don't really like using them to obscure my processing flow as above. Perhaps this would be a better compromise:

    (defn example [n]
      (let [square #(* % %)
            halve  #(/ % 2.0)
            add3   #(+ % 3)]
        (-> n square halve add3 str)))
    
    > (example 1)
    "3.5"

Re: On Lisp

#95

Post by chongli »

brudgers wrote: post #83
chongli wrote: post #41

Earlier quoted context omitted.

A fair amount of the examples involve mutation; a practice that Clojure discourages. A lot of the macros are very instructive, however.

Indeed, On Lisp has an excellent discussion of mutation and its use in programs written in a functional style. In discussing destructive functions, Graham describes the ways in which they can be used with reasonable safety - e.g. immediately mutating a list newly created by a mapping function. The reasons one might do so in Clojure are likely to bear similarity to those provided by Graham - speed and memory - despite…

Very good point. Mutation is extremely useful when birthing a new data structure; this is a time when it's not yet visible to the rest of the system so the danger of sharing intermediate state does not occur. Clojure has a very elegant facility for dealing with this particular scenario:

http://clojure.org/transients

Re: On Lisp

#96

Post by outworlder »

6d0debc071 wrote: post #15
officemonkey wrote: post #12

Earlier quoted context omitted.

However, if you ARE looking for a "teach yourself Lisp in 24 hours" type of book, you could do a lot worse than "Practical Common Lisp" by Peter Seibel ( http://www.amazon.com/Practical-Common-Lisp-Peter-Seibel/dp/... ).

Another rec: Land of Lisp - http://landoflisp.com/ - is also very good if you're looking to get up to speed with the absolute bare bones, so to speak, fairly quickly.

I love the comic: http://landoflisp.com/#guilds

Re: On Lisp

#97

Post by nickik »

unz wrote: post #80
nickik wrote: post #61

Earlier quoted context omitted.

People who have problems need to know about diffrent solutions. Just forcing everybody to use some langauge that supports some of these from the ground up want change that. You want a language that is flexible to expand into new fields. Also you have still not provided with these magical programming languages you are talking about. Is there any language you yourself would use? As far as I know many concepts like cont…

(you tamp down a little with your rudeness - why would multiple decades old tech be 'magical') Prolog with clpfd and chr, Mozart/Oz, Sql, Clips. Libraries like gecode, java choco. There aren't any new ways of programming that have been invented. There's basically the mathematical programming (constraint/logic/relational/linear), functional, procedural, oo, concurrent, stack. You're not going to come up with something…

I never said I invent something new. Lisp is a flexible languages that can incorparate new concepts better then other langauges. How nice is it to work if a logic programming system implmented within java compared with the same within clojure.

Re: On Lisp

#98

Post by [deleted] »

arh68 wrote: post #84
vamega wrote: post #44

Earlier quoted context omitted.

Just tried to do this, and found that the cover image size doesn't seem accurate anymore. What did you do for the cover?

Really? I just made the book and ordered it last night and the cover (the 13MB png) looked like it lined up exactly. The first cover-uploader had a 10MB limit but the other worked fine (not the design-your-own, the 1-piece-cover-designer).

[deleted]

Re: On Lisp

#99

Post by vamega »

arh68 wrote: post #84
vamega wrote: post #44

Earlier quoted context omitted.

Just tried to do this, and found that the cover image size doesn't seem accurate anymore. What did you do for the cover?

Really? I just made the book and ordered it last night and the cover (the 13MB png) looked like it lined up exactly. The first cover-uploader had a 10MB limit but the other worked fine (not the design-your-own, the 1-piece-cover-designer).

Turns out I was trying to get a hardcover. It worked just fine with a paperback.

Re: On Lisp

#100

Post by cgag »

pavelludiq wrote: post #78
eru wrote: post #55

Earlier quoted context omitted.

Oh, if your goal is to learn one of the Lisps, then don't spend any time on Common Lisp. It's old and ugly. Similar, if someone asked about a modern scripting language, I'd send them away from Perl in favour of Python or Ruby. If they goal was explicitly Perl (or Common Lisp) that would be a different thing, though.

Bullshit! In many ways Common Lisp is still a much better language than Clojure or Racket. It isn't old, compared to pretty much anything from the 80's it has aged unbelievably well, and while it has some "stale" parts you can call ugly, I find many parts of clojure or racket much uglier. All in all, it is one of the best high level languages around.

Can you give some examples of those ways?
Post reply on HN