Re: RAD Studio Roadmap Updated

In article <4822aa47$1@xxxxxxxxxxxxxxxxxxxxxx>, i.rather@not says...
Jolyon Smith wrote:

In article <48202b66$1@xxxxxxxxxxxxxxxxxxxxxx>, i.rather@not says...
Jolyon Smith wrote:

Strict private and strict protected provide a means for the compiler
to tell you when you have done something you shouldn't have done.

If you can code with strict private/strict protected then you code in
exactly the same way without them.

Then you don't need type safety or anything else, either.

As usual... "if you think carbon monoxide is bad then you must think all
gases are bad and then no-one could breath".

When offering something as an "improvement" the extent to which it
improves something is important in deciding just how much of an
improvement it is.

Do not lose sight of the fact that this started from an initial list
presented by Rudy of "new things that cannot be emulated".


"strict private" and "strict protected" absolutely CAN be emulated by
simply coding strictly. They are not langauge changes that allow
something new and previously impossible.

If a variable is meant to be strictly private, then treat it as such.
Similarly strictly protected. These declarations do not allow something
that you couln't not do before - i.e. they CAN be emulated. Very
easily.


THAT was my point.

NOT that they were intrinsically bad things to have introduced in the
first place.



Marking a fn inline does not "direct" the compiler to do anything
reliably. You can direct this until you are blue in the face and the
compiler will not necessarily always comply.

It will comply according to the specification (of the inline
directive).

Not necessarily. Last I heard (maybe things have changed in the
compiler...?) the inline directive will ask the compiler to inline it
but does not ensure nor guarantee that it will.


Profiling will
show the bottlenecks, 'inline' is one, new and previously very hard to
emulate, way of squeezing those bottlenecks.

Again, not quite sure what is so difficult about inlining the code
yourself.

In fact, something I have done myself... having profiled and found that
a handful of calls to a very trivial routine were causing a bottleneck,
the body of that routine was manually inlined in those handful of cases.

In that case, being as I say, trivial it was done "long hand" (i.e.
manually inlined in each case - in a couple of cases allowing for
further optimization of the code that previously surrounded the now-
inlined code, something that "inline" could NOT achieve, so where's the
improvement in THAT case?).

But you could equally use good ol' fashioned include files to emulate an
inlined "function", with the only slight niggle being the need to use
consistent variable names as inputs/outputs to/from the inlined code.

So not as elegant as a simple "inline" directive, but *really* not that
hard, and in fact (unless, as I say, the compiler has changed) actually
more reliable (in terms of knowing/ensuring that the code has actually
*been* inlined, without having to inspect the generated code).


But again the primary point in the context of this thread being that
contrary to Rudy's assertion, inline absolutely CAN be emulated.



.NET (gasp! shock!)

You are getting a bit tiresome with your .NET antipathy.

Again, you miss the point.

I make no secret of being highly skeptical of .NET (in terms of
relevance to what *I* do) but not anti-.NET per se, any more than I am
anti-Java. They both do a job. A very similar one in fact and a lot of
the reasons that I don't find Java relevant to what I do apply -
unsurprisingly - equally to .NET.


BUT a lot of the so called "improvements" in Delphi (for Win32) are
there for one reason and one reason only: because Delphi.NET *had* to
have them and Delphi for Win32 had to be compatible with Delphi.NET.

Highlighting that fact is done not to continue some diatribe against
..NET, but rather to point out that these "improvements" are not there
primarily *AS* improvements, but merely as compatability measures.



Why? Why shouldn't the language be used to show the intent,

The question is, where is the line to be drawn between intent and
implementation?

To indulge in a little of the extrapolation of argument that is often
used so inappropraitely against me, the ultimate expression of intent
over implementation detail would have it that software development be
reduced to:

TAccountsPackage.Create;

TNewFirstPersonShootEmUp.Create;

TVista.Create;

Which is obviously nonesense.

But if that is "obviously nonesense" why is it any less nonesensical to
suggest that implementation details DO MATTER?

