The current supreme court cited the 1987 Houston ruling in both 2024 and 2025 in decisions that reaffirmed insulting police officers as constitutionally protected speech.
I laugh about people confusing "using JIRA" for "using Agile." One is a tool, the other is a methodology. Instead of confusing the tool for the process, they... confuse the tool for the process. I guess it is the same sort of thing.
Agree, and I have been an Ultimate Edition license holder since like 2013.
I have opened an IDE for very very few things in the last 9 months or so. Im still renewing a license at this point mostly because I like JetBrains the company and it's not a financial burden but they are in a bad place.
JetBrainer here. Thanks for the loyalty, and I do think as one of the last independents, we are worth cheering for. But it's up to us to earn double-clicking on the IDE icon.
After using Air in PyCharm, it's some good stuff. It's re-imagined for this hybrid world. But my question for you, honest question: do you think you still want to look at code? How about write code? If so, what are some things you'd do, if you were in charge of our IDEs?
same here, but this will probably be my last year, their AI strategy where it seems impossible to use it with local models without it "calling home" really soured things for me, if I wanted an always connected spying on me IDE I would use vs.code, I paid for jetbrains because I wanted to use all functionality (including AI, pointed to my llama.cpp) with networking blocked in little snitch save quick unblocks for the occasional license check if needed.
JetBrainer here. I use OpenCode and Pi connected to local models and to stuff like hosted DeepSeek all the time. Once you have your model config set up in the agent, it works as expected.
thanks for the reply, last time I tried this in goland if you blocked the IDE from networking via little snitch/opensnitch, it did not seem to work or keep working, there seemed to be some sort of call home to enable the AI plugin / keep AI working. If this has changed I will retry and see.
If their revenue-generating products are not doing so hot, I wonder what that means to projects such as Kotlin and Compose Multiplatform. Will they keep the lights on?
The whole "multiplatform" portability business has been one of the most conspicuous victims of the agent wave. Porting is now primarily a QA exercise, not a development one. (Development too, generally, is heading that way).
You do need to worry about TC until it's enough and if it's not enough, you do need to figure out what needs to happen to get more... Whether that's chasing promos or job hopping or whatever.
If you have at least enough for now, you can start by just doing a good job and see what happens and if you're rewarded, not have to specifically chase. Hopefully you'll get to enough for the future without having to focus on promos etc. It's certainly nicer that way.
Then you can take on big projects when they make sense, instead of forcing them. Big projects that benefit your team/company where you're the right person to do it are more likely to work out than ones where you're a bad fit (or the project is a bad fit for the org!) but you think it will get you promoted.
>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!"
At the end of the day the developers have to work with logging and error messages and exception stacktraces that the production system spits out. Also, operations personell needs to be able to diagnose issues and handle them or give good bug reports to develops. The above concerns should dictate how to best handle errors, and developers should figure out how to best accomplish this within the constraints of their tech stack.
There are several valid ways to do this, but it's important that one strategy is agreed upon and abided to, at least in new code. It's important that one srrategy becomes the orthodox one, else there will never be a reckoning about its effectiveness, but instead only people clinging to their own standards on their own turf. Legacy code complicates the picture of course.
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.
Oh, then do explain the unbearable temp that we're going through last few years, that's completely not normal for my country, winters not needing worm clothes, and very little rain during the monsoon. This weeks heatwave left us wondering how to cope the next year, which already seems going to be worse
It makes us realize there are people who gets fed climate denying propaganda, simply because they're not yet going through it. And these people are like flat earthers, blind to see the reality lay beyond them in full view. Or worse sees the reality but ignores it
All I know is that in the 80s a scientist I respect predicted that coral would be bleached by changing global climate on a specific timeline which turned out to be spot on, and his advice then and now was that we need to seriously curb carbon emissions to avoid worse outcomes for life on earth. Until someone opposed to this suggestion comes up with a prediction equally as long range and impressive I'm afraid I can't really take their protests too seriously.
Right, and one of those industries is checks notes orders of magnitude smaller than the industries and secondary industries that benefit from denying climate change.
Really makes one think, if they try. Would need to ask Claude if there is some real middle ground here.
I've come to the point where I've thrown up my hands and decided we live in a little snow globe. There's no such thing as pollution, were just mixing existing things together. Nothing new under the sun. Sure, that mix might not be compatible with human life, but something will surely take its place. And maybe that something won't rely on selfishness to drive collective progress the way we do.
At some point you realise that an $11tn industry, with $7tn in handouts and subsidies every year, has spent billions on astroturfing, political capture, and straight PR to deny the obvious and keep itself on life support at the expense of everyone else.
There's no both sides here. One side is staffed by scientists, the other by dictators and corporate lunatics.
I'd say the exception is Demis. First, he's no wanker (in the AI space) and second he's done plenty of selfless things leading dm/googai. Obviously some of it is self-serving but not just self-serving, IMO.
reply