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

Not Lisp again (2009)

funcall.blogspot.com

Post reply on HN
Print view View original

41–50 of 276 posts

Re: Not Lisp again (2009)

#41

Post by [deleted] »

BoiledCabbage wrote: post #37
c3534l wrote: post #14

Yeah, but it's goddamned ugly and unreadable. It considers repetition to be a design feature . If you're going to sell people on the benefits of functional programming, I think you should really be pushing more for SML or Haskell or something like that.

It's been stated a number of times, but x.f(y, z) has just as many parens as (f x y z). And Haskell particularly comes with so many syntax quirks. There is a lot of cruft you need to learn to get to the underlying functional core of haskell. Lips you can get 100% of the cruft out within a few days / 1 week. And the rest is just understanding programming concepts. I don't use any LISP on a regular basis, but it still…

[deleted]

Re: Not Lisp again (2009)

#42

Post by [deleted] »

chongli wrote: post #24
pmoriarty wrote: post #6

The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…

You left out a rather glaring objection: 7 - Lisp has a tendency to lure programmers up the river of insanity [0] due to the sheer power of macros (particularly reader macros). This can leave the rest of the team (or any successors) struggling with a mountain of technical debt. Overall, I think the power of Lisp makes it difficult for a community to organize without a BDFL to keep everyone on the same page. [0] http:…

[deleted]

Re: Not Lisp again (2009)

#43

Post by idobai »

BoiledCabbage wrote: post #37
c3534l wrote: post #14

Yeah, but it's goddamned ugly and unreadable. It considers repetition to be a design feature . If you're going to sell people on the benefits of functional programming, I think you should really be pushing more for SML or Haskell or something like that.

It's been stated a number of times, but x.f(y, z) has just as many parens as (f x y z). And Haskell particularly comes with so many syntax quirks. There is a lot of cruft you need to learn to get to the underlying functional core of haskell. Lips you can get 100% of the cruft out within a few days / 1 week. And the rest is just understanding programming concepts. I don't use any LISP on a regular basis, but it still…

Lisp is a cult. It doesn't have any benefit but that doesn't matter for cultists. Lisp code is terrible in practice: https://github.com/emacs-mirror/emacs/blob/master/lisp/calc/...

Re: Not Lisp again (2009)

#44

Post by Will_Parker »

phailhaus wrote: post #12

I'm having trouble understanding why the derivative example was so impressive to the author. Can someone explain? It seems trivial to do in any language where functions are first class citizens.

Indeed, posts like this are of historical interest, but today, take Python:

    dx = 0.0001
    def deriv(f):
        return lambda x: (f(x + dx) - f(x)) / dx
This works just the same as the author's example and looks even more like the calculus formula people are used to.

Re: Not Lisp again (2009)

#45

Post by sedachv »

c3534l wrote: post #14

Yeah, but it's goddamned ugly and unreadable. It considers repetition to be a design feature . If you're going to sell people on the benefits of functional programming, I think you should really be pushing more for SML or Haskell or something like that.

> I think you should really be pushing more for SML or Haskell or something like that.

There are two clues in this sentence (mentioning SML and not OCAML, "something like that") that suggest you do not regularly program in a "something like that" language. I wrote my first Haskell program over a decade ago. I find Haskell very hard to read. The grammar is very complicated[1] and is actually context-sensitive[2].

[1] https://www.haskell.org/onlinereport/haskell2010/haskellch10... [2] http://trevorjim.com/haskell-is-not-context-free/

Re: Not Lisp again (2009)

#46

Post by AnimalMuppet »

jlongster wrote: post #18
phailhaus wrote: post #12

I'm having trouble understanding why the derivative example was so impressive to the author. Can someone explain? It seems trivial to do in any language where functions are first class citizens.

This was back in 1983 where most (all?) other languages did not have first-class procedures. If you can imagine programming without them and then being exposed to that, it would be a big deal. We take them for granted today.

