Frans Bouma on 4/4/2004 7:17 PM All the things you suggest are also important, but none of them are learned from reading other people's code, but by reading theory about these topics, like books on patterns (GoF's), theory about interfaces and what they really are (mechanism to implement multiple-type inheritance + assuring contracts) etc.



If I write a generator for an algorithm, are you then interested in how the code looks like? If you answer 'yes', do you also look at every IL the C# compiler generates for you? If you answer 'yes', do you also peek at the x86 asm the JIT produces when running your IL? I bet you don't. And the reason why you don't do that is probably (likely): because I trust the JIT for being efficient. Why? Because it produces A' on input A. And B' on input B. So what's important is the input, not the result. The input in your software is the algorithm, the design, not the code. The code is the output.



Perhaps I wasn't clear enough, but what I meant to say was: if you want to learn something, read the algorithm, then try to implement it and check if you've done it correctly. If you become very good at translating algorithms to code, you are generations ahead of any developer who thinks in code-constructs. The reason? in about 5 years more and more is done by abstract designers instead of hammering out raw code. However what stays the same is the theory that's the foundation of what you're producing.



You see the same with patterns: some people think patterns are holy grails and think in implementations of patterns. The biggest mistake you can make. If you don't grasp the FULL theory behind a pattern, you're doomed to use it in an anti-pattern scenario. Furthermore, once you understand the theory behind a pattern, you don't need the pattern. The theory becomes a generic building block for writing/designing software.



ps: the sedgewick book was an example. There are more algorithm books, also pattern books. It's about the theory, not the implementation, that's tic-tac-toe after a couple of times.

Kingsley Tagbo on 4/4/2004 8:14 PM I see what you are saying. When I started translating data mining algorithms to code a few years ago, I was very surprised at how difficult it was to re-produce elegant code from an elegant algorithmic blue print.



My production code did not really look like the algorithm I was re-producing. I realized that while I could write commercial everyday code, thinking and coding in an algorithmic fashion was a completely different story.



I am now beta testing my translation of APriori Market Based Analysis Algorithm to a C# Component and I feel a lot better about my ability to create working models of algorithms.

Has it made me a beter developer, in my opinion, YES.

Kingsley Tagbo on 4/4/2004 8:31 PM Is there more to life than algorithms?



Look at Google, take a peek under the hood, what do you see?

Panos Theofanopoulos on 4/4/2004 11:53 PM Kingsley : That reminds me a different case i had not long ago. I wanted an algorithm on iterative repair (a semi-heuristic for optimization of production orders), i found a paper (12 pages full of math symbols).



The first read was a nightmare, i did not understand anything, anyway because the project was demanding i did not give up. I did read it about 20 times (i am not a very clever person) and writing test/sample code (where is E&C when you need it?) for a week or so, when i finished i did some optimizations mainly for readability. The resulting code was just one page! (to be exact it was two nested loops and four or five conditional summaries ). Why did the original author describe it in 12 pages full of S(?,?)/S... ?



This chasm between "applied" mathematics and pure programming is imho the main reason what keeps software still in its infancy.

Stefan Cullmann on 4/5/2004 11:30 PM We should always try to get a better developer, not just a .NET developer. I think more important than reading code is to keep thinking and self reflecting.



Algorithm and patterns are about basic code writing, I will never forget the recognizing of patterns I still used before reading GoF without even knowing the term for.



Books like the "pragmatic programmer" are about programmers habits. It will help you to decide which parts of your code smells and why.



Examples and reading code can't really replace self doing. I have learned from my mistakes, there is no better teacher.

JosephCooney on 4/6/2004 5:28 AM The Pragmatic Programmer is indeed a good book, possibly my favourite. You can always find something relevant there. Stefan - as somebody who has read a few bits of my code you can probably attest to just how many "lessons" I am yet to learn .

Stefan Cullmann on 4/6/2004 10:02 PM Joseph, you understate your work. I refuse to attest that you need more learning lessons.

Are you unlucky with your own work, in particular m3rlin? Why? Does anybody tell you that something is missing or doesn't work?

No? Great. I didn't find anything I had to remove to use it in my project.



It fullfill YAGNI - and if you or I feel that something important is missing, we will expand your project, won't we?