Radical Simplicity by Stuart Halloway

Yet another talk by Stuart Halloway, his presentation style and pronunciation are really good. And personally I find it comforting and pleasant to listen to his voice which makes it for me really easy to follow. Putting not too much emphasis on the technical aspects, this talk raises a number of important questions, in my opinion. I want to name two aspects here in a bit more detail:
1. Simplicity
Around 00:53 reflection API Example is given to demonstrate what simplicity means. I think it is important to define, even simple (hu?, ha!) terms like simple because again, it becomes apparent that different people have different meanings and perceptions for terms. Maybe its obvious to some maybe not but simple does not easy or beauty. Now how can we grasp simple in terms of programming or rather API's? The reflection example demonstrates this quite nicely. The API should consist of small reusable parts which can be used to build higher level functionality or abstraction.

In the following he asks: Why we don't have radical simplicity?
And to observe the answer or even pursuing the question is a very worth goal for every programmer.
Stuart names Pressure (about 1:09) and the lack of trust. Could you justify to build 4 Prototypes in your curent/next project (Even if the first worked)? How do we, that is the programmer side and the stakeholder side define and agree on 'good enough'?


2.  (simple) Foundations of programming
On 1:03 these four foundations are listed:

• functions
• logic
• relational model
• associative model

and it is concluded that all these have a mathematical foundation.  But actually OOP has none. It is pointed out that OO is inherently complex and there could be a potential danger by having features that could do harm if abused. Specifically applied to Java he claims Java is: compound, complex and complicated.

Eventually this talk has inspired me to sharpen my point of view on API's and to question for simplicity in my programming job, consciously.

http://skillsmatter.com/podcast/java-jee/radical-simplicity/js-2051

Code use and re-use

One of the things that may seem trivial is how in software systems reuse is achieved. I'm going to write about some thoughts of mine in this regard.


OOP
I think that most people would agree with the OO(Object Oriented) Paradigm, it is common to use inheritance (implementation inheritance).  So you define code in a class, now if you extend that class from another one you can use the code from the parent class just fine.

Did you reuse the code from the parent class or are you now just using it?


It is quite important to pay attention to this. You can now use the code from the parent class but just in the child classes. So there is a dependency from child to parent class. I would argue that this is code use.

FP
In functional programming reuse is achieved through composition. Which means if you have a function which takes an Int and results in an array of chars and another one which takes an array of chars and results in a String, I can create yet another function which takes an Int and results in a String. Again this seems trivial and one might ask why same can't be done with OOP?

RT
The answer to this is (I guess) referential transparency. The fundamental principal of  FP is that if I  invoke a function with the same arguments I will always get the same result (or type therefore). This guarantees me re-usability.

Code use and re-use is about granularity and scope.  To identify clearly what you need in a specific situation is important.

So these are quite different approaches and there are many other aspects involved (besides re-usability) in software development. But for now I like the FP approach better. Because when composing functions I can rely on referential transparency while with OOP state and functions are usually mixed up.

ECF Team Editor

Today I found[1] out about a very nice tool for cooperative programming. It is based on eclipse and I used the following to get started:

• eclipse 3.5
• ECF 3.0 through update
• google mail account
• open communications perspective
• login with google mail 
• add contact
• project with same: name, package and files
• share workspace to collaboration
• host: share editor with

This enables two computers running eclipse to share a common code editor. It even offers simultaneously coding in the same file! That's pretty amazing. I don't know exactly how this could be used in a professional environment but for a quick hack session this seems ideal.

[1]http://live.eclipse.org/node/543
Some further references on the topic:
http://wiki.eclipse.org/DocShare_Plugin
skype provider
skype provider documentation

more on Scala

What is interesting about Scala that it offers a lot of powerful features.

Context Operations
Since Methods can be used in infix notation and you can use symbols as method names (like *,/,+,-) , it is important to view them always in context or to be specific in scope of the current code.

Many of those features derive from functional programming. Which seems a vast space to explore. But for now I may start with closures.


No Statics
Scala is in fact more OO than Java, it removes statics completely and introduces another construct the 'Object'. By defining an object in scala you define an single instance module or singleton, which can be referred to without using an constructor.


Closures and Functional Programming
So I stumbled about this blog post[1].  While it only started with the title Closures, it offers quite more than just that. The post discusses concepts which define algebraic structures, e.g.: associativity. The MyClass example seems simple and compelling. In quite a different manner (than so far for me) the author describes functional programming and how it can be useful. I really like that. Functional programming is a broad topic and this particular spot on helped me to get started.

Some more advanced topics from functional programming would include topics like: Monads, Applicative, Arrows and Zipper. Some useful links:

[1]http://aabs.wordpress.com/2008/05/29/functional-programming-lessons-from-high-school-arithmetic/
[2]http://debasishg.blogspot.com/2008/03/monads-another-way-to-abstract.html
[3]http://james-iry.blogspot.com/2007/09/monads-are-elephants-part-1.html

XML API's

The two most common XML API's are DOM and SAX. Now there is a third 'major' API evolving: StAX.


Concepts
Push - SAX
The API 'pushes' data to the application. The data is sequentially processed.
Pull - DOM
The API offers to 'pull' data out. Full random access to the data is available.

SAX uses a hierarchical event handler and DOM uses a nested iterators. Finally StAX uses a hierarchical iterator. So while SAX is very fast and efficient the API is a little bit difficult to use. You have to maintain  where you are in your document yourself on the other hand an iterator gives you a common control abstraction. In most cases you don't need access to the complete XML data tree but to a distinct subset and right here StAX fits in. 

So I think this illustrates pretty nicely that it's not only important to look at the 'speed' of your XML processing application but also about maintainability and extensibility. If it's really hard for you to implement your solution with SAX and performance is not a problem StAX  is a nice alternative.  

This is the first time where I realized what huge impact the design of an API has on code. Or to be more precise, on the actual result of what you had intended to code. 

Guice - Dependency Injection

Today this was released:
http://code.google.com/p/google-guice/
Minimizing dependencies in OOP projects sounds nice. Spring uses XML files for configuration while guice uses Java 5 Annotations. So far i only have experience with picocontainer and it's nice and simple to use.
further read

trac(ing)

Today i stumbled across this:
http://trac.edgewall.org/
This seems like a really good idea for project management since it integrates a lot of features that do seem use full in that context like:  a wiki or timeline features.

Sorting algorithms

Wikipedia (as usual) has very nice material on this[1]. Here are also some[2][3] graphical representations of sorting algorithims.

EDIT 2010: found [4] this on topic, you never know when there is a new search algorithm appearing.  

[1]http://en.wikipedia.org/wiki/Sorting_algorithm
[2]http://www.cs.rit.edu/~atk/Java/Sorting/sorting.html
[3]http://cg.scs.carleton.ca/~morin/misc/sortalg/
[4]http://www.drmaciver.com/2010/01/understanding-timsort-1adaptive-mergesort/

Webservices - Ménage à trois

Here I want to write down a little reminder to myself about current Webservices techniques.

RPC - Remote Procedure Call
Uses XML encoded Data types for communication.


WSDL - Webservices
So this is powering all the SOA(P?!) Hype. I have only some limited experience with some WSDL Webservices build using .NET 1.0 / 2.0.
Visual Studio holds your hand very nicely (as expected) for simple stuff. But to deal with more complex and custom Objects it would be very interesting i guess. I tried a "quick" example to get a Java client to interact with a .NET Webservice and it failed miserably.


REST - Representational State Transfer
Usually it goes like this: You have some kind of data and then you think about API's, how to access or manipulate this data. REST turns things a little upside down. There is a well defined set of operations : GET, PUT, DELETE. The concept is focused on the interaction of state full resources.


It will be interesting to see how these will develop in the future.