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

121–130 of 276 posts

Re: Not Lisp again (2009)

#121

Post by jacquesm »

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…

To me the hard part about lisp is that every programmer that uses lisp tailors it so to their own taste that it can become quite hard to read the 'top level' of a lisp program without first having gone through all the lower layers. It is as if every project in lisp somehow magically develops its own DSL. That's a high hurdle for newbies to clear.

Re: Not Lisp again (2009)

#122

Post by ScottBurson »

kazinator wrote: post #34
TheApexTheater wrote: post #11

Earlier quoted context omitted.

As a response to your objections, 1) It's just a syntax thing... It's still possible to make an understandable program through good style 2) I don't have anything. 3-6) I've heard Racket is a good spiritual successor to Lisp, complete with external libraries and a broad(er) userbase.

For (2) ( "Lisp doesn't look like or work like what I'm used to" ) I have something: * Lisp does look quite a bit like stuff you're used to: foo(bar(arg, (foo (bar arg arg arg2), arg2) arg2 xyzz()); (xyzz)) * Lisp does actually work a lot like stuff you are used to: evaluation of argument expressions to argument values, which are passed by value: much like C or Java. Functions return a value or multiple values. It ha…

> Lisp lists lack encapsulation; they are not opaque bags with which you do things like (add list item). That takes getting used to: always capturing the result value of a list construction.

You're conflating two properties: lack of encapsulation and functional update. It's true that lists expose their internal structure as conses, and it's also true that they're usually updated functionally (requiring, as you say, capturing the result), but these properties don't have to go together. It's entirely possible, and arguably desirable, to have functional collections -- where instances are immutable, but which provide operations for creating new instances from existing ones -- which are also opaque data types; see for example FSet [0]. Conversely, it's possible to have fully-mutable lists that expose their internal structure; you just have to wrap each list in a mutable cell. It would be ugly, and I don't know why you'd do it, but it's entirely possible.

[0] https://github.com/slburson/fset

Re: Not Lisp again (2009)

#124

Post by Jach »

mnarayan01 wrote: post #95
BoiledCabbage wrote: post #37

Earlier quoted context omitted.

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…

x + y * z has way fewer than (+ x (* y z)) though. I'm not arguing for one or the other, but e.g. infix operators do have upsides.

Fortunately with Lisp this isn't an unsolvable problem. https://github.com/rigetticomputing/cmu-infix

Re: Not Lisp again (2009)

#126

Post by sc4les »

hasenj wrote: post #104
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…

_My_ main objection to lisp is that it's confusing. I don't mean the syntax is hard to grasp. I mean the way it looks. It becomes very confusing when the program grows in size. This is not unique to Lisp. It applies to all dynamic languages that don't have strong tooling support (IDE's with intellisense). (Maybe I am wrong about Lisp being dynamic; my only experience has been with "arc"; and I have had someone tell m…

Have you tried Cursive for Clojure lately? It does a lot of the things really well

Re: Not Lisp again (2009)

#127

Post by smitherfield »

AnimalMuppet wrote: post #46
jlongster wrote: post #18

Earlier quoted context omitted.

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

He is right, you could do something roughly equivalent in 1983-era C, albeit a fair amount clunkier due to the lack of partial application or (any kind of) type-checking:

  #define DX (double)0.0001

  double f_prime(f, x)
          register double (*f)();
          double x;
  {
          return ((*f)(x + DX) - (*f)(x)) / DX;
  }
  #define DERIV(F, X) f_prime((F), (double)(X))

  double cube(x)
          double x;
  {
          return x * x * x;
  }
  #define DERIV_CUBE(X) DERIV(cube,(X))

  main()
  {
          printf("%f\n%f\n%f\n", DERIV_CUBE(2), DERIV_CUBE(3), DERIV_CUBE(4));
  }

Re: Not Lisp again (2009)

#128

Post by dualogy »

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…

> And Haskell particularly comes with so many syntax quirks

Wouldn't agree per se, I'd rather formulate "it gives the user-land a lot of freedom & powers for introducing syntax quirks". You can code super-clean Haskell, or you can roll in 2 dozen language extensions and libraries with a 100+ custom operators, and use TemplateHaskell --- then yeah the syntax will begin to look horribly "quirky". Many practitioners end up limiting themselves in this regard after a while, or insist on "going back to basics" as much as feasible

Re: Not Lisp again (2009)

#129

Post by pg314 »

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…

According to RMS [1], even the secretaries in Bernie Greenberg's office were extending Emacs in Emacs Lisp. Nobody had told them what they were doing was programming and they were able to pick it up from a manual.

The parentheses can't be that big an obstacle.

[1] https://www.gnu.org/gnu/rms-lisp.en.html

Re: Not Lisp again (2009)

#130

Post by gedy »

Chyzwar wrote: post #113
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…

1. Lisp have less symbols than other language (defun averagenum (n1 n2 n3 n4) (/ ( + n1 n2 n3 n4) 4) ) vs function averagenum(n1, n2, n3, n4){ return (n1 + n2 + n3 + n4)/4 } Lisp 9 vs 13 JavaScript(excluding keywords and return) 2, 3 ,4 , 5, 6 -> Chicken and egg problems, Lisp is not popular enough an this makes things difficult. Lisp real issues are: 1. Fragmentation: Scheme, CL, Clojure, ELisp, Racket... 2. Tooling…

True, but the issue is that most academic and vast majority of paid coding roughly looks like the JavaScript example (C/C++/Java/JS/etc) - so to most the Lisp style looks odd and hard to parse, not the raw symbol count.
Post reply on HN