crazy programming language thoughts

[Ryan Lowe]

disclaimer:
this is a little out-there, primarily a thought excersise for myself. it
probably belongs in group on programming language theory. but python got me
thinking about this, so here it is. and dont worry, its NOT a change
proposal.

one of the things i love about python is its use of the actual words
or/and/not/is/in, where other languages would use symbols ||/&&/?!@#$%, what
have you. the symbols dont save you much typing (especially if you count the
shift key), but are merely something extra to learn and remember. i also
like how python did away with the unneccesary parentheses in for/if/while
statements. soooo ive been toying with the idea of getting rid of parens in
functions too (ive just been reading the ruby tut and noticed parens are
optional in some cases which is cool, but trust me this is different)

the basic concept would be to use identifying words in front of the
arguments to determine their identity as well as making the function call
read more like an english phrase. for instance, take the simple python
statement:

>>> vtext.replace('a', 'b')

wouldnt it be nicer (more english-like at least) to say:

>>> replace 'a' with 'b' in vtext

since the arguments have an identifying word (with, b) (in, vtext), the
order isnt important (other than the first 'anchor' word(s)), so we could
instead have said:

>>> replace 'a' in vtext with 'b'

or

>>> replace in vtext 'a' with 'b'

ignoring that the last version is a little awkward to say, the advantage is
immediate understandability; each parameter's contribution is explicitly
stated so you dont have to guess or look up what each arg of a many-arg
function does. of course, you could forget what words go in front of the
args (e.g. was it 'in vtext' or 'from vtext'?), but since its english-like i
think less so. plus an editor could give you hints like many do now.

you may be thinking about keyword inflation. however, the parser would
consider the whole set of words together, so the 'in' in the above wouldnt
be bound to the meaning it has in a for statement. worst case scenario, a
naming convention like the v in front of variable names could be used to aid
parsing, but i think it may be possible to disambiguate without such a
convention.

i just want to say that i know i saw a similar idea in another language, a
few years ago, but damned if i remember where or what language. i guess the
language didnt make it:( but if anyone knows a language like this, PLEASE
let me know.

anyway, this is all well and good for this simple example, but lets see how
it scales up. once you get familiar with finctions and dot syntax, you
probably started chaining them together. it saves time and space and after
not so long it becomes pretty easy to write and understand something like
this:

>>> v = '/n'.join(file('file.txt').readlines()).lower().split('.')

but think back to when all this stuff was new. you probably would have
written:

>>> f = file('file.txt')
>>> v = f. readlines()
>>> v = '\n'.join(v)
>>> v = v.lower()
>>> v = v.split('.')

it may be a little clearer, especially to a beginner, but its not nearly as
convenient. now take a look at this:

>>> v = read lines from 'file.txt'; join it with '\n'; lower it; split it at
'.'

i showed this to a couple non-programmers, and they fould it much easier to
interpret than the first way (i didnt show them the second way). here i do
introduce a new keyword 'it' which you can probably guess contains the
return value of the statement to the left of the semicolon. you could add a
'them' keyword for aggregates (as in the join part) if you are a grammar
stickler.

ill stop here before i put people completely to sleep. im curious what
people think about this. im not concerned with 'minor' problems like the
speed of a parser that could handle this. id like instead to hear comments,
concerns, reguarding the theory. id especially like any links people might
know about interesting experimental programming languages.