Horizon

No, it's working fine Ben; we're all just too busy/idle [delete where applicable] to post anything.

Hmm. If nobody else is paying attention, I may start posting reviews of the Ruby programming language's %w{} operator. Or post-apocalyptic sci-fi.

Ruby is cool.

And Omega Man is a great film!

Good find, by the way. An objectivist and an anarcho-capitalist all on one blog.

Erm, I thought that objectivism and anarcho-capitalism went together, sort of like Evangelicalism and Intelligent design. Have you ever met an anarcho-capitalist who wasn't also an objectivist?

Now you mention it, I guess you're right. Okay, I take it back.

Seriously, have you used Ruby much? If so, I've got some Rails questions for you.

No, wish I had. I've just fiddled around with it, made a little grep-like thing to see how it worked. Took me a while to get my head around.

I guess it's a good thing I learned to use Perl, since that seems like an obvious choice for a linguist (if I wind up doing that sort of thing, don't know). But Ruby is just so interesting.

Oh, while we're at it, have you ever used/know much about functional languages like Haskell? I've heard some guy's modelling a new generative grammar with it.

The introductory CS class at Rice was entirely in Scheme. Recursion is a hard thing to wrap your head around, but I think learning a functional langauge is a worthwhile exercise. IRL, the only time it's really come in handy was about two years ago, when I had to write a global string replacement function in XSLT. (You may have to view source on that doc: "inner_replace" is the template that matters, "replace" is redundant but I never bothered extracting it.)

It's sort of bizarre to be projected back into a freshman-year classroom in your daily work life. Then again, I've had to do stranger things, like reading the NH state constitution.

The main intersection between lingustics and CS that I came across in my schooling was in compiler class. Building parse trees, describing a context-free grammer in BNF -- all very lingy.

Neat. I had to read that a number of times before I figured it out as I've never had an opportunity to learn much XML related stuff.

I haven't done too much XML (never made a DTD), but sure have done a lot of XSLT. We always joke about having to put your brain in the "XSLT Zone" when you deal with it, and it does take time to get your bearings each time. I think that a lot of that is due to XSLT being a functional language — the corresponding experience when I have to re-learn Perl every 18 months is much less disorienting.

Speaking of Perl and linguistics, do you have any opinion on $_ corresponding to the topic in topical natural languages? Never having learned one (or at least not well enough), I'm not sure.

I guess it's a good thing I learned to use Perl, since that seems like an obvious choice for a linguist

Why do you say that?

Speaking of Perl and linguistics, do you have any opinion on $_ corresponding to the topic in topical natural languages? Never having learned one (or at least not well enough), I'm not sure.

Not sure what you mean by topical languages. Do you mean something like Japanese that has a particle that indicates the theme of a sentence?

I've never really looked into it, but it seems like Perl has various features modelled on natural language, like the way it assumes so much based on context (a variable becomes whatever type you treat it as, $_, and so on).

I have the Perl bible here. Maybe Larry Wall has something to say about this. I'll check if I have time.

I guess it's a good thing I learned to use Perl, since that seems like an obvious choice for a linguist

Because it's easy, because as a linguist I doubt I'll be collaborating with others so who cares if it looks funny, because it's great for dealing with large chunks of data, etc. I'm mainly thinking in terms of some kind of corpus linguistics, but again I don't really know.

Ah, this is interesting.

Topicalization
With regard to topicalization, I should point out that this sentence starts with one. A topicalizer simply introduces the subject you're intending to talk about. There are several syntactic forms in English, the simplest one of which is simply a noun: "Carrots, I hate 'em." Pascal has a "with" clause that functions as a topicalizer. Topicalizers can sometimes give a list of topics, at which point you see words like "for BLAH and BLAH, do BLAH". In Perl, there are various things that work as topicalizers.

That's exactly the sort of thing I was thinking about.

I have a lot of problems with the claim that functional programming languages "resemble natural languages." This sets me at odds with Paul Graham and Joel Spolsky, both of whom I regard as otherwise sensible people who are infatuated with Lisp. In particular, they seem to have deluded themselves by the natural language analogy.

The problem with that analogy is that functional languages do not resemble natural language — they resemble natural language parse trees. Certainly something akin to recursion happens whenever we use relative clauses or nominal phrases, and even more so in German or Greek where you can say things like the the deer hunting man. If, in fact, humans spoke in long, deeply nested sentences, the Lisp partisans would be right. But we don't. Pronouns and antecedents are examples of the very concepts of state and assignment that functional languages seek to avoid.

People who tout functional languages as resembling natural ones should spend more time staring at paragraphs, and less time staring at parse trees.

Because it's easy, because as a linguist I doubt I'll be collaborating with others so who cares if it looks funny, because it's great for dealing with large chunks of data, etc.

You're right -- those are all great reasons for a Linguist to use Perl. I thought you were going somewhere else with your comment.

But Perl is not a functional language, as you know.

And topicalization occurs in English so I'm not sure why you say you haven't learned any languages with topicalization.

It would be nonsense to call $_ a topicalizer in the sense presented in Wall's article, nor does $_ remotely map onto theme marking particles. $_ (unless there's a use of it that I'm not thinking of right now) would simply correspond to a pronoun. Correct me if I'm wrong here.

Same goes for @_ and all those other variables.

You probably have a better understanding of topicalization and theme marking particles, as my knowledge of them is dimly-remembered freshman-level class.

Incidentally, I just remembered that that XSLT script spawned one of the quips buried in my firm's bugzilla database: Ben: My code finally works! Molly: Does this mean you'll quit doing that Tourette's thing?

You're just biased. ;)

But Perl is not a functional language, as you know.

Yes, but. See Paul Graham's essay "Revenge of the Nerds":

If you look at these languages in order, Java, Perl, Python, you notice an interesting pattern. At least, you notice this pattern if you are a Lisp hacker. Each one is progressively more like Lisp. Python copies even features that many Lisp hackers consider to be mistakes. You could translate simple Lisp programs into Python line for line. It's 2002, and programming languages have almost caught up with 1958.

In the book Hackers and Painters, Graham appends Ruby to the list.

The problem I have with $_, @_ and many other variables and special symbols popular in languages like perl and Ruby is that there *isn't* any natural language correspondence.

If you take a ruby example like this:

@params['person']['filename'] = @params['person']['tmp_file'].original_filename.gsub(/[^a-zA-Z0-9.]/, '_')

You can read it relatively easily, but writing it takes a lot of experimentation -- do I use [ or . ? Do I need a ' or not? Do these symbols mean the same things in different contexts? (Compare the use of [ and ' in the first half to the use in the regular expression.)

The "this" operator that Java, C++, and PHP uses seems much more "natural" to me.

I think a good programming language is one where it is as easy to maintain applications as it is to create applications. Optimizing for shorter number of lines of code definitely makes code easier to maintain. Optimizing for readability (*not* the same as using natural language structures) also does.

What a language optimizes for is a good indicator of whether you'll enjoy working with it or not. In learning Ruby, I keep stumbling over "features" that are not only bad ideas, but make me doubt the entire enterprise. For example, anyone who's programmed in the last decade or two knows that optimizing for developer keystrokes is a very bad thing indeed, and so single-letter variable names have gone the way of corset stays and ball pullers. So when I stumble across this:

Sometimes creating arrays of words can be a pain, what with all the quotes and commas. Fortunately, there's a shortcut: %w does just what we want.

a = %w{ ant bee cat dog elk }

, I start to question the whole enterprise.

Another example, which gets to Sara's maintainability issue is this quote from the same document:

Ruby statement modifiers are a useful shortcut if the body of an if or while statement is just a single expression. Simply write the expression, followed by if or while and the condition. For example, here's a simple if statement.

