> No doubt it could be construed as either-or rather than both-and. Having > relevant media to support professional development is necessary. However, it > seems rather too easy to end up with a cultural reduction toward the > technological means rather than the ends (and thus we end up mantras). > Personally, I find it useful to keep the big picture in mind. The development > of professional practices are not something that businesses are particularly > good at, in my opinion.
I don't disagree too much I am guessing. I agree most practices suck. I want things to start with Good Developers and Good Processes. But if I am one of those people who is practicing such things, I would like the computational power we have in abundance to help me outsource the things in my head to the system, so that it can be maintained (and searched and mined and used to generate tests and etc.) long term. And if the tools aren't there to help people latch on to good ways of doing things, then they will have more opportunity to not do it less badly. I mean, good people should be able to ignore bad tools. But good tools should not be eschewed or prevented from existing. > The subject of language choice continues the themes of description & signing > and interpretative complexity with respect to the constraints and affordances > of the language and its expected uses. We seem to muddle on by with rather > overly complicated syntax by virtue of the knowledge that certain languages > are generally applied to specific domains (text parsing, html processing). The muddling goes on is for many reasons, unfortunately. The stuff that might be used to encode the relationships among things in our ASCII source code might be a different programming / markup language, so it might be a chance to do at least that niche better. Who knows. > Again, I would stress that the structure is not inherent to the language, but > rather is mediated through its use. What we do with a language at the level > of action and the (desirable) craft-object of concern dictate the subjective > complexity. I think a useful distinction is being made between the means of > partitioning a problem and implementing it (the use of a language) in > distinction to a means to visualise artefacts derived from the language. If > the visualisation tool helps one to enlarge the scope of the object of > concern then it is also acting to specifically scope the approach (which may > be fine, but is worth recognising). Model driven design and all that jazz is something I suspect a lot of people wish really did work. I suspect we don't think our structure is inherent in the language at all. To me the original question clearly was about how the structure is unfortunately mediated and obscured through the use of a given programming language? > For me, these issues were clearly exemplified with windows based approach to > programming. By providing ease of use in one area, one makes it harder in > others. Hence it is possible to undermine skills in design and organisation > by introducing short-cuts in an attempt to change the landscape of a problem > (thereby setting oneself up for more adventurous problems in the future). Yes and no. E.g., just because one limited set of visual metaphors stopped at some arbitrary brick wall doesn't mean: a) that we should give up on visual approaches cf. Eve programming environment b) that we cannot marry the 2 cf. Smalltalk GUI, or Linux, Mac offering both windowed & terminal environments, with some minimal communication being supported back and forth between the two I don't see why it has to be a zero sum game *in the long run*, if there are enough intelligent & caring people who want to tackle it. Admittedly that is a different thing than what pragmatically has happened for whatever business or social reasons to date. -- You received this message because you are subscribed to the Google Groups "PPIG Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to ppig-discuss+unsubscr...@googlegroups.com. To post to this group, send an email to ppig-discuss@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
