Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SICP in Python

wizardforcel.gitbooks.io

Post reply on HN
Print view View original

121–130 of 136 posts

Re: SICP in Python

#121

Post by kadoban »

nitroll wrote: post #112
kadoban wrote: post #105

Earlier quoted context omitted.

It's pretty odd behavior, yeah. It's easy to work around (set the default to None and then set the actual default in the function body), but I don't know if I've _ever_ seen anyone want it to behave as it does now.

It does make sense to evaluate the default value for the parameter at the point of definition for serveral reasons. First of all, the default value does not have to be a literal value, and if you wanted it to be evaluated at call time the function would need to capture all of the default values in a closure. default = 10 def foo(x=default): return x default = 20 assert foo() == 10 I think tat makes a lot of sense. It…

You could easily generate that behavior manually though if the default were the other way, and it would target the common case instead of the rare case.

Re: SICP in Python

#122

Post by wegs »

geofft wrote: post #108
wegs wrote: post #80

Earlier quoted context omitted.

Dijkstra once said: "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." I find much the same to often be true for many Java programmers. Programmers who start out with a course all about classes, getters and setters, inheritance and so on often end up with their minds wedged such…

Dijkstra was empirically wrong about that (generations of perfectly good programmers were taught BASIC first in schools) and about most of the other witty and self-congratulatory quotes in that collection: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EW... Perhaps the most amusingly wrong one is the claim of FORTRAN, which sits at the core of the scientific Python stack, as "hopelessly inadequate for wha…

I agree that he was wrong about that :)

Or to put things more accurately, he exaggerated for humor. It's a communications style. He was wrong if you read it too literally.

If you read him less literally, the basic point he was making was right.

If you start out in a language like BASIC, plenty of programmers never make it to the other side. And it applies much more to Java than to BASIC. With BASIC, everyone who goes into programming will move on at some point (there aren't BASIC jobs out there), and they'll be forced to learn something different. With Java, plenty of people learn it, work whole careers, and never know any better. That doesn't just prevent them from coding in Ruby on Rails or whatever else -- it makes them worse Java programmers too. They understand WHAT, but they don't understand WHY. They can't reason about things like abstraction from first principles.

You want to start out with a broad view of computation. From there, you then want to narrow. Java is okay for a junior-level course on OOP, but it's really, really lousy for a first exposure to programming, or a freshman course.

(I started out in BASIC too).

Re: SICP in Python

#123

Post by dunefox »

analog31 wrote: post #91
wegs wrote: post #89

Earlier quoted context omitted.

Nah. You'll definitely want the new version. I'm not exactly sure what changes were made between the 1st edition and the new 2nd edition, but the 2nd edition is canonical. The text is online: https://mitpress.mit.edu/sites/default/files/sicp/index.html Virtually all Scheme interpreters support it: https://docs.racket-lang.org/sicp-manual/index.html https://www.gnu.org/software/mit-scheme/ Assignments and video lectur…

>>> The text is online: >>> https://mitpress.mit.edu/sites/default/files/sicp/index.html There goes my next few weeks.

Read this: https://sarabander.github.io/sicp/

Re: SICP in Python

#124

Post by StreamBright »

czzr wrote: post #67
StreamBright wrote: post #51

Earlier quoted context omitted.

Except that 90% of Python programmers fail to answer simple questions like: Given: def extendList(val, list=[]): list.append(val) return list What do the following print: print(extendList(1)) print(extendList(1)) print(extendList(2)) print(extendList(3,[])) I do not blame them. This sort of behavior is error-prone. You can make sure that you do not use such a code in production with code reviews but it would be also…

For what it’s worth, I’m not a Python programmer and I got that correct. The answer is: [1] [1, 1] [1, 1, 2] [3] It relies on knowing something about how python applies default arguments. I’ve only written about a hundred lines of python in my life, so possibly I just got lucky - still, I would have thought an actual Python programmer should get this?

Yes, it is called insanity, doing the same thing, and expecting a different outcome. This is exactly what that function does.

Re: SICP in Python

#125

Post by StreamBright »

theamk wrote: post #84
StreamBright wrote: post #51

Earlier quoted context omitted.

Except that 90% of Python programmers fail to answer simple questions like: Given: def extendList(val, list=[]): list.append(val) return list What do the following print: print(extendList(1)) print(extendList(1)) print(extendList(2)) print(extendList(3,[])) I do not blame them. This sort of behavior is error-prone. You can make sure that you do not use such a code in production with code reviews but it would be also…

If this is a problem for you, I recommend pylint. No need to rely on code reviews, and catches majority of cases like this. (You’ll likely want to disable some of the more opinionated checks, but this is well documented and supported)

Not a problem for me, just for the 90% of candidates who we interview.

Re: SICP in Python

#126

Post by [deleted] »

_revy wrote: post #75
jedberg wrote: post #25

It made me so sad when I found out CS61A was being taught in Python. I love Python, but I also know that I would have missed out on so much wonderful information if I hadn't learned Scheme. It was truly mind blowing when they had us implement a Scheme interpreter in Scheme, and then add infix operators. I think the original SICP was perfect for an intro course. It was also the great leveler, because even if you enter…

Unlike most programming books the environment and code samples never go out of date either. It's entirely self contained including assembly language.

[deleted]

Re: SICP in Python

#127

Post by kazinator »

lavp wrote: post #113
jedberg wrote: post #25

It made me so sad when I found out CS61A was being taught in Python. I love Python, but I also know that I would have missed out on so much wonderful information if I hadn't learned Scheme. It was truly mind blowing when they had us implement a Scheme interpreter in Scheme, and then add infix operators. I think the original SICP was perfect for an intro course. It was also the great leveler, because even if you enter…

It just isn’t the same, Scheme was such a wonderful educational language.

We don't need educational languages; people should use real production languages from day one.

Scheme implementations are that now, and maybe even standard Scheme is that now, but historically it has not been.

1998 was almost a quarter century after Scheme started. That year, R5RS came out, yet it defined no way to decompose a program into separately compiled files, and didn't specify what is an error (beyond saying that it's something that can happen that an implementation should diagnose) or how to recover from one. Even BASIC for 8 bit microcomputers had ON ERR GOTO.

