public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Gregory Casamento <greg.casamento@gmail.com>
To: Jonathan Wakely <jwakely.gcc@gmail.com>
Cc: esr@thyrsus.com, Steven Bosscher <stevenb.gcc@gmail.com>,
	GCC Mailing List <gcc@gcc.gnu.org>
Subject: Re: Don't shoot the messenger
Date: Thu, 23 Jan 2014 23:49:00 -0000	[thread overview]
Message-ID: <9CE797A6-7F95-435A-8F5D-EF93B9DA165A@gmail.com> (raw)
In-Reply-To: <CAH6eHdQoUtBC5kXWW5KDTBr=8pE8s258sck+3E9Me_ybU+atkA@mail.gmail.com>

Guys,

I have resisted entering into this argument up until now.   All I can do here is share my experience with technical decisions that have been made in GCC.  

I am the maintainer of GNUstep (http://www.gnustep.org/) and the principal author of the Gorm (Interface Builder) (http://www.gnustep.org/experience/Gorm.html) application as well as many other parts of GNUstep.  GNUstep, being an implementation of Cocoa, requires an up to date Objective-C compiler, something that, sadly, GCC lacks.

About 3 years ago it was necessary to have an Objective-C header parser in Gorm so that it could read classes and enter them into it's library for use when building the GUI for an application.  I attempted to use GCC's implementation, but was unable to because GCC was apparently, purposefully, not modularized such that it was possible to take advantage of the parser as a separate library.  I ended up writing my own which, while educational, should not have been necessary.   Whether the decision was made politically or not, it held back progress in my project and delayed me from adding important functionality to free software.

One other point I must make is in regards to clang's Objective-C support vs. that of GCC.   GCC regards Objective-C as a second class language and has done so for some time.  Objective-C, according to recent statistics has surpassed C++ in the number of developers using it (see this link http://www.i-programmer.info/news/98-languages/4462-objective-c-overtakes-c-in-tiobe-index.html).

Clang has, in my experience, at least the above two advantages over GCC.  My project is a free software project, but, yet, we are already starting to shift towards using Clang as our primary compiler for the above two reasons among others.  It will not surprise me if I see more projects go the same way.

I can't emphasize enough how important it is to see change in GCC not just for my project's sake, but for the whole of free software.

Is it enough to "win" based on philosophical grounds, but lose on technical ones?  And if GCC loses on technical grounds aren't you, in effect, losing the war since fewer people will end up using your stuff since it doesn't do what they need or want?  I don't believe that making technical decisions on the basis of political ends really wins anything.   A message earlier in this same thread bears out that many technical decisions on GCC were, in fact, made for political reasons and that GCC should carefully consider which ones should be rescinded. 

Sincerely,
Gregory Casamento

(Sorry for the repost, I didn’t know whether or not it was delivered as gmail sent it in HTML format which the list rejected)

On Jan 23, 2014, at 5:22 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:

> On 23 January 2014 21:58, Eric S. Raymond <esr@thyrsus.com> wrote:
>> Steven Bosscher <stevenb.gcc@gmail.com>:
>>> On Thu, Jan 23, 2014 at 10:27 PM, Eric S. Raymond wrote:
>>>> I have not run direct checks on the quality of the optimized code, but
>>>> reports from others that it is improved seem plausible in light of
>>>> the fact that GCC's optimization technology is two decades older in
>>>> origin.
>>> 
>>> Yay, another "fact".
>>> 
>>> You must have missed the almost complete rewrite of GCC's optimization
>>> framework that was merged in 2004 and that's been continuously
>>> improved since than: http://gcc.gnu.org/projects/tree-ssa/
>>> 
>>> Really. Do your homework.
>>> 
>>> Ciao!
>>> Steven
>> 
>> And another bullet whizzes by my head.
>> 
>> Really, attempts to shoot the messenger *won't help*.
> 
> Then stop trying to "help" us, please.
> 
>> By ignoring the
>> areas where clang *does* have a clear advantage, *right now*, you are
>> displaying the exact head-in-the-sand attitude that is most likely to
>> concede the high ground to clang.
> 
> It's not about having our head-in-the-sand and not wanting to hear the message.
> 
> You seem to think you're doing us a favour by telling us something we
> need to hear.
> 
> We've heard it. It's not a new message. You can stop telling us now, thanks.
> 
>> That outcome wouldn't be a problem for me.
> 
> In that case you can stop trying to pass on the message now. We've heard it.
> 
>> It would hurt the FSF's
>> prestige pretty badly, though.  It's not really my job to care about that,
>> but I thought someone here would. Perhaps I was wrong.
> 
> I know you think you're trying to help, but you're just yet another
> person standing outside the tent pissing in, thinking you're helping
> us win a war with Clang.  But there is no war.
> 
> There's room for two high-quality open source compilers. They will
> distinguish themselves in different ways, one of which is licensing.
> 
> Now please, stop trying to help.

  reply	other threads:[~2014-01-23 23:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-23 21:28 Eric S. Raymond
2014-01-23 21:58 ` Steven Bosscher
2014-01-23 22:22   ` Eric S. Raymond
2014-01-23 22:32     ` Jonathan Wakely
2014-01-23 23:49       ` Gregory Casamento [this message]
2014-01-24  1:02         ` Eric Botcazou
2014-01-24  1:28           ` Gregory Casamento
2014-01-24  1:43             ` Jonathan Wakely
2014-01-24  6:32             ` Ian Lance Taylor
2014-01-24 14:54               ` Richard Kenner
2014-01-24 16:34     ` Joseph S. Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9CE797A6-7F95-435A-8F5D-EF93B9DA165A@gmail.com \
    --to=greg.casamento@gmail.com \
    --cc=esr@thyrsus.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jwakely.gcc@gmail.com \
    --cc=stevenb.gcc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).