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

141–150 of 357 posts

Re: Use Your Type System

#141

Post by beders »

It is tempting, maybe a good first step, but often not expressive enough.

Especially and particularly attributes/fields/properties in an enterprise solution.

You want to associate various metadata - including at runtime - with a _value_ and use that as attribute/field/property in a container.

You want to be able to transport and combine these values in different ways, especially if your business domain is subject to many changes.

If you are tempted to use "classes" for this, you will sign up for significant pain later down the road.

Re: Use Your Type System

#142

Post by kwon-young »

This reminds me of the mp-units [1] library which aims to solve this problem focusing on the physical quantities. The use of strong quantities means that you can have both safety and complex conversion logic handled automatically, while having generic code not tied to single set of units.

I have tried to bring that to the prolog world [2] but I don't think my fellow prolog programmers are very receptive to the idea ^^.

[1] https://mpusz.github.io/mp-units/latest/

[2] https://github.com/kwon-young/units

Re: Use Your Type System

#143

Post by somethingsome »

I'm curious about what you think about something,

Supoose you make two simple types one for Kelvin K and the other for Fahrenheit F or degrees D.

And you implement the conversions between them in the types.

But then you have something like

d: D = 10;

For i=1...100000:

   k=f_Take_D_Return_K(d)
   d=g_Take_K_Return_D(k)
end

Then you will implicitly have many many automatic conversions that are not useful. How to handle this? Is it easily catched by the compiler when the functions are way more complex?

Re: Use Your Type System

#144

Post by ameliaquining »

kitten_mittens_ wrote: post #22
arrowsmith wrote: post #10

Earlier quoted context omitted.

FYI: Ruby is strongly typed, not loosely. > 1 + "1" (irb):1:in 'Integer#+': String can't be coerced into Integer (TypeError) from (irb):1:in ' ' from :168:in 'Kernel#loop' from /Users/george/.rvm/rubies/ruby-3.4.2/lib/ruby/gems/3.4.0/gems/irb-1.14.3/exe/irb:9:in ' ' from /Users/george/.rvm/rubies/ruby-3.4.2/bin/irb:25:in 'Kernel#load' from /Users/george/.rvm/rubies/ruby-3.4.2/bin/irb:25:in ' '

There seem to be two competing nomenclatures around strong/weak typing where people mean static/dynamic instead.

I recall a type theorist once defined the terms as follows (can't find the source): "A strongly typed language is one whose type system the speaker likes. A weakly typed language is one whose type system the speaker dislikes."

Related Stack Overflow post: https://stackoverflow.com/questions/2690544/what-is-the-diff...

So yeah I think we should just give up these terms as a bad job. If people mean "static" or "dynamic" then they can say that, those terms have basically agreed-upon meanings, and if they mean things like "the type system prohibits [specific runtime behavior]" or "the type system allows [specific kind of coercion]" then it's best to say those things explicitly with the details filled in.

Re: Use Your Type System

#145

Post by eyelidlessness »

MoreQARespect wrote: post #129
eyelidlessness wrote: post #101

Earlier quoted context omitted.

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 t…

I dont think tests and types are the same "thing" per se - they work vastly better in conjunction with each other than alone and are weirdly symmetrical in the way that theyre bad substitutes for each other. However, Im convinced that theyre both part of the same class of thing, and that "TDD" or red/green/refactor or whatever you call it works on that class, not specifically just on tests. Documentation is a funny o…

Types are a kind of test. Specifically they’re a way to assert certain characteristics about the interactions between different parts of the code. They’re frequently assertions you’d want to make another way, if you didn’t have the benefit of a compiler to run that set of assertions for you. And like all tests, they’re a means to gain or reinforce confidence in claims you could make about the code’s behavior. (Which is their symmetry with documentation.)

Re: Use Your Type System

#146

Post by [deleted] »

somethingsome wrote: post #143

I'm curious about what you think about something, Supoose you make two simple types one for Kelvin K and the other for Fahrenheit F or degrees D. And you implement the conversions between them in the types. But then you have something like d: D = 10; For i=1...100000: k=f_Take_D_Return_K(d) d=g_Take_K_Return_D(k) end Then you will implicitly have many many automatic conversions that are not useful. How to handle this…

[deleted]

Re: Use Your Type System

#147

Post by TuxSH »

gpderetta wrote: post #98
default-kramer wrote: post #65

Earlier quoted context omitted.

I've done something like that too. I also noticed that enums are even lower-friction (or were, back in 2014) if your IDs are integers, but I never put this pattern into real code because I figured it might be too confusing: https://softwareengineering.stackexchange.com/questions/3090...

FWIW, I extensively use strong enums in C++[1] for exactly this reason and they are a cheap simple way to add strongly typed ids. [1] enum class from C++11, classic enums have too many implicit conversions to be of any use.

> classic enums have too many implicit conversions

They're fairly useful still (and since C++11 you can specify their underlying type), you can use them as namespaced macro definitions

Re: Use Your Type System

#148

Post by TuxSH »

gpderetta wrote: post #98
default-kramer wrote: post #65

Earlier quoted context omitted.

I've done something like that too. I also noticed that enums are even lower-friction (or were, back in 2014) if your IDs are integers, but I never put this pattern into real code because I figured it might be too confusing: https://softwareengineering.stackexchange.com/questions/3090...

FWIW, I extensively use strong enums in C++[1] for exactly this reason and they are a cheap simple way to add strongly typed ids. [1] enum class from C++11, classic enums have too many implicit conversions to be of any use.

> classic enums have too many implicit conversions

They're fairly useful still (and since C++11 you can specify their underlying type), you can use them as namespaced macro definitions

Kinda hard to do "bitfield enums" with enum class

Re: Use Your Type System

#149

Post by munificent »

hombre_fatal wrote: post #118
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 don't see this having much to do with OOP vs FP but maybe the ease in which a language lets you create nominal types and functions that can nicely fail. What sucks about OOP is that it also holds your hand into antipatterns you don't necessarily want, like adding behavior to what you really just wanted to be a simple data type because a class is an obvious junk drawer to put things. And, like your example of a prob…

> Even in an OOP language you probably want `UUID.from(string): Maybe`, not `new UUID(string)` that throws.

One way to think about exceptions is that they are a pattern matching feature that privileges one arm of the sum type with regards to control flow and the type system (with both pros and cons to that choice). In that sense, every constructor is `UUID.from(string): MaybeWithThrownNone`.

Post reply on HN