There have been many attempts to use Postscript's programming power to implement a fuller document-production environment. AFAIK they all fall short of TeX's line-fitting abilities.
The most basic is the typewriter emulator from the Postscript Tutorial (Blue Book), which is then extended in the later Reid books (the Green Book and Thinking In Postscript) to handle embedded control-codes for font changes. These ones operate by reinterpreting the program stream, so I often call them "protocol-prolog" style.
Another style is to implement a set of commands with short mnemonic names and implement the document in the RPN syntax. Examples include the Gonzo Tools, Practical Postscript. This is also the primary technique for designing the output for a postscript driver.
A hybrid of the above approaches is illustrated by Anastigmatix's tools which even implement the Knuth-Liang hyphenation algorithm.
Not as powerful as Anastigmatix's tools, but stealing as many of his ideas as I could, my own effort (disclosure: it's also my resume, nudge nudge.) includes a combination of the above approaches, with a set of mnemonic procedures and embedded control-codes (including arbitrary postscript code) in the strings which contain the text. But it's limited to ragged-right.
On the other end of the issue is capturing the drawing output as a flattened ps document. The traditional tool for this is still.ps (in some sense, still.ps is to Distiller what cfront was to a native C++ compiler, by supplementing and extending the existing programmability (the ps interpreter on the one hand, the c compiler on the other). not really going anywhere with this, but I find it interesting). With ghostscript's
sDEVICE=pdfwrite) still.ps is largely unnecessary nowadays, but it remains a goldmine of postscript programming idioms and style.