Category talk:Solutions by Programming Task

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...

A string is always a data structure, even if it's a built-in type. Being a data structure is a conceptional property; a string is a data structure because it is decomposable into individual "data elements" (the characters). The same is true for arrays (which for most languages are built-in as well), lists (which are quite seldom built-in), etc. Especially being a data structure is in no way the opposite to being a data type; quite the opposite: In a strongly typed language, you'd always try to make each data structure to a data type (or a set of related data types, e.g. for each data type, there's usually the corresponding array type, which is another data type, and at the same time a data structure).

About function as an argument, that's clearly debatable. It's clearly a corner case, because some languages have data types for this (like function pointers in C and C++), while others don't (for example Standard Pascal allows functions as arguments, but doesn't define a data type for that), and in functional languages even the function itself is a data type (closures). There are other debatable cases as well (that's a general problem with categories: Real world categories are almost always fuzzy at their borders).

About introspection: I don't see how you could put that into "Program execution environment". The program execution environment is everything external to the program. Introspection, OTOH, is about things internal to the program, namely its own objects.

"Simple windowed application" quite clearly belongs under GUI.

About SQL: That's an interesting border case. On one hand, SQL can be seen as a language on its own (and would therefore be adequately be treated through the language categorization); OTOH database specific things might well be worth their own category. This would of course give yet another fuzzy border, because not everything you do in SQL is database specific (simple example: adding two numbers is nowhere database specific, even if you use it in a database context).

A note about the unevenness: I'm quite sure that the other categories will grow. Especially I'd be surprised if in the long run, the GUI category (which at the moment is very small) will not be one of the biggest categories.

BTW, you forgot to sign your discussion entry (--~~~~). --Ce 06:39, 26 March 2007 (EDT)

Regrouping?

Would it make sense to combine many of those file-system kinda things into a single task? In many languages, testing for the existence, readability and size of a file uses effectively the same mechanism/s (E.G. in TCL it would be "file exists $fname" and "file readable $fname" and "file size $fname" etc). I'm not sure it really warrants a "category" if most(?) languages will deliver the answers to all these questions by invocation of the same underlying mechanism. (In IDL you'd call result=file_info(fname) and the result is a structure with elements "result.exists" and "results.read" and "result.size" and so forth; thus all of these are the same task and you simply look at a different elements in the returned structure).

Just a thought ... Sgeier 18:37, 4 October 2007 (MDT)

Well, instead of regrouping, another idea would be to make a "bigger" task which would re-use all the other codes. If I understand what you're saying, you want to make a page which would list almost *everything* you can do with say, file interaction. Would you mind creating a post on the Village Pump to discuss this ? --CrashandDie 01:16, 5 October 2007 (MDT)

Further task divisions

I think this category is getting a bit big. Maybe it could be divided up more than it is now. Category:Programming Tasks can still be a big pile, but this category could be divided. We need some suggestions for new groups, though. What do you guys think? --Mwn3d 03:12, 10 August 2008 (UTC)