Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Parse, Don't Validate – In a Language That Doesn't Want You To

cekrem.github.io

Post reply on HN
Print view View original

41–50 of 107 posts

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#41

Post by throwaw12 »

sirwhinesalot wrote: post #35
throwaw12 wrote: post #24

I personally love the idea and concept, but struggle to apply to real projects. Suppose I have a User with some attributes like birthday, email and whether they have been verified. in common codebase, you can see `if (user.verified_at != null)` or something along the lines, in case of parsed code I do feel like I should have types for each of them (or interfaces): - UserWithBirthday - VerifiedUser, UnverifiedUser - U…

The computer-science answer to this problem are called "refinement types", where you can attach arbitrary predicates to a type, e.g. (pseudo-code): fn send_birthday_mail(user: {u: User, u.birthday != null}) Contracts are a similar solution that restricts the predicates to only appearing in function types. The difference between this and an assert is that it gets checked at compile time (it can get quite expensive to…

this looks cool, but you are doing validation when accepting the object, you probably can't do it excessively, for example, if you are dealing with objects with heights, you might have a HumanLikeHeight where height range is between 40cm and 250cm, and you want to send email to that human, would you keep adding these conditions to the predicates?

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#43

Post by bern4444 »

throwaw12 wrote: post #24

I personally love the idea and concept, but struggle to apply to real projects. Suppose I have a User with some attributes like birthday, email and whether they have been verified. in common codebase, you can see `if (user.verified_at != null)` or something along the lines, in case of parsed code I do feel like I should have types for each of them (or interfaces): - UserWithBirthday - VerifiedUser, UnverifiedUser - U…

It's pretty trivial to create derived and augmented types with Pick, Omit, Required, Partial. Combined with a few parsing functions that return an object typed to whatever specification you need and you are set IE:

    type User = { name: string; verified: boolean; email?: string; lastName: string; birthday?: string | { year: string; month: string; date: string; }}

    type Birthday = Required>;
    type UserWithBirthday = User & { birthday: Birthday } 
    type VerifiedUser = User & { verified: true; email: string; }
    type VerifiedUserWithBirthday = User & UserWithBirthday & VerifiedUser;


    const userHasBDayAndEmail = (user: User): user is VerifiedUserWithBirthday => {
        if (user.email === undefined || user.birthday === undefined) {
            return false
        }

        return true
    }
Any caller of userHasBDayAndEmail knows for the rest of its nested call stack if the provided user is a User object or a VerifiedUserWithBirthday.

The types are cheap to write (they're all derived) and have no runtime impact (types are erased at build/compile time) and these parsing functions are quite small to write

https://www.typescriptlang.org/play/?#code/FAFwngDgpgBAqgZyg...

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#44

Post by ben-schaaf »

lijok wrote: post #21
Bjartr wrote: post #19

Earlier quoted context omitted.

If nothing else, it should be done as a courtesy to those who would like to avoid such content. If the result is better for having used AI, why wouldn't an author want to disclose it?

Should they disclose the use of a spellchecker? A translation app? Gramarly? A writing tutor?

I find it's incredibly helpful to know when someone's using an automated translator, as they usually get details wrong while still reading like a native speaker. Not using a translator at all, or disclosing that one was used means I can make a better educated guess as to what they mean. It also changes how I reply.

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#45

Post by jerf »

Altern4tiveAcc wrote: post #17

Zod is by far the most ergonomic way to express those ideas in TypeScript these days. I miss it when writing code in other languages. The friction with the rest of the ecosystem is real, though. Most code out there expects you to handle errors with exceptions. I get the impression that polymorphic return types could get in the way of JSC/V8/SpiderMonkey's JIT, but I haven't measured it and I'm not sure of the actual…

I haven't done a lot of Typescript, but I've done at least a couple of month's worth now, and every time I have to type "as" my inner Haskell programmer screams.

If I could add one feature to Typescript it would be something like "as" that actually validates the result against the type system and can fail. Unfortunately, that's way, way easier said than done. It's the bad type of keyword that has unbounded runtime cost because it would have to be a runtime comparison, and there are a lot of design questions about how to write it. However, I still petulantly want it even though I can hardly define it. "zod" is pretty good but you can see how trying to add that as a "keyword" is nightmare fuel for a language-level change.

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#46

Post by lumpysnake »

NeutralCrane wrote: post #39
Bjartr wrote: post #19

Earlier quoted context omitted.

If nothing else, it should be done as a courtesy to those who would like to avoid such content. If the result is better for having used AI, why wouldn't an author want to disclose it?

I think the need to jump through hoops to disclose anything and anything that might offend someone’s particular sensibilities is a losing battle. What if I want a disclosure on if the content is being hosted via AWS vs some non-magacorp that agrees with my sensibilities more? Or that the power being used by the data center is renewable? Or a disclosure for the author’s every political position so I know if I agree wi…

> if the content is being hosted via AWS vs some non-magacorp

> power being used by the data center is renewable

That doesn't change anything about the content itself. AI writing is a disservice to the reader. Why should I even care to read an article you didn't even care about writing yourself? At this point a 300-character tweet would've achieved the same effect.

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#47

Post by robrenaud »

exceptione wrote: post #23

It is nice the author mentioned F#, because if you want to target the browser (or any JavaScript runtime), you can do from F# directly from fable ( https://fable.io ). This allows you to program by default in a type safe manner without having to play tricks to circumvent the limits of structural typing.

I suspect idiomatic TypeScript or idiomatic F# are both way better solutions in the real world than abstruse Typescript emulating idiomatic F#.

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#48

Post by programmarchy »

epolanski wrote: post #36
ramon156 wrote: post #30

The author found out about the square holes in round peg situation with TS. Functions can implicitly error, and there's no annotation that's enforced to tell you that it might error. FP solves this with Result/Option, but this doesn't fit in TS. Effect is there to find a solution but will fail. Zod is the acceptable middleground in my opinion. Zod will allow you to throw a schema against an object and it'll tell you…

> Effect is there to find a solution but will fail. What do you mean? I'm into Effect from long time and it really scales well the more complex your applications. Schema is way more advanced than Zod by the way, both at type level and functionality it has a proper decoder/encoder architecture. You can encode "this isn't just a string -> non-empty-string -> valid email pattern" but a confirmed email the user has click…

I haven’t used Effect but the problem I see with using it is that it seems to want to completely swallow the whole app architecture. At that point, why not just use a functional language?

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#49

Post by throwaw12 »

bern4444 wrote: post #43
throwaw12 wrote: post #24

I personally love the idea and concept, but struggle to apply to real projects. Suppose I have a User with some attributes like birthday, email and whether they have been verified. in common codebase, you can see `if (user.verified_at != null)` or something along the lines, in case of parsed code I do feel like I should have types for each of them (or interfaces): - UserWithBirthday - VerifiedUser, UnverifiedUser - U…

It's pretty trivial to create derived and augmented types with Pick, Omit, Required, Partial. Combined with a few parsing functions that return an object typed to whatever specification you need and you are set IE: type User = { name: string; verified: boolean; email?: string; lastName: string; birthday?: string | { year: string; month: string; date: string; }} type Birthday = Required >; type UserWithBirthday = User…

creation is not a problem, maintenance is.

Suppose you want to add one more property to VerifiedUserWithBirthday and UnverifiedUserWithBirthday, you might get 2 more new types, and somewhere at the higher layer call chains you need to know which enclosing type you should pass so that some method in the bottom chain will accept it.

I am sure there are more elegant ways, but I am struggling to generalize it to most enterprise SaaS CRUD apps, where you have one object with bunch of properties and can conditionally traverse the code logic

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#50

Post by twoodfin »

lumpysnake wrote: post #31
lijok wrote: post #15

Earlier quoted context omitted.

Why should they disclose how much AI was used to write an article?

Because I would've completely avoided the article if I knew that I would be served slop. I was interested in the content, but I was immediately thrown off by the writing style, which closely resembles what I've been getting from Opus 4.8 lately in my dev work. Filler language and useless metaphors everywhere. > Booleans look tidy until somebody adds a third case and exhaustiveness silently doesn’t kick in. Strings na…

I just flag like I would terrible writing by a human and move on.

It’s frankly depressing when (2018) oldies-but-goodies get reposted here for the Nth time. The clarity of thought and obvious effort that went into communicating that thought was expected for top-voted posts at the time. Now those posts appear exceptional in this era’s standard of “the LLM just cleaned up my notes” slop.

Post reply on HN