Potential Community Projects...what in the FreeBASIC ecosystem is lacking a bit of much needed TLC ?
Q whats not being done but could & should be ?
Q whats on your wishlist ?
Potential Community Projects
-
anonymous1337
- Posts: 5494
- Joined: Sep 12, 2005 20:06
- Location: California
Re: Potential Community Projects
- LLVM backend
- Mac port
- Object/class wrappers for all data types [Will work best with inheritance, which will be in an official release soon enough. I've been thinking of ways that this could be done using composition, while avoiding macros.]
- Better IDEs. I use FBedit and suffer any number of pains whenever I use it. I heard FBIde had been updated, but I never tried the new version. IMO, FlashDevelop is a pretty awesome, free, lightweight IDE. If a FreeBASIC plugin or install package worked with FlashDevelop, I would use it.
- Better tools/standard libraries. I will work on this.
- There's plenty of other stuff you could ask for. Some fundamental stuff needs to get done first, unless you're a masochist. Arguably, some stuff I'd like to see in FreeBASIC doesn't belong in statically typed languages.
Of course, it's a little difficult spending time making innovations in FreeBASIC when you know the following things:
1) You are me, and I work with modern programming languages. I frequently find myself innovating in these languages, which puts anything I do in them nearly a decade ahead of what FreeBASIC is typically capable of. ie: Sometimes it feels like a waste of my time, especially knowing that if I put the same effort into a "real" software environment, I might come up with something that pushes IT forward.
2) The compiler is a bit of a mess, so even if you want to dig in deep and implement fancy new features, FreeBASIC may not be the project you want to get into. It had certain goals in mind in its early development, and we're stuck what it.
3) To get this stuff done, you'll probably have to code in FreeBASIC, as it is now, not as you want it to be. Bleck.
- Mac port
- Object/class wrappers for all data types [Will work best with inheritance, which will be in an official release soon enough. I've been thinking of ways that this could be done using composition, while avoiding macros.]
- Better IDEs. I use FBedit and suffer any number of pains whenever I use it. I heard FBIde had been updated, but I never tried the new version. IMO, FlashDevelop is a pretty awesome, free, lightweight IDE. If a FreeBASIC plugin or install package worked with FlashDevelop, I would use it.
- Better tools/standard libraries. I will work on this.
- There's plenty of other stuff you could ask for. Some fundamental stuff needs to get done first, unless you're a masochist. Arguably, some stuff I'd like to see in FreeBASIC doesn't belong in statically typed languages.
Of course, it's a little difficult spending time making innovations in FreeBASIC when you know the following things:
1) You are me, and I work with modern programming languages. I frequently find myself innovating in these languages, which puts anything I do in them nearly a decade ahead of what FreeBASIC is typically capable of. ie: Sometimes it feels like a waste of my time, especially knowing that if I put the same effort into a "real" software environment, I might come up with something that pushes IT forward.
2) The compiler is a bit of a mess, so even if you want to dig in deep and implement fancy new features, FreeBASIC may not be the project you want to get into. It had certain goals in mind in its early development, and we're stuck what it.
3) To get this stuff done, you'll probably have to code in FreeBASIC, as it is now, not as you want it to be. Bleck.
Re: Potential Community Projects
Lots of good points. I agree that FB is not ready/ideal for heavy weight apps production. It is suitable for some mini apps/smaller software. I see it as a 2nd or 3rd language.
My wishlist.
useful enduser software written in FreeBASIC. Utility first, and a demonstration of current capability as a tangible side effect
better toolkits
better tutorials
creation of a killer app (popular app) written in FreeBASIC like Fritzbench or Audacity
My wishlist.
useful enduser software written in FreeBASIC. Utility first, and a demonstration of current capability as a tangible side effect
better toolkits
better tutorials
creation of a killer app (popular app) written in FreeBASIC like Fritzbench or Audacity
-
Destructosoft
- Posts: 88
- Joined: Apr 03, 2011 3:44
- Location: Inside the bomb
- Contact:
Re: Potential Community Projects
I'd like to see triple precision and a reorganization of Randomize to use it instead of Double. (Am I mad? Possibly, but I can see a need for more than 4 billion random seeds in procedural content.)
Along similar lines, making use of Long vs. LongInt to where LongInt is even longer, but that would confuse a lot of people needlessly and cause great consternation in having to recode everything to avoid 36-digit numbers. Anyway, isn't there a library called BigInt already?
I'd also like to see IIF() to work with fewer restrictions if possible. (Or is that just lazy thinking, not wanting to type IF THEN ELSE all the time?)
As for seeing it as a "second language", I cannot, as C++ is very annoying for many things without including certain libraries, whereas FB encompasses so much more even without gfx.bi, file.bi, fmod, FBPNG, etc.
Certainly it is true that most great applications were coded with Big Language, but I prefer to think they could have been so much better in FB. (Except maybe WoW-Chung. Sorry man.)
Along similar lines, making use of Long vs. LongInt to where LongInt is even longer, but that would confuse a lot of people needlessly and cause great consternation in having to recode everything to avoid 36-digit numbers. Anyway, isn't there a library called BigInt already?
I'd also like to see IIF() to work with fewer restrictions if possible. (Or is that just lazy thinking, not wanting to type IF THEN ELSE all the time?)
As for seeing it as a "second language", I cannot, as C++ is very annoying for many things without including certain libraries, whereas FB encompasses so much more even without gfx.bi, file.bi, fmod, FBPNG, etc.
Certainly it is true that most great applications were coded with Big Language, but I prefer to think they could have been so much better in FB. (Except maybe WoW-Chung. Sorry man.)
Re: Potential Community Projects
I bought PureBasic for 75 Euros it cost me $148 American dollors. PureBasic 4.30 couldn't step forward and backwards thru a 1 megabyte string without locking up. I haven't tried 4.60 current.
I downloaded RealBasic Trial-Version, the real one costs $1,000, and it didn't have all QB keywords as was about as slow as QB.
QB64 is sort of good, it compiles with MingW GNU tools and can make 32 or 64 bit exes. But their "not so like" QB editor is hard to work in. and my programs ran slower than in FB.
You could always look at all the other programming languages in existance and try to incorporate the most used or usefull functionality of them. (But then it wouldn't be completely "BASIC", so, you might have to rename it.)
The best thing to do to advance it; is to work on the *.ASM output to optimize it, ( it can never be fast enough ).
But having 10's of ( ifdef processor = ?? then ?? ) for each output would slow the compilation down 10 times like GCC.
I downloaded RealBasic Trial-Version, the real one costs $1,000, and it didn't have all QB keywords as was about as slow as QB.
QB64 is sort of good, it compiles with MingW GNU tools and can make 32 or 64 bit exes. But their "not so like" QB editor is hard to work in. and my programs ran slower than in FB.
You could always look at all the other programming languages in existance and try to incorporate the most used or usefull functionality of them. (But then it wouldn't be completely "BASIC", so, you might have to rename it.)
The best thing to do to advance it; is to work on the *.ASM output to optimize it, ( it can never be fast enough ).
But having 10's of ( ifdef processor = ?? then ?? ) for each output would slow the compilation down 10 times like GCC.