Slashdot Mirror

Point taken - I myself think of freely available ebooks as value-add for the treeware, as is the case with Thinking in C++ - but piracy seems to be much more popular with music and video than with books.

If it was legal to build a free-of-charge Netflix-like service that paid nothing back to the companies behind the available shows, and made a profit from advertising, then that service would flourish, to the detriment of the actual content-producers.

Well, it depends on your goals.

For example, if you're a college professor, and your goal is the learning for learning's sake and the distribution of knowledge, and society is already paying you for that, it might be OK to make 50 cents per book, basically the same as you would for traditional publishing.

Re: editing. Take advantage of colleagues or the Thinking in Java model.

copy editing: blog readers/TIJ model/pay someone.

marketing: depends on your goals. If you're not trying to become rich and famous, you don't really need paid marketing.

cover: again, it depends on your goals.

music analogy: Actually at $2.99, for many (most?) people, it'll cost less just to buy the book then to spend time vetting it.

Design books are good, but I think you may have trouble getting much from them until you go through a few real programs and see what problems can occur that design patterns can address.

One great book if you really want to understand Java at a much deeper level, is Thinking in Java by Bruce Eckel. It's really a great place to start, to understand how to use the language the way it was meant to be used - and that in turn will make your life easier, sort of like not putting your shoes on the wrong feet even though you can technically make it work.

Unless you can come up with a thoroughly researched and peer-reviewed paper which accounts for all the more recent approaches to static type checking (like typeful programming, dependent types, etc.) supporting this, I'd say you were full of shit.

I'd say you weren't paying attention. I didn't say that static typing never catches errors, I said that it does not catch as many errors as originally envisioned. As nearly any programmer can attest, it's a rare treat to have a program operate correctly after the first compile. More often than not, you need to perform iterative development and debugging to ensure the correctness of the code. The unfortunate result is that developing for a statically-typed vs. dynamically-typed language makes little difference to this process.

That being said, there are some advantages to a statically-typed language. e.g. There are no untested code segments with typing errors waiting to blow up. The code may blow up for other reasons, but typing won't be one of them. (Unless you force a cast, that is. Casted objects can blow up quite nicely.)

The other area where it's a good idea is when your code will share out or access a standard interface outside your project. In such cases, typing can create a contract that ensures the correct use of all APIs.

That's why I suggested the use of a JS2.0 compiler for times when typing is important. JS2.0 is a softly typed language. Typing can be defined to ensure correctness, but typing is not required. This allows for interfaces and APIs to be exposed properly while leaving the individual developer a free hand to design his code in a classless fashion.

I'm not going to write an entire dissertation on this, so see Bruce Eckel's excellent article on this issue for a decent introduction to the compile-time checking issue.

Besides, JavaScript gets what is arguably the most important feature of any language, namely scoping, completely and utterly wrong.

You've just pointed a finger at the very thing Javascript gets absolutely correct. While the scoping system may seem weird and even incorrect to coders with experience in other C-style languages, the Javascript scoping system is what welds the OOP aspects of the language together with the functional aspects of the language. If you changed the scoping system, you'd completely destroy Javascript's object system in addition to gimping its functional aspects. Which would leave you with the just the crappy procedural code that your average web developer creates for neat webpage effects.

There are many resources available for iPhone/Cocoa programmers. The earliest versions of Cocoa shipped commercially in 1988, and the most used features and patterns haven't changed much. Here is a good place to start: http://www.cocoadev.com/index.pl?CocoaPrerequisites

Why does Objective-C use BOOl and YES,NO instead of bool and true/false? One reason is that Objective-C predates the addition of the bool type to standard C by 11 years.

If you don't like dynamic languages, you won't like Objective-C. Bruce Eckel makes an interesting argument for dynamic languages at http://www.mindview.net/WebLog/log-0025.

I think the ability to seamlessly use and intermix the world of C and C++ software with Objective-C outweighs and criticism that Objective-C includes C.

You must keep an open mind - There are an infinite number of different ways to solve every programming problem. Many programming languages and reusable software libraries use different approaches to solve common problems. There is a good chance that Objective-C and Cocoa use a substantially different approach from other languages and frameworks you may have used. That doesn't make either approach better or worse automatically. Every commercial software development technology has advantages in at least some cases or the technology would not exist. Cocoa is renowned for enabling very high programmer productivity without constraining the set of problems that can be solved, but programmer's opinions will always vary and software development environments are subject to aesthetic judgments irrespective of abstract technical merit. Many programmers are enthralled by Objective-C and Cocoa. You might be enthralled too. Or, you may never like Objective-C and Cocoa from an aesthetic standpoint, and there isn't really anything anyone can do to change that without affecting the aesthetics for others.

