true, but having it look like a component might get annoying. since this is likely to stay at the top, having an island of non components between two components might make it hard to see where functions start and end. and if this isn’t used directly inside a component it’ll just look dumb and inefficient (this also looks like it’ll take way more to edit once you change something)
I think I agree with you both. I’m not a Bode developer; could you keep your SQL objects/components in a separate file so that they don’t clutter up other logic?
I was disgusted by the XML at first, but it’s a readable query returning a sane JSON object.
Meanwhile, I’m mantaining Java code where the SQL is a perfectly square wall of text, and some insane mofo decided the way to read the resulting list of Object[] 🤮 is getting each column by index… so I’d switch to SQXMLL in a heartbeat.
Remember, XML was actually designed for use cases like this, that’s why it came with XPath and XSLT, which let you make it executable in a sense by performing arbitrary transformations on an XML tree.
Back in the day, at my first coding job, we had an entire program that had a massive data model encoded in XML, and we used a bunch of XSL to programmatically convert that into Java objects, SQL queries, and HTML forms. Actually worked fairly well, except of course that XSL was an awful language to do that all in.
React simply figured out how to use JavaScript as the transformation language instead.
Yes, it’s been established that you can still use JavaScript, and it will only backfire sometimes, even though it’s a bad language. And yet, people try to use it where it’s not even required.
It never ceases to amaze me how far idiots will go to avoid learning the most simple things. SQL isn’t hard, people’s difficulty with it says a lot more about them than it does SQL.
People think in different ways. What might seem logical to you might look alien to another. I know SQL well enough to optimize queries, but I find it a lot easier to think about and write queries as LINQ methods. A lot more cleaner and logical to my brain.
I’d like you to think for a moment about CTEs, the HAVING clause, window functions and every other funky and useful thing you can do in SQL … Now just think, do you think that this syntax supports all those correctly?
Don’t just summarize the content though, summarize the rationale or how things connect. I can read your diff myself to see what changed, I want to know the logical connections, the reason you did X and not Y, etc.
Or just say “stuff” and provide that context in the PR description separately, no need to overdo the commit log on a feature branch if you’re using squash merges from your PR.
As an amateur web designer in the 90s and early 2000s, this speaks to me. I stopped web development when CSS became popular and I couldn’t wrap my head around it.
Is there a petition I can sign to scrap all this nonsense modern web progress and go back to that beautiful, dial-up friendly HTML?
That’s known as a ligature and they’re pretty common in many programming-oriented fonts, which usually have stylistic sets with different ligatures for different programming languages that you can optionally enable in your editor’s configuration. For example, here’s the stylistic sets the Monaspace font offers:
Personally I’m not too fond of ligatures so I never enable any, but many folks do like them.
Edit: and just as a side note, ligatures are super common in many fonts, you just might not notice them. Here’s some classic examples from the DejaVu Serif font, with and without a ligature:
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.