Fog Creek Software
Discussion Board




Eckel is thinking in C# now ..

Honestly, I didn't read Eckel's "Thinking in Java" by now (fortunately, he's not the only Java author so far). But I heard that both of his "T in C++" and "T in Java" were good. May be.But now I see this guy already ported himslef to Python and C#: http://www.mindview.net/Books! That just seems plain wrong to me - how can one manage 4 languages in the expert level ? I mean, he's probably smart and experienced and can use 4 different languages at his work (most if us do it, not a big problem), but hey .. You're *teaching* those languages, so you consider yourself to be an *expert*. I don't know how is it about him, but I think I should work at least 5 years with one language before I can think of myself as a real expert (and not so-called one). So, my point is - he's is bluffing. He isn't expert, he's a books writer .. Right, I didn't see his books but it's hard to believe otherwise.

Evgeny Goldin
Sunday, May 12, 2002

According to one of Bruce Eckel's newsletters (http://www.mindview.net/Etc/Newsletter/Newsletter36.txt), Larry O'Brien is spearheading the effort, and the publisher wanted Bruce's name on the cover.

Alan Hecht
Sunday, May 12, 2002

Anyway, he switches languages too frequently. Does he have any time left for *real* work ?

Evgeny Goldin
Sunday, May 12, 2002

He spent 2 years in making T in Java. I guess that he is a C++ expert (see his former books) and as such going into Java is no real difficulty. I have his books and they were very useful (I have a C++ background) for me to transition to Java. The samples go in all directions but they show working things. Unlike books that focus on popping windows around and try to make the experience being 'funny' (like the Deitel books which are cool for hacking around in the evening but not for complete coverage of topics), this one goes into interesting discussions of why things work the way they do. Also, a PDF version is available for free, something that is good. So, whatever can be said about Bruce Eckel, he gives quite a lot to the community. Of course, several topics are lightly done but who would expect complete coverage of EJB in such a book ? BTW, he said that he didn't wanted to write one more Thinking in <language> book. So, his name on the cover would make the book sell better because of his credentials (the same as Ed Yourdon did in the past for some analysis books).

Philippe Back
Sunday, May 12, 2002

<< his name on the cover would make the book sell better >>

This *is* really new for me ... I had no idea people put names that don't actually belong there to the cover. Well, you right, it may explain some things.

Moving from C++ to Java is just fine, but what I disliked is rapidly moving somewhere else.

Evgeny Goldin
Sunday, May 12, 2002

Ok, here's my real questions - how do you treat folks making their living mostly by teaching and writing books than developing a working code ?
I guess it's Ok for someone who already spent 15 years in development, but still .. I just don't feel comfortable being taught by someone who doesn't produce anything by himself, except seminar CDs. Where am I wrong ?

Evgeny Goldin
Sunday, May 12, 2002

Having worked through O'Reilly's second edition of Programming in C#, I have to say that an expert in Java and C++ would have no problem quickly getting to the forefront of the field in C#, at least enough to write a competent book on it.

Justin Johnson
Sunday, May 12, 2002

<< This *is* really new for me ... I had no idea people put names that don't actually belong there to the cover. Well, you right, it may explain some things. >>

It's VERY common for second editions: the original author may have moved on to other matters, so a co-author comes in to do the rewrite. The original author's contract may require that he or she continue to receive primary author credit; or if the first edition was well received (likely, since they're bothering with a second) and the original author has a recognized name, it's just good marketing to keep the "brand name".

It's less common but not unheard of in a situation like this, where one author establishes a series and then others add to it. Sometimes the original author would get a "Series Editor" credit, or something like that.


<< Ok, here's my real questions - how do you treat folks making their living mostly by teaching and writing books than developing a working code ? >>

As a 17-year developer who now spends more hours training and writing courses than writing code, I fear it tremendously. I get some pretty decent student evals; and one consistent factor is that I'm a developer talking to developers, and their past experience is with trainers who don't know development. They appreciate the difference. So I fear losing touch with developers, and thus losing relevance. I make an effort to find development opportunities just so I won't lose my edge. I would be very leery of anyone who trains but doesn't develop. (Having heard Eckel speak, I'm pretty confident that doesn't include him.)


<< Having worked through O'Reilly's second edition of Programming in C#, I have to say that an expert in Java and C++ would have no problem quickly getting to the forefront of the field in C#, at least enough to write a competent book on it. >>

Exactly. Comprehension often comes in threes. The first time, you learning what's new. The second time, you learn what's different from what you learned the first time. The third time, you learn what's the same from the first and the second. After that, learning similar things gets really easy.

So the first C-like OO language you learn teaches you OO with semi-colons. The second teaches you that things don't have to be the way you learned them. And the third teaches you the real commonalities among them. If Eckel wanted (at SD last month, he still seemed pretty thrilled with Java), I have no doubt he would be a capable C# developer in a couple of months.

Martin L. Shoemaker
Sunday, May 12, 2002

You don't have to be an expert, or use it daily to write a book on it.  One can make the argument that he can write a BETTER book becuase he doesnt work.  He has the LUXURY of researching every arcane feature of a language BECAUSE he doesnt have a dayjob. 

Also, OO is OO.  He's probably just rehashing the books in a new language/syntax.  I bet most of the book is copied from the other T in XXX books. 

Bella
Sunday, May 12, 2002

Martin Fowler has been playing with C# and so has Jason Hunter (authour of O'Reilly Java Servlets book).

Java and C# have a great deal in common so Eckel is well qualified to write such a title at this point in the language's history. He's also working on "Thinking In Patterns".

Fowler has some interesting things to say about .NET in his ISA draft (specifically when mentioning approachings to organising domain logic - http://martinfowler.com/isa/domainLogic.html ). My interpretation is that .NET lends itself to faster development, but less flexible solutions. If Sun can push JDO ( http://java.sun.com/products/jdbc/related.html ) this might provide a very interesting and clear distinction between .NET and J2EE.

Walter Rumsby
Sunday, May 12, 2002

I met a couple of authors who write for Wrox last year and it struck me that they had no real world development experience. Their activity was basically rewriting MSDN content in a more digestable form. It seems to me that the majority of the IT books are very poor with too much focus on delivery dates rather than real quality material.

You have to be very discerning about what you buy, I always read at least a quarter of the book in the bookshop before I decide it is good value and never buy any books with a product name in the title anymore.

I am currently studying a Maths course with the Open University and have been amazed by how good the matrial is compared with what we get in IT, it could be a lot better.

Tony E
Monday, May 13, 2002

-------------------------------------------------------------
Basically, Larry decided he would like to
translate "Thinking in Java" into C#
------------------------------------------------------ Eckel

Since Java and C# are so similar a direct translation of Thinking in Java seems straight forware.

Convert the Java listings to C#, and update the surrounding text accordingly.

Ged Byrne
Monday, May 13, 2002

From this interview with Bruce:

http://www.mindview.net/Etc/About/InformITRaw_html

"But then I moved to Python, and began to realize that both C++ and Java, being languages with strong static type checking, had again constrained my worldview so that my thinking was limited. For example, I would occasionally get questions from people, usually former Smalltalk programmers, who asked why I put so much emphasis on the concept of upcasting. To me, you couldn't really think about inheritance and polymorphism without understanding upcasting, so I patiently explained it to them. But then I started working with Python and being about 10 times more productive than I've been with C++ and Java. Python challenged many of my "known facts" about object-oriented programming, and even programming in general. A big one is that strong static type checking is necessary for robust code."

Dan Sickles
Monday, May 13, 2002

And one more from Bruce:

Question: How would you compare Java and C++? Would you recommend a beginning programmer to start with one or the other?

Answer: Perhaps I'm going to end up belaboring Python here, but my direction lately has been to direct people towards Python, which I think is a superior first language – it doesn't have all the weird nonsensical baggage that C++ and even Java have accumulated. And I'll bet that for most people Python will probably satisfy their needs and they may not need to learn Java or C++. But if they do, they'll be well-prepared because it has a much stronger object-oriented model, without arbitrarily restricting you to the limited concept of "object" that both C++ and Java have.

Dan Sickles
Monday, May 13, 2002

Does static typing bother him ?
I can't imagine building any serious system with dynamic one (Perl, for example, where you can switch {} to [] and the only thing that'll happen is a run-time crash .. someday). I agree that it's really attractive to program without static typing but than a maintenance is a nightmare.

Evgeny Goldin
Monday, May 13, 2002

> Perl, for example, where you can switch {} to [] and the
> only thing that'll happen is a run-time crash .. someday

Well, maybe. What happens to smart programmers is that their unit tests catch the error a few seconds or minutes later.

Anybody interested in starting a thread about this, or has it been hashed out enough times elsewhere? :) I think it's an interesting topic.

Adam Spitz
Monday, May 13, 2002

The basic argument against static typing is this:

1) Statically typed languages use static typing to catch errors.

2) In order to work with these type systems, you need to spend a good deal of time up front during development writing your code so the compiler understands the right types of everything.

3) You also need to warp your design so that it fits within the limitations imposed by the static type system.

The whole point of going through the pain of 2) and 3) is to catch errors. But in practice, you still have to test anyway, and test a lot, to get all the errors that static typing doesn't help with.

So, if you still have to do testing anyway, why not use a dynamically typed language where development is faster, and just put type testing in where you really need it, in the test harness? The time lost dealing with type errors (which is often not much in my experience) is more than offset by the increased development speed that results.

Chris Tavares
Monday, May 13, 2002

I think static typing vs dynamic typing is a good topic to discuss about. Let somebody start a new thread - I'm too sleepy to copy/paste previous posts to it ..

<< What happens to smart programmers is that their unit tests catch the error a few seconds or minutes later >>

Like everebody has a unit test ! No, no and no  and we no (oh, "know") it. Why would I hope that some unit test will *probably* catch a programming error ? If we'll trust unit test - what for do we need compilation checks then ? Let unit test crash the executable.

<< The whole point of going through the pain of 2) and 3) is to catch errors >>

For me there were never points 2) and 3). IMHO, dynamic typing has it's advantages but I never saw any disdvantages in the static one.

<<  But in practice, you still have to test anyway, and test a lot, to get all the errors that static typing doesn't help with >>

Compilation can't catch all errors, what it does is catching the most obvious and most frequent ones (typos and the like) - that's the point !
Tests should catch more obscure logic errors where compiler can't help. But where it does help - there's no reason to ignore it just because it's still not 100%.  Let it be X% - I feel great already.
Besides, as I said, I see no disadvantages in static typing (I *worked* with Perl and I know how flexible it is to have a scalar which may be anything you'd like) and I felt never urge to wrap my design to fit into the typing system of some language Y. Those regular types we have from C are flexible enough to not become a barrier.

Evgeny Goldin
Monday, May 13, 2002

As an example of warping a design:

I'm looking at code for a C/C++ language parser right now. The fundamental data structure is a symbol table.

The problem is that the entry in the symbol table is radically different for a class method and an enum constant. However, due to the static typing, everything has to be stuffed in a "Symbol *" pointer, and then when you actually use it, you need to typecast back to the "real" type.

Since you need to do runtime type testing ANYWAY, what's the point of having the static type system at all? All it did was cost you more work in order to get around it.

Chris Tavares
Monday, May 13, 2002

"Compilation can't catch all errors, what it does is catching the most obvious and most frequent ones (typos and the like) - that's the point !"

If you don't write tests, and you don't have bugs, keep doing what you're doing. If you don't write tests, and you find that some bugs still slip through the static type checker, try writing tests. And when you're good enough at testing to be confident that very few bugs are slipping through, try out a language without a static type checker.

When I performed this experiment several years ago, it was humbling. And it was fun to try. :) I heartily recommend it.

Adam Spitz
Tuesday, May 14, 2002

<>
As an example of warping a design:

I'm looking at code for a C/C++ language parser right now. The fundamental data structure is a symbol table.

The problem is that the entry in the symbol table is radically different for a class method and an enum constant. However, due to the static typing, everything has to be stuffed in a "Symbol *" pointer, and then when you actually use it, you need to typecast back to the "real" type.

Since you need to do runtime type testing ANYWAY, what's the point of having the static type system at all? All it did was cost you more work in order to get around it.
</>

Hmm.  Not knowing the setup of your code:

1.  Make an interface Called symbol.  Both Enum and Class entries implement symbol . (Pure Virtual class)
2.  As many of the methods as you can, move to symbol.

I'd be interested in seeing your current object model.


In general I do not like dynamic type checking.  Aside from the inherant latency, I just am too poor a typist to correctly get variable names consitantly correct.  I like it when the compiler checks things for me.  It especially helps refactoring:  I use it as my first test (*Well at least it compiles!)

Adam
Tuesday, May 14, 2002

Joel,
you are probably right that Bruce Eckel is not a guru with five years experience in all these languages. IMHO that doesn't mean that he is bluffing. I think that Bruce's strong general ability to teach (plus his books being a fun read, maybe not as funny as yours but still...) more than offsets this disadvantage. It is my experience, not least from University, that guruhood is less important than ability to teach. By ability to teach I mean for example ability to make the material comprehensible, accessible, concrete and attractive to beginners.

Peter Marklund
Wednesday, May 15, 2002

My impression of Eckel's books has always been that they are grounding books for introducing the language; not books about software development or engineering as such. In fact, I think they make that point.

In that role, Eckel's books seem to me to be among the clearest and best around. I would recommend his books to anyone picking up a new language.

To explain the language, Eckel doesn't really need years of experience in that particular language, as long as he has years of development experience, which I think he does. His teaching ability is the important thing, and it's excellent.

Hugh Wells
Sunday, May 19, 2002

Peter Marklund, it was my post, not Joel's ;)
I tend to agree with your opinion though ..

Evgeny Goldin
Sunday, May 19, 2002

Ok, ok, I'm convinced now. Thank you, guys !

Evgeny Goldin
Sunday, May 19, 2002

I do use C++ for the development. Still, I have to admit that I have learned a lot from Eckel's "Thinking in C++". Better to say, I would like to be as good in C++ as he is. When reading his explanations, it is clear that he deeply understands what he is writing about.
From another point of view, the language syntax is only one part of what one have to know when programming. You have to know also how the things should be done -- independently on the language syntax. Eckel apparently knows a lot about OOP and about patterns (design patterns). In my opinion, he knows how the things should be done. He is also able to explain why. In my opinion, this is often more than one can gain by only "being a developer for many years".
C++, Java, and C# all belong to the same family. While C++ is a hybrid language (not purely OO), the C# is a clean OO language. Python is also closer to pure OO language than C++ and I feel that Python and C# may share something common in that sense.
For me, I learn much more from books like the Eckel's ones than from "official" books that say what button should be pressed to create a dialog. The semantics behind the programming is much more important than the syntax.
I plan to buy the "Thinking in C#" if you wanted to hear that ;-)

Petr Prikryl
Monday, March 17, 2003

*  Recent Topics

*  Fog Creek Home