6 ms·

Is there a software-engineering methodology for functional programming?

46 points by marcog1 16y ago

jonsen 16y ago
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.
DanielBMarkham 16y ago
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.
hasenj 16y ago
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 16y ago
  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.
hxa7241 16y ago
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.
peregrine 16y ago
http://clojure.blip.tv/file/4457042/ 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.
tjpick 16y ago
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 http://en.wikipedia.org/wiki/Formal_methods
jrockway 16y ago
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 16y ago
  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.

46 points by marcog1 16y ago

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.

DanielBMarkham 16y ago

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.

hasenj 16y ago

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 16y ago
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.

hxa7241 16y ago

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.

peregrine 16y ago

http://clojure.blip.tv/file/4457042/ 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.

tjpick 16y ago

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 http://en.wikipedia.org/wiki/Formal_methods

jrockway 16y ago

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 16y ago
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.