• 0 Posts
  • 82 Comments
Joined 2 years ago
cake
Cake day: July 3rd, 2023

help-circle

  • 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.



  • 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.



  • 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.






  • 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).




  • It’s a tool with a medium-high skill floor and incredibly high skill ceiling. It rewards investment and is something that is able to accommodate one’s growth in skills rather than holding them back with limitations like typical editors do. Its built-in scripting is a big part of that and is something that really sets it apart from editors like vscode. And it’s much, much faster and lighter weight/less memory-intensive than other editors.


  • It’s not as big of a deal as you might think. You still have a lot of your muscle memory from regular keyboards. It might take a little while to adjust when switching between the two, but it’s not that bad.

    If you switch between the two enough, you can actually type on both equally well.


  • A lot of mechanical keyboards these days are programmable using QMK Firmware. I actually use https://www.caniusevia.com/ instead though, which uses (a subset of) QMK under the hood but allows programming the keyboard via a Web app on the fly.

    For my layout, I have the standard QWERTY layout for the unmodified layer (layer 0, holding no keys). Then I can hold down a thumb key for switching to a different layer, which has things like symbols, F1-F12, Home, End, etc. The layout I use isn’t too far off the default Iris layout, just a few tweaks here and there (like one that allows me to hold a key for control, or tap that key for escape).



  • expr@programming.devtolinuxmemes@lemmy.worldWell, where?
    link
    fedilink
    arrow-up
    5
    ·
    edit-2
    21 days ago

    Ctrl-C absolutely should not exit. There’s plenty of times you want it in vim to interrupt something in the editor.

    As others have said, it’s on the screen if you open vim without a file. Otherwise, it’s a tool for people that bother to learn how to use it. As someone who has been using it daily for the last 10 years, I would find it incredibly obnoxious to have a bunch of useless screen clutter telling me basic things that are easily learned.


  • It’s simply muscle memory. You think of the action and your fingers do it faster than you can consciously think of where they need to go. But I also use a split ergonomic keyboard (the Iris) and have symbols accessible from home row behind a layer. Though I can switch to a standard keyboard as needed too.