Being declarative in code
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.
Which is worse, Heathrow T1 or Washington Dulles C & D Concourse?
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.
Tera-scale computing & Programmer Productivity
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.
leave a comment