Hacker News Reader

Comment by skrebbel | Hacker News Reader

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?

View on HN

> 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".

What if your system isn't designed around OO-style classes?

Then your code, for some people, is not enterprisey enough and of course not maintanable over time..

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.

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.

> I take it you never took a UML certification exam.

You're either very disingenuous or deeply confused. You don't need to hold a Master's degree in English to hold a conversation with English speakers. You don't need academic certification to use a tool to communicate ideas.

It makes no sense to assert that the usefulness and ease of use of a language is demonstrated by how far and how extensively it may be covered in an academic setting.

Lines and boxes. It's not that hard, is it?

I don't understand why you insist on disagreeing so violently when we're mostly on the same page. In fact I don't disagree with a single word in your comment, except the part about disingenuous which baffles me.

We agree that UML has a subset of common features that are super useful to communicate about software. That doesn't make UML as a whole any less overcomplicated and overspecified, though!

Most people agree that languages like C++ or Scala are large and complicated. The fact that you can choose to write C++ code that only uses functions and structs and pointers doesn't change anything about that.

I said nothing about UML's ease of use. I said something about its drop in popularity and about the swathes of useless features UML fans promoted when it was at the peak of its hype cycle. I mean, I assume you agree that UML is less popular now than it used to be?

Sidenote: nothing about UML was ever intended to be academic, I'm not sure where you got that term from all of a sudden. It was all very industry driven. People wanted to do "model driven development" and realized if only UML could have super precise semantics, you could generate entire programs from UML. This actually works and serious amounts of software have been painstakingly written this way. It's totally nuts.

> 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.

The problem is OMG turns every analytical tool into programming tools, sacrificing focus on the core purpose; they did the same thing (with similar effect) with BPMN.

it was too tempting honestly and a natural tension of having computers manipulating graphs .. at one point you want to link the graph with the concrete artefact automatically

but classical OO is not appropriate methinks

It's unfortunately not true. A large fraction of the UML creators come from the formal specification camp. They always wanted UML to be a specification language, instead of a visual communication tool for developers. Therefore, most of it is way too fine-grained for getting a birds-eye view. For example, you can't have a sequence diagram with components as messages sources and destinations, only with objects.

Of course, you can just ignore the UML semantics and draw something that looks like UML. That might be still useful. However, it then isn't UML anymore.

> 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.

UML sucks for requirements (outside of, maybe, sequence diagrams); BPMN—which OMG overcomplicated the same way it did UML—is far superior for most requirements-relates diagramming, and honestly DFD’s and minispecs in the style of (Yourdon, et al.) old-school structured analysis beat UML for requirements.

For classes in a module, well, despite the wide availability of tools that will generate UML from code for that, the dominant mechanism seems to be autogenerated text documentation. That suggests people don't find UML adding a lot of value in that role.

UML is, however, pretty much the ultimate tool for communicating the structure of an object-oriented system to someone familiar with UML but not the implementation language. And UML sequence diagrams are, if not necessarily the best, at least a useful and popular way of showing interaction patterns even outside of OOP.

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 ?

> Nothing tells people what's going on at a glance better than a bunch of boxes and arrows.

Data structures?

Data structures won't tell you the communication paths and dependencies between modules/components/services.

Sequence diagrams?

Reply on news.ycombinator.com