If not .Net then what?

If not .Net then what?

am 28.12.2007 14:09:16 von 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

Re: If not .Net then what?

am 28.12.2007 14:45:35 von Arne

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

I think you should stick to C# (or VB.NET if you so prefer). Just
consider not targeting the latest and greatest .NET version.

Since Win2003 Windows does come with .NET preinstalled and it
is pushed out to Windows XP via Windows Update.

I believe you can even distribute the runtime with your app.

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 !

Arne

Re: If not .Net then what?

am 28.12.2007 14:46:32 von Terry Olsen

The .NET framework should be installed on every Windows XP machine that is
kept updated. That means you don't have to create an installer package. You
can distribute the executable alone and it should work fine. Vista machines
have the .NET framework pre-installed.

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. But what
do they think Windows itself is? It's a big runtime library that every
windows application ever written requires to run. The .NET framework is just
a few extra DLL's in the System32 directory.

I use primarily use VB for all my development. Every now & then some dummy
will email me and with "why don't you write a version of this program that
doesn't require the .NET framework?" And I'll respond with "why don't you
write it yourself?"

I use VB not because i'm stupid, but because I'm lazy. 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...". Using a non-ide language like gcc or other command-line compilers
doesn't make any sense to me. It's a time waster.

If I need to make a program that works without the .NET framework (one
that'll run on a BartPE bootable CD, for example) then I use BCX. But to
design the form, I use VB6 to create the .frm file, and use a program I
wrote to convert the .frm file into the BCX code needed to create the form
at runtime.

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.

"jim" wrote in message
news:Oz6dj.31741$Mu4.12235@bignews7.bellsouth.net...
> 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
>

Re: If not .Net then what?

am 28.12.2007 15:09:09 von notmyfirstname

Jim,

Honestly the application that you want to develop is from the previous
millennium from the time that Dos was reigning.

Now user's wants (while they tell that they do not), all kind of advanced
behaviour. That needs a lot of extra software for which the Net framework
is, it seems to me, the best solution today. You alone cannot create all the
classes which help us to make software today. The runtime of that software
(however not only that runtime, there is much more) is now in the Net
assemblies.

Another advance from Net related software is that it is easy to deploy
because the real application can be relative small because most people have
already the .Net versions and a Windows OS on their computer. The advance
from the Net versions is that it is undependable from the Windows OS that is
running. However not small as not any OS part is (and every runtime for
windows is).

Be aware that there never were really small applications that could run on
windows OS systems. An average VB6 was by instance much huger to deploy and
absolute not deployable with dialup connections. In past every (non
assembler type) program language had its own runtime even when big parts
were included in the OS (like in mainframes)

If you don't know why runtimes are build: First they appeared to overcome
every time repeated simple instructions as adding, which can be, without a
runtime, need real a lot of instructions, while in fact it is endless times
done in a program. This can be used of course for everything and is every
time done more.

I hope that this explains something to you.

Cor

Re: If not .Net then what?

am 28.12.2007 15:11:26 von Richard Heathfield

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

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.

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.



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



> 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
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 28.12.2007 15:13:12 von Michael Rubinstein

Hi Jim,
> 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.
that kind of opinion is often offered by people jealously guarding their
'corporate' pond and perks it offers. No matter what environment you are
developing for what matters is the quality and usefulness of your program.
It is much easier to conceal lousy workmanship in a corporate environment
where expressing an honest opinion may cost dearly.

> 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.
Just don't it expect to think for you.

> 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.
I never used Thininstall. Xenocode allows wrapping the whole application -
executables, Dlls, ActiveX, databases, INI or XML, plus, when necessary,
the whole .NET Framework, into a single executable. This executable can also
wrap registry entries. You can simply copy such an executable onto the hard
drive of the target machine without the traditional setup. This is
especially handy when the application includes an ActiveX that normally
would require registration on the target machine. I word of caution - if you
do it as hobby, it may cost you some money, besides the time and effort.

Michael

"jim" wrote in message
news:Oz6dj.31741$Mu4.12235@bignews7.bellsouth.net...
> 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
>

Re: If not .Net then what?

am 28.12.2007 15:24:48 von Michael Moreno

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

Delphi 7 (newer versions are not as stable) does that very well.

--
Michael
----
http://michael.moreno.free.fr/
http://port.cogolin.free.fr/

Re: If not .Net then what?

am 28.12.2007 15:32:46 von kareem114

Hi Jim,

>for the purpose of creating standalone, single executable apps

No application is standalone, every application has at least
an reference to the kernel dll and maybe to advapi, gdi, netapi
or user api. The only standalone application you can say is a real
standalone application would be a BIOS Code, Bootloader,
oskernel and code working in that space,...

..NET Framework is just fine, some additional dlls and a little
pe modification for such a great framework is more than acceptable!

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

Re: If not .Net then what?

am 28.12.2007 15:33:57 von unknown

Hi,


You can always use C++ and write unmanaged apps, if you only use win32 API
you know for sure that it will run always.




"jim" wrote in message
news:Oz6dj.31741$Mu4.12235@bignews7.bellsouth.net...
> 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
>


--
Ignacio Machin
http://www.laceupsolutions.com
Mobile & warehouse Solutions.

Re: If not .Net then what?

am 28.12.2007 15:35:05 von Jim

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.

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



"Michael Moreno" wrote in message
news:mn.e3607d7cfcf7bece.21643@free.fr...
>> 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.
>
> Delphi 7 (newer versions are not as stable) does that very well.
>
> --
> Michael
> ----
> http://michael.moreno.free.fr/
> http://port.cogolin.free.fr/
>
>

Re: If not .Net then what?

am 28.12.2007 15:45:55 von Richard Heathfield

[F-Us set to c.p]

Kerem Gümrükcü said:

> Hi Jim,
>
>>for the purpose of creating standalone, single executable apps
>
> No application is standalone, every application has at least
> an reference to the kernel dll and maybe to advapi, gdi, netapi
> or user api.

Bear in mind that this thread is cross-posted. What you say may well be
true in Windows, but it is not true of all computer systems, and
especially embedded systems, which might be the *only* software running.

> The only standalone application you can say is a real
> standalone application would be a BIOS Code, Bootloader,
> oskernel and code working in that space,...

It depends how pickily you're using the term "standalone". People nowadays
have a fairly loose definition of "standalone", as in "all I have to ship
is the .exe" - and under that definition, there's lots of scope for
standalone applications, even under Windows, let alone under Linux,
MS-DOS, and the Mac.

> .NET Framework is just fine, some additional dlls and a little
> pe modification for such a great framework is more than acceptable!

Ah, but here we must agree to differ. :-)

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 28.12.2007 15:47:29 von kareem114

Hi Ignacio,

>You can always use C++ and write unmanaged apps, if you only use win32 API
>you know for sure that it will run always.

as long as you use apis that are downward compatible and do not
depends on sh*** like mfc (anf if soyou need the rigth runtime) and
you target the right cpu (32/64), then you can run your code on any
windows,...if you target windows,..

But if you need indipendend runtimes then go write generic x86 asm and
store it in libs ond objectcode that you can compile into single exe image.
But i see only need for this if you need fast algo's and dont want to depend
on any runtime (c-runtime, mfc, msvb, et al,....)

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

Re: If not .Net then what?

am 28.12.2007 16:07:02 von FamilyTreeMike

> Bear in mind that this thread is cross-posted. What you say may well be
> true in Windows, but it is not true of all computer systems, and
> especially embedded systems, which might be the *only* software running.
>

The original post stated Windows XP or higher. The original post apparently
was written differently on the non-dotNet groups.

Re: If not .Net then what?

am 28.12.2007 16:28:06 von Kevin.S.Gallagher

Jim,

On top of what has been said already you have very little to lose trying
..NET since the Express edition is free. There should be no concerning about
large required run times since they are most likely there already and if not
99% of users without the framework can install it quickly and easily.

To be honest (coming from a former long time Delphi developer) at this
moment in time .NET is an excellent, or should I say the best way to write
desktop applications. For someone just beginning you should have only a
short learning curve. As task become more complex you need look no farther
then these newsgroups for resources to questions which come either in the
form of expert responses or pointers to web sites which hold the key to your
issue at hand.

VB.NET or C#, that has already been hashed out high level. I like C# but my
agency settled on VB. Either one will get the common task done.

"jim" wrote in message
news:Oz6dj.31741$Mu4.12235@bignews7.bellsouth.net...
> 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
>

Re: If not .Net then what?

am 28.12.2007 16:42:39 von Arne

Ignacio Machin ( .NET/ C# MVP ) wrote:
> You can always use C++ and write unmanaged apps, if you only use win32 API
> you know for sure that it will run always.

Only if you do not use features only available in newer windows
versions.

But admitteded the Win32 API is rather mature in not much
is added these days.

Arne

@ Richard - Re: If not .Net then what?

am 28.12.2007 16:48:08 von kareem114

Hi Richard,

>Bear in mind that this thread is cross-posted. What you say may well be
>true in Windows, but it is not true of all computer systems, and
>especially embedded systems, which might be the *only* software running.

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

>It depends how pickily you're using the term "standalone".

Oh yes, it really depends and the the transition from monolithic to
modular or in our case from standalone 2 library dependency is
also very vague,...

>People nowadays
>have a fairly loose definition of "standalone", as in "all I have to ship
>is the .exe" - and under that definition, there's lots of scope for
>standalone applications, even under Windows, let alone under Linux,
>MS-DOS, and the Mac.

I asume you are a experienced developer so the term "standalone" is
truly very "loose". I think if we start a discussion here what can be
told standalone or modular could end up in a book of software
architecture. I have really a lot of experinence in writing code for
a bunch of OS's and architectures from (not kidding) binary over asm
till completely OOP even functional PL, and i know that something
can be for some developer a closed library but for the other a complete
stackable, modular, reusable component, e.g. when you thing about
functions, exports, code segements, just the COFF&PE Format is
just a piece of reusable (binary) data structure/code when it comes
to e.g. hooking binaries just to give an example,...

> .NET Framework is just fine, some additional dlls and a little
> pe modification for such a great framework is more than acceptable!

>Ah, but here we must agree to differ. :-)

Suum Cuique ;-)

Each to his own dude,...

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

Re: If not .Net then what?

am 28.12.2007 16:48:54 von kareem114

Hi Arne,

read my post above,...;-)

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

Re: If not .Net then what?

am 28.12.2007 16:49:37 von Scott Roberts

"jim" wrote in message
news:eQ7dj.31776$Mu4.4081@bignews7.bellsouth.net...
> 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.
>
> 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. 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.

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

Re: If not .Net then what?

am 28.12.2007 16:53:00 von Arne

Richard Heathfield wrote:
>[followups set to comp.programming, where I'm reading this thread]

Changed back to include the groups more relevant for the question.

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

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

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

Arne

Re: If not .Net then what?

am 28.12.2007 16:57:20 von Arne

Richard Heathfield wrote:
> [F-Us set to c.p]

Set back again.

> Kerem Gümrükcü said:
>>> for the purpose of creating standalone, single executable apps
>> No application is standalone, every application has at least
>> an reference to the kernel dll and maybe to advapi, gdi, netapi
>> or user api.
>
> Bear in mind that this thread is cross-posted. What you say may well be
> true in Windows, but it is not true of all computer systems, and
> especially embedded systems, which might be the *only* software running.

The original post said:

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

So the assumption about Windows is fine.

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

Arne

Re: If not .Net then what?

am 28.12.2007 16:59:49 von Arne

Kerem Gümrükcü wrote:
> 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

Re: @ Richard - Re: If not .Net then what?

am 28.12.2007 17:04:33 von Scott Roberts

"Kerem Gümrükcü" wrote in message
news:%23c9VakWSIHA.4272@TK2MSFTNGP06.phx.gbl...
> Hi Richard,
>
>>Bear in mind that this thread is cross-posted. What you say may well be
>>true in Windows, but it is not true of all computer systems, and
>>especially embedded systems, which might be the *only* software running.
>
> 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).

Re: If not .Net then what?

am 28.12.2007 17:10:48 von Jim

"Scott Roberts" wrote in
message news:%23XzX$kWSIHA.5164@TK2MSFTNGP03.phx.gbl...
>
> "jim" wrote in message
> news:eQ7dj.31776$Mu4.4081@bignews7.bellsouth.net...
>> 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.
>>
>> 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.

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

Re: If not .Net then what?

am 28.12.2007 17:12:50 von Richard Heathfield

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.

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.

>> 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 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 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
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 28.12.2007 17:13:28 von 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.

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 28.12.2007 17:24:06 von lasse

jim wrote:
> 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)

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

Re: If not .Net then what?

am 28.12.2007 17:25:49 von unknown

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/

"jim" wrote in message
news:Oz6dj.31741$Mu4.12235@bignews7.bellsouth.net...
> 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
>

Re: If not .Net then what?

am 28.12.2007 17:27:40 von Jeff Gaines

On 28/12/2007 in message jim
wrote:

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

--
Jeff Gaines

Re: If not .Net then what?

am 28.12.2007 17:28:28 von 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".

Re: If not .Net then what?

am 28.12.2007 17:36:07 von lasse

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.
>
> 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
mailto:lasse@vkarlsen.no
http://presentationmode.blogspot.com/

Re: If not .Net then what?

am 28.12.2007 17:38:11 von lasse

Scott Roberts wrote:
> 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.

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

Re: If not .Net then what?

am 28.12.2007 17:49:39 von Jim

Thanks Miha!


"Miha Markic" wrote in message
news:OFCOs5WSIHA.5136@TK2MSFTNGP04.phx.gbl...
> 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/
>
> "jim" wrote in message
> news:Oz6dj.31741$Mu4.12235@bignews7.bellsouth.net...
>> 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
>>
>

Re: If not .Net then what?

am 28.12.2007 18:02:05 von Scott Roberts

"Richard Heathfield" wrote in message
news:Ob6dnVPdnNdTgujanZ2dnUVZ8q2dnZ2d@bt.com...
> 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.

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.

Re: If not .Net then what?

am 28.12.2007 18:11:21 von Jim

"Scott Roberts" wrote in
message news:OJG3eNXSIHA.5264@TK2MSFTNGP02.phx.gbl...
>
> "Richard Heathfield" wrote in message
> news:Ob6dnVPdnNdTgujanZ2dnUVZ8q2dnZ2d@bt.com...
>> 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.
>
> 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.

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

Re: If not .Net then what?

am 28.12.2007 18:32:31 von Scott Roberts

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

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.

Re: If not .Net then what?

am 28.12.2007 18:42:36 von hirf-spam-me-here

"Arne Vajhøj" schrieb:
>> 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) ?

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

--
M S Herfried K. Wagner
M V P
V B

Re: If not .Net then what?

am 28.12.2007 18:42:38 von 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.

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 28.12.2007 18:47:21 von Jim

"Scott Roberts" wrote in
message news:%23daRfeXSIHA.1208@TK2MSFTNGP05.phx.gbl...
>
>>> .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.
>
> 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

Re: If not .Net then what?

am 28.12.2007 18:48:54 von 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.

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

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 28.12.2007 18:49:07 von Jim

Herfried!

Nice to see you around!

jim

