Thoughts on productivity
Thoughts on productivity
- Subject: Thoughts on productivity
- From: Turtle Creek Software via Cocoa-dev <email@hidden>
- Date: Thu, 24 Oct 2019 09:04:47 -0400
TurtleSoft has shipped software built with 3 different programming tools:
Excel, HyperCard and CodeWarrior C++/PowerPlant. We started but abandoned
projects using 4 others: FileMaker, Omnis, Serius Developer and Think
Pascal/C++/TCL. There were another 6 app-development tools that we bought
and poked at for a while, but decided not to use. Cocoa's status is still
pending.
I've been thinking about what it was that made some platforms work well,
and some not. Rather than anything specific, it pretty much came down to
productivity. With some tools, we chugged along steadily and eventually
shipped software. The rest bogged down for one reason or another. When a
product release started looking too far off, it was time to bail.
Programming seems like one of those things that works best in a state of
"flow". Get totally focused and immersed. In the groove. It's possible to
get a lot done in that state. One phone call can kill it. So can getting
stuck on a problem. If you have to wander too far looking for a solution,
your concentration shifts elsewhere and it can be hard to go back.
In the 3 years moving from Carbon to Cocoa, we got stuck many, many times.
Surprisingly, it wasn't just a learning curve. The frustrations were
remarkably constant. It may even have grown harder with time, rather than
easier.
I'd estimate that our time with Cocoa was about 25% highly-productive flow
state. Looking back, Excel macro programming was about the same, but
spreadsheet setup was much faster. HyperTalk and C++ ran about 90%
high-productivity.
Here's where we stumbled the most with Cocoa:
1. Documentation. Class and method naming is usually quite reasonable in
Cocoa. But when something was confusing, online docs rarely helped. Too
often, they either stated the obvious, or linked to lengthy theoretical
background. To stay productive, what we really needed was usage examples,
code snippets, warnings about pitfalls. Sometimes deep knowledge is
worthwhile, but sometimes you just need a bit of code to copy/paste.
2. Example projects. Apple has a good selection, but most for Mac are
outdated and useless. Many don't even run. Some show features that are
nifty, but deprecated. Anything recent is Swift-only, and usually iOS
rather than Mac. Sample code from blogs has the same problems. Cocoa is
complex enough that it really helps to run working examples. Jump-starting
with existing code saves days or weeks, and keeps the workflow going.
3. Nibs. The graphic "GUI builder" environment is a great idea in theory,
but overly complex in practice. Too many minor settings with unexpected
consequences. Too hard to debug problems caused by small errors.
Constraints were a constant hassle. Woe to anyone needing to add a new item
in the middle. I suspect that nibs and storyboards are supposed to let
non-programmers create an entire app without writing code. Two of the tools
we abandoned (Serius and Prograph) had a similar goal, and both were
disasters. Text is easier to read. Easier to comment and debug.
4. Memory management. I complained about this previously. ARC sounds great
in theory, but it's too complicated in practice. Our C++ code rarely
crashes. It had just one small memory leak, hidden somewhere in
PowerPlant's LWindow (now removed). In contrast, we wasted too much time on
mystery deallocs in Cocoa classes. There are too many subtle ways to create
leaks.
5. Missing features. Cocoa includes all the basics and more, but there were
small deficiencies which made it more difficult. The first one that bit us
was NSComboBox not having a way to restrict choices to existing items only.
Apple's docs mentioned that it was possible, but we never found a way to
make it work, despite help from this list. Multiply that by 100. I get the
sense that most Cocoa features were created to run Safari, Finder, Preview
or some other Apple product. Not enough focus on the needs of folks who
develop other types of apps.
6. Changes too rapid. The assumption seems to be that Mac and iOS
developers should rewrite code frequently. That alone is more than some of
us can afford, but the pace of change also made problem-solving more
difficult. It was the root cause of problems #1 and #2. There is a whole
ecosystem of bloggers and Stack Overflow contributors who provide free
support for iOS and macOS, but they can't keep up. As a result, most online
help is outdated and unreliable. BTW Microsoft seems to err in the opposite
direction. They rarely toss anything, so their dev tools are a confusing
mess of options and duplications. Surely there is a sweet spot somewhere in
the middle?
7. MVC needs a more cooperative C layer. Right now the Cocoa controller
classes work fine with outside model code, but they don't coordinate well
with an outside controller. I think the key might be to have deeper access
to event handling within NSWindowController and NSViewController, but
that's just a guess. It would take some experimenting to figure how best to
connect Cocoa and C++ controllers. Linking the C's is particularly
important for cross-platform work, because Microsoft uses MV rather than
MVC. They have an MVC add-on for ASP.net, but not for MFC, and apparently
not for their other frameworks. Please correct me if I'm wrong on that.
Developing for Windows means writing your own controllers, and it would
really help if they didn't need a rewrite for Mac. This may also apply if
coming from PowerPlant or Carbon.
In general, Cocoa seems well-designed, with many extremely useful classes.
I think it's better than anything from Microsoft. More powerful than
PowerPlant. But there were enough impediments that it became a long,
painful slog that never improved. Not enough time spent on productive
programming.
Is there a way to fix this stuff? Changing Cocoa online docs into an
Apple-curated wiki might help with #1. Then people actually using Cocoa
can share their experience. Add code snippets, warn about the quirks and
gotchas. Like this list does, but more targeted and accessible.
For the rest, Apple really needs to listen to developers more. These days,
Cocoa is pretty much the only tool that creates native software for Apple
hardware. It ought to be more developer-friendly. That's why this wheel is
squeaking. We hope to be back on Cocoa in a year or two, and hope it will
be easier by then.
Casey McDermott
TurtleSoft.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden