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

241–250 of 288 posts

Re: Parse, Don't Validate (2019)

#241

Post by ukj »

justinpombrio wrote: post #203
ukj wrote: post #198

Earlier quoted context omitted.

“Well established” doesn’t mean anything. According to who? Computer scientists talk about “well formed” not “well established”. Those are categorical definitions.

> According to who? Wikipedia, every textbook you can find, the top dozen search results for "dynamic dispatch", me who has a PhD in computer science plus all the other CS PhD people I know, everyone in my office who knows the term (who are industry people, not academia people), every blog post I have ever read that uses the term, and all the other HN commenters except you. I'm really not exaggerating; a lot of CS te…

There is a legitimate confusion indeed and it seems to be on your part!

What I am talking about when I say "dynamic dispatch" is the sort of dispatching done by R, LISP and Julia (and not by C++ or Java). Now, we can bicker about labels and you can insist that it's actually called "multiple dispatch" and not "dynamic dispatch", but you can't bicker about the semantic fact that "multiple dispatch" is actually more dynamic than "dynamic dispatch".

And this semantic point would've been trivial to unpack if you weren't try to win an argument.

Indeed, sorry for engaging the trolls. 20; or 30 of you. Lost count.

Re: Parse, Don't Validate (2019)

#242

Post by nooorofe »

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…

There is one thing concerns me about type annotation. With annotation Python code looks like Java code, but with it I don't have advantages of Java (like speed). Besides I see things like `x: typing.Union[str, typing.Any]` - maybe better no annotation.

Re: Parse, Don't Validate (2019)

#243

Post by touisteur »

DougBTX wrote: post #175
touisteur wrote: post #103

Earlier quoted context omitted.

On the other end I'm endlessly tired of 'too simple' foreach/map iterators. They're OK until you want to do something like different execution on first and/or last element... Give me a way to implement a 'join' pattern over the foreach iterators, or less terse iterators (with 'some' positional information). I think I'm just ranting about the for-of iterator in Ada...

I quite like the “enumerate” pattern. When indexes matter, instead of `for x in v` you would write, `for (i, x) in enumerate(v)`, then the language only needs one type of for loop as both cases use the same enumerator interface.

Yes I was thinking of something like that. Only I wish I could also know whether I is first and/or last without calling into the iterated structure. I know this looks like corner case syntactic sugar but it comes up a lot, e.g. when serializing to JSON. I guess I should write my own iterators but I want them everywhere...

Re: Parse, Don't Validate (2019)

#244

Post by touisteur »

Jtsummers wrote: post #132
touisteur wrote: post #103

Earlier quoted context omitted.

On the other end I'm endlessly tired of 'too simple' foreach/map iterators. They're OK until you want to do something like different execution on first and/or last element... Give me a way to implement a 'join' pattern over the foreach iterators, or less terse iterators (with 'some' positional information). I think I'm just ranting about the for-of iterator in Ada...

Ada provides a kind of iterator called a Cursor which could be used to build up a package of functions similar to the various C++ standard library algorithms. I believe this has actually already been done. Cursor s can also be converted back to positional information if it makes sense (like with a Vector ).

I like the cursor, because it abstracts indexes. Problem is, if I want the element, I still have to go fetch it (calling Element on the Cursor) and then I have to save it in a local variable and then I need to add a declare block for the constant standing for the result of Element and then the thing makes 5 lines instead of two and is not much more readable. Maybe I can just use Element() (especially since AdaCore seems to want to generalize dotted notation) repeatedly and have it inlined, but my past experience says 'expensive'...

And sadly Cursors haven't been generalized to all associative iterable structures in Ada (arrays for example).

Re: Parse, Don't Validate (2019)

#245

Post by specialist »

chriswarbo wrote: post #69
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…

I have the same feeling after spending a few years with Haskell, StandardML, Agda, Idris, Coq, etc. One trick I've found very useful is to realise that Maybe (AKA Option) can be though of as "a list with at most one element". Dynamic languages usually have some notion of list/array, which we can use as if it were a Maybe/Option type; e.g. we can follow a 'parse, don't validate' approach by wrapping a "parsed" result…

Ya, having 'foreach( null )' be a no-op is my #1 language feature request.

Not being a big fan of method chaining, a null saavy foreach would probably eliminate most of my null checks, need for Optional.

Re: Parse, Don't Validate (2019)

#246

Post by ukj »

Jtsummers wrote: post #159
ukj wrote: post #122

Earlier quoted context omitted.

You are wrong about me being wrong. C++ is just a compiler. It outputs a binary for a target platform. The compiler does nothing for you at runtime - certainly not "type safety". Sometimes the 10 people on HN are wrong. This is one of those times.

C++ is not a compiler. C++ is a language with a specification from which people derive compilers and standard libraries and runtimes. C++ the language very much does tell you what to expect at runtime, though perhaps not everything you could ever want. I mean, it's not Haskell or Idris with their much richer type systems.

Hah! No wonder you don't grok my perspective.

If you derive a C++ compiler that accepts file A as valid C++. And I derive a C++ compiler that rejects file A as valid C++, then from the lens of type theory the two compilers have different type-signatures!

They are not the same formal language. One, or both compilers implement a language that is not C++.

Re: Parse, Don't Validate (2019)

#247

Post by [deleted] »

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.

[deleted]

Re: Parse, Don't Validate (2019)

#248

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's also no such thing as "standard use" of terms. Your dogma has a name. Linguistic prescriptivism ( https://en.wikipedia.org/wiki/Linguistic_prescription )

If there was a "standard use" languages wouldn't evolve and we wouldn't have so many of them. 8 billion people on Earth would be speaking The Standard Language!

Perhaps the thing you don't understand (over and above how to communicate) is this comic?

https://xkcd.com/927/

Re: Parse, Don't Validate (2019)

#249

Post by AlphaSite »

JPKab wrote: post #155
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…

Curious, but how does pydantic compare to marshmallow? I'm currently using marshmallow in a project, specifically using the functionality that builds parsers from dataclasses. I was curious what the differences were.

Marshmallow feels like a more flexible project, but it needs more work for a similar effect IMO.

My cons are: - Uses some dsl to define types - Doesn’t marshal to model objects by default, but from DICT to DICT

My pro is: - much more configurable and powerful

Re: Parse, Don't Validate (2019)

#250

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…

You've muddled your own thinking with the weasel word "incompatible".

Living is not incompatible with dying if you do each at different times and you are doing type-checking and dynamic dispatch at different times.

The "common understanding" doesn't even differentiate between the types of dynamic dispatch. My perspective is higher-fidelity than yours, yet you are trying to "correct my understanding". It's not troll-feeding - it's hubris.

Post reply on HN