8 ms·
The problem with complex systems is that you can be dead long before you realize you're dead. Things can continue to seem "pretty good" for a long time just fro
by rayiner 3mo ago
The problem with complex systems is that you can be dead long before you realize you're dead. Things can continue to seem "pretty good" for a long time just from the inertia of past good decisions and built-up infrastructure. You see some fraying or cracks but everything looks fundamentally sound, until it isn't.
Apple's inability to deploy a new UI framework that's better than the previous one is troubling. This is the company that shifted from Toolbox to Carbon to Cocoa and each step was better than the last. Could Apple build MacOS X and Cocoa today if they didn't already exist? Microsoft's two decades of failure to ship a true successor to Win32 suggests that Microsoft (at least, the operating system side of the company) died a long time ago. I wonder if we'll say the same thing about Apple 10 years hence.
- skydhash 3mo agoI think the main issue is the functional approach. Having a functional approach to state can be quite elegant, but ultimately the computer does not do functional. You have to implement a lot of plumbing to have stuff that is a bit performance (clojure), or just add a veneer of functional over what is essentially a normal state machine (emacs). React works well, because it's only an abstraction over the real DOM. React only handles your app state. But the DOM mechanism is still very performant and very much imperative. But I don't think something like React would work well in a mobile app, because the UI tree is often very simple on iOS and macOS.
- poly2it 3mo agoFunctional doesn't mean stateless. I'd argue functional programming is superior for representing state in user interfaces. For a success implementation, see Jane Street's Bonsai: https://github.com/janestreet/bonsai https://github.com/janestreet/bonsai
- mpweiher 3mo agoNot sure how you define "success" here. Is Bonsai used much outside of Jane Street?
- skydhash 3mo ago> Functional doesn't mean stateless. I didn't say that. User interfaces representation are mostly trees. And with functional programming you basically have Tree2 = f(Tree1). Until f is done you can't do anything really. React has a lot of escape hatches to improve performance, but they are escape hatches, not an endorsement of the architecture. With imperative programming (and OOP), you only have that single `Tree`, which you update at will. Less elegant yes, but we have modularization to help us there. What Emacs does is to keep that `Tree` as a single mutable object, but have the code be functional, while the results are imperative.
- rudedogg 3mo ago> functional programming is superior for representing state in user interfaces It's always going to be slower than using something imperative. Trying to process the entire world's state for the sake of purity can feel elegant but it isn't free. And the complexity that gets added to make things performant is worse than just accepting that UIs are going to require you to jump around the tree and modify state. Every time I go through the trouble of understanding the latest web technique (React, Elm, Signals (the newest solution), etc.) to deal with state management and the DOM, I end up walking away disappointed. There's nothing new in them that you can use to improve what we've been doing for ages in native GUI toolkits. And to jump back to the original topic, yes, Cocoa was pretty decent, and SwiftUI while nice in many ways tries to Reactify native macOS development and made it worse. And it made Swift incredibly more complex and worse in hindsight.
- kodebach 3mo agoThe goal of the reactive/declarative approach was never to be more performant than imperative code. The goal is to more easily build UI that is performant enough and functions correctly. With imperative UI code it is incredibly easy to forget an edge case in your update logic.
- mpweiher 3mo agoNot if you actually do MVC, so solved around 50 years ago. 1. The UI tells the model to change. 2. The model does the change and possible related changes. 3. The model notifies the UI that something has changed. 4. The UI updates itself from the model. Alas almost nobody does MVC, despite calling what they do MVC.
- dgellow 3mo agoHmm, but React doesn’t own or manage the app state. And react native has been used for pretty complex applications
- mpweiher 3mo agoNot just does the computer not do functional. UI is also very much not functional, and in fact the lack of progress in UI the last 30-40 years can largely be traced to trying to create UI with procedural/functional programming languages, an instance of linguistic-architectural mismatch. Further reading: Programs = Data + Algorithms + Architecture: Consequences for Interactive Software Engineering -- Stéphane Chatty. https://link.springer.com/chapter/10.1007/978-3-540-92698-6_22 https://link.springer.com/chapter/10.1007/978-3-540-92698-6_... Can Programmers Escape the Gentle Tyranny of call/return? https://2020.programming-conference.org/details/salon-2020-papers/5/Can-Programmers-Escape-the-Gentle-Tyranny-of-call-return- https://2020.programming-conference.org/details/salon-2020-p... UIs Are Not Pure Functions of the Model - React.js and Cocoa Side by Side https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html https://blog.metaobject.com/2018/12/uis-are-not-pure-functio... Beyond Procedure Calls as Component Glue: Connectors Deserve Metaclass Status https://2024.splashcon.org/details/splash-2024-Onward-papers/9/Beyond-Procedure-Calls-as-Component-Glue-Connectors-Deserve-Metaclass-Status https://2024.splashcon.org/details/splash-2024-Onward-papers...
- cloogshicer 3mo agoThanks for those links! Some of it was great reading. What is your thesis then? What is UI?
- Exoristos 3mo agoDeclarative–reactive. Like SwiftUI.
- mpweiher 3mo ago"A view is a (visual) representation of its model. It would ordinarily highlight certain attributes of the model and suppress others. It is thus acting as a presentation filter." https://web.archive.org/web/20090424042645/http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf https://web.archive.org/web/20090424042645/http://heim.ifi.u... View and model are related, but neither is procedurally dominated by the other. The view is not a subroutine of the model, or vice versa. They are related entities that communicate in order for the view to function as a representation of its model to the user, and for the model to be manipulated by the user. To get the details I really recommend the Chatty paper. It is a bit hard to read, but delivers the goods.
- torginus 3mo agoImo the biggest issue with this functional model (at least in React), is that it handles things like virtualization, async, etc. poorly. Which is kinda ironic, because in a true functional language, it'd be feasible to provide 'a world model' - that is act as if the entire state is always available, and let the engine decide when to evaluate pieces of code - without any effort from the part of the programmer. Unfortunately when complex state transitions, async, and virtualization enters the discussion, the magic of React breaks, and you have to deal with all that, and also deal with how React's engine handles things under the hood.
- dminik 3mo agoStuff like virtualization (if we're talking about stuff like virtualized lists) is hard not because of React, but because there just isn't any support for it in browsers. React doesn't really help here, but in my experience, it's usually the browser that starts choking on high element counts, not React. Async is just difficult in general though. It's not really a surprise that most libraries/frameworks converged on similar designs.
- torginus 3mo agoI am talking about virtualized lists. And it should be a framework feature. I used to use WPF on desktop, and it had pretty good virtualization support (though the framework in general was more like Angular) - most containers had virtualization support, and you only had to implement the logic on the data source, and they framework created and managed physical UI elements for you, and managed the mapping so it seemed seamless to the user. React also operates on a virtual dom, there's no reason imo why couldn't they just fake that for you.
- dminik 3mo agoI mean, it's not quite that easy. The web is a lot more dynamic than WPF. If you just want virtualized homogeneous lists, there are libraries for that (and grids). But, once you start hitting things like differently sized elements, search and so on, you start running into platform limitations that you won't be able to resolve in React land.
- kikimora 3mo agoFamous UI = f(Model) is oversimplification that was sold in slides. Real “functional UI” frameworks implement UI = f(Model, UIState) where UIState is scroll and cursor positions, view pool for virtualization, rendering caches, etc. USState is mutable and managed by the framework and the rendering engine (e.g. React + DOM, SwiftUI + UIKit + CoreAnimation). I don’t see a problem with functional approach as in React. I do see a problem with understanding of how UIState being managed between framework, ui library and rendering engine.
- steve1977 3mo agoI think the problem with SwiftUI in a way was (or is) that Cocoa was so good. And, at least IMHO, it didn't need replacing, just improving. But I feel like Apple wanted to appeal to young web devs and tried to offer something more similar to what these are used to.
- monster_truck 3mo agoTotally agreed. I kind of figured things were going to get shitty when the guy who made autolayout got hounded on so hard that he left. I sure hope they can figure out a way through. Whatever it is, SwiftUI isn't it.
- rudedogg 3mo ago> Whatever it is, SwiftUI isn't it. I think this opinion is heavily shared by Swift developers now, but the messaging every WWDC is always "Swift and SwiftUI is the best way to build apps for Apple Platforms", etc.. If you have to keep telling everyone what they don't believe is true, it's a sign there's a problem. It feels like someone with a lot of organizational power is disconnected from the pulse of the community. SwiftUI is undeniably clean in a lot of ways, it presents beautifully and fits on slides well, but that matters less and less, and this all wasn't really working out even before LLMs disrupted things.
- steve1977 3mo agoWell the problem now is Apple would need to admit they made a mistake. And Apple does not make mistakes.
- mpweiher 3mo agoYes, they don't ever openly admit mistakes. But they do quietly drop or fix them, covertly acknowledging they were mistakes. Often with this messaging: "we have this new shiny thing that is even better than the old shiny thing (that was really a turd)". Remember "garbage collection"? Or "modern syntax"? Or CocoaJava? And with hardware they had their "come to Jesus" moment a while ago. And then hit it out of the ballpark with Apple Silicon. The one for software is still upcoming.
- brnt 3mo agoI only have to look at the iPhone fucking 17 to know Apple is long gone.
- graypegg 3mo agoGenuinely curious, what’s wrong with it? I’m no huge apple fan, but I didn’t really think the 17 was more than a regular boring spec upgrade, which seems fine all things considered. (Currently on an iPhone fucking 17)
- stasomatic 3mo agoWhere?
- mpweiher 3mo agoNot just complex. Also "successful for other reasons". And of course the RDF is particularly strong in Apple's case. And these are interlinked as well: they were successful in the past not just despite ignoring feedback/outside advice, but often because of it.
- dosisking 3mo ago> Could Apple build MacOS X and Cocoa today if they didn't already exist? Apple got rid of all the NeXT people long ago, with Tim Cook stabbing Scott Forstall in the back, so the answer is No.
- ak39 3mo agoThis type of story about management getting rid of the old guard is so common and typical, it remains one of the most frustrating aspects of this industry. In the “enterprise scene”, this sort of purge strategy is likely linked to a big percentage of money wasted and sometimes total failure. Why do managers keep making this mistake? “Legacy” is only a bad word in IT. :-(
- saagarjha 3mo agoThis is completely false, many NeXT people still work there.
- ksec 3mo ago7 Years of release on Swift UI, 12 years for Swift. This isn't 7 years of development, but 7 - 12 years after release. And to most these past 7 - 12 years are an ongoing beta development. It is unfinished, unpolished with no end in sight. And I have been extremely critical since the beginning. But the problem runs much much deeper. It isn't the technology that is the problem, not the devs who are making it. It is the person making the decision as to WHY this was allowed from the get go. WHY this was allowed to be released, or even before all that WHY resources for development of these ideas were allowed in the first place. For every yes that are a thousand no. Instead a lot of Apple's software development can be summarised as resume or KPI bonus driven development. It is not as bad as Google and Microsoft, but it is clear Apple have this problem a well. If you look back into Jobs era of Apple software, ( and not just software ) Apple manage to have done most things 2x better with half the resources. The whole Apple now is bloated. And yet everyone is chanting Craig Federighi all the way. And it is funny because for the vast majority of these 7-12 years I was the only few on HN and Twitter that was extremely skeptical of it, to the point I gave up writing ( or ranting ) about it before majority Swift and Swift UI developers negative sentiment emerged. And I have often asked the same question every single time, what if they just spend one fifth of the resources to iterate and improve C / Objective-C and Cocoa. All the resources on Swift and everything adjacent to it could have been better spent somewhere else. I have high hope for John Ternus, hopefully he gets his political game right and manage to change course for Apple software somewhere down the line.
- ardit33 3mo agoI agree with you. Swift should have been a modernized Objective-C. It should have kept the best parts of it, which made it a joy to use, and leave the archaic and the weird things behind. it would have been a great language, meanwhile they decided to throw everything out and created a language that it is overcomplex, and it is failing to gain any traction outside iOS / Apple's ecosystem. Basically, if you weren't required to use it, nobody would, which makes it a failure. SwiftUI, should have been a rendering template/library integrated with UIKit. Also, cleaning up some of the UIKit syntanx and framework (simplifying it), and use SwiftUI as a template for UI, would have been ideal. SwiftUI instead was pitched as replacement, yet it is not near as capable as UIKit, and it is not feature parity even 7 years later. Just bad leadership by Apple in this case. (probably many of these decissions were 'promo / resume padding driven' as it happens in many large companies).
- zombot 3mo ago> I wonder if we'll say the same thing about Apple 10 years hence. I don't think we have to wait 10 years, we can say it today.
- simondotau 3mo agoThat wasn't the question though. Being able to say it today doesn't mean you will be able to say it in 10 years. Companies which lose their way sometimes rediscover themselves. One example that comes to mind is Apple. Another example that comes to mind is Apple. In fact I can think of at least three instances (at very different magnitudes) where Apple has dragged itself out of a stupid hole they dug for themselves.
- fidotron 3mo agoThe underlying problem is the programming industry completely resisting learning the lessons of Objective-C because it doesn't like them. It didn't like them when NeXT tried selling it, and it doesn't like it now. You can't have Cocoa without Obj-C, or at least a langauge and runtime with that philosophy. Apple software has been on a clear decline for a seriously long time, and it's propped up almost entirely by them pulling off Apple Silicon combined with how Microsoft have somehow been even worse.
- layer8 3mo agoAs someone who hasn’t used the language, I’m curious about what the valuable lessons of Objective-C are that the programming industry is resisting learning.
- jrmg 3mo agoWeak, dynamic typing. Dynamic method binding at runtime (method calls really are message-sends). 'Traditional' object orientation with inheritance (although delegation and dynamic mixins are also core concepts, and the class hierarchy and method lists can even be manipulated at runtime). Nil is allowed anywhere and messaging (calling methods on) it is a no-op. Heavy use of 'notification' posting and subscription. All of these are unfashionable nowadays, but they’re fundamental to Obj-C (some to the structure of the language itself, some just as idioms) and to the design of AppKit and UIKit. Now, the fashion is: Strong typing. Static binding at compile time with no runtime modifications to the type hierarchy. If OO is used, there should be minimal inheritance. Nullability is strictly defined in the type system, and acting on null objects causes, at its most forgiving, an exception, and at its least forgiving, program termination. Notification-based systems may be the outlier here (still in heavy use), but even they are often frowned upon for being too 'loose' and unanalyzable, at odds with the ideals of static typing and static binding.
- mpweiher 3mo agoMany, though I have to start with this disclaimer: I still don't fully understand why Objective-C is such a sweet spot. One very important one is that, empirically, it showed how much of what we think we know about language design is ... shall we say ... "incomplete". After all, Objective-C is a car-crash of a language: take some Smalltalk and jam it into C. Done. How can you write software with this? And yet NeXTStep and Cocoa/CocoaTouch, arguably the most elegant pieces of OS-level/UI-framework software ever, were written in Objective-C. And not despite of it, but because of it. From a safety standpoint, it's hard to see how you can get worse: all the static type safety of Smalltalk (none) combined with the memory safety of C (none). And these interact. And while it certainly is possible to use it very, very badly, in practice I haven't seen the horrors that we are supposed to get. https://blog.metaobject.com/2014/05/the-spidy-subset-or-avoiding-copeland.html https://blog.metaobject.com/2014/05/the-spidy-subset-or-avoi... As an example, we got the same level of improvement from doing an Objective-C → Objective-C rewrite with Wunderlist (from WL2 to WL3) that others claim for Objective-C to Swift transitions. Also, dynamic messaging is said to be slow, yet Objective-C programs consistently outperform the much more static Swift ones. https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0321842847&linkCode=as2&tag=metaobject-20&linkId=4f7c355096938fece9d7c880e6916ce8 https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie... And of course, we all know that to do dynamic OO, you need a large runtime and better yet a VM. But it turns out that you can get much if not all of it with a tiny sliver of an extension to portable PDP-11 assembly language. https://blog.metaobject.com/2024/08/objective-c-is-just-like-leaky.html https://blog.metaobject.com/2024/08/objective-c-is-just-like... With so much being provided by so little, you can actually put the rest of the language design space to better use, IMHO: https://objective.st https://objective.st
- sirwhinesalot 3mo agoThe problem with ObjC was mainly syntax, bolted on over many years on top of a C core. It was grown rather than designed, and it shows. But there's nothing wrong with the runtime. Swift should have just been a much improved syntax over that same runtime. It would have avoided so many headaches. For one they wouldn't have made the awful decision to have return-type overloading and completely ruin the typechecker's performance in the process. SwiftUI should have unapologetically been a convenient, reactive wrapper over UIKit and AppKit, rather than treating them as deprecated implementation details that devs nonetheless keep having to drop down into. These decisions come down to ego, of wanting to do away with the old and carve out your own legacy separate from it. Nice if you want a promotion but not so nice if you're trying to make a long lasting ecosystem for developers to build upon. At least Swift and SwiftUI have a reasonable interoperability story with the past. Can't say the same about Microsoft's graveyard of UI frameworks.
- mpweiher 3mo ago> Swift should have just been a much improved syntax over that same runtime That's exactly how Objective-Smalltalk started, and it's still very good at being just that. https://blog.metaobject.com/2019/12/the-4-stages-of-objective-smalltalk.html https://blog.metaobject.com/2019/12/the-4-stages-of-objectiv... However, it has grown to be, er, a bit more. https://2024.splashcon.org/details/splash-2024-Onward-papers/9/Beyond-Procedure-Calls-as-Component-Glue-Connectors-Deserve-Metaclass-Status https://2024.splashcon.org/details/splash-2024-Onward-papers... https://objective.st https://objective.st > SwiftUI should have unapologetically been a convenient, reactive wrapper over UIKit and AppKit, I am also working on a UI "framework" I call InterScript that is (for starters) a wrapper over UIKit and AppKit, and basically solves what I perceive to be the biggest problems of Cocoa: 1. UI specification using object literals. This makes UI-creation very compact and readable. The following example (mostly) reproduces a SwiftUI "Form" example from Apple documentation: #Grid{ frame: (20@20 extent: 400@340), #rows: [ [ #Label{ text: 'Name' }, #TextField{ stringValue: 'Taylor', frame: (200@24) } ], [ #Label{ text: 'Email' }, #TextField{ stringValue: 'taylor@example.com', frame: (200@24) } ], [ #Label{ text: 'Notifications' }, #NSSwitch{ state: 1 } ], [ #Label{ text: 'Sounds' }, #NSSwitch{ state: 1 } ], [ #Label{ text: 'Summary' }, #PopUp{ items: [ 'Daily', 'Weekly', 'Monthly' ] } ], [ #Label{ text: 'Color scheme' }, #NSSegmentedControl{ segments: [ 'System', 'Light', 'Dark' ] } ], [ #Label{ text: 'Text size' }, #Label{ text: 'Default' } ], [ #Button{ title: 'Reset All Settings' } ], ] }. There are actually even better ways of accomplishing this, but this should give you an idea. 2. Better communication between model and UI by using the support in the language for polymorphic identifiers and dataflow. Because dataflow is in the language, it can be expressed succinctly without making it hidden magic like in SwiftUI. With dataflow and polymorphic identifiers, you also get a dataflow-constraint mechanism similar to Cocoa Bindings, but again with proper support and less magic. Essentially the solution to this: https://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and-cocoa-bindings.html https://blog.metaobject.com/2014/03/the-siren-call-of-kvo-an... There is more, for example cross-platform, MDA/Naked Objects/Direct2Web style simplification and web integration with HTMX and HTMXNative.
- ransom1538 3mo ago"ship a true successor to Win32 suggests that Microsoft" Because it was good.
- estimator7292 3mo ago[dead]
- pjmlp 3mo agoIt is a generation thing, all the folks that were able to ship those products are now retired, or approaching retirement, and apparently newer generations can only do Electron, React Native and co.