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

41–50 of 60 posts

Re: Lisp is sin

#41

Post by KirinDave »

yummyfajitas wrote: post #24
arakyd wrote: post #7

Earlier quoted context omitted.

Yeah, he says that Lisp is too hard for the common man, and then sort of implies that this is because it doesn't use ALGOL derived syntax. I don't think that's the issue. It's not Mort who's fallen in love with ALGOL syntax, it's the CS graduate Elvis's who cling to their expensively acquired "skills" (priesthood memberships) with religious fervor (he says, as a CS student). I program in C#, and lambdas and delegates…

Something I've never gotten around to is building an algolish-lisp -> lisp translator. [a, b, c] -> '(a b c) f(x) -> (f x) These two translations are strictly syntatic modifications to lisp. Some syntactic sugar: { f(x) g(x) } -> (progn (f x) (g x) ) With these three tweaks, we are probably 90% of the way to recruiting the common man (if syntax is really what puts them off).

You can do these within PLT scheme quite easily. In fact, PLT Scheme comes with an Algol 60 reader that reads Algol 60 and turns it into scheme forms which are then executed. It's a cute trick.

http://docs.plt-scheme.org/algol60/index.html

Re: Lisp is sin

#42

Post by ynniv »

radu_floricica wrote: post #8
fogus wrote: post #5

Earlier quoted context omitted.

For some value of "soon"

http://github.com/richhickey/clojure-clr/tree/master http://blog.n01se.net/?p=41 http://clojure.org/todo As a rule, things move pretty fast in Clojure-land. And in the beginning it was dual-platform, so it's not really a new idea either.

