On Sat, 21 Apr 2012 10:20:41 +0200, Bernd Nawothnig
On 2012-04-20, Gene Wirchenko wrote:
These implementation details should better be hidden and invisible
for
most cases. Let the compiler automatically detect and generate
possible optimisations.
If you complicate things, the compiler then has to work to
decomplicate (optimise). Why not just keep it simple?
My proposal was quite the contrary: simplification of things, i.e.
removal of unnecessary data types by unifications.
Keep in mind: the compiler is not the programmer!
A programming language should be as simple and orthogonal as
possible.
One application of keeping it simple would be to use primitives
where possible -- since they are simpler than objects -- and only use
objects where they are needed.
See above: don't mix up the compiler, the machine, and implementation
details with the programmer. Things should be simple for the
*programmer*, not necessarily for the compiler or the machine, even if
that maybe preferable. But preferable is not necessary ...
I am not confusing them, but one does have to consider them all.
If a language can not be easily compiled, that creates problems. Even
if the compilation is simply slower, that may discourage use of it.
yep...
(pardon any exaggeration... this can be taken purely as personal
opinion...).
programmer considers whether to use C or C++ for something:
tries compiling code with a C compiler, kind of slow, but livable (well,
my project rebuilds in about 20 seconds);
tries compiling code with a C++ compiler, takes a while, programmer
wanders off, gets coffee, comes back, compiler is still churning
along... (and maybe continues to take an additional 30 minutes).
programmer concludes, regarding C++: "no... this just isn't worth it...".
OTOH: Java compiles fairly fast...
(but, admittedly, Java isn't really perfect either).
so, ultimately, the programmer chooses things based on a mixture of what
they are most comfortable with, and what annoyances they are inclined to
put up with, ...
so:
the C++ programmer lives with absurdly long build times (and says "but
at least I have, features!").
the C programmer lives with a world where doing OO stuff/... is
generally painful, and thinks "what problem is there which can't be
solved with a little pointer arithmetic?" (maybe followed by using an
#ifdef to check the CPU type, writing a few bytes into a buffer, and
then calling it as if it were a function pointer...), and concluding
"all this OO stuff is nothing really beyond syntax sugar over a few
structs and function pointers anyways... so why care?...".
and the Java programmer lives in a world where writing code in general
is painful (and then thinks, "well at least I have this giant class
library, just have to find the relevant SomeClassWhichDoesTaskX",
nevermind should anyone go through the pain of having to write some
actual code to do something...). but, it is all good, "for safety!".
say:
C:
void *p;
long long j;
int i;
...
i=p; //compiler: warning: I don't like the way this looks, but ok...
i=j; //compiler: <remains silent>
C++:
void *p;
long long j;
int i;
...
i=p; //compiler: error: you need to cast this crap...
i=j; //compiler: <remains silent>
Java:
Void p;
long j;
int i;
...
i=j; //compiler: error: OMG WTF!
... (error message spanning several lines)
... i=j;
... (gotta make sure, ^, programer sees this crap)
...
so user has to remember to type "i=(int)j;" or they might cut themselves
on the sharp edges of numeric precision, and meanwhile "i=(int)p;"
doesn't even come close to working (but, to be fair, there is little in
the language design to say what the value "should" be, if it were
in-fact to work).
and maybe some of:
C:
printf("Have you seen this? %f\n", sin(M_PI));
C++:
cout << "Have you seen this?" << sin(M_PI) << endl;
( somewhere in history: "hey, have you seen the spiffy new feature, I
can make these operators do whatever random crap I want!", someone else:
"hard-core yeah! using shift for printing! why don't we make this a
standard feature!" ).
Java:
System.out.println("Have you seen this? " + Math.sin(Math.PI));
("no one will notice...").
well, and:
C:
#include <stdio.h>
int main()
{
printf("yay!\n");
return 0;
}
C++:
#include <iostream>
using namespace std;
int main()
{
cout << "yay!\n" << endl;
return 0;
}
Java:
public class MyClass
{
public static void main(String[] args)
{
System.out.println("yay!");
}
}
just saying is all...
(decided to leave out some other examples here, potentially more likely
to create controversy, which isn't really my intent here).
or such...