"Herfried K. Wagner [MVP]" wrote in message
news:%23hywIkXSIHA.2376@TK2MSFTNGP02.phx.gbl...
> "Arne Vajhøj" schrieb:
>>> 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) ?
>
> I assume it should refer to the word variant which has an "e" as its last
> letter.
>
> --
> M S Herfried K. Wagner
> M V P
> V B

Re: If not .Net then what?

am 28.12.2007 19:19:44 von Peter Duniho

On Fri, 28 Dec 2007 08:38:11 -0800, Lasse Vågsæther Karlsen
wrote:

> Not to bring this entire discussion too far off-topic [...]

It's already off-topic, due to the fact that "jim@home.net" does not
appear to be able to restrain himself from excessive, inappropriate
cross-posting. This is the second time in a day that the
m.p.dotnet.languages.csharp newsgroup has been dragged into a lengthy
off-topic thread because of his posting habits.

I can't speak for comp.programming, but for sure the
m.p.dotnet.languages.* groups are not appropriate forums for comparative
discussions of various programming platforms. Those are for
language-specific programming questions, and nominally also general .NET
programming questions. _Maybe_ m.p.dotnet.general is appropriate, but
even there I'm skeptical.

Of course, it doesn't help that there are a number of people willing to
perpetuate the problem. So we get these long drawn-out threads that have
nothing to do with the newsgroup they're in.

It would be very nice if others could show more restraint than the OP has.

Pete

Re: If not .Net then what?

am 28.12.2007 19:25:51 von Scott Roberts

"jim" wrote in message
news:uEadj.31857$Mu4.3163@bignews7.bellsouth.net...
>
> "Scott Roberts" wrote in
> message news:%23daRfeXSIHA.1208@TK2MSFTNGP05.phx.gbl...
>>
>>>> .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.
>>
>> 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?

I can't answer your question because I've never used the "RAD" (i.e. drag &
drop data-binding) features of any IDE.

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

I said it wasn't suited for enterprise apps. It's fine for prototyping, but
you don't convert a prototype into a production app (by definition).

Also, it would be false for me to say I don't use *any* RAD features. I
obviously drag and drop controls onto forms and position them, set
properties related to appearance, etc. But since disk I/O has always been
the bottleneck for DB apps, I tend to roll my own data-binding so I know
*exactly* what is going on and why.

Re: If not .Net then what?

am 28.12.2007 19:31:52 von Scott Roberts

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

Re: If not .Net then what?

am 28.12.2007 19:46:40 von Chris Mullins

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

"jim" wrote in message
news:Oz6dj.31741$Mu4.12235@bignews7.bellsouth.net...
> 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
>

Re: If not .Net then what?

am 28.12.2007 20:03:02 von Jim

And, I wish you had answer.

Is this what you do....troll around for threads to call people trolls in?

If you have nothing to add to the discussion, then add nothing (i.e. don't
post).

jim

"Chris Mullins [MVP - C#]" wrote in message
news:%230yhbHYSIHA.5160@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
>
> "jim" wrote in message
> news:Oz6dj.31741$Mu4.12235@bignews7.bellsouth.net...
>> 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
>>
>
>

Re: If not .Net then what?

am 28.12.2007 20:25:52 von Spam Catcher

"Scott Roberts" wrote in
news:#XzX$kWSIHA.5164@TK2MSFTNGP03.phx.gbl:

> 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 thought Kylix didn't work too well? And Linux people prefer free
software?

--
spamhoneypot@rogers.com (Do not e-mail)

Re: If not .Net then what?

am 28.12.2007 20:28:13 von unknown

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#]" wrote in message
news:%230yhbHYSIHA.5160@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

Re: If not .Net then what?

am 28.12.2007 20:32:16 von 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

Re: If not .Net then what?

am 28.12.2007 20:32:45 von hirf-spam-me-here

"Scott Roberts" schrieb:
>> 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
V B

Re: If not .Net then what?

am 28.12.2007 20:35:39 von Arne

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

Re: If not .Net then what?

am 28.12.2007 20:38:23 von Arne

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

Re: If not .Net then what?

am 28.12.2007 20:50:02 von Jim

"Herfried K. Wagner [MVP]" wrote in message
news:u2R%23rhYSIHA.4272@TK2MSFTNGP06.phx.gbl...
> "Scott Roberts" schrieb:
>>> 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-bin/dnewsweb?cmd=listall&g roup=borland.public.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

Re: If not .Net then what?

am 28.12.2007 20:52:18 von Jim

"Arne Vajhøj" wrote in message
news:477550ae$0$90267$14726298@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

Re: If not .Net then what?

am 28.12.2007 20:52:54 von Jim

"jim" wrote in message
news:vrcdj.31909$Mu4.11052@bignews7.bellsouth.net...
>
> "Herfried K. Wagner [MVP]" wrote in message
> news:u2R%23rhYSIHA.4272@TK2MSFTNGP06.phx.gbl...
>> "Scott Roberts" schrieb:
>>>> 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-bin/dnewsweb?cmd=listall&g roup=borland.public.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

Re: If not .Net then what?

am 28.12.2007 20:57:06 von lasse

Richard Heathfield wrote:
> 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.
>
>>> 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?
>

I understand that you're focused entirely on the runtime speed of the
pure code, and in your situation that's fine, it's the only way to focus
because as you said in another post, your application reads data,
analyses it, and writes the result out again.

Your posts, however, goes along way to saying that .NET is slow,
generally. That's simply not true. It's slower than an alternate
solution in some parts, it's faster in others.

You also said you didn't rewrite it in .NET, you simply "tried it on
..NET". This leads me to believe you had C++ code that you just rebuilt
with managed extensions. Excusing me for pointing out that this hardly
constitutes as "writing a .NET application". That would be like me just
replacing a handful of keywords and classnames and voila, I got a java app.

Now, again, I'm going to assume you wrote the best .NET solution to your
problem so I'm assuming that the code you had would run at 1/60th of the
speed of your current solution.

This does not mean, generally, that all .NET code will run at that speed.

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

Re: If not .Net then what?

am 28.12.2007 21:07:47 von lasse

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:lasse@vkarlsen.no
http://presentationmode.blogspot.com/

Re: If not .Net then what?

am 28.12.2007 21:11:04 von kareem114

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

Re: If not .Net then what?

am 28.12.2007 21:13:39 von lasse

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:lasse@vkarlsen.no
http://presentationmode.blogspot.com/

Re: If not .Net then what?

am 28.12.2007 21:27:28 von hirf-spam-me-here

"Kerem Gümrükcü" schrieb:
>>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
V B

Re: If not .Net then what?

am 28.12.2007 21:27:31 von 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", , 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
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 28.12.2007 21:47:03 von Jim

"Lasse Vågsæther Karlsen" wrote in message
news:%23B6$T1YSIHA.3532@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

Re: If not .Net then what?

am 28.12.2007 21:53:35 von Scott Roberts

"Richard Heathfield" wrote in message
news:6ridnRGA467ixujanZ2dnUVZ8rOdnZ2d@bt.com...
> 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?

I'm curious why your boss even wanted to investigate .Net since the project
was already complete. Don't you generally choose a platform *before* you
begin such a project?

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

Yes it does. I learned something today too.

From http://msdn2.microsoft.com/en-us/library/ms998574.aspx

"Common Performance Issues
During your code reviews, pay particular attention to the following areas:

Frequent code paths. Prioritize your code review process by identifying code
paths that are frequently executed and begin your review process in these
areas.
Frequent loops. Even the slightest inefficiency inside a loop is magnified
many times over depending on the number of iterations. Specifically watch
out for repetitive property access inside your loops, using foreach instead
of for, performing expensive operations within your loops, and using
recursion. Recursion incurs the overhead of having to repeatedly build new
stack frames. "


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

Re: If not .Net then what?

am 28.12.2007 21:56:32 von lasse

jim wrote:
> "Lasse Vågsæther Karlsen" wrote in message
> news:%23B6$T1YSIHA.3532@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:lasse@vkarlsen.no
http://presentationmode.blogspot.com/

Re: If not .Net then what?

am 28.12.2007 22:22:48 von 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",
, 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

Re: If not .Net then what?

am 28.12.2007 22:24:37 von Jim

"Lasse Vågsæther Karlsen" wrote in message
news:uforjQZSIHA.2000@TK2MSFTNGP05.phx.gbl...
> jim wrote:
>> "Lasse Vågsæther Karlsen" wrote in message
>> news:%23B6$T1YSIHA.3532@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

Re: If not .Net then what?

am 28.12.2007 22:28:21 von Bart C

"Richard Heathfield" wrote in message
news:242dnVOad9NHqejaRVnytQA@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

Re: If not .Net then what?

am 28.12.2007 23:28:07 von Jim

"jim" wrote in message
news:dQddj.31954$Mu4.14910@bignews7.bellsouth.net...
>
> "Lasse Vågsæther Karlsen" wrote in message
> news:uforjQZSIHA.2000@TK2MSFTNGP05.phx.gbl...
>> jim wrote:
>>> "Lasse Vågsæther Karlsen" wrote in message
>>> news:%23B6$T1YSIHA.3532@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

Re: If not .Net then what?

am 28.12.2007 23:37:20 von Gerry

"Jeff Gaines" wrote in message
news:xn0ffhinofuvrq3002@msnews.microsoft.com...
> On 28/12/2007 in message jim
> wrote:
....

> VS is much too web-centric.

...

wow - now there is a very revealing statement !

Re: If not .Net then what?

am 28.12.2007 23:41:25 von 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)




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

Re: If not .Net then what?

am 28.12.2007 23:53:03 von Richard Heathfield

Scott Roberts said:



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



> 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
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 28.12.2007 23:59:05 von 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.



--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 29.12.2007 00:02:50 von Richard Heathfield

Bart C said:



> 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
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 29.12.2007 02:08:24 von ""YesHeIsPropsMICHALEAnA$$/"

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.

Re: If not .Net then what?

am 29.12.2007 02:32:00 von Dennis

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:
>
>
>
> > 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.
>
>
>
> > 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.
>
>
>
> > 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
> Email: -http://www. +rjh@
> Google users:
> "Usenet is a strange place" - dmr 29 July 1999
>

Re: If not .Net then what?

am 29.12.2007 02:36:01 von Dennis

Why are you even monitoring this newsgroup if you are so "anti .net"?
--
Dennis in Houston


"Richard Heathfield" wrote:

> 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.
>
> --
> Richard Heathfield
> Email: -http://www. +rjh@
> Google users:
> "Usenet is a strange place" - dmr 29 July 1999
>

Re: If not .Net then what?

am 29.12.2007 03:31:20 von Arne

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

Re: If not .Net then what?

am 29.12.2007 03:33:06 von Arne

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

Re: If not .Net then what?

am 29.12.2007 09:04:33 von 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. ;-)



>

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

Re: If not .Net then what?

am 29.12.2007 09:52:35 von Richard Heathfield

Andre Kaufmann said:



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

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

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 29.12.2007 10:04:25 von unknown

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

Re: If not .Net then what?

am 29.12.2007 10:07:08 von unknown

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

Re: If not .Net then what?

am 29.12.2007 10:31:06 von Richard Heathfield

"Miha Markic" said:

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

