frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

Whole-genome ancestry of an Old Kingdom Egyptian

https://www.nature.com/articles/s41586-025-09195-5
49•A_D_E_P_T•2h ago•15 comments

Trans-Taiga Road:The farthest you can get from a town on a road in North America

https://www.jamesbayroad.com/ttr/index.html
41•jason_pomerleau•2h ago•8 comments

Exploiting the IKKO Activebuds “AI powered” earbuds (2024)

https://blog.mgdproductions.com/ikko-activebuds/
454•ajdude•13h ago•169 comments

More Efficient Thermoelectric Cooling

https://www.jhuapl.edu/news/news-releases/250521-apl-thermoelectrics-enable-compressor-free-cooling
23•mcswell•2d ago•6 comments

ASCIIMoon: The moon's phase live in ASCII art

https://asciimoon.com/
149•zayat•1d ago•59 comments

Don’t use “click here” as link text (2001)

https://www.w3.org/QA/Tips/noClickHere
445•theandrewbailey•15h ago•318 comments

That XOR Trick (2020)

https://florian.github.io//xor-trick/
45•hundredwatt•2d ago•29 comments

Couchers is officially out of beta

https://couchers.org/blog/2025/07/01/releasing-couchers-v1
162•laurentlb•9h ago•65 comments

Show HN: CSS generator for a high-def glass effect

https://glass3d.dev/
236•kris-kay•11h ago•81 comments

What to build instead of AI agents

https://decodingml.substack.com/p/stop-building-ai-agents
84•giuliomagnifico•3h ago•61 comments

Vitamin C Boosts Epidermal Growth via DNA Demethylation

https://www.jidonline.org/article/S0022-202X(25)00416-6/fulltext
51•gnabgib•6h ago•15 comments

Physicists Start to Pin Down How Stars Forge Heavy Atoms

https://www.quantamagazine.org/physicists-start-to-pin-down-how-stars-forge-heavy-atoms-20250702/
42•jnord•6h ago•3 comments

AI note takers are flooding Zoom calls as workers opt to skip meetings

https://www.washingtonpost.com/technology/2025/07/02/ai-note-takers-meetings-bots/
78•tysone•9h ago•73 comments

The Zen of Quakerism (2016)

https://www.friendsjournal.org/the-zen-of-quakerism/
93•surprisetalk•3d ago•71 comments

The Evolution of Caching Libraries in Go

https://maypok86.github.io/otter/blog/cache-evolution/
85•maypok86•3d ago•22 comments

Sony's Mark Cerny Has Worked on "Big Chunks of RDNA 5" with AMD

https://overclock3d.net/news/gpu-displays/sonys-mark-cerny-has-worked-on-big-chunks-of-rdna-5-with-amd/
71•ZenithExtreme•11h ago•73 comments

Features of D That I Love

https://bradley.chatha.dev/blog/dlang-propaganda/features-of-d-that-i-love/
80•vips7L•10h ago•63 comments

Gene therapy restored hearing in deaf patients

https://news.ki.se/gene-therapy-restored-hearing-in-deaf-patients
297•justacrow•12h ago•73 comments

The Uncertain Future of Coding Careers and Why I'm Still Hopeful

https://jonmagic.com/posts/the-uncertain-future-of-coding-careers-and-why-im-still-hopeful/
5•mooreds•1h ago•1 comments

A Higgs-Bugson in the Linux Kernel

https://blog.janestreet.com/a-higgs-bugson-in-the-linux-kernel/
48•Ne02ptzero•8h ago•0 comments

Evidence of a 12,800-year-old shallow airburst depression in Louisiana

https://www.scienceopen.com/hosted-document?doi=10.14293/ACI.2025.0004
98•keepamovin•1d ago•49 comments

A list is a monad

https://alexyorke.github.io//2025/06/29/a-list-is-a-monad/
115•polygot•3d ago•134 comments

Conversations with a Hit Man

https://magazine.atavist.com/confessions-of-a-hit-man-larry-thompson-jim-leslie-george-dartois-louisiana-shreveport-cold-case/
6•gmays•1d ago•0 comments

Websites hosting major US climate reports taken down

https://apnews.com/article/climate-change-national-assessment-nasa-white-house-057cec699caef90832d8b10f21a6ffe8
237•geox•6h ago•128 comments

MindsDB (YC W20) is hiring an AI solutions engineer

https://job-boards.greenhouse.io/mindsdb/jobs/4770283007
1•adam_carrigan•9h ago

Escher's art and computer science

https://github.com/gritzko/librdx/blob/master/blog/escher.md
38•signa11•1d ago•7 comments

Private sector lost 33k jobs, badly missing expectations of 100k increase

https://www.cnbc.com/2025/07/02/adp-jobs-report-june-2025.html
413•ceejayoz•13h ago•249 comments

Efficient set-membership filters and dictionaries based on SAT

https://github.com/NationalSecurityAgency/XORSATFilter
33•keepamovin•3d ago•7 comments

WebAssembly Troubles part 4: Microwasm (2019)

http://troubles.md/microwasm/
34•Bogdanp•3d ago•1 comments

More assorted notes on Liquid Glass

https://morrick.me/archives/10068
116•freediver•19h ago•112 comments
Open in hackernews

Static Types Are for Perfectionists

https://mmapped.blog/posts/38-static-types-perfectionism
39•PaulKeeble•1mo ago

Comments

PaulKeeble•1mo ago
Despite the somewhat clickbait title this is quite interesting on technology preferences and the path to what makes us happy and productive.

The idea that our preferences in technology are driven by our path of learning seems relatively self evident, those that started with C/C++ verses Smalltalk verses Java verses Python as their first language likely have a very different perspective on the various trade offs of these languages. Given we don't usually learn every language and certainly not to a deep extent few have deep experiences in all the possibilities to grok the differences in practice on similar projects.

  "I need the right project and the right team to function well"
I really resonate with this, in the right environment I seem vastly more productive. I have a significant preference for low levels of control and oversight and in those environments I can take actions quickly with less discussion and often get to better answers quicker, but I hate not being able to do that and it impacts my performance disproportionately. Its one of those preferences for culture that seems vital to how I want to work and impacts productivity a great deal. Asking permission or high rigour for potentially "extra" work just grinds my gears!
AnimalMuppet•1mo ago
I don't think it's just "what our path of learning was", though that plays a role. I think that different personalities prefer different styles (functional vs procedural), different languages (static vs dynamic typing), and probably several other axes.

This explains, for example, why one person sees functional programming as a massive revelation, where suddenly everything "just fits", and assumes that anyone who doesn't have the same reaction hasn't "gotten it" yet. And others, despite diligent trying, never have that reaction.

parpfish•1mo ago
i like static code because a codebase that applies types well gives you the same benefits of writing lots of tests for free.
cma•1mo ago
Ironically they usually make unit tests and testing by hand in the repl harder
Spivak•1mo ago
Yep, there is basically nothing else to be said. Using a static type checker isn't some moral imperative or whatever. I simply am able to write better, more correct code faster than without it. And my test suite doesn't have to do things like check the return type of the function because the type checker already knows.
igouy•1mo ago
Ummm wouldn't that be check the return value which the type checker doesn't already know?
90s_dev•1mo ago
Type systems make 93% of tests obsolete. The other 7% are implied by developing new features and making sure they work as you expect. If nothing broke, you're good to go. Incidentally, it scales with a team. The more people writing code, the more people who will run into some bugs one of you introduced. In my experience, automated tests (unit or e2e) never reduced that number, but only slowed us down. I wonder if TDD & BDD were just an excuse to bill clients for more time while giving them a false sense of security.
theLiminator•1mo ago
Ironically the strongest advocates of dynamic languages tend to be places where a strong type system would solve a huge percentage of their bugs.

Web development is mostly the munging of data together and ensuring that you're glueing stuff together correctly. Static type systems, especially ML based ones would ensure that most of this is done correctly.

AnimalMuppet•1mo ago
> Type systems make 93% of tests obsolete.

I don't suppose I could trouble you for a source for that number?

90s_dev•1mo ago
Yeah I just made it up.
parpfish•1mo ago
I made up a similar number, so it’s been replicated
igouy•1mo ago
The benefits are not the same. Code can type check but not be correct.

There's no free lunch. Some languages require explicit type definitions others don't.

theLiminator•1mo ago
> Code can type check but not be correct.

Depends on your type system. It can prove the correctness of certain properties depending on your language.

Conversely, unit tests can pass but your code might not be correct.

igouy•1mo ago
Depends on your type system. Depends on your tests. Depends.

Yet another under-specified commentary ;-)

kibwen•1mo ago
Conversely, code can pass tests and not be correct, including in ways that would have been trivially caught by a type system.

If you care about correctness, use both. Codebases written in static languages still use tests.

igouy•1mo ago
Yes, we care about run time behavior.
kibwen•1mo ago
Then you'll be happy to hear that static types do a better job of determining runtime behavior than tests do, for less time and effort.
igouy•1mo ago
Do you have a case studies which show that to be true?
parpfish•1mo ago
Well, yeah. Types don’t remove the need for ALL tests, but it removes the need for the most boring 90% so your test suite can just focus on the most important behaviors
edg5000•1mo ago
I wrote a large enterprise JavaScript application that was behind Apple/Google update approval, was used daily by businesses whose entire operation depended on it.

I will never touch loosely typed stuff again. I want every keystroke checked for errors. I want autocomplete to select from possible members/fields/variables/functions/classes rather than doing constant global find/replace operations and having the customer be the beta tester

emoII•1mo ago
You do write tests, don’t you?
fyrn_•1mo ago
Yeah, that will really help with the auto complete and keystroke by keystroke checking?? What?
ninetyninenine•1mo ago
Don't understand why people find tests important but not types.

There's two popular ways to verify your programs. Types and tests. Types are EASIER then tests and types COVER more then tests.

The ideal thing is to use both, but why spend so much time on unit tests over types is beyond me.

Note that integration tests are a different beast. Why? Because you need to test things that aren't covered by either unit tests or types. In unit tests you mock out things that are external like IO, databases, and the like. In integration tests you need to test all of those things.

Integration tests are THE most important thing to use to verify your program because it's an actual test to see if your code works. But unit tests vs. types? Types win.

When I code. I never write a single unit test. Just types, and integration or end 2 end tests. It doesn't hurt to write a unit test and it's actually better. But the fact that I'm confident my code works without it shows the level of importance.

gleenn•1mo ago
If you do it right, your tests cover the thing you care about and are less work usually because you write the test for the part of code that has the interesting part you want to verify works correctly. Types, especially on fully typed languages, make only guarantees about the type of values and they make you do it in places you might not care about. Types also only catch certain classes of errors that I personally find less helpful that tests. So to me, tests are less work, focus on thebimportant parts, and give better error messages. Obviously you can also write bad tests and do things like effectively just check the types in pmaces and you are back to square one. Testing is more of an art but the effort/economics of time are far better to me.
the_af•1mo ago
> types [...] make only guarantees about the type of values

What do you think "type of values" means and encodes, and why do you think it's different from your handwritten tests?

