In the 1990s a piece of Germany’s air traffic control software ran on Emacs
old.reddit.com
old.reddit.com
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.
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.
That combined with some thing like Office365 or Dropbox type service and we have what you might be describing.
spreadsheet gui <--> database <--> application
The spreadsheet does simple data manipulation and acts as a GUI
The database can be mysql, postgres, sqlite (even JSON...)
The application does batch processing, generates documents, sends emails ect. everything excel can't or shouldn't do.
This stack could solve, in my opinion, >50% of all business software.
I have also considered some sort of general data storage but it's too slow. Drop box et al are not made for anything close to real time communication, which is critical for a spreadsheet that needs to talk to a program. Something like 100ms at most. This would also presumably require a perfect .xlsx implementation to read and edit the data which doesn't exist to my knowledge.
I'm confused. I have written Excel workbooks that write (insert/update/delete) to a database using VBA w/ ODBC.
Better would be something like Excel but that works P2P like SyncThing, or even directly using SyncThing itself.
I don't think it would actually be too hard as long as you didn't need truly realtime collaboration if you used file sync as your backend, and gave up on the 2D sheet model in favor of a table/records model that lends itself to conflict free operations instead of edits to specific numbered cells.
1) it's not clear what it does
2) it doesn't show them all the data at once all the time
3) it doesn't let them write formulas to work on the data
4) the few that saw Access in action say that they have to call a programmer to do what any Joe can do in Excel
So whatever Access is doing Excel does it better and they can't understand why Microsoft developed a crippled version of Excel to manage tables of data. At this point I almost don't understand it myself anymore despite having seen all the years of Access and Excel ;-)
I run it on Windows Server and paid somebody to write the Windows service to manage the Excel sheet. I can't remember which language I used for the web service itself.
They eventually gave up, commercial problems, not technical ones.
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.
Now, "supported" does not mean it was in any way good idea, or that it resembled how collaborative editing works in things like Google sheets or O365. Conflicts, deadlocks, etc were common - it's even why I built my first Rails app - we were given excel sheet and asked to do data entry on it over network from multiple machines, I didn't trust it despite a demo of it working and built a quick and dirty webapp.
(Source: I built one of those during my school holidays but I didn't get paid and I didn't have the balls to ask for payment)
I've done some industrial automation in Excel/VBA. The company wanted it that way. Their whole IT department did everything in Excel/VBA.
Guess which one you would see more of.
Still there are 100 faster, more efficent and less error prone ways to get data from A to B than printing it out and having another guy type it.
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.
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...
I was a bit of a fan back then. Much more powerful and stable than pretty much anything I encountered in Unix-land. And once you tossed out the C compact libraries, very fast, too :)
When you speak of “more ‘native’” languages, what do you mean? BLISS? MACRO? Pascal/BASIC/COBOL/FORTRAN? How do they make code like that simpler?
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 :)
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...
1. The kind that build a system they think is really cool.
2. The kind that stay up at night, stressed over how frighteningly bad the system they've been forced to build/work on is.
Someone who is eager and creative like that is unlikely to be a sociopathic jobsworth. I.e. the type most likely to steal secretes or undermine your business.
Paying Sun whatever stupid amount of money they wanted didn’t seem to make sense, GNU still didn’t have their own domain, and for whatever reason I couldn’t find a gcc binary for Solaris to download (probably related to the terrible state of web search engines at the time). So I visited my university sysadmin and copied gcc from his Solaris network to use to compile our own fresh copy.
It’s sometimes hard to remember just how bad things used to be.
Downloading them over my 28.8kbps modem was so expensive and tedious and unreliable that I put my PC in the car, along with a stack of floppies and the 15" CRT monitor, mouse, and IBM Model M keyboard, drove six hours to the opposite side of the country, to where my friend who ran the BBS lived.
We spent the weekend copying floppies and installing very early Slackware on a couple of machines.
Still... had to load the tape on our office AIX machine (the only Unix box I had access to), then wire up a null modem cable to a PC, install Kermit on both ends, transfer all the floppy images, find an MS-DOS image writer, and finally copy the works on that stack of floppies.
Good times, sort of :)
So whether I brought them from home or that company (if it had internet at all...) pulled them from gnu.org probably wouldn't have made a material difference. It was one of the reasons there was a big antipathy towards free software, at least with the vendor tapes you had someone to sue if they got tampered with.