No Silver Bullet

Posted on by John

Mike Swaim gave a presentation today entitled No Silver Bullet, an allusion to Fred Brook’s classic essay by the same title.

Mike discusses the pros and cons of the following software development techniques:

  • High level languages
  • Object oriented programming
  • Declarative languages
  • Functional programming
  • Data oriented design
  • Metaprogramming
  • Static typing
  • Duck typing
  • Garbage collection
  • Allocating on the stack
  • Tail calls
  • Resource acquisition is initialization
  • Symmetric multitasking
  • Heterogeneous multitasking

There’s a nice collection of links at the end of each section.

Update: Unfortunately the slides are no longer available.

9 thoughts on “No Silver Bullet”

  2. Preston L. Bannister

    Looks good, with one major omission. Metaprogramming and Lisp – one of the major insights I got using Lisp in school. The metaprogramming language of Lisp is Lisp. Enough so the you can readily create domain-specific languages within Lisp. One of the main failings of C++ templates is that they are yet-another programming language, within C++, with limited inflexible semantics.

    Or to put this differently, they re-implemented an aspect of Lisp programming, poorly.

  3. Mike Swaim

    That’s slide number 3 :) (And a reference to an article Fredrick Brooks wrote many years ago.) Giving credit, the graph of processor vs. memory speeds came from the Sony Data Driven Design article I linked to.

  4. Igor

    I like the spirit of the talk.

    One point on the slides confuses me, though: C, C++, Lisp, Java, Python and Ruby are listed as “stack based” languages, while the slide titled “C# Note” seems to argue that C# is not stack-based. But, I can’t think of any reasonable definition of the “stack based” category such that Java falls into it but C# does not.

    There are a number of other things on the slides that I could nitpick, but that one jumped out at me the most.

  5. Tim Wright

    Thanks John for a great blog.

    What about graphical programming languages? I have had arguments with people who think that tools like simulink and UML are silver bullets because you graphically draw the if statements and it makes the code easier to read. I do think these tools have their place but definitely not a silver bullet.

  6. John

    Tim: I think UML et al failed because people tried to make diagrams too detailed. When your diagram is as complicated as code, it’s easier to write code. See also Why there will always be programmers.

    I was at a company that tried to use Rational Rose in the ’90s. It sounded like a great idea but was a big pain in practice.

  7. Tim Wright

    I agree that it is hard to define everything in UML so the code can be auto generated. The diagrams get complex fast. But there are still people and at least one company who believe in this approach, it is not dead yet as an idea. I don’t personally like it and so far I don’t have to.

  8. patfla

    I always thought it interesting that Brooks’ “The Mythical Man Month” was about the creation of OS/360 – which, I believe, can hardly be called a failed project. Brooks oversaw the project.

    He deemed the new (at the time) System/360 project to have been successful. However its operating system, OS/360, was software and therein lay his tale.

Comments are closed.