Earlier quoted context omitted.
It raised the bar a lot, at least. The lag was nothing compared to what you got on the typical Java-enabled flip phone, or the original Android G1!
Only for those that never had a Symbian or Windows/PocketPC phone on their hand.
Swift Regrets
181–190 of 207 posts
Re: Swift Regrets
#182Earlier quoted context omitted.
There's a tool called "scapix" that's popped up recently that fixes this and is really impressive. It's zero-boilerplate (IE, don't need to manually write bindings like most tools) bindings from C++ code for both Swift/ObjC and Java. The idea being you can write C++ code and then consume it on both mobile platforms, making your life easier. https://github.com/scapix-com/scapix It also is really useful if you want to…
Sounds great, I’ll check it out! I’ve always wondered why Google didn’t make something like this themselves. I assume the answer is that they just don’t care about native code, or at least native/Java interoperability.
But yes, not even caring about a better JNI tooling story is a big pain, specially given Android Java, they surely could have come up with a better FFI story.
Re: Swift Regrets
#183Earlier quoted context omitted.
Yeah, this sounds like a tooling issue. I have no difficultly believing Kotlin + Android Studio might be faster or more reliable than Swift + Xcode. Hard to say with any certainty though, it could be any number of things, if the perceived difference is even real.
From my outside looking in perspective: * Android studio is reliable and just works. * Kotlin is simple, easy to learn and productive. * xcode is buggy and with their rapid pace of development it is just getting worse. * Swift is complex. They had to rethink and redesign multiple times. Also the language was constantly changing under them.
How I wish this would be true.
There is a reason why so many rather use InteliJ with Android plugins, or even drop into VSCode with Gradle instead, only starting Studio for workflows that have to be done inside it.
There is hardly a "stable" release without regressions.
Re: Swift Regrets
#184I don’t know if this is Swift’s fault, per se but I find Xcode to be a real pain to use. There’s something about the Apple Way for UI/UX that just doesn’t jive well with an IDE experience. I find myself constantly jockeying around the various windows and panes within Xcode that I usually never have to bother with inside of Visual Studio.
Probably depends a good deal on what you're used to. By far, the IDE I've spent most time in through my career is Xcode (or its predecessor Project Builder) and have found it's not too bad once you've got a grip on the things it doesn't "like". In fact I enjoy working in it more than I do the much-vaunted Jetbrains IDEs, even when configured to use Xcode key shortcuts (thus short-circuiting the familiarity problem a…
I really don’t want all the visual editors and previews. Interface builder, Core Data Model Editor, even Swift UI previews feel so half-baked that they’re effectively unusable anyway. Swift packages are a delight because they’re purely text based.
As coders, we’re working with text all day. It doesn’t make sense to context switch to dragging boxes around a canvas to wire things up.
I’d rather they invested the engineer time into the core editor and made it rock solid.
My hunch is that they spend so much time on them because they look great in demos, but when it comes to the end of the beta cycle and the tool is still broken, it leaves a bitter taste. Simplify it.
Re: Swift Regrets
#185Earlier quoted context omitted.
Only for those that never had a Symbian or Windows/PocketPC phone on their hand.
That’s why those both continued to be successful, right?
Nothing to do with the greatness of iOS that has created revisionists of the mobile computing platforms history.
Re: Swift Regrets
#186Earlier quoted context omitted.
But why on earth would I heap-allocate structs in Objective-C? That's what I have objects for. If I am going to dumb things down to structs, the reason is that I don't want heap allocation. Unless I have no clue whatsoever as to what I am doing. As in, I just wrote pure C (no Objective- at all) and for some reason changed the extension of the file to .m Anyway, not using the solution that is there is not the same as…
You "mpweiher" might not do it, but I assure you plenty of enterprise programming cogs do. They code mostly in a C like way, and only use Objective-C at the level it is required to call into Apple specific APIs. When using C++, then their code looks like what I call C+. The same set of people that are to blame for Objective-C conservative GC never working in practice, when mixing Frameworks compiled with different mo…
I mean, sure, I believe you that you've seen this. But I've looked at quite a number of iOS/macOS projects and this was never a problem. Not even close. If anything, people were extremely hesitant if not actually afraid of using C features outside of the very basic ones like control structures, arithmetic and assignment.
Re: Swift Regrets
#187Earlier quoted context omitted.
I was there with you too. Objective-C may have been verbose, but it was readable and easily modifiable. It definitely seemed like the people who wrote Swift hated Objective-C. The "let", "func", etc syntax is ugly and unnecessary, along with the question marks. I know I'm swimming against the tide, but I'll be writing Objective-C for as long as I can.
> along with the question marks I'd take the question marks any day over tracking a nil passed around a dozen source files before landing in a dictionary literal.
Re: Swift Regrets
#188I guess I was in the minority who loved Objective-C and it's selector syntax. I think my main objection to Swift is that it seems to be written by people who hate Objective-C and made the calling syntax much more complicated. I dearly wish a more mature F-Script had been the next Apple language. A lot of the other problems is Apple not providing good documentation and making sure sample programs continue to compile.…
However I've come to appreciate Swift a lot more recently. What had taken pages of code can now be coded in just a page of Swift. That's nice.
I still like OBjC, nonetheless. But I'm liking Swift a bit more. The fact that it's stabilizing is a key feature to this. My objections to Swift have been how changes would pull the rug out from under what you'd already learned and coded before 5.0.
I agree with the documentation issue. A lot of features can't be found short of watching WWDC videos. And even then...
The other issues are "bad faith" and "bad intent" with privacy lately. I've actively removing and abandoning most of my use of iCloud because I can't really trust Apple even on that anymore.
Re: Swift Regrets
#189Earlier quoted context omitted.
> Nobody else but apple would make ObjectiveSwift too, because for better or worst ObjC & Swift are languages that are for the apple platform and nothing else. What about all the work done to support Swift on Linux? I had thought that was mostly done by the community rather than from Apple itself, but I could be wrong
It is as successful as the work done to support Objective-C and GNUStep. It is interesting that it works, and some folks might even create some products that use it, but it won't ever take the world by storm. Similarly like Mono was never that much relevant, with Miguel and others ended up creating Xamarin and focusing on mobile instead. .NET nowadays has a good story on Linux, because now it matters to Microsoft to…
Re: Swift Regrets
#190Earlier quoted context omitted.
You "mpweiher" might not do it, but I assure you plenty of enterprise programming cogs do. They code mostly in a C like way, and only use Objective-C at the level it is required to call into Apple specific APIs. When using C++, then their code looks like what I call C+. The same set of people that are to blame for Objective-C conservative GC never working in practice, when mixing Frameworks compiled with different mo…
Er...no. I mean, sure, I believe you that you've seen this. But I've looked at quite a number of iOS/macOS projects and this was never a problem. Not even close. If anything, people were extremely hesitant if not actually afraid of using C features outside of the very basic ones like control structures, arithmetic and assignment.
Maybe time to also review the WWDC session and the points made there?