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

231–240 of 288 posts

Re: Parse, Don't Validate (2019)

#231

Post by ElevenPhonons »

kortex wrote: post #84

This principle is how pydantic[0] utterly revolutionized my python development experience. I went from constantly having to test functions in repls, writing tons of validation boilerplate, and still getting TypeErrors and NoneTypeErrors and AttributeErrors left and right to like...just writing code. And it working ! Like one time I wrote a few hundred lines of python over the course of a day and then just ran it... a…

I've also found Pydantic to be a valuable library to use.

However, it does have a strongly opinionated approach to casting that can sometimes yield non-obvious results. This behavior is documented and I would suggest new potential adopters of the library to explore this casting/coerce feature in the context of your product/app requirements.

For the most part, it's not an huge issue, but I've run into a few surprising cases. For example, sys.maxint, 0, '-7', 'inf', float('-inf') are all valid datetime formats.

- https://pydantic-docs.helpmanual.io/usage/models/#data-conve... - https://gist.github.com/mpkocher/30569c53dc3552bc5ad73e09b48...

Re: Parse, Don't Validate (2019)

#232

Post by globular-toast »

exdsq wrote: post #188
cortesoft wrote: post #130

Earlier quoted context omitted.

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?

You don't. But you only need to test it once (manually), then commit it.

You write automated tests so that you can keep running the tests later such that the behaviour is maintained through refactor and non-breaking changes.

Re: Parse, Don't Validate (2019)

#233

Post by LAC-Tech »

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's pretty clear at this point you don't understand what dynamic dispatch means.

Terms in computing are so overloaded that these days I try[0] and never correct anyone on how they use a term. Instead I ask them to define it, and debate off of that definition.

So instead of downvoting this guy for using different terminology - we can ask him what he means and just have a discussion.

[0] alright I don't always succeed but it's an ideal to strive for

Re: Parse, Don't Validate (2019)

#234

Post by ukj »

LAC-Tech wrote: post #233
BoiledCabbage wrote: post #182

Earlier quoted context omitted.

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's pretty clear at this point you don't understand what dynamic dispatch means. Terms in computing are so overloaded that these days I try[0] and never correct anyone on how they use a term. Instead I ask them to define it, and debate off of that definition. So instead of downvoting this guy for using different terminology - we can ask him what he means and just have a discussion. [0] alright I don't always succe…

This is a commendable approach.

Computation is a general, abstract and incredibly useful idea disconnected from any particular model of computation (programming language).

Different languages are just different models of computation and have different (desirable, or undesirable) semantic properties independent from their (trivial) syntactic properties.

It's this sort of angry dogmatism which prevents people from talking about programming language design.

Not for a second do they pause to think their own understanding may be limited.

Re: Parse, Don't Validate (2019)

#235

Post by rowanG077 »

RHSeeger wrote: post #78
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…

Plenty of people know multiple statically typed and dynamic languages, and multiple functional, imperative, and other languages; and use dynamic languages for some things but not other things. The set of people using dynamic languages isn't just "those that haven't had their eyes opened yet to what static languages can do". Different languages and paradigms make different things easier. I do believe that, for long la…

I'm one of those people. But the reasons I use dynamic languages is in spite of them being dynamic. I choose Python because it has insane library support, I don't like Python as a language though. I would instantly choose Haskell if it had even half the available libraries. But I can't justify having to write everything myself and take 10x as long.

Re: Parse, Don't Validate (2019)

#236

Post by imoverclocked »

adamlett wrote: post #59

