In the interest of disclosure, I have to admit that I went up to about
Day 5 in TYR a few months ago before being pulled away by a variety of
distractions. So Day 1 & 2 were'nt much of a surprise. Of course
there was the usual Hello World sample. I don't remember exactly where
this example originated, but I think it is pretty amusing that it is
the canonical first example to be used when learning new languages. As
if all the years of labor and innovation that went into programming
languages were just for the purpose of finding unique ways to force the
computer to acknowledge our existence. Really the only useful indicator
to come out of the Hello World example is that if a language's Hello
World program takes more than a few lines to explain and to write, you
probably should not use that language for anything involving text.
That rant aside, mostly I am looking for differences from what I am
used to, in this case C#, Java and to a lesser extent C. From a very
high level viewpoint, Ruby is not strongly typed, and it is
interpreted, not compiled. These are some big obvious language design
differences from C# and Java. Ruby is however object-oriented, so it is
not totally different from C# and Java. From an abstract prespective
this is all interesting and the arguments over strong vs. loose typing
or interpreted vs. compiled are usually loud, contentious and
never-ending. I don't expect to solve these arguments or add more fuel
to the fire; rather I am just interested to see what the practical or
pragmattic implications of these differences are. After only 2
chapters, that is hard to tell.
In the next week or so, I'm going to start up with Teach Yourself Ruby in 21 Days, so I'll be posting on anything interesting that comes out of that.
Otherwise, I thought I'd put out links to some "contrary" posts I've
been reading over recently. When discussing software development or any
technology it is an under appreciated talent to be able to get the
reader to pay attention. Most of us who read lots of technical things
will skim over about 80 to 90% of any given thread and concentrate only
on the small percentage that we see relevant to us at that time. This
occurs for 2 reasons:
- We're lazy
- Technical writers are boring
Now, lazy is a dangerous word. People tend to associate laziness
with shoddy work, a lack of moral fiber, and/or a tendency to dress in
ill fitted clothing. In the context of software development, laziness
certainly does not mean shoddy work; developers tend to be notoriously
picky and perfectionist when it comes to their work. As far as moral
fiber and fashion sense, those vary across the developer population
like any other group.
What developers mean by lazy is that when we're solving a technology
problem, we hate to do anything ourselves that has already been done
better by somebody else. For learning purposes it is ok to reimplement,
but for problem solving purposes it is a waste of time and mental
energy. Hence being a "lazy" developer is a good thing. Being a lazy
developer also means that when we're reading about technology, if we've
heard something before, we don't have much interest in hearing it
again, so we skim a lot.
Technical writers being boring is a not a universal truth. There are
certainly some interesting writers out there, but many technical
writers were chosen (or self selected) to write about technology
because they are good at it. Being good wtih technology does not
translate directly to writing well. So developers will often skip much
of the prose in an article and go straight to the technical details.
So why does this matter? Who cares if the articles, books or posts
are not flowing prose? Well, it is likely your brain does for one. From
a pragmatic perspective, we are more prone to absorb knowledge if it is
presented to us in a format that stimulates our brains and demands our
attention. It isn't that you can't learn anything from a dry text, you
can probably just learn more from one that grabs your attention. This
is the theory behind the O'Reilly Head First
books, which present a variety of technical topics in a book format
that includes pictures, diagrams, cartoons and inventive layouts. They
are well worth checking out to see if they fit your style.
Beyond pictures and layout, a good technical writer can draw a
reader in with simple rhetorical technique of being contrary. For
example,ASP.NET: Remote Scripting, Yes! AJAX, "NOT!" Or check out anything written by Paul Graham.
Both make bold and declaritive statements that go against the grain to
draw the reader in, then deliver valuable insights once they've got
your attention. Of course the danger in being contrary is that you
better be able to back up what you say. Because the other common trait
in programmers is that they will pounce on anyone who's all talk and no
substance. So use this technique at your own risk.
Well, it's time to get the ball rolling on this blog
so here goes. After spending way too much of my free time implementing
the A* pathfinding for our latest tech challenge competition, I have
some time for posting. Currently I am travelling for a project, so it
gives me some extra time on my own to check out some different
technologies. Besides whatever in the world of .NET happens to catch my
eye, I plan to start blogging on Ruby, a language that is object
oriented, but otherwise much different than C#, Java, etc.
What attracted me initially to Ruby was the
great community around it, so I'll start by pointing to
Why's (Poignant) Guide To Ruby.
Even if you have no interest in Ruby, it is worth looking at for the
pure bizareness of it all. Currently the hot topic in Ruby is
Ruby on Rails.
Rails boasts of quick development turn around, almost no configuration
files and a low barrier to entry. As I get into it, I will share my
reactions.