lad

I’m afraid it’s DLC only content, and requires a lot of macro-transactions

Only surviving ones

Got it. I agree that their drivers are (were?) of exemplary bad quality

But I don’t think that it is realistically possible to drop all the proprietary firmware blobs, and if it’s not maybe it’s better to not actively sabotage something to ‘avoid those being feasible’?

What’s the reason to avoid binary blob drivers being feasible? Is that about not being able to use non-free binary blobs in kernel? I don’t quite understand what it even is about

in which case, enjoy your privilege

…for now

Sometimes this is useful, though. Other times it’s infuriating 😅

You don’t need to use and learn everything, just pick what you need.

I used to think the same, but now I think you should at least skim through everything. Reason being otherwise you may reinvent the wheel a lot, and there are many use-cases where you really don’t want to do that (but C++ makes it so easy, I was constantly tempted to just do what I want and not look for it being already available)

A lot of computational heavy tasks for science were done in Fortran at least ten years ago (and I think still are). I was told that’s mainly because Fortran has a good deal of libraries for just that, and it was widely taught in academia so this is a common ground between the older and newer generations.

I think it may be gradually superseded by Python, but I don’t know if it is

Yeah, “nobody wants to work anymore”, but “we’re not willing to pay for 10+ years of experience, yet we’re only looking for 10+ years of experience”

So I who am careful to write readable and safe code

I just want to point out that it’s hard to be sure your code is readable if you don’t work with a team. More than once I saw people write “readable” code that was not readable. My own code I deemed “readable” was in fact not, as time had shown when I returned to fix something. So, the cited part looks a bit arrogant 😅

All heil Rust-toad

Rust is a bunch of great pieces that don’t fit together well.

That might change over time.

Down that path C may become somewhat of an intermediate representation language for binary interfaces. No one would write it by hand, and maybe for the better

And COBOL is listed as third-generation on Wikipedia, too.

I now remember reading about this concept of generations in a book about Ada, it seemed fascinating then but turned out to not be as good as expected 🥲

Also, Unix Shell is listed as 4GL example. There are SPSS, MATLAB, R, and Wolphram Alpha in the same list of examples, that kind of shows where 4GL went today.

I guess, opening a PR without forking is possible, but hey that’s sort of incredibly bullshit idea

Are we still talking about COBOL?

To be fair, I disagree with all the points author makes, except for performance which is important but may be less important than code clarity in different cases. I am surprised that exceptions perform that well, and I am surprised the author said that compared C++ exceptions to Rust results, but actually did the right thing and compared C++ exceptions with C++ expected first. I thought it was going to be one of those “let’s compare assembly to lisp”

Yeah, I shaped my words poorly. What I meant is that errors are sort of equivalent to exceptions, but errors are first class citizens of type system, and this is an improvement over exceptions being kind of independent of type

Have you ever worked at large old corporation? Wasting money is a bit of an underestimation on that scale.

Also, not all banks use COBOL, but the ones that don’t are usually much younger.

Besides, Ada would’ve been a better example, as it is used by telecoms and seems to be held in high regard, unlike COBOL. The only issue with Ada I heard of is that it’s on par with C++ in complexity which is far from being simple.

I’m just going to ask, without making assumptions. Have you managed to cut some time to read the article and find an answer?