From [ http://clojure.blip.tv/file/1313398/ ] I got the impression that Clojure on the CLR was back-burner at best. There appears to be only one committer to the CLR source base since February (possibly longer).

Re: Lisp is sin

#43

Post by snprbob86 »

lispm wrote: post #36
snprbob86 wrote: post #30

Earlier quoted context omitted.

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…

=> denotes a lambda. The left side is the args, the right side is the body. Lambdas are typically a single expression, but can have a statement body instead. A semicolon denotes the end of a statement.

  var square = x => x * x;

  var square = x => { return x * x; };

Re: Lisp is sin

#44

Post by rincewind »

yummyfajitas wrote: post #24
arakyd wrote: post #7

Earlier quoted context omitted.

Yeah, he says that Lisp is too hard for the common man, and then sort of implies that this is because it doesn't use ALGOL derived syntax. I don't think that's the issue. It's not Mort who's fallen in love with ALGOL syntax, it's the CS graduate Elvis's who cling to their expensively acquired "skills" (priesthood memberships) with religious fervor (he says, as a CS student). I program in C#, and lambdas and delegates…

Something I've never gotten around to is building an algolish-lisp -> lisp translator. [a, b, c] -> '(a b c) f(x) -> (f x) These two translations are strictly syntatic modifications to lisp. Some syntactic sugar: { f(x) g(x) } -> (progn (f x) (g x) ) With these three tweaks, we are probably 90% of the way to recruiting the common man (if syntax is really what puts them off).

I tried this with arc (worked with anarki based in arc2)

http://arclanguage.org/item?id=8172

The syntax is inspired by McCarthy's in his paper from 1958. It works, but i don't find it useful.

Re: Lisp is sin

#45

Post by snprbob86 »

stefano wrote: post #37
snprbob86 wrote: post #30

Earlier quoted context omitted.

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.

Yeaaah.... It turns out that generic methods with variable arity is a sore spot for the .NET type system. The C# and F# teams are quite aware.

The typical/recommended/easy/practical solution is to just provide another overload, pack the args into an object array, and then call the original overload; completely ignoring the problem.

Alternatively, you could do some scary things with reflection...

Re: Lisp is sin

#46

Post by arohner »

KirinDave wrote: post #18
itgoon wrote: post #14

Earlier quoted context omitted.

Horse hockey. While I know that there are a lot of horror stories (and I can tell a few), some of the most productive "programmers" I've ever met used MS Access or Excel. If you don't consider advanced usage of these applications as a form of programming, then you are illustrating the point: It is not only possible to "dumb down" programming, it is inevitable. So much so that you haven't even noticed it happening.

The only conclusion I can draw is that you didn't read my comment, because if you had you wouldn't try to counter my argument by circuitously agreeing with me. I am sure your friend was very productive with Access and Excel, and I'm sure they used advanced cryptographic protocols, solved tricky problems involving communications timing, handled cross-platform compatibility issues, programmed efficient inner rendering…

> You can't write a 3d engine in excel

You can, a guy has done it. I'm only being pedantic because this is cool if you haven't seen it:

http://www.gamasutra.com/view/feature/3563/microsoft_excel_r...

Re: Lisp is sin

#47

Post by jrockway »

yummyfajitas wrote: post #24
arakyd wrote: post #7

Earlier quoted context omitted.

Yeah, he says that Lisp is too hard for the common man, and then sort of implies that this is because it doesn't use ALGOL derived syntax. I don't think that's the issue. It's not Mort who's fallen in love with ALGOL syntax, it's the CS graduate Elvis's who cling to their expensively acquired "skills" (priesthood memberships) with religious fervor (he says, as a CS student). I program in C#, and lambdas and delegates…

Something I've never gotten around to is building an algolish-lisp -> lisp translator. [a, b, c] -> '(a b c) f(x) -> (f x) These two translations are strictly syntatic modifications to lisp. Some syntactic sugar: { f(x) g(x) } -> (progn (f x) (g x) ) With these three tweaks, we are probably 90% of the way to recruiting the common man (if syntax is really what puts them off).

This looks great for trivial code, but what about more complex code?

    destructuring-bind([a b &rest c] some-list lambda([x] +(a b x)))
or

    loop(for i from 1 to 10 collect 1+(i))
or

    with-current-buffer(get-buffer-create("foo")
      save-excursion(
        insert(text)
        buffer-substring-no-properties(point-min() point-max())))
This looks horrible. There is an advantage in using the same syntax for both lists and function application.

Re: Lisp is sin

#48

Post by pyre »

lispm wrote: post #36
snprbob86 wrote: post #30

Earlier quoted context omitted.

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…

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

We could argue for days about these sort of issues, and there are passionate ideas on either side of the fence.

  function
  {
    code;
    code;
  }
In that form, you have the beginning { and ending } for explicitly define the beginning and ending of the code block, and all of the code inside is also indented for good measure. Maybe it's redundant, but I don't see how it's wildly different from:

  function
    code;
    code;
> Why is there }; and } ?

Have you never programmer outside of lisp? I've never programmed in C#, but if 'arg =>' is the beginning of lambda, then it's because the definition of that line is return EXPRESSION;.

And in that case EXPRESSION = 'arg => { code }'. That's where the ';' comes from.

Re: Lisp is sin

#49

Post by [deleted] »

ynniv wrote: post #42
radu_floricica wrote: post #8

Earlier quoted context omitted.

http://github.com/richhickey/clojure-clr/tree/master http://blog.n01se.net/?p=41 http://clojure.org/todo As a rule, things move pretty fast in Clojure-land. And in the beginning it was dual-platform, so it's not really a new idea either.

From [ http://clojure.blip.tv/file/1313398/ ] I got the impression that Clojure on the CLR was back-burner at best. There appears to be only one committer to the CLR source base since February (possibly longer).

[deleted]

Re: Lisp is sin

#50

Post by fogus »

ynniv wrote: post #42
radu_floricica wrote: post #8

Earlier quoted context omitted.

http://github.com/richhickey/clojure-clr/tree/master http://blog.n01se.net/?p=41 http://clojure.org/todo As a rule, things move pretty fast in Clojure-land. And in the beginning it was dual-platform, so it's not really a new idea either.

From [ http://clojure.blip.tv/file/1313398/ ] I got the impression that Clojure on the CLR was back-burner at best. There appears to be only one committer to the CLR source base since February (possibly longer).

I believe the greater push is to write Clojure in Clojure which will (hopefully) facilitate targetting other platforms.
Post reply on HN