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.
No, I wasn't talking about just chunks of code you can call from anywhere and act like a singleton, and I am aware of static classes. Modules could contain a static class, but they're much, much more than that. They can be as little as a few procedural functions or they can contain a few hundred classes. They can contain BlitzMax code, C Code, C++ code or a combination of all of the above. They have their own namespace too. They're much more akin to a class library.
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.
Sure, but as as I already said, I just don't like class modules. I find it messy having DLL's all over the place, and there's no forced structure about them. I can put the source to a class module anywhere I like, and I'm lazy, so I probably will. When I come to back up all my class modules, where are they? All over the hard drive, of course, because I'm just that disorganized.
BlitzMax forces me to keep all my modules in one place, which I guess could be viewed as restrictive, but I find it a helpful restriction because it stops me from being stupid and lazy, which I am prone to be. I guess it's akin to SuperStrict forcing me to explicitly declare variables. It saves me from myself.
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.
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 know how it's done, I just don't think it's as elegant as it is with BlitzMax. Again, this may be because BlitzMax has modules and you can encompass all your external code in one of those.
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).
I completely agree. It's obvious from a quick read of the BlitzMax beginners forum that complete beginners are almost always happy to jump straight into OOP, and you see a lot less people struggling with types, in fact, than you did with B3D where they are somewhat "bolted on".