Now imagine an experienced racing team who can get a car around Silverstone
in around 86 seconds (the lap record is 84.475, so 86 is nothing
earth-shaking, but it's not exactly useless, either). They take delivery
of a brand-new car that supposedly works on a completely new principle.
The team has two drivers. The first one takes it out for a test, but about
a quarter of the way around the circuit she gets out and starts walking,
because she assumes it's stalled. It hasn't, but she's moving round the
track faster than the car. The second one is more patient, and completes a
single lap in just under an hour and a half - about the time it would
normally take to do the full sixty laps or so.

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"?

Yes, maybe the new car *can* be driven, by people who are very very
familiar indeed with it, at a sensible and even competitive pace. But for
people who need high performance in a hurry, it's a wombat.

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 29.12.2007 10:44:37 von unknown

> Yes, maybe the new car *can* be driven, by people who are very very
> familiar indeed with it, at a sensible and even competitive pace. But for
> people who need high performance in a hurry, it's a wombat.

..net is a complex tool and you are right, if you are in a hurry than you
should use whatever tool you are skilled in (this is a general rule, not
just .net one).
However, if you are planning mid-long term development then you might take a
better look at .net and start diggining into - you won't regret.
--
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/

Re: If not .Net then what?

am 29.12.2007 10:51:30 von Richard Heathfield

"Miha Markic" said:

>
>> 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
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 29.12.2007 11:49:06 von skeet

Richard Heathfield wrote:



> 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 -
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Re: If not .Net then what?

am 29.12.2007 12:24:04 von Richard Heathfield

Jon Skeet [C# MVP] said:



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



> 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
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 29.12.2007 12:40:26 von unknown

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

Re: If not .Net then what?

am 29.12.2007 12:42:51 von unknown

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/

Re: If not .Net then what?

am 29.12.2007 12:42:52 von lasse

Richard Heathfield wrote:
> Jon Skeet [C# MVP] said:
>
>
>
>> 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.

>
>
>
>> 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:lasse@vkarlsen.no
http://presentationmode.blogspot.com/

Re: If not .Net then what?

am 29.12.2007 13:08:27 von skeet

Richard Heathfield wrote:



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

I don't think .NET struggles with recursive algorithms. Tail-recursion
is only used in certain circumstances (depending on the JIT compiler
and source language, if I remember correctly) but that's unlikely to be
responsible for the majority of a 60x slowdown. It may have had *some*
performance impact, but not of the magnitude you saw.

I suspect it's far more likely that your code had some other bottleneck
(such as using string concatenation instead of a StringBuilder) which
was due to inexperience rather than anything inherently wrong with the
framework itself.

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

Well, it was in beta test for a pretty long time - people had
reasonable experience before it was fully released. I'd call myself a
reasonably experienced C# 3 developer, but C# 3 was only released last
month as part of .NET 3.5.

However, the significant point is that "lack of experienced
developers" certainly *was* a valid objection to using .NET - back
then. It isn't now, and it isn't a good reason to claim that .NET is
slow.

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

Fair enough - but it really doesn't sound like that "best shot" was
even slightly enough to give you sufficient evidence for your ".NET is
slow" claim.

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

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

Re: If not .Net then what?

am 29.12.2007 13:09:24 von Richard Heathfield

Lasse Vågsæther Karlsen said:



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



> 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
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 29.12.2007 13:09:58 von skeet

Lasse V=E5gs=E6ther Karlsen wrote:



> 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=20
strongly suspect that if the resources available had been experienced=20
C# developers who didn't know native C++, the best tool for the same=20
job would be .NET.

--=20
Jon Skeet -
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Re: If not .Net then what?

am 29.12.2007 13:17:29 von Richard Heathfield

Jon Skeet [C# MVP] said:



> 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
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 29.12.2007 13:38:24 von notmyfirstname

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

Re: If not .Net then what?

am 29.12.2007 13:38:53 von Bart C

"Richard Heathfield" wrote in message
news:uaSdnbmHc_M8sOvanZ2dnUVZ8tuqnZ2d@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

Re: If not .Net then what?

am 29.12.2007 13:53:31 von Richard Heathfield

Bart C said:



> 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
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 29.12.2007 13:58:35 von skeet

Cor Ligthert[MVP] wrote:
> 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 -
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Re: If not .Net then what?

am 29.12.2007 13:59:15 von skeet

Richard Heathfield wrote:
> > 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.

In that case it would probably be worth avoiding the assertion that
..NET is slow in future.

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

Re: If not .Net then what?

am 29.12.2007 14:10:10 von Richard Heathfield

Jon Skeet [C# MVP] said:

> Richard Heathfield wrote:



>> I simply don't care enough to construct an example. Sorry.
>
> In that case it would probably be worth avoiding the assertion that
> .NET is slow in future.

Yeah, fair enough - I'll revise it to "100% of the .Net projects I've been
involved with have run 60 times slower than their native equivalents". :-)

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 29.12.2007 14:11:48 von lasse

Richard Heathfield wrote:
> Jon Skeet [C# MVP] said:
>
>> Richard Heathfield wrote:
>
>
>
>>> I simply don't care enough to construct an example. Sorry.
>> In that case it would probably be worth avoiding the assertion that
>> .NET is slow in future.
>
> Yeah, fair enough - I'll revise it to "100% of the .Net projects I've been
> involved with have run 60 times slower than their native equivalents". :-)
>

Fair enough :)

Made me laugh :D

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

Re: If not .Net then what?

am 29.12.2007 14:29:06 von spinoza1111

On Dec 29, 4:27=A0am, Richard Heathfield wrote:
> 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 b=
y
> >> 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. =A0:-)
>
> 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

And, of course, to Learn YAMT.

> 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

Dijkstra was precise: much of what passes for knowledge in computing
circles is a sort of oral folklore, whisperings of dark secrets around
campfires in a demon-haunted world.

How would .Net not be good at recursion? My parser in the compiler for
Build Your Own .Net Language and Compiler worked at constant time
applying a rather deeply recursive top-down descent algorithm.

Net has to set up a safe and rational procedure call for recursion
the first time, and reuse it depending on the depth of recursion. The
folk-lore isn't confirmed that it isn't "good" at recursion.

Recursion was hard when routines supplied "work areas" to their
callees and compilers blew their tops trying to compile a recursive
call. The rumor that .Net's technologists messed it up, when the
academy has long known what you have to do (think stacks, Richard) is
a blood libel.

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

Whoa, a huge performance disparity emerges as it were from de jungle.
I'm no expert on relative performance disparities between .Net and
native. I do know, however, that historically, whenever a man wanted
to solve a problem with some sort of run-time language that had to be
interpreted in some way, your basic Computer Guys would mutter
aaaaargh burn me buttocks would ye slow things down, belike?

There is such a think as folkish wisdom. But there is also folly in
the folk.

With all due respect, this sounds to me belike one of those *ersatzen*
for due diligence, in which the actual coders are invited by
management to evaluate a new tech direction without being given any
slack on the deadlines, which they could use to sit back and do due
diligence.

I mean, did you write recursive code and run it on a .Net platform
side by side with a "native" platform?

It sounds to me that some guy passed along a rumor at some meeting.
One reason why programmers, and many other decent folk, abhor meetings
in tech venues where the main job is production. No time is given for
intellectual honesty, and Rumour, painted full of tongues, is the time-
saver of choice.

This is to me an economic tragedy as severe as that of the commons,
but nameless. The workers are asked to take control by management but
not given the time to do the work of self-management, and for this
reason, revert to folk-lore.
>
> --
> Richard Heathfield
> Email: -http://www. +rjh@
> Google users:
> "Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 29.12.2007 14:42:51 von Richard Heathfield

spinoza1111 said:



> My parser in the compiler for
> Build Your Own .Net Language and Compiler worked at constant time
> applying a rather deeply recursive top-down descent algorithm.

I am aware of your performance track record, as a result of which I find it
difficult to take seriously anything you say about performance. I am also
aware of your posting record, as a result of which I find it difficult to
take seriously anything you say on any subject whatsoever.

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 29.12.2007 15:52:24 von skeet

Richard Heathfield wrote:
> > In that case it would probably be worth avoiding the assertion that
> > .NET is slow in future.
>
> Yeah, fair enough - I'll revise it to "100% of the .Net projects I've been
> involved with have run 60 times slower than their native equivalents". :-)

And that's entirely reasonable, so long as you tack on:

"... but we didn't know how to optimise it, or profile it, or have any
experience in .NET"

Then everyone will understand how much weight to place on that
particular data point :)

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

Re: If not .Net then what?

am 29.12.2007 16:08:13 von Richard Heathfield

Jon Skeet [C# MVP] said:



> Then everyone will understand how much weight to place on that
> particular data point :)

My dear chap, if people truly understood how to weigh the data available to
them, we wouldn't let ourselves be ruled by crooks!

Er, sorry, typo. s/crooks/politicians/

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 29.12.2007 16:41:40 von Spam Catcher

Richard Heathfield wrote in
news:242dnVOad9NHqejaRVnytQA@bt.com:

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

Working code doesn't mean the optimal code for .NET. It's like running a a
foreign language document through BabelFish and expecting it to return a
flawless translated document - it just doesn't work that way. You probably
need to tweak, optimize your code for the .NET platform just as you did for
whatever language you originally wrote it for.

So you already had pre-conceived biases against .NET, so perhaps it's
better to you stick to whatever language/framework you were using
orignally... since that's what you want anyways.

--
spamhoneypot@rogers.com (Do not e-mail)

Re: If not .Net then what?

am 29.12.2007 16:47:33 von Spam Catcher

Richard Heathfield wrote in
news:ufKdnf2ncKub4ujanZ2dnUVZ8qqlnZ2d@bt.com:

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

For example, string concatenation without StringBuilder will grind .NET to
a halt. Could be something similar.

So 60x slower isn't something surprising ... especially if you do not have
..NET experience or understand how the framework works under the covers.

--
spamhoneypot@rogers.com (Do not e-mail)

Re: If not .Net then what?

am 29.12.2007 16:49:46 von Andre Kaufmann

Richard Heathfield wrote:
> Andre Kaufmann said:
>
>
>
>> Well I simply state you hadn't a performance problem, just used the
>> tools wrong.
>
> I know the performance problem existed, and I know it went away
> when we stopped using .Net - make of it what you will.
>

I'll continue to state it, since you don't write how you compiled your C
code for .NET -> how did you please ?
Otherwise I must assume you either aren't interested in an explanation
or try to troll around.

In one post you indirectly stated that you haven't converted your code
to .NET but recompiled it under Visual C++ .NET.
The latest Visual C++ .NET compiler doesn't compile by default C code to
..NET and a typical fault of CBuilder users is to compare debug builds
and I had long discussions why the C code (typically heap intensive one)
is so slow compiled under Visual C++ (in debug mode).

Andre

Re: If not .Net then what?

am 29.12.2007 16:52:10 von Spam Catcher

"Miha Markic" wrote in
news:OF4PC#fSIHA.1164@TK2MSFTNGP02.phx.gbl:

> .net is a complex tool and you are right, if you are in a hurry than
> you should use whatever tool you are skilled in (this is a general
> rule, not just .net one).
> However, if you are planning mid-long term development then you might
> take a better look at .net and start diggining into - you won't
> regret.

Nah, maybe the old fossil wants job security... and hence doesn't want to
introduce .NET into his workplace :-)

--
spamhoneypot@rogers.com (Do not e-mail)

Re: If not .Net then what?

am 29.12.2007 16:56:35 von Andre Kaufmann

Miha Markic wrote:
> 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?
>

He hasn't responded to the parts of my posts too, where I stated too he
has been doing something wrong, only by denying it.

I simply wanted to know how they have compiled C code to .NET but got no
answer yet, so I assume he is not interested in an explanation.

Andre

Re: If not .Net then what?

am 29.12.2007 16:57:43 von Jeff Gaines

On 29/12/2007 in message
Jon Skeet [C# MVP] wrote:

>In that case it would probably be worth avoiding the assertion that
>.NET is slow in future.

Why? .NET is slow, any VB6 or C app beats it hands down, there can't be
any programmers with a few years experience who aren't aware of that. If
it were possible to use the latest common controls in VB6 I'd go back to
it like a shot.

--
Jeff Gaines

Re: If not .Net then what?

am 29.12.2007 17:00:59 von Andre Kaufmann

Richard Heathfield wrote:
> Jon Skeet [C# MVP] said:
>
>> Richard Heathfield wrote:
>
>
>
>>> I simply don't care enough to construct an example. Sorry.
>> In that case it would probably be worth avoiding the assertion that
>> .NET is slow in future.
>
> Yeah, fair enough - I'll revise it to "100% of the .Net projects I've been
> involved with have run 60 times slower than their native equivalents". :-)

Since you don't write which compiler and settings you used and which
code basis (C - Code / C-Sharp etc.) I don't believe you've compiled
..NET code at all.

Andre

Re: If not .Net then what?

am 29.12.2007 17:12:23 von Richard Heathfield

Andre Kaufmann said:



> I simply wanted to know how they have compiled C code to .NET but got no
> answer yet,

C++, actually. Well, it was - what, four years ago? Something like that.
Lots of new technologies come along all the time. Pick one at random.
Spend two to three weeks using it. Abandon it, never to use it again. Then
answer random detailed questions on it four years later. Maybe you'll do
better than I did.

> so I assume he is not interested in an explanation.

Explain away if you want to. No, I'm not terribly interested, but I'm
interested enough to continue to follow the thread.

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 29.12.2007 17:15:09 von Richard Heathfield

Andre Kaufmann said:

> I don't believe you've compiled .NET code at all.

Then we have nothing further to discuss.

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 29.12.2007 17:23:58 von Registered User

On Sat, 29 Dec 2007 12:08:27 -0000, Jon Skeet [C# MVP]
wrote:

>Richard Heathfield wrote:
>
-snip-
>
>I don't think .NET struggles with recursive algorithms. Tail-recursion
>is only used in certain circumstances (depending on the JIT compiler
>and source language, if I remember correctly) but that's unlikely to be
>responsible for the majority of a 60x slowdown. It may have had *some*
>performance impact, but not of the magnitude you saw.
>
>I suspect it's far more likely that your code had some other bottleneck
>(such as using string concatenation instead of a StringBuilder) which
>was due to inexperience rather than anything inherently wrong with the
>framework itself.
>
One of the earlier posts by Mr. Heathfield mentioned the application
used sockets. If performance was an issue that is where I would look
first.
-snip-
>
>> But we did give it the best shot we could without compromising the
>> deadline.
>
A deadline is just an arbitrary date on the calendar chosen by someone
with a to-do list. Unfortunately marking the task as completed is
often more important than properly completing the task.

>Fair enough - but it really doesn't sound like that "best shot" was
>even slightly enough to give you sufficient evidence for your ".NET is
>slow" claim.
>
That seems to be what everyone is trying to point out. Anecdotal
evidence concerning a port of a port's performance is being given too
much value. The is especially true when the first port involved
hacking on socket code.

regards
A.G.

Re: If not .Net then what?

am 29.12.2007 17:49:26 von Andre Kaufmann

Richard Heathfield wrote:
> Andre Kaufmann said:
>
>
>
>> I simply wanted to know how they have compiled C code to .NET but got no
>> answer yet,
>
> C++, actually. Well, it was - what, four years ago? Something like that.

Thank you.

You have used the same C++ compiler (I assume Visual Studio) to compile
the *same* code to

a) native
b) pure or safe IL code


compared it and b) is 60 *times* slower ?


As I wrote it's a common pitfall for C-Builder users to:

1) Compile the debug version under VC only, which unfortunately
uses some slow debug settings by default, to catch heap
errors more quickly

2) Assume Visual Studio .NET C++ compiler is a .NET compiler by default
The name is unfortunately misleading

>

Andre

Re: If not .Net then what?

am 29.12.2007 17:59:01 von notmyfirstname

Jeff,

> Why? .NET is slow, any VB6 or C app beats it hands down, there can't be
> any programmers with a few years experience who aren't aware of that. If
> it were possible to use the latest common controls in VB6 I'd go back to
> it like a shot.

If that is really so, you should good follow the advices which by instance
Jon has given in this thread.

An average VB6 application should be much slower in overall throughput then
a .Net application (with the exception of applications using heavily late
binding in whatever way). A C application is not comparable because that can
even be software which is not real meant for Net like by instance drivers.

Cor

Re: If not .Net then what?

am 29.12.2007 18:03:32 von skeet

Jeff Gaines wrote:
> >In that case it would probably be worth avoiding the assertion that
> >.NET is slow in future.
>
> Why? .NET is slow, any VB6 or C app beats it hands down, there can't be
> any programmers with a few years experience who aren't aware of that. If
> it were possible to use the latest common controls in VB6 I'd go back to
> it like a shot.

If you can provide *evidence* of that, you'll be the first to do so in
this thread...

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

Re: If not .Net then what?

am 29.12.2007 18:12:49 von notmyfirstname

Miha,

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


It is very patriotic from you to tell that a Zastava is easier to handle
then a Lamborghini, however I have the idea that somebody coming from a
Lamborgini could have problems to drive with a Zastava too even if it was in
the same speed.

However starting a car should be with both no problems. I am not so fond
about cars from the communist era so I believe that the Lamborgini will
start much easier and be much reliable.

That should be the same with .Net developing software and the documentation
around it. And in my idea that is.

:-)

Cor

Re: If not .Net then what?

am 30.12.2007 00:19:59 von MrArnold

jim wrote:



I see the MS camp is in heated battle with King Little Richard
Heathfield of comp.programming. The king and his disciples as well as
most that frequent comp.programming are anti MS and hate MS with a passion.

But mainly it's that lunatic King Little Richard that sets the pace in
the NG and is at the helm, as everyone can see.

You should all kick him to the curb, because otherwise, I'll lip drivel
all of you about MS and .NET and until the cows come home.

I don't know why the OP posted to that disaster of NG called
comp.programming to arouse the lip babbling King Little Richard about .NET

Re: If not .Net then what?

am 30.12.2007 00:30:56 von MrArnold

jim wrote:




You should all kick him to the curb, because otherwise, King Little
Richard will lip drivel all of you about MS and .NET and until the cows
come home.

Re: If not .Net then what?

am 30.12.2007 01:52:13 von Stephen Howe

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

Well then, lets benchmark it:

Sieve of Erastophenes
Copying N files from one directory to another without using an API.
Reading the complete works of Shakespeare and then dumping to stdout each
word in alphabetical order plus a count

If you have to spend a couple of years on each task to get equivalent
performance, then .NET has lost.

Now if relatively simple tasks are all slow in .NET (or Java), dont care
which, compared to straight Win32 console apps in VB6, C, C++, Dephi,
Fortran, isnt it a matter of time before Microsoft declares .NET as legacy?
Garbage Collection from 1959 will work well for a limited class of problems.
But AFAIK, it is pretty poor as a universal panacea.

There was never anything wrong with straight Win32 or Win64 apps until MS
got bored.
Remind me also which MS apps are written in .NET?

Stephen Howe

Re: If not .Net then what?

am 30.12.2007 01:58:27 von Stephen Howe

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

If the code was, say, 250,000 lines of converted C++, then yes it could be
so.
There coudl be easily be something that is missed.

But suppose it was a 10-line program.
You check the obvious that you dont have debug switches switched on.
And it is still slow compared to an equivalent C or C++ Win32 program.
Then yes, I blame .NET

Stephen Howe

Re: If not .Net then what?

am 30.12.2007 02:12:15 von CBFalconer