if radiation > 3000
  puts "Danger, Will Robinson"
end

Here it is again, rewritten using a statement modifier.

puts "Danger, Will Robinson" if radiation > 3000

Perl does the same thing. The problem with this shortcut notation is that any subsequent modification to the body of the control structure will either require a rewrite of the control structure into the multi-line format, or will bite you.

Even in Java or C++, no developer I know is fond of using single-line control structures, and are more likely to write

if (someCondition()) {

     statement;

}

than the equivalent

if (someCondition()) 

    statement;

for the simple reason that adding a line later may break the logic. Heaven help you if you don't have an editor that auto-indents, or else you may end up with

if (someCondition())

     statement;

     statementIntendedToBeConditionalizedButIsnt;

I'm shocked that in the era of auto-completion, saving a pair of braces is considered important enough to add to a langauge definition.

I think we're gonna have to spin this thread off into a new blog, like The Jeffersons.

Anyway, ultimately I don't see any reason to suppose that modelling a computer language on natural language(s) makes it better. The two serve different purposes and maybe the language analogy is just that, an analogy which is admittedly seductive but also misguided.

For instance, is there really an equivalent to maintaining code in natural languages? I don't think so. Editing a document is not the same thing. Your word processor isn't going to throw an error if you punctuate incorrectly, and neither will most people. Nor is someone editing your writing going to have to get used to your writing/coding style in order to make sense of it. There is no such thing as writing an object oriented article, neither to my knowledge is there such a thing as writing inverted pyramid code. People and computers just aren't similar enough to make this analogy hold up.

On the other hand...

anyone who's programmed in the last decade or two knows that optimizing for developer keystrokes is a very bad thing indeed

Agreed.

a = %w{ ant bee cat dog elk }

Is that really such a bad idea? You've got things like that in perl all over the place and while admittedly I haven't had to read other people's code very often that would be the last offender I'd think of if you're talking about maintainability.

The problem (in terms of brevity) is when you have people making a variable for, say, the id of a mail client and they name it $mc. Or when they take a for loop and put it all on one line with fancy operators just to make themselves look 733t.

Or so it seems to me. I have no doubt you are both more experienced programmers. I am self taught after all.

The problem with this shortcut notation is that any subsequent modification to the body of the control structure will either require a rewrite of the control structure into the multi-line format, or will bite you.

That's a great point. I've heard a lot of bashing of perl for things like this and all I can say is, as Larry Wall constantly points out, Perl doesn't force you to have good practices, it's up to you. And from there I guess you take it or leave it. But I didn't realize Ruby takes after this philosophy so strongly. I can see that would be annoying considering what it's being used for these days.

Something just occurred to me. Maybe this sort of thing is endemic to collaborative, open source style design where programming languages are concerned. On the other hand something like Java could only be as strict as it is because it was developed within a company with a hierarchy etc.

Might be completely off base but it's a thought.

Maybe this sort of thing is endemic to collaborative, open source style design where programming languages are concerned.

This is an interesting point. Wouldn't open source projects actually lead to programming languages that are easier to maintain -- because you have a group of people with vastly different backgrounds maintaining the same piece of code? Or would the peer-review aspects of open source force you to have good practices?

As for the analogy between programming and natural languages, I think Perl Poetry is an amusing and slightly absurd example.

I was wondering if writers designed programming languages if that would make it better, however
both of my favorite techie essayists (Joel and Paul) started this thread about "natural languages" so I guess that theory is bust.

Personally I've always had my doubts about comparisons between programming languages and natural languages.

I think there'd be a lot less nonsense if the original developers of programming languages had used some other word for their creations -- "codes" perhaps. With "language" being the overloaded term it is, we get a lot of quasi-Whorfian nonsense from people who assume that what is true of one kind of "language" must be true of the other.

Well, it's not entirely our fault that we use "language" that way. Don't architects do the same?