Cleanliness, messiness, language, library

[Paul Prescod <address@hidden>]

Dan Sugalski wrote:

>
> I don't think the gap is unbridgeable. I think it's more getting 
> people to realize that there is a gap, and that behavior that is 
> appropriate in one problem domain may not be appropriate in another, 
> and that there really are many problem domains.

That all said, there are many circumstances where a person swears up and 
down that their language feature is necessary for success in their 
problem domain until the next language comes along without that feature 
that nevertheless dominates the problem domain. For instance, I've often 
heard that "native compilation is necessary for scalable software 
development." Until Java came along (and even after) you could find 
someone arguing that the features it removed from C++ were absolutely 
necessary for solving some of the problems Java is used for today. It's 
easy to fool yourself and we are probably all victims of it to some 
extent or another.

> > Second, a language with a variety of modes and different behaviours in
> > those modes is generally harder to learn (in total) than one without
> > modes.
>
>
> Yes, without a doubt. But... so? Simpler languages tend to push off a
> lot of their semantics to their library instead (C's printf, anyone?)
> which just shifts the semantic burden, not lessening it. 

I disagree. A well-documented flag to a function is usually easier to 
learn and understand than a global (or even lexical) flag that changes 
the behaviour of a variety of functions and/or operators.

Also, putting things in libraries usually (not always, but usually) 
makes them easier to learn because you're using the common abstraction 
of the function call with its very fixed semantics: input, behaviour, 
output. In most languages, when you call

x = a(y) + b(z)

you know that a is not going to affect z and z is not going to affect y. 
(well, they could using extreme hackery but that is incredibly rare)

On the other hand, if we replace that by language syntax:

x = a ~~ y + b ^^ z

you lose the comfort of the common function call abstraction and now 
need to understand much more clearly what "b" does to figure out if it 
is going to do something with y.

Furthermore, the function version has all kinds of nice properties:
  * it can be passed as a function to map
  * I can google it (if the name is a little more evocative than "b")
  * it goes into a preditable place in the index
  * I can apply my knowledge of English to its name (e.g. "select")
  * the same name will often appear in languages with radically 
different syntaxes
  * I can play introspection games with b: "oldb = b; b = myb" and "help(b)"

> ... Shifting this
> burden is only a win if you can ignore the semantics because they're 
> in the library, but often you can't. Since the shift seems to increase 
> the total semantic burden (I don't know if this is intrinsic in the 
> shift,  or just that less thought is given to the library code) there 
> really isn't any easing of effort. You trade six months of language 
> learning for two years of library learning.

My experience is exactly opposite: given a random bit of functionality 
(let's say MD5 hashing or MIME parsing), it is usually much easier to 
learn if it is in a library than in the language.

Of course, if the thing is done incredibly often (e.g. array indexing) 
then there is a strong argument that it should be in the language. Not 
because this makes it easier to learn: a[4] is not easier to learn than 
a.index(4). The reason to elevate things from library to first-class 
syntax is to make them easier to *recognize* when reading the code...as 
in mathematical notation. So one could argue that for a text processing 
language, regular expressions deserve first-class syntax. But I think 
that this is a visual aid, not a simplification of semantics.

> Even without that.... so what? The languages people use are complex 
> and messy, and programming languages are meant for people. For the 
> longest time languages were simple, but this was out of necessity, not 
> choice. That doesn't mean they shouldn't be complex, just that they 
> couldn't be.

My sense of the history of computer languages is different than yours. I 
don't think languages have been getting more complex "because they can." 
  I think that they are getting _more simple_ because they can. In 
particular I'm thinking of how quickly Java has taken market share from 
C++ in part by throwing out many features that programmers found 
confusing, complicated or messy. Similarly, VB.NET is much less 
complicated and messy than "classic VB". Often languages are messy 
because of performance issues (binary floating point math being a 
blatant example). Perl is probably unique in embracing messiness as a 
virtue rather than a side effect.

> I'm not trying to argue that all the decisions perl has made are
> correct, because for many of the decisions correct is domain-specific,
> and for some of the others the decision that was made is in hind-sight
> demonstrably sub-optimal. That's fine. What I *am* trying to argue is
> that the things perl has chosen to do are very valid things to do. The
> defaults we've chosen (or that have sort of fallen out) may not be 
> what someone else would choose, and a language with a different feel 
> would have different defaults, but the things we've chosen to do are 
> useful things worthy of doing. *That's* the important point.

Languages embed a theory about how programmers want to work and I think 
that the Perl theory deserves a chance. I don't think we know whether it 
will be a viable evolutionary branch but it is worth a try.

  Paul Prescod