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

111–120 of 146 posts

Re: Test, don't just verify

#111

Post by jodrellblank »

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.

> "records should be sorted by date of birth."

What's wrong with C#'s:

    System.Collections.Generic.SortedList

?

Re: Test, don't just verify

#112

Post by imiric »

zahlman wrote: post #99
imiric wrote: post #80

Earlier quoted context omitted.

Agreed. Besides, it's not like types don't matter in dynamically typed languages. The (competent) programmer still needs to keep types in their head while programming. "Can this function work with a float, or must I pass an int?" "This function expects an iterable, but what happens if I pass a string?" Etc. I started my career with JavaScript and Python, but over the years I've come to the conclusion that a language…

> Before type hinting tools for Python became popular, I worked on many projects where `TypeError` was the #1 exception in Sentry by a large margin. My experience is radically different. `ValueError` is far more common in my un-annotated Python, and the most common cause of `TypeError` anyway is the wrong order or number of arguments after a refactoring.

Hhmm I could be misremembering if it was `ValueError` or `TypeError`. This was a few years ago. I know that typing issues were always the most frequent in any Python project I have worked on.

How is your experience different?

Re: Test, don't just verify

#113

Post by chamomeal »

zahlman wrote: post #103
chamomeal wrote: post #86

Earlier quoted context omitted.

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…

> 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 st…

But nothing forces you to write functional code either. I’ve seen a whooole lot of php and JS, and most of it has been pretty terrible lol. Of course you can write terrible code in any language, but I think the ease of starting with JS/php combined with the lack of built-in opinions makes it easy to build huge piles of spaghetti.

Though these days fresh typescript codebases are usually pretty decent. I love typescript and it’s really nice to work with a well-typed, modern project with proper schema validation and such. Def miss that in clojure.

Also I wouldn’t really compare JS or pythons REPL to clojure’s. Python’s is useful, but I pretty much live inside the clojure repl

Re: Test, don't just verify

#114

Post by andrewl-hn »

phaedrus wrote: post #36
anon-3988 wrote: post #28

Before we start writing Lean. Perhaps we can start with something "dumber" like Rust or any typed program. If you want to write something correct, or you care about correctness, you should not be using dynamic languages. The most useful and used type of test is type checking. Type errors, especially once you have designed your types to be correct by construction, is extremely, extremely useful for LLMs. Once you have…

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…

> "a static type check is just a stand-in for a unit test."

This is not an original argument. Rich Hickey made a similar argument in his "Simple made easy" talk in 2011, though his focus was on a fact that every bug that easiest in a software system has passed unnoticed through both a type checker and a test suit. And even before that similar ideas of test suits being a suitable replacement for a type checker have percolated through Python and Ruby communities, too.

I distinctly remember that the "tests makes static type checks unnecessary" was in fact so prevalent in JavaScript community that TypeScript had really hard time getting adoption in its first 3-4 years, and only the introduction of VSCode in 2015 and subsequent growth of its marketshare over Atom and SublimeText got more people exposed to TypeScript and the benefits of a type checker. Overall it took almost 10 years for Typescript to become the "default" language for web projects.

Re: Test, don't just verify

#115

Post by Ericson2314 »

jesse__ wrote: post #69
Ericson2314 wrote: post #63

This blog post is out of its depth - Lean will optimize peano arithmetic with binary bignums underneath the hood - Property based checking and proof search already exist on a continuum, because counterexamples are a valid (dis)proof technique. This should surprise no writer of tactics. - the lack of formal specs for existing software should become less a problem for greenfield software after these techniques go mains…

> 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

I'm talking great libraries in great languages. Like how the kmettverse revolutionized writing Haskell. Libraries that make you completely reconsider what it is you're trying to do.

Most people use shit libraries in shit languages. NPM slopfests have no bearing on what I'm talking about.

Re: Test, don't just verify

#116

Post by andrewl-hn »

baq wrote: post #51
seg_lol wrote: post #44

Earlier quoted context omitted.

Hundreds of unit tests replace a type. Start using properties and it is in the thousands. Most code should be typed. Python is great for prototypes, but once the prototype gels, you need types.

Good that Python supports types then

It's actually remarkable how with the success of TypeScript so many other dynamic languages switched to gradual typing.

Erlang and Clojure were the early ones, TypeScript followed, and now Python, Ruby, and even Perl have ways to specify types and type check your programs.

Re: Test, don't just verify

#117

Post by shermantanktop »

seg_lol wrote: post #44
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…

Hundreds of unit tests replace a type. Start using properties and it is in the thousands. Most code should be typed. Python is great for prototypes, but once the prototype gels, you need types.

A unit test is a functional assertion. A type is a semantic construct that can provide that, but it provides a lot more.

As a trivial example, if I create a type alias from “string” to “foobarId,” I now (assuming a compliant language) can prevent code that consumes foobarIds from accidentally consuming a string.

Re: Test, don't just verify

#118

Post by baq »

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.

mypy is the simplest/oldest option, look into pyright and ty, too.

install uv and then

    uvx mypy
should do the rest.

Re: Test, don't just verify

#119

Post by baq »

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.

Hard to argue with an argument which isn’t internally coherent.

Re: Test, don't just verify

#120

Post by array_key_first »

zahlman wrote: post #95
kccqzy wrote: post #38

Earlier quoted context omitted.

Plus, it is simply more enjoyable to design the types in your program than to write unit tests. The fun factor comes from operating on a higher level of abstraction and engages more of your brain’s puzzle-solving mode than just writing unit tests. Making yourself think about “for all x” rather than a concrete x forces your brain to consider deeply the properties of x being used.

> it is simply more enjoyable to design the types in your program than to write unit tests. I have tried both and I have no idea what you're talking about. > Making yourself think about “for all x” rather than a concrete x forces your brain to consider deeply the properties of x being used. The entire point of dynamic typing is that you can think about interfaces rather than concrete types, which entails deep conside…

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.
Post reply on HN