knutwannheden

> Compiler would eat them like donuts.

Made me laugh out loud!

I reckon that while my programming has become more productive with LLMs, it has at the same time gotten a bit more frustrating and boring.

I think it is difficult to know in advance when the LLM will do a reasonable or good job and when it won't. But I am slowly learning when and how to use the tools while still enjoying using them.

Changing screen sizes appears to be a very common theme for Apple. That way they can a few years later re-introduce the old screen sizes as the best invention since sliced bread. Very annoying. I would also have liked to see a 24"+ model.

Interesting. I will be curious to see how it stacks up against Jackson Smile, both in terms of features and performance. Since it appears to support both polymorphism and back-references, it looks like it already has some advanced features.

My preference is Altair: https://altair-viz.github.io/

While I think the paraphrased Jurassic Park quote can be very funny at times, I don't really agree with the statement. But I assume you were being sarcastic.

Am I one of the only developers who actually likes the CONNECT BY queries? Often I think they are a very succinct alternative to recursive CTEs.

My personal favorites are Altair (Python/VegaLite) and Observable Plot. The latter just released a new version with GeoJSON support.

I still didn't get it.

Would be interesting to see what GitHub Copilot makes of this.

I would have opted for Shocker ;-)

It lets you specify a list of terms which mustn't be further apart from each other than a given number of tokens.

I don't have experience with PG FTS, but I've used SQLite FTS5 and love it for its ease of use. Also I really like its NEAR() queries. I was a bit surprised that the post doesn't mention this capability and compare it with the other implementations (i.e. is it available and how does it compare performance-wise).

100% agreed. Whenever I see something being promoted as "cheapest" I try to stay clear. Not only because you often get what you pay for, but also for reasons like the one you mention.

Is it possibly because the font should be monospaced and the reader might then mistake the distance before and after the "I" for a space?

There is this page about a free cluster [1]. It appears to be pretty beefy, but it seems like it is for one year only, but IMHO that isn't entirely clear.

[1] https://docs.microsoft.com/en-us/azure/data-explorer/start-f...

I had the same initial reaction regarding the pipe character. But once I started thinking of the query as a pipe (like in the terminal) through which the data flows, where stuff like ORDER BY, SELECT, and GROUP BY are just operators, it started making sense.

Out if necessity I've started working with Microsoft's Kusto Query Language [1] which is used by various services in Azure (e g. their Log Analytics Workspace).

At first I found the language rather akward and was wondering why yet another query language. But the more I used it the more it grew on me. The thing I really like is that unlike the clauses in SQL, the order of operators isn't really fixed and it reads and feels like a pipe command in a Unix shell.

One example where I find this far superior is when doing aggregations. In SQL I would have to modify both the start and the end of the query, which is quite a nuisance.

[1] https://docs.microsoft.com/en-us/azure/data-explorer/kusto/q...)

Very well said! It appears like the other commenters deliberately try to misinterpret you. Consuming less is indeed one of the best things we can do.

Instead of buying new cheap clothes all the time to be trendy we should buy quality clothing and wear it for a long time. Repair it (and other things we buy) or sell it or give it away rather than dispose of.

Here in Europe things are moving in the right direction, but still too slowly, I am afraid.

I thought that quote was from Pablo Picasso.

Since "database" and "relational model" is mentioned, I assume the collected data is indeed being written to an RDBMS. Would be interesting to be able to poke around in that with some SQL, even if not available as an official API.

jOOQ is an SQL library, which in addition to an internal SQL DSL for Java also includes other goodies like an SQL parser and since very recently (still under active development) also a schema diff tool (also available as CLI): https://www.jooq.org/diff/.

One thing which sets jOOQ apart from most other tools out there is the fact that it supports many different SQL dialects. Thus the schema diff tool can for instance also parse DDL in one dialect and render the diff in another SQL dialect. For certain applications this could be of interest.

Disclaimer: I am an active committer on the jOOQ project.