Naturally, vim is still acceptable.

Except it’s not seamless, and never has been. ORMs of all kinds routinely end up with N+1 queries littered all over the place, and developers using ORMs do not understand the queries being performed nor what the optimal indexing strategy is. And even if they did know what the performance issue is, they can’t even fix it!

Beyond that, because of the fundamental mismatch between the relational model and the data model of application programming languages, you necessarily induce a lot of unneeded complexity with the ORM trying to overcome this impedance mismatch.

A much better way is to simply write SQL queries (sanitizing inputs, ofc), and for each query you write, deserialize the result into whatever data type you want to use in the programming language. It is not difficult, and greatly reduces complexity by allowing you to write queries suited to the task at hand. But developers seemingly want to do everything in their power to avoid properly learning SQL, resulting in a huge mess as the abstractions of the ORM inevitably fall apart.

Access modifiers are definitely something I despise about OOP languages, though I understand that OOP’s nature makes them necessary.

The encryption thing is definitely weird/crazy and storing the SQL in XML is kinda janky, but sending SQL to a DB server is literally how all SQL implementations work (well, except for sqlite, heh).

ORMs are straight trash and shouldn’t be used. Developers should write SQL or something equivalent and learn how to properly use databases. eDSLs in a programming language are fine as long as you still have complete control over the queries and all queries are expressable. ORMs are how you get shit performance and developers who don’t have the first clue how databases work (because of leaky/bad abstractions trying to pretend like databases don’t require a fundamentally different way of thinking from application programming).

deleted by creator

I think the point is not that it’s a MacBook, but that the senior is using a single laptop instead of a full multi-monitor setup.

Personally as a senior, I use 4 monitors. My eyes are too shit to stare at a tiny laptop screen all day, and I want slack/browser/terminal windows on their own screens. It’s much more comfortable as well.

Removed by mod

Heh yeah that’s pretty straightforward:

SELECT a.*, COALESCE(b.some_col, 'some_default_val') as b_result
FROM a LEFT JOIN b ON (a.id = b.id);

This will produce at least 1 row for every row in a, and if a.id doesn’t match any b.id, the value of b_result will be 'some_default_val'.

Not sure if that’s exactly what you were describing (since it was a little ambiguous), but that’s how I interpreted it.

Ultimately it’s just a matter of investing a little time to learn it. It’s not fundamentally difficult or complex, even though you certainly can write very complex queries.

To be honest, it’s remarkably simple for what it’s doing. There’s a ton of details that are abstracted away. Databases are massively complex things, yet we can write simple queries to interact with them, with semantics that are well-understood and documented. I think, like anything else, it requires a bit of effort to learn (not a lot, though). Once you do, it’s pretty easy to use. I’ve seen many non-technical people learn enough to write one-off queries for their own purposes, which I think is a testament to its simplicity.

You seem to have missed the part where I said “unless there’s imminent danger”.

It doesn’t arbitrarily double rows or something. For each row in the relation on the left of the join, it will produce 1 or more rows depending on how many rows in the relation on the right of the join match the join condition. The output relation of the join may have duplicate rows depending on the contents of each joined relation as well as what columns you are projecting from each.

If you want to remove duplicates, that’s what DISTINCT is for.

That’s the whole point of a left join? Anything else wouldn’t be a left join anymore.

No variables, no functions

Every major SQL implementation includes both of those things. Of course, it’s rarely needed or desirable if you know how to properly write SQL.

“So why can’t you do that with expressions?”

You can alias expressions.

And then you try put a MAX in a where and it won’t let you because you gotta pull all the maxes out in their own query, make a table, join them in, and use them like a filter…

Wtf are you talking about? For one, filtering by the output of an aggregate is what the HAVING clause is for. But even if that didn’t exist, you could just use a subquery instead. You don’t need to make table…

Tbh it just sounds like you don’t know SQL very well. Which is fine, but doesn’t make for a very compelling criticism. SQL does have warts (even though it’s great overall), but none of what you described are real problems.

Yep. Postgres rocks. No idea why anyone would bother with anything else. They all suck in comparison.

Nope. Yelling isn’t okay. Parents are human and may do it anyway, but it’s always a mistake and should be treated as such (except in the case of danger as mentioned above). It absolutely should be avoided as much as possible. It’s an incredibly harmful thing to do (for any relationship, actually).

Yelling is never okay unless there’s imminent danger and yelling is needed to prevent it.

Sure sounds like an LLM.

It’s not exactly like vim, and there are plenty of vim plugins that don’t work with it (anything vim8 onward). There has never been a 1-to-1 correspondence, the gulf widens as both develop different features with different philosophies.

The most egregious offense on Neovim’s part that I can’t get past is the removal of access to the shell in which you run vim (via :!, :w !, etc.). Vim is so much more capable of being closely intertwined with the shell, whereas neovim requires everything to be done through terminal buffers (speaking of which, vim’s terminal buffers are a lot better than Neovim’s).

Also, Lua is really overrated and worse for vim scripting than vim9script (which is both more native to vim and faster).

Most of vim is not emulated. It’s very surface-level and limited. The closest is evil mode for emacs, which is decent, but still lacks a fair bit. The emulators in Intellij and VsCode are paltry in comparison to what vim can do.

That’s why vim is so great: it has a ton of power built right into it without customizations, and it’s already installed on basically any unix-like system. Unlike, say, vscode, it can do a ton of stuff out of the box without any plugins at all.