"Jon Skeet [C# MVP]" wrote:
>
.... snip ...
>
> 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.)

I think you are all missing the fundamental point. C++ has a well
known, and generally adhered to, ISO standard. .NET is basically a
single supplier system. Richard and associates prefer not to be
limited to such a small user area. The fact that they could
immediately find bugs [1] is confirmation of their wisdom.

[1] I define a slow-down factor of 60 as a bug.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)




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

Re: If not .Net then what?

am 30.12.2007 03:36:38 von MrArnold

CBFalconer wrote:
>
> Richard and associates prefer not to be
> limited to such a small user area. The fact that they could
> immediately find bugs [1] is confirmation of their wisdom.
>
> [1] I define a slow-down factor of 60 as a bug.
>

Well, you heard it from Prince CBFalconer a disciple, a serious behind
kisser to King Little Richrad in King Little Richard's comp.programming
NG about King Little Richard, and how they will kiss his behind time and
time again.

The OP that crossed posted to sorry comp.programming made a serious
mistake in posting to this NG and to the people with such serious bias
opinions and behind kissing going on that happens in that NG.

Re: If not .Net then what?

am 30.12.2007 03:54:42 von obermd.

"Jeff Gaines" wrote in message
news:xn0ffiwdyh992sc001@msnews.microsoft.com...
> On 29/12/2007 in message
> Jon Skeet [C# MVP] wrote:
>
>>In that case it would probably be worth avoiding the assertion that
>>.NET is slow in future.
>
> Why? .NET is slow, any VB6 or C app beats it hands down, there can't be
> any programmers with a few years experience who aren't aware of that. If
> it were possible to use the latest common controls in VB6 I'd go back to
> it like a shot.
>
> --
> Jeff Gaines
>


My experience with memory intensive apps in VB 6 that I have actually
rewritten in VB 2005 is quite the opposite. The VB 2005 version is usually
around twice as fast simply because the NET GC is so much better. As for
comparing C++ to any NET language, you're comparing apples to oranges. C++
and C# design goals are not the same, despite the similarity in name.

I have to agree with some of the other responders that OP is actually trying
to prevent a switch to dotNET, and, even, possibly a switch to Windows (or
forcing a switch away from Windows).

Mike Ober.

Re: If not .Net then what?

am 30.12.2007 06:16:46 von Scott Roberts

"Jon Skeet [C# MVP]" wrote in message
news:MPG.21e06f84b2ceab34755@msnews.microsoft.com...
> Richard Heathfield wrote:
>> > In that case it would probably be worth avoiding the assertion that
>> > .NET is slow in future.
>>
>> Yeah, fair enough - I'll revise it to "100% of the .Net projects I've
>> been
>> involved with have run 60 times slower than their native equivalents".
>> :-)
>
> And that's entirely reasonable, so long as you tack on:
>
> "... but we didn't know how to optimise it, or profile it, or have any
> experience in .NET"
>
> Then everyone will understand how much weight to place on that
> particular data point :)

You forgot "and only spent 2 weeks on it, and that was 2 years ago, and I
haven't even looked at it since."

Re: If not .Net then what?

am 30.12.2007 07:31:09 von spinoza1111

On Dec 29, 9:42=A0pm, Richard Heathfield wrote:
> spinoza1111said:
>
>
>
> > My parser in the compiler for
> > Build Your Own .Net Language and Compiler worked at constant time
> > applying a rather deeply recursive top-down descent algorithm.
>
> I am aware of your performance track record, as a result of which I find i=
t

That's lie, pure and simple, although in corporatese. You know very
little about it. Its flaws, FYI, are mostly ideological, a failure to
sign-on with normalized deviance.

> difficult to take seriously anything you say about performance. I am also

I found it equally difficult to take you seriously on .Net performance
because you passed along a rumor to save time.

> aware of your posting record, as a result of which I find it difficult to
> take seriously anything you say on any subject whatsoever.

So don't respond with lies about what you do and do not know. You have
performance anxiety and are engaged in psychological transference. You
enabled a cyberbullying campaign here in 2003 and 2004 by creating
offline web pages and you fantasize, as best as I can determine, about
the power of a pet language.

You feed what you believe to be a troll while at the same time
admonishing your partner in crime, Randy Howard, not to do so; this
alone displays bad faith.

>
> --
> Richard Heathfield
> Email: -http://www. +rjh@
> Google users:
> "Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 30.12.2007 07:36:02 von spinoza1111

On Dec 29, 10:52=A0pm, Jon Skeet [C# MVP] wrote:
> Richard Heathfield wrote:
> > > In that case it would probably be worth avoiding the assertion that
> > > .NET is slow in future.
>
> > Yeah, fair enough - I'll revise it to "100% of the .Net projects I've be=
en
> > involved with have run 60 times slower than their native equivalents". :=
-)
>
> And that's entirely reasonable, so long as you tack on:
>
> "... but we didn't know how to optimise it, or profile it, or have any
> experience in .NET"
>
> Then everyone will understand how much weight to place on that
> particular data point :)

My point. When I started messing around in Java, I realized very
quickly owing to greater type strictness, Java was a different world,
and for this reason I didn't pop off about Java. I was certainly
willing to have Heathfield admonish me in 2003, in effect remind me
after a long vacation from using C, that "for loops evaluate for
conditions repeatedly" based on his expertise. But here, he enters
like Rumour in Henry IV part 2:

Open your ears; for which of you will stop
The vent of hearing when loud Rumour speaks?
I, from the orient to the drooping west,
Making the wind my post-horse, still unfold
The acts commenced on this ball of earth:
Upon my tongues continual slanders ride,
The which in every language I pronounce,
Stuffing the ears of men with false reports.
I speak of peace, while covert enmity
Under the smile of safety wounds the world:
And who but Rumour, who but only I,
Make fearful musters and prepared defence,
Whiles the big year, swoln with some other grief,
Is thought with child by the stern tyrant war,
And no such matter? Rumour is a pipe
Blown by surmises, jealousies, conjectures
And of so easy and so plain a stop
That the blunt monster with uncounted heads,
The still-discordant wavering multitude,
Can play upon it.

Re: If not .Net then what?

am 30.12.2007 07:39:53 von spinoza1111

On Dec 29, 11:08=A0pm, Richard Heathfield wrote:
> Jon Skeet [C# MVP] said:
>
>
>
> > Then everyone will understand how much weight to place on that
> > particular data point :)
>
> My dear chap, if people truly understood how to weigh the data available t=
o
> them, we wouldn't let ourselves be ruled by crooks!
>
> Er, sorry, typo. s/crooks/politicians/

Excellent foppery, my dear Richard. Jon is objecting to your entering,
"painted full of tongues", to speak with no authority and to say,
".Net doesn't 'do' recursion well". You divert us with references to
politicians which were elected by you and who in fact use data systems
constructed not to clarify truth, but to massage Rumours, with the
person most able to afford the best hardware and software winning the
race.

In the case of .Net you could have downloaded free software and tried
testing your code under .Net to have some numbers. But it appears that
you let loud Rumour speak.
>
> --
> Richard Heathfield
> Email: -http://www. +rjh@
> Google users:
> "Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 30.12.2007 07:47:31 von spinoza1111

On Dec 30, 1:03=A0am, Jon Skeet [C# MVP] wrote:
> Jeff Gaines wrote:
> > >In that case it would probably be worth avoiding the assertion that
> > >.NET is slow in future.
>
> > Why? .NET is slow, any VB6 or C app beats it hands down, there can't be

As Dijkstra pointed out, folklore replaces science. My dear fellow, it
is almost ungrammatical to say that ".Net is slow". It's as
incomprehensible as saying "computers are slow", or "the Boeing 747 is
slow", in that it is unrelativised to specific benchmarks and specific
needs.

A better case could be made for saying "computers today are too fast
and should slow down" because today they produce wrong answers
elegantly and fast, and today they enable people to spread rumours and
to cyberbully.

Net is an interpreted. threaded, layer varnish'd over raw computation
which is reified when unattached from human needs. By the computing
reifier .Net stands sore charged for "wasting time" DESPITE the fact
that sans .Net or Java, we'd long have succumbed to random code
executing anywhere.

> > any programmers with a few years experience who aren't aware of that. If=

> > it were possible to use the latest common controls in VB6 I'd go back to=

> > it like a shot.

What!? VB6 controls were a joke and spread incomprehension because of
the unnecessary form/control divergence and the horror of the property
bag. Today, I can create controls without a mouse on sea, land and air
(on the commuter ferry and in coach class) by writing C sharp code,
and this is a Good Thing.

VB1..VB6 were infantile disorders, Babes in Toyland.

>
> If you can provide *evidence* of that, you'll be the first to do so in
> this thread...
>
> --
> Jon Skeet - http://www.pobox.com/~skeet=A0 Blog:http://ww=
w.msmvps.com/jon.skeet
> World class .NET training in the UK:http://iterativetraining.co.uk

Re: If not .Net then what?

am 30.12.2007 07:50:32 von spinoza1111

On Dec 30, 9:12=A0am, CBFalconer wrote:
> "Jon Skeet [C# MVP]" wrote:
>
>
>
>
>
>
>
> ... snip ...
>
> > 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.)
>
> I think you are all missing the fundamental point. =A0C++ has a well
> known, and generally adhered to, ISO standard. =A0.NET is basically a
> single supplier system. =A0

Which conforms to ECMA standards.

> Richard and associates prefer not to be
> limited to such a small user area. =A0The fact that they could
> immediately find bugs [1] is confirmation of their wisdom.
>
> [1] I define a slow-down factor of 60 as a bug.

Gee, even in Console.Writeline("Hello world") versus printf("Hello
world\n");? I'll alert the media.
>
> --
> Merry Christmas, Happy Hanukah, Happy New Year
> =A0Joyeux Noel, Bonne Annee, Frohe Weihnachten
> Chuck F (cbfalconer at maineline dot net)
> =A0 =A0 =A0
>
> --
> Posted via a free Usenet account fromhttp://www.teranews.com- Hide quoted =
text -
>
> - Show quoted text -

Re: If not .Net then what?

am 30.12.2007 09:07:16 von Richard Heathfield

spinoza1111 said:

> On Dec 29, 9:42 pm, Richard Heathfield wrote:
>> spinoza1111said:
>>
>>
>>
>> > My parser in the compiler for
>> > Build Your Own .Net Language and Compiler worked at constant time
>> > applying a rather deeply recursive top-down descent algorithm.
>>
>> I am aware of your performance track record, as a result of which I find
>> it
>
> That's lie, pure and simple, although in corporatese.

No, it's not, as anyone can see from a quick Google Groups search for
articles posted in comp.programming containing both "nilges" (not
necessarily as author) and "strlen". I got 163 hits. Anyone bored enough
to wade through them all will quickly learn that you don't know spit about
performance, and that you lack the intellectual honesty to acknowledge and
learn from your errors.

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 30.12.2007 09:11:36 von notmyfirstname

VB1..VB6 were infantile disorders, Babes in Toyland.

But in very much ways a bleu print for C#.

C# is not only inheriting from C++, Java or C.

To follow your anology: C# has beauty as mother an a geek as father.

:-)

Cor

Re: If not .Net then what?

am 30.12.2007 09:19:30 von notmyfirstname

>
> C# is not only inheriting from C++, Java or C.
>
> To follow your anology: C# has beauty as mother an a geek as father.
>
The same for her brother VB for Net of course.

Cor

Re: If not .Net then what?

am 30.12.2007 09:24:55 von skeet

CBFalconer wrote:
> > 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.)
>
> I think you are all missing the fundamental point. C++ has a well
> known, and generally adhered to, ISO standard. .NET is basically a
> single supplier system. Richard and associates prefer not to be
> limited to such a small user area.

That much is fine. It's a perfectly valid objection. I should point out
that C# also has an ISO standard; I'm not sure whether the CLI which
has an ECMA standard also has an ISO standard - but either way, unless
you include things like Mono, it's still a single supplier system.

> The fact that they could
> immediately find bugs [1] is confirmation of their wisdom.
>
> [1] I define a slow-down factor of 60 as a bug.

That's crazy without knowing what their code was doing. There are
plenty of reasons why Richard might have seen a slow-down factor of 60
by performing a *naive* port without any bugs in .NET. You just can't
expect to apply all idioms from one platform to another. You need to
learn the idioms of the new platform.

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

Re: If not .Net then what?

am 30.12.2007 09:37:47 von skeet

<"Stephen Howe" > wrote:
> > 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.
>
> Well then, lets benchmark it:
>
> Sieve of Erastophenes
> Copying N files from one directory to another without using an API.

Any API at all, or just a file copying API? In other words, do you
allow APIs to open a file as a stream?

> Reading the complete works of Shakespeare and then dumping to stdout each
> word in alphabetical order plus a count
>
> If you have to spend a couple of years on each task to get equivalent
> performance, then .NET has lost.

I'd agree, so long as you allow, say, a 20% performance loss to still
count as "equivalent" - it's close enough that the development benefits
of .NET easily make up for it, in my view.

I'd also have one other performance stipulation: that the tasks not be
so fast as to make startup time dominate. In other words, make the
tasks sufficiently long (or run them repeatedly within one test) so
that the overall test takes at least a minute. After all, most
applications (particularly server side) *do* run for more than a
minute, and it's the long-term performance which matters more.

> Now if relatively simple tasks are all slow in .NET (or Java), dont care
> which, compared to straight Win32 console apps in VB6, C, C++, Dephi,
> Fortran, isnt it a matter of time before Microsoft declares .NET as legacy?

I'd agree. But there's an "if" which you appear to be assuming is
actually the case.

Now, would you care to actually do the benchmarks you've mentioned
above? They all sound simple enough that I can probably find the time

> Garbage Collection from 1959 will work well for a limited class of problems.
> But AFAIK, it is pretty poor as a universal panacea.

It's not meant to be a universal panacea - just better than manual
malloc/free. (I also rather suspect that it's moved on since 1959 - did
John McCarthy invent generational, concurrent garbage collection back
then?)

> There was never anything wrong with straight Win32 or Win64 apps until MS
> got bored.
> Remind me also which MS apps are written in .NET?

There are some (Windows Live Writer and SQL Server Management Studio
just to pick a couple of examples), and some coming up (the health care
system they're building, for exampe). Don't expect Office to be
rewritten in .NET any time soon though - a complete rewrite would be
daft.

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

Re: If not .Net then what?

am 30.12.2007 10:19:56 von Andre Kaufmann

Richard Heathfield wrote:
> Andre Kaufmann said:
>
>> I don't believe you've compiled .NET code at all.
>
> Then we have nothing further to discuss.

O.K., you stated you don't want to port your code to .NET in another
post and you said that your code runs 60 times slower under .NET ?

If I ask how you did it you simply ignore the questions. And if I try to
tickle you a bit to get it out, you seem to be offended.

You blame others knowing nothing of performance, but you can't tell us
why your code port (was it ?) has been that slow.

So the facts:

a) You have C++ code
b) Stated you compiled it somehow as .NET application
c) Stated that it runs 60 times slower
d) Have no single proof
e) Don't tell us how you did b)
f) Blaming others to be kind of dumb by using the words "clicky-pointy"
g) Can't prove it all


But yes, in one point you are correct:

> Then we have nothing further to discuss.

There isn't really nothing substantial to discuss.


Andre

