ragnese

The waiting was hard, or your child having the phone in 7th grade was hard?

I'll be one of those guys. I see the invisible whitespace from pasting ALL the time. I've literally dealt with user complaints caused by it three times in the last two weeks! (Usually customer issues don't make it to me unless our support team can't figure it out or suspects a bug)

To be fair, it's not usually that frequent. Just a funny coincidence that I've JUST dealt with it more recently.

Firefox's are, nominally, reviewed. I don't know if Chrome's are, but I would've assumed that they are- even if by some automated tool(s).

Granted, I'm sure malware slips through. But, what security danger is there to a user if an extension blocks a network request? Manifest V3 eliminating the ability to block network requests is NOT for user security. The absolute best excuse they can come up with is that it has something to do with performance, but that's also bullshit because I'm 99% sure I can find plenty of ways to make a Manifest V3 extension waste CPU and/or memory.

This is the double standard I'm talking about. First, I honestly don't even believe your claim that Chrome was more stable than Firefox for a decade.

But, even so, you basically admit in the second paragraph that they're probably both fine, but you won't switch back to Mozilla "until they prove they're not going to let the browser stagnate for so long again." What the heck kind of test is that? And how long, exactly, will that take for you? If they "stagnated" for a decade, according to you, is it going to take another decade to prove they won't let it stagnate? Two decades, maybe? What does "stagnate" even mean? To me, it looks like Chrome is stagnating- what have they done lately that's innovative and actually good for users? Breaking a bunch of extensions and removing the ability to block ads? How many years does Chrome have to start behaving itself before you'll switch back to it after all of this? Ah, right- you won't switch away from it; you're probably only concerned about Firefox stagnating.

The truth is that you'll always make an excuse to not switch away from Chrome (and yeah, a browser that uses the Chromium guts is effectively the same thing when it comes to the monopoly on web standards).

That's it, I think. I think as long as enough of us actually do that, it'll make a difference. People seem to think that you need 50%+ of the users to "rebel" for there to be change, but the truth is that not all "users" are created equal. Developers, tech supporters (personal or professional), and "power users" matter more than typical users because it's our feedback, contributions, and demands that keep pushing these products forward. The "normies" will use whatever you put in front of them and they won't know or care that something could or should be different. If the nerds leave, the product will stagnate and other options will pick up steam.

There's still hope. I would like to draw a parallel to Microsoft Windows, with my own narrative added over.

Tech nerds mostly knew that Windows was not a good server operating system. It was also not a fantastic software development environment unless you were using a big, all-inclusive, IDE that was probably aimed specifically at developing Windows libraries and applications.

But, Windows was (and still is) the choice for normies by a WIDE margin.

The tech nerds continued to mostly ignore Windows for server stuff, and more and more ignored it for other dev stuff, too (many migrating to Macs, some to Linux, etc).

If you have a lot of users, but no developers on your platform, you're playing a dangerous game. Eventually Microsoft found a way to have Linux running in Windows. I don't know or care if that "saves" Microsoft or Windows or whatever, but I do see that as a win for the tech nerds.

All we have to do is get the tech nerds to stop using Chrome. Chrome can't survive forever if the nerds stop using Chrome, if we stop optimizing our web pages specifically for Chrome, and if we stop writing and maintaining extensions for it.

Eventually, they'll probably cave and put back more stuff to make the nerds happy, in order to bring them back to the platform and save their normie userbase. Either that or Chrome will die. Both are fine with me.

It was only true that Chrome was significantly superior (performance-wise, anyway) for a little while. Firefox had to play catch up and it took several years. It was (mostly) called the "electrolysis" (a.k.a., "e10s") project. It was considered complete by 2018, and had already offered significant performance and stability improvements for years before then.

I wouldn't be surprised if Chrome still performs better on Google-owned web sites, for obvious reasons. But, nobody is really going to notice a difference between Firefox and Chrome when visiting, e.g., your bank's web site.

