7 ms·

Sometimes I wonder if it wouldn't be more efficient for people to just learn SQL instead of trying to build tools or layers on top of it that introduce more com

• remon 2y ago
  HN is inundated with posts announcing paper thin abstractions on top of existing technology or utilities that just move the goalpost of what you knowledge you need to be effective. It's a weird trend that seems almost entirely motivated by people wanting open source projects in their resume, or seek funding if its a startup.
  • dlisboa 2y ago
    > It's a weird trend that seems almost entirely motivated by people wanting open source projects in their resume That’s really harsh and misguided. If people didn’t do “paper thin abstractions” projects on their own time for the simple pleasure of doing it we wouldn’t have 90% of the successful projects we have today. Let people have fun and don’t judge their motives when they’re making something Open Source. I can guarantee the person just thought “this would be cool to have” and implemented it.
    • 6LLvveMx2koXfwn 2y ago
      Unless you're the GP your guarantee about the persons motivation is as meaningless as the post you're replying to.
      • ddispaltro 2y ago
        I think his point is that we should treat something given freely, charitably
        • EGreg 2y ago
          Charitably? This! Is! HN!
      • neilotoole 2y ago
        I'm not GP, but I am the sq developer. > the person just thought “this would be cool to have” and implemented it. Correct. This is true of much OSS, or at least I've always suspected so.
  • neilotoole 2y ago
    > It's a weird trend that seems almost entirely motivated by people wanting open source projects in their resume Developer here. I can't speak to what you see as the weird trend, but I can speak about sq's history: - I created the first version of sq circa 2013 as my own personal dev tool to address some pain points (amongst other things: getting JSON out of various DBs from the command line in a consistent manner, and wanting an easy way to inspect DB schemas, i.e. "sq inspect") - It was starting to be a minor PITA dealing with colleagues asking for the latest revision of the tool, so I open-sourced it. In 2016 or so I think? - sq is FL/OSS and will remain so, no funding is sought, not even one of those "buy me a coffee" thingies - I didn't create this HN post about sq, nor do I know the person who did. But thanks for sq's 15 mins of fame, kind stranger
    • syndicatedjelly 2y ago
      Thank you for creating a composable, simple to grok Unix tool. sq is an example of what is so great about the Unix philosophy. Personally, I can see a spot for sq in my developer toolbox. Instead of reaching for DBeaver’s bloated interface, or psql’s perplexing TUI, I like the idea of picking up an sq multitool to answer some simple questions quickly about my databases. Thanks again!
  • raydev 2y ago
    Thankfully that doesn't apply to this post. sq is a great, full-featured tool.
  • WhitneyLand 2y ago
    What a cynical take. Most people working on side projects do so because they find them interesting or useful rather than to just score resume points. They’re not moving anyone’s goalposts all usage is voluntary. The fact that HN is mentioned is also confusing. If something had no value beyond paper thin abstraction I doubt we’d be seeing it on the front page with 500 votes. Even if this project turned out to be less than hoped it seems counterproductive to complain about people creating and exploring. It’s a good thing to see and natural selection will do any sorting needed.
• mschuster91 2y ago
  SQL interop is where the pain is at. Using standard tooling of most database systems, best you can get is CSV with all the pains this shithole of a data transfer format brings.
  • itohihiyt 2y ago
    What's wrong with CSV? I love me a CSV file.
    • mschuster91 2y ago
      Out of the random shit I had to deal with CSV file wrangling in the last two years: - no defined encoding, so it may be anything from US-ASCII over ISO-8859-x to UTF-8 and it's always a guesswork what it actually is - no definition of the separator sign, usually it can be a literal comma, a semicolon, or tabs - escaping of the separator sign in column values is always fun - escaping of newlines is even MORE fun - line endings are not specified Every piece of software there is has their own expectations on what specific kind of format it expects, and to make it worse, using "Microsoft Excel" as a target/source isn't foolproof either because it behaves differently between the Mac and the Windows version! JSON in contrast is clearly defined in all of these issues and has battle-tested implementations in every programming language there is.
      • seanhunter 2y ago
        Most of these issues while real don't actually arise in this case, because we're not trying to ETL some random file, we are the ones talking to the database so we get to choose exactly how the data gets formatted on extract. For example, here's your list fully handled in postgres: 1. SET CLIENT_ENCODING TO 'value'; (eg 'UTF8') 2. COPY ... with FORMAT CSV DELIMITER 'delimiter_character' QUOTE 'quote_character' Now the output format is fully specified and everything just works fine (including for input into excel) The values in each record are separated by the DELIMITER character. If the value contains the delimiter character, the QUOTE character, the NULL string, a carriage return, or line feed character, then the whole value is prefixed and suffixed by the QUOTE character, and any occurrence within the value of a QUOTE character or the ESCAPE character is preceded by the escape character. https://www.postgresql.org/docs/current/sql-copy.html https://www.postgresql.org/docs/current/sql-copy.html
