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

Use Your Type System

dzombak.com

Post reply on HN
Print view View original

101–110 of 357 posts

Re: Use Your Type System

#101

Post by eyelidlessness »

MoreQARespect wrote: post #28
pclowes wrote: post #3

I like this. Very much falls into the "make bad state unrepresentable". The issues I see with this approach is when developers stop at this first level of type implementation. Everything is a type and nothing works well together, tons of types seem to be subtle permutations of each other, things get hard to reason about etc. In systems like that I would actually rather be writing a weakly typed dynamic language like…

I've recently been following red-green-refactor but instead of with a failing test, I tighten the screws on the type system to make a production-reported bug cause the type checker to fail before making it green by fixing the bug. I still follow TDD-with-a-test for all new features, all edge cases and all bugs that I can't trigger failure by changing the type system for. However, red-green-refactor-with-the-type-syst…

I found myself following a similar trajectory, without realizing that’s what I was doing. For a while it felt like I was bypassing the discipline of TDD that I’d previously found really valuable, until I realized that I was getting a lot of the test-first benefits before writing or running any code at all.

Now I just think of types as the test suite’s first line of defense. Other commenters who mention the power of types for documentation and refactoring aren’t wrong, but I think that’s because types are tests… and good tests, at almost any level, enable those same powers.

Re: Use Your Type System

#102

Post by viktorcode »

lolive wrote: post #82

Primitive object types in Java (String, Float, …) are final. That blocks you from doing such tricks, as far as I understand.

The idea is to just wrap them in a unique type per intended use case, like AccountID, SessionID, etc. and inside the may contain a single field with String.

Re: Use Your Type System

#103

Post by lock1 »

bcrosby95 wrote: post #63
abraxas wrote: post #37

An adjacent point is to use checked exceptions and to handle them appropriate to their type. I don't get why Java checked exceptions were so maligned. They saved me so many headaches on a project where I forced their use as I was the tech lead for it. Everyone hated me for a while because it forced them to deal with more than just the happy path but they loved it once they got in the rhythm of thinking about all the…

I think most complaints about checked exceptions in Java ultimately boil down to how verbose handling exceptions in Java is. Everytime the language forces you to handle an exception when you don't really need to makes you hate it a bit more. First, the library author cannot reasonably define what is and isn't a checked exception in their public API. That really is up to the decision of the client. This wouldn't be su…

If only Java also provided Either-like in the standard library...

Personally I use checked exceptions whenever I can't use Either and avoid unchecked like a plague.

Yeah, it's pretty sad Java language designer just completely deserted exception handling. I don't think there's any kind of improvement related to exceptions between Java 8 and 24.

Re: Use Your Type System

#104

Post by gpderetta »

jerf wrote: post #42

This technique makes me sad. Not because it's a bad idea. Quite the contrary. I've sung the praises of it myself. But because it's like the most basic way you can use a type system to prevent bugs. In both the sense used in the article, and in the sense that it is something you have to do to get the even more powerful tools brought to bear on the problem that type systems often. And yet, in the real world, I am const…

Code review time:

   + int doTheThing(bool,bool,int,int);
Die a little bit inside.

Re: Use Your Type System

#105

Post by eyelidlessness »

pclowes wrote: post #48
MoreQARespect wrote: post #28

Earlier quoted context omitted.

I've recently been following red-green-refactor but instead of with a failing test, I tighten the screws on the type system to make a production-reported bug cause the type checker to fail before making it green by fixing the bug. I still follow TDD-with-a-test for all new features, all edge cases and all bugs that I can't trigger failure by changing the type system for. However, red-green-refactor-with-the-type-syst…

I like this approach, there are often calls for increased testing on big systems and what they really mean is increased rigor. Don't waste time testing what you can move into the compiler. It is always great when something is so elegantly typed that I struggle to think of how to write a failing test. What drives me nuts is when there are testing left around basically testing the compiler that never were “red” then “g…

As you move more testing responsibilities to the compiler, it can be valuable to test the compiler’s responsibilities for those invariants though. Otherwise it can be very hard to notice when something previously guaranteed statically ceases to be.

Re: Use Your Type System

#106

Post by gpderetta »

mk_chan wrote: post #44

I’ve been using hacks to do this for a long time. I wish it was simpler in C++. I love C++ typing but hate the syntax and defaults. It’s so complicated to get started with. https://github.com/Mk-Chan/libchess/blob/master/internal/Met... https://github.com/Mk-Chan/libchess/blob/master/Square.h

But it can be a bit easier! You could make Square itself an enum class and overload the operators for it directly.

Re: Use Your Type System

#107

Post by nikeee »

josephg wrote: post #25
pclowes wrote: post #3

I like this. Very much falls into the "make bad state unrepresentable". The issues I see with this approach is when developers stop at this first level of type implementation. Everything is a type and nothing works well together, tons of types seem to be subtle permutations of each other, things get hard to reason about etc. In systems like that I would actually rather be writing a weakly typed dynamic language like…

Yep. For this reason, I wish more languages supported bound integers. Eg, rather than saying x: u32, I want to be able to use the type system to constrain x to the range of [0, 10). This would allow for some nice properties. It would also enable a bunch of small optimisations in our languages that we can't have today. Eg, I could make an integer that must fall within my array bounds. Then I don't need to do bounds ch…

I proposed a primitive for this in TypeScript a couple of years ago [1].

While I'm not entirely convinced myself whether it is worth the effort, it offers the ability to express "a number greater than 0". Using type narrowing and intersection types, open/closed intervals emerge naturally from that. Just check `if (a > 0 && a 0)&(I also built a simple playground that has a PoC implementation: https://nikeee.github.io/typescript-intervals/

[1]: https://github.com/microsoft/TypeScript/issues/43505

Re: Use Your Type System

#108

Post by henry700 »

lock1 wrote: post #93
munificent wrote: post #88

Earlier quoted context omitted.

> This is where the concept of “Correct by construction” comes in. This is one of the basic features of object-oriented programming that a lot of people tend to overlook these days in their repetitive rants about how horrible OOP is. One of the key things OO gives you is constructors . You can't get an instance of a class without having gone through a constructor that the class itself defines. That gives you a way to…

I find regular OOP language constructor are too restrictive. You can't return something like Result to handle the error gracefully or return a specific subtype; you need a static factory method to do something more than guaranteed successful construction w/o exception. Does this count as a missing language feature by requiring a "factory pattern" to achieve that?

The natural solution for this is a private constructor with public static factory methods, so that the user can only obtain an instance (or the error result) by calling the factory methods. Constructors need to be constrained to return an instance of the class, otherwise they would just be normal methods.

Convention in OOP languages is (un?)fortunately to just throw an exception though.

Re: Use Your Type System

#109

Post by scottgg »

josephg wrote: post #25
pclowes wrote: post #3

I like this. Very much falls into the "make bad state unrepresentable". The issues I see with this approach is when developers stop at this first level of type implementation. Everything is a type and nothing works well together, tons of types seem to be subtle permutations of each other, things get hard to reason about etc. In systems like that I would actually rather be writing a weakly typed dynamic language like…

Yep. For this reason, I wish more languages supported bound integers. Eg, rather than saying x: u32, I want to be able to use the type system to constrain x to the range of [0, 10). This would allow for some nice properties. It would also enable a bunch of small optimisations in our languages that we can't have today. Eg, I could make an integer that must fall within my array bounds. Then I don't need to do bounds ch…

The generic magic for this is called “dependant types” I believe - generics that can take values as well as types as parameters. Idris supports these
Post reply on HN