Category talk:Solutions by Programming Task: Difference between revisions

Removed older discussions keeping a previous set of subcategory suggestions
(Removed older discussions keeping a previous set of subcategory suggestions)
Line 1:
== Previous Suggestion for sub-categories ==
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... [[User:Sgeier|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. --[[User:Short Circuit|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):
Line 23 ⟶ 20:
* '''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 <nowiki>{{Task}}</nowiki> template, that would be added to each page depending on its subcategory. More on this later. -[[User:Short Circuit|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 (<nowiki>--~~~~</nowiki>). --[[User:Ce|Ce]] 06:39, 26 March 2007 (EDT)
 
== Regrouping? ==
Anonymous user