5 ms·

This seems like a poorly-expressed question. The premise is that one set or another of tools are used only for OOP. UML is a modeling language for talking abou

This seems like a poorly-expressed question. The premise is that one set or another of tools are used only for OOP. UML is a modeling language for talking about abstract constructs. That means it's as good for working with FP as OOP. What you model in UML and how much you do and how you do it? That's an entirely different thing. You have to have data. In FP, more than anywhere else, data is king. So I use UML to initially model data structures, just like I would no matter what paradigm I was working with. Let Codd be your copilot. It's never right. There are those who model code ad infinitum and try to code the world completely top-down. This never works. There are those who don't model anything and try to code completely bottom-up. This works, but can become unmaintainable if not implemented correctly. The trick is to do a little top-down, a little bottom-up, a little top-down, etc. Usually within a couple cycles of this your basic program/data structure is nailed and you can move to being bottom-up and refactoring. I've probably described it more complicated than it actually is. But it works the same in OOP as FP (although I've noticed a quicker tendency to move towards bottom-up in FP and a tendency to stay top-down in OOP) If the questioner is talking about software development methodologies, like Agile or RUP or CMM or waterfall, then it's also the same. After years of beating ourselves up in various ways, we've pretty much all agreed that short timeboxes, with concrete deliverables, public demonstrations, and constant adaptation to changing conditions beats everything else. However else you want to do it is up to you, but it should conform to those basics. FP or OOP really has nothing to do with it. I think maybe the questioner is making the assumption that all this _stuff_, UML sequence diagrams and use cases and tiered architectures and whatnot -- that it's really how you program in OOP. But it's not. It never was. All that crap is just various tools that are useful in various situations to communicate about complex problems. They're not actually how you _do_ anything.

lispm 16y ago
From the UML standard: The Unified Modeling Language is a visual language for specifying, constructing, and documenting the artifacts of systems. It is a general-purpose modeling language that can be used with all major object and component methods, and that can be applied to all application domains (e.g., health, finance, telecom, aerospace) and implementation platforms (e.g., J2EE, .NET). object and component methods. The UML comes from modelling for object-oriented software. Using UML with Functional Programming is like using a hammer to drive screws into walls.
- DanielBMarkham 16y ago
  Draw a box. Write something in the box. Draw an arrow. 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.
  - lispm 16y ago
Dn_Ab 16y ago
mm I don't know about UML but I take two approaches. When going through concepts I use boxes with arrows and texts - I bet UML people would laugh derisively if I claimed what I drew was UML, my shapes arent even consistent from diagram to diagram. On the next level I use type diagrams ala category theory of functions to figure out what will be needed in code. The diagrams help in terms of thinking out the concepts, also about composition (how FP manages code reuse and extensibility) and setting up guard rails to guide my thinking. The diagrams are also underpinned by a mathematical language and I can do some basic algebra with the concepts before writing code. I use only the most basic parts of category theory though. Through out this process, and most heavily at the start, I am usually also at the interactive testing out ideas.
- DanielBMarkham 16y ago
  I bet UML people would laugh derisively I think we have a disconnect here in most folk's opinion of UML -- what it's supposed to be used for, what kinds of people use it, how to do it "right" or not -- and actual reality. Are you communicating effectively with others, with yourself? Do you diagram enough to help solve problems? Sounds to me like you're doing just fine. Sometimes my UML is so scratchy and rough that it looks like something from an impressionist painting. That's fine -- as long as it works for me. Programming is full of little nooks and crannies where people get really tightly focused on one thing or another. web design comes to mind, or picking a programming language. They create a lot of complexity where most of the times just a little is needed. The danger here is that the rest of us take a look at that complexity and kind of throw our hands up and say "hell with it. I'm just drawing little boxes. There's no way I'm going to do "correct" UML" Part of this is because other folks make things so complex, but part of it is ourselves: many times we feel that something like a UML standard is the same as a C++ standard. They're not. If I'm coding C++, I have to conform to the standard. If I don't the code won't work. But if I'm writing a web page? I can do it just about any dang way I want to. Standards be damned. Now in practice do I use standards with things like web design? Sure -- but only as much as I personally find useful. To make it an all-or-nothing proposition is throwing the baby out with the bath water. What's required is to dive into one of these areas for a bit, learn the ropes, then use your common sense to apply just as much of it as you need to do whatever you are working on. Modeling is a powerful tool in problem solving in all sorts of areas. Having knowledge of how to model things visually is a nifty little tool to have in your back pocket. That's true even if you'll never code a bit of OOP in the rest of your life.
