7 ms·

UML for the last level does not seem particularly adapted for functional languages or languages with a sophisticated module system though. Anyone knows of some

by rixed 7y ago

UML for the last level does not seem particularly adapted for functional languages or languages with a sophisticated module system though. Anyone knows of some conventional description language that would be a better fit, or is this a case where the code (higher level functions, often times forming some DSL, or the higher level module interfaces) is legitimately the actual description then?

skrebbel 7y ago
I like to draw software. Nothing tells people what's going on at a glance better than a bunch of boxes and arrows. Some 5-10 years ago when UML went out of vogue (for good reasons; much of it is overspecified and overcomplicated), and around the same time FP started getting traction, I think we accidentally lost something. I like FP and I also like using FP principles in not-strictly-FP language's such as JavaScript, but I miss OO's drawability. If anyone knows of a compelling diagram syntax for FP style software, I'm deeply interested. The best I've seen so far is abusing class diagrams for modules, which kinda sorta works when you follow a convention (common in eg Elixir) of having each module export one struct type plus some functions that operate on that struct. It's basically OO without inheritance that way so not surprising that it fits. But that feels a bit like shoehorning my FP into class diagrams rather than anything else. Any takers?
- jimmcslim 7y ago
  Sequence diagrams?
- rumanator 7y ago
  > Some 5-10 years ago when UML went out of vogue (for good reasons; much of it is overspecified and overcomplicated) Perhaps UML ceased to be a fad for some, but to this day UML is still the best tool (and practically only tool) that helps describe and document code effectively and efficiently, from requirements to what classes comprised a submodule. The "oversimplified and overcomplicated" jab makes no sense at all. UML is used to provide a view of a system without needing to go too much into detail (that's what code is for), and just because a bunch of people did a great job putting up a specification aimed at software developers intending to develop UML editora and code generators it does not mean it is overcomplicated". Anyone can use UML extensively if they can draw rectangles and lines on a piece of paper, or click and drag around in an editor. That's hardly a downside or a sign it's "overcomplicated".
  - Silhouette 7y ago
    Perhaps UML ceased to be a fad for some, but to this day UML is still the best tool (and practically only tool) that helps describe and document code effectively and efficiently, from requirements to what classes comprised a submodule. What if your system isn't designed around OO-style classes?
    - juangacovas 7y ago
      Then your code, for some people, is not enterprisey enough and of course not maintanable over time..
      - Silhouette 7y ago
        A significant proportion of the development work my businesses have been doing recently involves systems where reliability is at a premium. They include some quite intricate logic and they will be deployed in environments where fixing bugs later can be very expensive. Based on that experience, you throw out the negative aspects of "enterprise" development pretty quickly when quality actually matters, right behind a large set of Agile-related buzzwords.
  - skrebbel 7y ago
    I take it you never took a UML certification exam. Even the most useful UML diagram, class diagrams, has so much syntax that you can express all of C++'s weird ownership quirks plus some quirks no actual programming language has. UML activity diagrams let you specify, in full detail, the semantics of a trivial 3-line constructor using a ridiculously large amount of arrows and boxes. You can get good at this (even though it serves no purpose whatsoever) and get "UML Certified" stamps on your forehead. UML use case diagrams, hardly useful for anything at all, have a rule that you can put the name of the actor either above or below the actor stick figure. The name of a use case (an ellipsis), however, may only be above or inside the ellipsis, but not below. Put the name below the ellipsis and your UML is syntactically incorrect. Volumes of books were written about nonsense like this. The UML spec is many hundreds of pages. If you don't think this is overspecified and overcomplicated then I want some of what you're smoking. I believe it is these aspects of UML that made it unpopular among the "get things done" crowd. I agree that UML class diagrams and UML state charts, when you just use the normal, useful parts of them, are super useful and currently underrated. If the UML people had remembered they were making a communication tool and not a programming tool, then maybe so many people hadn't run away screaming.
- e12e 7y ago
  > Nothing tells people what's going on at a glance better than a bunch of boxes and arrows. Data structures?
  - Ace17 7y ago
    Data structures won't tell you the communication paths and dependencies between modules/components/services.
- agumonkey 7y ago
  I think it's obvious that FP is great at linear / dataflow which can be represented visually trivially. I think the missing part is distributed / protocol like interaction between pure agents. Maybe we should ask the erlang crowd. Or the smalltalk crowd. Also, who uses petri nets ?
bertylicious 7y ago
Well, functional languages really only distinguish between data and functions. They usually also lack control flow structures, because they are composed of expressions rather that statements. Given those properties, I think data-flow diagrams are a natural fit: https://en.wikipedia.org/wiki/Data-flow_diagram https://en.wikipedia.org/wiki/Data-flow_diagram
- simon_brown 7y ago
  +1 for DFDs ... UML was designed with OO programming languages in mind, and doesn't really fit well for diagramming functional languages (unless you start creating your own custom UML profile, which I don't see many people doing).

