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

The type system is a programmer's best friend

dusted.codes

Post reply on HN
Print view View original

211–220 of 467 posts

Re: The type system is a programmer's best friend

#211

Post by astrobe_ »

bluGill wrote: post #149
highwaylights wrote: post #145

Earlier quoted context omitted.

I’d take this further. I was listening to the John Carmack episode of Lex Fridman from the summer, and he makes a comment about being frustrated that in the Valley there’s an almost religious opposition to IDEs, debuggers, and static analysis. Some of those tools have only become more powerful over time and I’m perplexed as to the mindset that would make a person averse to automating the drudgiest parts of their job…

I'm adverse to debuggers as i've more than once caught myself following a rabbit hole of steping through code instead of thinking. IDEs have some use, and static analysis has proven to catch the same mistake over and over, but only as the authors of those tools have discovered that false positives cannot be allowed ever, once there is a false positive the tools is worthless.

> I'm adverse to debuggers as i've more than once caught myself following a rabbit hole of steping through code instead of thinking.

Yes. I was kind of forced to think and do printf debugging at the beginning of my career, after having used before that (as a hobbyist) quite good asm debuggers.

Maybe that's just me, but I also was, I believe, a bit over-reliant on the debugger - I would just compile, run, see what happen, and launch the debugger if something didn't work.

Nowadays I could use sometimes a debugger - but the system I work with is sort of soft real-time so stopping at a breakpoint of even slight changes in timings can change the context - in some cases even printf debugging could make a bug vanish.

If nothing else, debugging without a debugger is a good exercise in logically thinking - and it can save time too.

Re: The type system is a programmer's best friend

#212

Post by masklinn »

blep_ wrote: post #188
masklinn wrote: post #34

Earlier quoted context omitted.

> I can't imagine having a type for a persons name that holds checks anything but perhaps a strings length, certainly not a list of all possible names. As always, that is very domain-specific: there are lots of countries with naming laws, some of which do have lists of legal names.

Legitimate question: what do they do about immigration into those countries from countries without such laws?

Likely nothing: usually they’re laws which apply to parents / birth certificates.

I guess it’s possible that an immigrant trying to get naturalised would have to adopt a “legal” name for the country, but I’m not aware of any country where that’s a rule, aside from the Zairianisation movement of Mobutu.

Re: The type system is a programmer's best friend

#213

Post by emodendroket »

noobermin wrote: post #164
emodendroket wrote: post #154

Earlier quoted context omitted.

I don’t disagree that it makes things much more pleasant, but I started doing this around 2013, which, while old, was still a year beginning with 20, and consensus was trending the opposite way and people were bullish about stuff like Ruby. The pendulum has really swung in the other direction.

No, there really is no new insight OP or anyone else has. At the end of the day, the only thing that matters is writing something that works and works well. Hackers go through too many moodswings to be worth paying attention to when they start telling you how you should code.

Doesn't really follow that because you ended up with a successful product that means it was the best way you could have possibly done it. I don't feel like I'd learned everything I know today the first time I delivered a successful product, and I doubt I know everything I'll know in the future either.

Re: The type system is a programmer's best friend

#214

Post by jstimpfle »

Izkata wrote: post #207
jstimpfle wrote: post #194

Earlier quoted context omitted.

As much as I can just happily ignore JSON because I don't do webdev, I think there is a strong case to make that lists should be implemented using a native list, array, or vector class. But I won't argue because it's not necessary. The possibility for argument already proves my point. My point is to show that "the type system" provides endless rabbit holes, and often is just a waste of time. There are a lot of situat…

> The possibility for argument already proves my point. Was just correcting something wrong: > But as a heads up, Map couldn't be representation of all valid JSON documents. So, > As much as I can just happily ignore JSON because I don't do webdev I think this is why you're going wrong here. JSON is pretty much a solved problem, and Map is pretty close to how it's used in Java and other languages that don't have nati…

JSON is a data-interchange format, i.e. a specification how to serialize and deserialize a domain of values. So Map "isn't JSON" either.

JSON isn't a solved problem, it's a solution to a problem (and often used as a non-solution to a non-problem).

But none of that was my point.

Re: The type system is a programmer's best friend

#215

Post by zbentley »

pyjarrett wrote: post #143
runeks wrote: post #131

Earlier quoted context omitted.

That's definitely cool, but for everyday programming I'd consider this a waste of time.

I agree that it sounds really stupid up front, but it's done when you're just you modeling the constraints of the problem. I've found that it saves a lot of time in debugging and silly mistakes later. For types with invariants, you just add the `Invariant` aspect and then the type invariant gets checked automatically when passed as a parameter. Combined with built-in pre/post conditions, I've found that these sort of…

If you like this style of programming but use Python for your day-to-day, check out typeguard; it provides runtime assertions for parts of the Python type annotation system similar to "Invariant".

As with many tools, there are caveats. It's often surprisingly slow (so avoid using it on hot paths, or only turn it on during your testing/pre-production runs) and can't type-check everything (e.g. callables). But it's still pretty nice and requires minimal effort to use!

https://pypi.org/project/typeguard/

Re: The type system is a programmer's best friend

#216

