Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unix: A History and a Memoir, by Brian Kernighan

cs.princeton.edu

Post reply on HN
Print view View original

131–140 of 141 posts

Re: Unix: A History and a Memoir, by Brian Kernighan

#131

Post by ethbro »

pvg wrote: post #129
ethbro wrote: post #125

Earlier quoted context omitted.

We're discussing apples and oranges. You're saying computer science history objectively exists. I'm lamenting a lack of knowledge of it.

No, I'm saying the supporting evidence for such lamentations is much weaker than the evidence for the opposite view.

Ah. In that case, the existence of books (even popular ones) and ACM conferences isn't strong support that most devs are well-versed in computing history, to me.

In the same way that the medical field has similar historical output, but the number of everyday doctors versed in medical history is quite low.

I'll dig around today and see if I can find representative polls related to computer history. Surely SO has asked a question at some point...

Re: Unix: A History and a Memoir, by Brian Kernighan

#132

Post by kragen »

pjmlp wrote: post #113
kabdib wrote: post #108

Earlier quoted context omitted.

Apple's version of Pascal had a lot of non-standard extensions. If you squinted, it was essentially C.

So any system programming language with extensions for hardware access were essentially C? Even those 10 years older than C?

Pascal used var parameters rather than pointers into the stack and supported nested subroutines with lexical scope, limiting them to being passed as downward funargs to ensure safety, and it barely missed requiring tag checks on variant record access (an omission Wirth bitterly lamented). Pascal had pointers, but they were strictly for heap-allocated objects, not var parameters or array iteration. In standard Pascal, array size was part of the array type, so you couldn't write functions that operated on arrays of unknown size, because bounds checking of array accesses would have otherwise required passing an additional length word. That's why the string type in TeX is an index into a humongous string pool array.

I think this illustrates how the philosophy of Pascal differed from that of C.

Re: Unix: A History and a Memoir, by Brian Kernighan

#133

Post by rhinoceraptor »

aasasd wrote: post #111
pjc50 wrote: post #98

Earlier quoted context omitted.

> wire-type soldering iron tip cleaner (what even is that), It's basically a fancy version of those metal pot scourers for cleaning the burnt bits off, but without damaging the metal plating on the tip.

Ah. Alas the only thing that I needed to clean off the iron is solder that doesn't ever want to leave the tip and go on the contacts.

The trick to soldering is you're not trying to put solder on things from the the iron. You heat up the joint with the iron, and then feed solder into the joint.

You put a bit of solder on the tip, but that's just to help apply heat to the joint.

Re: Unix: A History and a Memoir, by Brian Kernighan

#134

Post by aasasd »

rhinoceraptor wrote: post #133
aasasd wrote: post #111

Earlier quoted context omitted.

Ah. Alas the only thing that I needed to clean off the iron is solder that doesn't ever want to leave the tip and go on the contacts.

The trick to soldering is you're not trying to put solder on things from the the iron. You heat up the joint with the iron, and then feed solder into the joint. You put a bit of solder on the tip, but that's just to help apply heat to the joint.

Yeah, I've once watched a short clip of someone properly applying solder and realized I've been doing it wrong the whole time. I keep meaning to watch some educational material on the matter, but for now I've conceded that it's just some kind of higher magic.

Re: Unix: A History and a Memoir, by Brian Kernighan

#135

Post by rhinoceraptor »

aasasd wrote: post #134
rhinoceraptor wrote: post #133

Earlier quoted context omitted.

The trick to soldering is you're not trying to put solder on things from the the iron. You heat up the joint with the iron, and then feed solder into the joint. You put a bit of solder on the tip, but that's just to help apply heat to the joint.

Yeah, I've once watched a short clip of someone properly applying solder and realized I've been doing it wrong the whole time. I keep meaning to watch some educational material on the matter, but for now I've conceded that it's just some kind of higher magic.

