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