It's possible that PB has better errors, but I'd not count on it.  Most programming languages give really cryptic messages for the obvious stuff.  Perhaps BGT is bad in this way, but I don't think PB or any other language is going to be as good as what you want.  Doing error messages is unbelievably hard.

@orin, the best way you can program memory train in PB is by following the following instructions. In this post, I'll detail a little on the code that you need:
1. Open a screen; keyboard input is not available without doing this (unless you wish to use the windows API?):
Procedure OpenAScreen()
If OpenScreen(#pb_ignore, #pb_ignore, 32, "Title Here")
; code
EndIf
EndProcedure
or
Procedure OpenAScreen()
If OpenScreen(width, height, depth, title)
; code
EndIf
EndProcedure
Or Even:
Procedure OpenAScreen()
If OpenScreen(width, height, depth, title, FlipMode, RefreshRate)
; code
EndIf
EndProcedure
2. Initialize the keyboard:
InitKeyboard()
3. Load the sounds into memory:
LoadSound (0, soundfilename)
LoadSound (1, soundfilename)
LoadSound (2, soundfilename)
; and the rest of your sounds.
4. Create the main menu. I'm not going to go into depth about this; you will need to create your own method of menu creation yourself. However, in PB, in SR and DMPA, our menus go like this:
            Procedure SoftwareUpdatesMenu ()
              choice = 0
              TTSStop()
              TTSSpeak ("Software Updates Menu. Use the up and down arrow keys to navigate this menu; press enter to modify a setting, or activate an option. Select 'cancel' to cancel this process.")
Repeat
ExamineKeyboard()
    If keyboardpressed(#PB_Key_Down)
      PlaySound(1)
      choice = choice +1
      suvoice ()
    EndIf
    If keyboardpressed(#PB_Key_Up)
      choice = choice -1
      PlaySound(1)
      suvoice ()
    EndIf
    If keyboardpressed(#PB_Key_Return)
      PlaySound(2)
      If choice = 1
        AutomaticCheckForUpdatesChange ()
        TTSStop()
        TTSSpeak (cfumethod)
      EndIf
      If choice = 2
checkforupdates ()
EndIf
    EndIf
    Delay(5)
          FlipBuffers()
  ForEver
EndProcedure
I'm of course not going to reveal the checkforupdates() procedure to you, but the basic method of creating menus in SR and DMPA for Danny and I is:
Create the original menu procedure. Once that's done, create any additional procedures the procedure calls, and then create a procedure that follows this format:
Procedure suvoice()
    TTSStop()
  If choice < 0
    choice = 1
  EndIf
  If choice = 0
    choice = 1
  EndIf
  If choice > 2
    choice = 2
  EndIf
  If choice = 1
    TTSSpeak ("Check for Updates Method: " + cfumethod)
  ElseIf choice = 2
    TTSSpeak ("Check for Updates Now")
    EndIf
  EndProcedure
I've revealed to you as much code as I can to the audiogames.net forum. Now, change that procedue, and mold it into your own. Read those two procedures I have revealed to you, and then, without leaching off of them (None of you!), mold it in your mind how it should look. Remember that before coding, always make a design of what the program should look like, either mentally, or on some form of method you use to write it down. Never jump directly into code without a design specification first.

There is a library for it, called PureTTS. TTSSpeak is a function in that library. I can host the library if you wish. And yes, you can use it in the demo of the product.

Hmm. PureTTS is good for those just wanting to make it on Windows, but I have the BGT game for that. I wonder if there is a library that is universal so that I can compile one on Windows and it'll use Sapi, compile it on the Mac and use the System Voice, and I could perhaps ask Robjoy to compile it in Linux to see if maybe I could get it working on Linux as well. That'd be awesome in itself to have a little audiogame on Linux, which has next to no audiogames. While I may prefer the syntax of PB, I also want the ability for my games to be cross platform as well. One option I could try is to make wav files for the speech, but I've got a score variable in the BGT game which Sapi speaks when it changes, so that wouldn't help in that regard.

I do not believe that Universal Speech works on Linux but could be wrong.  Accessible_output2 is the only thing I' aware of that works everywhere, and I have a feeling Linux isn't well tested if at all.  This package will not help a Purebasic programmer.
On Mac, you need to make calls directly to Voiceover via applescript or, in Yosemite javascript.  This can probably be done via Objective-c calls, but the sequence isn't trivial.
On Linux, the synth is the least of your problems.  I'd not worry about Linux for now.  I've heard that, at most, it's 10% of blind people.  Which is fine and good, except that really it's 10% of blind people across more than 10 distros.  The problem here is that binary distributions usually requires compiling on all of them, sometimes requires manual installation of dependencies, etc.  Linux is built around building your own software, not easily installing pre-built packages from others.  Linux is also built around the GPL; it's quite possible that if you use the wrong things, you'll have to open source your application.  I'm not an expert in Linux licensing, and it's possible that the kernel at least has some exceptions for commercial software, but it is a controversial point at best.