You don't have to use TypeScript if you don't want to: you can compile Haskell, Ocaml, Rust, F#, ... to javascript. This is quite efficient, especially if your backend is already in one of those languages. It saves you from creating the same abstraction twice in different languages.
Parse, Don't Validate – In a Language That Doesn't Want You To
71–80 of 107 posts
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#72default: { const _exhaustive: never = result; return _exhaustive; } ...is not how people should implement an exhaustiveness check ever! An exhaustiveness check exhausts your knowledge about the world, it should throw an exception at runtime. Just return ing the non-matched case is a recipe for disaster. Do this instead: default: ((value: never) => { throw new Error(`Missing case for value: ${value}`); })(result);
The original author is correct. Their implementation of an exhaustive check will give you a compiler error if you miss a variant in your switch statement. I much prefer a compiler error over a run time error.
It's even recommended in the official typescript docs - https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#73You don't have to use TypeScript if you don't want to: you can compile Haskell, Ocaml, Rust, F#, ... to javascript. This is quite efficient, especially if your backend is already in one of those languages. It saves you from creating the same abstraction twice in different languages.
How does that work with JS frameworks like React, since most development takes place with them?
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#74Earlier 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…
> Strings narrow honestly.
This is a great example of the latest "LLM tell" I'm seeing in prose.
It's so terse with its "power-verb" that I have to read it multiple times. It's a clever compaction of English, not something I want to read outside of a headline or motto.
Here's another example from a Claude convo I had open: "Alerts flag mirrors". It's agreeing with my proposal that the alert system should be expanded to consider duplicates, and it came up with a cutesy phrase for it that ends up reading like three unrelated words.
Makes me appreciate how helper words help make the structure of a sentence more obvious.
More examples: "Errors surface drift", "Tests anchor scope", "Guards screen input". That's probably what it is: when the verb is also the form of a noun (flag, surface) or adjective (narrow).
Slogans mask meaning.
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#75Earlier quoted context omitted.
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.
That’s my point. The AI writing either affects the content or it doesn’t. If you require a disclaimer to tell the difference, then it isn’t affecting the content.
Requiring a disclaimer is essentially admitting the content isn’t meaningfully different than human generated content. At that point, who cares? Just engage with the premise on its own merits, rather than on how it was written.
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#76Earlier quoted context omitted.
> 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.
That’s my point. The AI writing either affects the content or it doesn’t. If you require a disclaimer to tell the difference, then it isn’t affecting the content. Requiring a disclaimer is essentially admitting the content isn’t meaningfully different than human generated content. At that point, who cares? Just engage with the premise on its own merits, rather than on how it was written.
Then you're totally right. In this case, it's a poor usage of AI because we are able to tell it's slop.
Odds are very high at this point that I've come across a piece of content I enjoyed that was at least partly written by an LLM without having detected it.
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#77We should make authors disclose how much AI was used to write an article. This reeks of Opus 4.8.
Why should they disclose how much AI was used to write an article?
If the author hasn't bothered to spend time writing the article, why should I spend my time reading it?
Let agents do it for me!
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#78I don't like zod. I want to define my types, not write schemas. And I don't like that then I have to use the types derived from those schemas rather than types I've defined myself directly. So I just define my types and then use typescript-json-schema or similar to build a JSON Schema at build time (i.e. from an npm script) which then I use to validate input using ajv. The only thing I do on top of that is to use ann…
What you're doing is essentially what Zod is designed to avoid. If you tolerate needing a separate build step more than having to define types with Zod's syntax, then it makes sense not to use Zod since it's not made for you.
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#79I don't like zod. I want to define my types, not write schemas. And I don't like that then I have to use the types derived from those schemas rather than types I've defined myself directly. So I just define my types and then use typescript-json-schema or similar to build a JSON Schema at build time (i.e. from an npm script) which then I use to validate input using ajv. The only thing I do on top of that is to use ann…
For all its faults, this is one of the things the Python typing system gets right. It's dynamically introspectable at runtime, so you can define type, parsing and validation in one go with stuff like pydantic.
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#80Earlier quoted context omitted.
> 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?
I can’t think of a single functional language that offers what effect gives you, though. A fully typed and declarative error channel, managed dependency layer with compile time safety, excellent resource management, the best parsing/validating/serializing library I’ve used in TypeScript, concurrency, streams, cache, otel primitives baked in…
In all fairness it does require buy-in and gradual adoption isn’t perfectly seamless or frictionless, but I think it’s worth it. They’ve done an outstanding job with it.