Talk:Modular programming

Modularity (programming) vs Modular Programming

I believe it is a mistake to have the "Modular Programming" link to the "Modularity (programming)" page. The "Modularity (programming)" page is more of an abstraction whereas Modular Programming represents a set of practices that evolved in the 1960s. For a large segment of programmers the concept of Modular Programming was a paradigm shift that led away from procedural code that often took the form of "Spaghetti code" -- inline statements infested with "go to" operations that jumped forward and backward, into and out of loops, hither and yon.

Modular Programming and Structured Programming concepts evolved in the same time period, and some sources consider the topics synonymous; however, the difference is that structured programming absorbed the modular programming movement.

I'm not suggesting that is a mistake to identify the principle of modularity or even the use of the term of modular programming. My focus is on the history of Modular Programming. --YORD-the-unknown 18:59, 27 July 2006 (UTC)

Follow-up: I think the best explanation for why "Modular Programming" should be restored as a subject begins with the generally acknowledged claim that Alan Kay became aware of the concept of modular programming when he observed an assembly language program written by an anonymous U.S. Air Force programmer prior to 1961. The program was a set of methods and concepts that were in use, and the concepts embodied in that program represented a new programming paradigm even if only one person in the world was using it. The program that Kay saw went forward with him and provided an inspiration that eventually led to Object-Oriented Programming.

The best information I have been able to find, so far, is that the subject of Modular Programming was be presented at the "Modular Programming Symposium" of 1968. There were other works and that preceded this event but those works are for computer historians to put into context.

Speaking from personal experience, I was introduced to Modular Programming by my own anonymous programmer (meaning I can't remember his name) in 1969. He implemented MP techniques into his IBM 1401 Autocoder program, and the minute he got his first compile and test he could not wait to explain the concepts to someone. These were revolutionary concepts in my mind and I began my own modular programming at once.

As I mentioned previously, the Modular Programming paradigm was rapidly absorbed into the Structured programming revolution that exploded into widespread use in 1974.

Here are some references for further consideration:

1) IEEE Annals of Software Engineering Volume 22 Number 2, pages 61-63, 66, April-June 2000 The Origins of JSP and JSD: a Personal Recollection by Michael Jackson (http://mcs.open.ac.uk/mj665/JSPDOrgn.pdf)

"Around this time, in the mid-1960s, larger Random Access Memories (as large as 256KBytes) were becoming commonplace and data processing program sizes increased dramatically. As programs grew larger, monolithic program texts became less and less practical. ‘Modular Programming' became a widely recognised concern, and the first shoots of the ‘Structured Revolution' began to appear. Larry Constantine ran a Modular Programming Symposium in 1968, with contributions from Constantine himself and from George Mealy, along with several others."

2) Dr.Dobbs's Portal, June 29, 2001, Management Forum: Hiring the Best, Larry Constantine (http://www.ddj.com/dept/architect/184415690)

"Structured design did not, however, suddenly spring from the ground, fully formed in 1974. The foundations had been laid much earlier. The basic methods, models, and concepts were already well developed when I presented a paper at the National Symposium on Modular Programming in 1968, the same year the ACM published Edsgar Dijkstra’s duly famed letter on the harmfulness of GoTos. In my archives are documents going back to 1966 describing notational innovations that have stood the test of time. Those little arrows indicating information flow in the newly minted Unified Modeling Language, for instance, come from structured design by way of the Uniform Object Notation developed by Meilir Page-Jones, Steven Weiss, and myself (see “Modeling Object-Oriented Systems,”Computer Language, Oct. 1990)."

Action: I hope my observations demonstrate why "Modular Programming" should not link to "Modularity (programming)". I would like to get some feedback from those concerned with this subject before making this change. --YORD-the-unknown 20:31, 29 July 2006 (UTC)

Follow-up 2: In the past couple of days I’ve had an email exchange with Meilir Page-Jones, a well-know author, educator and authority on the Structured and Object-Oriented paradigms.

Mr. Page-Jones corrected my assumption that Modular Programming had been absorbed by Structured Programming. The truth is that Modular Programming and Structured Programming were on separate tracks. Structured Design (Constantine et al) actually absorbed Modular Programming. Structured Programming (Dikstra et al) and Structured Design continued on separate but compatible tracks.

He also confirmed, “Modularity is a principle. Modular programming/Structured Design represents a set of techniques for achieving modularity." --YORD-the-unknown 17:56, 4 August 2006 (UTC)

