Click Here to go to Home Page
 Calendar     Seminars     Books     Discuss     CD-ROMS     Services     Notes     Newsletter     About     FAQ
 

Frequently-Asked Questions

Feedback about this page
  1. I bought the 2nd edition of Thinking in Java/Thinking in C++ and the CD is cracked. Can you replace it?

  2. I bought the 2nd edition of Thinking in Java/Thinking in C++. When I took out the CD-Rom, the name on the CD-ROM is "Thinking is C" and it contains nothing about Java/C++. Shouldn't the CD be about C++ or Java?

  3. I think it is unfair that you didn't include answers to the exercises in the book. After spending money on a book, I would expect to have the answers (which to me make the book complete) included. Second, the fact that I can't buy the answers on your website is really frustrating. I don't imagine it would take very long for you or one of your cohorts to put the answers together.

  4. How do I find out more about makefiles?

  5. What do you mean by "mentoring?"

  6. What about .NET and C#?

  7. How about a book on Delphi (or insert your favorite language here)

  8. Do you have any opinions about the Ruby language, especially compared to Python?

  9. I'm thinking of publishing/been approached by a publisher. Do you have any advice?

  10. Why do you put your books on the Web? How can you make any money that way?

  11. Why do you think open source works?


@

I bought the 2nd edition of Thinking in Java/Thinking in C++ and the CD is cracked. Can you replace it?

The book is published by Prentice Hall, who will replace the CDs. If you send an email to disk_exchange@prenhall.com they will tell you how to get a replacement.


@

I bought the 2nd edition of Thinking in Java/Thinking in C++. When I took out the CD-Rom, the name on the CD-ROM is "Thinking is C" and it contains nothing about Java/C++. Shouldn't the CD be about C++ or Java?

We really did mean to put Thinking in C in those books. Look at the artwork on the CD, and you'll see it matches the cover of the respective book. Also see the back cover of the book, which specifically describes the Thinking in C CD. On page 19 of Thinking in Java, 2nd Edition and page 15 of Thinking in C++, 2nd Edition, Volume 1 you'll find more thorough descriptions of the CD.

Both books were designed for people who understand the syntax of the C language. We found that many people came to the books and/or the seminars with the attitude that they didn't want to learn C, but rather C++ or Java, without knowing that the C language contains the fundamental syntax for both C++ and Java. Thus, they were unprepared for the book or seminar. The reason that the "Thinking in C" CD was created was to help these people gain just enough of the fundamentals of C so they could move on to the C++ or Java covered in the books or seminars.

Thinking in C (foundations for Java & C++) is a seminar-on-CD, with approximately 8 hours of lectures and slides along with exercises, to bring you up to speed on C if you don't already understand the syntax well enough to move into Thinking in Java or Thinking in C++. When you go through it I think you'll realize that it's unlike most any CD you've seen packaged in the back of a book.

The CD also includes the electronic versions of Thinking in Java, 2nd edition and Thinking in C++, 2nd edition, volume one, along with source code -- look for TIJsource.zip and TIC2Vone-code.zip, respectively. Please note that most CDs packaged with books only contain the source code for the book. On this CD, you're getting the source code for both books as well as the electronic text for both books, and a seminar-on-CD, for effectively no added price for the book. If you still think this is a bad deal, I'm sorry. This is the only book that I know of that contains a seminar-on-CD.

Originally the books had no CD, and when I decided to include the CD with the books I wanted to make sure that the publisher didn't increase the price for the inclusion of the CD. Thus, you're effectively getting this seminar-on-CD for free when you purchase the book. In addition, you get a preview of what our other seminars-on-CD are like, in case you like the way that they work and want to purchase another one (currently, Hands-On Java is the only CD available, but we're working on others).

Originally, MindView sold Thinking in C as a separate product (a seminar-on-CD -- there has never been a "Thinking in C" book), but now the only way to get the CD is to purchase a book (we were selling the CD for more than what it now costs to get the book and the CD together, so this is a distinctly better deal).


@

I think it is unfair that you didn't include answers to the exercises in the book. After spending money on a book, I would expect to have the answers (which to me make the book complete) included. Second, the fact that I can't buy the answers on your website is really frustrating. I don't imagine it would take very long for you or one of your cohorts to put the answers together.

I've gotten a couple of comments like this, and because I am currently (9/2001) working on the solution guide, I felt it would be worth some research to address the issue.

First, you're right about the delay. It took me almost 1.5 years to get started on the solution guide, and that's far too long. It would have been much better to have had it available when the book came out, but that would have delayed the book (background sounds of publishers gnashing teeth). Since then, I seem to have a plate full and have also been procrastinating because it looked like a big job.

I certainly apologize for the delay. I've only started to get good at coming up with exercises in the last couple of years. Inventing good exercises is hard enough, but now I'm learning about solutions. I'm sure I'll get better at this with experience.

To address the last sentence of the question, it has turned out to be a very big job -- I've been working on it for a couple of weeks now and am only on Chapter 10. It turns out it's like writing another, albeit smaller, book. Right now it's 276 pages and looks like it could end up being over 400 pages. So no, it's not a trivial project.

The number of pages explains why it isn't part of the book. As it stands, I was trying to cut the book down and the publisher was squealing about the size. Adding over 400 pages wouldn't have flown -- the book would have been enormous.

So one option would be to publish a separate solution guide, which would almost certainly cost you more than what it will cost via the web, and I suspect you wouldn't prefer that. I think the electronic version is the best approach; if there's a big enough demand for a separate printed book I'll consider that, but right now I don't think it would be justified.

Finally, I decided to look and see how many books (1) Even had exercises and (2) Included solutions. My Java shelf includes a lot of books, and I've gotten rid of the ones that aren't so good, so I think I have pretty good coverage of the better Java books. I couldn't find one that had exercises. Then I decided to look back at the C++ books. The most popular two C++ books were Bjarne Stroustrup's The C++ Programming Language and Stan Lippman's C++ Primer. Both had exercises (these are the only ones I found that did, besides my own C++ book), but neither had solutions. In fact, both had separate solution guide books written by separate authors (supporting my assertion that it's a big job), each costing 30$.

