Board index » delphi » Re: Pondering the dev tool landscape from an outsider

Re: Pondering the dev tool landscape from an outsider


2007-02-07 10:56:31 PM
delphi116
Gareth Conner writes:
Quote
Yes, I too look forward to the day that I can ship a single EXE.
Currently, my VB(Visual Basic) app consists of the main project, several COM DLL's,
and one ActiveX EXE server (to provide the multithreading support,
which in VB(Visual Basic) had to be an out-of-process server). The low{*word*154}
fruit *seems* like it would be the DLL's and ActiveX exe. Since
those chunks are pretty well isolated currently, they may be a good
place to start porting.

I'm no fan of COM, since it was a source of distribution headaches for
me, but it may be the quickest route for now...

Hi Gareth,
Multithreading stuffs?
Have a look at the unit AsyncCall:
andy.jgknet.de/blog/exit.php
It's great piece of code from Andreas Hausladen!
Many thanks Andy!
Regards
Dario
--
 
 

Re: Pondering the dev tool landscape from an outsider

Dario Tiraboschi writes:
Quote

It's great piece of code from Andreas Hausladen!
Many thanks Andy!

Yep, I am using it, too.
Great piece of code, indeed. :-)
 

Re: Pondering the dev tool landscape from an outsider

Gareth Conner ha scritto:
Quote
Hello folks,
Hey Gareth!
Quote
My apologies in advance, this is a somewhat lengthy post...
No worries. We love insightful posts.
Quote
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.
Luckily, "professional programmers" and "formal training" have
very little in common, if anything. I have seen many "degree-endowed"
people write awful code and the other way around, thus methinks that
those two things are unrelated.
Quote
So, from what I have 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 am sure it is cleaner
programming, but every task requires a long chain of classes &
interfaces.
Personally, I have grown to dislike Java.
It's counter-intuitive to say the least.
Not that I know it particularly well, but I was ignorant of VB(Visual Basic) as
well after many years working with Delphi, but I picked it up
very soon. I also know some(not commercially) C++ and I don't
find it as complicated as Java.
That's probably going to have me shot dead from other folks
here :-), but that is my experience.
Quote
* Swing is almost *too* flexible. I have 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.
Swing is one of those things that must have been designed(and developed)
when participating to a rave party and while using {*word*110} all over.
That is, my opinion :D
Quote
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.
This sends cold shivers of memories, I totally feel the pain.
Quote
***Delphi***
Pros:
* Feels familiar. It doesn't seem terribly different than VB6. In
fact, in many ways it is the VB(Visual Basic) I wished I had (though I didn't know
about it during our version 1.0 development!) it is got a good mix of
procedural programming and OO.
One main difference with VB(Visual Basic) is that it is *completely* strong
typed, you can only have loose typing if you really want to,
although you will find out that this is a firmly discouraged
practice as - unlike VB(Visual Basic) - Delphi has a very good string
management and you can do pretty much what you want using
strings rather than variants.
The latter will mostly be useful on COM, which you're willing to
abandon anyway.
I've done COM and delphi classes in the same project(see this:
www.andrearaimondi.net/index.php
thus I know what I am talking about when I am telling you that your
easiest path is converting your code to Delphi classes and use
those inside your COM wrappers.
Quote
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.
As others have already pointed out, there's Lazarus and FPC.
I also have consulted in porting a quite complex framework to that
platform from Delphi. It was done in a few hours. This should
hint at how easy it is.
Quote
* 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.
LOL!
Borland has been doomed so many times in 20years and counting that,
really, it should be a hint.
Quote
***.Net***
Pros:
* Possible Interop strategy to gradually port the VB(Visual Basic) application. I'm
not sure if this is techincally smart, but it certainly sounds nice to
avoid doing the 'big port' all at once.
Interop? That is, adding another layer on top of another layer on
top of another layer...? Are you serious?
Quote
* Breadth and depth of class library is on par with Java.
Most concepts are "incredibly similar" to the Delphi ones, oh and by
coincidence, the original Delphi architect now works for MS and is the
brain behind C#... go figure...
Quote
Cons:
* Winforms is deprecated? I can not 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.
Ok, let me tell you: dotNET 1.1 classes can be called and used by
2.0 ones and the other way around.
And guess what? Delphi can do single-source Win32/NET1.1 :-)
See the difference now?
Quote
* WPF looks like it has questionable merits. I have seen some demos on
WPF is incredibly brighty :-)
Quote
* Fool me once, shame on you. Fool me twice shame on me. I am still a
little aggravated that my VB6 investment is somewhat wasted.
LOL, I got to write this sentence down for future reference.
I just love it.
Quote
would have chosen VB6. Therefore, I am trying to do a better job of
soliciting advice as I head down this same road again (albeit 5 years
later).
My advice:
Use Delphi, *but* keep yourself current on C#.
This way, you save your code, because you can still use the dotNET 1.1
assemblies with 2.0 apps, and... oh... did I tell you BDS does C# as
well? :D
Besides, some long awaited features should be available by this year,
thus you can start now and at the most re-target yourself later on.
I know this may seem anti-economic, but in such a fast moving world,
that's your best option.
Keep in mind, also, that you will have *more* than just a few problems if
your apps also target Win98 and use dotNET straight away.
Quote
If you made it this far along in the message, thank you very much for
your time and attention. Any advice is greatly appreciated.
These are just my 2c,
Andrew
--
You can subscribe my blog at
www.andrearaimondi.net/rss.php or
www.andrearaimondi.net/atom.php
 

