BetaNews just published a link about a new toy from Microsoft Surface team – Microsoft’s Sphere. Surface software in the ball. Even though a hardware is not of Microsoft’s origin, software is inherited from Surface project.
You can watch a little presentation about possible application of technology. Fun experience I would say.
First, if you were looking for information about Hyndai’s sporty compact, it is not about it.
CodeGear joined Embarcadero and finally is free to do what they suppose to do for many years now – develop the software for developers and not some few of many tools for IT management (there would be no problem there in general until development tools line start to degrade).
CodeGear extends the Borland legacy, but not in the way it was done last 8 years since the era of Inprise ALM movement.
Back in 2000, Dale L. Fuller, then president and CEO of Borland, said about going back to the roots and renaming from Inprise to Borland:
“The Borland name has always been synonymous with superior technology,” “We recognize the influence the Borland name has on customers, and we know this decision will strengthen our identification within our target markets. The Borland name symbolizes a new start for the company, which has proven itself over the past eighteen months with two consecutive quarters of profitability. As we continue our turnaround, the name change signifies our renewed commitment to customers, stockholders, employees and analysts. Borland has always been well known for its ability to simplify complex technologies and the new name signals a return to the commitment to deliver superior technology that helps speed and ease the software development lifecycle.”
Promiss which never had a chance to be furfilled. “Software development lifecycle” took over the “developers, developers, developers” (Microsoft (c), this guy can motivate) moto which we used to associate Borland’s name with. It took long 10 years to fully realize potentials of the development tools market.
Now with CodeGear finally free form “Inprise” legacy (it is sad that we have lost good old name “Borland” in “Delphi”, but may be it is for the best.) we all looking forward to see a comeback of Delphi development platform, both as a language and as IDE, to get back its rightful place among modern development platforms.
We have a great tool which just need to return to the day light.
Do you want to know more about a new version? Read what people are saying about a new version, codename Tiburón. If you are not currently using it, give it a try. See what Delphi name was about for years.
There is a hot discussion brewing in public about importance of the Unicode support in upcoming version of Delphi (Tiburón). There are people who do not see it as something to spend time on in current Delphi situation and some who disagree with that.
Did you notice that word “Tiburón” is in Unicode?
Let’s come back in time December 2002 – Delphi VCL Controls for Win32 should support unicode – 4.89 rating, 359 votes. One of first from the dozens of QC reports asking to add Unicode into Delphi. Do not tell me it is not important for many people.
Is it too little too late? Could as well be, but it is better to finally have it and enjoy a feature which is now mandatory for any major development platform.
Keep in mind that Delphi (itself) was already “unicoded” storing string resources and source code as Unicode for some few versions. Full VCL/RTL conversion had never received much of the attention from upper management allowing Dev team actually work on the feature. Everything was about ALM those days. This time around it is different. Today Unicode one of the features which are critical for Delphi survival.
Yes, for many years we have learned how to deal with no support for Unicode in Delphi, but it is way around things, and not a solution. How many times was I asked – “why Delphi, being a modern language, still does not support Unicode?”. Well, I have had no reasonable answer.
Let look at the feature in question. Would it be important for US or even EU markets?
Yes, if you write an application which is used outside of your company’s building.
No, if you are running a home-only applications.
Let’s not go into discussion of dancing around the issue instead of solving the problem. Delphi applications do not exist by themselves, there are plenty of 3rd party API, data, code you need to interact and if they are in Unicode and your code cannot be native to the data, then you will encounter many things which you otherwise would not see in your “home” environment. Windows NT, XP, Vista has Unicode support. Being a programmer means one has to follow the main stream, not go against it. Otherwise you look as a white crow.
Now let’s come back to Tiburón. As a component vendor and Delphi programmer for many years, I would worry about such drastic change and impact it might have. But after having “converted” my code to have Unicode support by simply opening my projects in a new Delphi and recompiling gives me an assurance that work is done well by the CodeGear team.
Yes, let’s not idealize the situation, some modifications could be required, especially when Windows API functions are used. But even in this case, you most likely would get informed about the problem on the time of the compile, since you would be asked to adjust a few places in your code to use your string resources as Wide or ANSI strings specifically. Otherwise, your code would just run.
Did it worth the time and resources and is it a major thing for the release? YES. Remember it is a lot of work to make sure that everything is converted properly and working considering that there is a lot of dependencies between VCL code and underlying Windows API.
PS. And do not forget that Tiburón is not only about Unicode. Read all information about it as CG team is talking about new features.
Now we finally can talk about a new version of RAD Studio - Tiburón.
Did you miss some of the posts? Check the list below for most comprehensive list of posts about upcomming Tiburon release.
