Not Lisp again (2009) • Hacker News Board

Re: Not Lisp again (2009)

#71

Post by pjmlp » Tue, May 02, 2017, 5:49 PM UTC

BoiledCabbage wrote: post #28

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.

> I'm having trouble understanding why the derivative example was so impressive to the author. Says someone 35 years later. :) Probably every (commonly found) derivative example, and the majority of languages with first class functions all come from this example. MIT introducing Scheme and those two professors writing SICP are a large part of the reason for the current functional programming landscape. Without them I…

I only got to read SICP almost a decade after finishing my degree, it wasn't even a thing at my university.

We got to learn FP via Caml Light, Standard ML, pure lambda calculus and we also had some LP classes via Prolog.

Those of us that learned Lisp did it to customize Emacs.

Re: Not Lisp again (2009)

#72

Post by exDM69 » Tue, May 02, 2017, 5:49 PM UTC

Will_Parker wrote: post #44

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.

Now do the same using symbolic computation.

SymPy does it beautifully but it's much much more complicated than the equivalent in Scheme.

Symbolic differentation a topic covered in the early chapters of SICP. Doing the same in Python requires intimate knowledge of the dark corners of Python and is not at all suitable for an example in an introductory computer science class.

Re: Not Lisp again (2009)

#73

Post by brlewis » Tue, May 02, 2017, 5:49 PM UTC

Will_Parker wrote: post #44

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.

f(x + dx) does look more conventional than (f (+ x dx)), but

  (/ numerator
     denominator)

looks more like the conventional fraction syntax than putting a / somewhere in the middle of a line.

Re: Not Lisp again (2009)

#74

Post by lmm » Tue, May 02, 2017, 5:50 PM UTC

golergka wrote: post #20

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.

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.

It makes e.g. arithmetic expressions look rather awkward.

Re: Not Lisp again (2009)

#75

Post by c3534l » Tue, May 02, 2017, 5:50 PM UTC

sedachv wrote: post #45

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

I do like OCaml, but have never had the opportunity to write more than a few toy programs for fun. I put SML in there just to be like "and other ML-family functional programming languages." Haskell is complicated, but some complication is needed and that's more of a learning-curve problem. If humans were capable of simple, we'd all be typing 1s and 0s. We do better with grouping, context, similar things being similar and dissimilar things being dissimilar. I don't think Lisp is the way forward for functional programming.

Re: Not Lisp again (2009)

#76

Post by [deleted] » Tue, May 02, 2017, 5:52 PM UTC

Illniyar wrote: post #68

a lot of people handwave the parenthesis and prefix notation as something you get used to, but it really is the thing that I think most people can't get a handle on. There's a reason why DSPs and languages that look like a real languages are sought after - it makes conversion between business logic/requirements to code easier. It makes maintenance easier - it's easy to make sure you made the right changes when the ch…

[deleted]

Re: Not Lisp again (2009)

#77

Post by gimagon » Tue, May 02, 2017, 5:52 PM UTC

Illniyar wrote: post #68

a lot of people handwave the parenthesis and prefix notation as something you get used to, but it really is the thing that I think most people can't get a handle on. There's a reason why DSPs and languages that look like a real languages are sought after - it makes conversion between business logic/requirements to code easier. It makes maintenance easier - it's easy to make sure you made the right changes when the ch…

What's DSP in this context?

Re: Not Lisp again (2009)

#78

Post by c3534l » Tue, May 02, 2017, 5:52 PM UTC

karmajunkie wrote: post #21

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.

That's a pretty subjective opinion... I don't have much trouble with lisp but Haskell makes my eyes bleed. Of course I'm not a Haskell programmer, so it stands to reason that those who are find its syntax enjoyable. To each their own...

> That's a pretty subjective opinion

Only on hacker news do people think there are objective opinions! The syntax is, let's say, "divisive" which is enough of a reason to think that if you want functional programming to grow, something needs to change about it.

Re: Not Lisp again (2009)

#79

Post by AnimalMuppet » Tue, May 02, 2017, 5:52 PM UTC

jlongster wrote: post #52

AnimalMuppet wrote: post #46

Earlier quoted context omitted.

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

That's not really the same thing at all. What's missing is the ability to close over values, which is a key part of first-class functions. You could not re-create the original example in C, which is to return a new function. You'd have to return some sort of object that keeps a reference to the function pointer, and provides a special mechanism for calling it, i.e. a poor man's closure.

OK, for the example given, I don't see how closures are relevant. I could write the exact same derivative function in C in 1983.

Are you saying that in general, closures are essential to first-class functions? Or are you saying that, in the derivative example, there's something going on with closures?

Re: Not Lisp again (2009)

#80

Post by Questron » Tue, May 02, 2017, 5:53 PM UTC

geofft wrote: post #63

Questron wrote: post #26

Earlier quoted context omitted.

Probably hadn't thought of passing a subroutine address to a routine in z80 machine language he was familiar with?

Yeah, I understand why this is difficult if not impossible to do in BASIC, but functions are first-class in just about any assembly language. That said, remember that the author is talking about his experience as a first-year college student. When I went to college, I had extensive experience with BASIC (GW, Q, TI, and a bit of Visual), a year of C++ in high school, and a few vague attempts at assembly (386 and Z80)…

Yes, pointers to pointers etc. are difficult to grasp, but then again, so is passing functions as arguments. Also, information wasn't as readily available then as it is now.

Anyways, to make a long story short, here's "mega-deriver" numerical calculus package I just whipped up in COMMODORE BASIC 2.0: http://imgur.com/94eNuSX

It should run (unmodified?) on all MS BASIC dialects of the time (including Apple II and VIC-20). Note the higher precision of floating-point numbers than the puny m86k lisp the OP linked to. This one's probably faster, too ;)