Re: Pondering the dev tool landscape from an outsider

Ray A. writes:
Quote
Gareth Conner writes:
[overquoted material snipped]
Quote
I used to be a VB6 programmer about 7 years ago and I have to say
switching to Delphi was a good decision.
[...]
Ray, please trim quoted material to the minimum required for context.
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"At the apex of every great tragedy of mankind there stands the figure
of an incorruptible altruist." - Ayn Rand
 

Re: Pondering the dev tool landscape from an outsider

Gareth Conner ha scritto:
Quote
Searching the b.p.d.l.general newsgroup turned up several
recommendations for using the PostMessage API. I am not familiar with
that API, but at least it gives a hint to some starting points.
Perhaps the link will shed some light on this issue for me. Thanks
again!
<spot mode="shameless">
You may also want to check out this:
cc.codegear.com/Item/22921
from me, which shows two threads and label updates in a form.
</spot>
Cheers,
Andrew
--
You can subscribe my blog at
www.andrearaimondi.net/rss.php or
www.andrearaimondi.net/atom.php
 

Re: Pondering the dev tool landscape from an outsider

Brian Moelk writes:
Quote

en.wikipedia.org/wiki/Skype

"The Skype code is closed source, and the protocol is not
standardized. The Windows user interface was developed in Pascal
using Delphi, the Linux version is written in C++ with Qt, and the
Mac OS X version is written in Objective-C with Cocoa.[2] Parts of
the client use Internet Direct (Indy), an open source socket
communication library."

nice to know. Thanks for the info Brian :-)
Quote

[...]
>- even if all goes wrong and Codegear disappears, that does not mean
>your company or any other that uses Delphi will disappear. Some of
>them would port their apps to other environments. Maybe Delphi
>would become open-source. Who knows. But hey, there are people
>still programming with Delphi 3!

Exactly: Who knows. This is what big companies do not like.
Agreed, but that does not mean Microsoft is better in this point. While
they surely will be around for a long long time, they have left people
out in the cold before and I'd not be surprised if they would do it
again. For example, I do not think all VB(Visual Basic) developers are happy about
the transition to VB.NET.
Anyway, my point was that if Codegear would disappear tomorrow, none of
their clients would disappear the day after tomorrow because of that.
They would need to adapt and prepare for change, yes, but nothing more.
Quote
Even if
"who knows" is true for every company, big or small, perception is
reality in this case.
not sure what you mean with this.
--
Best regards :-)
Guillem Vicens Meier
Dep. Informática Green Service S.A.
www.clubgreenoasis.com
Contribute to the Indy Docs project: docs.indyproject.org
In order to contact me remove the -nospam
 

Re: Pondering the dev tool landscape from an outsider

Gareth Conner writes:
Quote

Thanks Dario for pointing out that link. And, of course, thanks to
Andy for the code!

This morning I have been looking into threading in Delphi, and have
found a few key differences between TThread and threading in .Net &
Java. In particular, there doesn't seem to be a method similar to
Control.BeginInvoke (in .Net) or SwingUtilities.invokeLater (in Java).
Both of these offer a way to post requests to update GUI elements in
the main thread in an asychronous fashion. Since a thread may kick
off some events or callbacks without knowing whether or not those
events may lead to changing a VCL component, it seems odd to have a
blocking Synchronize method as part of the TThread class. At first
blush, this seems to increase the opportunity for deadlock situations.