(Good thing R5RS specified hygienic macros, because unwanted capture is a the real threat to your all-in-one-file program with no error handling.)

Re: SICP in Python

#128

Post by kazinator »

theamk wrote: post #47
wolfgke wrote: post #36

Earlier quoted context omitted.

> Python is a good language because it's readable and writeable. https://github.com/satwikkansal/wtfpython

Yep, python is probably one of the most human-readable and writable languages out there. There are some dark corners, like the site above illustrates, but it is pretty easy to avoid them. (It is still not the good fit for SICP, but that’s a different conversation)

You can only avoid dark corners as a writer. As a reader, you may have to peer into dark corners.

Most of the issues given on the linked-to page are not simple issues of readability; they are real pitfalls. A lot of the examples are actually readable. You will not easily avoid every single one of those pitfalls if you're coding in Python, even if you lint the code.

Re: SICP in Python

#129

Post by kazinator »

wolfgke wrote: post #36
woofie11 wrote: post #34

Earlier quoted context omitted.

SICP is about deeply understanding computation. Scheme is a good language for SICP because it's simple. You can build a Scheme interpreter as a class project. You can analyze it formally. Etc. Python is a good language because it's readable and writeable. But it doesn't work for SICP since it's too complex for that. Python also intentionally omits things critical to SICP (like tail recursion). Calling this book "SICP…

> Python is a good language because it's readable and writeable. https://github.com/satwikkansal/wtfpython

Python contains semantic cluster-fumbles. For instance:

   def fun(listarg = [])
     listlocal = []
     listarg.append(3)
     listlocal.append(3)
It turns out listarg is bound to a list which is not freshly instantiated each time the function is called (with no corresponding argument), unlike listlocal. The expression is evaluated at the time the function is defined, not at call time. The value is stashed somewhere and that value is used for initializing listarg by default.

I learned about this from ... running pylint3 on some code which found a buggy use of such a list.

This is probably that way for performance because Python doesn't have true literals. [1] is more like (list 1) in Lisp; it's a constructor that has to be executed, producing a newly allocated object; it is not like '(1) which is just a literal object that can be embedded into the compiled program image. Python literature incorrectly refers to [] as a literal, which is bad education: a disservice to newbies who deserve to understand what is a literal. The fact that you can do "x = []" and then safely append to to it proves that it's not a literal, because literal is an abbreviation of "literal constant", which is also something newbies should be taught.

Students of CS must absolutely learn the crucial difference between variable initialization and assignment. Python conflates the two.

   x = 42

   def fun():
      x = 43   # defines and binds local x.
This was not even fixed in Python for a long time; now you can assign to the global one with a global statement. The concept is bad here and damaging to newbie brains.

Re: SICP in Python

#130

Post by kazinator »

goatlover wrote: post #98
czzr wrote: post #67

Earlier quoted context omitted.

For what it’s worth, I’m not a Python programmer and I got that correct. The answer is: [1] [1, 1] [1, 1, 2] [3] It relies on knowing something about how python applies default arguments. I’ve only written about a hundred lines of python in my life, so possibly I just got lucky - still, I would have thought an actual Python programmer should get this?

It is different from how Ruby and Javascript handle default arguments. I'm surprised Python does that, since I would expect function arguments to be reset to their defaults each call. That's a major side effect.

It's also different from how Common Lisp handles default arguments, and ... how C++ handles default arguments.

This prints

  0
  1

  #include 

  using std::cout;
  using std::endl'

  int z;

  int foo(int x = z)
  {
    return x;
  }

  int main(void)
  {
    cout
Post reply on HN