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

[Michael Trausch]

On Mon, Sep 20, 2010 at 12:06 AM, Tim Watts <tim at cliftonfarm.org> wrote:
> Ron, I hope you're not expecting to be an expert in all of those areas
> in a year's time. Maybe I'm just a slug but if it were me I'd give
> myself 3-5 years. That's a big chunk o' cheese. If you're coming from a
> strong procedural programming background, just making object orientation
> click can take a while -- maybe 3 or 4 projects before the light really
> goes on (all those simple Shape/Circle/Square examples aren't much help
> once you're facing a real world design problem).

I think that it is also quite key to recall that most of these
concepts are just that---concepts.  They are things that can be
implemented in any language.  Object-oriented code is certainly
impossible in many very old programming langauges, particularly those
that lack support for record (structure) types and functions.  For
example, it is almost impossible to write a program using the
object-oriented methodology in very old versions of the BASIC
programming language; however, in the QuickBASIC programming language,
which let you define your own functions and data types, easily allows
you to implement an object-oriented design without any language
support dedicated to object-orientedness.  Also, if you had a library
similar in purpose to GNU Pth, but ported to 16-bit DOS, you could
have a multithreaded (technically, multi-fibered) application written
in QuickBASIC.

If you can get past the notion that you need support from a
programming language to implement something, you gain a great deal in
the amount of power that you wield to make things happen.

> Once you (re)gain your basic programming bearings, I'd also like to
> suggest getting involved with a good quality open source project that
> interests you. Get on their mailing list. Look at their bug list and
> submit some patches with unit tests. It can provide you with good brain
> exposure. Plus it's good for the project, good for open source and good
> for your resume.

I'll echo this.  Just try to start with the smaller things, and work
your way up.  GNOME has a project called "GnomeLove" which aims to
help people who want to get started contributing to GNOME.  They
identify "simple" thing that are suited for people who aren't familiar
with the GNOME project.  Many of those things take little to no
"hard-core" programming experience, but many of them are in C, and
object-oriented C (using GObject).  It can be found on the Internet,
of course: http://live.gnome.org/GnomeLove

> My sense is that you don't just want to be a programmer. A programmer
> takes a specification and implements it in code. Whereas a software
> engineer may handle everything from articulating a problem to designing
> a solution to evaluating implementation techniques. In truth, all
> programmers are, to varying degrees, software engineers. But it's easy
> to get caught up in the details of learning "good implementation"
> without ever stepping back to learn the elements of "good design". Both
> are necessary. So along that line you might want to read a book or two
> by Martin Fowler.

I think that very few programmers are "just" programmers, along the
same lines that very few system administrators are "just" system
administrators.  I have met some people who very much do not step out
of their domain, or even grow to learn their self-claimed domain to
their full potential, of course, but I don't think that many of those
types would be on this list.  If there are, I certainly haven't met
them yet.

Fowler is some excellent reading; I'd also suggest many of the items
in the Pragmatic Programmer's series, which cover lots of things and
are written in a manner which encourages you to think about what you
have read.  You can see the Pragmatic Bookshelf at
http://pragprog.com/categories

Also, and I can *not* stress this enough, know the stack which you're
working on.  As any programmer from any decade knows, you cannot write
software with only the view of the façade (API definitions and the
language itself).  Any time you work on a non-trivial program, you
will have problems.  While it is true that 90%+ of the time, the
problem will be with your own code, and not part of the operating
system or compiler or runtime library or virtual machine, you need to
be able to know what the correct behavior is supposed to be and you
need to be able to find out where in your stack something is broken,
if it does break (either on your development and testing machines or
in a production environment).  This is, of course, one argument
*against* systems like the CLR: not only do you have to know what C#
says you can and can not do, and not only do you have to know what
your runtime class library promises you it will do (and do
correctly!), but there will come a time when you'll need to see why
something that looks correct according to spec isn't behaving
correctly.  And the problem could be:

  - The compiler err'd in correctly compiling code.  Quite rare, but
not impossible.

  - There is a bug in the VM.  More likely, but still quite rare.

  - There is a bug in the class library.  Much more likely, since the
class library is the major component that will make assumptions about
the interface between your application and the operating system; for
example, if you call an API that is supposed to get stats on a file in
the filesystem, which itself calls into a native-code library to get
that information, and the native-code library (say, the system C
library) behaves in a way that is different from the class library's
expectation, you can have a problem.  With standardized interfaces
this isn't a frequent problem, but it can happen.

If you are working with a simple environment, such as C, then a lot of
this goes away.  C compilers are extremely well-tested---consider the
version of GCC that ships with a given release of Debian or Ubuntu.
Most of the system is written in C, including the kernel.  There are
versions of GCC that cannot compile the entire distribution, and
recently, GCC starting using the whole of Debian to test the compiler
for releases.  I don't know if they do that for every release or not,
but if GCC can compile all of Debian, I'd call that a pretty good
test.  That is not to say that GCC is free of bugs, but it is very
stable.  I don't know about you or anyone else on the list, but I
place a great deal more trust in GCC than I do, say, the Mono C#
compiler.  (I'm not saying that I distrust the Mono C# compiler,
either; merely that it is nowhere near as well-tested as GCC is.)

Also as with anything else, anywhere else, complexity is something to
think about.  The more complex a system, the more parts that there are
in it, the more likely it is to fail simply because of the complexity.
 The more complex it is, the harder it is going to be to troubleshoot
as well.  And the less likely it is that a single person will be able
to understand it all, or even a single team.

One reason that I have, even after learning "modern" languages, gone
back to writing a lot of things in C is that the environment that you
have when you're working in C is _simple_.  If I can write a simple
program using nothing but the C library and a C99 compiler, and it is
something that I am going to use time and time again, then I am
_absolutely_ going to write the program that way.  That way I know
that when my program is correct, and the things that my program
depends on are correct, the output will be correct (failing a hardware
error, of course).  I could very likely write the same program in C#,
Java, or whatever other language, but then I would have to have a lot
more to worry about in terms of being 100% certain that my program
behaved the same.  What if a different version of the VM is installed?
 What if a different version of the interpreter is installed?
Incompatibilities can (even if unintended) occur even in point
releases of runtime systems, virtual machines, and interpreters.  But
if you're using a known-good version of GCC on your system and pushing
the compiled binaries elsewhere, and you've vetted everything in the
environment, you can be as sure as you can be that it is all going to
work correctly.  This is something that I've come to appreciate quite
a bit.

> Finally, this bit of wisdom has helped me numerous times along the way:
> "When your only tool is a hammer, all problems look like nails."

Indeed.

   - Mike