Re: [DotGNU]Dotgnu written in C#?

[DrDiettrich]

j_post wrote:
> Modern compilers *should* do these things. What I meant by
> "protection" is languages that limit what programmers can do on the grounds
> that some practices are "unsafe". Some practices that are "unsafe" (pointers
> for example) are very powerful tools when used by a competent programmer, and
> programmers should not be prevented from using such tools just because some
> will abuse them.

The use of legacy practices, including assembler, for performance
reasons is questionable. According not only to my experience, most
"unsafe" things also can be done in a safe way, which an appropriate
compiler can translate into comparably fast code.

Nowadays processors, with instruction caches, overlapped operations etc.
require compilers, which create the best possible sequence of the best
cooperating instructions, at machine level. With source code of a too
low level (pointers...), a compiler often has not the chance to optimize
the code in the same way, as it could be done for higher level code.

Most programmers only will not notice the progress in language and
compiler techniques, because they very rarely give it a reasonable try.
Doing it in the safe way, I notice the improved performance of any new
compiler revision, and of my improved skills to do things in the best
optimizable way.

With regards to open source software, the usage of pointers and other
low level and consequently unsafe constructs often obscures the code to
other readers. This then leads to never-touch-any-more areas (write-only
;-) in a project, which later can prevent required or suggested
modifications and optimizations in other places.

And with regards to the performance of CLI code I remember a somewhat
official statement of an Borland Delphi developer. When they started to
make Delphi produce CLI code, they found the .NET version being
optimized better (running faster) than their own native code
compilation.

Another experience with low-level-optimizing programmers is a typical
lack of appropriate algorithms. They almost try to excessively improve
small parts of the code, where a change of the overall algorithms often
would reduce the order of an algorithm, with an exponential speed
improvement. And what seems to be good practice, on the programmers own
system, may turn out to be bad on other systems.

IMO it's not normally worth to spend time in optimizing parts of a
program by tweaking the code, since after such modifications the then
available hardware and compilers provide the same increase in execution
speed. Forcing programmers to take substancial steps towards safe and
readable programs, is the only way to convince them of the real benefits
of newer techniques, which otherwise they continue to ignore and deny.
Honestly.


> I have in mind not only runtime checks, but overhead that is inherent in any
> OO language. OOP is a good thing and is the appropriate choice for many
> applications, but in some cases (embedded systems is an obvious example), the
> overhead of constructors, destructors, garbage collection, etc, can be fatal
> to a project. Even in applications, it can make a huge difference: One of my
> current projects runs fairly fast in C--implementing the same algorithms in
> C# results in a runtime that crawls along at an unacceptably slow rate.

This behaviour can have various reasons, whose discussion would require
much more information. A more detailed discussion is OT in the frame of
this group, so I only want to add some general notes. Clearly there
exists code, which can not benefit from an OO port. Other code deserves
more or less redesign, before it fits together and can profit from OO.
Using C# together with CLI may currently not produce the best possible
results.

The benefits of OO and CLI almost become more obvious in the further
development of a project, when the previously restricted procedures can
be used in a much more extended scope. Then the immanent management
overhead for the objects can be justified by the many additional
features of the objects, which then are available at no extra cost.
Using powerful objects for trivial tasks is comparable to using powerful
command line tools in a shell script, to perform trivial operations;
like when creating a listing and piping it to grep to extract the only
interesting line of information. But no command line user complains,
that the same operation would run much faster when both programs were
accessible as simple subroutines in one program, or that the list
creator already should be able to omit all unwanted information. I often
have the impression that the same people defend in one context what they
offend in another context with the same vehemence.

> One must decide whether runtime efficiency or
> development/maintenance time is most important for a particular application.
> Having spent two decades developing embedded systems, I have a slight bias
> toward runtime efficiency and so prefer C over OO languages. ;-)

That's your right. I don't doubt your (or anybody elses) skills and
experience, and I don't want to give you concrete advice or education.
At least not unless explicitly asked for, and provided with sufficient
and detailed background information ;-)

If you say that it is so, then it is so. It were different if somebody
complains about a slow program, and asks for explanations and cures for
that unwanted behaviour.

DoDi