<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt">What's the point of version control when you just end up throwing code away?  ;-)<br><br>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.  <br><br>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.  <br><br>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?<br><br>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.  <br><br>I wish we would get some rain here.  Hot and Dry  but I guess it's preferable over Cold and Damp.  ;-)   <br><div><br></div>  <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> <hr size="1">  <b><span style="font-weight:bold;">From:</span></b> "boulder-pm-request@pm.org" <boulder-pm-request@pm.org><br> <b><span style="font-weight: bold;">To:</span></b> boulder-pm@pm.org <br> <b><span style="font-weight: bold;">Sent:</span></b> Monday, August 27, 2012 1:00 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> Boulder-pm

 Digest, Vol 39, Issue 15<br> </font> </div> <br>

Send Boulder-pm mailing list submissions to     <a ymailto="mailto:boulder-pm@pm.org" href="mailto:boulder-pm@pm.org">boulder-pm@pm.org</a> 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     <a ymailto="mailto:boulder-pm-request@pm.org" href="mailto:boulder-pm-request@pm.org">boulder-pm-request@pm.org</a> You can reach the person managing the list at     <a ymailto="mailto:boulder-pm-owner@pm.org" href="mailto:boulder-pm-owner@pm.org">boulder-pm-owner@pm.org</a> 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)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Mon, 27 Aug 2012 08:50:16 -0600<br>From: Walter Pienciak <<a ymailto="mailto:wpiencia@thunderdome.ieee.org" href="mailto:wpiencia@thunderdome.ieee.org">wpiencia@thunderdome.ieee.org</a>><br>To: <a ymailto="mailto:boulder-pm@pm.org" href="mailto:boulder-pm@pm.org">boulder-pm@pm.org</a><br>Subject: Re: [<a target="_blank" href="http://boulder.pm/">Boulder.pm</a>] Academic vs Production Code<br>Message-ID: <<a ymailto="mailto:20120827145016.GA8461@thunderdome.ieee.org" href="mailto:20120827145016.GA8461@thunderdome.ieee.org">20120827145016.GA8461@thunderdome.ieee.org</a>><br>Content-Type: text/plain; charset=iso-8859-1<br><br>On Thu, Aug 23, 2012 at 02:01:27PM -0700, Ed Dow wrote:<br>> Walter -- very interesting thoughts on academic vs production<br>> code.? In some ways it seems like it

 should be opposite.?<br>> Academia should be a place where you strive to put in long<br>> hours and thought into your work.? The real world, the evil<br>> exists, production is where after looking and pondering over<br>> code which will be used once and thrown away (sometimes), seems<br>> more like a time for minimal effort and get back to the more<br>> important things like drinking or theology which ever comes<br>> first. ? ;-) <br><br>My thoughts on this came from observation of programmers straight<br>from school, and in trying to reconcile the work of admittedly<br>bright programmers but new to the workforce with that of seasoned<br>pros.<br><br>It seems to me that while in school, the focus is on the ability<br>to break down a complex problem into workable fragments, to learn<br>new algorithmic process or data structures, to become familiar<br>with functions and tricky uses of ... etc.<br><br>Academic code seems barebones,

 with the logic and working of the<br>program evident.  Think of the examples in most textbooks.<br><br>Production code has acknowledgment of "shit that happens."  Full<br>disks, data input outside expected parameters, trying to open<br>nonexistent files, etc.  This the realm of Rob's comments, IMO.<br><br>So that's the sense in which I use "academic" and "production"<br>code.<br><br>It's pouring -- POURING -- rain here in CNJ this morning.  (I'm<br>working at the main facility this week.)<br><br>Walter<br><br><br>------------------------------<br><br>Message: 2<br>Date: Mon, 27 Aug 2012 10:23:34 -0500<br>From: Jay Hannah <<a ymailto="mailto:jay@jays.net" href="mailto:jay@jays.net">jay@jays.net</a>><br>To: <a ymailto="mailto:boulder-pm@pm.org" href="mailto:boulder-pm@pm.org">boulder-pm@pm.org</a><br>Cc: Nebraska USA Perl Mongers of Omaha <<a ymailto="mailto:omaha-pm@pm.org"

 href="mailto:omaha-pm@pm.org">omaha-pm@pm.org</a>>,<br>    "<a ymailto="mailto:odynug@googlegroups.com" href="mailto:odynug@googlegroups.com">odynug@googlegroups.com</a>" <<a ymailto="mailto:odynug@googlegroups.com" href="mailto:odynug@googlegroups.com">odynug@googlegroups.com</a>><br>Subject: Re: [Boulder.pm] Academic vs Production Code<br>Message-ID: <<a ymailto="mailto:230A4888-ED55-4606-89FA-7B4E604E4621@jays.net" href="mailto:230A4888-ED55-4606-89FA-7B4E604E4621@jays.net">230A4888-ED55-4606-89FA-7B4E604E4621@jays.net</a>><br>Content-Type: text/plain; charset=iso-8859-1<br><br>[From http://mail.pm.org/pipermail/boulder-pm/2012-August/001095.html]<br><br>On Aug 27, 2012, at 9:50 AM, Walter Pienciak <<a ymailto="mailto:wpiencia@thunderdome.ieee.org" href="mailto:wpiencia@thunderdome.ieee.org">wpiencia@thunderdome.ieee.org</a>> wrote:<br>> Academic code seems barebones, with the logic and working of the<br>>

 program evident.  Think of the examples in most textbooks.<br>> <br>> Production code has acknowledgment of "shit that happens."  Full<br>> disks, data input outside expected parameters, trying to open<br>> nonexistent files, etc.  This the realm of Rob's comments, IMO.<br><br><br>-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. <br><br>And 95% of computer science students don't want to be programmers...? Really? What % of CS-targeted jobs will be programming all day? <br><br>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?<br><br>As you can tell, I have many

 energetic beefs with computer related academia.  :)<br><br>jhannah<br>Omaha.pm<br><a href="http://www.linkedin.com/in/jhannah" target="_blank">http://www.linkedin.com/in/jhannah</a><br><br><br><br><br>------------------------------<br><br>Message: 3<br>Date: Mon, 27 Aug 2012 11:15:04 -0600<br>From: Rob Nagler <<a ymailto="mailto:nagler@bivio.biz" href="mailto:nagler@bivio.biz">nagler@bivio.biz</a>><br>To: <a ymailto="mailto:boulder-pm@pm.org" href="mailto:boulder-pm@pm.org">boulder-pm@pm.org</a><br>Subject: Re: [Boulder.pm] Academic vs Production Code<br>Message-ID:<br>    <CAJB=<a ymailto="mailto:V03PX3HDqh_27sYZeR8DUsgNvJHqEtm92CJXnkkZsrNLHA@mail.gmail.com" href="mailto:V03PX3HDqh_27sYZeR8DUsgNvJHqEtm92CJXnkkZsrNLHA@mail.gmail.com">V03PX3HDqh_27sYZeR8DUsgNvJHqEtm92CJXnkkZsrNLHA@mail.gmail.com</a>><br>Content-Type: text/plain; charset=ISO-8859-1<br><br>> 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?<br><br>It's interesting you choose this analogy.  In Hackers and Painters,<br>Paul Graham whom I'm respect highly doesn't mention version control:<br><br><a href="http://www.paulgraham.com/hackpaint.html" target="_blank">http://www.paulgraham.com/hackpaint.html</a><br><br>He also doesn't mention testing either.  Paul Graham is a penultimate<br>hacker, an absolute genius of creating abstractions.  However, he<br>doesn't know how to run a software business that lasts more than a few<br>years.  Y Combinator is about making money with technology solutions,<br>not about software longevity.  Joel Spolsky, I suspect, understands<br>the longevity issue, but doesn't get the abstraction part.<br><br>There are some practical aspects of programming such as version<br>control, testing, and so on.  There are also some artistic aspects of<br>programming, such as,

 "test what is likely to break", OAOO, and<br>TIMTOWTDI.  I'm not concerned about the practical aspects.  They are<br>easy enough to learn, and I would expect companies to train people in<br>their methodology anyway.  It's quite similar to understanding a<br>business, and why we train people in The Great Game of Business (see<br>book by that name).  I don't expect people to understand how business<br>works, although I consider it essential to writing good software.<br><br>What disturbs me is the knowledge that Paul Graham provides in his<br>books are not well-known.  There are some crucial ideas about creating<br>software that most programmers don't understand at all -- to the point<br>of not even understanding the words used.  They are native to the<br>culture of Lisp, and should be in all dynamic language cultures.<br><br>One of my ideas of how to remedy this problem is to teach a course on<br>refactoring which takes OSS

 packages, and has students applying the<br>skills of OAOO, IMTOWTDI, and three strikes rule to get a grade.  Most<br>software can be refactored to about 1/10 the size.  This isn't a big<br>effort, and it can be done in a short projects.  For example, I took<br>Mail::POP3Client and trimmed it down in my book<br>(<a href="http://www.extremeperl.org/bk/refactoring" target="_blank">http://www.extremeperl.org/bk/refactoring</a>).  There are a number of<br>aspects of being a programmer-artist which are important and go<br>untaught in companies and universities.<br><br>No time right now to do this, but someday...<br><br>Rob<br><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>Boulder-pm mailing list<br><a ymailto="mailto:Boulder-pm@pm.org" href="mailto:Boulder-pm@pm.org">Boulder-pm@pm.org</a><br><a href="http://mail.pm.org/mailman/listinfo/boulder-pm"

 target="_blank">http://mail.pm.org/mailman/listinfo/boulder-pm</a><br><br>------------------------------<br><br>End of Boulder-pm Digest, Vol 39, Issue 15<br>******************************************<br><br><br> </div> </div>  </div></body></html>