Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

But LISP was already 10 years old at the time, so why did it not get traction?

Maybe too minimal syntax? I kind of liked LISP, but figuring out whether you looked at the 5th or 6th closing parenthesis somewhere in the code was not fun. In other words the code gets unnecessarily hard to read. A mandatory formatter might haver helped a bit, but that came only with Python. (Still with too much freedom because everyone chooses their own indentation level.)

LISP is interpreted, not strongly typed, so definitely another class anyway.



No, Lisp is not interpreted. Lisp compilers exist for long times. Lisp is dynamic typed. "Strong" typing often is wrongly used as a term for static typing.

When programming, Lisp certainly benefits from good editor support - as most other languages do too. And remarkably, the Lisp community pretty much agreed on a formatting and indentation style, so support in editors like Emacs is pretty good.

But its dynamic nature together with automatic memory management certainly limited the performance especially on the weak hardware back then. In comparison, it is almost trivial to write a small compiler for a language like Pascal which will produce efficient code. Fun fact: the back then popular UCSD Pascal (I used it on the Apple II) was using a bytecode engine as the compilation task.


> But its dynamic nature together with automatic memory management

Generally Lisp was used with a resident interpreter and (loadable) compiler, often interactively, it contained lots of information about the program under development. PASCAL tended to be compiled to small programs with small runtimes by a batch compiler.

The actual performance was only a secondary problem. The main problem was that Lisp used lots of memory and when the GC kicked in, it was generating a lot of memory usage -> for example by a mark & sweep GC. On a shared computer this could mean that just the Lisp program used much of the memory and on GC it was busy for some period of time. Other uses would see a massive performance degradation of the computer.

That was one of the reason to develop special computers, expensive single user workstations for Lisp, which had lots of expensive memory just for one user and improved memory management. For example, they then had four megabyte (or more) of random access memory. ;-)

> UCSD Pascal (I used it on the Apple II) was using a bytecode engine as the compilation task

Lisp systems also used byte code engines. Example: https://dl.acm.org/doi/pdf/10.1145/800087.802811


> "Strong" typing often is wrongly used as a term for static typing.

Minor contradiction: the distinction between strong and static typing is modern. From wikipedia:

> In 1974, B. Liskov and S. Zilles defined a strongly-typed language as one in which "whenever an object is passed from a calling function to a called function, its type must be compatible with the type declared in the called function."


> A mandatory formatter might haver helped a bit

Lisp code was data and could be formatted a "pretty printer". That exists since the early 1960s.

> LISP is interpreted, not strongly typed, so definitely another class anyway.

Some informations about the early Lisp compilers:

https://retrocomputing.stackexchange.com/a/12279

> not strongly typed

Lisp was not "statically typed", but was often considered strongly typed, when it was type checking at runtime. For example if the Lisp system would get (+ 1 'a) for evaluation, it could at runtime check, whether all args are numbers. If not -> error.


> Lisp code was data and could be formatted a "pretty printer".

Sure, I have used it. Not in the 1960s, but in the 1980s. I don't doubt it was old already then.

The problem is only that if the formatter is not mandatory, programmers will not use it and develop their own styles. In theory the reader could run it through the pretty printer before looking at it, but few people/systems have the tooling ready for it.


Most people use automatic indentation in Lisp, though.

Thing is: Lisp is different, it's more fluid in its shape than a language, where the code only lives in one source file. My own code and data gets reprinted in the development process on many places. I have a source file, I may look at a pretty printed macro expansion, I'll see a code fragment in the debugger, I'll re-flow some code in the Listener. Sometimes I use this IDE, then I use another one, then the code looks slightly different. But it always follows a set of rules.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: