PERL Miscellaneous - Re: Perl Vs Python: Blind Folks

Author

Re: Perl Vs Python: Blind Folks

Veli-Pekka Tätilä

2006-12-21, 8:03 am

Hi Dan,
I won't cross-post to a group I don't read, so this one goes only in
comp.lang.perl.misc.

Dan Jacobson wrote:
> apparently python's dependence of formatting, indentation, etc. vs.
> perl's "(){};" etc. makes writing python programs perhaps very device
> dependent.
> perl can be written on a tiny tiny screen, and can withstand all kinds
> of users with various disabilities, etc.?

Lemme address small screensize and input device constraints first. I've
tried writing Python on a series 60 celphone lacking a querty keyboard and
it is no fun. Getting all of the punctuation out is tedious, the dictionary
cannot auto-compmlete stuff smartly and the display is extremely small. That
being said maybe a case-insensitive language with lots of English would be
easier to write with such a setup. I'd go so far to say, based on an
intuitive notion, that neither Perl nor Python is very well optimized for
tiny screens or keyboards in which special chars are hard to enter, though
arguably Perl does have source filtering.

What kind of disabilities and rationales did you have in mind, in
particular? I suppose you're thinking of sight-impaired folks with the
indentation comment. Being legally blind and part of the blind-programming
list, I'd like to comment on that a little.

But let's shatter a popular myth first. AS with choosing an OS,
accessibility is a big consideration but once that's out of the way the same
factors affect blind folks that affect the sighted. Many actually like the
GUI for mostly the same reasons. And not all CLi apps are speech friendly,
listen to ls -l with Festival. As far as languages go, asking in a Perl NG
probably yields pro Perl answers. I'm a casual Perl coder but know Perl,
Python and Ruby programmers in the blind-programming list.

First of all, the range of disabilities and assistive technology (AT) being
used can be very diverse. Some people use magnification, meaning a smaller
viewport, less detail and slower reading speed. For me, that's 7x
magnification for comfortable reading (10 pt font 96 DPI at 1024x768 17
inches) and I can only see a few chars at once. My reading speed magnified
is roughly one fourth of what it is with speech.

Most screen readers primarily output stuff using highly intelligible,
synthetic speech. Generally the screen reader program driving the synth
tracks the keybord focus, reads stuff left to right and is very generic
having little notion of context and using generic punctuation names and so
on. This means some major difficulties in programming in any language. My
normal listening speed is roughly 330 words per min having used speech for 8
years or so on a daily basis.

Lastly, there's braille. Fixed-width, typically 40 8-dot chars on a line
which you read left to right using your fingers. It's often the easiest
medium for parsing nested expressions, be they math or programming, and is
good for homing in at specific bits. However, scrolling, getting the big
picture and unicode chars can be problematic. I do have a braille display
but don't use it as much as I should.

And to make things more complex people can generaly use any combination of
the above three output media. I myself am using a curious mix of
magnification and speech. I use speech with no punctuation to get the big
picture and home in at bits of an expression with magnification. I tend to
cursor left or right in textual units like words within an expression.

Regarding language issues, let's deal with indentation first. AS a
magnification user who uses an editor with auto-indentation, I find that
keeping stuff aligned as in Python is something I do in any
block--structured language anyway. My pseudo-code also uses that kind of
indentation. Indentation makes it easier to tell apart blocks of code even
without magnification, as you can see the big shift in the left margin with
relative ease. ON the other hand the magnified view port is very small. IT
is easy to leave something accidentally on the left or right side of the
screen and then miss it producing a flurry of mystical compilation errors.

As a speech user, indentation can be a real problem. Not something you
wouldn't get used to but I've noticed that some beginning sight-impaired
Python programmers appear to have more issues on average than the sighted
would. The problem is that white space has no natural spoken representation
and it is easy to lose the layout in a speech stream.

The leading Windos screen reader Jaws has some audible presentation for
indentation but the one I'm using, the Dolphin Supernova which is popular in
the UK, does not. Most other readers don't including basic stuff like
Apple's Voice Over, Microsoft Narrator, and I think, the Linux reader Orca.
Emacs Speak probably has the best speech support for programming languages
but comparatively few users have access to it, as Windows assistive
technology has several years of head start in features, app-specific support
and foreign language speech (Finnish in my case), among other things.

As I'm using a combo of speech and magnification I like the BSD/Allman style
personally in Perl and many other langs.

while(<> )
{ # Comment if any.
# do stuff
} # while

The reason is the small viewport in magnification. As the braces line up it
is quick to check, by merely cursoring up and down, that a block includes
both braces, for example. Using the K&R style Would require you to use end
to get at the end of the line to check the left brace. Also, I tend to
comment ends of blocks because I don't use punctuation in speech so the
right brace wouldn't be spoken otherwise. I use magnification to check most
operators. Actually, I think Ruby, having an explicit end, would be closest
to my preferences, which are largely due to what kind of AT I use and how.
That is:

while line = gets
# do stuff
end

About indentation and Braille, usually it is not a problem. Though screen
readers need to convert all text to fixed-width format as Braille is
inherently fixed-width by nature. Well, provided that the screen reader and
braille display have been configured correctly, spaces and alignment are
pretty esy to track. Again, though, stuff that's indented a lot requires you
to scroll to see the rest of the line. By the way, formats are white-space
sensitive and thus present the same basic problems as indented code.

Large part of the kind of issues people have with speech is that it is
produced rather mechanically. That is the star or asterisk, if you will, is
always said star here, no matter hether it means indirection,
multiplication, bold in e-mail, bullet character, a star or something else.
So Perl's special variables don't sound nice at all "dollar back slash", but
again there's the english module.

Regardless of language regular expressions can be very complex to parse with
speech. I need to usually home in at white-space surrounded bits and cursor
them character by character keeping track of parens, braces and what-ever in
my head. Comments and the X modifier as well as modules thatllet you use
more English-like expressions do help. Some sort of APi for
programmatically building up a regexp by calling English-sounding methods
would be great.

Another problematic construct is stuff that's read right to left such as
long list processing statements. I write loads of them and typically
separate them by whitespace so that I can read each piece left to right.
Still a syntax that's closer to piping in the shell would be my cup of tea.

I should also mention that when you do use speech, how the code reads out is
an issue affecting aesthetics and intelligibility. Most speech synths use
case changes, underscores and whitespace to break words but when the synth
resorts to spelling depends. For example, Dolphin Orpheus says lcfirst,
rindex, , substr, dbmclose and chown as words (some Python built-ins have
similar issues). They should be spelled e.g. , rIndex, , subStr, dbmClose
and chOwn to have the intended effect. I'm especially suffering from POSIX
names that are read as words e.g. S_IRWXG be damned, <smile>. Most object
oriented modules have English-sounding method names, though there are
exceptions.

These are not pure language issues but how the tools of the language work
with AT like screen readers affect matters, too. The control hierarchy,
relations, text, type and state should be programmatically accessible from
3rd party apps to make apps usable with speech and braille and make focus
tracking work with magnification. Python built-in docs aren't very
structured in terms of textually navigable units like HTML headings and
links, which screen readers use as navigation landmarks. Similarly any
language utilities currently written in TK are inaccessible, until Active
Accessibility support is added to TK itself. Unfortunately, the PPM utility
in Active State Perl is now graphical and TK-based. I gave plenty of
usability feedback but the worst issues can only be fixed in TK itself. If
it worked with my screen reader, I'd take the PPM GUI over the PPM CLI any
day. Though the PPM CLI is one of my favorite command-lien utilities, I like
its prompts as a speech user.

Another cconsideration are the GUis visually impaired people are producing.
They should be accessible to screen readers to be useful. TK is out as I
said. Fortunately Perl has Win32::GUI and Python WX Widgets both of which
are accessible, I think.

Wel, hope this gives you a detailed enough picture. I've written on
accessibility before, too. Links to Google:
Perl debugger with speech: http://tinyurl.com/sczrf
Python access issues: http://tinyurl.com/vmwkr

--
With kind regards Veli-Pekka Tätilä (vtatila@mail.student.oulu.fi)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/

zentara

2006-12-22, 8:02 am

On Thu, 21 Dec 2006 15:07:42 +0200, "Veli-Pekka Tätilä"
<vtatila@mail.student.oulu.fi> wrote:

>Another cconsideration are the GUis visually impaired people are producing.
>They should be accessible to screen readers to be useful. TK is out as I
>said. Fortunately Perl has Win32::GUI and Python WX Widgets both of which
>are accessible, I think.

You didn't mention Gtk2's ATK (Accessability ToolKit).

I havn't done anything with it myself, but it is described at
http://developer.gnome.org/projects/gap/

Perl's Gtk2 port contains accesability to the ATK library.

--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html

Veli-Pekka Tätilä

2006-12-23, 8:02 am

zentara wrote:
> On Thu, 21 Dec 2006 15:07:42 +0200, "Veli-Pekka Tätilä"
> <vtatila@mail.student.oulu.fi> wrote:
> You didn't mention Gtk2's ATK (Accessability ToolKit).
> Perl's Gtk2 port contains accesability to the ATK library.
A good point, that's the choice you should use in any Unix-like OS. I'm a
Windows user because of various music apps and softsynths. I've found that
the WIndows GTK+ port is not accessible with the screen readers here so
that's why I didn't mention it. I should have either mentioned my Win32
background or taken a wider view. I wonder what's accessible in OS X using
Perl, by the way? GTK+ is X based and neither X nor classic is accessible to
VoiceOver. So can you write Cocoa apps in Perl?

Aditionally, only the title bars speak in GTK+ apps written in Cygwin. I'm
writing just such an app as an exercise in C and POSIX, and was disappointed
to notice that the accessibility is so poor I'll have to rely on Windows
magnification to use the app. Guess I'll do a rewrite with Perl and
Win32::GUI, isolating the GUI specifics.

--
With kind regards Veli-Pekka Tätilä (vtatila@mail.student.oulu.fi)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/

Sherm Pendley

2006-12-23, 10:00 pm

"Veli-Pekka Tätilä" <vtatila@mail.student.oulu.fi> writes:

> So can you write Cocoa apps in Perl?

Yes, you can. :-)

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

Sponsored Links