ATC is much more impressive than my little story of Emacs in unexpected places...
My research group needed to very rapidly make an interactive piece, for a looming big open house event for sponsors and VIPs. For Reasons, we had trouble getting computers, but there were some ancient ones that didn't run much of anything. I'd been programming in Java heavily before this, but the solution to the immediate emergency of deadline plus resource constraints was... Emacs.
Emacs would run on the box we had available, and, with it, I could develop all the things I needed, including complex HTML generation, even faster than with Perl (which I also knew). I ended up having a new Emacs process exec'd for every request, by Apache CGI, and displaying in Netscape. Process startup of the dumped Emacs itself was fast, and it worked fine.
I don't have that code anymore, but some other non-editor application for which I used Emacs before then was a kind of code generator: https://www.neilvandyke.org/jomtool/ You can see Emacs was supporting objects and even syntax macros, which was very respectable for any programming language at the time, and this was only the extension language of a text editor. What you can't see is that Emacs was additionally a super-productive "IDE" for developing with its own extension language.
This is a great story - especially that someone "almost hugging me" in Germany in a professional context is more or less equivalent to a marriage proposal. He must have made their lives really, really better.
I witnessed the disconnection of a (large) sensitive system because the 5yo grandson of a highly graded person who was touring him in the center flipped the switch of an AIX system. The system came back with a 513 error code (I think I still get it right after 30 years, the trauma).
The high graded person's jaw dropped on the floor when he realized what was switched off, looked at me, smiled and zoomed off with the kid. I recovered the system with a toothpick and manual in Swahili and, boy, that was quite a night.
Fascinating story. I wonder what other dirty secrets state agencies have in stock for us tech stack-wise.
This being said, Excel is most likely the most widespread tool for anything that involves office work. I've seen entire financial algorithms being implemented using Excel alone.
About 15-20 years ago, apparently one of the major ISP in my country was running off excel. Every customer was a row in some file.
ISP agents would come to your house to collect your bill. If someone didn't pay, the agent would flip a cell in their excel row. And that would trigger that person's internet being suspended. Sometimes they would flip the wrong person, and you had to call them, and they would fix it.
Sorry but I just don't buy this. As fas as I know, there was no collaborative editing in Excel 15-20 years ago (no Office 365). The only way for several people to edit the same Excel file stored on a network drive would have been to a) make a local copy of the file, b) do the modifications and then c) overwrite the file on the network drive. This would have destoryed _all_ modifications that occured to the file between a) and c), and would have resulted in such high rate of errors that the company would have been simply impossible to operate.
EDIT: As many people have pointed out, Excel did suppport collaborative editing at the time.
About 15 years ago or so, back when I still did web development gigs and the like (because I hadn't accepted yet that the low level system development I loved was what I should do for a job, hard to imagine now), I got requests to build complex or not so complex systems, but with the restriction that "it has to be written in Excel". Most of the time, what they really needed was a CRUD app and a database. Needless to say, I never accepted any of them.
I'm torn on this. I think many saas type services can be a spreadsheet, but excel is only 98% of the way there. Because the main issue with excel is that it is local only and even then cannot be accessed even by other local programs. Hence all the wacky VBA "scripts" that turn into full flegded programs. I wish excel _would_ become a database, that is, a frontend to a postgres instance that could be run locally or on a server. Then we just set the postgresql srting in our app and everything just works: excel is the frontend, special features run in a sane programming language, can be updated seperately ect.
Since that will nerver happen, someone needs to make an open source speadsheet that runs on postgres. And yes, it does have to be open source because otherwise nobody will learn it. And it needs at least 80% feature parity with excel.
Depends on your definition of dirty. I'd take "air traffic control running on emacs" over "guy prints out a form he received digitally and other guy types it into their computer by hand" any day. The first seems dirty, the second one is downright idiotic.
Yeah, I used to work at a large UK university and I saw (helped manage) a vast Excel spreadsheet which calculated students' final degree classifications. It was so complex I never managed to unpick the algorithms, just assumed it was right.
For the rare cases where digital comms between planes and ground ATC system is done, planes run OSI Internet protocol stack to talk with ground stations.
The rest of this is essentially about ATC talking to other ATC components (for example airport's CTR zone passing a plane to another region after takeoff)
Original author here. C worked on VMS but it was not a good match. VMS used complex data structures and async for kernel comms ($QIO) and the C standard library was built with other expectations. Setting up and handling syscalls was cumbersome and the POSIX style library was slow.
I still remember picking up VAX Pascal for an other gig and getting a decent taste for the delight that VMS systems level coding was. Yes, Pascal was better suited for that than C on VMS. Fun times :)
Ah, thanks for the response! My experience in the same timeframe was using C and Fortran on VMS, though I suppose the work I was doing wasn't digging into the same level of detail as you did.
My understanding is that, even for the brand new x86-64 port, large parts of OpenVMS are still written in BLISS and MACRO, although I believe they prefer C for brand new code. A key component of the porting effort was modifying the existing BLISS and MACRO compilers to produce x86-64 binaries instead of Itanium ones. [0]
> This would have been 1991 or 1992 so DEC was probably still a BLISS shop. Maybe they didn't ship C manuals or something.
I suspect the actual reason – in 1993, DEC released a new C compiler for OpenVMS – DEC C, to replace their earlier VAX C compiler. [0] DEC C was designed to be a fully ANSI C compiler, VAX C was a pre-ANSI (K&R) compiler with various unusual proprietary extensions, along with some half-finished ANSI C compatibility tacked on the side. Probably, they were used to writing ANSI C on other platforms, and were given VAX C to use as a as a compiler, and were (quite understandably) frustrated by its inability to compile ANSI C code correctly.
That's pretty cool. Are there also other editors that could, at a stretch, pick up similar tasks? Emacs always seems so singular in these accounts (or in the it's-an-OS-sense) but I just wonder what some other editors in that class, or close to it, might be.
Probably not as easily. One way to look at Emacs is as a Lisp system in which someone has written an editor. It has scads of functions for file and network IO, a zillion useful general functions, and a decent, well-tested runtime. While Emacs Lisp is most often used to write functions that manipulate documents and files, there’s no constraint at all on what you can use it for. I mean people have implemented web browsers, window managers, MP3 players, and other wild stuff in it.
Now, I think you could theoretically implement all those things in Vimscript, in the sense that both are Turing complete. However, Emacs Lisp is a decent general-purpose programming language in its own right. I wouldn’t necessarily choose it over other modern languages for implementing non-text-editing related things, but if that were the only option conveniently available to me, I wouldn’t cry too much about it.
Pretty much every modern IDE with a plugin system could be repurposed into a message router, since they all have underlying code execution in their respective runtime environment (just as how in this case, Emacs was really just a Lisp runtime).
Certainly any of the major Java-based IDEs (Eclipse, IDEA, etc.) could host a message router, although this is quite boring as it's just Java. Amusingly though, Volkswagen's automotive dealership service tool, called ODIS, is built in Eclipse.
On contrary software designed to be a fully integrated ecosystem meant to be extended indefinitively and refactored indefinitely in the same codebase, at any level, user programming level included regularly (even if rarely) show they can do countless things with simplicity and power. Oh, sure they are hard to design and evolve at first, BUT they pay back so much.
These stories put side-by-side clearly show the complete failure of the software divide et imper commercial model and the need of classic desktop computing as designed back then by Xerox and kept up by Symbolics and co. Some in the unix land have seen that late and try to correct the aim a bit with Plan 9 but they fail. Nowadays the modern web with a substantial U-turn from widget-based UIs to document based ones, modern Uis in general, are another small brick few seem to see. In a decade perhaps we will back at original desktop model have forgotten it from the past...
Readit News
My research group needed to very rapidly make an interactive piece, for a looming big open house event for sponsors and VIPs. For Reasons, we had trouble getting computers, but there were some ancient ones that didn't run much of anything. I'd been programming in Java heavily before this, but the solution to the immediate emergency of deadline plus resource constraints was... Emacs.
Emacs would run on the box we had available, and, with it, I could develop all the things I needed, including complex HTML generation, even faster than with Perl (which I also knew). I ended up having a new Emacs process exec'd for every request, by Apache CGI, and displaying in Netscape. Process startup of the dumped Emacs itself was fast, and it worked fine.
I don't have that code anymore, but some other non-editor application for which I used Emacs before then was a kind of code generator: https://www.neilvandyke.org/jomtool/ You can see Emacs was supporting objects and even syntax macros, which was very respectable for any programming language at the time, and this was only the extension language of a text editor. What you can't see is that Emacs was additionally a super-productive "IDE" for developing with its own extension language.
I witnessed the disconnection of a (large) sensitive system because the 5yo grandson of a highly graded person who was touring him in the center flipped the switch of an AIX system. The system came back with a 513 error code (I think I still get it right after 30 years, the trauma).
The high graded person's jaw dropped on the floor when he realized what was switched off, looked at me, smiled and zoomed off with the kid. I recovered the system with a toothpick and manual in Swahili and, boy, that was quite a night.
This being said, Excel is most likely the most widespread tool for anything that involves office work. I've seen entire financial algorithms being implemented using Excel alone.
ISP agents would come to your house to collect your bill. If someone didn't pay, the agent would flip a cell in their excel row. And that would trigger that person's internet being suspended. Sometimes they would flip the wrong person, and you had to call them, and they would fix it.
EDIT: As many people have pointed out, Excel did suppport collaborative editing at the time.
Since that will nerver happen, someone needs to make an open source speadsheet that runs on postgres. And yes, it does have to be open source because otherwise nobody will learn it. And it needs at least 80% feature parity with excel.
Guess which one you would see more of.
I've done some industrial automation in Excel/VBA. The company wanted it that way. Their whole IT department did everything in Excel/VBA.
https://www.datenschutz.org/fax/#:~:text=Immer%20mehr%20Date....
The rest of this is essentially about ATC talking to other ATC components (for example airport's CTR zone passing a plane to another region after takeoff)
"because C was not very well adapted to VMS"
It's been a long time, but I remember using C on VMS in the 80's, and I don't recall anything odd about it.
I still remember picking up VAX Pascal for an other gig and getting a decent taste for the delight that VMS systems level coding was. Yes, Pascal was better suited for that than C on VMS. Fun times :)
This would have been 1991 or 1992 so DEC was probably still a BLISS shop. Maybe they didn't ship C manuals or something.
My understanding is that, even for the brand new x86-64 port, large parts of OpenVMS are still written in BLISS and MACRO, although I believe they prefer C for brand new code. A key component of the porting effort was modifying the existing BLISS and MACRO compilers to produce x86-64 binaries instead of Itanium ones. [0]
> This would have been 1991 or 1992 so DEC was probably still a BLISS shop. Maybe they didn't ship C manuals or something.
I suspect the actual reason – in 1993, DEC released a new C compiler for OpenVMS – DEC C, to replace their earlier VAX C compiler. [0] DEC C was designed to be a fully ANSI C compiler, VAX C was a pre-ANSI (K&R) compiler with various unusual proprietary extensions, along with some half-finished ANSI C compatibility tacked on the side. Probably, they were used to writing ANSI C on other platforms, and were given VAX C to use as a as a compiler, and were (quite understandably) frustrated by its inability to compile ANSI C code correctly.
[0] https://vmssoftware.com/docs/2021-04-27-x86-Compiler-Update....
[1] https://www.digiater.nl/openvms/freeware/v70/vmsfaq/vmsfaq_0...
Now, I think you could theoretically implement all those things in Vimscript, in the sense that both are Turing complete. However, Emacs Lisp is a decent general-purpose programming language in its own right. I wouldn’t necessarily choose it over other modern languages for implementing non-text-editing related things, but if that were the only option conveniently available to me, I wouldn’t cry too much about it.
Certainly any of the major Java-based IDEs (Eclipse, IDEA, etc.) could host a message router, although this is quite boring as it's just Java. Amusingly though, Volkswagen's automotive dealership service tool, called ODIS, is built in Eclipse.
The Javascript IDEs like VSCode could as well.
On contrary software designed to be a fully integrated ecosystem meant to be extended indefinitively and refactored indefinitely in the same codebase, at any level, user programming level included regularly (even if rarely) show they can do countless things with simplicity and power. Oh, sure they are hard to design and evolve at first, BUT they pay back so much.
These stories put side-by-side clearly show the complete failure of the software divide et imper commercial model and the need of classic desktop computing as designed back then by Xerox and kept up by Symbolics and co. Some in the unix land have seen that late and try to correct the aim a bit with Plan 9 but they fail. Nowadays the modern web with a substantial U-turn from widget-based UIs to document based ones, modern Uis in general, are another small brick few seem to see. In a decade perhaps we will back at original desktop model have forgotten it from the past...