Yeah, me too. I hear Ada has something really weird, but I don't know anything about it. Smalltalk and especially Gemstone also have some really different approaches, and OS/400 also does some pretty strange stuff.
Mostly I've noticed unusual compilation/build styles when they come into conflict with version control systems. One weird one was when I was contracting 01996 to 01997 at TCSI, Teknekron Communication Systems, Incorporated, which I guess was a spinoff of Teknekron dedicated to building telco software. I was working on a project called STNMS, the SONET Tunnel Network Management System. There were some pretty funny things about the project, including some amazing recursive acronym soup. One of the major components of STNMS was the NGEMS TOM, which stood or NGDLC Element Management System TCSI Object Manager, or, fully expanded, New Generation Digital Loop Carrier Element Management System Teknekron Communication Systems, Incorporated, Object Manager.
Anyway, one of the interesting things about the system was that it was built on a distributed object system like CORBA or PARC's ILU or DCOM or eventually Java RMI, where you would invoke methods on objects, and the methods could execute in another process or even on another machine. So the NGEMS GUI would invoke methods on NGEMS-related objects which were actually implemented by code running in the NGEMS TOM, which might be on another machine, so that you could be running the NGEMS GUI on lots of machines, all calling methods on the same NGEMS-related objects, which could therefore avoid any concurrency-related bugs, I guess.
I'm not totally sold on this actually being a good idea, among other things, because the various TOMs stored their data in an INFORMIX-ONLINE SQL database server, which had pretty decent concurrency control already, and was pretty fast.
I was responsible for maintaining the bug-tracking system, the INFORMIX servers in the test environment, the build system, and the software version-tracking system, which was a pile of csh scripts built on top of RCS, running on NFS. And I was also responsible for doing a full system build, I think about once a month, which usually took me about a week of tweaking things. I was 19, and it was 01996, so I didn't know any better. I'd learned SQL and RCS by reading the O'Reilly books on the plane out to California.
Anyway, TCSI wasn't using a CORBA ORB or an ILU ORB or a DCOM ORB for their RPC layer. They'd written their own ORB, whose name I forget, but its IDL was generally called "MOSU", and lived in files with the .mosu extension. This stood for Methods, Objects, and something or other I can't remember; just as with any ORB IDL, you needed to define the class interfaces and methods and parameters that you could invoke through the ORB, so that the clients and servers would agree on what they were. You'll have to forgive me for the vagueness — it's been almost 30 years, and even at the time I wasn't writing code that went into the system, just tweaking it until it compiled so the 30 or so programmers and testers on the project could get on with their work.
The thing that caused trouble with version control was the .moslog file that accompanied the .mosu file, assigning numbers to methods and objects.
For efficiency, there was a small positive integer assigned to each of the methods, objects, etc., that the ORB's protocol could refer to. The client and server also had to agree on these numbers, just as in Protocol Buffers you need a unique tag number for each field that all users of the .proto agree on. You could solve this by burdening programmers with the need to declare these numbers in their IDL (the .mosu), as protobuf does; or you could solve it by reaching agreement on them when the connection was opened and then doing the mapping dynamically during the session, as X-Windows's XInternAtoms() does; but the MOSU IDL compiler solved it by assigning these MOS numbers automatically, starting with the smallest natural numbers.
But, to ensure that it assigned them consistently, it would log the assignments to the .moslog file.
Therefore, the .moslog file had to be checked in to source control, but the build process might modify it. And, if different programmers added things to the same .mosu, their .moslog changes were almost certain to conflict, because the compiler would assign the same next number to both things — conflicts I seem to recall I sometimes had to clean up by hand. Of course this required sneaking around behind the back of the version-tracking system, since RCS requires exclusive locks to modify a file, but often the programmers did have to sneak around thus in order to get their work done, for example because someone else had the .mosu and the .moslog locked that day.
TCSI is now dead and gone; https://en.wikipedia.org/wiki/Teknekron_Corporation tells me that it was bought by Rocket Software in 02003. I think the STNMS project failed, and BellSouth, the company that was paying TCSI to build it, also no longer exists. So, I doubt anybody has used these primitive tools in 20+ years, and I haven't seen them described anywhere publicly before, perhaps because TCSI foolishly thought they were a competitive advantage at the time. (I hope I haven't made too many errors in my recollections.) But it's interesting what we can learn from them for the future.
Today, there's a somewhat similar thing that happens with generative testing systems like Hypothesis: when they find a failing "instance" of a property-based test, they record it in a database of failing tests, so that you can always use it in the future. So the "build process", or rather the test process, sometimes produces data that must be checked in to the version tracking system. This doesn't mesh well with conventional version-control workflows, and especially established continuous-integration systems which blow away the universe when the test suite finishes running.
Of course, training AI neural networks doesn't fit cleanly into the conventional version-control model either.
Comments
Yeah, me too. I hear Ada has something really weird, but I don't know anything about it. Smalltalk and especially Gemstone also have some really different approaches, and OS/400 also does some pretty strange stuff.
Mostly I've noticed unusual compilation/build styles when they come into conflict with version control systems. One weird one was when I was contracting 01996 to 01997 at TCSI, Teknekron Communication Systems, Incorporated, which I guess was a spinoff of Teknekron dedicated to building telco software. I was working on a project called STNMS, the SONET Tunnel Network Management System. There were some pretty funny things about the project, including some amazing recursive acronym soup. One of the major components of STNMS was the NGEMS TOM, which stood or NGDLC Element Management System TCSI Object Manager, or, fully expanded, New Generation Digital Loop Carrier Element Management System Teknekron Communication Systems, Incorporated, Object Manager.
Anyway, one of the interesting things about the system was that it was built on a distributed object system like CORBA or PARC's ILU or DCOM or eventually Java RMI, where you would invoke methods on objects, and the methods could execute in another process or even on another machine. So the NGEMS GUI would invoke methods on NGEMS-related objects which were actually implemented by code running in the NGEMS TOM, which might be on another machine, so that you could be running the NGEMS GUI on lots of machines, all calling methods on the same NGEMS-related objects, which could therefore avoid any concurrency-related bugs, I guess.
I'm not totally sold on this actually being a good idea, among other things, because the various TOMs stored their data in an INFORMIX-ONLINE SQL database server, which had pretty decent concurrency control already, and was pretty fast.
I was responsible for maintaining the bug-tracking system, the INFORMIX servers in the test environment, the build system, and the software version-tracking system, which was a pile of csh scripts built on top of RCS, running on NFS. And I was also responsible for doing a full system build, I think about once a month, which usually took me about a week of tweaking things. I was 19, and it was 01996, so I didn't know any better. I'd learned SQL and RCS by reading the O'Reilly books on the plane out to California.
Anyway, TCSI wasn't using a CORBA ORB or an ILU ORB or a DCOM ORB for their RPC layer. They'd written their own ORB, whose name I forget, but its IDL was generally called "MOSU", and lived in files with the .mosu extension. This stood for Methods, Objects, and something or other I can't remember; just as with any ORB IDL, you needed to define the class interfaces and methods and parameters that you could invoke through the ORB, so that the clients and servers would agree on what they were. You'll have to forgive me for the vagueness — it's been almost 30 years, and even at the time I wasn't writing code that went into the system, just tweaking it until it compiled so the 30 or so programmers and testers on the project could get on with their work.
The thing that caused trouble with version control was the .moslog file that accompanied the .mosu file, assigning numbers to methods and objects.
For efficiency, there was a small positive integer assigned to each of the methods, objects, etc., that the ORB's protocol could refer to. The client and server also had to agree on these numbers, just as in Protocol Buffers you need a unique tag number for each field that all users of the .proto agree on. You could solve this by burdening programmers with the need to declare these numbers in their IDL (the .mosu), as protobuf does; or you could solve it by reaching agreement on them when the connection was opened and then doing the mapping dynamically during the session, as X-Windows's XInternAtoms() does; but the MOSU IDL compiler solved it by assigning these MOS numbers automatically, starting with the smallest natural numbers.
But, to ensure that it assigned them consistently, it would log the assignments to the .moslog file.
Therefore, the .moslog file had to be checked in to source control, but the build process might modify it. And, if different programmers added things to the same .mosu, their .moslog changes were almost certain to conflict, because the compiler would assign the same next number to both things — conflicts I seem to recall I sometimes had to clean up by hand. Of course this required sneaking around behind the back of the version-tracking system, since RCS requires exclusive locks to modify a file, but often the programmers did have to sneak around thus in order to get their work done, for example because someone else had the .mosu and the .moslog locked that day.
TCSI is now dead and gone; https://en.wikipedia.org/wiki/Teknekron_Corporation tells me that it was bought by Rocket Software in 02003. I think the STNMS project failed, and BellSouth, the company that was paying TCSI to build it, also no longer exists. So, I doubt anybody has used these primitive tools in 20+ years, and I haven't seen them described anywhere publicly before, perhaps because TCSI foolishly thought they were a competitive advantage at the time. (I hope I haven't made too many errors in my recollections.) But it's interesting what we can learn from them for the future.
Today, there's a somewhat similar thing that happens with generative testing systems like Hypothesis: when they find a failing "instance" of a property-based test, they record it in a database of failing tests, so that you can always use it in the future. So the "build process", or rather the test process, sometimes produces data that must be checked in to the version tracking system. This doesn't mesh well with conventional version-control workflows, and especially established continuous-integration systems which blow away the universe when the test suite finishes running.
Of course, training AI neural networks doesn't fit cleanly into the conventional version-control model either.