I assume you do know that type checking is more than simply validating you're passing a string to a function that expects a string argument?

> Types also only catch certain classes of errors

Which classes of errors? Why do you think manually written unit tests are more complete?

AnimalMuppet•1mo ago
Depending on your language, some things may not be easy to encode in types. "Verify that the function handles gracefully the situation where the map it's passed doesn't contain that one magic entry." That won't be easy to encode in a type...
the_af•1mo ago
Of course not everything can be encoded in types, and also YMMV regarding the specific language you're using.

But you now why I asked the question: people who make claims like "types make only guarantees about the type of values" usually don't understand what modern type-checking can do or what can be encoded in types. People making these claims often believe type-checking is limited to validating that you only pass strings to a function expecting a string argument, or some minor variation of that.

gleenn•1mo ago
The fact remains that your type system can be turing-complete and still not validate the actual logic that I need checked/tested.
the_af•1mo ago
The same can be said of tests.

Types are just tests. By removing all the mindless, repetitive tests you write, typechecking can free you up to write the actual meaningful tests that you truly need to write.

It's not "pick one", it's "use type checking to help you only write the unit tests that matter".

gleenn•1mo ago
If I have a complicated set of business-logic functions that all return booleans, the type-checker can tell me I got a boolean back but not that in xyz scenario my result should be true and abc scenario it should be false. You must write a test for that, the types are only the most marginal at helping check correctness. There are many more examples like this. If I have to write the tests, why do I want to spend time writing all the types too if my tests cover the things I care about the the types only cover details like "you returned a number from a function marked boolean", that type of error is super easy to catch with a test, so I didn't need the types.
the_af•1mo ago
> the types only cover details like "you returned a number from a function marked boolean", that type of error is super easy to catch with a test, so I didn't need the types

Thanks for your reply, this is why I asked: this kind of typechecking you describe only scratches the basics of what a robust type-checking system can do.

In practice, it can cover much more than "you returned a number from a function marked as boolean", and so it saves you from writing lots of unit tests, leaving you free to write only the few tests that make sense for your business logic.

Once you have a proper type system in place, you can do much more than:

> [...] a complicated set of business-logic functions that all return booleans [...]

You can encode more useful things in the type of the functions than just "it returns a boolean". Of course if every function you write only returns a boolean you won't get much from the type system! But that's circular reasoning...

gleenn•1mo ago
It's not circular reasoning, I literally have piles of boolean-typed functions in business logic and there is no quantity of type-checking that will validate that (defn should-go [light-is-green? intersection-is-clear?] (and light-is-green? intersection-is-clear?)) is correct. That requires an actual test. Obviously my example is trivial but they quickly become non-trivial and the type-chrcker will never save me if I replace "and" with "or".
the_af•1mo ago
> I literally have piles of boolean-typed functions in business logic

Yes, but this is working with legacy code that wasn't written with a mature type-checking system in mind. The boolean type encodes very little meaning with it, and so there's not much you can reason about it, as you've noticed.

If your argument is "a modern type system cannot help me much with legacy code that didn't leverage it to begin with" I can understand you and even agree somewhat. But that's a different argument.

That's what I mean by circular reasoning: if you don't use the types, then yes, a type system won't be of much use. You'll spend time writing unit tests, which for legacy code seems like an adequate approach.

gleenn•1mo ago
I neither used the word legacy nor modern. I don't care how fancy your type checker is today or tomorrow, the arbitrarily deeply complicated boolean-typed function I write tomorrow gleans nearly zero value from type validation. It gains actual validation of correctness with real tests.
the_af•1mo ago
It's a legacy problem in the sense your system is a badly designed mess of functions that only return boolean. You could encode additional semantics in the types. Of course if you don't, the type system will be unhelpful.

This is a modeling problem at this point. Types can make your model better by encoding more things. It's often not easy or feasible to refactor the mess, so sometimes you're stuck with it.

gleenn•1mo ago
Can you explain concretely how adding types would make a bunch of boolean-valued functions and some tests better? What types would you introduce to my example?
ninetyninenine•1mo ago
You need dependent types for this to fly. But the main argument is that there’s an infinite number of ways your Boolean functions can go wrong if they mistakenly taken a wrong input type or return a non Boolean. Types reduce this universe of runtime errors by 99 percent. It’s still infinite though but you have a lot less possible errors.
gleenn•1mo ago
That's my point, the type errors being reduced isn't that interesting, I usually find and fix those extremely quickly. What I don't find but am most interested in is the actual logic. So I must write tests. And when I write tests, I get the type errors covered too. So why should I spend my precious time modeling inside a type system when the ROI is minuscule and the cost is I have to litter my codebase with types. Just write the tests.
ninetyninenine•1mo ago
You can write the test in the type system with dependent types. It's the same thing. But your language needs to support this. Typescript supports it. The static analyzer in your ide or during compilation will now run the test. You get a model and a test for free.
dragonwriter•1mo ago
If your type-checker is “mature" enough to encode the full value level semantics of the code it types (rendering the code itself superfluous, as then you’d just need to compile the type-level code to get your app), you then have the problem of validating the logic of the type-level code, and the natural solution to that problem is, again, testing.
the_af•1mo ago
Type checking is modeling + testing.
MoreQARespect•1mo ago
Like tests, types can be more hassle than theyre worth if you dont use them correctly.

Before mypy came along I was pretty disciplined at A) testing and B) ruthlessly clamping down on primitive obsession.

I use types a lot now but I didnt see enormous quality or productivity gains when I started using them. I suspect people who let compilers catch their bugs were always A) pretty lax testers and B) probably often let primitive obsession get the better of them.

