Fog Creek Software
Discussion Board

Any reason to consider .NET for this?

Here at Mitch and Murray we are getting ready to develop a new end user app targeted to software developers.  It must work well for both the one developer / no server shop as well as a full squad of developers using a server.  There is a large amount of database action as well as various internet communcations protocols inherent in the design.  A web interface is not required, and is not in the spec, but might be useful at some future point.

Our first choice is to use Borland Delphi along with various third party tools to do the job.  This is what we know, this is the environment that we have confidence in.

On the other hand, is there any reason why we should look closely at .NET using either C++ or C#?  Has there anyone that has been down this road before us who has _carefully_ looked at .NET and the tools, and can comment?  We already own all the Visual Studio .NET stuff as well as the latest Delphi tools, so cost of development tools is not an issue.  We want a deployment platform that works well now and into the future.

Many thanks, and Good Leads to you all,

- M & M

Mitch & Murray (from downtown)
Sunday, May 25, 2003

Write the back end in ALGOL and use Simula for the front end...

Seriously, unless you see an advantage in .NET, stick with what you know. It will take you less time to implement the design if you don't have to worry about language and architecture hurdles (not necessarily in your way, but just the different way of doing things).

If time and or competitive/technological advantage is not an issue, go with .NET.

Of all my products at the moment, 2 are in Delphi and 4 are in VB. I intend to move all of them to .NET eventually, but right now I'm only moving the ones across that have reached a point where it would be more beneficial to invest the development time in another language.

Geoff Bennett
Sunday, May 25, 2003

What the heck kind of software budget do you have here?

You mean you can just jump in, and adopt a new platform without doubling, or tripling your time estimates?

I mean, it takes a good 6 to 14 months to really learn a new environment. You productivity during this first year will be at least 1/2 (if not one third) less in terms of programmer output!

Can you really afford to just double, or triple the budgets because you “FEEL” like using  ad different tool?

Gee, boss, well if we use our existing software team with all their knowledge and cool tools and utilities they have been developing with for the last few years (ie: Delphi), we can do this in 5 months. However, if we use the new .net stuff, we need extensive training, and the developer team needs a good year to get up to speed. So, instead of 5 months, we need a 17 months of budget time. Can your company really afford that?

Can you just triple your budget out of the blue? Gee, I want to work for your company. Well, of course you will use .net! You get to triple your budget, and spend a whole year learning new platform. Gee, go for it!

Next time use Oracle. And then Sybase the next time!

The only reason that would stop you here from using .net is your budget, and it sounds like you don’t have one! How can you possibly just change your major development platform on a whim?

I have more then once quoted the following skills set from Yourdon’s book Decline and Fall of the American Programmer. They are:

Stage 1 Innocent (never heard of the product)

Stage 2 Aware (Has read an article about X)

Stage 3 Apprentice (has attended a three-day seminar)

Stage 4 Practitioner (ready to use X on a real project)

Stage 5 Journeyman (uses X naturally and automatically in his job)

Stage 6 Master (has internalized X, knows when to break the rules)

Stage 7 Expert (writes books, gives lectures, looks for ways to extend x)

To attempt any software project with a team comprised of 3 or less is going to be a complete disaster. Even if the team is comprised of just Stage 4, you better have some stage 5’s or 6’s on the team for design and project lead.

Boy, if you can just pick your tools out of the air, and triple your software budget, then you are lucky person. Go for .net! You will be being paid to learn a new platform, and make some mistakes along the way, but who cares if you don’t have a budget here!

It must be nice to be in that position!

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Monday, May 26, 2003


This is a great and typical spew.  However, you didn't give me a single reason to consider .NET.

That, I am afraid, is my question.  The details and the consequences of the adoption of .NET was not part of the equation.

Mitch & Murray (from downtown)
Monday, May 26, 2003

Linux d00d, straight C, GUI in motif and protocols all hand-written.  You'll be done in a week.

Nat Ersoz
Monday, May 26, 2003

When all other things are equal, choose the thing you're most comfortable with.

Is there any hole in Delphi that you're hoping .NET will fill, like say, great support for Web Services? If not, then Delphi is likely to be the right choice.

