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

171–180 of 467 posts

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

#171

Post by gary17the »

marcosdumay wrote: post #153
suzzer99 wrote: post #128

Earlier quoted context omitted.

It's weird to me how scanning the comments all seem to refer to systems with 100k-ish LoC and dozens of contributors. A big chunk of my job is writing node microservices in AWS Lambda. I do everything I can to avoid shared library code, since past experience tells me there be lots of dragons (mainly in when and how to push or pull lib updates to components). I have a very tiny shared lib that I try to never touch and…

> Unit tests are a breeze since I never have to cast objects or worry about generics Generics reduce the amount of things you must care about on your tests. And you shouldn't cast objects in almost no code ever. Most 100k LoC programs won't need it even once, your microservices should need it proportionally less. That's the thing. The gains grow superlineraly with the amount of code. They make it just a bit easier to…

> The gains [introduced by a strong type system] grow superlineraly with the amount of code.

That's a good way to put it.

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

#172

Post by Jach »

barbariangrunge wrote: post #85

The main benefit of static types is great refactoring tools

It's amusing that the first language with great refactoring tools had dynamic types (Smalltalk). But I think it's an underappreciated note that static type languages often create a bias for earlier coupling, less system-independent modularity, and a lot of unnecessary data copying from structure to structure, creating in turn a stronger need for refactoring tools since what should be small changes end up becoming larger ones affecting more places. Even though they can't catch everything (thanks to reflection) I'm pretty happy that such tools exist when doing Java development. I've sometimes missed them in less tooling-mature dynamic langs, but also have found them less necessary. (Though I'm sure part of that is due to other feature-factors, like closures, that historically have been a long time coming (if ever) to the most popular static langs.)

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

#173

Post by Izkata »

arwhatever wrote: post #90
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

Understanding existing code is a big benefit of static types as well. I’m sure one could argue that member names should obviate the need for type annotations. There’s also the distinct possibility that my preceding ~15 years of statically-typed software development have affected how I think about software development in some way. (wink) But I am finding type annotations internet useful while working on a huge applica…

> Understanding existing code is a big benefit of static types as well.

At a syntax level perhaps, but not necessarily at a semantic level. This won't apply to everyone, but I've noticed that the more types are relied on, the less my co-workers really understand the code. They're relying on the compiler so much they don't slow down and think through the changes they're making. In one extreme case I saw a guess-change-compile workflow that relied entirely on the compiler doing the work for them.

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

#174

Post by AnimalMuppet »

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

The tradeoff is that I have to explicitly say (and know) what type I'm dealing with at every point in the program.

But I'm not sure that's much of a tradeoff. If I don't know what type this thing is, how do I know what operations I can safely do on it? How do I know that I can make it do what I'm trying to do? Or will it blow up at runtime when I do that?

I consider "I coded it, it's done, but it might blow up at runtime" to be highly unprofessional. "We covered that with unit tests" is theoretically OK, if you've got 100% test coverage. But you don't, and you never will.

Having to say everywhere what the type is gets tedious. Autocomplete (and "auto", for those languages that have it) help a bit here, but only a bit.

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

#175

Post by hither_shores »

Barrin92 wrote: post #39

>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 this is a classic case of not needing more types but needing proper names . Types as concretions, i.e. simply collections of data or functions are a terrible idea because they're static and don't accrete. Data in the real world always does. This becomes very obvious whe…

> this is a classic case of not needing more types but needing proper names.

Those are types.

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

#176

Post by AnimalMuppet »

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…

Ahem. Not all email addresses have an @ in them. If you're sending an email to another user on the same machine, just their username is enough (at least for some mail implementations).

Note that this makes your overall point stronger, not weaker.

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

#177

Post by jdrek1 »

hgomersall wrote: post #138
mikewarot wrote: post #3

I once attended a meeting where a Professor from a University somewhere in Chicago gave a brilliant demonstration of using a similar type system for dealing with values in Electrical Engineering. It made quite sure you couldn't do things like add volts and amps. [Edit] it also handled things like parallel resistances, etc. It was in C++ if I recall correctly. This is a great idea, that I've haven't had cause to use y…

It's possible to go even further than just protecting against the wrong unit in the wrong place. You can generalise units: https://docs.rs/dimensioned/latest/dimensioned/ (Edit, that's not possible in c++)

> (Edit, that's not possible in c++)

Mind expanding on that? Because what that readme there shows is absolutely possible in C++, I have used a similar system for dealing with natural units.

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

#178

Post by Jach »

Ygg2 wrote: post #24
musingsole wrote: post #14

>A string value is not a great type to convey a user's email address or their country of origin. I can argue whatever type you use in place of a string will similarly be "not a great type". This can be argued in perpetuity because no type/map actually matches the reality it's encapsulating. Type systems require you to build a Pretty Good Theory of your problem space so that your types can overlap with reality/actual…

> I can argue whatever type you use in place of a string will similarly be "not a great type". All Types are wrong, but some are useful. Will Money type solve all problems? Is it better than decimal, from POV of prevention of mistakes - yes.

You have Money types? Lucky, I still see people using floats...

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

#179

Post by Izkata »

jstimpfle wrote: post #129
kajaktum wrote: post #80

Earlier quoted context omitted.

What? Would you rather have JSON as a string or as something like Map ? > No, if your idea of validating an email is more complicated than "should have an @ symbol" Then how is just using a string any better? Would you rather litter the entire codebase with validations that this is indeed a valid email or just do it once at the entry point? I think excessive type system hacks are bad too but they are more often than…

> What? Would you rather have JSON as a string or as something like Map ? This question can't be answered without additional context. What are the requirements? But as a heads up, Map couldn't be representation of all valid JSON documents. Lists are valid Json as well AFAIK. So I think this is making a point.

Based on the casing JsonValue is an object, not a primitive, so there's no reason that interface wouldn't work. It would just by a different subtype depending on what type the value is, and lists/dicts would also implement the Map interface.

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

#180

Post by noobermin »

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…

People are getting lost about your example as they don't see the analogy as it sounds like validation of input. The point is still there if people are willing to look past the confusion, that making a type hierarchy requires you clearly know upfront what different subsets of the data you deal with actually look like and this will change at different stages of the project. This is the reason people ditched c++ and java in 2000 and started hacking in python and js, at least at the beginning although things are shifting.

The thing is a lot of things are reversed here, the reality is the way evolution is more sensible is to "generalize" from the bottom up, unless you are very sure from the start that certain types categories make sense for your problem. That's how things should always be, you can only generalize once you've worked through a problem and realized certain aspects are actually common in someway and can be connected somehow, and thus you can take a subset of data you have in your program and organize it into a type. The thing is I feel like that is even harder than thinking top-down (which I feel like is where the pendulum is swinging now) because that takes time.

The reason top-downers still do their thing is they feel their method is better is selective thinking (sorry, I know this is harsh) because they honestly discount the anger and fury people from the outside have dealing with their code and they ignore the amount of refactoring they need to do when their designs break. In fact, they love the churn really or at least merely accept it as a "part of development."

Post reply on HN