There are only a few types of tests where I think that types actually serve as an appropriate substitute.

theLiminator•1mo ago
> When I code. I never write a single unit test. Just types, and integration or end 2 end tests. It doesn't hurt to write a unit test and it's actually better. But the fact that I'm confident my code works without it shows the level of importance.

Imo this might be true if you're writing a lot of glue code. But I think unit tests are extremely valuable for testing pure functions that are pure logic/computation. For glue code/ensuring everything is hooked up correctly, types easily beat tests, but for pure logic tests (ideally property based testing if you can swing it) works great.

ninetyninenine•1mo ago
Game developers work with more purity then web devs as web devs always funnel pure computations to external resources (usually the database).

The weird thing is Game developers don't unit test stuff. Why? Because it's mostly not that effective. I know a lot of people say stuff like game devs are cowboys that don't follow best practices but that's not true. A lot of game devs know their shit inside and out.

Here's the reason why Game devs don't unit test. There's no point. They run the program themselves a couple of times on their own computer and their good. The problem with web dev is that all their code is so Tied with IO they can't even run the code on their computer. So in order to test their logic they have to write mocks and then unit test their code with mocks in place. But why even do this when you can cover it all with an integration test?

Hence I don't unit test. My integration tests and type checking covers it all.

90s_dev•1mo ago
TDD and BDD are security blankets for enterprises and clients. They add disproportionately little value, and significantly increase the cost of evolving an app in any direction.
jamil7•1mo ago
The person you're responding to only mentioned tests, not TDD or BDD.
90s_dev•1mo ago
People who think like that commenter implied, are almost always indoctrinated into "if you don't write tests and use TDD or at least BDD, you're literally Satan."
MoreQARespect•1mo ago
TDD and BDD teaching and tutorials are almost universally terrible so people inevitably do them badly and then moan about the results, which can be worse than not using them at all.

Usually the primary mistake is either using cucumber (which is awful) or surrounding the wrong interfaces with tests (usually at too low a level).

Done well they are like a mini superpower.

90s_dev•1mo ago
I've learned from the so-called experts for years. I studied directly under them. I spent so many years trying to find the perfect way to do TDD and BDD. I saw their own code and their own solutions up close. They're frauds. It was all a sham.
MoreQARespect•1mo ago
I'd be shocked if it wasnt because they also led you to make the two primary mistakes i refered to above.
90s_dev•1mo ago
Ah so you're the guru I should have studied under all those years. If only.
MoreQARespect•1mo ago
Perhaps. More than a famous guru I find most companies badly need a testing framework that can simulate 90% of possible scenarios hermetically and lack somebody who can build that.

Once you have that and somebody has taken you around the block 3 or 4 times pairing with TDD on your app it usually starts to make more sense.

On my team after I inculcated the TDD habit properly, BDD came naturally. I didnt even encourage them to have conversations with the PO while screensharing the tests. They dont even know that's called BDD.

NeutralForest•1mo ago
TDD/BDD are just tools, in some cases they're useful and some other cases they're not.

If your work is deeply exploratory and you don't even know what the final interface/API will look like, you shouldn't start with TDD. You should probably test as you go though, once you find some behavior you'd like to keep and pin down variations and edge cases you met during dev.

If/Once you know what the expected behavior is, you can encapsulate that knowledge in tests, that's TDD to me. Then, I can write more code that meets the need of the expected API.

toolslive•1mo ago
"unit tests are a poor man's compiler" (NN)
rrauenza•1mo ago
I adopted Python type annotations on a new project I was writing. Requirements shifted a lot as well as the implementation.

It was amazing. I could refactor quickly after changing a dataclass, field name, function arguments, type, etc. I just ran mypy and it immediately told me everywhere I needed to update code to reference the new refactored type or data structure.

Then only after it was mypy clean, I ran the unit tests.

bpshaver•1mo ago
Even better, run `mypy` as part of your LSP setup and you don't even need to wait to run `mypy` to see type errors! If I make a mistake I want to be notified immediately.
IshKebab•1mo ago
Just use VSCode with Pylance. Much better than Mypy.
bpshaver•1mo ago
Not a VS Code user
IshKebab•1mo ago
You can use Pyright still for errors in other editors. It's better than Mypy.
bpshaver•1mo ago
I'm aware, but you said Pylance, which to my knowledge is just the VS Code extension.

I'm satisfied with Mypy but curious to someday try other type checkers. Pyright is on the list.

NeutralForest•1mo ago
My style has changed over time and part of it is thanks to static type checking in Python. I rarely use dictionaries anymore when what I actually want is a different type that functions will handle down the line. So to transfer data, I usually make frozen dataclasses where I used to use dictionaries. It's more work when you want to add fields on the fly ofc but it pays dividend anytime the logic becomes more complex.
rrauenza•1mo ago
Agreed -- dataclasses over dicts. And for legacy code I try to move them to typed dictionaries.

Pydantic is also helpful to enforce types on json.

I've also stopped passing around argparse namespaces. I immediately push the argparse namespace into a pydantic class (although a dataclass could also be used.)

smitty1e•1mo ago
Yes, but, the longer I use python (for personal and admin tasks mostly), the more the REPL and pytest let me sneak up on the 80% solution to my task at hand and get on with life.

The scope of possibility does not end with a full-on enterprise application, having all of the Bell() and Whistle() classes.

constantcrying•1mo ago
I think it is important to understand why you are doing what you are doing. Sure, enjoyment and "authenticity" can be part of it, but it clear that e.g. static vs. dynamic typing is an engineering tradeoff. Making a decision in either direction should be based on those tradeoffs.

