If not .Net then what?

[Arne Vajhøj]

read my post above,...;-)

The one whre you for reasons unknown to me start to talk about MFC in
a Win32 API discusssion and use the term "Sh***", which I have no
idea about what means (the word that comes to my mind only has
4 letters not 5) ?

Arne

 

[Scott Roberts]

Hi Richard,


yes, this was meant for windows systems, i dont talk about any other
system,
nor linux, nor vx, nor mac or other archtitecture. It was only meant for
Windows Systems, and i think the OP was talking about windows,...

I've got to agree with Kerem. If you view .Net as a platform (as I do) then
so-called ".Net Applications" are, in fact, "standalone".

From reading Jim's other thread, he is apparently unhappy with the installed
base of the .Net framework and therefore doesn't view it as a viable
platform for his apps. No problem there, it's the same as not wanting to
write apps for linux or Macs or Mainframes because there just aren't enough
people who use those platforms.

But unlike those other platforms, .Net can be installed "on top of" Win32
which *is* widely deployed. Also, unlike those other platforms, I personally
believe that .Net *will* be ubiquitous in the next 3-5 years (if not
sooner).

 

[jim]

If by "Borland couldn't make a go of it" you mean "Borland has developed
10+ versions of it over the span of 10+ years" then I guess you're right.
I started using Delphi 2.0 in 1997.

I don't mean to run down Delphi (or Borland). I remember coding some pretty
cool apps with Turbo Pascal myself. I was simply commenting on the fact
that Borland spun off the developer tools section to a new company called
CodeGear. That makes me a little nervous as a developer.

People have been predicting the demise of Delphi for years. The reality
is, it's a niche product that performs admirably for it's intended
purpose. And I think it would be great for someone who wants to create
"standalone" Win32 apps. I would gauge it as "far superior" to VS up until
VS 2003. I agree with the previous poster who recommended Delphi 7. It's
very stable. D8 was a complete nightmare - so much so that I haven't tried
any version since.

I'll look into D7.

Further, you can supposedly port your code to linux fairly easily using
Kylix (Delphi for Linux), though I've never tried it (and neither did
anyone else, from what I can gather).

I called Borland about Kylix a year (maybe 2) ago, and the person that I
spoke to at Borland had never heard of Kylix. I had to show her the website
for it. At that point Kylix had not been upgraded in 3 years.

I really wish that companies that "retire" software (like Kylix and OS2)
would make it open source. It would be a real help to everyone.

Can you imagine what the world would be like if IBM open sourced OS2 instead
of letting it rot on the vine? It was better than Windows back then......

jim

 

[Richard Heathfield]

Arne Vajhøj said:

I think you should spend a bit more time studying .NET !

Let me explain the background. We were developing an analysis product for a
UK bank, we already had working code, and we were asked to try our code
out under .Net - which we did. It ran sixty times slower. Our jaws
dropped, we laughed, and we didn't bother with .Net from then on. Ever.

If you're supposed to be hauling eight thousand tons of freight from London
to Newcastle, and the boss suggests you try using a bicycle instead of
your existing freight train, well, you might give it a go (because it's
the boss asking), but when it doesn't work it would be very silly to blame
yourself for not studying the bicycle enough. You just go back to your
freight train.

Same with .Net - we came, we saw, we laughed - and left.

Since the original poster stated:

#My goal is to create desktop applications for use on Windows XP+ OSs

Then that should not be a problem.

Agreed. But I wasn't answering the OP. Rather, I was answering the person
who said "The only objection to the .NET framework I've heard is..." - so
I was just giving him a couple more to chew on.

I am not particular impressed by either claim. If I had ever created
an app that fast I would try to keep it a secret - if you get my point.

Yeah, I can understand that, although there is something to be said for the
rapid development of cheesy little toys. Sometimes, they turn into Real
Programs that can be a real benefit to lots of users (at which point it
becomes worth writing them more - um - carefully, shall we say?).

 

[Richard Heathfield]

Arne Vajhøj said:

I just don't think the original poster should have included
a group as general as comp.programming for a Windows specific
question.

Precisely. I agree entirely.

 

[Lasse Vågsæther Karlsen]

Thanks!

I've seen Delphi pop up a lot in these conversations, but I was kind of
afraid that it may not be that reliable since Borland couldn't make a go of
it.

Delphi, older versions, was a very very good development system, well
able to stand on its own against Microsofts tools. The main problem was
userbase and the decision to go for .NET which meant Borland would be
stuck in catch-up mode for a foreseeable future.

They lost the battle, however, mostly because they slipped on the
stability criteria and started shipping really buggy software. Couple
that with a low userbase and the future suddenly didn't look too bright.

If Borland had stuck to what it did best, produce a Win32 compiler, they
might've still had a competing product. These days Delphi is more like
roadkill.

(note, this is an opinion from a long-time Delphi and .NET user)

 

[Miha Markic]

Hi jim,

In your case Delphi would me my choice, too.
At least when your requirements are an OS that doesn't have .net installed
by default (XP).

 

[Jeff Gaines]

I've seen Delphi pop up a lot in these conversations, but I was kind of
afraid that it may not be that reliable since Borland couldn't make a go
of it.

I'd hate to begin using a language/IDE and have the company supporting it
go under. It would just waste a lot of time that I could have spent
learning something else.

Codegear is a subsidiary of Borland so they haven't given up yet

I have been following your thoughts with interest. I don't like Delphi and
the IDE is not as good as VS. I've even started playing with C again, I
could never get on with C++.

There is definitely a need for an IDE to develop pure desktop
applications, VS is much too web-centric.

 

[Scott Roberts]

I don't mean to run down Delphi (or Borland). I remember coding some

pretty cool apps with Turbo Pascal myself. I was simply commenting on the
fact that Borland spun off the developer tools section to a new company
called CodeGear. That makes me a little nervous as a developer.

While I did use Delphi in corporate environments, it was really adopted more
by hobbyists and freelancers. Borland decided to try to focus on enterprise
markets (you may recall them changing their name to "Inprise" for a bit) and
began to focus on non-Delphi tools. It was a bit perplexing to those of us
who loved Delphi because some version of Pascal had always been their
flagship product. I have no idea what they are doing now.

I called Borland about Kylix a year (maybe 2) ago, and the person that I
spoke to at Borland had never heard of Kylix. I had to show her the
website for it. At that point Kylix had not been upgraded in 3 years.

Kylix was highly demanded and highly touted. I don't really know why it
failed so miserably. I recall it getting fairly good reviews, and people
chalked it up to "linux users don't want to pay for software".

 

[Lasse Vågsæther Karlsen]

Arne Vajhøj said:

Let me explain the background. We were developing an analysis product for a
UK bank, we already had working code, and we were asked to try our code
out under .Net - which we did. It ran sixty times slower. Our jaws
dropped, we laughed, and we didn't bother with .Net from then on. Ever.

If you're supposed to be hauling eight thousand tons of freight from London
to Newcastle, and the boss suggests you try using a bicycle instead of
your existing freight train, well, you might give it a go (because it's
the boss asking), but when it doesn't work it would be very silly to blame
yourself for not studying the bicycle enough. You just go back to your
freight train.

Hauling cargo is usually not done the fastest way, just to make a point
here. The cost of doing so far outweighs the actual benefits. There is
typically a sweet spot where you calculate the cost of fuel, increased
wear and tear, and thus maintenance, against the reduced cost of labor,
and time-to-market. I've seen examples of around 75% of the best speed.
Bicycle? no... Trucks? perhaps...

My point? The task of picking the "best tool for the job" should never
use only one measurement to determine the "bestness".

Now, I'm not saying that you could justify switching to a system that
ran your workload at 1/60th of the current speed, but there could be
other trade-offs that could lead you to accept some speed degradation to
get other benefits, perhaps by rewriting the engine using a more
..NET-based approach. Since you don't describe the workload, I'll assume
the best .NET-based approach for this workload ran at 1/60th of the
speed of your current solution. In this case, .NET is entirely the wrong
tool for this particular job.

In your case it might not be possible to get pure .NET managed code to
do what you wanted with the speed you required, but its all about
picking the best tool for the job. Perhaps building the GUI would be
better with .NET and C++ would be better for your analysis engine.

All I can say is that .NET apps does not by a long shot run generally at
1/60th of the speed of a non-.NET app. I've seen faster ones, and I've
seen slower ones. To be fair, many of the slower ones were *really* slow
compared to the non-.NET implementation, but in that case the wrong tool
was being used.

It all depends.

In the original posters case, there are loads of questions that would
have to be asked before a reliable answer could be given to the question
of what is the best tool. Here's just a few of them:

- what is the program supposed to do?
- what kind of programming languages/systems do you know already?
- why the criteria of single-exe, no installer?
- what is the target userbase? (linked to what the program is supposed
to do)

 

[Lasse Vågsæther Karlsen]

If by "Borland couldn't make a go of it" you mean "Borland has developed
10+ versions of it over the span of 10+ years" then I guess you're
right. I started using Delphi 2.0 in 1997.

People have been predicting the demise of Delphi for years. The reality
is, it's a niche product that performs admirably for it's intended
purpose. And I think it would be great for someone who wants to create
"standalone" Win32 apps. I would gauge it as "far superior" to VS up
until VS 2003. I agree with the previous poster who recommended Delphi
7. It's very stable. D8 was a complete nightmare - so much so that I
haven't tried any version since.

Not to bring this entire discussion too far off-topic, but Borland was
good at making their niche products, but the latest versions have all
shipped (and been patched to) horribly buggy beasts.

Delphi had its time in the spotlight and could've pulled off a standing
ovation dance act, but it stumbled along the way. I wouldn't inflict
Delphi on my worst enemy these days.

 

[jim]

Thanks Miha!

Hi jim,

In your case Delphi would me my choice, too.
At least when your requirements are an OS that doesn't have .net installed
by default (XP).

--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/

In a thread about wrapping .Net applications using Thinstall and
Xenocode, it was pointed out that there may be better programming
languages/IDEs to use for the purpose of creating standalone, single
executable apps.

My goal is to create desktop applications for use on Windows XP+ OSs that
are distributed as single executables that do not require traditional
install packages to run.

I would like to use a drag and drop UI development tool like the .Net IDE
(or the old VB6) to make development as easy as possible. I am a
hobbyist programmer and would like to put out some useful apps, but I
don't want to have to become an expert at a complex language like C++ to
do so reliably.

More than one person responding to the previous thread held the opinion
that .Net was great for corporate environments where all PCs are strictly
regulated, but may not be the best option to develop the type of apps
that I would like to develop for the PC community at large.

So what, in your opinion, would be a good alternative to use to develop
the type of applications that I am trying to develop?

jim

 

[Scott Roberts]

Arne Vajhøj said:

Let me explain the background. We were developing an analysis product for
a
UK bank, we already had working code, and we were asked to try our code
out under .Net - which we did. It ran sixty times slower. Our jaws
dropped, we laughed, and we didn't bother with .Net from then on. Ever.

I'm not sure that your inability to write efficient code with .Net is
necessarily and indictment against .Net.

If you're supposed to be hauling eight thousand tons of freight from
London
to Newcastle, and the boss suggests you try using a bicycle instead of
your existing freight train, well, you might give it a go (because it's
the boss asking), but when it doesn't work it would be very silly to blame
yourself for not studying the bicycle enough. You just go back to your
freight train.

I think you may have been asked to use freight train with more dials and
switches, and you couldn't figure out the controls, so you gave up.

Same with .Net - we came, we saw, we laughed - and left.

You came, you couldn't figure it out, you left.

..Net is (eventually) compiled into native code, so there is no reason for it
to be slower - other than lack of programmer skill, of course.

 

[jim]

I'm not sure that your inability to write efficient code with .Net is
necessarily and indictment against .Net.


I think you may have been asked to use freight train with more dials and
switches, and you couldn't figure out the controls, so you gave up.


You came, you couldn't figure it out, you left.

.Net is (eventually) compiled into native code, so there is no reason for
it to be slower - other than lack of programmer skill, of course.

