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

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

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

With kind regards Veli-Pekka Tätilä (vtatila@xxxxxxxxxxxxxxxxxxxx)
Accessibility, game music, synthesizers and programming:

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 

Other related posts: