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

241–250 of 467 posts

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

#241

Post by christophilus »

noveltyaccount wrote: post #151
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…

When I graduated college in the '00s I thought Vim was the most amazing thing I'd ever learned. Then a colleague at my first job showed me what happend when you typed . after a variable name in Visual Studio. Code completion, inline documentation...my mind was blown, and I never looked back. When I meet a young chap extolling the benefits of Vim or Emacs or really anything that doesn't have stepped debugging and code…

I remember using Visual Studio in college (back in 1999, 2000) and coding circles around folks who were using text editors.

These days, I use Neovim + LSP for a pretty decent approximation of an IDE-- it's quite good. Still not as good as Visual Studio + C#, but I'm on Linux now, and not writing C# anymore, and I definitely prefer an open-source, general purpose, light-weight, customizable editor.

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

#242

Post by germanjoey »

hither_shores wrote: post #156
capableweb wrote: post #122

Earlier quoted context omitted.

> The trade-off is obvious: you gain confidence about your program but you need to Learn More Stuff This is why engineering/software articles in general (this one included) needs to bring up tradeoffs more often. No, "learning more stuff" is not a downside or a tradeoff, it's just a fact of learning anything. That you introduce more coupling is a tradeoff. That the program (sometimes) gets harder to change is a trade…

> That you introduce more coupling is a tradeoff. That the program (sometimes) gets harder to change is a tradeoff. You don't introduce more coupling, you document the coupling that already exists. If your program is hard to change with types, it would be hard to change without types - but easier to change incorrectly. > That is becomes easier to write large, messy programs because programmers feel more safe in the f…

> You don't introduce more coupling, you don't the coupling that already exists.

This is true at the code level. But at the system-design level, this documentation is the extra coupling.

I feel like it's important to understand this. I agree with the original commenter; in engineering, nothing is truly free. In many cases, this extra coupling helps keep a system strong and stable, like extra nails holding planks of wood together. In other cases, you may find that part of a system's spec actually missed the mark and now needs to be ripped up and redone. That extra coupling might now work against you!

Again, that doesn't mean that it wasn't worth having it. It is just important to understand tradeoffs in engineering.

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

#243

Post by yellowapple »

zbentley wrote: post #219
gnabgib wrote: post #204

Earlier quoted context omitted.

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.

In my experience with that tradition, I've found that the moderators will just add it to the second-chance queue instead of asking the poster first.

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

#244

Post by hither_shores »

jmull wrote: post #231
jmull wrote: post #76

