Delphi 2010 has now been released by Embarcadero.

First impressions is, that if there have ever been a time to drop Delphi 7, and move on to a new Delphi, then that time has come.

D2010 is just so much faster than the last several Delphi releases, that its an absolute joy to use. It also have Delphi 7 usability features implemented, like the ability to get the old component bar back, as an alternative to the newer style component palette implemented in D2005.

There are few quirks related to that (like that the componentbar's position seems to move after a restert of D2010), but they are relatively minor issues, and can probably quickly be resolved in a future fixpack.

 In D2005, D2006, D2007 and D2009 there were nasty leaks in the IDE, that made the memory usage swell up over a short period of time, making the IDE (and the rest of the machine) painfully slow to use after a short while. Although some progress was made from D2005 to D2009, there still were annoying leaks of this type, that required a restart of the IDE regularly to get rid of the leaked memory.

Im happy to conclude that they finally nailed the leaks in the iDE in D2010 it seems. Previously it wasnt possible for me to work, using a complex project, for more than a couple of hours without having to restart Delphi. Now its not an issue any longer.

The responsiveness of the IDE has improved vastly. Its startup time seems quicker than D2009. In general it just has the right snappy feel about it that we knew from D7 (on the machines of that time), and that makes it a pleasure to use.

There have been improvements the components provided with D2010, but the, in my opinion, most interesting one is the new gesture support. >Gesture support means that you can make special mouse movements to signal a command to the application. That of course is mostly interesting when you are not using the mouse, but instead a touchscreen. Hence its possible to make an interface that operates similarly to the touchscreen of an iPhone.

I think its an important feature, not so much of the feature in itself, but because it gives some indications of where the desktop part of Delphi is heading or at least where it, imo is supposed to be heading.

I have, in a previous blog post, almost written off Delphi as a futureproof and viable development tool and language, due to the fact that for desktop applications, development tools like Adobe Flex and MS WPF are making serious efforts in providing a relatively easy to use way to make very cool looking client side applications with lots of functionality. Delphi simply lacked the facilities they are providing.

And on the server side I wrote off Delphi, as its market has been shrinking seriously due to Java and .Net and due to the loss of the last cross platform compatibility feature (namely cross compiling for .Net) which in addition to the previous loss of Linux support, by dropping the ancient Kylix compiler, really didnt leave many reasons for a manager to choose Delphi vs the rest of the wolfpack. The only major sellingpoint, one source/multiple platforms, that Delphi did have with Kylix 3 and Delphi.Net, wasnt any longer. Thats still the case today, but Embarcadero have however, within the last 6 months, announced plans for supporting cross platform compilation for Mac and Linux, which absolutely is a step in the right direction, as long as Embarcadero delivers on the plans!

Delphi 2010 is no doubt the best native Win32 development tool today. It runs circles around all other development tools in that respect. And if thats all you need, then there is no reason not to upgrade to D2010 right now!

With the new gesture support and plans for cross compilers, my griefs seems to have been heard, and Delphi may in the next years, actually have a chance to compete and win back market shares. However we still need to  see the cross compilation support emerge, and Embarcadero should not rest on the laurels about gesture controls, as that is just a small, but important, step in the right direction for desktop applications.

Whats imo missing on the desktop for Delphi to really compete? 

• Improved binding of any data to any control. Today the only binding existing is when you use specialized datasource binding aware controls (TDataSource and the TDBxxx components). It was cool when it was presented back in the early days of Delphi, but today it has been surpassed by both .Net and Adobe Flex/Flash 4, which allows for 2 way binding of any property to any other property or value. The existing Delphi DB controls needs to be deprecated, and somewhere in the hiearchy between TObject and TCustomControl, there needs to be added advanced automatic 2 way binding on any property value.
• The existing TCanvas and windows Device Contexts, should be abstracted further, to make it possible to place any control on the canvas, and let the canvas be free floating in a 3D space.  That would allow for a new ball game of user interfaces, which is allot more intuitive to how users perceive the world, than the current 2D flat way. One example... you only have so much screen estate available, and you want to present details about multiple products in your product inventory software at the same time. You would often resort to a list, and someone clicking on the item on the list to present a window with details about the product, or you would have a number of tabs with product information in each. However in both cases you dont actually present information concurrently about multiple products. What if you could use the Apple CoverFlow method (http://en.wikipedia.org/wiki/Cover_Flow), where the focused product is shown in a 2D way, while the other products full product information is shown as pages in 3D space. Then combine that with the gesture control and a touch screen, and let the user use his fingers and hands to navigate thru the products. Its allot more demanding on the hardware than a simple 2D form, and it would have been a challenge in the D7 days, but today, even the simplest machines PCs are able to provide enough power to make it look smooth.

Generally as language features I would like to see 

• XML and regular expressions as part of the language itself! XML has come to stay, and regular expressions are really very useful string matching and parsing facilities, that many applications use. But today its all done outside the language, via class instances etc. Why not simply make it part of the language syntax? Like you have a string native type, have an XML native type where you can simply do this: var myXML:XML = <xmlnode><xmlnode2 attr1="abx"/></xmlnode>; In fact check out E4X EcmaScript for XML (http://en.wikipedia.org/wiki/E4x), where they have chosen to integrate XML directly into the language. It seems so natural to use it that way, and much easier than going thru rigid object instances and collections. 

In addition, I think it wouldnt hurt, if they bright people of Embarcadero, would start to think about how to solve the following tasks as an integrated part of the development process:

• Packaging and distribution of applications. Today thats something that is made AFTER the application has been developed. Instead the IDE or language, should encourage that to happen while the development is taking place.. possibly by using the new attribute features of D2010.
• Distributing to the Win32 environment today is already quite complex, although made somewhat simpler by various 3rdparty installation tools. But the problem with most of them (if not all) is that they require use of yet another development tool and language for creating the relevant installation scripts. And those scripts of course very quickly become stale, and needs constant updating.
• Documentation has become part of the development process to some extent, by providing various comment tags inside the source code where the full document for a topic can be written in. Its a method I personally dont like as it clutters up the source immensely, but I also dont like the current alternative which is a completely decoupled documentation application, that needs to be kept in sync. Hence imo, the IDE should provide a solution that keeps things guaranteed in sync, but separates the documentation from the source, so its easy to get documentation translated to other languages, and its possible to distribute documentation and source separated.

Yesterday my long time good friend and colleague Richard pinged me with a weird looking web address: www.embarcadero.com

When receiving such an address, there must be a reason... could it have some funny jokes or ahrm... pictures... in it... Richard usually dont send such links to me.. (hmm... I wonder if he keeps those to himself  .....Just kidding ). So it had to have something to do with what we do.

The name itself didnt ring many bells to me... but that can be because I have been living under a stone for a couple of years coding. Anyway.. I clicked it.

While the web page builds up I notice.. hmm... there is a cool tool... and there is another... but what have that to do with me or us?

Then suddenly a text written in relatively small font showed up... Embarcadero have bought CodeGear...  a few secs... WHAATT!!!! Is this April fools day?.. checking the calender... and year... nah... its indeed just any other normal day.

First impression were... a tools company not much different (although slightly bigger I admit) than us, bought CodeGear! How on earth can that happen. The mouse ate the elefant. We are DOOMED!

Well... then it was time to a second go on what exactly was Embarcadero (couldnt they have named it something pronounsable?.. and writable...my fingers are making knots trying to type it ).

Reading over what it was all about, then it shows that Embarcadero is a relatively big company, actually people wise bigger than CodeGear (but they have certainly not being making any fuzz about that in the media Im reading), and whats more important is that Embarcadero is just one of several private companies owned by a huge private investment company. Hence we are suddenly now talking about money backing of proportions that would make Borland have wet dreams in night.

Ok.. money and size isnt an issue anylonger... but what about the longevity of the CG tools? Could it be a shark attack that results in some technologies being digested and put into other tools, while the rest is discarded?

Only the future knows how it fares, but it certainly do look like Embarcaderos and CodeGears toolsets are extremely complimentary with no direct overlap at all, which indicates that there is a true potential for huge synergies between the companies. They have alot of dedicated and knowledgable developers, and we all knows that CodeGear have the same but on other type developer oriented projects.

Embarcaderos have an organization that contains all the relevant functions for running a developer oriented company, while CodeGear probably have been somewhat amputated in the seperation from Borland, and I could imagine that some administrative and marketing functions within CodeGear either were missing or at least severely limited in manpower. In that scenario, those areas would be naturally strengthened by this acquisition.

As Embarcadero have been targeting a very different vertical market than CodeGear, they also have their feets inside some places where CodeGear would never before have had access, specially related to native development (example Java houses and other non typical areas for CG native tools. Visa versa, Embarcadero now ofcourse have easier access to the many dedicated supporters of CG products, and this way will expect increasing sales of their own products. The total market for most people like us.. 3rdparty tools developers, does seem to open up as the market canvas have now been broadened and the exposure of our products potentially made alot more visible in usually non accessible places.

That should bode well for CodeGear customers too. If the market canvas grows, the potential to earn money for vendors targeting that canvas grows and that ensures stability and progress towards CodeGear customers.

My current take on the situation is that, despite the initially surprising selection of buyer, this is probably the best possible outcome one could dream of.

So ... Very welcome Embarcadero!

I think we all will have a great future together. Delphi, JBuilder, C++Builder now have both the code quality and the market canvas and exposure to really make things happen!

(I will try to get used to writing  "Embarcadero".... but boy... CodeGear is easier... will probably have to use the shorthand writing of it... CG vs ET... battle of the galaxians)

I have seen the light.. I have faith!

Kim Madsen
TeamC4D

We had on our newsgroups at news://news.components4developers.com recently a question about if kbmMW can be considered a 'corporate product'.

My answer to that was that in our opinion, yes, but we certainly dont have the marketing muscles of the big ones that are considered 'corporate'. I consider something to be 'Corporate' if the following conditions are fullfilled:

1. It serves a corporate purpose
2. It provides a reasonable ROI
3. It is backed by a stable organization/vendor
4. It has a future
5. It is maintainable
6. It is maintained

Lets take them one at a time:

1) Well.. if it doesnt serve any purpose in corporate sense (eg. a company cant use it for something useful), it isnt corporate.
2) If it is costing an arm and a leg to install or use to serve purpose 1, then it isnt corporate.
3) If its looking like abandonware, or anyway highriscware, then it isnt corporate. A company has to be able to trust that the vendor is around to support it.
4) If the product do not have a future, its not corporate. There is no idea for a company to spend energy on something without a future.
5) If the product is next to impossible to maintain and require too many manhours, its not corporate.
6) If the product is not maintained it means that the product is reaching a status that would kick in point 4. No future. Its not corporate.