3) I agree with YORD with respect to "Modular Programming" perhaps linked but not merged with the term "Modularity (programming)". I am struggling with the term "Modularity" within the domain of "programming" with respect to "composability" and "producability". My concern is that complexity (software) as related to the notion of emergence (software systems engineering)returns to the user in unpredictable ways. Where emergence is consistent to and enhances the software functionality, that is positive and could/should be encouraged, but discouraged if emergence is not consistent nor enhancing. Since the property of emergence is largely or wholly unpredictable and thus is uncontrollable, discretion to enhance 'good' emergence is limited. Modularity, it seems to me, represents a means to the end of composing software that can be complicated but need not be complex. This is the condition confronting systems development today, in my opinion. How to develop code that may be complicated but not complex. As of the current readings available, modularity (programming) is not well enough understood or defined except in colloquial ways.

By-the-way, I am frustrated in the conventional use of the term "artifical intelligence". To me this is an oxymoron, especially in the current state of understanding regarding how the brain works. In this respect I agree with Peter Naur in his article "Computing vs Thinking", in COMMUNICATIONS OF THE ACM January 2007/Vol. 50, No. 1. I also feel that the use of the term "artificial intelligence" does a disservice to our endeavors, misleads and over sells the advancement of the discipline/science, and misleads many of the 'educated' in the field of cybernetics into "believing their own 'press'". I wish wikipedia could be a vehicle for eliminating the use of these and related terms. 160.91.241.63 18:49, 14 February 2007 (UTC)strawdog

I apparently undid the split, as the former "Modular programming" article was deleted, and I moved this article back to that name. The difference between the two was not sufficiently explained in either article, and if one is merely an "abstraction" of the other, then there's no reason I can see that they would need to be separated. While your interest may be in the "history" of this programming paradigm, there is again no reason why you can't simply create a "history" section in this article. If the two concepts are truly distinct, WP:N applies, and whatever movement that you are referring to is apparently not worthy of mention other than in primary sources. Besides that, article titles should refer to the most commonly recognized subject -- the idea that an obscure theory from the 60s should take precedence over a modern and widely used practice is another problem with the way the split was handled. Ham Pastrami (talk) 22:25, 14 April 2008 (UTC)

Hi Ham Pastrami... sorry I haven't been around lately to respond to your proposal. Well, if a researcher wishes to understand the roots of a technology, I submit that he or she really need to keep this historical perspective. It is especially important to recognize that up though the late 1960s and early 1970s, there were many practitioers using modular programming techniques that came from the original papers from Constantine, et al. The divergence from the Modular Programming techniques to the Structured Programming technquiues was a technological event, and the principles and condiditons that led to that divergence is worth perserving. Most importantly, the Modular Programming was related to the subject of Modular Programming as we use it today only in the sense that it was an influance.

I will make an attempt to contact Constantine again and see if he will release the paper from the "National Symposium on Modular Programming of 1968". I believe this will establish a major event of the software development timeline, and give additional weight to my assertion that Modular Programming warrants a historical reference in the evolution of software developoment technology. My biggest concern is, if we don't record these topics here in Wiki, they will be much more difficult, if not impossible to reconstruct should some researcher wish to discover these facts that may die when the authors die. Larry Constantine is a major figure who gave us many of ther terms we now use today. Hope this Helps, YORD-the-unknown (talk) 20:58, 19 July 2008 (UTC)

First, producability is no English word at all, you mean producibility. Secondly, I agree with Ham Pastrami: Wikipedia needs to describe first the state of the art and then possibly elaborate on the history - this is widely accepted practice, and moreover some concepts were not fully understood when they were discovered. For instance, modularity was misused until Parnas explained how to best modularize software, i.e., by the criterion of information hiding, in 1972 (On the criteria to be used in decomposing systems into modules). If we were to discuss this point, we could mention the older practice only in an historical section. The target of a Wikipedia article is much broader than "researchers", and the historical development of concepts is normally kept separated (for instance, it is not discussed by the introduction). Finally, it is fine two discuss together two strongly related concepts. --Blaisorblade (talk) 01:22, 24 October 2010 (UTC)

Let me start over: the concept of software modularity is well understood and discussed in the relevant literature, but I find no clear definition for "modular programming" in nowadays literature. It seems there was such a movement in the '60s, so somebody might want to write an article on that - no content about this exists here. What we need is a discussion about modularity, and about the general concept of module in the practice of programming languages - maybe they can be discussed together until the article doesn't grow enough, and split afterwards.--Blaisorblade (talk) 01:22, 24 October 2010 (UTC)

