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

151–160 of 468 posts

Re: Things I Was Wrong About: Types

#151

Post by edem »

aembleton wrote: post #121
aazaa wrote: post #95

> Type inference: because having to write out every type, however obvious, is an incredible waste of time. Person me = new Person(); is ridiculous. let me = new Person(); may seem like a small improvement, but spread over the body of an entire program and generalized to all sorts of contexts means that type annotations become a tool you employ because they’re useful — for communicating to others, or for constraining…

You might enjoy Kotlin. Type inference, with full compatibility with Java libraries and ecosystem. Similar to Rust, you can just write `val me = Person()`. No need for the new keyword.

I love Kotlin. I also love Typescript. I'm yet to try Rust, but I'm positive that I'll love it as well. They are all born to solve the same problem I think, only from a different perspective. I use Kotlin every day and the more I learn the happier I am. I'd never go back to Java if I can help it.

Re: Things I Was Wrong About: Types

#152

Post by tluyben2 »

kybernetikos wrote: post #143
tluyben2 wrote: post #100

Earlier quoted context omitted.

I am positive about a lot of these points for the future. Especially the performance points; that's going forward fast. But yes, that's often pretty slow; not that bothered by it for my work though. Also, linters work well for statically typed languages too; I usually don't have to compile for 100s of lines of code. If the editor does not complain, it'll probably all work fine. Like I said; do what works for you , bu…

> you cannot program without knowing what data you are getting Types almost always overconstrain. Each part of your code relies on some very specific properties of your data, yet most type systems end up restricting your function to only work with data that meets a whole bunch of other properties that your code doesn't actually care about.

> Types almost always overconstrain

Not in my experience; so many, basically, stringy types.

> Each part of your code relies on some very specific properties of your data,

So then you either have a type that exposes those you need or you have different types for different functions.

> yet most type systems end up restricting your function to only work

Again, I don't understand this statement; someone implemented the types to fit the data for some functions they needed. How does the 'type system restrict' anything?

Re: Things I Was Wrong About: Types

#153

Post by TooCreative »

jenscow wrote: post #115
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…

A better example for a typed function would be something like: function Request(string method, string url, RequestOptions options) : Result {...} or Result Request(string method, string url, RequestOptions options) {...} Here, we know `url` is a string (rather than the parsed object), we know all the supported options (they're members of the RequestOptions object/enum), and every value in the return value. Some might…

For the example I simply took to a random, recently updated file from Symfony:

https://github.com/symfony/http-client/blob/master/HttpClien...

And shortened it a bit. In the real example, as you can see, there are even more parameters, making it even harder to read.

Re: Things I Was Wrong About: Types

#154

Post by rswail »

dynamite-ready wrote: post #27

Types are useful, but they are currently trending, so now, they might often be forced into situations where they might not be needed. Programming languages and their type systems are tools, at the end of the day. Occasionally, an overwrought system of types will slow you down, or quite possibly make simple changes impossible. On another day, some other type declaration could save you hours of debugging, or speed up y…

The focus of industrial development for a long time has been focussed on the processes, or the verbs, not the things, or the nouns.

Focusing on the Nouns and the types of those Nouns lets you understand what states they can be in and more importantly, the ones they cannot be in. By using types as much as possible to express those invariants and constraints, you can make sure that the processes don't do something that they shouldn't.

Proving software correct is a very complicated and, as yet, unsolved in most practical cases. Strong typing and strong type systems are a step in that direction.

If a compiler ensures that a sum type's possible values are always exhaustively matched, then you can be sure that the processing at least considers all of the possible values.

That leads to positive results when programming.

If you use Option types and then ensure that the None type is handled, the possiblity of nulls is dramatically reduced, if not eliminated.

If immutability is enforced, that removes the possibility of inadvertent modification, especially somewhere deep in a call stack. That leads to safer concurrency, which is an absolute requirement for using the compute capacity to its fullest extent.

Strong typing like this isn't "overwrought", it's making sure that your code doesn't do something to a thing that it shouldn't do.

Re: Things I Was Wrong About: Types

#155

Post by TooCreative »

castwide wrote: post #94
TooCreative wrote: post #85

Earlier quoted context omitted.

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.

> You know it returns an array, but you don't know what the array contains. So you don't know how to use it. That's a limitation of your specific example, not type systems in general.

For the example I took a random line from Symfony and shortened it a bit:

https://github.com/symfony/http-client/blob/master/HttpClien...

You are free to link to some other example.

Re: Things I Was Wrong About: Types

#156

Post by rswail »

jondubois wrote: post #75
dynamite-ready wrote: post #27

Types are useful, but they are currently trending, so now, they might often be forced into situations where they might not be needed. Programming languages and their type systems are tools, at the end of the day. Occasionally, an overwrought system of types will slow you down, or quite possibly make simple changes impossible. On another day, some other type declaration could save you hours of debugging, or speed up y…

Type hype is real. It almost seems like job-creation propaganda at this stage. When I judge things, I look at practical outcomes; and the fact is that I produce better software with more features within the same timeframe if I use JavaScript rather than TypeScript and the product in both cases is equally robust. This has been true for me both independently and as part of a team. With JS, I can write more code and mor…

Sorry anecdata isn't data. You might be able to write more code in terms of LOC but you're also writing tests that a strongly typed system wouldn't need.

You don't know that your code is "equally robust". You don't know what sort of "drop in quality" you have because you're not using strong types.

You are making a judgement that isn't backed by anything other than intuition.

Re: Things I Was Wrong About: Types

#157

Post by Ar-Curunir »

TeMPOraL wrote: post #141
cconroy wrote: post #99

Earlier quoted context omitted.

"statically, strongly typed Lisp that still doesn't sacrifice its flexibility and expressive power" SML

... with sane (i.e. s-expression based) syntax. :). But I'll check out SML. That's Standard ML, right?

