vincent-manis

“The law, in its majestic equality, forbids the rich as well as the poor to sleep under bridges, to beg in the streets, and to steal bread.” — Anatole France

Treating people equally does not mean treating them the same (or, why don't healthy people get to be hospital patients, too?).

Oh, and there was a Cobol compiler for the 6600. (Wirth's first Pascal implementation was also for the 6600, as I recall.) My point is that the central processor architecture of the 6600, apart from the large word size, was entirely consistent with the way that scientific computers from IBM, Univac, Philco, General Electric, and other manufacturers were designed.

As for time-sharing,IBM explicitly ruled it out as a design objective for OS/360. Then MIT went shopping for a partner for Multics. IBM had nothing of interest for them, but GE agreed to design a virtual memory version of their 635, the 645. Suddenly, IBM realized that they were going to lose a market, so they rapidly added memory mapping to the 360/65, producing the Model 67. They also announced Time Sharing System/360, but the early versions were unusable (20 minutes to log in, for example), so a few folks at the University of Michigan whipped up an interim solution, the Michigan Terminal System, which worked fine, and was in service at various places from 1968 to the 1990s.

Although IBM produced various time-sharing systems, including Call/360, APL\360, the Time Sharing Option, and VM/CMS, they never really understood it, which is why a few underfunded folks at a university could produce something better than what they could produce with a professionally-managed team.

By contrast, DEC did get it in that era, which is why the PDP-10 did so well in university computer science departments.

Excuse me? No character addressability? The scientific machines IBM was selling in 1963, the 704x/709x, were 36-bit-word-addressible. The 6600 was definitely similar to those, in many ways. And you didn't need character addressibility for business applications, there were Cobol compilers for those machines. The stranger feature of the 6600 was the division between the central processor and the peripheral processors; if the 360 had been designed that way, much of the operating system would have been running in the channels, or in the smaller computers then used for offline punchcard/printer support.

A much greater omission was IBM's refusal to consider time-sharing, until it was too late, and then they made a total mess of it with TSS/360. (The 360/67 was a good machine, I have fond memories of it, but it needed a different OS, Michigan Terminal System in our case.) It took IBM a long time to understand the need for interactive computing.

When Xerox established PARC, they asked the assembled scientists what computer they wanted. The majority view was a DEC PDP-10 KA10, with the BBN memory management unit that let it run Tenex (the ancestor of DEC TOPS-20). Xerox couldn't really buy a competitor's mainframe, so they built MAXC (maximum access computer), which was a complete emulation of the Tenex machines.

This reminds me of the apocryphal story of the IBM System/360 running a 1410 emulator that ran an IBM 705 simulator that ran a business-critical application.

The reason for that is that it did arithmetic via table lookup. As I heard from someone who was there, the University of British Columbia wanted to show off its brand new 1620, so they wrote a demo program, and with a host of onlookers, they pressed Memory Clear, then loaded the program, and it failed. Memory clear had erased the addition and multiplication tables.

Back in the early 90s, I ran several procurements for university computer labs. We were under severe budget constraints, and, as a computer science department, we had constraints not normally found in such labs (for example, we needed to use certain compilers, so they had to support the workstation architectures). We wrote RFPs in accordance with university policies, and, while a number of potential bidders couldn't meet them, the companies in question all understood the constraints, and unsuccessful bidders were constructive, on the grounds of “consider us next time, ok?” All of them were like this, except one. The only time I have ever had someone threaten my job was the Sun Microsystems sales rep, after they lost a competition.

Back around 1968, I did some work on an IBM 1130 (small-scale 16-bit computer, definitely not a minicomputer, as it filled most of a room). The disk drive was driven by a voice coil, and made an audible click as the head moved from one track to the next. I would do a Fortran compile, then walk to the other end of the building to the break room to get a coffee while the compiler was working. The disk made a distinctive sound when the compiler went to write the executable, and I would immediately walk back to the computer room to see the compilation results.

I use Tk routinely in Scheme; there is no Tcl in my code, but Tk is a very nice (though basic) GUI kit, and my programs work on Linux, BSD, MacOS, and Windows. Other commenters have mentioned that Python ships with Tkinter, a library module that interfaces to Tk. I believe Ruby does the same. Hell, if you're programming in Cobol, you can have Tk (as long as your Cobol allows you to call C). You do not have to love Tcl to love Tcl/Tk.

I have nothing to say on the merits of Khan Academy (I have never looked at it, nor have I known anyone taking a course), but from 35 years of teaching, I know that we mostly learn by doing. It's why university courses have labs, problem sets, and required essays. All else is memorization (not that memorization is inherently bad, part of learning assembly language programming is memorizing the available instructions, while learning French includes memorizing vocabulary).

Educational technology that is focused on delivering “content” is unlikely to be of much value. Technology that induces the learner to experiment, to discover, to discern patterns, and to ask further questions, is going to be much more valuable.

A correction. I can find no evidence of a Unix v2 at Berkeley, it looks like it was v4. (I was told long ago by someone who was at Berkeley then that they had had v2, but there is no evidence of this in the usual sources of information.)

My vague recollection is that the kernel in Unix v2 (still called UNIX in those days) was written in assembly language, but that many of the commands were written in B. Because B was interpretive on the PDP-11 (it suffered from the same problem as BCPL, in that it expected a word-addressed machine), it would have been impractical to use it in the kernel. If I recall correctly, the first Unix to reach Berkeley was some kind of v2.

The C compiler appeared in v3, and the kernel rewrite happened for Version 4, which is the version described in the paper.

Using .S for assembly language source is a historical accident, by the time the majority of code was written in C, .a was defined as the conventional filetype for archive (ar) files.

s/dark side/far side/

I tried to use Vim once, and found that none of the Emacs keybindings worked there. Seriously, learning x86 assembly language is easier than trying to grasp that INSANELY bad keyboard layout.

I would never buy a kit that required soldering, because I'm terrible at it. But I like putting things together. I've assembled a couple of DIY keyboards, and I bought a Framework 12 laptop. It doesn't take too long (Framework estimated 15 minutes, but it was more like 45, because I am slow and methodical), and I like knowing what's inside it. The transition from “box of components” to “working system” always thrills me. And, though the repairability of a trackball is not a big issue, it's nice to know that what you put together can be taken apart, for example, to replace an SSD in a laptop.