Posted on October 2, 2008 by abahtowt
This is a nice response to a question on functional vs declarative from Sean McDirmid over on lambda-the-ultimate, a great site for programming language geeks.
Declarative means that code does not encode how computations occur, just what occurs. Admittedly, this is a very fuzzy definition, and it is easier to just say declarative = immutability, but that really misses the point. I also think the declarative label should be applied to code rather than languages, as non-declarative code can be expressed in any Turing-complete language.
Code that is declarative does not encode control-flow details, which are dealt with by the language run-time. Prolog can be used as a declarative language in simple contexts, but for complicated programs that require cuts or lots of recursion, code becomes very non-declarative as programmers are exposed to a lot of control details. Likewise in Haskell, especially since imperative programming is conveniently done with monads. IMHO, recursion is as non-declarative as assignment, as it is easy to simulate one with the other. It is definitely possible to express declarative code in Prolog and Haskell, but it is also possible to express declarative code in Java or even assembly. Declarative code in these latter languages would just look really ugly, and their declarative nature would be obscured by syntax.
Syntax issues are important when designing a declarative language. If we want to make two values are equivalent, i.e., x is y, its much better to write x = y or x==y or x is y, rather than x.set(y), where the declarative nature of the code is obscured by syntax (it looks like an assignment rather than a declarative relationship). Expressing declarative code in Java is ugly, as everything is done through assignment, and it is difficult to tell that the code being written down is actually declarative. Also consider expressing declarative rules in Java that execute via a rule engine. On the other hand, Scala list comprehensions provide a nice declarative syntax for abstracting over data that hides less declarative function call and closure creation details. Also, using operator overloading in Scala, it is possible to also write decent Prolog code.
Filed under: Declarative | No Comments »
Posted on October 1, 2008 by abahtowt
Probalbly not a question you have likely asked yourself unless like me you have travelled through both recently. Heathrow airport really has to be the worst of all the major hubs, I think everyone agrees on that.
Last week I passed through the recently refurbished Heathrow T1 terminal. On first appearance it’s nice, airy, spacious but then try finding a drink. Yes, there is a coffee shop, just the one, and with a queue of 25 people at it. So I started looking for a shop that sells drinks, and there is one of these as well, just the one, at the other end of the building and charging a 100% mark-up, not very impressive after 20hrs of traveling.
There are plenty of other ‘outlets’ in T1 but selling stuff that really has no value to me, electronics (at high-street prices), designer clothes, perfumes, etc. My experience was not really helped by having the fire-alarm go off while I was there and having to be photographed on entry for a purpose I have no idea about as I had a brand new biometric passport in hand.
Dulles is a big contrast, it’s aged, claustrophobic and cramped but hey it has a choice in food services so that is something. The big killer for me there is that there are too many gates. This means too many people for the size of the concourse at busy times. It’s close to the experience of a busy London tube station and not in a good way. This may be OK if you are just jumping around the US but for an international traveller not a great option.
So my current favourite airport? Think it has to be Shanghai, the building is great, there are enough services to get what you need easily and recently they have put a big effort into speeding your entry & exit which is more than can be said for US passport control recently.
Filed under: Travel | No Comments »
Posted on October 1, 2008 by abahtowt
For software geeks there are a couple of interesting projects running at Intel under the Tera-scale computing research initiative, here.
I have been looking at the progress on Ct, a C like runtime model for throughput computing, think “how to get high throughput on many core systems” where many-core could mean core counts into the 100s. It’s obvious there are some real significant challenges here but that is not what caught my attention, but how we trade focus on efficient hardware use against programmer productivity as an industry.
In enterprise environments we have plenty of thread-level parallelism to exploit for some time to come in our web and applications servers. This necessarily makes the questions Ct is trying to answer less pressing than for client application developers which really need to be addressing at least the multi-core challenge today. That of course begs the question of what ranks higher, in fact what does that productivity improvement list look like, here is my list of -isms,
Declarativism - Well maybe not really a word, but I am sure you get what I mean. There is no real argument over how much easier declarative approaches to design and implementation are for me. What is missing is making the approaches more open. I tend to find junior programmers really resistive to declarative thinking. I don’t think this is simply an education problem, it’s more deep rooted than that and maybe will require a conceptual breakthrough similar to the object-orientated revolution.
Dynamism - Covers everything from dynamic typing to reflection features. This is a “get out of my way” request to the tool chains but it has a significant proviso, don’t let me look like a fool by creating code that is unreliable. We are on a path to progressing this but I think its going to be a long path to make it to main street in a form safe for mass use.
Parallelism - The multi/many-core challenge does make my list but it really is third of these three. Important for some environments today and no such much others. It’s an efficiency concern that we must solve for sure.
Filed under: Declarative, Dynamic Languages, Intel | No Comments »
Posted on June 9, 2008 by abahtowt
John Rose has got the early draft release for JSR 292 invoke dynamic out the door recently. Will be interesting to see how this is all received in the wider language community. There were a few things in there I was not that happy with but I will save commenting on them for another day.
I did really want to do some low-level coding towards this but the Sun contributor agreement is not that open to me so I will probably have to watch the rest of the JCP process unfold a bit from the sidelines.
Filed under: Dynamic Languages, Java, invokedynamic | No Comments »
Posted on June 9, 2008 by abahtowt
I watched QCon presentation from Martin Fowler & Jim Webber over at infoQ (great site) this morning. It’s entertaining, informative, presented by smart people, based on rational judgments but it still smells a bit to me.
They argue very coherently that current ESBs are not the dog danglies (as we would say in england). They do this via an agile manifesto that while comforting to all stuck in corporate hell really fails to address the key point, that enterprise integration/messaging are very very hard, like parallel algorithm hard.
Putting aside the obvious agile agenda here, the root issue for me is that the WS-* and REST camps don’t represent a binary decision. They are extremes upon which we try and map to the simplest but no simpler. It’s hogwash to suggest that a REST model is good enough for anything, it’s just about good enough for web pages and really very little beyond that. It’s equally hogwash to think WS-* is a panacea, it creates as many difficulties as it solves.
The real question is where is the middle ground that is better than both, maybe this really is like parallelization, fundamentally hard with little prospect of a solution, just some pills to take away some of the pain.
Filed under: Uncategorized | No Comments »
Posted on May 1, 2008 by abahtowt
I used to think code spaghetti was one of the worst types of complexity you can have to deal with. I have just found another form of spaghetti that might actually be worse, fuel-injected engine wiring.

