why scrap working code?

This is probably just a naive question, so I'd genuinely appreciate anyone's critical response.  This just keeps coming to mind and I can't quite understand why everyone does things they way they do.

Suppose our program is doing something in a particular way.  It works OK, or it works most of the time, but we've figured out a way to make it work better, or work more of the time.  It seems like the standard thing to do is to replace:

try { old implementation }
except { fall flat on our face }

With:

try { new implementation }
except { fall flat on our face }

What occurs to me instead is:

try { new implementation }
except
{
    log that there's apparently a problem with the new implementation;
    try { old implementation } // we know this used to work!
    except { NOW fall flat on our face! }
}

What am I missing?  Why is code that used to be considered important and reliable constantly scrapped, to somewhere deep in a heap of old dead code that can only be resurrected by human intervention, just because we thought of something a little faster or broader or newer or cleverer?

a flexible case convention

There's all this contention and confusion about CamelCase vs mixedCase vs using_underscores, etc.  It just occurred to me that it would be easy enough to define a standard where those are interchangeable, so that a function defined as some_function could also be called as SomeFunction or someFunction or Some_Function or whatever makes you happy.  That would helpfully disallow some confusingly close pairs, make names easier to remember, and allow us to write each section of code in its own coherent style.

the allure of languages

I've been studying for a few weeks since my last post, and my actions have not lined up with my intentions.

A few weeks ago I carefully considered what I thought I knew and what I thought I didn't know, attempting to chart a course for myself.  I found that so far I know a fair amount about the syntax of a few computer languages-- and not much else!  Not much at all about any other piece of the process of developing software. 

So I started putting together in my mind a list of some other tools I thought I needed in my toolbox: A powerful text editor, a revision control system, a debugger, a bugtracker, a profiler, etc.  And then I began filling in the list with concrete tools, starting with emacs and git.  For the computer language in my toolchain I chose python, which I reasoned would be simple enough to not distract me from learning the other tools, especially since I already knew the basics of its syntax. 

I was entirely wrong!  I greatly underestimated my distractability.  Actually I've spent much of the past few weeks deeply immersed in python's grammar, captivated by it.  I can still barely crawl around in emacs, and I've learned just enough git to get by, yet I could tell you all sorts of interesting facts about python's formal grammar that I'll probably never need to know. 

So it's been occurring to me more and more what shiny objects languages are.  They tempt you to look for your keys under the street lamp, hoping in vain that the solution to your problems is somewhere in that stark elegance, not in slogging through the muck of complexity. 

I'm starting this blog to share my experiences and thoughts as I attempt to teach myself software development. 

At first I would have said that I was teaching myself "computer programming."  I threw myself into SICP and Knuth, devouring programming paradigms left and right, under the foolish delusion that the secrets that allowed programmers to make the software that I used and loved (and hated) would be under the next rock. 

Now the pendulum has swung the other way, I've overcompensated: Lately I've been seeing software as if it were an entirely social process, as if the technical obstacles were a trivial afterthought if we could only agree how to put things together. 

So here I'll share with you some notes on my progress as I continue seeking that happy middle, that small place where human need and understanding can make fragile contact with purity and abstraction.  Wish me luck! 

<3, 

mungojelly