Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/04/06/meme-hustler.html

All this past week, people have been emailing and/or pinging me on IRC to
tell me to read the
article, The Meme Hustler by Evgeny Morozov. The
article is quite long, and while my day-job duties left me TL;DR’ing it
for most of the week, I’ve now read it, and I understand why everyone
kept sending me the article. I encourage you not to TL;DR it any longer
yourself.

Morozov centers his criticisms on Tim O’Reilly, but that’s not all the
article is about. I spend my days walking the Free Software beat as a
(self-admitted) unelected politician, and I’ve encounter many spin doctors,
including O’Reilly — most of whom wear the trappings of advocates for
software freedom. As Morozov points out, O’Reilly isn’t the only one; he’s
just the best at it. Morozov’s analysis of O’Reilly can help us understand
these P.T. Barnum‘s
in our midst.

In 2001, I
co-wrote Freedom
or Power? with RMS in response to O’Reilly’s
very Randian arguments
(which Morozov discusses). I remember working on that essay for
(literally) days with RMS, in-person at the FSF offices (and at his office
at MIT), while he would (again, literally) dance around the room, deep in
thought, and then run back to the screen where I was writing to suggest a
new idea or phrase to add. We both found it was really difficult to craft
the right rhetoric to refute O’Reilly’s points. (BTW, most people don’t
know that there were two versions of my and RMS’ essay; the original one
was published as a
direct
response to O’Reilly on his own website. One of the reasons RMS and I
redrafted as a stand-alone piece was that we saw our original published
response actually served to increase uptake of O’Reilly’s
position. We decided the issue was important enough it needed a piece that
would stand on its own indefinitely to defend that key position.)

Meanwhile, I find it difficult to express more than a decade later how
turbulent that time was for hard-core Free Software advocates, and how
concerted the marketing campaign against us was. While we were in the
middle of the Microsoft’s attacks that GPL was an unAmerican cancer, we
also had O’Reilly’s the freedom that matters is the freedom to pick
one’s own license meme propagating fast. There were dirty politics
afoot at the time, too: this all occurred during the same three-month
period
when Eric
Raymond called me an inmate taking over the asylum. In other words,
the spin doctors were attacking software freedom advocates
from every side! Morozov’s article captures a bit of what
it feels like to be on the wrong side of a concerted, organized PR campaign
to manipulate public opinion.

However, I suppose what I like most about Morozov’s article is it’s the
first time I’ve seen discussed publicly and coherently a rhetorical trick
that spin doctors use. Notice when you listen to a pundit at their undue
sense of urgency; they invariably act as if what’s happening now is somehow
(to use a phrase the pundits love): “game changing”. What I
typically see is such folks use urgency as a reason to make compromises
quickly. Of course, the real goal is a get-rich-(or-famous)-quick scheme
for themselves — not a greater cause. The sense of urgency leaves
many people feeling that if they don’t follow the meme, they’ll be left in
the dust. A colleague of mine once described this entrancing effect as
dream-like, and that desire to stay asleep and keep dreaming is what
lets the hustlers keep us under their spell.