I strongly disagree. Although I am no .Net expert, I am pretty adept at the
simple stuff. And, the simple .Net apps that I wrote had slower UIs and
presented data slower than their desktop counterparts.

The sad thing is that the desktop counterparts weren't even C++ - they were
VB6.

jim

 

[Scott Roberts]

I strongly disagree. Although I am no .Net expert, I am pretty adept at
the simple stuff. And, the simple .Net apps that I wrote had slower UIs
and presented data slower than their desktop counterparts.

The sad thing is that the desktop counterparts weren't even C++ - they
were VB6.

When you say "simple stuff" it makes me think that you probably used the
built-in, drag & drop, "RAD" features of the IDE. I would contend that those
features are not intended for use in enterprise applications.

 

[Herfried K. Wagner [MVP]]

The one whre you for reasons unknown to me start to talk about MFC in
a Win32 API discusssion and use the term "Sh***", which I have no
idea about what means (the word that comes to my mind only has
4 letters not 5) ?

I assume it should refer to the word variant which has an "e" as its last
letter.

 

[Richard Heathfield]

Lasse Vågsæther Karlsen said:

Now, I'm not saying that you could justify switching to a system that
ran your workload at 1/60th of the current speed,

Not only could we not, but we saw no reason why we would want to.

but there could be
other trade-offs that could lead you to accept some speed degradation to
get other benefits, perhaps by rewriting the engine using a more
.NET-based approach.

Excuse me? We already had working code - and you want us to *rewrite* it?
As in, write it *again*? I Don't Think So. We already had a solution that
worked well and worked fast. We tried it on .Net and suddenly it took ten
minutes instead of ten seconds. Now, we had two ways we could go - rewrite
the code to find two orders of decimal magnitude from somewhere (bearing
in mind that the original coding did not build in two orders of stupidity
for us to magically find later), or drop .Net - it was no contest, believe
me.

Since you don't describe the workload, I'll assume
the best .NET-based approach for this workload ran at 1/60th of the
speed of your current solution. In this case, .NET is entirely the wrong
tool for this particular job.

Right. That's what we thought, too.

In your case it might not be possible to get pure .NET managed code to
do what you wanted with the speed you required, but its all about
picking the best tool for the job. Perhaps building the GUI would be
better with .NET and C++ would be better for your analysis engine.

GUI? Why would we need a GUI? It was analysis software, not a video game.
Its job was to dig out dependency relationships from application source
files, so it was parsing SQL, HTML, C, C++, VB, VBS, and a bunch of other
stuff (as instructed over a socket), and writing dependency data back
through the same socket. No GUI requested, required, or desired.

All I can say is that .NET apps does not by a long shot run generally at
1/60th of the speed of a non-.NET app.

I'm delighted to hear it, but in a fast-moving business like software
development you don't get two chances at a first impression.

 

[jim]

When you say "simple stuff" it makes me think that you probably used the
built-in, drag & drop, "RAD" features of the IDE. I would contend that
those features are not intended for use in enterprise applications.

You would be right. But, that's what we used to build the VB6 apps before
..Net - so why the disparity in speed?

And, why would RAD not be a thing needed in enterprise development? In all
of my enterprise development (back a few years) RAD was a big reason for
using VB. It saved us time in development and mocking up new apps.

jim

 

[Richard Heathfield]

Scott Roberts said:

I'm not sure that your inability to write efficient code with .Net is
necessarily and indictment against .Net.

That's another way of looking at it, it's true. What you seem to be saying
is that it's really hard to write efficient code with .Net - which is just
another way of indicting it.

You came, you couldn't figure it out, you left.

What's to figure out? .Net was as slow as syrup, when we already had
something as fast as fireworks. So obviously we dropped it. You can say
it's down to a lack of programmer skill if you like, but your claim
translates to ".Net is so difficult that it can't be used efficiently by
two programmers with over 40 years C++ experience between them" - which
doesn't bode well for .Net, does it?

 

[jim]

Herfried!

Nice to see you around!

jim

I assume it should refer to the word variant which has an "e" as its last
letter.