> But even if someone does include extra width, it takes me about a tenth of a second to pinch-zoom. Which is way quicker than trying to decipher line-wrapped spaghetti.
Strong disagree there. It's far easier to read the line wrapped code than to pinch to zoom. I think you have your answer: you have different preferences than others do, and no amount of explaining is going to make their "I like cats" make sense to your "I like dogs" sensibilities.
That is not a pitfall, that is the whole point of checked exceptions. By making the errors part of the type system, you get the ability for the compiler to warn you "hey man, that method started to raise a new error so you have to make sure to handle it". That is a great benefit, not a pitfall!
Put another way - it would be a lot easier for the programmer to write code if there were no types checked by the compiler at all, but we recognize that the safety net they give us is worth the additional effort at times when refactoring. So why would the benefits of static type checking be worth it, but not the benefits of static error type checking? It seems to me that either both are good ideas, or neither is.
Right, but I think the GP is saying that, with checked exceptions, the 'throws' list is part of that function's API. Changing the 'throws' list is exactly like changing the arguments to or return type of the function.
It's not so much a "pitfall" as it is an intended part of the deal.
It just turns out that many people hated it, so most of the time functions omit the 'throws' list and throw unchecked subclasses of RuntimeException. Which also has its trade offs! (Or "pitfalls", if you want to use the same term.)
Types help the programmer. When the compiler gives me a type error, it is telling me about something I messed up and that would otherwise be an error at runtime. Sometimes the type system is wrong and I need an escape hatch. A type system that is wrong too often isn't very useful. For the majority of exceptions, there no useful thing that can be done at the call site to deal with them beyond bubbling them up the stack. A type system that constantly makes me explicitly deal with such errors is making my job harder, not easier.
There are plenty of errors/exceptions that don't need to be bubbled up the call stack. I don't think that's the main issue with them. Like you say the issue with checked exceptions is that there is no escape hatch to shut the compiler up and panic if you can't handle an error or its not possible. They desperately need a short hand like Rust's ?, Swift's try?, or Kotlin's !!.
A a;
try {
a = someFnToGetA();
} catch (AException aex) {
// not possible in this situation
throw new RuntimeException(aex);
}
In a modern language that has checked errors that just becomes something like:
val a = try! someFnToGetA();
val a = someFnToGetA()!!
> history has shown that companies will bleed the commons dry and they need to be legally strong-armed into contributing back to the free software projects they make their fortunes off of.
Software is not a scarce good. Let companies use free software without contributing back as much as they wish; it doesn't affect others in the least. There is no bleeding of the commons here, because even if companies take as much as they can without giving back, it doesn't reduce the resources available for others.
Software is rarely finished, and development has real costs.
When that development gets silo'ed away in proprietary systems, that is potential development lost upstream. If that happens enough, upstream becomes starved and anemic, and with forks only living on in silos.
Apple, for example, has made trillions of dollars off of FreeBSD. To this day, FreeBSD still does not have a modern WiFi or Bluetooth stack.
Meanwhile, AMD, Intel, Microsoft, and even Apple, etc have full-time engineering roles and teams dedicated to upstreaming their improvements to Linux. And there are paid engineers at these companies that ensure WiFi and Bluetooth work on Linux.
Companies do worse than bleeding of the commons: lock down weak-licensed software and lock in users and devices. It totally reduces users ability to benefit from FOSS and reduces funding for developers.
> the current regime daily infringing the [USA] Constitutional rights of USA citizens
That has been happening for decades at this point. That doesn't make today's violations ok, but neither are they something new. The people of the USA gave up on freedom after 9/11.
Yeah, a CEO being "held accountable" looks like "we will pay you enormous sums of money to leave the company". Just once I would like to see the CEO of some big corp face actual consequences for running the company badly, but I'm not holding my breath.
I still use VLC to this day on Linux because it's still as great as it ever was. I'm gonna have to install something to play videos, why wouldn't it be VLC?
I remember having to install the K-Lite Codec Pack back in the day (college days) to be able to watch videos I would "acquire". When I eventually discovered VLC, it was like a breath of fresh air. I still use it to this day as my default video player, because nothing else comes close to the quality they have.
I'm the opposite. I started out using VLC, but once I found the codec packs (K-Lite being one of the last) I immediately started using other, more user friendly media players.
The problem with VLC is that the interface consistently feels... both imprecise and ridiculously granular. Everything just behaves weird. It felt weird in 2002 and it still feels weird in 2025. Like they cribbed the design from a DivX player, and haven't thought about it since.
VLC seems bound and determined to not let you interact with a video without pausing it, then opening the menu and hunting for option you need. Yes, I could set up my own interface, but that's not an excuse for not having a bare minimum of functionality that matches modern user expectations. Besides, configuring VLC to have the interface you want is itself not an easy task. Like, they have interface presets. Why isn't there a preset interface for "make this match YouTube"?
Just looking at what they chose to make be default key bindings is just bizarre to me. Half the things they have bound to single key presses are things that have never come up for me ever, while several things I want to use frequently are double or triple key combinations or not available for binding at all. All the default adjustments like skipping ahead or adjusting speed are all so granular that you have to hit them 10 or more times to actually accomplish anything. Just a completely alien interface to me. This software feels like it was built to solve media problems that I have not encountered since the late 90s when video tracks and audio tracks were more frequently out of sync from the producer.
What using VLC has taught me over 20 years is that the best way to play media with VLC is to open the software, begin playback of the media, and then under no circumstances attempt to interact with the software again.
For that, they would need to make LLMs not suck at easy programming tasks. Considering that with all the research and money poured into it they still suck at easy stuff, I'm not optimistic.
Strong disagree there. It's far easier to read the line wrapped code than to pinch to zoom. I think you have your answer: you have different preferences than others do, and no amount of explaining is going to make their "I like cats" make sense to your "I like dogs" sensibilities.
reply