[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: succinctness = power
We're talking about languages, not individual programs.
Of course there are cases where you can by some hairy
trick make a program slightly shorter yet harder to
understand. Everyone has seen such programs.
The question at hand is, can a *language* be too succinct?
I.e. can you design a language that forces users to
express their programs in an excessively dense style,
rather than (like any language) merely allowing them to?
I have not seen any evidence for succinctness and
readability (overall readability, not readability-per-line)
pulling in different ways at the level of language design.
Got any evidence of that? Let us know.
Incidentally, I am not a big fan of comments. I think they
are often an artifact of using weak languages. I think
that programming languages should be a good enough way to
express programs that you don't have to scrawl additional
clarifications on your source code. It would be a bad
sign, don't you think, if a novelist had to print notes
in the margins saying "she left without saying anything
because she was angry about the trampled petunias?" It is
the job of the novel to make that clear. I think this is
what SICP means when they say "programs must be written
for people to read, and only incidentally for machines to
execute." I use comments mostly to apologize/warn about
hacks, kludges, limitations, etc.
> > ... (Which is why
> > I distrust arguments about language design that treat
> > readability and succinctness as if they were opposites.)
> They are not opposites. In particular situations they can pull in
> opposite directions. That's a very different statement.
> Is it really the case that you've never seen a situation where you could
> leave something anonymous that would be more readable if it were named?
> If yes, then you've demonstrated the point of programming is not to make
> the most succinct program. Or to put it another way, do you use comments
> in your programs? How do they help you to make the program more
> Paul Prescod