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

181–190 of 276 posts

Re: Not Lisp again (2009)

#181

Post by conistonwater »

monochromatic wrote: post #166
vog wrote: post #49

Earlier quoted context omitted.

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

What do you mean by reverse mode? I assumed integration, but that doesn't seem to be what you're talking about.

It's also sometimes called adjoint mode. See this: https://en.wikipedia.org/wiki/Automatic_differentiation#Reve...

Re: Not Lisp again (2009)

#182

Post by rhaps0dy »

cutler wrote: post #117
jakebasile wrote: post #36

Earlier quoted context omitted.

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.

The only difference of using Hy instead of Python are the macros though. What can you do easily with macros that is cumbersome to do with regular Python?

Re: Not Lisp again (2009)

#183

Post by lelandbatey »

Chyzwar wrote: post #156
gedy wrote: post #130

Earlier quoted context omitted.

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.

Lisp style is more elegant, almost everything is either data or function. Other languages you mention are massively more complex and difficult to understand. For me C++ is some kind of clusterfuck of symbols/keywords/operators and plain magic. After you learn prefix notation, Lisp is super easy. Unfortunately in the world were "worse is better" we discard beautiful and smart: Smalltalk, Lisp and ML. Instead we build…

It is not.

When it comes to learning anything, we humans have a massive tendency to prefer that which is familiar. This means that when a human is faced with an obstacle and must choose between:

- An unfamiliar tool or paradigm which is custom built to solve this and all future problems (should they arise) such that time and effort is saved

- A familiar tool which has been extended this one time to solve this one problem, and which can be inellegantly extended to solve future problems potentially at the cost of time and effort

People will almost always pick the later.

Re: Not Lisp again (2009)

#184

Post by omaranto »

klibertp wrote: post #101
Will_Parker wrote: post #83

Earlier quoted context omitted.

I'll give you that but also, ask 100 random people what "3/4" means and what "(/ 3 4)" means.

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?

It's used outside of programming in, say, mathematics. :)

Re: Not Lisp again (2009)

#185

Post by lispm »

openasocket wrote: post #167
Jach wrote: post #140

Earlier quoted context omitted.

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.

Why does Common Lisp get the distinction of being the "true Lisp" and not Scheme? Scheme precedes Common Lisp by almost a decade

This Lisp I code is from 1959/60.

http://bitsavers.informatik.uni-stuttgart.de/pdf/mit/rle_lis...

