5 ms·

This book takes a theoretical approach to OOP. As the author said, this book is NOT about Java. Similarly, SICP is NOT about Scheme. Interestingly, It's the s

This book takes a theoretical approach to OOP. As the author said, this book is NOT about Java. Similarly, SICP is NOT about Scheme. Interestingly, It's the same author who teaches how to design programs with Racket, a lisp dialect. http://www.ccs.neu.edu/home/matthias/HtDP2e/index.html http://www.ccs.neu.edu/home/matthias/HtDP2e/index.html

mcantor 15y ago
The book opens with "What you'll learn: Java."
- Open-Juicer 15y ago
  You'll learn Scheme going through SICP too. From the author: "It is a good idea to study the programming language that you use on a daily basis and to learn as much as possible about it. We strongly believe, however, that it is a bad idea to teach the details of any programming language in a course. Nobody can predict which programming language you will use. Therefore, time in a course is better spent on studying the general principles of program design rather than the arcane principles of any given programming language."
- ekiru 15y ago
  It actually says "What you won't learn: Java."
  - mcantor 15y ago
    In my defense, this is what shows up on my screen: What you will learn What you won't learn Java. Weird!
    - contrast 15y ago
      Your defense is that you badly misquoted what shows up on your screen? That is weird...
      - mcantor 15y ago
        Honest question: Is that really what you thought? It seems obvious to me that I was implying a defense that the phrase I quoted also appears on the page, directly next to the phrase ekiru quoted, which makes the mixup a little more understandable, because it means I didn't see something that simply didn't exist. Did you get that and post your reply anyway, or did I just express myself poorly?
Goladus 15y ago
> As the author said, this book is NOT about Java. That's what it says, but the concepts covered are so java-oriented it may as well be. It uses generic language to describe most of the concepts, but the underlying assumption seems to be that you need to understand these concepts because you need to program in Java, C#, C++, or some other closely-related language with no dynamic typing, no first-class functions, and explicit java-style semantics for abstract classes, interfaces, public vs private methods, implements vs extends, and such. Much of that is invisible in a language like Python, and a book that laboriously covers each concept in the context of a language where you have to specify everything explicitly probably isn't going to make you much better at writing classes in python. Or if it is, it's going to be a lot of work for minimal benefit. > Interestingly, It's the same author who teaches how to design programs with Racket, a lisp dialect. Indeed, that's partly why I'm surprised the book takes the approach it does. However, it does seem to be a good, thorough book (ignoring the missing sections) if you need to design classes in Java or C# (which covers a lot of people).
- bitops 15y ago
  I think this is where a lot of Rubyists/Pythonistas get lost. Just because the languages hide ideas like "interface" and "abstract base class" doesn't mean that those concepts aren't useful. Particularly in Ruby-land there's been a push to have common interfaces. They're only enforced by contract. And if you think about it, having "interface" explicitly in the language just means that the contract is enforced at compile time. Even so, you have to be careful. You could implement an interface and still just return null.
  - Goladus 15y ago
    > I think this is where a lot of Rubyists/Pythonistas get lost. Just because the languages hide ideas like "interface" and "abstract base class" doesn't mean that those concepts aren't useful. I agree, somewhat. The problem is that HtDC seems to spends so much time on vocabulary and describing how to construct classes that very little is left over for discussion of actual design. Here's an excerpt: This first section on classes suggests that the design of a class proceeds in three steps: 1. Read the problem statement. Look for statements that mention or list the attributes of the objects in your problem space. This tells you how many fields you need for the class definition and what information they represent. That is probably quite reasonable from a java-perspective. But in Python the best answer might be to use the built-in data structures, define a bunch of functions to operate on that data, which are automatically encapsulated in a namespace based on the name of the file. But it might not, sometimes you would want to define a class with explicit fields. The question is, how do you know which technique to use? This book doesn't seem to help with that. We've jumped from a data-driven approach using scheme to a java-style object-oriented approach for no apparent reason and very little explanation of the benefits of this approach. Even if the part about interfaces might help a bit with designing a Python module, in order to get that out of this book you're going to have to wade through a lot of other stuff.

mcantor 15y ago

The book opens with "What you'll learn: Java."

Open-Juicer 15y ago
You'll learn Scheme going through SICP too. From the author: "It is a good idea to study the programming language that you use on a daily basis and to learn as much as possible about it. We strongly believe, however, that it is a bad idea to teach the details of any programming language in a course. Nobody can predict which programming language you will use. Therefore, time in a course is better spent on studying the general principles of program design rather than the arcane principles of any given programming language."
ekiru 15y ago
It actually says "What you won't learn: Java."
- mcantor 15y ago
  In my defense, this is what shows up on my screen: What you will learn What you won't learn Java. Weird!
  - contrast 15y ago
    Your defense is that you badly misquoted what shows up on your screen? That is weird...
    - mcantor 15y ago
      Honest question: Is that really what you thought? It seems obvious to me that I was implying a defense that the phrase I quoted also appears on the page, directly next to the phrase ekiru quoted, which makes the mixup a little more understandable, because it means I didn't see something that simply didn't exist. Did you get that and post your reply anyway, or did I just express myself poorly?

Goladus 15y ago

> As the author said, this book is NOT about Java. That's what it says, but the concepts covered are so java-oriented it may as well be. It uses generic language to describe most of the concepts, but the underlying assumption seems to be that you need to understand these concepts because you need to program in Java, C#, C++, or some other closely-related language with no dynamic typing, no first-class functions, and explicit java-style semantics for abstract classes, interfaces, public vs private methods, implements vs extends, and such. Much of that is invisible in a language like Python, and a book that laboriously covers each concept in the context of a language where you have to specify everything explicitly probably isn't going to make you much better at writing classes in python. Or if it is, it's going to be a lot of work for minimal benefit. > Interestingly, It's the same author who teaches how to design programs with Racket, a lisp dialect. Indeed, that's partly why I'm surprised the book takes the approach it does. However, it does seem to be a good, thorough book (ignoring the missing sections) if you need to design classes in Java or C# (which covers a lot of people).

bitops 15y ago
I think this is where a lot of Rubyists/Pythonistas get lost. Just because the languages hide ideas like "interface" and "abstract base class" doesn't mean that those concepts aren't useful. Particularly in Ruby-land there's been a push to have common interfaces. They're only enforced by contract. And if you think about it, having "interface" explicitly in the language just means that the contract is enforced at compile time. Even so, you have to be careful. You could implement an interface and still just return null.
- Goladus 15y ago
  > I think this is where a lot of Rubyists/Pythonistas get lost. Just because the languages hide ideas like "interface" and "abstract base class" doesn't mean that those concepts aren't useful. I agree, somewhat. The problem is that HtDC seems to spends so much time on vocabulary and describing how to construct classes that very little is left over for discussion of actual design. Here's an excerpt: This first section on classes suggests that the design of a class proceeds in three steps: 1. Read the problem statement. Look for statements that mention or list the attributes of the objects in your problem space. This tells you how many fields you need for the class definition and what information they represent. That is probably quite reasonable from a java-perspective. But in Python the best answer might be to use the built-in data structures, define a bunch of functions to operate on that data, which are automatically encapsulated in a namespace based on the name of the file. But it might not, sometimes you would want to define a class with explicit fields. The question is, how do you know which technique to use? This book doesn't seem to help with that. We've jumped from a data-driven approach using scheme to a java-style object-oriented approach for no apparent reason and very little explanation of the benefits of this approach. Even if the part about interfaces might help a bit with designing a Python module, in order to get that out of this book you're going to have to wade through a lot of other stuff.