reuse & economics

[philfrei]

I'm sure this topic has been done to death. I'm still trying to find my away around all the ramifications.

This quote from "Dreaming in Code" (pg. 97, book from 2007, by Scott Rosenberg) got me thinking.

Cox, now a consultant living in Manassas, Virginia, says that although he uses open source software daily and considers himself a Linux hacker, he doesn't see the open source approach as a realistic answer to the problem of software reuse. "They do have an economic model that works for people that are motivated by reputation more than money, " he says.  "But most folks are motivated by how to pay the mortgage. And I'm more interested in how to mobilize that majority to make reuse work."

This was the ending paragraph of a discussion on contributions by Brad Cox, who designed Objective-C in an effort to allow more reuse in C programming, and wrote a book called "Superdistribution" explaining a possible economic model for reuse that never caught on.

I find a lot to be sympathetic of here.

[Orangy Tang]

I suspect someone will correct me here, but the author (and the original post) seems to conflate two separate aspects of software reuse. There's 'how do I write code/languages/libraries so they can be reused and shared' and 'under what terms and environment can we get people to share existing code/libraries'. The first is mostly a technical one (design of APIs and languages) and the second is mostly a people problem (how do you make people want to reuse and contribute existing code).

I'm not sure there's much (any?) overlap.

[philfrei]

I guess my thoughts are in a bit of a muddle here. 

I thought this was an interesting quote, too.

We are still building our software cottage-industry-style today, Cox argued. We need to "transform programming from a solitary cut-to-fit craft into an organizational enterprise like manufacturing." Today's software developer is like the colonial-era gunsmith, lovingly handcrafting every nut and screw. We haven't yet made an industrial revolution leap from "filing away at software like gunsmiths at iron bars" to "commercially robust repositories of trusted, stable components whose properties can be understood and tabulated in standard catalogs, like the handbooks of other mature engineering domains."

Games published by our own members! Check 'em out!

[sproingie]

Ah yes the old clarion call of software as a fully repeatable process where we simply stamp out generic software widgets without all that messy code work.  I've got some news for folks like Cox: the interchangeable parts are part of your operating system.  No one goes out and buys a TCP/IP stack or a high performance ethernet driver, even though 20 years ago that was quite a common practice.  95% of browsers are from four different products, and except for the newer mobile markets, no one goes out and buys those either (even Opera is freeware now).

In short, no one is knocking out commodity software as interchangeable parts, because if it's truly commodity, someone else is already doing it by the hundreds of millions.  That category of commodity software may gradually expand, but for the forseeable future, everything else is custom.

As for that old pipe dream of just clicking boxes and making software happen: only trivial software will ever be written that way.  Interesting software has interesting behavior, and as the xkcd comic says, "you will never find a programming language that frees you from the burden of clarifying your own ideas."

[dezzroy]

...the xkcd comic says, "you will never find a programming language that frees you from the burden of clarifying your own ideas."

This made me smile and exclaim a bit, too. It has a lot of truth to it. I'm spending a lot of time on coding my game to follow a design that is not available on any shelf. Some of my peers question my choice of Java, and the flat out truth is: Java ain't holding me back--I am. It's my ideas and how well I can specify them in code. The language/libraries aren't the enemy. The enemy is me! (Wow, I sound a bit disturbed) 

However, I did find myself rolling code for Separating Axis Theorem inspired polygon intersection detection, Monotone Chain (forgot its name exactly) to get a poly from a cloud of points, point of intersection of 2 line segments, and other stuff. Either these functions are not provided by the Java standard library, or had some issues which were unacceptable. One of the big reasons I went with Java for my game is I was impressed with the functionality of the java.awt.geom package (at first), then found out I had to write a lot of my own stuff for things they didn't include.

Why wouldn't there be a floating point 2D polygon class with all the goodies? I had to make my own on top of Path2D, plus extra methods awt.Polygon didn't have.

So, yeah, in my experience, I can sympathize with Cox each time I need to hunt for algorithms on Google or roll my own, but, yeah, as Sproingie said, only trivial (read for games: boring) software can be made from purely using what's out there. Buy the Unreal Engine, and you can make a handsome clone of Unreal... put some creativity and your own home-made code in, and you could have a hot new game!

[Roquen]

Did I mention that Cox originated component based design pattern?  Why yes, I did.

[gimbal]

and the flat out truth is: Java ain't holding me back--I am. It's my ideas and how well I can specify them in code. The language/libraries aren't the enemy. The enemy is me!

Nicely put! Although I wouldn't necessarily call yourself the enemy, lack of knowledge is the enemy and you're fighting it. In that respect you are still the hero, not the enemy.

Similarly, it is ignorance, lack of knowledge and prejudice that will make your peers question your choices. The poor saps are to be pitied, not hated.