Previous Hacker News Discussions:
https://news.ycombinator.com/item?id=3491142
https://news.ycombinator.com/item?id=3141996
Full disclosure: I'm a TA for the course right now.
Teaching SICP in Python is just a further development of that trend.
Software engineering is a very trend-following, path of least resistance, bandwagon-jumping profession. If "everyone" is using language X, that's where most engineers (and managers) want to be. Universities are just satisfying that need.
It's a wonder that Scheme lasted in universities as long as it did. It'll be interesting to see how long Python lasts.
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool...
Python is 25 years old.
Remember, all of those "old" languages, when they became notable or influential, were younger than Python is now.
Scheme, when SICP was written, was only 15 years old. It was young and trendy at the time.
C was less than 20 years old when I learned is as part of a required course for my CS degree. I've no doubt that part of the reason was that it was widely used in industry.
C++ was the trendy thing by the time I left school. It was less than 10 years old.
Perl was 10-15 years old when it was used as the "Swiss Army chainsaw" for a lot of the first era of web development.
While this appears to solidify your observation that software engineering is very trend-following, I listed them to point out that Python seems to be the oldest language when it made the jump. It's surely older than most of the students and even TAs for the course.
You won't see a CS course taught in Go or Rust anytime soon.
def make_adder(n):
def f(a):
return n + a
return f
"About 12 years ago, Python aquired lambda, reduce(), filter() and map(), courtesy of (I believe) a Lisp hacker who missed them and submitted working patches. But, despite of the PR value, I think these features should be cut from Python 3000."
If my understanding is flawed, I'd like it to be corrected, though.
You can't have anonymous lambdas that aren't first class (how would you reference them?) but you can have first class functions that are not technically anonymous.
I suppose I wasn't aware that that wasn't a universal requirement, but count me in with that group. I think it's useful to make a distinction between "higher-order" and "first-class" for this very reason (i.e., we can talk about languages that do make a distinction without resorting to overloaded terms).
I mean, consider a language where this is the case:
> "hello," .. " world"
==> "hello, world"
> 2 + 2
==> SYNTAX ERROR
> def a = 2
==> #<number "a">
> a + a
==> 4
Sort of on a tangent, but while I'm reminded of it: as far as Python's "lambdas" go, they're brutally gimped compared to Python's notion of a function, since what is allowed (and even required) of a function body in Python is much different than what is allowed of a "lambda" body.
Yes, I still would, because integers can be bound to variables, passed to and returned from functions, and stored in fields of objects.
I would think that the language had a silly syntactic restriction -- which is the same thing I think about Python -- but it wouldn't materially change how I would write programs. It's just that, before any expression using an integer literal, I would have to name the literal.
Well, same here. If you want to use a function too complicated to fit in Python's restricted lambda expression syntax, you have to use a named local function. I agree that it's silly, and I'd never design a language like that myself, but again it wouldn't materially change how I write programs -- it just means that what would have fit in one expression would now, in some cases, require multiple statements.
Trying to draw a fine distinction between "higher-order" and "supporting first-class functions" doesn't appeal to me; I think of the latter as the definition of the former. (I'm sure I would have trouble remembering which was supposed to be which.)
But again, I have no problem with criticizing the design decision -- just not using these terms :-)
I could see saying something like, Python functions are semantically first-class but syntactically second-class. Or maybe we should just call them "business-class" :-)
(BTW your comment downthread about referential transparency is spot-on.)
And I also see (now) where you're coming from. But it's hard for me to accept the "once the value has been created" exception, because in my mind the construction of a value is as important as any other operation on that value.
Anyway, I'm not going to argue this any further -- I think we understand each other's perspective and we can pretty much resolve to chalk this one up to the (rather unfortunate, imo) lack of precision that's so common to terminology in computation science (see also: any debate whatsoever about types ;) ).
I'm a seasoned programmer, who after years in the industry really enjoyed SICP once I discovered it. I found it very nicely put together in the sense that it managed to teach a simple LISP and handle programming in a deeper and more academical/sciency way, and not just the regular "here's how you make a blog with whateverDB".
I'm currently looking into expanding my very basic Python knowledge, and are looking for books/courses on the subject.
Would you say this course here is good for learning Python, or would you rather recommend something else to experienced programmers?