Re: If not .Net then what?

am 30.12.2007 10:27:38 von Jeff Gaines

On 29/12/2007 in message
Jon Skeet [C# MVP] wrote:

>Jeff Gaines wrote:
>>>In that case it would probably be worth avoiding the assertion that
>>>.NET is slow in future.
>>
>>Why? .NET is slow, any VB6 or C app beats it hands down, there can't be
>>any programmers with a few years experience who aren't aware of that. If
>>it were possible to use the latest common controls in VB6 I'd go back to
>>it like a shot.
>
>If you can provide evidence of that, you'll be the first to do so in
>this thread...

What would be a good test? I am happy to try it (if only for my own
satisfaction) but don't want to spend hours putting something together.
Something like sorting a large string array and calculating factorials?

--
Jeff Gaines

Re: If not .Net then what?

am 30.12.2007 10:41:47 von unknown

> If the code was, say, 250,000 lines of converted C++, then yes it could be
> so.
> There coudl be easily be something that is missed.
>
> But suppose it was a 10-line program.
> You check the obvious that you dont have debug switches switched on.
> And it is still slow compared to an equivalent C or C++ Win32 program.
> Then yes, I blame .NET

I really wonder how could be a 10 lines program 60x slower. :-)

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

Re: If not .Net then what?

am 30.12.2007 12:42:44 von Bart C

"Stephen Howe" wrote in message
news:rNidna8kFOAgduvanZ2dnUVZ8uSdnZ2d@pipex.net...

> Well then, lets benchmark it:
>
> Sieve of Erastophenes

I tried this little recursive program in C#. And similar in straight C. The
C# took nearly twice as long but that was probably in debug mode. So
pleasantly surprised.

Unless I've missed the point about what .Net is, I'm assuming it's a bunch
of MS languages all producing the same IL and a huge runtime, plus some
over-the-top IDEs.

using System;
class program
{
static void Main(string[] args)
{
int n,f;
n=43;
f = fib(n);
Console.WriteLine("Fib({0})={1}", n,f);
Console.ReadLine();
}

static int fib(int n){
if(n>1)
return fib(n-2)+fib(n-1);
else
return 1;
}
}


Bart

Re: If not .Net then what?

am 30.12.2007 13:41:13 von skeet

Jeff Gaines wrote:



> >If you can provide evidence of that, you'll be the first to do so in
> >this thread...
>
> What would be a good test? I am happy to try it (if only for my own
> satisfaction) but don't want to spend hours putting something together.
> Something like sorting a large string array and calculating factorials?

Calculating factorials is fairly useless, and sorting tends to be done
by library calls rather than in your own code.

The suggestions by Stephen Howe are fairly reasonable though - although
I suspect they'll be IO limited rather than CPU limited. Mind you,
that's often likely to be the case in real code as well...

I'm happy to do the C# - it would be good to see VB6, C and C++
solutions. It would also be nice to look at the complexity/readability
of the solutions afterwards, as well as the performance...

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

Re: If not .Net then what?

am 30.12.2007 15:20:18 von Richard Heathfield

Andre Kaufmann said:

> Richard Heathfield wrote:
>> Andre Kaufmann said:
>>
>>> I don't believe you've compiled .NET code at all.
>>
>> Then we have nothing further to discuss.
>
> O.K., you stated you don't want to port your code to .NET in another
> post and you said that your code runs 60 times slower under .NET ?

Since you say you don't believe me, what is the point in my saying anything
to you? Think about it.

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: You should do yourself a favor here and cut King Little Richardloose.

am 30.12.2007 15:47:53 von MrArnold

Andre Kaufmann wrote:
> Richard Heathfield wrote:
>> Andre Kaufmann said:
>>



You can't talk to King Little Richard as he knows it all. You should cut
that fossil loose, and let him try to hold his court in comp.programming. :)

Re: If not .Net then what?

am 30.12.2007 16:25:54 von Barry Kelly

Richard Heathfield wrote:

> Andre Kaufmann said:
>
> > Richard Heathfield wrote:
> >> Andre Kaufmann said:
> >>
> >>> I don't believe you've compiled .NET code at all.
> >>
> >> Then we have nothing further to discuss.
> >
> > O.K., you stated you don't want to port your code to .NET in another
> > post and you said that your code runs 60 times slower under .NET ?
>
> Since you say you don't believe me, what is the point in my saying anything
> to you? Think about it.

Because factual evidence stands alone, and you haven't provided any.

-- Barry

--
http://barrkel.blogspot.com/

Re: If not .Net then what?

am 30.12.2007 16:36:22 von Barry Kelly

Herfried K. Wagner [MVP] wrote:

Disclaimer: I work for CodeGear, a division of Borland. I do not and
(legally) cannot speak for the company. I speak in a personal capacity
only.

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

Delphi is a product developed by CodeGear, a subsidiary of Borland.

> I am not sure
> about support for older versions of Delphi like Delphi 7.

We work hard to ensure compatibility between releases, such that people
upgrading to newer versions should simply face a recompile, possibly
with a few adjustments, rather than a large amount of work. If code
compiled using very old releases doesn't work as well as possible with
new OSes etc., we hope that the code can be ported to a newer release
with ease.

As Delphi applications can and often are built as standalone
executables, I'd wager that they are often more resilient to changing
OSes than systems which link in lots of shared code.

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

Delphi is an ongoing product. It's not like VB6, terminated in its
tracks. Delphi continues to be enhanced and developed.

-- Barry

--
http://barrkel.blogspot.com/

Re: If not .Net then what?

am 30.12.2007 17:32:19 von Richard Heathfield

Barry Kelly said:

> Richard Heathfield wrote:
>
>> Andre Kaufmann said:
>>
>> > Richard Heathfield wrote:
>> >> Andre Kaufmann said:
>> >>
>> >>> I don't believe you've compiled .NET code at all.
>> >>
>> >> Then we have nothing further to discuss.
>> >
>> > O.K., you stated you don't want to port your code to .NET in another
>> > post and you said that your code runs 60 times slower under .NET ?
>>
>> Since you say you don't believe me, what is the point in my saying
>> anything to you? Think about it.
>
> Because factual evidence stands alone, and you haven't provided any.

Not so. Everything that I have reported in this thread is factual. Whether
I have made correct *deductions* from the facts I have reported is of
course a matter of opinion, and I accept the possibility that I have made
incorrect deductions.

Nevertheless, it *is* the case that, in 2003 (I think), I and a colleague
wrote, in C++, a working system for analysing source code for determining
dependency relationships, and it *is* the case that we moved the code to
..Net and found that it ran sixty times slower on that platform. There may
be many reasons for that, reasons which we couldn't identify at the time,
and I accept that wholeheartedly.

But when Andre Kaufmann says that he doesn't believe that we did this, he
is basically accusing me of lying. If that is what he thinks, well, that's
up to him, but it makes future discussion with him rather pointless.

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 30.12.2007 17:58:08 von Andre Kaufmann

Richard Heathfield wrote:
> Barry Kelly said:
> [...]
>
> But when Andre Kaufmann says that he doesn't believe that we did this, he
> is basically accusing me of lying.

No - I don't blame you of lying, but perhaps misinterpreting - read below.

> If that is what he thinks, well, that's
> up to him, but it makes future discussion with him rather pointless.


I only can't believe you, because you don't say us how you did it -
moved the C++ code to .NET. You haven't converted it, since you posted
that you don't want to convert code to .NET.

We don't know which compiler you used and which language: C++ / C# /
Delphi / C++/CLI ?

You haven't answered this question not in several posts, where I asked
for this information to track down the problem.
What would you conclude if one makes statements and doesn't answer
simple questions (please continue reading before answering this question) ?


Currently my conclusion, derived from the posts was:
----------------------------------------------------

You have compiled your code with Visual Studio C++ .NET in the debug
version, which is .... slow compared to the release switch. This is a
rather common "problem", when switching the compilers from CBuilder to
VStudio, because by default CBuilder (the old version) hasn't supported
multiple configurations and starts by default with all optimizations
turned on.

Even if you turn all optimizations on in VStudios debug default
configuration of a C++ project, the debug heap is still active and slows
down heavily your application. Since you are using commonly *not*
VStudio but only CBuilder I came to the conclusion above.


Shouldn't be offensive to you at all.

Andre

Re: If not .Net then what?

am 30.12.2007 18:02:31 von obermd.

"Richard Heathfield" wrote in message
news:9JadnfhzK_KqWuranZ2dnUVZ8vWdnZ2d@bt.com...
> Barry Kelly said:
>
>> Richard Heathfield wrote:
>>
>>> Andre Kaufmann said:
>>>
>>> > Richard Heathfield wrote:
>>> >> Andre Kaufmann said:
>>> >>
>>> >>> I don't believe you've compiled .NET code at all.
>>> >>
>>> >> Then we have nothing further to discuss.
>>> >
>>> > O.K., you stated you don't want to port your code to .NET in another
>>> > post and you said that your code runs 60 times slower under .NET ?
>>>
>>> Since you say you don't believe me, what is the point in my saying
>>> anything to you? Think about it.
>>
>> Because factual evidence stands alone, and you haven't provided any.
>
> Not so. Everything that I have reported in this thread is factual. Whether
> I have made correct *deductions* from the facts I have reported is of
> course a matter of opinion, and I accept the possibility that I have made
> incorrect deductions.
>
> Nevertheless, it *is* the case that, in 2003 (I think), I and a colleague
> wrote, in C++, a working system for analysing source code for determining
> dependency relationships, and it *is* the case that we moved the code to
> .Net and found that it ran sixty times slower on that platform. There may
> be many reasons for that, reasons which we couldn't identify at the time,
> and I accept that wholeheartedly.
>
> But when Andre Kaufmann says that he doesn't believe that we did this, he
> is basically accusing me of lying. If that is what he thinks, well, that's
> up to him, but it makes future discussion with him rather pointless.
>
> --
> Richard Heathfield
> Email: -http://www. +rjh@
> Google users:
> "Usenet is a strange place" - dmr 29 July 1999
>

Now that we have an application, there are a few questions that you still
haven't answered.

1) What version of dotNET? I suspect it's 1.1 with VS 2003 from your time
frame. Version 2.0 is signficantly faster that 1.1 for most applications.
2) What dotNET language did you port your application to?
3) Did you use automated porting tools or did you take the time to actually
rework the application to take advantage of the features in dotNET? I
suspect the answer to this is that you didn't spend the time to use the
framework the way it was designed.

Mike Ober.

Re: If not .Net then what?

am 30.12.2007 18:20:40 von Richard Heathfield

Andre Kaufmann said:

> Richard Heathfield wrote:
>> Barry Kelly said:
>> [...]
>>
>> But when Andre Kaufmann says that he doesn't believe that we did this,
>> he is basically accusing me of lying.
>
> No - I don't blame you of lying, but perhaps misinterpreting - read
> below.

Then I have certainly misinterpreted an earlier remark that you made, for
which I apologise.

>> If that is what he thinks, well, that's
>> up to him, but it makes future discussion with him rather pointless.
>
> I only can't believe you, because you don't say us how you did it -
> moved the C++ code to .NET. You haven't converted it, since you posted
> that you don't want to convert code to .NET.

We wrote the original system in ISO C++ (plus Berkeley sockets).

> We don't know which compiler you used and which language: C++ / C# /
> Delphi / C++/CLI ?

We compiled the original code using several compilers - Intel, Visual
Studio 7, and gcc - and got comparable results from all of them - around
the 6 to 10 second mark for our test data set, with Visual C++ giving us 8
seconds IIRC. The translation to .Net involved converting to "managed"
C++.

> You haven't answered this question not in several posts, where I asked
> for this information to track down the problem.
> What would you conclude if one makes statements and doesn't answer
> simple questions (please continue reading before answering this question)
> ?

I would conclude that the person concerned isn't all that interested in a
justification, no matter how spirited, of a development environment that
they themselves rejected some years ago.

> Currently my conclusion, derived from the posts was:
> ----------------------------------------------------
>
> You have compiled your code with Visual Studio C++ .NET in the debug
> version,

No. I may not be the brightest star in the firmament, but even I know to
switch to release mode when doing performance analysis - and my
then-colleague *is* one of the brightest stars in the firmament; even if
I'd been dense enough to try a performance test in debug mode, she'd soon
have put me right.

You seem to think that, because I sing C++ Builder's praises, I am a heavy
C++ Builder user. I'm not. In fact, I don't think I've ever used it in the
Real World, although I use it a fair bit at home. Most of my Real World
experience has been on Microsoft, GNU, and big iron compilers. I've used
(almost) every version of Visual C++ ever published, as well as Microsoft
C5.0, 5.1 and 6.0 (which pre-dated Visual C++). I am perfectly well aware
of the difference between debug and release.

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 30.12.2007 21:39:03 von skeet

Bart C wrote:
> > Well then, lets benchmark it:
> >
> > Sieve of Erastophenes
>
> I tried this little recursive program in C#. And similar in straight C. The
> C# took nearly twice as long but that was probably in debug mode. So
> pleasantly surprised.

The funny thing about the Fibonacci sequence is that it's always shown
as the example of recursion, but it's one of the easiest recursions to
"undo" into a *far* more efficient form.

I'm sure most people reading this could give an alternative in their
sleep, but here's an example:

static int Fib(int n)
{
int previous = 0;
int current = 1;

for (int step = 0; step < n; step++)
{
int next = previous+current;
previous = current;
current = next;
}
return previous;
}

(Note that this is one step off from the code you gave - I was checking
by the sample data from Wikipedia. It's trivial to change, of course.
If you don't care about the n=0 case, it's slightly neater to return
current and make step start at 1, but hey...)

> Unless I've missed the point about what .Net is, I'm assuming it's a bunch
> of MS languages all producing the same IL and a huge runtime, plus some
> over-the-top IDEs.

Whether VS is over-the-top or not is a matter of opinion, of course. I
personally prefer Eclipse's Java support to VS's C# support, but never
mind. There are certainly a lot of designers, which I'm not generally a
fan of.

Other than that:
o Lots of languages compiling to IL - yes.
o The languages all being MS - no (see http://boo.codehaus.org for
example).
o Large runtime - yes.

I wouldn't say that's the "point" of .NET though. That's a question I
don't have time to address right now, unfortunately.

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

Re: If not .Net then what?

am 30.12.2007 22:06:16 von Marc Gravell

