MIX - Novell's de Icaza criticizes Microsoft patent deal (LinuxWorld)

It's true that Sun are just as bad, but that doesn't make Microsoft any better. And
specifically it doesn't mean Mono's even lousier support is any good.

I did single out Mono. I'm sure the Microsoft CLR has its problems, but it can manage to fall
properly asleep and it does, (in current versions) more or less get Unicode handling correct,
or close enough. What we have isn't a good clone of a terrible system, but a poor clone of a
not-so-great system.

Crossing out UCS-2 and writing UTF-16 in your documentation (when you even remember to say
something more specific than just "Unicode") isn't enough. In any case, UCS-2 tends to get
people into a mindset where they start thinking of a character, a code point, a code unit and
a glyph as more or less the same thing, precisely the type of attitude that UTF-8 has been
beating out of people developing in C or Perl. .NET inherits from Win32 certain APIs that
implicitly make this mistake, and fixing them makes it awkward and unsettling. As with Java,
the C# "wide character" built-in type is almost entirely useless, because it can only store a
UTF-16 code unit, and in a high level language you almost never /want/ a UTF-16 code unit but
instead need a character, which won't fit.

Exactly as I said, the suggested "fix" is that you can upgrade to some future version (Python
2.6 isn't out) and use this new API to work around the problem.

If this was some minor library being worked on by a volunteer in their spare time, fair
enough, we can always just avoid that library - but people are proposing that we write large
and important programs in this language now.

Look what it took to even get this concession, 18 months later, that the next version would
have a fix, someone had to grab Guido at a conference and basically shake him up and down so
he'd go investigate.

In a toy language, or a prototyping language, these sorts of problems are easily forgivable.
But today people want to recommend Python for writing real software that will go out to end
users or into production systems. Indeed most Linux distributions include such software, and
you'll find it running on your machine easily enough, it's the program with the GUI that
freezes whenever it's doing any work, or the one that wakes up needlessly every few
milliseconds, chewing through the whole laptop battery in an hour and a half - and far from
being concerned about this total failure, the Python developers hail it as a success.

> Because of this, there is a strong technical argument that libraries (at least, those
intended to be widely used) should be written with C interfaces, because
lowest-common-denominator C interfaces can be called by essentially every other language
whereas interfaces in "modern" languages mostly cannot. 


Well I don't have any problem with libraries written in C. It's code that is commonly used in
multiple applications and any sort of memory savings, language compatebility, or performance
is a has the largest amount of impact. Higher up on the application stack C is much less
attractive and it's benefits become more rarefied.

The issue is with *Official* Gnome and Gnome is far more then just system libraries, is it
not? You have browsers, utilities, nautilus, etc etc etc.

The OP is that Gnome should never use anything other then C, in anything it plans on including
in itself, to write anything because that is unfair to other languages. (?)

> Reread my posting: because it's bare unfair.

That's what I don't understand.  Why does it matter that Gnome needs to treat Lua, Ruby,
Cobol, <insert favorite small language>, or Python all as equals? What does it matter? How
does that make it a better desktop environment?

I mean being 'fair' sounds very cool and all. We are taught in gradeschool that being fair is
nice.. but as a basis for designing a desktop environment I do not see the real benefit.  It
could be that I am just ignorant, but I just don't see it.

What I see that your saying is that you'd rather see all non-C language support be equally
crappy rather then favor a few and make support for those those great.


> What's even worse, is to have to maintain a bloat like mono to support "official" gnome: I'm
sorry, but I see the monstruous amount of complex mono code lines as THE very big issue. It's
worse than java since the base technology must not be trusted at all (mono is viewed on the
computer market as a poor quality and inferior .net framework... thx for the poisonous gift).

Ok, then pick out something better. I don't care if Mono is seen as a second rate .NET. It
doesn't bother me one bit. In fact I don't care one way or another if Gnome supports Mono as a
'official' language.

(If you care about image so much you should pay closer attention to what they are saying about
Linux application developers clinging to C as the answer for everything...)

What I do care about is Mono is already supported, it's legal security is as fine as any other
language (say.. Java), IMO. It's a modern language, it's "good enough", and it's already being
used.  So embrace it.

> Coding in C *is* about "chasing" pointers and doing manual allocation. 

Yes, that's what I said and I think that for most applications it's a waste of time with
little benefit to end users or the quality of the application. I figure people should use C
were it's appropriate, but otherwise use something more productive.


> It does mean "I understand what's going on", "I have control", and "I depend already on gcc
complexity and that's fairly enough". Nowadays you have tools to assist you in order to let
you code properly (valgrind, gcc more and more verbose warnings, etc). Moreover my experience
demonstrates what you say is irrelevant: time spent on boilerplate code is minimal in
comparison of time spent on application logic.

So your saying that for programmers coding in C they can create applications just as fast and
create programs just as safe (given the same limited amount time) as if they programmed in any
other language? That runs completely counter to most everything I've ever read on the
subject...