Multithreaded applications are notoriously difficult to debug and if not done correctly can be easily outperformed by a single threaded application.
Maybe 5 years ago. Today we have things like Erlang and Stackless Python. Take your cue from languages that do it right, that's all you need to do to make multithreading accessible. Of course as long as you're working with archaic languages like C/C++, you're going to have to work with their limitations as well. I also heard that Intel was working some black magic on a future processor that would some how allow single-threaded applications to utilize multiple cores/processors without putting the burden of determining context locks on the developer.
They were. Not anymore. Intel finally seem to have embraced the ideas of VLIW, and are moving all those expensive operations to the compiler, to reduce the costs of CPU dies. So not much good news for BlitzMAX. If multithreading were done in Max, Microsoft's way of doing it is a pretty good model to follow to keep it simple.
Surely you jest? Microsofts way of doing it is only marginally better than stdC. Java, Erlang, Stackless Python, even Common Lisp all provide much, much cleaner and simpler ways of doing multithreading than the miserable BeginInvoke() bollocks you have to put up with in .Net. I still don't see why anyone would think you could code a game easier or better in Blitzmax compared to langauge "x".
Because of empirical experimentation. For the purpuse of making a game, compared to any other type of software, BlitzMAX provides pretty much the perfect balance or "acceptable usability" if you will, between an abstract easy to use language (mainly focusing on features relevant to games, that is none of the other things on my list that practically all "x" languages have) and a native performance-oriented compiler. And for a noob coder, Blitzmax would be very hard to grasp.
Compared to what? Seriously? And by "noob" coder do you mean someone entirely new to programming, or someone burdened with a couple of years of procedural indoctrination. Because if it's the former, and you're having a hard time understanding BlitzMAX, then maybe programming just isn't your thing. If it's the later, I'll cut you some slack because you're doing it wrong, and it'll click eventually. This is a true game language
Except for that annoying little fact that Torque isn't a language. It is at best a framework, albeit a poorly thought out one. If you're looking for a game framework to go along with you're game programming language, I hear Grey Alien is selling one. You might want to hurry tho' because he won't be for long. while Blitzmax is nothing else than a general purpose simplified OO programming language
Well I've programmed in a wide variety of programming languages over the last few decades, and to this day only a handful of them (of the top of my head AMOS/STOS, BlitzBasic/BlitzMAX, PureBasic and Dark Basic) are the only ones out of literally 1000's who have come with built-in drawing and collision detection functionality (which is only useful for games, and game-like applications) as part of the core language. So yeah. Games language. The point is that a programming language must come with a 3d module
And yet surprisingly few do. So I'm thinking your definition of programming language is slightly misaligned to the real world.