Counters
The other option here is that rather than standardization, you just want BRL to do all the work. The nice thing about BRL doing all the work is that 1) if something goes wrong, you can sometimes blame them (rarely, since it's usually your terrible code's fault) and 2) you don't have to actually look for a solution, it's being sold right here.
I think this originates from the fact that most programmers here have little skill and are still learning how to tie their own shoes (so to speak), and so they simply don't know what they need, much less where they should find it. My solution to this? Yeah, go ahead, let BRL sell solutions. Stop acting like it's a problem with BMax though, this is a problem with you.
Issues
In no particular order.
1] As mentioned, documentation. However, my issues more stem from the fact that bcc's arguments aren't documented. This is really annoying, since I would like to use scons for building my projects, but working out how to use bcc has been too annoying for me to bother.
2] Import does not handle files that are dependent on each other. E.g., console.bmx depends on script.bmx and script.bmx depends on console.bmx (arbitrary names, don't place too much meaning on them). This has actually caused me a good headache, and as such I've just ended up switching to include. Sure, it pretty much requires a complete rebuild for any change, but it solves the problem.
3] Circular references aren't handled by the garbage collector. This isn't a huge issue, provided you program safely, but there are a good deal of people here who don't know how to do that and it's not an issue that's fixed by programming safely, only more likely to be avoided. In the end, it can still come up.
4] Not all data types are objects. I would really like to see the primitive types as objects, not just strings and classes. This, however, is not a big issue and should not be seen as one, it just requires that we use have a work-around when dealing with lists of numbers and such. It's just a design feature I would have liked to see, and does not impact us much.
5] Method callbacks. Just a nice thing to have, can be worked around easily.
6] The debugger really needs work. The default and community IDEs are nigh-useless in helping this, and working with it in a console is only slightly less difficult. I think something that would really help is a completely separate program that gets launched when debugging. This program will attach itself to the process and handle the debugging from then-on. This could probably be done now as an interface to the console debugger. However, I'm used to the Visual Studio 2005/2008 debugger, so I may be spoiled.
4. Poor built in IDE. <No don't spend time on this, Mark!!!> Solution: Official support for CE IDE.
The CE IDE is just as bad, so I don't see how it'd help. 5. More promotion/advertising.
This is a non-issue, as it does not affect our work, only BRL's sales. If you can come up with an example of this affecting your work without it being a pointless "but if they don't market it, they won't get money to improve the product I'm already using, and if the product I'm already using doesn't improve, I won't be able to finish my work" argument, then you may have something. Haven't seen anything of the sort lately, so I'm doubtful any good reason exists for this affecting anyone's work. I feel that there are too many ways of doing things in BlitzMax so you hav tothink about how to do somethign rather than what it is you want to do.
This is an issue with you not knowing what you want and doing it. If anything, this is caused by a lack of planning and knowledge on your part. Your inability to do something is only your fault, not BMax's. Don't blame the tool, lest you become one yourself. I want standardization
I've read this in different forms from different people over time. I've probably said it myself numerous times, and I can't help but look at all the cries for standards now and think it's just stupid. This is programming, standards are very far from standard, they change very frequently and you just get to pick a standard to implement. Standardization won't benefit you at all in programming today.The other option here is that rather than standardization, you just want BRL to do all the work. The nice thing about BRL doing all the work is that 1) if something goes wrong, you can sometimes blame them (rarely, since it's usually your terrible code's fault) and 2) you don't have to actually look for a solution, it's being sold right here.
I think this originates from the fact that most programmers here have little skill and are still learning how to tie their own shoes (so to speak), and so they simply don't know what they need, much less where they should find it. My solution to this? Yeah, go ahead, let BRL sell solutions. Stop acting like it's a problem with BMax though, this is a problem with you.
Its not beginner friendly, please dont say it is, the docs are sporadic and the OOP aspect still feels alien in Basic to me.
You don't have to use OOP features, so stop complaining. Nobody is telling you what you have to do, the language is very open. 3. Fix the audio. why were being forced to use openAl or *insert audio driver* is very annoying. I paid for blitz, I dont want to have to pay for anything else to finish my projects.
You don't have to pay to use OpenAL. There is the opportunity to pay for more advanced solutions, but you are not required to as OpenAL is sufficient for most tasks.Issues
In no particular order.
1] As mentioned, documentation. However, my issues more stem from the fact that bcc's arguments aren't documented. This is really annoying, since I would like to use scons for building my projects, but working out how to use bcc has been too annoying for me to bother.
2] Import does not handle files that are dependent on each other. E.g., console.bmx depends on script.bmx and script.bmx depends on console.bmx (arbitrary names, don't place too much meaning on them). This has actually caused me a good headache, and as such I've just ended up switching to include. Sure, it pretty much requires a complete rebuild for any change, but it solves the problem.
3] Circular references aren't handled by the garbage collector. This isn't a huge issue, provided you program safely, but there are a good deal of people here who don't know how to do that and it's not an issue that's fixed by programming safely, only more likely to be avoided. In the end, it can still come up.
4] Not all data types are objects. I would really like to see the primitive types as objects, not just strings and classes. This, however, is not a big issue and should not be seen as one, it just requires that we use have a work-around when dealing with lists of numbers and such. It's just a design feature I would have liked to see, and does not impact us much.
5] Method callbacks. Just a nice thing to have, can be worked around easily.
6] The debugger really needs work. The default and community IDEs are nigh-useless in helping this, and working with it in a console is only slightly less difficult. I think something that would really help is a completely separate program that gets launched when debugging. This program will attach itself to the process and handle the debugging from then-on. This could probably be done now as an interface to the console debugger. However, I'm used to the Visual Studio 2005/2008 debugger, so I may be spoiled.