Page 101:

    DEFINE
    (((COLLAPSE,(LAMBDA,(L),(COND,((ATOM,L),(CONS,L,NIL)),
    ((NULL,(CDR,L)),(COND,((ATOM,(CAR,L)),L),(T,(COLLAPSE,
    (CAR,L))))),(T,(APPEND,(COLLAPSE,(CAR,L)),(COLLAPSE,(CDR,L))))))))
This is the Common Lisp version. Formatted, comma removed, DEFUN instead of DEFINE.

Other than that the code is unchanged. It still works in Common Lisp.

    (DEFUN COLLAPSE (L)
      (COND ((ATOM L) (CONS L NIL))
            ((NULL (CDR L))
             (COND ((ATOM (CAR L)) L)
                   (T (COLLAPSE (CAR L)))))
            (T (APPEND (COLLAPSE (CAR L)) (COLLAPSE (CDR L))))))

    CL-USER 191 > (collapse '(1 2 (3 4) ((5 6) 7)))
    (1 2 3 4 5 6 7)
Common Lisp is backwards compatible to Lisp I and Lisp 1.5 in many ways.

Code like that can be relatively easy ported to Scheme (naming and syntax is slightly different). There are examples which are more difficult. But generally simple (!) Scheme is not that far away from that old core.

Re: Not Lisp again (2009)

#186

Post by tomjakubowski »

sigjuice wrote: post #177
Roboprog wrote: post #159

Earlier quoted context omitted.

Try putting the closing parens on a line aligned with the opening one, as if they were K&R style closing braces (ignoring that open-paren goes before keyword/func-name, rather than after ) (define (fact x) (if (zero? x) 1 (* x (fact (- x 1))) ) ) Square brackets work in some dialects, as well: [define (fact x) (if (zero? x) 1 (* x (fact (- x 1 ]

Almost all Lisp code will put the closing parens all together at the end. And the idea is to not care about how many there are by using an editor that provides the appropriate assistance.

> by using an editor that provides the appropriate assistance.

To spell it out: this means Emacs with Paredit, or an imitation thereof.

Re: Not Lisp again (2009)

#187

Post by tomjakubowski »

sigjuice wrote: post #177
Roboprog wrote: post #159

Earlier quoted context omitted.

Try putting the closing parens on a line aligned with the opening one, as if they were K&R style closing braces (ignoring that open-paren goes before keyword/func-name, rather than after ) (define (fact x) (if (zero? x) 1 (* x (fact (- x 1))) ) ) Square brackets work in some dialects, as well: [define (fact x) (if (zero? x) 1 (* x (fact (- x 1 ]

Almost all Lisp code will put the closing parens all together at the end. And the idea is to not care about how many there are by using an editor that provides the appropriate assistance.

> by using an editor that provides the appropriate assistance.

To spell it out: this means Emacs with Paredit, or an imitation thereof.

Re: Not Lisp again (2009)

#188

Post by int_19h »

AceJohnny2 wrote: post #163
jacquesm wrote: post #121

Earlier quoted context omitted.

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.

Sounds like a common objection to C++, where the language is so large that every team chooses its own subset of features they'll use, and ignore the rest :)

That's much less of a problem, because if you know the whole thing, then any subset of it is also known. It only becomes a problem if you need to change the code, because then you have to be aware of the subset to restrict yourself to.

C++ actually has a similar problem with developing idiosyncratic in-house solutions to common problems - it's not uncommon to find hand-rolled collections, reference-counting pointers etc, especially in older codebases from before STL and Boost became more widely accepted. But because the language doesn't offer anything close to the flexibility of Lisp macros, those idiosyncrasies are also much easier to parse.

Re: Not Lisp again (2009)

#189

Post by nickbauman »

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…

The parenthesis go away pretty fast once you start writing. I remember it took me a day or so. Mind you I mostly work in Clojure where parentheses are not used everywhere (function airity is described using a vector [ ] for example).

Re: Not Lisp again (2009)

#190

Post by openasocket »

Jach wrote: post #170
openasocket wrote: post #167

Earlier quoted context omitted.

Why does Common Lisp get the distinction of being the "true Lisp" and not Scheme? Scheme precedes Common Lisp by almost a decade

Naggum has a pretty good answer for that, linked in the other comment branch: http://www.xach.com/naggum/articles/3224964049435643@naggum.... You could also argue based on things like Common Lisp can run LISP code from 1960 with a very small driver, or the general history of code porting and sharing, as done here: https://news.ycombinator.com/item?id=9387131#9404543

I read that answer, I didn't find it helpful on two points.

1. There's this really nice analogy about German and English languages, but it doesn't have any specifics. In particular, the crux of his entire argument is in this statement

> The two languages and their attendant communities have drifted so far apart that there is nothing of value in their intersection.

Which he simply states as fact without any sort of follow up or justification. And I disagree. Consider this Common Lisp snippet from Wikipedia computing the answer to the birthday paradox:

  (defconstant +year-size+ 365)

  (defun birthday-paradox (probability number-of-people)
  (let ((new-probability (* (/ (- +year-size+ number-of-people)
                               +year-size+)
                            probability)))
    (if (
Literally replace "defconstant" with "define" and "defun birthday-paradox (probability number-of-people)" with "define (birthday-paradox probability number-of-people)" and that's valid Scheme.

I'll readily admit they are two different languages, but pretending they are as different as C and Python or something is absurd.

2. Even if you convince me these two languages are so different, there's nothing here to convince me Common Lisp deserves the title of the "real Lisp" or "true Lisp". Scheme can also run LISP code from 1960 with a very small driver.

Post reply on HN