Searching the b.p.d.l.general newsgroup turned up several
recommendations for using the PostMessage API. I am not familiar with
that API, but at least it gives a hint to some starting points.
Perhaps the link will shed some light on this issue for me. Thanks
again!
there are a lot of sources!
Two that come in mind are:
www.midnightbeach.com/jon/pubs/MsgWaits/MsgWaits.html by John
Shemitz
Multi-threaded programming contest winners:
dn.codegear.com/article/29786
The winner, Mandelbrot Explorer, makes thread synchronisation using
windows messages (PostMessage API ) and doesn't use synchronize (no
thread blocking).
Dario
 

Re: Pondering the dev tool landscape from an outsider

Andrea Raimondi writes:
Quote
Swing is one of those things that must have been designed(and
developed) when participating to a rave party and while using {*word*110}
all over. That is, my opinion :D
Perhaps, though it also gives the impression of being designed by some
very smart folks with PhD degrees and lots of time. Its architecture
is beautiful, difficult to use correctly, and near impossible to code
rapidly.
Quote
This sends cold shivers of memories, I totally feel the pain.
LOL!
Quote
One main difference with VB(Visual Basic) is that it is completely strong
typed, you can only have loose typing if you really want to,
although you will find out that this is a firmly discouraged
practice as
Yes, and I am glad to use a strongly-typed language. I generally
succeeded in avoid the loose-typing in VB. Though it was eye-opening
to find the aspects of VB(Visual Basic) that work against strong-typing efforts
behind your back.
Quote
I've done COM and delphi classes in the same project(see this:
www.andrearaimondi.net/index.php
thus I know what I am talking about when I am telling you that your
easiest path is converting your code to Delphi classes and use
those inside your COM wrappers.
Thanks for that, I am interested in the approach and it is good to hear
that it works.
Quote
LOL!

Borland has been doomed so many times in 20years and counting that,
really, it should be a hint.
I've done a little searching through the newsgroup archives, and I can
see your point. There seems to have been dire predictions for quite a
few years, but Codegear is still on its feet.
Quote
Interop? That is, adding another layer on top of another layer on
top of another layer...? Are you serious?
Well...when you say it like that it doesn't sound so good :)
Quote
And guess what? Delphi can do single-source Win32/NET1.1 :-)
See the difference now?
Does that happen through Interop as well? Are there drawbacks to
taking advantage of .Net sockets & threading API's and using straight
VCL for the GUI? Or is that approach just asking for trouble?
Or are saying that you can share a single codebase and compile for
either Win32 or .Net? In that case, I suppose you just need to be
careful not to use any FCL classes or Win32 calls directly, right?
Quote
These are just my 2c,

Andrew
Thanks Andrew, I appreciate your thoughts.
--
Best regards,
Gareth Conner
 

Re: Pondering the dev tool landscape from an outsider

Guillem writes:
Quote
Agreed, but that does not mean Microsoft is better in this point. While
they surely will be around for a long long time, they have left people
out in the cold before and I'd not be surprised if they would do it
again. For example, I do not think all VB(Visual Basic) developers are happy about
the transition to VB.NET.
I agree, and that is what I meant by my statement below. There are no
guarantees things will actually be better simply because one chooses a
larger vendor/community.
Quote
Anyway, my point was that if Codegear would disappear tomorrow, none of
their clients would disappear the day after tomorrow because of that.
They would need to adapt and prepare for change, yes, but nothing more.
Yes, but FUD is a big reason why people make decisions. Simply
identifying it as FUD is not sufficient to neutralize it.
Quote
>Even if
>"who knows" is true for every company, big or small, perception is
>reality in this case.

not sure what you mean with this.
What I mean is that I basically agree with your rational argument:
choosing a large vendor/community isn't necessarily going to be better.
There are no certainties in any of this stuff.
I was making the point that some decisions are made based in part on
irrational reasons. This is especially true of purchasing decisions and
decisions made by large companies in regards to selecting other large
companies. It seems to me that birds of a feather flock together (big
companies like to buy stuff from other big companies).
OTOH, there are some very rational reasons why choosing a large
company/vendor or a large community is advantageous to a
proprietary/small vendor with a relative small user base.
--
Brian Moelk
Brain Endeavor LLC
XXXX@XXXXX.COM
 

Re: Pondering the dev tool landscape from an outsider

Dario Tiraboschi writes:
Quote
Two that come in mind are:

www.midnightbeach.com/jon/pubs/MsgWaits/MsgWaits.html by John
Shemitz

Multi-threaded programming contest winners:
dn.codegear.com/article/29786

The winner, Mandelbrot Explorer, makes thread synchronisation using
windows messages (PostMessage API ) and doesn't use synchronize (no
thread blocking).