In reality I see large corporations use products that they consider corporate, but that typically do not live up to those 6 criterias. Lets look at some examples:

Sun - J2EE: For the most part it doesnt live up to the 2nd and 5th criteria. It is typically difficult to get to perform (why there are lots of highly paid contractors in that area), and its equally difficult to deploy an application server. Some vendors of application servers have made it somewhat easier than others, but the base line is that a scalable, performing production deployment is not easily made.

Sun - JMS: In addition to the difficulties in deploying a production system, thus violating point 5, it also violates 2 as JMS by itself does absolutely nothing. Routing mechanisms, request/response mechanisms, quality of service mechanisms etc. must all be handcoded by each project wanting to implement JMS. There exists frameworks based on JMS that makes this somewhat easier, but that may actually end up in making the maintainability even worse.

Microsoft - VB: The number of VB3-6 applications still running in corporate environments are quite staggering. However it is abandonware, and no longer maintained by MS, hence violating 3, 4 and 6. In addition upgrading in the good old days from one VB version to another usually required rewriting specially the database access code as MS had an idea to reinvent the wheel on a 6 months basis.

Microsoft - .Net: That surely must be corporate, right? Well.. the corporations that based millions of US$ on VB in the good old days should actually have removed the 'Corporate' label of that product, although most havnt. The trackrecord (as in whats the chance your application can be recompiled with the next version) of MS development products except perhaps for Visual C/C++, has not really been something to make corporations feel a good warm fuzzy gut feeling. The amount of US$ spend to rewrite existing applications to move them to the new version or to support the new Vista etc. is simply staggering. People who believed in WinForms being the future also have to count with uncertainty to what amounts of rewrites are needed.

IBM - Visual Age for Java. It was actually a very capable Java development IDE, with some features that made it really unique. After IBM chose to drop VA for Eclipse, developers using VA had no choise but to follow to the new platform, despite that the new IDE didnt contain all the wizard functionality originally found in VA.

IBM - ComponentBroker. IBM's CORBA solution for Java and C++. It was dropped about 4 months after I attended a quite expensive course in the product. Fortunately we the company I worked for at the time didnt get to actually integrate it into something, but if we had, it would have cost serious US$ to replace it with something still maintained and supported. In addition it was cumbersome and errorprone to use it. However it was still considered 'Corporate' all the way until it was dismissed.

In my opinion, the label 'Corporate product' often is a synonym with big, difficult to use, difficult to manage, difficult to deploy, overly expensive software backed by the 3-4 most PR active IT companies.

What is your definition of 'Corporate'?

Kim

During the last several years, our flagship product, kbmMW, have been supporting more and more IDE's and versions, and it has also undergone a facelift in the sense that multiple editions were made available.

kbmMW currently consists of 2 packages (one runtime and one designtime) for each IDE for each edition. Each of those packages consists of one or two files. As kbmMW currently supports 10 different IDE's/variants (D5, D6, D7, D2005 Win32, D2005 .Net, D2006 Win32, D2006 .Net, D2007 Win32, C++ Builder 6, Kylix 3), and there are (or have been) 6 different flavours of kbmMW (OpenSource, Std, Pro, ProPlus, Ent, CodeGear), simple math makes the number of files to update each time a source file is renamed, deleted or added quite staggering. Its currently totalling around 100 files that must be updated!

