Slashdot Mirror

Ignore the other two replies to your post as of this writing; they fall into the trap of "countering the opponent at all costs", even if it isn't the best idea.

The real problem with your post is that nothing in it is specific to Java. A lot of other modern languages do those things without the other weaknesses of Java, like Python. The only difference is Python doesn't have checked exceptions but that's a good thing.

Like the Fine Article seems to be (I can't read it, server hosed), that's a fine defense of Java in general, but it only reinforces Paul's attack, IMHO, by listing the "good things" about Java that are in no way unique to it. Paul didn't compare Java to K&R C like you implicitly do, he compared it to Python. You're going to have to work a lot harder to defend Java against Python... in fact I don't think it can be done as I'm basically with Paul here, but if you want to try, that is the real challenge, not defending Java as "better than C". (What isn't? If it isn't better than C somehow, it's dead.)

(The only other major point to make that I am aware of is the so-called "benefits" of static typing, which are also dubious if you actually examine the issue instead of swallowing what the theorists have pounded into your head. Both of the links to Eckel are only samples, there's a lot more on both topics; "eckel " + "static typing" or "checked exceptions" will bring up a lot more in the Google hits below #1.)

Ignore the other two replies to your post as of this writing; they fall into the trap of "countering the opponent at all costs", even if it isn't the best idea.

The real problem with your post is that nothing in it is specific to Java. A lot of other modern languages do those things without the other weaknesses of Java, like Python. The only difference is Python doesn't have checked exceptions but that's a good thing.

Like the Fine Article seems to be (I can't read it, server hosed), that's a fine defense of Java in general, but it only reinforces Paul's attack, IMHO, by listing the "good things" about Java that are in no way unique to it. Paul didn't compare Java to K&R C like you implicitly do, he compared it to Python. You're going to have to work a lot harder to defend Java against Python... in fact I don't think it can be done as I'm basically with Paul here, but if you want to try, that is the real challenge, not defending Java as "better than C". (What isn't? If it isn't better than C somehow, it's dead.)

(The only other major point to make that I am aware of is the so-called "benefits" of static typing, which are also dubious if you actually examine the issue instead of swallowing what the theorists have pounded into your head. Both of the links to Eckel are only samples, there's a lot more on both topics; "eckel " + "static typing" or "checked exceptions" will bring up a lot more in the Google hits below #1.)

I have a plaque on my desk with a series of 9 principles of Object Oriented design that I stole from Bruce Eckel's outstanding Thinking in Patterns with Java. I made the plaque not because I'm a huge fan of OO (which I am), but because many of them are equally useful when designing human interfaces.

Don't be astonishing. In other words, don't do something in a completely new way and don't spring new concepts onto users without educating them first. I've used many designs that were fantastic after a bit of training (Blender comes to mind) but WITHOUT that training you can't do a damned thing. That's astonishing. That's bad design. That's the reason why Apple mice have only one button and the HI guidelines BEG you not to require contextual menus. And for god's sake, don't use a menu called "Script-Fu" and expect people to know what the fuck it does!

Make common things easy, and rare things possible. In other words, allow people to do what they have to do most often in a clear cut way with minimal interaction. If you have additional options, hide them. They don't have to go far away, but don't sour your main interface for an option 99% of users will never need.

Consistancy The A1 most important thing. If you perform actions with the control key on one screen, and with the alt key on another, you've got a crappy interface. If your program uses drop downs for some things and autofill text boxes for others, you've got a crappy interface. Choose one method for managing each type of relationship, one hotkey for each type of function, lay things out in similar fashions, etc. Using visual inheritance helps.

Law of Demeter (don't talk to strangers) A window should only have power over the information inside it, information passed to it and information it sends back. A Tools window that has a save button is useless.

Subtraction A design is only finished when you can't take anything else away and have it be useful. Get rid of all those bullshit options and useless features, they're just making the app bloated and confusing.

Simplicity before Generality A general purpose app that is not simple is not worth using. I point and laugh when I see interfaces like Novell's terrible management utility. Drilling through a tree where every node does something different with no explanation of what they something does is only good if you charge several grand for certifications on that interface. For everybody else, it sucks.

Reflexivity Don't change more than one variable per control, and don't use more than one control per variable. If you've got a drop down that says "Change Name to Rob and Street to Youngstown," you need two controls.

Independence / orthogonality "Express independent ideas independently," something we can argue about as it sort of breaks the simplicity/generality idea. But the concept is this: if you're editing user information on a screen/tab/etc, there shouldn't be anything about filenames on it. If you do have independent ideas that have to share space (say, addresses with names), separate them with different colours, spaceing, group boxes, whatever, so that users know they are different ideas grouped together.

Once and Only Once I could argue this too...the idea that there should only be a single way of entering or editing data is a sound one, but there are many times where it is more convenient for duplicating data or editing multiple records to use two different interfaces. But the basic idea is sound...and if you do allow more than one entry point, it should only be to make things simpler for users -- and maybe the two interfaces should share code (in .NET, I use a lot of User Controls to create "panels" of functionality, thus preserving this principle of design while reproducing the functionality).

Google turned this up, which cites a source: http://www.mindview.net/WebLog/log-0037

I read a pretty good interview w/ Eckel and that guy who has done most of the work on C#. The creator of C# was bashing Java's generics, because they aren't giving the full performance possible. And I agree. There is still such a thing as performance critical code, and Java can make it frustratingly hard to write it. Providing featureful, fast data structures would be a good place to start.

I can't find the article I'm referencing, but this sums up Eckel's view.

Pizza was an alternative implementation of generics for Java. I wish that Sun had chosen this project as their basis for 1.5's generics, rather than GJ (Generic Java). I believe its implementation is much closer to that of C++'s templates. I'd love to use pizza, but it's just not wide-spread enough to justify it in enterprise code.

The How to Think Like a Computer Scientist series is very good for both Python and Java. They also have versions for Logo and C++.

Scheme is not a bad choice for learning programming and the Sussman book which is the intro CS/Engineering text is avaialble for free also.

All of the above have open source or free environments and if she learns the material, will have a very good chance of learning a trade and having it outsourced to India!

• math.hws.edu/javanotes/
• www.mindview.net/Books/TIJ/
• javaboutique.internet.com/tutorials/Thread0/
• www.labsoftware.com/Java/

(disclaimer: one of my livejournal interests is "informed dislike of c++". ;))

Bruce Eckel has written some fairly good (IMHO) books on c++ and Java. You can download them for free from here. The thing I like best about his approach is that it tries to teach you more than just the syntax, also (as the titles suggest) how to think in that language. The only con to his writting style is that his examples are sometimes a little contrived...

As other posters have said, do try to learn the STL as soon as possible. It makes C++ far less painful and more like Java. Of course, you could be stuck in a situation where your compiler is really old (bad templates support) and/or the environment doesn't have the STL, so as nice as std::vector is, you should probably learn how to use arrays too. ;) One of the biggest flaws in C++ to me is that it is almost like three languages in one, any one of which can be used to build a solution, but the best way isn't always obvious. [Well, and manual garbage collection sucks!]

Good luck!

Bruce Eckel's Thinking in C++ will help, also...

Quoth Hast:
the two "x" variables were in different scopes and thus completely independent

Hello Hast --

I'm actually reading Thinking in Java right now, and your talk of threads has me confused. I'm a complete Java noob, so that may well be the issue. However, once you declare a variable to be "final", isn't there only one by default? Please, clue me in if otherwise.

Cheers

See JWZ's rant about Java.

Now, here's what Python has that Java doesn't:

• Local functions,
• lambdas,
• "everything is an object",
• automatic invoking of getter-setter methods,
• static methods are really class methods (and not merely global functions),
• two (byte, or otherwise) arrays compare equal if they have equal contents (and therefore they also work fine in hashtables),
• separate types but common interface for ascii and unicode strings,
• multiple inheritance (programmers are not dumb),
• weakly typed (solves 4-5 of his problems),
• methods don't really "belong" to classes (in his terminology),
• printf-like formatting is supported :-)

Actually, J2SE 1.5 already fixes a lot of these things in Java.

About static typing: Bruce Eckel very recently wrote about what he thinks about Python's typing, what he refers to as "latent typing". See my related blog entry.

We've started believing that static typing has a low benefit/hassle ratio.

See also: The Great Computer Language Shootout. (Python comes out way too bad in performance.)

I thought about coming up with a syllabus for myself of C, Haskell, LISP and Perl (which just evades me....)

I'd like to strongly recommend some books. The first is Modern C++ Design by Andrei Alexandrescu. The second is On Lisp by Paul Graham. In conjunction with that, you will need an introductory text on Lisp if you don't already know it and a good book on C++ templates. While I don't know what the best Lisp text currently in print is, I'd be willing to give Graham's ANSI Common Lisp a try on the strength of his other book. And C++ Templates: A Complete Guide by Vandevoorde and Josuttis illuminates a lot of dark corners in templates and explains some new features.

In the end, the goal is to understand how many times Graham and Alexandrescu are talking about the same things using very different languages. C++ templates are in many important ways a compile-time, functional macro language on top of C++ that implement many of the features of Lisp macros. For what it's worth, Bruce Eckel has mentioned this generic programming link in the context of discussing Java generics.

The Que book is littered with omissions and errors. If you want to learn C++, start with the free Bruce Eckel e-book Thinking in C++, then move on to the Meyers trio, the Sutter pair, Gang of Four, Dewhurst, Alexandrescu, then Agile Software Development, in that order.

See Accu's booklist, EfNet #c++'s book list, or Yechiel Kimchi's list of bad books for opposing opinions.

I'm more than willing to pay for a book if I decide that I really like it.

Yep. I did the same thing with Bruce Eckel's Thinking in Java.

Downloaded it, read it, loved it, bought it to support the author.

First, you need to do what you like to do. I think a warning about the tough times in computing is fair. However, the employment situation is much better for harder skills (i.e. CS versus IT, research level CS versus UML/OOP/J2EE). I think there's still plenty of room for highly educated and motivated people.

Actually I saw a program at Dartmouth for a dual MD and PhD in CS (odd combination, but definitely useful). You may also be interested in the field of computational biophysics. It's all of the same ilk.

The article poster said he was interested in CS. Are you interested in research or business? There are a lot of different routes you could take. Do you want to deal with biomedical engineers, biochemists, or lawyers? Frankly, you were way too broad.

Incidentally, for what ever it's worth. You may get a kick out of http://www.santafe.edu/sfi/People/kauffman/">Stuar t Kauffman's work. He's regarded as one of the best in the field of complexity research. He also has an MD and no PhD. He taught himself quite a bit.

Some good Math and CS books:

"The (New) Turing Omnibus: 66 Excursions in Computer Science" by A. K. Dewdney
This book is a great advanced introduction to all of the major topics of CS (except neural networks). This book has sections on Godel's Incompleteness Theorem, Relational Algebra (database theory), viruses, operating systems, data structures, and more. This is a great book for you.

http://aduni.org/
This site has lectures from an entire CS curriculum online. It was an experimental program designed for people like you.

You'll need a good introductory book on programming. Since you're probably not worrying about polishing up your resume, and you seem to be more interested in learning, you should take a look at:
"The Little Schemer" or "The Little LISPer" by Daniel Friedman.

If you really want the traditional route, take a look at "Thinking in Java" by Bruce Eckel. It's free and most people recommend Java or C++ as a good first language.

If you're really daring, try the "Perl" book by Larry Wall or "Learning Perl" by Randall Schwartz. Although, I think Perl is a horrible first language to learn. It's way too exotic.

Take a look at "Advanced Programming in the UNIX Environment" by W. Richard Stevens. It's a great book on the internals in Unix.

Learn assembly language, it's a poor man's computer architecture course. Try to make a small graphics program (draw some primitives [lines and circles]) with assembly. Of course, you can't do that in Windows (unless you call some Win32 libraries or are VERY good.

"First Order Logic" by Raymond Smullyan
This book essentially covers the mathematics of automated theorem proving. Armed only with this, I was able to read papers in the field. Some knowledge of basic logic (prepositional logic, maybe some slight familiarity with predicate logic) is required. I'd also recommend a whole lot of "mathematical maturity". I recommend any of Raymond Smullyan's books (technical and popular science) sight unseen. Even his thesis (Theory of Formal Systems) was pretty good.

Any book by Howard Whitley Eves or Robert R. Stoll
Both men wrote books on matrix theory (linear algebra and more) and set theory. Actually, both are top-notch textbook writers and many of their books are available from Dover Publications.

Calculus Made Easy by Silvanus P. Thompson (or by FRS [Fellow of the Royal Society] if it's really old) and Calculus by Michael Spivak

The first book is the closest thing to a competent Calculus for dummies. It's almost 100 years old and it's a classic. Incidentally Mr. Thompson was an engineer, not a mathematician. The second book is notoriously rigourous and is almost an introduction to analysis. I don't know if you really care about Calculus. You probably won't

With A Fat Paycheck Comes Fat Responsibility

If you are interested in Programming then these are a great place to start:

How to Think Like a Computer Scientist: Learning with Python

How to Think Like a Computer Scientist: Java

PDF's plus Logo and C++ here: Open Book Project

More Java, C++

I agree with the above posts, if you want to code or you can project manage, get involved with an open source project and don't quit your day job until you have an established portfolio of projects.

Build a Linux box from scratch, and know it inside and out. Play games on it, run benchmarks with it using beta kernels. Backport something to Debian

All that said, I'm a techie whose thought about being a doctor or lawyer. Maybe we should swap stories and frustrations. The grass is always greener... HTH, Bod

Actually, if anyone is interested in learning Python and doesn't mind reading a book on their computer, there's a bunch of free ebooks available on the Python Documentation page (as well as a comprehensive list of books that are only printed). I've read a few of them, most of them are pretty good, in particular "How to think like a Computer Scientist" is a very good text for a less experienced programmer and Bruce Eckel's "Thinking in Python" is a nicely comprehensive coverage of Python (not unlike his "Thinking in Java" and "Thinking in C++" books).

Even if you do mind reading books on your computer screen, most of these books (actually I think all of them) are also available as physical printed books as well.

Thinking In Python by Bruce Eckel
An Introduction to Python by Guido van Rossum, and Fred L. Drake, Jr. (Editor)
How To Think Like a Computer Scientist: Learning with Python by Allen Downey, Jeff Elkner and Chris Meyers
Dive Into Python: Python for Experienced Programmers by Mark Pilgrim
Text Processing In Python by David Mertz
Python Language Reference Manual by Guido van Rossum

Also, I suppose a /. thread viewed at a threshold of 3 or 4 or higher would qualify as a collaborative commentary on whatever article is being discussed.

Of course, I realize that neither of these examples are exactly what 3D17 is suggesting, but they share elements.

Also, I suppose a /. thread viewed at a threshold of 3 or 4 or higher would qualify as a collaborative commentary on whatever article is being discussed.

Of course, I realize that neither of these examples are exactly what 3D17 is suggesting, but they share elements.

Also, I suppose a /. thread viewed at a threshold of 3 or 4 or higher would qualify as a collaborative commentary on whatever article is being discussed.

Of course, I realize that neither of these examples are exactly what 3D17 is suggesting, but they share elements.

Or what about Bruce Eckel's Thinking in Java? (Why didn't I mention it in my original post? ah well...) For those who don't know, this book is widely regarded as the best introduction to the java programming language. And Eckel offers the book as a complete, free download on his site. Why would he do this?

In fact, in his site FAQ, Eckel addresses this question: Why do you put your books on the Web? How can you make any money that way?

He writes: ...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.

Note that he mentions seminars - so this case represents an instance of an author that can have "concert tours" that make up for the lost revenue of a free online book.

Or what about Bruce Eckel's Thinking in Java? (Why didn't I mention it in my original post? ah well...) For those who don't know, this book is widely regarded as the best introduction to the java programming language. And Eckel offers the book as a complete, free download on his site. Why would he do this?

In fact, in his site FAQ, Eckel addresses this question: Why do you put your books on the Web? How can you make any money that way?

He writes: ...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.

Note that he mentions seminars - so this case represents an instance of an author that can have "concert tours" that make up for the lost revenue of a free online book.

First, you CANNOT remove strong typing from Java. It's an object oriented language. Tell me how you do one without the other.

See that's where I differ - I'd rather trade enforced checks for greater productivity - guess that depends on the environment you work in and whether you prefer to hand code or use an IDE.
But for checking, I prefer unit testing. Bruce Eckel makes an interesting argument that compiler checks are just a subset of Unit Testing, in Strong Typing vs Strong Testing.
There's a similar discussion going on at Artima right now with C#'s creator arguing checked exceptions are bad while Java's co-inventor says checked exceptions are good.
Sloppy coding is in the hands of the developer IMO, not the hands of the vendor.

Bruce Eckel sums it up best:
"Programmer cycles are expensive, CPU cycles are cheap, and I believe that we should no longer pay for the latter with the former. " from a post by Bruce Eckel on artima.com.

Perhaps people should stop obsessively benchmarking platform VMs, and start benchmarking coding productivity and teamwork, perhaps in Python, with the performance bits in C. For a real-world example, Zope does exactly that: 95% of the code in Zope ends up being done in Python - only the real performance-intensive stuff need be in C... and the stuff done in Python is easy to read, modify, reuse, and tweak (thus, better productivity for both developers that use Zope as and app-server platform well as developers who work on Zope's core).

I've worked in a variety of Java development projects in the past and not once has it ever risen to the task to show itself as a worthy choice and/or a mature language. Instead it has invariably wasted companies time and money.

I would be willing to bet the reason they failed is because you do not understand how to use Java correctly. As long as we're playing the personal experience game, it has been my experience that hardcore C/C++ programmers tend to make horrible Java programmers because they think Java should behave like C/C++. It doesn't (obviously), and when you try to shove that round peg into a square hole what you get is a huge mess.

At my company, we have a bunch of old school C/C++ progammers and a few Java programmers. As our Java products started to take off (now our #1 selling product line), we wanted to move some of those developers over to Java to help out.

It was a disaster. They made object pools in order to try to manage thier own memory. They were calling System.gc() and yield() instead of using a Java profiler to find bottlenecks. The never used lazy loading. They never used failfast ("exceptions are too slow!", they said). The result was all the projects they worked on were extremely brittle, used twice as much memory, and ran much slower than our original Java stuff because they were constantly fighting against the system instead of working with it.

Try reading Effective Java by Josh Bloch and Thinking in Java by Bruce Eckel. Do what these guys suggest and your Java apps will run just as well than as anything written in C or C++.

I find that having a paper copy and an ebook is great when learning a new programming languages. Traditionally, I like to read the book and refer to code directly out of the paper book. But ebooks are essential when you are trying to read code out of the book that takes up multiple pages, without having to flip back and forth all the time. Ebooks are also useful if you want to do a quick search for something it's quicker and more accurate (if the word/phrase you are looking up isn't in the inex) than looking it up in the index to use CTRL-F. The paper book and the ebook compliment each other quite well.

I think it's great when author's like Bruce Eckel who release paper versions and ebooks versions of their books and even updates to their ebooks.

• The programmer's stone, a *must* for anyone who is into programmation
• How to design programs
• Books by Bruce Eckel

Like other said before me, if the point is teaching Java, there's no better book than Bruce Eckle's "Thinking in Java", which is available electronically from Eckle's website. (The 3rd edition is new, I haven't read it specifically. My opinion is based on previous editions.)

I suggest, however, focusing on OOP, rather than on Java. A programmer who groks the fundametal concepts of OOP will have a relatively simple time adapting to the specific tidbits of Java. For this purpose, the best teaching language is Eiffel, and the best book is Object-Oriented Software Construction by Bertrand Meyer.

Check out Bruce Eckel's Thinking in Java. Not really a textbook in the classic sense, but sounds like what you need. Also available in an HTML version.

C# is one programming language I've stayed away from--and for no particular reason. I had picked up the C# specification [PDF] in 2000, but never really got down to the canonical "hello world" program. Today in 2003, as I look back, I guess I haven't missed much.

Let's go back to August 2000 and revisit Hejlsberg's famous O'Reilly interview by Josh Osborn.

Why are there no enums in Java, for example? I mean, what's the rationale for cutting those?

And Java has enums now, just like they come in C#.

one of our key design goals was to make the C# language component-oriented

I think this was really nice, and fitted in well with Microsoft's COM framework. I remember COM enthusiasts mentioning how every C# object would automatically be a COM object, thereby eliminating all that old school drudgery.

C# is the first language to incorporate XML comment tags that can be used by the compiler to generate readable documentation directly from source code.

Python and Java have docstrings (or javadoc) as part of the language.

Developers are building software components these days. They're not building monolithic applications or monolithic class libraries.

Developers are building all sorts of stuff, and not just "components". I think that statement is overrated.

Boxing allows the value of any value type to be converted to an object, while unboxing allows the value of an object to be converted to a simple value type.

Thanks, now Java has it too!

Unsafe code allows you to write inline C code with pointers, to do unsafe casts, and to pin down memory so it won't accidentally be garbage-collected. [...] The real difference is that it's still running within the managed space. The methods you write still have descriptive tables that tell you which objects are live, so you don't have to go across a marshalling boundary whenever you go into this code. Otherwise, when you go out to undescriptive, unmanaged code (like through the Java Native Interface, for example), you have to set a watermark or erect a barrier on the stack.

Honestly, I didn't understand the stuff about "unsafe code", the implementation of IL, and the implementation of generics. Just for comparison sake, Python also has a scheme for inlining C and C++ code.

Let's face it, some people like to program in COBOL, some people like to program in Basic, some like C++, and some will like C#, I hope. But we're not trying to tell you to forget everything you ever did.

I've raised this point to Java bigots on several occasions. It's just too difficult (and sometimes impossible) to interface Java with other languages. (In this context,

not all software can be free.

Why not?

Seriously. I don't see any reason that programming a computer to do any arbitrary task requires a corporation backing the development of the program.

And even if there is corporate backing, that doesn't eliminate the possibility that the software will be released as Free Software -- look at Apple, Red Hat, SuSE, Mandrake, et al.

As to who puts food on the table, that's for them to figure out. Apple et al pay their developers for their time; other developers make money selling books ( O'Reilly , Bruce Eckel ); others give lectures (Bruce Perens, Eric Raymond, Richard Stallman), and others make money at their day jobs which could be anything -- attorney, dentist, carpenter, factory worker, you name it.

Please back up your assertion, as I don't see any reason that "not all software can be free."

Bruce Eckel, Thinking in Java's author has an inclomplete and unfinished, but interesting book. http://mindview.net/Books/TIPython

For example, Bruce Eckel makes his Thinking in Java book available for download online for free. He also sells it, apparently he's earning enough to justify not removing the download. More of his take on download availability is here

For example, Bruce Eckel makes his Thinking in Java book available for download online for free. He also sells it, apparently he's earning enough to justify not removing the download. More of his take on download availability is here

If you're a C or C++ developer, you probably won't need either of these books - Eckel's Thinking In Java will probably do you just fine, and you can download it for free.

Strong typing: I'm tired of seeing casting errors at runtime.

If your goal is to be pragmatic, then strong typing is not something you want. There is getting to be more evidence that strong typing is a red herring. The people who insist on it get all hot and bothered by languages that don't have strong typing, but it sure isn't keeping other people from being super productive in Python (for example).

Here's a good read.

Generic design patterns that you could "plug" into via some sort of object and run from there.

For what it's worth, either you can trivially do that now (like Singleton), or it's effectively impossible (like MVC). IIRC, "the" Patterns book explicitly disclaims the possibility of this, because they're just too high-level.

As a concrete for-instance, Python has first class support for "Iterators". But they are very specific iterators, and there's a discussion going on right now in the newsgroup about a slightly different sort of iterator, one that you could tell was empty. The type of "iterator" Python natively supports can't do that (it's a minimal commitment iterator, meant to be used in situations where you may not know whether the iterator is empty until you try it, and I've used this property before), yet that doesn't make it the One True Iterator; there's a place for iterators that know they are empty, or can be rewound, etc.

If that's the kind of support you want, you can have it, but that's not really full Pattern support, more like Pattern-inspired features.

I'll refrain from most of my other criticisms since they are matters of taste... oh hell, Bruce-Eckel-on-checked-exceptions-I'd-kill-myself- if-I-had-to-use-them. *gasp* sorry, had to toss that one in. ;-)

Here here to the Bruce Eckels sugesstion. He is far and away one of the best authors on the topic of OOP. Further, he does a lot of training, etc... and has made most/all of his books freely downloadable.

Here here to the Bruce Eckels sugesstion. He is far and away one of the best authors on the topic of OOP. Further, he does a lot of training, etc... and has made most/all of his books freely downloadable.

Neither of the books mentioned are as good a learning book as Thinking in Java by Bruce Eckle. Which has the benifit of being free as in beer: http://www.mindview.net/Books/TIJ/.

if you want to learn a particular Java aspect look at Sun Java Tutorials. (they are excellent a free).
If you want to leatn OO programming and Java I would suggest Think In Java (it's the best and it's free).

mindview.net/Books

You'll be glad you did!

The parent post was copied directly from this link (originally linked in the article summary as Bruce Eckel's viewpoint.) Please do not mod the parent post up, as it is not an original post and does not identify the original source.

Maybe not quite as many modules as Perl, but the standard Python library provides interfaces for a lot of different tasks. It's not skimpy, in case any of you potential Python users was worried.

There's good reason the motto is "Batteries Included".

I've found Python useful for all kinds of tasks and love the clean, short syntax devoid of punctuation characters.

If you need more of a recognized authority to recommend how great and wonderful is Python, then listen to Bruce Eckel or Eric Raymond.

Have a look at Bruce Eckel's weblog on the subject which points to Bob Martin's thoughts. (Artima seems to be down at the moment, unfortunately.)

I don't want to have the compiler (or run-time environment, or interpreter, whatever) to "guess" at what I mean -- I want to tell it exactly what I mean.

Perhaps this is why huge applications are usually written in languages requiring typecasting, and the "looser" languages are usually relegated to simple task duty.

Dynamically yet strongly typed languages such as Python and Lisp allow you to tell the compiler or interpreter "exactly what you mean" with regard to types, they just don't require you to do so. Where's the beef?

Bruce Eckel, a C++ and Java expert and the author of the "Thinking In ..." series of books, wrote recently:

After I had worked with Python for awhile -- a language which can build large, complex systems -- I began noticing that despite an apparent carelessness about type checking, Python programs seemed to work quite well without much effort, and without the kinds of problems you would expect from a language that doesn't have the strong, static type checking that we've all come to "know" is the only correct way of solving the programming problem.

This became a puzzle to me: if strong static type checking is so important, why are people able to build big, complex Python programs (with much shorter time and effort than the strong static counterparts) without the disaster that I was so sure would ensue?

This shook my unquestioning acceptance of strong type checking...

The exceptions and formality of Java are supposed to aid development by making sure you've crossed all your t's and dotted your i's when it comes to error handling and type checking. (emphasis mine)

You carefully qualified your statement so I won't lay into you ;-) That is indeed the "strong, static type checking" party line.

An increasing number of smart people are starting to ask questions about that party line though. They'll try out a dynamic language like Python, and the disaster promised by the static typing advocates conspicuously fails to materialize. For two examples of this, see Are Dynamic Languages Going to Replace Static Languages? and Strong Typing vs. Strong Testing. A lot of other people are leaning this way too in newsgroups and on personal weblogs, and of course a lot of people still believe the party line.

Personally, I'm suspicious of "received wisdom" that's much older then 10 or 20 years, as the static typing claims are; the world has changed a lot since then in a lot of ways, not least of which is our improved understanding of how to build things (i.e., even in non-technological ways).

Hmmm...
I wouldnt mind contributing but what do I get for it? Looks lkike I still will have to buy the books to get any info.
I rather like the Bruce Eckel model, he publishes the book online, anybody can contribute online(though your contributions might not make it to the paper version), and you only have to pay if you want a paper copy of the book. Almost like GPL.The end result does look good.
Or maybe the Wikipedia model More like BSD license.

Well, other authors have put books online for free, such as Bruce Eckel, who as many know is the author of the immensely popular "Thinking in [Java|C++|...]" series. He always releases electronic, free copies that are fully hyperlinked, come with all the code, etc., at the same time as the bound copy. He says that the electronic books are an enhancement to the book, not necessarily a replacement for it, and that ultimately electronic books are targeted at a slightly different audience. In any event, he also says that he still gets brisk sales of the "real" books even with the very open availability of the electronic ones. Personally, I like having a copy on my laptop for quick reference that is not watered-down, but I much prefer the true codex format for general reading, portability, sharing, etc.