If not .Net then what?

[jim]

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

[Andre Kaufmann]

Scott Roberts wrote:

>

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

[...]
Did you bother to find out why it was so much slower? I'd be interested
to know, just for my own edification.

Also it would be interesting, how the code was ported to .NET ?
Was it simply C++ / C recompiled as IL code ? This would be not a good
idea, except if you have to ship safe code.
I assume the original code was C based and used C string concatenations.
Simply porting such code to .NET without using StringBuilder wouldn't be
a good idea, performance wise.
Strings in .NET are immutable, which is still a reasonable decision
regarding multi threaded programming and safety.

I can write dumb code in C, which is slower than .NET code. Also I can
tune .NET code by simply using extension libraries like the (beta)
Parallel extensions to .NET, which by changing a single line makes the
code to use multiple cores and outperforms the C/C++ one using only a
single core.

As many other posters wrote, use the right tool for a special task and
don't assume that one code optimized for one platform runs and performs
the same way on other platforms.
Andre

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Richard Heathfield wrote:

Arne Vajhøj said:

>Richard Heathfield wrote:

>>Terry Olsen said:
The only objection to the .NET framework I've heard is from people who
say they don't want some big runtime library installed on their pc's.
Another objection is that it's slow. The first program I moved to .Net
ran around 60 times slower than native - way too slow to be useful.

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.

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

You may benefit from looking again.

A factor x60 is not a typical difference.

I would expect a difference somewhere in the 0-60% range.

Something went wrong in that port.

Note that already having working code may actually be one
of the reasons. Porting design 1:1 from language A to B
can often result in poor design.

>>A third objection is that it's non-portable.

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 agree on that one.

Mono is a very interesting project.

But I would not recommend .NET as a portable solution
based on Mono.

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?).

Yep - it has happened many times !

Arne

[Herfried K. Wagner [MVP]]

"Scott Roberts" <sr******@no.spam.here-webworks-software.comschrieb:

>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.

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.

People have been predicting the demise of Delphi for years.

Well, yes, but on the other hand Classic Visual Basic (Version 1.0 to 6.0)
was a flagship product and it has been "killed" too without providing an
acceptable upgrade path. If preservation of assets is important, make sure
there exists more than one implementation of the programming language and
the libraries used by applications developed using it. In addition, the
programming language should be widely adopted, so you are not alone if one
vendor suddenly decides to stop further development. Sure, there are many
other factors to be taken into account too for choosing the right
programming language.

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.

Delphi is now developed by another company than Borland. I am not sure
about support for older versions of Delphi like Delphi 7. Applications
developed using older versions may not be guaranteed to work properly on
future versions of Windows. That's what will finally kill VB6 too.

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).´

Is Kylix still supported and developed further?

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

jim wrote:

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.

Hm. That text does not really make any sense. A win forms .NET app
is a desktop app as well. And comparing a web app with a desktop app
is at least when it comes to speed comparing apples with oranges.

Arne

[jim]

"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote in message
news:u2****************@TK2MSFTNGP06.phx.gbl...

"Scott Roberts" <sr******@no.spam.here-webworks-software.comschrieb:

>>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.

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.

People have been predicting the demise of Delphi for years.

Well, yes, but on the other hand Classic Visual Basic (Version 1.0 to 6.0)
was a flagship product and it has been "killed" too without providing an
acceptable upgrade path. If preservation of assets is important, make
sure there exists more than one implementation of the programming language
and the libraries used by applications developed using it. In addition,
the programming language should be widely adopted, so you are not alone if
one vendor suddenly decides to stop further development. Sure, there are
many other factors to be taken into account too for choosing the right
programming language.

>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.

Delphi is now developed by another company than Borland. I am not sure
about support for older versions of Delphi like Delphi 7. Applications
developed using older versions may not be guaranteed to work properly on
future versions of Windows. That's what will finally kill VB6 too.

>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).´

Is Kylix still supported and developed further?

