atrn

CSP. In hardware.

I did a lot of work with transputers and occam in the 1980s and wrote an OS for a machine that used them. The exposure to the CSP way of thinking was a blessing. occam-2 on the other hand was a little too primitive.

I remember when Inmos marketing came up with "We wanted to make occam the FORTRAN of parallel processing". My response was "You have." (a reference to occam-2 having only static arrays and no concept of a record/struct)

Not to be confused with the other Helios OS - https://github.com/axelmuhr/Helios-NG

https://pkg.go.dev/cmd/go#hdr-Controlling_version_control_wi...

Second paragraph.

Lots of good links getting posted. Another interesting resource is the ACM's History of Programming Languages (HOPL) proceedings,

https://dl.acm.org/conference/hopl/proceedings

Putting on my "user" hat, a stack trace is a just a long winded way of saying "ABEND" or "core dumped".

I'm still waiting for concurrent COBOL...

PERFORM x CONCURRENTLY WITH y BUT NOT WITH z.

They had a functioning compiler and decided to concentrate on other areas and it's not too uncommon for a languages's compiler to NOT be written in that language. Afterall Rust relies on the non-Rust LLVM.

Same area, many of the same people, but at a different studio, FAME. MSS was a spin off due to various "fights". I did some recording, with Spooner and David Hood, at both places, a few years back. I really liked FAME, the room is fantastic but MSS has a great vibe.

Did some recording there a couple of years back. Not a bad room but the studio itself is mostly a museum these days and our engineer had to do a bit of work to get it functioning well enough for our purposes. In the area there are a number of great studios, e.g. Fame, Nutthouse but MSS is closer to a really, really good fried chicken place!

size(1) exists to provide the actual information. File sizes are only a rough indicator.

There were others far before Windows. In the 1980s I used Polytron version control system and the MKS port of RCS on MS-DOS.

At home I use buckling springs (Unicomp model M style plugged into an iMac) - I live alone and can make lots of typing noise. In the office its a Filco with some color Cherry switch I forget but its a lot better than the keyboard that came with the box they supply.

No beard but it would be grey...

A variant of this has been my PS1 since the 90s (yes, mostly on workstations with a GUI by then [Sun,NeXT,HPUX etc...]). Unfortunately bash doesn't like a lone ';' without something before it ("-bash: syntax error near unexpected token `;'") so I've had to use ':; ' with it (I like its use of readline, emacs user since Gosling's in the early 80s).

Triple-click, middle-click (for xterm and others that do that) is efficient and easy. The csh-inspired '!!' can work nicely too though.

Reminds (old) me of WSFN - https://en.wikipedia.org/wiki/WSFN_(programming_language)

A great engineer and hacker. I've recorded (bass) through his circuits numerous times over the decades.

I don't know if it was his idea or not but I always loved the Portico 5042 tape emulator. Want the sound of tape? Then run the signal through some tape heads. A proper "hack".

My Cube cracked the PCBs of two graphics cards before I gave up on it.

Related Ampex patent from 1989 - https://patents.google.com/patent/US5236790A/en

I really wish Go's select had guard clauses. The need to nil channels feels like a hack. However I haven't actually had much need for them but haven't written many things that would need them.

I do miss PAR's synchronization semantics, which Go programmers know as the "sync.WaitGroup" idiom. Given the number of times I see Go developers asking about synchronizing goroutine termination perhaps having some form of concurrent control structure atop 'go' could help. Or maybe not - they'd just start asking about their inability to terminate :) At least PAR is easy enough to simulate (I wrote myself a little 'par' package to hide the WaitGroup manipulations with functions/closures as the [CSP] process bodies).

I did a lot of occam in the 1980s working with transputer-based machines (I wrote a sort of OS for the system our company was building to target TV/film animation). At the time Inmos marketing came up with the line "We want to make occam the FORTRAN of parallel processing." My response, referring to occam's lack of data structuring, was, "You have."

Text files used ^Z character as end of file marker.

But only if the file size wasn't a multiple of the 128-byte block size. Fun!

Not just improvising. Its a bit of old gag...if you make a mistake just do it again and pretend you meant it (if its "outside" claim to be playing jazz).

And Rucker's "The Hacker and the Ants"

This is important and high quality research. It deserves an Ig Noble nomination.

Coming from an occam/transputer background (in the 1980s) I felt goroutines were too low level. Luckily its trivial to add a PAR-like construct via sync.WaitGroup (e.g. github.com/atrn/par). That said Go's channels are far easier to work with - buffering and multi-producer/-consumers being very common needs which, in occam, you implement yourself. The lack of guards in Go's ALT (select) is a shame and the nil channel hack is just that, a hack.

Ditto. I was a NeXTSTEP developer at the time and when Win95 came out I thought the influences were pretty obvious.

And, as always, check out Phong Vo's CDT: https://www.usenix.net/legacy/publications/library/proceedin...

Have a look for Phong Vo's CDT - container data type - library.

transputers had four links and comms beyond that required routing in s/w. I wrote such a thing for a transputer machine.

Also, the auto-discovery wasn't really auto... That was the boot code probing for CPUs on other ends of links and propagating itself to connected CPUs, building a map of the network in the process (which is kind of cool).

Sabre C aka Centerline C and later Centreline ObjectCenter (C++). Best C debugging environment I've ever used. I ported the X11R3 server to some custom h/w using it.