Russel Winder wrote: > There is complexity in software but increasing size is not > a certainty. Two reasons, new (old?) technology that enables a > shrinking of the space required for current functionality (e.g. ORIGIN, > cf. http://www.180sw.com/) and use of higher-level languages that enable > the expression of solution at a level of abstraction appropriate for > the reasoning that is happening. I was thinking about the size of function bodies and the number of functions. When functions may grow in size and numbers, the entire system/component becomes difficult to comprehend and manage at some point. In large-scale applications sheer volume can become a hurdle. > Concurrency is perhaps the most interesting of the issues you raise. > Individual programs are now increasingly multi-threaded systems (cf. > Java where all GUI-based systems have at least three threads even if > the programmer doesn't use threads at all) and yet most people are still > thinking in terms of sequential algorithms. Also of course the control > mechanisms for concurrency are still not > really properly worked out. Yes, this was exactly what I was thinking of. Nowadays, many programmers happily use multi-threading without even knowing what deadlocks and race-conditions are. > Managing complexity, as measured by the flow graph, is the most > important skill. Minimization, use of symmetry principles and use of > aesthetic judgements about code all help to create simpler code that is > more functional. For most quality programmers this is a set of skills > and knowledge that are hard learnt. Patterns are helping to bring much > of the knowledge together but still there is a > need for better notations to write down the implementation of systems. I fully agree. Patterns are very useful, but not all knowledge is best captured by patterns. A few years back, when patterns were fashionable, I set out to create a set of debugging patterns (most resembles those that can be found at [1]). I soon realised that, although the patterns were rather easy to construct, I was not using them myself, but rather shifted between them all of the time. When to shift was usually apparent to me during debugging, but very difficult to describe in any meaningful way. In the end I concluded that maybe patterns weren't the proper way to represent debugging skills. [1] http://www.c2.com/cgi/wiki?DebuggingPatternLanguage
