I can understand why you'd say poorly designed, because the tradition it comes out of is so austere. But "terribly implemented"? That detracts from what you're saying. The thing achieves performance everybody else dreams of.

No doubt its error handling leaves a lot to be desired, but single-character names are a different matter. That's part of the APL style, and it's a mistake to reject it out of hand. The trouble is that nearly everybody does, because it's so beyond the pale.

Edit: Perhaps I should explain what I mean about the APL style.

Languages in this style are not "unreadable"; rather, they trade lexical readability for whole-program readability. Their emphasis is not on names, but on operators; specifically, operator composition. Their advantage is the astonishingly high-level power of their operator strings—sequences of composed operators, each of which passes its output to the next, like Unix pipes.

After a while, typical operator strings become recognizable as idioms, making them leap out at the reader. This allows one to comprehend quickly what would take many lines of code in most other languages. True, each of those many lines would be more lexically "readable" in the sense that you could grok its individual tokens more easily. But that's not how you comprehend what a program is doing. To do that requires grokking the intent of a bunch of lines together. In other words, program intelligibility is not primarily a matter of token readability but of whole-program comprehension. We're just so used to one way of doing it that we reject all others as "unreadable". We forget that variable and function names are not an end in themselves, but a means to an end. APL-based languages have a different means to that end.

If APL-style programs were to use long expressive names like other languages, the shape of their operator strings—the most important thing—would be obscured, and you would lose comprehensibility rather than gain it. The role that names play in such programs is different. They are placeholders. Like colored beads, they occupy certain positions in the operator strings and demarcate what the code is doing. If these names were even half as long as what you use in conventional languages, they would overwhelm the code so much that it would consist of nothing but names with a few operators scattered here and there. The program's structure would then be less accessible.

Another way of saying this is that names are so much shorter because everything is so much shorter, which is what makes the operator-oriented style so powerful.

It's true that such a language is symbolic, even cryptic, compared to most. But that is a bad reason to dismiss it, especially before one's eyes have adjusted. All programming languages are symbolic and cryptic before one has learned any. The reason why programmers take for granted that conventional languages are more "readable" is that these languages are related to each other and we all know one of them. We are like Spanish speakers saying that French is more readable than Russian. Since we all (to extend the analogy) know at least one Latin language, we take this view for granted when it's really just relative and—if one wants to push the point—false.

Now where are beagle3 and silentbicycle to back me up.