Brad Wilson (
Monday, May 26, 2003

Since when do people who write books on things fall into the expert category? Most of the people out there writing programming books write books because they can't hack it as programmers ...

And the horse you rode in on
Monday, May 26, 2003

Wasn't Delphi 7 supposed to have some kind of .NET support?

And then there's this "Delphi for .NET" thing coming.

What was the reason for using C# again?

Monday, May 26, 2003

"What was the reason for using C# again?"

That it already exists, as opposed to just being "coming?"

Anyway, as for the original question...

First some deployment issues. Using .NET means that all machines that run any part of your application:

a) MUST have the .NET Framework installed (23 MB), and anything the Framework requires, including IE 5;

b) CANNOT run Windows 95 or NT 3.51.

The Framework isn't too widespread right now, so if the Delphi solution has significantly lower prerequisites you might reach a bigger market. These issues remain the same regardless of the .NET language you choose, by the way, so Delphi .NET won't help here.

As for language choice, there shouldn't be too much difference in productivity between C# and Delphi. But you should have a look at the .NET Framework library because that's where I expect you'll find the biggest difference to your current environment.

Jeff Prosise's "Programming .NET" (MS Press) is a good overview; you might want to check MSDN Online and browse other .NET books to get an idea what the standard library can do, and if it might help you with whatever requirements your project has.

I definitely recommend against using C++ with .NET unless you really have to.  Managed C++ packs another layer of ugly complexity on top of an already overcomplicated language. You should use it only as a last resort when you can't otherwise get the runtime performance you need.

Chris Nahr
Monday, May 26, 2003

Since you're intending to ship a product you also have to be aware that  .NET's CLI means its easy to decompile, unless you use managed code, which (I think) implies C++.

Simon Lucy
Monday, May 26, 2003

"Since you're intending to ship a product you also have to be aware that  .NET's CLI means its easy to decompile, unless you use managed code, which (I think) implies C++."

Probably just a typo, but to clarify: Managed code means MS Intermediate Language (MSIL) which is easy to decompile. UNmanaged code is native x86 machine language which is hard to decompile.

You do need Managed C++ to mix both in the same assembly, but you could also create a native DLL in any language that can produce a standard C interface. Such DLLs are easily accessed from a .NET program using the built-in interoperation features.

Chris Nahr
Monday, May 26, 2003

Reasons to use .NET - M$ is backing it to the hilt so it's probably going to be around for a while. You could argue that learning it now is an investment in the future of your company. Also, the developers who work for you will be happier working in an environment that allows them to learn new skills.

I disagree with Albert's analysis of how long it takes to get up to speed with a new language/technology. Sure the learning curve will be steep and your initial code may suck. But as long as you design things properly, you can always replace sections later as you learn more and improve. Besides, if we all thought that way then we'd all still be programming in COBOL or FORTRAN (apologies to those of you who still are).

Of course, this is assuming that you have some smart people who know or can learn OO design.

Monday, May 26, 2003

The fact that a technology is backed by Microsoft does not necessarily mean that it will be around for a long time. Microsoft has abandoned several technologies in the past to replace them with newer ones.

For example, win32 is no longer supported since VB6, while Borland announced that Delphi 8, to be released at the end of the year, will still support win32 (besides .NET and CLX). And its applications will run on all 32 bits Windows platforms.

Jan Derk
Monday, May 26, 2003

Lets clear up some myths:

Managed code means code that uses the .NET Framework. By managed, it means things like the garbage collector for managing memory.

Because .NET uses Just In Time compiling, it is easy to decompile it. It isn't the fact that it is "Managed" but rather that it isn't fully compiled. There is software available to encrypt this code and therefore protect your code from decompilation.

Win32 has not been abandoned. It just isn't part of the .NET Framework. This is because .NET is designed to be supported by multiple platforms and only Windows has Win32.

