Friday, July 4, 2008

Some things CodeGear RAD does well

So to balance out all the CodeGear hate, I decided to post some of the things that CodeGear RAD does well.

1. Uses the Delphi language - Delphi as a language is pretty nice to use. I particularly like how you are forced to declare your variables at the top of a function, it keeps your code cleaner. However, I would say that you should be able to declare your variables at the top of any section of code who's visibility is different from others. Case in point. If you are inside a "for" loop, you should be able to declare a variable that is accessible from only within the "for" loop. Current Delphi standards say that even though your intent is to only use this variable within the "for", you must declare it at the top of the function, where it is accessible to the entire function.

2. Debugging - From my previous experience with Visual Studio, I was happy to see that CodeGear had debugging facilities that were just as strong as Visual Studio. 

3. Wysiwig editor - Again, from my previous experience with Visual Studio, I was happy to see that CodeGear had a wysiwig editor that was similar to Visual Studio (believe me, I've read all the stuff about MS gutting Borland's development team to form .NET and C#, so I understand that there are similarities in the platforms and IDE's). My only complaint about the wysiwig editor for both Visual Studio and CodeGear RAD, is that there are components that have no visible display, but can be added to your form's gui anyways. Case in point, your data access components (TClientDataSet, etc.). To me, the display editor should be kept pure, and if the IDE wants to show you a graphical representation of non-graphical components, it should be on a separate screen, not intermingled with your display widgets.

4. Heavy use of Win32 API - From experiences with poorly documented 3rd party widgets, I try to stay as far away from 3rd party add-ons as I can. The only time I will use one is when the widget is so awesome that it solves a problem perfectly for me. 

5. Usage of .NET - As far as I understand it, CodeGear is one of the only IDE's besides Visual Studio that can write code to .NET's CLR.

6. How similar it is to Visual Studio - Yes yes, I know the history. Delphi is the father of C#, CodeGear RAD (or whatever it used to be called) is the father of the modern Visual Studio. Still, the 2 IDE's are so similar that I could pick up CodeGear RAD and hit the ground running.

The main reason why I am so critical of CodeGear RAD, is because I have heavy experience with Visual Studio, .NET and C#, so I can see where CodeGear RAD falls short. It is only natural to compare the 2 platforms, given how much history they have together. Here's my feelings about Visual Studio vs CodeGear RAD summed up in a pic.


5 comments:

  1. Hahaha! Good illustration!
    It enhance a very important point. Competition is necessary for progress.

    Good commentary as well. I mostly agree, possibly with the exception on the 3rd party widgets. As long as they come with source, it's all good.

    I partially agree on the loop variable, although I actually tend to reuse them if I have consecutive (not nested) loops, but only for indexing. ix,rx,cx ... minimalist notation style for indexing variable. Indexes meant to be remembered, I assign to a variable with a more meaningful name.

    ReplyDelete
  2. Heh, yes I feel that competition among IDE's is great for us! CodeGear (or Embarcadero) needs to do some drastic measures to draw new developers to their IDE, and to Delphi. What drastic measures? I dunno. They would need some special "thing" that Visual Studio doesn't. Graphical debuggers, better integration with CVS or SVN, integration with Trac or Bugzilla, a document generator (like Javadoc or Doxygen), so on and so forth.

    ReplyDelete
  3. Fullblown SVN / Tortoise integration would indeed be nice. There are a couple of tools that does it already, but they are not fully aware of the Delphi file relationships.

    Drastic measures...
    How about a UML tool to document your classes, or that generate code from your data model? Delphi already has that. It's a bit inaccessble though... (View|Model View), and the GUI have "room for improvement".

    There already are several different tools to produce javadoc like extract from Delphi source (DelphiDoc (open source), Doc-O-Matic, and some that have slipped my mind).

    Any bugtracking tool with a web interface can be used within Delphi. IMO, it is more important that the tracking tool integrate with the version control tool - f.x. like TrackStudio integrates with SVN, allowing you to quickly see all changes related to a specific issue.

    I don't need revolutionary improvements - but I sure would like them to fix a ton of small annoyances and the freaking painful MS based help system that sucks so hard you would think it could power a black hole.

    ReplyDelete
  4. This comment has been removed by the author.

    ReplyDelete
  5. 1) Delphi supports nested functions, and that makes stack management a bit different than other languages. And it would depart a lot from Pascal standards by allowing those kind of declarations.

    3) Use a datamodule as a container for non-visual components. Despite its name, a datamodule its just a non visual container to allow for design time interaction. Datamodules are a good way to separate gui code from non-gui code.

    4) Delphi 3rd party components usually comes with full source code (almost all) and good documentation (mostly commercial ones).

    RAD Studio also support an API (OpenTools) to extend the IDE. There are plug-ins for several SCM tools.

    Delphi can generate XML files to be used to create documentation, see http://dn.codegear.com/article/32770.

    It was integrated with Borland Starteam, now that they are no longer tied I guess we'll see a much stronger integration with open source tools.

    ReplyDelete