Board index » delphi » Re: Is Delphi for Win32 still mainstream?

Re: Is Delphi for Win32 still mainstream?


2008-04-24 04:18:25 AM
delphi261
To answer your question, in the US no, in Europe I think so.
I think the easy answer is if you don't need to use "new technology" to
get the app to work and it is a win32 app, do it in Delphi. If you have
to worry about new tech, then you should look as who knows how many new
version and what technologies will actually make it out the door when.
It is likely to be 2010 by the time we see a 64bit compiler from code
gear and it will only be on for one platform.
You also may want to check out how to program your app so it compiles
with FreePascal so you have a back up plan.
It has been a long long time for Unicode to make it out the door. I am
sure they will do it right, waiting several extra years to save us all a
couple of extra weeks of programming, well let's just say, I could have
survived with a bit more code breakage then they are trying to accomplish.
Good luck.
--
Thomas Miller
Chrome Portal Project Manager
CPCUG Programmers SIG Chairperson (formally Delphi)
Delphi Client/Server Certified Developer
programmers.cpcug.org/
sourceforge.net/projects/chromeportal/
sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 
 

Re: Is Delphi for Win32 still mainstream?

In article <480e2343$XXXX@XXXXX.COM>,
XXXX@XXXXX.COM says...
Quote
I would tend to disagree. I think .NET is being used heavily for desktop
applications. Maybe not for products that you can buy or download. More
so for in house applications within a company.
Yep, in many ways (this being just one of them) .NET is just VB++
 

Re: Is Delphi for Win32 still mainstream?

Quote
>Igor Ivanov writes:
>Is Delphi for Win32 still mainstream?
Object Pascal and C++ will be around for the long haul. Used by companies
who make interesting software not only for the Windows platform but for
Linux/Unix variants.
C#, VB, Java, Mono, whatever new one that comes out next week, are in use
by big companies for their internal software. That is why you see so many jobs
requesting them because head hunters looking on behalf of corporate America's
needs use these language syntax skills.
These "business casual" languages are pushed, hyped, given away by large software
companies (Microsoft, Sun, Novell) to tie these big corporations into their
other software offering and platforms.
To summerize:
The Vertical, Custom, Performace software market is C++ and Object Pascal (Delphi).
The corporate software market is everything else...
Who do you want to work for?
 

Re: Is Delphi for Win32 still mainstream?

Quote

To summerize:
The Vertical, Custom, Performace software market is C++ and Object Pascal (Delphi).
The corporate software market is everything else...

Who do you want to work for?
This seems to be implying that the majority of software being written
is still desktop software. IME this is not the case, most new software
is web based (Delphi people often refuse to admit this). I find
writing web software more interesting than desktop these days,
especially stuff like Silverlight. it is not the kind of thing where
Delphi or C++ excels.
Craig.
 

Re: Is Delphi for Win32 still mainstream?

Wayne Niddery (TeamB) writes:
Quote
"JohnE" <XXXX@XXXXX.COM>writes
news:XXXX@XXXXX.COM...
>I've successfully hired C++ programmers to do Delphi work, and it
>didn't take them long to get up to speed.

The only thing you have to watch is that they remember they need to free
(non-owned) objects they create. C++ programmers are too used to
automatic instantiation and destruction of locally defined classes.
Getting used to having to create them doesn't take long, but eliminating
the memory leaks takes longer. <g>

