Saturday, March 19, 2011

How not to appraise your competitors

How not to appraise your competitors
Your reviewer was looking at the Delphi Product Manager's blog, Mr. Michael Rozlog(1) and wondered if he was preaching to the choir(2). Mr. Michael Rozolog's blog goes two ways - writing opinions "Mobile will be a possible future" (which may be true) but the second one your reviewer do have opinion against: bashing competition. Posts like "Top 10 technology predictions" in the guise of promoting future, "Java is the cobol of the 90's" which bash Java.

Does the Emperor have no clothes in the future?
When you preach to the choir - you can make all sorts of insults towards other competitors, that they are no good, that their products are useless and will not help you. You can make assertions that your product is the finest development tool in the whole world and buying this product will make you hundreds of thousands (of dollars), if not millions (of dollars). You can make all sorts of claims, misrepresentations and allegations. But this is the real world, the world does not revolve around Delphi, it does not revolve around Embarcadero and if you cannot provide a working and affordable solution, there are other vendors hard at work to provide working and affordable solutions.

Your reviewer sees the usual pulpit preaching that other solutions are bad and Embarcadero's solutions are superior. Posts like "Java continues to be the Cobol of the 90's", "3D gaming technology is not the next big thing yet", "Top 10 technology predictions of the future" sounds like advising on all things you should not do with Delphi.

Sounds more like:
- Avoid 3D because Delphi's floating point and 3D libraries are not up-to par. Even Chris Benson wonders why the same EXE built with a physics engine ported to Delphi is much slower in Delphi.(3)

- Avoid TCP/IP SOAP stacks because RemObjects SOAP interop requires you to buy RO SOAP for NET or Java because the RO SOAP client/server serves up non-compliant SOAP packets whereas JavaSoap and NET SOAP interop with each other.

Corrections Requested
Your reviewer corrects some of Mr. Michael Rozlog's predictions with realistic assumptions:

- Native Development will be "in the game" again. He argues because of the smartphone booming. The hard issue is that he wants to make a logical fallacies framework: if you will take that Native Development will be the future, you will think in general that Delphi will be great. Also he states things that are true for VM in particular too: the idea that you can use whatever your OS can bring.
To be fair, there are places where native development do matter: performance critical parts of code. Games are the best frame to say so, bot to say in perspective, here is where Delphi as performance do not shine. Anyway, Mike was kind enough to estimate that games are not what it will happen. Many things changing native development (as of Win32/VCL)  are dead for some years. Your reviewer not here to say that it will disappear, but as of today reality are not that relevant. Is like if you write compilers you should know most likely assembly language, but never use it, excluding for that 10% that you have no other option (even in this case, you can write to LLVM or to VM's bytecodes, so rules are a bit different today).

Another area where "native development" matter is to achieve responsive guarantees that the a VM (mostly on underpowered device) is not always capable of. Anyway, this is different in many ways today, like Android uses a fairly decent VM (that have a JIT for some time), Windows Phone too, and in supported languages Delphi (or Delphi support) is not included.

Is Java really the next Cobol?
- Is it really Java a Cobol "replacement"? Why does Mike said things that he knows already, since he worked as the JBuilder Product Manager and he understands how Java works? He wants to promote his software that he's selling. At the end, he bashes the two platforms are competing Delphi at its heart: Java and .NET. Both are not as much as phone toys software, but are platforms that work on enterprise. Don't worry, he bashes one year before RIA (and he apologizes next year). that was another competition of Delphi: if you can distribute your application in browser, using either Flash, Silverlight or JavaFx, so you will not need Delphi anymore. Even you will use an HTML5 application, can become rich enough to not become RIA, browsers support that. Look to Facebook that you don't believe me or GApps (GMail, Google Docs, Google Calendar). Did you heard a Delphi's server side site that is widely used? Does anyone use JBuilder anymore?(3)

(Did anyone find a working, affordable and usable equivalent TCP/IP, HTTP, SOAP and RIA stack in Delphi?)

 Even Java did not released a big overhaul for some reasons as internal hardships (Your reviewer can argue that Delphi did the same from 2002 till Delphi 2006 making to stagnate as platform). Java is a platform that evolves and innovate. Is also much faster than .Net have to offer in raw performance and how applications scale. Delphi does not scale well server side as does not have support for 64 bits and huge heaps. Java and .Net offer mature support for 64 bits at least for 5 years to date. Java bring stable betas for at least 1 year as time. Some things may not be there for deployment, but everyone seems to love the message boxes that sometimes appear to Delphi application, and many complained on Delphi applications and libraries stability. JRuby is a very active project. Also GWT or Android could not exist without Java heritage, and they build and run and move as we speak.

At the end the problem is not about which platform is the best, your reviewer does believe that .NET is not a silver bullet, but on the other hand, Delphi as is today is not a better replacement for .NET.

Some things are missing in Delphi and as far as it seem for me, Delphi will lag behind more and more to "impress" people that will be long gone to .Net like platforms. AIR runtime for me at least appear a more mature distribution platform: a very small runtime to run, a fairly fast JIT that will generate for any web application an instant response, accelerated controls to: see movies, to make controls with easy workflows from Photoshop. Do you need speed for your HPC code and you cannot use Java as backend? You can call it from AIR by handling data via TCP. Theoretically Silverlight 4 let you call native code directly, if you allow it.

At the end, will Mike promote open ideas? Maybe never. As far as I'm concerned, probably your reviewer should not write this post, on the other hand, just thinking that making blunt statements at the end will hurt his blogging authority. Wanna see a more interesting and less biased posts? Look on Cliff Click(6) and Java in general, or Miguel de Icaza(7), or Linus Torvalds.

Your reviewer wonders why Mr. Michael Rozlog not praise his competitors? The Mozilla Team praises Chrome's JavaScript implementation(8)



Wanna biased talking persons, look also on Steve Balmer's quote: "someone will pay that much on an iPhone" he said... and people did.

Some of your reviewer's more accurate predictions vs. Mr. Michael Rozlog's predictions are:

1. It will be less usage of "native code" in enterprise word. People need to scale, a garbage collector give predictable throughput, a memory leak more  unlikely. Second problem is the software stack: vertical stacks are mostly in JEE or high level frameworks. And as C++ is hard, you will likely invest on a Ruby on Rails implementation or PHP implementation.
Talking about Garbage collection to Delphi developers is like talking to a lazy person who cannot check their own work because AQTime (standard) is massively crippled and requires US$599 for accurate profiling.

Did anyone hear about the Delphi developers who had a memory leak in the server application and the server applicate ate up 2 Gigs of memory before failing? Maybe nobody did because there are no Delphi embedded servers or lack of sales due to customers complaining about a big server app that eats-up 2GB of memory...

2. More applications will go towards browser-only, maybe HTML5: FF4, IE9, Chrome, Safari and Opera will have guaranteed JIT for all instances running your code. This will make clear that users will get a bit richer experience, maybe flash like from browsers.

3, "Going native" will happen probably on PHP server side, as Facebook's HipHop will get more traction and most of it's bugs will be fixed. No other platforms will likely get this path. Node.JS a Google JavaScript server side projects will get more traction for somewhat more complex server side part.

4. Google Go will be hit and still miss. Language sugar is not enough to change the world, just making interfaces minimalist will mean that some people may use it, still will not give to it momentum. As it have just C like integration, have no advantage to Java, C#, or Delphi on that matter.

5. A lot of Free to play game will appear. Browser based may use flash and integrated socially. Native ones will be free to play like MMORPG or so. The baseline will be connected and to one level social. The business model will change for a lot of games

6. (Your reviewer have just one biased prediction and is somewhat related with my project, but will happen your reviewer think for a lot of projects:) The tendency will be for people to integrate higher level platforms on top of old codebases. GCC is necessary for most people, sometimes reflection, a good code completion also helps. What your reviewer mean with this is that many giant applications will offer higher level platform interoperation: OpenOffice may rewrite some of the dialogs using  Java or Qt (this will be a 2012 prediction) to make the messy code to go away. Your reviewer predict this because your reviewer work on a fairly complex logic app. This application if was written in C++ was much less advanced than the C# today codebase. Your reviewer really think that similar codebase would require much bigger team and much more extensive tooling but with a lower market price.


(1) Michael Rozlog Blog. http://blogs.embarcadero.com/michaelrozlog/
(2) Idioms. http://www.phrases.org.uk/meanings/preaching-to-the-choir.html
(3) Box2D. Chris Benson's blog. http://chrisbensen.blogspot.com/2011/01/delphi-box2d.html
(4) JBuilder 2008 review. TheRegister. http://www.theregister.co.uk/2008/04/28/jbuilder_2008_review_rough_edges/
(5) HipHop. FaceBook. https://github.com/facebook/hiphop-php/wiki/
(6) Cliff Click's Blog. http://www.azulsystems.com/blog/
(7) Miguel de Icaza Blog. http://tirania.org/blog/
(8) David Mandelin's blog. CranShaft. http://blog.mozilla.com/dmandelin/2010/12/08/crankshaft/

3 comments:

Dev{eloper} Stonez said...

If you consider enterprise devel, you are right ... no much space left there for Delphi.

But if you think about the consumer market, Delphi is a very good tool at hand. I'm running quite a lot of small STANDALONE apps developed in Delphi (ex: TheBat!, HeidiSQL, ImgBurn ...etc) that are fast, portable and quite full-featured.
.NET and Java is not the answer in this "arena" ... and Delphi can get a foothold there.

The new AppWave Store from Embarcadero can also help to spread the Delphi usage

In my view, native devel is back on track, and here are some pointers to support this:

1) Google Native Client

2) Android RenderScript

3) Android NDK

4) C++ Renaissance at Microsoft

Hopefully, Delphi will be still relevant (with Embarcadero, is in a better shape anyway) with focus on RAD, x-plat and mobile (ARM compiler!)

And BTW, if you really want a productive and scalable language you may look NOW at Scala that can run both on JVM and also CLR (in devel)

Dev{eloper} Stonez said...

Some additional links (with tech details) related to Google NaCl and PNaCl (Portable NaCl = "pinnacle"):

Google 'Arctic Sea' – Chrome native code, ahoy!


Inside Google Native Client for x86 binaries

Native Client: Getting Ready for Takeoff
Google advances Native Client Web browser technology

Anonymous said...

I waited for a chance to write in C++ again, perhaps even in RAD Studio in near future.

Allen stated that Emb will support NaCl if NaCl gets more popular...

I would suggest supporting before NaCl get more popular, it is only way for RAD Studio to get some larger space in enterprise apps also cross-platform share, two bugs with one shot...