[Boulder.pm] Boulder-pm Digest, Vol 39, Issue 15

Tue Aug 28 08:40:16 PDT 2012

What's the point of version control when you just end up throwing code away?  ;-)

Or I've found a more common issue is not allowing time for the version control to take place.  Management doesn't want to hear it's going to take an extra day because of a check in and check out process.  How do you want it Good, Fast or Cheap...pick two please.  They will tell you all three, but the reality of the situation is they only care about Fast and Cheap.  Quality is job 2 in most cases.  

But I have to agree....academia and the real world are two different places.  I'm not really sure what the CS degree is attempting to produce.  It seems like the school I graduated from was attempting to shoot for software engineers rather than code monkeys, but that was over ten years ago.  No telling what they are trying to do now.  It seems that one of the biggest problems they were facing at the time is the amount of information to cram in a 4 year degree.  

Interesting LISP culture was brought up.  I used to love LISP while in school.  Lost of InSignificant Parenthesis.  ;-)  The native language in itself lent itself so well to many things.  Sure you had to adjust your mind but once you did I believe the mentality of OAOO could be achieved.  Perl in all of it's splendor and glory with it's TIMTOWTDI mentality could never achieve the eloquence of LISP.  However the two languages seems to share much in common as pointed out in Mark Dominus' "Higher Order Perl".  Maybe this is how I got linked up with Perl?

Paul Graham's cover art on his "Hackers and Painters" book is both revealing and intriguing.  The Tower of Babel.  Are we as coders/developers building towers of babel with our own code?  Will we ever be able to unite all programming languages into one great programming language? Why are there so many programming languages?  I'll have to read the book when I get a chance.  

I wish we would get some rain here.  Hot and Dry  but I guess it's preferable over Cold and Damp.  ;-)   

________________________________
 From: "boulder-pm-request at pm.org" <boulder-pm-request at pm.org>
To: boulder-pm at pm.org 
Sent: Monday, August 27, 2012 1:00 PM
Subject: Boulder-pm Digest, Vol 39, Issue 15

Send Boulder-pm mailing list submissions to
    boulder-pm at pm.org

To subscribe or unsubscribe via the World Wide Web, visit
    http://mail.pm.org/mailman/listinfo/boulder-pm
or, via email, send a message with subject or body 'help' to
    boulder-pm-request at pm.org

You can reach the person managing the list at
    boulder-pm-owner at pm.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Boulder-pm digest..."

Today's Topics:

   1. Re: Academic vs Production Code (Walter Pienciak)
   2. Re: Academic vs Production Code (Jay Hannah)
   3. Re: Academic vs Production Code (Rob Nagler)

----------------------------------------------------------------------

Message: 1
Date: Mon, 27 Aug 2012 08:50:16 -0600
From: Walter Pienciak <wpiencia at thunderdome.ieee.org>
To: boulder-pm at pm.org
Subject: Re: [Boulder.pm] Academic vs Production Code
Message-ID: <20120827145016.GA8461 at thunderdome.ieee.org>
Content-Type: text/plain; charset=iso-8859-1

On Thu, Aug 23, 2012 at 02:01:27PM -0700, Ed Dow wrote:
> Walter -- very interesting thoughts on academic vs production
> code.? In some ways it seems like it should be opposite.?
> Academia should be a place where you strive to put in long
> hours and thought into your work.? The real world, the evil
> exists, production is where after looking and pondering over
> code which will be used once and thrown away (sometimes), seems
> more like a time for minimal effort and get back to the more
> important things like drinking or theology which ever comes
> first. ? ;-) 

My thoughts on this came from observation of programmers straight
from school, and in trying to reconcile the work of admittedly
bright programmers but new to the workforce with that of seasoned
pros.

It seems to me that while in school, the focus is on the ability
to break down a complex problem into workable fragments, to learn
new algorithmic process or data structures, to become familiar
with functions and tricky uses of ... etc.

Academic code seems barebones, with the logic and working of the
program evident.  Think of the examples in most textbooks.

Production code has acknowledgment of "shit that happens."  Full
disks, data input outside expected parameters, trying to open
nonexistent files, etc.  This the realm of Rob's comments, IMO.

So that's the sense in which I use "academic" and "production"
code.

It's pouring -- POURING -- rain here in CNJ this morning.  (I'm
working at the main facility this week.)

Walter