So according to my bookshelf, it doesn't appear to be so unusual that solutions are a separate item from the book. What does appear unusual is to have exercises at all. So if you still feel it's unfair to have a book without exercise solutions, then look at the alternative, which you'll find in most books: no exercises at all.


@

How do I find out more about makefiles?

There's a page about it here.


@

What do you mean by "mentoring?"

Consulting guidance on a project -- that is, a team is working on an actual project and the mentor comes on site periodically and helps "steer the boat," which includes reviews and walkthroughs of design, code, and/or process. You could think of it as "someone to watch over you."


@

What about .NET and C#?

My first inclination has been to say that I've been jerked around by Microsoft far too many times to want to fall for that again. And they're still at it, see discussions of Open Sockets in Windows XP.

One thing that is intriguing about .NET is the ability to treat objects in one language as objects in another language -- for example you can inherit VB objects in C#. This could be very interesting if you weren't stuck in Microsoft's world. A recent development has made me consider the issues a little differently: an Open Source Version of .NET. If this works, I'm going to pay a little more attention to it -- although I would almost certainly come at it from a Python approach rather than bothering with C#.

But in the end, who knows? I'll leave the door open.


@

How about a book on Delphi (or insert your favorite language here)

I have a long history with Delphi. I remember being in my friend Zack Urlocker's office at Borland when he showed it to me for the first time. I told him that I liked the name, and that he should keep it (it was originally a code name for the project; I suspect many others told him they liked the name as well, but I like to think I had some influence...). Every once in awhile I would take a dive into it, and create the odd program. The summer of 2000, after the Borland conference, I sponsored Marco Cantu to give an advanced Delphi seminar. The best equivalent for a "Thinking in Delphi" is Marco's collection of books.

Even though Pascal, and Turbo Pascal, were my first languages, I have had so much experience in C-ish languages that it's awfully difficult for me to go back to Pascal syntax. So if I *did* need to create a Windows-specific program and I couldn't use Python (my favorite language, which I use all the time) then I would probably use C++ Builder, since I am much more fluent in that syntax.

And books, well. They're getting harder to do, and taking longer, so I get very careful about what I think I can do. I suspect it has to do with what I want from a book, which is based on all the feedback I get about the books I put up on the Web. I'm sure my process could be improved but in general I'm getting slower rather than faster at producing books (and of course I'm slowed down by all the other things I do -- but somehow Martin Fowler is able to pull it off...).


@

Do you have any opinions about the Ruby language, especially compared to Python?

I keep trying to like Ruby. This question arrived for the nth time on a day that I just happened to spend about 45 minutes in the bookstore looking through the Ruby book. (Please note that I have looked at the language before, so my opinions here are not limited to a 45 minute perusal of one book. Also note that I've looked at a fair number of languages, and learned some of them in depth, so I like to think I know what I'm looking for).

The question that kept popping into my head as I was going through the book was "why?" Why did the language designers bother doing this? So far I keep coming to the conclusion that Ruby is just a bad ripoff of Python, just like C# is a bad ripoff of C++ and to some degree Java (I'm willing to be convinced otherwise about C#, but so far the only compelling reason seems to be "blessed by M$." There's certainly nothing compelling about the syntax or power of C# compared to C++).

IMO, the Ruby syntax is worse and often annoying to me, based on my knowledge of other languages and especially Python. Ruby is much more like Perl in syntax than it is like Python, and I spent enough time with Perl (2 months) to think it was great, then run into its walls. Anything that looks like Perl, or does things because Perl did them that way now says "walls" to me. Ruby requires more typing for no particular reason, and has an uninspired choice of syntax in many cases (there were some minor interesting features like static class methods, but this is a tiny amount of syntactic sugar and won't solve any problems Python doesn't). Plus Python has 10 years behind it and a big, very smart, very active community, a nice number of good books and more on the way, a large set of libraries and a whole process and team in place for developing the language. Recent improvements to the language have outstripped whatever Ruby could offer, I think, and there's currently lots of very good work going on to further improve Python.

FWIW, I usually find that this question is asked by someone who is considering learning to program, and was snagged by the fact that Ruby is new, and perhaps thinks that it's going to be the next great thing like Java. From everything I can see, it's not. For some reason, the creator of the language saw Python and decided to do a clone, and people who had never used Python thought it was a good idea. Harsh, maybe, but that's my impression: if you've used Python at all, you wouldn't give Ruby a second glance.

Perhaps the real question to ask, which is usually what I ask myself when I'm looking at a language, is "what does this language do/accomplish/improve that is better than the language it is competing with (in this case, Python)." Here are some comments readers have made:

  • "Under the hood Ruby is pure OO" [ I get the feel of OO from Python when I'm programming. Perhaps there's some way to argue that "purity" will contribute to my productivity, but such arguments have not panned out in the past. Also, why is "purity" a good thing? Java claims to be more "pure" than C++, but in many cases that just gets in my way and makes me type more, put things in classes that don't belong there, etc. ]
  • "Writing Ruby extensions in C are a joy compared to Python" [ I believe it. I usually find that languages have some kind of improvements here and there, but not enough to say that you will, for example, double your productivity over using Python ]
  • "Ruby needs more libraries" [ And libraries are the fundamental unit of reusable code; without them, you're going to be treading water with Ruby, and be far less productive.]

Again I ask "why"? If you're not going to double your productivity over using Python, what is your motivation for using this language? Personally, my interest is in being productive, and based on that I believe my evaluation of Ruby is reasonable. If your interest is in exploring languages then we are evaluating based on different criteria, and you may certainly judge my evaluation to be wrong.

Here's an alternative evaluation of the language, on the Ruby site. Note that the author says "If you like Perl, you will like Ruby." I liked Perl for about 3 months, before discovering Perl objects and references and trying to read my own Perl code. I haven't looked back. The author also notes that, as a Python programmer, Ruby hasn't won him over (yet).

A commentary by Andrew Dalke seems to go further into issues that are important to me:

What do you see as Python's niche? I see it as a language which is usable by beginning programmers and enjoyable by experienced developers. I don't see Ruby really fitting the first of those. (I don't see how '@var' obviously means "instance variable" nor '$var' for "global variable", while Python's is much easier to explain, since the 'self.' makes it more apparant. I like that Python doesn't have an implicit return of the last evaluated expression, making it easier to find them. I like that I can say "methods inside of __s are special" as compared to Ruby where you have to memorize that things like "to_s", "initialize", have special meaning. I like that empty function calls still need a () in the declaration. I don't like that Ruby promotes adding methods to existing classes, since I think that can lead to conflict. I think 'abs(x)' is better than 'x.abs' or 'x.abs()'. I'm forgetful, so I don't like special syntax shortcuts, like
  a = %w{ ant bee cat dog elk }
for
  a = ["ant", "bee", "cat", "dog", "elk"]
(especially since it can be written
  a = "ant bee cat dog elk".split()
I don't like that regular expressions are treated with special syntax. I don't like having aliases, as Hash.indexes/indicies, Array.len/size. Ohh, and Hash has three equivalents in has_key?(key) / key?(key) / include?(key) .


@

I'm thinking of publishing/been approached by a publisher. Do you have any advice?

I could probably go on and on about this, but it turns out someone else already has. Read this.


@

Why do you put your books on the Web? How can you make any money that way?

I think we're clearly in the brave new world of the Internet here, and as far as I know I may be the first to do what I did -- publish the book as I was developing it, and leave it as a free book in perpetuity, after it was printed. Personally, I was prepared to have low sales but the book brought people to my web site and to the CD Rom and seminars, so I felt it was worth the risk. Prentice Hall did a low first printing because they were worried about the online book cannibalizing sales. However, this book has done better than all the other books I've written — for the first time I've gotten royalty checks that have made a difference (book publishing in general is a pretty high-risk business; the figures I've heard are "10% break even, 1% are profitable).

At this point I would never go back to the old model of print publishing. All of my future books will be electronically published on my site first, and will stay on the site. The reasons for this are many:

  • (Possibly most important) I get extremely valuable feedback during the development of the book. I've never had any useful feedback to speak of from the so-called technical reviewers hired by a publisher, but I got an endless stream of incredibly valuable corrections from readers.
  • Readership is built throughout the development of the book.
  • Publication dates are not so critical: if you are only printing the book, then it's either available or not available, whereas if it's on the web it's always available in some form, so there's not so much of a compulsion to rush out a half-finished piece of work in order to meet the needs of the readers.
  • Books can be adopted by universities before they are printed. I give permission for universities to print copies of the book for their classes, as long as they sell to the students strictly at the cost of printing (no profits==no hassles, nobody battling over profits, etc.). When the book is actually printed by the publisher, the university has already decided to use it for their classes, and they tend to be reluctant to change.
  • I get a fair amount of mail from 3rd world countries saying "we could never afford to buy this book here, but because it's electronic we can still learn." I know this is of no interest to publishers (pardon my cynicism) but if you're like me and you want to reach people this really does the trick — you're making a big difference. On a more practical level, folks who may not have money now but eventually will get to know you, and when they can purchase they're much more likely to purchase your book.
  • In general, the fallout from doing this has been all positive and nothing negative.

However, I've also heard the refrain — mostly from publishers who were interested in "Thinking in Java," trying to talk me out of leaving it on the web — that "we've tried this and it negatively impacts book sales." Upon closer inspection, though, what one discovers is very interesting. The experiments I heard about turned out to be with books that weren't doing very well in the first place, and lo and behold, if you put them on the Internet then people get a chance to see what the book is before buying it, and amazingly enough fewer people buy a book if they discover it's not very good before buying it.

Another issue is the type of book. As Elliotte Rusty Harold pointed out, "The Java Programming Language Specification" isn't exactly the best litmus test. Personally, it's not the kind of thing I need in paperback; in fact, I would much prefer to have it electronically since I'm not going to read it cover to cover, but rather search through it when I'm trying to figure out some particular language quirk. In that case, I would have a free version and then sell an enhanced electronic version that somehow made it easier to use, and then finally a printed version. But "Learning Python" is a book that I want to read, away from the computer. That's what many, many folks said about "Thinking in Java": they wanted the paper version of it, some folks got quite belligerent when they couldn't get it after awhile.

I think there are books that you want to read as books and others that make more sense as electronic books. But my experience is that if people download the book (even the whole book; I know some books publish a chapter or two, but giving the whole book away doesn't seem to make any difference) and they like it, then they want to buy it, and it doesn't seem to me that they buy it because they want to give something back to me (like the 2 dollars or whatever makes that big a difference to me) but because they want the thing printed out for them on paper (and it's nicer, and in most cases cheaper, than if they printed it out on their printer).

I think this is the wave of the future. In the past, publishers controlled publishing because they controlled trucks and printing presses, but now that is not (so) necessary. Which means that publishers now must re-evaluate themselves and say "what do we really offer" (of course, this includes publishing of everything including conferences, which I am also involved in — but that's another story). That's a good thing, I think.


@

Why do you think open source works?

This is the question that comes up a lot with open software: "If we give away the cow, how do we make money?" So far, the only answer is in cow maintenance: people really just want the milk from a reliable cow. If you sell them a cow in a closed box, then they don't really know what's going on, whether the cow is sick or dead (Microsoft has been selling sick cows — some would say with mad cow disease -- for a long time now, and getting away with it because they are in boxes), or most importantly whether the cow can be healed or not. So it appears customers are all for just having the whole cow. But now they have the thing and don't know how to service it. Since it's working so well, people don't seem to mind paying for upgrades, for example (and upgrades haven't been that expensive -- the latest version of Red Hat, 6.2, is something like $25 at Costco), and service agreements from companies like IBM. You get a better cow for free, and you can get support if you want to pay for it. One of the nice things about this model is that you actually pay for support, whereas with the old model the company would already have your money when you bought the product, and sure, sure, we provide support too -- but that actually appeared to cost them money, so they tried to minimize those costs and you end up with difficult and not-very-useful support systems. Whereas if support IS the product, then it had better be good or the customer won't pay for it.

Because the source is open, a company can build on it rather than creating a product from scratch, so add-ons become a possibility. Autodesk was so successful because it allowed third party add ons to enhance the product.

Is that all? I have the sense that there might be something else that would be a way to make money with free stuff. The key, as we know but the marketing people always seem to miss, is to try to figure out "what do people want?" The answer in the computer arena is that they want work done for them (that's what computers do). I suppose the other area has something to do with services, possibly like those services that provide you with things like databases for your web site, and email list managers, etc., so that all you have to do is hook these pieces together without doing the programming or maintenance yourself.

Home     Calendar     Notes     Books     CD-ROMS     Seminars     Services     Newsletter     About     Contact     Site Feedback     Site Design     Server Maintenance     Powered by Zope
©2001 MindView, Inc.