The themes of this week's readings seem to be the issues of code intelligibility and readibility, the documentation of code, and the possible integration of commenting and programming into a medium where both are the same entity. The concept of FrameWork s does this by clarifying the code to an outsider. However, the assumption is made that both the coder and reader have had in-depth experience with programming in other languages, and therefore are able to pick up on standard conventions and other subtle ties.

It makes more sense to me to aim for a programming language with a higher entry-level readability quotient. Design is just as hard as actual code to understand as a first-time programmer. Especially in this GISP where our focus is on introductory-level programming, our concentration needs to be on the education of students at the introductory level.

Although in my previous reaction I spoke of commenting as one of the most important things I learned to do during my CS15 semester, that was under the heading of things that help me understand my own code. It's tou gh to decipher a sizeable program without having pretty generous knowledge of its history, ins and outs, and contacts with whom you can speak should problems in comprehension arise.

It seems as though the goal of an easily intelligible programming language has yet to be attained -- who knows if it's possible? But no one ever said programming was easy; documentation is one way that source code can be made more readable, but like any trade, computer science/computer programming is difficult to master. Is the sacrifice in efficiency worth the gain in comprehension? At this point, I don't think so, but things change. We shall see ...

Perhaps I'm not understanding your take home message, but it seems to be that documenting code is not worth the time it takes. I imagine that you mean something completely different, but I'm not sure.

If, instead, your point is that code effeciency should be stressed over readability and reusability, I also disagree. There is a big trade-off made by using OOP. Objects present a big overhead, but would you argue that that overhead is not worth the gains of reusability?

Perhaps your argument is against a sort of natural language programming language in which case I agree that that is not necessarily a fantastic idea, but I don't think that the paper is addressing a language which reads like a natual language. Rather, I think that the frameworks are meant to be modular concepts which are applicable in specific situations.

And maybe I have no idea what you're talking about. :-)