WRT magic, I've generally thought that was a result of frameworks - Spring, for example. In the past, my feeling was that these impose a sort of meta/configuration language that itself is not checkable at compile time, so you'd get weird runtime errors that are somewhat inexplicable. This was like... 2018 though, so perhaps things have improved.
I'd argue that checked exceptions are still worth it, even though all the problems pointed out do exist. And that's because it works to inform consumers of what a producer is doing. Haskell has the IO and Maybe monads; Java communicates the same information through IOException and other domain exceptions.
Many times I've decided to switch from one function to another, or even an entirely new library, because the checked exceptions told me that it was doing far more than I expected, and I was not comfortable introducing those new failure modes.
It's far from perfect, one still has to handle nulls and wrapped/merged exceptions, but overall I like this language feature.
>in places where it's pointless to check, like IOException
Can you explain why this is pointless? In my mind, this being a checked exception would hopefully be a hint that I should think about this failure-case and make an explicit decision whether to handle it or not. Network connection failed? Maybe I retry. Maybe I store that data somewhere else as a fall back. Isn't this similar to Go programmers needing to check if err is not nil?
I don't think I can recall a time where I routed-around-the-damage on the basis of a particular typed exception.
As soon as you consider retrying a network failure, you immediately need to start thinking about distributed systems failures, idempotency, and all that good stuff.
As soon as you start thinking about the above, it becomes immediately obvious that low-level calls should not be able to decide to re-run themselves.
I appreciate that there is a _ton_ of different experiences out there when it comes to solving problems, but I _have_ encountered exactly the case I was describing, which is what led me to my original question. Isn't the fact that it was a checked exception that led you to "consider retrying a network failure, you immediately need to start thinking about distributed systems failures, idempotency, and all that good stuff" worth it as opposed to an unchecked exception you may not realize is being thrown?
Mostly I think they are a mistake, like in ordinary application code instead of catching close to the throw you want to do a lot of
try {
...
} finally() {
...
}
to make sure things get torn down that have to be torn down and let the exception go to the top of the unit of work and probably to whatever drives the work unit. You can probably do better than logging the raw exception and moving on to the next work unit but you can do much worse. That is, you want a default "sloppy" error handling approach that's correct that you can do without thinking and avoid other kinds of "sloppy" coding encouraged by checked exception such as catching exceptions locally without doing the right thing globally.
Occasionally though I have built something really sensitive, like an authentication filter for a web site which has at least 5 ways to log in and in that I have a hierarchy of exceptions and use checked exceptions heavily to document all the ways things can go wrong and felt like "the type system really has my back here" but that is like 5% of the Java I write.
> avoid other kinds of "sloppy" coding encouraged by checked exception such as catching exceptions locally without doing the right thing globally.
That's a code style and code review issue; each project has so set standards regarding how errors are dealt with and enforce them throughput the codebase.
But from a quality standpoint there are three concerns:
(1) Do you actually do the code review, do you actually enforce the style?
I worked on a Scala project where the dev manager thought it was preferable to handle errors with monads and would be vociferous about what a great practice that was compared to exceptions and that code review was central to how we do things... but if you looked at the code most of the time errors just got dropped silently and that was the same for many practices that the dev manager told me were doing but that we don't. He still posts on LinkedIn complaining about other dev managers who say they do code review but really don't. Practically that code didn't consistently give the right answers and poor error handling was one reason, another was that they never really understood that teardown was just as important as initialization.
(2) Is your documented practice correct? Is it really doing the right thing?
In a lot of cases there really is a right and wrong way to do things (e.g. uv resolves Python dependencies properly, pip doesn't) but it's less clear in error handling, like sometimes things went wrong and there is no way you can make it right and you can do the best that you can.
The global nature of the problem is vexing. Like an IOException might really be a BackhoeCutAFiberSomewhereInWisconsinException and a segmentation fault is occasionally a YouAskedForAOneAndGotAZeroInsteadException and it's not just academic because, given an exception, you want to answer questions like "Should I retry this operation? How long should I wait before I retry this operation?"
(3) Is this practice something you can sustain? How hard is to do? How much cognitive load does it add and how does it interact with other practices? "Throw up as much as you can", "tear down in finally {}", "otherwise handle local consequences of errors and rethrow" and "really catch errors at the drivers of units of work" is a practice that really works in many languages and is pretty easy to do right, even code that is written without a lot of care will do the right thing or something close by default. I've seen a lot of "no plan for error handling" or "bad plan for error handling"... like I was traumatized by the first C program I saw in a 1984 issue of Byte magazine which was using errno to handle errors which vastly complicated very simple code because the error path was intimately wound with the happy path and in cases like that there tend to be bugs in both of them. When I saw Exceptions in Java I remembered that old C program and thought "I love this!"
Scala's ZIO also demonstrates that they're a great idea and can be perfectly ergonomic, but you need type inference, which Java devs were resistant to for a long time (maybe still are? I remember lots of "how will I ever know what `val a = new Animal()` is???"). If you infer the exception type, they're basically invisible except for when you forget to have some place in your program to handle them, which is exactly what you want.
Somewhat related. I've also been generating lots of markdown files, which I've occasionally wanted to print out (so I can rest my eyes, or just read them somewhere other than my desk.) First class (free) printing support for rendered markdown seems like a lacuna in the overall ecosystem. I'm currently using the "print" plugin for VS Code, which opens rendered markdown in a browser window, which I print from there. Curious if anyone knows of better options?
Really cool deck! Anyone out there play Mu? It's an _excellent_ trick taking card game. One of the few (complex, trick-taking... I'm not counting stuff like Uno in this genre) card games that I know of that works really well with 5 or 6 players.
This deck _almost_ would work for Mu, but it'd need different point values. (I keep having to rebuy new Mu games when the deck wears out so I've been contemplating other possibilities.)
Mu is awesome, one of my favorites. I especially like the "Mu and More" and "Mu and Much More" decks that have other games you can play in the box. It is a bit fiddly customizing the decks for the different games, but it is amazing how much game is in that one box. Njet was mentioned in another comment, and that is one of my go-to games when playing with non-gamers.
Mu is my favorite trick taking game of all time, but it is difficult enough that I don't get a chance to play it very often.
I went down the rabbit hole of alternative games for this deck, and saw Mü mentioned in the forums with some tips alongside a table. Hopefully that helps, though I did notice someone commented about needing to remember the point values.
Basically, you write the point values in the card and use numbers 0-11 where 1=2 and 8=9 (1s and 7s in original game). My cards are made out of plastic, so they don't break. And you get the bonus of being able to play many more games. ^o^
Pagat is a wonderful source for all things card games. https://www.pagat.com - in particular https://www.pagat.com/class/trick.html which at that level is the groups of games (under the trump group is the euchre group which itself has six games)
Similar basic game and mechanics, though there are 8 additional cards to the 52 card deck - four wizards and four fools. A wizard can be played instead of any other card, the first wizard played takes the trick. A fool can be played instead of any other card and a fool will not take the trick (unless you've got the extreme oddball situation where you've got all the cards for a trick as a fool - then the first fool played wins the trick).
One of the things about it being a 60 card deck is that it evenly plays 3, 4, 5, or 6 players.
The European edition of the game has beautiful artwork (though confusing compared to the French suited cards) that make a long mural when an entire suit is laid down end to end.
I'd also suggest Nyet ( https://boardgamegeek.com/boardgame/1107/nyet ) which is another odd deck count game (3x1, 1x[2...13]) x 4 suits. It was originally a ruleset for the Mü deck where you excluded rules from the next round ("no - not that rule" -> "Nyet")
A third problem is that, depending on the project, one's recollection might be pretty fuzzy. A fourth is that, while you might be a great programmer, perhaps you've never had the opportunity to do the work of the design or greenfield development, meaning, you may not have a ton of insight into the design work that went into the project. E.g., perhaps you mostly do maintenance work on a large number of projects, so your overall knowledge of each is fairly shallow.
Recollection of specific implementation details of an old project may be fuzzy, but I'd hazard that any competent programmer should be able to discuss the themes and challenges of the project in depth, along with approaches for different requirements.
Overall shallow knowledge is not a positive signal, in my opinion. If they really are a firefighter who constantly jumps around, the interviewer should lean in to the organizational challenges they face when identifying and fixing problems across a variety of projects and domains. There's always a way to drill down with more specific questions.
Yeah. Even a "firefighter" should be able to discuss the architecture(s) they inherited, and the associated strengths and pain points, and the tricky/interesting parts of the system. So I wouldn't view that as an impediment at all to this style of interview.
And I'm not interested in the sorts of specific details that go fuzzy over time. I'm interested in a big picture view of choices made and alternatives discarded. We should talk about some implementation details as well, but "I don't recall" is definitely an acceptable answer for some decently large percentage of those choices.
If you're talking about a Rails project you did ten years ago, I don't really care if you used Sidekiq instead of Resque or vice-versa. I mostly want to know if you know what sorts of jobs should be moved to background tasks and how you structure those jobs and what are the tradeoffs etc.
Also, if I (the interviewer) selected one of the candidate's more "boring" roles, I'd happily let them suggest we focus on one that is juicier and/or one where they were more involved in the design process.
Perhaps the joke is that the valence of going backward or forward isn't equivalent. IIRC, some studies show that people will generally accept smaller gains to avoid the possibility of loss. Eg, loss has a greater (negative) emotional impact than equivalent (positive) gains.
> I don't think it's reasonable to compare the risk of suffering a large loss with the risk of missing out on a large gain. If your annual income is $N, missing out on a gain of $N is bad, but not nearly as bad a suffering a loss of $N.
- A comment I saw elsewhere on HN today
It's quite rational, in many cases, to consider loss of an object X worse than gain of X. A less rigorous example I like to use: it's far easier, and unequal, to kill a person than revive a person.
Isn't this the accepted advice for investment. Putting money in something that gains X% consistently with years of proven sustained growth vs putting money in something with potential 100X% growth but could give you negative growth if it fails has always been the advice in long term financial planning
> A less rigorous example I like to use: it's far easier, and unequal, to kill a person than revive a person.
People's intuitions aren't going to work right for situations that are impossible. I don't think you should use that example. (Or if you mean medical revival from the edge of death, then it's very difficult to visualize a "kill" that's actually an equal amount of damage.)
And things you own are fungible while people are not, which is itself enough to ruin the analogy.
Random family seating anecdote. A couple of years ago, we were on vacation and my wife had to go home early to tend for a sick pet. My daughter and I also re-arranged our flight to get home early, and ended up in like the D boarding group (on Southwest). So we're getting on the plane and we're almost dead last, and there are very few seats left together anywhere. My 6 yr old daughter was not really emotionally equipped to sit alone at that point.
We get about 2/3 of the down and there's now nothing, so I say -- with some desperation -- "If someone would be willing to switch seats so my daughter and I can sit together I'll give you $20." A guy says "I don't want the money but I'll switch."
Which sort of shows that if you're not a jerk, and you ask nicely, often people will go out of their way to help you.
Families who seem to expect other passengers to move, especially when there's assigned seating, are another story, and deserve the condemnation they get, IMHO.
Is anyone arguing "all fringe ideas must be false" or, conversely, "widely accepted ideas are true?" That's basically just argumentum ad populum, and I don't think that's the argument of the paper. Rather, it's that those with fringe ideas tend to be over-confident in their beliefs.
IME, a scientific/empirical mindset tends to lead one to a state of epistemological modesty, in which few things are unassailably true, and beliefs are provisional until disproven. One crucial feature of that mindset is the notion of falsifiability. Knowing if/how ideas may be falsified helps one avoid leaping down conspiracy rabbit holes. <- (A likely unfalsifiable statement!)
"Step out" is how to get out of the lower level frameworks, and or "step over" to avoid diving into them in the first place. I can't speak for other IDEs, but all of the JetBrains products have these.
This was my question. There's a weird sort of self-cannibalism that this hints at. The LLM is only as good as it is because it's been able to train on existing SO answers. But if over time, SO content production declines, then the LLM results will be less reliable. It seems that a new equilibrium could be one in which -- for newer questions/concerns -- both SO and LLMs will be worse than they are now.
I have a theory that, wrt knowledge, the relative advantage of age has been at least partially eroded by rapid technological advancement. In traditional/tribal societies, prior to the 20th century, wisdom actually accumulated with age, because the pace of change was slower. Wisdom & knowledge could be passed on from generation to generation.
Now, wisdom and knowledge become obsolete quickly. Many things you knew 20 years ago are outdated. The ICE engine you learned how to fix as a kid is now computer controlled, or has been replaced by batteries. Your optimistic/open/friendly mindset now makes you easy pickings for online scammers. Hell, even your family's secret cherished muffin recipe is spurned by your grandchildren because it has gluten or they're vegan or keto or whatever.
All this is just a take, but when I look at voting patterns in particular, I find myself pessimistic that the elderly are wiser than average.
Knowledge changes. I don't think wisdom necessarily changes. Maybe this is a philosophical discussion, but I think that is once of the key differences of knowledge and wisdom. However, I do think it is false that people necessarily accumulate wisdom with age. I know wise and unwise people of all ages, including people who think they're wise only because they're old.
when I look at voting patterns in particular, I find myself pessimistic that the elderly are wiser than average
Don't stop there, look at the US elected representatives! Washington is, from a lot of angles, a gerontocracy, and I don't think anyone would consider it "wise". The world has passed a lot of these folks by and even aside from that, their stubbornness to not step aside has in cases meant that they predictably die in office, so their seats go unfilled for a while, leaving people unrepresented...
The median age of the House is 57.5 years old and the Senate is 64.7[0]
Its really not great. There's very few representatives that have any life experiences of someone in the 30s or 40s. I'd argue that makes them out of touch on a host of very real, very pressing issues.
The other thing to think about is the age of those with the levers of power. Its one thing to be elected as a House member or to the Senate, its a whole other thing to sit on key powerful committees, be the leader of the party in the respective chamber etc. and the most powerful folks in congress trend into the 60s+
I disagree on the advantages of wisdom as these days I’m thinking the opposite:
1) Lack of wisdom leads to reinvention of the wheel. How many programming languages are there only now doing things the same way as 30 years ago? What is novel versus an unnecessary re-invention?
I started studying Tcl code from back in the late ‘90’s and honestly was surprised. Hell, many people don’t even know what macports is even though homebrew isn’t much but an attempt to reinvent macports with a “cool” spin.
2) Societal language and general problem solving skills are deteriorating. Language, and mathematics evolve ever so slowly, and yet emphasis on their importance is reduced in favor of the whims of technological advancement.
I would rather hire someone with the slow-developing, traditional skills, than the new-age fads.
In addition, with the advances in AI the only people worth hiring will be the ones with traditional education—and the wise, classically trained among our elders will be evermore important.
Yet what we’re seeing on the web with Typescript components turning to a pretty version of MFC minus the right/middle-click capability. The “single-page app” becoming a defacto standard mode of development.
Looking at the Fluent design React components just makes me wonder: this is progress from the desktop metaphor designed in the 90’s? What are we trying to achieve?
Then, I take a step back and realize that the 20-something’s from today don’t generally know what that is because they are cloud native.
For the future of the USA this is fortunately not very accurate, and microplastics are not associated with increased incidence of dark triad personality traits, as far as I know.
The craziest and stupidest things I hear regularly are from older people. There are broad swathes of old people that, not having been raised to be skeptical about media consumption on the internet, are entirely credulous about all manner of insane dis/mis-information.
That said, it's also something I'm seeing with younger people as well.
Every time I scroll through r/wallstreetbets or r/cryptocurrency I realize that I understand something about risk and patience that many young people do not. I am not disrespecting individual investors and I don't hate btc (tbh I don't invest in it either).
It's obvious that a lot of people feel like they have to find a way to get rich in the next three years or they will be poor forever. I am sure my generation was often the same. But people who have been through good times and bad times understand risk and patience.
people today cannot imagine what it would have been like to have each generation do, experience and believe exactly the same thing. for thousands of years. even just a few hundred years ago, new ideas were basically a waste of time because everything had already been tried. history would swallow you up.
I find many “elders” I know think climate change is a hoax, solar power is dumb , transsexuals are evil, immigration is silly etc, basically they hold extreme views and it effects my ability to trust their word or opinion.
I’m not sure if technology is to blame, I think social media is probably part of their corruption, Fox News too, but yeah, the lack of interest in their opinions is mostly self inflicted and I feel they choose to believe in nonsense because it’s fun to hate things.
What technology has done is give me access to lots of knowledge and wisdom and now I don’t have to put up with all the cruft to get what I need.
Some elders in my life are more balanced and I enjoy seeking their opinion and wisdom and leaning on their experience for all sorts of things.
One exception for me is that in Japan, even opinions are considered to be potentially offensive so elderly people are careful with their words. I’ve very really interacted with an older Japanese person who just spits rhetoric and conspiracy theories. Japanese even are careful to make a statement like “this is the best chocolate I’ve tasted”,
It’s much more common to say “I think this is wonderful”.
> ...but when I look at voting patterns in particular, I find myself pessimistic that the elderly are wiser than average.
Wisdom like 'It's harder to build something than it is to tear it down' and 'Change carries its own risk.'
The irony is that older people overwhelming voted for Trump on the basis of returning things to the way they were... and then Trump staffed his administration with young ideologues who are determined to upset the traditional order.
People group together uncorrelated concerns way too much in politics. I guess it's necessary side effect of the "us vs. them" mind virus.
> The irony is that older people overwhelming voted for Trump on the basis of returning things to the way they were... and then Trump staffed his administration with young ideologues who are determined to upset the traditional order.
There isn't any irony there. People heard promises of some X and Y and Z returning to the way things were, they voted accordingly, and then their candidate proceeded to go against them on A, B and C. This is only surprising if you believe there's a strong ideological correlation between all these things (there isn't), and that parties and their leaders act according to their purported ideologies (they don't).
That portions of the investment community threw in behind Trump and are now shocked (shocked!) that he has bigger priorities than keeping the market pumped is absolutely ironic.
Counterpoint: The only people who voted for Harris more than Biden were old white people (especially old white women).
The biggest shift towards right wing authoritarianism from a demographic perspective is among the young (specifically young brown/black men in America). This is happening globally at a rapid and unprecedented pace.
Get ready for a conservative, violent, radicalized youth. A Clockwork Orange but with 4chan like characteristics.
I'm not pessimistic about Boomers anymore. They're becoming teddybears as they age.
Two of my teenage sons play sports and at times it feels like all content consumption roads eventually lead to “manfluencers”[0]. If they’re watching content on lifting techniques, sports discussions, or gaming—not uncommon topics for teenagers—the recommendations are riddled with rabbit holes into the so called manosphere.
[1] https://www.javacodegeeks.com/2026/01/javas-checked-exceptio...
[2] https://reflectoring.io/do-not-use-checked-exceptions/
WRT magic, I've generally thought that was a result of frameworks - Spring, for example. In the past, my feeling was that these impose a sort of meta/configuration language that itself is not checkable at compile time, so you'd get weird runtime errors that are somewhat inexplicable. This was like... 2018 though, so perhaps things have improved.
reply