Re: Thoughts on ARC
On Wed, 2 Oct 2019 10:50:19 +1300, Sam Ryan via Cocoa-dev said: >That was a good read, thank you for passing that on. It highlights a good >point, that Apple is itself releasing applications with non-Mac UI (News, >Home, Stocks, Voice Memos are mentioned in that article). Another way to look at it: Apple is redefining what "Mac UI" is. For better or worse. Sean ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on ARC
—Jens > On Oct 1, 2019, at 2:50 PM, Sam Ryan wrote: > > In fact those applications are forced upon the user in a way that I've never > seen before, as if they are core system components. You mean pre-installed? There have always been plenty of bundled apps like Mail, Calendar, Chess, etc. The specifics have varied from release to release, of course. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on ARC
That was a good read, thank you for passing that on. It highlights a good point, that Apple is itself releasing applications with non-Mac UI (News, Home, Stocks, Voice Memos are mentioned in that article). In fact those applications are forced upon the user in a way that I've never seen before, as if they are core system components. As a slightly interesting aside, the Stocks app on my MacOS installation has always been called "Μετοχές.app", which might be Greek? I've never known why, and as I cannot delete or uninstall it due to System Integrity Protection I have simply ignored it. On Wed, 2 Oct 2019, 02:16 Richard Charles, wrote: > > > On Sep 30, 2019, at 5:57 PM, Sam Ryan wrote: > > > > I tried a completely new approach - Electron. I have found Electron to > be surprisingly quick to prototype, easy to bridge to c++, and is cross > platform (non mobile at least). I would not have recommended a non-native > approach until recently, but for what it is worth, I've come to realise > this is one of the better options available these days. YMMV. > > Interesting. > > > On Sep 30, 2019, at 7:00 PM, Jens Alfke wrote: > > > > If you don't mind coding in JavaScript, don't care about Mac UI > guidelines, and aren't shy about shipping a 200MB+ app that has an entire > freakin' web browser embedded in it… > > > > (Sorry for the grumpiness. I'm just sick of all the "Mac apps" that are > just Electron-based web pages, e.g. Slack.) > > Also interesting. > > I found John Gruber's comments on Electron and the Decline of Native Apps > enlightening. > > https://daringfireball.net/2018/12/electron_and_the_decline_of_native_apps > > --Richard Charles > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on ARC
> On Sep 30, 2019, at 5:57 PM, Sam Ryan wrote: > > I tried a completely new approach - Electron. I have found Electron to be > surprisingly quick to prototype, easy to bridge to c++, and is cross platform > (non mobile at least). I would not have recommended a non-native approach > until recently, but for what it is worth, I've come to realise this is one of > the better options available these days. YMMV. Interesting. > On Sep 30, 2019, at 7:00 PM, Jens Alfke wrote: > > If you don't mind coding in JavaScript, don't care about Mac UI guidelines, > and aren't shy about shipping a 200MB+ app that has an entire freakin' web > browser embedded in it… > > (Sorry for the grumpiness. I'm just sick of all the "Mac apps" that are just > Electron-based web pages, e.g. Slack.) Also interesting. I found John Gruber's comments on Electron and the Decline of Native Apps enlightening. https://daringfireball.net/2018/12/electron_and_the_decline_of_native_apps --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on ARC
> On Sep 30, 2019, at 4:57 PM, Sam Ryan wrote: > > I tried a completely new approach - Electron. I have found Electron to be > surprisingly quick to prototype, easy to bridge to c++, and is cross platform > (non mobile at least). I would not have recommended a non-native approach > until recently, but for what it is worth, I've come to realise this is one of > the better options available these days. YMMV. If you don't mind coding in JavaScript, don't care about Mac UI guidelines, and aren't shy about shipping a 200MB+ app that has an entire freakin' web browser embedded in it… (Sorry for the grumpiness. I'm just sick of all the "Mac apps" that are just Electron-based web pages, e.g. Slack.) —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on ARC
No apology necessary, I'm pained by the same problems as you mentioned! On Tue, 1 Oct 2019 at 14:00, Jens Alfke wrote: > > > On Sep 30, 2019, at 4:57 PM, Sam Ryan wrote: > > I tried a completely new approach - Electron. I have found Electron to be > surprisingly quick to prototype, easy to bridge to c++, and is cross > platform (non mobile at least). I would not have recommended a non-native > approach until recently, but for what it is worth, I've come to realise > this is one of the better options available these days. YMMV. > > > If you don't mind coding in JavaScript, don't care about Mac UI > guidelines, and aren't shy about shipping a 200MB+ app that has an entire > freakin' web browser embedded in it… > > (Sorry for the grumpiness. I'm just sick of all the "Mac apps" that are > just Electron-based web pages, e.g. Slack.) > > —Jens > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on ARC
I have recently looked at utilising Swift to update an old Carbon based application. I stopped pursuing this path Swiftly, in part because of lack of good support for sockets and generally problematic use of CG* code. I tried a completely new approach - Electron. I have found Electron to be surprisingly quick to prototype, easy to bridge to c++, and is cross platform (non mobile at least). I would not have recommended a non-native approach until recently, but for what it is worth, I've come to realise this is one of the better options available these days. YMMV. Sam On Tue, 1 Oct 2019, 06:09 Jens Alfke via Cocoa-dev, < cocoa-dev@lists.apple.com> wrote: > > > > On Sep 30, 2019, at 8:16 AM, Robert Walsh via Cocoa-dev < > cocoa-dev@lists.apple.com> wrote: > > > > however, to use it to do anything other than building a desktop or IOS > GUI application seems to result in code with messy syntax and what seem to > me to be hacks in order to bridge between NS* and CG* code. (Lots of casts > and strange machinations for massaging pointers.) > > This is true when calling C code from any language that isn't based on C > :) Bridging between different languages is not a simple thing (I've done a > lot of it…) Take a look at how you call C code from Rust, Go, Java,Python, > etc.; it's at least as complex. > > > Also, as you've said Swift makes cross-platform development nearly > impossible because, even though Swift itself is available on other > platforms, the pre-built components that prevent the developer from having > to reinvent every wheel from scratch are not. > > This is true, but getting less so. There's pretty good support for > server-side Swift now, apparently. > > Both of these are complaints about the immaturity of the Swift libraries, > not about the language itself, and the good thing is that libraries are > much easier/faster to build than languages. > > —Jens > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/thesquib%40gmail.com > > This email sent to thesq...@gmail.com > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on ARC
> Le 30 sept. 2019 à 17:16, Robert Walsh via Cocoa-dev > a écrit : > > > Swift may be the solution, but it's built on a weak foundation. It makes > cross-platform development almost impossible. The TIOBE index shows Swift > declining (and Objective-C increasing). So, maybe it isn't. > > I don't yet have a lot of experience with Swift, but I would already argue > that Swift is not the solution. Swift is cool and has some really neat > features that make for good presentations and blog posts (where the > real-world issues and constraints associated with interfacing to other > systems, particularly older ones that do not use HTTP, can be minimized or > eliminated entirely); however, to use it to do anything other than building a > desktop or IOS GUI application seems to result in code with messy syntax and > what seem to me to be hacks in order to bridge between NS* and CG* code. > (Lots of casts and strange machinations for massaging pointers.) I'm in the > process of converting an application written in C++ using an older version of > Qt because the Qt code relies on Carbon (which has been removed from > Catalina). The new code is in Swift. I've written and maintained code that > uses UNIX-style C sockets for many years, but finding a native approach for > plain sockets in Swift was very > difficult. There appears to be good support for async HTTP communication, > but not much for socket-based TCP. SwiftNIO is protocol agnostic, and let you manipulate any data stream as you like. Moreover, it is cross platform (unlike the lower level Network Framework, which is far superior to using unix socket IMHO, but can’t be use for cross platform dev). ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on ARC
> On Sep 30, 2019, at 8:16 AM, Robert Walsh via Cocoa-dev > wrote: > > however, to use it to do anything other than building a desktop or IOS GUI > application seems to result in code with messy syntax and what seem to me to > be hacks in order to bridge between NS* and CG* code. (Lots of casts and > strange machinations for massaging pointers.) This is true when calling C code from any language that isn't based on C :) Bridging between different languages is not a simple thing (I've done a lot of it…) Take a look at how you call C code from Rust, Go, Java,Python, etc.; it's at least as complex. > Also, as you've said Swift makes cross-platform development nearly impossible > because, even though Swift itself is available on other platforms, the > pre-built components that prevent the developer from having to reinvent every > wheel from scratch are not. This is true, but getting less so. There's pretty good support for server-side Swift now, apparently. Both of these are complaints about the immaturity of the Swift libraries, not about the language itself, and the good thing is that libraries are much easier/faster to build than languages. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on ARC
Swift may be the solution, but it's built on a weak foundation. It makes cross-platform development almost impossible. The TIOBE index shows Swift declining (and Objective-C increasing). So, maybe it isn't. I don't yet have a lot of experience with Swift, but I would already argue that Swift is not the solution. Swift is cool and has some really neat features that make for good presentations and blog posts (where the real-world issues and constraints associated with interfacing to other systems, particularly older ones that do not use HTTP, can be minimized or eliminated entirely); however, to use it to do anything other than building a desktop or IOS GUI application seems to result in code with messy syntax and what seem to me to be hacks in order to bridge between NS* and CG* code. (Lots of casts and strange machinations for massaging pointers.) I'm in the process of converting an application written in C++ using an older version of Qt because the Qt code relies on Carbon (which has been removed from Catalina). The new code is in Swift. I've written and maintained code that uses UNIX-style C sockets for many years, but finding a native approach for plain sockets in Swift was very difficult. There appears to be good support for async HTTP communication, but not much for socket-based TCP. I found some examples on the web that were built around Grand Dispatch, but that feels clunky in a command-line application. Further, the many versions of Swift complicate the examples; if the example code was written in Swift 2 or Swift 3, it may require non-trivial modification to work in Swift 5 without compiler errors and warnings. I've settled on using a library from IBM called BlueSocket with a thin wrapper around it, and that seems to be working for me for now. However, even using the command line tools (swift package) for creating and managing an XCode project with external library dependencies has been for me a challenge. XCode and the packaging framework seem to be fighting over control of the project's structure, and going back and forth between them (and regenerating the XCode project each time) is tedious. But then maybe I'm just not using the tools corre ctly. Also, as you've said Swift makes cross-platform development nearly impossible because, even though Swift itself is available on other platforms, the pre-built components that prevent the developer from having to reinvent every wheel from scratch are not. This app I am rewriting _was_ cross-platform when it was built with Qt, but it will no longer be when we rework it for Swift. (And we are motivated to use Apple's "approved" language and tools in order to be eligible for developer support in the event that we need it. Our experience has been that they will not help, even with an Apple Developer subscription, if the app is in pure C/C++ or Java or anything but Swift or Objective-C.) It could simply be that Swift is the wrong tool for my current task. However, I'm not sure what would be. This could be done in Java or Python or Javascript with Node or any number of other mature, cross-platform options, but those aren't really welcome as first-class citizens in the Mac app space (or at least result in solutions that potentially require a lot of manual intervention on the part of the user). It could also be done in pure C, but that seems like a step backwards. I'm not down on Swift; as I said, I think it has some really neat features and constructs, and I'm sure that making a desktop or IOS GUI application is its sweet spot. I just wish there was a solid option for those applications (or application components) that are outside that sweet spot. Rob Walsh ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on ARC
> On Sep 27, 2019, at 1:21 PM, Jens Alfke wrote:
>
> I was typing a lengthy answer, but it occurred to me it's basically the same
> reason why Apple didn't release macOS for generic PCs ('hackintoshes') and in
> fact actively made it difficult for anyone to port macOS. It's because it
> would damage or tank their hardware business. To a lesser degree, if it's
> just apps being ported and not the whole OS, but still significant I think.
>
> Porting your software crown jewels to run on commodity PC hardware is
> something only a failing company does, when it's throwing its own hardware
> business overboard. Consider NeXT and Be. (And I believe Amiga was planning
> something similar before they went under.)
>
> Anyway, these days Windows is only for cash registers, accountants, and
> basement-dwelling hardcore gamers. ;-)
There a lot of business users still on Windows. Adobe, AutoDesk, and other
large organizations have dual track development for Mac and Windows but this is
hard for a small developer.
The computer aided design software that Apple engineers use to design their
stuff is Unigraphics NX which runs on Windows and on the Mac under X11 because
NX has a Unix heritage. So I don't think you will ever see the day that the Mac
drops support for X11. The point is there are still business segments, users
and developers that benefit from cross platform high performance desktop apps.
In 1998 Apple was more than ready to give away the crown jewels with the
Rhapsody Yellow Box but Adobe made them change their mind when they refused to
port Photoshop. Subsequently Apple changed the focus with Mac OS X and removed
the cross platform offer. I think one of the major reasons was the amount of
time they spent writing Core Foundation and Carbon. Perhaps they didn’t want to
stretch their resources thin by also supporting Windows apps.
--Richard Charles
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Thoughts on ARC
> On Sep 27, 2019, at 9:20 AM, Richard Charles via Cocoa-dev
> wrote:
>
> What I wish Apple would do is release a cross platform Objective-C (and
> Swift) solution. ...
> The Mac vs Windows war is over and long gone so why doesn’t Apple help out
> the small developer and release a cross platform solution.
[OT]
I was typing a lengthy answer, but it occurred to me it's basically the same
reason why Apple didn't release macOS for generic PCs ('hackintoshes') and in
fact actively made it difficult for anyone to port macOS. It's because it would
damage or tank their hardware business. To a lesser degree, if it's just apps
being ported and not the whole OS, but still significant I think.
Porting your software crown jewels to run on commodity PC hardware is something
only a failing company does, when it's throwing its own hardware business
overboard. Consider NeXT and Be. (And I believe Amiga was planning something
similar before they went under.)
Anyway, these days Windows is only for cash registers, accountants, and
basement-dwelling hardcore gamers. ;-)
—Jens
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Thoughts on ARC
> On Sep 27, 2019, at 6:19 AM, Turtle Creek Software via Cocoa-dev > wrote: > > We used an object database called NeoAccess for our 32-bit C++ app. It had > reference counting for objects retrieved from the database. Setting the > ref count manually was extremely easy to screw up. It was hard to debug > off-by-ones on the ref count. So we made those calls private, and replaced > them all with a stack-based watcher class. It adds a reference in the > constructor, and removes it in the destructor. Simpler, more reliable, and > exception-safe. > > It makes sense that Cocoa programmers much prefer ARC to MRC. Doing it > manually is easy to break and hard to debug. However, the fact that ARC is > not exception-safe concerns me. It suggests that Cocoa still manages ref > counts manually, somewhere under the hood. We've had two sets of mystery > deallocs that both involved NSTabView. From hard past experience, I would > bet there is a bug lurking somewhere inside there. Traditional Cocoa manual memory management relies on naming conventions and just a few basic rules. When combined with the Xcode static analyzer it is almost pain free. However it is not as Swift as latest thing. > In fact, assuming that Cocoa is written entirely in plain C, it may not > even be possible to avoid manual ref counts. No STL, no RAII, no native > exceptions. It makes sense to write kernels in C because speed is > important. But GUI frameworks are way more complex, and C may just not be > the right tool for them. Objective-C is plain C with a runtime and a few syntactic additions. The big and beautiful thing about Cocoa are frameworks which are written in Objective-C and now Swift. > I'm no fan of garbage collection, but those languages do make programming > easier. There's enough other stuff to worry about. It's why Java & Python > are so popular. > > C++ makes the programmer fully responsible for memory, but the modern STL > really helps. It's improving rapidly. Even when C++ breaks, it's easy to > debug object lifetimes. Just put a breakpoint in the destructor. If it's > dying too soon you'll see exactly what killed it. If a leak it will never > get there. > > Our company sells to construction companies. Our expertise is in > accounting, estimating and other construction business tasks. We need a > platform that lets us create apps quickly. Cocoa is not that. We've spent > 3 years so far on 64-bit porting via Cocoa. Best guess is another year or 2 > to get it perfect. Meanwhile, we should be adding features to keep up with > the Windows competition. It appears like your biggest challenge is porting a 32-bit C++ third party library and porting Carbon to Cocoa? Moving from 32 bit Cocoa to 64 bit Cocoa should not be a big deal. What I wish Apple would do is release a cross platform Objective-C (and Swift) solution. They already transitioned from PowerPC to Intel and ARM. iTunes at one time was released for Windows. One programmer almost did this single handedly with the Cocotron. It was so well written and comprehensive that Microsoft picked it up and started using it for their WinObjC framework. The Mac vs Windows war is over and long gone so why doesn’t Apple help out the small developer and release a cross platform solution. > I don't know if anyone from Apple is on this list, but I think Cocoa needs > a huge overhaul. It's 30 years old and showing its age. The problem is > not just memory management. The constraint system is extremely difficult- > we've spent many days futzing with it, and there are still mystery > problems. Pretty much everything else is more creaky and awkward than it > could be. > > Swift may be the solution, but it's built on a weak foundation. It makes > cross-platform development almost impossible. The TIOBE index shows Swift > declining (and Objective-C increasing). So, maybe it isn't. > > It would really help if programmers could write Macintosh apps in C++, > Python, etc. Apple did a language overhaul with Swift. My primary app requires integration with C++ so I have stuck with Objective-C and Objective-C++ and the traditional Cocoa frameworks. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on ARC
On 27 Sep 2019, at 14:19, Turtle Creek Software via Cocoa-dev wrote: It makes sense that Cocoa programmers much prefer ARC to MRC. Doing it manually is easy to break and hard to debug. However, the fact that ARC is not exception-safe concerns me. Cocoa in general is not exception safe as the policy is to only use exceptions for programmer errors such as accessing an array with an invalid index, therefore any exception thrown in production is likely to cause problems, leaking an object, which is the effect of ARC’s lack of exception safety, is not going to make much of a difference. You can however make ARC exception safe by passing `-fobjc-arc-exceptions` to clang (default for Objective-C++ code). It suggests that Cocoa still manages ref counts manually, somewhere under the hood. The compiler will insert retain/release calls where necessary, so yes, retain counts are still used, as with your smart pointers in C++, it’s effectively just compiler generated constructor/destructor code to perform the retain/release (with a few optimizations). ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
