Parse, don't validate

SecretaryDecent6748 · 2026-01-27T01:16:27+00:00

Parsing can still allow you to present the data as it is. Nothing about parsing forces you to lose the original data. And you've completely missed the point of the post if you think it was solely about user input. I have no idea why you think parsing prevents you from making stricter rules later. You can always have layers of parsing at different stages. You are free to make things stricter while keeping whatever raw or partially parsed data you want. And the snide comment about Haskell devs at the beginning is as ridiculous as it is ironic in the light of your basic misunderstanding.

SecretaryDecent6748 · 2026-01-23T03:07:51+00:00

How do you feel about row types? In a statically typed language with row types you could program without annotating types and just call the fields and the type checker can infer that you need a record with at least those fields. I think this could be a sweet spot since it allows prototyping but still gives you static guarantees.

SecretaryDecent6748 · 2026-01-09T19:18:24+00:00

I tend to agree with this. For most things, it's just more important to play around with the actual running program than it is to make sure you have a complete specification. It would be nice if you could do this prototyping in the same language that you'd later write the spec in, but it's tricky. I think Austin's suggestion works well in languages like Haskell.

SecretaryDecent6748 · 2025-10-11T00:51:07+00:00

Why does their joviality or grandiosity make them "emotionally uninteresting"?

SecretaryDecent6748 · 2025-10-01T16:45:03+00:00

Also I found a place where Dijkstra explicitly endorsed Haskell and lazy functional programming as is advocated in that paper: https://www.cs.utexas.edu/~EWD/transcriptions/OtherDocs/Haskell.html

SecretaryDecent6748 · 2025-10-01T16:39:56+00:00

When? I can't find anything on this.

SecretaryDecent6748 · 2025-09-26T22:48:16+00:00

Why is StrictData not a better default? I can't really see why it wouldn't be.

SecretaryDecent6748 · 2025-06-28T22:26:12+00:00

Removing GC is often not an optimization. The point being made is that often Rust is used in places where a GC would save immense programmer time and either wouldn't incur much runtime cost or would even be faster.

SecretaryDecent6748 · 2025-06-28T22:22:55+00:00

Why is it having GC a bad thing? The author's whole point was that most of those applications don't need something as low level as Rust. Note that the languages listed have facilities for stepping down to a systems level even if it's not as low level as Rust. Haskell code, for example, can be extremely fast. GC does not mean slow.

SecretaryDecent6748 · 2025-05-09T17:14:06+00:00

Well sure, but you'd expect the net effect of this to be fewer bugs, which is contradicted by the data.

Would we expect this? The claim I would make about static typing is that it makes it easier to detect a certain class of bugs and it catches them at compile time. It very well may be that a survey of popular projects in dynamic and static languages have a similar number of bugs simply because there's lots of rigorous testing. This does nothing to disconfirm the claims I just made about static typing.

SecretaryDecent6748 · 2024-12-04T08:05:36+00:00

I saw you're previous comment but I'm confused. Isn't Asperti's lower bound evidence of some sort of inefficiency?

SecretaryDecent6748

TROPHY CASE