FWIW, SML is an old research-focused language that was the progenitor of Haskell and Ocaml and Rust, and not something to program in :)

Re: Things I Was Wrong About: Types

#158

Post by withinboredom »

I work on the big data side of Automattic, so I tend to work with PHP, Typescript/JavaScript, Python, and Scala, but I also work with C# for fun. When you work with and without types often, you realize that it doesn't matter. Types are great for expressing constraints on the code, but you can do the same thing with conventions in non-typed code.

IMHO, type-less provides some resiliency. If you write code for a "string" anything that satisfies "stringiness" will still run just fine. This lets you build types that "trick" the code you're calling, which can be useful sometimes. I think I've abused this capability less than 3 times, but more than once. Mostly it allowed me to significantly change behavior without rewriting huge chunks of core code. However, these were all proof of concepts. Don't get it twisted, working with no types is pretty annoying sometimes.

Types, on the other hand, are great for most things, but I do find they get in the way sometimes. It's annoying when you look at the code you're calling and see that it only uses `.x` on a type you pass it, but you have to completely build a type just to create a `.x` on the type you pass in. I once found a NullPointer bug in HDFS with a static type (very strange) and had to work around it doing exactly this. Anyway, I think I'd like Go's approach to interfaces.

Re: Things I Was Wrong About: Types

#159

Post by rswail »

A lot of people are making comments about how they can code "faster" without types.

But for the majority of the code we write, inital speed isn't that important. Understanding the code and maintaining it are orders of magnitude more important for any non-trivial code.

Types are not only a way for the compiler to understand your code and impose constraints. They're also your API to other programmers. When they see a sum type, they can understand its possible states. When they see a product type they can understand its possible values.

Understanding other people's code is at least half the job of a programmer, whether it's understanding a library or understanding code you have to maintain, or understanding your own code that you wrote 6 months ago.

Types help you do that.

Re: Things I Was Wrong About: Types

#160

Post by TooCreative »

tluyben2 wrote: post #91
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…

Got that, but was triggered by ‘algorithmic structure’; that sounds a tad ‘over the top’ when you then come with some basic web request. However, I would not call your example particularly well typed. Array is still basically untyped. When I talk about types I mean things like; Either AddGroup(string GroupName, User[]? users) In this case I know what I am getting and I know the users are already, when reaching the we…

And now instead of

    $body = Http::request('GET', 'https://example.com')['body'];
You have to do this?

    $body = Http::request(new Method('GET'), new URL('https://example.com'))->body;
And you have cuttered the global namespace with "Method", "URL" and "Option"?
Post reply on HN