From: "M. Edward (Ed) Borasky" <znmeb@...>
Date: 2008-04-28T02:19:44+09:00
Subject: Re: Ruby & Artificial Intelligence

Arlen Cuss wrote:
> Hi,
> 
> On Fri, Apr 25, 2008 at 2:53 PM, Pranjal Jain <pranjal.jain123@gmail.com>
> wrote:
> 
>> Hi
>>
>> Suppose I am having a sentence like this
>>
>> "Navigate to the application page. Enter the user field with
>> credentials"
>> When I give this sentence to  the computer, it should be able to
>> understand the key words like "Enter", "User field", "Credentials".
>> It should be able to make a priority on "Enter & Navigation",
>>
>> then it should write the user name & password in desired field.
> 
> 
> 
> I have a good feeling that what you're asking for is nearly impossible - and
> at the least, not Ruby specific. You'll need to research this in a community
> more geared towards language analysis/AI/etc... but while I was stumbling on
> the 'net, I found this:
> 
> http://web.media.mit.edu/~dustin/rubyai.html
> 
> Hope it helps you in some way.
> 
> Cheers,
> Arlen
> 

Well ... programming in "natural" languages has been a dream for 
decades. Heck, that was one of the things that was supposedly attractive 
about COBOL (and its predecessor, COMTRAN). You can probably still find 
code like

SUBTRACT TAXES FROM GROSS_INCOME GIVING NET_INCOME

in the COBOL code base.

Mabye that's why it irks me so when I see Rails code like

class Order < ActiveRecord::Base
   has_many :line_items
end

Now, if it were "An order has many line items," that would be natural. 
But it's the mix of Ruby code and English (class <Class-name starting 
with a *capital* letter>, <two English words separated by an underscore> 
<two English words separated by an underscore *and* preceded by a 
colon>), etc. It's un-natural. I'd rather have straight code.

Rake is another example ... file tasks are named with strings and other 
tasks are named with symbols. The whole "when do I use a symbol and when 
do I use an ordinary identifier" conundrum is difficult for me.

The point is that if you're writing code for other programmers to read, 
you can assume that they know both the programming language and "the" 
natural language. And an IDE for teams of these programmers should 
introduce another common language -- coding standards, project 
structure, version control, lexical and syntactic help, testing 
frameworks, debugging, etc.

I think it's a mistake to try to design languages and programs in a way 
that *in theory* attempts to make the code readable to non-programmers. 
First of all, non-programmers rarely, if ever, read code. They care 
about what the software *does*, not what's under the hood. And second, 
it makes the job of the programmer more difficult.