User talk:Morn: Difference between revisions
Responses
No edit summary |
(Responses) |
||
Line 12:
::::I strongly recommend you get a feel for the task creation "process", such as it is; I noticed you have domains of interest that we don't have strong task coverage in. Apart from that, code review and linting of existing code is a useful contribution, as well. (You could also learn another language... :) ) --[[User:Short Circuit|Michael Mol]] 02:02, 26 December 2010 (UTC)
:::::I think the site could use a few more games or simple graphics demos as tasks, because too many of the current tasks are heavily geared towards language features such as recursion, complex data structures and such. Of course it's impressive when all you have to do is import the appropriate module in Python to solve a task in [[N-queens_problem#Python|about 3 lines of code]], but then it's not really comparing languages but standard libraries. Not that doing the latter is wrong; I absolutely love Python for its extensive standard library, but I'd like to see more tasks that are more equally within reach of powerful present-day and older languages. --[[User:Morn|Morn]] 11:34, 26 December 2010 (UTC)
::::::[[Remote
:::::::Graphics demos would also show that particularly those languages that are very powerful for implementing algorithms such as CL or Python are relatively inconvenient for e.g. drawing things on screen or producing sound, because you need additional libraries for that. If people ask me I like to recommend Python as the perfect language for beginners (and as opposed to 1980s BASIC, you are less likely to outgrow it completely), but some things like graphics output have not become easier in newer languages at all. JavaScript with the canvas element or perhaps Processing.js really fill a niche there.--[[User:Morn|Morn]] 15:10, 26 December 2010 (UTC)
:::::::As for the library intercomparison, I agree that's interesting, but then you will probably not only want to show ''how'' it's done, but also benchmark it, e.g. regular Python vs Psyco vs NumPy execution speed. And you might have to rethink the layout, because putting all solutions for a given problem on a single page might lead to overlong pages then.--[[User:Morn|Morn]] 15:10, 26 December 2010 (UTC)
::::::::Yeah, that's a known problem, and we've banged into it a few times already. There are some task-refactoring workarounds. Splitting solutions into subpages ([[RCRPG]], [[RCBF]], [[RCSNUSP]], [[RCHQ9+]], etc.)) and finding common differentiations in existing tasks ([[Hello world/Text]], [[Hello world/Graphical]], [[Hello world/Standard error]]) are the two most-widely-implemented, right now. We're settling into using Semantic MediaWiki for dynamically populating task pages based on example properties, but it's taking time to get familiar with Semantic MediaWiki, and to figure how to build the needed system of templates. --[[User:Short Circuit|Michael Mol]] 15:47, 26 December 2010 (UTC)
:::::::I'm wondering if there should be a better way for source code comments. I don't mean putting // or REM or # in the source code, but a template solution that e.g. displays a red dot in front of a line and when you hover over it with the mouse pointer, it shows the comment. Right now explanations are relegated to Talk pages and that seems like an inconvenient solution. --[[User:Morn|Morn]] 15:10, 26 December 2010 (UTC)
::::::::Explanations currently ''should'' be placed in proximity to the code, either as language comments or next to the block of code. Some contributors, for various reasons (I assume concerns about oververbosity are one of them), put their explanations in the Talk pages. Sometimes, questions are raised about whether/how an example solves a task, and the matter is worked out in the talk page. (In some of those instances, additional documentation of the code example may well be warranted.) --[[User:Short Circuit|Michael Mol]] 15:47, 26 December 2010 (UTC)
| |||