> o The languages all being MS - no (see http://boo.codehaus.org for example)



Marc

Re: If not .Net then what?

am 31.12.2007 00:34:39 von Andre Kaufmann

Richard Heathfield wrote:
> Andre Kaufmann said:

> [...]
> seconds IIRC. The translation to .Net involved converting to "managed"
> C++.

O.K. thank you for the information and please apologize the parts of my
posts which might have been unintentionally offensive.

To be honest I'm playing around with managed C++ only after the old
managed C++ style supported by VS7 had been deprecated and C++/CLI has
been introduced.
So I have only performance experience with the newer C++/CLI syntax and
don't know if the managed C++ syntax / implementation had some
"performance problems". It definitively had some readability problems,
regarding the ugly double underscore keywords, although these have been
more standard compliant.

60 times is a huge decrease and from the information I currently have I
would suspect it to be a string problem, since strings in .NET are
immutable and therefore each changing of a string creates a new string
object, which may be quite inefficient.

But it's also possible that managed C++ had other performance problems.


That a performance decrease is not always the case, when switching to
managed C++, here a little illustrative example I'm currently investigating:

-------------------------------------------------
Native C++ example:

class T { public: void cb(int i) {} };

void perf()
{
test t;
boost::function foo = boost::bind(&T::cb, t, _1);
foo(100);
return 0;
}

-------------------------------------------------

Managed C++/CLI example:

ref class T { public: void cb(int i) {} };
delegate void CBD(int i);

void perf()
{
T^ test = gcnew T();
CBD^ foo = gcnew CBD(test, &T::callback);
foo(100);
return 0;
}

-------------------------------------------------


The native function call foo(100) needs 30 assembly instructions and 3
branches/jumps.
The managed one needs 5 assembly instructions and 3 branches/jumps.
But it's too early to derive anything from that. I'm currently searching
for the problem / failure I've made - if there is one.
And I'm not an expert regarding the boost::bind/function templates, so
maybe there's a more efficient way to write it, which reduces the number
of assembly instructions needed too.


> [...]
> C5.0, 5.1 and 6.0 (which pre-dated Visual C++). I am perfectly well aware
> of the difference between debug and release.

Then please apologize, wasn't my intention to be offensive. I've got
bitten by the default configuration too, activated all optimizations,
but forgot to remove/change the damn debug macros.

Andre

Re: If not .Net then what?

am 31.12.2007 00:44:02 von Andre Kaufmann

Andre Kaufmann wrote:
>
> O.K. thank you for the information and please apologize the parts of my
> posts which might have been unintentionally offensive.

Ehm, damn could be misinterpreted too ;-).
Shouldn't mean that I had any intention to be offensive only that some
posts might be.

Should read:

Please apologize all parts of my posts which might have been offensive.
Wasn't my intention to be offensive.

> [...]

Andre

Re: If not .Net then what?

am 31.12.2007 01:07:35 von Randy Howard

On Sun, 30 Dec 2007 17:44:02 -0600, Andre Kaufmann wrote
(in article ):

> Andre Kaufmann wrote:
>>
>> O.K. thank you for the information and please apologize the parts of my
>> posts which might have been unintentionally offensive.
>
> Ehm, damn could be misinterpreted too ;-).
> Shouldn't mean that I had any intention to be offensive only that some
> posts might be.
>
> Should read:
>
> Please apologize all parts of my posts which might have been offensive.
> Wasn't my intention to be offensive.
>

This political correctness bull is out of hand when you must post a
correction to your apology because you fear that the original apology
might have been offensive.


--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Re: If not .Net then what?

am 31.12.2007 02:17:53 von obermd.

"Andre Kaufmann" wrote in message
news:OP9zGyzSIHA.4104@TK2MSFTNGP05.phx.gbl...
> Richard Heathfield wrote:
>> Andre Kaufmann said:
>
>> [...] seconds IIRC. The translation to .Net involved converting to
>> "managed" C++.
>
> O.K. thank you for the information and please apologize the parts of my
> posts which might have been unintentionally offensive.
>
> To be honest I'm playing around with managed C++ only after the old
> managed C++ style supported by VS7 had been deprecated and C++/CLI has
> been introduced.
> So I have only performance experience with the newer C++/CLI syntax and
> don't know if the managed C++ syntax / implementation had some
> "performance problems". It definitively had some readability problems,
> regarding the ugly double underscore keywords, although these have been
> more standard compliant.
>
> 60 times is a huge decrease and from the information I currently have I
> would suspect it to be a string problem, since strings in .NET are
> immutable and therefore each changing of a string creates a new string
> object, which may be quite inefficient.
>
> But it's also possible that managed C++ had other performance problems.
>
>
> That a performance decrease is not always the case, when switching to
> managed C++, here a little illustrative example I'm currently
> investigating:
>
> -------------------------------------------------
> Native C++ example:
>
> class T { public: void cb(int i) {} };
>
> void perf()
> {
> test t;
> boost::function foo = boost::bind(&T::cb, t, _1);
> foo(100); return 0;
> }
>
> -------------------------------------------------
>
> Managed C++/CLI example:
>
> ref class T { public: void cb(int i) {} };
> delegate void CBD(int i);
>
> void perf()
> {
> T^ test = gcnew T();
> CBD^ foo = gcnew CBD(test, &T::callback);
> foo(100);
> return 0;
> }
>
> -------------------------------------------------
>
>
> The native function call foo(100) needs 30 assembly instructions and 3
> branches/jumps.
> The managed one needs 5 assembly instructions and 3 branches/jumps.
> But it's too early to derive anything from that. I'm currently searching
> for the problem / failure I've made - if there is one.
> And I'm not an expert regarding the boost::bind/function templates, so
> maybe there's a more efficient way to write it, which reduces the number
> of assembly instructions needed too.
>
>
>> [...] C5.0, 5.1 and 6.0 (which pre-dated Visual C++). I am perfectly well
>> aware of the difference between debug and release.
>
> Then please apologize, wasn't my intention to be offensive. I've got
> bitten by the default configuration too, activated all optimizations, but
> forgot to remove/change the damn debug macros.
>
> Andre
>


OK - now we're getting somewhere. I have heard that the C++ in VS 2003 had
some major issues with performance, especially when mixing C++ code with
dotNET libraries. I do know that Visual C++ 7.0 is slower than VC++ 6.0.
In addition, you need to realize that Managed C++ isn't a true dotNET
language. Rather, it's a hybrid. Thus you can't really make the claim that
dotNET apps are slower than C++.

Mike.

Re: If not .Net then what?

am 31.12.2007 07:47:11 von Andre Kaufmann

Michael D. Ober wrote:
> "Andre Kaufmann" wrote in message
> [...]
>
> OK - now we're getting somewhere. I have heard that the C++ in VS 2003
> had some major issues with performance, especially when mixing C++ code

Hm, I was aware that it (managed C++) had a serious problem regarding
mixing managed and native code, which could lead to a deadlock, when a
native dll has been loaded dynamically - loader lock.
Wasn't aware that there were such flaws, that could explain a speed
decrease of 60 times. But as I wrote, I don't have that much experience
with the old implementation.

> with dotNET libraries. I do know that Visual C++ 7.0 is slower than
> VC++ 6.0.

The IDE yes, code generation definitively not, at least not that
significantly.

By the way the upcoming V10 (!not VS2008!) version has already a
nickname "the new 6" ;-)

> In addition, you need to realize that Managed C++ isn't a true
> dotNET language. Rather, it's a hybrid. Thus you can't really make the
> claim that dotNET apps are slower than C++.

The C++ compiler should emit the most optimized IL code of all .NET
compilers available from MS. At least with C++/CLI.
With managed C++ you may be right - don't know for sure.
There are some pitfalls, when crossing the boundaries between managed
and native code, but such a high decrease would be only explainable if
they have permanently crossed the borders, but I would assume that the
core function with the high decrease in performance hasn't done this.

> Mike.

Andre

Re: If not .Net then what?

am 31.12.2007 10:03:41 von Richard Heathfield

Michael D. Ober said:



> OK - now we're getting somewhere. I have heard that the C++ in VS 2003
> had some major issues with performance, especially when mixing C++ code
> with
> dotNET libraries. I do know that Visual C++ 7.0 is slower than VC++ 6.0.

So in other words, you recognise that the .Net implementation I was using
had serious performance issues, which is what I said all along.

> In addition, you need to realize that Managed C++ isn't a true dotNET
> language. Rather, it's a hybrid. Thus you can't really make the claim
> that dotNET apps are slower than C++.

It said .Net on the box. Are you telling me Microsoft were lying to my
then-client by claiming it was .Net when really it wasn't .Net? Would you
advise them to sue Microsoft?

In any case, it is not my claim that .Net apps are slower than C++, because
C++ doesn't have a speed. It's a language, not an implementation. The
speed of the "vanilla" C++ version varied depending on whether the
executable image had been built using Intel, gcc, or Visual Studio.

..Net, however, /is/ an implementation, so it does make sense to talk about
the speed of .Net applications - and in my experience it is unacceptably
slow. If you have a different experience, I'm pleased for you.

My original response in this thread was to someone who said "I've only ever
heard one objection to .Net...", and he went on to explain why he thought
that the objection was invalid. My only objective in this thread was to
broaden his experience, by giving him two more objections. The fact that
some people here don't agree with those objections does not put them into
a different class from the original objection which, after all, he himself
did not agree with. But never again will he be able to say "I've only ever
heard one objection to .Net..." - because he has now heard at least three.

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 31.12.2007 13:12:51 von hirf-spam-me-here

"Andre Kaufmann" schrieb:
> The C++ compiler should emit the most optimized IL code of all .NET
> compilers available from MS. At least with C++/CLI.

Well, optimization is primarily performed by the JIT compiler nowadays and
not by the compiler used to emit the IL. Optimization on JIT-level can be
more powerful because it can keep the machine's characteristics in mind.
Inlining, for example, is typically performed by the JIT compiler in .NET.

--
M S Herfried K. Wagner
M V P
V B

Re: If not .Net then what?

am 31.12.2007 13:50:36 von Andre Kaufmann

Herfried K. Wagner [MVP] wrote:
> [...]
> Well, optimization is primarily performed by the JIT compiler nowadays
> and not by the compiler used to emit the IL. Optimization on JIT-level
> can be more powerful because it can keep the machine's characteristics
> in mind. Inlining, for example, is typically performed by the JIT
> compiler in .NET.

Sure, agreed.

But the JIT compiler has to be fast, so that startup time/runtime isn't
decreased that much. And IMHO it currently can do only local
optimizations. High level optimizations, like removing complete code
parts or function calls, are still the task of the compiler itself.

It doesn't mean that the effect is significant and measurable
(generally), only that the C++ compiler sometimes can optimize the code
better and emit somewhat more efficient IL code.

This might be not the case in the future anymore, if all compilers will
share the same back end. And this will be the case if I understood the
Phoenix project correctly.

Andre

Re: If not .Net then what?

am 31.12.2007 14:42:23 von hirf-spam-me-here

Andre,

"Andre Kaufmann" schrieb:
>> Well, optimization is primarily performed by the JIT compiler nowadays
>> and not by the compiler used to emit the IL. Optimization on JIT-level
>> can be more powerful because it can keep the machine's characteristics in
>> mind. Inlining, for example, is typically performed by the JIT compiler
>> in .NET.
>
> [...]
>
> But the JIT compiler has to be fast, so that startup time/runtime isn't
> decreased that much.

That's true. In some situation creating a native image of the IL image may
be a solution. This can be archieved using the "ngen.exe" tool which comes
with the .NET Framework. The resulting native image is placed in the NIC
(Native Image Cache), which is part of the GAC (Global Assembly Cache). In
addition, the JIT compiler performs caching, which means that native
versions of methods etc. are cached and reused. This will reduce overhead
when calling a certain method more than once.

> And IMHO it currently can do only local optimizations. High level
> optimizations, like removing complete code parts or function calls, are
> still the task of the compiler itself.

Sure, the compiler can do some optimizations. However, the potential
optimizations a JIT compiler can perform are more evolved than those of the
compiler. Nevertheless, some sompilers provide different optimizations.
The VB compiler, for example, supports disabling of certain checks which
will result in fewer IL instructions but will also reduce security.

I believe that the whole performance debate misses the point:

..NET is a platform that is most suitable for writing user mode applications
in which performance and real-time behavior are not really important. On
the other hand, C and C++ are optimized for writing system applications
(kernel mode, heavy interaction with hardware, etc.).

Although C++ can be used to write applications similar to those commonly
written in VB/C#, the latter programming languages are more suitable for
this purpose (library support, designer support, IDE support, abstraction).

--
M S Herfried K. Wagner
M V P
V B

Re: If not .Net then what?

am 31.12.2007 16:37:50 von notmyfirstname

Herfried,

Please (you know what I want to write)

Cor

Re: If not .Net then what?

am 31.12.2007 16:51:52 von Jeff Gaines

On 31/12/2007 in message Herfried
K. Wagner [MVP] wrote:

>On the other hand, C and C++ are optimized for writing system applications
>(kernel mode, heavy interaction with hardware, etc.).

I would love to go back to pure C, but I would like a decent IDE and drag
and drop creation of forms. Is there anything like that available nowadays?

--
Jeff Gaines

Re: If not .Net then what?

am 31.12.2007 16:57:22 von hirf-spam-me-here

"Jeff Gaines" schrieb:
>>On the other hand, C and C++ are optimized for writing system applications
>>(kernel mode, heavy interaction with hardware, etc.).
>
> I would love to go back to pure C, but I would like a decent IDE and drag
> and drop creation of forms. Is there anything like that available
> nowadays?

This can be done using VC++ in C mode, for example. You can define forms as
Win32 dialog resources and use these resources in your Win32 C projects.
Note that most of the Win32 API is C-based and does not require C++. I am
sure that similar tools exist for other forms packages too.

--
M S Herfried K. Wagner
M V P
V B

Re: If not .Net then what?

am 31.12.2007 16:57:46 von hirf-spam-me-here

"Cor Ligthert[MVP]" schrieb:
> Please (you know what I want to write)

Sorry, I don't know what you want to tell me...

--
M S Herfried K. Wagner
M V P
V B

Re: If not .Net then what?

am 31.12.2007 18:38:13 von Tom Shelton

On 2007-12-30, Jon Skeet C# MVP wrote:
> CBFalconer wrote:
>> > 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.)
>>
>> I think you are all missing the fundamental point. C++ has a well
>> known, and generally adhered to, ISO standard. .NET is basically a
>> single supplier system. Richard and associates prefer not to be
>> limited to such a small user area.
>
> That much is fine. It's a perfectly valid objection. I should point out
> that C# also has an ISO standard; I'm not sure whether the CLI which
> has an ECMA standard also has an ISO standard - but either way, unless
> you include things like Mono, it's still a single supplier system.
>

I'm not sure why people discount mono all the time. Mono works and is
being used - for real applications. No, it is not 100% compatible with
MS's implementation - but, it is pretty close.

--
Tom Shelton

Re: If not .Net then what?

am 31.12.2007 19:05:34 von Randy Howard

On Mon, 31 Dec 2007 11:38:13 -0600, Tom Shelton wrote
(in article <#id8rP9SIHA.5164@TK2MSFTNGP03.phx.gbl>):

> On 2007-12-30, Jon Skeet C# MVP wrote:
>> CBFalconer wrote:
>>>> 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.)
>>>
>>> I think you are all missing the fundamental point. C++ has a well
>>> known, and generally adhered to, ISO standard. .NET is basically a
>>> single supplier system. Richard and associates prefer not to be
>>> limited to such a small user area.
>>
>> That much is fine. It's a perfectly valid objection. I should point out
>> that C# also has an ISO standard; I'm not sure whether the CLI which
>> has an ECMA standard also has an ISO standard - but either way, unless
>> you include things like Mono, it's still a single supplier system.
>>
>
> I'm not sure why people discount mono all the time. Mono works and is
> being used - for real applications. No, it is not 100% compatible with
> MS's implementation - but, it is pretty close.

On what percentage of the platforms for which a standard (pick a
flavor) C or C++ implementation is available?




--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Re: If not .Net then what?

am 01.01.2008 01:27:14 von MrArnold

