Report Offensive Message

Here it is, Friday morning. Every Thursday evening now, I attend T3H
meetings. I get together with some friends that have some similar
interests, and we . . . learn stuff. It is, so far, sort of a
programming study group, with the primary goal of helping its members
learn stuff. I put it together in the first place (yes, I'm the person
who organized it) from members of a local LUG as an excuse to create an
environment where I wasn't learning new programming skills alone and in
a vacuum. I wanted more people to play off of, in person, where we'd be
there specifically to help each other with new concepts and new
implementations.

It all started with Objective-C, but as of last night that has
changed. The group member who knows the most about the language was
running into a wall, in part because of a lack of the necessary skills
to be leading the charge alone and in part because he doesn't actually
know the syntax of the language well enough to be teaching it. As such,
the whole group hashed out the needs, wants, and skills of the group as
a whole. From this, we developed a new, more useful plan for the future.

This, of course, perfectly suits one of the first rules of good
software design: plan to throw the first one away, for any given value
of "one".

So, Objective-C is on the back burner (for those of us who plan to
ever revisit it). We're going in new directions. The new directions, in
this case, number three, with three different languages that we'll be
studying as a group, simultaneously.

Basically, we're going to be attacking essential concepts of
programming, in each case first in theory (by discussing the concepts),
then in usage and implementation (by discussing how they're used and,
possibly, by working up pseudocode), and finally in practice (by using
the three example languages we've chosen to give these concepts useful
form). Yes, three languages.

See, there are three different basic types of languages that we have
decided we need to learn in order to get the full run of important
theories of program design. Each of us knows at least one programming
language (and by "programming language", I mean "turing complete
language", and by "knows", I mean "has at least a functional familiarity with"), and the number of languages known with any real facility
varies between us from "one" to "half a dozen or more", but nobody has
as complete a knowledge of all three of these types of programming
language methodologies as we'd like. The three types are procedural,
functional, and object-oriented*.

The representatives of each language type are C for procedural
programming, Scheme for functional programming, and Ruby for
object-oriented programming. In addition to procedural, functional, and
object-oriented programming methodologies, however, these languages
also represent a second trinity, this time of programming aesthetics,
though this aspect of the reasons to choose the languages went largely
unremarked: the "shiny new thing", the "obscure, eccentric genius", and
the "venerable workhorse".

In Ruby, everything is an object; it is a "true", or "pure",
object-oriented language. It's the useful scripting language child of
Smalltalk and Perl, in essence. It has a reputation for power,
flexibility, rapid development, intuitive ease of learning and use, and
a whole bunch of other wonderful (if improbable, by some measures)
characteristics. It's an example of a "shiny new thing" language, as
well, fitting it into the trinity of programming aesthetics.

In Scheme, everything (or at least nearly everything) is a function.
I'm less familiar with what makes Scheme what it is than I am with
Ruby, though from what I understand it is about as close to a "true" or
"pure" functional language as you're going to get without resorting to
simply writing programs in Lambda calculus (which would be akin to
trying to communicate using English without nouns). Scheme is one of
the Lisp family of languages, which as a whole comprises one of the
canonical examples of the "obscure, eccentric genius" programming
aesthetic. In fact, the two primary approaches to Lisp seem to be
embodied in Common Lisp (a large, sprawling language) and Scheme (a
more succinct, terse language that grew from the same base). Granted, I
could be mistaken. This will be my first-ever foray into the land of
Lisp and its imitators.

Finally, of course, there's C. C is the procedural representative,
though it is not the most "true" or "pure" procedural language out
there. It is, however, procedural enough to get the point across by a
fairly wide margin, and it's a language that every serious code hacker
should know. Period. It's the language to which all modern languages
owe their compilers and interpreters, most of them owe their syntax,
and all owe their running environments. It's the language in which
operating systems are written, because you don't want to do everything
in kernel development with automatic garbage collection or object
oriented design. It's the only language developed specifically because
a high-level tool for operating system design didn't already exist. It
is, truly, the practical, pragmatic, ubiquitous, venerable old
workhorse of programming languages. Unix and C are each the other's
mother, in a strange sort of incestuous, mutually procreative,
synchrogenetic relationship. It's going to be the example language
representing procedural programming, and that's that.

Conveniently enough, most of what makes Objective-C what it is will
be covered by these languages ? particularly, C and Ruby. Objective-C
is a true superset of C, unlike that OOP (object-oriented programming)
kluge C++, which means that if you learn all of C you'll know all of
Objective-C except the OOP structure. Ruby gets its OOP structure ? its
OOP semantic elements ? from Smalltalk, which is precisely the source
of Objective-C's OOP structures. Between C and Ruby, then, Objective-C
will be only a step away. Well, good.

I've lucked out. I get to learn Ruby and Scheme from the ground up,
and I frankly haven't done much with C either. I get to learn a whole
lot of stuff here. For the small price to pay of organizing and
coordinating all this, I get to learn everything without having to
shoulder the responsibility of contributing superior expertise. I get
to go back to just being a student again. Because I have experience
with other languages (like PHP, Perl, and Object Pascal, for instance),
and because I enjoy reading books about programming theory**, I also
have free reign to comment and rattle on and not be perceived as a
prejudicial idiot. This should be great fun.

Did I mention that I get to learn? That's such a barrel of fun that
I don't know what to do with myself. Happy times are ahead.


* = Objectional? Hah. That's funny.

** = I quite strongly recommend both Eric Raymond's The Art Of
Unix Programming and The Pragmatic Programmer by Andrew Hunt
and David Thomas. They're thoroughly excellent books on programming
theory.