Let me first state that I have over 40 years of programming and computer science experience and experienced the advent almost all of what is being described here first hand. I have extensive experience in assembler, FORTRAN, COBOL, C (K&R and ANSI), C++, Java/J2EE, C# and further experience with Pascal (both Wirt, whom I met with several times in Colorado, and ANSI) Algol 60, Algol 68, Ada, Anna and others too numerous to mention, all on a large variety of mainframe, mimi, micro systems including GECOS, EXEC8, OS/MVT/VS2, GCOS, VME/B, Tops 10 and 20, UNIX (system III and V), Solaris, Linux, Microsoft from DOS through to current Windows, all in a variety of academic, commercial and military environments on 3 continents.

What motivated modularity, modular programming, structured programming and design and object oriented programming and design were observations about complex software systems, namely the exponentially increasing difficulty of economically creating systems that worked correctly (i.e. were bug-free systems)and finding design methods for solving the complexity problem that did not constrain computability. I agree with much of what is already stated in the discussion. I also believe some of it comes from perspectives that see only part of a much larger tapestry of what was going on in computing at the time. I'd like to add a larger perspective based on first-hand experience. Hopefully, that perspective may be useful in crafting an article here in Wikipedia that gets beyond some of what I perceive as artificial distinctions.

Modularity and modular programming were interwoven with structured programming and structured design and OOP/OOD at the time. All are separable as intellectual concepts, but they are historically joined at the hip. Furthermore, dispensing with important concepts as being irrelevant because "nowadays" literature does not address them directly is rather like dispensing with concepts from von Neumann machines, the Church-Turing thesis, Alonzo Church's Lambda Calculus, Alan Turing's machine, S. C. Kleene's Meta-Mathematics and Gödel's Theorem as irrelevant because "nowadays" computer literature does not directly discuss them. The reason it doesn't is because it more-or-less assumes them and currently used programming languages strongly embrace the practical outcomes of those concepts and that programmers more-or-less write software consistent with those outcomes. I also believe that an article that discusses concepts such as modularity and modular programming from current programming and software languages and practices and then shows their historical roots and the evolution to them as motivated underlying concerns and objectives to be a most useful arrangement. After all, most of the readers aren't likely have my over 4-decade experience base and are far more likely to be familiar with current programming languages and practices.

Edsgar Dijkstra observed that there are only two real components to software design methods and, thus, tools. The first is abstraction and the second is decomposition. It is decomposition that led to modularity and abstraction to the nature of modularity. Further, an understood requirement was that the proposed methods would not artificially limit computability. A simple test for acceptable proposed programming and design mentods would be to ensure that whatever design method(s) were embraced could implement a Turing Machine and, therefore, could implement all computable functions. Two very famous influences on the thinking at the time should be noted here. The first is Böhm and Jacopini's paper on Flow diagrams, Turing machines and Languages with Only Two Formation Rules, published in CACM 9(5), 1966. That paper normalized flow diagrams down to 3 formations and, subsequently, to two and then showed that the formations encompased all computable functions, i.e. they could implement a Turing Machine. It is direct evidence that proposed programming programming and design practices and programming languages needed to not artificially limit computability. The second was Dijkstra's famous letter to the ACM in 1968 and published in CACM 11(3), 1968 with the title Go To Statement Considered Harmful. Wilst the first was interesting and extremely important from a theoretical perspective, the second was the one of the first comments on software programming and design practice that got significant note by the programming community at large. It is also widely recognized as the letter that launched a revolution in programming and software design practices.

In commercial computing, the burning question at the time was how to decrease the human difficulty of creating error free complex software systems without limiting computability or exponentially increasing costs and what architecture(s) of abstraction and decomposition might be useful in achieving these goals. One of the concepts developed at the time was an understanding of how modules are coupled. The question of module coupling led to distinguishing among data coupling, control coupling and side-effects. Data coupling was considered the most desirable and control coupling the least desirable for reasons of abstraction and simplicity of module relationships. Furthermore, side-effects were considered very undsirable, especailly any module coupling based on them, for the same reasons that control coupling was considered highly undesirable. By using data coupling in design and programming, one could abstract the design of a module to only its external behavior and know nothing about its internal construction. Also, modules could be programmed independently of one another since the only dependency amongst them were their data interfaces. Control coupling to a module, or even worse, side-effect coupling, by contrast, required a programmer to know about the internal construction of a module, and intimately tied the use of the module to its internal construction. The outcome of all these considerations became what was popularly known at the time as Structured Programming and Structured Design. Much of the popular and reference literature on these subjects included works by C.A.R (Tony) Hoare, Edsgar Djkstra, Tom DeMarco and Ed Yourdon. The elements of what happened at the time may be summarized as follows. All computable functions are possible with only 3 constructs, sequence, selection and interation including hierarchic usage of them. Modern languages implement sequence as statements and functions; selection as if-else and case (or switch); and iteration as a plethora of constructs including, but not limited to, for loops, while loops and do-while loops, and recursive functions, the main differences amongst these being the determination of loop invariance and termination conditions. Abstraction and decomposition are achieved by limiting the relationships amongst decomposition elements to data coupling.

