[deleted]
Don't Be Afraid of Types
161–170 of 233 posts
Re: Don't Be Afraid of Types
#162People might be afraid of types because in OOP land there's the idea that types aren't mere containers for data. You have to use encapsulation, inheritance and polymorphism. Fields and properties shouldn't have public setters. You assign a value only through a method, otherwise you make the gods angry. You have gazillions of constructors, static, public, protected, private and internal. And you have gazillions of met…
> Imagine we have immutable records that hold just data and static classes as function containers, and those functions just act on the records, return some new ones and change no state
Or imagine those functions are part of the immutable record and create new instances. The aspect of (im)mutability is orthogonal to where you place your logic. In the context of domain models, if the logic is an inherent part of the type and its domain, then there are good reasons to model the logic as part of the type, and those have nothing to do with Java or the typical OOP dogma (Rust chrono: `let age = today.years_since(birthday)` - Yes, you could argue that the logic is part of the trait implementation, but the struct's data is still encapsulated and correct usage of the type is enforced. There is only one way to achieve this in Java.)
Re: Don't Be Afraid of Types
#163Earlier quoted context omitted.
I don't think this is what lasagna means. Lasagna is when you have your software organized in layers. In other words instead of having a big ball of mud where A calls B calls C calls A calls C calls B you have layers (like in lasagna) so that A calls B calls C and you keep your code base so that classes/modules/types that are in the lower layer do not depend on or know of the anything above them and the dependencies…
Not trying to be funny, but "Ravioli code" might be closer: https://stackoverflow.com/questions/2052017/ravioli-code-why... https://en.wikipedia.org/wiki/Spaghetti_code#Ravioli_code A related principle that I don't think is talked about enough is "locality": I'd rather have all the code about one feature in one file or close together, rather than it strewn across files where it's harder to read and understand as a wh…
I love that there's a serious debate about which pasta shape is the best metaphor for particular software engineering patterns!
Re: Don't Be Afraid of Types
#164Also known as primitive obsession
Re: Don't Be Afraid of Types
#165Earlier quoted context omitted.
Your profile says "just another C hacker". I learned C from reading K&R in the late 80s. Every C compiler I've worked with could output the code as assembler, so C is really a thin layer of abstraction that wraps assembler. Having programmed in pure assembler before, I understand the benefits of C's abstractions, which began with its minimal, but helpful, type system. Should I not be taking you seriously? We are not…
Sorry man, I was just trying to spew some harmless banter.
Apology accepted. No worries.
It's just that my post rate is severely limited, even to reply to people replying to me.
I'm on some kind of naughty list in "the algorithm", which is something beyond dang's control, by what I gather from his reproachments to me.
That's why I've got to minimize my number of replies.
And 'harmless banter' doesn't communicate in pure text, friend.
Peace be with you.
Re: Don't Be Afraid of Types
#166Earlier quoted context omitted.
But once you get down to the unit data values inside any of those aggregates, you're still dealing with either characters, ints, floats, strings, arrays, and they each have their own individual access patterns and, more importantly, modification functions. You can't add a number to a string, only to another number. If you are dealing with a float, you better be careful how you check it for equality. If it's pure bina…
> You can't add a number to a string, only to another number. Works in C, as long as the integer keeps the resulting pointer within the bounds of the allocation. See a trivial example[1]. [1] https://godbolt.org/z/YWKK1P7zj
Ok, sure. But I doubt that's a good practice. In fact, I can't possibly imagine it not being a horrible idea.
So, I ask: what size and signedness of int? 1, 2, 4, 8? What if the string is of length 3, 2, 1, 0?
Why bother with all those corner cases. Everything has a memory layout and appropriate semantics of representation and modification. Pushing those definitions is a recipe for problems.
I like to keep it simple, keeping the semantics simple in how I code specific kinds of transforms.
The less kinds of techniques you use, the less kinds of patterns you have to develop, test, and ensure consistent application of across a codebase.
Especially down in C land, which is effectively assembler.
Gone are the days of Carmac having to save bytes in Doom, unless you're doing embedded work, in which case that's all the more reason to be very careful how you handle those bytes.
Re: Don't Be Afraid of Types
#167People might be afraid of types because in OOP land there's the idea that types aren't mere containers for data. You have to use encapsulation, inheritance and polymorphism. Fields and properties shouldn't have public setters. You assign a value only through a method, otherwise you make the gods angry. You have gazillions of constructors, static, public, protected, private and internal. And you have gazillions of met…
If the encapsulation is implemented in a way that a) it is not possible to instantiate invalid objects of the type and b) all modifications via the type's methods only create valid invariants by enforcing the type's rules (either by mutating it in place or by returning a new instance for every modification), then it is ensured at compile time that this type cannot be misused ("make invalid states unrepresentable"). If that particular logic lives somewhere else, that's not possible.
Re: Don't Be Afraid of Types
#168Earlier quoted context omitted.
it’s common to be imprecise and mix up the type and an instantiation of the type, and that’s all that is happening here
It's usually not just imprecision though, I've found that a lot of programmers fundamentally don't understand what types are and this confusion might be an example of that. Types are just a layer on top of your code that help enforce certain logical / mathematical properties of your code; those that your particular type system enables you to constrain. Most actual type systems are not powerful enough to allow you to…
> Types are just a layer on top of your code that help enforce certain logical / mathematical properties of your code; those that your particular type system enables you to constrain.
I don't know if I really agree with that. It seems to presume the default form of data is a map and you constrain that down to a specific set of fields. (Or similar logic over void pointer spaghetti.) If you build up a record type from scratch you're doing something quite different. Adding a field where there used to be nothing, no way to store data there in an instance, is not what I would call a constraint.
Re: Don't Be Afraid of Types
#169People might be afraid of types because in OOP land there's the idea that types aren't mere containers for data. You have to use encapsulation, inheritance and polymorphism. Fields and properties shouldn't have public setters. You assign a value only through a method, otherwise you make the gods angry. You have gazillions of constructors, static, public, protected, private and internal. And you have gazillions of met…
Humans reason with objects much better because that's how the real business world works.
Real business world works with Excel tables, not "objects". (Whatever that is.)
Excel is a pure functional programming language, BTW.
Re: Don't Be Afraid of Types
#170Earlier quoted context omitted.
How do you understand the sentence above: > Benefits of types should be carefully balanced against the cost of introducing them Does "benefits of types" not imply to you that there are downsides to not having them?
The rest of the comment was clearly framed in a way that any cost of not having types might as well not exist. Reinforced by the very first sentence of how one should be afraid of introducing types.
Is it uncommon to focus on the things that support your counter argument in a discussion?
Does one need to always "fairly" represent both sides when it's clear that there are obvious properties that you are not discounting? This is a discussion, and that was a single comment — I couldn't imagine people would see it as a comprehensive look at a topic as complex as types in programming.
In that case, why not respond to the arguments I raise but instead attack what was never stated? I can see how part of the comment can prejudice you to an unbalanced opinion, but that's more on the reader than on the author — at least I think so.