Language goals

What are language features for?

magpiebrain (love the name!) blogged:

Each language feature introduced that tries to enforce safety of some kind invariably introduces some reduction in the power of the language. Some of these tradeoffs’ seem acceptable.

Written as above, it would seem that the primary goal of a language feature was to restrict. My own view is a little different - the primary goal of language features is to focus. Focus attention on the critical parts of the problem domain being addressed by the language. Focus time on solving instances of those problem domains.

I have a photography hobby (that is sadly starved for time). When I'm composing images, I usually work in B&W and upside down, to turn off as best I can the parts of my brain that are hung up on naming objects and instead focus on their shapes and relationship to one another.

The same is true in programming as well, and my choice of language.

Prolog is interested in propositional logic, and so exposes Horn clauses as the way to utter propositional logic problems. (Whatever happend to Prolog? Does anyone still use it? I think I last wrote a Horn clause over 15 years ago).

C was designed to solve operating system problems: communications, scheduling, isolation, etc. Pointers and pointer arithmetic allows easy iteration through lists of same-sized (ideally same-typed) things, like process info, thread info, malloc info. Buffer management is important for an operating system because it is tasked with marshalling the limited resources of the system - it needs to know how much memory is allocated, free, occupied by idle processes, etc.

The Java language and platform weren't really intended for this sort of thing. Business apps are more concerned with business and presentation logic. While it can (and has) been said that pointers were removed for safety, I think safety is just gravy. Motivations aside, pointers simply aren't needed nor useful for biz apps and presentation logic. If they had been necessary you can bet that necessity would have won over safety.

Taken to ridiculous extremes to bludgeon the point into submission, all of these problems can be solved in assembly language, but we'd never have the time to do so. My attention span is shorter than the overhead of working in that language (or class of languages, I suppose) for anything but a tiny problem.

Positive value trumps negative value.

Where magpiebrain was really going was to dynamic typing, and he says:

These dynamic languages can be seen primarily as enabling languages - they make the assumption that developer actually know what they are doing.

Expressing 'dynamic' as enabling is good, I like that (per the above). ;) But dynamism by and large hasn't been useful to me in focusing my attention on the problem I'm solving.

And as for knowing what they're doing ...

A developer can know what he's doing, but developers frequently don't. Especially as their numbers, and the number of years a project stays in development and maintenance increases. It is the institutional knowledge problem, or the buzzphrase we used to use, programming in the large.  Teams aren't all that good at disseminating and maintaining knowledge.

Which means that so long as "knowing what they're doing" only requires local knowledge, fine.  But few problems are that localised, at least in my experience.

(Sam, if there was a trackback link, I couldn't find it. Apologies)

[Comments from my previous blog]

1. a reader left...

Wednesday, 28 April 2004 9:29 am

 

Yeah, I really need to display thr trackback URL - the RDF gets spit out so it should really autodiscover. Anyway, found this via bloglines.

When I was talking about language features in the first sentence, I stated features introduced to improve saftey, not all language features...

Sam Newman

2. Geoff Arnold left...

Wednesday, 28 April 2004 9:45 pm

 

In some sense, this is tautological: a feature introduced to enforce safety must do so by making some previouly legal construct illegal, or by constraining the effects of some language construct. The interesting question is whether the constraint is significant or not; are there circumstances under which I might reasonably have wished to express that which is now inexpressible? In the case of Java and pointers, for example, I think that I can state fairly comfortably that in a memory model where there are no guarantees about how structured entities are mapped into memory and no general way for me to discover the mapping, pointers are pretty much useless and I lose nothing if I'm restricted to references.

Visit me @ http://geoffarnold.com

Instant Solutions?

This morning I picked up the April issue of JDJ, and Joe Ottinger's editorial "Looking for Instant Solutions?"  (which doesn't appear to be freely available, so no link, sorry) caught my eye.

His premise is that solutions aren't valuable in large part due to their inflexibility. The same for programmers. Both are stuck in the past, nailed up to prior experiences that adversely colour their reactions.

In part I like this notion, because it explains why some very bright developers insist repeatedy that Enterprise JavaBeans are the wrong solution - it is that they aren't evaluating in terms of the current application and current capabilities of EJB containers so much as they are evaluating in terms of their prior projects and frequently version 1.0 EJB containers.

But Joe goes a little too far with this thought, appearing (after skipping a couple of steps of his article) to recommend the use of meta-solutions over solutions. That is, he calls for a framework of solution creators, from which application-specific solutions can be constructed on the fly.

Perhaps this is an evolution thing. His thought reminds me of reports of the rennaissance, in which there was a vast explosion of creativy and advancement in design, thought, science.  What there wasn't was much standardisation. And in the time between then and now, the processes of constructing things has evolved quite a bit.

The economics of software construction should be of major concern to developers today. Without efficient end-to-end software construction/deployment/maintenance/extension/etc, net return isn't there, and can't flow to the developers. Read: downward cost pressure, which leads to offshoring and other amusements.

The evolution of processes (in the previous sense of the rennassance, construction, et al) has been driven by the same economics: these processes start off with artisans, and over time the grunt work is taken out (from one point of view) or the inefficiencies are removed (from another) or the room for creative craftsmanship is removed (from a third point of view).  Building a car, I no longer design my fasteners one-off.  Only the pentagon gets away with $500 toilet seats.

So long as we're still designing and building screws, we can't focus our brain cycles on the car. And it the car that makes a profit, and pays our salaries.

So while I can understand a desire to use meta-solutions, I don't believe they are efficient or that they help the economics of software development and really allow the field to advance. I certainly agree that a single solution doesn't apply in all situations, but the solution isn't to design the solutions one-off, but is instead to develop a more flexible solution or group of solutions that cover a range of our activities.

My big red tool chest has 4 sizes of Phillips screwdrivers, and 2 Robertson. And this is good. I don't need to craft screwdrivers on my own.