[ale] On Programming and Programming Langauges

[Justin Simms]

Mike,

Thanks for this post! There is nothing more fulfilling than reading an excellent
summary of the strengths of learning C. I agree with you fully. I do,
however, wish that
more developers would be able to see that all programming languages
add to understanding the whole
of software engineering. Dynamic languages, strongly typed languages,
etc..... Once we can step
outside of the comfort zone of our "learned" language, we can then
truly advance ourselves as engineers
and forward thinkers. At least that is my take on things.

Justin

On Fri, Sep 17, 2010 at 11:07 AM, Michael B. Trausch <mike at trausch.us> wrote:
> Given the C# thread and the volumes of comments that I have there---both
> addressed and not, because of space---I thought I'd go ahead and just
> send an email out with all my thoughts.  Whether or not this turns into
> a thread that anyone has any interest in.  I do not expect that most
> will care to read this, it's _quite_ long.  Oh, well.  Take the rambling
> for what it is (or is not) worth.  :-)
>
> There are, of course, _many_ languages out there.  And there are a lot
> of people out there looking to hire for projects in language X which
> have insane requirements like "five years experience in X", which is,
> frankly, _stupid_.  It shows that management and HR types really know
> next to nothing when it comes to the world of programming, and a lot of
> programmers buy into that knowledge of nothing.  Moving on, though...
>
> If you are a _programmer_ (regardless of what other hats you might wear,
> such as system administrator) then you hold a lot of programming
> knowledge that is independent of the implementation language.  For
> example, you know algorithms, and you know where to look them up for the
> ones that you've never used, and you're familiar with the costs and
> benefits of them.  You know how to craft a hand-written parser for
> simple to moderately complex data types.  You know that you have
> metaprogramming tools available to you.  You know that a compiler isn't
> some special magical black box, but yet another tool in the process of
> translation, which is something that all programs ultimately wind up
> doing (translating data from one form to another).  You are also fluent
> in multiple _programming environments_.  And you are able to "program
> into" them.  More on this in a minute.
>
> It's easy to be fluent in a language.  Seriously.  It's more difficult
> to be fluent with the entire standard library for a language, though,
> whether that is a class library or a function library or a hybrid of
> both.
>
> Insofar as "programming into" an environment, it means that you do
> creative things with the resources that you have.  For example, I often
> see a lot of people say that "C isn't object-oriented".  Bull$#!t!  It
> _absolutely_ is.  In fact, even assembler can be object oriented, if you
> want it to be.  "Object-oriented"-ness isn't a feature of a programming
> language that is depended upon to write programs in an object-oriented
> manner.  Languages that support object-orientation natively have
> provided a convenient notation for supporting that programming model,
> and a type system that is accessible behind it, but nothing more than
> that, really.  I mentioned GObject before, and I'll mention it again:
> GObject is an object-oriented type system for C.  It is easy to write C
> programs that use it, and it even supports refcount assisted memory
> management along the lines of what you expect to see from other
> languages.  It's more difficult to write classes in GObject, but there
> are tools available which take the tedium out of that (for example, GOB
> and Vala, both of which take code as input and output C-GObject code).
>
> GNOME is written in C.  And GNOME is heavily object-oriented.  And the
> GObject type system is really an awesome, amazing work.  It does it all
> without the binary mangling problems of C++, without the managed runtime
> aspects of Python, the JVM, the CLR, or whatever, and it works well,
> given enough time and effort put into to being fluent with that
> particular programming environment.  And it is portable across POSIX
> systems and even Windows to a certain degree (because of the way Windows
> manages things like network file descriptors there can be a few caveats
> that the programmer needs to be aware of, but it's not that awful a
> situation, really).
>
> Now, there is the issue of whether or not it is useful to learn C these
> days.  It absolutely is!  C is not a dead language, by any stretch of
> the imagination.  Why do I think that?  Because there are a lot of
> things about being fluent in C that provide insight to programming
> problems in other languages.  If you can sort through the issues of
> programming language vs. type system vs. standard library in your head
> (they really are all separate things!) then you can gain the insight
> that C has to offer from a programming perspective.  There was once a
> time when it was necessary to program in C for everything.  Do I think
> that we should return to that?  Hell, no.  There are one-off things that
> I use HLLs like Python for, and I wouldn't want to write those sorts of
> things in C.  But the things that I do write in C are things that are
> not one-off programs; that is, things that I deploy in multiple
> environments.  And writing cross-platform C code, as I've mentioned
> before, isn't as difficult as a lot of people seem to think it is.
>
> I learned a lot of programming languages before I learned C.  BASIC (in
> the forms of BASICA, GW-BASIC, QuickBASIC, and Visual Basic), 6502
> assembler, some x86 assembler---the BASIC family and PHP were the ones
> that I used the most.  And honestly, I think that was detrimental to my
> way of thinking.  You see, while BASIC is a general-purpose language
> ("Beginner's All-purpose Symbolic Instruction Code", wow, I still
> remember that?), it does not expose a lot of the system's underlying
> functionality in the way that C does.  It cannot, in fact, because BASIC
> requires certain built-in statements (PRINT, INPUT, and so forth) that
> are part of the core language itself.  This coupling of the language to
> things that ought to be explicit function calls in the language's
> runtime makes it difficult to use for "all purposes".
>
> After I learned the many variants of BASIC and then PHP, I spent a fair
> amount of time avoiding C.  People told me that it was pointless to
> learn, that it was arcane, that it was a dead/dying language, that it
> was a waste of time.  And so I avoided it.  At some point, I had a
> problem, and I don't even remember what that problem was now, but it was
> a problem with a program that was written in C.  And I went looking
> through it, and because C is so bloody different from BASIC and PHP I
> was utterly confused.  Now, I'd been programming in PHP for quite some
> time at this point, and I was fully used to the ideas of weak type
> systems.  At first, I saw C's relatively strict data typing as a
> hindrance to productivity.  How wrong was I!  It's something that I wish
> PHP would implement, it would reduce bugs caused by implicit coercion
> that I see in every PHP project I am paid to work on.
>
> Sorry, I digress a lot.
>
> In any event, I had to learn C, and I was able to fix my problem.  And
> then I put it off, and I didn't write anything in it because I had no
> need to.  But as time went on, I kept coming back to learn C.  And the
> standard library, and so forth.  I learned these so that I could
> (mostly) fix problems with things I had, or at least that was my
> intention at the time.  But I found that the more that I learned C and
> the standard library and all of that, the more I could appreciate its
> simplicity and structure.  I realized that I had been thinking about
> programming all wrong!  So I started learning more about it the whole
> process.  I decided that if I'm going to continue to call myself a
> programmer, I needed to really understand what the hell was going on.
>
> So I started learning about compilers, and interpreters, in a
> lower-level-than-most sort of manner.  What happens when GCC is run over
> C code?  All of us know that if you have valid C input, you get object
> code as output, and you can link that into an executable.  How do those
> executables play nicely together?  What about for other languages, is it
> the same?  Turns out that C++ has non-standardized linkage while C has
> standardized linkage and a lot of other programming environments take
> advantage of that (too bad that PHP does not, though that is probably
> because the bulk of PHP code out there would choke and die if it did).
>
> Jumping topics again, I said in the other thread somewhere that if you
> learn C, your abilities as a programmer greatly improve.  Allow me to
> correct and clarify on this point somewhat.  There is some indescribable
> quality of knowledge that can be obtained from working at a low level.
> You get a chance to see all the things that are going on, a chance to
> understand what is _really_ happening.  When I allocate some memory in
> C, it's pretty straightforward compared to the creation of a new
> variable in Python, at least in terms of what's really happening under
> the scenes.  And if you have a problem with the Python VM, you have a
> hell of a problem debugging it because you probably (as a Python
> programmer) do not care to understand all the internals of the Python
> VM, you just want to get things done.  So now you're holding a ball that
> you will need to handle---either you find someone to give the ball to,
> and depend on them to fix it, or you start learning enough about the
> Python VM to be able to troubleshoot what's going on and fix it.  After
> all, all software has bugs.
>
> The lower-level your understanding is, though, the more that you can
> infer.  And if you know C, you can understand other C-family languages
> more easily.  I mentioned before that of this family there is C++, C#,
> and Java.  Omitting the standard libraries of each, my statement is
> factually correct.  The languages themselves have very similar rules in
> terms of syntax and type-strength.  You have nuances that are of course
> different, or they wouldn't be different languages.  But they are all
> part of the same family.  PHP, OTOH, while it looks like it is a
> C-family language at a glance, cannot be described as such.  Some of the
> syntax is similar, but it is _very_ different in terms of how you would
> write code for it, and the very simple fact that you can just $create a
> variable anywhere and it's valid even if it $creates a new $Variable
> changes the fundamental understanding that one has to have in order to
> properly scrutinize and read a program.
>
> To that end, I think that everyone should at least be familiar with what
> assembly language is, and how it works.  I don't think that everyone
> could or should program in it, because once you get "lower" than C, you
> have the problem that you are now tying yourself to a particular CPU
> family, and potentially even just typing yourself to a single CPU model.
> While that used to be something that was useful at one point in time, it
> has no payoff anymore.  You can get all the performance that you need
> from a good C compiler, and if you need to squeeze more than that, you
> can pay someone who will write hand-optimized assembler, and you'll pay
> out the nose through it (which I suppose will tell you just how much you
> probably don't need to do it, since another CPU is less expensive).
>
> But writing code in C is _not_ as expensive as people make it out to be.
> There is a *heavy* investment in learning.  *HEAVY*.  And you need to
> sit yourself down and you need to find a routine that works for you in
> terms of writing code.  There are multiple books on programming best
> practices out there that talk about how to do things like ensure that
> you're always keeping up on your memory allocations and whatnot.  And
> for the most part, it is as simple as adopting a convention and
> following it.  And if your convention is well-thought-out, you can
> probably even write a small program that will automatically enforce it
> for you.  You can use your version control system to run sanity checks
> on your code, telling you when you step out of your convention.
>
> The real expense with C and C++ code (and in fact, with nearly any other
> language that I can think of) comes not in the writing of it by a
> programmer, but in the maintenance of it by a programmer when the code
> was originally written by someone who isn't a programmer, but writes
> programs.  There's a distinction, I think.  I know many people that can
> write programs, but I would not call them a programmer.  You say
> "algorithm" to them and they say "what's that?"  You say "type system"
> to them and they again say, "what's that?"  And many of these are people
> that can put "5 years of programming in X" on their résumé!
>
> I'm not saying that "real" programmers are immune to bugs and failures
> and mistakes, but as with any field, mistakes are far less likely to
> happen if you are aware of what causes them and head them off before
> they can form.  If you have a brand new car and you don't want to get
> ketchup in the seats, don't eat in the car.  If you are a C programmer
> and you don't want to leak memory, remember to have a matching free (or
> g_free, or struct_or_object_free) call to match every malloc (or
> g_malloc, or struct_or_object_new) call.  You do this the same way that
> you match your braces, and you're good to go (for the most part).  And
> if you write library code that will be reused, and you make it easy to
> do both, chances are that it'll get done and you won't forget.
>
> In any case, I've touched on every point I wanted to touch on, for now,
> I think.  If this turns into a discussion (which I'd like very much to
> see, but it might be too long to keep anyone's interest) then cool.
>
>        --- Mike
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>