101–110 of 134 posts
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 complexities and are harder to search for.
It is great, I installed it, only thing I'd suggest, probably minor, is to also extract the commands to install from the bash script, and put them in the `Install` section directly, I don't run .sh script, especially if they need privileges, so I went through the bash script to take the commands for debian, they're there, probably could also be outside for other kind of people
I love sq. It's handy for quickly performing simple operations on DBs and outputting that as CSV or JSON. Though my one wish is that the sq query language (SLQ) supported substring matching like SQL's `... LIKE "SOME_STRING%"`. Though you can just invoke SQL manually with `sq sql`
Substring matching is on my short list (also totally open to a PR!).
Though I respect and applaud the effort that went into creating this and successfully releasing it, It has fewer features than duckdb supports at the moment. Duckdb supports both Postgres, Mysql, SQLite and many other extensions. Postgres: https://duckdb.org/docs/extensions/postgres MySQL: https://duckdb.org/docs/extensions/mysql SQLite: https://duckdb.org/docs/extensions/sqlite You can try this yourself. 1. Clone th…
Earlier quoted context omitted.
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 qu…
I like Go a lot and can work with it's error handling paradigm, but I still often wonder if the same semantics could be accomplished with less verbosity in a way that makes the underlying algorithm more clear when reading the code.
Verbosity is in the eye of the beholder; To me, it's the verbosity of error handling that makes the algorithm clear. Of course I recognize with others that opinion probably changes depending on whether the person reading a given bit of code views error handling as part of the algorithm.
Not to be confused with the gpg alternative from sequoia-pgp also called sq : https://sequoia-pgp.org/
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 complexities and are harder to search for.
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 complexities and are harder to search for.
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.
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 complexities and are harder to search for.
Sometimes I wonder why these SQL standards cost so much to burn a hole in a millionaire's pocket.