Not by Borland. The last time they posted a download for it was for a
debugger patch for Linux 2.4 kernel on 01/23/2002 (according to their site
at http://info.borland.com/devsupport/kylix/downloads/).

I had called the company (in 2005 I think) and inquired about Kylix. The
girl answering the phone had never heard of it and I had to lead her to her
company's Kylic pages on their site. She tried to find out something, but
was unable to find anyone that knew anything about it then.

CodeGear (the offshoot of Borland that took all of the developers tools)
doesn't mention it on their site, and any attempts to contact the usergroups
(listed on
http://newsgroups.borland.com/cgi-bi...c.kylix.&utag= )
failed to bring back any posts.

It would have been nice if they donated it to open source instead of just
letting it rot.

jim

[jim]

"Arne Vajhøj" <ar**@vajhoej.dkwrote in message
news:47***********************@news.sunsite.dk...

jim wrote:

>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.

Hm. That text does not really make any sense. A win forms .NET app
is a desktop app as well. And comparing a web app with a desktop app
is at least when it comes to speed comparing apples with oranges.

The .Net apps I was refering to here were all desktop apps.

The one database access app that I wrote in VB.Net 1.0 as a webform that
queried an Oracle database perfomed even worse.

jim

[jim]

"jim" <ji*@home.netwrote in message
news:vr*******************@bignews7.bellsouth.net. ..

>
"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote in message
news:u2****************@TK2MSFTNGP06.phx.gbl...

>"Scott Roberts" <sr******@no.spam.here-webworks-software.comschrieb:

>>>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.

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.

People have been predicting the demise of Delphi for years.

Well, yes, but on the other hand Classic Visual Basic (Version 1.0 to
6.0) was a flagship product and it has been "killed" too without
providing an acceptable upgrade path. If preservation of assets is
important, make sure there exists more than one implementation of the
programming language and the libraries used by applications developed
using it. In addition, the programming language should be widely
adopted, so you are not alone if one vendor suddenly decides to stop
further development. Sure, there are many other factors to be taken into
account too for choosing the right programming language.

>>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.

Delphi is now developed by another company than Borland. I am not sure
about support for older versions of Delphi like Delphi 7. Applications
developed using older versions may not be guaranteed to work properly on
future versions of Windows. That's what will finally kill VB6 too.

>>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).´

Is Kylix still supported and developed further?

Not by Borland. The last time they posted a download for it was for a
debugger patch for Linux 2.4 kernel on 01/23/2002 (according to their site
at http://info.borland.com/devsupport/kylix/downloads/).

I had called the company (in 2005 I think) and inquired about Kylix. The
girl answering the phone had never heard of it and I had to lead her to
her company's Kylic pages on their site. She tried to find out something,
but was unable to find anyone that knew anything about it then.

CodeGear (the offshoot of Borland that took all of the developers tools)
doesn't mention it on their site, and any attempts to contact the
usergroups (listed on
http://newsgroups.borland.com/cgi-bi...c.kylix.&utag= )
failed to bring back any posts.

It would have been nice if they donated it to open source instead of just
letting it rot.

jim

Then again, it would have been nice to see OS2 and Visual Basic open
sourced.

jim

[Miha Markic]

Troll or not, he has a point. copy & run is a weak point in .net right now.
That is until you are guaranteed that OS has a .net framework installed
which isn't to happen anytime soon.
--
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/

"Chris Mullins [MVP - C#]" <cm******@yahoo.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

>I wish you weren't a troll.

This is a great conversation to have, as there are a number of good
options, all with their own unique set of pros and cons.

... but given, as evidenced from the other thread, that you're just
trolling, it doesn't seem worth the time. Ah well.

--
Chris Mullins

[=?ISO-8859-1?Q?Lasse_V=E5gs=E6ther_Karlsen?=]

I'm going to break my habit here and place a reply/post to the original
post you made.

jim wrote:

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.

There's plenty. As evident in other posts here, Delphi is one of them.
Be sure to evaluate carefully which version you *need* though, as the
latter versions have gotten steadily more buggy/unstable, at least that
has been my experience.

>
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 very much like to know why you have this criteria. While I can
understand the wish to not having to include, or force the download of,
a multi-megabyte runtime engine, everyone I've talked to (all levels of
users) seems to prefer an installation program to take care of things
like correct location on disk, start menu items, uninstallation, etc.

There's installer applications that doesn't add that much to the final
size as well so size should not be a big deal in that respect either.

>
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.

You'll pretty fast find out that any development engine worth its own
cost will be a complex endeavour. If you pick Delphi or C#, just to take
two examples, you'll find that most of your time will not be spent
learning the language, although C# with its latest 3.0 version is
rapidly building up speed in the complex arean. Instead, most of your
time will be spent either looking through the runtime classes to figure
out which ones to use and how to use them, or online googling for 3rd
party libraries or examples of what you need to do.

This holds true for VB, Delphi, C#, Java, and C++ and many other systems.

Your best option against this uphill battle is to pick one development
tool and get good at it. When you're good at one of them, switching
isn't going to be that tough since a lot of things are similar enough
for you to find them more easily once you've learned how to find them in
one system.

>
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.

This still holds true, to a certain degree. I've found that the best
option to combat this is to do one of the following:

1. bundle the .NET runtime with your installer (making it bigger)
2. make the installer download and install the runtime, if necessary
3. add a link on your download page to the runtime downloads

To be honest, I prefer solution 1, with two installers, one with the
runtime and one without. This way the downloadee (?) can pick the right
one for his machine, and even install it offline.

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

Personally I would go with C#, but I already know C#. I don't know if
this is a good enough answer for you though. If you absolutely cannot
use .NET, I would pick another system, but each system have its pros and
cons, you're going to have to pick the ones you care about.

--
Lasse Vågsæther Karlsen
mailto:la***@vkarlsen.no
http://presentationmode.blogspot.com/

[Kerem Gümrükcü]

Servus Herfried,

>Is Kylix still supported and developed further?

no, Kylix is dead! There is something that is close to Kylix and
it is called Lazarus. It is a open-source FP(ascal)C IDE that can
be used to develop apps for windows and linux, but it is still under
development, though you can write code with it, that can be compiled
without change on windows and linux, as long as you dont use
platform dependend libraries and functions. Give it a try if you like, but
dont expect too much,...it is still under development and far away from
production,...thats what i found out,...

Regards

Kerem

--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Microsoft Live Space: http://kerem-g.spaces.live.com/
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."

[=?UTF-8?B?TGFzc2UgVsOlZ3PDpnRoZXIgS2FybHNlbg==?=]

Miha Markic wrote:

Troll or not, he has a point. copy & run is a weak point in .net right now.
That is until you are guaranteed that OS has a .net framework installed
which isn't to happen anytime soon.

Copy&run problems like described in this thread holds true for many
languages. There's pros and cons with all these choices. Pick the ones
you can live with and care about.

--
Lasse Vågsæther Karlsen
mailto:la***@vkarlsen.no
http://presentationmode.blogspot.com/

[Richard Heathfield]

Scott Roberts said:

>

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

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?

Did you bother to find out why it was so much slower? I'd be interested
to know, just for my own edification.

Ah, I approve. :-)

Okay - *at the time*, no, we didn't bother. We simply showed the boss the
comparative figures, and he agreed that there was no point in continuing
with .Net. After all, everyone has deadlines, and we'd already beaten
ours. The last thing anyone wanted was to add another three months to the
project while we fiddled around trying to figure out how to get Yet
Another Microsoft Technology to do as it's told. It was that or deliver
fast code, early, within budget. We chose the latter. Wouldn't you?

Later on, however, one or other of us (I forget which) discovered (I'm not
sure how authoritatively) that, apparently, .Net is not good at heavily
recursive code, and since our code did little else *but* recurse (its
function was to extract dependency relationships from source code, and
much of this was achieved by parsing the source to look for stuff like
#include "foo.h", <a href="yadayadayada.html">, etc etc - and parsing is
an inherently recursive process), this may go some way towards explaining
the huge performance disparity between .Net and native code.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Herfried K. Wagner [MVP]]

"Kerem Gümrükcü" <ka*******@hotmail.comschrieb:

>>Is Kylix still supported and developed further?

no, Kylix is dead!

OK, so I didn't miss anything since I took a look at it for the last time.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[jim]

"Lasse Vågsæther Karlsen" <la***@vkarlsen.nowrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

I'm going to break my habit here and place a reply/post to the original
post you made.

jim wrote:

>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.

There's plenty. As evident in other posts here, Delphi is one of them. Be
sure to evaluate carefully which version you *need* though, as the latter
versions have gotten steadily more buggy/unstable, at least that has been
my experience.

Well, that's pretty much takes Delphi out of the running then. I create
enough bugs myself - don't really need much help in that area.

>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 very much like to know why you have this criteria. While I can
understand the wish to not having to include, or force the download of, a
multi-megabyte runtime engine, everyone I've talked to (all levels of
users) seems to prefer an installation program to take care of things like
correct location on disk, start menu items, uninstallation, etc.

There's installer applications that doesn't add that much to the final
size as well so size should not be a big deal in that respect either.

The idea (in addition to avoiding denpendencies wich can change on a user's
sytem) was to also be able to run the single exe apps from USB drives or
even from websites. The idea being that the more places you can run the
apps, the more people can (and hopefully will) run the apps.

>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.

You'll pretty fast find out that any development engine worth its own cost
will be a complex endeavour. If you pick Delphi or C#, just to take two
examples, you'll find that most of your time will not be spent learning
the language, although C# with its latest 3.0 version is rapidly building
up speed in the complex arean. Instead, most of your time will be spent
either looking through the runtime classes to figure out which ones to use
and how to use them, or online googling for 3rd party libraries or
examples of what you need to do.

This holds true for VB, Delphi, C#, Java, and C++ and many other systems.

Your best option against this uphill battle is to pick one development
tool and get good at it. When you're good at one of them, switching isn't
going to be that tough since a lot of things are similar enough for you to
find them more easily once you've learned how to find them in one system.

I've considered C# (since a lot of examples are written in it and they'd
help me to learn more quickly), but I used to code in VB and feel more
comfortable with that language.

Anothe plus for C# is that the syntax is similar to C++ - another language
I'd like to learn.

>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.

This still holds true, to a certain degree. I've found that the best
option to combat this is to do one of the following:

1. bundle the .NET runtime with your installer (making it bigger)
2. make the installer download and install the runtime, if necessary
3. add a link on your download page to the runtime downloads

To be honest, I prefer solution 1, with two installers, one with the
runtime and one without. This way the downloadee (?) can pick the right
one for his machine, and even install it offline.

Since these apps are mostly free (being a hobbyist coder and all) I would
choose option 2. That option would keep things as simple as possible for
most users and still dl the framework if needed.

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

Personally I would go with C#, but I already know C#. I don't know if this
is a good enough answer for you though. If you absolutely cannot use .NET,
I would pick another system, but each system have its pros and cons,
you're going to have to pick the ones you care about.

I may take the plungs and go C#. I always have hated the syntax of C#/C++,
but the vast amount of examples written in C# and the power of C++ are
mighty compelling.

Thanks for your post.

jim

[Kevin Frevert]

"Arne Vajhøj" <ar**@vajhoej.dkwrote in message
news:47***********************@news.sunsite.dk...

Kevin Frevert wrote:

>Borland spun off it's IDE tools into another "company" called CodeGear.
Delphi has been "dying" for over twenty years (according to "experts"),
but it's products have never been stronger. With native 64-bit support
on the horizon, it's future continues to look bright.

I agree that Delphi absolutely is a possibility for the original
poster.

But claiming that 64 bit support coming in 2008 should indicate
a bright future seems a bit optimistic to me. Almost all other
languages has had for a few years already.

Indicates an investment in future growth. With CodeGear's roadmap in place,
it appears they have a direction. Now the real trick is getting there.

Not that it matters, but doesn't .Net (2.0/3.whatever) target only Win32?

[=?ISO-8859-1?Q?Lasse_V=E5gs=E6ther_Karlsen?=]

jim wrote:

"Lasse Vågsæther Karlsen" <la***@vkarlsen.nowrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

>I'm going to break my habit here and place a reply/post to the original
post you made.

jim wrote:

>>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.

There's plenty. As evident in other posts here, Delphi is one of them. Be
sure to evaluate carefully which version you *need* though, as the latter
versions have gotten steadily more buggy/unstable, at least that has been
my experience.

Well, that's pretty much takes Delphi out of the running then. I create
enough bugs myself - don't really need much help in that area.

Well, to be honest, I'm perhaps a bit vauge here. What I mean to say is
that latter versions of Delphi is unstable in themselves. The code they
produce seems fine though.

>

>>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 very much like to know why you have this criteria. While I can
understand the wish to not having to include, or force the download of, a
multi-megabyte runtime engine, everyone I've talked to (all levels of
users) seems to prefer an installation program to take care of things like
correct location on disk, start menu items, uninstallation, etc.

There's installer applications that doesn't add that much to the final
size as well so size should not be a big deal in that respect either.

The idea (in addition to avoiding denpendencies wich can change on a user's
sytem) was to also be able to run the single exe apps from USB drives or
even from websites. The idea being that the more places you can run the
apps, the more people can (and hopefully will) run the apps.

Running the application from a external drive without installing it is a
good goal, but doesn't necessarily mean that you need to limit yourself
to one file in total. FireFox comes to mind and requires a whole host of
files and directories to be present.

Running it from the web is an entirely different ordeal though and will
likely involve either using ClickOnce deployment or running the app with
severly limited rights. Unless you mean that you want to click the
Open/Run button in the IE/FireFox download dialog and run the program
from the cache, in which case the program might be gone later.

--
Lasse Vågsæther Karlsen
mailto:la***@vkarlsen.no
http://presentationmode.blogspot.com/

[Kevin Frevert]

"jim" <ji*@home.netwrote in message
news:%g*******************@bignews7.bellsouth.net. ..

>>
There's plenty. As evident in other posts here, Delphi is one of them. Be
sure to evaluate carefully which version you *need* though, as the latter
versions have gotten steadily more buggy/unstable, at least that has been
my experience.

Well, that's pretty much takes Delphi out of the running then. I create
enough bugs myself - don't really need much help in that area.

I (along with 12 other developers here) use Delphi 2007 (latest version) on
a daily basis and it works flawlessly.

My experience with Delphi (started way back with D2)

D6 - Best version, ever
D7 - D6 with .Net compiler preview.
D8 (first .Net only version) - not so good
D2005 (first .Net and Win32 mixed IDE) better, but IDE had some quirks
D2006 better than D2005, and after the 2nd service pack rather rock solid
D2007 - huge piece of granite right out of the box. I haven't had to shut
down D2007 for over two weeks (doing lots of debugging ). Can't say the
same for Visual Studio (which itself is a pretty rock solid ide).

Even if you go the VS/C# route, you won't be disappointed.

Good luck,
krf

[Andre Kaufmann]

Richard Heathfield wrote:

Scott Roberts said:

[...]
Later on, however, one or other of us (I forget which) discovered (I'm not
sure how authoritatively) that, apparently, .Net is not good at heavily
recursive code, and since our code did little else *but* recurse (its

Recursive code doesn't IMHO cause a performance problem in .NET. This is
rather a problem for unexperienced C++ programmers placing large objects
on the stack.

That remembers me of a famous article in a German computer magazine,
stating that Java is multiple times faster than C++.
But the author(s) used std::string objects in C++ like Java string
objects and passed them by value, instead as reference. So the C++
compiler copied always the strings to a temporary object on every
function call. And since the code was heavily recursive .....

Do you see the similarities ? In this case the author stated that the
same code did run several times faster in a managed language, than in
C++. I think you are stating currently the opposite ;-)
And if the author would have done the same as your team, he wouldn't
have touched C++ again, because it's so damn slow.

I think the function in your code, which is called recursively uses a
string parameter in it's arguments.

function was to extract dependency relationships from source code, and
much of this was achieved by parsing the source to look for stuff like
#include "foo.h", <a href="yadayadayada.html">, etc etc - and parsing is

There would have been several other possibilities in .NET:

a) Use regular expressions - provided in .NET directly. You have the
option to use on the fly compiled regular expressions in .NET

b) Use a full fledged parser like ANTLR

c) Compile a mixed mode application in .NET
The native part is still native and the other code, using .NET will
be compiled to IL code.
Has downsides, but sometimes still the fastest solution

d) Convert the Code to the .NET platform, not simply recompiling

E.g. replacing the text "oldtext" by "newtext" in a single text file
named "myfile.txt" could be done in a single line in .NET (C#)

File.WriteAllText(
File.ReadAllText(
"myfile.text".Replace("oldtext",
"newtext")), "myfile.text");

(Despited my newsreader wrapped to single line to 3 lines ;-) )

Perhaps good enough for small files, but not a good idea for large
files. So even in .NET there are multiple solutions, some are
faster to implement, but performance wise not always a good idea.

an inherently recursive process), this may go some way towards explaining
the huge performance disparity between .Net and native code.

What about profiling ? Takes only a few minutes.

All in all just the meaning of a "pointy-clicky" developer ;;;-)

By the way. The same way you've (as I assume) ported your code to .NET
Quake II (IIRC) has been ported - simply by recompiling and has reached

>90% of the original speed of the native compiled application.

Andre

[jim]

"Lasse Vågsæther Karlsen" <la***@vkarlsen.nowrote in message
news:uf**************@TK2MSFTNGP05.phx.gbl...

jim wrote:

>"Lasse Vågsæther Karlsen" <la***@vkarlsen.nowrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

>>I'm going to break my habit here and place a reply/post to the original
post you made.

jim wrote:
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.
There's plenty. As evident in other posts here, Delphi is one of them.
Be sure to evaluate carefully which version you *need* though, as the
latter versions have gotten steadily more buggy/unstable, at least that
has been my experience.

Well, that's pretty much takes Delphi out of the running then. I create
enough bugs myself - don't really need much help in that area.

Well, to be honest, I'm perhaps a bit vauge here. What I mean to say is
that latter versions of Delphi is unstable in themselves. The code they
produce seems fine though.

>>

>>>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 very much like to know why you have this criteria. While I can
understand the wish to not having to include, or force the download of,
a multi-megabyte runtime engine, everyone I've talked to (all levels of
users) seems to prefer an installation program to take care of things
like correct location on disk, start menu items, uninstallation, etc.

There's installer applications that doesn't add that much to the final
size as well so size should not be a big deal in that respect either.

The idea (in addition to avoiding denpendencies wich can change on a
user's sytem) was to also be able to run the single exe apps from USB
drives or even from websites. The idea being that the more places you
can run the apps, the more people can (and hopefully will) run the apps.

Running the application from a external drive without installing it is a
good goal, but doesn't necessarily mean that you need to limit yourself to
one file in total. FireFox comes to mind and requires a whole host of
files and directories to be present.

Running it from the web is an entirely different ordeal though and will
likely involve either using ClickOnce deployment or running the app with
severly limited rights. Unless you mean that you want to click the
Open/Run button in the IE/FireFox download dialog and run the program from
the cache, in which case the program might be gone later.

ClickOnce deployment over thw web really got me excited....then I found out
how limited it was....

jim

[Bart C]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:24*********************@bt.com...

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.

For me that would be intriguing. 60x is a big slowdown. What was the main
reason for the slowdown? .Net is not interpreted as far as I know (it runs
some intermediate language via JIT compiler or whatever?).

It would be interesting to found out why: maybe you could have fixed
something that made it run *faster* than what you had. Or maybe you'd
discover some basic truth that you can use as an argument against .Net.

Perhaps you were not motivated enough and were relieved at the results.

Bart

[Andre Kaufmann]

Kevin Frevert wrote:

"Arne Vajhøj" <ar**@vajhoej.dkwrote in message
[...]
Not that it matters, but doesn't .Net (2.0/3.whatever) target only Win32?

Not at all.

E.g.: WinCE (PDA development),
Win64
Micro controller framework
Smart Clients running in a browser
-Silverlight 2.0 (alpha currently)
....

Other vendors: Novel Mono - Linux implementation

So sum it up .NET isn't bound to Win32 generally ;-).

Andre

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Kevin Frevert wrote:

Not that it matters, but doesn't .Net (2.0/3.whatever) target only Win32?

No.

..NET has had 64 bit since version 2.0 (2.0 was released in 2005,
but the 64 bit version may have been in 2006).

Arne

[=?ISO-8859-1?Q?Lasse_V=E5gs=E6ther_Karlsen?=]

Kevin Frevert wrote:

"jim" <ji*@home.netwrote in message
news:%g*******************@bignews7.bellsouth.net. ..

>>There's plenty. As evident in other posts here, Delphi is one of them. Be
sure to evaluate carefully which version you *need* though, as the latter
versions have gotten steadily more buggy/unstable, at least that has been
my experience.

Well, that's pretty much takes Delphi out of the running then. I create
enough bugs myself - don't really need much help in that area.

I (along with 12 other developers here) use Delphi 2007 (latest version) on
a daily basis and it works flawlessly.

My experience with Delphi (started way back with D2)

D6 - Best version, ever
D7 - D6 with .Net compiler preview.
D8 (first .Net only version) - not so good
D2005 (first .Net and Win32 mixed IDE) better, but IDE had some quirks
D2006 better than D2005, and after the 2nd service pack rather rock solid
D2007 - huge piece of granite right out of the box. I haven't had to shut
down D2007 for over two weeks (doing lots of debugging ). Can't say the
same for Visual Studio (which itself is a pretty rock solid ide).

I'm having the exact opposite results.

D2007 sucks up 700+MB of memory doing nothing, unstable as a house of
cards and slow as a doorstop for simple code intellisense. Granted, it's
a rather big project, but I have projects in Visual Studio 10x times
that size that doesn't have any problems or slowdowns at all. Some code
even trips it up in the editor so when I hove my mouse over something it
goes into a loop of checking-displaying nothing-checking-displaying
nothing-etc. all I can see is a buzzing mouse cursor until I move the
mouse away. The help file is a joke as well, doesn't show anything for
about 99% of whatever I ask for help about, unless I go in and manually
search it from the help index (as opposed to hitting F1 in the source
code editor).

--
Lasse Vågsæther Karlsen
mailto:la***@vkarlsen.no
http://presentationmode.blogspot.com/

[jim]

"jim" <ji*@home.netwrote in message
news:dQ*******************@bignews7.bellsouth.net. ..

>
"Lasse Vågsæther Karlsen" <la***@vkarlsen.nowrote in message
news:uf**************@TK2MSFTNGP05.phx.gbl...

>jim wrote:

>>"Lasse Vågsæther Karlsen" <la***@vkarlsen.nowrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl.. .
I'm going to break my habit here and place a reply/post to the original
post you made.

jim wrote:
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.
There's plenty. As evident in other posts here, Delphi is one of them.
Be sure to evaluate carefully which version you *need* though, as the
latter versions have gotten steadily more buggy/unstable, at least that
has been my experience.

Well, that's pretty much takes Delphi out of the running then. I create
enough bugs myself - don't really need much help in that area.

Well, to be honest, I'm perhaps a bit vauge here. What I mean to say is
that latter versions of Delphi is unstable in themselves. The code they
produce seems fine though.

>>>
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 very much like to know why you have this criteria. While I can
understand the wish to not having to include, or force the download of,
a multi-megabyte runtime engine, everyone I've talked to (all levels of
users) seems to prefer an installation program to take care of things
like correct location on disk, start menu items, uninstallation, etc.

There's installer applications that doesn't add that much to the final
size as well so size should not be a big deal in that respect either.

The idea (in addition to avoiding denpendencies wich can change on a
user's sytem) was to also be able to run the single exe apps from USB
drives or even from websites. The idea being that the more places you
can run the apps, the more people can (and hopefully will) run the apps.

Running the application from a external drive without installing it is a
good goal, but doesn't necessarily mean that you need to limit yourself
to one file in total. FireFox comes to mind and requires a whole host of
files and directories to be present.

Running it from the web is an entirely different ordeal though and will
likely involve either using ClickOnce deployment or running the app with
severly limited rights. Unless you mean that you want to click the
Open/Run button in the IE/FireFox download dialog and run the program
from the cache, in which case the program might be gone later.

ClickOnce deployment over thw web really got me excited....then I found
out how limited it was....

I really don't get Microsoft's decision to move away from activeX. ActiveX
was THE web app development tool, IMHO.

You could (and I did) basically develop complete applications as activeX
controls and have them run in the browser.

I even wrote an activeX control to repair damage done by a virus that had
been set loose in the company I was working at once.

ActiveX had almost everything you needed to develop apps that really ran
across the internet.

Oh well....

jim

[gerry]

"Jeff Gaines" <wh*********@newsgroups.nospamwrote in message
news:xn****************@msnews.microsoft.com...

On 28/12/2007 in message <eQ******************@bignews7.bellsouth.netjim
wrote:

....

VS is much too web-centric.

...

wow - now there is a very revealing statement !

[Richard Heathfield]

Scott Roberts said:

<snip>

I'm curious why your boss even wanted to investigate .Net since the
project was already complete.

(Well, we were halfway through testing, actually. But yeah.) Company
policy, basically. .Net had (literally) just been released, and this
client was, they said, one of the first companies in the UK to get hold of
the release version. Their policy was to switch every possible project
over to .Net as soon as was practicable. Hence the edict from on high to
investigate the practicality thereof - which we did, to our complete
satisfaction.

Don't you generally choose a platform
*before* you begin such a project?

No, actually. Why would the *platform* matter? Who gives a stuff?

In this case, we wrote the code in ISO C++ (plus Berkeley sockets)
specifically because we didn't know what platform it would eventually run
on. We favoured putting it on a Unix box, which is why we made it drivable
via a socket - just in case a miracle happened and we got our way. We
actually developed on Cygwin and Linux (because we liked g++), but then we
were told to port it to Windows. That took - oh, ten minutes or so,
basically hacking around at the sockets code. Then we were told to port it
to .Net. If we'd been silly enough to make it platform-specific at the
beginning, we'd have run out of time or money or both.

<snip>

Recursion incurs the overhead of having to
repeatedly build new stack frames. "

Well, duh. :-)

Of course we all know that any recursive routine can be rewritten as an
iterative routine. So I still contend that the "problem" was with your
code (specifically, it's lack of optimization for the new platform).

Nonsense. Natively, it ran like a ferret up an accordionist's trousers, so
clearly there is no intrinsic obstacle to good performance on recursive
programs. If .Net can't handle recursion, it is not suitable for problems
that are best expressed recursively.

The whole reason for having high level languages is so that you can express
the problem in the problem domain. If the problem is recursive (and
language parsing /is/ recursive in nature), then a recursive solution is
practical and sensible. Removing the recursion at source code level for
the benefit, not of the programmer, but of the *computer*, is Just Plain
Daft.

Optimising for the platform is all very well, but one should optimise the
platform too if possible, and in this case the optimum platform is
achieved when one removes an entire useless abstraction layer and lets the
code run natively.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Andre Kaufmann said:

Richard Heathfield wrote:

>Scott Roberts said:

[...]
Later on, however, one or other of us (I forget which) discovered (I'm
not sure how authoritatively) that, apparently, .Net is not good at
heavily recursive code, and since our code did little else *but* recurse
(its

Recursive code doesn't IMHO cause a performance problem in .NET.

Well, if that wasn't it, it was something else. Certainly the performance
problem existed.

This is
rather a problem for unexperienced C++ programmers placing large objects
on the stack.

No. If that were true, the native code would have run slowly too. Remember
we are talking SIXTY times slower on .Net than natively.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Bart C said:

<snip>

Perhaps you were not motivated enough

It is certainly true that we were not highly motivated to "fix" a working
program.

and were relieved at the results.

Well, no - having spent time on the port, we were *annoyed*[1] at the
results, not least because it meant we'd have to spend time arguing with
the Powers That Be. If everything had gone sweet as a nut, that would have
suited us fine.

[1] Actually, our first reaction was "it's crashed", and we spent some time
looking for a cause. It took some time for us even to consider the
possibility that it might be a performance issue, because no program takes
*that* long...

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Arne Vajhøj wrote:

jim wrote:

.... snip ...

>
Unless your app specifically targets users with old Windows
version and/or slow dialup internet connections, then I can not
see a problem going with .NET !

How about the fact that it won't run on real operating systems?

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Romeo Props MICHALE the A$$]

CBFalconer wrote:

Arne Vajhøj wrote:

>jim wrote:

... snip ...

>Unless your app specifically targets users with old Windows
version and/or slow dialup internet connections, then I can not
see a problem going with .NET !

How about the fact that it won't run on real operating systems?

You can crawl back under a real rock you POS.

[=?Utf-8?B?RGVubmlz?=]

Just noted your comment about industrial use of Windows. I'm just curious
what you consider industrial? I work for the world's largest public company
(maybe you've heard of ExxonMobil) and guess what system they use...you
guessed it "Windows"!
--
Dennis in Houston
"Richard Heathfield" wrote:

[followups set to comp.programming, where I'm reading this thread]

Terry Olsen said:

<snip>

The only objection to the .NET framework I've heard is from people who
say they don't want some big runtime library installed on their pc's.

Another objection is that it's slow. The first program I moved to .Net ran
around 60 times slower than native - way too slow to be useful.

A third objection is that it's non-portable. Even if I were of a mind to
run .Net programs under Linux, I couldn't actually do so - at least, not
yet. Mono promises to sort that out... oonnee ddaayy...... but in the
meantime Linux users would rather have something that actually works.

<snip>

I use VB not because i'm stupid, but because I'm lazy.

Being even lazier than you, I use C++ Builder for those rare occasions when
I need to write a Windows program. Because I'm so lazy, though, I prefer
to use Linux, where almost everything is so much easier to do. (In the
interests of balance and fairness, I will of course concede that there are
some things that it's easier to do in Windows. But industrial-strength
programming isn't one of them.)

I like that I can
whip out a windows form in a few seconds and use the various built-in
functions and classes to do the work that I want done. I've been known to
get a quick app done in 15 minutes when someone says "I need a utility to
do this...".

What took you? My personal record for responding to such a request is 30
seconds (including compilation) for the first version, and another 60
seconds when the user suddenly decided to require some extra features.
Builder rocks like that. I recommend it to you - and it doesn't need that
silly .Net framework either.

Using a non-ide language like gcc or other command-line
compilers doesn't make any sense to me. It's a time waster.

I don't like wasting my time, which is why I use the best tool for the job.
Sometimes, that's an IDE tool like C++ Builder. But sometimes it's a
command-line tool. If you think command line compilers are a waste of
time, that suggests that you haven't much experience of life outside the
world of pointy-clicky.

<snip>

So it's up to you. Use whatever you're comfortable with and don't listen
to people who have pre-conceived ideas about your language of choice.

There, at least, I can agree with you.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[=?UTF-8?B?QXJuZSBWYWpow7hq?=]

Dennis wrote:

Just noted your comment about industrial use of Windows. I'm just curious
what you consider industrial? I work for the world's largest public company
(maybe you've heard of ExxonMobil) and guess what system they use...you
guessed it "Windows"!

I know nothing about Exxon, but I serious doubt that they only use
Windows.

A company of that size typical use Windows on the desktop and
windows + 2-3 flavours of *nix + 1-2 other OS's on servers
scattered over 6 continents.

Arne

[=?UTF-8?B?QXJuZSBWYWpow7hq?=]

Dennis wrote:

Why are you even monitoring this newsgroup if you are so "anti .net"?

If you have read the thread carefully, then you would have
seen that the original poster for some reason included
comp.programming in the distribution, so it indeed went
out to non-.NET and non-Windows programmers.

Arne

[Andre Kaufmann]

Richard Heathfield wrote:

Andre Kaufmann said:

>This is
rather a problem for unexperienced C++ programmers placing large objects
on the stack.

No. If that were true, the native code would have run slowly too.

Remember

we are talking SIXTY times slower on .Net than natively.

Sorry if you got me wrong.

I meant it generally not related to you. It's easier even for
experienced C++ developers to write slow recursive functions than .NET.
Shouldn't mean that your C/C++ application was slow too or that your
team was unexperienced - regarding C++.

[...]

>Recursive code doesn't IMHO cause a performance problem in .NET.

Well, if that wasn't it, it was something else. Certainly the performance
problem existed.

Well I simply state you hadn't a performance problem, just used the
tools wrong.

You haven't mentioned how you have converted your C/C++ code to .NET.
Normally that isn't quite simple and even if most of the code
recompiles, commonly you have compiled a mixed application consisting
out of managed + native code, which shouldn't be slower.
But perhaps you / you're team has done common mistakes of developers
used to C++ Builder are commonly doing, when using MS VStudio for the
first time:
1) Visual Studio .NET C++ compiler is generally .NET code.

No - it's still a native compiler and special options have to be set
to generate true "IL" code (PURE / SAFE) mode

2) Debug / Release Version

Commonly Debug versions compiled in Visual Studio are slower.
Depending on the settings and application this may be up to
100 times slower.

By Default Visual Studio generates a Debug and a Release
configuration, but enables Debug by default.
So if you don't write *how* you have converted your code to .NET, I
simply state you haven't had a performance problem related to .NET but
just another performance problem, unrelated to .NET. ;-)

<snip>

Take for example iostreams in C++, I can write easily applications in
C++ that are 60 times slower than their C# counterparts. Does that mean
that C++ is generally slower ?
Short example, which illustrates potential performance problems,
regarding strings, which are always Unicode strings !:

a) C++: (string buffer not reserved - bad performance)

std::string s;
for (size_t i = 0; i < 0x2000; ++i)
{
s+= "text";
}

######
###### < 1 ms.
######
b) C++/CLI - .NET:

