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

Warning... the following may contain provocative statements and irony.

There are often a reference to a programming language to be 'outdated', and often that happens in comparison to another language that someone wants to
promote.

Say.. Delphi... many places management and project managers refer to it as outdated.

But what exactly means 'outdated'? Why is something 'outdated'?

Looking strictly at the wording, then Java is more outdated than Delphi, as Java was invented in 1991 based on a C syntax, and Delphi in 1995 based on a Pascal syntax.

And buzzwords like Garbage Collection was invented all the way back in 1959 when Lisp was invented. Heck even Basic had GC built in.. so that surely _must_ be an outdated feature! ;)

Then there is C, which C# and Java and C++ et all builds parts of their syntax on... that was invented back in 1972... must seriously be outdated... why on earth are anyone still using C/C++ to make operating systems, real time systems and other applications that are critical and where leaks and severe bugs are no no's as they have a huge impact on the use of the product?.. yes.. why on earth is that.... reflection... ah.. reflection..

What about the term 'reflection'....

Reflection is in its core the same as RTTI in Delphi (RunTime Type Information), but given a new shiny brand.
It was already available in Smalltalk invented back in 1970/71.. so surely that feature must be perfect examplified object of being totally outdated.

Hmm.. object... object...     object oriented... that word combination rings a bell somewhere... now... we all know that C# and Java are masters of OO... anyway so are the claims... but did they invent OO?... nah... we all know that Bjarne Stoustrup invented C++ and the object oriented scheme dont we?..

Nope.. not even close. It goes all the way back to 1960s, and the language Simula that was invented by a couple of Norweigians.

So OO is really pretty old stuff.. it cant be useful today that old stuff can it? It must virtually be outdated!

That rings another bell... virtual... virtual.. something that isnt there for real!... weird word... ... virtual machine.. thats really a buzzword in this decade... What is actually referred to are process virtual machines. Things that enables on the fly interpretation of semi compiled source code (also called Pseudo code or P-code). Interpreter... that goes all the way back to 1930 (and perhaps even longer) by a numerical interpreter by IBM... THATS old.. so we wont even spend a startrek second more on that.. that is definitely outdated.

However there is another variant of process virtual machines, that use a technique called Just In Time compiling (JIT).. ie. the source or semicompiled source (P-code) is compiled to machine instructions shortly before the time the instructions are needed while executing the application.

THAT sounds cool... it MUST be a novel and very modern thing since it even got a modern name for it... Managed Code, right? Nah.. VisualWorx (which is a SmallTalk implementation) did that almost 30 years ago... in the 1980s. Thats old! Thats outdated!

Well.. you get the picture I hope...

What imo should be outdated is how money controls hype that controls management that controls pure logic and common sense.

Lets take a step back and discuss what exactly what is the reason for new commercially popular languages today?

My take is that its not technical, practical or even (for the single user) economical reasons that is the reason for them.
Its a global battle about marketshares and control. In other words... something happening in the very high altitudes where the air is so thin that people living in such places will get problems thinking rationally.

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

People who have registered on our myc4d portal or on TurboMiddleware now have access to a new cool freeware utility - kbmDiff.

As the name says, its a tool that can compare files and show you the differences. In addition it allows you to manually merge selected differences from one file to the other.

I cant take the credit for all the work behind it, as 95% of it was made by Angus Johnson as a demo for his TDiff component. I have however added several features to it like:

• Ability to compare normally non comparable files like unformatted XML (ofcourse using kbmMW's DOM XML parser/generator) and binary files.
• Scrollwheel support
• Support for clicking and dragging in the right differences summary pane to show where the difference is in the text

and some more details here and there to imo improve the user experience.

The application is actually quite versatile, and can easily be compared with the typical commercial tools in the market.

Angus Johnson, who deserves every credit, have a home page here: http://angusj.com/delphi/ where the original source code for TDiff and the TextDiff (as his project was called) can be found.

To get the kbmDiff version of it signup at: www.myc4d.com or at www.turbomiddleware.com

best regards

Kim Madsen

UPDATED June 14 2007 (check update further down)!

The last days another riot have happened in the CodeGear non-tech newsgroup. Yet again!

The relationship between a vendor and a consumer should be healthy. The vendor make decisions thats supposed to be for the benefit of the majority of its consumers and other potential consumers not yet in the fold. Sometimes those decisions are annoying some consumers or even hurting them to some extent. Hence the consumer ofcourse will need to voice his or hers opinion on whats going on and that its hurting the consumer. Thats a natural right in an open society with freedom of speech etc.

However there is a fine line between expressing ones opinions and terrorising the community. Disgruntled consumers are almost as dangerous as disgruntled employees... they can make alot of harm. The difference is imo however that the consumer often still have things at stake... existing codebases etc. and essentially often would have liked CodeGear to be successful of the simple reason that then the chance of the consumer to be successful with the current codebase is higher.

Hence its completely incomprehensible to me that all the so called Delphi lovers are so busy as they are damaging CodeGear by diminishing Delphi. Sure Delphi has had its rough edges in the D8 and D2005 releases, but the issues have been dealt with by CodeGear who obviously are aware about the problems and knows its in their interest to get those issues solved. Hence D2007 and Update 1.

Im personally quite annoyed about the way the critisism is expressed. Why do I care? Because I am a consumer of CodeGear products, and the company I work in is producing products consumed by thousands of CodeGear consumers too. Hence what damages CodeGear sales directly damages us and our customers. And I simply wont accept that, regardless of that Im in agreement with some of the elements that have been expressed by others regarding what would be good to have in a CodeGear roadmap like Linux/Cross compilation support etc.

The constant negative aura around CodeGear's non-tech group says to me that CodeGear is better of shutting it down permanently. Although sometimes being entertaining to read, its surely not doing CodeGear or its customers any good.

The article I wrote about a year ago 'The story of 3rdparty announcements and reactions on them' which is still available on our website at:

http://www.components4programmers.com/articles/thestoryof3rdpartyannouncementsa.htm

can be directly applied to whats going on between CodeGear as the vendor and its consumers.

UPDATE June 14 2007:

The responses I get on this blog entry, both as comments here and on the CodeGear nontech newsgroups, makes me realize that people dont seem to understand the effect that extremely negative posts in vast amounts can have. Its a misconception that just because its on a non-tech newsgroup, only the geeks will read it. WRONG. The non-tech newsgroup is being cached into several web based search machines, including Google Groups. Try to search for CodeGear and order the search by date.... the top 6 entries are all providing the probing potential new customer with a negative view on everything related to CodeGear.

Some people may be smart enough to read thru the bulls..t, but managers arent always that smart and as they may already be biased away from CodeGear, this number of negative posts will just be the final proof they need to convince their bosses that... "dont go the CG way... Ive read comments from their customers... and they dont believe in CG or its products... too risky to go there".

I welcome constructive discussions about features and techniques... but please.... grow up and dont act like a child when things dont go your way! As CodeGear have multiple times said.... single customers cant possible have any idea about why CodeGear make their business decisions the way they do, so continuing to whine about it wont do any good, on the contrare. No doubt that every community served by CodeGear, that being Delphi developers, C++ developers, PHP developers, Java developers etc. wants to feel that CodeGear takes special good care about them. However try to look at your own company... how does that operate? Are you able to provide specially good care for all your customers at once?... specially if the demanding ones are numerous? and very vocal? No.. .you will have to prioritize... and so does CodeGear.

Help yourself by helping CodeGear in the right way! Give them input but dont expect them to jump according to your tune as thats not how a company behaves. It receives the input, estimates the ups and downs of implementing the idea and then either accept, reject or postpone the idea. If you think you can do that better than CodeGear and being more economically successful than CodeGear, then you have an option for starting your own company. Do that... spend time on that... and realize how the world suddenly seems different when the problems and tough decisions start to pile up.

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