Home | Reviews | GUIpedia | Forum | Fun500

BrandonLet's Talk

That image is taken from Google Analytics (a great service, I might add). It shows the hits to pages on the blog over the last two years, and it shows a pretty obvious trend. I don't really find the trend surprising, and I doubt many of you do either. In it's current state, the GUI blog will be non-existent in a matter of a year. The question that I ask, you the members, is what is next? Do we going in our current direction, leaving the existing projects on display and hoping someone will find them and be interested and ask questions which will spark new activity? Or does the blog need some sort of rebirth? What would this new rebirth be? How would it be more effective/ make the community more active? Would we open up the site to discussing new topics? Should it be made into a more simple site which just acts as a "Museum" of GUIs of the past? I'm just throwing thoughts out there, if anyone wants to throw some back, please feel free.		2012-07-2810:46 AM
pharoahRe:Let\'s Talk
One of the major problems is that QBasic is a hard language to develop in. I rarely start personal projects in QBasic anymore, because I spend more time working around the limitations of the language and tools than I do solving actual programming problems. QBasic's tooling sucks. The IDE becomes painful to use once you're accustomed to something that lets you see more than 25 lines of your own code at once. And since QBasic isn't object oriented, you have fewer opportunities to refactor your code, so everything becomes a long sub or function. Instead of syntax highlighting, we get automatic capitalization, which makes everything look like COBOL. The debugger in QBasic/QuickBasic is pretty limited, so nobody really uses it. There are basically no third party development tools: no debuggers, no profilers, no unit testing frameworks. There is QBMCX, which looks like it might be useful, but I haven't tried it. Even worse is the library system, which is such a puzzle that many programmers don't know how to use it at all. You're limited to one library at a time, so you have to unload the standard library in order to use a third party one. Creating your own libraries is not intuitive at all. There's a general consensus that it's often easier to reinvent the wheel than to use somebody else's code, even if that other programmer knew his or her domain better than you do. The QBasic community is full of helpful people, but this blog is an example of the most modern way the community disseminates information. Everything's old style forums where people post programming questions. This is fine, but it doesn't really support searching very well, so you end up with the same questions and answers over and over again. Code is shared by uploading it or pasting it into a forum thread. It's hard to find things that you might want to use (see previous paragraph). QB64 has many nice improvements, but it's not relevant in this context since we're talking about DOS GUIs. More to the point, however, QBasic is one of those languages that you use in order to challenge yourself with a limited language. If you wanted something nicer, you'd probably write your project in Python or Ruby or C#, or even Perl. If you were forced to use something unpleasant for practical reasons, it would probably be C++ or PHP, both of which have larger communities. That's the central challenge of QBasic programs, many people write them in order to produce "X in QBasic" instead of just "X". If you think the actual idea for your program is really great, you'd probably use something with real data structures (I mean, for fuck's sake...) or one of the other million things that help you get the program working faster. Trying to shove dynamic data structures, hash maps, linked lists, skip lists, and the like into REDIMmed QBasic arrays is like pulling your own teeth out with a pair of rusty needle-nosed pliers. From time to time, I like the challenge of developing something in QBasic, especially GUIs. I still quite frequently have ideas for things I'd like to do. But I'm absolutely sick of rewriting the same kinds of things over and over again. I think we should get together and spend a little bit of time writing developer tools that we'll enjoy using, regardless of the language they're written in. It's worth that effort now to make our projects less painful. My idea, which I've prototyped already, is to have a website that keeps collections of subs and functions which can be automatically integrated into your code. Essentially, this would be like a hacky form of CPAN. This would bypass the library system by the simple expedient of just adding crap to your source, which has its limitations but is still better than copy and paste. I'd like to know if anyone is interested in this, though, before I develop it further and release it to the public. And by interested, I mean would contribute properly formatted and documented modules of your own code to the archive. 		2012-07-291:17 AM
HorvatMRe:Let\'s Talk
Brandon: I think TGB started dying around the time you started implementing your strict forum rules. BTW, I can't log in in any browser other than Firefox - it logs me out immediately after logging in (and I have cookies enabled). I'd have replied sooner if I could log in. pharoah:
"QBasic's tooling sucks. The IDE becomes painful to use once you're accustomed to something that lets you see more than 25 lines of your own code at once. And since QBasic isn't object oriented, you have fewer opportunities to refactor your code, so everything becomes a long sub or function. Instead of syntax highlighting, we get automatic capitalization, which makes everything look like COBOL." I disagree. I think the QB IDE makes it easy to jump around code (hit F2 and choose a procedure) and the 20-something lines make you write smaller code. It's not impossible to write nicely structured procedural code, but I agree it's hard to do so in QB due to the language's lack of support for pointers and dynamic data structures (more on that later). I never use syntax highlighting, because I don't need it. If your code is not easy to read, you should blame yourself and not the editor you're using. And I think BASIC is easier to read when the reserved words are uppercase (I use CamelCase otherwise). "The debugger in QBasic/QuickBasic is pretty limited, so nobody really uses it. There are basically no third party development tools: no debuggers, no profilers, no unit testing frameworks." I disagree. The debugger is pretty good, and because QB is/can be interpreted, it's easy to debug code. I don't know about the other tools you mentioned. I prefer minimalistic IDEs. I think QB's is well-suited to the language. "Even worse is the library system, which is such a puzzle that many programmers don't know how to use it at all. You're limited to one library at a time, so you have to unload the standard library in order to use a third party one. Creating your own libraries is not intuitive at all. There's a general consensus that it's often easier to reinvent the wheel than to use somebody else's code, even if that other programmer knew his or her domain better than you do." I agree that the library system is a pain in the ass. You can merge libraries by compiling a library with a library (and I've seen a program that's supposed to make merging them easier, but it didn't look simple enough for me to use it). I write my own code (even if it's an implementation of an existing algorithm) because I simply don't trust other people's code to fit my needs. And honestly, I've never seen QB code as nicely structured and documented as mine, but that's just my opinion. "If you think the actual idea for your program is really great, you'd probably use something with real data structures (I mean, for fuck's sake...) or one of the other million things that help you get the program working faster. Trying to shove dynamic data structures, hash maps, linked lists, skip lists, and the like into REDIMmed QBasic arrays is like pulling your own teeth out with a pair of rusty needle-nosed pliers." I agree. I recently wrote a simple library that implements a wrapper over the DOS memory allocation functions. It's pretty simple to use. Maybe I should post it. I'm focusing on C now exactly because of the reasons you listed, and also because the executables aren't as slow and bloated as those produced by BASIC compilers. Maybe I should write my own compiler some day. PS: WTF, I can't use <blockquote> or <p><i>? That's ridiculous.		2012-07-297:56 AM
BrandonRe:Let\'s Talk
@Pharoah: I think that your post could more or less me summed up by saying that QBASIC is not an optimal tool. I think BASIC has the advantage of being easy to start learning, because concepts like variables/functions are easier to pick up in a system where they are written out in English. Admittedly starting with a harder language with more functionality maybe better in a long run. But what exactly does that mean for the blog? Is QBASIC dead and we should accept that? I don't know of many DOS GUIs in other languages; is DOS dead?
@Horvat: I have just now removed the formatting restrictions from the forum, it's never worked right and annoys even me. As far as log-in issues, Pharoah redid the cookie system at one point to hopefully make users stay logged-in, but idk as it's working. I use Chrome and can log-in, however I should note that both username and password are case sensitive.		2012-07-299:03 AM
HorvatMRe:Let\'s Talk
however I should note that both username and password are case sensitive. I'm posting this from IE and apparently they really are. But when I typed my username in lowercase, it still did say "Logging you in".		2012-07-2912:06 PM
BrandonRe:Let\'s Talk
I imagine that if I took the time to work out the kinks with the log-in system, that might be a start. But is that the best way forward? Is fixing this site up, and it what ways, better than using some other CMS/starting over.		2012-07-2912:16 PM
pharoahRe:Let\'s Talk
> But what exactly does that mean for the blog? Is QBASIC dead and we should accept that? I don't know of many DOS GUIs in other languages; is DOS dead? That's not exactly what I meant. Both QBasic and DOS are not practical tools to use in the 21st century. There are probably some people still running legacy DOS systems, and probably some people being paid to write QuickBasic code, but these people are patching up an old system, not writing anything new. However, the fact that a tool isn't practical doesn't mean that there's nothing to be gained from using it. After all, people still write demos for the C64. People still make furniture by hand, write novels on manual typewriters, and listen to vinyl records. These are things we do because we enjoy them, not because they get the job done in the most direct way. I know that I feel this way about QBasic, and I'm guessing that there are many people in the community who feel the same way. But that doesn't mean that everything surrounding QB development has to be such a pain in the ass as well. People who create ROMs for 8 bit machines typically do that on their own PC nowadays, and there's no reason why we should limit ourselves to the crap people had to put up with 20 years ago. > I think the QB IDE makes it easy to jump around code (hit F2 and choose a procedure) and the 20-something lines make you write smaller code. It's not impossible to write nicely structured procedural code, but I agree it's hard to do so in QB due to the language's lack of support for pointers and dynamic data structures (more on that later). If the QB IDE works for you, go ahead and use it. It's certainly not impossible to use, and I quite liked it in the past. But now that I've started to use Eclipse for Java dev (which has better integrated help and auto-suggest, admittedly something you need more of in a language like Java) and vim for everything else, I feel really boxed in when I use the QB IDE. Syntax highlighting is certainly not a necessity, but (like comments) it makes your code easier to read, even if you write the world's nicest code. There's a reason why pretty much every programming text editor, and all the modern IDEs offer syntax highlighting. But I'd be happy if I could just fit more shit on the screen. As for the site, I don't think that's really a problem. There are certainly limitations to the GUI blog, but I don't think that they're what keeps people from posting. I do agree that the formatting restrictions were a massive pain in the ass. I wish we could use markdown for our posts -- that wouldn't be too hard to integrate. 		2012-07-293:10 PM
HorvatMRe:Let\'s Talk
pharoah: But I'd be happy if I could just fit more shit on the screen. I've just remembered the /H command line parameter, which is documented as "Displays the maximum number of lines possible for your hardware.". I've just tried it in NTVDM and DOSBox and it gave me 80×50 on both. It's supported by both QBasic and QB.		2012-07-3111:05 AM
sbRe:Let\'s Talk
So I wonder if we should work together to make a new IDE for Quick Basic then?

We could still use the compilers tools (bc, link, lib)

But provide a better system to build apps. Debugging will be an issue unless we decide to completely re-implement interpreted basic, or do some weird funky things with interrupts and compiled basic. (I think it would be a fun project to re-implement basic, but thats for another time)

I think that would be an interesting project for us all to work together on, we could possibly make it a challenge, we take our existing text editors in our guis and add programming elements to it?

We should decide on the specifics for what a basic editor should do.

Projects (using .mak) Shows multiple modules (.bas) Provides some form of syntax highlighting Provides some kind of intellisense (variable info, function info, external functions from .bi, etc.) Compiles project and provides feedback (shows error lines, can jump to line, etc.)
One more thought is we can also expand the lanugage too, running it through a preprocessor, to create qbasic compatible code which is then compiled.
So you could start thinking about making an OOP version of basic :)

Anyways my thought, could be fun?
2012-08-023:11 PM
BrandonRe:Let\'s Talk
I wonder how hard it would be to port QB64's IDE code to DOS? It seemed pretty decent when I last tried QB64 a couple weeks ago.		2012-08-049:31 AM
JasonRe:Let's Talk
I think you all forgot that it's the GUI blog, and not the qbguiblog anymore. As for the blog I can't really imagine anyone breathing life back into the community. I work on GUIs still as side projects. (my QB directory resembles a car yard)

