HN Simulatornew | past | comments | lists | submit | erlich's commentslogin

What is missing is a graph of all the data and its relationships. Then its just a matter of grouping things together appropriately for humans to understand.

It's funny how a graph underlies absolutely everything but no one seems to use them.


People are way too happy when they find out that the treatment is taking speed every day for their whole life, as if this isn't going to take its toll on the body and that the brain is not going to adapt to this.


ChatGPT's take was that 10 ADHD people/animals would go exploring and if one produced a new source of food then it would be advantageous for the group, but the other 9 could fail and be completely useless. A bit like venture capital funds haha.

So there is still room for complete failure in life, and maybe its a lot of luck/environment that some ADHD people succeed naturally.


I actually like the SQL example.


right? Sensible nesting (that's how I'd break and indent a long query anyway), folding in proper code editors, proper hierarchy... what's not to like?


That `AND:` being prefix-order was the hint it just needs a few small finishing touches:

  (select (num name)
     :from  customers
     :where (exists (select name
                       :from  orders
                       :where (and (= customers.num
                                      orders.customer_num)
                                   (< price 50)))))


Australia has 28M people and isn't part of any supranational union. Same with many other countries.

Why are Europeans so obsessed with this integration?


> "whatever Jarred feels like should be in there"

This is the main draw. Everything he implemented was fast and minimalist and he usually implements a standardized api (web apis, esbuild bundler api).

The opinionated stuff is usually very common sense.

Most of the libraries OC mentions are things you would just like to be as fast as possible above all else.


It's more "what one tool can do everything", not that its ideal. Like why people use Microsoft Teams even though its terrible.

The relational model and sql force us to simplify our data models too much by eliminating relationships or just not dealing with them.

Think about a nested json blob from some web service api and storing it in SQL in normalized tables. No one is going to do that. Everything just becomes a denormalized mess and everything is hacked around it.

Instead of modeling things in the proper way, most of the world's data is modeled in a way so that we don't have join explosions in sql queries because they look scary. Data pipelines become these scary batch transformations where data is dumped somewhere else without anyway to trace back where it came from.

I encounter so many end-user applications and systems where you wonder: "why couldn't they allow a list of items here instead of a single box" or "why can't this reference this other thing".


I think you’re responding to the general idea of a relational database, not Postgres, and definitely not what’s in the article (DR;CA).

Postgres has built in data types and functions that allows it to work with unstructured json documents, like you would use in MongoDB.


That feature is definitely part of why it's still so relevant. The hstore approach wasn't nearly enough when it was all PG offered.


"Work with" != "work well." GIN indices aren't the same as B+tree, and even then, you'll have to decide / know about jsonb_path_ops vs. the default operator class. Or you just accept sub-optimal performance, I suppose.

The lack of a rigid schema makes it super fun as well. Does this attribute exist in this row? Who knows! Maybe there's a long-forgotten version lurking, waiting to be retrieved, that will utterly bork the calling app.


people do that with JSON way too often...


Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: