Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SwiftUI After 7 Years

ykvm.com

Post reply on HN
Print view View original

181–190 of 343 posts

Re: SwiftUI After 7 Years

#181

Post by vintagedave »

migueldeicaza wrote: post #29
migueldeicaza wrote: post #10

skills issue

I joked, but reading the post is even more clear - man this poor dude. He is brute forcing his way through life and broadcasting it on YouTube. Dunno man, Xogot is made up of almost half a million lines of code. Of those 727 files use SwiftUI, and 65 use UIKit, 119 use AppKit (I did not count the overlap, so they are not mutually exclusive). Using GeometryReader makes it clear he is living in the past and the fact th…

> Using GeometryReader makes it clear he is living in the past

He seems to phrase it as though he has to, that he falls back because nothing else works. What would you suggest instead?

I'm only lightly familiar with both Cocoa and SwiftUI, but I have heard many nightmare stories about SwiftUI and Swift the language. I'm inclined to take his criticism seriously, and I think there's a big distinction between people who know a platform very deeply -- you are a strong expert almost everywhere you touch :) and it's clear from your comment SwiftUI works for you -- and normal developers who, you know, just want to learn a framework once and use it to get a job done. Living in the past is not necessarily bad; it's a good thing if what worked in the past worked well and still works today.

Re: SwiftUI After 7 Years

#182

Post by mpweiher »

bsder wrote: post #176
mpweiher wrote: post #171

Earlier quoted context omitted.

>> UI is also very much not functional, > I disagree, and I believe that the complete stagnation of GUIs is due to ignoring this. I disagree with your assessment. >Description->Pack->Apply events->Generate assets->Render assets. 1. What does that even mean? I don't see a UI in there at all, at best some graphics (Render). 2. That's not "functional". If anything, it looks like a pipeline, so dataflow. But then again,…

Functional is all about reification . You take a set of things in, you apply/map/collect/fold/whatever, you eject a set of things out. That is 100% functional--every time you supply the same inputs you get exactly the same outputs. The point of functional programming is that you avoid mutation and hidden state. And, um, side note: dataflow programming is almost always considered functional programming. Object oriente…

You obviously have some very non-standard definitions at work here. apply/map/collect are just higher order operations, they have nothing to do with reification, except that you need the functions that are arguments to be first class.

> dataflow programming is almost always considered functional programming

That turns out not to be the case. Dataflow programming shares some aspects with functional programming, they are not the same at all.

> Object oriented, by contrast, is all about hidden state and mutation.

That also turns out not to be the case at all. Heck, there were even object-functional programming languages.

> And increasing evidence suggests that MVC doesn't work beautifully today because it doesn't parallelize,

What does MVC have to do with parallelization, in your humble opinion?

Re: SwiftUI After 7 Years

#183

Post by Razengan »

viktorcode wrote: post #154
Razengan wrote: post #44

Earlier quoted context omitted.

That's actually why I jumped from Windows to Mac in the first place! My first Apple purchase was an iPad I got for my aunt, and I loved how streamlined yet powerful it was so I installed a VM on Windows to dabble in iOS development, and fell in love with the sheer consistency of macOS, iOS and their APIs. This was during the era when Microsoft was still figuring out whether to keep the Start Menu and replace the whol…

> Then came Swift and I loved it, but then it took literal years to catch up with everything you could do in Objective-C with the Apple APIs. I don't get this part. You can literally rewrite Obj-C code verbatim in Swift and it will work. The only missing part is C macros.

> You can literally rewrite Obj-C code verbatim in Swift and it will work.

It took a while to get there. They didn't have native Swift APIs for some things like URIs etc until later.

Re: SwiftUI After 7 Years

#184

Post by lonelyasacloud »

Used SwiftUI mainly on macOS since it was first released.

On macOS it is still comes up short on a lot of the GUI functionality. Stuff like window management, decoration, focus, undo/redo, finder tree type views etc. What Apple have implemented seems okay to me for iPad, iOS etc, but is not up to the standards users' expect for non-trivial native desktop applications.

With enough determination most of the omissions on macOS can be worked around by breaking the SwiftUI encapsulation and delving into AppKit or jarringly inelegant solutions. All of which are somewhat liable to ended up binned when/if Apple pull their fingers out. I had higher expectations of Apple, and overall, it's easy to understand why it does not have a stellar reputation.

As to why it's a bit rubbish on macOS; SwiftUI is largely a mapping to UIKit, AppKit etc primitives. At a guess Apple wants to reduce that number and are seeking to minimise investment in moribund technology.

Re: SwiftUI After 7 Years

#185

Post by jrmg »

layer8 wrote: post #167
fidotron wrote: post #153

Earlier quoted context omitted.

The 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…

As 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.

Weak, 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.

Re: SwiftUI After 7 Years

#186

Post by dminik »

torginus wrote: post #71
skydhash wrote: post #16

Earlier quoted context omitted.

I 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. Reac…

Imo 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. Unfortu…

Stuff 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.

Re: SwiftUI After 7 Years

#187

Post by mpweiher »

layer8 wrote: post #167
fidotron wrote: post #153

Earlier quoted context omitted.

The 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…

As 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.

Many, 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-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...

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...

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

Re: SwiftUI After 7 Years

#188

Post by mpweiher »

kikimora wrote: post #170
mpweiher wrote: post #157

Earlier quoted context omitted.

I never claimed MVC is a silver bullet. Just that it solves "... incredibly easy to forget an edge case in your update logic." > UI does not re-render itself too much? Glad you asked! In my Blackbird reference architecture (which is an instance of MVC), I use a coalescing queue to capture the updates. The coalescing is two-level: first, simple duplicates are weeded out. Second, if the update queue gets very full, it…

>The coalescing is two-level: first, simple duplicates are weeded out. Second, if the update queue gets very full, it becomes coarser-grained, and weeds out duplicates based on that coarser grain This is not about duplicates. For example, sync updates 100 items in a list changing their titles. Items are bound to a list in the UI. Thus, 100 unique title update events triggered. >Events are only used in the M→V communi…

> For example, sync updates 100 items in a list changing their titles. Items are bound to a list in the UI. Thus, 100 unique title update events triggered.

Those "updates" go in the queue. When the UI gets around to updating itself, it looks at the queue and invalidates all the UI elements that refer to the model items in the queue.

It then updates those elements, using the coarsening to update larger elements in bulk if that becomes better.

> Button clicked -> model change -> view update -> new event triggered -> model or view updated again

Once again, that is not allowed. View updates are not allowed to trigger any events in MVC. A model → view update updates the view. That's it.

The only event is "model changed", so it also doesn't make sense for the view to generate those events.

Re: SwiftUI After 7 Years

#189

Post by saagarjha »

ardit33 wrote: post #138
ksec wrote: post #122

Earlier quoted context omitted.

7 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 th…

I 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 req…

> 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.

Which means Objective-C was a failure, right?

Re: SwiftUI After 7 Years

#190

Post by mathverse »

For small apps I use exclusively SwiftUI for anything more complicated I use a combo of Sciter and Swift (courtesy of https://news.ycombinator.com/user?id=c-smile).

There are still a lot of rough edges when it comes to look and feel on Apple platforms but it gives me the performance and speed while also being multiplatform.

Post reply on HN