If not .Net then what?

[Peter Duniho]

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

It's already off-topic, due to the fact that "(e-mail address removed)" 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

 

[Scott Roberts]

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.

 

[Scott Roberts]

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.

 

[Chris Mullins [MVP - C#]]

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.

 

[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

 

[Guest]

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?

 

[Miha Markic]

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

 

[Andre Kaufmann]

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

 

[Herfried K. Wagner [MVP]]

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?

 

[Arne Vajhøj]

Arne Vajhøj said:

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

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.

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

 

[Arne Vajhøj]

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

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

Arne

 

[jim]

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.


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.


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&group=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

 

[jim]

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

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

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

jim

 

[jim]

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&group=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

 

[Lasse Vågsæther Karlsen]

Scott Roberts said:



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.


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]

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

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.

 

[Kerem Gümrükcü]

Servus Herfried,

Is Kylix still supported and developed further?

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

Regards

Kerem

--

 

[Lasse Vågsæther Karlsen]

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.

 

[Herfried K. Wagner [MVP]]

no, Kylix is dead!

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

 

[Richard Heathfield]

Scott Roberts said:

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

Ah, I approve.

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

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