In academia, I believe the burning question at the time was similar to commmercial computings question, but more focused on what academics called program "correctness" and ensuring complete computability than software economics or the scale of commercial systems and data repositories at the time. Furthermore, the tools, methods and languages in use by academia were far more oriented towards their endeavors than any real practical or economical use in large scale commercial, government or military systems, especially with very large volumes of data and the extant commercial database systems (or engines) at the time. However, despite their different foci in practice, the underlying motivations were nearly identical and sprang from the same origins. Namely, finding out what it takes to have correctly operating complex software systems that are economically feasible, and then doing what it takes.

I would like to point out that the modularity objective was not least or no coupling at all, but rather data coupling exclusively. I believe the first part of the article should be amended to reflect this concept of coupling instead of the statement that the objective was to have as few dependencies as possible. The objective was (and still is) to have zero (or as close to zero as possible) dependencies amongst modules based on the internal construction of modules and use data dependencies instead. This includes eliminating the creation of and, especially, dependencies on side-effects from modules. Furthermore, one of the objectives was to have data constructs be cannonical in nature. That is, they would be abstractions of real world objects and their behavior. All this thinking in commercial and academic circles existed before 1970. Structured and modular programming and design and came into commercial widespread use by 1974 and was ubiquitious by 1980.

Finally, notwithstanding common claims that OOP and OOD have no relationship whatsoever to structured and modular programming, OOP and OOD are also outcomes of the motivations behind structured programming and structured design within a modularity that embraces abstraction and decomposition using data coupling amongst modules. Furthermore, OOP and OOD as well as languages that are considered object oriented are an embodiment of a direction that embraces hierarchic programming limited to using sequence, selection and iteration with an abstraction and decomposition oriented on data coupling. The concept of "messages" amongst modules is a direct embodiment of data coupling as opposed to control coupling. The concept of encapsulation is a direct embodiment and furthering of the kind of abstraction that data coupling amongst modules is supposed to facilitate. I believe that something to keep in mind is that the early languages that directly embodied OOP/OOD constructs, e.g. Simula 67 et al, were principally programming languages used in academic research and had little or no implemention or usage in large-scale commercial, government or military systems which were, at that time, dominated by assembler, FORTRAN, COBOL and C programming. Hence, whilst OOP/OOD implementations were going on in academia, and academia pursuing the the same objectives from more theoretically friendly languages and methods, the main body of programmers and software designers were grappling with how to accomplish the same ends with the same underlying concepts using the tools at their disposal, mainly assembler, FORTRAN, COBOL and C. Whilst the underlying considerations were rooted in the same concepts and motivations, the taxonomy and vocabulary evolved within partitioned environments. I believe that the partitioned environments between academia and commercial systems history led to arbitrary and artificial distinctions between modular, structured and object oriented concepts, especially when it comes to their fundmental motivations and theoretical underpinnings.

I believe something else to take note about when looking at the historical evolution of structure, modularity and object orientation in programming and software design is the commercial motivation behind ownership of the intellectual ideas at the time. Just as there are now, there were then individuals who made their substantial living from promoting the next new panacea for solving the great commercial computing problem at the time and selling resources (e.g. books, seminars, training courses) to do so. However framed by commercial self-interest, the great problem was and still is the economical creation of complex error-free software systems. A lot of hype was generated by leading commercially published voices and new taxonomies with attending vocabularies created by many of them in attempts to lay claim to complete originality and exclusivity. This is especially the case with early OOP/OOD versus structured programming/design in which there were, at times, holy wars. Distinctions between modular programming and design, structured programming and design and early OOP and OOD are artificially amplified by commercially self-serving taxonomies and vocabularies still extant in the literature. For those of us who were there at the time and personally experienced the several environments, we recognized the evolution and development as a continuum of several threads of highly related issues and concepts regardless of the names attached. Lind j a (talk) 00:20, 27 November 2011 (UTC)

