Hacker News Reader

Comment by wcrichton | Hacker News Reader

Not related to your point, but I do think it's entertaining that every time I post something about programming languages, there is always at least one person who says "Lisp already solved it!" [1] [2]

[1] https://news.ycombinator.com/item?id=16726379

[2] https://news.ycombinator.com/item?id=12221818

View on HN

Maybe it's because you sound like you detected new and unique (!) stuff or that it is actually like you describe. For example:

> Jupyter presents a unique programming style

UNIQUE (!)

> But the difference between Jupyter and a REPL is that Jupyter is persistent. Code which I write in a REPL disappears along with my data when the REPL exits, but Jupyter notebooks hang around.

Sounds like a typical Mathematica notebook to me.

Macsyma (a Computer Algebra system written in Lisp) has had also Notebooks like that: https://people.eecs.berkeley.edu/~fateman/macsyma/docs/intro...

REPLs on Lisp systems have been persistent in Lisp images (not in notebook files and not transferable) since a very long time and some display text/graphics inline.

I'll grant "unique" is not an ideal world choice. I meant it not as much as "you literally can't find this anywhere else" so much as "it's something you don't find much these days."

And I think it's a little uncharitable to think I was claiming that wholesale, since I explicitly reference other implementations of the same idea at the end.

> it's something you don't find much these days

This is approach is available with all of the JVM languages too. Putting that with what others have noted about the CLR, C, and LISP implementations, this may be more common than rare.

https://zeroturnaround.com/rebellabs/reloading_java_classes_...

https://www.jetbrains.com/help/idea/2018.1/debugger-hotswap....

It may not be so much the case the people are being uncharitable as that there really isn't much that is new or unique in software.

For my own part, I have hit that wall so many times that I now begin with the assumption "if I can imagine how it might work, someone has probably already done it".

That is actually nice in the sense that I nearly always have a starting foundation when solving problems these days but also frustrating to the point of cynicism when discoveries or inventions I put a lot of time in to turn out to be minor variations on something 1k+ people already knew about.

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