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

Test, don't just verify

alperenkeles.com

Post reply on HN
Print view View original

81–90 of 146 posts

Re: Test, don't just verify

#81

Post by paulddraper »

pmontra wrote: post #68
phaedrus wrote: post #36

Earlier quoted context omitted.

I once attended a talk by someone who is or was big in the node.js world. He opened with the premise, "a static type check is just a stand-in for a unit test." I wanted to throw a shoe at him. A static type check doesn't stand in for "a" unit test; static typing stands in for an unbounded number of unit tests. Put another way, this common misconception by users of languages like Javascript and Python that unit testin…

Good luck using static typing to model many real world unit tests for the programming languages people use most. I start with an easy example: those records should be sorted by date of birth. We can move on to more complicated scenarios.

No one claims that types are a stand in for all unit tests.

They stand in for the banal unit tests.

Re: Test, don't just verify

#82

Post by jesse__ »

teaearlgraycold wrote: post #72
jesse__ wrote: post #69

Earlier quoted context omitted.

> the key to productive software development is more and more libraries You had me until this statement. The idea that "more and more libraries" is going to solve the (rather large) quality problems we have in the software industry is .. misguided. see: https://www.folklore.org/Negative_2000_Lines_Of_Code.html https://caseymuratori.com/blog_0031

Don’t use a library unless you really need it. Someone recently recommended I add Zod to a project where I am only validating two different JSON objects in the entire project. I like Zod, but I already wrote the functions to progressively prove out the type in vanilla JS. Less is more, including other people’s libraries.

Agreed.

Re: Test, don't just verify

#83

Post by paulddraper »

lelanthran wrote: post #56
baq wrote: post #51

Earlier quoted context omitted.

Good that Python supports types then

> Good that Python supports types then "Optional typing" is not the same as "Static typing". Great, my program will crash, because I forgot to opt-in to typing :-/

C has void pointers.

Re: Test, don't just verify

#84

Post by altmanaltman »

layer8 wrote: post #46
altmanaltman wrote: post #30

Earlier quoted context omitted.

I don't fully understand what you mean by accounting expects the probability of making the same mistake twice is fairly low? Double-entry bookkeeping can only tell you if the books are balanced or not. We absolutely cannot assume that the books reflect reality just because they're balanced. You don't need to mess up twice to mess up the books in terms of truthness. Also tests and code are independent while you always…

With double-entry bookkeeping, the only way an error can slip through is if you make the same error on both sides, or else they wouldn’t be balanced. A similar thing is true for testing: If you make both an error in your test and in your implementation, they can cancel out and appear to be error-free. I don’t quite agree with that reasoning, however, because a test that fails to test the property it should test for i…

> With double-entry bookkeeping, the only way an error can slip through is if you make the same error on both sides, or else they wouldn’t be balanced. A similar thing is true for testing: If you make both an error in your test and in your implementation, they can cancel out and appear to be error-free.

Yeah but it's very different from tests vrs code though, right? Every entry has two sides at least and you do it together, they are not independent like test and code.

You can easily make a mistake if you write a wrong entry and it will still balance. Balanced books =/= accurate books is my point. And there is no difference between "code" and "tests" in double entry, it's all just "code".

So it seems like the person who made the metaphor doesn't really know how double-entry works or took maybe one accounting class.

Re: Test, don't just verify

#85

Post by altmanaltman »

9rx wrote: post #33
altmanaltman wrote: post #30

Earlier quoted context omitted.

I don't fully understand what you mean by accounting expects the probability of making the same mistake twice is fairly low? Double-entry bookkeeping can only tell you if the books are balanced or not. We absolutely cannot assume that the books reflect reality just because they're balanced. You don't need to mess up twice to mess up the books in terms of truthness. Also tests and code are independent while you always…

What about the concept of "high confidence" is not understandable?

You can use a little less snark and "high confidence" is pretty easy to understand but your metaphor makes no sense. Balanced books =/= accurate books and it is not at all a sign that the bookkeeping is accurate. The entries are also not independent like code and tests.

Re: Test, don't just verify

#86

Post by chamomeal »

brabel wrote: post #37
packetlost wrote: post #32

Earlier quoted context omitted.

I think it's possible to write correct systems with dynamic languages, just not the ones we commonly use like Python and JavaScript. I find Clojure, for example to be one example of a dynamic language that is pretty easy to manage and I attribute that to the immutable nature and data-centric ethos. I'm sure there are other dynamic languages that would work as well. Now, I wouldn't necessarily use Clojure on a huge mu…

