Sorry your browser is not supported!

I generally don't post very much in forums, but I wanted to offer my thoughts on this debate. I read DarkCoders original comments and I thought they seemed like reasonable requests and to me, who is new to DBPro but not to programming, they seemed well worded and I don't think they were meant to offend.

DarkCoder is obviously a user of the language and, IMHO, his comments were made in an effort to improve the language, not to trash it and I think we need to read them from that point of view. For somebody to take the time to write such a lengthy post he must care about his topic, in this case DBPro. So from my point of view, I believe he is attempting to improve a product that he obviously liked, which I think everybody would agree is a good thing.

Game programming languages/environments are starting to to get very popular I believe and I think DBPro is competing against products such as BlitzMax, GLBasic, PureBasic, PlayBasic and perhaps even products such as Gamestudio and Unity. As more competition enters that market, customers will expect, rightly or wrongly, products to continue to evolve and improve to keep pace with other offerings. Now I'm not saying these other products are better or worse, only that each seems to be improving with each new release (and I'm not saying DBPro isn't). I think what darkCoder is trying to say is "hey, I think that DBPro has the potential to be an even better indie/hobby/garage environment and I want to keep seeing it improve and become even better".

Whether the original post highlighted bugs or features, it doesn't matter what we call them or whether they are necessary or just good to have, I for one would be chuffed to see them added, but their absence isn't a deal breaker for me, but it might be for other potential customers.

I may have this all wrong, but if you consider this point of view I think his comments seem pretty reasonable. Lets be honest, we visit and read these forums because we like to be here and we like to use the products. I, for one, want to keep using these products and I want to keep seeing them improve over time. I think the only way this is going to happen is if TGC can continue to draw in new customers and to do that, it has to compete against these other competitors.

Before we start arguing against each other, I get the impression we are all on the same side. IMHO, DarkCoder cared enough about DBPro to write the original post and I for one didn't take offence to the way he said it (I'm only new here though so their may be other issues which I don't know about). Lets lighten up a bit and remember the reason for the post and not argue over is it a bug or a feature or is it decent language or not.

Let's instead turn our efforts to trying to continue to improve the product.

No Sid, that's my line of thinking - now do you want me to go through the reasons why I know better?

If you are learning a language for the first time, UDT's and more ADVANCED features would just complicate matters. It's easy to grasp straightforward array handling, then typed arrays would be the next stage up in learning, adding arrays to typed arrays would be quite tricky to understand and most people would have found other methods by then. Functions are straightforward right now, they can return a value, if they were to be expanded on with type support then they'd be more complex to learn. DBPro is a language that is easy to learn, there is no argument that DC's suggestions would benefit longer toothed users, but people learning certainly don't need to know about them yet, or the lack of them, or have it as an excuse for doing nothing all this time.

People keep saying work around, and that's bull. It's not a work around to avoid using a feature that doesn't exist - you just find other methods, and they tend to be as complex as needing an extra array or global variable compared to the methods DC mentions. I started using BASIC before these methods were even options, so when people make out that they can't do without them just makes me laugh.

As for TGC improving their products - in what way is my comment counter-acting that ideal? - I said that these issues won't affect users unless they know about them and miss them. Do you think learners here are getting flustered because of the lack of UDT's, or do you suppose they have more important things to be learning. Out of all the people I've helped with DBPro, these issues have never cropped up, funny that, funny how one can form an opinion based on experience as well.

I quite like DBPro to be honest. I found it a very good stepping stone to the more complicated languages. The more time I spent in BASIC, the more I understood things in PHP and Java.

I think people are expecting too much from DBPro. I don't see how you can argue about the faults of DBPro when there is Pure.GDK, Dark.GDK and Dark.GDK .net to counter all the issues.

if you want OOP, use Pure.GDK or .net

If I had payed £1000 ( which is really the norm for any indie engine out there ), I would be pretty miffed, but for the £30 I payed I don't think I got a pretty bad deal, especially considering updates are free.

A) If these things are so unimportant, why would the programmer have to learn about them right away? B) UDTs already exist (and can hardly be considered advanced as you claim), and the only thing one is arguing about relating to them is the ability to have them treated just like other variables - allow them to be returned from functions. Anything else is inconsistent and confusing (why force the programmer to learn this limitation?). C) Who explicitly said that all learners won't have prior programming experience?



Nonsense, how would it be tricky? It's the same fundamental nesting concept that surrounds UDTs and arrays in general.



Can you give absolutely any evidence to back up this nonsense claim? Adding consistency would not make anything more complex to learn, in fact it would do quite the opposite as you don't have to learn the exceptions to the behaviour you learn about.



But they are workarounds because we're talking about things that are arbitrary limitations, things that should be a fundamental part of the language. I don't think I've seen many workarounds in DBPro that most decent programmers wouldn't consider bad coding practices, and this shouldn't be the case.

Well there's quite clearly a pattern here seeing as we're getting a lot of moderators here who are either constantly re-posting responses to non-existent arguments that they've made up in their head, or just posting about how great they think DBPro is (no offense, I like it too, but that's not at all the point of this thread! ). With this in mind, I'm going to abstain from posting until we get something constructive we can debate about that is both on-topic and doesn't involve us going round in circles and formulating arguments that never existed in the first place.

How about we just lock, because I'm sick of seeing anything we say taken however it suits you.