I think it tracks everything with the public key that you use to push to github. The username will look the same, but will not be linked to your account.
Summary: SICP is a great book but it has little concern for the program design process and so is not a good introductory text. Our text, HtDP, is a much better introduction to programming.
Twenty years ago Abelson and Sussman’s Structure and Interpretation of Computer Programs radically changed the intellectual landscape of introductory computing courses. Instead of teaching some currently fashionable programming language, it employed Scheme and functional programming to teach important ideas. Introductory courses based on the book showed up around the world and made Scheme and functional programming popular. Unfortunately, these courses quickly disappeared again due to shortcomings of the book and the whimsies of Scheme. Worse, the experiment left people with a bad impression of Scheme and functional programming in general.
In this pearl, we propose an alternative role for functional programming in the first-year curriculum. Specifically, we present a framework for discussing the first-year curriculum and, based on it, the design rationale for our book and course, dubbed How to Design Programs. The approach emphasizes the systematic design of programs. Experience shows that it works extremely well as a preparation for a course on object-oriented programming.
I guess the next one in line should be getting rid of file as a concept. Not much point knowing where exactly the song you want to listen or a movie you want to play is stored.
Depends what you mean by "where". With respect to finding it amongst other files, making it available on portable devices, sharing it (or NOT sharing it) with others, "where" is very important to the user.
What we really want is the user's concept of a file decoupled from the system's concept, and then cleansed of various baggage from the prior coupling. That's very different than making it a system concept exclusively.
I meant from a user's perspective. You shouldn't care if the song is stored in /foo/bar or in a remote database somewhere in the cloud. You access it through some obvious interface e.g. iTunes.
Having 'file' as a central concept of accessing data doesn't have much connection to the actual way it is used. My vim config file doesn't have much in common with a song I've just downloaded. It is stored the same way, but that's about it.
Most aspects of the file concept are indispensable to the user. A generic data container is what allows us to have standardized document formats not coupled to applications or platforms and generalized organizing, packaging, sharing, storage, and search. These are user concepts that can't be abstracted away without sacrificing enormous amounts of utility.
The aspects that the user can do without are related to sharing the file system with software that uses it as a backend store.
The funny thing is that I actually understood what he was talking about. Very well explained and undeniably one of the coolest things you could have in a garage.
