[ale] Hello World - in C# - in Mono - in Ubuntu is done

[Michael B. Trausch]

On Thu, 2010-09-16 at 22:25 -0400, Ron Frazier wrote:
> Aaron,
> 
> I would have hoped for a more informative and less divisive reply from 
> you.  However, I have no desire to start an argument.  8-)  If you type C# 
> vs C++ vs Java into Google, you get about 2.5 million results.  So, 
> obviously, it's a hot debate.  Instead of trying to read or summarize them, 
> I'll just give my take on the issue.

Not everyone got the memo on the fact that Mono is indeed free software,
licensed under a freedom-granting free software license and that even
Richard Stallman, probably the one person that defines the end of the
spectrum (though Aaron isn't far away from that! ;-)) even grants it
that.

Before going any further on this mail, let's think about this another
way.  We already know that a programming language cannot be copyrighted;
its _specification_ may be, but someone can always write another
specification.  The same goes, really, for _any_ file format, whether it
is structured text or binary or some hybrid or whatever.

Once upon a time there was only the dBase programs that interacted with
the dBase file format.  Someone came along at some point and said that
they wanted to interoperate with that format, and they didn't want to or
could not purchase the software from the vendor to do so.  So, instead
of looking for something else (or maybe the requirement was true two-way
interoperability, I don't know for sure) to perform the same task in a
different file format, another implementation that accessed the same
file format was born.  Today there are many, many implementations of
code that can read and write files in the entire xBase family.

What I mean to say by all of this is that no single file format can be
considered to be "proprietary", at least not completely.  Yes, people
will try to hinder the understanding of the format when they have some
money invested in it.  But even de facto standard formats can be freed
from the title of being nasty proprietary things by creating free
software implementations of those file formats.  Those file formats can
be anything:

      * GCC and GNU's binutils support a number of executable formats,
        including ELF, COFF, and PE executables for various system
        architectures.  Note that PE executables are a Microsoft format
        (and that format is also used for the CLR system that is
        implemented by .NET and Mono)
      * There are many applications and libraries which implement
        support for the GIF image format and the MP3 audio format.  Note
        that in both cases (though I don't have citations handy at the
        moment) it is technically possible to get around patent issues
        on both if you do things slightly different but in a fashion
        that is compatible with most codecs (who writes perfect
        code---not even the drafters of a specification do, it turns
        out).
      * A great many applications support various versions of RTF.  I
        see none of those applications being cursed up and down for
        supporting it, even though the RTF specification is, like the
        Microsoft Office file format specifications, a Microsoft
        specification.  Even various addons to the TeX typesetting
        engine support RTF output!

With sufficient effort (and desire!) it is indeed possible for all of us
freedom loving people to implement support for any file format, for any
purpose.  What does that get us?  Some would say that it means that we
interoperate with the evil proprietary things and we wouldn't want that
in a million years.  I don't buy that; if that were the case, would we
not implement some specification for networking that would exclude such
systems, and then deploy it on a massive scale?  No, what it does mean
is that as we perfect our understanding of opaque data formats, and as
those formats go from opaque to translucent to eventually almost
transparent, we also can support those formats indefinitely.

An example:  I frequently get people who get in touch with me---usually
they're referred to me by people I have done work for at some point in
the past---who have insanely old documents that need to be brought
up-to-date in terms of the format used to store them.  Most popularly
this happens with Microsoft Works files, don't ask me why.  Anyway, I do
a lot of this by hand, because there isn't great support for these
formats in terms of converting them automatically.  I've started writing
a parser for them so that I can convert them to ODT and ODS and ANSI
SQL, but I haven't gotten terribly far just due to lack of time.  In any
event, if I can ever get it done, we'll have a free software
implementation of that file format.  Mostly useful for getting data the
hell out of it, but also useful for if someone wants to save a more
modern document in an ancient format to give to someone who only has an
ancient computer and ancient (and unsupported!) software.

We can, in doing this sort of thing, take over the ownership in some
sense of the file format.  That is, after all, how a lot of our
standards came to be in the first place.  Or they never really came to
be, and they were just de facto standards, whether documented or
otherwise.

In any event...

> 
> First and foremost, I want the knowledge I'm trying to acquire to make me 
> money.  These Wikipedia articles talk about market share:
> 
> http://en.wikipedia.org/wiki/Microsoft_Windows - Windows - ~ 91%
> http://en.wikipedia.org/wiki/Macintosh#Software - Mac OS - ~ 10%
> http://en.wikipedia.org/wiki/Linux - Linux Server - ~ 20% - 40%, Linux 
> Desktop - ~ 5%
> 
> A quick and dirty search on the Monster job board within 200 miles of 
> Atlanta yields:
> 
> C++ - 11 jobs
> C# - 57 jobs
> Java - 106 jobs

I'd like to point out that this is hardly representative and is quite
likely completely irrelevant.  You'll probably find very few openings
for COBOL programmers, I would expect, but they are in demand---after
all, they're all dying!

> So, I think I can certainly make money by learning C#.  I could make money 
> with Java too, but I'm more concerned about Oracle being a corporate evil 
> demon than Microsoft at this point, given their propensity to sue people 
> after acquiring Sun.  The Java community seems to be in an uproar.  Also, 
> Microsoft is under scrutiny by the US Government for potentially anti 
> competitive practices.  That past is not good, but they have to be careful 
> about further activities of that nature.

That hasn't stopped them from the continuance of those practices.  But
that is neither here nor there; Microsoft does not control the Mono
implementation, and that is good enough for me.

> 
> http://arstechnica.com/open-source/news/2010/08/oracles-java-lawsuit-undermines-its-open-source-credibility.ars
> http://www.linuxinsider.com/rsstory/70619.html?wlc=1284686907
> http://www.infoworld.com/t/intellectual-property/oracles-android-lawsuit-pandoras-box-serious-evils-359
> http://phandroid.com/2010/08/23/android-developers-unhappy-with-oracle-over-baseless-lawsuit/
> 
> In addition, I want the following from my language of choice:
> 
> Modern, high performance (but not real-time, for drivers, or kernels), 
> object oriented, multi threaded, capable of usage for desktop, server, or 
> network based applications.  In my mind, the candidates are:
>       C++, C#, Java

While it is true that some languages would be exceedingly difficult to
implement properly without what you're calling "multi threaded" support,
no language actually (strictly speaking) _requires_ it except in
specification.  Even C# with its threading primitives can be implemented
without using true threads.  Granted, it would break some programmer's
expectations, but it shouldn't break the code itself.  It'd just run
more slowly and with less actual threads (consider, for example, if a C#
implementation implemented those primitives using fibers instead of
threads).

C is a very high performance language.  It can be written in an
object-oriented manner (see GObject, GTK+, GNOME, etc.), can be used to
write multithreaded applications (using something like the POSIX threads
APIs or GNU Pth on systems that do not support threading directly), can
be used for any type of application imaginable, including embedded
applications on extremely limited processors, and is modern even after
all these years.  If you are willing to get into a solid set of habits
about how you write your code (one part of learning to write C code
properly!) and if you are willing to spend more effort than the average
idiot programmer and take some damned pride in your code, then C can
work most excellently for you.  Note that C++ is in the same boat here,
though there is a most excellent reason for preferring C:  It's ABI is a
de facto standard on almost any platform where there is a choice of
compiled languages.  It is pretty easy to call into a C library from
other languages.  C++, not so much.

One thing you should probably think about to, is code reuse and code
longevity.  While C code that you write may initially start out to be
less robust, you'll likely reuse it often if it is correctly factored,
and over time it'll become both more robust and more efficient than any
other implementation would be.

> In terms of performance, the list above should be in order of fastest to 
> slowest.  Also, my personal experience with Java applications indicates 
> they tend to be slower than native applications.

Correct, as is the case with C#.  However, a long time ago (I'm sorry,
again I don't have the link handy, but it's on my blog somewhere) I did
a comparison between C# and C as compiled by GCC.  I was surprised to
find that Mono runs some functions just as fast as GCC's compiled code,
after the JIT was finished with them anyway.  However, they did consume
a great deal more memory, and that means that you would not want to
write C# applications if you expect users to have older computers and
run them.  After all, it is another managed code system and you don't
really expect someone with a system with 128 MB of RAM to be running all
that and a bag of chips, do you?

Java is slower to JIT functions because the JVM wants to only JIT
compile "hot spots" in the code.  The CLR, however (at least every JIT
implementation of it that I am aware of) will JIT a method the first
time it is encountered, and then it's just a matter of a invoking the
compiled method on subsequent invocations of it.

> I want my language to protect the programmer from bugs like memory leaks 
> and pointer errors.  That knocks out C++.  Both Java and C# are resistant 
> to those types of errors and have automatic garbage collection as far as I 
> know.  Remaining candidates:
>       C#, Java

Note that no programming language---that is right, I said "no", as in
"none", "zero", "nil"---can protect you from memory leaks.  And for that
matter, C# and Java make it absolutely possible for you to get your
hands on native pointers and start scrawling all about your program's
memory.  These are things that we use memory management units for.  And
let me tell you, memory management and access control has come a long
way.  It does sometimes get in the way of things; secure memory
management can make it difficult for JIT runtimes to properly work, for
example.  Systems that force secure memory access are extremely
difficult if not impossible to get a functioning JIT on, since on such
systems executable code pages cannot be written to except by the
operating system, and pages that are to be written to by applications
can never be made executable.

With proper programming practices, knowledge, and just a bit of
discipline, it's relatively easy to write code in C without blasting
your leg off with a shotgun.  You just have to know how to do it.

> In terms of being proprietary, both C# and Java are - in that their syntax 
> and features are controlled by corporations.  See post #11 in the following 
> thread:
> 
> http://bytes.com/topic/c-sharp/answers/249140-c-proprietary-programming-language
> 
> C# is documented and specified in international EMCA standards.  I'm not 
> sure whether anything similar exists for Java.

Not to my knowledge; the Java standard is the JVM provided by Oracle.
It is a de facto standard.

> I want my language to be cross platform.  Java is well known for 
> this.  However, through the Mono project, as well as possibly others, it 
> appears that C# is very cross platform as well.  I believe the situation 
> has been improving recently.  A Google search on C# cross platform yields 
> 948,000 results.  Also, the following link on the Mono site lists 20+ 
> applications that have been written in Mono.
> 
> http://mono-project.com/Screenshots
> 
> Finally, I want my language to be able to produce self contained free 
> standing applications.  As far as I know, this knocks out Java.

It still sounds to me like you're talking about C!  ;-)

> So, overall, I don't think I was so short sited after all. 8-)
> 
> PS# 1 - I was thinking about learning Java, before the Oracle debacle.
> PS# 2 - I did produce my Hello World app in a fully Linux environment.
> PS# 3 - The /ect/sudoers file, for example, uses the # symbol as a comment, 
> not a NOT.

Don't stop at a single programming language.  That has to be my most
important piece of advice.  Programmers are _programmers_.  A good
programmer can, after having learned two or three languages, pick up
other languages (perhaps with the exception of insane languages, such as
LISP and other so-called "functional" languages) with relative ease.  If
you learn C fluently, you gain the ability to easily pick up and run
with C++, C#, Java, Vala, and other languages that are in that family.
If you learn C and GObject, you will likely manage your resources better
and maybe even better understand the limitations and practical
applications of the type systems that you use in whatever language you
are working in.

You'll also want to think about this statement:  You want to write your
code *into* a language, not *in* it.  I cannot remember which one of the
books I've read that had that statement in it, but it was a real eye
opener for me.  I think it was one of the books on the "pragmatic
bookshelf".  Programming into a language means that you write the best
code to handle your situation, emulating any functionality that you need
if it's not available.

For example, in C, you can get a pointer at runtime to an array of
objects.  You can resize that array, growing or shrinking it as
necessary.  If you do that frequently, you'll eventually write code in
an language where this is not something you can easily do.  What do you
do?  See if someone has a class that wraps what you're after and use
that, and if not, write one.  Basically, the more languages you know,
the more programming idioms you will pick up from different
environments, and the larger your programmer's toolbox will be.

Boy, I've done it again with the long email.  And I'm quickly fading, so
I think that this is my last one for the night.  Night all.

	--- Mike