One important consideration is the importance of the project, hobby projects are for enjoyment mostly, so there "authenticity" is really important. At the same time you shouldn't make decisions on how to develop aerospace software based on how "authentic" the development process feels.

roman-kashitsyn•1mo ago
> you shouldn't make decisions on how to develop aerospace software based on how "authentic" the development process feels.

You don’t just land in an aerospace company with an unbiased, rational mind and make an engineering tradeoff. You join it because you find building high-integrity software fulfilling (I am!), and the job enables you to exercise choices that feel right to you. Alternatively, you are so passionate about space that you can endure whatever it takes to get there, including writing Ada/Spark.

The best swimmers don’t grow high and develop long limbs and a big chest due to their practice and rational decisions. They become best by already having a matching physique and working hard to capitalize on it.

I don’t promote a fixed mindset, saying that you can’t get better if you weren’t born with a natural talent. My point is that some things will resonate more with you and bring you the most satisfaction. You should try different things, listen to your inner response, and not judge others because they made different choices.

gejose•1mo ago
Ragebait title
constantcrying•1mo ago
And a thread where people respond to the title of an article and not the article itself.
chrisweekly•1mo ago
It's not a title that suggests much subtlety or wisdom will be found in the article.

EDIT: ... which is unfortunate, bc it's actually a decent read w/ interesting points about the relationship between (programming preferences) and (emotions / psychology).

Jtsummers•1mo ago
https://news.ycombinator.com/item?id=43966948

I'll make the same remark I did last time this was posted here (it's been submitted 3 times in one week):

The author starts with this:

> I conclude with two implications of this idea: the necessity to accept other people’s preferences without judgment and the importance of finding an environment rewarding your style.

And follows it with these two things:

> Type theory maximalists should give up their aura of moral and intellectual superiority and accept that they need therapy just as badly as everyone else in the industry (if not more).

>> Haskell will still be used in 20 years, because there will always be people looking for a productive way to weaponize their autism.

So much for "without judgement".

90s_dev•1mo ago
"If I haven't seen it, it's new to me."

I'm very happy to see the case being made for static typing. Dynamic types should be niche, and eventually they will be. Rails and Python only made them popular out of a reactionary minimalism thanks to types done wrong in C++ and Java ecosystems. New developers should read articles like this very early on. The more often they're written and posted, the sooner we can all move on from unnecessary type errors.

sshine•1mo ago
After writing a lot of Nix in the last year, it has opened me to possibly switch to Scheme.

I’ve always been a strong static type guy since 1st year of university, and yes, it ties to perfectionism and even a sense of OCD: if I model the world around me, I can relax.

But here’s a take that I’ve been trying to articulate about Nix: it’s not about the static types. Nix is loosely typed, and if there is a functional language that doubles as coping strategy for recreating a quasi-perfect model of the world, it’s Nix.

So I believe any strong modelling combined with declarative syntax can be argued is a coping strategy for autism. It’s not strictly the types.

It also happens that software made this way is more reliable, breaks less.

Maybe the opposition to its use in businesses is that business needs often change rapidly, and tying yourself to any correct understanding of the world means you’re late to the party.

(I’ll then argue: there are companies that succeed at strong modelling, and companies that succeed at pivoting, and all companies need a bit of both at different times. That’s why huge companies with scaling problems and infinite runway pick Rust, and startups pick JavaScript.)

wiseowise•1mo ago
> So much for "without judgement".

Previously author felt enlightened by sneering on stupid normies for not understanding beautiful, clean™, statically typed code.

What’s better way to show how better you’re now, that you’ve reached new nirvana, by sneering on ivory tower wizards with their arcane languages that are obviously a sign of autism (because whoever is different from, and possibly smarter than, you is obviously autistic)?

roman-kashitsyn•1mo ago
Author here.

> because whoever is different from, and possibly smarter than, you is obviously autistic

I’m not sure how you came to this conclusion from the text I wrote.

Autism has nothing to do with intelligence level.

BTW, I identify as autistic. And I find Haskell very soothing.

90s_dev•1mo ago
> Give them time and relevant experience, and they will arrive at the same conclusions:

What does this say about DHH then? He's got decades of experience yet ripped TypeScript out of his codebase angrily, preferring the foggy mystery that is dynamic types. Is he a legitimate outlier? If not, then wouldn't you have to conclude he's just a really bad programmer?

goda90•1mo ago
I work in software where bugs can be very disruptive for the end user's very important job. Typescript was a godsend over JavaScript. I've blamed issues on changes where the developer clearly didn't grok the area they were changing. And I've witnessed dependency hell slowing down the development process. I've come to the conclusions OP did from professional experience that provides negative feedback, not some past psychology from my personal life.

There are certainly cases where you wouldn't get that negative feedback for your software, so you would never feel the need for those things. And maybe in that case you can move faster without them, but you should be careful taking those beliefs into other domains.

keithasaurus•1mo ago
static types: here's what this piece of data is

dynamic types: go look through code, tests, comments and project history to try figure out what this data is supposed to be

dynamic types are exhausting

dleeftink•1mo ago
Exhausting, yes, why would we need to prep our own meal if it can be served to order?

Types are needed for sure, but don't make up for the fact we have to prep our own meals from time to time, even the best recipes don't cover all variations.

theLiminator•1mo ago
In general though, a strong statically typed language will allow the user to locally reason to a much greater extent.
keithasaurus•1mo ago
For me the variation is one of the places where dynamic typing gets really dangerous, because as variations increase, the requirement for code archaeology does as well. At some point there is enough variation that nobody could reasonably be expected to do enough code exploration to understand the full breadth of that variation.

