Slashdot Mirror

There are massive tomes for C, but they are just book shovelware.

Try "Compiler Design in C". - 924 pages, hardcover, high-quality paper that you just don't see any more, and definitely NOT shovelware.

And no, it's not just useful for writing C compilers.

Is that you, BadAnalogyGuy? Compiler design is not related to learning a language in any way. If you want to learn a language, you do not need to read a book on compiler design. If I wanted to learn Python I wouldn't read "How to write a compiler in Python".

I think I know what I'm talking about here. As a teen I read the famous dragon book on compiler design and wrote a C compiler (in C, perversely enough!) as a personal project. I used K&R as the language spec.

There are massive tomes for C, but they are just book shovelware.

Try "Compiler Design in C". - 924 pages, hardcover, high-quality paper that you just don't see any more, and definitely NOT shovelware.

And no, it's not just useful for writing C compilers.

Not the same as saying that he didn't want java to be OO.

Oh, no, that's not the point at all. The point is this:

OO != Classes

And in fact that Classes may not be the ideal way to orient a program around objects. And the bonus point is that the person who implemented what's the arguable current king of OO languages understands this. He's not the only one. The Drupal Devs also have a thing or two to say on the subject.

I'm very familiar with the Allen Holub article you referenced -- stumbled across it three or four years ago, and it eventually led me to buy Holub's book on patterns. The takeaway point about the hazards of implementation inheritance is one that I think he overstates, but it's absolutely necessary given the way most people learn OO programing these days. Most books and tutorials hammer on extends and necessarily use examples of class hierarchies because it's necessary to teach what all the OO syntax does, but this really isn't what OO programming is about.

The interesting thing is that Javascript is one of the few popular languages where this is quite clear. There are weak clases, there is no "extends", and therefore very little magic implementation inheritance. You can code up syntax for this, if you like, as many of the major libraries do, which I think illustrates the power of the model and the language, but by and large, the prototype inheritance method means that you're doing interface inheritance or very explicit implementation sharing. This means the pitfalls Holub points out are easier to avoid, and there's many other bonuses. It also unfortunately means a bit extra work in some cases where implementation inheritance is handy and less dangerous, but it's not all that much, and I think the tradeoff is worth it.

Now, the next version of Javascript will particularly be nice for developers of libraries who have reasons not to trust the developers using what they're producing, because they'll be able to freeze things they can't freeze now with the static typing and class definitions.

But I'm pretty afraid a prevalent culture that seems to have a fairly narrowly scoped idea of object orientation and "best practices" is going to clap their hands and grab onto the familiar classes as they approach Javascript, rather than really understand the breadth of the language, and in 3-4 years, you'll have newly-minted team leads fresh from their recent readings of Fowler and GoF talking about tortured design patterns using static types and classes when a little sprinkling of dynamic language will do the job.

Please, allay my fears by not saying "JS2 finally bring real OO programming to Javascript."

No, please replace UML in everyones minds with User Mode Linux so never again will the horror that is Unified Modeling Language be forced upon us.

I actually like Unified Modeling Language when used appropriately.

If you hate UML, you've probably only seen class diagrams. I hate them, too. I find that they tend to get out of sync with reality and aren't that easy to read anyway (why put the complete list of methods in with the inheritance structure? too much information!). Tools that generate code from them only make the synchronization worse - better to generate diagrams from code, since the code is what definitely changes as needed. I much prefer doxygen output - it's always in sync and has easy-to-read inheritance diagrams with textual lists of methods and full documentation right there which is kept with the source code.

But class diagrams aren't all there is. Take a look at the other UML diagram types on this reference card. In particular, I find UML sequence diagrams are the best way to describe race conditions. State diagrams, activity diagrams, and use case diagrams have their place, too.

I'm sure a book called C Puzzlers would sell at least twice as well as this.

Would you settle for slightly different titles like these?
C Traps and Pitfalls
Enough Rope to Shoot Yourself in the Foot

Fortunately, there's also:
The C Answer Book
Which obviously has all the answers. :-)

Actually, none of these is settling at all -- all three are excellent books, at least IMO. Much of Holub's book also applies about as well to Java as to C or C++, for that matter.

--
The universe is a figment of its own imagination.

The official site is located here.

users can ask their computers to retrieve all pictures that include a specific person's face

I wonder if they'll link to any of this pictures, when searching for this specific person's face:

http://www.areyadone.com/images/hated/bill-gates.j pg
http://users.cybercity.dk/~cfs4636/PIC/Bill%20Gate s%20-%20007.jpg
http://www.holub.com/goodies/images/Billborg.jpg
http://home.midsouth.rr.com/catcam/bill-gates-borg .gif
http://www.kewlcard.de/bilder/postcard/5/bill%20ga tes.jpg
http://www.rockhardplace.com/horror/images/ironmai den/eddie-bill%20gates.jpg
http://superwebon.iespana.es/superwebon/Archivos/B romas/Fotos/Humor%202/Bill%20Gates%20Feto.jpg
http://www.paulsjusticepage.com/images/cyborg.jpg
http://www.telegraph.co.uk/money/graphics/2002/09/ 24/cnforb24.jpg
http://ta.twi.tudelft.nl/DV/Staff/Lemmens/gates.jp g
http://images.ecampus.com/images/d/258/0312192258. gif

Well...the Dragon book for starters, as mentioned earlier. That's probably the ur-source for most of the theory behind the magic. Makes my head hurt, though.

Terence Parr's book, Practical Computer Language Recognition and Translation (out of print). His doctoral dissertation is a useful thing too (try the Purdue University library).

comp.compilers is another useful resource. It's archived at http://compilers.iecc.com.

Alan Holub's Compiler Design in C is a classic.

The ACM's SIGPLAN ("Special Interest Group On Programming Languages") and it's journal SIGPLAN Notices of the ACM are all fine resources. So is ACM Transactions on Programming Languages and Systems.

Don't forget the IEEE as well.

Not to mention Abelman and Sussman: Structure and Interpretation of Computer Programs.

The garbage collection page is a good source for information on memory management and garbage collection.

Your university's library is another good resource.

Well. That should keep you out of trouble.

The job of Marketing is to determine the minimum feature set required for a product to succeed in the marketplace at a given price.

The job of Sales is to sell the stuff that marketing has specified and Development has built. Sales should not be asking Development for features when some customer wants them--they need to talk to Marketing first.

Its too bad that writing threaded code is still considered to be an "advanced coding skill".

Java unfortunately makes threading so easy, it's one of it's shortcommings. Anyone can write code to take advantage of multiple threads, but without knowing exactly what's happening under the hood, unnecesssary things happen to degrade the performance on the Java VM. I know my first few multi-threaded programs in Java didnt turn out as I had hoped - performance was significantly worse than a comparable single-threaded version.

I feel that being able to multithread code effectively in Java would make a programmer advanced in that topic.

It's not only a vendor problem (unless you're using green threads).

On most systems the JVM uses native threads for performance and scalability reasons. Now let's take a look at the Java API. In java.lang.Thread there exists 10 levels of priorities for Java threads. Now let's see how this maps to a native thread system of say...oh so dear Windows NT.

On NT you don't have process priorities in the same sense that most Unixes have. Instead, what you have is thread groups (Low, Medium, High, Realtime) and each of these has 7 levels. So let's say our JVM runs on the High priority group. There's only 7 levels there, yet we have 10 in Java threads. There must be some overlapping going on here! So you cannot guarantee that your Java thread with priority of 7 is lower than your Java thread with priority of 8. Maybe they map to the same level 5 on the native threads!

Then take a look at the thread model Solaris uses... and Linux which clones light processes... it gets very messy real quick.

So its not just a vendor problems. Java leaves alot to desire when specifying threads, and mostly the reason is that abstracting all the thread models of the world is a pretty difficult thing to do.

Allen Holub has a great series of articles on Java threads. He goes into some length in explaining both the threading models of both NT and Solaris. He also nick names the NT thread system as an 'unholy mess' which is quite amusing :)

It's not only a vendor problem (unless you're using green threads).

On most systems the JVM uses native threads for performance and scalability reasons. Now let's take a look at the Java API. In java.lang.Thread there exists 10 levels of priorities for Java threads. Now let's see how this maps to a native thread system of say...oh so dear Windows NT.

On NT you don't have process priorities in the same sense that most Unixes have. Instead, what you have is thread groups (Low, Medium, High, Realtime) and each of these has 7 levels. So let's say our JVM runs on the High priority group. There's only 7 levels there, yet we have 10 in Java threads. There must be some overlapping going on here! So you cannot guarantee that your Java thread with priority of 7 is lower than your Java thread with priority of 8. Maybe they map to the same level 5 on the native threads!

Then take a look at the thread model Solaris uses... and Linux which clones light processes... it gets very messy real quick.

So its not just a vendor problems. Java leaves alot to desire when specifying threads, and mostly the reason is that abstracting all the thread models of the world is a pretty difficult thing to do.

Allen Holub has a great series of articles on Java threads. He goes into some length in explaining both the threading models of both NT and Solaris. He also nick names the NT thread system as an 'unholy mess' which is quite amusing :)