Comment by primitur | Hacker News Reader

Comment by primitur | Hacker News Reader

Parent Full thread

C pretty much still Rules the System Layer. Its never going to go away for as long as its easy, and efficient, to write very good C code which performs well. In spite of the hate, there is a lot of really good C code out there still running, still working, still burning up the market. I'm pretty sure there's nary a system image which doesn't, eventually, get itself operating per the rules of C, for the most part, somewhere ..

That said, for all your very valid points about Objective-C, the same (essentially) can be said of Lua, and the Lua VM, for example.

As a mobile developer, I'm no longer interested in Objective-C - its only an Apple Language. But I can take the Lua VM and put it on all the other machines, host-wise/parasitically, and create my own internally ordered Framework which runs on all Platforms, and still gain a lot of the benefits of a re-evaluation of 'language simplicity' versus programmer effectiveness.

After 4 years of Mobile development on iOS and Android, where multiple projects have blossomed organically into unwieldy godawful trees of complexity which prove, every day, even more difficult to turn over to other programmers, themselves creating massive WordSpaceCollections: ofCode.to_BeMaintained((Some*)Way) || Other { NSLog("grr..", &etc} ;

On a Drama Scale, it goes like this:

"Oh, Android NDK/SDK, how you have blossomed to being something I regret I am not putting into the trash in the early days. XCode, you %(#@&% Asshole piece of software, Why I Gotta Download CMDLineTools just to get work done"

..

"SublimeText2, factory settings .. Open Folder->".lua files", build and distribute for MacOSX, Linux, Windows, iOS, Android, and still only need to maintain one codebase.

tl;dr - You can't do that with Objective-C.

This seems like a long way of saying that you don't like Objective-C because it's not cross platform, and that you've decided instead to write all your mobile code in Lua and to maintain your own abstraction layer onto MacOSX, Linux, Windows, iOS, and Android.

The question I was responding to was simply whether there are compelling reasons for Apple to use Objective-C.

Supporting cross platform native development is clearly not a strategic goal for them.

I think I'd add another reason - which is that they are in control of the evolution of Objective-C.

I'm really more trying to point out that there is a great way to escape the trap being laid for you by Apple and their plans for Objective-C, which is indeed to keep the language in their own privileged domain.

And it really is important enough that anyone considering learning Objective-C today, or even using it, know that there is a way out of it: roll your own walled garden and plant what you like within it, on any platform you can.

I would be willing to wager a small bet that says that the scripted-VM-glommed-in-a-web-of-libs approach to the Platform wars will become more and more a key survival strategy in software development over the next 2 years.

The OS, and indeed Distributions are dead; long live the new King, VM-managed library bundling..

I'm not sure what you mean by 'keep the language in their own privileged domain' actually means, but I do agree that it is Apple's strategy to invest in Objective-C above other languages on its own platform, and that they have no investment in making a cross-platform framework other than HTML5.

I don't see why you describe Apple's approach as a 'trap'. They are providing a lot of software components that save effort for those who use them. The results are platform specific, but everyone who uses them knows that and chooses to make that tradeoff intentionally.

What you describe as "VM-managed library bundling" sounds a lot like "building your own platform out of open source parts and maintaining a compatibility layer to your target platforms".

That strategy works for a few of the largest most-well resourced projects - e.g. the browsers Firefox, Chrome, Safari, Opera etc, plus the Adobe Suite, and even these draw criticism for the results not being as good as they could be if they focussed on one platform.

Something like this works on the web too - where people assemble a 'platform' out of javascript libraries - because the base platform simply doesn't provide enough.

I don't see it being a viable strategy for a small team or an individual developer trying to build native applications though because of the amount of time you'll spend keeping the compatibility layer up-to-date with the rapidly changing underlying platforms.

Run with the pack and eventually become de-marginalized on the slippery platform being controlled by Apple, or work a bit harder and gain traction on every platform you can. This has always been a strategic decision for developers, large and small groups, and both paths have their merits and pitfalls. Neither is a guarantee of success.

Also, its not as hard to "keep the compatability layer" up to date as you state .. you need to do it anyway, if you use the vendor-provided native tools. If you can do that, you can take it one step further, and maintain a very productive outer-shell over the trap-tools. That can be a very good strategy, or a poor one; all the examples you provide may be the larger failure cases, but there are smaller success cases underlooked in your argument .. MOAI, Love2D, GamePlay .. these are all coming along to eat the Native Development Devotee's lunch ..

Reply on news.ycombinator.com