With types, the scope of the variation is clearly stated, and if you want to expand the variation, it should be clear how to do so, depending on the flavor (e.g. union types, sum types, generics, sub types).

dleeftink•1mo ago
It's definitely easier to extend existing recipes than having to start from none. What I tried to get at, is that even with in-depth recipes, there's a bigger codebase picture behind the type, that GP found exhausting navigating without.

I think if we start to lean on types for our all recipes, we may forget how to prepare them without instruction.

williamdclt•1mo ago
If there’s a lot of variations that’s exactly when you need help from typing to not mess things up.

If the modelling is trivial, the ROI is much lower (although the devx benefits still make it worth it to me)

igouy•1mo ago
static types: write types into the code to make the compiler happy, when trying to think about more important stuff

dynamic types: method parameter name gives the type and comment gives the method return type — conventions show what data is supposed to be

static types are disruptive and exhausting :-)

declan_roberts•1mo ago
The author is 100% right when he says that personality has a big affect on programming preferences.

I see this play out in language preferences every day, INTJ (haskell, rust) and ENTJ (Golang, Java, Python).

Giving a list of the "best 3" programming languages can probably map you very accurately to a Meyers-Briggs personality.

throw4847285•1mo ago
Unfortunately, MBTI is bunk so we'll have to discover a new personality schema that explains people's programming preferences. One may exist, but it won't be a series of binary divisions of normally distributed traits.
RetroTechie•1mo ago
640B parameters should be enough to classify everyone's personality.
igouy•1mo ago
2018 "Scientists determine four personality types based on new data"

https://news.northwestern.edu/stories/2018/september/are-you...

throw4847285•1mo ago
I love the Big Five. It is a framework with a lot of explanatory power.

The Big Five are demonstrably not personality types because each trait is normally distributed. The biggest mistake that the MBTI makes is drawing a line right down the middle of each spectrum and turning it into a binary. So you get absurd scenarios like the 49% introvert and the 51% extrovert having less in common with eachother than with more extreme types.

The second biggest mistake is that the Big Five traits are totally independent of each other. Someone can be very open to experience and extremely neurotic which leads to behaviors that do not really make sense in terms of the common sense understanding of personality as a single "type" that is encoded in the MBTI. Relatedly, the third biggest mistake is that there is no dimension for neuroticism in the MBTI. This mistake was so bad that they fixed it by adding a fifth dimension for turbulence.

I would be interested in somebody trying to map Big Five onto the choice of programming languages, but then you face the challenge of trying to boil a complex decision down to human temperament. I would bet you $100 that two people with opposite "personalities" can both end up loving Python for very different reasons. Or, what if somebody is average across the board, the most likely scenario. What programming language are they going to gravitate towards?

Sorry you just shared a link to an article and I went off, but this is a topic that really gets me fired up.

igouy•1mo ago
Thanks maybe your comment will motivate me to take another look.
igouy•1mo ago
> choice of programming languages

We can make our own choice of features:

declare variables once

convert truthy / falsy to Boolean

const and final when possible

local type inference when possible

But then someone else must deal with what we've done.

bpshaver•1mo ago
I would love to read the steel man case for dynamic typing, but "static typing is for people who need therapy" isn't doing it for me. Anyone have something to recommend so I can understand the intended benefits of dynamic typing?
bryanlarsen•1mo ago
My attempt: "These dynamic languages are so much more pleasant and productive than Java 1.X."
lisper•1mo ago
> I would love to read the steel man case for dynamic typing

It's very simple: sometimes lower development effort matters more than correctness. Not all software has to run in a hostile production environment to be useful.

bpshaver•1mo ago
That would seem to be begging the question to an extent. Why does dynamic typing lead to lower development effort? I mostly write Python and make heavy use of type hints. With LSP set up, mypy informs me immediately of any potential type errors which makes development way easier for me.

Just saying "dynamic typing is easier" doesn't do it for me without further qualification since that statement doesn't conform to my own experience.

doug_durham•1mo ago
How much is maintaining your type system really helping you out? I find I spend more time tracking down irrelevant type warnings than fixing type issues. For example if you declare a type hint on a function parameter as `foo: int = None` you will get a type error. It says that a parameter of type int can't have a None value. This is false. So now I have to update my declaration to be `foo: Optional[int] = None`. This yields no value because when you say `= None` you are saying that this is an optional argument. The more you tighten your type declarations the more you will be chasing non-existent issues.
bpshaver•1mo ago
No offense, but this sounds like user error. I rarely have irrelevant type warnings. If I do, it suggests something is wrong with my design.

