191–200 of 227 posts
Freely available here: https://papl.cs.brown.edu/2018/
More on the Pyret language here: https://www.pyret.org
Earlier quoted context omitted.
Domain knowledge vs. programming "in isolation" is a false dichotomy. Indeed, the programmer's business is to think about the domain in terms of computer science in the programming language of choice. It is sometimes a very complicated translation process, and the complexities do not necessarily come from the domain per se but often from requirements concerning the target platform, efficiency, precision, user interfa…
The "important part" is that the code solves the end user's problem while creating the minimum possible amount of new problems for them. Everything else is an implementation detail. Everything else that we hold so dear about computer science is only important insofar as it solves someone's problem.
"The other side of this observation is that the professional never quite takes any problem as seriously as does the amateur. He has had bugs before, and he will have them again. This difference in attitude is a source of constant friction between the two types: the professional is very tired and a bit irritated by the unending stream of amateurs waving their printouts in his face and condemning the machine, the operator, the system, the keypuncher, the language, or the government. The amateur, on the other hand, can see that the professional does not even care that his means and standard deviations are not going to be ready in time for inclusion in the proceedings of the conference."
Gerald M. Weinberg, The Psychology of Computer Programming.
Earlier quoted context omitted.
Clearly. If people want code written by people with a lot of domain knowledge but not a lot of software engineering experience, look at the code written by electronic engineers who just need to write a little software (typically for microcontrollers) to interact with the hardware, the true focus of their craft. Some of the most horrendous, fragile, unmaintainable spaghetti code I've seen in my life was written by ele…
That’s a great example! Unfortunately.
During my time as a student I felt that the computer science department should have been split into two disticnt programs. The first program should have existed in the math department dealing with the theory and mathematics of computation. The other should have been in the engineering school and focused more on actual computers. Hardware, software, operating systems, working in a team, designing large systems, etc. I…
Earlier quoted context omitted.
Thank you for this much more nuanced response. Your original post was very critical of SICP in a way that didn't seem to do it justice - I think that's what set of much of the debate in this thread. But if what you say in this comment is what you really meant, I fully agree with it.
I am writing from the perspective of someone who isn't a CS major and is trying to learn programming on my own. I am very interested in the CS aspects of programming but am finding it hard to learn it in an approachable and understandable way. If an "ivory tower" approach is working, I'm on board, but I bet more people get value out of SICP after they have a lot of classes and experience under their belt and not the…
Earlier quoted context omitted.
The curriculum is too artificial and disjoint from the rest of their CS degree. That was my takeaway from CS61A at Berkeley. I thought that Scheme was incredibly elegant and I was disappointed that we never used it again. The profs sure were pleased with themselves at the end of CS61A and I imagined later that they thought their preferred outcome would have been that we pursued a PhD using Jikes. SICP was the text wh…
I quote "programs must be written for people to read, and only incidentally for machines to execute" fairly often to students, which is from the 1st ed preface.
Earlier quoted context omitted.
For me it wasn't the maths in SICP, it was the physics, or rather the particular examples in the chosen domain. I love physics but coding Newton-Raphson does not engage me. (I had a similar reaction to particular Python book -- Roman numeral conversion? blah!)
The motivation for using that example in particular is, I believe, that it's computing a fixed point - which is an idea that came up several times in the course in increasingly general settings. First you do the concrete example of newton's method, then do a more general fixed-point (higher order) function, and a more general newton's method. Later on the Y-combinator is presented as computing the fixed point of an (…
But it would be good to hint about it's relationship to later material.
Perhaps it's the timing/context; I had an very odd lecturer for numerical methods.
I think it's worth pointing out why the author's of SICP themselves acknowledge why it was phased out. Praphrasing, it essentially boils down to the kind of applications developpers of today are writing. People are now mostly slinging libraries they have a superficial understanding of together in a black-box style. So for most proprammers there's a lot of prodding and tinkering and this isn't a skill that SICP teache…
Gerald Sussman made some remarks about this during an unrelated roundtable discussion at the 2009 International Lisp Conference:
https://cemerick.com/2009/03/24/why-mit-now-uses-python-inst...
Note that Sussman did not actually state why the committee decided to change the curriculum. The remarks about studying software empirically were his opinion. I was in the audience, and while Sussman seemed sincere in his remarks, I still have a hard time believing he was serious. How can anyone state, without irony or sarcasm, that we should just give up, and start treating software programs, where all the "laws" are not only known, but made up, by us, as if they were natural systems, where our only way to understand them was to start "poking" (I may be wrong, but from what I remember this was the actual word Sussman used) at it and observing the results?
If you give up before you have even started on modularity, composition, etc., and start treating every program as if it was a million line COBOL hairball, the hairball part is just going to be a self-fulfilling prophecy.
My takeaway from Sussman's remarks was the opposite of his message - the ideas about applying mathematical principles to software design in SICP have become even more relevant as a way to prevent software hairballs.
I make good money doing the "poking," but if you are going to teach that, stop pretending that you are teaching a science at the university level - this kind of shrug-and-give-up empirical programming is to computer science and engineering what a trade college auto mechanic education is to a mechanical engineering degree.
It's always interesting seeing the textbooks that are renowned by professors/people with prior knowledge, yet disliked by actual students. The Feynman Lectures on Physics is a pretty famous example (iirc, the actual course was received pretty negatively by students). I wonder how many people have actually sat down with a bunch of students and done a real experiment with textbooks. It's quite easy to think that a text…
> MIT students are far stronger than average and can generally skip certain elided steps that other students cannot. They are stronger at what? Either they know things already or they don't. If they know things already then they can skip steps and if not then they can't or can use guesswork. And that's what any other human being will do.
Lifting heavy books, of course.
> If not SICP, then what? Maybe HTDP? I can recommend "Concepts, Techniques, and Models of Computer Programming" (CTM or CTMCP). Book's page: https://www.info.ucl.ac.be/~pvr/book.html Quote from www.c2.com: "Like SiCp, CTMCP is first and foremost a book on programming, not on Oz or Scheme or anything else. And if SiCp is the reigning king of such books, CTM is a worthy challenger to that particular throne."