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.

er, no, it was licensed, but available to educational institutions. I remember having to send Bell Labs our university calendar when i wanted to get a copy of LSI-11 Unix circa 1976. What is true is that Ken Thompson visited a number of places over the years, and maybe from time to time he forgot to pick up his Unix install tapes when he left.

Bell Labs/AT&T claimed exclusive ownership of Unix, and the exclusive right to license it, right up to the BSD case in the early 1990s, where it was determined that AT&T had used Berkeley code, and vice versa, to the point where copyright notices were essentially fiction. Berkeley Software Design had to remove a small number of files from their distribution, and then System V and BSD could go their own separate ways.

There are 2 more that I would add, both books I read as an undergraduate nearly 60 years ago. First, Marvin Minsky's Computation: Finite And Infinite Machines (published 60 years ago). Not the latest word in automata theory, but as a first year student, I could read it and understand the issues he was addressing. Second, reading the First Edition of v.1 of The Art of Computer Programming (which of course Knuth has revised several times) was what convinced me that there was a difference between computer programming and computer science. Needless to say, there was much in TAOCP that I didn't understand, but showing me the relationship between computer programming, computer science, and mathematics really did change my life.

There are a number of image-based Scheme systems. Chibi Scheme and Chez Scheme come to mind. In both, you can save an image and reload it at a later time, though for very good reasons, most people start each session with a fresh copy of the default image.

I for one really appreciate Caps Lock. I always remap it as Compose.

SICP is not intended as a how-to-program manual, it attempts to lay the foundation for a big chunk of computer science. “How To Design Programs” might be a better choice for someone learning Scheme. (But SICP will turn some of the people on to CS as a discipline.)

Until the threat of anti-trust against IBM, and the latter's decision to “unbundle” its software from its hardware, in 1969. There had been proprietary software before that, but very little horizontal software (OSs, development tools, etc.) Autoflow's flowchart generator was a rare example of this.

I disagree with this profoundly. There is no argument that Lisp in general can get you in a terrible mess. So can C, or pretty much any language (I well remember a case of 11-way multiple inheritance in C++ game code). If I were running a Lisp-based project, there would be project standards (like no exported macros without signoff, and a list of standard library dependencies), documentation requirements, and code review.

The fact that Lisp is the “programmable programming language” doesn't mean that every engineer should be inventing weird versions of while loops. What it does mean is that a skilled Lisp programmer can build a domain-specific language that substantially helps in development.

One good example of this is the Crash Bandicoot games, along with the same studio's Jax and Daxter, which were built with dialects of Lisp (yes, they had to compile the code, and take care with storage allocation, just like any other game code). Cisco hired Kent Dybvig, principal author of the Chez Scheme system, and open-sourced that software; I have no clue what they use it for, to be honest, but I assume that they had some reason for doing this. Companies using various Lisp languages have been documented in areas from fintech to quantum computing.

I have no opinion on the validity of this claim, but I do know that many students do not read things. I taught university level computer science for over 30 years. On midterms, I would embed phrases such as “print OKAPI on the top of page 2 for an extra mark” in the exam instructions. About 40% of students followed this instruction, even though I did this for years, and you'd have thought students would tell their friends. But they didn't.

I could go on about cheating rings that encompassed entire classes (I never saw this myself, but have read authenticated reports of it.) I know of a case where a class writing an exam had teaching assistants writing the exam answers on the blackboard at the front of the room.

The CS students I taught were a highly motivated group overall. But perhaps these students were in a course they didn't want to take, resentful of being made to study things they weren't interested in, because it was a program requirement. (I taught service courses, I know that mentality.) Then it is entirely plausible to me that they might cut and paste an answer without even looking at it, or an executive summary that appears there.

I first discovered that not all students are fussy about the work they hand in, back in the late 1960s, when I was a marker for a course that taught some Cobol. The lab was a payroll program, and I saw several students hand in programs that computed pay as $2.00/hour times 40 hours equals something like $-123456.78. I asked them, when I gave them their work back, if they had looked at their output. They were all surprised that I'd expect that.

Lest there be any misunderstanding, I taught many highly motivated students who worked hard and cared very much about their work. But I did deal with many incidents of cheating in my career too.

One of the best labs I ever did in university (this was circa 1970), was to create an Initial Program Load (bootstrap) program for a virtual IBM System/360, which copied punch cards, using no OS assistance. (Modern zSeries I/O is so complicated that you'd never ask people to write it bare, but the 360 was just barely manageable for that.)

I think that wrangling with a computer in the absence of an OS is the only way for a person to understand what the OS is actually doing for you. It's all very nice to study synchronization schemes or memory management, but the methodologies all seem pretty abstract until you have to face a real computer.

Tk without Tcl?

Burgess reputedly disliked the American edition's inclusion of a glossary. I'm in partial agreement with that.The right way to read it is to let the language flow over you, and you gradually start making sense of it. The glossary is useful in demonstrating how brilliantly constructed the Nadsat language is, especially the words derived from Russian: horrorshow from khorosho, good; lewdies from lyudi, people; and starry from starei, old.

I disagree with much of Burgess's politics,but his use of language was masterful.

I second the recommmendation, for these two systems with a caveat. MIT Scheme has not been made to run on Apple Silicon, though with a few tricks, the amd64 version is usable on a modern Mac (this will presumably go away once Apple takes away Rosetta2). Racket might therefore be a better choice.

It is possible to use pretty much any decent Scheme system with SICP, but the language has changed since even the Second Edition, so I don't recommend it. That said, once you are working on your own projects, nothing stops you from using a different system, even though you might have to RTFM to see modern equivalents to ancient idioms.

I always got a chuckle when Stargate went meta. They had a planet called Kelowna (a real BC city) and a country called Langara (I was for a time a faculty member at Langara College). At one point, they visit an Oregon town called Steveston, with the location being the Steveston district of Richmond BC.

Of course, nothing can beat the thrill of waking up every morning and looking out my bedroom building at the office building that was taken over by an evil computer on X-Files.

Tectonic would be more convincing if the authors wrote their documentation in LaTeX, rather than Markdown (and I do know about Pandoc).

I did that kind of thing when I first started using C (my attitude then was that C was fine, but it should have looked more like BCPL). I stopped after a short time.