Common Lisp as well. I can’t explain why, but type errors are just not something I struggle with in Common Lisp! But it is in JS and Python for sure. Maybe someone knows why it feels different?

I think it’s cause there’s less imperative code and side effects to track data transformations through.

Like any random JS/php app is probably a huge pile of loops and if statements. To track what happens to the data, you need to run the whole program in your head. “And now it adds that property to the object in the outer scope, and now that object gets sorted, now it hits the database… ok…”. Whereas in clojure most functions are either a single atomic transformation to a set of data, or batch of side effects. You still have to run it through your head, but you can do it more piece-by-piece instead of having to understand a 1,000 method with class states being auto loaded and mutated all over the place. Also you have a REPL to try stuff out as you go.

Dont get me wrong, I LOVE static types. Statically typed clojure would be the best fckin language ever. But there is definitely a wide gulf between a dynamic language like JS, and one like clojure!

Re: Test, don't just verify

#87

Post by lelanthran »

scubbo wrote: post #70
lelanthran wrote: post #59

Earlier quoted context omitted.

> We always could. That has been true since the days we programmed computers by plugging jumper wires into a panel. That's news to me, and I'm an ancient greybeard in development. If you have a team of 1x f/time developer and 1x f/time tester, the tester would be spending about half their day doing nothing. Right now , a single developer with Claude code can very easily overwhelm even a couple of testers with new cod…

> If you have a team of 1x f/time developer and 1x f/time tester, Y'all have dedicated testers!? In 14 years of development, across FAANG and startup, this has never been true for me. The closest I've come is a brief period when a group of ~7 teams were able to call on the services of two testers. As you can imagine, with that ratio, the testers were not spending much time doing nothing.

I've had it at least 4 times; it's a byproduct of working in a highly regulated industry that requires the software (or goods sold) to meet a specific certification (military/munitions/EMV/etc).

In the FAANG and startup world that I worked in, there was no QA department, so I assume that FAANGs and startups don't have a dedicated and autonomous/independent QA department.

That's not the point I was making, though. The point is that we could never emit code faster than it was to deploy. Deployment (including QA) was always 2x to 4x as fast. Sometimes as much as 10x as fast.

=================

EDIT: Of course, I've been working for about twice the number of years as you, and back in those days it was pretty common for large companies to have dedicated QA. Even Microsoft had those :-)

Re: Test, don't just verify

#88

Post by 9rx »

altmanaltman wrote: post #85
9rx wrote: post #33

Earlier quoted context omitted.

What about the concept of "high confidence" is not understandable?

You can use a little less snark and "high confidence" is pretty easy to understand but your metaphor makes no sense. Balanced books =/= accurate books and it is not at all a sign that the bookkeeping is accurate. The entries are also not independent like code and tests.

> Balanced books =/= accurate books

Naturally. Hence "high confidence" and not "full confidence". But let's not travel too far into the weeds here. Getting us back on track, what about the concept of "high confidence" is not understandable?

Re: Test, don't just verify

#89

Post by lelanthran »

paulddraper wrote: post #83
lelanthran wrote: post #56

Earlier quoted context omitted.

> Good that Python supports types then "Optional typing" is not the same as "Static typing". Great, my program will crash, because I forgot to opt-in to typing :-/

C has void pointers.

> C has void pointers.

And? Void pointers are not the default type :-/

With Python I have to do extra work to get type errors.

With C I have to do extra work to hide the type errors.

I am battling to understand the point you are making.

Re: Test, don't just verify

#90

Post by lelanthran »

tasuki wrote: post #78
lelanthran wrote: post #55

Earlier quoted context omitted.

I've always hated Python. Could never enjoy it at all . Pretty much the same poor DX as PHP, Javascript, Ruby, etc. Finally set up neovim with pyright; use types on every single fucking thing , and now I love Python[1]. Can't wait to see TC39 become a reality (learned about it just this past week on HN, actually). Maybe I'll enjoy Javascript too. -------------------- [1] Within reason; the packaging experience is sti…

I've never seen types used correctly in Python. A `tuple` is not even a type! It's a type constructor!

Most of the types are "not even types". It's why you can pass a type as a value (not a string) to a function.

If the type was a type, you'd not be able to use it as a value.

Post reply on HN