Most active commenters
  • ukj(10)
  • justinpombrio(4)

←back to thread

Parse, Don't Validate (2019)

(lexi-lambda.github.io)
389 points melse | 16 comments | | HN request time: 0.001s | source | bottom
Show context
seanwilson ◴[] No.27640953[source]
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 type checking, flakey dynamic code that relies on runtime checks and just being careful to avoid runtime errors makes your skin crawl, and you'll intuitively gravitate towards designs that takes advantage of strong static type checks.

When all you know is dynamic languages, the design guidance you get from strong static type checking is lost so there's more bad design paths you can go down. Patching up flakey code with ad-hoc runtime checks and debugging runtime errors becomes the norm because you just don't know any better and the type system isn't going to teach you.

More general advice would be "prefer strong static type checking over runtime checks" as it makes a lot of design and robustness problems go away.

Even if you can't use e.g. Haskell or OCaml in your daily work, a few weeks or just of few days of trying to learn them will open your eyes and make you a better coder elsewhere. Map/filter/reduce, immutable data structures, non-nullable types etc. have been in other languages for over 30 years before these ideas became more mainstream best practices for example (I'm still waiting for pattern matching + algebraic data types).

It's weird how long it's taking for people to rediscover why strong static types were a good idea.

replies(10): >>27641187 #>>27641516 #>>27641651 #>>27641837 #>>27641858 #>>27641960 #>>27642032 #>>27643060 #>>27644651 #>>27657615 #
ukj ◴[] No.27641651[source]
Every programming paradigm is a good idea if the respective trade-offs are acceptable to you.

For example, one good reason why strong static types are a bad idea... they prevent you from implementing dynamic dispatch.

Routers. You can't have routers.

replies(3): >>27641741 #>>27642043 #>>27642764 #
justinpombrio ◴[] No.27642764[source]
Are you sure you know what dynamic dispatch is? Java has dynamic dispatch, and it is a statically typed language. In Java, it's often called "runtime polymorphism".

https://www.geeksforgeeks.org/dynamic-method-dispatch-runtim...

And using it doesn't give up any of Java's type safety guarantees. The arguments and return type of the method you call (which will be invoked with dynamic dispatch) are type checked.

replies(2): >>27643722 #>>27650975 #
ukj ◴[] No.27643722[source]
Are you sure you know when type-checking and when dynamic dispatching happens?

Compile time is not runtime.

The Java compiler is not the JVM.

The compiler does type checking. The JVM does the dynamic dispatching.

Neither does both.

replies(1): >>27643937 #
1. justinpombrio ◴[] No.27643937[source]
All those statements are correct. The people downvoting you know that too. I don't think anyone has figured out what point you're trying to make, though. Could you spell it out in more detail?

Consider addition. The compiler does type checking, and the JVM actually adds the numbers. Nonetheless, the addition is type checked, and does not represent a weakness of static type checking. How is dynamic dispatch different than this?

replies(1): >>27644085 #
2. ukj ◴[] No.27644085[source]
The point is trivial.

You can’t have both static type safety AND dynamic dispatch at the same time and in the same context about the same data.

Choose one. Give up the other. Make a conscious trade off.

The language that you are using is making such trade offs for you - they are implicit in the language design. Best you know what they are because they are meaningful in principle and in practice.

replies(1): >>27644214 #
3. justinpombrio ◴[] No.27644214[source]
Java has both static type safety AND dynamic dispatch at the same time and in the same context about the same data.
replies(1): >>27644270 #
4. ukj ◴[] No.27644270{3}[source]
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”?

replies(2): >>27644442 #>>27644498 #
5. justinpombrio ◴[] No.27644442{4}[source]
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 about the type checker. It relates type checking to run time (and thus to compilation too). That is, if you muck with Java's runtime or compiler, you can break type soundness, even if you don't change its type system in the slightest.
replies(1): >>27644614 #
6. BoiledCabbage ◴[] No.27644498{4}[source]
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

replies(3): >>27644551 #>>27645529 #>>27646404 #
7. ukj ◴[] No.27644614{5}[source]
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.

8. ukj ◴[] No.27645529{5}[source]
>If you're going to reply, please explain why an organization that Bjarne Stroustrup is a director of believes that C++ supports dynamic dispatch.

Because the meaning of "dynamic" is ambigous!

Since you are pointing me to wikipedia I'll point you right back...

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."

If the vtable is generated at compile and is constrained to a known set of methods then that array is immutable! Calling that "dynamic" is an obvious misnomer!

You are neither charitable nor patient. You are committing the bandwagon fallacy as we speak. You and the other 120 (and counting) angry downvoters ;)

I am using the word "dynamic" to actually mean dynamic! I am not going to define it. Use your judgment. Dynamic is NOT static. I am not asking you to "educate me", or to tell me I am right; or wrong. I am asking you to understand the sort of programming language design I have in mind!

Either you understand; or you don't.

9. LAC-Tech ◴[] No.27646404{5}[source]
> 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

replies(2): >>27646463 #>>27646699 #
10. ukj ◴[] No.27646463{6}[source]
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.

replies(1): >>27646601 #
11. Jtsummers ◴[] No.27646601{7}[source]
> 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.

replies(3): >>27646642 #>>27647693 #>>27647802 #
12. ukj ◴[] No.27646642{8}[source]
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.

13. Jtsummers ◴[] No.27646699{6}[source]
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.

replies(2): >>27646746 #>>27648312 #
14. ukj ◴[] No.27646746{7}[source]
>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!

15. ◴[] No.27647693{8}[source]
16. ukj ◴[] No.27647802{8}[source]
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/