------------------------------

Message: 2
Date: Mon, 27 Aug 2012 10:23:34 -0500
From: Jay Hannah <jay at jays.net>
To: boulder-pm at pm.org
Cc: Nebraska USA Perl Mongers of Omaha <omaha-pm at pm.org>,
    "odynug at googlegroups.com" <odynug at googlegroups.com>
Subject: Re: [Boulder.pm] Academic vs Production Code
Message-ID: <230A4888-ED55-4606-89FA-7B4E604E4621 at jays.net>
Content-Type: text/plain; charset=iso-8859-1

[From http://mail.pm.org/pipermail/boulder-pm/2012-August/001095.html]

On Aug 27, 2012, at 9:50 AM, Walter Pienciak <wpiencia at thunderdome.ieee.org> wrote:
> Academic code seems barebones, with the logic and working of the
> program evident.  Think of the examples in most textbooks.
> 
> Production code has acknowledgment of "shit that happens."  Full
> disks, data input outside expected parameters, trying to open
> nonexistent files, etc.  This the realm of Rob's comments, IMO.

-nod-  In my two rounds of being "computer science adjacent" (1993, 2010) I was amazed, both times, at how poorly CS mapped to programming computers for a living. There's a lot of conversational overlap, but academia's refusal to get "bogged down" in any particular toolset leaves students undercooked for being code monkeys. 

And 95% of computer science students don't want to be programmers...? Really? What % of CS-targeted jobs will be programming all day? 

They're still not teaching version control? (ANY version control system?) Isn't this like an art student having no concept of a paint brush?

As you can tell, I have many energetic beefs with computer related academia.  :)

jhannah
Omaha.pm
http://www.linkedin.com/in/jhannah

------------------------------

Message: 3
Date: Mon, 27 Aug 2012 11:15:04 -0600
From: Rob Nagler <nagler at bivio.biz>
To: boulder-pm at pm.org
Subject: Re: [Boulder.pm] Academic vs Production Code
Message-ID:
    <CAJB=V03PX3HDqh_27sYZeR8DUsgNvJHqEtm92CJXnkkZsrNLHA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

> They're still not teaching version control? (ANY version control system?) Isn't this like an art student having no concept of a paint brush?

It's interesting you choose this analogy.  In Hackers and Painters,
Paul Graham whom I'm respect highly doesn't mention version control:

http://www.paulgraham.com/hackpaint.html

He also doesn't mention testing either.  Paul Graham is a penultimate
hacker, an absolute genius of creating abstractions.  However, he
doesn't know how to run a software business that lasts more than a few
years.  Y Combinator is about making money with technology solutions,
not about software longevity.  Joel Spolsky, I suspect, understands
the longevity issue, but doesn't get the abstraction part.

There are some practical aspects of programming such as version
control, testing, and so on.  There are also some artistic aspects of
programming, such as, "test what is likely to break", OAOO, and
TIMTOWTDI.  I'm not concerned about the practical aspects.  They are
easy enough to learn, and I would expect companies to train people in
their methodology anyway.  It's quite similar to understanding a
business, and why we train people in The Great Game of Business (see
book by that name).  I don't expect people to understand how business
works, although I consider it essential to writing good software.

What disturbs me is the knowledge that Paul Graham provides in his
books are not well-known.  There are some crucial ideas about creating
software that most programmers don't understand at all -- to the point
of not even understanding the words used.  They are native to the
culture of Lisp, and should be in all dynamic language cultures.

One of my ideas of how to remedy this problem is to teach a course on
refactoring which takes OSS packages, and has students applying the
skills of OAOO, IMTOWTDI, and three strikes rule to get a grade.  Most
software can be refactored to about 1/10 the size.  This isn't a big
effort, and it can be done in a short projects.  For example, I took
Mail::POP3Client and trimmed it down in my book
(http://www.extremeperl.org/bk/refactoring).  There are a number of
aspects of being a programmer-artist which are important and go
untaught in companies and universities.

No time right now to do this, but someday...

Rob

------------------------------

Subject: Digest Footer

_______________________________________________
Boulder-pm mailing list
Boulder-pm at pm.org
http://mail.pm.org/mailman/listinfo/boulder-pm

------------------------------

End of Boulder-pm Digest, Vol 39, Issue 15
******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/boulder-pm/attachments/20120828/87193b1b/attachment.html>