If you declare a function parameter as `foo: int = None`... that is just an incorrect declaration. Of course a variable annotated as `int` can take a `None` value, but that is because any variable can take any type in Python. Within the Python type (annotation) system it is simply the case that an `int` and an `int | None` are two different things, as they are in other languages (eg Rust's `T` vs `Option<T>` types).

Mypy used to support the "implicit optional" feature you describe but now you must make nullable arguments explicitly optional. This is in line with Python's "explicit is better than implicit" design philosophy. In any case, how long does it take you to just type `foo: int | None = None`? Or you could re-enable the old behavior to allow implicit optionals with `--implicit-optional` or the corresponding config file option. It seems like you just need to configure mypy to match your preferences rather than fighting with its defaults.

To return to the broader point, I'm unsure what an "irrelevant type warning" is, but I suspect that has something to do with my lack of appreciation for dynamic typing. Can you give an example that isn't just a complaint about typing an extra 6 characters or about mypy being misconfigured for your preferences?

doug_durham•1mo ago
No offense taken. I've had a long career with many different phases. I had a phase where I built palaces of types bordering on DSLs. I ended up building myself a straight jacket. I wasn't solving the customer problem, and I was only slowing myself down. Software is an engineering discipline. Every situation needs to be critically evaluated. Building a life-critical single point of failure component is much different than building a road over a culvert. In early languages you needed to specify types so the compiler knew how much space to allocate for storage. In languages like Python, type hints are more like documentation. It helps the reader understand how to use your code. It can be used for correctness. However if correctness is a primary criteria driven by engineering requirements I'd probably consider another language and accept that it is going to cost more and be slower to develop.
dragonwriter•1mo ago
> For example if you declare a type hint on a function parameter as `foo: int = None` you will get a type error. It says that a parameter of type int can't have a None value. This is false.

No, it is correct. The value None is not with the domain of type int, a parameter that can take the value None does not in fact have type int.

> This yields no value because when you say `= None` you are saying that this is an optional argument.

When you provide any default value, you are making the argument optional, but that's an orthogonal concern to the Optional[T] type, which doesn't mean “optional argument", it is simply a more convenient way of expressing Union[T, None], though with the modern type syntax, T | U is generally more convenient than either Union[T, U] or Optional[T] for U=None.

lisper•1mo ago
> Why does dynamic typing lead to lower development effort?

Because you can run your program to see what it does without having to appease the type checker first.

There is nothing wrong with presenting type hints or type errors as warnings. The problems arise when the compiler just flat-out refuses to run your code until you have finished handling every possible branch path.

bpshaver•1mo ago
What is an example of a compiler that flat out refuses to run (compile) your code? Obviously Python is not an example. The other language I know best is Rust, where as I understand the compiler doesn't refuse to compile your code, it cannot compile your code. Is there a language where the compiler could compile your code but refuses to do so unless the types are all correct?
Jtsummers•1mo ago
Not that you should ever write this in any language, but as an illustration:

  fn main() {
    let x: i32 = if true {1} else {"3"};
    println!("{}", x);
  }
This will not compile even though if it were allowed to execute it would, correctly, assign an integer to x. Python will happily interpret its equivalent:

  x = 1 if True else "3"
  print(x)
Even giving the if-expression an explicit `true` constant for the condition, Rust won't accept that as a valid program even though we can prove that the result of the expression is always 1.
lisper•1mo ago
> the compiler doesn't refuse to compile your code, it cannot compile your code

"Can not" and "will not" are kind of the same thing in this context. It's not like compilers have free will and just decide to give you a hard time. It's the language design that makes it (im)possible to run code that won't type-check.

bpshaver•1mo ago
Thanks for clarifying that compilers don't have free will. I was being facetious, sorry.
steveklabnik•1mo ago
Haskell has -fdefer-type-errors, which makes any type error fail at runtime.

This means you can only really rely on the parts of your program which are type correct, so...

static_void•1mo ago
In Rust, the `todo!()` macro will fill in type holes without needing to be finished.

Surely you can't be against putting a TODO in an unfinished part of the code?

lisper•1mo ago
I'm against anything that adds cognitive load without a compelling reason, anything makes me do unnecessary work. Typing "todo!()" is not a huge burden, but it's not zero, and if the Rust compiler is smart enough to fill in the hole it should be smart enough to do it without my having to explicitly tell it.
kibwen•1mo ago
No, because 99.9999% of the time, you explicitly do not want the compiler implicitly filling in a hole like that, and do want the compiler to tell you that you've forgotten an entire branch of control flow. Typing `todo!()` to make your intent explicit is among the least obtrusive things imaginable.
lisper•1mo ago
> No, because 99.9999% of the time, you explicitly do not want the compiler implicitly filling in a hole like that

Who are you to tell me what I want? You are making all manner of tacit assumptions about the kind of work I do and what my requirements are. I absolutely do want the compiler filling in every hole it possibly can. For me, that's the whole point of using a high-level language in the first place. For the kind of work I do, what matters most is getting things done as quickly as possible. Correctness and run-time efficiency are secondary considerations.

kibwen•1mo ago
If correctness is a secondary consideration, then you'll be happy to learn that LLMs will let you code in plain English, so there's no need to bother with using a programming language at all. The LLM will happily fill in all the holes it encounters, more eagerly than any compiler would ever dream of.

But for people who prioritize precision and correctness, that's what programming languages were invented for.

lisper•1mo ago
There are two problems with using LLMs for writing code. The first is that when the code they produce doesn't work (which is most of the time) I still have to debug it, and now I'm debugging someone else's (or someTHING else's) code rather than my own. The second is that the work I do is very specialized (custom ASIC design) and LLMs are utterly useless.

But yeah, if all you need to do is build a vanilla app then an LLM is probably an effective tool.

igouy•1mo ago
>That would seem to be begging the question …

Please excuse my pedantry: That would seem to lead to the question …

bpshaver•1mo ago
No, I was correct. Briefly, my question was "why is static typing good?" and the answer given was "static typing is good because it makes development easier." To the extent that "good" here just means "makes development easier" (and I think that is a lot of what "good" means in this context) then the answer I received was question begging to precisely that extent. Which is why I said "... to an extent." The conclusion was not quite assumed but a pretty similar conclusion was.

I can see how it appeared that I was using the phrase in the incorrect way! That usage bothers me too, and I am attentive to it.

igouy•1mo ago
Yes, you were correct. Apologies.
AnimalMuppet•1mo ago
1. Dynamic typing says "anything I can do these operations on, I accept as input". This lets you accept input from code that doesn't have something that fits the strict definition of what input you were expecting.

