It's B. BCPL has "LET MAIN() BE $(..." instead of "main $(...".
Running B was a challenge on the PDP-7 but easier on the PDP-11, apparently, because of the increase of memory size. The linked document has an interesting history about compiling B to threaded code, a form of interpreted code, and then to machine language. B never really made the jump to a full-fledged citizen because it quickly got replaced by C, although BCPL was popular for a long time.
Wikipedia's article on B says that BCPL used := for assignment and = for equality tests, whereas B used = for assignment and == for equality. Assuming that's correct, this must be B code.
I love how thin the layer above assembly is: without knowing B, is my interpretation correct that this function effectively “inherits” the stack of the calling function? In other words, rather than passing function arguments and let the compiler deal with it, you’re supposed to push the string you want to lcase onto the top of the stack?
Reminds me a lot of writing my own compiler/assembler in university, where it’s expected that all this happens automatically nowadays.
Hmm, don’t think so. The function does not operate on a string, it seems to read a character using read() and write it back, transformed, using write(). Given that the function is named main, it’s probably the top level function anyway (from the programmer’s point of view, often the OS actually calls into a different function that is part of the language runtime, e.g. _start, which in turn calls main eventually, but that is usually hidden from the programmer).
That’s 0 in Unix epoch time (guess why!), so seems more like a missing timestamp than a crafted one. The fact that the linked file does not have a 0 timestamp, but a slightly later one, suggests it's valid, or at least intended to be valid.
I recall that in A Deepness in the Sky by Vernor Vinge, a space sci-fi set in the far future, they're still using Unix time underneath many many layers of abstractions, and with their cultural context they guess that humanity must have set it to start with the moment mankind first travelled into space to land on the Moon.
They had "auto" vars in 1970. WG14, the ISO work group that maintains the C programming language specification, has just recently discussed acceptance of __auto_type.
EDIT: ops, the "auto" here means automatic allocation.
auto stands for 'automatic', because such variables are automatically allocated for each function invocation. In C it became redundant because base types were added, and so the base type could start the definition (auto was still permitted with default base type of int until C99 I think). auto in B is a bit like 'let', it starts a declaration, along with 'extrn'.
{} were added to the 1967 revision of ASCII, along with `|~ and lower case. (EBCDIC never got them in the base character set, only in alternate ‘code pages’.)
I remember in 1990 IBM sponsored a small 370 for our university. I fiddled weeks to get curly braces to work correctly. We were all used to work with Sun workstations or at most VAXen at the time. It was unbelievable how complicated this was in the IBM world. They were still living in the world of full-time machine operators. My colleagues were glad I did it, my professor who had not programmed for years and was moving in higher spheres was not impressed I had spent so much time on it when he learned about it later.
This repo has been super useful as I've been writing a book that teaches Rust by rewriting classic Unix utilities. I settled on using the 4.4 BSD source as a base but having the whole history available has been really interesting. Recently I came across a bug in the 4.4 version of cat that wasn't fixed until a few years later (in FreeBSD).
I'm not sure what the problem to be solved here is. It doesn't seem reasonable to force YouTube (or any other free video host) to indefinitely store and host content.
If you want something to stay around on the internet it has to take up space on somebody's drive and bandwidth on somebody's network connection - and for sufficiently large content like video you're going to have to do that yourself or convince/pay someone you trust to do so on your behalf.
Diomidis Spinellis' "Code Reading: The Open Source Perspective" is a thing I've wanted but didn't know existed, browsing it now to hopefully recommend, thanks for the pointer.
I work with computer engineering students and often tell them that reading more code would be good for them but have never had a great generic but concrete suggestion for how to get there.
The second best programming class I took in college was a graduate elective and the _only_ code-reading-based course I took or knew of being offered: a guided safari in the Linux kernel sources where we had to make targeted changes for the assignments. FTR, the best programming class was set up as "new language in a different paradigm every few weeks, write one small program that suits it and one small program that doesn't," not incidentally taught by the same person ( https://en.wikipedia.org/wiki/Raphael_Finkel ).
We have all this commit data at scale, it really feels like there are interesting stories or lessons that could be extracted from them.
There's kind of the obvious operational stuff like: What are the properties of commits that introduce bugs compared to those that don't. Which type of commits are rarely changed and which are more likely to be changed over time. But what I'd find even more interesting is some insight into how we solve problems and how well we're able to solve them. I guess part of the puzzle is missing - the external requirements / environment that give rise to some number of the commits.
There is a series of conferences MSR — Mining Software Repositories — with research papers looking at such questions. http://www.msrconf.org/ In fact, I presented this work in the 2015 MSR conference.
That ship sailed nearly half a century ago. All of this source code was previously licensed to research universities starting in 1975. The earlier releases weren't under FLOSS license like we know them today, but with the intent that researchers would be reading, learning from, and modifying the code. And they did! creating later BSD Unix releases with more open licenses whose code was shared more widely under more permissive licenses.
Finally, the people who created this repo are some of the primary authors of the code. They wanted this to be in the open.
There was an interesting discussion in 2019 after a group of people started cracking the passwords of the original Unix developers that had been obtained from an old /etc/passwd file in this repo (https://github.com/dspinellis/unix-history-repo/blob/BSD-3-S...).
Kernighan's is my favorite. The keyboard layout could be different, but im imagining him rapping his fingers against the three adjacent keys as if the motion itself were a secret handshake.
> IBM's OS/360 IEBUPDTE software update tool dates back to 1962, arguably a precursor to version control system tools. A full system designed for source code control was started in 1972, Source Code Control System for the same system (OS/360). Source Code Control System's introduction, having been published on December 4, 1975, historically implied it was the first deliberate revision control system.[4] RCS followed just after,[5] with its networked version Concurrent Versions System. The next generation after Concurrent Versions System was dominated by Subversion,[6] followed by the rise of distributed revision control tools such as Git.[7]
https://github.com/dspinellis/unix-history-repo/blob/Researc...
Is this B, or is it BCPL? What would have compiled this code back in the day?