jcromartie 16y ago
UML is more naturally mapped to OOP than to flat relations, and relational programming is more natural for a functional language. See http://web.mac.com/ben_moseley/frp/frp.html http://web.mac.com/ben_moseley/frp/frp.html

lispm 16y ago

From the UML standard: The Unified Modeling Language is a visual language for specifying, constructing, and documenting the artifacts of systems. It is a general-purpose modeling language that can be used with all major object and component methods, and that can be applied to all application domains (e.g., health, finance, telecom, aerospace) and implementation platforms (e.g., J2EE, .NET). object and component methods. The UML comes from modelling for object-oriented software. Using UML with Functional Programming is like using a hammer to drive screws into walls.

DanielBMarkham 16y ago
Draw a box. Write something in the box. Draw an arrow. 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.
- lispm 16y ago

Dn_Ab 16y ago

mm I don't know about UML but I take two approaches. When going through concepts I use boxes with arrows and texts - I bet UML people would laugh derisively if I claimed what I drew was UML, my shapes arent even consistent from diagram to diagram. On the next level I use type diagrams ala category theory of functions to figure out what will be needed in code. The diagrams help in terms of thinking out the concepts, also about composition (how FP manages code reuse and extensibility) and setting up guard rails to guide my thinking. The diagrams are also underpinned by a mathematical language and I can do some basic algebra with the concepts before writing code. I use only the most basic parts of category theory though. Through out this process, and most heavily at the start, I am usually also at the interactive testing out ideas.

DanielBMarkham 16y ago
I bet UML people would laugh derisively I think we have a disconnect here in most folk's opinion of UML -- what it's supposed to be used for, what kinds of people use it, how to do it "right" or not -- and actual reality. Are you communicating effectively with others, with yourself? Do you diagram enough to help solve problems? Sounds to me like you're doing just fine. Sometimes my UML is so scratchy and rough that it looks like something from an impressionist painting. That's fine -- as long as it works for me. Programming is full of little nooks and crannies where people get really tightly focused on one thing or another. web design comes to mind, or picking a programming language. They create a lot of complexity where most of the times just a little is needed. The danger here is that the rest of us take a look at that complexity and kind of throw our hands up and say "hell with it. I'm just drawing little boxes. There's no way I'm going to do "correct" UML" Part of this is because other folks make things so complex, but part of it is ourselves: many times we feel that something like a UML standard is the same as a C++ standard. They're not. If I'm coding C++, I have to conform to the standard. If I don't the code won't work. But if I'm writing a web page? I can do it just about any dang way I want to. Standards be damned. Now in practice do I use standards with things like web design? Sure -- but only as much as I personally find useful. To make it an all-or-nothing proposition is throwing the baby out with the bath water. What's required is to dive into one of these areas for a bit, learn the ropes, then use your common sense to apply just as much of it as you need to do whatever you are working on. Modeling is a powerful tool in problem solving in all sorts of areas. Having knowledge of how to model things visually is a nifty little tool to have in your back pocket. That's true even if you'll never code a bit of OOP in the rest of your life.

jcromartie 16y ago

UML is more naturally mapped to OOP than to flat relations, and relational programming is more natural for a functional language. See http://web.mac.com/ben_moseley/frp/frp.html http://web.mac.com/ben_moseley/frp/frp.html