1. Capability and Suitability
1.1. Capability
1.1.1. The power to express an idea
1.1.2. LISP
1.1.3. Just because you "can" doesn't mean you should
1.2. Suitability
1.2.1. The power to deliver a software system that works
1.2.2. reliably delivering reliable software
1.2.3. JAVA
1.3. Examples
1.3.1. '57 Fortran
1.3.1.1. You could say things in Fortran you couldn't say in Assembly
1.3.2. '68 Structured Programming
1.3.2.1. It used to be thought that gotos were necessary for good software design
1.3.2.2. Structured programming is a nice academic exercise which works well for small examples, but I oubt that any real-world program will ever be written in such a style
1.3.3. '70 Relational model
1.3.3.1. Response to unstructured flat files
1.3.3.2. At first sight I doubt that anything omplex enough to be of practical interest...
1.3.4. '85 C++
1.3.4.1. C++ must be compatible with C and have classes
1.3.5. '95 Java
1.3.5.1. C++, but safer to use
1.3.6. '04 Rails
1.3.6.1. Is Rails a capability response or a suitability response or neither or both?
1.3.6.2. Rails is OBVIOUSLY not suitable for large systems!
1.3.6.3. Rails seems to be an advance in capability
1.3.6.4. Rails gave us higher level constructs to build web apps out of.
1.3.6.5. Culture of brokenness: Everything broken all the time. Held together by chewing gum
1.3.6.5.1. Install gem x. Works great. Discover it sucks in 9 months, switch to gem y
1.3.6.6. It's all about the new thing, what can I say that I couldn't say before
1.3.6.7. Not about reliably building something
2. Expansion and Contraction
2.1. one tool increases the capability
2.2. Another shaves 5% of the capability and 85% of the confusion
2.3. Things get crazier, then simpler, then crazier, then ssimpler
2.4. Abundant resources and confusion
2.4.1. driving force fof change in this industry
2.4.2. cause lots of whining
2.4.3. high confusion
2.4.3.1. contracts suitibility
2.4.3.2. reaction is to limiting
2.4.4. Abundant resources
2.4.4.1. reaction is always "too slow"
2.4.4.2. trigger expanded capability
2.5. Expansion
2.5.1. Increases ideas, most of which are bad
3. Activity and progress
3.1. Managers who were once technical but lost that focus on the illusion of work
3.1.1. Just because I'm good at VIM doesn't make me producive
3.1.2. I'm making commits but am I actually doing anything?
3.2. What is progress?
3.3. A new system that is highly capable generates a lot of activity
3.4. Contraction into more suitable tools leads to more progress
3.5. JAVA is where progress happens.
4. Divination
4.1. Now
4.1.1. Rails was a capability expansion
4.1.2. Rails apps are bad on the inside
4.1.2.1. this is universally true
4.1.3. Rails took PHP culture of BBOM into a slightly smaller BBOM
4.1.4. All the mud goes into the model
4.2. Next?
4.2.1. GOOS wins!
4.2.1.1. outside in top down london style TDD becomes mainstream
4.2.1.2. This is impossible
4.2.1.3. Outside in TDD is a nice academic exercise...
4.2.2. Functional revoluation
4.2.2.1. Clearly impossible
4.2.2.2. Functional programming is a nice academic exercise
4.2.3. It's contraction time
4.2.3.1. There is frustration