• zmmmmm 2y ago
  I think it'd be a moot point if SQL wasn't painful and awkward to work with in the first place. But database purists control it and won't let go, so we will have to live with everyone else inventing layers to make their lives easier.
  • dewey 2y ago
    For me this feels like the complaints about error handling in Go. People who work with it all the time, don't even think about it past the first week. If you are starting out it might bother people because they are not used to it. Personally I really like working with SQL and find it quite elegant, I always encourage people to use it as it really is a job-superpower if you can just dig up issues directly in the DB quickly. It has a long history so for every question you have there's many answers or avenues to ask them.
    • deergomoo 2y ago
      I agree with the GP’s point that people should probably just learn SQL, but there are things about SQL that are objectively bad, especially from the perspective of a software developer. It’s not a very composable or consistent language, so I think it makes total sense that we see so many abstractions over it.
      • jeltz 2y ago
        The issue with the abstractions over SQL is that while they fix some problems they always introduce a bunch of new problems so in the end SQL is still preferable. I have yet to see an example where that is not the case.
        • deergomoo 2y ago
          For me query builders are the quintessential example. Not ORMs, just thin layers that allow you build up a query in pieces. If you have cases where you might need to conditionally join, or have any reasonably complex filtering based on input, building up a plain SQL statement using string interpolation at the call site gets very messy very quickly.
• Xenoamorphous 2y ago
  It's funny because recently a "full stack" dev who's in reality 95% frontend was telling me he's not a fan of Tailwind and that he'd rather learn "proper" CSS. And the irony is of course, he never wants to use a relational DB to avoid SQL, so No-SQL DB it is.
  • nikolamus 2y ago
    Wat
  • freedomben 2y ago
    I've unfortunately met a number of "full stack" devs recently that are clearly 95% frontend as well, and have a very similar attitude as that person toward backend tech in general. We of course should not take such a small sample size and draw any sort of conclusions, but it's definitely a trend I'm looking out for now whenever someone claims to be "full stack." If the only backend stuff you've done is Firebase, or just a handful of serverless functions that don't do much, or if the "backend" you have in mind is just SSR-ing templates into HTML, then you really should qualify any claims about backend. One recently after
• fforflo 2y ago
  Paraphrasing Spencer: Those who don't understand SQL are doomed to reinvent it, poorly
  • EGreg 2y ago
    Actually, when it comes to SQL specifically, it almost demands using a language one higher up. Any language that features the ability to embed/interpolate unescaped quotes is not secure enough to be used directly by professional developers. Just not worth it to track down all the potential injection attacks. And if an abstraction lets you understand the structure of queries (eg for sharding them) and even writes the code for you and balances parentheses, flags other syntax errors at compile time etc. then it’s a net benefit. And of course there is the Adapter Pattern to abstract away connection logic and differences between mysql, pg, etc. I wrote the “Db” library 12 years ago in PHP and still use it. I never released it on HN for reasons like this. But I might. Here it is, embedded in my larger library, but I might break it out: https://github.com/Qbix/Platform/tree/main/platform/classes/Db https://github.com/Qbix/Platform/tree/main/platform/classes/... Documentation: https://qbix.com/platform/guide/database https://qbix.com/platform/guide/database https://qbix.com/platform/guide/models https://qbix.com/platform/guide/models One of the coolest features: https://qbix.com/platform/guide/models#relations https://qbix.com/platform/guide/models#relations If you read the above, please let me know your feedback! Question: Should I release it as a Show HN?
    • EGreg 2y ago
      I did it -- posting it here: https://github.com/Qbix/Db https://github.com/Qbix/Db
    • Hugsun 2y ago
      There's no reason not to post it.
  • simplify 2y ago
    SQL itself is a reinvention of Prolog, poorly. Its core value is that we're stuck with it.
