“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?).
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.
The IBM 704, 7090 were computers targeted at the science market, being (some of?) the first with floating point hardware. Their “business” counterparts would be the 705, 1401 and did decimal math and string processing. You could run business apps on both, but manipulating strings in them is a chore because you either pack a character as a word or you need pointers within pointers. With 36-bit words, at least, you can have a character pointer turn into an address by two bitshifts.
I don’t remember much about time sharing being a thing at that time - batch processing made sense in both kinds of applications.
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.
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.
>MAXC (maximum access computer), which was a complete emulation of the Tenex machines.
Compuserve also had a software dependency on the PDP-10 and Decsystem 20, and when those machines were no longer available they bought a company making clones so they could continue to manufacture them for themselves. The company they bought, Microsolutions, was Mark Cuban's first startup.
making clones of mainframes (IBM's) had been a big area of intellectual property litigation, but also facing monopolization investigations, IBM had to allow them. They were referred to as "plug compatibles".
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 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.
>you can have Tk (as long as your Cobol allows you to call C).
No C required, you can just connect to the UI through a socket and often skip the FFI completely. This is my preferred way to use Tk and I don't even consider anything else unless there is a reason. Working this way also has the nice side effect of making the application UI agnostic.
Believe you have to do that anyways unless you are going to create full language bindings as tkinter and the like do. I don't know the Tk API in full but I don't believe it provides ways to create widgets, just interact with them more directly. Perhaps someone more knowledgeable will fill in the gaps here, I learned what I needed of the Tk API and called it good.
STk is a Scheme interpreter which can access to the Tk graphical package.
Concretely it can be seen as the John Ousterhout's Tk package where
the Tcl language has been replaced by Scheme.
The Scheme interpreter is now R4RS conformant.
This release provides an efficient object oriented system called STklos.
STklos is a full OO system with multi-inheritance, generic functions,
multi-methods and a true meta object protocol.
in what way is Tk basic? can you elaborate? also what are your thoughts on the issues with python as mentioned in the article? how do the scheme bindings compare?
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.
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.
The timeline you're presenting matches what I recall, also. Nice!
That tidbit about .S vs .a is a lovely detail. "A Research Unix Reader" has other cultural details called out that're similar - https://doc.cat-v.org/unix/unix-reader/A.Research.Unix.Reade.... Two of my favourites are the idea that originally a shell script couldn't be part of a pipeline ("programs that were likely to read from shell scripts, especially sh and ed, were made to read their input one character at a time. It was impossible to pipe into a shell script because the standard input was already dedicated to the script. For the same reason a program in a shell script could not take input from a terminal except when given the terminal’s real name.") and this note from the man page for sort v1:
> A bug note in join(1) declares, ‘‘The [field-specification] conventions of join, sort, comm, uniq, look and awk(1) are wildly incongruous.’’ Although these programs are often used together, they remain, like American weights and measures, sturdily eccentric.
I remember thinking that commands were weirdly unsimilar as I was first learning them; it took this many years for me to see one of the early authors wrote an oopsie about them :)
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.)
You're generally correct, but in this particular instance it does actually make sense to call it the dark side. Dark, as in "quiet" from RF interference. Just like some areas on Earth, near radio observatories, are declared "dark" (i.e. everyone tries to avoid using high RF emitting stuff in these regions, even comms satellites avoid it).
reply