81
Root
137d

Best: the tool that works for the job.
Worst: the tool that doesn’t.

Example: Ruby is great for scripts and web dev, but simply doesn’t work for graphics engines.

Example: SQL is great for fetching data (etc.), but it is absolutely terrible for business logic.

Example: XSLT is great for lowering your faith and your will to live, but it is absolutely awful for literally every other purpose.

Comments
  • 3
    PL/SQL is fine for business logic but you do run into scalability issues.
  • 8
    @AlgoRythm Just no.
  • 3
    @Root Yeah, yeah, I know. But outside of tech savvy, (even just minimally) forwards-thinking programs, you're gonna find a ton of shitty business apps that do tons of work in the DB

    I work on PL/SQL that was written when I was 7. Didn't even have my first computer yet, and someone was writing the same scripts I pull my hair out over today.
  • 2
    @Root

    Well... for Ruby: https://github.com/ArekX/RAGE

    Works pretty well. :D
  • 0
    But yes it's not a pure ruby implementation. Pure ruby implementation would have horrible performance.
    As for SQL. Even in 2021 apps unfortunately people still store logic in DB. Sometimes, you really have no choice but to use it. :/
  • 5
    A graphic engine in SQL
  • 0
    How can you avoid business logic on SQL if your logic requires data from the db? You don't want to keep doing round trips for every check just so the logic is on the server, right?

    Edit: even if you fetch all the data required before hand, it's still at least 2 trips...
  • -1
    >Ruby is great for scripts and web dev, but simply doesn’t work for graphics engines.
    who the fuck writes a graphics engine in ruby?
  • 5
    @bananaerror They’re generally quick. Fetch what you need. Separation of concerns (and therefore maintainability) is much more important than optimizing on the order of milliseconds.

    @plus44 Nobody sane! I’ve made games in Ruby, too, but I lost my sanity years ago.

    @arekxv I’ll take a look at that later. Thanks :)
  • 3
    I feel this on so many levels I need a stylesheet to express them.
  • 2
    Spot on for XSLT..
  • 1
    @AlgoRythm dude if u use sql for business logic please do us all a favor and move to UI/UX design.
    none of us deserve to refractor that mess.
  • 0
    @ostream let's do it..
  • 0
    @maces I don't write it I just maintain it
  • 0
    @AlgoRythm move it to the backend and then take the hard disk where source control is saved and burn it with a flame thrower
  • 0
    Hahaha, XSLT - I’ve worked at two companies over my career that had an absolute love affair with XSLT. I see the purpose of it, but it’s like regex for me, I can’t write it from memory. When I tell the younger devs that XSLT has been around since the ‘90’s they think I’m lying: “But we’re using it in our newest applications, how can’t it be so old?” Here, let me google it for you kids.
  • 2
    @maces we don't have source control for our SQL if that gives you an idea of the shitshow I get paid $not.enough to deal with
  • 1
    @AlgoRythm dude now I love my place
  • 2
    @AlgoRythm No source control for SQL has been an issue in 100% of the places I have worked. When I hear: “Stored procedures are bad”, that just confirms to me that someone has no source control over their SPROCS. They’ve been burned by not knowing which is the right version of the code.
  • 1
    @fiftyhz all the time. Currently, in fact. Past three weeks the site load times have been doubled after a DB move.

    Even if I had a say, I don't have any love for this project anyways and I wouldn't bother fixing it.

    Stepping stone job.
  • 0
    First 2 lines said it all
Add Comment