Re: The top three big problems: Better Speech Reading
- From: Veli-Pekka Tätilä <vtatila@xxxxxxxxxxxxxxxxxxxx>
- To: programmingblind@xxxxxxxxxxxxx
- Date: Sun, 14 Oct 2007 01:09:14 +0300
Hi Andreas,
Many thoughts late at night:
I'd like to add one thing I personally miss greatly in current IDEs.
That is when reading someone else's code or my own code that is
syntactically correct, it could be read much smarter in speech than it
is currently read. This is provided that the screen reader, language
parser and Ide could co-operate a bit.
The problem is I get told each and every comma, parenthesis, semicolon
etc... even though most of them are evident by context. The same is true
of operators, we have generic prompts such as star, plus plus and
vertical line vertical line, in stead of using the vocabularity of the
language. I would also like the ability to navigate a statement in
syntactical units since speech normally reads the change in cursor
position. i.e. next operator, next operand, next argument, matching
paren or brace or howabout a top down, tree-like view of complex
expressions.
Last but not least, nested Perlish list processing or list
comprehensions in Python are suboptimal reading in speech, and the
parens always drive me nuts in Lisp. They should be read from the inside
out, in suitable chunks. Ruby, Apple Script and SQL are langs I like a
lot, as far as readability with speech goes.
As to how operators could be read, here are some initial thoughts in
table form, for Java and C like langs:
+ plus
- minus
* times
/ per
% modulo
++a pr-einc
--a pre-dec
a++ post-inc
a-- post-dec
.f f field
->f f field
.f() f
->f() f
(t) t cast
< less than
> greater than
<= at least
>= at most
== equals
!= differs
= is
op= op is
a?:c cond a ? true b : false c
! not
&& and
|| or
& bit and
| bit or
^ xor
~ negation
<< left shift
>> right shift
// c comment c
/*c*/ comment block c end
f{ block
} f end
{ bear block
a[x] a at x
x1,x2 comma op
t* pointer to t
t& ref to t
&i i's address OR address of i
*i deref i OR value of i
As for punctuation and parens, most simple non nested function calls and
most clauses requiring parens could have them omited quite well. The
same is true of commas in function arguments, a small pause would be
unambiguous enough in most such cases. Semicolons should not be read,
unless someone crams several statements on a single line. And even on a
for loop like:
for(int i = 0; i < 10; ++i)
WHich is read
for left paren int i equals 0 semi colon i less than ten semi colon plus
plus i right paren
the gist of it reduces to:
for int i 0 pause
i less than ten pause
preinc i pause
and later, end for
Another way to look at this would be to analyse how program code is read
in university books that are actually audio books for the blind. Most of
such experiences of mine have been pretty horrible. However, in high
school physics, in Finnish that is, there was a great reader who new the
math, read Greak letters well including their case, understood what he
read, and had a talent of partitioning a math formula into managable
chunks by intonation, pausing and various other cues. Now, if the gist
of such partitioning could be turned into a program applying heuristic
reading rules for program code, that would absolutely rock big time.
Here are my current rather basic omition rules for punctuation, too. I
haven't really thought these further, these are age old ideas of mine:
code prompt argument
a.f() a f void function, dot implied
a.f(a, b) a f a PAUSE b simple param list
if(cpmd) if cond parens implied by context
else if(cond) else if cond parens implied by context
else(cond) else cond parens implied by context
while(cond) while cond parens implied by context
for(exps) for exps parens implied by context
switch(expr) switch expr parens implied by context
(exp) op a parens exp op explicite parens: precedence
case label: case label colon implied by context
lab: statement label lab statement rare, so explicit
x1;<nl>x2; x1 PAUSE x2 statements pause delimited
x1; x2; <nl> x1 PAUSE x2 line emphasizes related statements
; nop has meaning as a no-op
for(x;y;z) for x PAUSE y PAUSE z statements implied by pauses
for(x : y) for x in y audible equivalent of colon
x<type> x of type advice taken from generics
a[j][k] a at j k for simple Expressions
[x1][x2] at [ROW] x1 [COL] x2 more explicit inddeces
{r1},{r2} row r1 row r2 {} no blocks in inits
Judjing by comments here the use of indentation alone does not transform
well into speech. is why many like Ruby and don't like Python. It is a
small thing for the sighted. but not for us. ANother thread you might
want to look into is one concerning how blind do code formatting. In
that thread various speech, braille and magnification users gave their
reading styles and code formatting recommendations for accessibility's
sake.
I threw around ideas of how to render programming languages better
aurally with a sighted coder friend of mine, whose probably the best
programmer I know. And one great idea he had about Lisp would be to omit
parens directly i.e. take constant breaks and map nesting level in
s-expressions to some attribute of the speech in stead. Such as notes of
a minor scale, where you could easily tell opening and closing parens by
pitch changes alone. LIsp statements would then form simple melodies.
Which left us joking that now that we have Perl Poetry we could have
Lisp songs, haha. But that idea could work, seriously. Pan position is
much harder to pinpoint exactly, too, and notes are often easier to hear
than raw frequencies. I don't have perfect pitch but like many hobby
musicians, as part of music theory studies, I had to learn to recognize
most intervals on the fly. That stuff is hard to forget, <grin>. I think
this would be worth investigating.
PS: Oh yes and in proprietry speech solutions, I would like the ability
to freely choose the SAPi 5 synth and its params. I hate to be limited
to someone else's view of what speech synth is best for me. I far prefer
formant over sample based and ORpheus and Dectalk to Eloquence for
intonation, but the point is that mileage may vary here, as they say in
usenet.
--
With kind regards Veli-Pekka Tätilä (vtatila@xxxxxxxxxxxxxxxxxxxx)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila
Andreas Stefik wrote:
> Hey folks, I'm working nowadays on writing tools that tightly
> integrate speech based audio into all sorts of areas in the compiler.
> Being a sighted user, however, I'm pretty naive about what the real
> needs and problems the blind programmer community has when interacting
> with programming environments. If you folks had to choose the top 3
> most vexing problems you have, in your own personal experience, when
> programming, what would they be? What about when you are trying to
> find bugs, what are the three biggest issues then?
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
Other related posts:
