@dekkzz76 Yes and severe more—since 1982, so I’ve had loads of time to bone up. Often, I had to use a few of these languages simultaneously for different clients, and teach a handful simultaneously back in my academic days. I like all those languages, more or less. But my favourites are few.
@dekkzz76 Me too; I like all of Wirth’s babies—to varying degrees. He’s a genius. I might still have my copy somewhere of the Wirth & Jensen book on Pascal.
@dekkzz76 It wouldn’t have been easy. Do they have Oberon packages now?
Long ago here, DoD was enamoured with Ada, and the brass tried to force a conversion of all their systems from Fortran, C, Cobol, etc., to Ada. Programmers just about mutinied.
By the way talk about far flung languages: have you used Eiffel? That “contracts” concept was novel, some decades ago.
One of the variants had a launch able image for linux
Ada has its place, but any lang is just a tool, forcing a lang into a hole just costs you money. i've seen dying projects turned around just by the right language choice
yes i looked at eiffel, another interesting one is pony with it's actor model
@dekkzz76 When you work with web tech, have a look at Grain. It generates to wasm. It’s fast compared to JS, but the current compiler isn’t sophisticated; code size is large.
@dekkzz76@lproven I assume you're asking me about my tirade about OS being "the browser". You know I'm an old curmudgeon, Dekks. So, I'll offer a simple solution that my old brains can grasp. Don't expect a "simple solution" to be welcomed by modern IT community, though.
First, today's OSs are sophisticated and secure—well, compared to 4.2BSD of my day. So, eliminate the browser, and make the OS securely "interpret" a standard "binary", like WASM or LLVM binary, or something newer. But most importantly, eliminate the middlemen: browser, WebSockets, HTTP, SSL, the lot. Use BSD Sockets directly. I'm proposing to revert to the 1980s software distribution model, augmented and secured using modern techniques.
Secondly, we now have hundreds of thousands of programming languages, each with a legion of ardent supporters. Yet, all languages have one thing in common: they all have to be translated into ASTs which are subsequently transformed into native binary, sooner or later. Liberate us programmers! Let us use whatever source language we fancy, and have the IDE, runtime, and other intermediaries take care of translating between high-level languages. In the early 1980s, we used to have raging fights over how we format FORTRAN, LISP, COBOL, C, Pascal, whatever, source code. Today, we use the IDE to reformat someone else's code into our preferred style. The same can now be achieved at the programme source text.
I assure you; no one will agree with my perspective. It's too old, too simple, too mundane.
@AmenZwa@dekkzz76 AmenZwa, ISTM that what you want is, in a way, Inferno.
Inferno is what came after Plan 9. Plan 9 was UNIX 2.0: it's what the creators of Unix and C did next.
Inferno is UNIX 3.0.
It embeds a runtime, Dis, right into the kernel, and all apps are compiled down to Dis code. So all its native binaries are cross-platform and execute on all CPU architectures Inferno supports: the same executable runs on x86, Arm, MIPS, PowerPC, anything.
@AmenZwa@dekkzz76However, I think you're barking up the wrong tree with SOCKETS everywhere. Plan 9 shows that you can abstract away networking into the filesystem in a clean, cross-platform way that does away with special APIs.
That seems far preferable to me to what you propose.
@lproven@dekkzz76 My main point is this. It'd be more efficient and effective, if we adapt already adopted technologies that are next to the hardware, instead of coating higher and higher levels of abstraction atop an already bloated web technology stack. It is wasteful to implement WebSocket, WebWorker, etc., inside a browser, when WebSocket just mirrors the TCP protocol, WebWorker just mirrors lightweight threads, and Web browser just mirrors the operating system.
I wasn't proposing to ditch web technologies and revert to Bill Joy's 4.2BSD Sockets from 1982. In frustration, I'm pointing out the obvious wastefulness I see.
@AmenZwa@dekkzz76 Which is precisely the point I was making. These problems were solved decades ago. We just need to adopt the existing, working solutions. We do not need to come up with new solutions. Indeed we'd all be better off if we stopped coming up with new solutions in general.
@lproven@dekkzz76 Then, we are in perfect agreement. We all must acknowledge our industry's lack of restraint and find better ways ahead, if we wish to see fundamental improvements therein.
To that end, I wish to reiterate that I wasn't proposing a new technology stack; I was lamenting about the imbecility of reimplementing the OS-level technologies in the Web stack. Retrenchment rather than reinvention, as it were.
@AmenZwa@dekkzz76 I think that among the most useful contributions old timers here can make is to ensure that they know the prior art, select and pull out and highlight the relevant parts.
And those are not from BSD 4.2. Unix advanced for decades more after that.
There is much more to learn from the offspring of Research Unix than from the BSDs, IMHO.
@lproven@dekkzz76 I agree. For clarity, let's avoid citing specific implementations of technologies. That's why, in my latest interaction, I deliberate used "TCP protocol", instead of Sockets; "lightweight threads", instead of "PThreads"; and so on. Things are way too complicated as they are; we needn't muddy up our attempts at simplification and clarity.
@lproven@dekkzz76 I usually work with signal processing, image processing, radar, etc. I don't mean to trample the grounds outside my domain.
And I take your pointed objections about my choice of terminology. I was using those terms to describe the reinvention of old technologies in the Web stack, so I couldn't have avoided their use.
Add comment