[ale] On Programming and Programming Langauges

[Pat Regan]

I'm not going to even manage to respond to everything I'd want to in
here.  Hopefully I don't miss anything you feels is imporant, Michael!

On Fri, 17 Sep 2010 11:07:28 -0400
"Michael B. Trausch" <mike at trausch.us> wrote:

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

I don't entirely disagree but I don't know that "easy" is the correct
level of difficulty.  It is very easy to nearly instantly become fluent
in one C-like language if you know another.  C is a very restrictive
language and many of its relatives are as well.

If you right Perl (or, like I do, lisp!) the same way you write C you
are doing it wrong.  You're probably failing to take advantage of the
syntactic sugar the language makes available.  If you come from C
you're probably going to write a for loop when a map or grep would be
much cleaner and more readable.

If you write your lisp like I do by trying to wedge your C style code
into those parens you're writing very ugly and very inefficient code :)

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

C is absolutely not object oriented.  Using an object oriented library
may be helpful but it is absolutely not the same thing.

Syntactic sugar makes things easier to write and easier to read.  The
example gobject code on the gobject wikipedia page looks horrid :)

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

Something like the core of Gnome should absolutely be written in a fast
lower level language.  It uses CPU cycles all day, every day on
millions of machines.  That doesn't mean something like Tomboy notes
shouldn't be written in C# (ignoring the fact that Tomboy/mono has some
sort of bug that causes a stupid number of wakeups per second).  

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

I don't think you were wrong.  There are advantages and disadvantages
on both sides of that fence.  If you are going to be writing unit tests
anyway (and you should be :p) then the type safety just becomes a
hindrance.

C's typing means that I am constantly, and long windedly, manually
casting and converting things when other languages get it right for me
more than 99% of the time.  I might care that something is a number but
I very rarely care how large the number is...

I don't want to have to repeat myself.  I don't want to ever have to
write nearly identical methods to handle multiple numeric types.  I
don't want to have to know that one function returns an 8 bit unsigned
int and another returned a 32 bit signed int.  I had to care about this
stuff 10, 15, 20 years ago.  Why do I care today?  

I can complain about PHP all day long, though.

> Sorry, I digress a lot.

No problem!

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

I think this right here is the heart of the whole matter.  I think this
all depends on what sort of code you are writing and what sort of
applications you are going to be writing.

I'm under the impression that is is possible to get through college
with a degree in information systems without ever learning how to
implement a linked list.  If anyone actually reads this can you confirm
that this is true?

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

The bulk of PHP code scares the bejeebies out of me.  I'm amazed that
the PHP crowd hasn't been pushing template systems and a reasonable DB
layer for at least the last 5-10 years.  I don't understand why someone
today would be building SQL statements with string concatenation
instead of using a DB library that supports placeholders.

> 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

We should be familiar with assembly language for which processor? :)

> 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

Writing C is quite expensive.  It isn't expressive at all.  You have to
write more lines of code in C than in any modern language.  

The extra verbosity increases the time to write the code and makes it
harder to debug.  That alone is a problem but with C you are probably
introducing whole new classes of bugs related to memory management.

Does anyone enjoy the time it takes tracking down memory leaks in C? :p

> 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'd argue that even maintaining one's own code from 5 years ago is an
effort, no matter what the language.

> 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

Yes!  So why use a language that is prone to memory leaks and pointer
related bugs in the first place? :)

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

My editor and compiler both find mismatched braces.  Why should anyone
need to write their own library code to help them manage their own
memory when there are oodles of languages more modern than C that do
this for you.  If speed is the biggest reason, it doesn't affect most
of us most of the time (for very high levels of "most").

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

I do enjoy talking!

Pat