Tuesday, July 29, 2014

Is Python a possible alternative for Java

One of the language I evaluated as an alternative to Java of course was Python despite my hatred for languages that have significant white spaces. I did not get very far. In general, the syntax of the language is ok (except for whitespace) but the problem is speed. CPython is terribly slow as in unacceptably slow so I looked at PyPy since this uses a JIT compiler. No luck. It is better that CPython but it is not a substitute for it. You simply cannot assume that the program you ran in CPython will run with PyPy. Some libraries do not run with the JIT and there are a few other incompatibility. So, Python will not be the successor for Java in my book.

Monday, July 21, 2014

Finding an alternative for Java

Some people at work question the use of Java as our main programming language. Since I am not a Java language fanatic I welcome the discussion however, several of the arguments mentioned against Java simply do not resist close scrutiny. Speed when compared to C/C++ ? JIT compiled Java speed is very close to C/C++ and the problems we have encountered in the past where speed was a problem were mostly related to I/O or ... bad design. Verbosity when compared to other languages ? Not such a big problem since the IDE handles most of the scaffolding (the infamous curly brackets, etc ...) and Java 8 removes some of the verbosity. Certainly not worth switching language specially when you consider the advantage of Java. Advantages that include: an incredible ecosystem of tools an libraries, a very good specification, several of the advantages of modern languages such as Garbage Collection and good support for multi-core processors. In fact, since I love programming languages I did try to find a good alternative because of the license issue. Having to pay for a license on embedded systems is a problem when trying to cut cost. Finding a viable lower cost alternative is not obvious. More on this in the next blog.

Wednesday, December 25, 2013

Another reason to use Netbeans instead of Eclipse

A couple of weeks ago I stumbled on a post by another Eclipse fanatic. The insect ... oups, blogger, was making fun of people using Netbeans. Well, fortunatly for him there was no comments or reply button on the page because I would have replied and my comment would have been difficult for him to handle:
You might like the chaotic and always in beta look and feel of Eclipse however the biggest problem with Eclipse is its buggy Java compiler.
Some people don't even know this but Eclipse has his own "internal" Java compiler. Netbeans on the other hand uses the JDK supplied compiler. Eclipse's compiler has one advantage over the one in the JDK and that is the granularity of the compiled elements. Eclipse will compile and "link" smaller pieces of code. In a few cases where you have to stop debugging and restart in Netbeans, Eclipse will simply recompile the small bit of modified code and keep the debugging session alive. The problem however is that the last time I looked there was still a bug in the compiler forcing us to add useless class cast in generic code. To that you might respond that it is not such a big issue. My response to this would be: well one of the benefit of generics is to remove the need for a lot of type casting in the code so for me it is important. My other response to this would be that it is not the only problem with the Eclipse Java compiler. The reason I switch to Netbeans despite Eclipse being the standard where I work is that for a while in the transition to Java 1.7 the Eclipse compiler would simply not compile my project. This was eventually fixed (a week later) but I simply could not wait a whole week without a working IDE so I switched to Netbeans. I have no problems with that because I have always preferred Netbeans to Eclipse. Aside from what I would call the objective argument (an IDE should compile the code correctly) there is of course a subjective side to my preference for Netbeans. I prefer the more static placement of the Netbeans windows and views. It is flexible enough for me and without feeling chaotic like Eclipse. Also, Netbeans was in front of Eclipse supporting the preview version of Java 1.8 and I would not want to be the guinea pig for the 1.8 internal Eclipse compiler.

Sunday, June 2, 2013

The answer to the question at the end of the previous post

What is the answer to the question at the end of the previous post:
Is using an enum for analyzer family a good way to customize the processing in the client application (CT)
Well the answer in the case of our projet was no. The stable part of the application ecosystem was the CT and the analysis cycle step in it. Adding an enum that we would then use to skip step in the processing would have made it impossible for us to add new Analyzer class without opening the code of the CT to support the new class.(remember the OCP or Open Close Principle)
What is an API designer to do in such a case ? Well, what we did was define an interface for the steps in the analysis cycle of the CT and implement a kind of Decorator for that in all SM(I) instances. Of course, concrete instances of this interface are provided by the IInstrumentDefinition factory. The main interface for this is something like:

interface IAnalysisSteps
{
void doStep (String stepName);
}

The CT supplies a default implementation of this that is in fact a supertype that looks like this:

interface IAnalysisStepHandler extends IAnalysisStep
{
void skipStep (String stepName);
}

The IInstrumentDefinition interface has a factory method that looks like:

IAnalysisStep getAnalysisStep (IAnalysisStepHandler analysisStepHandler);

The SM(I) implements a version of IAnalysisSteps that will do one of two thing when it gets called:

- Simply call the default implementation of the IAnalysisStepHandler
- Call the skipStep(String) version of the method in the IAnalysisStepHandler

Now SM(I) instances can customize the steps in the CT without actually having to open the code of the CT. What if new analysis steps are added to the CT ? Well, in that case you don't have any choice but to open the CT and to support that you simply have to implement the SM(I) IAnalysisSteps decorator such that if an analysis step is unknown it is skipped. Since this step was originally not present in the CT skipping it should be a good default behavior for old SM(I) instances. I left out some details above like having different parameters for different analysis steps. That however is easily handled using a single additional parameter of type Map<INamedParameter>. If you don't remember what a INamedParameter is simply look at the previous blog entry.

Wednesday, May 22, 2013

Good software design principles (part 5)

AS you have seen the two main interfaces of the SMF are:
- IInstrumentDefinition: an Abstract Factory that defines methods to get different classes to work with analyzers.
- IInstrument: a Strategy that implements all the steps needed to acquire data from an analyzer. Concrete instances of this are returned by concrete implementation of IInstrumentDefinition dynamically loaded from a .jar file.
The only class that needs to be public (exported) in the SM(I) .jar is the implementation of the IInstrumentDefinition
Now, how do you customize the behaviour of the client application (CA) to work properly with a given SM(I) ? After all, the steps in a analysis sequence of the CA might not all be appropriate for the data returned by a given SM(I).
Would having a method that defines an analyser family be a good idea ? Something like:
Family getFamily()
Where Family would be an enum. Something like:

public enum Family
{
FTIR,
PARTICLE_COUNTER,
MASS_SPECTROMETER
}

Is this a good idea ? Think about this in light of the OCP.

Monday, May 13, 2013

Good software design principle part 4

Another thing that was a big success in the SMF was the use of List and Map(s) (Dictionary in .net). If a class looks like a List, smells like a List and sounds like a list then it probably is a List. This might sound trivial but I have seen project where a class with getters and setters was defined to handle a concept that obviously was a Map. People had to constantly update the interface when new properties where added and the whole thing really was a nightmare. Using data structures such as Lists and Maps makes programming in Java feel much more like dynamic programming. So the IInstrumentDefinition includes a number of methods that actually return unmodifiable Maps. The Maps are generic Map<String, INamedParameter> where the INamedParameter interface is a little one element heterogeneous container. The INamedParameter defines the name, class and value of a parameter or variable. A Map of those is a nice little package that can easily give access to the List<String> of INamedParameter names. Once you have the name you can get the actual INamedParameter from the Map.

Saturday, May 11, 2013

Good software design principle part 3

In the previous post I gave a summary of the problem to be solved using the Successful Module. I explained that in fact the problem is solved using a Successful Module Framework (SMF) and Successful Module Instances SM(i). The SMF is a library used by the client application (CA) and the SM(i) to interact with each other without building cumbersome circular references and dependencies. In Java all modules are .jar files. At compile time both the CA and the SM(i) know the SMF but they don't know each other. Of course at runtime the CA needs to know how to load the SM(i) but that information is limited to the file location. Once it is loaded the CA interacts with the SM(i) as if it consisted only of classes (more precisely interfaces) defined in the SMF. The CA loads the SM(i) .jar and looks for a class that implements an interface called IInstrumentDefinition that marks it as the point of entry into the module. In fact the CA knows only interfaces (pure abstract classes in C++) defined in the SMF. This is one of the key to the success of the whole project. No concrete classes in the API. To understand what the IInstrumentDefinition is we need to enumerate some of the interaction between the CA and an analyzer. The CA needs to:
1- Define the value of parameters used by the analyzer (resolution, number of scan, etc...)
2- Find the list of values that a particular analyzer can supply (the data it can return, etc...)
3- Start an acquisition
4- Read the status of the analyzer
5- Read the data at the end of an acquisition cycle
So. Does the IInstrumentDefinition need to supply operations (methods) related to all these interactions ? No, not at all. In fact it turns out that many of the operations listed above are defined in a separate class called an IInstrument. Things like operation 3, 4 and 5 are defined in the IInstrument. We found that in practice it was very useful to have a specific interface - the IInstrumentDefinition - to define the functions that would provide the more "static" information about an analyzer and that it made sense that this interface be the entry point into the module. We also identified another very important function of the IInstrumentDefinition: Abstract Factory.
The instrument definition is a factory for a host of classes used when interacting with a specific analyzer. Of course the most important of the factory method is the getInstrument() method that returns a IInstrument.