Dario
This is great stuff, thanks for the links. If my post has proven
nothing else to me, I now know that the Delphi folks respond to
questions with useful info!
--
Best regards,
Gareth Conner
 

Re: Pondering the dev tool landscape from an outsider

Gareth Conner ha scritto:
Quote
Thanks for that, I am interested in the approach and it is good to hear
that it works.
Yes it does.
Quote
I've done a little searching through the newsgroup archives, and I can
see your point. There seems to have been dire predictions for quite a
few years, but Codegear is still on its feet.
Yeah, and still wholly owned by Borland, so what? :D
Quote
Well...when you say it like that it doesn't sound so good :)
Yeah, I bet <g>.
Quote
Does that happen through Interop as well? Are there drawbacks to
taking advantage of .Net sockets & threading API's and using straight
VCL for the GUI? Or is that approach just asking for trouble?
I'm not sure, I have (almost) never been asking for trouble using
Delphi <g>(ok, this one was a bit {*word*193}... :P)
I really don't know, I mostly use either/or and mixing them
never crossed my mind because I never needed it(hint, hint...).
Quote
Or are saying that you can share a single codebase and compile for
either Win32 or .Net? In that case, I suppose you just need to be
careful not to use any FCL classes or Win32 calls directly, right?
Right, you have two approaches here:
1) Use conditional defines and compile your source accordingly,
2) Have a base abstract class and inherit descendants. This
approach should be working for the largest majority of cases.
There's however something to note: between Win32 and dotNET
some things change quite prominently, such as GUIDs: while in
Delphi Win32 you have a way of specifying them, in Delphi.NET you
should be following dotNET rules(i.e. a GUID attribute).
You better research for the other "weirdnesses".
At last, it is worth noticing that you will use GUIDs in D32
only when you want reference count(i.e. most of the times),
while in dotNET they're optional(so you may want to avoid
refcount altogether in both worlds).
When I am saying "prominently" that should be intended as "won't
compile".
Oh and just by dropping a stone in the water: many Delphi
applications run smoothly on Linux using Wine... :-)
Quote
Thanks Andrew, I appreciate your thoughts.
You welcome :D
Andrew
--
You can subscribe my blog at
www.andrearaimondi.net/rss.php or
www.andrearaimondi.net/atom.php
 

Re: Pondering the dev tool landscape from an outsider

Gareth,
Quote
>Multi-threaded programming contest winners:
>dn.codegear.com/article/29786
For no other reason that it is fun to play with [I do hope to learn from
the code when I get to that stage] my fav is:
Building pyramids with cooperative worker threads by Denis Portilho.
--
Dave
 

Re: Pondering the dev tool landscape from an outsider

Gareth Conner writes:
Quote
Searching the b.p.d.l.general newsgroup turned up several
recommendations for using the PostMessage API. I am not familiar with
that API, but at least it gives a hint to some starting points.
As I said in another reply to you. Delphi is closer to the metal than
.Net. You don't have to use the Win API, but it is always there, ready
to be used.
Basically, all controls are windows, the main form, a button, an edit
box, a panel - they are all windows, mostly being "owned" by another
window further up in the hierarchy.
In the Windows OS all windows have a process that runs in a loop. In
these loops, the message queue is scanned for new messages all the
time. In general, there are two ways to pass a message to a window,
PostMessage()
SendMessage()
Using SendMessage, the process sets aside all pending tasks and throws
itself at the incoming message and handles it immediately.
With PostMessage OTOH, the process first gets pending work done, the
incoming message has to politely sit and wait for its turn.
Thats why PostMessage is good for threads, there is no collision
because the OS self organises the work.
In Delphi, this is very easy to implement, when you see it, you will
understand it, Delphi has excellent support for declaring message
handlers and also message loops running that you can hook into.
--
Ingvar Nilsen
Brand New Web Site! Free Delphi Tool:
www.ingvarius.com
 

Re: Pondering the dev tool landscape from an outsider

"Andrea Raimondi" <XXXX@XXXXX.COM>writes
Quote
>* Fool me once, shame on you. Fool me twice shame on me. I am still a
>little aggravated that my VB6 investment is somewhat wasted.

LOL, I got to write this sentence down for future reference.
I just love it.
I thought it was "Fool me once, shame on-shame on you. Fool me-you can not get
fooled again." :)
 

Re: Pondering the dev tool landscape from an outsider

"Mark Reichert" <XXXX@XXXXX.COM>wrote in news:45ca21bf$1
@newsgroups.borland.com:
Quote
Fool me-you can not get
fooled again." :)
you forgot the power chord.
--
Iman