• krosaen 2y ago
  I know sql pretty well and still find value in this kind of tool - creating schemas and inserting data is a clunky part of sql - the query language is where it really shines. So I can imagine using this to quickly insert some data or to get familiar with the schema and then dive in with normal sql queries.
• mattbrewsbytes 2y ago
  The sq and jq tools are both neat command line gimmicks but in my workflow their usefulness is very short. I can't imagine using sq on a query involving a handful of tables and some inner/outer joins. How would I know its outputting the correct SQL? If you mess up joins you end up with bad output. Here's my theory: some developers see simple languages that are easy to learn and want to build something more complex to output that language. Maybe its a sub-conscious thing. HTML is another one, if explained simply, HTML and CSS basic use cases should be easy-ish to pick up by nearly anyone. The fact that we have so many over-engineered frameworks and libraries out there that generate these is evidence of over complicating simple things. Maybe its called resume driven development? Maybe people see genuine useful frameworks that get wide adoption and are wannabes?
  • neilotoole 2y ago
    > How would I know its outputting the correct SQL? If you mess up joins you end up with bad output. The generated SQL is output in sq's logs, when logging is enabled. https://sq.io/docs/config#logging https://sq.io/docs/config#logging
    • mattbrewsbytes 2y ago
      If I have to go look at log files to see if the intermediary tool is doing the right thing, I might as well just write the SQL myself, right? jq has more use cases dealing with JSON that could come in handy. sq seems to handle trivial use cases but for complicated data models its going to be a hindrance.
• 8338550bff96 2y ago
  Lots of people struggle to understand the declarative programming language paradigm. It is really pesky because since you're declaring what kinds of results you expect rather than dictating what must be done, you're forced to define your boundary conditions up-front. Much more fun and exciting to charge ahead without worrying about such things
• goosejuice 2y ago
  There are a several features here that go beyond 'learn SQL'. I don't see how you could jump to this conclusion if you read the docs. Why does pgcli exist. What about dbeaver, datagrip, pgadmin, postico, LINQ, ORMs? It's almost as if people value different interfaces to databases. Maybe it's not for you, but it's not hard to imagine that someone, beyond the author, might find it useful. Maybe it's just me but to dismiss those people as individuals that should just 'learn SQL' is a pretty rude thing to say.
• deleted 2y ago
  [deleted]
• _hyn3 2y ago
  I tend to agree! but this seems to have a subtly different use case. It's actually very cool. I can see this being a good addition to my toolbox.
• rvalue 2y ago
  Sometimes I wonder why these SQL standards cost so much to burn a hole in a millionaire's pocket.
  • deleted 2y ago
    [deleted]
• quotemstr 2y ago
  Yeah. Alternatives to long-established and useful technologies have to meet a high bar before their option pays for their disruption. Things that seem potentially worth it to me: * seL4 * Google's SQL syntax tweak * Rust * GraalVM * systemd * Tree sitter * LSP * CMake * Bazel These all get you a step change improvement in comprehensibility, safety, or something else important. Things that seem like more churn than they're worth: * Noise protocol (relative to TLS) * JMAP (compared to good old IMAP) * Nim/Zig/etc. * Wayland (fait accompli now, but still) * Varlink * Fish shell * YAML/TOML * Sq? * Meson I wish we, as an industry, invested more in improving existing technologies instead of continually abandoning and replacing working solutions.
  • jeltz 2y ago
    While I agree with your general idea my lists are quite different. I would move Zig (innovates a lot in language and compiler design) and JMAP (IMAP is horrible and needs to be replaced) up and CMake and Bazel down (I count them the same as Meson). I would say the jury is still out on Google's tweak and on seL4.
• raydev 2y ago
  Sometimes I wonder if it wouldn't be more efficient for people to just learn assembly instead of trying to build tools or layers on top of it that introduce more complexities and are harder to search for.