• Thinking in C++ by Bruce Eckel http://mindview.net/Books/TICPP/ThinkingInCPP2e.html
• Computer Networks by Andrew Tanenbaum http://www.prenhall.com/tanenbaum/details2.html
• Structured Computer Organization by Andrew Tanenbaum http://www.pearsonhighered.com/educator/academic/product/0,,0131485210,00%2Ben-USS_01DBC.html
• Producing Open Source Software by Karl Fogel http://producingoss.com/
• Design and Implementation of the FreeBSD Operating System by Marshall Kirk McKusick and George V. Neville-Neil http://www.mckusick.com/books.html
• Code Quality by Diomidis Spinellis http://www.spinellis.gr/codequality/

I got another one to prove otherwise.

Bruce Eckel for a while released his books for free. And initially things went very well. But then things went downhill because people would end up NOT buying his books.

Cite?

They would have read his books, but not bought them.

I only heard of Thinking in C++ because of the buzz about it being free. I read it online and liked it. I bought two copies on paper, one for work, one for home. My anecdote beats your unfounded speculation, 0 data points to 1.

Now Bruce is not making the later editions for free anymore. Why? I can only surmise that it did not work out.

Ah yes, the incontrovertible proof that comes from idle speculation.

I once asked him and he said, "oh yeah that it was an interesting experiment."

That answer is pretty evasive. Sounds equally likely that he could either be disappointed in the sales, or uncomfortable acknowledging he used the Open Source/"FREE STUFF!" model to make a name for himself. It's a perfectly valid strategy, but the FOSS crowd can have some freaky folks, and he might very well be concerned about being labeled a "sellout"...

I know Bruce personally and he is not a money freak. He is a very nice guy. He is in fact somebody who likes Open Source, etc. But I know he also has to feed himself and I wonder if sales did end up going down...

If the freebies are depriving him of sales, why does he still maintain a list of places where you can download the stuff on his web site? Again, you offer nothing but idle speculation.

It actually disappoints me because Bruce was very willing and wanted to help the community. But the community let him down...

Conclusion not supported by evidence. You're claiming to know Bruce's motivations with nothing to go on but a very evasive answer from him.

for example
Bruce Eckel's thinking in c++/java/python http://www.mindview.net/Books
some good free perl books http://learn.perl.org/
always javascript or
Introduction to Computer Science using Java
http://chortle.ccsu.edu/CS151/cs151java.html

there's more

Thinking In Java by Bruce Eckel is available for free from his website. I recommend it as a starting point.

Thinking in Java is a good book on the Java language. You can read it online at the author's web site: http://www.mindview.net/Books/TIJ/

Thinking in Java is nice. And it's free. http://www.mindview.net/Books/TIJ/

Security has nothing to do with strong/weak typing. Strong typing is simply the first stage of testing code and validating input.

http://mindview.net/WebLog/log-0025