2. Dynamic typing lets you change what shape your data is without having to change type annotations everywhere.

Problem is, I think both of these are deeply flawed:

1. If you're writing something nontrivial, you probably have several layers of nested function calls, some of which may be calls to libraries that are not yours. If you're saying "anything I can do these operations on, I accept", it becomes very difficult to say what the full extent of "these operations" are. Thus it becomes hard to say whether the caller is passing in valid input. You can "just try it", but that becomes hard if you care about it working in all cases.

2. Refactoring IDEs are a thing these days. You want to change the type signature? Press the button. Even better, it will tell you everything you broke by making the change - everywhere where you're doing something that the new type can't do. Without types, sure, you can just change it without pressing the button. Now try to find all the places that you broke.

It may be possible to construct a better steelman than I have done. For myself, even trying to steelman the position, I find it incredibly unconvincing.

igouy•1mo ago
"Static typing is a powerful tool to help programmers express their assumptions about the problem they are trying to solve and allows them to write more concise and correct code. Dealing with uncertain assumptions, dynamism and (unexpected) change is becoming increasingly important in a loosely couple distributed world. Instead of hammering on the differences between dynamically and statically typed languages, we should instead strive for a peaceful integration of static and dynamic aspect in the same language. Static typing where possible, dynamic typing when needed!"

https://ics.uci.edu/~lopes/teaching/inf212W12/readings/rdl04...

igouy•1mo ago
> Without types … Now try to find all the places that you broke.

Do failing tests show what we broke?

bpshaver•1mo ago
Sometimes, but maybe you haven't written any tests! Type hints and immediate feedback from mypy are a lot easier than writing unit tests.
igouy•1mo ago
> haven't written any

Any!

Then maybe the immediate feedback of consistent types conveys a false impression.

bpshaver•1mo ago
Hard to conceive of a case where that would occur. Can you think of one?

The implication of what you're saying seems to be that if you're concerned about some kind of correctness you should be writing unit tests anyway and not being so fussed about type checking in a language like Python. I suppose if you are strictly following TDD that might work, but in all other cases type checks give you feedback much more quickly than unit tests ever can. I guess I don't understand.

igouy•1mo ago
Any old math with consistent types and incorrect calculation? (If only we'd diff'd the output with some known result.)

No doubt we're at cross purposes.

I'm a little surprised that you haven't mentioned — "Program testing can be used to show the presence of bugs, but never to show their absence!" (or existential versus universal quantification).

bpshaver•1mo ago
I'm afraid you lost me.
AnimalMuppet•1mo ago
Yes, if you have tests that test all aspects of the behavior for all possible inputs.

Oh, you don't have that? Then do not scorn the help you can get from types.

igouy•1mo ago
"Less than 35 bugs were found in the 17,100 changes."

https://news.ycombinator.com/item?id=42473314

I wonder how many were not found.

bpshaver•1mo ago
But you can achieve #1 with typing.Protocol in type-annotated Python and traits in Rust. Fitting the "strict definition" sounds like nominal typing but you can opt in to explicit duck typing or structural typing while still being typed. (Someone correct me if I'm using these terms incorrectly.) In short you can still encode a lot of flexibility with types without just abandoning them alltogether.

And with #2, you can get that with static typing too... Let's say a method accepts an instance of an object `Foobar`. I can change the definition of `Foobar` ("change what shape [my] data is") without having to change type annotations everywhere.

I agree with you, I guess, that I find the steel man position unconvincing.

igouy•1mo ago
Refactoring IDEs were a thing back in the day.

"Less than 35 bugs were found in the 17,100 changes."

https://news.ycombinator.com/item?id=42473314

Jtsummers•1mo ago
The way I see it:

Your type system is sound or complete (cannot be both, if it's a Turing-complete language). If it's dynamically typed, then it's probably complete but not sound (many, but not all, dynamically typed language implementations have some basic static type checking). If it's statically typed, it can be either sound or complete. The difference between sound and complete is: Sound type systems will reject valid programs that they cannot prove are valid; Complete type systems will reject only those invalid programs they can prove are invalid.

In practice, the choice is more one of default these days:

Do you default to static typing and allow some dynamic (runtime) type checking? C++, C#, Java, etc.

Do you default to dynamic typing and allow some static (compile-ish time) type checking? Python, JS, Common Lisp, etc.

This lets both sides have what they really want. They want to be able to express all valid programs (a complete type system) but they want to reject all invalid programs (a sound type system). They can't have it. So you end up choosing a direction to approach it from. Either start conservatively and relax constraints, or start liberally and add constraints.

If you accept that, then the case for dynamic typing is that it's a choice to move from the too permissive extreme towards a stricter position. For me this works better (in general, though I also happily use statically typed languages like Ada) because I find it easier to add constraints to a relaxed system than to remove constraints from a restrictive system.

adamnemecek•1mo ago
Types give you speed, correctness and better tooling. Dynamic typing supposedly gives you "authentic self". I think I'll pick the former.
dkarl•1mo ago
The author seems obsessed with what their code says about them personally, and only mentions other people to discuss other points of view on this question. At no point do they say anything about how working with other people influenced their thinking about programming or their technical preferences. In fact they only mention peers a single time:

> I met many people whose programming approach was my polar opposite.... I don’t have any issues with their way, as long as we don’t work on the same system

Being obsessed with what your code says about you is a concern that competes with and inevitably detracts from other desirable outcomes. This is true even when working by yourself, but it is especially true and especially obvious when working with other people.

alabhyajindal•1mo ago
So many comments about static vs dynamic typing whereas the article barely discusses that. I loved reading this - very well written!