Well, its very simple - millenials and GenZs have no political power, so the hangry wolves are just eating the food from their plates.
Drugged and blinded by social network, mobile apps, insane conspiracy theories and radical agendas, they keep missing the most obvious of things - there are no free meals, and all the sharks and wolves of the world will eat away on your hard work if you will not fight for it. What's right is not important - what's actually happening is.
Millenials and GenZs have all the political power if they just stand up and take it. The younger generations can change the entire demographic of the elected leadership if they so choose.
Why else do you think the older powers are trying to control who votes? Why else is there so much false rhetoric trying to convince people that their vote doesn't matter?
The only way political power translates to economic power is through socialism (when considered not just to be control of the means of production, but control of everything, including living arrangements). And while certain things are socialistic in Western countries, it would be a dramatic upheaval to make everything socialistic.
In the US there's only about 107 million Millennials and GenZers of voting age. This compares to about 150 million of GenX and older. Some of those people undoubtedly can't vote due to citizenship constraints, but Millennials and GenZers certainly can't control political power, even if they unified. https://www.statista.com/statistics/797321/us-population-by-...
2022:
GenZ = 69.58 million, 1997-2012 births, so about half can vote.
What do votes matter when just about every politician with reach got there by corporate sponsorship, and regardless of campaign promises hear most loudly the interests of lobbyists once in office?
Some months ago, I stumbled into an OOP inheritance rabbithole which got me thinking the same:
- Isn't the (biological) concept of inheritance built at it's core around the idea of "generations"? How does that make any sense in OOP?
- Why do Java beginner courses still teach Inheritance like it was 1995 with all the bells and whistles and dogs and cats and mammals?
- Why do they teach Inheritance and later introduce "favor composition to inheritance"? Doesn't this just confuse everyone?
- Why does Inheritance have first-class syntax support in an OOP language like Java ("extends") whereas Composition usually needs to be "engineered" using some more complex patterns, e.g. DI?
Most of it is probably for historical reasons, i guess.
"Why does Inheritance have first-class syntax support in an OOP language like Java ("extends") whereas Composition usually needs to be "engineered" using some more complex patterns, e.g. DI?"
I think the main reason is that DI is seen as an orthogonal concept by language designers, so you'd need new two first-class features in a language.
If you do composition without injection (e.g.: by having new ChildObject() in the constructor), you don't really require that many more lines of code compared to inheritance.
class Car {
private Engine engine;
public Car() {
engine = new Engine();
}
public void drive() {
engine.start();
System.out.println("Driving...");
engine.stop();
}
}
Of course it's much less flexible and less testable than composition + injection, but not that inflexible when compared to inheritance. And first-class support for only that would make the feature a bit useless without DI...
> Why does Inheritance have first-class syntax support in an OOP language like Java ("extends") whereas Composition usually needs to be "engineered" using some more complex patterns, e.g. DI?
Yep. You've got to remember that Java is nearly 30 years old; at the time making a distinction between interfaces and abstract classes was seen as a radical move. Newer languages have better support for more decoupled ways of doing things, e.g. Rust's use of typeclasses (which it calls traits for some reason) or Kotlin's built-in support for delegation.
The thing that Rust calls traits is quite different from the thing that Scala and PHP call traits, and much more like the thing that many languages call typeclasses.
If every class inherits Object then you probably need to understand the concept still, even if it’s no longer favored for organizing your own business logic. Besides, you will encounter other people’s code that doesn’t follow all the best practices eventually. And I’m not sure anyone has come up with a better way of teaching inheritance in the past few decades.
I don't know for Java currently but for example in Ruby composition is simply a matter of putting your code in a module rather than a class. Then you can extend any class with this module. You can even extend instances. That is 3.extends(Some_module).method_from_some_module is perfectly valid.
Of the many models of “composition” that are possible I think Ruby’s free-for-all blend of mix-ins and monkey patches is the only one that can drive a maintenance programmer more insane than a deep hierarchy of inheritance of Java classes.
irb(main):001:0> "bar".foo
Traceback (most recent call last):
4: from /usr/bin/irb:23:in `<main>'
3: from /usr/bin/irb:23:in `load'
2: from /Library/Ruby/Gems/2.6.0/gems/irb-1.0.0/exe/irb:11:in `<top (required)>'
1: from (irb):1
NoMethodError (undefined method `foo' for "bar":String)
Did you mean? for
irb(main):002:0> class String
irb(main):003:1> def foo
irb(main):004:2> "foobar!"
irb(main):005:2> end
irb(main):006:1> end
=> :foo
irb(main):007:0> "bar".foo
=> "foobar!"
irb(main):008:0>
Yes! Let's modify the core library String class on the fly to add new functions to it.
There are things about ruby that truly scare me if my goal was to write secure and reasonable code.
This doesn’t leverage on the more subtle but all the more elegant type system that Ruby provides. As told just above, since all object also have their own class instance you can extend this instance specific class without polluting the general class it derives from.
irb(main):001:1* module Awesomeness
irb(main):002:1* def awesome? = :yes
irb(main):003:0> end
=> :awesome?
irb(main):004:0> ?Ô.awesome?
(irb):4:in `<main>': undefined method `awesome?' for "Ô":String (NoMethodError)
from /Users/someone/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/irb-1.4.1/exe/irb:11:in `<top (required)>'
from /Users/someone/.asdf/installs/ruby/3.1.2/bin/irb:25:in `load'
from /Users/someone/.asdf/installs/ruby/3.1.2/bin/irb:25:in `<main>'
irb(main):005:0> ?Ô.extend(Awesomeness).awesome?
=> :yes
irb(main):005:0> ?Ô.awesome?
(irb):5:in `<main>': undefined method `awesome?' for "Ô":String (NoMethodError)
from /Users/someone/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/irb-1.4.1/exe/irb:11:in `<top (required)>'
from /Users/someone/.asdf/installs/ruby/3.1.2/bin/irb:25:in `load'
from /Users/someone/.asdf/installs/ruby/3.1.2/bin/irb:25:in `<main>'
Right, that’s monkey patching. You run into the real problems when you have multiple people wanting to add them.
Ruby isn’t alone in supporting this functionality (you can fiddle with JavaScript prototypes, for instance), but I think it is unique how much it is encouraged (at least in Rails world). I think extension methods are a much better model to achieve something similar.
Consider where you can slip in a block invocation and the following code:
def mal(&block)
block.call
block.binding.eval('a = 43')
end
a = 42
puts a
mal do
puts 1
end
puts a
and that that means that you've got full access to be able to inspect and manipulate all of the variables in scope at the time of the invocation. While that example is rather obvious, it can be done much more subtly too.
The power of ruby to do meta programming and by extension some really neat DSLs also provides it with some dangerous tools that are otherwise rather difficult to track down.
This is the Smalltalkiness of Ruby. Why have a separate place to put a function that operates only on strings when you can put it in String?
Of course, in Smalltalk you might have #trim defined by two different packages and they might conflict. Then what? Maybe you have to manage that complexity. However, it's not much different from having conflicting functions in the global namespace in C, but actually easier to resolve in a given situation.
Yeah, more modern Smalltalks are able to put things in various namespaces so they don't conflict but still generally work as expected. In Smalltalk, adding methods doesn't weigh down a class like in other languages, because method lookup is on-the-fly like in Objective-C, not precalculated and placed in a table.
Because it's an object-oriented language, and so its primary paradigm is object-orientation. Various style guides will tell you that object-orientation is bad and you should try writing in a procedural style instead, but the correct answer when you pine for procedural programming is to stop using Java.
Personally, I want a car with as little interaction as possible.
Sometimes I feel like a machine operator and not just a driver, especially when it's raining or when I need to defrost the windshield - constant hassling with whatever just to make things work.
How the hell is this progress? I want a car that does all the simple things for me - turn on the wipers at the right speed when its raining, defrost the windshield, knows when to heat/cool the car etc etc. You know - just learn me and do it.
This recent (10+ years) idea of adding more and more levers and buttons and cool screens to a car, to a point where it looks like an F-15 cockpit, might appeal to under-developed young males, but I really had enough. When I was younger, when you got into a new car, it took 2 minutes before you understood everything that needs to be understood and could safely driver with it. Now days you have to spend 10-15 minutes just to understand how to release the parking brake.
7 years ago I deleted my FB account. The mental relief was immediate.
Since then, I deleted all my social media accounts - LinkedIn (in some insanely magical way I'm still employed!) and twitter.
Being the old fart I am, I had no other social media accounts.
Not taking any needless selfies, not posting crap, not waiting anxiously for likes or comments, not reading BS from people I don't know just because some algorithm decided that's a good content for me for reasons I have no control over.
I kept LinkedIn account alive. enjoying those spam letters telling me how much xx new contacts I got. might even log in and take a look who's that if/when I'll look for a new job
For me LinkedIn just became another kind of FB, with people writing stupid posts, trying to present themselves as smart and successful and beautiful and PC and blah blah blah.