Construct's like "for-in" etc are fabulous for churning out code
quickly, but CREATING code has NEVER been where the majority of the COST
of code has sat - that is attributed to the MAINTENANCE of code.

And a great deal of the effort in code maintenance (ime) is expended in
trying to find performance improvements and optimisations and eliminate
side-effects as the weight of functionality in any given system
increases and so acts to impair performance.

At which point, the exposure of the implementation details is CRITICAL
to being able to successfully identify those implementation details that
can be refined and modified to improve performance and/or identify
potentially unanticipated side-effects.


Dismiss this as just my opinion, which it is, but it is an opinion
formed after years of experience, so in dismissing my opinion you must
also dismiss that experience and that is NOT just _mine_, and takes in a
hugely disparate variety of software projects from simple single-user
desktop apps to real-time powerstation simulations, taking in multi-tier
and traditional client server applications along the way, covering
commercial software and both strategic and tactical enterprise apps.


The current fad in software development is in improving "productivity"
which, when you peel away the hyperbole and critically examine what is
on offer, comes down to "make it easier to CREATE code" with very little
concern for the future maintenance of that code.

Many of the "advances" quite obviously will create maintenance PROBLEMS
downstream. Which will set up quite nicely the opportunity that the
companies peddling todays "productivity boon" need to then peddle
tomorrows "maintenance boons" to a willingly gullible marketplace when
the time comes. In 5-10 years say.

After which we'll go around again with a new batch of "productivity
innovations" etc etc etc.

Last time around it was 4GL's and RAD.

This time around it has been intention and agility.

The hardest part is coming up with new names for the same old rope.


and the
compiler used to translate that into an implementation? Don't you trust
computers?

Your question is meaningless - computers don't do anything that requires
trust. They do of course run software, of which compilers are just one
example, but software is created by humans, fallible and unreliable
creatures at the best of times.

So your question really is "Don't you trust people?"

A hugely general question and imho an unfair one.

So allow me to refine your question to the one that I think you meant to
ask - certainly the one you should have asked:

"Don't I trust compiler writers to extract the best possible
implementation for any given situation from any general high level
abstraction of intent that I might express?"

The simple and obvious answer to that is: No.


"Obvious" because a compiler does not know the CONTEXT of any given
"expression of intent", so what might be optimal in one case could be
disastrously sub-optimal in others.

Jacks of all Trades are never Masters of any One.


A compiler of course is a VERY GOOD master of taking high level
expressions of implementation details and turning them into machine
executable instructions.

Not so good at taking high level expressions of intent in an infintiely
variable range of contexts and then devising the best possible
implementation details in any specific case.



So have I. I have seen all too many of those "why change, we're OK as
it is" and "I'm not interested in changing my ways. This is just a fad"
and "etc." people during the years (professional programmer since 1979).

And yet you haven't noticed that as much as things "change", they
invariably stay the same?


have a nice weekend (ok, a bit early, but you
get my meaning, I hope)!

You too, although I suspect my weekend shall arrive a little sooner than
yours.

:)
.

Relevant Pages

  • Re: OT: C++ overloading operators
    ... way before complex numbers were part of the STL. ... I used the INLINE directive for these trivial functions. ... A compiler can not do inlining without access to the source code. ...
    (comp.dsp)
  • Re: HLA
    ... inline assembler for that compiler. ... different beast from a standalone assembler and IMHO, HLA is most ... It could be added to almost any C compiler without problems... ... then you're no longer programming in the standard form of the ...
    (alt.lang.asm)
  • Re: Inline Functions?
    ... an inline function is a programming language ... that is, it suggests that the compiler ... so the complete body of function func() should actually be placed from ...
    (comp.lang.c)
  • Re: introspection in SML
    ... inline and notinline declarations, and compiler macros. ... still sometimes do it, but with a compiler like MLton, I don't have ... noticed that it did fewer calls to arbitrary precision ...
    (comp.lang.functional)
  • Re: RAD Studio Roadmap Updated
    ... Strict private and strict protected provide a means for the compiler ... that the new directives can *help* you doing right, ... and "etc." people during the years (professional programmer since 1979). ...
    (borland.public.delphi.non-technical)