exevp

The majority of humans is not delusional all the time. But every human is delusional some times. Same as the majority of LLMs hallucinating some times but not all the time.

So if the bar for proper reasoning is never ever being delusional then humans and LLMs sit in the same bucket.

Psssst, if you put it this way it won't attract VC $$$

So cloning yourself is the actual idea you should pursue? ;)

This space is getting so much interest that OpenAI will not be the only one providing LLM as a service forever.

This is probably a good opportunity to have a heated discussion over parseInt() vs Number() since parseInt('Infinity') yields NaN. I know people prefer Number() for reasons but in this case it reveals the weakness of using basically a typecast with implicit language semantics for interpreting string inputs.

Also the example of bypassing this is rather contrived:

1) bypassing some timer in an API service requires the API to accept the string „Infinity“ and convert it to the JavaScript value Infinity - which is highly unlikely. Instead, the value would just fail the numeric validation.

2) bypassing some timer in client-side code by injecting Infinity seems overly complex - if you alter client-side code you might aswell just remove the validation instead of abusing edge cases of the language runtime.

> I am not sure about what do you mean here?

Given i have defined the columns of interest in my data objects anyways...

  class User { name = null; email = null; }

... i wouldn't necessarily have to repeat them when writing my SQL:

   sql`SELECT ${Object.getOwnPropertyNames(new User).map(camelCase).join(', ')} FROM users`

Of course using a better helper function.

There's a few repetitive tasks when writing SQL where don't necessarily need a powerful query builder but still end up writing a few handler functions. Shipping some common helpers with the framework might be handy.

I understand where Prisma is coming from with the custom DSL: they want to guarantee type safety and therefore need to know exactly the structure of the types the result set is supposed to be mapped to.

In most other languages you'd shout "reflection" but unfortunately, there is no such thing in TS. Hence the custom DSL so you know, while parsing, what the structure of the type is.

I'm just asking myself: why invent the custom DSL for that? You could just use babel to parse TS types. Sure babel is quite the dependency but in a node environment, that wouldn't be a bigger concern to me then inventing a custom DSL instead.

You could even use TS decorators to add more metadata like sequences and (foreign) keys to the TS types.

> In my experience this is just a very, very small percent of the cases. Most of the time I find myself doing pretty simple CRUD operations, and the boilerplate for the simple cases goes out of hand quickly, specially when running joins.

That's true, although the most frustrating percent of the cases :)

I think what KISS will eventually need is some simple toolbelt for the basic CRUD queries, e.g. expanding lists of column names, dealing with casing (snake_case to camelCase). So making the stuff you write 90% of the times easy without inventing a custom SQL abstraction.

MyBatis (which i mentioned in another comment) approached this for example with sql snippets one could re-use in queries.

KISS enables the same thing by allowing nesting of tagged sql strings. I guess time will show which additional helpers are needed to make the devs life easy/reduce the boilerplate for the simple queries.

Also one of the bigger reasons why i dislike SQL abstractions: you usually pick your RDBMS for a reason, because of some vendor-specific features, extensions or something. Abstracting SQL away makes end up with the smallest common denominator which defeats the purpose of choosing one specific RDMBS.

So whenever you have reasons to spend some thoughs on the choice of RDBMS, you'll probably not want to abstract SQL away.