That was starting to get REALLY boring to do, not to say time consuming and error prone. Automation must be the name of the day!

Hence we had to invest some time in a new product called kbmProject, which essentially is an advanced project file generator using scriptable templates.

In it we define:

• Units - which defines all the units that we know of for kbmMW as a whole. The unit definitions can also include information about forms/datamodules etc.
• Requirements - which define all the possible requirements that we know of for kbmMW as a whole.
• Projects - which we use for defining editions and what subset of the Units definition and Requirements they should contain.
• Templates - which defines the overall layout of the files. The templates can contain scripts and take advantage of variables/parameters defined on a job, project, template group, template, unit and snippet level etc.
• Template groups - which we use for defining groups of templates ... doh...
• Jobs - which is a combination of a Project and a Template Group

In addition we can define:

• Snippets - which essentially are small reusable code/data pieces that can be referenced from within a template
• Conditions - which for example can be used to indicate if a specific unit or requirement should be part of a specific package under some given conditions

When it all has been hooked up correctly, its as simple as clicking a Generate all button and all the relevant package files are generated automatically.

Quite neat!

This is a screenshot of the units pane... notice the raw unpolished look :)... its a good indication for this being a tool for toolers :)

And the following is a screenshot showing the templates and template groups.

As can be seen, the currently selected template simply contains a reference to the snippet BPK_kbmMW_Designtime. It could have contained alot more if needed, but I decided that I preferred the snippets to contain all the info as it would then be easily reusable.

So lets checkout the snippet then....

The snippet can be opened in a fullscreen editor to make it easier to read/edit.

Some places in this snippet there are references to either parameters or other snippets. The {%$=...} syntax references a parameter, and the {%$@....} references another snippet that will be inserted at that place.

The parameters can be defined on almost all elements in kbmProject. They are searched in a specific order to for example ensure that the parameter ANAME on the unit level takes precedence over ANAME (if defined) on job level etc.

The following show the scripted snippet SpaceLibsFroBpkPackage.

Anyway this was just to show you some of the extra tools we need to maintain continued development of kbmMW.

Kim/C4D

In quite a departure for us at Components4Developers we have decided to start blogging.  Day to day we constantly talk amongst ourselves about new ideas, techniques and ways to improve our products.  Some of these ideas get into the released code line, some get put into our research basket for a revisit and some get rejected.  Our customers though don’t see this process occurring, well that’s not quite true.  Customers that engage us in consultancy services get to see this first hand as often we are solving big issues for them through elegant additions to our products.

Another customer needed connectivity for PHP, C, C# etc from which came the Spider clients collection.

Getting back to the blogs.  Here from time to time we will share with you some of the ideas we have in the works, or things we have noticed across the industry.  Or, we may just have a joke or a moan.

Everyone is invited to join in. We invite our C4D friends who wish to join our bloggers list to let us know and we'll setup an account for you. Those that would simply like to comment on, or syndicate our missives please go ahead.

On another note.  Theses blogs are powered by BlogEngine.net.  Check it out.  It is Open Source and based on ASP.net.  Maybe I'll find a reason to hook it up to a kbmMW application server sometime.

Richard and Kim