You can still access everything in Win32 from within any .NET language, but you are restricting yourself to Windows at that point (obviously this isn't an issue today but it could be latter).

So Delphi isn't doing anything special. They are just using the Microsoft.Win32 name-space that is provided by the .NET Framework on Windows.


As for switching to C#, I don't see a reason you should. By using Delphi for .NET you can get all of the new functionality of the framework without the cost of learning a new language.

Of course, .NET doesn't care what language you use so you could do some in Delphi, some in VB.NET, and a little more in C# if you felt like it.

Hope this helps some.

Monday, May 26, 2003

I was in a similar position 2 weeks ago. I had to pick a development environment and language for a new project. I wanted to use .NET. After reading the comments for the thread I started, it was clear to me that there was no reason to switch to .NET yet. I say “yet” because I did create a small application/prototype using C# about a year ago.  The development environment and object model were surprisingly consistent, and I effectively used a lot less code and less time, as advertised (The Professional C# 2nd Edition book helped a lot as a reference).

So, why I didn’t choose .NET? Well, the application I am developing is desktop based and frankly I don’t see much penetration of .NET in the desktop yet. Other minor reasons were deployment issues, performance and lack of mature third party controls, topped with the new changes introduced in .NET 2003 ( I like “some” stability in my development environment).


William Williams
Monday, May 26, 2003

Many, many thanks for all the thoughtful replies.

Mitch & Murray (from downtown)
Monday, May 26, 2003

Delphi does something special: It gives you a choice.

You can compile either .NET or win32 applications. You know those good old exe's that don't require a 20MB+ framework to run. Sure, you can import a win32 dll in .NET, but you will have a hard time creating native win32 apps using C# or VB.NET. Personally I call that abandonning win32.

Jan Derk
Monday, May 26, 2003

"You will have a hard time creating native win32 apps using C# or VB.NET"

What do you mean by "native win32 apps"?

Do you mean such that the framework isn't required? Because you can NEVER do that.

Do you mean that the apps look and work just like normal Windows apps? That's what Windows Forms is for.

Brad Wilson (
Monday, May 26, 2003

I would have said that using a major new technology on a new project where there is no business need for the project itself to use that new technology is dangerous.

Maybe you should look at .net but I personally would suggest that unless you need something that it offers then "now" is not a good time.

Robert Moir
Tuesday, May 27, 2003

"If time and or competitive/technological advantage is not an issue, go with .NET."

That could probably be said for years to come

Tuesday, May 27, 2003

>> "What was the reason for using C# again?"
> That it already exists, as opposed to just being "coming?"

I don't know about other industries, but ours has this tendency to produce over-hyped vaporware that is just "around the corner", and will be the next silver bullet.

I'm not labeling neither .Net nor Delphi as such. Just saying that the reason stated above, while making perfect sense, is, quite often, perfectly ignored :)

Paulo Caetano
Tuesday, May 27, 2003

"..This is because .NET is designed to be supported by multiple platforms and only Windows has Win32. ..."

Besides hand-helds, what other platforms does .NET run on? I keep hearing all the ranting about .NET and it's cross platform bla bla bla, but I've yet to really see it. Wheres .NET for UNIX? VMS? AS/400? .....


Thursday, May 29, 2003

Anybody who means anything besides "Windows PC and Pocket PCs" when they say "cross-platform .NET" is a liar.

Of course, that's all I ever hear people mean. Are you interpreting it in whatever way makes you happy, so that you can rant about it and feel some moral superiority? :-p

Brad Wilson (
Thursday, May 29, 2003

"Cross platform" is a hot button with those of us who bought into certain programming product vendors in the early 90s who promised "cross platform compatibility" of code developed using their product. Generally, except for very unambitious projects, such hype was absolute bullsh*t.

The assertion back then was almost always that programming to some vendor's GUI toolkit would give you Windows 3.1, NT, DOS, OS/2, Unix Curses, and X for "free". 

It NEVER worked that way until supplemented with LOTS of brute force labor. Common applications ALWAYS needed conditionally compiled sections inserted into them in order to operate properly in each target environment.

And, .Net is a much richer programming environment than Windows 3.1 ever was, by a couple of orders of magnitude.

The point is, commercial vendors entering a wide open marketplace and addressing a much simpler problem domain generally failed to deliver, and quite miserably.

With .Net, the library IS the language. Therefore the .Net runtime will have to be ported almost completely in order to make something like "Mono" viable. With unmanaged volunteer labor and no commercial incentives, no less.

So, I'm really not holding my breath, unless a major player wants to ante up for the development costs.

Bored Bystander
Friday, May 30, 2003

A few couples of programmers in the entirely word, have the expertise and the knowledge to rights the 95% or more peoples in the computers arena. While Microsoft it is looking precisely INTO this 95%. Looking for fans; people’s whit not highly knows about Computer Programming; PEOPLES which LIVES from and for the Software and/or Hardware World.

I’m concern and sorry for the other 5% in the next future (certainly, very closely), BUT YOU DON’T KNOW HOW MUCH WE NEED YOU! We want to be free like you. Please, put yours foots on the ground and help us… if you help us, May Be we can help you. Don’t think about I’m in a mistake. Never… it’s not a matter about binary code… it’s about live philosophy.

Good look

PD: but if you only have in your mind a $ sing… forget about…
That is because Linux exits… and will go on.

dosen't matter
Tuesday, April 20, 2004

*  Recent Topics

*  Fog Creek Home