Re: Pondering the dev tool landscape from an outsider

Hi Gareth,

First a little background on myself for calibration. Like you, I'm not
formally trained in computer science. My degree is in Electrical
Engineering, but I created some software and it sort of "took off" so I now
run a software company.

I'm a VB/MS Basic user from way before it was "cool". My first projects
were on CP/M and TRSDOS so I've used pretty much every version of MS Basic,
QuickBasic, Professional Basic, and VB that has existed. I was in the
first group of VB MVP's when they created the MVP program in 1993, and was
in the forefront of those battling to keep Classic VB in play. But, it's
over.

That is, I come from a similar background, I've got a large amount of VB
code, and I know your pain.

I've done a lot of soul searching on the subject of "where to go". It can
depend somewhat on your application and application plans, but in most cases
Delphi appears to be the best target. The more I use it, the more I wish
Basic had been on the Delphi architecture(VCL/IDE). Heck, I *still* wish
they'd make a "DB" (Delphi Basic). But, as you say, Delphi's Object Pascal
feels very nice for a VB guy.

One key difference between the VB debacle and Delphi is that the Delphi
developers *actually use Delphi*. You may or may not be aware, but the guys
responsible for VB simply do not use it. They've *never* used it except for
writing sample code. They are as clueless as to what makes Basic attractive
as anyone on the outside (Borland for example). A huge amount of Delphi
itself is written in Delphi, and it matters. CodeGear *does* understand
Delphi and Delphi users because they are users themselves.

A second key in our decision was that Delphi is designed for the developer
market. VB was not. VB (and the rest of the MS developer tools) are
actually designed to press Microsoft's OS and Office agenda. It is no
accident that MS does not include native development tools, they have a lot
at stake in pressing developers into .Net. They absolutely refused to
include VB6 in current Visual Studio versions even leaving it in its current
form.

Delphi also gives the capability of creating some of your code in a way that
it can be used in both native (Win32) and DotNet without change. When we
first stared looking, you could also use your Delphi code on Linux (still
can, I think, sort of). That takes a bit of thought if you're using library
code, but it can be done. It simply *can't* be done, at all, with C#, VB,
or any other signifcant choice I'm aware of. Since you're doing hardware
interfaces I'm guessing you'll find native code fairly high on your list of
priorities.

