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

Parse, Don't Validate (2019)

lexi-lambda.github.io

Post reply on HN
Print view View original

181–190 of 288 posts

Re: Parse, Don't Validate (2019)

#181

Post by lukashrb »

tikhonj wrote: post #142
lukashrb wrote: post #135

Earlier quoted context omitted.

For what its worth: People don't use dynamic language because they don't know better or never used a static language. To better understand what dynamic languages bring to the table, here are some disadvantages of static types to consider: Static types are awesome for local reasoning, but they are not that helpful in the context of the larger system (this already starts at the database, see idempotency mismatch). Code…

The example with pattern matching doesn't have anything to do with static types. You'll have exactly the same problem if you pattern match against positional arguments in Python: match event.get(): case Click((x, y)): handle_click_at(x, y) (Example from PEP 636[1].) In both Python and statically typed languages you can avoid this by matching against field names rather than positions, or using some other interface to…

You're absolutely right. I guess I mentioned pattern matching in particular because of the cited sentence from OP "I'm still waiting for pattern matching + algebraic data types".

> The same is true for the rest of the things you've mentioned: none are specific to static typing!

Sure, I could be wrong here. I frequently am. But could you point out why do you think that?

Re: Parse, Don't Validate (2019)

#182

Post by BoiledCabbage »

ukj wrote: post #174
justinpombrio wrote: post #173

Earlier quoted context omitted.

Java has both static type safety AND dynamic dispatch at the same time and in the same context about the same data.

No, it doesn’t. The input-data to the compiler can’t be handled by the JVM and vice versa. The JVM handles byte code as input. The compiler handles source code as input. That is two different functions with two different data domains. They literally have different types! Which one of the two functions is the thing you call “Java”?

It's pretty clear at this point you don't understand what dynamic dispatch means.

I don't think it's worthwhile for anyone else to argue with you further. C++ and Java both support dynamic dispatch although you deny it.

You've taken up almost a full page of HN arguing with everyone trying to explain it to you. People have pointed you to wikipedia showing you that you're wrong. [1]

ISOCPP of which Bjarne is a director [2] says that C++ supports dynamic dispatch. [3]

And you continue to attempt to argue that everyone on HN, Wikipedia and the creator of the C++ language are all wrong and don't know what dynamic dispatch is.

Your continued insistence is both wrong and a negative impact at this point on hn. Please stop arguing something that numerous people have taken lots of patience and charity in trying every way possible to explain to you and what is clearly factually wrong.

If you're going to reply, please explain why an organization that Bjarne Stroustrup is a director of believes that C++ supports dynamic dispatch.

1. https://en.wikipedia.org/wiki/Dynamic_dispatch#C++_implement...

2 https://isocpp.org/about

3. https://isocpp.org/wiki/faq/big-picture#why-use-oo

Re: Parse, Don't Validate (2019)

#183

Post by ukj »

BoiledCabbage wrote: post #182
ukj wrote: post #174

Earlier quoted context omitted.

No, it doesn’t. The input-data to the compiler can’t be handled by the JVM and vice versa. The JVM handles byte code as input. The compiler handles source code as input. That is two different functions with two different data domains. They literally have different types! Which one of the two functions is the thing you call “Java”?

It's pretty clear at this point you don't understand what dynamic dispatch means. I don't think it's worthwhile for anyone else to argue with you further. C++ and Java both support dynamic dispatch although you deny it. You've taken up almost a full page of HN arguing with everyone trying to explain it to you. People have pointed you to wikipedia showing you that you're wrong. [1] ISOCPP of which Bjarne is a director…

It is pretty clear at this point that you don’t know what “meaning” is when it relates to the semantics of formal languages.

For starters you don’t even understand Rice’s theorem.

Sadly this isn’t on Wikipedia. You actually have to dive deep on the Topological, Categorical and Logical view of computation.

Re: Parse, Don't Validate (2019)

#184

Post by Scarbutt »

kortex wrote: post #171
jimmaswell wrote: post #119

Earlier quoted context omitted.

I've found this to be simply a matter of experience, not tooling. As the years go by I find the majority of my code just working right - never touched anything like pydantic or validation boilerplate for my own code, besides having to write unit tests as an afterthought at work to keep the coverage metric up.

No this was like over a week, and 100% due to the tooling. Pydantic, pycharm, black, mypy, and flake8. Pretty much went from "type hints here and there" to "what happens if I try writing python as if it were (95%) statically typed." I'd been testing well before this point but it's not the same as writing test. The development process is totally different when you write structured types first and then write your logic…

The development process is totally different when you write structured types first and then write your logic. 10/10 would recommend.

Unless you were writing very small throwaway scripts, in what world where you writing your logic first and thinking about your data structures later?

Re: Parse, Don't Validate (2019)

#185

Post by ukj »

justinpombrio wrote: post #180
ukj wrote: post #174

Earlier quoted context omitted.

No, it doesn’t. The input-data to the compiler can’t be handled by the JVM and vice versa. The JVM handles byte code as input. The compiler handles source code as input. That is two different functions with two different data domains. They literally have different types! Which one of the two functions is the thing you call “Java”?

A type system is sound when: for all expressions e: if e type checks with type t, then one of the following holds: - e evaluates to a value v of type t; or - e does not halt; or - e hits an "unavoidable error" like division by 0 or null deref (what counts as "unavoidable" varies from lang to lang) Notice anything interesting about this definition? It uses the word "evaluate"! Type soundness is not just a statement ab…

