programming languages and human languages
    -----------------------------------------

    rambling intro
    programmers don't input machine code directly,
    at least not in normal circumstances -- they
    use a programming language instead, because
    those are more intelligible than a bunch of
    numbers. there are endless debates about how
    programming languages should work (and I'm not
    even counting the implementation part), since they
    have to be explicity created as opposed to human
    languages which grow far more organically. still,
    there are similarities between these two categories
    of language that might answer a few questions about
    programming language design.

    also, I should note that I only know English and German,
    which are pretty similar when it comes down to it.
    I'll try to avoid making conclusions that implicitly
    assume every language works like Germanic languages,
    because that's obviously not true. that being said,
    my limited perspective might mess up parts of this
    essay without my knowledge.
    
    parameters for a language
    first of all, languages derive structure from their usage.
    the whole class of human language is used to describe
    all the depth of human thought and perception, using
    elements like words and sounds to symbolize specific things.
    these elements ("words" for simplicity's sake) are very
    messy -- there's no single, objective meaning for words,
    although we try to reach the needed level of specificity
    by using synonyms, inflections, tone, context, etc.

    techinically, computer languages achieve the same form of
    expression that human languages do, but the syntax and
    grammar looks more unusual. what makes them different from
    human languages is that their role demands very specific
    definitions. furthermore, programming languages tend to
    work from the bottom up with definitions (via composition),
    while human language defines aspects of our experience
    from the top down (since there's no objective hierarchical
    way to categorize this strange existence we find ourselves in).
    
    ease of use
    the vast variety of meaning works in conflict with (sometimes
    in tandem with) the need for efficiency. unless it's for
    the need of expression, it's generally more uncommon for
    things to be said the long way. the "expressive" reason for
    saying things the long way are often tones that need to be
    established; for example, bureaucratic language is very
    verbose in the US and many other areas because social context
    associates that language with professionalism and robustness.
    
    what I'm going to call "contraction" (making "shortcuts" to
    saying things) in a language often occurs like code optimization
    -- "hot" (frequently run) parts of code are pared made faster
    so that the overall program is more efficient. an example of
    this in human language is the use of genitive pronouns -- it
    would sound clunky, but still be expressible, to say "the book
    of her" rather than "my book." the english language could still
    express the same things with the clunky version, but the
    shortcut of possessive pronouns occurs because possessive
    phrases are common (at least, I think that's why they exist).

    in programming languages, the same sort of "contraction"
    occurs via syntactic sugar and macros. even though syntactic sugar
    isn't absolutely necessary, it helps reduce cognitive load
    and makes writing code more efficient. therefore, a good
    programming language should have the ability to shorten
    things up when they're used a lot; usually, this means
    metaprogramming capabilities.
    
    expression from the bottom up
    programming languages work from the bottom up, meaning
    programmers build code from the baseline of a few inbuilt
    rules and functions. more complex programs are just a result
    of composing and abstracting these simpler elements. what
    most programming languages are concerned about is abstraction.
    basically, abstraction is good and should be easy in a language.

    fine-grained expression
    understanding computer programs isn't just for computers.
    humans need to understand programs as well, which is why
    they do things like abstraction and code comments. comments
    seep into the human language side of things, and while they
    help with fine-grained expression, there's even more that
    can be done. literate programming as it is today requires
    translation between human and programming languages, but I
    think more structural forms of expression could help push
    literate programming to a more subconscious level, where
    the programming language itself works both as a human language
    and a coding language.

    one way of to achieve this is to allow more variation in syntax,
    so that there is more than one way to express the same
    code instructions syntactically. perhaps this could create differences
    in a section of code's "tone?" I don't know.

    grown, not made (?)
    <insert cathedral and bazaar metaphor>
    it's a trick paragraph! I know my writing is insufferable,
    so the rest of this essay leads to somebody else's essay.
    even though they're bottom up and are explicitly designed
    (at least in the beginning), programming languages don't have
    to stay that way -- they can evolve like human languages.
    so read Guy Steele's essay Growing a Language for a
    legitimate opinion on all of this. then again, if you read my
    whole essay, you must not have great taste, so maybe you won't
    like Growing a Language.