Swift is collapsing under the weight of its increasing complexity. So many, many special cases & they keep adding more!
As a developer it becomes so very hard to reason about code behaviour. This is especially true with concurrency, which was meant to simplify concurrent operations, but in actual fact is a nasty can of worms. In an effort to "hide the complexity" it just introduces a huge amount of unexpected & hard to grok behaviour. The new "immediate" Task behaviour & non-isolated async behaviours are good examples of this.
Swift's become so feature-heavy, and complex, whilst the documentation is all over the place. That's not even counting things like SwiftUI, or its rather arcane CLI tooling.
Out of curiosity, I put in more than 150 genuine hours in 2024, trying to get deeply into Swift - and eventually just abandoned the language.
In comparison - I got very far experimenting with Go in the same amount of time.
Unless one needs to get into the Mac ecosystem, I see no reason why learning Swift should be necessary at all.
I've spent pretty much my entire career (20 years!) writing Objective-C: first for macOS, later iOS. Of course Swift is now the new kid on the block, and has lots to recommend it. But there's something about the simplicity and purity of Objective-C that has a special place in my developer's heart (despite its flaws & imperfections).
So thank you Brad, you've influenced my entire career. RIP.
Yeah, I feel the same way about Dash 5. Eventually had to upgrade to 5 when 4 became incompatible with the latest Apple docets. But I much preferred the Dash 4 search.
The developer of Dash is very receptive to feedback (in fact I think this change was called out as something that he was interested in hearing opinions on).
That's not my experience. I've reported this to him on two occasions, with screenshots and detailed descriptions of how the UX had regressed.
First one took a year before I got a reply (after reminding him), and only partly answered the request.
The second one I'm still waiting for a reply.
I would love for Dash 5 to fix these issues still, and I would upgrade in a heartbeat, but as it stands, I'm stuck with Dash 4.
The issues are:
1. Dash 4's sidebar shows significantly more hits when searching, making it a lot easier to find what you were looking for, compared to the "omnibar" of Dash 5:
2. Dash 4 shows/loads the currently selected search immediately, requiring no extra step. Dash 5 requires the user to press enter to confirm the search. This is especially frustrating when triggering a search from an editor
edit: where did he indicate he was looking for feedback on these features?
I've been a professional macOS developer for almost 20 years now and I can't tell you the number of times that this has been an issue.
With no access (or ability to patch) the platform source code you are left with a) hacky work-arounds, b) re-implement the component or c) change the app's design or feature to compensate. All of which are a pain / more work / risky etc, etc - just to work-around bugs in the platform.
Sure you can file radars (I do), but whether something gets fixed or not, is up to the gods...
That is likely to be non-trivial to develop unless you’re very comfortable with large, complex C++ projects and then you have to convince them to accept and ship ship it. That’s better than not having the option but it’s not for the faint of heart.
Chromium — yeah, seems like not friendly towards outside contributors, and nobody has convinced Google to accept stuff they don't care about (JIT for unpopular CPUs, support for new windowing systems, video decoding acceleration APIs, …).
Mozilla? Getting your patches merged is rather easy and very pleasant. Firefox is truly a community project we all build together.
Sure, but this is a thread about how Linux is better than MacOS because you can modify Linux. Those same criticisms you have I think could apply to Linux too.
True. In my experience though, it tends to work out. If 100 people are affected by a bug it's a drop in the ocean in the grand scheme of things, but now you only need a 1 in 100 chance of someone being up to the task! And the others can help with info and testing along the way.
Sure, but this is a thread about how Linux is better than MacOS because you can modify Linux. I think a Linux patch would take much longer to reach users. Modern browsers auto update frequently, but I don't think Linux users update Linux as frequently.
I'll give a big vote of thanks to the OpenCore developers.
Clover had constant stability problems during boot on my hardware (Coffee Lake, Z390), but OC has been stable since day one (v0.5.6 IIRC). I've not had a single issue since switching.
Author mentions web browsers and extensions in the context of barriers to creating a successful malleable system.
Surely the web browser - considered in relation to web pages & technologies (HTML, Javascript etc), rather than extensions - is perhaps the most successful malleable system in history.
The core browser "functionality" has been and can be extended in an almost infinite number of ways via web "pages". You could consider his dichotomy between "foundational" features (unavailable to the user/tinkerer) and extendable features to be comparable between Emacs (C vs elisp) and the Browser (C++ [for example] vs HTML/Javascript/CSS).
I realise that to "extend" the browser by building a web page includes a great deal more friction than playing with elisp in scratch. Does this rule out the browser as a "malleable" system?
You are taking the point of view of a web developer, not a web user: a web browser gives a web site's developer a lot of control over the experience of a visitor to the web site; the visitor has some control over his or her own experience, but not much. In contrast, an Emacs user has a lot of control over his or her own experience.
Simple example: Emacs is of course used to view files not written by the Emacs user. It is the sole decision of the Emacs user what size, color and thickness/thinness the text will be. In contrast, the writer of a web page decides those things, and maybe the user can modify that and maybe they cannot.
In Chrome for example, there is no simple way to increase the text size without also increasing the size of all the other elements on the page (without increasing the zoomLevel, in other words). If some of those other elements are fixed-position elements (elements that remain in the viewport no matter how much the user scrolls) that already take up a large fraction of the viewport (which happens a lot when you browse the web on a 1360-pixel-wide monitor and you have old eyes and consequently need large text), it might not be possible to increase the zoomLevel.
That's not the same thing: if the content can be modified by the content provider then it is malleable for him, not for the user; the dynamicity is entirely controlled by the site owner.
Following that logic, wouldn't be everyting that eats content to display them malleable? Image-viewers, audio&video-players, office-applications, MS Paint and Windows Notepad? They all have the core-functionality of showing something to the user which is not embedded in their source-code, while this core-functionality is part of it.
If anything, I would go for web pages as a malleable system. Because with userscripts and userstyles you can change them however you want.
Since the dawn of time advertisers have over-exaggerated and over-sold products. Call it an art (I might, but not in this case), call it a sham. It is what it is. No surprises here.
As a developer it becomes so very hard to reason about code behaviour. This is especially true with concurrency, which was meant to simplify concurrent operations, but in actual fact is a nasty can of worms. In an effort to "hide the complexity" it just introduces a huge amount of unexpected & hard to grok behaviour. The new "immediate" Task behaviour & non-isolated async behaviours are good examples of this.