On Tue, Jan 31, 2012 at 3:52 PM, Dr. David Kirkby
<david.kir...@onetel.net>wrote:

>
> But it makes the code unportable. What hope do we have with the Sun/Oracle
> compiler if idiots use non-standard C? What hope do we have if we try to
> build on Windows at some point in the future using a native compiler? All
> these GNU extensions are a headache for everyone except the linux community.
>
> If there was not so much poor code in Sage, building with the Sun compiler
> would be possible, but it rejects much of the code.
>
>
This is a long reply, so a quick summary: "If there was not so much poor
code in Sage, building with the Sun compiler would be possible, but Sage
would be much less useful."

This is a rather late response, but as I don't see any responses that
complain
about your viewpoint, it seems appropriate. I don't want anyone to see your
email that think that your views are representative of the majority of
opinions, because I think that they are both wrong and harmful.

Whether or not someone writes standard C has little to do with whether or
not
they are an "idiot" and in many (most?) cases it doesn't even have much to
do
with whether or not they are ignorant (which is much different). As far as
example given above, I would say that, though I do not know him personally,
I
am pretty sure that Michael Stoll (who wrote ratpoints) is not an idiot.
(The
situation is probably quite the opposite.)

In general, person X might use nonstandard GNU extension Y for many reasons,
including:

(1) X has more important things to worry about than what is or isn't
standard C/C++.

(2) gcc is (for better or for worse) a de facto standard.

(3) Y happens to be very useful, and perhaps makes the code much faster

(4) X knows that Y is not a standard, but for he/she/they is/are only
interested in running his/her/their code for his/her/their own purposes, and
doesn't much care whether or not it works for Sage, or on Solaris, or on
Windows.

That is (partially) why I think your viewpoint is wrong. Another nice
example
is smalljac. It would be very nice if this were included in Sage, bit it
won't
be for the moment largely because

"This code is only supported on 64-bit Intel/AMD platforms
(life is too short to spend it worrying about overflowing a 32-bit
integer)."

This has nothing to do with GNU extensions, but you can see quite clearly
that
the Drew Sutherland is well aware of some shortcomings of his code and that
he
has no intention of fixing them. That puts the onus to fix the code on Sage
developers, if they want it to be included, the same way that Sage
developers
should be willing to fix ratpoints if they want it to compile with clang (or
sun's compiler, or MSVC).

For another example: I recently tried to compile some of my own code using
clang++ and discovered that I am not allowed to do

void f(int j) {
    complex<double> x[j];
    [...]
}

even though g++ accepts that. ( See
http://clang.llvm.org/compatibility.html#vla ) Now, I have a few options. I
could allocate everything on the heap explicitly; I could use
vector<complex<double> >; or I could specify a maximum size for j. All of
these options are bad for me, because I care very much about speed, and
I know that j is small, and 99% of the time it will be less that 20, but I
don't want to always allocate space for j = 100 because this is very rare.
So
I have to consciously decide what to do, and if I decide to stick with the
nonstandard gcc extension it is not because I am an idiot but because it is
probably the fastest/easiest option on what is likely to be the only
compiler I ever care about.

Continuing: I might find a 5% improvement in my code through proper use of
__builtin_expect on gcc. I know this is not portable, but should I really
take
the time to figure out how to write a proper macro that will work for one
million different compilers, when am only going to use one? If I don't it
has
nothing to do with idiocy.

As for why your viewpoint might be harmful: I have heard anecdotes of people
not wanting to release their code because it was ugly, or nonstandard, or
difficult to use, etc. As long as the response that they are going to
receive
it along the lines of the above, that viewpoint is valid, even if the
response
should be "Yes, this is ugly, but it is still awesome."

Large (most?) parts of Sage have simply come from third-party code written
by people who never had any intention of having anything to do with Sage.
Such people should be encouraged to release their code, not called idiots
when they do release it.

(This was a rather long off-topic response, and I'm not going to respond
again.
Or at least not in this thread.)

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to