Live data from Hacker News

Use Your Type System

dzombak.com

191–200 of 357 posts

Re: Use Your Type System

#191

Earlier quoted context omitted.

I interpret your question as «given that I am doing many conversions between temperature, because that makes it easier to write correct code, then I worry that my code will be slow because I am doing many conversions». My response is: these conversions are unlikely to be the slow step in your code, don’t worry about it. I do agree though, that it would be nice if the compiler could simplify the math to remove the con…

That's exactly the problem, in the software I have in mind, the conversions are actually very slow, and I can't easily change the content of the functions that process the data, they are very mathematical, it would take much time to rewrite everything. For example, it's not my case but it's like having to convert between two image representations (matrix multiply each pixel) every time. I'm scared that this kind of '…

Why would it be difficult to monitor the slowness? Wouldn’t a million function calls to the from_F_to_K function be very noticeable when profiling?

On your case about swapping between image representations: let’s say you’re doing a FFT to transform between real and reciprocal representations of an image - you probably have to do that transformation in order to do the the work you need doing on reciprocal space. There’s no getting around it. Or am I misunderstanding?

Please don’t take my response as criticism, I’m genuinely interested here, and enjoying the discussion.

Re: Use Your Type System

#193

Im on the opposite extreme here in that I believe typing obsession is the root of much of our problems as an industry. I think Rich Hickey was completely right, this is all information and we just need to get better at managing information like we are supposed to. The downside of this approach is that these systems are tremendously brittle as changing requirements make you comfort your original data model to fit the…

A lot of us programmer folk are indefinitely in search of that one thing that will finally let us write the perfect, bug-free, high performance software. We take these concepts to the extreme and convince ourselves that it will absolutely work as long as we strictly do it the Right Way and only the Right Way. Then we try to convince to our fellow programmers that the Right Way will solve all of our problems and that it is the Only Way. It will be great, it will be grand, it will be amazing.

Re: Use Your Type System

#194
This can solve a lot of problems, but also introduce awkward situations where it is hard to make a square shape or panel because the width measure must first be converted explicitly into a height measure in order to be used as such which might be considered correct but also expensively awkward and pedantic.

Re: Use Your Type System

#196
post #152

Earlier quoted context omitted.

Haskell has this, it's called newtype. In OOP languages as long as the type you want to specialize isn't final you can just create a subclass. It's cheap (no additional wrappers or boxes), easy, and you can specialize behavior if you want to. Unfortunately for various good reasons Java makes String final, and String is one of the most useful types to specialize on.

But then you are representing two distinct types as the same underlying type, String. MyType extends String; void foo(String s); foo(new MyType()); // is valid Leading to the original problem. I don't want to represent MyType as a String because it's not.

It has to work that way or else you can't use the standard library. What you want to block is not:

    StringUtils.trim(String foo);
but

    myApp.doSomething(AnotherMyType amt);
The latter is saying "I need not any string but a specific kind of string".

Re: Use Your Type System

#197

Earlier quoted context omitted.

That's exactly the problem, in the software I have in mind, the conversions are actually very slow, and I can't easily change the content of the functions that process the data, they are very mathematical, it would take much time to rewrite everything. For example, it's not my case but it's like having to convert between two image representations (matrix multiply each pixel) every time. I'm scared that this kind of '…

Why would it be difficult to monitor the slowness? Wouldn’t a million function calls to the from_F_to_K function be very noticeable when profiling? On your case about swapping between image representations: let’s say you’re doing a FFT to transform between real and reciprocal representations of an image - you probably have to do that transformation in order to do the the work you need doing on reciprocal space. There…

I have many functions written by many scientists in a unique software over many years, some expect a data format the others another, it's not always the same function that is called, but all the functions could have been written using a unique data format. However, they chose the data format when writing the functions based on the application at hand at that moment and the possible acceleration of their algorithms with the selected data structure.

When I tried to refactor using types, this kind of problems became obvious. And forced more conversions than intended.

So I'm really curious because, a part from rewriting everything, I don't see how to avoid this problem. It's more natural for some applications to have the data format 1 and for others the data format 2. And forcing one over the other would make the application slow.

The problem arises only in 'hybrid' pipelines when new scientist need to use some existing functions some of them in the first data format, and the others in the other.

As a simple example, you can write rotations in a software in many ways, some will use matrix multiply, some Euler angles, some quaternions, some geometric algebra. It depends on the application at hand which one works the best as it maps better with the mental model of the current application. For example geometric algebra is way better to think about a problem, but sometimes Euler angles are output from a physical sensor. So some scientists will use the first, and the others the second. (of course, those kind of conversions are quite trivial and we don't care that much, but suppose each conversion is very expensive for one reason or another)

I didn't find it a criticism :)

Re: Use Your Type System

#198

    > In any nontrivial codebase, this inevitably leads to bugs when, for example, a string representing a user ID gets used as an account ID
Inevitably is a strong word. I can't recall the last time I've seen such bug in the wild.

    > or when a critical function accepts three integer arguments and someone mixes up the correct order when calling it.
Positional arguments suck and we should rely on named/keyword arguments?

I understand the line of reasoning here, but the examples are bad. Those aren't good reasons to introduce new types. If you follow this advice, you'll end up with an insufferable codebase where 80% LoC is type casting.

Types are like database schemas. You should spend a lot of time thinking about semantics, not simply introduce new types because you want to avoid (hypothetical) programmer errors.

"It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures."

Re: Use Your Type System

#199
post #93

Earlier quoted context omitted.

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.

In languages with generic types such as C++, you generally need free factory functions rather than static member functions so that type deduction can work.

Re: Use Your Type System

#200
post #103

Earlier quoted context omitted.

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.

Ok please help me understand, what is the difference between - R method() throws L, and - Either method() To me they seem completely isomorphic?

There is a major difference at the call site.

try/catch has significantly more complex call sites because it affects control flow.

Post reply on HN