crazy programming language thoughts

[Bob Gailer]

At 12:39 AM 8/22/2003 +0000, Ryan Lowe wrote:

>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.

Those of us who programmed in APL got great benefit from symbols. Not only 
did they save a LOT of typing they made it real easy to compose and read 
expressions. Consider (assuming A is a matrix of numbers):

(+/A)%@A

(in the APL font the % is a divide symbol (a - overstruck with a :) and the 
@ is the Greek letter rho.

The pythonic equivalent is (Assuming A is a sequence of numbers):

reduce(operator.add, A) / len(A)

>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).

Reminds me of showing others programs in languages they did not know. 
They'd say "I can't read that." Duh. And COBOL was famous for its verbose 
use of English to make programming easier.

>here i do introduce a new keyword 'it'

new?? I assume you are unfamiliar with Apple's hypercard.

>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.
>
>
>--
>http://mail.python.org/mailman/listinfo/python-list
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.506 / Virus Database: 303 - Release Date: 8/1/2003

Bob Gailer
bgailer at alum.rpi.edu
303 442 2625
-------------- next part --------------

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.506 / Virus Database: 303 - Release Date: 8/1/2003