Hacker News Reader

Comment by badcede | Hacker News Reader

It seems more embarrassing than entertaining.

I find this comment frustrating, just like many of the Lisp comments. Asserting a condescending statement with zero explanation. These Lisp comments aren't taking the form "oh, Lisp has something like this too, we can learn from it," instead it's, "something like this feature exists in Lisp, therefore these ideas clearly aren't new." For example on the thread about gradual typing, Common Lisp has definitely not had gradual typing since the concept didn't exist until the last 10 years (distinct from optional static typing). Yet that does not stop the commenter from asserting "oh Lisp has had this for forever" without any further discussion or nuance.

I think the point isn't asserting that it isn't new, rather it is a sad state of affairs that many tools are still playing catchup with developer tools of the 80's.

For example, every time we discuss Lisp on HN, many talk about SLIME, SBCL and such.

Yet, the actual modern experience of what it meant to use Lisp on its glory days lives on Allegro Common Lisp and Lispworks.

Reading papers from Xerox PARC research always makes me sad that many think replicating a PDP-11 is the ultimate developer experience.

Siek/Taha in http://scheme2006.cs.uchicago.edu/13-siek.pdf say

> Common LISP [23] and Dylan [12, 37] include optional type annotations, but the annotations are not used for type checking, they are used to improve performance.

Actually, type annotations in Common Lisp have been mostly used for three different purposes:

  * improving performance
    (by choosing specialized operations
     and/or removing runtime type checks/dispatching)
  * improving runtime safety, plus better error messages
    (by adding more and more specific runtime type checks)
  * improving compile-time safety
    (by compile-time warnings of type errors)

The CMUCL compiler has used optional type declarations and type annotations at compile time for some static type checking, combined with some type inference.

https://common-lisp.net/project/cmucl/doc/cmu-user/compiler....

There are at least two forks of CMUCL (SBCL and Scieneer CL), which use this,too.

Thus CMU Common Lisp has optional static typing + a limited form of compile-time type inference/propagation/checks.

Not sure when CMUCL added this, probably in the late 80s/early 90s. It was for example published in 1992 in the paper: 'The Python compiler for CMU Common Lisp', https://www.researchgate.net/publication/221252239_Python_co...

SBCL is quite good at the static checking even in the imo. Not sure what level of maturity it was at 10 years ago though.

Same. This came from the python compiler in CMUCL, in the 80ies.

I know that feel :)

It's just as bad in any discussion of graphics techniques, operating system features, and again in security approaches/features. Migrating to devops and security spaces has been like a conceptual "Groundhog Day".

I'm starting to think our industry is actually not so innovative and fast moving as we all like to say it is. It may be that software is merely a new engineering field and new fields begin with a wave of invention followed by reflections of reiteration as boundaries are found and concepts get refined.

It's mostly frustrating for me that the state of art for dynamic programming had not really advanced and instead in many cases is an objective regression.

Reply on news.ycombinator.com