I feel that the disconnect is the presumption (which at one point in my career I was fully on board with) that Everything Is An Object.

Additionally, I have grown resistant to "methodology" more than anything. In my harsher moments, I argue that methodologies are insisted on by PHB who don't really understand programming and want something to insulate them from the reality of software development.

The other huge disadvantage to sequence diagrams is that they are very poor at describing concurrency, and only work real well for simple single threaded systems.

I disagree. If, for example, you are dealing with cooperating processes, then sequence diagrams are quite useful.

There. You're using UML.

Yes, the guys who spec out UML -- and many of the practitioners -- think of it as a do-all, end-all language of goodness and OOP.

But read your quote again. It's a visual language. A purpose of a language is to communicate. Who are you communicating with? Some folks think you're communicating with the computer itself, and their UML looks that way. But the language communicates to other people. You can be as loose or as detailed as you like, as long as you are communicating. The language spec simply provides you a range of depth in formality to use depending on your circumstances.

I teach this, I use this, and I've coded both OOP and FP for years. I think I know what the hell I'm talking about. Yes, according to the authors it can be used with all major OO systems, but that's a far cry from meaning the two are inseparable. It can also be used with railroad design, or industrial lighting systems.

I get really tired of dogmatism in programming. The idea that you can quote an authority as somebody who somehow controls the everyday practical uses of a thing. It's almost like we think of standards bodies as the programmers and people as the little machines that run the standards. UML is a tool. Pick it up. Use it. Understand what the tool is used for -- in a practical sense, not in a technical one. The definition of the tool is in the hands of the wielder, not some standards group. They just write specs. No one tool can do everything, and the directions that came with the tool were probably written by folks who see the entire world in terms of their tool.

If you're not designing your functional structures in some fashion -- including just in your head -- then I don't want to be maintaining your code. Whether or not you draw pretty pictures to do that or not is only important if you need to communicate that design to somebody else or sort it out in your head. And that's not even getting into all the other uses of UML -- component modeling, network diagramming, etc -- that have nothing at all to do with programming. If you think of UML artifacts as directly relating to OOP, go talk to a business domain modeler who uses UML, or a network analyst, or a BA.

It's a modeling language, not a coding language. You use it when you need to model. Modeling can help you in all kinds of situations. Or not. Draw a box. The rest of the discussion is around whether you need to draw the box or not, and it's so dependent on particular situations it's not germane to this conversation. Simple as that.

There is a reason, while in addition to OOP (object-oriented Programming) we are talking about OOA (object-oriented analysis) and OOD (object-oriented design). It's wrong to believe that OO is only for programming - it goes right into modelling and design. UML is originally created to support OO modelling.

Of course, using an UML class diagram for a detailed design describing the implementation of a component does not make sense when using functional programming.

The bulk of code generation tools and diagram "helpers" might be pointless in FP, but when you sketch on a napkin boxes and arrows just do their work in a way that even OO people can understand what you are talking about.

I do agree with the premise that FP feels a lot more agile to me, and thus benefits less from a big design-up-front effort.