Well, in 1992 (IIRC), I did a numerical integration in C. For a "first class function", it just took a function pointer. That approach would have been available in C in 1983...

Re: Not Lisp again (2009)

#47

Post by wtetzner »

chongli wrote: post #24
pmoriarty wrote: post #6

The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…

You left out a rather glaring objection: 7 - Lisp has a tendency to lure programmers up the river of insanity [0] due to the sheer power of macros (particularly reader macros). This can leave the rest of the team (or any successors) struggling with a mountain of technical debt. Overall, I think the power of Lisp makes it difficult for a community to organize without a BDFL to keep everyone on the same page. [0] http:…

Yeah, this seems to be a common objection, but in my experience of actually having used a lisp (Clojure) in production, this was never a problem. Sure, you'll likely still end up with some technical debt, but no more than the Java project's we had at the same company. And not because of macros.

When people first learn about macros, they go crazy trying to do all kinds of things that weren't possible without macros. But once developers gain a little experience with macros, they learn to use them judiciously and tastefully.

Re: Not Lisp again (2009)

#48

Post by kazinator »

tromp wrote: post #30
golergka wrote: post #20

Earlier quoted context omitted.

Unreadable? Personally, I think that Lisp has the clearest possible syntax - because it basically doesn't have any. It's just straight ASTs - something that I have to visualize myself in other languages wich have more syntax sugar.

Lisp has the minimal syntax for lists: (a b c d) where other languages require separating commas, but Haskell has minimal syntax for function application: f x y z with no parenthesis needed. (Technically, this is a triple application ((f x) y) z, masked by the convention of application being a left-associative binary operator.)

That is "minimally punctuated syntax". What we want is a "minimal correspondence between written syntax and the AST"; that is what is really meant by "Lisp has minimal syntax".

What you have there is loaded with ambiguity that has to be resolved by semantics. And after the dust settles, you're left without variadic functions.

Partial evaluation and currying are very valuable techniques. They are still succinct if there is a visible, explicit partial application operator to denote a function that is constructed by binding arguments around an expression.

Re: Not Lisp again (2009)

#49

Post by vog »

ungzd wrote: post #32
phailhaus wrote: post #12

I'm having trouble understanding why the derivative example was so impressive to the author. Can someone explain? It seems trivial to do in any language where functions are first class citizens.

Better example would be symbolic differentiation[1][2] which requires more quirks even in modern languages[3][4] [1] https://mitpress.mit.edu/sicp/full-text/sicp/book/node39.htm... [2] https://github.com/clojure-numerics/expresso [3] http://docs.sympy.org/latest/tutorial/intro.html#a-more-inte... [4] https://github.com/yuemingl/SymJava#examples

Note that the simplistic approach doesn't scale well, as terms tend to "explode" in size and hence computation time.

There is a whole sub field of mathematics / computer science called "algorithmic differentiation", also known as "automatic differentiation".

The goal is to take an existing computer program and transform it into another computer program that calculates the derivatice just as efficiently (up to a constant factor of ~2 to 5, depending on how you measure), and with about the same numeric stability (by usual measures).

And this is just the start. Classic differentiation is also called "forward" mode. Understanding the "reverse mode", and why you want this for gradients, is even more mind-bending.

There is a whole world to discover here. The book "Evaluating Derivatives" is a good starting point for anyone interested.

http://epubs.siam.org/doi/book/10.1137/1.9780898717761

There are also many of beautiful papers on that topic.

Re: Not Lisp again (2009)

#50

Post by pmelendez »

phailhaus wrote: post #12

I'm having trouble understanding why the derivative example was so impressive to the author. Can someone explain? It seems trivial to do in any language where functions are first class citizens.

> It seems trivial to do in any language where functions are first class citizens

When you put that in the historical context, you will see that first class function with dynamic scoping are coming around that time. Also, Scheme which was the LISP used in the story, was the first introducing proper support for lexically scoped first-class functions. I would guess that Javascript inherited this from Scheme.

Post reply on HN