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

211–220 of 288 posts

Re: Parse, Don't Validate (2019)

#211

Post by ukj »

Jtsummers wrote: post #138
ukj wrote: post #115

Earlier quoted context omitted.

>I do dynamic dispatch all the time in strongly typed languages. I believe semantics is getting in our way of communicating. You don't do dynamic dispatch ___ALL___ the time. You only do it at runtime. And you only do static type safety at compile time. Those are different times. You can't have both of those features at the __SAME TME__, therefore you can't have both features ALL the time. They are mutually exclusive…

Dynamic dispatch is literally a runtime feature of a language. That's why it's called "dynamic". GP can absolutely use dynamic dispatch "all the time" in the sense that they use it regularly in their program, perhaps in every or nearly every program they write. Your statement is verging on the nonsensical, like saying to someone "You don't use integers all the time, sometimes you use strings, they're different things…

I am using a perfectly sensible notion of "dynamic" (e.g NOT static) when I am talking about "dynamic dispatch".

Registering pointers to new implementations at runtime (adding entries to the dispatch table) Unregistering pointers to old implementations at runtime (removing entries from the dispatch table).

If your dispatch table is immutable (e.g static!), there's nothing dynamic about your dispatch!

Re: Parse, Don't Validate (2019)

#212

Post by JPKab »

mixmastamyk wrote: post #204
JPKab wrote: post #150

Earlier quoted context omitted.

It's an immediate tell when someone makes statements like the one you're replying to. It immediately tells me that they've never worked on large software projects, and if they have they haven't worked on ones that lasted more than a few months. I apologize to folks reading this for my rather aggressive tone but I've been writing software for a long time in numerous languages, and people with the unit tests as an afte…

You got paid to do the work presumably. You might also be able to push back on it. Coding standards should be a thing just about anywhere competent. In short, there are choices besides, “I alone have to do all the hard work.”

I quit the company and the team as a result of the bosses refusing to make their pet data scientists write remotely professional code.

I was more experienced with predictive algorithms and deep learning than any of the data scientists at the company but because they were brought in from an acquisition of a company that had an undeserved reputation due to a loose affiliation with MIT, they were treated like magicians while the rest of us were treated like blacksmiths.

I had the choice and I made the choice to leave. And of course I raised hell with the bosses about them not writing remotely production quality code that required extensive refactoring.

And yes I was paid to do the work but the work occupied time that I could have spent working on the other projects I had that were more commercially successful but less sexy to Silicon Valley VCs who look at valuations based on other companies' newest hottest product.

Re: Parse, Don't Validate (2019)

#213

Post by ukj »

bidirectional wrote: post #167
ukj wrote: post #94

Earlier quoted context omitted.

Tractability vs possibility. You don't grok the difference. You can implement EVERYTHING in Brainfuck. Tractability is the reason you don't. The goalposts are exactly where I set them. With my first comment. "Every programming paradigm is a good idea if the respective trade-offs are acceptable to you."

You can't actually implement everything in Brainfuck. You can implement something which is performing an equivalent computation in an abstract, mathematical sense. But there's no way to write Firefox or Windows or Fortnite in Brainfuck. Turing completeness means you can evaluate any computable function of type N -> N (and the many things isomorphic to that), it doesn't give you anything else.

I am interested in computation. Period. Not any particular model of computation (programming language); and not merely computation with functions from N->N.

Quoting from "http://math.andrej.com/2006/03/27/sometimes-all-functions-ar..."

"The lesson is for those “experts” who “know” that all reasonable models of computation are equivalent to Turing machines. This is true if one looks just at functions from N to N. However, at higher types, questions of representation become important, and it does matter which model of computation is used."

Re: Parse, Don't Validate (2019)

#214

Post by chrisandchris »

syngrog66 wrote: post #210
exdsq wrote: post #188

Earlier quoted context omitted.

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

you run it. look at the results or output. like the stdout, or a file it changed, or in a REPL or debugger. depends on situation

Yeah I‘m not sure that‘s how software engineering should work.

Tests should prove a desired behaviour. Sometimes it‘s not possible to fully run code until late in some staging, just because there are a lot of dependencies and conplexity. That‘s what tests are for (on various lebels of abstraction).

Re: Parse, Don't Validate (2019)

#215

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…

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

Re: Parse, Don't Validate (2019)

#216

Post by goodoldneon »

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.

My company soured on Marshmallow a while back due to performance. Maybe it’s gotten a lot better, but it has a bad reputation here. Most people seem really happy after we started using Pydantic. Take all that with a grain of salt since I’m just parroting hearsay :)

Re: Parse, Don't Validate (2019)

#217

Post by cortesoft »

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?

Sorry, should have said “aren’t JUST to make sure your code works when you write it”

I was specifically responding to the commenter I replied to, who said they didn’t need tests because their code just worked the first time after he wrote it.

Re: Parse, Don't Validate (2019)

#218

Post by cortesoft »

chrisandchris wrote: post #214
syngrog66 wrote: post #210

Earlier quoted context omitted.

you run it. look at the results or output. like the stdout, or a file it changed, or in a REPL or debugger. depends on situation

Yeah I‘m not sure that‘s how software engineering should work. Tests should prove a desired behaviour. Sometimes it‘s not possible to fully run code until late in some staging, just because there are a lot of dependencies and conplexity. That‘s what tests are for (on various lebels of abstraction).

I think it depends on the task. Some code we write is so simple and only used a few times that you don’t need tests.

Re: Parse, Don't Validate (2019)

#219

Post by omegalulw »

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…

Can't you do this already with Python type annotations? I am a fan of typing in general (not just for data model as this seems to be) and using types everywhere saves a lot of debugging hassle and even allows for catching some bugs with static analysis.

Re: Parse, Don't Validate (2019)

#220

Post by joshuamorton »

b3morales wrote: post #201
justinpombrio wrote: post #97

Earlier quoted context omitted.

You understand it. It's using the word "parse" metaphorically, to mean "validate, then put it in a specially marked data structure". For example, `parse_int :: string -> maybe int` is a parsing function, and it "validates that the string is an integer, then puts it in a specially marked data structure called int". However, the post uses the word "parse" not only for true parsing functions (that convert text into a da…

I don't think this is the same as "make illegal states unrepresentable"; it's a corollary (or the converse maybe): "Make assertions of legal states representable"

They're sort of the same. If you have str and safestr, and safestr is known to confiorm to some invariant, the illegal state of a, say str where validate hasn't been called, isn't representable.
Post reply on HN