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

131–140 of 276 posts

Re: Not Lisp again (2009)

#131

Post by karmajunkie »

c3534l wrote: post #78
karmajunkie wrote: post #21

Earlier quoted context omitted.

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.

yeah, I don't think that's true. Neither Clojure nor Haskell seem to have any problems finding adherents, nor does the functional paradigm itself seem to be in danger of... anything. Your personal distaste for parens isn't much evidence to support the idea that they are antithetical to the growth of functional programming, nor my own distaste for Haskell evidence of the same.

Re: Not Lisp again (2009)

#132

Post by gumby »

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…

This could be simply familiarity. Back in the 80s I wrote a large system (100s of Kloc) in Common Lisp (Cyc) and it was clear and easy to follow...for a Lisp programmer.

I don't say "familiarity" as some sort of insult. I find human-generated Lisp, Forth, Postscript, and TECO clear. I find APL code impenetrable, but I know my APL-using friends (well, some Well Street variant) find it as clear as a bell. And machine-generated C code is, well, opaque.

Now what I like about the lisp syntax is precisely what (if I understand you correctly) don't: it fades into the background so I can concentrate on the algorithm. This means the C/C++ code (mostly C++ these days) I write for myself or in my small workgroup is visually unlike traditional style guides:

    node*
    foo(node& first, node& last){
      if(first_fails_qualifier(first))         return nullptr; 
      if(last_fails_qualifier(last)  )         return nullptr;
      if(!some_other_precondition(first, last) return nullptr;

      // OK, we have valid arguments
      ...do some processing on the args...

      return (wanted_first_p() ? &first : &last);
    }
I find the aggressive use of { on its own line distracts; you want the interesting stuff in your fovea (so the preconditions are easy to scan; the algorithm is set apart, and the return clearly returns one type, doing a late discrimination).

but YMMV

Re: Not Lisp again (2009)

#133

Post by icc97 »

Jach wrote: post #112
Will_Parker wrote: post #53

Earlier quoted context omitted.

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

> SICP uses Scheme, which is not Lisp.

Wikipedia [0]:

> Scheme is a functional programming language and one of the two main dialects of the programming language Lisp.

[0]: https://en.wikipedia.org/wiki/Scheme_%28programming_language...

Re: Not Lisp again (2009)

#134

Post by greenshackle2 »

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…

I never thought that I would miss writing C, but writing Python in a fairly large system, I miss the type checking.

Some of the ease of use of dynamicity is paid back in the added costs of writing more tests.

In my experience a big downside of highly dynamic languages that let you hack the language itself, including Python and Lisp, is that they give programmers quite a bit of room to shoot themselves in the foot by designing language-altering atrocities. On the Python system I currently work on, I've found atrocious uses of metaclasses that make classes behave in unintuitive ways.

Don't get me wrong, I love using Python and Lisp for my own projects, and I don't like Java very much, but I've come to appreciate its one big advantage for large software systems: it limits the damage that can be done by mediocre programmers.

Re: Not Lisp again (2009)

#135

Post by amackera »

Jach wrote: post #112
Will_Parker wrote: post #53

Earlier quoted context omitted.

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

"SICP uses Scheme, which is not Lisp." --- is that a "no true Scotsman" argument or do you just mean "Scheme is not Common Lisp"?

Re: Not Lisp again (2009)

#136

Post by ScottBurson »

amackera wrote: post #135
Jach wrote: post #112

Earlier quoted context omitted.

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

"SICP uses Scheme, which is not Lisp." --- is that a "no true Scotsman" argument or do you just mean "Scheme is not Common Lisp"?

I'm guessing the latter.

Re: Not Lisp again (2009)

#137

Post by Sharlin »

Questron wrote: post #26
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.

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

Passing function addresses as parameters is easy. It's more difficult to return a nested function that closes over the outer function's variables.

Re: Not Lisp again (2009)

#138

Post by lisper »

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 - All those parenthesis. (Still a top objection)

If you actually count parens fairly you will find that Lisp has no more than any other language, it's just that other languages use a mix of parens, square brackets and curly braces whereas Lisp only uses parens. Also, if you really don't like parens, you can get rid of a lot of them using macros. See e.g.:

https://github.com/rongarret/ergolib

and in particular the binding-block (BB) construct.

> 2 - Lisp doesn't look like or work like what I'm used to.

Neither does anything else until you get used to it.

> 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages.

That used to be one of my objections, but it's simply not true any more. And with Quicklisp accessing the (very large) collection of available libraries is incredibly convenient. (Thanks Zach!)

> 4 - There aren't nearly as many Lisp programmers, so it'll be hard to find more to join your project/company if you use Lisp.

That becomes a self-fulfilling prophecy. But it's no harder to create new Lisp programmers than it is to create new X programmers for any other value of X.

> 5 - There aren't nearly as many Lisp jobs, so why bother learning Lisp if you're going to have a hard time finding work using it?

Because knowing Lisp is a huge lever for learning other languages. Once you know Lisp everything else becomes a lot easier to learn (but a lot more frustrating too because now you will be aware of the shortcomings of other languages).

> 6 - Lisp is ancient, and anything that old is useless and primitive compared to new and shiny languages.

Chasing the shiny new thing is usually a mistake. Most old things suck simply because most things suck in general. But the things that don't suck continue to not suck even after they become old. In fact, standing the test of time is one of the defining characteristics of non-sucky things.

Re: Not Lisp again (2009)

#140

Post by Jach »

amackera wrote: post #135
Jach wrote: post #112

Earlier quoted context omitted.

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

"SICP uses Scheme, which is not Lisp." --- is that a "no true Scotsman" argument or do you just mean "Scheme is not Common Lisp"?

I mean Scheme is not Common Lisp, and Common Lisp is Lisp. Both are "a Lisp" (as is Clojure), or perhaps "a dialect of Lisp", but it's questionable if that really means anything beyond s-exps and macros.
Post reply on HN