Plugin

How do the topics plugin, extension (computing), and add-on fit in here? --Abdull (talk) 22:16, 29 January 2008 (UTC)

I would say that they are applications, or examples, of modular design in software. Plug-in is especially relevant, as software can be designed from the ground-up using a plug-in based architecture -- like Eclipse (software). Add-ons are probably not exactly in the same realm, as they can be created without looking at or interfacing with the original program code. Extensions are really the same thing, it's a redundant article that should probably be merged somehow. Ham Pastrami (talk) 22:30, 14 April 2008 (UTC)

VybeEra VybeEra (talk) 05:57, 8 November 2022 (UTC)

Block IP

How can we request the blocking of 24.149.222.5? This is a anonymous user with static IP who has been vandalising this and other articles for the period of more than a month. See his "contributions". We can safely undo in an automatic way all his changes to any article too. --Antonielly (talk) 17:45, 11 November 2008 (UTC)

List of "modular programming" languages

The list of languages supporting the concept of a "module" seem to just grep for the term "module" in the language manuals - Java is not included, I guess, because currently it supports packages and not "modules". I would remove such a list altogether, both because it lacks a citation, and because it seems Original Research, and stupid one.

Let me show how stupid it is: it seems that the next Java revision will support the concept of modules, imitating the concept of assemblies in .NET. That's just a packaging unit above the "package" level - a module is made of more packages. So it should be included. But in Python, a package is a collection of modules. In C#, an assembly is also a collection of... namespaces (I'm not sure). Yet, we are all talking about the same thing - more or less.

It would make more sense to define what a module is and show different forms of support for modularization. C has includes, essentially a hack. In C++ you have includes and namespaces. In modern languages, instead, accessing a namespace automatically looks for the definitions related to a namespace - "using namespace std;" does not include any header, while Python's "import os" actually imports all the declaration from the "os" module, putting them into a namespace also named "os".

Disclaimer: I'm a PhD student in Programming Languages but I never formally studied a definition of a "module" programming language construct in general. However, I've studied deeply the underlying design principle - and the current article is quite bad at describing it. I'm therefore flagging relevant sections with appropriate further templates. --Blaisorblade (talk) 00:53, 24 October 2010 (UTC)

I wondered about this too, and thought it had been eliminated on the basis of missing interface-implementation separation. But on those grounds, the scripting languages (that apparantly were added later )have to go too 88.159.66.26 (talk) 20:08, 26 October 2010 (UTC)

I'm not sure I would agree that C's form of modularisation is #includes. Whilst you could write several .c files and #include them all into one big, compilable file, that isn't what's usually done. Instead, individual .c files are compiled into object files, which in turn are linked together (with other libraries of object code) into an executable.

I think the namespace thing is a bit of a red herring too, since you can have a highly modular program within a single namespace, and multiple namespaces in a monolithic program. Namespaces are used either to avoid naming conflicts, or for some abstract reason (e.g. to delineate ownership).

I agree that this article is poorly written and self-contradictory. It begins with a definition that's dubious at best, but goes on to provide a great definition of a monolithic program - any program where the smallest usable component is the program itself. I think as far I'm concerned Modular programming is amonolithic programming (i.e. any program that is not monolithic is modular by definition). Djonesuk (talk) 16:26, 1 November 2010 (UTC)

I'd say #include and the systematic use of defines to avoid multiple including is a way to manually approach modularisation. It's the same as like using a struct with function pointers to emulate OOP. Not the same, not as safe, not as easy, but with C it is the best thing achievable. Moreover the way that e.g. a Pascal or Modula-2 "auto-make" a binary is impossible with C too. You always need to manually/externally keep an compilation order.

88.159.64.210 (talk) 16:29, 18 December 2010 (UTC)

I would not consider #include to be a rudimentary form of modular programming, it may allow for it, but it really has nothing to do with it. C is completely capable of being fully modular, if not more so than others due to it's low-level memory access.

Neither would I. But it is an attempt to emulate modular principles with what is available. That is something else than being a modular language. (iow the concept vs the language support). I'm not sure if C can be considered modular. The meaning of an header can be modified by the preprocessor history till then, and thus does not uniquely represents an interface to an implementation I've no clue what the memory access remark is supposed to demonstrate? 88.159.64.210 (talk) 10:40, 10 May 2011 (UTC)

I would describe modular programming as analogous with legos. You start at some point, and build up. Each block is a piece of the greater structure. You can move blocks (or groups of blocks) to other structures copying their functionality to the new structure without everything falling apart. They´re both interdependent, and independent at the same time. The whole part in the article about trying to minimize dependencies is absolutely wrong, it's more the direction that the dependencies are going, they should be upper to lower. As in no foundational component can be reliant on a component that is less foundational. That is to say, lego blocks sit on each other, therefore they rely on their foundation, not the other way around. There my 2 cent. —Preceding unsigned comment added by 96.45.180.110 (talk) 00:11, 27 December 2010 (UTC)

I would also like to lend my voice to this - I'm no expert in programming but I was really surprised to see the list and that the writer asserted that even object-oriented (OO) languages like Java and C++ did not, at any time, support modularity. I would have thought that the concept of OO programming naturally lends itself to that of modularity and I find it illogical for C++ not to "support" modularity. This is so, so odd and I would appreciate if the experts among us can ensure that it is clarified in the article or let the list be expunged! - BroVic (talk) 06:24, 18 August 2016 (UTC)

Old stuff

Uttal, as far as I can tell, is not a staunch defender of domain-general processing, or at least not in The New Phrenology. The issue in TNP is whether using neuroimaging techniques to localize cognitive functions is a plausible line of inquiry. Whether you can localize cognitive functions and whether these functions are independent modules are not logical equivalants. This is a serious misrepresentation. A better source of domain general processing would be "Rethinking Innateness" by Jeff Elman, et al. MIT Press 1996.

---Does this have anything to do with the topic? Did someone botch a cut-and-paste? And what is up with these two biology references?

    Guimerá, R. & L.A. Nunes Amaral (2005). Functional Cartography of Complex Metabolic Networks. Nature, 433: 895-900.
    Yang, A.S. (2001). Modularity, Evolvability and Adaptive Radiations. Evolution and Development, 3:2, 59-72.

Are these really applicable to Modularity (programming)? Vreejack 23:46, 1 January 2007 (UTC)

The lack of answers means this stuff was indeed irrelevant here. I don't think stuff can be just deleted, but I had to move it away from the top of the page - it was too bad there.--Blaisorblade (talk) 01:25, 24 October 2010 (UTC)

Incomplete sentence

I noticed the following in the first paragraph:

" It is also called "

What's up with this? It seems like this editor had something to say, but just didn't finish the thought. I was going to delete the fragment, but left it in because of the very long quote. Peter Flass (talk) 12:32, 5 June 2012 (UTC)

References

How do modules differ from singletons?

I can't seem to find anything that makes modules as described in the article different from singletons. Glyph27notfound (talk) 14:47, 14 July 2012 (UTC)

Modules need not have single instantiations. The concept of modules does not require classes either. It's a much less well defined concept as far as I can tell. Diggory Hardy (talk) 18:31, 12 May 2013 (UTC)

History

This looks more like a short summary that should go at the top of the page. Mostly it's not history. Diggory Hardy (talk) 18:45, 12 May 2013 (UTC)

Advantages

This section is wooly (no citations, vague language) and is not balanced by talking about drawbacks (e.g. modifications of a module's interface having to touch on a lot of code, the advantages for testing only being realised with considerable extra work writing tests, and the often large amount of extra code required (over if logic)). Should it be deleted? Complemented by a "drawbacks" section? Renamed "comments"? Diggory Hardy (talk) 18:45, 12 May 2013 (UTC)

wut

What does "modularity" have to do with "stepwise refinement"? Modularity is all about abstraction and separation of concerns. A user of a module does not need to be concerned with its concrete implementation, so long as the module's structure matches its given signature. Of course, modular programming makes stepwise refinement easier by allowing programmers to handle the evolution of each module's internals independently, but even if this were not the case, stepwise refinement would be feasible. — Preceding unsigned comment added by Catnaroek (talk • contribs) 15:02, 27 June 2013 (UTC)

C and C++

While COBOL and Java appear in the list of programming languages that support modules, I see that C, C++, and C# are noticeably absent. Is this just an oversight? — Loadmaster (talk) 22:55, 29 January 2014 (UTC)

Higher order modules

OCaml provides higher order modules. Such we mention this explicitly? I think Racket has something similar. — Preceding unsigned comment added by ShalokShalom (talk • contribs) 10:30, 11 June 2019 (UTC)