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

131–140 of 146 posts

Re: Test, don't just verify

#131

Post by Izkata »

baq wrote: post #19
badgersnake wrote: post #4

> AI is making formal verification go mainstream. This nonsense again. No. No it isn’t. I’m sure the people selling it wish it was, but that doesn’t make it true.

You haven't been paying attention. The fact that we're reading about it here today and have read about it in the past weeks is one piece of evidence. Another is that we hadn't been reading about it in the past months before November. Opus 4.5 and GPT 5.2 have crossed an usefulness frontier. Anecdotally, I've been having some success (guiding LLMs) writing Alloy models in the past month and ensuring conformance with c…

> The fact that we're reading about it here today and have read about it in the past weeks is one piece of evidence. Another is that we hadn't been reading about it in the past months before November.

Except I do remember reading about it on here many times in past years.

Re: Test, don't just verify

#133

Post by maleldil »

zahlman wrote: post #128
array_key_first wrote: post #120

Earlier quoted context omitted.

That's not the entire point of dynamic typing, because all the interface stuff comes from statically typed languages. Some* dynamic languages borrowed it, but most use "implicit" interfaces - where the interface is whatever kind of works, I guess.

> because all the interface stuff comes from statically typed languages. No, it doesn't. It comes from theory that came after the languages. > Some* dynamic languages borrowed it, but most use "implicit" interfaces An implicit interface is an interface, and is exactly the sort of thing I'm talking about in GP. The point is that you think about the object in terms of its capabilities, rather than some proven-up-front…

You can achieve this with structural subtyping, such as Go interfaces and Python protocols. Whether that is desirable is a different question.

Re: Test, don't just verify

#134

Post by paulddraper »

lelanthran wrote: post #89
paulddraper wrote: post #83

Earlier quoted context omitted.

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.

I believe that is in fact the exact return type of malloc.

You have to do extra work to type it.

I’m not aware of any other statically typed language that does that.

Hopefully that helps you in your battle.

Re: Test, don't just verify

#135

Post by lelanthran »

paulddraper wrote: post #134
lelanthran wrote: post #89

Earlier quoted context omitted.

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

I believe that is in fact the exact return type of malloc. You have to do extra work to type it. I’m not aware of any other statically typed language that does that. Hopefully that helps you in your battle.

> I believe that is in fact the exact return type of malloc.

> You have to do extra work to type it.

Nope. Casting the return from `malloc` is a code-smell in C. You have to do extra work if you use `malloc` in C++.

> Hopefully that helps you in your battle.

Not sure what you mean by this - weren't you the one who dragged C into a conversation about Python?

Re: Test, don't just verify

#136

Post by lelanthran »

Jensson wrote: post #127
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…

> Right now, a single developer with Claude code can very easily overwhelm even a couple of testers with new code to test. Because there are endless errors and problems that never gets fixed with AI coding. The reason testers ran out of things to test before was that developers tested themselves before sending it over, if you take a bunch of cowboy coders coding thousands of lines a day with no testing whatsoever bef…

> Because there are endless errors and problems that never gets fixed with AI coding.

But, that's my point :-)

> The reason testers ran out of things to test before was that developers tested themselves before sending it over, if you take a bunch of cowboy coders coding thousands of lines a day with no testing whatsoever before throwing it over to the testers you would say you don't have enough testers even if you had thousands.

Right. But even if the devs are doing unit-tests (which is all devs are supposed to do), they can still overwhelm a QA department.

We could never do this before. GGP claimed that we always could. I am disagreeing with that specific claim - "We could always overwhelm the testers".

Re: Test, don't just verify

#137

Post by seg_lol »

tasuki wrote: post #79
baq wrote: post #51

Earlier quoted context omitted.

Good that Python supports types then

Tell me more please: how does one use types in Python? Unfortunately I write Python professionally these days (it is the language that has all the libraries) and hate it with a passion.

You will never get good if you continue to hate it. You don't have to like it, but hating it creates a mental block.

Re: Test, don't just verify

#138

Post by swid »

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.

Go Proverb:

A little copying is better than a big dependency.

Re: Test, don't just verify

#139

Post by teaearlgraycold »

swid wrote: post #138
teaearlgraycold wrote: post #72

Earlier quoted context omitted.

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.

Go Proverb: A little copying is better than a big dependency.

100% agree. This actually makes AI-aided development a big improvement (as long as you’re careful). You can have an LLM write you a little function, or extract the correct one from a big library, and inline it into your module.

Re: Test, don't just verify

#140

Post by kccqzy »

Groxx wrote: post #67
baq wrote: post #51

Earlier quoted context omitted.

Good that Python supports types then

Python has formalized magic comments. You can run a third party linter on those comments, but you must hope that they're correct. There are usually some checks for that, but they're only reliable in trivial cases. This is not static typing any more than "you can use emscripten to transpile JavaScript to C" means that JavaScript is a low level language with native assembly support. It's a huge step forward from "no sy…

They are originally magic comments, unformalized. The feature is originally known as annotations and you can basically put anything there.

    def f(a: "something like an int", b: "another int-like thing"): pass

    def g(a: sys.stdin, b: sys.stderr): pass
Post reply on HN