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

111–120 of 276 posts

Re: Not Lisp again (2009)

#112

Post by Jach »

Will_Parker wrote: post #53
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…

7 - It's too easy to make a mess. And the mess made by brilliant people who are looking for any excuse to put higher order metaprogramming and functional concepts into production is considerable. 8 - It has consistently lost in the marketplace in the last 20 years. We had most top CS grads in North America groomed on SICP at one point in history. You'd think many of them would want to use Lisp in production. Many of…

SICP uses Scheme, which is not Lisp. It was taught at an introductory level because some concepts of computation can be taught nicely with Scheme, up to making a compiler for another language (perhaps a "real" language in the student's minds?), but it doesn't actually teach you Lisp, and I imagine leaves a bad taste in many students' mouth at the nonsense no-for-looping-no-mutation they had to suffer through which isn't a requirement in Lisp (nor necessarily in Scheme). SICP doesn't even have something as quick to go through as e.g. this series http://malisper.me/2015/07/07/debugging-lisp-part-1-recompil... to get a feel for what it's actually like to work with Lisp.

Clojure has been very successful though it seems like your point #7 would apply more-so to it (since Lisp isn't as functional oriented) unless you mean crazy-in-production things like closures and mapping functions. =P I don't even think you can call all that many Clojure projects skunkworks ones, because the language is quite visibly successful. Something like https://www.ptc.com/cad/elements-direct/modeling you might call a skunkworks success for Lisp...

Re: Not Lisp again (2009)

#113

Post by Chyzwar »

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: package manager, build system, support outside emacs.
  3. Concurrency and safety: some do better than other but added to late.

Re: Not Lisp again (2009)

#114

Post by davexunit »

drdre2001 wrote: post #102
davexunit wrote: post #56

Earlier quoted context omitted.

Lisp is not a functional programming language.

How? Functions are first class in lisp.

Functional programming is but one of the many paradigms that you can use in Lisp, along with imperative, object-oriented, relational, etc. When you say a language is a functional language, you are saying that it is the paradigm supported, which is not the case here.

Re: Not Lisp again (2009)

#115

Post by vilhelm_s »

vilhelm_s wrote: post #85
klibertp wrote: post #62

Earlier quoted context omitted.

> What's missing is the ability to close over values, which is a key part of first-class functions. This is not true. You can have first-class function which are not closures: every dynamically-scoped Lisp works that way, see Emacs Lisp without `lexical-binding: t` and the `lexical-let` implementation.

And the derivatives example will not work, because it needs to close over the variable f. (setq dx .0001) (defun deriv (f) (lambda (x) (/ (- (funcall f (+ x dx)) (funcall f x)) dx))) (defun cube (x) (* x x x)) (setq cube-deriv (deriv #'cube)) (funcall cube-deriv 2) Error: Symbol's value as variable is void: f Setting lexical-binding to t, so that deriv returns a closure, fixes the problem.

Incidentally, I think comparing the elisp and the Scheme versions is instructive because it shows how much is going on "behind the scenes" in this lecture. Abelson and Sussman made it all seem natural and effortless, but the key ideas in this 1983 lecture come from Sussman and Steele's research on Scheme in the late 1970s.

The blog post author marveled that the compiler could optimize all tail-calls, which was a new emphasis of Scheme (earlier Lisps only did a best-effort job), and which required e.g. changing the function calling conventions.

He appreciated how the definition of derivatives looks like the mathematical definition; but it only looks this clean because of Scheme's choice to have a single namespace for functions and values (1-Lisp versus 2-Lisp), so we get rid of elisp's setq/funcall/#' cruft.

And he wondered if the substitution model (which lets you think about programs like high school algebra, instead of modelling the execution in detail) could really always work. But it only works because of Scheme's choice to use lexical binding and closures.

All of these were difficult design problems at the time, and different Lisps explored different choices. We really have Scheme to thank for a lot of programming language concepts which we take for granted nowadays.

Re: Not Lisp again (2009)

#116

Post by dualogy »

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…

> All those parenthesis. (Still a top objection)

I'm glad for its parens. Would never have checked out Haskell (and gotten into purity&lazy-eval) if Lisp's syntax was like Haskell's (no mandatory braces except by choice, no mandatory parens except by choice --- indent is enough and in practice we all mostly end up indenting all code in all languages anyway, so.. works for me)

Re: Not Lisp again (2009)

#117

Post by cutler »

jakebasile wrote: post #36
marcosdumay wrote: post #13

Earlier quoted context omitted.

To be fair, the one time I decided to do something biggish and kinda important in Lisp, I stopped at #3. Not exactly because "it does not have many libraries", but because "library for X, Y and Z are not there and I don't want to write them". Oddly, Haskell has a similar problem, but going through C code by the FFI does not feel like a problem. I don't think why it does in Lisp, it may be just a matter of better docu…

Clojure has a good selection of libraries, and similarly can call into any Java library pretty easily.

There's also Hy (hylang.org) which is kinda Clojure-in-Python giving you access to the Python library ecosystem.

Re: Not Lisp again (2009)

#118

Post by kazinator »

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…

If every feature of a programming language syntax can be used in about 100 kilobytes of code, and your project is 3000 kilobytes, that's a 30:1 "sameness ratio" at best. If you use every language feature in that program, any 3% (if not more) of your program will look the same as some other 3%.

Most programs don't exercise every language feature throughout most of their code, so their pieces look even more self-same than that.

In Lisp, we have to learn to factor in the identity of the operators into what is "same": learn not to see (defclass bear (animal) ..) as being the same "same" as (block foo (init) ...).

When you're reading Lisp code, you're seeing chunks like this:

    xxxxxx xxxxxxxxxxxxxxxxx
       xxxxxx xxx xxxxxxxxxxxxxxxx
              xxxxxxx xxxxxxxxxx
                xxxxxxxxxxxxxxxx
              xxxxxxxxxxxxxx
                xxxxxxxxxx
You have to train yourself to see the upper left corner of this blob before any other processing:

    (defun xxxxxxxxxxxxxxxxxx
       xxxxxx xxx xxxxxxxxxxxxxxxx
              xxxxxxx xxxxxxxxxx
                xxxxxxxxxxxxxxxx
              xxxxxxxxxxxxxx
                xxxxxxxxxx
The meaning of the rest of it depends on that one; it has to look different from other blobs that have something else in that corner.

Re: Not Lisp again (2009)

#119

Post by klibertp »

archgoon wrote: post #106
klibertp wrote: post #101

Earlier quoted context omitted.

Are you sure random people are going to recognize "3/4" notation? It could be different for "3 ÷ 4", but I think "3/4" is not widely used outside of programming?

Have you ever looked at a cookbook? http://www.tasteofhome.com/recipes/how-to-cook/how-to-cut-do... Taken a drive? https://c1.staticflickr.com/5/4149/5174138836_6603010a7d_b.j...

No, I didn't... At least, not in English. Good to know, thanks.

Re: Not Lisp again (2009)

#120

Post by dualogy »

dorfsmay wrote: post #110
hasenj wrote: post #104

Earlier quoted context omitted.

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

They are IDEs, and if you think about it for a minute, Lisp languages have to be the easyest to implement IDEs for, as their syntax is exactly the AST and easy to parse.

> if you think about it for a minute, Lisp languages have to be the easyest to implement IDEs for, as their syntax is exactly the AST and easy to parse

I wouldn't think the parsing stage has ever been the top bottleneck or chief complexity/complication for IDE/tooling developers..

Post reply on HN