Apache Mahout is an open source project aimed to develop a scalable machine learning library. This is an exciting project. Although machine learning technology has its roots in the field of artificial intelligence, but it has broad application in today's digital world.
In the past, developing sophisticated and scalable machine learning library is limited to academic institutions and commercial companies with a deep pocket and an army of research scientists. I think Mahout is going to change that.
Mahout reminds me of its parent project Lucene, a very successful Apache project created to develop open source library for document search. Before Lucene, it was difficult to create an effective and scalable document search engine. These days with Lucene, developers can easily use it create a custom search engine in a few hours. I'm looking forward to see Mahout everywhere!
Check out Grant Ingersoll's introduction on Apache Mahout.
Showing posts with label Java Programming. Show all posts
Showing posts with label Java Programming. Show all posts
Saturday, September 19, 2009
Sunday, April 19, 2009
Programming languages should die
Recently I wrote a blog on learning new programming languages and how to think about the constant changes of programming languages. Learning a new programming language is easy, but mastering it, able to use it well, is often difficult. It would be ideal if the world has only one or two programming languages. All engineers can master them and program with them effectively. Unfortunately, that's not the case.
It's necessary for us to develop new program languages every few years, I argued in the previous blog. Today I come across a related article on Javalobby, which titled "Languages Should Die".
Central to the article is the idea that programming languages are like animal species, they evolve and they die. Programming languages should die (i.e., we should avoid using them) when they become unusable. We should be prepared to abandon languages when they become less effective to program.
In reality, the problem is a bit more complex. Sometimes the industry may continue to use a programming languages because it's too costly to replace, or it's worthy of fixing. For example, COBOL is an ancient programming language. It's a language that should have died in the last century. It's still used today because certain organizations refuse to change for political and financial reasons. The Java programming is a good language, but has its imperfections. While we could create new language to replace Java, but it's probably worthy the effort to fix it.
A programming language evolution is a good thing. Every few years we should create new languages (or fix the existing languages), so that when we develop software, we can avoid inheriting "bad" and obsolete designs from the previous generation of languages. Hopefully, those improved languages will help us to build more robust and reliable software.
It's necessary for us to develop new program languages every few years, I argued in the previous blog. Today I come across a related article on Javalobby, which titled "Languages Should Die".
Central to the article is the idea that programming languages are like animal species, they evolve and they die. Programming languages should die (i.e., we should avoid using them) when they become unusable. We should be prepared to abandon languages when they become less effective to program.
In reality, the problem is a bit more complex. Sometimes the industry may continue to use a programming languages because it's too costly to replace, or it's worthy of fixing. For example, COBOL is an ancient programming language. It's a language that should have died in the last century. It's still used today because certain organizations refuse to change for political and financial reasons. The Java programming is a good language, but has its imperfections. While we could create new language to replace Java, but it's probably worthy the effort to fix it.
A programming language evolution is a good thing. Every few years we should create new languages (or fix the existing languages), so that when we develop software, we can avoid inheriting "bad" and obsolete designs from the previous generation of languages. Hopefully, those improved languages will help us to build more robust and reliable software.
Wednesday, April 15, 2009
Create singleton classes in Java
The Java singleton design pattern restricts the creation of a class to one object. There are two ways to create a singleton class in Java. While both approaches are correct, but deciding which approach to use requires some discussion.
Let's see how to create a singleton class Foo, which has one method doFoo that prints a string message to the standard output stream. By being a singleton class, at anytime only one instance of this Foo class can be instantiated by a single Java classloader.
Approach 1: Use enum to create a singleton class
Approach 2: Use private static variable and static factory method to create a singleton class
In the two usage examples, the calls to Foo.doFoo look very similar. But, technically they are very different. In the first example, we access the singleton object through an enum instance of the class (i.e., Foo.INSTANCE). In the second example, we access the singleton object through a static factory method, which returns the static variable singleton. This private variable is statically created when a Java classloader loads the Foo class.
So which approach is more preferred when writing a Java singleton class? Some developers prefer the second approach because it is the de facto approach to create a singleton class since the birth of the Java programming language. They also argue that since all experienced Java developers are familiar with this approach, software programs that adopt this approach should be more maintainable and readable.
Personally I prefer the first approach. First, it's easy to create singleton classes using enum -- if you know how to create an enum class, then you know how to create singleton. Second, it eliminates the possibility for multiple objects of the same singleton class to be created through a careless custom Java serialization implementation.
Let's see how to create a singleton class Foo, which has one method doFoo that prints a string message to the standard output stream. By being a singleton class, at anytime only one instance of this Foo class can be instantiated by a single Java classloader.
Approach 1: Use enum to create a singleton class
public enum Foo {
INSTANCE;
public void doFoo(){
System.out.println("Hello World!);
}
// Usage Example 1:
// Gets the singleton Foo object, and calls doFoo
Foo.INSTANCE.doFoo();
Approach 2: Use private static variable and static factory method to create a singleton class
public final class Foo {
private static final Foo singleton = new Foo();
// Make the default constructor private
private Foo(){
// no code
}
public static final Foo getInstance(){
return Foo.singleton;
}
// Usage Example 2
// Gets the singleton Foo object, and calls doFoo
Foo.getInstance().doFoo();
In the two usage examples, the calls to Foo.doFoo look very similar. But, technically they are very different. In the first example, we access the singleton object through an enum instance of the class (i.e., Foo.INSTANCE). In the second example, we access the singleton object through a static factory method, which returns the static variable singleton. This private variable is statically created when a Java classloader loads the Foo class.
So which approach is more preferred when writing a Java singleton class? Some developers prefer the second approach because it is the de facto approach to create a singleton class since the birth of the Java programming language. They also argue that since all experienced Java developers are familiar with this approach, software programs that adopt this approach should be more maintainable and readable.
Personally I prefer the first approach. First, it's easy to create singleton classes using enum -- if you know how to create an enum class, then you know how to create singleton. Second, it eliminates the possibility for multiple objects of the same singleton class to be created through a careless custom Java serialization implementation.
Friday, April 10, 2009
On learning new programming languages
Programming languages are the building blocks of computer science. New programming languages often emerge every few years. Recently I come across a new language called Scala. This new language attempts to unify object-oriented programming and functional programming. Its syntax is similar to Java and C# with some additional features.
This paper gives an overview of Scala.
After reading up on Scala and its recent buzz in the new, I thought about the relationship between new programming languages and software development.
Business requirements will continue to change. For this reason, new programming languages are necessary to help engineers to get their job done faster and better.
Answering Q2. Develop software programs using cutting-edge technologies don't always yield the best result. For example, Twitter was built on Ruby, and it proved to be problematic. If it had developed the system using PHP or Java, I suspect many scalability issues could have been avoided. However, this doesn't mean new technology has no value. Building systems with new languages usually encourage new way of thinking, opening new doors to innovation. For example, Google Maps is successful because its innovative usage of Ajax, and which helped spawning a new generation of "cool" web applications.
Answering Q3. What separates good software engineers from the rest is in the ability applying software design and engineering skills to problems that don't have conventional solutions for. Fluent in new programming languages is not a substitute for programming experience and skills. However, knowing the intricacy of different programming languages and having the will to learn new technologies can certainly help engineers to sharpen their skills.
Technorati Tags: Scala, Programming
This paper gives an overview of Scala.
After reading up on Scala and its recent buzz in the new, I thought about the relationship between new programming languages and software development.
- Q1: Why do we invent new programming languages every few years?
- Q2: What benefits do we gain by developing software with those new languages? Can't we just program with the languages that we are already familiar with?
- Q3: Should all good software engineers be expected to be fluent in cutting-edge languages at all time (i.e., should I go learn Scala today)?
Business requirements will continue to change. For this reason, new programming languages are necessary to help engineers to get their job done faster and better.
Answering Q2. Develop software programs using cutting-edge technologies don't always yield the best result. For example, Twitter was built on Ruby, and it proved to be problematic. If it had developed the system using PHP or Java, I suspect many scalability issues could have been avoided. However, this doesn't mean new technology has no value. Building systems with new languages usually encourage new way of thinking, opening new doors to innovation. For example, Google Maps is successful because its innovative usage of Ajax, and which helped spawning a new generation of "cool" web applications.
Answering Q3. What separates good software engineers from the rest is in the ability applying software design and engineering skills to problems that don't have conventional solutions for. Fluent in new programming languages is not a substitute for programming experience and skills. However, knowing the intricacy of different programming languages and having the will to learn new technologies can certainly help engineers to sharpen their skills.
Technorati Tags: Scala, Programming
Friday, August 1, 2008
On Java exception handling
I came across a series of blog posts by Daniel Pietraru that deal with the use of exceptions in Java programming -- I love it. The exception framework in Java provides a means for programs to signal and handle errors and other exceptional events. It's not difficult to write code to throw and catch exceptions in Java. But, properly use exceptions in Java programs is not well understood by many developers.
There are three types of exceptions in Java: checked exceptions, unchecked exceptions and error exceptions. Checked exceptions are all exceptions that subclass from the java.lang.Exception class. When a method throws a checked exception (e.g., IOException), the client code must handle the exception by either defining a try-caught block or delay the exception handling by propagating the exception event up to a higher level code.
Unchecked exceptions are all exceptions that subclass from java.lang.RuntimeException. Unlike the checked exceptions, when a method throws unchecked exceptions, the client code is not required to define explicit code to handle the exceptions -- e.g., NullPointerException.
Error exceptions, the last type of exceptions in Java, are all classes that subclass from java.lang.Error. These exceptions indicate serious problems that a reasonable application should not try to catch. For example, the exception java.lang.VirtualMachineError indicates the JVM is broken or has run out of resources necessary for it to continue operating. Developers rarely need to throw error exceptions or write codes to explicitly hand error exceptions.
When designing a Java API that throws exceptions, how should you choose to throw a checked exception and an unchecked exception? Daniel discussed this in Exceptional Java - Exception design relatively. An answer to this question is also described in Joshua Bloch's Effective Java.
The basic guideline:
Sometimes it's difficult to draw a black-and-white line between which exception to throw given a specific exceptional condition. It's really up to the developers to decide. Exception handling in Java if use properly can greatly improve software quality. It's definitely valuable for developers to think about exception handling design early in their software development cycles.
There are three types of exceptions in Java: checked exceptions, unchecked exceptions and error exceptions. Checked exceptions are all exceptions that subclass from the java.lang.Exception class. When a method throws a checked exception (e.g., IOException), the client code must handle the exception by either defining a try-caught block or delay the exception handling by propagating the exception event up to a higher level code.
Unchecked exceptions are all exceptions that subclass from java.lang.RuntimeException. Unlike the checked exceptions, when a method throws unchecked exceptions, the client code is not required to define explicit code to handle the exceptions -- e.g., NullPointerException.
Error exceptions, the last type of exceptions in Java, are all classes that subclass from java.lang.Error. These exceptions indicate serious problems that a reasonable application should not try to catch. For example, the exception java.lang.VirtualMachineError indicates the JVM is broken or has run out of resources necessary for it to continue operating. Developers rarely need to throw error exceptions or write codes to explicitly hand error exceptions.
When designing a Java API that throws exceptions, how should you choose to throw a checked exception and an unchecked exception? Daniel discussed this in Exceptional Java - Exception design relatively. An answer to this question is also described in Joshua Bloch's Effective Java.
The basic guideline:
- Throw checked exceptions if the problems can be reasonably recovered in the client code.
- Throw unchecked exceptions to indicate programming errors (e.g., bugs in the client code and mistakes by a careless programmer).
Sometimes it's difficult to draw a black-and-white line between which exception to throw given a specific exceptional condition. It's really up to the developers to decide. Exception handling in Java if use properly can greatly improve software quality. It's definitely valuable for developers to think about exception handling design early in their software development cycles.
Subscribe to:
Posts (Atom)
