Lisp Machine Manual (1984) • Hacker News Board

Re: Lisp Machine Manual (1984)

#161

Post by fusiongyro » Fri, Sep 08, 2017, 5:28 PM UTC

pjmlp wrote: post #156

fusiongyro wrote: post #147

Earlier quoted context omitted.

That erodes part of my argument. Why did C overtake Pascal? If it wasn't performance or availability, was it just preferences? Or portability from other existing codebases?

Short answer, UNIX and politics. Long answer is a bit more complex. UNIX was the only OS where C was relevant, and AT&T was forbidden to sell it, so they made the source code available to universities and companies for a nominal price. That was already a big difference, instead of paying a sum of several thousands for closed source OS stuck to a specific mainframe, companies and universities could get something with…

This was hugely useful to me, and I appreciate the copious links. But I am still stuck on something. In the early days, you programmed the home computers with assembler (it was the truth) or you used co-equal non-truth languages like C or Pascal. Later on, the OSes were all written in C, so the application code was being written in C (or mixed C + assembler) and you had FFI problems if you weren't using C. But what happened in between these that caused the OSes to be written in C rather than Pascal? Was Pascal just not perceived to be useful as a systems language?

Politics and Unix would explain it if, people were borrowing and/or aping Unix in their OSes, or if people just generally had the impression that C was more powerful. Is that kind of the direction you're pointing?

Re: Lisp Machine Manual (1984)

#162

Post by nocman » Fri, Sep 08, 2017, 5:32 PM UTC

AdeptusAquinas wrote: post #142

nocman wrote: post #132

Earlier quoted context omitted.

"parens ... make them optional ... and I would argue (again at my peril) that if it was optional in a lisp-style language as well, that would be great." ^ making parens optional in a lisp would IMHO make everything more complicated at best. Someone else in this thread mentioned SRFI 49. Personally I don't find it's syntax... define fac x if = x 0 1 * x fac - x 1 ... to be any easier to read or understand than the usu…

SRFI 49 went too far the other way. In F# the expression would be: let rec fac x = if x = 0 then 1 x * fac (x - 1) Or with pattern matching: let rec fac = match x with | 0 -> 1 | _ -> x * fac (x - 1)

I suspect that SRFI 49 went as far as it did in an attempt to reduce ambiguity (but I haven't spent much time looking at it, so take that with a grain of salt).

I understand why people prefer the combination of infix expressions and a possible reduction in the number of bracket-like symbols in their programming language (indeed, as I stated before, I originally found lisp syntax to be weird, and originally I didn't like it). When things are different than what you are used to, it is common to not like them.

However, having spent a considerable amount of time programming in lisp-like languages, I find that the benefits of prefix notation and the use of parens as boundaries in the language far outweigh the costs of having them there. Any discomfort with the aesthetics of the code seems to fade with time for most people (if they are willing to spend enough time using the language to get used to them).

Re: Lisp Machine Manual (1984)

#163

Post by [deleted] » Fri, Sep 08, 2017, 6:14 PM UTC

rjsw wrote: post #158

lispm wrote: post #144

Earlier quoted context omitted.

Computer architecture on the user level is defined by the data format and instruction set the CPU offers. How it is implemented is another level. I don't know how some Intel i7 is implemented, but it probably has writable microcode and some very different architecture inside. That Intel hides the microcode and the CADR didn't is just another detail.

You still haven't identified what hardware features you think can be emulated in software on a CADR but couldn't be emulated in software on a 68020.

[deleted]

Re: Lisp Machine Manual (1984)

#164

Post by pjmlp » Fri, Sep 08, 2017, 6:39 PM UTC

fusiongyro wrote: post #161

pjmlp wrote: post #156

Earlier quoted context omitted.

Short answer, UNIX and politics. Long answer is a bit more complex. UNIX was the only OS where C was relevant, and AT&T was forbidden to sell it, so they made the source code available to universities and companies for a nominal price. That was already a big difference, instead of paying a sum of several thousands for closed source OS stuck to a specific mainframe, companies and universities could get something with…

This was hugely useful to me, and I appreciate the copious links. But I am still stuck on something. In the early days, you programmed the home computers with assembler (it was the truth) or you used co-equal non-truth languages like C or Pascal. Later on, the OSes were all written in C, so the application code was being written in C (or mixed C + assembler) and you had FFI problems if you weren't using C. But what h…

In the 8 bit days, home computers where programmed in Assembly, Basic and Forth.

Anything else required being loaded from tape or floppy, including running CP/M instead of the ROM firmware.

Remarkable systems in these days Spectrum, C64, Tandy, Atari, MSX, Apple.

You can find a few programming books here:

http://atariarchives.org/

http://www.worldofspectrum.org/documentation.html

Then we moved into 16 bit, the major platforms being MS-DOS, Lisa and MacOS, Atari and Amiga.

MS-DOS was coded in Assembly, Lisa and MacOS in Object Pascal, Atari and Amiga used a mix of Assembly and BCPL.

MS-DOS and AmigaOS had quite a few UNIX influences on them.

Regarding my experience in Portugal, MS-DOS applications were being mostly programmed in Assembly, Pascal, C, C++, Basic and Clipper. Then there were some outliers using Prolog, Modula-2, Forth.

Microsoft and Borland were the two biggest vendors on the market and supported almost the same set of languages, with Borland ones being more programmer friendly.

Amiga were usually programmed in Assembly, Basic, AMOS, Modula-2 and C.

Mac OS was using Object Pascal until by System 7 release they decided to switch to C++.

UNIX started to be quite relevant by the mid-90's, and many wanted to continue the work on their home computers, that were doing at work or university on the expensive computer centres running some form of UNIX.

For example, I wrote K&R C code on MS-DOS for OS classes where the teacher would bring a PC tower into the class running Xenix, where each group would get a turn trying to execute their UNIX assignments.

Think a bit like how the Web influenced the desire to have JavaScript everywhere with node, it was a similar experience.

UNIX was being adopted by companies, the other contender being VMS (using BLISS as systems language).

With C companies had an ANSI/ISO standard ratified in 1989, while with Pascal, there was a de facto standard Turbo Pascal/Object Pascal with ISO being largely ignored, but they were confined to MS-DOS/Mac OS.

Re: Lisp Machine Manual (1984)

#165

Post by fusiongyro » Fri, Sep 08, 2017, 6:55 PM UTC

pjmlp wrote: post #164

fusiongyro wrote: post #161

Earlier quoted context omitted.

This was hugely useful to me, and I appreciate the copious links. But I am still stuck on something. In the early days, you programmed the home computers with assembler (it was the truth) or you used co-equal non-truth languages like C or Pascal. Later on, the OSes were all written in C, so the application code was being written in C (or mixed C + assembler) and you had FFI problems if you weren't using C. But what h…

In the 8 bit days, home computers where programmed in Assembly, Basic and Forth. Anything else required being loaded from tape or floppy, including running CP/M instead of the ROM firmware. Remarkable systems in these days Spectrum, C64, Tandy, Atari, MSX, Apple. You can find a few programming books here: http://atariarchives.org/ http://www.worldofspectrum.org/documentation.html Then we moved into 16 bit, the major…

Thanks! I really appreciate your sharing this with me.