Good luck with your decision. I know it's not easy, until you get your feet
well into it. We're quite happy with our decision and I wish I'd started
the move when I first detected the reason to do it in 2001 (ref:
http://vb.mvps.org/tips/stability.asp ). While I've been tinkering with
Delphi during this whole process, we didn't really start serious development
with it (and I didn't start really understanding Delphi) until last year.

Unfortunately, I hung around trying to convince MS to see the light for
several more years. I thought there was hope of success. We were
spectacularly unsuccessful, but we tried.

In starting your move, you need to decide on one of several strategies.

You can do a whole-app conversion. There are conversion tools to help
( www.deluxsoftware.com is of some help but not a complete conversion)
You can create new programs with Delphi, leaving your existing programs
in VB until they die
You can convert in a segmented way, leaving the frontend as VB while you
rewrite logical parts in Delphi (calling them from the VB app).

With the "whole app" conversion you have to shut down app development while
you convert and test. That wasn't reasonable for us, we have to keep our
app moving forward or we're dead. It also presumes you start out knowing
how to program in Delphi, which you won't.

We also didn't want to just create new programs in Delphi. Our primary apps
are in VB and they need to be converted to be viable for the long term. Our
primary assets (code assets) are in a large library, in VB.

So, we're converting in a segmented way. As we get time we convert portions
of our VB library to Delphi and expose those to the existing VB app. At
some point we'll have the VB portion doing nothing but startup and we'll
replace that. This process takes some careful thought, but it can be done.
We've even decided to do it without COM for the calls. That's made it more
of a challenge in some ways, but we're simply tired of the DLL Hell made
worse by COM.

Hope this helps. If you have more questions, ask.

Dan


"Gareth Conner" <garethATcreativeconnersDOTcom> wrote in message
news:45c80076@xxxxxxxxxxxxxxxxxxxxxxxxx
Hello folks,

My apologies in advance, this is a somewhat lengthy post...

I've been lurking around these newsgroups for some months and purchased
a Turbo Delphi Pro license a little while ago. I've had some time to
play with Delphi, and I'm now mired in a quandry trying to decide my
best path for continuing development on an existing VB6 application.

I am not what you would consider a professional programmer, since I
lack any formal training (other than a couple of comp sci classes I
took while earning my degree in theatre!). However, the company I run
makes its business by developing and selling Ethernet-enabled motor
control devices and control software for use in live entertainment
(musical performances, etc.). We split our time between developing
electronic gadgets, firmware, machinery, and desktop software.

Our main desktop software was originally developed in VB6, and has
served us pretty well for the past several years. However, we are
faced with updating the software for the next major version and I'm
trying to make the most prudent decision regarding which platform to
use. This is a process I've been looking at casually for well over a
year, and has been back-burnered a number of times as more pressing
needs required attention. I've been seriously considering: Java with
the Netbeans RCP, Delphi, and VB/C# .Net.

Over a couple of months of sporadic work, I've gotten about 20% into a
Java port leveraging the Netbeans RCP. Though I'm somewhat pleased
with the result, I'm still plagued with enough doubt to lead me in a
vicious circle of constantly evaluting other platforms. As I've read
posts from other folks in this newsgroup, it's apparent that many
people here are well experienced in all of the same platforms I'm
considering. I'm hoping to hear some words of wisdom to help me put my
doubts to an end and forge forward with development on the best path.

The application requirements can be met by any of the tools in
question. It controls a network of motors via TCP sockets. There is a
fair amount of background processing happening all the time, so the app
must be multi-threaded (currently implemented as an ActiveX COM server
in VB version). The main GUI isn't flashy, but has a tree view, grid
view, and a 2d real-time schematic that depicts the scenery as it moves
around on stage.

So, from what I've learned throughout my meanderings the tools stack up
like this:

***Java (with Netbeans RCP)***
Pros:
* Extremely well documented. Easy to find answers to questions.

* Vast class library. Many times things you want to do, are already
implemented (if you can find them).

* Swing is a very flexible & powerful GUI toolkit with a well-designed
API.

* Cross platform.

* Garbage collection relieves some responsibility.

* Easy sockets & multi-threading.

Cons:
* Somewhat convoluted. As a gut reaction, it takes 2x-3x the amount of
code to get something done compared to VB. I'm sure it's cleaner
programming, but every task requires a long chain of classes &
interfaces.

* Swing is almost *too* flexible. I've been using the Netbeans Rich
Client Platform to get a basic framework to give some guidance. The
Netbeans RCP is pretty good, but it is also complex (like the base Java
libraries). Unfortunately, unlike the base Java libraries, the
Netbeans RCP isn't terribly well documented which can be frustrating.

* Hard to start & stop development. The nature of my work requires
that I switch gears to other disciplines fairly quickly (we're a small
shop). Because of the general complexity of the Java libraries and
Netbeans RCP, I've found it very hard to come back to coding after a
week or two of troubleshooting machinery in the field. It takes me
several days to get back in the swing (no pun intended) of things. I
never had this problem with VB, it was pretty easy to pick up where I
left off. Perhaps this is a language issue, but I think it's more an
issue of the framework. VB was small in comparison to Java. You could
keep the majority of what you needed to know in the back of your head.
Trying to remember how to paint bold text in a JTable in Java sends me
thumbing back through my code to find the various subclasses required.

***Delphi***
Pros:
* Feels familiar. It doesn't seem terribly different than VB6. In
fact, in many ways it's the VB I wished I had (though I didn't know
about it during our version 1.0 development!) It's got a good mix of
procedural programming and OO.

* Good class library with source code. I like that I can see what the
VCL is doing under the hood. VB often had too much black magic.

* Easy GUI builder & tight IDE integration with the language. Some
very convenient and rich visual components.

Cons:
* Proprietary language. I feel a bit burned by the VB6 debacle, and
that makes me gunshy of tieing myself to another single-source
language/tool.

* Documentation isn't so great. The online help is not very helpful.
The books available are good, but few.

* Weird vibe surrounding the company & future development. There's
obviously a lot of history between Borland and the customer base, I'm
not sure what all has happened of the years but there's a tangible
bitterness towards the company.

***.Net***
Pros:
* Possible Interop strategy to gradually port the VB application. I'm
not sure if this is techincally smart, but it certainly sounds nice to
avoid doing the 'big port' all at once.

* Breadth and depth of class library is on par with Java.

* Good documentation.

Cons:
* Winforms is deprecated? I can't find a straight answer on this one,
but it is awfully confusing to hear the yet again the 'next big thing'
from MS is being deprecated. Its confusing to figure out what GUI
toolkit MS is recommending for development today, that has a shelf life
of at least 5 years.

* WPF looks like it has questionable merits. I've seen some demos on
MSDN, I've played with the tools, I've read 1 book, and I'm not sure I
see an advantage to WPF for my work. They appear to be taking the same
course as Swing, custom rendering everything on a base native Canvas
control. This allows for huge flexibilty at the expense of some speed.
With Swing you gain the ability to move across platforms, with WPF you
get locked onto Vista and XPsp2.

* Fool me once, shame on you. Fool me twice shame on me. I'm still a
little aggravated that my VB6 investment is somewhat wasted.

Whew...

At the end of the day, I realize that I *could* get the work done with
any of the above. But, I feel that if I had sought out better advice
when embarking on the initial development during 2001/2002, I never
would have chosen VB6. Therefore, I'm trying to do a better job of
soliciting advice as I head down this same road again (albeit 5 years
later).

If you made it this far along in the message, thank you very much for
your time and attention. Any advice is greatly appreciated.

--
Best regards,
Gareth Conner


.

Relevant Pages

  • Re: The Difference is Obvious!
    ... commercial app trial because I saw the fine print "requires ... vbrun100.dll" or "requires Java". ... want to advance the wider adoption of the VCL.NET to include new Delphi ...
    (borland.public.delphi.non-technical)
  • Re: VCLs Future
    ... I have been in the Java world for a while, and, like most of you, struggle ... If I had Java clients and Delphi clients needing ... Security is built into the app and the database server. ... Delphi gives it all to me way too easily. ...
    (borland.public.delphi.non-technical)
  • Re: Is there a future for Borland in .NET?
    ... because it then relies on another compiler to get anything ... > people with much existing Delphi code and ASM knowledge can use it as a ... Delphi has always dependancies on Microsoft Libraries? ... you must either compete on cost or compete on feature ...
    (borland.public.delphi.non-technical)
  • Re: Is there a future for Borland in .NET?
    ... because it then relies on another compiler to get anything ... with a few changes we now how Delphi for .Net for the ... Delphi has always dependancies on Microsoft Libraries? ... server product that support ASP.NET now. ...
    (borland.public.delphi.non-technical)
  • Re: D8 vs D7-
    ... and web-services than any previous versions of Delphi. ... The .NET Framework has tons of available libraries that are just a namespace ... Any web services you would ... but none have matched callbacks yet. ...
    (alt.comp.lang.borland-delphi)