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

[Ron Frazier]

Michael,

Your posts are always quite informative.  See comments below.

Ron

At 9/20/2010 01:00 AM -0400, Michael Trausch wrote:
>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.

You're right.  I really like the idea of generalizing concepts across 
languages and platforms and / or adapting to get around the limitations of 
the language or platform.

> > 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

Thanks for this tip.  Looking it up and bookmarking it now.

> > 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

Thanks for the link.  Looking it up and saving it now.  No way I can digest 
all this new info at this moment.

>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.

These are all good points.  I hate it when that type of error 
happens.  There were one or two times in the past when I was trying to do 
something in the code, and I knew the syntax was right, but it wouldn't 
work.  I don't remember the details now, but I don't think I ever got a 
fix.  I had to rewrite the algorithm with different commands, just to get 
it to work.  Very frustrating!  I can see how having more layers in the 
stack would make troubleshooting more difficult.

>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.

These are also good points.  Hopefully, someday I'll be a multilingual 
computer language programmer.  That way, I could use different languages 
each to it's advantage and maybe link in modules of different kinds when 
needed.

This is another way where my feeling is that the new way is not the best 
way, from my just knowledgeable enough to be dangerous point of view.  It 
seems to me that we need a unified, standardized, cross platform, modern 
(with all the neat features we've been discussing), open, non patented, 
expressive, powerful language.  Kind of like Java was supposed to be.  And, 
that language should go through a HAL / compiler / linker / whatever and be 
translated to native machine code on each platform, not interpreted, and 
not bytecode.  Everything that would interfere with cross platform usage 
should be covered in the spec, like little and big endian notation, data 
formats, 32 / 64 / 128 (later) bit conversions, GUI variables, etc, 
etc.  That way, you get rapid application development, logical robust 
scalable software architecture, modern bells and whistles, extensibility, 
freedom, true reliable cross platform capability, and blazing fast machine 
code performance.  We'll name the language "U" for ultimate.

Why don't you, I, and 2 or 3 other people design that tomorrow and the next 
day.  We'll debug on Thursday, and publish on Friday. 8-)

> > 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


--------------------------
(PS - If you email me and don't get a quick response, you might want to 
call on the phone.  I get about 300 emails per day from alternate energy 
mailing lists and such.  I don't always see new messages very quickly.)

Ron Frazier

770-205-9422 (O)   Leave a message.
linuxdude AT c3energy.com