
Is there a software-engineering methodology for functional programming? - marcog1
http://stackoverflow.com/q/4852251/89806
======
DanielBMarkham
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
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
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
If you draw a box with an arrow, then you use a drawing program and not UML.

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.

------
hasenj
Sadly, programming is not a step-by-step process, and so the search for
methodologies is pretty fruitless IMHO.

Instead of looking for "proven" programming methodologies, one should develop
an aptitude and taste for how to write good programs. This can only come from
"doing" it and seeing how other people do it.

"Bottom up programming" is not a methodology. It's not a step-by-step process,
nor is it a set of strict rules and guidelines. It's just a general idea; and
it's not something you implement, it's a mindset you absorb and imitate.

By the way, UML & co. are horrible abominations and you should steer away from
them. If you want to sketch something out on a piece of paper, just use your
common sense: draw boxes, circles, arrows, trees, or whatever you like.

~~~
flatline
While I love doing bottom-up programming for my own projects or with a small
team, I think there is something to be said for many elements of the top-down
approach. It is often wasteful and overbearing in its process, but when
engineering large systems, having a general consensus on modelling (UML being
the most common form) and code structure does have its payoffs. Not all team
members are equals in their passion for writing code, their interest in the
current project, or their general competency. If you have to write code for
the lowest common denominator - and I don't mean this in any deprecatory sense
- clarity and consistency are tangible benefits.

A clear methodology also provides both a shield to the developers and a
benefit for those involved in the project but not directly working on the
code.

------
jonsen
A methodology for software engineering or a methodology for programming? Not
necessarily the same, as I see it.

You may have one methodology you use for your overall engineering. A framework
for supporting your problem analysis, architecting your system, and doing
system design. You may have another methodology for detailed design and
implementation of the parts of the system that goes into programs. It may of
course be advantageous if the latter support the paradigm of your programming
language. The former less so.

A software based system has three main dimensions, state, event streams, and
functionality. Your methodology should support all three dimensions evenly. If
it does not, you should be aware of that and do your own compensation.

------
jrockway
This is one of my least favorite types of questions. It's like asking, "is
there a painting methodology for latex-based paints?" Well, no. You use latex-
based paints just like you use oil-based paints. Apply it to the paper until
your sense of taste tells you you have art.

Programming is the same way. Write a small amount of code until you have
something beautiful. This methodology will get you far with any language.

The hard part is refining the sense of taste. Just like there are a lot of
poor starving artists who never get it, there are going to be a lot of poor
starving programmers who never get it. That's sad, but that's the reality of
creativity. Not everyone has it.

But you can try, and the way you try is by reading other programs and writing
your programs in a similar style. There are low-level things and high-level
things to look out for, and you're not going to get them by reading Stack
Overflow. You have to play with a language and its libraries on a daily basis
for years. Then you will begin to find the "methodology" you are looking for.

There are no easy answers.

~~~
rdouble
_Well, no. You use latex-based paints just like you use oil-based paints.
Apply it to the paper until your sense of taste tells you you have art._

Except you don't use oil-based paints the same way you use latex. Most of the
time you wouldn't use either on paper.

Painting is a bad example to argue your point. Painting requires adherence to
a certain technical methodology or else you don't get anywhere near your
envisioned artistic result.

------
hxa7241
UML and its manipulations are only a relatively small thing -- the Unified
Process covers much more than that.

So, as a question on _process_ , OO or functional does not matter much: the
software is treated really as modules or parts. Whether those are composed of
lists or objects, methods or functions, is a minor concern. Process
deliberately works at a higher level. There is some specialisation to OO, but
translating it to FP would seem essentially straightforward.

But as a question on that particular sub-area, it is valid and interesting,
and there does not seem to be such a functional specialisation.

Perhaps there is a way to answer by looking back to the history of the Unified
Process. A substantial basis of it was developed by Jacobson while working at
Ericsson on phone switches etc. And that was the same place and same kind of
work where Erlang was later created. So maybe investigating how to use Erlang
might lead to some approaches.

------
tjpick
Lots of talk of UML. Surely if there is a software engineering concept that
suits functional programming, it's formal methods.

<http://en.wikipedia.org/wiki/Formal_methods>

------
peregrine
<http://clojure.blip.tv/file/4457042/> This video with Rich Hickey(Creator of
clojure) is the closest to a functional programming methodology you will find.

Software engineering and programming are simply problem solving with an
abstract tool set.

