jacob navia said:
Richard Heathfield a écrit :
[...] The point you are missing is that there is more to
programming than "making it as easy as possible". Programming languages
have various characteristics, of which "ease of use" is only one. Others
include performance, portability, flexibility, expressive power, and
simplicity (a non-exhaustive list).
I am speaking not about "making it as easy as possible" (do not know
where you got that) but about "less error prone interfaces"!
I accept the correction (for I am not trying to misrepresent your view,
after all). To aim for less error-prone interfaces is a worthy goal, but
there are lots of worthy goals of which that is only one, and it is
unfortunately true that we cannot always get closer towards one goal
without moving further away from others.
This means that mind-dumbing requirements like having to take
care of all the millions of string lengths that you have got
in your program are to be banned.
That's certainly an opinion, but I value freedom of choice. If you want to
offer people an extension which takes care of these "mind-numbing
requirements", that's entirely up to you, but let's not forget that it
comes at a cost - lock-in to a particular implementation - and not
everybody wants to pay that cost. It may also have other, less obvious
costs, such as performance degradation.
Interfaces should take
care automatically of string lengths. A string is a single
OBJECT composed of data and a length (counted strings),
and maybe other fields.
That's certainly an opinion, and it's not necessarily a bad one. It forms
the basis of typical third-party string libraries (including my own). But
to *force* people to use it is a step backwards. Your trade-off preferences
do not necessarily match everyone else's trade-off preferences.
This is by the way vastly more efficient than counting
the length of the string at each usage, as you may know.
That depends on how often you need the length of the string. It may be that
you don't need it often enough to justify the space or time overhead
involved in storing it.
Of course this efficiency is maybe not desired. Is that what
you mean?
No, I mean that it isn't *necessarily* the most efficient way. Often it will
be, but often isn't always.
But anyway:
I have nothing against making it as easy AS POSSIBLE... Read well the
"AS POSSIBLE" part.
Simplifying, making interfaces less complex makes them less
error prone, and is surely a step in the right direction.
It's a step in *a* right direction, but unfortunately that may involve it
being a step *away* from other right directions.
[snip]
You appear to wish to promote one particular characteristic - ease of use
- without regard to the effect that such promotion will have on various
other characteristics.
When implementing the extensions in lcc-win32 nothing is paid by other
software that does not use them. All the extensions do not affect
in any way the rest of the language.
I have no problem with any implementor choosing to provide extensions to the
language, but it is important for the programmer to remember that using
such extensions renders the program non-portable.
The performance implications of calling
MyAdd(Number *a, Number *b);
or doing
a+b;
are ZERO.
That depends on the implementation (including the machine architecture).
In both cases there is a function call.
No, there is no function call involved in a+b; (unless a and b are macros
that are concealing function calls in their definition).
<snip>
