Comment by rcarmo | Hacker News Reader

Comment by rcarmo | Hacker News Reader

I coded in Objective-C back in the NeXT days, did various (small) Cocoa and iOS apps and still use Macs daily - but work at Microsoft now.

Despite my own personal plights with small desktop utilities I write now and then, I don't think Apple has broken Cocoa _that much_ or that it is untenable for a small company to ship cross-platform desktop apps these days (never mind Electron, I'm talking about toolkits like Qt, Xamarin, etc.). _Especially_ if their core functionality can be cleanly detached from the UI.

I poked around a bit to figure out the detail to which the software does estimations, and it does seem like there is a very complex UI:

https://www.turtlesoft.com/Images/Goldenseal%201024x768.jpg

...but I keep wondering how much of it could be abstracted away by a cross-platform toolkit, and what kind of separation there is between the estimation/modeling code and the UI itself.

We'll never know without a good overview of the internals, but my guess (based on looking at many internal corporate apps over the years, from the pre-web days) is that this evolved organically over time and built up technical debt by literally following UI abstractions rather that isolating their core code from it.

> Goldenseal was written in C++, using the CodeWarrior Pro development environment. We used the PowerPlant application framework (part of CodeWarrior). The layout for some windows was done using Constructor (also part of CodeWarrior). CodeWarrior is a great program. Thanks, Metrowerks!

> The basic database features in Goldenseal are based on NeoAccess, licensed from NeoLogic Systems. Unfortunately we ended up re-writing a large percentage of the code there, which explains 6 or 8 months of the delay in our shipping date.

> We have used OOP (object oriented programming) throughout Goldenseal. It's a very good programming model which makes it easy for us to add new features, without getting lost in the 5+ million lines of code that the program now contains. A lot of that is comments and spacer rows, but it still represents many programmer-years!

> We estimate that about 50% of the code is for the basic interface—screen display, file management, mouse behavior. About 25% handles data storage for the many object classes, and 25% handles posting, action dialogs, basic accounting and estimating features.

https://www.turtlesoft.com/Goldenseal-Software-Reference/Sof...

That is a bunch of Buttons, Textfields, Dropdowns and Listviews? How hard can that be in Cocoa?

In their blog post they said they worked for three years on the Mac version ... maybe the company is just one person not having much time or coding experience. Maybe I am underestimating the problem, but in my time they would have just hired a student or the nephew of their neighbor to hack something together useful.

They also mention in another post that four different contractors gave up on migrating it, three targeting Cocoa and one Qt. Maybe the codebase is brittle and hard to work with and not really worth the effort.

Without using their software, and just going based off of screenshots, I don't see anything that couldn't be ported to Qt fairly easily.

Now if there is a lot of intertwined code that makes the UI less portable, that's another issue, but I currently don't see how their UI layer could be so complex as to not be easily shifted to Qt.

The cross platform nature alone would be worth the cost in my opinion.

Or even electron (gasp). The application looks like simple webpages.

It might even work better as a web site, so the customers don't have to worry about backups, sharing data, etc.

Or just go the whole way and make a virtual machine

http://fabiensanglard.net/anotherWorld_code_review/

>...but I keep wondering how much of it could be abstracted away by a cross-platform toolkit, and what kind of separation there is between the estimation/modeling code and the UI itself.

Apparently they tried QT in 2015: https://turtlesoft.com/wp/?p=198 .

Reply on news.ycombinator.com