Live data from Hacker News

Not Lisp again (2009)

funcall.blogspot.com

251–260 of 276 posts

Re: Not Lisp again (2009)

#251

Earlier quoted context omitted.

It's not something we ever really think about. That list of closing parentheses just signals termination of the top-level S-expression. And there's virtually nobody coding in a Lisp that doesn't use a structural editing mode (like Paredit or SmartParens). E.g., any time you type "(", you get "()", enforcing balance. What we rely on is proper indentation to indicate the important groupings.

Exactly. IMHO, this is quite similar to Python indentation rules, except it is up to writers of Lisp code to be disciplined enough to maintain the proper indentation.

No. Our editors auto-indent the code for us. This is one of the reasons Lisp syntax is better than python. Python syntax does not have enough information to auto-indent so it really is up to the programmer. Not so with Lisp.

Re: Not Lisp again (2009)

#252
post #89

The real power of this isn't just differentiating a given function; as others have pointed out, you can do this in, e.g., C with function pointers. Having first-class procedures and closures means you can actually return the derivative as a function. This lets you do things that the simple example doesn't show. For a physics example, see https://mitpress.mit.edu/sites/default/files/titles/content/... : given a Hamilt…

To clarify, the relevance is that deriving the vector field from the Hamiltonian requires taking partial derivatives; see the linked section from Structure and Interpretation of Classical Mechanics (SICM) by Sussman and Wisdom w/ Mayer. Closures lets one do this by composing functions in a way that mirrors the mathematical structure. Note in the SICM implementation, the partial derivatives are computed exactly, not numerically, but the resulting ODEs are integrated numerically.

Re: Not Lisp again (2009)

#253

Earlier quoted context omitted.

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.

To any lisp enthusiasts who wonder why the language family isn't more popular: this is 99% of why. You have to use an editor where "copy" is called "Kill-ring-save" is invoked with "Meta-w". Any attempt to use any other tool will be met with incredulous responses to "just use Emacs".

It's such a shame because the development environment for Lisp could be so much better than other languages. It could be mindblowingly futuristic, instead of mindblowingly archaic.

Re: Not Lisp again (2009)

#254
post #253

Earlier quoted context omitted.

> by using an editor that provides the appropriate assistance. To spell it out: this means Emacs with Paredit, or an imitation thereof.

To any lisp enthusiasts who wonder why the language family isn't more popular: this is 99% of why. You have to use an editor where "copy" is called "Kill-ring-save" is invoked with "Meta-w". Any attempt to use any other tool will be met with incredulous responses to "just use Emacs". It's such a shame because the development environment for Lisp could be so much better than other languages. It could be mindblowingly…

> You have to use an editor where "copy" is called "Kill-ring-save" is invoked with "Meta-w"

You are misinformed. I'm using a GNU Emacs (-> Aquamacs) on the Mac and cut/paste/copy are invoked with the usual command keys. But usually I use the LispWorks editor, which is also in the Emacs family, and even there cut/copy/paste is the usual command sequence... Both editors are built with excellent Lisp support. One is written in C + Emacs Lisp and the other one in Common Lisp.

> mindblowingly archaic

You haven't even understood the old part, how would you be able to deal with the futuristic part?

Re: Not Lisp again (2009)

#255

Earlier quoted context omitted.

It's not something we ever really think about. That list of closing parentheses just signals termination of the top-level S-expression. And there's virtually nobody coding in a Lisp that doesn't use a structural editing mode (like Paredit or SmartParens). E.g., any time you type "(", you get "()", enforcing balance. What we rely on is proper indentation to indicate the important groupings.

Exactly. IMHO, this is quite similar to Python indentation rules, except it is up to writers of Lisp code to be disciplined enough to maintain the proper indentation.

Hmm, my editor does it for me.

Wait, even Lisp does that for me, because it has a built-in source code pretty printer:

Call the pretty printer to format this mess:

    CL-USER 41 > (let ((*print-case* :downcase))
    (pprint '(defun add-text-padding
    (str &key padding newline)
    "Add padding to text STR. Every line except for the first one, will be
    prefixed with PADDING spaces. If NEWLINE is non-NIL, newline character will
    be prepended to the text making it start on the next line with padding
    applied to every single line."
    (let ((str (if newline (concatenate 'string (string #\Newline) str) str)))
    (with-output-to-string (s) (map 'string (lambda (x) (princ x s) (when (char= x #\Newline)
    (dotimes (i padding) (princ #\Space s)))) str))))
    ))

It prints wonderfully formatted and indented code:

    (defun add-text-padding (str &key padding newline)
      "Add padding to text STR. Every line except for the first one, will be
    prefixed with PADDING spaces. If NEWLINE is non-NIL, newline character will
    be prepended to the text making it start on the next line with padding
    applied to every single line."
      (let ((str
             (if newline
                 (concatenate 'string (string #\Newline) str)
               str)))
        (with-output-to-string (s)
          (map 'string
               (lambda (x)
                 (princ x s)
                 (when (char= x #\Newline)
                   (dotimes (i padding) (princ #\Space s))))
               str))))
Now one would only need to fix this beginner level code.

Re: Not Lisp again (2009)

#256
post #209

Earlier quoted context omitted.

To me, that's a sign that maybe a language has too little syntax. I can read C++, Javascript and PHP just as well in plain text because the other non-paren elements provide necessary contextual cues, along with nesting. Syntax coloring is helpful, but it shouldn't be necessary. I can at least understand nesting closing parens on their own lines, the way Roboprog did above, but throwing all of them on a single line ju…

It's not something we ever really think about. That list of closing parentheses just signals termination of the top-level S-expression. And there's virtually nobody coding in a Lisp that doesn't use a structural editing mode (like Paredit or SmartParens). E.g., any time you type "(", you get "()", enforcing balance. What we rely on is proper indentation to indicate the important groupings.

Actually I write Lisp code, but I use neither Paredit nor SmartParens. I don't automatically balance my parentheses.

Re: Not Lisp again (2009)

#257
post #170

Earlier quoted context omitted.

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

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

It's the lineage of Lisps where Common Lisp is in, which is Lisp:

Lisp I, Lisp 1.5, Standard Lisp, Interlisp, Maclisp, New Implementation of Lisp, ZetaLisp, Spice Lisp, Common Lisp, Emacs Lisp, ISLisp, ...

Those are all compatible to some extent and share a common core. Code moved a lot along these dialects. Macsyma had been written in Maclisp, moved to Zetalisp, then to Common Lisp. Reduce was written in Standard Lisp and then was ported to Common Lisp (without adoption). Hemlock was written in Spice Lisp and moved to Common Lisp. LOOPS was written in Interlisp and then moved to Zetalisp and later Common Lisp. CLOS was written in Common Lisp and was moved to Emacs Lisp and ISLisp. Even much of Common Lisp was moved to Emacs Lisp. ISLisp can be implemented as a package in Common Lisp relatively easily (Kent Pitman did this to check that ISLisp is compatible and has nothing which is not 'easily' implementable).

It was also usual that some Lisp implementations ran multiple Lisp dialects side by side, sharing everything: data, memory, I/O, ... For example Interlisp-D had a Common Lisp implementation side-by-side with Interlisp. The Symbolics Lisp Machine ran Zetalisp and four variants of Common Lisp side-by-side.

Then there are a lot of derived languages which either have different syntax, different semantics, different data structures, etc.

Examples are Logo, MDL, Scheme, Racket, Dylan, ML, Clojure, Javascript and a bunch of other languages.

Scheme initially shared some code with Lisp. Dylan tried it with a Lisp transpiler, ML initially was written in Lisp, ...

> Scheme can also run LISP code from 1960 with a very small driver.

The old Scheme is relatively near the Lisp mainstream, the newer Scheme less and less. Twenty years ago there was some code sharing between Lisp and Scheme, now almost none.

For me there are two definitions of Lisp:

* the main line compatible and sharing Lisps

* the general abstract family of Lisp which share an undefine subset of a set of features: lists, s-expressions, lambdas, parentheses, ... But you can find lots of languages in the larger Lisp family which have only a rough subset of this, like Javascript or Logo.

Re: Not Lisp again (2009)

#258
post #213
post #203

Earlier quoted context omitted.

Is it that absurd? Where is Scheme's CLOS, condition system, built-in debugging framework, and batteries-included standard library? Type declarations? Dynamic scoping? Multi-methods? Maybe Racket (or Chicken or Chez or Guile or...) has all of these things, Racket is pretty awesome, but those things aren't standardized, whereas I can get those things in Lisp regardless of if I use SBCL/Clozure/clisp/etc. Maybe it's cl…

>Is it that absurd? Where is Scheme's CLOS, condition system, built-in debugging framework, and batteries-included standard library? Type declarations? Dynamic scoping? Multi-methods? Does Lisp from 1960 have these things? Then I guess it isn't really Lisp?

No, but the Common Lisp of 1984 has much of the Lisp of 1960. It's backwards compatible in many ways.

Re: Not Lisp again (2009)

#259
post #253

Earlier quoted context omitted.

> by using an editor that provides the appropriate assistance. To spell it out: this means Emacs with Paredit, or an imitation thereof.

To any lisp enthusiasts who wonder why the language family isn't more popular: this is 99% of why. You have to use an editor where "copy" is called "Kill-ring-save" is invoked with "Meta-w". Any attempt to use any other tool will be met with incredulous responses to "just use Emacs". It's such a shame because the development environment for Lisp could be so much better than other languages. It could be mindblowingly…

I've been programming in Lisp for 17 years now. I've always done it in Vim.

Re: Not Lisp again (2009)

#260
post #209
post #204

Earlier quoted context omitted.

Why? (And what language do you use where you don't have to rely on the editor to format your code?)

To me, that's a sign that maybe a language has too little syntax. I can read C++, Javascript and PHP just as well in plain text because the other non-paren elements provide necessary contextual cues, along with nesting. Syntax coloring is helpful, but it shouldn't be necessary. I can at least understand nesting closing parens on their own lines, the way Roboprog did above, but throwing all of them on a single line ju…

[deleted]
Post reply on HN