<p>I wanted to post this to <a href="/r/programming" rel="nofollow">/r/programming</a> but they only accept links, and I could care less about blogging.</p>
<p>First, a short preface. I write a lot of Go code. Not all of it is public and yet very little of it is paid for. Frankly, a number of my hobbies involve programming and Go is my go-to language. But why? A talk by Brad Fitzpatrick a while back with a short mention of the loathsome state of programming, the desire to get out of the game, and my questioning of the time spent otherwise hit a nail for me. Why am I programming in my free time? Why am I writing Go code always for completely random things? Why Go, who really cares?</p>
<p>Well, this got me thinking over the coming months about some of the senseless stuff I've written via abstractions available to me. Things that seemed great at the time, almost a beauty to behold, but ultimately I look back on and wondered why I even bothered abstracting particular concepts for literally no gain 2+ years later.</p>
<p>A tangent from the preface, I don't mean to come off as abstractions aren't useful. But, you know, maybe the context is really effin important.</p>
<p>So, my story goes, once I wrote a generic solution to messaging on android. No, not text messages between persons, I'm talking about different portions of an application talking to other portions of the same application for various "parts" of said app. Android, in general, facilitates said communication and I built on top of that for a generic interface that facilitated communication across these various "channels". It wasn't until a couple years later that I truly realized how this "abstraction" could be expressed in maybe 30+ lines of Java specific to an application and a hell of a lot more readable 2+ years after-the-fact.</p>
<p>So, since then I've written an annotation processor to generate that 30+ lines of boring boiler plate (but even that, why?), but I'm curious how many people writing any kind of code have looked back on any kind of abstraction and realized the (not?) net-gain it's afforded them.</p>
<p>If you have a story, I'd like to hear it. For, uh ... science, et all...</p>
<hr/>**评论：**<br/><br/>ChristophBerger: <pre><p>This reminds me a bit of the old story by Joel Spolsky about <a href="http://www.joelonsoftware.com/articles/fog0000000018.html" rel="nofollow">architecture astronauts</a>. Ok, maybe he exaggerates a bit...</p>
<p>I did have some attacks of <em>architecture astronautism</em> in the past, but I feel that it happens much less to me with Go. Go seems to much more support <a href="http://www.joelonsoftware.com/items/2009/09/23.html" rel="nofollow">duct tape programming</a> than over-abstracting.</p></pre>dasacc22: <pre><p>Thanks, it does get a little silly but that put into words exactly what I was trying to work out.</p></pre>Gyrospring: <pre><p>Would event handling be a form of polymorphism?</p></pre>dasacc22: <pre><p>Android provides two independent interfaces for comm depending on your interest in either. Regardless, the question you pose can be generalized in "polymorhism? why?", which is what I'm exploring with my question.</p>
<p>Honesly, I don't expect much given what I typically see on reddit, but summarizing the human experience based on reedit seems pretty dull-witted so I figured I'd ask. At best, I don't know what to expect, but that's life eh?</p></pre>Gyrospring: <pre><p>I felt the same way in Cancun.</p></pre>commentzorro: <pre><p><em>> but ultimately I look back on and wondered why I even bothered abstracting particular concepts for literally no gain 2+ years later.</em></p>
<p>I'll play devil's advocate. I'd say it's not for no gain, just not the gain you thought. Abstracting away the concrete and domain specific details is a tremendous learning experience. You get to understand the fundamental problem, how it might be applied to other unrelated situations, and it can be tons of fun.</p>
<p>I'd say languages such and lisp, forth, and Haskell exist because someone spent the time abstracting away specifics. And certainly there are branches of math that owe their existence to this playing around.</p>
<p>In the end, you might not have gained for your particular problem, but you've likely setup a nice set of neural pathways that might come in handy later. </p>
<p>I also like the idea of blurring the line between coding and art ... "<em>almost a beauty to behold</em>". Art gets to exist for no practical reason. [Hey, I'm art!]</p></pre>
