43

Possible Duplicate:
Functional Programming vs. OOP
How to write manageable code with functional programming?

In OOP, your basic unit of organization for code is the class. A frequently used methodology in Java, C# and similar languages is to organize your code around having one file for each class with the file name following the class name.

You can consider each of these class as a unit of organization to group a single concept.

These classes are in in namespaces which often follow the directory structure of the files in the solution/project. Namespaces are another level of organization.

How are large projects in functional languages typically organized?

How to you determine how to split your functions into different files?

Are other units of grouping beside files used?

How is code typically organized within a single file?

Community
  • 1
Gilles
  • 2,201
  • 1
  • 19
  • 26
  • What's stopping you from (1) reading a Haskell program and (2) writing down the organization used? Why ask here when you can read real code and see how real projects and really organized? What do you want from us that you can't get form reading real code? – S.Lott Nov 30 '11 at 02:48
  • 18
    @S.Lott `What's stopping you from...` Years and years of programming with a completely different mindset, to the point that Haskell code doesn't mentally compute. And of course you are assuming that real projects are always correctly and neatly organized (maybe they are but how's a noob like me to know?) – yannis Nov 30 '11 at 03:03
  • 14
    @S.Lott: I have always programmed in OOP. I have started dabbling in functional languages very recently out of curiosity. You say: "Why ask here?". A: To get some mentoring and insight from people with experience (or experts as the site puts it) who could enlighten me on the subject. Isn't that the purpose of this site? Can't all Programmers or SO questions be replied with: "why don't you find out for yourself"? The answer is yes, you can. But the reason to ask the question is to get better/faster results from someone who is an expert on the subject. – Gilles Nov 30 '11 at 03:25
  • 5
    @S.Lott: if he just reads random code, how will he know whether the organizational decisions they have made are good ones or bad? And why they are good or bad? – Carson63000 Nov 30 '11 at 04:33
  • 1
    http://stackoverflow.com/questions/1135168/organizing-clojure-code – Robert Harvey Nov 30 '11 at 04:41
  • http://en.wikipedia.org/wiki/Standard_ML#Module_system – SK-logic Nov 30 '11 at 07:35
  • @YannisRizos: Interesting points. I don't see what stops someone from reading code and learning from that. Yes. It's different, you're right. What **stops** someone from reading that code? Why isn't that good enough? What more information could we possibly provide? You've made it crystal clear that it's different. What's stopping someone from reading? "assuming that real projects are always correctly and neatly organized" isn't the point. They're all **examples**. What **more** is needed here? The question isn't very clear on why examples aren't good enough. – S.Lott Nov 30 '11 at 10:56
  • @bleakcabal: "To get some mentoring and insight from people with experience". Why isn't an open source project the perfect place for this? Why ask here? Why not find an open source project and read that code and ask those authors? I'm unclear on how we can provide a better answer than the source code of an existing, widely-used open source project. Please explain how our answer can possibly better than real, working code. – S.Lott Nov 30 '11 at 10:57
  • @Carson63000: "how will he know whether the organizational decisions they have made are good ones or bad?" That seems trivial. If it makes sense. If the code doesn't make sense, move on to another project. If there's an issue, ask **specific** questions here about that **specific** issue in that **specific** project's code. – S.Lott Nov 30 '11 at 10:58
  • @S.Lott There's a difference between code making sense and having good organizational decisions for the paradigm and language. A project could be well organized and understandable to someone fluent in the language and paradigm, but not to someone new. I've encountered this myself, even in paradigms that I'm familiar with. – Thomas Owens Nov 30 '11 at 11:57
  • @ThomasOwens: I'm afraid that "making sense and having good organizational decisions" shouldn't be radically different. If "someone fluent in the language and paradigm" uses an organization that does not make sense, that's a bad thing, I would think. An organization that makes sense may be "atypical" for a given language, but that's easily seen by looking at several projects instead of just one. – S.Lott Nov 30 '11 at 13:20
  • @S.Lott It would make sense to the person who created it, as well as other people who were fluent in the language and/or paradigm. But it wouldn't make sense to someone who wasn't. I remember the first time I saw a C project of significant size, after developing in Java and C++ for a few years - it was very unnatural and seemingly bad. However, as I became involved in the project, it made sense. If I was to write a new C application prior to seeing that project structure, I would organize it like a C++ application, but I now see that doesn't make much sense. Now, I would do it differently. – Thomas Owens Nov 30 '11 at 13:23
  • @ThomasOwens: Are you saying that reading code was helpful? Or not helpful? My question to the OP remains: What's wrong with reading code? You seemed to have learned a lot from reading code. Why isn't reading code acceptable in this case? What's wrong with reading code? Your example seems to show the value of reading code. – S.Lott Nov 30 '11 at 13:45
  • @S.Lott If I didn't have an expert C developer to say "this project is actually an example of a well-structured C program" and then explain why the project was structured the way it was, I wouldn't have known. If you just go and look at random open source applications, there's no way to know if it is actually well-structured. I'm no expert on functional programming, but to me, a good answer would identify a project in a functional language that is well structured and organized, and then explain why that structure is the way it is, along with alternative structures that are considered good. – Thomas Owens Nov 30 '11 at 13:51
  • 4
    @S.Lott To summarize, having an expert in the language or paradigm identify a well organized project, identify any weaknesses/shortcomings that might exist in the organization, and explain why is far more valuable than just reading the code and looking at the organization, with the assumption that it's well structured. – Thomas Owens Nov 30 '11 at 13:53