Post by samatman »

PainfullyNormal wrote: post #73

Articles like this bug me. You've given me a list of why types are awesome. Great. Now, tell me what the tradeoff is. Nothing is free in engineering. To get something, you have to give up something else. Even grug[0] understands this. [0]: https://grugbrain.dev/#grug-on-type-systems

I found this blog post on HN some time this year, and refer to it frequently:

https://hirrolot.github.io/posts/why-static-languages-suffer...

The key thing the author identifies is the two languages problem. Static types are a second program about the program, and that's great when the second program is simple declarations that keep you from passing one struct when another is expected.

But a flexible language needs more than that, and generics end up either Turing Complete or bad in some other way.

I'll be mulling this one over in years to come.

Re: The type system is a programmer's best friend

#217

Post by mamcx »

deltasevennine wrote: post #168
gary17the wrote: post #104

This is, IMvHO, such old news that it feels... weird to still read about it in a year with the prefix of 20. Every programmer who has ever single-handedly written a 100,000+ LOC software system will tell you the same thing: shift as much responsibility on the compiler as you can and have the compiler check the code you write to any extent technologically possible. Getting rid of bugs by experiencing, diagnosing and f…

But there's a paradox. Why does 100,000 lines of code of python tend to be safer and more manageable then 100,000 lines of C++ despite the fact that python has no type checker and C++ has a relatively advanced type checker? Why do startups choose a python web stack over a C++ web stack? I don't think it's "self-evident." I think there's something more nuanced going on here. Hear me out. I think type systems are GREAT…

> and C++ has a relatively advanced type checker?

But why it NEEDS that?

Because C++ is FAR MORE DANGEROUS.

And worse language, in so many aspects, that you need everything to tame it.

In contrast, other langs like python have the luxury of see what C/C++ do wrong and improve over it.

Just having a `String` type, for example, is a massive boost.

So for them, the type system already have improved the experience!

---

So this is key: Langs like python have a type system (and that includes the whole space from syntax to ergonomics - like `for i in x`, to semantics) and the impact of adding a "static type system checker analysis" is reduced thank to that.

And considering that if you benchmark for a "static type system checker analysis" is what C++/C#/Java (at the start?) is then the value is not much.

Is only when you go for ML type systems where the value of a static checker become much more profitable.

Re: The type system is a programmer's best friend

#218

Post by zbentley »

dustedcodes wrote: post #190

Hey author here! Sorry I didn't respond to any feedback yet. I've literally posted this before leaving my house and didn't think it would get many upvotes as it didn't get any votes the other day either. Sorry that the general sentiment is "everything old gets new again". I didn't try to rehash some old news again. I basically blog about things that come up in my daily work life and this topic was something that I fe…

Don't let it get you down. HN sentiment often trends grumpy when someone makes a point that's been made before. That doesn't mean it's not important to restate, extend, elaborate on, modernize, and recontextualize ideas!

There are almost 8 billion people on this planet; most claims echo prior statements to some degree.

I found your article practical, short, and largely accurate; which is to say: I liked it. I think it could be improved with either an edit or followup which links to similarly-inclined articles, papers, or talks that discuss the topic, so folks can deepen their understanding of the role of type systems in day-to-day programming and PLT.

Re: The type system is a programmer's best friend

#219

Post by zbentley »

gnabgib wrote: post #204
activitypea wrote: post #99

>4 hours ago Ah, you reposted this, hoping the weekend crowd might be kinder. Cheeky lad.

Based on the history of dusted submissions[0]... he's a bit of a serial offender [0]: https://news.ycombinator.com/from?site=dusted.codes

Perhaps, or perhaps the poster is a beneficiary of the (useful IMO) "do you want to post this again? We felt that it's good but didn't get visibility this time around" moderator outreach tradition.

Re: The type system is a programmer's best friend

#220

Post by waprin »

emodendroket wrote: post #154
gary17the wrote: post #104

This is, IMvHO, such old news that it feels... weird to still read about it in a year with the prefix of 20. Every programmer who has ever single-handedly written a 100,000+ LOC software system will tell you the same thing: shift as much responsibility on the compiler as you can and have the compiler check the code you write to any extent technologically possible. Getting rid of bugs by experiencing, diagnosing and f…

I don’t disagree that it makes things much more pleasant, but I started doing this around 2013, which, while old, was still a year beginning with 20, and consensus was trending the opposite way and people were bullish about stuff like Ruby. The pendulum has really swung in the other direction.

I noticed this too and I have a simple explanation.

Ruby and Python overtook Java and C++ in the early 2010s in _spite_ of their lack of a good typing system, not because of it. On the whole, they are much more productive languages.

Now we're seeing languages that have Ruby / Python productivity but also have much better ways of static typing such as Typescript and Swift. And the Ruby / Python community is more open to static types as well.

The problems of ~2010 Java and C++ were mistakenly pinned on static types and the framing of "static vs dynamic languages" was always a red herring. Java and C++ were just crappy languages (at least in 2010, not sure about modern incarnations).

It really is a shame that Swift is so confined to the iOS world because it's such a great example of how you can have a language that feels like a scripting language but with much more advanced type safety.

Post reply on HN