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)

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)

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)

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)