A Serious Article Debating the Pros and Cons of FreeBASIC
I head up another open source project, and I'd like to offer my experience there as a resource for the devs here. I think even some very basic changes can help... for example, simply communicating where things stand and why would be great, especially for people who don't follow these long threads. Is there any way to boil that information down into a sticky post at the top of this forum so the community can check in there if they can't remember who's working on what when and where things are going? I'm horrible at keeping a roadmap myself, but I'd like to improve that... but at the very least, people know who the active developers are on the project and have pointers in the right direction for chipping in.
There are a lot of people here in the community with different abilities, and not everyone needs to be a compiler hacker to contribute significantly to FreeBASIC. One great example is the fact that FB has some of the rockinest documentation I've ever seen for an open source project. : )
There are a lot of people here in the community with different abilities, and not everyone needs to be a compiler hacker to contribute significantly to FreeBASIC. One great example is the fact that FB has some of the rockinest documentation I've ever seen for an open source project. : )
Great point. Anyone that can follow the simple style guides provided in the FBWiki, their help would be welcomed immensely. The Programmer's Guide has lists of pages that need written, as well as the MissingDocs page. coderJeff and many others have made this an excellent documentation, let's make it better !Landeel wrote:There are a lot of people here in the community with different abilities, and not everyone needs to be a compiler hacker to contribute significantly to FreeBASIC. One great example is the fact that FB has some of the rockinest documentation I've ever seen for an open source project. : )
Quickly learn how to contribute in a consistent manner:
http://www.freebasic.net/wiki/FBWikiHelp
See what needs written or updated:
http://www.freebasic.net/wiki/MissingDocs
These are more prose than technical:
http://www.freebasic.net/wiki/CatPgProgrammer
Have a tutorial you think would be helpful to the FB scene at large ?
http://www.freebasic.net/wiki/CommunityTutorials
I think it all starts with something like this:
http://gcc.gnu.org/onlinedocs/gccint/
And promoting the idea that developing the parser can be done by anyone able to program in FreeBASIC.
Someone wanting to contribute to compiler development might be put of by the seeming complexity of it all. There are a lot of files that together somehow form a compiler.
Building a compiler = knowing a little bit about compiler theory. Once you know how a recursive descent parser operates (the FBC uses a handwritten recursive descent parser) and what parts a compiler is made of the FBC code suddenly seems a lot less complicated. Lexing, preproccessing, parsing, building the abstract syntax tree, generating code, it's all got to be in there one way or another.
I've tried to clarify things a bit with a tracing version of the FB compiler so at least you can see what is happening during compilation (in terms of recursive descent parsing/what functions are getting called).
And many, many people on the internet have written about recursive descent parsing. Just a link:
http://www.techhui.com/profiles/blog/sh ... ost%3A1683
Or you could just 'get' the infamous Dragon Book,
http://en.wikipedia.org/wiki/Compilers: ... nd_edition
This page contains some very good links:
http://www.more-compiler.blogspot.com/
One last link (it's on the above mentioned page):
http://www.scribd.com/doc/47354/Basics- ... ler-Design
You've got to be willing to read (a lot) if you want to help out developing the compiler. And at the same time I think enjoying the development of a compiler is much more important than what a developer, at a certain point in time, 'knows' about building a compiler.
http://gcc.gnu.org/onlinedocs/gccint/
And promoting the idea that developing the parser can be done by anyone able to program in FreeBASIC.
Someone wanting to contribute to compiler development might be put of by the seeming complexity of it all. There are a lot of files that together somehow form a compiler.
Building a compiler = knowing a little bit about compiler theory. Once you know how a recursive descent parser operates (the FBC uses a handwritten recursive descent parser) and what parts a compiler is made of the FBC code suddenly seems a lot less complicated. Lexing, preproccessing, parsing, building the abstract syntax tree, generating code, it's all got to be in there one way or another.
I've tried to clarify things a bit with a tracing version of the FB compiler so at least you can see what is happening during compilation (in terms of recursive descent parsing/what functions are getting called).
And many, many people on the internet have written about recursive descent parsing. Just a link:
http://www.techhui.com/profiles/blog/sh ... ost%3A1683
Or you could just 'get' the infamous Dragon Book,
http://en.wikipedia.org/wiki/Compilers: ... nd_edition
This page contains some very good links:
http://www.more-compiler.blogspot.com/
One last link (it's on the above mentioned page):
http://www.scribd.com/doc/47354/Basics- ... ler-Design
You've got to be willing to read (a lot) if you want to help out developing the compiler. And at the same time I think enjoying the development of a compiler is much more important than what a developer, at a certain point in time, 'knows' about building a compiler.
Not for beginners. Dragon books overly focusses on parsing techniques and -math, and is light on code generators.AGS wrote:I think it all starts with something like this:
http://gcc.gnu.org/onlinedocs/gccint/
A good beginner tutorial was Jack Crenshaw's. There are multiple links for that, but I obviously like my own (PDF, formatted, hyperlinked) best:
http://www.stack.nl/~marcov/compiler.pdf
IMHO a more important thing than knowing parsing is a good working knowledge of how a compiler works (the "procedural" regime so to speak) Can be achieved by studying compiler output (comparing with the basic input to the generated assembler)Building a compiler = knowing a little bit about compiler theory. Once you know how a recursive descent parser operates (the FBC uses a handwritten recursive descent parser) and what parts a compiler is made of the FBC code suddenly seems a lot less complicated. Lexing, preproccessing, parsing, building the abstract syntax tree, generating code, it's all got to be in there one way or another.
-
- Posts: 453
- Joined: Dec 24, 2005 2:32
- Location: WA - USA
- Contact:
-
- Posts: 453
- Joined: Dec 24, 2005 2:32
- Location: WA - USA
- Contact:
Their open source projects just like FreeBASIC. What's next, don't talk about open source libraries that you don't use? My comment was a suggestion on how to hone your skills to help the FreeBASIC project out. Your not helping with your bitter attitude. If you have issue with me, take it off line and e-mail me at support@scriptbasic.org.TheMG wrote:Stop plugging your favourite projects.
Alright, TheMG and John... take the crap off this post (and the forum)... thanks in advance.
I know this might sound harsh, but I've read a bit on this topic now about how we should 'have a poll' and the developers should take guidance from that. If you ask my opinion (and I'd hope you might consider that!) I'd say you're dead wrong.
In my opinion, good open source projects should be run as meritocracies. This means that simply using Firefox to point towards this forum doesn't make you qualified to make design decisions. If you have something to contribute, then contribute it and the ones with the skills will pick it apart and tell you if it's good or not.
I will automatically give more weight to someone whose opinion is attached to skill and a past demonstration of ability. Even me being your friend on IRC chat doesn't mean I'll support your whim getting into FreeBASIC. I'm sorry if this sounds harsh, but let's face it. FB's code isn't written by the community, it's written by the devs, and usually the community are just the complainers. :) Of course not everyone in th community, but then like I said, contribute and I give you props.
Most people here who say FB is everything it should be at this point are unfortunately a bit ignorant I think. The world hasn't moved towards ways of programming because they felt like it'd be funny to Πss off everyone using the old languages and methodologies. We've moved that way because it's BETTER. FreeBASIC is missing polymorphism and inheritance, and it won't be takenas seriously until we implement that stuff. We're even missing (as many have mentioned already) things that should be a given, like dynamic arrays in types, and proper ByVal string passing.
To settle on the current state of FreeBASIC is either an admission of incompetence, or ignorance, IMHO.
I'm of the belief that the QB compatibility should be scrapped, especially now that QB64 has come around. We don't have to be everything for everyone. Implicit allocation is stupid, not only having to implement all the quirks associated with it, but if you don't explicitly allocate your variables, you are an incompetent programmer. Maybe you're a good scientist/cook/envelope stuffer, but you're an awful programmer.
I also believe the compiler being written in FreeBASIC is needless pain for developers that ultimately has left us in a rut for the time being. It's like everyone wants it both ways. You say BASIC is for the newbies and C is for the pros, well here's the reality: pros are the ones who do compiler development, not newbies. This decision is killing us, I believe. I want to write the compiler in C++. At very least C, but why make our lives harder? If you just want to use BASIC, keep your nose out of how I want to allow you to be able to do that... :)
Not only would writing it in C(++) make it faster, it also removes the need for us to constantly tiptoe around chicken/egg problems, and more importantly (IMO) the fact that EVERYONE has a C compiler already on their platform. We have to cross-compile FreeBASIC to any significantly different platform we want to host on.
FreeBASIC may end up being forked. I think it's mature enough now where a fork wouldn't kill the original project. Too many people find the things I write here reprehensible, and that virtually ensures that if I were to start a new project based on what I've said, they at very least would take a while to show up. It's the nature of open source and nature in general. Evolution through natural selection is fact, and I don't see any problem with killing FreeBASIC, IF the result is a better, faster stronger language overall. GW-BASIC is dead... there's no special reason to keep it alive if everything we have now is vastly superior. It's a hard reality... so hard that people have been making up an believing stories about it for thousands of years to try to escape it.
FreeBASIC is actually a bit more closed than I'd like. Not the source code, but the site itself. No one has real access here except v1ctor. We can't make improvements or changes to the way the site works, even though it's pretty obvious me and the other devs are only here because we care about the language. I know I haven't been around much lately, but that will probably change in the near future.
The biggest thing keeping me from getting into development now is the fact that I run a 64-bit system now. I have to run a VM to do any development because there simply IS no 64-bit FreeBASIC compiler right now. I don't want to spend more time hacking on FreeBASIC slogging through the mud just so that I can bootstrap it to 64-bit and then start "real" development.
I've seen the same methods being used in a project I've been working on the last year... the idea that if we just keep hastily porting it forward, some day we'll magically be able to fix all the problems we keep carrying forward, breaking more and more. People are just afraid. It's a scary thought to start over... look how long it took for people to start on FreeBASIC after QB was long irrelevant.
I'm not content to live in fear of what will happen if we try to make a fresh start. I want to cut out all of the ugly QB-related stuff and make FB modern and intelligent. Read the posts here... I'm not the only one. If you want to stay on this and keep hoping that if we pile on fixes here and there, somehow things will change... that's fine. Just like when we gt starships and are able to leave this ruined dying planet, there will be people that stay for the most ridiculous religious reasons. I'll be on the ship off!
Ok, so I should probably note that I don't think FreeBASIC is dead at all. As many have mentioned, it would be more appropriate to classify it as a kind of stasis. We don't have any mandate to change anything more, and what's here is powerful enough to make a lot of really awesome things happen. Every language ultimately has its quirks and weirdness and pitfalls. That's great, and I'm really glad I was able to contribute as long as I did here. However, I just feel like we can do better, and I'm not just gonna close my eyes, look to the heavens and shout to you that we're there and we should accept what we have. We're not *there* yet. We can do better.
I know this might sound harsh, but I've read a bit on this topic now about how we should 'have a poll' and the developers should take guidance from that. If you ask my opinion (and I'd hope you might consider that!) I'd say you're dead wrong.
In my opinion, good open source projects should be run as meritocracies. This means that simply using Firefox to point towards this forum doesn't make you qualified to make design decisions. If you have something to contribute, then contribute it and the ones with the skills will pick it apart and tell you if it's good or not.
I will automatically give more weight to someone whose opinion is attached to skill and a past demonstration of ability. Even me being your friend on IRC chat doesn't mean I'll support your whim getting into FreeBASIC. I'm sorry if this sounds harsh, but let's face it. FB's code isn't written by the community, it's written by the devs, and usually the community are just the complainers. :) Of course not everyone in th community, but then like I said, contribute and I give you props.
Most people here who say FB is everything it should be at this point are unfortunately a bit ignorant I think. The world hasn't moved towards ways of programming because they felt like it'd be funny to Πss off everyone using the old languages and methodologies. We've moved that way because it's BETTER. FreeBASIC is missing polymorphism and inheritance, and it won't be takenas seriously until we implement that stuff. We're even missing (as many have mentioned already) things that should be a given, like dynamic arrays in types, and proper ByVal string passing.
To settle on the current state of FreeBASIC is either an admission of incompetence, or ignorance, IMHO.
I'm of the belief that the QB compatibility should be scrapped, especially now that QB64 has come around. We don't have to be everything for everyone. Implicit allocation is stupid, not only having to implement all the quirks associated with it, but if you don't explicitly allocate your variables, you are an incompetent programmer. Maybe you're a good scientist/cook/envelope stuffer, but you're an awful programmer.
I also believe the compiler being written in FreeBASIC is needless pain for developers that ultimately has left us in a rut for the time being. It's like everyone wants it both ways. You say BASIC is for the newbies and C is for the pros, well here's the reality: pros are the ones who do compiler development, not newbies. This decision is killing us, I believe. I want to write the compiler in C++. At very least C, but why make our lives harder? If you just want to use BASIC, keep your nose out of how I want to allow you to be able to do that... :)
Not only would writing it in C(++) make it faster, it also removes the need for us to constantly tiptoe around chicken/egg problems, and more importantly (IMO) the fact that EVERYONE has a C compiler already on their platform. We have to cross-compile FreeBASIC to any significantly different platform we want to host on.
FreeBASIC may end up being forked. I think it's mature enough now where a fork wouldn't kill the original project. Too many people find the things I write here reprehensible, and that virtually ensures that if I were to start a new project based on what I've said, they at very least would take a while to show up. It's the nature of open source and nature in general. Evolution through natural selection is fact, and I don't see any problem with killing FreeBASIC, IF the result is a better, faster stronger language overall. GW-BASIC is dead... there's no special reason to keep it alive if everything we have now is vastly superior. It's a hard reality... so hard that people have been making up an believing stories about it for thousands of years to try to escape it.
FreeBASIC is actually a bit more closed than I'd like. Not the source code, but the site itself. No one has real access here except v1ctor. We can't make improvements or changes to the way the site works, even though it's pretty obvious me and the other devs are only here because we care about the language. I know I haven't been around much lately, but that will probably change in the near future.
The biggest thing keeping me from getting into development now is the fact that I run a 64-bit system now. I have to run a VM to do any development because there simply IS no 64-bit FreeBASIC compiler right now. I don't want to spend more time hacking on FreeBASIC slogging through the mud just so that I can bootstrap it to 64-bit and then start "real" development.
I've seen the same methods being used in a project I've been working on the last year... the idea that if we just keep hastily porting it forward, some day we'll magically be able to fix all the problems we keep carrying forward, breaking more and more. People are just afraid. It's a scary thought to start over... look how long it took for people to start on FreeBASIC after QB was long irrelevant.
I'm not content to live in fear of what will happen if we try to make a fresh start. I want to cut out all of the ugly QB-related stuff and make FB modern and intelligent. Read the posts here... I'm not the only one. If you want to stay on this and keep hoping that if we pile on fixes here and there, somehow things will change... that's fine. Just like when we gt starships and are able to leave this ruined dying planet, there will be people that stay for the most ridiculous religious reasons. I'll be on the ship off!
Ok, so I should probably note that I don't think FreeBASIC is dead at all. As many have mentioned, it would be more appropriate to classify it as a kind of stasis. We don't have any mandate to change anything more, and what's here is powerful enough to make a lot of really awesome things happen. Every language ultimately has its quirks and weirdness and pitfalls. That's great, and I'm really glad I was able to contribute as long as I did here. However, I just feel like we can do better, and I'm not just gonna close my eyes, look to the heavens and shout to you that we're there and we should accept what we have. We're not *there* yet. We can do better.
Well, somebody wants to remove QB compatibility, but someone doesn't.
Since -lang QB is already here, what do you gain by removing it?
Also, rewriting FB in C would mean a complete restart, and where's the point? Features similar to C, no full compatibility with BASIC, almost all programs/API will have to be fixed/rewritten, only developers that know C can work to it... it would be easier to switch to C.
Some die-hard programmer would stay anyway with the actual source code... and so, FB would loose part of its community, and nothing is solved .
IMHO, starting a new, different language is easier than radically change an existing one.
Instead, the idea of a fork could be good: both projects could benefit from each other, and new features could be tested and implemented. I 've suggested to do different distributions, but you are more extreme.
Since -lang QB is already here, what do you gain by removing it?
Also, rewriting FB in C would mean a complete restart, and where's the point? Features similar to C, no full compatibility with BASIC, almost all programs/API will have to be fixed/rewritten, only developers that know C can work to it... it would be easier to switch to C.
Some die-hard programmer would stay anyway with the actual source code... and so, FB would loose part of its community, and nothing is solved .
IMHO, starting a new, different language is easier than radically change an existing one.
Instead, the idea of a fork could be good: both projects could benefit from each other, and new features could be tested and implemented. I 've suggested to do different distributions, but you are more extreme.
I'd argue that the people that actually help with the compiler wouldn't have problems with C. We've proven so far that having it written in FB *doesn't* suddenly give us lots of able contributors.angros47 wrote:only developers that know C can work to it... it would be easier to switch to C.
Some die-hard programmer would stay anyway with the actual source code... and so, FB would loose part of its community
What should be done IMO, is that if people that have the skills feel like it'd be cool to have the compiler written in FB, then THAT should be the fork, and no one should care when it breaks, it'd be a toy.
Having the compiler written in C doesn't impact the language at all. The PHP interpreter is written in C. Anyone who has any pro-level skill in both those languages would NEVER state that PHP would be more like PHP if it was written in PHP, that's absurd.
EDIT: I admit my thinking is very forward, that is, I wouldn't suggest that tomorrow when you check out SVN it's a begining compiler written in C. What I'm saying is that I think that if we explore a fork, I believe it can emerge as superior, and then EVENTUALLY replace what we have now.
-
- Posts: 453
- Joined: Dec 24, 2005 2:32
- Location: WA - USA
- Contact:
This may be true for compilers but scripting languages have been traditionally typeless and I don't feel incompetent by any means. The less framework code I have to write to get the job done is being smart and doing my clients a service.Implicit allocation is stupid, not only having to implement all the quirks associated with it, but if you don't explicitly allocate your variables, you are an incompetent programmer. Maybe you're a good scientist/cook/envelope stuffer, but you're an awful programmer.
Well, to be fair, you have a point. I've done PHP development for a bit now and I've seen examples. However there's a bit of a difference here with scripting, I think. I'll give an example of what I mean:John Spikowski wrote:This may be true for compilers but scripting languages have been traditionally typeless and I don't feel incompetent by any means. The less framework code I have to write to get the job done is being smart and doing my clients a service.Implicit allocation is stupid, not only having to implement all the quirks associated with it, but if you don't explicitly allocate your variables, you are an incompetent programmer. Maybe you're a good scientist/cook/envelope stuffer, but you're an awful programmer.
"Explicit":
Code: Select all
$foo = array(3, 4); if ($foo[1]) print "hi";
(Assuming $foo hasn't been defined earlier)
Code: Select all
if ($foo[1]) print "hi";