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

301–310 of 467 posts

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

#301

Post by yakshaving_jgt »

hiAndrewQuinn wrote: post #71
cardanome wrote: post #52

Oh god, please just use primitive types. Don't make assumptions about things. Everyone thinks they are so smart validating emails, phone numbers, zip codes and all until their great design goes live and they discover that users in the real world do not follow their assumptions. I have seen that happen again and again. No, if your idea of validating an email is more complicated than "should have an @ symbol", I guaran…

My favorite "easy win" find from learning Haskell last year was just the `newtype` keyword, which basically just let you alias primitive types with zero runtime impact. `newtype Email = Email String` and `newtype Username = Username String` are just `String`s with guard rails.

You probably want smart constructors, as you probably don't want the possibility for a 10,000 character username to float through your system.

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

#302

Post by xigoi »

rowanG077 wrote: post #117
jstimpfle wrote: post #111

Earlier quoted context omitted.

> Would you rather litter the entire codebase with validations that this is indeed a valid email Why would you? Just use it. For most of parts of the program it's not relevant to the computation whether the string is a "valid email", whatever that means. It's a string.

"Just use it" is what lead to the big SQL injection fallout and even today we pay the price as not even a year ago thousands of crucial service were vulnerable via log4j because of the "Just Use It" mantra.

You don't avoid injection attacks by validation, but by escaping.

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

#303

Post by jjav »

deltasevennine wrote: post #285
jjav wrote: post #248

Earlier quoted context omitted.

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

That's fine. A type checker won't catch everything. Run time errors happen regardless. I find it unlikely that all the errors your code base is experiencing is the result of type errors. Something like c++. You get a runtime errors. You have no idea where it lives or what caused it. Your python code base delivers an error but a patch should trivial because python tells you what happened. Over time these errors should…

> A type checker won't catch everything.

That's a strawman, nobody has claimed a statically typed language will catch all possible errors.

It will however catch an important category of common errors at compile-time, thus preventing them from reaching production and blowing up there. Other types of logic error of course exist, in all languages.

> Something like c++. You get a runtime errors. You have no idea where it lives or what caused it.

I don't know what this means? You seem to be suggesting that code in a statically typed language cannot be debugged? Clearly that's not true. Debugging is in fact usually easier because you can rule out the type errors that can't happen.

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

#304

Post by sixstringtheory »

_dain_ wrote: post #287
plasticeagle wrote: post #255

Earlier quoted context omitted.

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…

>The result was a disaster. wtf? metres and centimetres are not different types! they are just different ways of writing same type: Length. radians and degrees are just ways of writing a dimensionless Angle quantity. you made the absolutely elementary mistake of conflating a physical quantity with the unit used to measure it, of course it was a disaster. >nothing sensible to infer when you, say, multiply an angle and…

I can see how it could cause problems if they weren’t using the type system correctly.

    typedef float cm;
    typedef float meter:
    cm a = 1;
    meter b = 1;
    if (a == b) {
        // launch rockets
    }
I’ve done something similar (not including rockets, don’t worry!) in Swift with its typealias feature. Thankfully there is a way to actually force compiler errors in such situations with something like https://github.com/pointfreeco/swift-tagged

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

#305

Post by za3faran »

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…

You shouldn't compare a Python web stack with a C++ web stack, as C++ and Python target very different use cases.

You can compare however with a Java or C# web stack, both of which offer a superior developer experience, as well as a superior production experience (monitoring, performance, package management, etc.).

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

#306

Post by kazinator »

> A string value is not a great type to convey a user's email address or their country of origin. These values deserve much richer and dedicated types. I want a data type called EmailAddress which cannot be null.

Sure, I'm on board: I also want an e-mail address type. Just not in your shit language in which something can be of type String, yet be null reference.

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

#307

Post by pencilguin »

deltasevennine wrote: post #150

Types got a bad wrap because of C++. There was a strange dichotomy between languages like python/javascript and C++. If type systems were so good why was it easier to program with javascript and python then with C++? People got confused and promoted dynamically typed languages as better. What many people didn't realize was that C++ was hard DESPITE the type system, not because of it. This was soon rectified with type…

The above, while carefully tailored to tickle HN biases, has no connection with reality.

Types are exactly equally as "traceable" in C++ as in Rust.

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

#308

Post by xigoi »

dividedbyzero wrote: post #186
cardanome wrote: post #52

Oh god, please just use primitive types. Don't make assumptions about things. Everyone thinks they are so smart validating emails, phone numbers, zip codes and all until their great design goes live and they discover that users in the real world do not follow their assumptions. I have seen that happen again and again. No, if your idea of validating an email is more complicated than "should have an @ symbol", I guaran…

> No, if your idea of validating an email is more complicated than "should have an @ symbol", I guarantee you, there is counter example that will mess you pretty system up. Requiring b2b users to use their @company.com email is common and some b2b customers actually expect to be able to configure that. Another simple case is stripping out any "+whatever" from gmail addresses and to flag that sort of thing for other e…

> Another simple case is stripping out any "+whatever" from gmail addresses and to flag that sort of thing for other eomains so support can verify it's not a case of someone creating 72 trial accounts.

trial1@mypersonaldomain

trial2@mypersonaldomain

trial3@mypersonaldomain

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

#309

Post by pencilguin »

GnarfGnarf wrote: post #294
pencilguin wrote: post #269

Earlier quoted context omitted.

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.

Classes can be OO. Or not OO. Makes no difference, at compile time.

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

#310

Post by za3faran »

deltasevennine wrote: post #265
gary17the wrote: post #203

Earlier quoted context omitted.

> So basically compile time type checking just makes some of the errors get caught earlier which is a slight benefit but not a KEY differentiator. Unfortunately, I have to completely disagree here, at least based on my experience. Shifting software error detection from runtime to compile time is absolutely paramount and, in the long run, worth any additional effort required to take advantage of a strong type system.…

Your argument makes no sense. I say the type checker is not the key differentiator then you say for python the key differentiator is the garbage collector. So that makes your statement contradictory. You think type checkers are important but you think python works because of garbage collection. Either way I'm not talking about the implementation of the language. I'm talking about the user interface. Why is one user i…

GC was one of the most important and relevant features (if not the most important) that allowed Java to penetrate, and eventually dominate the space where C++ used to be relevant in terms of middleware/business type applications. This detail matters a lot in this discussion. Then once that is taken as a given, you can compare different GC enabled languages based on other factors, such as type safety (or lack thereof in the case of python).
Post reply on HN