Today I came across a UI design from Microsoft that made me laugh, so I thought I would share it.
Archive for the ‘Uncategorized’ Category
Today I was listening to the 50th podcast @ Delphi.org where Jim McKeeth again brought forth the idea of Managed Code being the future, and JITing for the CPU of the device being better than native compilation in advance. While I agree with the latter to some extent, I certainly don’t agree with the former. I think it’s safe to say the vast majority of OS/X and iOS applications are written in ObjC and compiled to native code. Native is still king in many camps, and even Microsoft is bringing sexy back.
IMHO managed code is not very well managed. What I mean by that is, every time you load a managed EXE, the code contained therein, is JITted for your CPU. This increases startup time, and CPU load every time you run it. Even today, .NET applications start up slower than a Delphi application compiled for a native target. Most businesses have standard, relatively current hardware so you don’t have to worry so much about whether to target Pentiums with floating point issues. You can target current generation CPUs and still get decent optimization. Perhaps not as good as some IL JITters, but good enough, and you don’t need the Jitters to already be installed on the target machine. What native compilation without garbage collection does, is force the developer to think more about managing lifetimes, and making efficient use of CPU cycles. The more abstract the language and framework, the harder it is to truly understand the cost of implementation decisions, which only adds to the memory bloat and performance problems that are the scourge of software development.. The resurgence of native compilation seems to indicate that even .NET has gone full circle just as Java did. It’s great for interoperability, and on the server side, but not the end all be all for XPlatform, or client applications. Native toolkits still have their place, which is great news for EMBT, and has been reflected in their recent sales figures.
Back in the days of the Dec Alpha and WinNT 3.51, you could choose to convert an EXE compiled for an Intel x86 CPU into an EXE native to the Alpha. That was done once, and from that point forward you saw the true performance of the Alpha chip. Unless the EXE changes, or the user changes their CPU, there is no point in re-compiling the EXE, therefore JITting should really be a deployment activity. IL is merely a method of delivering application code in a CPU agnostic way, the same as Google’s PNaCl used as part of their NaCl. If the CPU market was more fragmented and there were OSes that ran on multiple platforms using different CPUs, I could see a real advantage to JIT compilation. As it is now, in the worst case scenario you generate a couple different versions of your EXE for the popular instructions sets, and you’re good to go.
As for whether the UI is native or not for the platform, really depends on the platform. Sometimes having a unique, or non-standard UI helps differentiate your product. Sometimes it’s plainly not acceptable to the users on that platform because it doesn’t adhere to platform conventions. That’s just another choice a developer has to make when choosing a toolset. What’s nice, is to have choices that don’t necessarily box you in. That’s why it would be great if EMBT would support ObjPas on the Mac without FireMonkey. If you don’t want to learn ObjC, prefer pascal syntax, or have a lot of Pascal code you want to leverage, you would have another option to produce a native UI on the platform. I don’t know that this would make sense for EMBT financially, but they could certainly help the open source community make Pascal a first class citizen again on the Apple platform.