1 Answers1

34

I suspect this depends on language. As far as functional programming, I have mostly dabbled in Haskell, so I'm going to explain how it works there.

Haskell code is organized into "modules" which are basically just collections of functions and data types. Each module is a single file. A module is something of a mix between a Java class and a Java package--the exact scope of what a module does varies. A module also has control over which functions and type constructors to export, and which ones to hide; this is similar to private and public in Java.

In my own programs, I like to have modules do one thing, semantically; this makes them like a Java class except that they might define multiple data types. The modules I use from the standard library, like Data.List, are more like packages--they provide a set of similar utility functions. This is also very similar to static Java classes like java.util.Arrays.

The modules are also like Java packages in that they can be nested for clarity (I do not think this has any effect on the code itself). In general, for a single project, I give it a name (say Project) and have all of my modules be part of this (e.g. Project.Parse and Project.Run). If I was writing code that was more like a library than an application, I would organize it based on what it was doing, like Data.List or Control.Monad. One major difference from other languages is that Haskell encourages limiting IO and putting it all in one place. A large number of modules do no IO at all, and for any given project, I like to have as many modules be pure as possible.

As an example, I am working on a simple programming language I'm calling TPL (for no good reason). For this I have created two simple modules: TPL.Parse which defines the internal representation of the language and how to parse it, and TPL.Run which runs the interpreter and deals with variables and IO. For actually compiling and running the code, there is generally a Main module which is what ends up being the entry point of the program.

There is significant freedom in organizing the functions within a file; this is just what I like to do. I define my data types towards the top, before they are used elsewhere. Right after defining the data types, I implement whatever I need to make them part of their appropriate typeclasses--this is sort of like implementing an interface. Then I follow with logic and various helper functions, as appropriate. Finally, I like to have all of my IO functions at the very bottom ending with main. This makes it clear exactly what is doing any IO and where the program starts.

So, in summary: functions are contained in modules, each of which is made up of a single file. Several modules can make up a program or library; the former generally includes a Main module that is its entry point. Within a file, there are different options for organization, but I prefer to group data types near the top, IO near the bottom and logic in the middle.

Tikhon Jelvis
  • 5,206
  • 1
  • 24
  • 20
  • Long shot since this is such an old answer but do you have an example folder structure that would be standard in Haskell. I specifically wonder if they make a distinction between IO folder name/level with pure ones – Ced Feb 10 '23 at 23:43