[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Cleanliness, messiness, language, library
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
* 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 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.