Why is it better to have two email types, VerifiedEmail and UnverifiedEmail vs. one Email type with an "isVerified" field? One type is probably going to align with storage and transport better, and you probably mostly want to treat verified and unverified email addresses the same except for some very specific situations. (E.g., maybe only your EmailBlaster cares, where it's like a privilege: some can send to unverifi…

(Replying to my own post) Wow, lots of great, thoughtful replies, thanks! But I'm not convinced... Maybe it's just a bad example (this is what the main article is about, though)... Generally speaking, you need to be able to send emails to both verified and unverified emails. The difference is in what the email you are sending is about. That's why VerifiedEmail as a type doesn't make a lot of sense to me. You'll need…

> You'll need sendToUnverifiedEmail(email: UnverifiedEmail) and sendToVerifiedEmail(email: VerifiedEmail), and have code to get the right type to pass to the right function the in the right circumstance...

Only if you're using a language with an insufficiently strong type system (e.g. Java, C#)

in typescript:

    type UnverifiedEmail = { address: string, verified; false }
    type VerifiedEmail = { address: string, verified; true }
    ...
    type Email = UnverifiedEmail | VerifiedEmail | FooBarBazEmail

    const sendToEmail = (email: Email): Promise = ...
in Haskell:

    class SendTo t where
         sendTo :: t -> IO ()

    newtype Email = Email string

    instance SendTo Email where
         sendTo (Email address) = ...

    newtype VerifiedEmail = VerifiedEmail Email deriving (SendTo)
    newtype FooBarBazEmail = FooBarBazEmail Email deriving (SendTo)
> I.e., due to a bug, a value of type VerifiedEmail could be created for an email address that is not really verified. Then, your static checks for VerifiedEmail don't help you at all.

Of course they do - they tell you that the bug is in the verification code, and not in any of the thousands of lines of business logic separating it from the place where the error was found.

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

#245

Post by Our_Benefactors »

constantcrying wrote: post #163
noveltyaccount wrote: post #151

Earlier quoted context omitted.

When I graduated college in the '00s I thought Vim was the most amazing thing I'd ever learned. Then a colleague at my first job showed me what happend when you typed . after a variable name in Visual Studio. Code completion, inline documentation...my mind was blown, and I never looked back. When I meet a young chap extolling the benefits of Vim or Emacs or really anything that doesn't have stepped debugging and code…

Vim is not really an editor. It is a way to edit text, you can use vim in almost any environment. You are also totally wrong about vim or emacs not having code completion, that is just nonsense. I use (a version of) visual studio, the first thing that I did was installing a vim extension. Also vim itself already supports almost any of these features with some basic plugins for the completion logic. If I type "." in m…

Vim: I can do that too, I swear! Just configure some plugins, can’t tell you what they might be though. But I’m turing complete, and I’m the best!

VScode: Of course I can do autocomplete bud. Here, search my package repo, I’ll tell you which plug-ins are the most popular and handle the entire download and install process for you.

There’s no comparison.

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

#246

Post by dgan »

pipeline_peak wrote: post #140

Type systems cause programmers to write 300 classes no one references and many duplicates of each other. Dynamic typing allows you to focus on what really matters, not trivial business logic OOP hierarchies that get inevitably ignored. I feel like in app development, there’s something honest about dynamic typing. You’re focusing on the instance rather than the unnecessary model definition that again, nobody uses and…

Seems like you mix up classes, and types ... like many others in this thread

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

#247

Post by constantcrying »

Our_Benefactors wrote: post #245
constantcrying wrote: post #163

Earlier quoted context omitted.

Vim is not really an editor. It is a way to edit text, you can use vim in almost any environment. You are also totally wrong about vim or emacs not having code completion, that is just nonsense. I use (a version of) visual studio, the first thing that I did was installing a vim extension. Also vim itself already supports almost any of these features with some basic plugins for the completion logic. If I type "." in m…

Vim: I can do that too, I swear! Just configure some plugins, can’t tell you what they might be though. But I’m turing complete, and I’m the best! VScode: Of course I can do autocomplete bud. Here, search my package repo, I’ll tell you which plug-ins are the most popular and handle the entire download and install process for you. There’s no comparison.

Why do you even reply to a post that you didn't bother to read? VScode is a neovim frontend.

>There’s no comparison.

Read the first line of my post. There literally is no comparison, because there is a category error.

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

#248

Post by jjav »

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…

> If you have errors in your program, does it matter that much if those errors are caught during runtime or compile time?

Of course it matters. If an error can be caught by the compiler, it will never get to production. Big win.

With typeless languages like python the code will get to production unless you have 100% perfect test coverage (corollary: nobody has 100% perfect test coverage) and then some unexpected moment it'll blow up there causing an outage.

This happens with metronomic regularity at my current startup (python codebase), at least once a month. It is so frustrating that in this day and age we are still making such basic mistakes when superior technology exists and the benefits are well understood.

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

#249

Post by yellowapple »

> I want that data type to have helpful methods such as .Domain() or .NonAliasValue() which would return gmail.com and foo@gmail.com respectively for an input of foo+bar@gmail.com.

No the hell you don't.

Please please please do not attempt to separate the alias from an email address I submit. It's there for a reason - specifically, to hold you accountable if I experience a sudden influx of spam, and generally to keep things categorized in a world where senders can be sending things from all sorts of domains. Knowing that this is something one would even remotely consider is grounds to never touch anything one has built with a ten-foot pole, and I am now very strongly inclined to look into the author and compulsively scrub any accounts of mine from anything said author might've touched.

I am not exaggerating. The thing before the @ is meant to be opaque. Deeming otherwise for the sake of something so blatantly user-hostile as removing aliases is plain evil, and I will not sugarcoat my condemnation of such practices.

If you're sufficiently sociopathic to have no regard for the morality argument here, then at the very least take heed of RFC 5322 (https://datatracker.ietf.org/doc/html/rfc5322) and recognize that trying to parse any meaning from an email address' local-part is blatantly ignorant of IETF specifications and almost certainly will create bugs. Just don't do it - if not for your users' sake, then for your own.

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

#250

Post by hither_shores »

dgan wrote: post #246
pipeline_peak wrote: post #140

Type systems cause programmers to write 300 classes no one references and many duplicates of each other. Dynamic typing allows you to focus on what really matters, not trivial business logic OOP hierarchies that get inevitably ignored. I feel like in app development, there’s something honest about dynamic typing. You’re focusing on the instance rather than the unnecessary model definition that again, nobody uses and…

Seems like you mix up classes, and types ... like many others in this thread

Java and its consequences have been a disaster for the human race
Post reply on HN