I suggest we preserve the history that has taken place over the last 15 years. It sounds like a big project, but reformatting, and getting all the relevant old posts from jacobpalm.dk and qbguiblog.uni.cc and displaying them on this site. Including all the QB GUI competition results. Maybe migrate the QB GUI reviews website here as well. I see this as being the most reasonable/realistic approach.

PS Brandon, can you let me fix the "My Profile" page?
Parse error: syntax error, unexpected '.' in /homepages/11/d157582457/htdocs/cblog/userinfoedit.php on line 44 		2012-08-0411:26 AM
HorvatMRe:Let\'s Talk
I agree. That would be great.		2012-08-059:20 AM
BrandonRe:Let\'s Talk
but reformatting, and getting all the relevant old posts from jacobpalm.dk and qbguiblog.uni.cc and displaying them on this site. Including all the QB GUI competition results. Maybe migrate the QB GUI reviews website here as well.
Jacobpalm.dk has been offline for years, where do you suggest we get content from there? And what content would you want integrated?
By qbguiblog.uni.cc I assume you mean the blog before the Joomla revamp in which case I do have a back-up I could get content from, but what content?
The Awards Page here does list all 1 & Second place finishes in all GUI Awards, but maybe that section could be expanded to include the prize images and other announced places?
Integrating the GUI reviews site is a neat idea, that more or less could be done by anyone, right now. For each GUI that is on the review site, download it, and save the image and the review. Then here sign-up the GUI upload it and the screenshot and save Todd's review. It'd be a lot of work, and that's why no one has done it, I moved a few of my favorite GUIs over (without the reviews) but don't have time to move everything.
I like the idea, to make this site a place where the history of QB GUIs can be displayed, and I think the current site "CMS" could handle it fine, although maybe with some tweaks. 		2012-08-059:52 AM
JasonRe:Let\'s Talk
i { color: #aaeeff; } I agree. That would be great.
If that was directed at me, thank you. :) Jacobpalm.dk has been offline for years, where do you suggest we get content from there? And what content would you want integrated?
Internet Archive By qbguiblog.uni.cc I assume you mean the blog before the Joomla revamp in which case I do have a back-up I could get content from, but what content?
Interesting posts, articles, I recommend including information from the Joomla times aswell Integrating the GUI reviews site is a neat idea, that more or less could be done by anyone, right now. For each GUI that is on the review site, download it, and save the image and the review. Then here sign-up the GUI upload it and the screenshot and save Todd's review. It'd be a lot of work, and that's why no one has done it, I moved a few of my favorite GUIs over (without the reviews) but don't have time to move everything.
I'd write a PHP script to scrape the site, however, I'd rather scrape the database, as Todd has obviously used one. I like the idea, to make this site a place where the history of QB GUIs can be displayed, and I think the current site "CMS" could handle it fine, although maybe with some tweaks.
Sweet, I may hopefully contribute after I finish these monetised projects		2012-08-0510:13 PM
pharoahRe:Let\'s Talk
I don't know about this plan to aggregate all the old blog stuff. It doesn't seem to be worth the effort. It would be one thing if these older communities were no longer online, but I can still visit them if I want to see something. The joomla forum is still online, as is Todd's website. Spending a bunch of time scraping all this disparate data into a new ephemeral hacked together format holds very little appeal, and it does nothing to improve the quality of the community we have now. As for the whole QB GUI blog vs GUI blog thing, let's be honest and state that this is primarily a QB community. There's nobody here who hasn't been a Qbasic or QuickBasic programmer at some point in the past, and using a more powerful language is considered "cheating" for the purposes of demoing things here. With regard to the developer tools, I've been looking a bit more at QBMCX, and I'm definitely impressed. The only thing I'd say it lacks is recursive preprocessing. I'm also thinking of writing a simple unit testing framework, and something that instruments your code so that you can play back runs for debugging purposes like Chronon does. Unfortunately, it's hard to find time for such projects now that I'm closer to being a part of the real world.		2012-08-0811:44 PM

Blog

2021 Brandon Cornell