I think making this about the type checker is a bit of a red herring. There is nothing in this – otherwise excellent – advice that can’t be applied to a dynamically typed language like Ruby. It’s the same insight that leads OOP folks to warn against the Primitive Obsession code smell ( http://wiki.c2.com/?PrimitiveObsession ). It’s also the insight that leads to the Hexagonal Architecture ( https://en.wikipedia.org/w…

I agree but I also think it’s on the right path. This seems partially like a “why Haskell” in disguise to me.

I’ve run across DSLs that have three or more layers of parsing and validation. Embedding different languages within each other (eg: JSON snippets within your own DSL) definitely leads to the issues the article talks about.

Also, growing your own parser without understanding standard lexer/parser basics seems far more common than it ought to be. I’m not talking brilliant design, rather the extremely naive one-character-at-a-time-in-a-really-complex-loop variety of design.

The better level of bad is, “I know what lexers/parsers are, now I’ll write something to basically implement a type-checking parser with the lexed+parsed tree as input.”

This article is basically stating, “Why not just get your parser to do it all for you in one swell foop?” When I have refactored code to follow this kind of design, I have never regretted the outcome.

Re: Parse, Don't Validate (2019)

#237

Post by Jtsummers »

ukj wrote: post #234
LAC-Tech wrote: post #233

Earlier quoted context omitted.

> It's pretty clear at this point you don't understand what dynamic dispatch means. Terms in computing are so overloaded that these days I try[0] and never correct anyone on how they use a term. Instead I ask them to define it, and debate off of that definition. So instead of downvoting this guy for using different terminology - we can ask him what he means and just have a discussion. [0] alright I don't always succe…

This is a commendable approach. Computation is a general, abstract and incredibly useful idea disconnected from any particular model of computation (programming language). Different languages are just different models of computation and have different (desirable, or undesirable) semantic properties independent from their (trivial) syntactic properties. It's this sort of angry dogmatism which prevents people from talk…

> It's this sort of angry dogmatism which prevents people from talking about programming language design.

The dogmatism demonstrated today was in your comments, ukj. Your inability to understand that your non-standard use of terms makes it impossible for others to communicate with you in any effective way made this a remarkable farce of a conversation or debate.

Re: Parse, Don't Validate (2019)

#238

Post by ukj »

Jtsummers wrote: post #237
ukj wrote: post #234

Earlier quoted context omitted.

This is a commendable approach. Computation is a general, abstract and incredibly useful idea disconnected from any particular model of computation (programming language). Different languages are just different models of computation and have different (desirable, or undesirable) semantic properties independent from their (trivial) syntactic properties. It's this sort of angry dogmatism which prevents people from talk…

> It's this sort of angry dogmatism which prevents people from talking about programming language design. The dogmatism demonstrated today was in your comments, ukj. Your inability to understand that your non-standard use of terms makes it impossible for others to communicate with you in any effective way made this a remarkable farce of a conversation or debate.

There is no such thing as a "standard" model of computation, and therefore no such thing as "standard definition" or use of computation.

There is only the model you (and your tribe) believe is "standard" implicitly. Do you actually understand that?

I kinda thought navigating the inherent ambiguity of all language (programming or natural) is a fundamental skill for software engineers.

Communication is indeed impossible when you think you possess the "right" meaning of words.

Oh... by the way, somebody capable of understanding/listening has just informed me that what I am actually talking about is closer to multiple dispatch than dynamic dispatch.

Multiple dispatch is, in fact, more dynamic than "dynamic dispatch". Hilarity ensues.

Re: Parse, Don't Validate (2019)

#239

Post by Jtsummers »

LAC-Tech wrote: post #233
BoiledCabbage wrote: post #182

Earlier quoted context omitted.

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's pretty clear at this point you don't understand what dynamic dispatch means. Terms in computing are so overloaded that these days I try[0] and never correct anyone on how they use a term. Instead I ask them to define it, and debate off of that definition. So instead of downvoting this guy for using different terminology - we can ask him what he means and just have a discussion. [0] alright I don't always succe…

Dynamic dispatch is not terribly overloaded. It's dispatching based on run-time information instead of just compile-time information.

The problem in this discussion is that ukj has come to the belief (but communicated it poorly) that dynamic dispatch is somehow incompatible with static typing. And for some reason this also matters.

Static typing does not preclude dynamic dispatch, and despite being pointed to several mainstream languages that have both features, ukj decided to ignore reality or the common understanding of the phrase "dynamic dispatch" and produced this grotesque example of trying to communicate with an individual who is, apparently, just a troll. Feeding the troll, ukj, is probably the dumbest thing I did today, but I'll blame that on the insomnia reducing my ability to detect trolls.

Re: Parse, Don't Validate (2019)

#240

Post by ukj »

Jtsummers wrote: post #239
LAC-Tech wrote: post #233

Earlier quoted context omitted.

> It's pretty clear at this point you don't understand what dynamic dispatch means. Terms in computing are so overloaded that these days I try[0] and never correct anyone on how they use a term. Instead I ask them to define it, and debate off of that definition. So instead of downvoting this guy for using different terminology - we can ask him what he means and just have a discussion. [0] alright I don't always succe…

Dynamic dispatch is not terribly overloaded. It's dispatching based on run-time information instead of just compile-time information. The problem in this discussion is that ukj has come to the belief (but communicated it poorly) that dynamic dispatch is somehow incompatible with static typing. And for some reason this also matters. Static typing does not preclude dynamic dispatch, and despite being pointed to several…

>Dynamic dispatch is not terribly overloaded. It's dispatching based on run-time information instead of just compile-time information.

According to the above definition C++ does not have dynamic dispatch!

The vtable in C++ is generated at compile time and used at runtime. It's immutable at runtime. That means it is NOT dynamic!

https://en.wikipedia.org/wiki/Virtual_method_table#Compariso...

"Virtual method tables also only work if dispatching is constrained to a known set of methods, so they can be placed in a simple array built at compile time."

Like, I don't care how you use words, but you (and everyone) are using "dynamic" to speak about a statically-behaving system!

Post reply on HN