System::String^ s = "";

for (size_t i = 0; i < max; ++i)
{
s+= "text";
}

######
###### 2000 ms.
######
c) C++/CLI .NET - Optimized

System::Text::StringBuilder^ s = gcnew System::Text::StringBuilder();

for (size_t i = 0; i < max; ++i)
{
s->Append("text");
}
######
###### < 0 ms.
######
Andre

[Richard Heathfield]

Andre Kaufmann said:

<snip>

Well I simply state you hadn't a performance problem, just used the
tools wrong.

<shrugI know the performance problem existed, and I know it went away
when we stopped using .Net - make of it what you will.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Miha Markic]

<shrugI know the performance problem existed, and I know it went away

when we stopped using .Net - make of it what you will.

Imagine a person used to drive a Zastava Yugo. He knows it to the bones.
Now, let's imagine that he tries a brand new Lamborghini Diablo and because
his lack of knowledge he can't even start it up.
Now, he doesn't bother to RTFM, nor he asks anybody how to start it up.

The conclusion? Diablo sucks while Yugo rules.
--
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/

[Miha Markic]

Another objection is that it's slow. The first program I moved to .Net ran
around 60 times slower than native - way too slow to be useful.

It is not that slow. It might be a bit slower or a bit faster, depending on
what you are doing.
But the magnitude of your problem clearly shows that you were doing
something wrong.

--
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/

[Richard Heathfield]

"Miha Markic" <miha at rthand comsaid:

>

>Another objection is that it's slow. The first program I moved to .Net
ran around 60 times slower than native - way too slow to be useful.

It is not that slow.

Denial? Interesting.

It might be a bit slower or a bit faster, depending
on what you are doing.

A bit, yes. :-)

But the magnitude of your problem clearly shows that you were doing
something wrong.

No, that's begging the question.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Jon Skeet [C# MVP]]

Richard Heathfield <rj*@see.sig.invalidwrote:

<snip>

The race is next week. What should the team do? Sing the praises of the
car, and say "this must be our fault for not knowing the car; let's forget
the race, and work 24/7 on getting the car up to walking speed in time for
the following race"? Or are they more likely to say "this looks like a
complete lemon - let's stick with a car that can compete"?

I don't think anyone's really criticising your decision to go with
native C++ instead of .NET - it's the fact that you've taken your first
experience of .NET (which sounds half-hearted - you got the result you
wanted, i.e. the decision to stick with C++, and didn't put significant
effort into understanding why the .NET version was slow) and
extrapolated from there to your original claim that "it's slow".

I suspect that if I wrote C++ trying to use .NET idioms, that could be
slow as well - but I wouldn't make the assumption that that was the
fault of C++.

It's worth accepting that different platforms have different idioms,
and that you shouldn't expect your first experiences in a "new"
platform to compare well with experiences in a platform on which you
have a lot of experience.

Now, if you'd hired a .NET developer (not necessarily an expert - just
someone who was genuinely familiar with the platform), profiled the
app, *tried* to make it perform well, and still failed - *that* would
have been good evidence that .NET was slow for your particular
situation. (It still wouldn't have been good *general* evidence of
course.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[Richard Heathfield]

Jon Skeet [C# MVP] said:

<snip>

I don't think anyone's really criticising your decision to go with
native C++ instead of .NET - it's the fact that you've taken your first
experience of .NET (which sounds half-hearted - you got the result you
wanted, i.e. the decision to stick with C++,

Well, to be honest, I wanted C, but my colleague reasoned that C++ is
pretty much like C except that it has more toys, and it would be easier
for me to ignore toys I don't want than for her to do without toys she's
used to. She had a point, of course, so we went C++ instead of C.

and didn't put significant
effort into understanding why the .NET version was slow) and
extrapolated from there to your original claim that "it's slow".

Life's too short to spend it doing exhaustive analysis of every single
technology that comes along. Nevertheless, we spent several weeks on the
..Net thing, if memory serves me right. And we did use it to write a test
harness, which we ended up using even though we didn't like it very much.

I suspect that if I wrote C++ trying to use .NET idioms, that could be
slow as well - but I wouldn't make the assumption that that was the
fault of C++.

Yes, it's a fair point. Nevertheless, it does seem that .Net struggles with
recursive algorithms, which makes it kinda pointless for language
processing applications.

<snip>

Now, if you'd hired a .NET developer (not necessarily an expert - just
someone who was genuinely familiar with the platform), profiled the
app, *tried* to make it perform well, and still failed - *that* would
have been good evidence that .NET was slow for your particular
situation. (It still wouldn't have been good *general* evidence of
course.)

It would have been a neat trick, actually, since the ink on the box was
still wet - the only .Net people in the UK at the time were either beta
testers or liars. :-)

But we did give it the best shot we could without compromising the
deadline.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Miha Markic]

Nevertheless, it does seem that .Net struggles with

recursive algorithms, which makes it kinda pointless for language
processing applications.

