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

Things I Was Wrong About: Types

v5.chriskrycho.com

Post reply on HN
Print view View original

81–90 of 468 posts

Re: Things I Was Wrong About: Types

#81

Post by unrealhoang »

TooCreative wrote: post #79
tluyben2 wrote: post #22

Earlier quoted context omitted.

What are you working on though? What algorithmic structure?

Compare this: private static function request(?string $method, ?string $url, array $options): array { ... } To this: function request($method, $url, $options) { ... } I can grasp the latter much better. It immediately forms a structure in my head that I will remember while I read other parts of the code. To do the same with the former, I think my brain uses up twice the energy or more. And even then, I will not have…

Counter point: with the former, I know exactly how to use it: for item in request(“get”, “google.com”, []) { .... } Whereas if there’s no example for the latter, I’d have to read the code of that function (or sometime the code of the functions it called) to know how to use correctly.

Re: Things I Was Wrong About: Types

#82

Post by JackMorgan »

Types are controversial because we can't measure engineer productivity. Full stop. I see people on here arguing that they are faster one way or the other, yet we have absolutely no empirical evidence for such a claim. What makes it more complex is that "fighting with types" often takes one out of the flow in a different way than usual progamming challenges. Since it's unmeasurable, we cannot see the effect of productivity relative to team size, feature churn, product timeline, unit test discipline, etc.

For example, I'm completely convinced types add significant productivity increase to any team of more than two programmers. Likewise types are a net productivity improvement to software that has to be added to multiple times in a year. If it's a one-off write and throw away, or tiny team, it probably doesn't help as much. Also if it's a big team, but with highly siloed developers, likely doesn't add as much value. I think fighting with types FEELS slower than it is, like how dealing with a car that doesn't start immediately or a street with a lot of stop signs feels slower than just getting out and walking, despite the empirical evidence to the contrary.

However, these beliefs of mine are BACKED BY ZERO EVIDENCE. Just let that sink in. We all are arguing about a topic that inherently cannot be measured. We should be trying to tackle the measurement issue first, rather than just keep yelling about chocolate vs vanilla forever.

When all we have to go on is feelings, we get people arguing which is better: cars or bicycles, without any discussion or facts about top speed or total distance. The cyclist is always going to talk about wind in their hair feeling like they are going so fast, or how it slows them down to look for gas stations and just stand there pumping gas when they could be making progress pedaling. And to stretch the metaphor even further, there are plenty of environments when a sedan is slower than a mountain bike, and plenty where they are the same. I suspect all this is true with types, yet we have absolutely no way to know. For all we know, the "collective wisdom" of types might be exactly backwards, because basing engineering decisions on feelings rarely correlates to empirical results.

Re: Things I Was Wrong About: Types

#83

Post by asiachick »

loup-vaillant wrote: post #51
adnzzzzZ wrote: post #33

I don't really see most of my code being improved that much by types and I also see a lot of extra complexity that people in the sphere I am (indie games) have to deal with when using typed languages. It just doesn't seem worth it. When you have to spend a lot of time fighting your language, and handling numerous extra concepts that don't exist in an untyped language because they don't need to, it feels like the peop…

Statically typed languages (or at least the good ones) are disciplined so the programmer doesn't have to. If you can work reliably with dynamic typing, that means you are very disciplined about giving the right data to the right function, in exactly the right form. That you are very disciplined about tests, possibly including fairly stupid-looking unit tests (which aren't actually stupid, at least in a dynamic contex…

how many times have you not used bash/dos/pwsh scripts because it's not typed?

Maybe there's a place for both?

Re: Things I Was Wrong About: Types

#84

Post by jondubois »

alkonaut wrote: post #80
jondubois wrote: post #65

Earlier quoted context omitted.

I agree. I think the downside of static typing is that it encourages developers to pass around complex types between functions instead of simple types and I think this is a mistake. If you have the option between creating a function which accepts a string (e.g. ID) as argument or accepts an instance of type SomeType, it's better to pass a string because simple types such as strings are pass-by-value so it protects yo…

The correct thing is imho to pass an immutable SomeType or an interface that only exposes the parts of SomeType necessary for the calculation and doesn’t allow mutation of the object. Of course you don’t send around references to mutable objects and of course you only send to a function just what it needs - but that’s regardless of type system.

Sometimes this will be the best approach possible but adhering with this principle too strongly can overcomplicate the general design/architecture - It can give developers a green light to start passing around complex types all over the place and harms the separation of concerns principle.

In terms of modularity and testability, the ideal architecture is when components communicate with each other in the simplest language (interface) possible. Otherwise you become too reliant on mocks during testing (which add brittleness and require more frequent test updates). I think very often, static typing can cause developers to become distracted from what is truly important; architecture and design philosophy. I think this is the core idea that Alan Kay (one of the inventors of OOP) has been trying to get across.

'I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging"' - Alan Kay

It's very clear from Alan Kay's writings that when he was talking about 'messaging' he was talking about communication between components and he did not intend for objects to be used in the place of messages.

Re: Things I Was Wrong About: Types

#85

Post by TooCreative »

unrealhoang wrote: post #81
TooCreative wrote: post #79

Earlier quoted context omitted.

Compare this: private static function request(?string $method, ?string $url, array $options): array { ... } To this: function request($method, $url, $options) { ... } I can grasp the latter much better. It immediately forms a structure in my head that I will remember while I read other parts of the code. To do the same with the former, I think my brain uses up twice the energy or more. And even then, I will not have…

Counter point: with the former, I know exactly how to use it: for item in request(“get”, “google.com”, []) { .... } Whereas if there’s no example for the latter, I’d have to read the code of that function (or sometime the code of the functions it called) to know how to use correctly.

Wishful thinking.

You know it returns an array, but you don't know what the array contains. So you don't know how to use it.

You still need to look into the code to see what it returns. Then you will see that it returns an array and what the array contains.

And now you had to process the information that it returns an array twice. Once in the function definition and once in the function body.

Re: Things I Was Wrong About: Types

#86

Post by asiachick »

haileys wrote: post #6

An interesting insight I came across a little while ago is that for mainstream, industrial languages, this way of thinking about types is relatively new. It's not that we're seeing the pendulum swing back to types, it's that we're discovering them for the first time! In earlier typed languages, the types weren't there for reasons of soundness or productivity at all. The types were there for the compiler alone, as the…

I feel like new features of popular typed languages have also helped them catch up to dynamic language it terms of ease of use. Go back before C++11, without "auto" writing generic code sucked! Callbacks without lambda closures also sucked. I'm sure someone will point to some 40 yr old language that had this but those languages weren't popular for whatever reason. var got added to C# in 2007 and it took more releases to let it be used in more places. Apparently added to Java much later.

I'm sure someone will give me a good example but for example std::sort in C++ before closures in C++, if you want to sort one array by another, for example you have an array of indices and an array of values and you want to sort the indices by the values, before closures I'd argue this was fairly painful unless you resorted to global variables or copying all of the data into some intermediate format. You'd end up having to write or generate a class with a sort function solely for the purpose of being able to pass in a member function to sort that could access the values. Today it's trivial because you can write a lambda that closes over the values and pass the indices into sort.

Re: Things I Was Wrong About: Types

#87

Post by Aeolun »

asiachick wrote: post #83
loup-vaillant wrote: post #51

Earlier quoted context omitted.

Statically typed languages (or at least the good ones) are disciplined so the programmer doesn't have to. If you can work reliably with dynamic typing, that means you are very disciplined about giving the right data to the right function, in exactly the right form. That you are very disciplined about tests, possibly including fairly stupid-looking unit tests (which aren't actually stupid, at least in a dynamic contex…

how many times have you not used bash/dos/pwsh scripts because it's not typed? Maybe there's a place for both?

Javascript is for scripts that fit in one file. Anything else is typescripy.

Re: Things I Was Wrong About: Types

#89

Post by viraptor »

TooCreative wrote: post #79
tluyben2 wrote: post #22

Earlier quoted context omitted.

What are you working on though? What algorithmic structure?

Compare this: private static function request(?string $method, ?string $url, array $options): array { ... } To this: function request($method, $url, $options) { ... } I can grasp the latter much better. It immediately forms a structure in my head that I will remember while I read other parts of the code. To do the same with the former, I think my brain uses up twice the energy or more. And even then, I will not have…

You're showing an example of a function signature in a specific language, not an example of typing though. These are related but not exactly the same.

For example here is a Ruby version, very dynamic:

    def request(method, url, **options)
    end
    request("get", "http...", foo: "bar")
And here is a completely statically typed Crystal version:

    def request(method, url, **options)
    end
    request("get", "http...", foo: "bar")
The argument types are inferred automatically from the usage and mismatched usage will be caught at compile time. And in the second case the ide can still tell you the types in the signature if you want to know them.

In the third example, here's completely dynamic python:

    def request(method: str, url: str, **options): Dict[...]
No type checking happens here in the language itself.

So what I'm getting at is - if you don't like languages with verbose explicit type signatures, it doesn't mean you don't like static types.

Re: Things I Was Wrong About: Types

#90

Post by nlitened »

cel1ne wrote: post #37

Types are important and necessary. Can you skip them in a typed language? Yes, just use any, Object or whatever the equivalent. Can you add them to an untyped language? No. They are not needed anywhere. But I argue that especially JavaScript module-systems would have benefited greatly from them. A million lost hours in fixing obscure "undefined is not a function"-errors from output of highly dynamic pluggable build/t…

JavaScript is not untyped, it’s dynamically typed. The types are still there, they are just not enforced at compile time.
Post reply on HN