Hacker News Reader

My problem with this sort of bottom-up approach to learning how to program is that what seems "fundamental" from one point of view always turns out to be an abstraction built on an even lower-level foundation.

So, virtual functions aren't real because they're just vtables implemented in C. But C isn't real because it's just fancy assembly language. But assembly language isn't real because it's just fancy machine language. But machine language isn't real because it's just 0's and 1's zipping around the hardware. So I have to learn how integrated circuits work before learning how to program? No.

Bottom-up knowledge is important for understanding performance and other trade-offs. However, there's also a lot of benefit in learning how to program in a formal system without knowing much about how that system is implemented under the covers. If I was teaching an intro programming course to undergrads in 2017, I'd be strongly inclined to teach them a clean functional language first (e.g. Elixir, F#, etc.), and only introduce gory details like pointers and memory allocation later on.

F# would be particularly well suited for this since it can reasonably do imperative, object, and functional styles. I'm not as familiar with Elixir to make the judgement there. Though I suppose one could also argue for something like Clojure.

> So I have to learn how integrated circuits work before learning how to program? No.

I took a couple classes in college that were designed to teach what is going on underneath the 1s and 0s of instruction sets. I didn't take the classes about how circuits work, but they existed, I had friends who took them, and I really wish I had as well.

Maybe this isn't required knowledge to do software engineering, but it's definitely useful knowledge. Why wouldn't we want to learn these things?

I agree that these are useful and interesting things to learn. I just don't agree that they should be taught first when learning to program.

Sure, I agree.

I personally agree with your inclination to teach them using a clean functional language.

I'm sure it would be possible to produce a few excellent software developers doing the bottom up approach as well, starting with a course on hardware, then assembly and then going up the stack from there. I would have loved that approach personally, but it would probably turn the average CS student into an awful programmer.

I think a relatively balanced approach is desireable, as in most things.

Sure, start the freshman off with Python. Let them get their feet wet and see whether they even enjoy this dark art at all. Besides, knowing about the hardware before "Hello World" isn't very helpful.

After their intro class, you don't do bottom up or top down. You start at both ends and work your way in. You got your computer systems course which teaches C and a smattering of assembly and hardware and your algorithms and data structures class that can use an easier language like (python/scheme) to reduce the cognitive overhead to teach the material.

If the students are taking these at the same time and the professors coordinate to explain how they relate at the various levels, you get very balanced developers. (Assuming they do well in the classes!)

While I think that most CS people should learn assembly and computer internals basics, it would be an absolute disaster to start students off in assembly as CS 101.

Python is a fairly decent language for starting people off:

* It doesn't have a lot of boilerplate, so no magic "I'll teach you what this means in three weeks" steps

* Output for debugging is fairly easy, since print accepts a lot of stuff without needing to muck with formatting strings

* Assignment is a statement, not an expression. You can't say "if x = 3" by accident

* Python is one of the major programming languages, so you're teaching students something that is pretty much guaranteed to be useful for them.

But many students come in with years of programming in a language like Python, Java, or C++. My friends and I built video games when we were in high school so we were comfortable in all three of those languages.

Scheme levels the playing field. I have never encountered a student who entered university with years of functional programming experience and I was a TA for an introductory CS course. I think moving back to Scheme would be a wise choice for universities that are combating problems with diversity.

If students have years of programming experience, why are they being made to take programming 101?

Because it is a required subject in your curriculum? You don't get to pass people just because they say they know something.

My university did. COS101 was an optional class for complete novices but if you weren't already at least exposed to programming your advisor would sign you up for it. COS125 was the first for-realsies class (taught in Scheme, as it happens).

If a student claims to know what the class would teach, you don't have to take their word for it: you can talk to them, or you can give them a test.

(I skipped the first two intro CS classes in college after talking to the professors and figuring out the right place to start given my background.)

Berkeley used to let students skip the introductory CS course, 61a (in Scheme), if they had received a 5 on the AP CS exam. They removed that option I believe after fall 2010.

One of my friends was able to skip 61a by meeting with the department chair, Paul Hilfinger, and convincing him that 61a would be a waste of time for him. My friend could drone on and on about the simplest of subjects so we assumed he just annoyed Hilfinger until he said "enough already".

Hilfinger also liked to give people enough rope to hang themselves many times over with.

Most campuses call this "challenging" - I did it several times. In city college, I successfully took courses without their prerequisites by speaking with the professors and showing them my work/experience. It wasn't test-based, just portfolio review.

In university, successfully challenging also gives you credits for that course (though there is a small fee per unit). I successfully challenged four courses (all in graphic design) - three of which were based on portfolio review and the fourth was based on completion of course projects in an accelerated period. Additionally, though not quite a challenge, I was able to speak with a couple CS professors and get them into admitting me into their courses despite not having the prerequisites (though was doing them concurrently).

The course requisite structure is more a guideline than a rigid computer system that works one way and only that way.

In addition, computer science is not the same as programming.

Because they probably don't know as much as they think they know regarding algorithms, Big-O, etc. There are exceptions, of course.

When you say "programming 101" you might not be talking about the MIT courses being discussed here.

6.001 was a course in functional programming, based on the book Structure and Interpretation of Computer Programs.

6.01 (the replacement course that uses Python) is a project-based course involving robots and stuff.

Neither of these courses depend on any specific knowledge, but they would be very difficult courses if you've never programmed before. (Most people coming into MIT course 6 have programmed before.)

The "you don't know how to program, here's how to program" course has taken various forms over the years. When I was there it was 1.00, a Java course for engineers. Later it was 6.00, an optional intro to Python, based on "How To Think Like A Computer Scientist".

As part of a reorganization of the undergraduate EECS curriculum last year the intro class is now two half-semester classes, 6.0001 and 6.0002. It's 0's all the way down!

>6.001 was a course in functional programming, based on the book Structure and Interpretation of Computer Programs.

While I can't speak for MIT, SICP was used as the introductory course for CS in a number of universities. It assumes no programming. It is challenging, but that's the point of going to top universities.

Today it is not "many" students who come in to college with programming exp; for instance Berkeley's CS61A, which also moved to Python has over 1300 students. The overwhelming majority have not taken CS classes before.

Dang. 61A with SICP was my favorite class.

> The overwhelming majority have not taken CS classes before.

When I want to university I never took a CS class before and nevertheless could program really well. I believe one is not able to go to a university if one is not able to teach oneself the prerequirements of the subject that one want to study.

It really depends on the type of school. We started programming on University with a simplified assembly, but it made a lot of sense since it was electrical engineering school and we've learned about hardware in parallel, so we could follow what physically happens when the code is executed. I don't remember that anyone had a huge problems with following it. For many people around me with good math skills, but no previous programming experience (and little interest in it) it was much harder when we next moved to C and data-structures and algorithms, where you need to think in an abstract way and solve more complex problems.

I choose electrical engineering for some weird reason - I don't think it occurred to me that software engineering was a way of making a living even if I had been a hobby programmer since I was 12.

Luckily the introductory course was based on SICP - and it really realigned my BASIC- and C- damaged brain.

It turned out to be the only course that I enjoyed so I eventually switched to a more computer systems and sciences oriented education.

It was a good introductory course for me, and perhaps most others. Perhaps not good for the most daft though...

I guess you also need some assembler-skills but it's hard in a totally different dimension somehow.

I'll add one more item to this list: Python has a turtle graphics library out of the box. Turtle graphics is an excellent way to explain concepts like loops, functions and recursion in a visual way that is much easier to grok than the more abstract explanations. It goes step by step, too: you can show the basic notion of issuing statements by drawing stuff like triangles and squares and pentagons; then demonstrate how this becomes tedious as number of edges grows, which gives an opportunity to introduce looping; then show how it's essentially the same loop for various polygons with different parameters, and introduce functions. Drawing spirals, snowflakes and trees is where recursion steps in. And so on.

Another approach is to introduce newcomers to programming with a single course that: 1) uses Python to teach general programming, 2) uses JS to show how to write code that runs in a browser, and 3) demonstrates low-level programming patterns using C.

This is essentially what CS50 at Harvard does, and it seems to work well. Once a student has been exposed to these 3 languages, subsequent courses can explain how a computer works and introduce new paradigms (FP, LP).

Yes, I think it's very reasonable to use a scripted dynamically typed language to learn control flow to start with. We tend to forget that the basics of loops and mutation are a hurdle for many people.

I'm not sure new programmers need to worry about how virtual function inheritance is implemented via the viable. Are there even standards for that? Or is that an implementation detail which seems popular across multiple compilers?

There's time for them to learn the details, but just learning that the functionality exists and knowing how to use it is a good start.

The point isn't to learn it as if it's something you'll have to recreate--it's to understand that "advanced" language features are built on top of the "fundamental" structural model and are not magic. You need some understanding of how programming languages are built in order to keep languages and libraries honest. Otherwise learning about type/object systems becomes learning all the pitfalls and incidental complexities caused by the design as if they're benefits and not costs.

I kinda despise the notion that assembly is everything. It's better than falsely higher abstraction like cpp and java but it's not all.

Inductive logic and the functional paradigm maps onto all of these. And allows for more diverse abstractions without lying either.