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

261–270 of 468 posts

Re: Things I Was Wrong About: Types

#261

Post by 6gvONxR4sf7o »

bo1024 wrote: post #199
skohan wrote: post #187

Earlier quoted context omitted.

> Understanding other people's code is at least half the job of a programmer This was one of the pain-points when I was working more with node.js: the function signature told you nothing - like whether the function would even return or not would sometimes be a mystery. In very, very short scripts you can get away without types (like in a notebook for example), but once a project starts to get even medium size the tin…

This kills me about python. So many times I cannot figure out what exactly a functions expects and what it returns, sometimes even from reading the documentation! Matplotlib is especially bad.

kwargs makes me so angry in docs. Pass in anything! Learn the whole library to use this function!

Re: Things I Was Wrong About: Types

#262

Post by edem »

deckard1 wrote: post #209

I see a lot of comments on HN the last few years that just assume the dynamic vs static debate was settled at some time. It never ended. Static typing merely became trendy because dynamic typing was the trend for many years (Ruby, PHP, Python, Perl, JavaScript). Like all fashion, things that are trendy will once again become untrendy, and the cycle repeats. With that said, it's important to note that type inference i…

I don't have to look at my static code to know that it is doing the wrong thing. The compiler tells me. This is impossible with dynamic languages. It is obvious that you never used types otherwise you wouldn't have come up with this nonsense.

Re: Things I Was Wrong About: Types

#263

Post by Gibbon1 »

creata wrote: post #226
deckard1 wrote: post #209

I see a lot of comments on HN the last few years that just assume the dynamic vs static debate was settled at some time. It never ended. Static typing merely became trendy because dynamic typing was the trend for many years (Ruby, PHP, Python, Perl, JavaScript). Like all fashion, things that are trendy will once again become untrendy, and the cycle repeats. With that said, it's important to note that type inference i…

> Without the annotations, you can't look at code and know what is going on. In Rust, type inference is only inside the function, which I think gets you the best of both worlds. > In addition to that, you get the pain in the ass of having the compiler always complaining. This has stopped so many dumb errors of mine. My types aren't complex enough to guarantee that my program is correct , but they're complex enough to…

My experience learning Perl and Python after C/C++ and C# was okay I really get the obsession with unit tests now.

One thing notable in C you usually don't have to type the type name twice. But C++/Java/C# you do. That's when I think about it was a really bad grammar mistake. Java and C# shouldn't have propagated it.

Mentioned above I agree with, designing good types is non trivial. I think that's part of the problem that designing good API's is non trivial. I can see programmers getting the hate on when dealing with code bases with crappy types and crappy API's.

Re: Things I Was Wrong About: Types

#264

Post by throwaway894345 »

mettamage wrote: post #257
throwaway894345 wrote: post #138

Earlier quoted context omitted.

I've often felt that some people dislike types because they expect to be able to write code in a certain way that they know will make some very narrow happy path work now and they get really frustrated when the compiler tells them that there are other paths in the code that don't work. "Why is this stupid compiler slowing me down?!". This frustration betrays the programmer's indifference toward the broader quality of…

Yea, I agree and for this reason when I teach type systems to new programming students, I tell them that a type is somewhat analogous to a building material. You have brick, wood, steel and iron. You want to build a house that has solid bedrock and has easy forest fires in the area. What material would you use? Most would say rock. Then I tell them about strings and ints. You can represent 66 both with strings and in…

I don’t know if this is pedagogically useful, but I think of types as shapes, variables (including struct fields and function parameters) as a shaped hole, and values as a shaped thing that can fit (or not fit) into those holes. Kind of like the children’s toy. You don’t want to pass a circle in to a function that needs a square shaped thing, and the type system helps make sure you don’t do that by accident.

Re: Things I Was Wrong About: Types

#265

Post by chriskrycho »

wutbrodo wrote: post #193
steveklabnik wrote: post #134

Earlier quoted context omitted.

