Talk:Modular programming

message: How do the topics plugin, extension (computing), and add-on fit in here? --Abdull (talk) 22:16, 29 January 2008 (UTC)
replies: text: 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)
thread_title:  Plugin 

message: 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)
thread_title:  Block IP 

message: 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)
thread_title:  List of "modular programming" languages 

message: 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)
replies: text: 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)
thread_title:  Old stuff 

message: 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)
thread_title:  Incomplete sentence 

message: 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)
replies: text: 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)
thread_title:  How do modules differ from singletons? 

message: 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)
thread_title:  History 

message: 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)
thread_title:  Advantages 

message: 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)
thread_title:  wut 

message: 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)
thread_title:  C and C++ 

message: 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)
thread_title:  Higher order modules