Very interesting David. I'm subscribed to the RSS feed but I don't think I read that one yet.
I agree that largely, we can use more work on languages, but it seems that making the programming language responsible for solving all of programming problems is somewhat narrow. A friend of mine, Janelle Klein, is in the process of publishing a book called "The Idea Flow Method: Solving the Human Factor in Software Development" https://leanpub.com/ideaflow . The method she arrived at, after leading software teams for a while, in my mind, ended up mapping a software organization into how a human neocortex works (as opposed to the typical Lean methodology of mapping a software organization onto a factory). The Idea Flow Method, in my poor summary, focuses on what matters when building software. And what appears to matter cannot be determined at the moment of writing the software, but only after multiple iterations of working with the software. So, for example, imagine that I write a really "crappy" piece of code that works, in a corner of the program that nobody ever ends up looking in, nobody understands it, and it just works. If nobody ever has to touch it, and no bugs appear that have to be dealt with, then as far as the broader organization is concerned, it doesn't matter how beautiful that code is, or which level of Dante's Inferno it hails from. On the other hand, if I write a really "crappy" piece of code that breaks in ambiguous ways, and people have to spend a lot of time understanding it and debugging, then it's really important how understandable that code is, and time should probably be put into making it "good". (Janelle's method provides a tangible way of tracking this type of code importance). Of course, I can only defend the "deal with it if it breaks" strategy only so far. Every component that is built shapes it's "surface" area and other components need to mold themselves to it. Thus, if one of them is wrong, it gets non-linearly worse the more things are shaped to the wrong component, and those shape to those, etc. We then end up thinking about protocols, objects, actors, and so on.. and I end up agreeing with you that composition becomes the most desirable feature of a software system. I think in terms of actors/messages first, so no argument there :D As far as applying metaphor to programming... from the book I referenced, it appears that the crucial thing about metaphor is the ability to pick and choose pieces from different metaphors to describe a new concept. Depending on what we want to compute/communicate we can attribute to ideas the properties of commodities, resources, money, plants, products, cutting instruments. To me, the most striking thing about this being the absence of a strict hierarchy at all, i.e., no strict hierarchical inheritance. The ability to mix and match various attributes together as needed seems to most closely resemble how we think. That's composition again, yes? On Sat, Apr 6, 2013 at 11:04 PM, David Barbour <[email protected]> wrote: > > On Sat, Apr 6, 2013 at 8:48 PM, Tristan Slominski < > [email protected]> wrote: > >> a lot of people seem to have the opinion the language a person >>> communicates in locks them into a certain way of thinking. >> >> >> There is an entire book on the subject, "Metaphors We Live By", which >> profoundly changed how I think about thinking and what role metaphor plays >> in my thoughts. Below is a link to what looks like an article by the same >> title from the same authors. >> >> http://www.soc.washington.edu/users/brines/lakoff.pdf >> > > I'm certainly interested in how metaphor might be applied to programming. > I write, regarding 'natural language' programming [1] that metaphor and > analogy might be addressed with a paraconsistent logic - i.e. enabling > developers to apply wrong functions but still extract some useful meaning > from them. > > [1] > http://awelonblue.wordpress.com/2012/08/01/natural-programming-language/ > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
