Wow.. it's been awhile, but the same old arguments about OO and same misconceptions still exist here..
Here's the unpopular truth:
Over here in the states, universities offer Java, C# and C++ as 101-level classes. "Basic" as you know it is not even a skill that is being offered to teach future programmers. Nor is offered to those that intend to just use it casually (such as those learning it just to get a math credit against their major). From my understanding, some high school curriculums now utilize Python to teach their elective programming classes.
So, the misconception that beginners can't learn OO syntaxes has already been largely disproven. At the risk of offending some of you, I'd say the issue is more along the lines of intimidation, fear and complacency. It's different, it's scary, you have no desire to learn something new, even if it's a skill you will easily carry over to the other scary languages. Therefore it's bad. If 1/2 the energy complaining about the evils of OO were applied toward actually learning about it, you'd probably see how well its model-based ideas fits into the paradigm of simulation programming (which is really what most games are).
From a non-selfish perspective, why would Mark want to pursue a demographic that, while obviously very vocal, is going to be in the very small minority in the future?
To further support a point John Galt has been making, object oriented approach has nothing to do with the syntax anyway. Just because you have a "class" keyword, doesn't mean you are developing an object oriented program. You wouldn't believe the number of applicant's code-samples that come across my desk that, while written in C#, a supposed OO language, are very procedural in nature.
Someone mentioned something about standards. They do exist to a large degree in object oriented design. Usually they are referred to as "patterns and best practice". And again, these are markers of design, rather than syntax. So, you can apply these standards to Blitz as well as C# or Java.
When writing chunks of reuable code, BlitzMax lets you use modules which are elegant and as easy to use as could be. With C# you really have to be using class libraries, as far as I can see, and they're just not as elegant as modules. Again, it's a trivial point, but one which irritates me.
Assuming you're referring to "modules" as just chunks of code you can call from anywhere and act like a singleton, you're probably not familiar with static classes, methods and members in C#, which accomplishes exactly that. Incidentally, this is the easiest way to make a very procedural c# program.
The C# Maths class uses radians instead of degrees, and while conversion and/or writing your own isn't difficult, it's an irritation, and easy to forget when you're coding large chunks of code fast as I am prone to do.
But if you can easily re-write the library to utilize your desired output, you only have to do that once, save off the .dll as a class library, and use it in all future projects instead of the one in the .Net framework.
Neither BlitzMax nor C# let me directly interface with external C++ classes, but because BlitzMax has GCC tucked discretely into the build process, wrapping them for use with BlitzMax is pretty easy, and because it uses the module system again, very elegant. I can't say the same about writing a managed wrapper for C#.
You can call external and "unsafe" code in c# through the extern keyword and unsafe code blocks. The .Net framework will wrap the call for you as well.
If you want to in-line C++ source, you can have C++, VB, IronPython, or any other .net language intermixed within a Visual studio solution. They just need to be in separate projects since they are compiled to IL at that level.
I have been using BlitzMax for, what, two years? And I still think memory management is stupid.
The lack of strict memory management in native code is one of the reasons why Vista has been such a burden for so many people. Contrary to what many think, the enormous amount of incompatibilities encountered on Vista have more to do with the programs they are running than the operating system itself. The problem being that these rogue programs make "insecure" calls that either cause the application to act like a system administrator and do things the application shouldn't be doing (this is why it's so easy to target windows for viruses), or attempt to access memory outside of it's allocated memory space. Thus the annoying warning message pop-ups.
Memory management ensures that the application does not violate boundaries, and if implemented system-wide will make O.S. incredibly stable. XP implemented some of this already in it's OS, and as I eluded to above, even more so in Vista. But OS-level implementation doesn't go far enough to protect memory consumption while an application is actually executing. Sure, you could manage this yourself, but a managed runtime environment like .net or java is going to know more about the current state of memory and the best time to dispose of your out-of-scope items than you will. Plus, if you take advantage of the abstract nature of this, your applications will benefit from improvements Sun or Microsoft makes to the disposal process without ever having to re-code for it. Same can be said for Marks implementation within BMax (though in his case, you'd have to at least re-compile since there's no JIT)
Never read this Code Complete book everyone is talking about. Will have to look it up and see whether or not it's worth having. I'm pretty picky about programming books, since a lot of them seem to contradict each other.
It's a code-agnostic look into software design. I agree alot of books contradict each other. Code complete certainly has it's opinions, and I don't agree 100% with all of them either. But at least it gives good reasons for the opinions it presents, which, right or wrong allow you to judge that for yourself. I'd say a vast majority of the book is pretty close to the mark.
I would like to see variables, functions etc etc to be case sensitive
Case sensitivity at the compiler level is useful if the IDE doesn't auto-correct the casing of your declared variables/methods. Typically, case sensitivity is enforced to eliminate a compiler pass to "normalize" the references in the source code. As a side effect, it makes the code more readable and consistent by enforcing each reference to look the same. Anyone that's worked on a mult-programmer application, where there's no consistent set of programming standards quickly grows to appreciate the case-sensitivity enforcement of most compilers.
There are also some issues with case-insensitivity when unicode enters the mix. I'm indifferent until it bites me, but there is a reason why case sensitivity exists in the first place.
Hey, here's an idea... maybe Mark could contact Microsoft and see if there's a way to "port" BMAX into the 360/XNA stuff? Would be cool to have portability from PCs/Macs and also to consoles :)
Not entirely impossible. First step would be to make BMAX compile to IL rather than native code. From there, wrap the XNA framework calls within BMAX's equivalent commands and make sure the application doesn't fall outside of the constraints of an XNA project (i.e. do not reference any libraries the XBOX's JIT doesn't have access to, such as the standard Windows UI/Forms libraries).
Heck, if it targetted .Net/XNA and Java/LWJGL and could emit both assemblies and java byte code, it would be worth it's weight in gold from a platform independence standpoint.
XNA targets C# mostly because the team within Microsoft that's responsible for it is very small. From my understanding, using any of the .Net languages is plausible if you're very careful about the libraries you reference.
Here's the unpopular truth:
Over here in the states, universities offer Java, C# and C++ as 101-level classes. "Basic" as you know it is not even a skill that is being offered to teach future programmers. Nor is offered to those that intend to just use it casually (such as those learning it just to get a math credit against their major). From my understanding, some high school curriculums now utilize Python to teach their elective programming classes.
So, the misconception that beginners can't learn OO syntaxes has already been largely disproven. At the risk of offending some of you, I'd say the issue is more along the lines of intimidation, fear and complacency. It's different, it's scary, you have no desire to learn something new, even if it's a skill you will easily carry over to the other scary languages. Therefore it's bad. If 1/2 the energy complaining about the evils of OO were applied toward actually learning about it, you'd probably see how well its model-based ideas fits into the paradigm of simulation programming (which is really what most games are).
From a non-selfish perspective, why would Mark want to pursue a demographic that, while obviously very vocal, is going to be in the very small minority in the future?
To further support a point John Galt has been making, object oriented approach has nothing to do with the syntax anyway. Just because you have a "class" keyword, doesn't mean you are developing an object oriented program. You wouldn't believe the number of applicant's code-samples that come across my desk that, while written in C#, a supposed OO language, are very procedural in nature.
Someone mentioned something about standards. They do exist to a large degree in object oriented design. Usually they are referred to as "patterns and best practice". And again, these are markers of design, rather than syntax. So, you can apply these standards to Blitz as well as C# or Java.
When writing chunks of reuable code, BlitzMax lets you use modules which are elegant and as easy to use as could be. With C# you really have to be using class libraries, as far as I can see, and they're just not as elegant as modules. Again, it's a trivial point, but one which irritates me.
Assuming you're referring to "modules" as just chunks of code you can call from anywhere and act like a singleton, you're probably not familiar with static classes, methods and members in C#, which accomplishes exactly that. Incidentally, this is the easiest way to make a very procedural c# program.
The C# Maths class uses radians instead of degrees, and while conversion and/or writing your own isn't difficult, it's an irritation, and easy to forget when you're coding large chunks of code fast as I am prone to do.
But if you can easily re-write the library to utilize your desired output, you only have to do that once, save off the .dll as a class library, and use it in all future projects instead of the one in the .Net framework.
Neither BlitzMax nor C# let me directly interface with external C++ classes, but because BlitzMax has GCC tucked discretely into the build process, wrapping them for use with BlitzMax is pretty easy, and because it uses the module system again, very elegant. I can't say the same about writing a managed wrapper for C#.
You can call external and "unsafe" code in c# through the extern keyword and unsafe code blocks. The .Net framework will wrap the call for you as well.
If you want to in-line C++ source, you can have C++, VB, IronPython, or any other .net language intermixed within a Visual studio solution. They just need to be in separate projects since they are compiled to IL at that level.
I have been using BlitzMax for, what, two years? And I still think memory management is stupid.
The lack of strict memory management in native code is one of the reasons why Vista has been such a burden for so many people. Contrary to what many think, the enormous amount of incompatibilities encountered on Vista have more to do with the programs they are running than the operating system itself. The problem being that these rogue programs make "insecure" calls that either cause the application to act like a system administrator and do things the application shouldn't be doing (this is why it's so easy to target windows for viruses), or attempt to access memory outside of it's allocated memory space. Thus the annoying warning message pop-ups.
Memory management ensures that the application does not violate boundaries, and if implemented system-wide will make O.S. incredibly stable. XP implemented some of this already in it's OS, and as I eluded to above, even more so in Vista. But OS-level implementation doesn't go far enough to protect memory consumption while an application is actually executing. Sure, you could manage this yourself, but a managed runtime environment like .net or java is going to know more about the current state of memory and the best time to dispose of your out-of-scope items than you will. Plus, if you take advantage of the abstract nature of this, your applications will benefit from improvements Sun or Microsoft makes to the disposal process without ever having to re-code for it. Same can be said for Marks implementation within BMax (though in his case, you'd have to at least re-compile since there's no JIT)
Never read this Code Complete book everyone is talking about. Will have to look it up and see whether or not it's worth having. I'm pretty picky about programming books, since a lot of them seem to contradict each other.
It's a code-agnostic look into software design. I agree alot of books contradict each other. Code complete certainly has it's opinions, and I don't agree 100% with all of them either. But at least it gives good reasons for the opinions it presents, which, right or wrong allow you to judge that for yourself. I'd say a vast majority of the book is pretty close to the mark.
I would like to see variables, functions etc etc to be case sensitive
Case sensitivity at the compiler level is useful if the IDE doesn't auto-correct the casing of your declared variables/methods. Typically, case sensitivity is enforced to eliminate a compiler pass to "normalize" the references in the source code. As a side effect, it makes the code more readable and consistent by enforcing each reference to look the same. Anyone that's worked on a mult-programmer application, where there's no consistent set of programming standards quickly grows to appreciate the case-sensitivity enforcement of most compilers.
There are also some issues with case-insensitivity when unicode enters the mix. I'm indifferent until it bites me, but there is a reason why case sensitivity exists in the first place.
Hey, here's an idea... maybe Mark could contact Microsoft and see if there's a way to "port" BMAX into the 360/XNA stuff? Would be cool to have portability from PCs/Macs and also to consoles :)
Not entirely impossible. First step would be to make BMAX compile to IL rather than native code. From there, wrap the XNA framework calls within BMAX's equivalent commands and make sure the application doesn't fall outside of the constraints of an XNA project (i.e. do not reference any libraries the XBOX's JIT doesn't have access to, such as the standard Windows UI/Forms libraries).
Heck, if it targetted .Net/XNA and Java/LWJGL and could emit both assemblies and java byte code, it would be worth it's weight in gold from a platform independence standpoint.
XNA targets C# mostly because the team within Microsoft that's responsible for it is very small. From my understanding, using any of the .Net languages is plausible if you're very careful about the libraries you reference.