Live data from Hacker News

Don't Be Afraid of Types

lmika.org

111–120 of 233 posts

Re: Don't Be Afraid of Types

#111
post #27

Please be afraid of types. On top of new cognitive load, introduction of redirection, and anti-patterns like pretend-simplification where you shuffle a bunch of unrelated parameters into a struct to make a function receive only a single argument (which quickly evolves into functions receiving parts of that struct they don't need, making use and testing much harder — I am surprised an article is really recommending th…

It's more cognitive load to write a validation for every parameter because you can't rely on your fellow dev knowing it's not good to pass a string where you want a boolean.

Re: Don't Be Afraid of Types

#112
post #27

Please be afraid of types. On top of new cognitive load, introduction of redirection, and anti-patterns like pretend-simplification where you shuffle a bunch of unrelated parameters into a struct to make a function receive only a single argument (which quickly evolves into functions receiving parts of that struct they don't need, making use and testing much harder — I am surprised an article is really recommending th…

There's always types. The question is if they're dynamic, static, implied or explicit.

Re: Don't Be Afraid of Types

#113
post #109

People 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.

Not really. I mean, if objects corresponded directly and only to business organizations—the active entities in business—OOP would correspond tolerably well to how “the real business world” works, but as usually implemented OOP is a very bad model for the business world, and particularly the assignment of functionality to objects bears no relation to the underlying business reality.

IME, people don't actually “reason better with objects”, either.

Re: Don't Be Afraid of Types

#114

As somebody who is afraid of types (and also, who hates types, because we all hate what we fear), may my point of view serve as balance: you don't need a type system if everything is of the same type. Programming in a type-less style is an exhilarating and liberating experience: assembler : everything is a word C : everything is an array of bytes fortran/APL/matlab/octave : everything is a multi-dimensional array of…

Files have types though: .txt, .jpg, .bin, etc.

The filename suffix isn't much more than part of the filename (a simple variable name in that analogy) - it's more convention than constraint. Nobody is stopping you from giving your file the name you want (and the OS allows). You'd use literal magic[0] to assume an actual type.

"Everything is a file" rather refers to the fact that every resource in UNIX(-like) operating systems is accessible through a file descriptor: devices, processes, everything, even files =)

[0]: https://www.man7.org/linux/man-pages/man4/magic.4.html

Re: Don't Be Afraid of Types

#115
post #79

Earlier quoted context omitted.

I’ve first learned Java in introduction to programming in 2001 and that’s what interfaces were for back then already.

Interface are more fundamental to Java than classes. Sadly, at the beginning, many people came to Java from C/C++, and they did the thing we used to call "writing C/C++ code in Java".

I'm late to the Java party, I first did anything serious in it in 2009-10 and it was Android not "traditional" Java. So no idea about early Java's history.

The interfaces is the only thing i loved from it.

Re: Don't Be Afraid of Types

#116
Kind of disagree with this article, when you add a "noun" (aka type), you're often introducing a new abstraction.

Abstractions have a maintenance cost associated with it ie, another developer or possibly yourself must be able to recreate the "algebra" associated with that type (your thought process) at the time of making modifications. This creates some problems:

1. Since there's no requirement to create a cohesive algebra (API), there was probably never a cohesive abstraction to begin with.

2. Requirements may have changed since the inception of the abstraction, further breaking its cohesion.

3. Since we largely practice "PR (aka change) driven development", after a few substantial repetitions of step 2, now the abstraction has morphed into something that's actually very tied into the callsites (verbs), and is essentially now tech debt (more like a bespoke rube goldberg machine than a well-designed re-usable software component).

You can introduce types if you follow the open/closed principle which means you don't change abstractions after their creation (instead create new ones and then delete old ones when they have no callsites).

Re: Don't Be Afraid of Types

#117

Earlier quoted context omitted.

Files have types though: .txt, .jpg, .bin, etc.

The filename suffix isn't much more than part of the filename (a simple variable name in that analogy) - it's more convention than constraint. Nobody is stopping you from giving your file the name you want (and the OS allows). You'd use literal magic [0] to assume an actual type. "Everything is a file" rather refers to the fact that every resource in UNIX(-like) operating systems is accessible through a file descript…

And the good(sic) thing about conventions: so many to choose from! .htm .html .HTML .jpeg

Re: Don't Be Afraid of Types

#118

As somebody who is afraid of types (and also, who hates types, because we all hate what we fear), may my point of view serve as balance: you don't need a type system if everything is of the same type. Programming in a type-less style is an exhilarating and liberating experience: assembler : everything is a word C : everything is an array of bytes fortran/APL/matlab/octave : everything is a multi-dimensional array of…

I'm a big fan of primitive types, in particular byte arrays.

It's okay to create a new data structure that combines some primitive data types in a "struct", like an array that tracks its length.

But we don't want to "build abstractions and associate behavior to them" (just associate behavior to data structures like push/pop).

Re: Don't Be Afraid of Types

#119
post #107

> I found that there’s a slight aversion to creating new types in the codebases I work in. I've encountered the same phenomenon, and I too cannot explain why it happens. Some of the highest-value types are the small special-purpose types like the article's "CreateSubscriptionRequest". They make it much easier to test and maintain these kinds of code paths, like API handlers and DAO/ORM methods. One of the things that…

This can't be the explanation for everything, but I do know that once upon a time just the sheer source-code size of the types was annoying. You have to create a constructor, maybe a destructor, and there's all this syntax, and you have to label all the fields as private or public or protected and worry about how it fits into the inheritance hierarchy... and that all still applies in some languages. Even the dynamic…

>Even the dynamic scripting languages like Python that you'd think it would be easy tended to need an annoying and often 100% boilerplate __init__ function to initialize them.

For this reason, I very much appreciate the dataclass decorator. I notice that I define classes more often since I started using it, so I'm sure that boilerplate is part of the issue.

Re: Don't Be Afraid of Types

#120
post #85

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

That is what happens when all too commonly people treat OOP as their religion. Prefer encapsulation to inheritance is good advice. Interfaces are very useful if you have more than one implementation (mocks/fakes do not count), but otherwise pointless. Having private data is always a good idea - no matter what your code style is you don't want to have to look over all 10+million lines of code anytime you need to chang…

> Interfaces are very useful if you have more than one implementation (mocks/fakes do not count)

Why not, again?

Post reply on HN