Category talk:Solutions by Programming Task

From Rosetta Code

I think these need to be organized/categorized somehow. For example there's tasks that are meaningless for anything other than SQL-alikes. Or tasks that expressly require object-orientation. Or we could have a section that deals with GUI'ish programming stuff. That kind of thing... Sgeier 01:01, 24 February 2007 (EST)

Yeah. I've been thinking about how to do that. I think the solution will be to add tasks to subcategories without removing them from this category. --Short Circuit 12:24, 26 February 2007 (EST)

Suggestion for sub-categories

I think the following sub-categories would make sense in addition to the existing Control Structures category (there are probably better names for some of them):

  • Basic Data Operations: Here go all the fundamental operations on basic data types.
Articles: Address Operations, Basic pointer and reference operations, Function as an Argument
Add {{basic data operation}} below {{task}} to appropriate articles. --Short Circuit 18:09, 21 March 2007 (EDT)
  • Data Structures: Anything covering data structures and how to create and read them. Only the most basic algorithms should be here.
Articles: Assigning Values to an Array, Classes, Collections, Compound Data Type, Create a Sequence of unique elements, Creating an Array, Creating an Associative Array, Data Representation - Controlling Fields in a Structure, Data Representation - Getting the Size, Data Representation - Specifying Minimum Size, Defining Primitive Data Types, Enumeration, Introspection, Polymorphism, Retrieving an Element of an Array, Singly-Linked List (element insertion), Singly-Linked List (element), String Byte Length, String Character Length, Table Creation, Table Creation - Address, Two-dimensional array where both dimensions are given at run time
This category needs to be further parted out into categories representing actual structures, operations inherent to them, and possibly their representation. I did create {{data structure}}, though. It should be placed before {{task}}. --Short Circuit 19:17, 21 March 2007 (EDT)
  • Basic algorithms: For all other "pure" algorithms. Those algorithms of course often will make use of the data structures above, but then their point should not the data structure itself, but some operation of it (e.g. sorting, combining two data structures into another one, etc.).
Articles: Apply a callback to an Array, Bubble Sort, Change string case, Copy a string, Creating a Hash from Two Arrays, Increment numerical string, IsNumeric, Product of Array, Regular expression matching, Select from Array, Sorting Using a Custom Comparator, Sorting an Array of Integers, Sum of Array
  • Input/Output: Everything related to I/O, serialization or the file system
Articles: DOM XML Serialization, File I/O, Object Serialization, User Input, User Output, Walk Directory, Walk Directory Tree, Zero fill
  • Program execution environment: Everything which relates to the environment the program executes in (except that strictly speaking, File I/O also relates to the program's environment).
Articles: Command Line Arguments, Discover the Hostname, Execute a System Command, Fork Proccess
  • Concurrency:
Articles: Metered Concurrency, Simple concurrent actions, Synchronous Concurrency
  • GUI:
Articles: Creating a Window
  • Complex algorithms and applications:
Articles: Creating a SOAP Client, SQL-Based Authentication, Towers of Hanoi, XML and XPath

Any thoughts?

Thank you! Thank you! Thank you! I've been wanting to do this for a couple months, but I just haven't had the time to think through the categories.
I would suggest creating a template structurally and organizationally modeled after the {{Task}} template, that would be added to each page depending on its subcategory. More on this later. -Short Circuit 15:55, 21 March 2007 (EDT)
I like this as a first cut. There's a bit of uneveness, where about half the articles are in one category - needs a bit of cleanup. I guess I'm not sure about the whole "data structure" thing - in the end a string can be a data type - or it can already be seen as a data structure. (In some languages it'll be the one and in some the other). Is "function as an argument" really about data types? "Introspection" should probably be more 'programming environment' than 'data structures'. "simple windowed application" should go under GUI, I suppose. It might also be beneficial to have a category dealing with SQL type things, as their general use lies in a somewhat different domain than more general-purpose computer languages; this could be kinda overlapping with the other categories, I suppose...