Live data from Hacker News

If Inheritance is so bad, why does everyone use it?

buttondown.email

231–240 of 389 posts

Re: If Inheritance is so bad, why does everyone use it?

#231

Earlier quoted context omitted.

The cascade is not much like inheritance at all. If anything it's more like composition because the styles can come from multiple sources, eg user styles vs author styles, multiple layers. The cascade is so much not like inheritance that I wonder if you meant either the concept of selectors in general, or inherited properties?

Yeah, the other poster pointed out https://developer.mozilla.org/en-US/docs/Web/CSS/Inheritance and https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade . I meant the concept that when you e.g. apply the style "color: blue;" to an element, all child elements get the same style unless you override it. I'm not saying it's identical to inheritance, but it's similar in that changes and additions at the top-level ripp…

> I meant the concept that when you e.g. apply the style "color: blue;" to an element, all child elements get the same style unless you override it.

This is the first thing you've said so far that I would push back against. Neither BEM nor Tailwind removes this behavior that I'm aware of. I thought when talking about the cascade you meant generic styles on elements like "p", "ul", etc... getting applied across separate components, or specificity of child selectors, or something similar.

If you really dislike styles being applied to children in the DOM that don't override those styles, I don't think there is a way around that other than web-based components and shadow DOM with isolated styles. Or I guess use a bunch of style resets beforehand I guess? Neither Tailwind nor BEM gets rid of child inheritance of applied styles; you can use @layer I guess, but that doesn't get rid of that behavior either, it just allows you a bit more control over style order.

If you're using Tailwind and you write:

  
     

Some text

that text will be red. If you're using BEM and you write:

  
     

Some text

.Container { color: red; }
same deal.

Re: If Inheritance is so bad, why does everyone use it?

#232

Earlier quoted context omitted.

Have you ever seen wildly over-architected OO code where everything seems to be an abstract class and it seems impossible to find out where stuff actually happens? Inheritance is like a lot specialised tools - it can be useful in some situations but I think those are rarer than supporters might thing. Completely refusing to use inheritance and always using inheritance both seem like extreme views that should be avoid…

Feels like that time my physics PhD student girlfriend asked me "hey you're a programmer, right" and I was one until I discovered ROOT and suddenly I lost taste for life and anything related to Computers.

Did you become a reclusive mathematician like Perelman or Grothendieck??

Re: If Inheritance is so bad, why does everyone use it?

#233

Earlier quoted context omitted.

