The developerWorks team recently unveiled their new site using WebSphere Portal server, which you can read about here. As part of the new site, they’re now offering RSS feeds for all the articles here:
http://www-106.ibm.com/developerworks/rss/
Generally very high quality stuff. Subscribe now!
Bryan Hogan posted a thought provoking blurb a couple weeks ago where he postulated that passing a data structure as the parameter to a method is better than passing numerous parameters. Specifically, he said: “If you have more than say two arguments that are needed to be passed into a function, use argumentCollection!” In his opinion this is better:
email = structnew();
email["subject"] = "test subject";
email["to"] = "to@test.com";
email["from"] = "from@test.com";
email["content"] = "check this out!";
email["type"] = "text";
// send the email using the SendEmail() function
SendEmail(email);
than writing this:
SendEmail("test subject", "to@test.com", "from@test.com", "check this out", "text");
His hypothesis didn’t sit right with me so I picked up my Code Complete book and went to see what Steve had to say about the subject. Chapter 5, “Characteristics of High-Quality Routines”, mentions that there are 5 levels of coupling between routines: simple-data coupling, data-structure coupling, control coupling, global-data coupling, and pathological coupling. Bryan’s code sample seemed to me to be an example of data-structure coupling, which is defined as “.. two routines are data-structure-coupled if the data passed between them is structured and is passed through a parameter list.” (it’s also called stamp coupling for anyone who cares). The example that uses multiple parameters is an example of simple-data coupling: “… two routines are simple-data-coupled if all the data passed between them is nonstructured and it’s all passed through a parameter list. This is often called ‘normal coupling’ and is the best kind.’”
These definitions certainly don’t prove Bryan’s hypothesis, but they don’t disprove him either. It seems then that the real juice of his argument is that one or two parameters is better than four or five. Chapter 5, section 7 of Code Complete, titled “How to Use Routine Parameters” has this to say: “Limit the number of a routine’s parameters to about seven… If you find yourself passing more than a few arguments, the coupling amoung your routines is too tight. Design the routine or group of routines to reduce the coupling.”
Stepping outside of academia for a second, I’d personally much rather use a method where either:
a) I can read the parameter list and know exactly what is required. For example:
sendEmail(string to, string from, string subject, string body, string type)
is concise and explicit. It leaves nothing for me to mess up.
or b) I can pass an object (which presumably has either defined getters or publicly accessible instance variables). For example, I might define an email package:
EmailPackage email = new EmailPackage(to, from, subject, body, type);
and then send that package to the method:
EmailDeliverer.send(email);
Conclusion? Using more than 2 parameters is definitely not a bad practice, using a data structure instead of a number of parameters is sometimes a good practice, but not the best. Thinking about you should best structure your code? Priceless. Keep up the great thoughts Bryan.
Ray asked a great question a couple weeks ago that I meant to reply to but just never got around to it. He asked why ASP.NET doesn’t include an <asp:query> tag to enable developers to quickly embed SQL queries into an ASP.NET page. The responses seemed to agree with Ray’s assessment that the lack of an <asp:query> tag was shortcoming of ASP.NET, but I think it’s something more than that. If you look closely at the tags (oops! ‘controls’) that Microsoft chose to include in the System.Web.UI.WebControls namespace, you’ll notice that *none* of them give you the ability to declare variables, read a file, query a database, or send email. In fact, all of the controls are about outputting either form components (buttons, drop down lists, checkboxes, etc..) or regular HTML (like images, table cells, table rows, etc.) Microsoft didn’t leave it out because they didn’t have time or money to do it, they left it out because they don’t think you should be writing web applications using tags/controls. Using a code-behind class and controls leaves you with a much cleaner page, one that contains very little, if any scripting code and one where the design is truly separated from the logic. Not one to shy away from an example, compare these two blocks of code that create a drop down list in a form from a query. First in ColdFusion:
<cfquery name="users" datasource="#mydatasource#">
select id,username FROM users
</cfquery>
<select name="userid">
<cfloop query="users">
<cfoutput><option value="#userid#">#username#</option></cfoutput>
</cfloop>
</select>
and then in ASP.NET:
// in code behind class, MyDBWrapper.Query returns a DataSet object
DataSet users = MyDBWrapper.Query("select id, username FROM users");
userid.DataSource = users;
<!--- asp.net page --->
<asp:dropdownlist id="userid" runat="server">
That’s a pretty lame example, but the main takeaway from it is that all of the ASP.NET controls can be manipulated from the code behind class, which is something you cannot do in ColdFusion. You can declare a drop down list in your code behind, bind it to a datasource, modify the selected value, toggle it’s visibility, or modify any of the other 20 or so properties that exist for a drop down list. To me this provides true separation of presentation from logic. Page designers can drop in ASP.NET controls and I can sit in a dark room and modify anything and everything on those controls from my codebehind. You can’t do that in ColdFusion.
Does this mean that ASP.NET is better than ColdFusion? Nope. Notice that I have to create a code behind (technically I could write my code in a <script runat=”server”> block) and that I have to create my own database wrapper class. ASP.NET takes a little bit more work. ColdFusion is much faster to develop in but arguably encourages you to intermingle code with display. ASP.NET takes a bit longer, but developed correctly, encourages you to separate your logic and display code.
Cheers!
If you’re in the New England area next week, you should check out the “Why I hate programming” seminar at MIT. The abstract sounds interesting:
“Over the past thirty years a host of new ideas about programming have
emerged from this building, yet the average engineer has seen little
change in the drudgery of day to day programming. Why is it that have
we not seen large-scale improvements in our programming environments
and methodology? To answer this question I will share a few lessons
and trends picked up from industry and the implications I think these
have for the future.
I will argue that, in part, we have not been solving the right
problems. Far too little of the techniques learned in the pursuit of
AI and the advancement of computer science are employed in our
programming environments and these environments are of too limited
scope. I argue that visibility into behavior is more important than
specific language semantics. I illustrate why testing is more
fundamental to good programming than coding. I explore why the
ambiguity in most projects is actually backwards; typically found in
the design specification and not in the implementation. I’ll propose
that languages hurt abstraction and reuse by requiring programs to be
too specific and introduce some ideas on how to avoid this.
This talk addresses the fundamental question of how to make Moore’s
law work for programmers as well as users: enabling software to be
faster to create, easier to evolve and more robust to run.”
More information can be found at the Dangerous Ideas site.
Flex seems pretty interesting when you realize how similar it is to something like ASP.NET. Look how similar this snippet of Flex:
<?xml version="1.0" encoding="iso-8859-1"?>
<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml">
<mx:script>
function copy() {
destination.text=source.text
}
</mx:script>
<mx:TextInput id="source" width="100"/>
<mx:Button label="Copy" click="copy()"/>
<mx:TextInput id="destination" width="100"/>
</mx:Application>
to this snippet of ASP.NET code:
<script language="C#" runat="server">
public void Copy(Object src, EventArgs e) {
destination.Text = source.Text;
}
</script>
<form runat="server">
<asp:textbox id="source" size="30" runat="server" />
<asp:button id="copy" OnClick="Copy" text="Copy" runat="server" />
<asp:textbox id="destination" size="30" runat="server" />
</form>
I can’t wait to see the IDE rolled out for Eclipse and the .NET version. Cool stuff Macromedia!
Misleading title. I implemented the first of the examples that Erik Hatcher used in his
article about the Lucene QueryParser, only I used NLucene. Lucene and NLucene are very similar, so if anything, it’s interesting only because it highlights a couple of the differences between C# and Java.
First, here’s the Java example taken directly from Erik’s article:
public static void search(File indexDir, String q) {
Directory fsDir = FSDirectory.getDirectory(indexDir, false);
IndexSearcher is = new IndexSearcher(fsDir);
Query query = QueryParser.parse(q, "contents", new StandardAnalyzer());
Hits hits = is.search(query);
System.out.println("Found " hits.length() +
" document(s) that matched query '" q "':");
for (int i = 0; i
The NLucene version looks eerily similar:
public static void Search(DirectoryInfo indexDir, string q) {
DotnetPark.NLucene.Store.Directory fsDir = FsDirectory.GetDirectory(indexDir, false);
IndexSearcher searcher = new IndexSearcher(fsDir);
Query query = QueryParser.Parse(q, "contents", new StandardAnalyzer());
Hits hits = searcher.Search(query);
Console.WriteLine("Found " + hits.Length +
" document(s) that matched query '" + q + "':");
for (int i = 0; i
The differences are mainly syntax.
First, Erik used the variable name 'is' for his IndexSearcher. In C# 'is' is a keyword, so I switched the variable name to 'searcher'. If you're really geeky, you might want to brush up on all the Java keywords and the C# keywords.
Second, while Java uses the File class to describe directories and files, the .NET Framework uses the DirectoryInfo class.
Third, Java programmers are encouraged to capitalize class names and use camel Case notation for method and variable names while C# programmers are encouraged to Pascal notation for methods and camel Case for variables, so I switched the static method name from 'search' to 'Search'.
Next, 'Directory' is a system class, so the reference to the NLucene directory needed to be fully qualified:
DotnetPark.NLucene.Store.Directory fsDir = FsDirectory.GetDirectory(indexDir, false);
rather than this:
Directory fsDir = FsDirectory.GetDirectory(indexDir, false);
Finally, the Hits class contains a couple differences. Java programmers use the length() method on a variety of classes, so it made sense for the Java version to use a length() method as well. C# introduced the idea of a property, which is nothing more than syntactic sweetness that allows the API developer to encapsulate the implementation of a variable, but allow access to it as if it were a public field. The end result is that instead of writing:
for (int i = 0; i
in Java, you'd use this in C#:
for (int i = 0; i
The authors of Lucene also decided to use the C# indexer functionality (which I wrote about a couple days ago) so that an instance of the Hits class can be accessed as if it were an array:
Document doc = hits[i].Document;
I put together a complete sample that you can download and compile yourself if you're interested in using NLucene. Download it here.
Joe and I went to the Lightweight Languages Workshop at MIT this past Saturday. In short, a bunch of nerds got together for the entire day to talk about stuff like haskell, lisp, lua, scheme, and boundaries. If you’re at all interested, you can watch the webcasts (which are of surprisingly good quality) in Real Media or Windows Media here and Joe wrote up his notes already. I’m behind a bit, so here’s mine a couple days late.
The initial session “Toward a LL Testing Framework for Large Distributed Systems” was especially interesting to me for a couple reasons: a) it was based on technology deployed for DARPA called UltraLog, b) ultralog is an “… ultra-survivable multi-agent society” and c) it uses Jabber, Python and Ruby. Specifically, they used the above technologies to enable them to get an up close and personal look at how their entire system (in this case 1000’s of agents) was performing. Said another way, they created a way to quickly and unobtrusively gather information from a variety of datapoints while the program is running. If you have a single website on 1 server, this problem doesn’t matter to you much. But imagine a system of 5000 servers (which is something I was asked to imagine this past Monday, more on that at a later time). An application running on 5000 servers would generate an unuseable amount of information; simple logging statements won’t help you. I’m rambling though. The interesting takeaway from all this is the idea of creating instrumentation for your applications [google search for ‘code instrumentation’].
URLs harvested from the other sessions:
· Web Authoring System Haskell (WASH)
· XS: Lisp on Lego MindStorms
· the idea of continuations, where:
def foo(x):
return x+1
becomes:
def foo(x,c):
c(x+1)
· dynamic proxies [googled] [javaworld.com] [onjava.com]
· The Great Computer Language Shootout
· lua: embeddable in C/C++, Java, Fortran, Ruby, OPL, C#…. runs in Palm OS, Brew, Playstation II, XBox and Symbian.
· scheme
Bill Venners posts part 5 of his converstation with Anders Hejlsberg, this one entitled “Contracts and Interoperability“.
Spent some more time on the C# logging class I’ve been working on. Per Joe’s suggestions, I modified the StreamWriter so that it is now a class variable and as such, it need not be initialized every time the class is used. Instead, you can use a static constructor (the idea exists in both C# and Java, although they go by different names). In C#, you simply append the keyword ‘static’ to the class name:
public class Logger {
static Logger() {
// insert static resource initialization code here
}
}
In Java it’s called a static initialization block (more here) and it looks like this:
public class Logger {
static {
// insert static resource initialization code here
}
}
If you’d like a real life example of a Java static initialization block, check out the source for the LogManager class in the log4j package.
Anyway, now the Logger class declares a StreamWriter:
private static StreamWriter sw;
and then uses the static constructor to initialize it for writing to the text file:
static Logger() {
// load the logging path
// ...
// if the file doesn't exist, create it
// ...
// open up the streamwriter for writing..
sw = File.AppendText(logDirectory);
}
Then use the lock keyword when writing to the resource to make sure that multiple threads can access the resource:
...
lock(sw) {
sw.Write("\r\nLog Entry : ");
...
sw.Flush();
}
Now all objects that call the various static methods will be using the same private streamwriter. But you’re left with one more problem. The streamwriter is never explicitly closed. If the StreamWriter was an instance variable, then we could solve this by implementing a destructor. The destructor would take this form:
~ Logger() {
try {
sw.Close();
} catch {
// do nothing, exit..
}
}
However, in this case the StreamWriter is a static/class variable, no ‘instance’ of Logger ever exists in the system, the ~Logger destructor will never get called. Instead, when the StreamWriter is eligible for destruction the garbage collector runs the StreamWriter’s Finalize method (which itself will then presumably call the Close() method of the StreamWriter instance), which will then automatically free up the resources used by the StreamWriter.
I updated the Logger class and it’s personal testing assistant TestLogger (which has also been updated to use 3 threads). You can download them here:
Fun stuff going on at MIT in a couple days:
“LL3 will be an intense, exciting, one-day forum bringing together the best programming language implementors and researchers, from both academia and industry, to exchange ideas and information, to challenge one another, and to learn from one another.
The workshop series focuses on programming languages, tools, and processes that are usable and useful. Lightweight languages have been an effective vehicle for introducing new features to mainstream programmers. ”
More information here.