Comment by PaulHoule | Hacker News Reader

Comment by PaulHoule | Hacker News Reader

in the 1970s there were two common interpreted languages on small-RAM (say 4k) microcomputers and those were BASIC and FORTH; the second of which is almost "take the parenthesis out of your LISP program, reverse the order of the tokens, and... it works!"

By 1980 or so I think there was a LISP for CP/M that fit in a large-memory micro (48k) but it was expensive not that popular. A LISP runtime could have been an answer to the certifiably inzane segmented memory model of the IBM PC and I know people tried it, but other languages pulled ahead... In particularly Turbo Pascal and other languages with very fast-compilers and IDE user interfaces ripped off from LISP machines that were about as good as Visual Studio, Eclipse, IntelliJ are today -- only the PC versions were much much faster than the modern equivalents!

To be fair: modern IDE's are handling much larger programs. I remember a 1988 issue of BYTE magazine devoted to the idea of "software components" which the author thought were a long way off, but are now realized in the form of "npm", "maven", "pypi", if not the ancient CPAN, ActiveX, ...

I think it's also funny that circa 1988 Nick Wirth thought that true modularity in the module system mattered, the world didn't listen, and we've gone on to see Java only moderately harmed by the "Guava13+ broke Hadoop" crisis and to see npm practice diverge into inzanity with 2000+ dependencies for small projects but it works because the half-baked module system is more modular than Java.

> FORTH ... is almost "take the parenthesis out of your LISP program, reverse the order of the tokens, and... it works!"

Strictly speaking, FORTH does not have a lambda syntax. But if you literally "reverse the order" of function application (while keeping lambda abstraction the same) in lambda calculus, you get De Bruijn notation which is rather more compelling than the LISP default, and also rather FORTH-like as you note. (Even moreso if variable names are replaced by De Bruijn indices.)

For those like me who hadn't heard of De Bruijn notation, check out this PDF from Cornell. [0] I found the Wikipedia article pretty impenetrable, but no doubt it makes sense to a reader who already knows all about De Bruijn notation.

[0] (PDF) https://www.cs.cornell.edu/courses/cs4110/2018fa/lectures/le...

FORTH is very different from LISP but it's very similar in that you can use the quote operator to write control structures the same way you write any other function.

Common LISP had CLOS that implemented object-oriented programming in a style not too different from Python, but as a library without compiler support and that was also true for late 1980s FORTH.

> but as a library without compiler support

I'm not sure what you mean by this;As part of CL, CLOS always had compiler (and run time compiler) support.

Many early OO systems were implemented in lisps, partially because they are flexible enough to add language features reasonably well, by default. See, e.g. Flavors, Loops. These predate CL and influenced the design of CLOS.

CLOS generics+methods style is actually quite a different model in some ways from the Smalltalk-like model Python runs on! Primarily, method dispatch has the generic function primary and the classes secondary: methods are separately-definable specializations of what would otherwise be functions, rather than “owned” by a receiver object via its class. There was a recent item on Python versus CL: https://news.ycombinator.com/item?id=27011942

> can use the quote operator to write control structures

The quote operator cannot be used for writing control structures in Lisp, unless we are referring to something you generally should not do in production code, like:

  (defun meta-circular-if (cond then else)
    (if (eval cond) (eval then) (eval else)))

  (meta-circular-if (quote (> 3 2)) (quote (+ 4 4)) 0)

Quoting is nothing like referring to Forth words as data. When Forth code refers to a Forth word foo, that's more like (function foo) than (quote foo).

> The quote operator cannot be used for writing control structures in Lisp

I'm not sure this is what they had in mind, but I've actually done pretty much this when bootstrapping. Eg:

  (def (do-if cond)  # actually a built-in, but defined this way
    (if cond id quote))
  ((do-if tee) (foo))  # (id (foo))
  ((do-if nil) (bar))  # (quote (bar))

The Python object model is quite unlike CLOS.

I can't find a link to it at the moment, but Pierre de Lacaze gave an excellent talk about the CLOS/MOP systems at Lisp NYC about 5 years ago. If anyone is interested in these topics, I'd recommend digging around to see if you can find it.

> Even moreso if variable names are replaced by De Bruijn indices.

De Bruijn indices are not simply variable names: they vary dynamically depending where in the term (i.e. under how many binders) they occur, which is why beta reduction is so hairy with the De Bruijn notation.

It's interesting that you cite package managers that are deeply flawed while not listing the two that are, in my opinion, the best in class around:

- The JVM Maven Central repo

- Rust's Cargo

Also, you never say exactly which product from Wirth you are referring to, I'm assuming Modula 2. If so, all Modula 2 introduced is namespaces at the language level, and while this was a pretty novel idea at the time, it was very simplistic.

Also, the reason why Turbo-Pascal and family were fast was because the compilers were not just single pass but would abort on the first error.

I can't think of any reason why I'd trade the current compilers I use on a daily basis (mostly Kotlin and Rust) to go back to a single pass compiler, even for speed. My time is precious and a fast compiler that then forces me to spend three times as much time writing and correcting my code is not a good use of my time.

I did mention maven.

The advantage that Javascript has over Java in this respect is that in Javascript module A can import version B.1 of module B and module C can import version B.2 of module B and it works almost always.

Contrast that to the Guava - Hadoop incompatiblity in which a tiny change to Guava that broke HDFS in an racy way got Hadoop stuck at Guava 13 so you have the choice of going with G13 forever, ditching Hadoop, or ditching Guava.

I think that one is the worst diamond dependency in Java ever, but it is one of the scaling problems that maven has as the number of imports goes up, it might not be the worst one limiting what you can do with maven. (e.g. if you have a platoon of developers and a corresponding number of projects you might be able to complete a build that downloads SNAPSHOT(s) about 0.5 of the time)

You're over dramatizing.

For one instance of the Guava/Hadoop incident (which could happen just the same in any env), there are millions of builds that are happening every day that work just fine with the JVM + Maven Central repo combination.

And as opposed to the Javascript repos, you cannot delete anything on a Maven repo once it's been uploaded there.

Hi Paul,

beside Byte, do you know any place to read about that part of history ?

I'd say for that part of history, I'd go with Dr Dobb's Journal from the period. Not sure if any are online or if you'd have to find paper copies at the library.

David Ahl's, Creative Computing magazine is rarest and best of all. My mom threw most of mine out when I was away in school and so did most of the world's libraries!

The other day I found the first issue of "PC Computing" which did survive in my collection and it has a nice article on the "future of printing" that explains current-day inkjet and laser printing quite well.

Ha, my mom did the same thing. Luckily, my issues of The Transactor survived the purge.

Back issues of CC are archived here: https://archive.org/details/creativecomputing

Reply on news.ycombinator.com