WHAT??!?!? While I was in college, I learned Pascal, C (which I already knew), some light assembly stuff, Modula-2, Prolog, LISP, ADA, Fortran, and several more I'm forgetting at the moment. I want to say I learned 10-12 different languages (some deeply and some we just scratched the surface) while I was in college.
I was in for a Physics BSc, so there was a limited amount of programming-related courses. In fact, the only programming-related mandatory subjects were an introductory course to informatics on the first year (C and C++) and a course on
Computational Physics on the second year (also in C) which was less about programming and more about useful algorithms in simulations. Other courses had programming assignments, and it was possible to fit a decent amount of experience on numerical simulations with that, but there wasn't a lot of push for learning new languages. We didn't even *really* need to learn Python, but since we had freedom to chose whatever language we wanted and Python has NumPy/SciPy and the like... it was the best tool for some of the assignments, so some of us used it.
I had some contact with Fortran too, since I was given a bunch of Fortran code written by my proffessor to compute some things for a section my final graduate dissertation. And, for the rest of the project, since I had chosen to make it run on the GPU, I used Metal. And then I wrote the UI in Swift, which I had learned for a different reason outside college. But a lot of people graduated knowing only C.
Hmm, I’m not too familiar with the issue there, but I am curious. What’s the problem being faced?
You can set up SwiftUI lists to recycle cells, as long as you initialize them with:
Swift:
List(items) { item in
ExampleCellView(item)
}
If you are scrolling down,
ExampleCellViews that go offscreen at the top simply get reused and start appearing at the bottom (with new parameters). So, at any given time, no matter how much you've scrolled, there's only a handful of
ExampleCellViews in memory. So you can create a infinite scrolling
List trivially.
LazyHStacks, on the other hand, don't deallocate or recycle instances of its views in memory. So if you do:
Swift:
LazyHStack {
ForEach(items, id: \.self) { item in
ExampleCellView(item)
}
}
At first you have just a couple cells in memory, since they're lazily loaded. But if you scroll through a long array of
items, new
ExampleCellViews keep being added to memory, without the first ones being deallocated/recycled. So if you try to create an infinite scrolling
LazyHStack, it'll eventually run out of memory.
Fair enough, looking over the tutorials again, I do see that they are pretty MVVM. I’d still argue that Apple doesn’t do a good enough job getting folks onto the golden path, and some of their choices of what to include are great for prototyping, but are traps that make it harder to consolidate similar views that should be consolidated. I learned more looking at how they implemented the SwiftUI API itself than from the tutorials.
Agreed.
To a point I agree that existing codebases aren’t going to be able to transition easily. That said, with how you can mix and match AppKit/UIKit and SwiftUI means that you can use SwiftUI in more limited ways which are much less costly to implement. I can see legacy apps using SwiftUI as a means to start building out specific components in the view hierarchy. With this bottom up approach, you can start with components that are built around bindings and simple state rather than full view model objects. And it’s not like you can’t back a view model with a data source or some other data available to a delegate/controller object as part of a transitional state. If you want an MVVM-compliant @FetchedResults, you need to do something similar anyways by wrapping NSFetchedResultsController yourself.
Oh, putting little SwiftUI views inside existing UIKit screens (which is how most codebases are going to start the transition) is for sure going to be the easy part. And with just that it's going to make a *great* design system for apps. But when you're using entirely SwiftUI screens and not just components, you're going to want to switch to MVVM, and for a while the architecture is going to be a mess.
And yet, Xcode will happily auto-complete it for you. Go figure. I think Apple is expecting folks to lean on auto-complete to know when variables are in-scope or not, but I still don't like it.
I think most people do
if let foo = foo { ... } now. I haven't seen any codebase where unwrapping optionals doesn't use variable shadowing by default. You get used to it, and it becomes perfectly natural... but it's still a terrible choice of syntax for any newcomer IMHO. Zero readability. I used to hate it.