by rixed 7y ago

skrebbel 7y ago

I like to draw software. Nothing tells people what's going on at a glance better than a bunch of boxes and arrows. Some 5-10 years ago when UML went out of vogue (for good reasons; much of it is overspecified and overcomplicated), and around the same time FP started getting traction, I think we accidentally lost something. I like FP and I also like using FP principles in not-strictly-FP language's such as JavaScript, but I miss OO's drawability. If anyone knows of a compelling diagram syntax for FP style software, I'm deeply interested. The best I've seen so far is abusing class diagrams for modules, which kinda sorta works when you follow a convention (common in eg Elixir) of having each module export one struct type plus some functions that operate on that struct. It's basically OO without inheritance that way so not surprising that it fits. But that feels a bit like shoehorning my FP into class diagrams rather than anything else. Any takers?

jimmcslim 7y ago
Sequence diagrams?
rumanator 7y ago
> Some 5-10 years ago when UML went out of vogue (for good reasons; much of it is overspecified and overcomplicated) Perhaps UML ceased to be a fad for some, but to this day UML is still the best tool (and practically only tool) that helps describe and document code effectively and efficiently, from requirements to what classes comprised a submodule. The "oversimplified and overcomplicated" jab makes no sense at all. UML is used to provide a view of a system without needing to go too much into detail (that's what code is for), and just because a bunch of people did a great job putting up a specification aimed at software developers intending to develop UML editora and code generators it does not mean it is overcomplicated". Anyone can use UML extensively if they can draw rectangles and lines on a piece of paper, or click and drag around in an editor. That's hardly a downside or a sign it's "overcomplicated".
- Silhouette 7y ago
  Perhaps UML ceased to be a fad for some, but to this day UML is still the best tool (and practically only tool) that helps describe and document code effectively and efficiently, from requirements to what classes comprised a submodule. What if your system isn't designed around OO-style classes?
  - juangacovas 7y ago
    Then your code, for some people, is not enterprisey enough and of course not maintanable over time..
    - Silhouette 7y ago
      A significant proportion of the development work my businesses have been doing recently involves systems where reliability is at a premium. They include some quite intricate logic and they will be deployed in environments where fixing bugs later can be very expensive. Based on that experience, you throw out the negative aspects of "enterprise" development pretty quickly when quality actually matters, right behind a large set of Agile-related buzzwords.
- skrebbel 7y ago
  I take it you never took a UML certification exam. Even the most useful UML diagram, class diagrams, has so much syntax that you can express all of C++'s weird ownership quirks plus some quirks no actual programming language has. UML activity diagrams let you specify, in full detail, the semantics of a trivial 3-line constructor using a ridiculously large amount of arrows and boxes. You can get good at this (even though it serves no purpose whatsoever) and get "UML Certified" stamps on your forehead. UML use case diagrams, hardly useful for anything at all, have a rule that you can put the name of the actor either above or below the actor stick figure. The name of a use case (an ellipsis), however, may only be above or inside the ellipsis, but not below. Put the name below the ellipsis and your UML is syntactically incorrect. Volumes of books were written about nonsense like this. The UML spec is many hundreds of pages. If you don't think this is overspecified and overcomplicated then I want some of what you're smoking. I believe it is these aspects of UML that made it unpopular among the "get things done" crowd. I agree that UML class diagrams and UML state charts, when you just use the normal, useful parts of them, are super useful and currently underrated. If the UML people had remembered they were making a communication tool and not a programming tool, then maybe so many people hadn't run away screaming.
e12e 7y ago
> Nothing tells people what's going on at a glance better than a bunch of boxes and arrows. Data structures?
- Ace17 7y ago
  Data structures won't tell you the communication paths and dependencies between modules/components/services.
agumonkey 7y ago
I think it's obvious that FP is great at linear / dataflow which can be represented visually trivially. I think the missing part is distributed / protocol like interaction between pure agents. Maybe we should ask the erlang crowd. Or the smalltalk crowd. Also, who uses petri nets ?

bertylicious 7y ago

Well, functional languages really only distinguish between data and functions. They usually also lack control flow structures, because they are composed of expressions rather that statements. Given those properties, I think data-flow diagrams are a natural fit: https://en.wikipedia.org/wiki/Data-flow_diagram https://en.wikipedia.org/wiki/Data-flow_diagram

simon_brown 7y ago
+1 for DFDs ... UML was designed with OO programming languages in mind, and doesn't really fit well for diagramming functional languages (unless you start creating your own custom UML profile, which I don't see many people doing).