What is the best way to understand large programs?

Hello. I am trying to fully understand yi as quickly as possible. Yi, like most big programs, consists of a number of modules; e.g. Yi.UI, Yi.Buffer, etc. Since I am not smart enough to understand all the modules at once, I am trying to understand them one at a time (is this itself the problem?); however, since mutual dependencies exist, I can't do it that easily, since understanding module A requires knowledge of the interface of module B requires knowledge of the implentation of module B requires knowledge of the interface of module A requires knowledge of the implementation of module B (and my brain's lazy fix is not very good). Yi has haddock-style comments (despite not being a library), so I tried using ./Setup.lhs haddock for readable side references, however this failed on CPP markup. After asking on #haskell, newsham noted that he had filed a cabal bug (#102), but the bug's page notes: Haddock generates interface documentation. That's only appropriate for libraries, isn't it? So, if haddock isn't what I want, what is? Or am I going at this completely wrong? What is the recommended way to approach a largish program like yi or lambdabot? (and if haddock is the wrong way to handle this, why does yi have haddock comments?) Note: I *have* managed to pretty thourougly understand lambdabot, but it took a while, wasn't particularly easy, and anyway lambdabot's dependency groups are quite small compared to eg lambdabot's. I'm hoping to make things easier for myself. Stefan

Hi
Haddock generates interface documentation. That's only appropriate for libraries, isn't it?
Wrong, its very useful for normal programs as well. That along with a nice HsColour generated source links with Haddock and you can navigate the code just a bit quicker. Having a Hoogle database for a large program is also handy for figuring out where things are and what they do - especially when the program has introduced new custom data types. Some sort of module dependancy graph would also be handy, but I'm not sure any program can yet produce that kind of information. Thanks Neil

Hi
Some sort of module dependancy graph would also be handy, but I'm not sure any program can yet produce that kind of information.
Take a look to HaSlicer (http://labdotnet.di.uminho.pt/HaSlicer/HaSlicer.aspx ) Currently it is only available online but if you want it to run locally in your machine you can email the author and ask for the source code. Best Miguel Vilaça

Hello Neil, Monday, January 29, 2007, 2:26:03 AM, you wrote:
Having a Hoogle database for a large program is also handy for figuring out where things are and what they do - especially when the program has introduced new custom data types.
vim+hasktags can just show definition of every identifier in separate window. i'm not 100% sure but afair vim can also show all usages of given identifier -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On 30-jan-2007, at 23:52, Bulat Ziganshin wrote:
Hello Neil,
Monday, January 29, 2007, 2:26:03 AM, you wrote:
Having a Hoogle database for a large program is also handy for figuring out where things are and what they do - especially when the program has introduced new custom data types.
vim+hasktags can just show definition of every identifier in separate window. i'm not 100% sure but afair vim can also show all usages of given identifier
Unfortunately the current incarnations of hasktags do not generate tags files that vim likes much. Workarounds are to use ghci 6.6's :tags command, or to sort the generated tags files afterwards. Another gotcha: hasktags generates the files 'tags' and 'TAGS' by default. This *will* break on case-insensitive file systems such as e.g. default installations of HFS+ on Macs. Doei, Arthur. -- /\ / | arthurvl@cs.uu.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching

Hello Arthur, Wednesday, January 31, 2007, 3:06:21 PM, you wrote:
Unfortunately the current incarnations of hasktags do not generate tags files that vim likes much.
it's no problem for one knowing haskell :) actually, i use my own version that fixes all these problems and don't require '::' to see a function. attached -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hello Stefan, Monday, January 29, 2007, 1:59:22 AM, you wrote:
Note: I *have* managed to pretty thourougly understand lambdabot, but it took a while, wasn't particularly easy, and anyway lambdabot's dependency groups are quite small compared to eg lambdabot's. I'm hoping to make things easier for myself.
imho, the problem is common for any language and it's just because most of programmers don't like to write comments. in my own program, comments/code ratio is about 1:1 and i, after 2 years of development, still understand it's every line :) just compare yi and lambdadot with two best commented libs i've seen - base and MissingH -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

bulat.ziganshin:
Hello Stefan,
Monday, January 29, 2007, 1:59:22 AM, you wrote:
Note: I *have* managed to pretty thourougly understand lambdabot, but it took a while, wasn't particularly easy, and anyway lambdabot's dependency groups are quite small compared to eg lambdabot's. I'm hoping to make things easier for myself.
imho, the problem is common for any language and it's just because most of programmers don't like to write comments. in my own program, comments/code ratio is about 1:1 and i, after 2 years of development, still understand it's every line :) just compare yi and lambdadot with two best commented libs i've seen - base and MissingH
I had to go and check this! Code Comments Lambdabot: TOTAL: 14263 5063 Yi: TOTAL: 3314 3270 Data.ByteString: TOTAL: 3255 3135 Data.Binary: TOTAL: 782 849 hmp3: TOTAL: 2351 2236 base: TOTAL: 43513 29009 MissingH: TOTAL: 6492 2017 Lambdabot wasn't commented at all until about 2 years ago! It's had a strange history. Not sure what this all means. -- Don
participants (6)
-
Arthur van Leeuwen
-
Bulat Ziganshin
-
dons@cse.unsw.edu.au
-
José Miguel Vilaça
-
Neil Mitchell
-
Stefan O'Rear