Yes this is precisely what I am talking about.

Different implementations of eval() a.k.a different programming languages have different semantics.

Which implicit eval() implementation does the above hold?

What type system do you have in mind such that the above holds for ALL expressions. Type-checking itself is not always decidable.

Re: Parse, Don't Validate (2019)

#186

Post by yashap »

seanwilson wrote: post #48

From the Twitter link: > IME, people in dynamic languages almost never program this way, though—they prefer to use validation and some form of shotgun parsing. My guess as to why? Writing that kind of code in dynamically-typed languages is often a lot more boilerplate than it is in statically-typed ones! I feel that once you've got experience working in (usually functional) programming languages with strong static ty…

This matches my personal experience, for sure. I started out writing Python (pre-type-annotations) and JS, with lots of “raw” dicts/objects. For the past ~7 years though, I’ve written mostly Scala, but also a decent amount of TypeScript, Go and Java, and it’s completely transformed how I code, dramatically for the better.

Now, even in the rare case where I write some Python, JS or PHP, I write it in a very statically typed style, immediately parsing input into well-thought-out domain classes. And for backend services, I almost always go with 3 layers of models:

1) Data Transfer Objects. Map directly to the wire format, e.g. JSON or Protobuf. Generally auto-generated from API specs, e.g. using Open API Generator or protoc. A good API spec + code gen handles most input validation well

2) Domain Objects. Hand written, purely internal to the backend service, faithfully represent the domain. The domain layer of my code works exclusively with these. Sometimes there’s a little more validation when transforming a DTO into a domain model

3) Data Access Objects. Basically a representation of DB tables. Generally auto-generated from DB schemas, e.g. using libs like Prisma for TS or SQLBoiler for Go

Can’t imagine going back to the “everything is a dictionary” style for any decent sized project, it becomes such a mess so quickly. This style is a little more work up front, when you first write the code, but WAYYYYYY easier to maintain over time, fewer bugs and easier to modify quickly and confidently, with no nasty coupling of your domain models to either DB or wire format concerns. And code gen for the DTO and DAO layers makes it barely more up-front work.

Re: Parse, Don't Validate (2019)

#187

Post by ukj »

justinpombrio wrote: post #176
ukj wrote: post #154

Earlier quoted context omitted.

Deciding which implementation of a function handles any given piece of data at runtime. Trivially, because you don’t have this knowledge (and therefore you can’t encode it into your type system) at compile time.

Aha! I think I have debugged your thinking. Wow you made that hard by arguing so much. Apparently you do know what dynamic dispatch is, you're just wrong that it can't be type checked. In Java, say you have an interface called `Foo` with a method `String foo()`, and two classes A and B that implement that method. Then you can write this code (apologies if the syntax isn't quite right, it's been a while since I've wri…

So, there is nothing dynamic about that dispatch.

Because the implementation details of Foo are actually know at compile time. Which is why you are able to type-check it.

You have literally declared all allowed (but not all possible) implementations of Foo.

What happens when Foo() is a remote/network call?

Re: Parse, Don't Validate (2019)

#188

Post by exdsq »

cortesoft wrote: post #130
jimmaswell wrote: post #119

Earlier quoted context omitted.

I've found this to be simply a matter of experience, not tooling. As the years go by I find the majority of my code just working right - never touched anything like pydantic or validation boilerplate for my own code, besides having to write unit tests as an afterthought at work to keep the coverage metric up.

Tests aren't to make sure your code works when you write it, it is to make sure it doesn't break when you make changes down the line.

How do you know your code works when you write it if you don't test it?

Re: Parse, Don't Validate (2019)

#189

Post by detaro »

ukj wrote: post #187
justinpombrio wrote: post #176

Earlier quoted context omitted.

Aha! I think I have debugged your thinking. Wow you made that hard by arguing so much. Apparently you do know what dynamic dispatch is, you're just wrong that it can't be type checked. In Java, say you have an interface called `Foo` with a method `String foo()`, and two classes A and B that implement that method. Then you can write this code (apologies if the syntax isn't quite right, it's been a while since I've wri…

So, there is nothing dynamic about that dispatch. Because the implementation details of Foo are actually know at compile time. Which is why you are able to type-check it. You have literally declared all allowed (but not all possible) implementations of Foo. What happens when Foo() is a remote/network call?

so you are using a different definition of dynamic dispatch than the rest of the software industry.

Re: Parse, Don't Validate (2019)

#190

Post by exdsq »

globular-toast wrote: post #158
jimmaswell wrote: post #119

Earlier quoted context omitted.

I've found this to be simply a matter of experience, not tooling. As the years go by I find the majority of my code just working right - never touched anything like pydantic or validation boilerplate for my own code, besides having to write unit tests as an afterthought at work to keep the coverage metric up.

I agree. I'm often baffled by some developers who seem to think dynamic typing is a minefield that inevitably goes wrong all the time. I note these are almost always Javascript programmers, though. In practice, experience developers in dynamic languages like Python, Lisp etc. rarely make such errors. The number of bugs we deal with that would have been caught early by static typing are vanishingly small. The best arg…

It's okay if you're working on a blog site, less so if you're working on an air-planes autopilot.
Post reply on HN