Modern type systems have come a long way since C. They’re no longer just about pleasing the compiler. These days they form a sub-language that helps us express ideas about software clearly & succinctly. A true design language. So let’s take a look at how a modern type system supports talking about software. How it highlights problems, clarifies designs, and supports reuse. Most importantly, see how types can help you talk to your colleagues.
Very cool - thanks for pointing this out. I’ll give it a watch.
Thanks for the link!
Does anybody have an actual implementation example of something like the Db and DbRead phantom types (?) he used? My initial expectation would have been that it’s a separate parameter and not part of the result’s type.
Thats funny about the bad Java programmers. Sometimes I would do this just to see what reaction I would get from my colleagues:
public class SomeRecord {
public string id;
public string name;
public int age;
}
Shocker! Its entirely legal Java though, and I can’t help but think the languages designers made it so deliberately.
A very powerful thing you can do in Elm is to use types, opaqueness and smart constructors/builder patterns/ and decoders to enforce a domain model. In a small team the domain model might be part of the application codebase and editable by all.
In a big enterprise I can see a value in having a domain model that is maintained by a smaller group of programmers, and read only by most application developers. If we had private packages this would be versioned and published to some package cache running on the company domain. This could be used to enforce parse-dont-validate thinking and would eliminate a common source of errors entirely.
So I wonder, why are we not doing this? I see application code that is full of null checks, overly broad types, ways around the typing, or just bugs. Elm domain models on backend could really change all that, although it isn’t the only language that could.
this Java code wouldn’t do anything on its own, it’s missing a constructor ou another class that extends it. however, your coworkers might be super happy to learn that there is now a syntax for records:
record SomeRecord(String id, String name, int age) {}
var jane = new SomeRecord("1234", "Jane", 42);
I’m pretty sure it’s borrowing scala’s case classes more than ML’s records though.
Yes. I probably should have said that was Java code I might have teased my coworkers with about 15 years ago, way before records were added to Java. One of the reasons some people hated Java so much was that adding a simple field required also adding a getter and setter. No-one seemed to really know why it had to be done that way, mumble mumble something about “encapsulation”.
Sometimes people would even write getters or setters that were side effecting.
For some context, I have been working in Elm last 3 years, but recently started a new job doing solution design work. The teams I work with have Java and Typescript/JS code and a few other languages also - this is all backend business logic.
Once you have taken the red pill and start thinking like an Elm developer, its painful to look at code like this:
if measurement.unit === 'g' {
return measurement.value / 1000
}
return measurement.value
Yet in mainstream programming this is totally normal and acceptable.