So, it's been somewhere between six and eight years that Firefox has had comparable performance, comparable web dev tools, and way cooler extensions. I'm sure plenty of people will reply that this isn't true and there was some website just this week that FORCES them to stay with Chrome because they noticed a jitter once, but people on the internet are top-tier experts at rationalizing and I don't buy it.

We could've all jumped on board with Firefox when the e10s project landed, but nobody did because it was just slightly less convenient to switch than to not. I hope it was worth it for them.

This may sound impolite, but what you should do is to tell them to use Firefox. When they don't or say no, then that's that. It's not your problem and you should not feel obligated to enable or mitigate their poor decisions. If they can't manage their computing affairs without you, then they have to start respecting your professional advice.

Life's too short.

> It looks like the recent changes are all about slowly locking down what extensions can do because it’s currently a free for all where random anonymous extension owners have full access to everyone’s browsers.

The major browser vendors already have extension "stores" that are supposed to be curated. I believe it's also true that installing an extension directly ("side-loading") is usually disabled by default (or just not an option at all).

They've done their due diligence for our "safety". Now, it's just bullshit to prevent us from blocking ads, trackers, and spyware.

The vast, vast, majority of normies I know use Google Chrome and use zero extensions.

Sure, but we saw this coming a mile away (as in, people have been saying this about Chrome for about a decade). People--especially tech nerds--didn't have to switch to the closed source, conflict-of-interest, browser. But, everyone did, and this is what we get for it. We now have proprietary DRM built in to the web standards, and all kinds of other bullshit, because a bunch of people decided to not learn any lessons at all from Microsoft and Internet Explorer.

But, every time Mozilla does something slightly abrasive, HN users pile on about how Mozilla is ruining their privacy-respecting reputation, and then go back to using Chrome... The double-standard is really something else.

Maybe instead of getting someone else to break up Google for us, we could just... stop using their shit? I'm typing this from Firefox, I use Proton Mail (and pay for it!) for email, and I mostly search with DuckDuckGo (I know that's not perfect, either). I certainly don't feel like I'm living like a caveman...

/rant

I think this is backwards. A calculator app should be a simple thing. There's nothing undefined or novel about a calculator app. You can buy a much more capable physical calculator from Texas Instruments for less than $100 and I'm pretty sure the CPU in one of those is just an ant with some pen and paper.

You and I only think it's complex because we've become accustomed to everything being complex when it comes to writing software. That's my point. The mathematical operations are not hard (even the "fancy" ones like the trig functions). Formatting a number to be displayed is also not hard (again, those $100 calculators do it just fine). So, why is it so hard to write the world's 100,000th calculator app that the world's highest paid developers can't get it 100% perfect? There's something super wrong with our situation that it's even possible to have a race condition between the graphical effects and the actual math code that causes the calculator to display the wrong results.

If we weren't forced to build a skyscraper with Lego bricks, we might stand a better chance.

> My point was that making meaningful contributions such a big fixes requires understanding how the code is _supposed_ to function vs. how it actually functions, that's the hard part. In the majority of cases that's simply not something the code can tell you [...]

That's kind of my point, though. I'm trying to zoom out and "think outside the box" for a minute. It's hard to compose smaller pieces into larger systems if the smaller pieces have behavior that's not very well defined. And our programming languages and tools don't always make it easy for the author of a piece of code to always understand that they introduced some unintended behavior.

To your first point: I'm not shitting on Chromium or Firefox or any other software projects, but they're honestly ALL "buggy messes" in a sense. I'm a middling software dev and the software I write for my day job is definitely more buggy, overall, than these projects. So, I'm not saying that other developers are stupid (quite the opposite!). But, the fact that there are plenty of bugs at any given point in any of these projects is saying something important, IMO. If I use our current programming tools to write a Base64 encode/decode library, I can do a pretty good job and there's a good chance that it'll have zero bugs in a fairly short amount of time. But, using the same tools, there's absolutely no hope that I (we, you, whoever) could write a web browser that doesn't have any bugs. That's actually a problem! We've come to accept it because that's all we've got today, but my point is that this isn't actually an ideal place to settle.

I don't know what the answer is, but I think a lot of people don't even seem to realize there's a problem. My claim is that there is a problem and that our current paradigms and tools simply don't scale well. I'm not creative enough to be the one who has the eureka moment that will bring us to the next stage of our evolution, but I suspect that it's what we'll need to actually be able to achieve complex software that actually works as we intend it to.

That's true, and fair point for the example not being the best one. It was several years ago that I was poking at the Chromium code base to investigate something. I don't honestly remember much about the code itself, but I do remember struggling with the build system like you said. And that's probably why I just remember the whole endeavor as being difficult. Though, the build system being so complicated is not totally irrelevant to my point... Understanding how to actually build and use the code has some overlap with the idea of understanding the code or project as a whole.

There are multiple reasons that contributing to various projects may be difficult. But, I was replying to a specific comment about writing code in a way that is easy to understand, and the comment author's acknowledgement that this idea/practice is hard to scale to a large number of developers (presumably because everyone's skills are different and because we each have different ideas about what is "clear", etc).

So, my comment was specifically about code. Yes, developing a kernel driver requires knowledge of the hardware and its quirks. But, if we're just talking about the code, why shouldn't a competent C developer be able to read the code for an existing hardware driver and come away understanding the hardware?

And what about the parts that are NOT related to fiddly hardware? For example, look at all of the recent drama with the Linux filesystem maintainer(s) and interfacing with Rust code. Forget the actual human drama aspect, but just think about the technical code aspect: The Rust devs can't even figure out what the C code's semantics are, and the lead filesystem guy made some embarrassing outbursts saying that he wasn't going to help them by explaining what the actual interface contracts are. It's probably because he doesn't even know what his own section of the kernel does in the kind of detail that they're asking for... That last part is my own speculation, but these Rust guys are also competent at working with C code and they can't figure out what assumptions are baked into the C APIs.

Web browser code has less to do with nitty gritty hardware. Yet, even a very competent C++ dev is going to have a ton of trouble figuring out the Chromium code base. It's just too hard to keep trying to use our current tools for these giant, complex, software projects. No amount of convention or linting or writing your classes and functions to be "easy to understand" is going to really matter in the big picture. Naming variables is hard and important to do well, but at the scale of these projects, individual variable names simply don't matter. It's hard to even figure out what code is being executed in a given context/operation.

That's not what I would call a "first-party" library. Yes, it's written by JetBrains and under the Kotlin project umbrella, but we have to add it to our project like any other dependency.

I can install a persistent collections library in any language. I know for a fact there are persistent collections libraries for Rust, JavaScript, Java, etc.

But since none of those are built-in, they aren't used by the standard library APIs, and they won't be used throughout the wider ecosystem.

And, I'm still not willing to call Java a "functional language" because I can install a third-party library for persistent/immutable collections and hopefully avoid the built-in collections as much as possible.

> My goal in most cases now is to optimize code for the limits of the human mind (my own in low-effort mode) and like to be able to treat rules as guidelines. The trouble is how can you scale this to millions of developers, and what are those limits of the human mind when more and more AI-generated code will be used?

I think the truth is that we just CAN'T scale that way with the current programming languages/models/paradigms. I can't PROVE that hypothesis, but it's not hard to find examples of big software projects with lots of protocols, conventions, failsafes, QA teams, etc, etc that are either still hugely difficult to contribute to (Linux kernel, web browsers, etc) or still have plenty of bugs (macOS is produced by the richest company on Earth and a few years ago the CALCULATOR app had a bug that made it give the wrong answers...).

I feel like our programming tools are pretty good for programming in the small, but I suspect we're still waiting for a breakthrough for being able to actually make complex software reliably. (And, no, I don't just mean yet another "framework" or another language that's just C with a fancier type system or novel memory management)

Just my navel gazing for the morning.

I have LOTS of opinions about this topic, but I'll try not to ramble.