I’ve admittedly spent more time than I’d like refuting these spin doctors
(or, as Morozov also calls them, meme hustlers). Such work seems
unfortunately necessary because Free Software is in an important, multi-decade (but
admittedly not urgent 🙂 battle of cooption (which, BTW, every
social justice movement throughout history has faced). The tide of
cooption by spin doctors can be stemmed only with constant vigilance, so I
practice it.

Still, this all seems a cold, academic way to talk about the phenomenon.
For these calculating Frank Luntz types, winning is enough;
rhetoric, to them, is almost an end in itself (which I guess one might dub
“Cicero 2.0”). For those of us who believe in the cause, the
“game for the game’s sake” remains distasteful because there
are real principles at stake for us. Meanwhile, the most talented of these
meme hustlers know well that what’s a game to them
matters emotionally to us, so they use our genuine concern against
us at every turn. And, to make it worse, there’s more of them out there
than most people realize — usually carefully donning the trappings of
allies. Kudos to Morozov for reminding us how many of these emperors have
no clothes.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html

In 1991, I’d just gotten my first real programming job for two reasons:
nepotism, and a willingness to write code for $12/hour. I was working
as a contractor to a blood testing laboratory, where the main
development job was writing custom software to handle, process, and do
statistical calculations on blood testing results, primarily for
paternity testing.

My father had been a software developer since the early 1970s, and worked
as a contractor at this blood lab since the late 1970s. As the calendar
had marched toward the early 1990s, technology cruft had collected. The
old TI mainframe, once the primary computer, now only had one job left:
statistical calculation for paternity testing, written in TI’s Pascal.
Slowly but surely, the other software had been rewritten and moved to an
AT&T 3B2/600 running Unix System VR3.2.3. That latter machine was the
first access I had to a real computer, and certainly the first time I had
access to Usenet. This changed my life.

Ironically, even on that 3B2, the accounting system software was written
in COBOL. This seemed like “more cruft” to me, but fortunately
there was a third-party vendor who handled that software, so I didn’t have
to program in COBOL.

I had the good fortune, actually, to help with the interesting problems,
which included grokking data from a blood testing machine that dumped a
bunch of data in some weird reporting format onto its RS-232 port at the
end of every testing cycle. We had to pull the data of that RS-232
interface and load the data in the database. Perl, since it treated
regular expressions as first-class citizens, and had all the Unix block
device fundamentals baked in as native (for the RS-232 I/O), was the
obvious choice.

After that project, I was intrigued by this programming language that had
made the job so easy. My father gave me a copy of the Camel book —
which was, at that point, almost hot off the presses. I read it over a
weekend and I decided that I didn’t really want to program in any other
language again. Perl was just 4 years old then; it was a young language
— Perl 4 had just been released. I started trying to embed Perl into
our database system, but it wasn’t designed for embedding into other
systems as a scripting language. So, I ended up using Tcl instead for the big
project of rewriting the statical calculation software to replace the TI
mainframe. After a year or two writing tens of thousands of lines of Tcl,
I was even more convinced that I’d rather be writing in Perl. When
Perl 5 was released, I switched back to Perl and never really looked
back.

Perl ultimately became my first Free Software community. I lurked on
perl5-porters for years, almost always a bit too timid to post, or ever
send in a patch. But, as I finished my college degree and went to graduate
school, I focused my
thesis work on Perl and virtual machines. I went to the Perl
conference every year. I was even in the room for the perl5-porters
meeting the day
after Jon
Orwant’s staged tantrum, which was the catalyst for the Perl 6
effort. I wrote more than a few RFC’s during
the Perl 6 specification
process. And, to this day, even though I’ve since
done plenty of Python
development, too, when I need to program to do something, I open an Emacs
buffer and start typing #!/usr/bin/perl.

Meanwhile, I never did learn COBOL. But, I was amazed to hear that
multiple folks who graduated with me eventually got jobs at a health
insurance company. The company trained them in COBOL, so that they could
maintain COBOL systems all day. Everyone once in a while, I idly search a
job site for COBOL. Today, that search is returning 2,338 open jobs. Most
developers never hear about it, of course. It’s far from the exciting new
technology, but it’s there, it’s needed and it’s obviously useful to
someone. Indeed, the COBOL standard was just updated 10 years ago, in
2002!

I notice these days, though, that when I mentioned having done a lot of
Perl development in my life, the average Javascript, Python, or Haskell
developer looks at me like I looked at my dad when he told me that
accounting system was written in COBOL. I’d bet they’d have my same
sigh of relief when told that “someone else” maintains that
code and they won’t have to bother with it.

Yet, I still know people heavily immersed in the Perl community. Indeed,
there is a very active Perl community out there, just like there’s an
active COBOL community. I’m not active in Perl like I once was, but it’s a
community of people, who write new code and maintain old code in Perl, and
that has value. More importantly, though, (and unlike COBOL), Perl was
born on Usenet, and was released as Free Software from the day of its first
release, twenty-five years ago today. Perl was born as part of Free
Software culture, and it lives on.

So, I get it now. I once scoffed at the idea that anyone would write
in COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even
today, are surely good programmers — doing useful things for their
jobs. The same is true of Perl these days: maybe Perl is finally
getting a bit old fashioned — but there are good developers, still
doing useful things with Perl. Perl is becoming Free Software’s COBOL:
an aging language that still has value.

Perl turns 25
years old today. COBOL was 25 years old in 1984, right at the time
when I first started programming. To those young people who start
programming today: I hope you’ll learn from my mistake. Don’t scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don’t judge them because you don’t like their favorite
language.

Update (2013-04-12):
I posted
a comment on Allison Randal’s blog about similar issues of Perl’s
popularity.