*BSD as a "main driver" for average users

COBOL is usually written using a text editor or on a data terminal. Which editor or terminal was used to write the program is rarely displayed.

Hint: HTML is a markup language while COBOL is a programming language. There is a difference.

How about COBOL inside HTML?

"Writing Web Apps in COBOL"

There are still schools, universities and online course that teach COBOL. A sample:

The brother of a former friend and customer (both deceased) was life-long COBOL programmer. His employers and customers were mostly government, insurance and financial institutions. I lost count of how many times he retired and was then called back to write or fix COBOL programs. You might be correct that there's not much demand for COBOL programmers. However, those that are working on COBOL programs don't seem to starving.

Jeff Liebermann snipped-for-privacy@cruzio.com wrote: |-------------------------------------------------------| |"On Sun, 21 Jun 2026 12:33:04 -0700, Don Y | | snipped-for-privacy@foo.invalid wrote: | | | |>In some sense, you've gotta feel sorry for MS [. . .] | |[. . .] | |>Ditto POSIX [. . .]" | |-------------------------------------------------------|

Eh no.

|-------------------------------------------------------| |"[. . .] | |

IBM decided to focus on Java so it sold off its Smalltalk and Ada divisions. (S.

I don't believe it was "sold off". IBM conglomerated Smalltalk and other languages into a single IDE (integrated development environment) called VisualAge:

"VisualAge for Java is based on an extended Smalltalk virtual machine which executes both Smalltalk and Java byte codes. Java natives were actually implemented in Smalltalk."

I don't know what happened to Ada.

Editor used is not an issue. How was the HTML written, on a chalkboard?

The HTML is served *to* the browser. There's no COBOL, there.

Both are LANGUAGES. Both are created by programmers (not poets or english literature majors -- though both could likely be trained to use one of the common frameworks/wizards). Both are Turing complete (if you augment HTML with CSS or JS).

How about Inferno and run real distributed apps?

Or, run an app *in* your PS printer (PS being Turing complete)?

I've repeatedly mentioned my colleague who rescues Sun big iron to support his employer's enterprise. He's quite secure in hhis job as few people have even the foggiest ideas of how to configure and operate such kit -- or, an interest in doing so!

When a skill is scarce, it can command outsized pay. But, its very scarcity marks it as a likely bad career path.

What do you think I'd charge to bail someone out of a bind with an

OTOH, what appeal supporting a product taht is (likely) representative of a decades old design? I toured the Cheyenne Mountain Complex in ~1980. At the time, they were having a "computer upgrade" installed -- that had been ordered and specified in the 1960's. How exciting to be working on the initial release of a 20 year-old design (not!)

OTOH, it's not worth advertising those capabilities as they are rarer than hen's teeth.

Would YOU like to be forever supporting decisions you'd made

I've never reused code as clients like to think they paid for a certain set of character strings. But, *design* reuse is far more effective. Persistence of ideas (models) instead of cut-and-paste of "code".

This gives me the ability to explore different design approaches without burdening a new project with support for code developed for an old one. Each OS can present a different API and different notion of hardware abstractions that the "current project" can explore to determine their efficacy -- cherry pick the ideas and models that have the most value and leave the "mistakes" behind.

MS has to drag all of their dirty laundry forward with each successive release lest they annoy some developer that can now no longer run something he wrote "a few months ago" on a new platform.

It is certainly possible (in fact not uncommon) to write PHP inside HTML. I have done it and even used the PHP to write more HTML 'on the fly'. I don't see why COBOL: shouuldn't be used in the same way.

Lost out to C/C++ in the market.

Joe

It was mostly propped up by the DoD’s insistence on its use.

I was a great fan of VisualAge C++. Version 3.08 had by far the best debugger I’ve ever used—when one thread hit a breakpoint, all threads stopped right away.

That made multithread program development way easier.

Cheers

Phil Hobbs

Yes, although the top-down crowd was all in because Ada promised to force programmers to be better by tying their wrists to their ankles.

Did anyone else ever adopt that? I'm thinking it might be awkward to implement in an interrupt-driven threaded kernel.

Too bad it never escaped the IBM ecosystem.

Joe

That's how most ICEs work (of necessity). It was usually more of a hindrance than a help as now the hardware is frozen in a particular state and the machine has no way of ensuring it returns to a safe/stable state while you're trying to sort out what has happened. E.g., a mechanism is now in motion without supervision.

My (run-time) debugger lets you decide whether the thread, process, core or machine is "interrupted" by such conditions. You can exploit this to ensure an independant thread/process/core can continue to execute to bring the machine to a safe state (because a thread/process/core could potentially "stop" during production code and you'd still want the design to protect itself).

Dunno. AFAIR it worked fine with SMP kernels in OS/2. Around 2005 I moved to XP and Linux on a homemade cluster (seven dual-processor pizza boxes).

I quite liked the Intel C++ compiler at the time—it outperformed MS on vectorized FP code by about a factor of 2, and both left that era’s GCC in the dust.

Yup. I still have Warp 4.5 (Aurora) on a Virtualbox VM somewhere, but haven’t tried using it in a dozen years.

Cheers

Phil Hobbs

Joe Gwinn wrote: |-----------------------------------------------------------------------| |"On Mon, 22 Jun 2026 12:29:02 -0700, Jeff Liebermann snipped-for-privacy@cruzio.com| |wrote: | |[. . .] | |>>IBM decided to focus on Java so it sold off its Smalltalk and Ada | |>>divisions. | |[. . .] | |>I don't know what happened to Ada. | | | |Lost out to C/C++ in the market. | | | |Joe" | |-----------------------------------------------------------------------|

IBM does not support C/C++ instead of Ada. IBM favors Java instead of C/C++. IBM sold its Ada-compiler division to a different Ada-compiler company. (S.

IBM operation systems of the day were typically polled at ten Hertz or so; interrupt-driven multithreaded kernels came later. HP's operating systems did the same.

It's the difference between maximizing throughput and minimizing latency.

Yes.

It will likely drop into hyperspace if you even try.

Joe

Don Y snipped-for-privacy@foo.invalid wrote: |-----------------------------------------------------------------------| |"MS has to drag all of their dirty laundry forward with each successive| |release lest they annoy some developer that can now no longer run | |something he wrote "a few months ago" on a new platform." | |-----------------------------------------------------------------------|

I do not feel sorry for a millionaire for making business decisions which made it a millionaire.

"Windows 10 is being updated way too frequently (twice a year) and each new version changes something that breaks Classic Shell." complains a Classic-Shell programmer since 2017. Cf.

(S.

If those decisions limit your future ability to make money, then they are consequential. Windows Phone, anybody?

Then "The Cloud" and cloud services.

Now AI.

Meanwhile, you've got talent tied up forever supporting 40+ year old decisions.

Some components update themselves almost daily.

But, one can say *all* OSs update themselves too frequently once the distinction between kernel and userland got blurred in the minds of users. And, once vendors got trapped into supporting bolt-ons AS IF they were integral and indespensible parts of the OS.

That's fine as long as the millionaire didn't start out a multi-millionaire or billionaire.

I highly recommended Open Shell. Not including my own, I currently support about 50 Windows machines. (I'm allegedly retired). In the distant past, it was something like 200+ machines. Every one of those machines are running Open Shell, a fork of the original Classic Shell:

Open Shell offers my customers a stable desktop environment that looks very much like previous Windows environments that my customers have learned to use. In many cases, my customers didn't even notice that they had a new Windows desktop environment. Open Shell updates are mostly fixes for things Microsoft had broken. For myself, it's a huge time saver not having to teach every user a new and allegedly improved way to operate their computers. Currently, the Open Shell start menu is immune to Microsoft ad injection and distracting wiggly icons. That feature alone makes Open Shell worthwhile.

When was "of the day"? IBM had interrupt-driven mutithreaded systems back in 1967, ie: MVT.

Adapting to the superficial changes in the desktop is annoying but largely a fixed investment.

The killer issues, in Windows upgrades, are the ABI changes that make supporting *other* MS (and third party) apps on the new OS difficult or impossible.

SWMBO relies heavily on O2KPro which was tedious to get running on W7 (I think support ended at XP/W2K3S). The move to O2K3 would have broken many of her apps and required a significant amount of in depth relearning as the UI/UX in O2K3 changed as MS shifted towards supporting web-based use of the tools.

I, personally, lament the changes that have made After Dark "troublesome" to use.

To computer users, who are either too busy to learn new things, or too old make the attempt, those "superficial" changes are a major stumbling block. They will never get to application problems if they can't get past the absolute basics.

I'm currently dealing with a customer who has the intelligence to understand the importance of making backups, but refuses to do backups because he's either too busy to make backup or simply doesn't want to bother. If he runs into an application compatibility problem, he simply buys a new computer with the latest software. That will keep him treading water for the following 5 to 10 years or to his next clueless mistake. A consistent user interface is critical to keeping such customers functional. Unfortunately, most of my current customers are like that. They're easy to spot. They don't or won't take notes when I explain how to do something important. If I blackmail them into taking notes, they have the amazing ability to not be able to find those notes when they are needed. When a software vendor (including Microsoft) makes a mistake or "improvement" that causes problems, it usually affects thousands of users. These are not a problem because I can usually find the answers with a web search or on a specialized forum. Finding the solution is much easier than teaching the user to apply it. Remote control software often fails because the user can't find the icon on their desktop.

True. I'm sometimes tempted to installing VM (virtual machine) software and staying with an older version of the applications software. Or sometimes, it's easier to just add a 2nd computer on their desk with a KVM switch. I have that arrangement for several customers. It's a nice way to deal with legacy software and vendors who use software updates as an excuse to charge large amounts for software upgrades or force renting the new software.

After Dark is an old screen save: