historyloop

It can be tricky in that fuzzing your program to discover race conditions seems to behave perfectly on one compilation target where these atomics are detected and reified, while you later discover on another platform surprisingly your app crashes 20% of the time.

Ideally we test our applications on all hardware, with all configuration permutations etc. etc. In practice we do rely on our compilers translating our intent accurately and sometimes such edge cases matter.

Compatibility is a tricky thing. It's kind of like the argument whether adding optional arguments to a function breaks BC. It doesn't break BC if you don't pass those parameters. But if for some reason you were passing extra parameters hoping they'd be ignored (for example as a handler some other place) then adding optional parameters WILL break BC and cause your software's behavior to be undefined.

The gist of the article is that software projects have more ad-hoc decisions and more flexibility. This is due to the nature of software. To claim this as a justification that software engineering is not engineering seems rather shallow to me.

You have less repetitive process in software because once software is built, copying it and reusing it as-is is free. In construction if you need to build 10 twin buildings, each of them is a project on its own. In software that'd be building one piece of software and deploying it 10 times.

Furthermore I question the notion that software projects can accommodate more "fundamental midcourse design changes". Can you spend 2 years writing a dedicated Windows desktop application and then midway suddenly switch it to being an Android application? That would be fundamental. Reskinning the UI or replacing a dependency with a similar one is not fundamental design change.

Software can't sustain fundamental design changes, unless we misinterpret what is fundamental and what isn't.

Basically we need to be careful with our analogies so we don't cross from trying to extract insight into flexing our useless cynicism about how software sucks because it's not like making a car in a superficial ways.

Standards can only happen when an industry has matured and moves slow enough for these standards not to be obsolete by next year.

We have plenty of laws and standards regarding handling private information, payment systems, independent pen testing and so on. So it's incorrect to say we have "no standards" at all. Where it matters, we do.

But to try and standardize a process that's evolving faster than a standard can spread is pointless.

This doesn't make software engineering any less engineering. Engineering isn't about standards. It's about the design, construction and use of systems.

Question: why do you claim EdgeDB is a "relational" database when you can't actually do relational algebra with it? How do you join?

Materialized edges (i.e. what you call "links") are not part of any relational model, it's a part of the graph model. You seem to have implemented a graph database, but possibly without the graph walking capabilities of graph databases.

> EdgeDB, a relational database with strongly typed schema

Relational database without relational algebra wouldn't be useful, would it? So... uhmm. How do we join? There's no JOIN statement.

False dichotomy.

Introverts on average took less of a hit, as they didn't see much change to their lives and many of them already had remote jobs they were able to keep during lockdowns.

This doesn't mean they're loving it.

Well I gotta say many preppers were loving it though.

It's interesting that you know SELECT being first is clunky, without understanding why.

SELECT in SQL is clunky because it comes before FROM and JOIN. Do you see FROM or JOIN anywhere here? No.

The collections you're selecting from are literally written before the fields you select.

The real WTF for me is this claims to be a relational database and you can't join seemingly.

Did the author forget that we had this entire "NoSQL" period that lasted well over a decade, where SQL was the worst thing ever, and everyone kept coming with the superior alternatives to SQL?

What happened?

What happened is many of those NoSQL products started adding SQL syntax and features to their databases, others disappears, and yet others specialized into niches where they don't compete with SQL RDBMS at all, which remains the primary database paradigm and language.

So those are the facts. If someone still believes they know better, put up or shut up.

SQL isn't immutable, it's always evolving. I find it awkward some of the arguments in the article read like "you couldn't do that before CTE was added". But it WAS added, so?

If you want to fix SQL, contribute to the next version of the standard, or provide example by implementing what you want to see out there.

We need to go back to fixed width all caps green text on black background for everything.

Eventually blue text on black background, but that's as far as I want to go.

Black Widow is destroying opening expectations in cinemas as we speak.

Barry Diller is clearly disillusioned with the process, this happens a lot with veterans. But there's a constant supply of wide-eyed youngsters to fill-in those positions with new energy.

I'd say it's a bit premature to declare permanent changes. Streaming will play a stronger role over time, but none of this is new or unexpected. And cinemas will continue to thrive.