Randy Howard wrote:
> On Mon, 31 Dec 2007 11:38:13 -0600, Tom Shelton wrote
> (in article <#id8rP9SIHA.5164@TK2MSFTNGP03.phx.gbl>):
>
>> On 2007-12-30, Jon Skeet C# MVP wrote:

>> I'm not sure why people discount mono all the time. Mono works and is
>> being used - for real applications. No, it is not 100% compatible with
>> MS's implementation - but, it is pretty close.
>
> On what percentage of the platforms for which a standard (pick a
> flavor) C or C++ implementation is available?
>

This is another poster out of comp.programming that you should just
simply ignore him as he too is an old retired, mind you, fossil that's
not in the game any more.

Re: If not .Net then what?

am 01.01.2008 01:37:12 von Jeff Gaines

On 01/01/2008 in message Mr.
Arnold wrote:

>This is another poster out of comp.programming that you should just simply
>ignore him as he too is an old retired, mind you, fossil that's not in the
>game any more.

Happy New Year to you too :-)

Some of the best products in their class have been produced by people who
do not have to price their time in to them.

--
Jeff Gaines

Re: If not .Net then what?

am 01.01.2008 01:56:56 von MrArnold

Jeff Gaines wrote:
> On 01/01/2008 in message Mr.
> Arnold wrote:
>
>> This is another poster out of comp.programming that you should just
>> simply ignore him as he too is an old retired, mind you, fossil that's
>> not in the game any more.
>
> Happy New Year to you too :-)
>
> Some of the best products in their class have been produced by people
> who do not have to price their time in to them.
>

Oh, I left out he's a MS and .NET hater to the max, and he sitting in
his little Admiral chair do nothing, count on it. :)

Re: If not .Net then what?

am 01.01.2008 03:19:00 von Liz

"Scott Roberts" wrote in
message news:uG531OZSIHA.4888@TK2MSFTNGP02.phx.gbl...


> of for, performing expensive operations within your loops, and using
> recursion. Recursion incurs the overhead of having to repeatedly build new
> stack frames"

but that's not unique or specific to C#

Re: If not .Net then what?

am 01.01.2008 03:40:21 von Liz

"Richard Heathfield" wrote in message
news:kfqdneCv4OFyiuvaRVnytAA@bt.com...

> "Miha Markic" said:
>
>>
>>> 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.

psycho-babble ...


>> But the magnitude of your problem clearly shows that you were doing
>> something wrong.
>
> No, that's begging the question.


it's begging YOUR question; so what were you doing wrong?

Re: If not .Net then what?

am 01.01.2008 03:50:24 von Liz

"Richard Heathfield" wrote in message
news:xL6dnXxRu7EE3-vanZ2dnUVZ8qninZ2d@bt.com...
> Bart C said:
>
>
>
>> 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.

so why in god's name are you talking about code you don't have, can't
disclose (nonsense and you know it) and don't really care about ?

Re: If not .Net then what?

am 01.01.2008 04:09:06 von Richard Heathfield

Liz said:

>
> "Richard Heathfield" wrote in message
> news:kfqdneCv4OFyiuvaRVnytAA@bt.com...
>
>> "Miha Markic" said:
>>
>>>
>>>> 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.
>
> psycho-babble ...

Sure. Let me put it another way. I find it interesting that people would
rather pretend a problem doesn't exist than find ways of dealing with it.

>>> But the magnitude of your problem clearly shows that you were doing
>>> something wrong.
>>
>> No, that's begging the question.
>
>
> it's begging YOUR question; so what were you doing wrong?

It seems you don't know what "begging the question" means. As for what we
were doing wrong, "using .Net" was the conclusion we came to at the time.
So we fixed that.

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 01.01.2008 04:15:24 von Richard Heathfield

Liz said:



> so why in god's name are you talking about code you don't have, can't
> disclose (nonsense and you know it)

Even if I had the legal right to disclose it (which I don't), how could I
disclose code I don't have? Duh.


> and don't really care about ?

If you had read my first reply in this thread [1], you would know the
answer, and you wouldn't have had to ask such a silly question.

But to save you the trouble of learning how to track down a Usenet article
by its message ID, I'll tell you. Someone claimed that they'd only ever
heard one objection to .Net. So I offered a couple of other objections -
performance and portability (lack thereof, in both cases). It seems,
however, that this thread has been cross-posted to some .Net fan groups,
and some rather animated defence of .Net has been going on. Well, I can
understand that. But most of the defenders have managed to keep a civil
tongue in their heads. You could learn a thing or two from them.

Message ID:

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 01.01.2008 09:46:50 von spinoza1111

On Jan 1, 10:50=A0am, "Liz" wrote:
> "Richard Heathfield" wrote in message
>
> news:xL6dnXxRu7EE3-vanZ2dnUVZ8qninZ2d@bt.com...
>
> > Bart C said:
>
> >
>
> >> 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.
>
> so why in god's name are you talking about code you don't have, can't
> disclose (nonsense and you know it) and don't really care about ?

Liz, part of the joy of programming is that it gives us insight into
logics of society and, from that insight, some control over our
lives...which we're not supposed to have.

My experience is that you're talking to a fellow who uses confusion in
his business dealings. In my experience, he makes obscure references
to language standards to describe common, and understandable, if
slightly confusing, expressions in C and C++ as unpredictable when in
fact they are defined by a virtual machine, while the standard needs
to accomodate novel platforms which he isn't qualified to program, and
which provably equate to the semantics of the VM. He also makes
elementary mistakes in execution at those rare times when his modus
operandi are exposed.

Hero computer scientist Edsger Dijkstra said some time ago, in so many
words, that "at university, we learned that Truth matters: in the
'real' world of business, we learn that only Secrets matter". I'm
afraid that his newsgroup is dominated by people who under financial
pressure in an ongoing world collapse are becoming Fascists, and who,
as Fascists, confuse and destroy Truth using references to what they
know to be Secrets, even as the Nazis used references to blood libels
and Protocols to insinuate that their opponents were incompetents, or
malefactors.

You're not going to get any straightforward answers out of Heathfield.





Edward G. "spinoza1111" Nilges, author of "Build Your Own .Net
Language and Compiler", Apress, May 2004.


Cyberbullies need not respond.

Re: If not .Net then what?

am 01.01.2008 12:13:13 von Andre Kaufmann

Richard Heathfield wrote:
> Michael D. Ober said:

Happy new year to all.


> [...]
> It said .Net on the box. Are you telling me Microsoft were lying to my
> then-client by claiming it was .Net when really it wasn't .Net? Would you
> advise them to sue Microsoft?

The C++ compiler can generate mixed assemblies. Some part is native some
part is managed - hybrid.

> In any case, it is not my claim that .Net apps are slower than C++, because
> C++ doesn't have a speed. It's a language, not an implementation. The

However you are comparing the speed of a C++ application with a managed
C++ one - don't you ?

> speed of the "vanilla" C++ version varied depending on whether the
> executable image had been built using Intel, gcc, or Visual Studio.
>
> .Net, however, /is/ an implementation, so it does make sense to talk about
> the speed of .Net applications - and in my experience it is unacceptably
> slow. If you have a different experience, I'm pleased for you.

I've given one example, which proves the opposite. 6 times more assembly
code than the C++ native code generates.

> [...]
> heard one objection to .Net..." - because he has now heard at least three.

We are still missing an example, which proves it. I've given one which
proves the opposite. That doesn't mean that I claim it to be always the
case.

I can find hundred examples where C++ is faster and where a managed
version is faster. Perhaps more examples where C++ is faster, but the
point is use the best tool for the task you want to accomplish.

If the developer is more experienced in C++ then it will be C++, other
way round the developer might be more productive with another language
but the result mustn't be slower than the C++ implementation.

It's always the same discussion C++ is better than ..., Java is better
than .... or other way round. Or Linux is better than ...., Open Source
is better than....., Shell Xxxx is better, Desktop Xxxx is better.

How about working together ? Using the best tools from both sides,
languages etc. ?

Andre

Re: If not .Net then what?

am 02.01.2008 04:15:11 von Arne

Richard Heathfield wrote:
> 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.

:-)

You are narrowing your tool set unnecessarily if you assume
that the x60 difference is a general case.

Arne

Re: If not .Net then what?

am 02.01.2008 04:18:19 von Arne

Richard Heathfield wrote:
> 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?

I don't think it say much.

Ask 2 programmers with 40 years of C# experience - hmmm make that
10 programmers with 40 years of C# experience - to write a C++ app.

I doubt the result will be good. And that is not C++'s fault.

It is not clear to me whether the .NET language used was C# or
managed C++ aka C++/CLI, but the latter looks like C++ but
is significantly different anyway.

Arne

Re: If not .Net then what?

am 02.01.2008 04:19:11 von Arne

jim wrote:
> "Arne Vajhøj" wrote in message
> news:477550ae$0$90267$14726298@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.

Then I do not understand the "slower than their desktop counterparts".

Arne

Re: If not .Net then what?

am 02.01.2008 04:20:17 von Arne

Richard Heathfield wrote:
> 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?

I think everybody would.

Just don't conclude too much from the experience.

Arne

Re: If not .Net then what?

am 02.01.2008 04:22:14 von Arne

Scott Roberts wrote:
> "Common Performance Issues
> During your code reviews, pay particular attention to the following areas:
>
> Frequent code paths. Prioritize your code review process by identifying
> code paths that are frequently executed and begin your review process in
> these areas.
> Frequent loops. Even the slightest inefficiency inside a loop is
> magnified many times over depending on the number of iterations.
> Specifically watch out for repetitive property access inside your loops,
> using foreach instead of for, performing expensive operations within
> your loops, and using recursion. Recursion incurs the overhead of having
> to repeatedly build new stack frames. "
>
> Of course we all know that any recursive routine can be rewritten as an
> iterative routine.

And you do not think 2 guys with 40 years of C++ experience would
know that ??

Arne

Re: If not .Net then what?

am 02.01.2008 04:25:38 von Arne

Richard Heathfield wrote:
> Jon Skeet [C# MVP] said:
>> 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.

Don't.

0-60% is more likely to see.

Arne

Re: If not .Net then what?

am 02.01.2008 04:29:34 von Arne

Andre Kaufmann wrote:
> Richard Heathfield wrote:
>> Jon Skeet [C# MVP] said:
>>> Richard Heathfield wrote:
>>>> I simply don't care enough to construct an example. Sorry.
>>> In that case it would probably be worth avoiding the assertion that
>>> .NET is slow in future.
>>
>> Yeah, fair enough - I'll revise it to "100% of the .Net projects I've
>> been involved with have run 60 times slower than their native
>> equivalents". :-)
>
> Since you don't write which compiler and settings you used and which
> code basis (C - Code / C-Sharp etc.) I don't believe you've compiled
> .NET code at all.

So because a guy can not remember the compiler switches he used on
a project 4-5 years then you do not believe the project existed.

Hmmmm. I guess I have been working on bunch of non existing projects
in my time.

Arne

Re: If not .Net then what?

am 02.01.2008 04:36:13 von Arne

CBFalconer wrote:
> "Jon Skeet [C# MVP]" wrote:
> ... snip ...
>> 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.)
>
> I think you are all missing the fundamental point. C++ has a well
> known, and generally adhered to, ISO standard.

And what is ECMA-334 ?

> .NET is basically a
> single supplier system. Richard and associates prefer not to be
> limited to such a small user area.

You consider Windows a small area ??

Hmmmm.

> The fact that they could
> immediately find bugs [1] is confirmation of their wisdom.
>
> [1] I define a slow-down factor of 60 as a bug.

No it does not.

Since it is unclear what exactly caused the lack of
performance.

All indications is that something was not ported properly.

I do not blame the dev team for that. Brand new technology
introduced late in a project with a deadline is not a recipe
for success.

But considering it wisdom may be stretching it !

Arne

Re: If not .Net then what?

am 02.01.2008 04:40:26 von Arne

Andre Kaufmann wrote:
> Richard Heathfield wrote:
>> Andre Kaufmann said:
>>
>>> I don't believe you've compiled .NET code at all.
>>
>> Then we have nothing further to discuss.
>
> O.K., you stated you don't want to port your code to .NET in another
> post and you said that your code runs 60 times slower under .NET ?
>
> If I ask how you did it you simply ignore the questions. And if I try to
> tickle you a bit to get it out, you seem to be offended.
>
> You blame others knowing nothing of performance, but you can't tell us
> why your code port (was it ?) has been that slow.
>
> So the facts:
>
> a) You have C++ code
> b) Stated you compiled it somehow as .NET application
> c) Stated that it runs 60 times slower
> d) Have no single proof
> e) Don't tell us how you did b)
> f) Blaming others to be kind of dumb by using the words "clicky-pointy"
> g) Can't prove it all

He did explain that it was many years ago and that he obviously
could not provide the code (which should not even be necesarry
to state BTW).

And it is a free world.

He can post his opinion on .NET performance.

People can ask if he has a code example.

And he can explain that it was business code.

And then readers must summarize all experiences posted and
make their own conclusions.

But you can not demand proof.

Arne

Re: If not .Net then what?

am 02.01.2008 04:43:41 von Arne

Andre Kaufmann wrote:
> Currently my conclusion, derived from the posts was:
> ----------------------------------------------------
>
> You have compiled your code with Visual Studio C++ .NET in the debug
> version, which is .... slow compared to the release switch. This is a
> rather common "problem", when switching the compilers from CBuilder to
> VStudio, because by default CBuilder (the old version) hasn't supported
> multiple configurations and starts by default with all optimizations
> turned on.
>
> Even if you turn all optimizations on in VStudios debug default
> configuration of a C++ project, the debug heap is still active and slows
> down heavily your application. Since you are using commonly *not*
> VStudio but only CBuilder I came to the conclusion above.
>
> Shouldn't be offensive to you at all.

1) I doubt that could give a x60 difference

2) C++ programmers usually check compiler switches

3) You can not serious expect him to remember the project settings
on a project 4-5 years ago.

Arne

Re: If not .Net then what?

am 02.01.2008 04:46:27 von Arne

Michael D. Ober wrote:
> 1) What version of dotNET? I suspect it's 1.1 with VS 2003 from your
> time frame. Version 2.0 is signficantly faster that 1.1 for most
> applications.

Stuff like generic collections for simple data types has provides
huge performance improvements, but not in the x60 range.

I have not seen big improvements in the JIT (32 bit).

> 3) Did you use automated porting tools or did you take the time to
> actually rework the application to take advantage of the features in
> dotNET? I suspect the answer to this is that you didn't spend the time
> to use the framework the way it was designed.

As Jon has posted a couple of times, then different language
sometimes requires different way of doing things.

Arne

Re: If not .Net then what?

am 02.01.2008 04:54:54 von Arne

Richard Heathfield wrote:
>> OK - now we're getting somewhere. I have heard that the C++ in VS 2003
>> had some major issues with performance, especially when mixing C++ code
>> with
>> dotNET libraries. I do know that Visual C++ 7.0 is slower than VC++ 6.0.
>
> So in other words, you recognise that the .Net implementation I was using
> had serious performance issues, which is what I said all along.

I think he is talking about small percentages not x60.

>> In addition, you need to realize that Managed C++ isn't a true dotNET
>> language. Rather, it's a hybrid. Thus you can't really make the claim
>> that dotNET apps are slower than C++.
>
> It said .Net on the box. Are you telling me Microsoft were lying to my
> then-client by claiming it was .Net when really it wasn't .Net? Would you
> advise them to sue Microsoft?

