This course is not the first CS course that most Stanford students (who take a CS course) take-- that's CS106A, which is based on Java. This CS101 class is a small, recent addition aimed at people in non-technical majors. I believe there's only one class of ~30 people, taught by Nick Parlante.
I always thought it was interesting that a lot of the top CS schools seem to use Java as their teaching language rather than C++ (or C). I've heard that MIT is using python (switched from scheme) and I know the University of Chicago uses Scheme. My school (RPI) uses C++, but I don't know anyone else who does. I recognize that the teaching language is largely irrelevant to the material, but I wonder why the departments choose the different languages.
That's only true for introductory and some algorithms courses. After that, it diverges mostly into C and a bunch of custom languages, such as MATLAB for theoretical courses. I go to CMU and I haven't really touched Java since freshmen year. But upperclassmen CS is still done in C majorly.
Yes, MIT shifted to Python for intro level CS classes. CMU is doing that following this fall.
Yale (not considered a top CS school, I know) still uses scheme for its introductory classes. With both Berkeley and MIT switching away, I wonder if Yale's one of the last holdouts.
I'm not sure I agree with you that language is irrelevant to material. I definitely notice the influence of scheme on my thought-processes when programming.
Stanford's intro CS sequence is CS106A, CS106B, CS107, and CS108.
106A is taught it Java. (It was taught in C until 2004. It's nice to be able to teach for-loops without also having to explain pointers.)
106B is taught in C++.
107 is now the first introduction CS students get to C and Unix. While 106B focuses on basic algorithms and learning to use abstractions, 107 goes into the guts of low-level C.
108 is on OOP and is taught in Java.
Higher level classes are either in C++ (all the systems classes) or Java (e.g., Natural Langauge Processing).
There are a few factors - whether the academics are in love with some particular language (i.e. Haskell, Eiffel, Smalltalk, or Lisp); whether there is pressure to use a language that will help students "hit the ground running" (i.e. industry buzz words that may be obsolete by the time the students graduate, or Java/C#); and whether it's easy to teach.
Imperial College Joint Maths Computing first year was Haskell, Turing, Fortran, Mathematica. And was undocumented - no books, had to turn up to the lecture and scribble.
That was 1997, I have no idea what's done there now.
At my university (Dalhousie, Halifax NS), they still use Java for the first 3 classes (CSCI1100,CSCI1101,CSCI2110) which are basic data structure and algorithm classes, they include a mixture of Linked Lists, Binary Trees, Search Algorithms, etc. Afterwards its a mixture of C, C++, Matlab, Perl, and Scheme.
Generally the more mathematical based courses like Digital Signal Processing use MATLAB, Operating Systems and Algorithms in C, Graphics (Computer Graphics, Animation, etc) in C++, Object Orientated Programming in C++, and Principles of Programming Languages (Compiler Design, Grammars, Scoping etc..) in Scheme and C/C++.
All other courses give the student free reign on what language they choose. It's interesting to note that atleast from my year there seems to be a uniform distribution of C#,C++,Java,Python, and Perl used in these courses. They tend to be the more project based such as Information Retrieval, Network Computing, Software Engineering etc.
However, a large amount of the faculty no longer supports Java as the language that is taught in first year computer science (Java and C are the only languages that are taught in class at all) and moving towards Python after they have had great success in the last several years with intro courses for non-cs majors.
My university is actually changing the major to Python for the first 3 courses, and then switching over to C++ for the remainder of the program. With our languages class still using Scheme and having to learn an additional 2 scripting languages. Sadly, I took the curriculum when the beginning and through most of it was Java. I guess I just get to learn it on my own then :)
Great! I already liked to try Python in the browser and I was thrilled to find the WeScheme that was posted here. But using something, literally so visual as image processing is an awesome idea.
One comment: Maybe, I'm the only person in the world so tired and stupid. But at first I got the impression that it didn't execute in chrome or was so slow that it takes forever. So I fired up Firefox to test it there. Only then, did I realize, that the new computed picture would show up to the right of the code. I had zoomed in too much in chrome.
I guess the average Stanford student is smarter, but if you would force the picture to be below the code you might have one source of confusion less.
The approach of WeScheme is very different, but they provide syntax highlighting and saving code files. It'd be great if this guy can borrow some of their work.
>I need to add the ability to use any image you want, not just the canned ones I have. This is not some feature I just left out. It turns out that the browser/javascript system deliberately screens out access to images coming from other domains
i solved this here http://www.barbafan.de/farbzauber/w but yeah, u need some server side code that takes an url and returns the image data as a base64 string, i havent found another workaround yet and i doubt that there is one.
for (var x = 0; x < im.getWidth(); x++) {
for (var y = 0; y < im.getHeight(); y++) {
That would repeatedly call the get*() methods, and for a 1000x1000px image, that is a lot of calls. Better call them once and then use variables for the loop boundaries.
var w = im.getWidth()
var h = im.getHeight()
for (var x = 0; x < w; x++) {
for (var y = 0; y < h; y++) {
Your insight into performance is obviously good, but I'd rather see the students focus on writing code which is obvious to them and have the compiler/interpreter realize there's a ton of redone work. I think you can do this with flow analysis.
When I see this sort of optimization I flag it to wonder how much "help" the student got during the assignment. Years ago I saw this on a student F77 assignment
y = x + x + x
instead of
y = x * 3
The real author the assignment clearly knew that for the particular machine it was executing on that 3 addition ops were faster than a multiply and couldn't help themselves.
When questioned as to why this was, the student couldn't explain the meaning of the expression and the jig was up
not for floats (which javascript numbers are) on x86 (using the XMM registers, I don't know the x87 numbers offhand), last I checked a MULSD is 5 cycles, and ADDSD is 3, therefor conversion doesn't generally make sense.
While it is true that all JavaScript numbers appear to be floats, there's nothing stopping them from being optimized by the JIT compiler into 32-bit integers if possible.
I think the original comment about x + x + x there was not about JavaScript.
For JavaScript, you get all sorts of additional complications depending on how good your JIT is. For example, you have to check both integer addition and integer multiplication for overflow (at which point you have to recompile as doubles) unless your interval analysis is good enough. So the cost is more than just the cost of the machine add in some cases.
In practice, I'd be suprised if current JS JITs do strength-reduction in this case. They might get there sometime in the next few years, but there's lower-hanging fruit to be had so far.
For integers only. For floats, a compiler will typically only do strength-reduction if you ask it to explicitly, because it changes the answer, so it technically an invalid optimization.
I find the efficient version much clearer, too. It extracts one layer of abstraction: a beginner may wondering, how can a variable being less than a function (a<func()), then find out, that the function returns a value, etc.
I've been back and forth about how to respond to your comment. My initial reaction was "'func()' is a call and therefore returns an expression." Having thought about it, I don't really remember what my neophyte reaction would have been.
It shouldn't confuse students with optimization advice, but with the authority the lecture holds on malleable students, your asterisk should still be mentioned as an FYI for good measure.
I agree that in an introduction course, it is important to keep the code as readable as possible. But it is likewise important to get performance considerations in student's heads as early as possible.
I would say another advantage of Javascript is that virtually everyone can run Javascript in their browser, while python is a separate environment. There's the step where you have to install the interpreter or at least use something you might never have used before, and there's the step where you have to connect command-line oriented problem-solving with presentation.
The full CS course listings are here:
http://explorecourses.stanford.edu/CourseSearch/search;jsess...