Open note to David Mitchell & Bob Pritchett

Hello.

I would like to respond to the comments which you have made to my original posting 'Let's request Logos 4 Mac to be more Mac like 3) Ditch 'Mono' and 'go native' found here (http://community.logos.com/forums/t/12648.aspx)

Firstly, from my side, I must apologise for the title of my original posting. On reflection it could have been misread to be a bit inflammatory. That was not the intention, and certainly it was not intended in any way to run down the effort which I am sure the team is doing to bring out Logos 4 Mac.

Having said that, I was somewhat disappointed (annoyed actually) when, after David replied to my posting with the words "the official and final word on the topic" and then, for good measure locked the posting, someone else from Logos (I believe the head of the company) also added a comment to which, basically (in that post), I have no possibility of reply. I believe you would agree that that is not 'a level playing field'. Hence this posting.

Next I would have to say that these valid questions (and concerns) about Logos 4 Mac would not keep recurring if perhaps there had been a more clear communication of things to start with. I still don't believe there has been adequate communication and/or some of the information is somewhat misleading. Again, hence this posting.

From a technical perspective I believe (and obviously happy for any technical clarification) that the design basically is as below - I made this graphic:

The Mac application communicates to the .NET application using Mono as the intermediate 'translation' layer. The .NET application, and this is one of the areas which I believe was not previously clearly communicated, is solely the 'engine' which communicates with the 'database' of book resources. So, if I am correct in my understanding, it is now being stated that Logos 4 Mac has three development components:

The .NET 'engine' which interfaces with the Libronix book database - the coding for this is essentially complete and is a shared code base with Logos 4 Windows.
The Mono translation layer which sits between the .NET 'engine' and the 'native' Mac (Cocoa) application. This Mono layer being utilised, and extended by Logos, is stretching the capabilities of Mono (as reported on the forum).
The Mac application, incorporating the full user interface, which is being coded from scratch as a native Mac (Cocoa) application. This is the part which perhaps some customers don't realise how much work is involved because it is not the same code as Logos 4 Windows, it is new/extra, from scratch, code. This naturally would take some time, it's not a small application.

What is the same code is only the .NET 'engine'.

The Windows application, on the other hand, being on Windows (the native .NET platform) is essentially a fully 'native' end-to-end .NET (?) application using .NET for the engine and UI component (?) and could be graphically represented thus.

I understand, and sympathise with what I am sure was a (difficult) business decision for building the Mac application in this way. Obviously I believe everyone would agree that naturally, wherever possible, Logos does not throw away many man-years of development poured into Logos 4 (a great product BTW). And everyone would understand that historically Logos has investments in the legacy Windows OS (legacy referring to the Windows operating system, not Logos 4).

I sincerely hope, for Logos' and our sakes, that it works out. Building any application utilising translation layers would be a challenge, throwing out lots of code is also not a palatable option. The point that I made in my first post is still relevant. I did not say "slow" anywhere in my post - I said "not optimal". And it is not optimal because it is not, like the Windows application, a top-to-bottom native application. I just trust to the skill of the Logos programmers that this design will not result in 'slow'. That would be a disappointment to Mac users who also have significant investments in Logos - mine is already upwards of $ 2,000 and I am pointing other people to Logos 4 Mac/Windows.

I have to say that find it a bit strange that David runs down the Mac/Cocoa development platform, and then confirms that it is that platform which is being 100% used to create the UI (user interface) of Logos 4 Mac. Sorry, I can't agree with you David on the point of the Mac development platform and/or Mac vs Windows generally so we will have to agree to disagree.

Finally, with respect to choice of Mono, I trust that that will not a decision which backfires. I, and many many others, would not 'bet the farm' on Novell or anything Novell sponsors. Especially as Novell is, shall we say, beholden to Microsoft.

With Mono it is not at all the situation of "burning down the house because we don't like the siding", but the possibility of having to tear down the whole building because the foundations are flawed, or someone comes along and says you're not allowed to use that type of foundation.

We all hope for the best, and look forward to enjoying Logos 4 Mac for years to come.

p.s. I see visitors can lock postings also - as I have no intention in this becoming a overheated discussion I have locked this post so only Logos staff can do anything with it.

Find more posts tagged with

Comments

Bob Pritchett

We're not trying to squelch any conversation here. I hadn't noticed that the thread had been locked (I confess, I didn't know our forums could do that!), and we won't be doing that in the future.

I think it's fantastic that our users care enough about our application to want to argue the technical implementation details, and I'm happy to do that. But it seems, especially on the Mac platform, that people take it too seriously, and start to get into arguments that are more political (which company you're aligning with) rather than technical.

Personally, I'm interested in the business arguments first, the technical second, and the political last.

The business argument for our approach is that I don't want to double our software development costs to reach < 20% of the market.

If we re-write our app from the ground up, 100% Objective-C/Cocoa, we'll have to write every single line we wrote for Windows again on the Mac.

There's some small savings in re-using the logic and architecture, but basically it'll take the same time as writing it the first time.

If we can use Mono to share 85% of our code on both platforms, we take our development costs on the Mac to about 20% of the costs to develop the Windows application. That's a multi-million dollar savings.

Of course we don't want to go down a dead end, so we've carefully investigated the technical and political issues, and we aren't using any technology piece we're worried could be "snatched away".

I don't have time to make cool graphics, but, here's a character graph of the workload:

With Mono: +++

W/O Mono: ++++++++++++++++++++

Plus, by sharing code, we ensure that we don't get incompatible data files, subtly different logic, etc. and bug fixes /improvements to our core functionality only need to be done once, in one place.

As for the "translation layer" argument... yes, this is always a concern. But everything on a computer goes through multiple translation layers. Objective-C is compiled to assembly, and then it's run on a processor that itself has instructions written in microcode, which is itself on top of transistors. The more abstract your top layer, and the more layers you have, the more you may (not always) have performance issues, but the faster your coding is. It's a trade-off; we know we could make the whole app faster if we coded it in assembly, for example, but we'd need another 20 years.

And the graphics presented aren't really correct. .NET is an abstraction layer on both Windows and the Mac. The native Windows platform is Win32, and .NET is run on top of that. Now "just-in-time" compiling is replacing some of the translation layer, and optimizing performance, but on the Windows platform we're still calling .NET functions that in turn call Wind32 functions, where we used to call Win32 directly. So using a .NET layer on the Mac isn't really any different, or less optimal, than using it on Windows -- we're doing the same thing on both platforms: using a higher level, more abstract platform in order to get a more optimal development process.