C++ in .NET variation supports so called mixed mode with both native
code and .NET managed code. I don't think you can sue MS for that.
But it is a rather complex matter.

Arne

Re: If not .Net then what?

am 02.01.2008 04:57:19 von Arne

Liz wrote:
> so why in god's name are you talking about code you don't have, can't
> disclose (nonsense and you know it) and don't really care about ?

Why not ?

Do you think people should only post their experience if they
can release the source code the experience is based on ?

Arne

Re: If not .Net then what?

am 02.01.2008 05:03:50 von Arne

Randy Howard wrote:
> On Mon, 31 Dec 2007 11:38:13 -0600, Tom Shelton wrote
> (in article <#id8rP9SIHA.5164@TK2MSFTNGP03.phx.gbl>):
>> I'm not sure why people discount mono all the time. Mono works and is
>> being used - for real applications. No, it is not 100% compatible with
>> MS's implementation - but, it is pretty close.
>
> On what percentage of the platforms for which a standard (pick a
> flavor) C or C++ implementation is available?

Win/x86
MacOS X/x86
MacoS X/PPC
Solaris/SPARC
Linux/x86
Linux/PPC
Linux/IA-64
Linux/IBM mainframe

are the supported ones I think.

It has also been build on some other platforms like *BSD/x86,
Solaris/x86 etc..

Arne

Re: If not .Net then what?

am 02.01.2008 05:07:00 von Richard Heathfield

Arne Vajhøj said:

[elsethread]
> You are narrowing your tool set unnecessarily if you assume
> that the x60 difference is a general case.

Yes, I understand that. Nevertheless, there are so many tools in the shed
already. That's why producers of new tools have to impress their potential
customers quickly.

> Richard Heathfield wrote:
>> 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?
>
> I don't think it say much.
>
> Ask 2 programmers with 40 years of C# experience - hmmm make that
> 10 programmers with 40 years of C# experience - to write a C++ app.

(Presumably you mean 40 years total.)

> I doubt the result will be good. And that is not C++'s fault.

Ask 10 programmers to write an app in any language, and I doubt the result
will be good. :-)

> It is not clear to me whether the .NET language used was C# or
> managed C++ aka C++/CLI,

It was C++, translated into "managed C++".

> but the latter looks like C++ but is significantly different anyway.

Agreed! :-)

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 02.01.2008 05:14:20 von Richard Heathfield

Arne Vajhøj said:

> Scott Roberts wrote:

>>
>> Of course we all know that any recursive routine can be rewritten as an
>> iterative routine.
>
> And you do not think 2 guys with 40 years of C++ experience would
> know that ??

Um, quite so. [1]

But the point bears addressing anyway. The suggestion seems to be
"eliminate the recursion by replacing it with iteration, and the code will
speed up". But of course programming languages are all about expressive
power. The original code (in "native" C++) expressed inherently recursive
algorithms recursively, and was thus easy and quick to write. Translating
it into an iterative equivalent for the sake of .Net would have been
(relatively) difficult and slow, and therefore expensive, and there was no
guarantee that the performance gain would have been sufficient to justify
the expense of carrying out the conversion. What's more, the code would
have ended up as a *poorer* expression of the algorithms we were using,
and thus it would have been harder (read: more expensive) to maintain.


[1] Just one nit - one of the "guys" (and the brighter of the two, in fact)
was actually a gal.

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 02.01.2008 05:16:42 von Richard Heathfield

Arne Vajhøj said:

> Richard Heathfield wrote:
>> Jon Skeet [C# MVP] said:
>>> 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.
>
> Don't.
>
> 0-60% is more likely to see.

Er, this might be a misunderstanding. I was not claiming here that .Net
/is/ typically 60x slower. I was merely claiming that, if it /were/, I
think it would still be widely used even so (because it has "Microsoft"
written on the box).

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 02.01.2008 05:22:39 von Richard Heathfield

Arne Vajhøj said:

> Richard Heathfield wrote:
>>> OK - now we're getting somewhere. I have heard that the C++ in VS 2003
>>> had some major issues with performance, especially when mixing C++ code
>>> with
>>> dotNET libraries. I do know that Visual C++ 7.0 is slower than VC++
>>> 6.0.
>>
>> So in other words, you recognise that the .Net implementation I was
>> using had serious performance issues, which is what I said all along.
>
> I think he is talking about small percentages not x60.

Well, I hope so. Still, he did say "major issues with performance".

>>> In addition, you need to realize that Managed C++ isn't a true dotNET
>>> language. Rather, it's a hybrid. Thus you can't really make the claim
>>> that dotNET apps are slower than C++.
>>
>> It said .Net on the box. Are you telling me Microsoft were lying to my
>> then-client by claiming it was .Net when really it wasn't .Net? Would
>> you advise them to sue Microsoft?
>
> C++ in .NET variation supports so called mixed mode with both native
> code and .NET managed code. I don't think you can sue MS for that.

Yeah, I know - I was teasing him a little, that's all.

> But it is a rather complex matter.

The problem is that we live in a sound-bite world, where complex matters
are invariably over-simplified. The original claim, "I've only ever heard
one objection to .Net", smacked (to me, at least) of over-simplification,
hence this entire sub-thread. I hope that at least one person's horizons
have been stretched a little as a result. :-)

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 02.01.2008 06:56:27 von Liz

"Arne Vajhøj" wrote in message
news:477b0b95$0$90262$14726298@news.sunsite.dk...

> Liz wrote:

>> so why in god's name are you talking about code you don't have, can't
>> disclose (nonsense and you know it) and don't really care about ?

> Why not ?

> Do you think people should only post their experience if they
> can release the source code the experience is based on ?

I think posting 30 messages on a topic positing an implausible 60x
performance deficit while providing **NO** detail about the code is
ridiculous ... when the poster further says he doesn't really care about the
code, what do you think we should conclude, Arne? That he's making a
sincere effort to contribute something worthwhile to the dialogue? Don't
think so ....

Re: If not .Net then what?

am 02.01.2008 07:13:41 von Richard Heathfield

Liz said:

> what do you think we should conclude, Arne? That he's making a
> sincere effort to contribute something worthwhile to the dialogue?

What you *should* conclude is really up to you. But what you *could*
conclude with a great deal of accuracy is that I started off by making a
simple and perfectly valid reply to someone else's article, and that the
discussion then grew out of all proportion to the importance of the
original point, as it so often does on Usenet.

--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 02.01.2008 07:29:06 von MrArnold

Liz wrote:
> "Arne Vajhøj" wrote in message
> news:477b0b95$0$90262$14726298@news.sunsite.dk...
>
>> Liz wrote:
>
>>> so why in god's name are you talking about code you don't have, can't
>>> disclose (nonsense and you know it) and don't really care about ?
>
>> Why not ?
>
>> Do you think people should only post their experience if they
>> can release the source code the experience is based on ?
>
> I think posting 30 messages on a topic positing an implausible 60x
> performance deficit while providing **NO** detail about the code is
> ridiculous ... when the poster further says he doesn't really care about the
> code, what do you think we should conclude, Arne? That he's making a
> sincere effort to contribute something worthwhile to the dialogue? Don't
> think so ....
>

The only place King Little Richard is appreciated in is by his (MS
posse)is in comp.programming. He is a (MS basher) King Little Richard is
and the Supremes. But even his Supremes have better sense to not show.
You should drop him like a hot rock.

Re: If not .Net then what?

am 02.01.2008 09:55:43 von Randy Howard

On Tue, 1 Jan 2008 22:03:50 -0600, Arne Vajhøj wrote
(in article <477b0d1e$0$90264$14726298@news.sunsite.dk>):

> Randy Howard wrote:
>> On Mon, 31 Dec 2007 11:38:13 -0600, Tom Shelton wrote
>> (in article <#id8rP9SIHA.5164@TK2MSFTNGP03.phx.gbl>):
>>> I'm not sure why people discount mono all the time. Mono works and is
>>> being used - for real applications. No, it is not 100% compatible with
>>> MS's implementation - but, it is pretty close.
>>
>> On what percentage of the platforms for which a standard (pick a
>> flavor) C or C++ implementation is available?
>
> Win/x86
> MacOS X/x86
> MacoS X/PPC
> Solaris/SPARC
> Linux/x86
> Linux/PPC
> Linux/IA-64
> Linux/IBM mainframe
>
> are the supported ones I think.
>
> It has also been build on some other platforms like *BSD/x86,
> Solaris/x86 etc..

If the above list of platforms where you can use Mono is accurate, and
I have no reason to doubt you, then it is /much/ less portable than
either C or C++.

Of the above list, I am only familiar with comments on its
functionality and compatibility with two of them relative to .NET on
Windows platforms, and they have been so far that it is not baked, and
does not allow relatively complex .NET apps written for Windows
platforms to move over easily, or in some cases at all.

Since my impression is that Mono is by no means "baked" yet, and that
Microsoft isn't exactly not developing .NET anymore either, Mono is
chasing a moving target somewhat, so I don't find this particularly
surprising, and don't fault Mono itself. It's an understandable
problem.


--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Re: If not .Net then what?

am 02.01.2008 11:50:37 von unknown

> If the above list of platforms where you can use Mono is accurate, and
> I have no reason to doubt you, then it is /much/ less portable than
> either C or C++.

You can't actually compare the portability of .net against C(++). .net is
more than just a language, it is a framework, while C(++) you are talking
about is a language + small library.
Furthermore, even those aren't exactly portable due to different library
implementations, right?

>
> Of the above list, I am only familiar with comments on its
> functionality and compatibility with two of them relative to .NET on
> Windows platforms, and they have been so far that it is not baked, and
> does not allow relatively complex .NET apps written for Windows
> platforms to move over easily, or in some cases at all.
>
> Since my impression is that Mono is by no means "baked" yet, and that
> Microsoft isn't exactly not developing .NET anymore either, Mono is
> chasing a moving target somewhat, so I don't find this particularly
> surprising, and don't fault Mono itself. It's an understandable
> problem.

Here steps in Silverlight 2.0....
--
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/

Re: If not .Net then what?

am 02.01.2008 12:22:15 von Richard Heathfield

"Miha Markic" said:

>
>> If the above list of platforms where you can use Mono is accurate, and
>> I have no reason to doubt you, then it is /much/ less portable than
>> either C or C++.
>
> You can't actually compare the portability of .net against C(++).

Er, why not?

> .net is
> more than just a language, it is a framework, while C(++) you are talking
> about is a language + small library.

Nevertheless, if you require Functionality F to be available on Platform P,
and are not prepared to go to the trouble of porting a development tool to
Platform P yourself, you have no option but to choose a development tool
that is available on Platform P. If Platform P has a C (or C++)
implementation available that provides the infrastructure (i.e. sufficient
features) for implementing F but no .Net implementation, then you can
implement Functionality F on Platform P using C (or C++), but you cannot
use .Net to do the same thing. Now range over all P (for a given F), and
you have a relative portability measure between C (or C++) and .Net - thus
demonstrating that you can in fact compare the portability of .Net against
C (or C++). But see below.

> Furthermore, even those aren't exactly portable due to different library
> implementations, right?

Both C and C++ are defined by ISO standards. C compilers that conform to
ISO/IEC 9899:1990 are available on a very, very wide range of platforms,
including not just desktop and middle range machines, but also top-end
mainframes and tiny little embedded systems. To a lesser extent, this is
also true of C++. For hosted environments, this also includes the standard
library specified by ISO.

Having said all that, in one sense you are right, because .Net offers
vastly more functionality than either ISO C or ISO C++ (flashy graphics,
mouse-talk, and the like - stuff that you /can/ do in C or C++ but only by
using vendor-supplied or third-party libraries that are not part of the
standard language), and so in that sense they're not really comparable. It
would be like comparing a chainsaw with a machine shop. You can do a lot
more with the machine shop, but on the other hand it's a lot harder to
carry around!



--
Richard Heathfield
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999

Re: If not .Net then what?

am 02.01.2008 12:52:37 von hirf-spam-me-here

"Arne Vajhøj" schrieb:
> And then readers must summarize all experiences posted and
> make their own conclusions.

Facts are not subject of a poll. It's perfectly valid to request a proof to
substantiate claims.

--
M S Herfried K. Wagner
M V P
V B

Re: If not .Net then what?

am 02.01.2008 19:46:28 von Tom Shelton

On Jan 2, 4:22 am, Richard Heathfield wrote:
> "Miha Markic" said:
>



> Both C and C++ are defined by ISO standards. C compilers that conform to
> ISO/IEC 9899:1990 are available on a very, very wide range of platforms,
> including not just desktop and middle range machines, but also top-end
> mainframes and tiny little embedded systems. To a lesser extent, this is
> also true of C++. For hosted environments, this also includes the standard
> library specified by ISO.
>

ISO/IEC 23270 (C#)
ISO/IEC 23271 (CLI)

--
Tom Shelton

Re: If not .Net then what?

am 10.01.2008 03:08:53 von Arne

Richard Heathfield wrote:
> Arne Vajhøj said:
>> Richard Heathfield wrote:
>>> 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?
>> I don't think it say much.
>>
>> Ask 2 programmers with 40 years of C# experience - hmmm make that
>> 10 programmers with 40 years of C# experience - to write a C++ app.
>
> (Presumably you mean 40 years total.)

Yup. As for the 2 C++ programmers.

>> I doubt the result will be good. And that is not C++'s fault.
>
> Ask 10 programmers to write an app in any language, and I doubt the result
> will be good. :-)

It is possible, but the the process needs to be different.

Arne

Re: If not .Net then what?

am 10.01.2008 03:12:38 von Arne

Herfried K. Wagner [MVP] wrote:
> "Arne Vajhøj" schrieb:
>> And then readers must summarize all experiences posted and
>> make their own conclusions.
>
> Facts are not subject of a poll. It's perfectly valid to request a
> proof to substantiate claims.

It is valid.

But the one doing it should expect to be laughed at.

Arne

Re: If not .Net then what?

am 10.01.2008 03:17:29 von Arne

Randy Howard wrote:
> On Tue, 1 Jan 2008 22:03:50 -0600, Arne Vajhøj wrote
> (in article <477b0d1e$0$90264$14726298@news.sunsite.dk>):
> > Win/x86
> > MacOS X/x86
> > MacoS X/PPC
> > Solaris/SPARC
> > Linux/x86
> > Linux/PPC
> > Linux/IA-64
> > Linux/IBM mainframe
> >
> > are the supported ones I think.
> >
> > It has also been build on some other platforms like *BSD/x86,
> > Solaris/x86 etc..
>If the above list of platforms where you can use Mono is accurate, and
>I have no reason to doubt you, then it is /much/ less portable than
>either C or C++.

Not necessary less portable.

C/C++ programs are usually not portable at all.

But absolutely less platforms available.

But the list does cover some of the most popular platforms.

> Of the above list, I am only familiar with comments on its
> functionality and compatibility with two of them relative to .NET on
> Windows platforms, and they have been so far that it is not baked, and
> does not allow relatively complex .NET apps written for Windows
> platforms to move over easily, or in some cases at all.

In that sense it is much like C/C++ - stick with the standard
and it it portable - do some platform specific and it is not
portable.

Arne