I agree with this sentiment but I also must say that the time's I've needed inheritance have been few and far between. I have seen really good examples where it works really well (UX is pretty common, but I've also seen really clean cases like data structures with complex interfaces and a simple abstract class). Where I think inheritance works best is when the state in base classes is limited and the interface is qui…

> Where I think inheritance works best is when the state in base classes is limited and the interface is quiet clear. Ideally where you are meant to override is also well defined. What benefit is inheritance providing here? What you described sounds mostly like a struct, at which point the only value the interface provides is possibly some computed fields.

When you scratch deep enough at programming, everything is structs and interfaces defining how you interact with them and how they interact with the world.

The best example of this (IMO) is how `AbstractMap` works in Java. [1]

In order to make a new object which implements the `Map` interface, you just have to inherit from the `AbstractMap` base class and implement 1 method, `entrySet`. This allows for you to have a fully compliant `Map` Object with very little involved work which can be progressively enhanced to provide the capabilities you want from implementing said map.

This comes in handy with stuff we've done when you can take advantage of the structure of an object to get a more optimal map. For example, a `Map` can be represented in a 3 node structure, with the first node representing the year, the second the month, and the final the day. That can give you a particularly compact and fairly fast representation.

The value add here is you can start by implementing almost nothing and work your way up.

[1] https://docs.oracle.com/javase/8/docs/api/java/util/Abstract...

Re: If Inheritance is so bad, why does everyone use it?

#234

Earlier quoted context omitted.

Yeah, the other poster pointed out https://developer.mozilla.org/en-US/docs/Web/CSS/Inheritance and https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade . I meant the concept that when you e.g. apply the style "color: blue;" to an element, all child elements get the same style unless you override it. I'm not saying it's identical to inheritance, but it's similar in that changes and additions at the top-level ripp…

> I meant the concept that when you e.g. apply the style "color: blue;" to an element, all child elements get the same style unless you override it. This is the first thing you've said so far that I would push back against. Neither BEM nor Tailwind removes this behavior that I'm aware of. I thought when talking about the cascade you meant generic styles on elements like "p", "ul", etc... getting applied across separa…

> I thought with inheritance you meant generic styles on elements like "p", "ul", etc... getting applied across separate components

Yes, so I mean if you add "color: blue" to "p", it's now going to start interacting with any element that's a child of "p" (which will probably be on all pages on your website so hard to predict and check what will happen).

BEM and Tailwind don't get rid of the behaviour of the color being applied to child elements, but it at least forces you to isolates these kinds of style changes to the component level (vs sitewide) which is what improves maintainability.

Re: If Inheritance is so bad, why does everyone use it?

#235

Earlier quoted context omitted.

> I meant the concept that when you e.g. apply the style "color: blue;" to an element, all child elements get the same style unless you override it. This is the first thing you've said so far that I would push back against. Neither BEM nor Tailwind removes this behavior that I'm aware of. I thought when talking about the cascade you meant generic styles on elements like "p", "ul", etc... getting applied across separa…

> I thought with inheritance you meant generic styles on elements like "p", "ul", etc... getting applied across separate components Yes, so I mean if you add "color: blue" to "p", it's now going to start interacting with any element that's a child of "p" (which will probably be on all pages on your website so hard to predict and check what will happen). BEM and Tailwind don't get rid of the behaviour of the color bei…

Okay, we are on the same page then -- sorry. Yep, I generally agree with this.

Re: If Inheritance is so bad, why does everyone use it?

#236

Earlier quoted context omitted.

The cascade is not much like inheritance at all. If anything it's more like composition because the styles can come from multiple sources, eg user styles vs author styles, multiple layers. The cascade is so much not like inheritance that I wonder if you meant either the concept of selectors in general, or inherited properties?

Yeah, the other poster pointed out https://developer.mozilla.org/en-US/docs/Web/CSS/Inheritance and https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade . I meant the concept that when you e.g. apply the style "color: blue;" to an element, all child elements get the same style unless you override it. I'm not saying it's identical to inheritance, but it's similar in that changes and additions at the top-level ripp…

I can see how it causes problems, but I don't really see any alternatives for certain properties. Would you want to set the color property on every element that contains text? Or do something with the universal selector?

Re: If Inheritance is so bad, why does everyone use it?

#237
post #144

Earlier quoted context omitted.

You’re describing the strategy pattern, which is probably one of the most practical coding design patterns. Ex: each chess AI difficulty gets its own class, which all extend a common interface.

I still find it funny that somehow the idea of runtime function dispatch via function pointer is called the "strategy" pattern.

Hey I didn’t name it!

Re: If Inheritance is so bad, why does everyone use it?

#238

Earlier quoted context omitted.

> Where I think inheritance works best is when the state in base classes is limited and the interface is quiet clear. Ideally where you are meant to override is also well defined. What benefit is inheritance providing here? What you described sounds mostly like a struct, at which point the only value the interface provides is possibly some computed fields.

When you scratch deep enough at programming, everything is structs and interfaces defining how you interact with them and how they interact with the world. The best example of this (IMO) is how `AbstractMap` works in Java. [1] In order to make a new object which implements the `Map` interface, you just have to inherit from the `AbstractMap` base class and implement 1 method, `entrySet`. This allows for you to have a…

I understand, and what you shared is a perfect example of what I said- but I fundamentally disagree with the notion that it's the same between the two.

I think that in effect, as you associate more behavior with a particular struct(as opposed to what you're attempting to do with said struct), the greater expectation it presents that the struct is what you code around. More and more gets added to state over time, and more expectations about behavior get added that don't need to exist.

Sure, you could say "Well, then just be strict about what behavior is expected in the interface"- but that effort wouldn't be necessary if we didn't make the struct the center of the behavior in the first place.

Re: If Inheritance is so bad, why does everyone use it?

#239

Earlier quoted context omitted.

Main reason I use c++ is because it has the most mature libraries. I gave Rust a try, and lots of nice things about it. But many of its libraries are not very mature.

What libraries do you miss from C++ that you can’t find in rust? ML is the big piece for me - there’s no mature equivalent to CUDA or PyTorch.

All the company specific libraries we have debugged of the past 30 years.

Re: If Inheritance is so bad, why does everyone use it?

#240

Earlier quoted context omitted.

I'll never understand why a lot of CSS devs are opposed to it. I can understand the initial gut reaction, but I've been writing CSS for 14 years and I love Tailwind. The cascade is a wonderful idea that has unfortunately not played out well in practice. Anyone who thinks it's just a skill issue is deluding themselves. In all my years, I've never seen CSS that (a) leverages the cascade, and (b) scales elegantly. It al…

Mainly because nobody is a "CSS Dev". If someone's entire job was developing CSS, you might expect that they would be willing to learn one new slightly different way of doing it. But in reality the pushback comes from full stack developers who already have a million other things to worry about, such that relearning all the basic CSS they already know, to achieve benefits that are rather minuscule in the grand scheme…

On the contrary, Tailwind's ergonomics are what attract me to it. With the autocomplete features via the VSCode intellisense plugin, I'm able to create UIs at a pretty extraordinary pace.

As a trivial example, let's imagine we need to apply a border radius to an element. Without Tailwind, it looks like this:

  1. I find the element I need to style
  2. I look at which class it's using
  3. I navigate to my CSS file
  4. I scroll down until I find the selector
  5. I type "border-r", then tab on the auto-complete to fill in "border-radius"
  6. I type the colon character, then space
  7. I think about what unit is appropriate - rems, ems, pixels, percentage
  8. I think about what value is needed for the design
  9. I also look around to see if this style is used elsewhere
  10. If the style is used elsewhere, I think about whether I need to refactor
  11. I type in the desired value
  12. I type a semicolon to mark the end of the statement
  13. I type cmd+s to save the css file
Here's the same example, with Tailwind:

  1. I find the element I need to style
  2. I type `round` and wait for the autocomplete to present my options
  3. I use my arrow key to select which one I want
  4. I type enter to add the desired tailwind class
  5. I type cmd+s to save the html file
The Tailwind interaction path takes less than half of the concrete steps to complete. But it's even more dramatic than that, because several of the steps taken in the first example require enough thought that it breaks your workflow and takes you out of your flow state. Then you have to get back into that flow state to keep working. But this keeps happening, so you're constantly stopping and restarting. With Tailwind, I tend to find myself staying in that flow state, because as I demonstrated above, there's very little getting in my way.
Post reply on HN