This is a new Yamaha R1 2007 engine being retro-fitted to my little sprint car. The car is a westfield that I built a few years a go while taking a break from the software world. Sprinting is a fairly low-key motor sport in the UK that involves timed runs over mostly open circuits. Here is a westy in typical sprint action.
The R1 is part of a plan to make us competitive in our class and have a bit more fun along the way, its always about performance with me…
Filed under: Westfield | No Comments »
Posted on January 21, 2008 by abahtowt
Bruce Eckel started an interesting debate with his article on
artima. He elegantly puts forward the view that it’s perhaps time to stop adding to Java and to move on with new languages. I have struggled with issue in relation to JSR292, the invoke dynamic proposal. In some ways doing very little is entirely possible but it shifts significant burden to the JIT implementer to do a good job. More radical change will likely result in better end results but there is certainly a cost to be paid in backward compatibility and complexity for that. I have to vote for stability, just because that is what always won out for the x86 market.
What this debate reminded me of is a famous
Craig Barret quote:
“Barrett compares Intel’s microprocessor business to the creosote bush, a tall desert plant that drips poisonous oil, killing off all vegetation that tries to grow anywhere near it. Microprocessors so dominated the company’s strategy, he says, that other businesses could not sprout around it.” -
BusinessWeek
In this case it’s the Java business/hype that has always hindered other JVM languages. Sun have clearly being trying to change this over the last year but it’s small steps so far. The crux for me is that the JVM is and always has been a slave to the Java language. Until this changes and it becomes independently managed for the benefit of many languages we are stuck. Maybe
OpenJDK will make this possible but good opportunities are frequently lost due to
poor business decisions.
Filed under: Dynamic Languages, Intel, Java, invokedynamic | No Comments »
Posted on December 31, 2007 by abahtowt
This looks important. Smart guys from UC Irvine have developed a technique for getting significant performance gains in a JVM using a much simpler (and therefore smaller & cheaper) JIT model. The Adobe team behind the Tamarin VM for Javascript have announced a branch which is trying to use this technique. The original paper shows gains of 7x over interpretation against 10x for Hotspot. It’s easy to get mislead by micro-benchmarks but lets hope this materialises into gains on everyday workloads.
Filed under: Dynamic Languages, Java | No Comments »
Posted on December 27, 2007 by abahtowt
Here is some more on JAXB performance, the graph below shows the performance of the JAXB 2.0 Reference implementation and the Apache JaxMe project as the size of a data is increased for a trivial address book mapping. It also shows what happens to the JAXB-RI performance when schema validation is turned on, not a pretty picture.
This is better than I had seen elsewhere because at 10k (about 13.5 on the graph) we are getting ~80% of peak performance. Obviously using JAXB with smaller messages or with validation on may be damaging to your applications health. The graph for marshaling is below, this is a much more healthy for small messages but validation is again very costly.
Profiles for these runs shows that un-marshal performance is being governed by startup time and the maximum speed of the XML parser. When marshaling the parser startup costs are obviously not a factor and so the results are more linear. In either case turning on schema validation has a dramatic effect.
Filed under: JAXB, Java, XML | No Comments »
Posted on December 8, 2007 by abahtowt
One of the tricks to making good use of SIMD performance is to know all the parameters of the problem, it’s an 8×8 matrix or a 128byte vector etc. etc. In practice though this is really hard in a number of domains, that kind of information is not known until the code runs. For that type of an application template-based metaprogramming for C++ may be a real bonus. A couple of libraries that use this approach are Macstl & EVE.
My question, what do you do from Java & please don’t suggest JNI is quick enough :-)
Filed under: Java, SIMD | No Comments »