I can't speak for Chris, but I can speak for myself. I did the bulk of my early programming in statically typed languages. Specifically, late 90s C, C++, and Java. Then I found Perl, and pretty much went into dynamically typed languages only for the next near-decade. At the time, I felt like the types didn't pull their weight. There was a lot of extra writing, and you got very little benefit for it. Plus, dynamically…

> Plus, dynamically typed languages had these rich features that just weren't really accessible in mainstream statically typed languages, and so they kind of became associated with each other in my brain even if that wasn't specifically true. This resonates a lot with me (though as you say, isn't really a typing thing). I work on ML systems for autonomous vehicles, so I switch between Python and C++, and I definitely…

For what it’s worth, a significant part of my not seeing the value of types back in the early 2010s was the combination of my own immaturity with the pretty poor quality of the systems I was working with. You can make C++ do a lot of this work for you (albeit not quite as far as a language influenced by Standard ML). But none of the C++ I ever encountered in the wild in that era did. It was all the effort with none of the benefit. I spent many, many months of my life dealing with the exact same kinds of bugs in Fortran, C, and C++ systems that I was dealing with in PHP and JS and Python. So the feeling that resulted was: why do the extra work I have to do in Fortran and C and C++ if it’s not actually buying me anything? No doubt if I’d been working on teams which were effectively leveraging C++’s type system, I might have felt differently. But I wasn’t, so I didn’t.

For what it’s worth, these days I tend to talk almost exclusively in terms of the tradeoffs involved with adopting any given type system vs. the alternatives in the space. Even as an admittedly huge Rust fanboy,[1] I don’t think it’s a panacea or a thing you should pick for every project. To the contrary. And I’d go so far as to say that there are some places where something like Erlang is going to help you solve your specific problems more robustly than Rust will, which likely sounds like heresy to many fellow fans of type systems.

[1]: https://newrustacean.com

Re: Things I Was Wrong About: Types

#266

Post by dboreham »

Honestly I think people who object to typing are lazy and inconsiderate to other people who will need to read use and maintain their code. They often haven't had much experience and haven't worked on large code bases in my experience.

Re: Things I Was Wrong About: Types

#267

Post by codygman »

> 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 your code from unpredictable mutations

What if you work in a language where SomeType is pass-by-value?

Would you still prefer the string?

Re: Things I Was Wrong About: Types

#268

Post by szatkus »

hn_throwaway_99 wrote: post #169

I'll add a 4th thing to his list based on my experience moving from Java to Typescript: Nominally -based type systems like Java (where you can only write Foo f = new Bar() if Bar has Foo somewhere up it's static type chain or interface hierarchy) are way more of a pain in the ass than structurally -based type systems like TypeScript (where you can say f: Foo = new Bar() as long as TypeScript determines Bar has all th…

In the end when properties are missing I usually use an interface and click "Implement all missing fields and methods" anyway. Modern Java would be good enough for solving this problem.

I could agree that error message with information which properties are missing would be helpful is some circumstances.

Re: Things I Was Wrong About: Types

#269

Post by codygman »

jgilias wrote: post #19

I once told a JavaScript guru colleague of mine that I was spending my free time dabbling in Haskell. His response was 'lol, why would you do that?'. His point was that spending time learning things that you're not going to be using directly any time soon is a waste of time. My point was (and still is), that learning such things opens up a completely new way of thinking about problems and potential solutions.

> I was spending my free time dabbling in Haskell. His response was 'lol, why would you do that?'. His point was that spending time learning things that you're not going to be using directly any time soon is a waste of time.

Just as an anecdote, if you are persistent enough you can learn Haskell and get a job writing it :)

Re: Things I Was Wrong About: Types

#270

Post by ir123 »

rogerkirkness wrote: post #195

Rewriting our app from Node to Go reduced cloud spend by 20x, did not increase dev time, made it much easier to read and grow the project past 5k lines. Literally no downside. If your database is typed on the bottom, and your documentation is typed on the top, you have a type sandwich in every non-script application. Might as well be consistent.

Can you elaborate on how you reduced the cloud spend? Was it the CPU usage?
Post reply on HN