I always found checked exceptions (Java) to be mostly fine/good. I sincerely believe that a lot of the hate for them in the last decade is just cargo culting. I get a small dose of schadenfreude when I see someone doing mental contortions to simultaneously explain why Rust's Result type and handling (and similar features in other langs) is awesome, and Java's checked exceptions are terrible and definitely not 95% similar in DX and semantics...

The one point against checked exceptions for me is that if I'm trying to model a domain failure, it really doesn't make sense to collect a stack trace. For example, if I'm writing a logIn function that takes a username and password, then it's totally normal for the username and password to be invalid. Why would I want to spend the CPU time collecting a stack trace when someone simply typed in an incorrect password? Do we want to collect a stack trace when the password is correct and the user gets logged in?

So, in that sense, I do have a small preference toward expected failure modeling to be somehow different from "true" "exceptions".

I do also agree with you that Kotlin's biggest original sin was to throw away checked exceptions without replacing the concept with ANYTHING. Of course, as you've pointed out, they're backtracking on that somewhat by trying to add this concept of errors as a kind of ad-hoc union type. (aside: they also backtracked on their choice to not have type classes because "extension functions are good enough" by trying to do context receivers, which is ending up being really hard and probably more complex than just doing damned type classes in the first place...)

I do kind of like the direction that Swift is moving with finally adding specifically typed throw signatures (essentially Swift now has checked exceptions, but they're aren't actually traditional exceptions because they don't collect stack traces and unwind the stack- they're just syntax sugar around a Result/Try type).

But, my prediction is that the pendulum is starting to swing back in favor of checked exceptions. In the next decade we'll continue seeing languages adopt mechanisms that are essentially checked exceptions. But, they will be slightly different and definitely called something else so that we don't have to admit that we were wrong to shit on the idea for 15 years.

EDIT: Also, I do follow Kotlin developments closely, but I haven't actually worked in Scala for several years, so I had no idea about this capabilities idea. Thanks for the link.

I think a comparison to Scala is apt. Working with both languages makes it quite clear to me that Scala is most certainly much more functional than Kotlin. Kotlin is really not very functional in practice, in that it really doesn't encourage a functional style, nor is it optimized for the patterns that are common in functional programming.

