361–370 of 448 posts
Earlier quoted context omitted.
Still doesn't beat Assembly, which will continue running on Voyager 1 even after the inevitable demise of our planet. Would survive the end of our solar system too.
Assembly ain't a language. Differs for every chip microarchitecture. Doubt there's many folks who know voyager 1 assembly
Your last sentence explains why ASM is a language. ASM compiles to machine language.
Earlier quoted context omitted.
I mean, if you squint your eyes a bit, that could be SQL! So even if it's not COBOL, there's people out there writing in a vaguely english business programming language.
The nice thing about a vaguely English like language is that your average LLM is going to do a better job of making sense of it. Because it can leverage its learnings from the entire training set, not just the code-specific portion of it.
Cloud is the new mainframe, except worse. It has all the downsides, but does not have the biggest upside. The grandpa could create (using CICS), a very reliable and performant service that would call other services inside the same transaction. The platform would handle all the complicated stuff, such as maintaining data integrity. Try to write AWS Lambdas that call each other within the same transaction.
> It has all the downsides Vendor lock-in from a single vendor? Wildly expensive capex and opex? Impossibility for people to know any of the tech involved without you sending them on a course to learn about it or them already having experience with it? > Try to write AWS Lambdas that call each other within the same transaction. Why is that your comparison? Was deploying to the mainframe as simple as throwing a .zip w…
Is this a trick question? The answer is 'yes' to all three.
Earlier quoted context omitted.
There is a disconnect somewhere. When I read online, I hear about how GenAI/LLMs replace programmers and office workers. When I go to work, I mostly hear the question of how we can apply GenAI/LLMs, apart from discussion of the general buzz. Maybe this is a reflection of local conditions, I'm not sure, but it doesn't seem like the truly revolutionary changes require the solution to find a problem. It was immediately…
Electricity famously took perhaps twenty years for people to slowly figure out how to re-organise factories around it.. Hence the delayed impact on productivity figures. To elaborate: in the bad old days of you had one big engine, eg a steam engine, that was driving shafts and belts all around the factory. There was a lot of friction, and this was dangerous. So you had to carefully design your factory around these co…
"Let’s look at the brief history of computers. Best way to understand it’s probably an analogy. Take the electric motor. The electric motor was first invented in the late 1800s. And when it was first invented, it was only possible to build a very, very large one, which meant that it could only be cost-justified for very large applications. And therefore electric motors did not proliferate very fast at all.
But the next breakthrough was when somebody took one of these large electric motors and they ran a shaft through the middle of a factory and, through a series of belts and pulleys, brought…shared the horsepower of this one large electric motor on 15 or 20 medium-size workstations, thereby allowing one electric motor to be cost-justified on some medium-scale tasks. And electric motors proliferated even further then.
But the real breakthrough was the invention of the fractional-horsepower electric motor. We could then bring the horsepower directly to where it was needed and cost-justified it on a totally individual application. And I think there’s about 55 or so fractional-horsepower motors now in every household."
Earlier quoted context omitted.
To be fair, what we imagined was dystopian, too. It's just that some people with a lot of ambition and not much media literacy didn't realize it was dystopian, and set about to build that future.
could have been high budget dystopian at least!
Oh, btw, COBOL has the 2038 problem and it is right around the corner. We're going to need A LOT of new COBOL engineers to fix it. It runs so much of our world. We managed to save the world from Y2K in the nick of time. But, I'm not sure if we're going to have the minds necessary to solve 2038 by then as the can has just been kicked down the road without consideration. If anyone is worried there won't be jobs, there…
This sounds interesting, but I wonder who this message needs to be directed to? As a dev who doesn't work there, I can't just go "fix 2038 for the post office." Are you encouraging devs like me to go try to get themselves hired into these positions now, and advocate allocating resources to fix these problems? Are you trying to tell the higher-ups at these places about a problem they might not know about?
Oh, btw, COBOL has the 2038 problem and it is right around the corner. We're going to need A LOT of new COBOL engineers to fix it. It runs so much of our world. We managed to save the world from Y2K in the nick of time. But, I'm not sure if we're going to have the minds necessary to solve 2038 by then as the can has just been kicked down the road without consideration. If anyone is worried there won't be jobs, there…
> we need to transfer the knowledge while the people who have it are still alive Nah. We need to not transfer that knowledge, because the problem will be solved when the house is on fire. But do not worry : nothing will happen until then. If those people cared, they would work to replace all that cruft, not enhance it to fix 2038.
Earlier quoted context omitted.
dBase and its numerous descendants and competitors (FoxPro, Clipper etc) were extremely popular for line-of-business desktop applications in the 90s. And, yes, they are indeed traditionally categorized as 4GLs - and, given how nebulous the definition always has been anyway, I think that "traditionally categorized" is the most practical definition that you can use here. But, yes, I agree that aside from the generally…
That class of software also allowed for very efficient data capture against normalised tables. A recall as early as Paradox for DOS (something I haven't thought of for a while) in about 1990 being really simple tools for creating one-to-many database capture 'forms' (with selection boxes, date drop downs, the lot). The richness of form design and tight coupling to the database meant that the language did not need to…
Earlier quoted context omitted.
> It has all the downsides Vendor lock-in from a single vendor? Wildly expensive capex and opex? Impossibility for people to know any of the tech involved without you sending them on a course to learn about it or them already having experience with it? > Try to write AWS Lambdas that call each other within the same transaction. Why is that your comparison? Was deploying to the mainframe as simple as throwing a .zip w…
> Vendor lock-in from a single vendor? Wildly expensive capex and opex? Impossibility for people to know any of the tech involved without you sending them on a course to learn about it or them already having experience with it? Is this a trick question? The answer is 'yes' to all three.
For AWS, it isn't. Outside of a few narrow exceptions, there is no vendor lock-in into a single vendor. (A container that can run into Lambda can run into Google Cloud Run just fine).
There is no capex with AWS.
There's a free tier and it's freely accessible to anyone. Anyone, and I mean anyone, can start learning it if they want to.
Good luck getting access to a mainframe to play around to see how and what works. Or finding any useful tutorials from this century.