Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't Be Afraid of Types

lmika.org

Post reply on HN
Print view View original

31–40 of 233 posts

Re: Don't Be Afraid of Types

#31

Post by NoahKAndrews »

necovek wrote: 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…

You need to think about backwards and forwards compatibility either way, types help make that easier.

Re: Don't Be Afraid of Types

#32

Post by noduerme »

re-thc wrote: post #28
noduerme wrote: post #18

Earlier quoted context omitted.

I think Java culture had something to do with the ridiculously verbose names, but even more so the prevalence of Factory and Singleton paradigms in Java created these issues. Maybe because it was the first OO language that a lot of procedural coders came to in the 90s. Those patterns became sort of escape hatches to avoid reasoning about ownership, inheritance and scope. They're still common patterns for emergencies…

> I think Java culture had something to do with the ridiculously verbose names People complain about this all the time but I'd rather take a verbose name than not knowing what is going on. Sometimes these naming conventions help. Digging into older poorly named, structured and documented codebases is not fun.

Definitely. If you have functions that only do one thing and are only called a few other place in the code, then by all means, name them explicitly. And I'd rather see that than a bunch of the same inlined anonymous function. I'm not really knocking the naming patterns as much as the data/logic patterns that required them. Factories are not a good thing. They usually imply that globals need to hold references. Obviously, so do Singletons. Global lifecycles in general are just easy to create and really hard to manage on your own.

Good comments are better than good function names.

Re: Don't Be Afraid of Types

#33

Post by galaxyLogic »

Types are the dual of Functions. You could create very many functions which differ just a bit, or you could create functions which take arguments/parameters and do with a smaller set of functions.

So how about using generic (=parameterized) types? Isn't that the answer?

Re: Don't Be Afraid of Types

#34

Post by motorest »

pjmlp wrote: post #25
noduerme wrote: post #18

Earlier quoted context omitted.

I think Java culture had something to do with the ridiculously verbose names, but even more so the prevalence of Factory and Singleton paradigms in Java created these issues. Maybe because it was the first OO language that a lot of procedural coders came to in the 90s. Those patterns became sort of escape hatches to avoid reasoning about ownership, inheritance and scope. They're still common patterns for emergencies…

For whatever reason Java gets the blame for what was already common Smalltalk, C++, Clipper 5, Object Pascal, Actor, Eiffel, Objective-C,....before Oak idea turned into Java. To the point many think the famous patterns book used Java, when it is all about Smalltalk and C++ patterns.

> For whatever reason Java gets the blame for what was already common (...)

Java's problem is that it's hugely successful, and to some it's the only language they ever experience in their formative years. Thus, because poor workmen always blames the tools, Java becomes the root of all evil.

Re: Don't Be Afraid of Types

#35

Post by 9rx »

pjmlp wrote: post #26
9rx wrote: post #19

Earlier quoted context omitted.

You can love conflicting things, but the basis of OO programming, that which makes it object-oriented and not just object-based, is message passing, which sees messages flow between objects for inspection. That is inherently runtime behaviour which is at odds with static type enforcement.

As shown by The Art of Metaobject Protocol that is the genesis of CLOS, not really.

The Art of the Metaobject Protocol does not seem to go into any detail about senders sending blobs of data to receivers. What do you think it shows, exactly? That you don't need to send blobs of data? That should be obvious by the fact that you can count the number of languages that support that concept on one hand, but does not remove that message passing when employed is necessarily dependent on runtime.

Re: Don't Be Afraid of Types

#36

Post by noduerme »

9rx wrote: post #19
noduerme wrote: post #15

Huh. I don't see any conflict between loving OO-programming and also loving types. Isn't 9/10ths of OO just about consolidating your business logic into interfaces and types that you'd ideally want to re-use? I feel like if it's not, then people are using OO the wrong way.

You can love conflicting things, but the basis of OO programming, that which makes it object-oriented and not just object-based, is message passing, which sees messages flow between objects for inspection. That is inherently runtime behaviour which is at odds with static type enforcement.

The whole point of static typing is to ensure that runtime behavior is consistent with what gets passed. Right? The beauty of a typed OO language (like AS3 or TS) is that you immediately know if you might be referencing something using the wrong type. The only major language where every variable is cast/guessed in message passing at runtime is in naked Javascript, where everything's type is any/wildcard. It's such a shitty ridiculous language that they had to build an entire type system for serious coders to compile down to it. But in pure form, a well typed OO language should never run into undefined behavior at runtime. Runtime interpolation is not an inherent drawback, or a logical outcome of OO languages. Some of them were just designed to be incredibly loose.

Re: Don't Be Afraid of Types

#37

Post by necovek »

taberiand wrote: post #11
parpfish wrote: post #2

my code became much easier to maintain once i stopped thinking of it as writing "algorithms" and "processes" and started thinking of it as a series of type conversions. structuring what lives where became easier, naming things became systematic and consistent, and writing unit tests became simple.

I agree; in my experience, pretty much everything is ETL. We take data from one thing, change it a bit, and put it somewhere else. Sometimes, as a treat, we take data from two things, put them together, and then put that somewhere else. Frontend, backend, databases, services, reports, whatever - ETL. In that context, the types and transformations between types are the most important feature. (Everything is actually C…

Except that "ETL" is a terrible name for it: one of those generic acronyms, that even when expanded to "Extract, Transform, Load", needs explanation for at least the "E" and "L" parts.

To me, looking at it as "functional" approach instead (data in, operate over that data, data out) is cognitively simpler.

Re: Don't Be Afraid of Types

#38

Post by tossandthrow »

noduerme wrote: post #17
tossandthrow wrote: post #13

Earlier quoted context omitted.

Now when you establish full functional languages, most languages will allow you to do fullName = map list \(firstName, lastName) -> firstName + " " + firstName and type it as `funfullName: (String, String)[] -> String`. I have worked on large scale systems in both types and untyped languages and I cannot emphasize strongly enough how important types are.

The only thing with anonymous functions is, when the boss says "please include every user's middle initial", you need to go find every instance of an inline function that resembles this. Consolidating that function in a getter in a class object called Person or User or Customer is a lot nicer.

This is more a question about architecture.

But one thing is certain: When you have that one function that is used 165 times throughout the code base, having a type checker is certainly going to help you when you add in the users middle initial.

Re: Don't Be Afraid of Types

#39

Post by necovek »

paulddraper wrote: post #8

Relatedly, don’t be afraid of (database) tables. It’s okay, you really can have hundreds of tables, your DBMS can handle it. Obviously don’t create them for their own sake, but there’s no reason to force reuse or generic design for different things.

I think with databases, it's natural to go for normalized forms for the benefits you get with a relational database.

Unless you don't have anyone with any semblance of DB design, you usually have more friction when you want to de-normalize the DB instead.

At least, that's been my experience, but I did have the luck of mostly working with experts in DB design.

Re: Don't Be Afraid of Types

#40

Post by motorest »

noduerme wrote: post #32
re-thc wrote: post #28

Earlier quoted context omitted.

> I think Java culture had something to do with the ridiculously verbose names People complain about this all the time but I'd rather take a verbose name than not knowing what is going on. Sometimes these naming conventions help. Digging into older poorly named, structured and documented codebases is not fun.

Definitely. If you have functions that only do one thing and are only called a few other place in the code, then by all means, name them explicitly. And I'd rather see that than a bunch of the same inlined anonymous function. I'm not really knocking the naming patterns as much as the data/logic patterns that required them. Factories are not a good thing. They usually imply that globals need to hold references. Obviou…

> Factories are not a good thing. They usually imply that globals need to hold references.

No. Your statements are fundamentally wrong at many levels. Factories are tools to instantiate objects of a specific type a certain way. They are constructors that don't suffer from the limitations of constructors. A factory does not impose any requirement on object life cycle.

Post reply on HN