Scala has `Try` and `Either` for modeling domain failures as values as opposed to throwing (unchecked) exceptions, which are side-effecting. Scala also has for-comprehension syntax built in to make it more convenient to compose and chain fallible operations that use `Try`, `Either, `Option`, etc. Kotlin's `Result` type is not designed for modeling fallible operations (not a sealed class, no type parameter on the error variant, error must be `Throwable`, etc), and Kotlin does not offer convenient syntax like for-comprehensions despite being more than able to (given that many of us have implemented near-perfect analogues to Scala's `Try` and for-comprehension syntax in Kotlin). Similarly, no official Kotlin libraries or APIs ever return errors as values and always opt for throwing exceptions instead.

Scala's collection types are implemented as persistent collections, which are optimized for cheap updates. If you want to avoid direct mutation in Kotlin, you have to make a full copy of a collection.

Scala's mutable and immutable collection types are actually distinct from each other and cannot be used interchangeably. In Kotlin, List<T> is a supertype of MutableList<T>, which means I can pass a MutableList into a function that expects a List. That means that the list can be changed in another thread while my function is running, so I can't even assume that checking `list.size` at two different points in my function will return the same value.

Scala has actual type classes. Kotlin has extension functions which are not nearly as useful (and they have very surprising semantics when it comes to static vs dynamic dispatch). Type classes are certainly not required for functional programming with a statically typed language, but it definitely helps when it comes to modeling things without needing to lean on writing more classes and/or utilizing inheritance.

Also, Kotlin's "functional" APIs on collections are much more janky than Scala's. For example, if I have a `Set<T>` and I call `.map((T) -> R)` on it, Kotlin will give me a `List<R>` while Scala will give me a `Set<R>`, which makes way more sense.

Kotlin is cool, and it would be dishonest for me to say that it's not at all functional, but after having worked in other many other languages, I'm very comfortable saying that Kotlin is an OOP/imperative language first with some functional stuff added in (sealed classes, convenient lambda syntax, top-level functions, and some of the typical collection combinator APIs). Whereas Scala is quite clearly designed to be actually GOOD for functional programming without taking an extra-hard performance hit.

It's much more "multi-paradigm" or "unopinionated" than Java, but since it is a pretty thin layer over Java and uses its standard library, the ecosystem and idioms are still very much OOP by convention. But, I see the language itself as more akin to C++ in that it really doesn't strongly push much in one direction or another, but they also both lack built-in tools or optimizations for doing real functional programming. So, I'd say that Kotlin, like C++, is an unopinionated language that does well for OOP and/or imperative styles.

> We're all bad people, just some of us are more comfortable with our corruption being visible to others to a higher degree.

If the GP's story is true (and I have no reason to suspect otherwise), then there are clearly differences in the degree of "badness" between people. GP chose to resign from his job, while his manager chose to be negligent and dishonest.

So, even if we're all bad people, there are less bad and more bad people, so we might as well call the less bad end of the spectrum "good". Thus, there are good and bad people.

Sure, but it's all so vacuously ambiguous that it doesn't really matter. I hate advice lists like this because it can essentially be summarized by saying "write good code" and you'd be left with almost exactly as much wisdom.

What does "succinct" mean? Well, it means terse but not too terse. What does "readable" mean? It means I can easily understand it.

How is this helpful?

> Taxing fake wealth because you own a company > [...] > Why should you dilute your ownership share

So... is owning piece of a productive company "fake wealth"? Is it fake when you can leverage that valuation to have access to more credit and use that to buy real stuff (like property...)?

Who--other than "governments"--decided that its "your" property and that you somehow deserve monopoly rights to a piece of the planet that you didn't create?

Makes sense. I don't have an X account, so I can only see the linked post (AFAIK).

And if we were in an alternate universe where we had reason to believe that the app did this analysis offline and never sent the data off to be sold to who-knows-who, that would be fine.

I fucking hate this dystopian future we've already entered. It's only a matter of time until every car on the road is connected to the internet and has the "good driver" logging built-in and automatically sent to your insurer. They'll also know exactly where you've driven to and when via GPS. Then they'll offer you discounts on the restaurants and stores you frequently drive to, and everyone will love it and tell ME that I'm the crazy one...

/rant

Honestly, even if it's not sustainable and never ends up profitable, I'd be willing to bet there are multiple entities that exist that would pay you some ridiculous amount of money for that info just to try to resell that info or attempt to monetize it directly "some day".

Think about how many companies have pivoted to burning cash on adding "AI" to their products. How many of those cases are going to end up actually being a good business decision? Probably very few. It's likely the same with everyone just wanting "data" to "analyze"--even if they have no idea how it might be useful.

To be fair, all of that tracking and data collection would still never add up to some 100MB. It's more likely that they have extremely unoptimized assets (images, icons, fonts, time zone data, sounds, etc) and/or are using one of these janky "frameworks" that let you slap together a half-baked "native" app in a few hours by translating your poorly-written JavaScript into poorly-written native code.

That's a fair point. It's definitely pretty different from an unrealized capital gain because, like you said, it's not about your net gain or loss on the house. But, I'd still say that it's practically similar enough to a wealth tax precisely because it's a tax based only on the current value of the thing that I own.

Also, just to add to the above discussion, it's even worse in practice than a tax on unrealized gains because I'll have to pay the same amount of tax every year if my house stays the same value. If it were a tax on the unrealized "gains" of my house, I'd pay $0 if it stayed the same value. And if the value of my house decreases, I'll still have to pay more than $0 in property tax, whereas a capital loss would mean I would pay at most $0.

So, I think I still stand by my sentiment that property taxes are more burdensome than a tax on unrealized capital gains.