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

291–300 of 467 posts

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

#291

Post by maxbond »

abraxas wrote: post #225

I'm learning Python after 35 years of working with statically typed languages (Pascal, C++, Java, a bit of Typescript lately) and by god this is hard. Not because there is anything in the language that I don't understand but the lack of any type info is killing me. I just can't build up a rhythm of coding. I feel like every five lines I have to sprinkle in print() statements to keep track of the data transformations…

I've moved from Python to a static language and it's made programming enjoyable again. I'd forgotten that that was possible. It's much more productive as well. Using Python as a production application language is like playing operation. For me what I really detest is ambient, untyped (in the sense that they aren't declared in the function definition) exceptions. Exceptions can just happen on any line, and there's no way to know what exceptions a function will raise. So you have to dig into the source code of your dependencies and such, it's a tremendous waste of time and you still get unanticipated exceptions in production.

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

#292

Post by tialaramex »

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…

> (Yes, Rust 4ev3r! ;))

Rust has a perfectly nice type system by modern standards, but it's nowhere close to showing you just how deep the rabbit hole goes when it comes to avoiding bugs at runtime by having stronger type systems.

For example suppose my Rust function takes a slice of clowns (named unimaginatively "clowns") and also a usize integer k. Can we write clowns[k] ? Rust says sure, it will emit a runtime bounds check to confirm that k is inside the bounds of the slice. If there are sixteen clowns, and we ask for k = 20, this Rust code will panic at runtime.

But we can do better, if we are willing to pay for it. Dependent Types. In a language with dependent types and enough inference our type inference system will conclude that k can be 20 here, thus clowns must be a slice of at least 21 clowns, but this slice has only sixteen clowns - type error during compilation, either k or clowns are wrong.

Now, for cases where bounds checking would be the reasonable thing to do, Dependent Types just result in you writing bounds checks, ie in this case checking k But in cases where bounds checks were not the only sensible approach, or maybe you didn't even realise a bounds check would be emitted because you assumed it was statically correct - this can catch some bugs at compile time which would otherwise survive into a running program, "Shifting left" is I believe the usual phrase to describe this improvement.

If you thought the function is obviously correct, "Of course there are more than k clowns" but it isn't, the type error may cause you to take that extra moment to think about it. "Wait, why can there be fewer clowns than... oh, I didn't mean clowns here, this should say circus_performers. I'm not even using the right slice!".

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

#293

Post by constantcrying »

Our_Benefactors wrote: post #256
constantcrying wrote: post #247

Earlier quoted context omitted.

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.

> Why do you even reply to a post that you didn't bother to read? VScode is a neovim frontend. I did read your post Mr. snark. > There literally is no comparison, because there is a category error. Pure pedantry. VScode takes far less effort to get a high quality feature set when compared to vim. That’s the only point of debate that matters for most people.

No post body was provided.

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

#294

Post by GnarfGnarf »

pencilguin wrote: post #269
snickerer wrote: post #262

I summarize the article as "use OOP and design your classes well".

Has absolutely nothing whatever to do with OOP. OOP, where it means anything at all, involves runtime selection of operations according to types organized in hierarchies. TFA is about compile-time type compatibility enforcement.

Au contraire, types can be implemented with OO classes and operator overloading. Errors caught at compile time.

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

#295

Post by idontpost »

acchow wrote: post #222
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…

You say “prefix 20” but there was this weird trend in the early-mid 2000’s where Ruby evangelists really believed that TDD is just as good as static types - even better because you’re forced to test actual business logic! And they even managed to convince masses of programmers that this is true! Glad that’s over.

No post body was provided.

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

#296

Post by sixstringtheory »

plasticeagle wrote: post #255
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

For a while in the codebase I was working on, we had a set of distinct types for different units. You know, a type for meters, another for centimetres, etc etc. We had types for radians, types for degrees. We had conversion functions between them, and type inference when you performed certain operations. The result was a disaster. Not an enormous disaster, but enough of a problem to rip the entire thing out and repla…

I would rather have dependency problems-which are able to be automated with sufficient tooling-than working in a codebase written by someone that thought you could just use floats and strings for everything in an extremely overloaded fashion. Doubly so if they don’t believe in documenting all the separate use cases and just keep all that knowledge in their head.

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

#297

Post by maxbond »

_dain_ wrote: post #290
abraxas wrote: post #225

I'm learning Python after 35 years of working with statically typed languages (Pascal, C++, Java, a bit of Typescript lately) and by god this is hard. Not because there is anything in the language that I don't understand but the lack of any type info is killing me. I just can't build up a rhythm of coding. I feel like every five lines I have to sprinkle in print() statements to keep track of the data transformations…

use mypy? it can enforce the type hints.

MyPy is awesome and will make you a more productive programmer and will make your application more robust. But I agree that Python types are "weak ass". It's not a particularly ergonomic type system to use, and it's more difficult to express complex types than is worth it for the sometimes questionable benefit.

3.10 does add unions using | which is nice, and I expect the type system will get better, but I share these frustrations.

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

#298

Post by kinkrtyavimoodh »

yellowapple wrote: post #249

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

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

I am sorry but this makes no sense. You do realize that the only reason you are able to use aliases is because your email provider chooses to parse meaning out of the supposedly "opaque" text right? If your email provider is free to "break" the spec, so are people you give your id to.

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

#299

Post by xigoi »

GnarfGnarf wrote: post #281

100% agree. I love C++ for allowing me to do things like: CInches in1, in2, in3; // basically just floating points CCm cm1; // basically just floating points in1 = in2 + in3; // no compilation error in1 = in2 + cm1; // compilation error in1 = in2 * in3; // compilation error in1 = 2. * in2; // no compilation error float foo(CInches *); foo(cm1); // compilation error Obviously there's a lot of code behind "CInches", bu…

> Which other languages also support this?

Haskell and related languages have distinct types; so does Nim. But even if there's no direct language support, you can always emulate them by having a compound type (record, struct, class, whatever you call it) with one field.

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

#300

Post by yellowapple »

Our_Benefactors wrote: post #273
yellowapple wrote: post #267

Earlier quoted context omitted.

Visual Studio: Of course I can autocomplete! Hold my beer while I bring your machine with 16 cores and 64GB of RAM to its knees for multiple minutes ;)

This is just false. Does it have a higher memory/cpu footprint than vim? Sure. But VScode is plenty performant. Edit: vscode != visual studio. I’ll leave my comment.

VSCode != Visual Studio

EDIT: I'd also hardly call VSCode "performant", either, at least compared to the multitudes of editors that don't pull in a full-on browser engine for basic text rendering... but yes, it is indeed "performant" relative to Visual Studio.

Post reply on HN