GolfScript SyntaxSource is split into tokens. These tokens are words (letters or underscore followed by letters, numbers, and underscore), numbers, strings (either "...", or '...'), comments (# until newline), everything else is a single character token. The regular expression used is:
All variables when loaded are pushed on the stack except if that variable is a block it will be evaluated instead. So essentially interpreting GolfScript is just pushing or evaluating variables. This is why an interpreter is about 25 lines of ruby code.
However this language will not be able to do anything without some variables already initialized to some blocks that execute primitive functions. Most of the complexity in a GolfScript interpreter comes from defining this set of primitive functions. At the bare minimum functions such as integer add, divide, array concat, array to string, block execute, etc would be needed. From these the rest of the standard operators could be defined. However, the current implementation implements most everything in ruby for simplicity's sake.
It might be interesting to try and write an implementation using as few as built-in's as possible and defining everything else in GolfScript itself. However this would make little difference except making code run even slower. Also local variables should be added to the language to make defining your own functions easier.
Ruby is slow to start with so GolfScript is even slower. There is nothing innately slow about GolfScript. Except for the string evaluate method, everything could be statically compiled into C, and analysis could be done to remove most if not all stack use. I do not plan on making a more efficient interpreter, as the purpose of language is not numerical analysis, however if any feels like creating one, I would be delighted to use it.