Showing posts with label codegear rad. Show all posts
Showing posts with label codegear rad. Show all posts

Sunday, July 6, 2008

Visual Studio is better than CodeGear RAD

It's very clear to me that Visual Studio is the superior IDE compared to CodeGear RAD, and that is sad. Other Delphi programmers are constantly telling me how Microsoft gutted Borland's Delphi team, and hired away their best and brightest, including Anders Hejlsberg. Well you know what, all of Anders' creativity and talent are being put into C# right now. So it's no surprise that to many people, C# and Visual Studio are superior to Anders' old projects, Delphi and CodeGear RAD (or Turbo Pascal, whatever you wanna call it). It's unfortunate that Borland lost the corporate power game against Microsoft, but nobody said life was fair.

So from one Delphi developer to another, I ask you to demand more from CodeGear (or Embarcadero). You want people like me to sing the praises of CodeGear RAD? The best way to do that is to make CodeGear RAD the SUPERIOR TOOL.

And what's with the unconditional love for Borland/CodeGear? Is it because they are the scrappy company vs the monolithic giant? Even Java fans routinely criticize Sun. And you know what? Sun responds. Not everyone is happy with the way Sun treats their community at times, but at least they try to change for their users.

Effort vs Benefits of using different IDE's and Platforms

If I can paraphrase one of the commenters on my blog, Donald Shimoda suggests that I'm not spending enough time learning about CodeGear RAD and Delphi before I started using it. He says that I should read a few books before attempting to code in Delphi.

I disagree with him. I implore developers out there to not settle for crappy IDE's, API's and languages. Back in the day, hardware was expensive, programmers were cheap, and the tools were written for the machines, not the programmer. Nowadays, hardware is cheap, programmers are expensive, and tools are written for the programmer, not the machine. 

Remember this, all you other developers out there, the programmer is the expensive one, the important one. You have the power to demand more from your tools.

Some observations on Delphi and CodeGear RAD

To whatever random Delphi people that might read this blog and think that my criticisms stem from me not using CodeGear RAD for any length of time, please understand that the project I'm working on is relatively complex. I'm converting 30 or so forms from VB to Delphi, doing bug fixes all along the way. I use it all, xml, datasets, all kinds of widgets, straight file manipulation, everything. If there's anything at all that I can discover about Delphi or CodeGear RAD to help me work on this project, I use it. It especially frustrates me when I KNOW there's a way to do something in .NET, but there's no counterpart in the Delphi API's. I usually end up having to manually code more in Delphi than I did in C#/.NET.
  • Delphi has no foreach control statement.
  • Delphi arrays are primitive datatypes (like C, or you can call it a pointer with offsets, just like C, whatever floats your boat). So if you want to search an array, you have to write the code to do it yourself. There's no array object types, so there's no myArray.Find(value). I imagine there's redundant array searching code in pretty much every Delphi app out there (unless you rolled your own API into a .dll and bring it with you to different projects).
  • If I pass a dynamic array into a function, Delphi assumes that it is a static array when in the function.
  • Why doesn't ShowMessage automatically convert numerics to strings with an overloaded "+" operator? Oh it can, you say.... if I overload "+" myself... great.
  • CodeGear RAD does not understand nested block comments. It takes the first end block comment, and applies that to the first start block comment. Nested block comments should function like nested parenthesis.
  • Delphi has no automatic set/get declarations for accessing data inside a class. Not a big deal, but I thought it was nifty when C# added special syntax just for this.

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.


More about me being pissed at CodeGear RAD

To expand on the visibility issues, when I set a breakpoint and attempted to debug my code, control would flow from "test := TestClass.Create;" in Form1 to the definition of TestClass in global.pas. It would actually step into the constructor, and bomb on the first line of executable code. If I commented out all the executable code in the constructor, it would bomb upon attempting to exit the constructor. If I didn't have the proper visibility to execute the constructor, why did CodeGear RAD's compiler allow me to compile at all, and why would it bomb upon attempting to EXIT the constructor, as opposed to ENTER the constructor (I shouldn't even have been able to enter the constructor if the visibility was wrong).

Now I'm pissed at CodeGear RAD

I just wasted a good 4 hours because of retarded behavior of CodeGear RAD. Lets say I have a form called Form1, and a file called global.pas. I define a custom class called TestClass in global.pas. In the "uses" section of Form1, I add global. In the implementation section of Form1, I have a procedure called Proc1. In the "var" section of Proc1 I declare "test: TestClass;". In the code section of Proc1, I write "test := TestClass.Create;". 

I figure since "global" is in the "uses" section of Form1, I'm good to go with using "TestClass" in Proc1. I compile with no errors. When I run my app, I get an "access violation". I rack my brain and use all the google-fu at my disposal to figure out what I'm doing wrong. Cause obviously the fault lies with my code somewhere right? Wrong. I must use a "test := global.TestClass.Create;" in Form1. In order for it to run properly. I completely lose my fucking mind at this point. 

In any programming language known to man, something is either visible to you, or it is not visible to you. There is no "well, you can see it at compile time, but not at runtime". If "TestClass.Create;" was NOT in the proper visibility, THE COMPILER SHOULD HAVE THROWN AN ERROR. If "TestClass.Create;" was IN the proper visibility, THE RUNTIME SHOULD HAVE EXECUTED PROPERLY. 

I understand when I waste my time because of something I did. I can accept that. What I cannot accept is when someone else wastes my time. The group of monkeys that made CodeGear RAD need to go take a class in compiler theory. 


Before anyone bitches at me, please read the paragraph above on visibility, and why the compiler should have thrown an error. 

CodeGear RAD crashing again

This is the 3rd crash in a week. Not my application crashing mind you, but CodeGear RAD crashing. I edited out any sensitive information in the pic below. If there weren't so many people using CodeGear RAD, I'm not sure I would trust it to create executables that would run well in production.


Upon restarting CodeGear RAD, here it is with the view changed (everything undocked).


Just for note: ONLY CodeGear RAD crashes on this box. Not IE, not MSSQL, not Visual Studio, not anything else. CodeGear RAD is the special one.