2,752 karma · joined September 20, 2021
First, I hadn't heard of BETA. It's always interesting to see language choices that didn't survive, for whatever reason.
Second, I agree with the statement, "What this means is that the subclass is in control of the dispatch chain...This is great for flexibility, but as an API designer, that can be frustrating."
But I don't agree that's a problem. Isn't the need for the subclass to be in control the more frequent use case? I would be shocked / upset at a language that made it the other way around. You have to support both. You probably want the implementer of the subclass to have maximum freedom and to decide what's appropriate, because you can't anticipate all possible implementations.
The following two paragraphs, "There’s an implied requirement here...how are you supposed to know that you need to do that? You can document it, but it would be better if the base class itself made sure you did the right thing" aren't convincing to me. For one thing, maybe I don't want the call to setTransform in my implementation. Or maybe I want to setTransform(x - 1, y - 1). Also, to answer "how are you supposed to know...?" Maybe by reading the code. Why would you even need to document it? If you are extending a class, you have to read its code to even know if it's a good idea.
The example of the render method with an abstract onRender method is good for many use cases of this. How is this more difficult than using the proposed "inner" keyword? The "inner" approach doesn't seem to me to have less code or to be easier to understand. When I imagine how inner would work ("...specialize the behavior of their superclasses at well-defined points (i.e. at calls to inner...") it didn't seem to be any different than the super keyword in practice.
There's also many other options that may be more appropriate depending on the context. Someone in the comments pointed out that maybe interfaces and inversion-of-control would be better. There are also a variety of different patterns available that achieve the same thing depending on the context. The Decorator pattern might be another one. If you always want all GameObjects to be transformed in a game, for instance, one approach that would work fine is to only render objects of type "Renderable" and perhaps you wrap all GameObject instances in a decorator of type Renderable, which calls setTransform and then calls the onRender of the wrapped object.
Like I said, that's just one other option.
At the end of the article, I'm left scratching my head a bit at the title. It would be more "impolite" to me if the person who created a given base class
a) required me to extend their base class in order to achieve something in the program; and b) also required that super be called at a specific point in any overridden methods
One small nit that's neither here nor there: in Java methods marked final can't be overridden so maybe the example code with the protected abstract onRender method should have a "final void render..." method.
I'm starting to wonder about the safety of lithium-ion batteries. Does anyone have any insights on whether these are isolated incidents or something to be concerned about when buying products with lithium-ion batteries?
I have stopped using Goodreads already--probably for a couple years now. I found that the only feature I really used was the "To read" bookshelf. And I found that I just replaced it with a specific "To read" list of reminders in my iPhone's Reminders app. For that use case, this seems to work great for me. Can you speak to potentially any features of Booqsi that would be an improvement over my simple / non-book-specific approach?
"Noted" is purposefully agnostic to the underlying tools used, and outputs Markdown which is a standard that affords a wide range of available tooling and also can be converted to many other formats with widely-available open-source tools like pandoc.
I share more about the philosophy behind it in a four-part series here:
https://dev.to/scottshipp/an-amazing-note-taking-system-with...
From the post:
> A caveat for readers concerned about their most recent meal is that this study was conducted on mice, and mouse studies do not always translate to the same results in humans.
It's a shell script.
If interested: https://github.com/scottashipp/noted/
Sure there is. There are companies that are going to go out of business if they can't hire.
> ... just offer higher compensation or better working conditions
Not if they are a startup and simply can't. They only have so much funding. And besides that, it's not even a question of offering more. It's a classic low supply and high demand situation. Only those with the most are going to win the bid in the end.
The rest will go out of business for failure to hire. That's the crisis.
> crisis (noun)
> 1. A crucial or decisive point or situation, especially a difficult or unstable situation involving an impending change.
-- American Heritage Dictionary, 5th Ed.
Sounds great! Can't argue with that. My feeling is that the real problem isn't a company or companies offering computing services. That has always happened and will always happen. I think the real problem people aren't grappling with is vendor lock-in. Most of the catastrophic anecdotes I read on here and elsewhere are about people who put all their eggs into one basket and did not have any kind of disaster recovery plan. When their provider service went down or even went away due to a merger or whatever, they were left with nothing. And that's really a different problem.
Yes, please! That would be amazing
My experience in the industry is that no one in charge of either hiring or promotion is aware of the research, and have chosen to structure the systems that support them without data and prone to biases. The most bizarre aspect of our industry is that there is a high emphasis on work output, whether that be measured in LOC, number of PRs, number of releases, number of "story points," etc. or another measure, and yet low value of those same metrics in promotion processes.
I don't actually think those are great metrics to base career advancement on, but the contradiction is egregious.