Did FreeBasic is stagnating / dying?
Did FreeBasic is stagnating / dying?
Hi all,
I have look on FreeBasic status and their updates are decreasing largely in the last year, and v1ctor seems to not contribute to it. I am concerned yet that it will be hard moments tor a compiler to stagnate, based that is doubled by a harsh competition from other opensource projects.
My hope with that post is to make the community to get together and to add more value to compiler, not only writing small QB games in it. Adding a new library or improving the compiler/runtime is the best way. Elsewhere will became a dead opensource project and is a pity.
Regards...
I have look on FreeBasic status and their updates are decreasing largely in the last year, and v1ctor seems to not contribute to it. I am concerned yet that it will be hard moments tor a compiler to stagnate, based that is doubled by a harsh competition from other opensource projects.
My hope with that post is to make the community to get together and to add more value to compiler, not only writing small QB games in it. Adding a new library or improving the compiler/runtime is the best way. Elsewhere will became a dead opensource project and is a pity.
Regards...
Ironically, the newest version of FB was just released 3 days ago:
http://www.freebasic.net/forum/viewtopic.php?t=11955
http://www.freebasic.net/forum/viewtopic.php?t=11955
I somewhat agree. there are no ground braking changes anymore. Well the only real update to the compiler that I see is AndAlso/OrElse additions. Beside that there are just small tidbits. Updated gfx a bit. Some new versions of headers. I personally don't care at all about dialects and feel it is a bad thing to have. At least #lang option was added to help things at least a little.
On the other hand it is good that regular bugfixes and updates are released. But I guess what many (me included) really look forward to is a real progress.
Implement proper OOP. I understand it's not an easy goal. But since V1ctor left(?) no one works on this anymore. At least implement delegates that I have proposed several times. Using delegates we can fake interfaces and virtual methods.
Return BYREF - don't know what's the status on this. But would be useful also
Of course wish list could go on and on. But perhaps byref and delegates could be next goal? if real OOP is beyond current scope?
On the other hand it is good that regular bugfixes and updates are released. But I guess what many (me included) really look forward to is a real progress.
Implement proper OOP. I understand it's not an easy goal. But since V1ctor left(?) no one works on this anymore. At least implement delegates that I have proposed several times. Using delegates we can fake interfaces and virtual methods.
Return BYREF - don't know what's the status on this. But would be useful also
Of course wish list could go on and on. But perhaps byref and delegates could be next goal? if real OOP is beyond current scope?
-
- Posts: 1759
- Joined: May 23, 2007 21:52
- Location: Cut Bank, MT
- Contact:
Did anyone mention that the real great stuff (OOP, especially, and a few other things we all would like) are going to be some of the hardest things to implement? Well in case you didn't know that already... development is hard and getting harder. The developers do the best they can, but from here it's a rather hard, uphill climb. Real OOP is not going to be easy. Same with C front/backend, etc. There is a list of things to do and the developers are hitting them as they get the opportunity, but it takes time (I will point out that AndAlso/OrElse seem to be pretty big - something that has been talked about for a long time, and only just implemented).
So... I think the state of FreeBASIC is good (definitely not dieing or losing out to "competition" - other compilers may be used more, but those who use FreeBASIC now continue to use FreeBASIC and contribute to the community) and development is coming along just fine - but slowly. You have to bear in mind, along with all I've already said, that the developers do have lives of their own. Whether you like it or not, FB development is not necessarily the most important thing in their lives (they make no money at it, and only do it for the enjoyment they get out of the compiler and the community behind it).
We should realize that the compiler is very great (having already surpassed the language it was formerly intended to in some ways replace or be based upon, QBasic, and moving on to greater things yet in order to stand on its own among the other great free open source compilers) considering it's young age and the number of developers on the team. Be glad of how far it has come, and look forward to the future - but do be patient and understanding with the developers, who work so hard to continue fixing bugs and adding features to the compiler.
So... I think the state of FreeBASIC is good (definitely not dieing or losing out to "competition" - other compilers may be used more, but those who use FreeBASIC now continue to use FreeBASIC and contribute to the community) and development is coming along just fine - but slowly. You have to bear in mind, along with all I've already said, that the developers do have lives of their own. Whether you like it or not, FB development is not necessarily the most important thing in their lives (they make no money at it, and only do it for the enjoyment they get out of the compiler and the community behind it).
We should realize that the compiler is very great (having already surpassed the language it was formerly intended to in some ways replace or be based upon, QBasic, and moving on to greater things yet in order to stand on its own among the other great free open source compilers) considering it's young age and the number of developers on the team. Be glad of how far it has come, and look forward to the future - but do be patient and understanding with the developers, who work so hard to continue fixing bugs and adding features to the compiler.
Thank you. I might be biased, but I really enjoy a LOT of features that FB supports. I've always been about games and gfx and I'm really amazed at how much you can do with FB and all the supported libraries. Sound, Music, GFX, OpenGL, WinAPI, Internet, Hardware, GUI, TrueType, etc. That's some serious power we have access to.We should realize that the compiler is very great (having already surpassed the language it was formerly intended to in some ways replace or be based upon
No, full OOP support isn't there yet, but its a hell of a lot closer than what QB provided and seriously, we're programmers. The language is robust enough to allow you to write work-arounds for most anything.
Looking at FB from a strict language perspective is a bit closed minded. A programming language is just a tool, a means to an end, and with that in mind, you can achieve quite a bit with what's already present. Not to mention, it's FREE.
What do you want? MakeGame()?VonGodric wrote:I somewhat agree. there are no ground braking changes anymore.
I'm not so in the hurry for virtual methods (although they would be useful) as much as I am for inheritence.VonGodric wrote:Implement proper OOP. I understand it's not an easy goal. But since V1ctor left(?) no one works on this anymore. At least implement delegates that I have proposed several times. Using delegates we can fake interfaces and virtual methods.
Well, while I could see one or two uses in a low-level application (driver/boot strap) I can see no practical use for it at a high level.VonGodric wrote:Return BYREF - don't know what's the status on this. But would be useful also
I still say inheritence is way more important as well as inline and naked functions.VonGodric wrote:Of course wish list could go on and on. But perhaps byref and delegates could be next goal? if real OOP is beyond current scope?
It's unfortunate when users (and statistic reports) can't see the the developers' efforts. I guess improved stability can't be measured directly like "X number of new features" or "X lines of code added" so it doesn't get noticed.
Obviously v1c knows (knew?) the compiler better than anyone and so could bring in a new feature and have it 70-80% complete fairly quickly. Same could be said for lillo and GFX or mjs and rtlib. No disrespect to the previous developers, but we have lots of features that are like that: 70-80% complete. It's then still a great deal of effort to bring it that last 20-30%; a task which now falls to other developers. For example, counting_pine spent more than month just on conversion stuff (e.g, VAL, STR, ASC, WRITE, INPUT, etc) making fixes and improvements in all dialects. That was a lot of work but not many commits. Anyway, it is that kind of thing I think is being reflected in the commit statistics.
I know there are mixed opinions about the dialects. But with the exception of SCOPE (maybe), I think the main work with dialects is complete. Some problems, for example, like PRINT USING, passing strings BYVAL, etc, have never worked 100% right and they are a problem in all dialects (because they share the same code base). So for those kinds of issues, there is no split on development time due to dialects (someone still has to work on them though).
There's also the effort made on what only a few users will notice: like new build options (DrV), the C emitter improvements (Yetifoot, sir_mud), and a native linux package (cha0s, myself). All of that work will eventually take fbc to new platforms/architectures, inclusion in Linux distros, and exposure to a broader user base. And with more users there is the potential for more contributors (though we will still probably have to beg for help ;)).
--
IMO, next up should be static data members, boolean data type, BYREF returns. Those missing features make it impossible to port even simple C++ headers. And it doesn't make sense to me to start adding CLASS features (e.g. inheritence, virtual methods) until all the object stuff is done first.
Of course, fixing bugs usually gets in the way of feature additions, so if anyone is up to the task and is interested in improving the compiler/rtlib/gfxlib, get to it and submit those patches. :)
Obviously v1c knows (knew?) the compiler better than anyone and so could bring in a new feature and have it 70-80% complete fairly quickly. Same could be said for lillo and GFX or mjs and rtlib. No disrespect to the previous developers, but we have lots of features that are like that: 70-80% complete. It's then still a great deal of effort to bring it that last 20-30%; a task which now falls to other developers. For example, counting_pine spent more than month just on conversion stuff (e.g, VAL, STR, ASC, WRITE, INPUT, etc) making fixes and improvements in all dialects. That was a lot of work but not many commits. Anyway, it is that kind of thing I think is being reflected in the commit statistics.
I know there are mixed opinions about the dialects. But with the exception of SCOPE (maybe), I think the main work with dialects is complete. Some problems, for example, like PRINT USING, passing strings BYVAL, etc, have never worked 100% right and they are a problem in all dialects (because they share the same code base). So for those kinds of issues, there is no split on development time due to dialects (someone still has to work on them though).
There's also the effort made on what only a few users will notice: like new build options (DrV), the C emitter improvements (Yetifoot, sir_mud), and a native linux package (cha0s, myself). All of that work will eventually take fbc to new platforms/architectures, inclusion in Linux distros, and exposure to a broader user base. And with more users there is the potential for more contributors (though we will still probably have to beg for help ;)).
--
IMO, next up should be static data members, boolean data type, BYREF returns. Those missing features make it impossible to port even simple C++ headers. And it doesn't make sense to me to start adding CLASS features (e.g. inheritence, virtual methods) until all the object stuff is done first.
Of course, fixing bugs usually gets in the way of feature additions, so if anyone is up to the task and is interested in improving the compiler/rtlib/gfxlib, get to it and submit those patches. :)
I too would like to help but when I downloaded the source, sadly I had a really tough time understanding what was going on. Perhaps if there was a document which could help prompt a new developer what is going on with each module, structures and such.Imortis wrote:I would love to help out with the compiler, but my skill is sadly far lacking.
Do you have any suggestions on what I would need to learn/do to increase my skill with the language?
-Vince
I appreciate all the hard effort developers put into the compiler. This must not be underestimated.
However from enduser point of view - Everytime I see a changelog I think that, great - another bug is fixed. But what would really excite me are new additions. More complete OO. To make FB a really more complete programming language that I could really use as a tool. Most of my fb code is just playing around. Whenever I need to get something "serious" done I turn to C++ (I like OOP)
It is often so that small things go unnoticed/underapreciated. I've faced the same frustration myself many many times both from work and from my own projects.
I also agree that adding CLASS keyword is not a priority on itself and other stuff needs to be done first. But why not implement something like delegates until then? they should be simple enough (compared to full blown OO) to add. Would allow to simulate interfaces, virtual methods and even inheritance - sort of. Also allow creating event handlers much the same way as in C#.
Of course I might be overlooking some obvious technical complexity here... The way I see it is allow taking address of a method. and save "this" and method address into 8byte data structure. Once you got inheritance and vtables will probably need 12 bytes (pointer to vtable entry, "this" pointer and some sort of trigger mechanism to ensure right thing is called - probably a flag stating the type.)
If someone would point out how to attempt to add such a feature I might give it a try. But as someone else mentioned fb source is rather scary at first glance.
However from enduser point of view - Everytime I see a changelog I think that, great - another bug is fixed. But what would really excite me are new additions. More complete OO. To make FB a really more complete programming language that I could really use as a tool. Most of my fb code is just playing around. Whenever I need to get something "serious" done I turn to C++ (I like OOP)
It is often so that small things go unnoticed/underapreciated. I've faced the same frustration myself many many times both from work and from my own projects.
I also agree that adding CLASS keyword is not a priority on itself and other stuff needs to be done first. But why not implement something like delegates until then? they should be simple enough (compared to full blown OO) to add. Would allow to simulate interfaces, virtual methods and even inheritance - sort of. Also allow creating event handlers much the same way as in C#.
Of course I might be overlooking some obvious technical complexity here... The way I see it is allow taking address of a method. and save "this" and method address into 8byte data structure. Once you got inheritance and vtables will probably need 12 bytes (pointer to vtable entry, "this" pointer and some sort of trigger mechanism to ensure right thing is called - probably a flag stating the type.)
If someone would point out how to attempt to add such a feature I might give it a try. But as someone else mentioned fb source is rather scary at first glance.
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
I can't speak for myself, but I wasn't aware that the project seemed to have been stagnating. V1ctor has mainly been busy with Real Life recently, and that has hindered progress with regards to the OOP work, but we have been busy working on FB in other ways. CoderJeff, in particular, has been doing an amazing job keeping things together in v1ctor's stead. I hope people aren't underestimating the amount of work that has gone on behind the scenes between releases.
Also, for anyone who uses FbEdit, you might find it worthwhile loading the entire FBC project into there for viewing. FbEdit does a good job of keeping track where functions are written, and so if you come across a function name you don't know, you can right click it and click "Find Declare", and it will take you straight to the module where it's written.
As someone who's only recently gotten to know the source in any great depth, and still has a long way to go, one of the best pieces of advice I can give is to keep Grep close to hand when reading the source code. I find this very useful for looking up things like defines and structure names.vdecampo wrote:I too would like to help but when I downloaded the source, sadly I had a really tough time understanding what was going on. Perhaps if there was a document which could help prompt a new developer what is going on with each module, structures and such.
Also, for anyone who uses FbEdit, you might find it worthwhile loading the entire FBC project into there for viewing. FbEdit does a good job of keeping track where functions are written, and so if you come across a function name you don't know, you can right click it and click "Find Declare", and it will take you straight to the module where it's written.
Er, as eager as I am for oop, the comment about rather having new additions than fixing whats there just strikes me as rather odd. Personally I'd rather have a guaranteed product with a limited feature set than those projects with lots of features and promises but sub par performance. Oop will come. Whats the point of speeding fb across the finish alone, if doing so requires hacking the racecar into bits and having it explode right after?
No, take what time is needed, make the cookies right, don't make them at 500 degrees just so they take 3 minutes instead of 6. When I code stuff using fb oop, I want to know the compiler is working well, not just working.
@devs, as opposed to other comments here, every time I read a report about more bug fixes and stability issues resolved I understand how much that means. Good job, I understand the time crunch -- lack of time is probably the only reason I've never looked into helping this project out at the highest level (ie compiler coding rather than building a project base)
No, take what time is needed, make the cookies right, don't make them at 500 degrees just so they take 3 minutes instead of 6. When I code stuff using fb oop, I want to know the compiler is working well, not just working.
@devs, as opposed to other comments here, every time I read a report about more bug fixes and stability issues resolved I understand how much that means. Good job, I understand the time crunch -- lack of time is probably the only reason I've never looked into helping this project out at the highest level (ie compiler coding rather than building a project base)
Hey, I've submitted a couple patches fixing bugs and adding features. I always eagerly await the new stable releases so that I can see all the list of bug fixes and updates which are made. It doesn't seem like much when you are doing a nightly build and there are 5-20 commits a week but you see the effect of a few hundred between releases.
Also, while I'm not in too much of a rush for the C backend (although, being able to take advantage of GCC's optimization engine would roxz0r) there are a couple even non-oo features which would be wery nice. Mostly naked functions and inline functions as I stated before.
Anyway, the compiler is far from dead and the devs, contibutors and people submitting bugfix patches and new features (sse-maths) all get a round of applause from me.
Also, while I'm not in too much of a rush for the C backend (although, being able to take advantage of GCC's optimization engine would roxz0r) there are a couple even non-oo features which would be wery nice. Mostly naked functions and inline functions as I stated before.
Anyway, the compiler is far from dead and the devs, contibutors and people submitting bugfix patches and new features (sse-maths) all get a round of applause from me.
Hi all
There must be a guide on the net somewhere to show you how to start heated discussions, ie:
Dos is dead
FB is dying.
Oop's did I just do the same ?
I have one machine weighing up 10 kg of Barbeque coals at 16 bags per minute,24 hours per day, seven days per week.
The second just came on line doing 1kg of chinese noodles at 35 bags per minute.
That's a good measure for me.
Stability, Predictability, Bug Free, they are the priority.
But I guess I am not here for the Game's, so my priority is different then most.
Regards
There must be a guide on the net somewhere to show you how to start heated discussions, ie:
Dos is dead
FB is dying.
Oop's did I just do the same ?
Yes it can,I guess improved stability can't be measured
I have one machine weighing up 10 kg of Barbeque coals at 16 bags per minute,24 hours per day, seven days per week.
The second just came on line doing 1kg of chinese noodles at 35 bags per minute.
That's a good measure for me.
Stability, Predictability, Bug Free, they are the priority.
But I guess I am not here for the Game's, so my priority is different then most.
Regards