Beautiful Code [79]
The most natural way to design the system to leverage both speech options was to first implement a speech server that abstracted away the distinction between the two output solutions. The speech server abstraction has withstood the test of time well; I was able to add support for the IBM ViaVoice engine later, in 1999. Moreover, the simplicity of the client/server API has enabled open source programmers to implement speech servers for other speech engines.
Emacspeak speech servers are implemented in the TCL language. The speech server for the DECTalk Express communicated with the hardware synthesizer over a serial line. As an example, the command to speak a string of text was a proc that took a string argument and wrote it to the serial device. A simplified version of this looks like:
proc tts_say {text} {puts -nonewline $tts(write) "$text"}
The speech server for the software DECTalk implemented an equivalent, simplified tts_say version that looks like:
proc say {text} {_say "$text"}
where _say calls the underlying C implementation provided by the DECTalk software.
The net result of this design was to create separate speech servers for each available engine, where each speech server was a simple script that invoked TCL's default readeval-print loop after loading in the relevant definitions. The client/server API therefore came down to the client (Emacspeak) launching the appropriate speech server, caching this connection, and invoking server commands by issuing appropriate procedure calls over this connection.
Notice that so far I have said nothing explicit about how this client/server connection was opened; this late-binding proved beneficial later when it came to making Emacspeak network-aware. Thus, the initial implementation worked by the Emacspeak client communicating to the speech server using stdio. Later, making this client/server communication go over the network required the addition of a few lines of code that opened a server socket and connected stdin/stdout to the resulting connection.
Thus, designing a clean client/server abstraction, and relying on the power of Unix I/O, has made it trivial to later run Emacspeak on a remote machine and have it connect back to a speech server running on a local client. This enables me to run Emacspeak inside screen on my work machine, and access this running session from anywhere in the world. Upon connecting, I have the remote Emacspeak session connect to a speech server on my laptop, the audio equivalent of setting up X to use a remote display.
Code in Motion > On Being "Bookish"
32. Code in Motion
Laura Wingerd and Christopher Seiwald
The main point is that every successful piece of software has an extended life in which it is worked on by a succession of programmers and designers….
Bjarne Stroustrup
Early in the planning of this book, greg wilson asked contributors whether Beautiful Code was an apt title. "Much of what you're going to discuss is software design and architecture, rather than code per se," he wrote us.
But this chapter is about the code. It's not about what the code does, nor is it about how beautifully it does it. Instead, this chapter is about how the code looks: specifically, how certain human-visible traits of coding make serial collaboration possible. It's about the beauty of "code in motion."
What you're about to read is borrowed largely from Christopher Seiwald's article, "The Seven Pillars of Pretty Code."[*] In a nutshell, the Seven Pillars are:
[*] The article is available on the Perforce web site: http://www.perforce.com/perforce/papers/prettycode.html
Being "bookish"
Making alike look alike
Overcoming indentation
Disentangling code blocks
Commenting code blocks
Decluttering
Blending in with existing style
While these may sound like