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

help-circle

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



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



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






  • 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
    4
    ·
    edit-2
    1 month 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.




  • None of what you described requires a video. Articles can be written for different audiences, and, in fact, are much more capable of mixed-media content. Text can be selected/copied/consumed by screen readers etc, graphics can be embedded with accessibility information (unlike videos, which can easily contain inaccessible content), images can contain controls that allow one to pan, zoom, etc. and can be separately downloaded, other file types can be embedded with their own controls (including animations, as needed). Relevant related content (like, say, documentation) can be linked inline where it’s referenced, rather than dropping a huge bag of links in a video description. Articles can be indexed, searched, translated, and more. Articles also allow each person to consume the content at their own pace, rather than whatever pace is determined by the person in the video. I personally find videos agonizingly slow compared to how fast I can read.

    Videos are an ineffective mechanism for communication of information, particularly for information that is more complex or technical in nature. They are popular due to the ever-shrinking attention span of people, but that doesn’t mean we should optimize for that.


  • I mean, it explains things at length, but it’s all fairly accurate.

    As a senior engineers writing Haskell professionally for a number of years, I’ve found it much simpler to teach about Monads after having taught about Functors and Applicatives first, because there’s a very natural, intuitive progression, and because most people already have an intuitive grasp of Functors because map is cribbed so commonly in other programming languages. I’ve used this approach successfully to teach them to people completely new to Haskell in a fairly short amount of time.


  • Yeah most developers haven’t the slightest clue what it means. Most people use it to mean a shitty version of a RPC API with a bad query language.

    If you’re going to do that, you may as well use something that’s actually meant for that, like the numerous RPC protocols available. Or hell, even GraphQL (which is basically what you’re saying).

    REST can take different forms, but all of them necessarily require you to be talking hypermedia-enabled APIs. If your resources (read: not endpoints, which are not a concept in REST) do not contain links to other resources, you aren’t doing REST and you should stop pretending that you are.