I wouldn't expect a beginner to design a shellsort, mergesort or the something, or even know what big-O means, but implementing one (after being shown how they work) is a good exercise for a beginning programmer to introduce the concepts. Obviously, if possible, in a "real" program you should use some existing efficient sort already provided, unless you have very specific requirements.

_________________
KGS 4 kyu - Game Archive - Keyboard Otaku

About programming languages I just discovered an interesting one julia ( http://julialang.org/ ) IT happen to be just started so evolution might happen but it is interesting that it is quite high level (maybe not as much as python) but rut quite fast (maybe not as much as C) so I decided to use it for writting a go engine.

I also saw Julia a few days ago (HackerNews). Although it looks promising (code is very clean), if you are in for the raw speed nothing beats C (except assembler), unless the algorithm or design are very screwed up. I wonder if the name is a reference to Gaston Julia (would bet for a "yes", but...).

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net

Actually the assembler vs. C run-time speed comparison is not necessarily true anymore. Nowadays C compilers do very advanced optimizations. Even the easy to understand ideas are cumbersome to do while manually coding in assembly (like changing the order of unrelated computation to reduce memory access). Furthermore, modern CPU's execution got very complicated with advanced features (out-of-order execution, speculative branching, more stuff I don't know about). In short, not only you would go mad writing assembly code, but also a decent C compiler would beat you in execution time (as you say, assuming C implementation is not a total screw up).

Btw. I love Python. A language named after Monty Python, how cool is that (spam spam spam spam spam spam)

Even pipelining (Pentium I) already made optimizing C compilers almost as good as the best "human assemblers". The only point of writing assembly is optimizing very very small computations repeated over and over, in case of need. I have never needed anyway, C is fast enough. And when it is not, it means you need to improve the algorithm. And I also love Python as a language, when I need to do something "quick and dirty" I use either Lisp or Python, depending on what's more suitable.

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net

Mostly true, but I think I learned the O(n) characteristics of several sorting algorithms before I could do "hello world" in any language.

I did a lot of math and logic in college and grad school, but before age 23, all I'd ever done with code was a short and disastrous encounter with Maple in high school.

I will concede that that's unusual.

_________________
Occupy Babel!

Absolutely not!

Code that is not clearly commented is an abomination.

Ideally the "comments" go in before the code is written. When I used to do this I would design the program "in words" formatted according to the rules for "comments" in the target language and only later when the design has been analyzed as correct insert the actual code that implemented those words.

Maintainers not maintaining comments? That's a shop discipline issue.

Mind, in some cases I was sometimes writing things that most of the programmers in the shop did not understand. In other words, had to be written so that they would be able to maintain the code after I was gone even though they didn't understand the fundamental concepts behind how the program worked (example a fast "exception" look up routine using a hash table of lists in a shop where most programmers don't know what a hash table is, what a list is, etc.) Bomb proof design with comments like "if this program needs more space (to handle a larger number of exceptions) increase this constant and recompile".

Now the little devil in me wants to know why it was a constant and not a parameter (I mean something that could be e.g. read from a configuration file or similar)?

_________________
Offending ad removed

My bet: Because increasing the number of exceptions per se implied changing the code, so moving the constant to a configuration file doesn't make much sense.

May well be, but then the comment itself was quite misleading

_________________
Offending ad removed

Required recompiling.

We did not use assembler when we didn't have to as maintenance then limited to just a couple of us. Only when we had to for services not available to the higher level language. If we had expected frequent need to change the size I would have written the routine in assembler (which does support dynamic memory allocation).

OK -- since this has people curious, no, this was the reverse of having programmers code exceptions.

In a large system (about a half million lines, about 350 sub porgams, 90% COBOL) about 20 of the programs had had hard coding for cases that were exceptions to their processing. The volume of changes to the exxcption cases meant that 2-3 programs were being changed each week and that's a lot of programmer time considering the security involved in the process (a few minutes tot make the change itself, a few hours to get any change into the week's build).

Replaced with a single look up routine that each of thses programs could call to answer the question "is this case one of my exceptions". So now the exceptions are records in a data file. The first time the look up program gets called it sees the table is not built so reads in the file and builds the table before returning the answer. Subsequent calls of that night's run just do the look up.

The comment I was talking about was in case the number of exception ever grew larger than the available number of cells. This was telling the standby programmer what to do if called in the middle of the night becasue the look up routine aborted file maintenance with a "I don't have enough room" message. Not worth writing the program in assembler just to avoid this possibility that might not happen for years if ever.

I suspect that most of you are unfamiliar with batch runs so large you can't afford to do I/O for look up? (I'm just fallstalling that question -- no, several hundred thousand direct access I/Os not an acceptable solution!)

Well, I/O for lookup is a speed (and disk wear ) problem. I've done my share of clogging our department's computers with I/O (for some fractal computations with a huge amount of stuff done per pixel), and indeed, this is something you just can't let happen. In my case I just stopped writing data that was likely not needed and wrote as it was computed instead of every 1GB (sending 1GB to the disk every 20 or 30 minutes was worse for the system than sending it as it was computed)

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net