I can remember when I was learning Java (around 2000 iirc) that one book proved invaluable in learning the language - and it was (and still is) free! It has been released in the forth edition now so I believe it is quite successful. Thing is the author got his and his book's name out by sharing it with the online community. Not only that, but he got direct feedback from the community on anything from source code bugs to overall structure. It's the perfect way to improve the quality of a book - listen to your readers and see where most people would like an improvement, then simply improve it (given, of course, that most of your readers aren't complete morons ;). In fact, this model proved so successful he went on and wrote two other good books "Thinking in C++" and "Thinking in patterns" in much the same way.

It kind of has some similarity with an open source project with the author in control and deservedly so reaping all the monetary profits. The community on the other hand profits from a very useful book, that you can buy in order to take advantage of the "paper-format" as opposed to a PDF displayed on your monitor, or simply to support the author (yes, not everyone is entirely egoistic in this world). And those poor students who can't afford spending to much money get a great product absolutely for free. And perhaps a couple of years down the road a few of them will write a book just like that about the next programming language that comes around or start some kind of other open collaborative project that benefits the community..

However, his recent book, Thinking in Java, Fourth Edition, is no longer available in a free, electronic form.
Well, you can still download the third edition for free. It is interesting, however, that he seems to have given up on the idea of making his books free in the future. He started doing it back before anybody else was doing it, ca. 1999, and his example was one of the things that influenced me to make my own textbooks free online. I wonder whether he's soured on the whole idea, or has some other legal or financial reason why he can't do it with the fourth edition of the book.

I agree. This guy found a proprietary solution that fits his purpose...and he's promoting it. This is a fluff piece for Flex.

Um. No. Quoth his own bio page:

He is the author of Thinking in Java (Prentice-Hall 1998, 2nd edition 2000, 3rd Edition, 2003, 4th Edition, 2006, see www.BruceEckel.com), the Hands-On Java Seminar CD ROM (available at www.BruceEckel.com)

He was a founding member of the ANSI/ISO C++ committee. He speaks regularly at conferences and was for many years the chair of both the C++ and Java tracks at the Software Development conference.

Thinking in Java also received the Jolt Award, for best book published in 2002, as well as the Java World Reader's Choice Award and Java World Editor's Choice Award for best book, the Java Developer's Journal Editor's Choice Award for books

Bruce was the "Java Alley" columnist for Web Techniques magazine

I'm not even a Java guy, and I know Bruce Eckel knows what he's talking about when it comes to Java. A shill he ain't.

Not only that, Eckel also wrote two volumes of Thinking in C++, which in my humble opinion is far, far more readable than the Intro CS standby by Deitel & Deitel. He also gives this book away for free! Check it out. So in my mind, Eckel, being very familiar with Java and the alternatives to Java, is supremely qualified to comment on Java's good and bad points.

The other advantage is that Java and C++ can be had for free with nice helpful IDEs. The Eclipse CDT (http://www.eclipse.org/ ) with cygwin (http://www.cygwin.com/) provides a fairly full IDE (and you can tailor it's key interface to EMACS :-) ). Eclipse also looks to be a fair Java IDE and there is also netbeans (http://www.netbeans.org/).

As a book I would suggest one I have enjoyed using in its online form, Thinking in C++ by Bruce Eckel (http://www.mindview.net/Books/TICPP/ThinkingInCPP 2e.html). It has the advantage that there is also a second volume that takes you into using more advanced features (fancy templating, STL, and some more complicated patterns) that they can look into or you could use as a follow on.

My current favorite Java programming book is Java Concurrency in Practice by Broan Goetz and others. It's not for beginners, but if you really want to understand how to write multi-threaded code in Java you need to read this book. Several times, probably, because it's a tricky subject.

Other books I like for Java are Effective Java (though he needs to update it for Java 1.5) and Java Puzzlers.

I don't know of any books that are good descriptions of the Java 1.5 features for experienced programmers. Some people like Thinking in Java, but it seems pretty wordy to me. I originally learned Java from Java in a Nutshell but it's been something like 8 years, so I don't know if the newer editions are any good.

Disclaimer: some of the authors of these books are my co-workers, though I don't know them very well.

...is Bruce Eckel's Thinking in Java which has already invented the idea displayed here. Thats why you'll see that this book (tij) doesn't fully go into the bare Jave code but mostly reflects on the things which really matter. Knowing what things like Objects are, why objects differ from primitives, etc. Being a Java enthousiast myself it still amazes me how many people "program in Java" yet never learned how to interpret the JDK documentation, especially the so called API documentation.

Anyway, the Thinking in Java book is both available for free download (see URL above) and if you wish a hardcopy (or the latest release) then you can also purchase it. In my opinion this is a much better book which is also presented in a more fair way.

...is Bruce Eckel's Thinking in Java which has already invented the idea displayed here. Thats why you'll see that this book (tij) doesn't fully go into the bare Jave code but mostly reflects on the things which really matter. Knowing what things like Objects are, why objects differ from primitives, etc. Being a Java enthousiast myself it still amazes me how many people "program in Java" yet never learned how to interpret the JDK documentation, especially the so called API documentation.

Anyway, the Thinking in Java book is both available for free download (see URL above) and if you wish a hardcopy (or the latest release) then you can also purchase it. In my opinion this is a much better book which is also presented in a more fair way.

Even if photocopies or digitized scans of books are legal for personal use, it wasn't until recently that such a thing was technologically possible. The very nature of the book prevented you from making a copy of it, without laborious hand copying, which is akin to, but much harder than, the type of copying possible of DVDs and video tapes. Granted, it happened. Just look at the history of Shakespeare's plays. Even now, scanning a 300 page book, running it through OCR, and fixing the inevitable problems is much harder than copying a DVD. Granted, it happened. Just look at the history of Shakespeare's plays.

To me the biggest change has been for the creators of content - in the past one was happy when one's works were heard, read, watched, because that made one popular, and thus, successful. Writers didn't actively encourage copying, but they didn't fight it too hard, as long as they were credited for the work, and as long as the work wasn't too corrupted. Shakespeare never made a penny off his plays being published, but he gained in popularity due to their publication.

Since we don't have sponsors anymore, writers need to make money off selling our work. That puts artists in the place of wanting their work to be wide spread, but also controlled. It's an odd situation to be in. I'd love everyone to read my work, but I'd also like to make some money off of it. Some are successful at allowing free usage (look at Thinking in Java for an example) and some aren't.

I still think the difference between DVDs and books aren't that different when it comes to ownership. Both can be copied, if one is willing to work hard enough. In both cases it's not the physical media that one buys, but one particular instance of the content.

Absolutely spot on. I was a Philosophy Major in College and I totally agree on the inherent problem solving nature that formal (symbolic) logic and critical thinking provide in determining solutions. Obviously, you don't need formal training to 'get it' (as you demonstrate.) In fact, I daresay, some Philosophers don't get it.

Curiously, Philology (study of language) was always closely aligned with Philosophy. Nietzsche was a Philologist. Studying human languages (Latin, Greek, French, etc.) and studying programming languages (can't think of any right now) are very similar. Objects (nouns) have methods (verbs) and properties (adjectives). Think back to diagramming sentences if you ever did that.

In fact, reading Bruce Eckels Thinking in Java, I was struck by his outlining of Classes and thought, "This is Aristotle". Sure enough, he says the same thing on the next page.

Finally, it's worth noting that just about every science has its roots in Philosophy. In fact, the Scientific Method is a Philosophic proof. ;-)

Luckily, you there are workarounds, such as using Eclipse instead of swing and a different language to avoid checked exceptions.

Most studies show that this is blatantly untrue -- programmer productivity is generally independent of language chosen.

Excuse me? Which studies?

Certainly not this one:

http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpp rt_computer2000.pdf

Nor this one:

http://www.erlang.se/publications/Ulf_Wiger.pdf

Nor even this one:

http://www.theadvisors.com/langcomparison.htm

And this well-regarded programmer certainly doesn't agree that the choice of language doesn't matter:

http://www.mindview.net/WebLog/log-0025

I tell you what -- interview a group of experienced programmers for a prospective project to write a database-backed web application with complex requirements. Tell them that they will be required to program in assembly language because "most studies show that... programmer productivity is generally independent of language chosen." Record their responses and post them to Slashdot.

I don't understand as a developer what dynamic typing does to help a language, and what real world advantages it offers the developer.

Fact: Nothing is free.

Everyone will agree with that in principle, but few people have internalized it.

Static typing is not free. It makes you jump through hoops to type correct code. When you need to change a type, it's even more difficult, especially when it's not something you can search and replace. When changing requirements require you to refactor out some interface, this costs yet more.

The great failure in this debate between static typing people and dynamic typing ethusiasts largely arises from the fact that static typing people can only see the benefits of static typing, and only see the costs of dynamic typing. You particularly made reference to your own inablitity to see the benefits in your post.

You can't complete the debate until you admit to yourself that there are costs to static typing, and benefits to dynamic typing. Only then can you intelligently weigh the costs and benefits of each approach.

I think dynamic typing wins in the vast majority of cases not because "static typing has no advantages", but because static typing charges you through the nose for very, very dubious benefits. Yes, static type correctness catches bugs. But what kind of bugs does it catch? Type bugs. All in all, as someone working in dynamically typed languages exclusively for years now, that's just not the kind of bug I deal with very often. I have logic bugs, architecture bugs, library bugs (bleh! and no these aren't type bugs), comprehension bugs, specification bugs, but I just don't run into type bugs that often. Thus, "paying through the nose" to avoid this particular type of bug is not a compelling bargain.

You're almost always better off taking the development-speed gains of a dynamically-typed language, and learning the discipline to write good tests (which, incidentally, tend to be easier in those languages). Static type correctness has very little overlap with program correctness. (Neither is even a subset of one another; it's perfectly possible to have a completely correct program that does not meet some definition of "static type correctness".) (Elaboration by somebody else.)

There are rare calls for static type languages, where it is so important not to make any type errors, ever, that's it's worth the pain of using them. But it's pretty rare for most programmers. (Of course there are programmers who deal in that exclusively.)

One of the things that could conceivably tip the balance back in favor of static type correctness is if static type correctness becomes more cheap, perhaps with such things like better type inference. But few things are worth the unbelievably staggering price you pay in Java for static type correctness. If you've never used a dynamic language for long enough to see the benefits, you have no idea just how much you are paying.

Until someone shows me that all the code that I've written in dynamic languages that have served tens or hundreds of thousands of people are somehow riddled with type bugs that have somehow failed to cause my code to come crashing down, I'm going to continue to use dynamically-typed languages. The predictions of doom if you let go of static typing have so far shown themselves to just be fear-mongering, quite a lot of it (as far as I can tell) from people who learned in school that static typing was important and have never even tried anything else.

I suggest:

• How to Think Like a Computer Scientist: Learning with Python, introductory, available both in electronic form (for free) and printed;
• Thinking in Python, advanced, available only in electronic form (for free);
• Python Cookbook, Second Edition, advanced, available only in printed form, but it's a really good book.

Good reading.

I'd actually forgotten that some people use the one-statement unbraced-if in Java or C-ish code - I (and most of the teams I've worked with) use the always-brace-even-single-statements style.

But more generally (and more relevant to the original line of discussion :)) on Python's "safety" (relative to Java, etc.) in a team dev environment - I just last night reread Bruce Eckel's Strong Typing vs. Strong Testing article. You may also find it worth a (re-)read. It talks specifically about programmers coming from the Java mindset to the Python mindset (as Bruce did) and eventually concludes that a proper unit-testing regime completely supersedes compile-time syntax/type checks for verifying code correctness... and the same applies in Python. He emphasises his point of view with:

I came to feel so strongly about this that in the third edition of Thinking in Java, I wrote: If it's not tested, it's broken.

Of course, Bruce is a unit-testing nut. But that's not necessarily a bad thing to be. :)

"It'd be pretty silly to be missing something like dlopen or LoadLibrary..." Just like missing checked exceptions? Yeah that would be silly.

I'm pretty sure dynamic class loading has been around longer than Java, or even unchecked exceptions. So I say it would be sillier to be missing a way to dynamically load classes.

Out of curiosity, how many "major" languages have checked exceptions? Java is the only one I can think of off the top of my head.

It's been a while since I worked with Java, and I'm far from an expert. But when I was dinking around with it, I found it extremely annoying that I had to label every function that could possibly throw an exception. The compiler needed to be smart enough to detect whether a function might throw an exception, in order to tell me that I had forgotten to label it... So if the compiler can tell this without me telling it so explicitly, that pretty much relegates the label to syntax-enforced documentation.

Not to mention people got so sick of being required to write pointless code to handle pointless exceptions, that they figured out a ways to hack around it, making the checking useless:
http://www.oreillynet.com/pub/wlg/5559

All of that seems silly to me. But that's just MHO.

Or maybe it's not just mine. This guy, and many others, seem to agree that checked exceptions in general are kind of silly:
http://www.mindview.net/Etc/Discussions/CheckedExc eptions

OH! Yes! I nearly forgot! Electronic copies are available for free!

Strong Typing vs. Strong Testing From the man himself.

I think you forgot to mention that "Thinking in Java" is also a free download, no strings attached. The C++ version of this book, "Thinking in C++" (also a free download), helped me "get" OOP.

I think you forgot to mention that "Thinking in Java" is also a free download, no strings attached. The C++ version of this book, "Thinking in C++" (also a free download), helped me "get" OOP.

Bruce Eckel has some great books here. I use them as reference for OO stuff. There is also Windows Internals, great book, for windoze code monkeys.

I agree with the above and I'm not sure as to how well qualified this guy is to comment.

Bruce Eckel (http://www.mindview.net/ author of "Thinking in Java") seems to disagree with Brown's view on OOo 2 in his blog: http://www.artima.com/weblogs/viewpost.jsp?thread= 133553 (Eckel is not an OSS programmer though he did work on Zope), he doesn't say OOo is perfect, but he was almost ready to give up Windows in favour of MacOS X because of it.

...I'd say here:

http://mindview.net/Books

and here:

http://www.c2.com/cgi/wiki?WelcomeVisitors

and maybe here:

http://www.objectmentor.com/resources/articleIndex

And although a lot of people around here would probably disagree, I think it would be worth your time to go back and try to get a Computer Science degree. Programming != Computer Science, but it's helpful to understand the scientific principles that modern software development is based on.

Don't know about you, My teachers taught me how to learn. Maybe some of it was incopentence or ignorance, maybe it was the fact that we were both looking at the computerized typewriter (no kidding Paper output only) for the first time. The very best example (and I use this with my children) is to say "I don't know, lets find out." I learned this early and often. How to find out is often way more important than the information you may need at this very second.

I later have had brilliant teachers try to impart what they know in the short time they have, and fail miserably with 90% of the class. Computer Programming is just Composition: Syntax, punctuation, Form and Logic(hopefully). But the rules change from language to language.

Reference Documentation is our life.
The trick is how do you make the students want to know bad enough to read the dry docs.

Along those lines may I suggest you throw http://poignantguide.net/ruby/ at them.

I second Python and Pygame, for reasons already covered.

I also recommend the Excellent "Thinking in..." books by Bruce Eckels. C++, Java and Python(haven't read that one, yet.)http://www.mindview.net/Books But my best recommendation, dont laugh:
Microchips PIC assembler. Short BOOKS/command list, lots of intro to memory, bits, arrays, data flow, Structure and syntax.Throw in some basic electronics. Nice introduction to the complexities of how things work.
Good C compilers but much bigger instruction set really should have c background first.

VB.net Bad......VB EvIL
Basic lesser of three.

You could try Eckel's Thinking in C++, which is available for free in electronic format via his web site.

Writer Bruce Eckel has been publishing his books as beta for several years now. Even though I could download his books series "Thinking in Java" and "Thinking in C++" for free I still bought the final versions in printed form. I think the final releases of these books really benefitted from the beta-releases.

Writer Bruce Eckel has been publishing his books as beta for several years now. Even though I could download his books series "Thinking in Java" and "Thinking in C++" for free I still bought the final versions in printed form. I think the final releases of these books really benefitted from the beta-releases.

I'm surprised no one mentioned (perhaps I've missed it?) Thinking In C++, by Bruce Eckel. It explains every subject in a very clear manner, providing quality examples throughout the two volumes. Not only that, you can download the book for free from http://mindview.net/

That's certainly amongst the most important differences between java and python.

Others include more concise syntax, more dynamic objects (can be modified at runtime), meta programing, and functional language like constructs.

Try these (watch for URL mangling)
http://www.ferg.org/projects/python_java_side-by-s ide.html
http://www.mindview.net/WebLog/log-0025
http://mindview.net/WebLog/log-0063
http://mindview.net/WebLog/log-0052

I put a bunch of links to Bruce Eckel's site because he is a well known java expert as well as an avid python programmer.

That's certainly amongst the most important differences between java and python.

Others include more concise syntax, more dynamic objects (can be modified at runtime), meta programing, and functional language like constructs.

Try these (watch for URL mangling)
http://www.ferg.org/projects/python_java_side-by-s ide.html
http://www.mindview.net/WebLog/log-0025
http://mindview.net/WebLog/log-0063
http://mindview.net/WebLog/log-0052

I put a bunch of links to Bruce Eckel's site because he is a well known java expert as well as an avid python programmer.

That's certainly amongst the most important differences between java and python.

Others include more concise syntax, more dynamic objects (can be modified at runtime), meta programing, and functional language like constructs.

Try these (watch for URL mangling)
http://www.ferg.org/projects/python_java_side-by-s ide.html
http://www.mindview.net/WebLog/log-0025
http://mindview.net/WebLog/log-0063
http://mindview.net/WebLog/log-0052

I put a bunch of links to Bruce Eckel's site because he is a well known java expert as well as an avid python programmer.

Does anyone know of a good book on C++ programming in Linux?

How about just a good book on programming C++? Should cover most of what you want to know. Most C++ stuff is not platform specific.

The best C++ book that I know is free online here. If you want move on from there you could always buy Stroustrup's book, but I found it a little opaque. If you really want to move to the next stage read "The C++ Standard Library" by Josutti.

I thought C++ (or at least, C) was supposed to portable

C != C++, so comments that C is supposed to be portable, and therefore C++ being supposed to be portable are just silly. Anyway, C++ is portable, but it depends on how you write it. First off, if you use Microsoft specific stuff (eg #include , Win32API etc), of course it won't work. On the other hand, you might want to be aware that g++ does not support as much of the STL (Standard Template Library, read Josutti for details) as the Microsoft compiler. This may come as a surprise, but the Microsoft C++ compilers have consistently been the best at complying with the standards.

Anyway, I'd stick with VS.Net. It is actually an excellent C++ compiler, probably better than g++. You do need to understand how to use it though.

Before the locals gather their pitchforks to run me out of town, here's why:

-If you don't know much about programming, even something basic like vectors or graphics libraries could be more than a little daunting. Flash makes graphics dog-dumb easy, leaving you to focus on the logic. A lot of the abstractions (game speed, display parameters, collision detection) can be handled easily, leaving you to learn how to program.

-You can do some OO programming with Actionscript, so you can start with a simple program, and when you get skilled, learn how to extract that functionality into libraries or classes.

-You should be able to focus on some simple programming aspects like game physics, or making it fun (which doesn't have much to do with programming).

-There are a zillion sites out there with bits of code that you can learn from and modify. Granted, lots of it sucks (i.e. it works, but it will not show you how to be a 'good' coder). Offhand, I don't know what to recommend to become a good coder, but at the least, I'd recommend plowing through at least the first 3 chapters of Bruce Eckel's Thinking in C++ (free online). Once you get through pointers and address references, actionscript will look like child's play. Sure, there are sites out there with sample PyGame/Java/etc. code, but Flash code is easier to cherry pick and drop in.

-You have to realize that what you're doing is similar to saying "I've never turned a wrench before, but I want to build a car in 4 months." Game programming can be exceptionally difficult on a number of levels.

it is usual to see code where people capture (because they are forced by the language) and ignore exceptions (because they are too lazy and/or stupid to understand the consequences).

In my Java code I'm pretty paranoid about catching exceptions and handling them in as intelligent a way as I can, and even so I've run into plenty of situations where there's really no good way to recover from an underlying error and I end up just repackaging the exception into a higher-semantic-level one and tossing it upstream, where the upstream code does the same thing, all the way back out to the UI code, which displays an error message. At which point all I've achieved is cluttering up the intermediate layers of code with useless exception handlers when I could have gotten exactly the same effect by just catching a superclass exception in the UI code and displaying the same error message. (In addition to catching any specific exceptions that would cause a different result, of course.)

Most likely anyone who's written a Java app of any appreciable size has run into exactly the same thing. In theory, and in small sample snippets of code, checked exceptions seem great. In practice, even some experienced Java gurus find them more hassle than they're worth. I'm quite certain that over the years I've spent far more time writing code to handle checked exceptions than they've saved me in debugging or diagnosis time. That to me is not the sign of a helpful language feature.

Even then, C is probably one of the worst languages to write a game in (except maybe assembler). If you are using C because you are too lazy to learn C++, you're in for a world of pain. It's possible to do OOP in C -- it's just a horrible, horrible pain in the ass.

Seriously, people, read one of Bruce Eckel's books or something. They are available for free on his website and they are the the best programming books I have seen so far.

Also, another piece from Bruce Eckel here. This is even more clear in its skewering of Java Generics. It really sounds like Sun dropped the ball on this one.

Also, another piece from Bruce Eckel here. This is even more clear in its skewering of Java Generics. It really sounds like Sun dropped the ball on this one.

One step further along that road: consider using Python to glue together old pieces.

If Java was a step toward elegant simple expression away from C++, the Python is yet another wonderful step in that direction. The URL is for Bruce Eckel's site: he of the Thinking in {C++,Java} book series fame.

You can glue together all those highly efficient numerical kernels written in FORTRAN, C or C++ with a nice object oriented scripting language. No need to go through more off-road stress testing of a new Java implementation of SomeOldAlgorithm with all the quirky corner cases that people have already hit using the crust old code in languages no one wants to learn anymore.