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

Lisp is sin

blogs.msdn.com

Post reply on HN
Print view View original

31–40 of 60 posts

Re: Lisp is sin

#31

Post by StrawberryFrog »

justinhj wrote: post #27

Compare the C# version of memoize to this one (from On Lisp). The C# one looks very long and ugly in comparison, so I hope it isn't the new Common Lisp. (defun memoize (fn) (let ((cache (make-hash-table :test #'equal))) #'(lambda (&rest args) (multiple-value-bind (val win) (gethash args cache) (if win val (setf (gethash args cache) (apply fn args)))))))

Code in unfamiliar languages always looks ugly. I know c# but not Lisp, and that just looks like ugly brackets salad to me. It can't help that your formatting as AWOL.

So your statement that The C# one looks very long and ugly is entirely subjective.

Re: Lisp is sin

#32

Post by rplevy »

This article is a couple years old. The author probably would have tried Clojure for his foray into Lisp had this been written today.

Re: Lisp is sin

#33

Post by anonjon »

TallGuyShort wrote: post #6

>> one of the driving forces was to let non-geeks build software He makes the extremely important point that the technology has failed if ordinary people can't use it to get their own work done. However, I've personally seen a project where the aim was essentially to let non-programmers program, and the result was horrendously messy. In large part, I think that's because a lot of people ended up developing that had n…

I agree, its kind of like asking the illiterate to read and write, you'll get something, but it won't be Dickens or Proust. (It probably won't even be Tom Clancy).

Re: Lisp is sin

#34

Post by joechung »

radu_floricica wrote: post #2

> I know that if I write a C# program today that it can be called by a Boo program which in turn can be called by IronPython. This is another reason we should be grateful for Clojure. It will have a .Net implementation soon, too.

I thought Rich Hickey abandoned the .NET version of Clojure a couple years ago?

Re: Lisp is sin

#35

Post by anonjon »

semmons wrote: post #4

> But I'm willing to bet that a lot more developers will be able to understand this since this is in a programming language they understand well. This is one argument I don't buy. He talks about the Mort programmers never being able to understand Lisp. I am willing to bet, any Mort programmer who looked at this C# would not be able to understand it. I'm sure they could take advantage of it, but write it themselves, I…

Agree completely.

Lisp syntax is stupidly simple, if anything it would be easier for a 'Mort' to pick up; In lisp it is pretty easy to hack together something that works.

Mort wouldn't use memoize because mort doesn't know what memoize is, and doesn't understand the theoretical basis of it (regardless of language).

The learning curve and difficulties in lisp come when you are trying to use the advanced features of the language and write efficient code.(Which isn't any different from any other language, just there are more 'advanced' features available, generally).

(Or maybe the learning curve comes when you try to install external libraries, which is my biggest frustration.. at times you struggle longer getting everything setup properly than you would have implementing the library from scratch).

Re: Lisp is sin

#36

Post by lispm »

snprbob86 wrote: post #30
justinhj wrote: post #27

Compare the C# version of memoize to this one (from On Lisp). The C# one looks very long and ugly in comparison, so I hope it isn't the new Common Lisp. (defun memoize (fn) (let ((cache (make-hash-table :test #'equal))) #'(lambda (&rest args) (multiple-value-bind (val win) (gethash args cache) (if win val (setf (gethash args cache) (apply fn args)))))))

Lisp certainly has many advantages, but general readability is not one of them. Maybe when talking about complex algorithms with a sufficiently designed DSL... Here's your code reformatted: (defun memoize (fn) (let ((cache (make-hash-table :test #'equal))) #'(lambda (&rest args) (multiple-value-bind (val win) (gethash args cache) (if win val (setf (gethash args cache) (apply fn args))))))) And here is a prettier (use…

I would format the function like this:

    (defun memoize (fn)
      (let ((cache (make-hash-table :test #'equal)))
        (lambda (&rest args)
          (multiple-value-bind (val win)
                               (gethash args cache)
            (if win
              val
              (setf (gethash args cache) (apply fn args)))))))
I'm a Lisp programmer and the C# arglist is already hard to parse with lots of noise - for me.

Second I don't look for { or ( but for the block indentation, so a { on a single line does not give me enough visual clues.

The 'return arg =>' form is not obvious to me. What does it do? Where dies TReturn come from, TParam?

Why is there }; and } ?

Re: Lisp is sin

#37

Post by stefano »

snprbob86 wrote: post #30
justinhj wrote: post #27

Compare the C# version of memoize to this one (from On Lisp). The C# one looks very long and ugly in comparison, so I hope it isn't the new Common Lisp. (defun memoize (fn) (let ((cache (make-hash-table :test #'equal))) #'(lambda (&rest args) (multiple-value-bind (val win) (gethash args cache) (if win val (setf (gethash args cache) (apply fn args)))))))

Lisp certainly has many advantages, but general readability is not one of them. Maybe when talking about complex algorithms with a sufficiently designed DSL... Here's your code reformatted: (defun memoize (fn) (let ((cache (make-hash-table :test #'equal))) #'(lambda (&rest args) (multiple-value-bind (val win) (gethash args cache) (if win val (setf (gethash args cache) (apply fn args))))))) And here is a prettier (use…

I don't know C#, but it seems to me that your C# version of memoize works only for functions with exactly one argument, while the CL version works for any kind of function.

Re: Lisp is sin

#38

Post by radu_floricica »

KirinDave wrote: post #9
radu_floricica wrote: post #2

> I know that if I write a C# program today that it can be called by a Boo program which in turn can be called by IronPython. This is another reason we should be grateful for Clojure. It will have a .Net implementation soon, too.

I see two problems with this statement: 1. This only works if you're willing to seclude yourself in the Microsoft Yurt and never leave. Technical benefits aside, history has shown MS is not afraid to abandon projects. It's a dangerous position to take, in my opinion. And I sincerely doubt a port of Clojure to .NET would result in a 0-difference result. We're back to the exact same problem that plagues other lisp impl…

What I meant was now you have an ecology of languages on the jvm (Clojure, JRuby, JPython, Scala, Groovy...), and on top of this a .NET port is in the works. Sorry if I was a bit unclear.

Re: Lisp is sin

#39

Post by radu_floricica »

joechung wrote: post #34
radu_floricica wrote: post #2

> I know that if I write a C# program today that it can be called by a Boo program which in turn can be called by IronPython. This is another reason we should be grateful for Clojure. It will have a .Net implementation soon, too.

I thought Rich Hickey abandoned the .NET version of Clojure a couple years ago?

Yes, but it's alive again. Though I'm more excited about the clojure-in-clojure thing - it will eventually make it easily portable on a whole lot of platforms.

Re: Lisp is sin

#40

Post by KirinDave »

tnovelli wrote: post #25
KirinDave wrote: post #19

Earlier quoted context omitted.

Your resources are pretty old, the "crisis" of car/cadr is just not there with modern, updated lisp implementations like PLT Scheme. PLT Scheme is competitive in every way with Python and Ruby, I don't know why people keep ignoring it.

Umm... what's this scheme_make_pair(car,cdr) function in plt/src/mzscheme/src/list.c? That's a wart (the crisis is in my mind :-) It doesn't have to be that way: Clojure has abstract sequence types, with cons/car/cdr wrappers in case you want them.

I fail to see how having a linked list datatype is a crisis. Use vectors if you don't like them. You can write a very large amount of complex, fully-functional scheme code without ever typing in any expression matching "c[ad]+r". PLT Scheme also comes with a host of sequence-agnostic (or sequence aware for performance) comprehensions:

Please refer to: http://doc.plt-scheme.org/guide/for.html

Post reply on HN