It does seem to you....

--
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/

[=?ISO-8859-1?Q?Lasse_V=E5gs=E6ther_Karlsen?=]

Richard Heathfield wrote:

Jon Skeet [C# MVP] said:

<snip>

>I don't think anyone's really criticising your decision to go with
native C++ instead of .NET - it's the fact that you've taken your first
experience of .NET (which sounds half-hearted - you got the result you
wanted, i.e. the decision to stick with C++,

Well, to be honest, I wanted C, but my colleague reasoned that C++ is
pretty much like C except that it has more toys, and it would be easier
for me to ignore toys I don't want than for her to do without toys she's
used to. She had a point, of course, so we went C++ instead of C.

>and didn't put significant
effort into understanding why the .NET version was slow) and
extrapolated from there to your original claim that "it's slow".

Life's too short to spend it doing exhaustive analysis of every single
technology that comes along. Nevertheless, we spent several weeks on the
.Net thing, if memory serves me right. And we did use it to write a test
harness, which we ended up using even though we didn't like it very much.

>I suspect that if I wrote C++ trying to use .NET idioms, that could be
slow as well - but I wouldn't make the assumption that that was the
fault of C++.

Yes, it's a fair point. Nevertheless, it does seem that .Net struggles with
recursive algorithms, which makes it kinda pointless for language
processing applications.

Did you profile the .NET solution and verified that it was indeed
recursion that ate up time? So far all we know is that it relied heavily
on string parsing and recursion, but without profiling evidence I
wouldn't assume anything about why it ran slow.

I have a fairly extensive recursive solution implemented in a system
that processes gigabytes of log-files each day and recursion was nowhere
near a bottleneck in that solution. I/O and memory usage (GC) was the
top two time-spenders in that solution.

>
<snip>

>Now, if you'd hired a .NET developer (not necessarily an expert - just
someone who was genuinely familiar with the platform), profiled the
app, *tried* to make it perform well, and still failed - *that* would
have been good evidence that .NET was slow for your particular
situation. (It still wouldn't have been good *general* evidence of
course.)

It would have been a neat trick, actually, since the ink on the box was
still wet - the only .Net people in the UK at the time were either beta
testers or liars. :-)

Considering I'm still learning new ways to eek more performance out of
..NET every week I'll venture a guess that your solution wasn't optimal
either. It might've been the best you could produce but I'll vaguer that
there is probably a better solution available.

Would it be able to eat up the 1/60th speed degradation? Probably not,
but who knows.

All I'm saying that regardless of your particular solution, .NET isn't
slow in all respects.

Pick the best tool for the job. Sounds like you did. Case closed.

--
Lasse Vågsæther Karlsen
mailto:la***@vkarlsen.no
http://presentationmode.blogspot.com/

[Miha Markic]

To avoid countless further posts, would you be so kind to create a sample
that shows ~60x (or whatever the factor is) slower code execution?

--
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/

[Richard Heathfield]

Lasse Vågsæther Karlsen said:

<snip>

Did you profile the .NET solution and verified that it was indeed
recursion that ate up time?

As I said upthread, as far as I can recall we did not succeed at the time
in working out why the .Net version was so slow.

<snip>

Considering I'm still learning new ways to eek more performance out of
.NET every week I'll venture a guess that your solution wasn't optimal

I can accept that.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Jon Skeet [C# MVP]]

Lasse Vågsæther Karlsen <la***@vkarlsen.nowrote:

<snip>

Pick the best tool for the job. Sounds like you did. Case closed.

I'd expand that slightly further:

Pick the best tool for the job and for the resources available. I
strongly suspect that if the resources available had been experienced
C# developers who didn't know native C++, the best tool for the same
job would be .NET.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[Richard Heathfield]

Jon Skeet [C# MVP] said:

<snip>

Do you think that .NET would be widely used at all if it were typically
60x slower than native code?

Yes, I'm afraid I do.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bart C]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:ua******************************@bt.com...

[on C++ appl being 60x slower in .Net]

Yes, it's a fair point. Nevertheless, it does seem that .Net struggles
with
recursive algorithms, which makes it kinda pointless for language
processing applications.

Perhaps you can post the shortest piece of code that shows the problem. Then
some of us (not me) might help finding the reasons.

Bart

[Cor Ligthert[MVP]]

Jon,

Do you believe in the fable that native code is quicker than code build
around efficient routines?
Native code is because of the nature which leads to often inneficient use
normally slower, which start at the loading time because the size of a
native program in memory is forever huger then with efficient routines
(what a runtime in fact is).

Beside that there is since 1965 probably not anymore one real for general
purpose written application in total native code which works without any OS
around it. (The OS's were in the beginning in fact nothing more then a kind
of runtime).

Cor

[Richard Heathfield]

Bart C said:

<snip>

Perhaps you can post the shortest piece of code that shows the problem.

That's a perfectly sensible request, but alas, the answer is no, I can't do
that. This is because the incident in question occurred (several years
ago) on a client site - NDA applies, so I wouldn't be able to show the
code to you even if I had a copy (which I don't). And since I never use
..Net any more if I can possibly avoid it, I simply don't care enough to
construct an example. Sorry.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Jon Skeet [C# MVP]]

Cor Ligthert[MVP] <no************@planet.nlwrote:

Do you believe in the fable that native code is quicker than code build
around efficient routines?

I'm not at all sure what you mean.

In some cases I believe that idiomatic native code will be faster than
..NET. In some cases it will be slower. In most cases my experience
suggests it will be "about the same".

Native code is because of the nature which leads to often inneficient use
normally slower, which start at the loading time because the size of a
native program in memory is forever huger then with efficient routines
(what a runtime in fact is).

Um, no. Loading a runtime takes time - this is easy to see when you
first run even a small .NET program after boot. A comparable native
program is likely to load and start up much quicker. After the
framework is in the disk cache, the startup time of .NET improves a lot
though.

Beside that there is since 1965 probably not anymore one real for general
purpose written application in total native code which works without any OS
around it. (The OS's were in the beginning in fact nothing more then a kind
of runtime).

"Native code" in this context is "source code which is compiled
directly to machine code". That doesn't prevent it from using standard
libraries.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk