Via Hans, this Survey of Object Oriented Programming Languages looks pretty interesting. It's important for people to realize that there are a lot of different options for what makes something object-oriented. The biggest distinction I'm aware of is that between prototype-based systems and class-based systems. This paper looks like it covers that and more.
Woo, competitive dog dancing! When my friend Justin sent me this video, I expected something bad to happen, like the dog biting its owner during the routine... But no, this video is just a whole bunch of awesome dog dancing
The ever-excellent Cox & Forkum: Root Causes. There's a lot of great stuff in this post. Just check it out.
I'll quote this bit:
In Dean's announcement for candidacy he alluded to how he thinks America's military might should be used:
"The idea of America using its power solely for its own ends is not consistent with the idealistic moral force the world has known for over two centuries."
In other words, he considers it more "moral" and "idealistic" to use our military self-sacrificially and not to secure our national self-interests. To him it is better when our soldiers risk death for the sake of other countries than for the sake of America. I can think of few foreign policies more morally atrocious than that.
Dean's quote seems to be straight out of Conflict of Visions as an example of an unconstrained approach to politics.
Debuggers: a modern 'Dr. Jekyll and Mr. Hyde'. I found this article more interesting than I expected to.
Beside that for certain problems a debugger is a great tool it prevents many developers from focusing on the real problem that their code is plain buggy and that they have no clue where to look for. Stepping through a program only works well when the developer can remember where he came from and where he is heading to. But most of the time people lose that and when they found the problem they do not know how they got there in the first place and so the have to step through multiple times until they understand what caused the problem and how to fix it. A much better way is to look at your code, log output and, if you have, your test cases to localize your problem area and then focus on this area. For me this does mostly lead to a solution and I do not need a debugger anymore. With an AOP framework and a decompiler I can also debug third party library without a debugger.
I've advocated logging before. In particular, now I want to check out log4j and understand how that works.
An interesting summary of why a particular development team chose Python (and stuck with it). Via Erik, via Chris.
One of the most common recurring problems in software design is how to manage data flow in your code. Unless you use global variables for everything, you have to worry about this problem. Of course, if you do use global variables for everything, you have other problems.
Anyway, consider:
frob(arg1, arg2, arg3)...
Eventually, the number of parameters to a function may get unwieldy, and importantly, you may need to pass a number of those parameters to different subroutines called from frob. That gets hard to maintain, it's ugly, you forget which order the parameters go in, and it's generally a pain. People have probably given guidelines about how many parameters to a function is too many, but you don't need a rule like "7 is too many" to know when you have a problem.
So, the next step is to make arg1, etc. into fields of a record, and then pass the record around to different subs. But then you have a whole set of different problems. It can introduce another compile-time dependency (at least, in languages like C (Pascal too?): see John Lakos.), and you then you wind up writing extra code to initialize and return a record. Sometimes a function doesn't need everything in the record but you still wind up passing the whole thing in, and I could swear there's some "software rule" that explains how this increases the coupling between different pieces of code (can anyone remind me what it is?).
This is one of the things OO is meant to solve. Group pieces of code that need the same data together, figure out what abstraction that represents in your program, and then each method that accesses the data doesn't have to get it from anywhere else but its own object instance. Not that this solves all of your problems, of course, but it helps.
In languages that support further levels of program organization, there are other places to stick things. For instance, consider languages that have modules in addition to classes. There are yet more ways to abstract around data... closures, currying, continuations. What else?
And of course, you often have to figure out where to put your data. Where is the data created and initialized? Who "owns" it (who's responsible for freeing its memory, etc.)?
The problem of what you do with return values is yet another common issue.
This post feels incomplete and without purpose, but this bit from Adam (bottom part of the day) spurred me to write down some thoughts.
Just came across a neat for loop idiom I don't think I'd ever considered before:
for(long i = 0, m = file.length(); i < m; i++)
As a general rule, it's bad (with varying degrees of badness) to call a function in a loop condition. One of my favorite examples of why is exemplified by this bit of C:
for(n=0; n<strlen(str); n++)
print str[n];
It turns what should be a Theta(n) algorithm into a Theta(n^2) algorithm.
Usually what I'd do in that case is something like (back to Java):
int length = file.length(); // or str.length, etc.
for(int n=0; n<length; n++){...}
But the idiom above allows you to put it in the loop declaration, which allows you to better associate it with the loop conceptually, and has the added benefit of making the variable scoped to the loop.
Adam has a really interesting observation on data binding in .NET. Adam, thank you in advance, because you most probably just saved me lots of time at some unknown point in the future. Not only time, in fact, but I'm also saved from having to go through the conceptual discovery he spent the time going through.
I hope he doesn't mind, but I'll quote the whole thing here because the observation is short and not easily excerptable:
Using an object as the DataSoucre for two different ComboBoxes in a Windows Form means that the selection of those two boxes is synchronized. You change one, the other changes too, which is not what I expected. I just wanted to use the same IList in two drop-downs. It appears that in order to do that I need to copy the list into an array, then use .AddRange() on each box.
Why why why?
Because data-binding is conceptually about controls viewing the same record in a database, not conceptually about being MVC.
"I think we deserve a $rubyometer-- for bypassing mixins." - Larry Wall
Piers has some things to say about this message and how Larry is handling Perl 6 design in general.
I remain very optimistic about Parrot and Perl 6.
Saturday, December 6, 2003
Permalink
new⇒Java join function
Meh, don't have null strings inyour string arrays imo, but you'rewelcome ...
Keith: Nov 19, 7:51pm