Solder flows like water, it "wants" to stick to absorbent material via capillary action. The only difference is the material needs to be clean and free from oxidization so it has a direct metal contact (that's why solder has a flux core), and it needs to be hot. If you take care of that, the solder will pretty much do what you want it to.

Re: Unix: A History and a Memoir, by Brian Kernighan

#136

Post by stevej_cbr »

greatquux wrote: post #104

Regarding availability of an ebook version, I just wrote to bwk and got back a reply within a few minutes: -----Original Message----- From: Brian Kernighan To: Mike Russo Subject: Re: please publish ebook of Unix memoir!! Date: Mon, 28 Oct 2019 11:12:48 -0400 Mike -- I have just uploaded a Kindle version, but it has to go through Amazon's approval, which could take a day. I also can't see a preview on a physical devi…

It's now available. Big thanks to BWK for doing this.

Australia: A$11.99 [my local site] https://www.amazon.com.au/dp/B07ZQHX3R1/

or US$8.20 https://www.amazon.com/dp/B07ZQHX3R1/

vs printed book US$18 https://www.amazon.com/dp/1695978552

Re: Unix: A History and a Memoir, by Brian Kernighan

#137

Post by kabdib »

kragen wrote: post #132
pjmlp wrote: post #113

Earlier quoted context omitted.

So any system programming language with extensions for hardware access were essentially C? Even those 10 years older than C?

Pascal used var parameters rather than pointers into the stack and supported nested subroutines with lexical scope, limiting them to being passed as downward funargs to ensure safety, and it barely missed requiring tag checks on variant record access (an omission Wirth bitterly lamented). Pascal had pointers, but they were strictly for heap-allocated objects, not var parameters or array iteration. In standard Pascal,…

These are indeed the places where Apple extended their version of Pascal. C-style calling convention support, pointer arithmetic, much better I/O, and a host of things I can't remember. Suffice to say that when I started working at Apple (towards the end of the Pascal era) I was pretty comfortable, even though I'd been doing mostly C for a long time. This was definitely not the language we had to use in college.

(No tagged unions, though. Systems guys are allergic to 'em, apparently).

Apple also added object-oriented features, but I don't count those as addressing anything borken or awkward in the base language.

Re: Unix: A History and a Memoir, by Brian Kernighan

#138

Post by kragen »

kabdib wrote: post #137
kragen wrote: post #132

Earlier quoted context omitted.

Pascal used var parameters rather than pointers into the stack and supported nested subroutines with lexical scope, limiting them to being passed as downward funargs to ensure safety, and it barely missed requiring tag checks on variant record access (an omission Wirth bitterly lamented). Pascal had pointers, but they were strictly for heap-allocated objects, not var parameters or array iteration. In standard Pascal,…

These are indeed the places where Apple extended their version of Pascal. C-style calling convention support, pointer arithmetic, much better I/O, and a host of things I can't remember. Suffice to say that when I started working at Apple (towards the end of the Pascal era) I was pretty comfortable, even though I'd been doing mostly C for a long time. This was definitely not the language we had to use in college. (No…

Well, in the base language you couldn't store function pointers in variables or record fields, since they might refer to nested subroutines that included a context pointer to their parent subroutine stack frame, and invoking them after it had returned would be catastrophic. This “downward funargs restriction” made OO-style programming in standard Pascal very difficult in a way that it isn't in standard C. So I think the OO features, too, aimed at a weakness of the base language—but I admit I never looked at Apple's version.

Re: Unix: A History and a Memoir, by Brian Kernighan

#139

Post by kabdib »

kragen wrote: post #138
kabdib wrote: post #137

Earlier quoted context omitted.

These are indeed the places where Apple extended their version of Pascal. C-style calling convention support, pointer arithmetic, much better I/O, and a host of things I can't remember. Suffice to say that when I started working at Apple (towards the end of the Pascal era) I was pretty comfortable, even though I'd been doing mostly C for a long time. This was definitely not the language we had to use in college. (No…

Well, in the base language you couldn't store function pointers in variables or record fields, since they might refer to nested subroutines that included a context pointer to their parent subroutine stack frame, and invoking them after it had returned would be catastrophic. This “downward funargs restriction” made OO-style programming in standard Pascal very difficult in a way that it isn't in standard C. So I think…

Apple's Pascal had function pointers, and I'm pretty sure you could still do callbacks to nested procedures with a little trickery.

Ahh, I was right (PDF file here): http://mirror.informatimago.com/next/developer.apple.com/tec...

These are not closures, they're still strictly nested and on the native stack, so the usual crashes happen if you execute a callback to something that has gone out of scope.

Remind me to tell you about "Fork Queues", a solution we had on the Newton for dealing with multiple entities that all wanted to have the main event loop (of which you could really only ever have one, but we cheated).

Re: Unix: A History and a Memoir, by Brian Kernighan

#140

Post by kragen »

kabdib wrote: post #139
kragen wrote: post #138

Earlier quoted context omitted.

Well, in the base language you couldn't store function pointers in variables or record fields, since they might refer to nested subroutines that included a context pointer to their parent subroutine stack frame, and invoking them after it had returned would be catastrophic. This “downward funargs restriction” made OO-style programming in standard Pascal very difficult in a way that it isn't in standard C. So I think…

Apple's Pascal had function pointers, and I'm pretty sure you could still do callbacks to nested procedures with a little trickery. Ahh, I was right (PDF file here): http://mirror.informatimago.com/next/developer.apple.com/tec... These are not closures, they're still strictly nested and on the native stack, so the usual crashes happen if you execute a callback to something that has gone out of scope. Remind me to tel…

Oooh, this sounds fantastic!
Post reply on HN