Heh, well...
A MODULAR PROGRAMMING LESSON FOR ALL DELPHI PROGRAMMERS
(not directed at Rudy, but everyone on this group)
There is a little niche community out there that makes use of the stack,
not just heap - so that we don't have to create and free every darned
thing in the universe.
I am bringing back stack objects and records into my programming. Mmany
times I just don't need a full blown class instance. Going against every
OOP rule - yes. Do I care: nope. Neither does Niklaus Wirth in his
modular Oberon/ComponentPascal languages -where lots of people use the
stack.
Constructors and destructors aren't needed for many simple tasks in a
local scope. And a lot of programming does exist in local scope, and a
lot of programming is simple little bits of local scope. Regardless of
what people think - programming should NOT be overly complex. Which
unfortunately a lot of delphi code ends up being, with all its free and
create line noise (and := nil too).
Consider a stringlist that requires no free and create
procedure local;
var
SL: TStackStringList;
begin
SL.Add('foo');
SL.Add('bar');
SL.SaveToFile('file.txt');
end;
No create or free!
No setting to := nil
Beautiful. No over engineering.
When we need a so called "constructor" it looks instead like so:
var
O: TSomeStackObject;
begin
O.Init; // instead of constructing, we may use init sometimes
O.DoStuff();
end;
Not always is an init needed. If it is, it is my standard way of
initing.. to make an Init() proc for most all stack records/objects.
Just keeps things consistent.
In many cases, a constructor or a destructor isn't needed and I'm
saddened to see people freeing and creating over engineered things like
stringlists just to open files and save them! Honestly, I see this all
the time in delphi code. It is truly sad!
We need to gather together a bunch of lightweight stack objects for
these purposes where people are abusing over engineered huge classes
like stringlists just for saving and opening files. And don't think I'm
making it up - I see people even abusing a hidden TMemo for these
purposes (yuck!).
In addition people need to also consider simple functions like
StringToFile and FileToString which require no class instance at all..
going against every OOP rule in the book once again. (StrLoadFile and
StrSaveFile). Instead i see nonsense like creating and freeing
stringlists just to get file into a stringlist.text to then to convert
over to ansistring var. Sick! Verbose! Ugly. Unnecessary.
What were their options? To use old pascal readln/writeln and Text file
from the system unit? That can be even worse to work with, so yes they
go ahead and use stringlist.create stringlist free. Yuck yuck yuck.
The solution is to make a useful lightweight old borland object library
that just uses the stack and nothing else (even records) for common
structures we need to use in programs.
var
SL: TStackStrListRecord;
begin
unit.Add(SL, 'foo');
unit.Add(SL, 'bar');
unit.SaveToFile(SL, 'file.txt');
end;
The unit.prefix obviously isn't even needed. I just show it optionally.
Some may be thinking: but how can all these stack structures be
inherited and reused and...??
Surprise: many cases we don't need it, but if we do, you can wrap the
stack objects into a class of your choice or use another over engineered
class on the heap if you need that over engineered class on the heap -
but in 70 percent of cases you don't need it, especially in local scope
situations where code is short (what can it possibly do that it is so
complex if it is in such a short local scope?).
But - sadly - everyone has this silly idea that ONLY classes on the heap
are the CORRECT way to program - or only RAII is the right way to do all
class/object/structure coding. Sometimes classes, destructors,
constructors, can be useful. In many situations, not. I hate to break it
to people. Actually, I love to.
I personally hate creating and freeing anything when there isn't a big
*need* to do so (i.e. just for the sake of doing OOP because some book
said I should do proper instantiation and object life cycle management.
Total bull hooky).
One of my biggest gripes with Delphi, is that Delphi programmers abuse
heap classes for every single thing in the world and think it is good to
throw everything in a heap class. It reminds me of Java where everything
is an over engineered object - but worse, even more code bloat at times
in delphi (line noise, not Exe bloat but *line* bloat) since delphi
objects need to be freed and usually nilled too - in ADDITION to needing
creation. Yucky yucky yucky.
End of legitimate rant/advice.
 

Re: Is Delphi for Win32 still mainstream?

Rob McDonell writes:
Quote
Alan Rose writes:
>... However I see win32 apps only lasting another five years max
>before its simply becomes too old fashioned to support (remember slow
>death of DOS apps).

I don't think there any parallel in between "DOS ->Windows" and "WinAPI
->DotNet". The move from DOS to Windows meant more work for the
developer, but a much better experience for the user. In the end, the
market demanded the nicer looking Windows apps. Conversely, the move
from WinAPI to DotNet means potentially less work for the developer, and
arguably a worse experience for the user (at least for desktop apps).
There are no users demanding DotNet apps, it is a developer-driven thing.

--Rob.
Yep complete ridiculous comparison.
My father, mother, sister, do not even know what ".NET" is. They might
even know that it is a domain name extension like .COM and .ORG. They
might even know that! Might. And these aren't dumb people.. but typical
computer users who don't give a flying fudge about microsoft .NET nor
should their user experience ever know about it either.
Dos is completely different operating system and completely unrelated to
this topic.
It's like comparing a car to a shovel.
 

Re: Is Delphi for Win32 still mainstream?

Alan Rose writes:
Quote
I was coming from the view point of MS supporting the win32 API in future
operating systems. WinAPI will only stick around as long as it takes the
market place to migrate to what ever is next. You maybe right in that it is a
seamless migration to win64 API programming and if MS see's a buck to be
made they'll continue to support it but I wouldn't hold my breath on that.
Plenty of alternatives on the market now. For the first time I see the PC
losing it {*word*108} in data processing and been relegated to being a simple
server



Oh, so now instaed of .NET we can choose Win64 API... WHICH is the same
thing as Win32 APi except it has been enhanced here and there to take
advantage of 64 bits.
Wow... so .NET really isn't required then - and Win32 api is in fact the
win64 API.... essentially.
 

Re: Is Delphi for Win32 still mainstream?

albert writes:
Quote
I can confirm that you can build data-aware applications with Lazarus using
the default MySQL connection, but also with Zeos. This doesn't mean however
that I disagree with the point that it is not ready for production. It does
generate some obscure errors now and then.
albert


I use it to power databases and websites for clients with millions of
rows. I parse anywhere from 10,000 to 30,000 websites with fpc monthly
by hand, and have been using it in the real world for over 3 years.
Although all compilers have bugs, if this is what you mean by obscure
errors. Sometimes I get obscure errors in a delphi IDE when the delphi
IDE crashes with an unexplained access violation too.
i.e. I don't see much difference ;-)
 

Re: Is Delphi for Win32 still mainstream?

Graeme Geldenhuys writes:
Quote
and we have a support newsgroup. See the link in my signature.

Thanks for the details. I will try the fpGUI.
Btw, I tried your support newsgroup a couple of months ago.
The messages never load in my day time! It only worked whenever I
accessed it after midnight!
FYI, I am in (GMT -05:00) Eastern Time Zone (US & Canada).
Thanks,
John
 

Re: Is Delphi for Win32 still mainstream?

na writes:
<snip>
Quote
To summerize:
The Vertical, Custom, Performace software market is C++ and Object Pascal (Delphi).
The corporate software market is everything else...
Interesting argument.
If you are right about this, there are not much commercial products
developed in .net.
Can anybody confirm this?
Thanks,
John
 

Re: Is Delphi for Win32 still mainstream?

"John" writes:
Quote
na writes:
<snip>
>To summerize:
>The Vertical, Custom, Performace software market is C++ and Object Pascal
>(Delphi).
>The corporate software market is everything else...

Interesting argument.
If you are right about this, there are not much commercial products
developed in .net.
The devil is in the details - so how do you define "commercial products"?
Do you mean only products like MS Office or do .NET products that were not
developed within a corporate IT group and/or specifically intended to use
only within that corporate enterprise qualify?
Does freeware count as "commercial"? For instance the only "for pay" Delphi
produced product I use is FeedDemon which recently became freeware.
Does the Delphi IDE use of .NET count as a commercial product?<RBG!>
 

Re: Is Delphi for Win32 still mainstream?

I.P. Nichols writes:
Quote
how do you define "commercial products"?
IMO, A generic software product developed by an application vendor who
sells copies of it to several corporate companies for profit.
In house development for internal use does not qualify, even if it is
out sourced.
Yes, the MS Office does qualify, but it is not developed in .NET!
Quote
Does the Delphi IDE use of .NET count as a commercial product?<RBG!>
No! :)
Recently I suggested to one of our sales guys who was pitching about
.net, that we would develop a Help->About screen in .net so that our
product can be called as a .net product! ;)
He doesn't care as long as he can tell his prospectus clients that our
product uses .net! ;)
 

Re: Is Delphi for Win32 still mainstream?

In article <4813b41e$XXXX@XXXXX.COM>, XXXX@XXXXX.COM says...
Quote
Wayne Niddery (TeamB) writes:
>"JohnE" <XXXX@XXXXX.COM>writes
>news:XXXX@XXXXX.COM...
>>I've successfully hired C++ programmers to do Delphi work, and it
>>didn't take them long to get up to speed.
>
>The only thing you have to watch is that they remember they need to free
>(non-owned) objects they create. C++ programmers are too used to
>automatic instantiation and destruction of locally defined classes.
>Getting used to having to create them doesn't take long, but eliminating
>the memory leaks takes longer. <g>
>

Heh, well...

A MODULAR PROGRAMMING LESSON FOR ALL DELPHI PROGRAMMERS

Nice. Put my name on the list.
:)
 

Re: Is Delphi for Win32 still mainstream?

L writes:
Quote
I am bringing back stack objects and records into my programming.
Mmany times I just don't need a full blown class instance. Going
against every OOP rule - yes. Do I care: nope. Neither does Niklaus
Wirth in his modular Oberon/ComponentPascal languages -where lots of
people use the stack.
I'm not so sure that is actually against every OOP rule. I have been
using stack objects (records) for a long time already, it it made sense.
--
Rudy Velthuis [TeamB] www.teamb.com
"Rarely is the question asked: Is our children learning?"
-- George W. Bush
 

Re: Is Delphi for Win32 still mainstream?

GrandmasterB writes:
Quote
"I.P. Nichols" <XXXX@XXXXX.COM>writes
news:4815fb92$XXXX@XXXXX.COM...
>>Yes, it does!
>>We only need more such examples.
>How many new Delphi (or C++ for that matter) desktop commercial
>product applications have been developed in the roughly two years
>that .NET 2.0+ has been available?

This to me wouldnt be a good example given the installation problems
I had with Delphi due to the J++ runtime requirement. If anything,
it re-enforces my position that making commercial software that
requires a huge runtime install is a bad idea.
Depends on the customer. If it is a package where you do the install
for them (or even also provide the hardware, like they do with the
software for my clinic), they won't care. If you mean shrinkwrap
software, you may have a point.
--
Rudy Velthuis [TeamB] www.teamb.com
"Attention to health is life's greatest hindrance."
-- Plato (427-347 B.C.)