Using the console for something other than CLI
Pages: 12
Why do so many newbies want to do this? What is the appeal? Is it just because they were introduced to the console with cout/cin and are too scared to move away from it? Do they just not realize what the console is for?
I'm seeing all these absurd questions like "how do I change the text color" or "how do I clear the screen", etc. When there's little practical reason to do either in console programs (I can see changing color for highlighting different kinds of output, like the ls command, but I can't think of a practical use for clearing the screen).
Every time I see one of these posts, I want to scream out "you shouldn't be using the console for this", but it either falls on deaf ears, or is outweighted by people actually answering the asked question. Ultimately I end up feeling more like a jerk for saying it rather than being helpful.
What makes me even more sad is I'm seeing more and more of Windows-specific console stuff in "solutions" to these problems. Lots of people posting in the newbie board, showing code that includes HANDLEs and GetStdHandle calls. Makes me cringe every time I see it.
Is it wrong of me to tell people to leave the console? Should we, as a community, be encouraging this behavior? Wouldn't it be better if we pointed people in the right direction, rather than encouraging them and helping them go in the wrong direction? Why should we be teaching them techniques that they'll outgrow and never use again once they realize the console is dumb for this kind of thing? Isn't it just a waste of everyone's time and energy?
I'm seeing all these absurd questions like "how do I change the text color" or "how do I clear the screen", etc. When there's little practical reason to do either in console programs (I can see changing color for highlighting different kinds of output, like the ls command, but I can't think of a practical use for clearing the screen).
Every time I see one of these posts, I want to scream out "you shouldn't be using the console for this", but it either falls on deaf ears, or is outweighted by people actually answering the asked question. Ultimately I end up feeling more like a jerk for saying it rather than being helpful.
What makes me even more sad is I'm seeing more and more of Windows-specific console stuff in "solutions" to these problems. Lots of people posting in the newbie board, showing code that includes HANDLEs and GetStdHandle calls. Makes me cringe every time I see it.
Is it wrong of me to tell people to leave the console? Should we, as a community, be encouraging this behavior? Wouldn't it be better if we pointed people in the right direction, rather than encouraging them and helping them go in the wrong direction? Why should we be teaching them techniques that they'll outgrow and never use again once they realize the console is dumb for this kind of thing? Isn't it just a waste of everyone's time and energy?
Creating cool looking console programs the way beginners do when starting with C++ is useless but any program written by a beginner would have no other uses than practice for them
When making a TUI is sometimes useful to clear the entire screen
| I can't think of a practical use for clearing the screen |
Now, hold on a moment. While I do agree that there are better console interfaces than CUI, such as command line arguments, I think saying that the console shouldn't be used for X, when X is "putting characters at specific positions in a rectangular matrix", is going a little too far. That may not be the correct use of a standard stream, which, since it's unknown what it's abstracting (a console? A file? A printer?), should always be treated as a stream of bytes; but it's certainly how the console is supposed to be used, if you know it's there.
But I do wonder why so many people want to clear the screen. My first guess is that they come from a language that includes console manipulation routines, such as BASIC (CLS and LOCATE, most importantly).
I also think we should avoid giving platform-specific solutions, specially to beginners. For two reasons:
1. As I've said before, it defeats the purpose of using a portable language. Understandably, not everyone will agree with me on this. I just put a lot of emphasis on portability, since I don't like doing the same thing twice.
2. If we give them solutions that require an external library, that will push beginner in one of two paths: they will either try and use it, thereby learning how to use libraries, or they will stick to writing simpler interfaces, at least until they are able to use libraries.
But I do wonder why so many people want to clear the screen. My first guess is that they come from a language that includes console manipulation routines, such as BASIC (CLS and LOCATE, most importantly).
I also think we should avoid giving platform-specific solutions, specially to beginners. For two reasons:
1. As I've said before, it defeats the purpose of using a portable language. Understandably, not everyone will agree with me on this. I just put a lot of emphasis on portability, since I don't like doing the same thing twice.
2. If we give them solutions that require an external library, that will push beginner in one of two paths: they will either try and use it, thereby learning how to use libraries, or they will stick to writing simpler interfaces, at least until they are able to use libraries.
I intend to answer this question with my (upcoming) article on Types and purposes of console applications, but for now see the following links:
http://www.cplusplus.com/forum/beginner/1988/page2.html#msg10636
http://www.cplusplus.com/forum/beginner/1988/page4.html#msg14423
http://www.cplusplus.com/forum/beginner/1988/page2.html#msg10636
http://www.cplusplus.com/forum/beginner/1988/page4.html#msg14423
| When making a TUI is sometimes useful to clear the entire screen |
I guess I just don't see the point of making TUIs in the modern world (it's 2009 for crying out loud! It's not the early 90s anymore). Except for very low level stuff (like if you're writing BIOS or something). And that's beyond the capabilities of newbies anyway.
| I think saying that the console shouldn't be used for X, when X is "putting characters at specific positions in a rectangular matrix", is going a little too far |
I think that's an oversimplified assessment. I'm pretty sure that X is not "output characters on a grid", but rather "draw a map for my game". To which the newbie thinks the solution to that is "output characters on a grid" -- but in reality there are many better solutions to this problem.
closed account (z05DSL3A)
I have started a reply several times but canceled them because I my head I run through the arguments and counter arguments.
I guess the conclusion I have come to is that, on the one hand you are correct, but on the other hand you could be missing the point.
For example, little Johnny has been asked, for his course, to do a student marks program. The aim of the program is to give the student some practice at a certain aspect of C++. Now little Johnny decides that it would look neater to clear the screen, between menu options, and asks for advice on how to achieve this on a forum. While technically it is better to tell little Johnny that he should use a more appropriate user interface, is it the correct approach to helping him? It is kind of like school level physics, when they tell you about centrifugal force knowing that is is wrong but at that level that is what you can handle without going into higher level physics (or just things you have not learnt yet).
I guess the conclusion I have come to is that, on the one hand you are correct, but on the other hand you could be missing the point.
For example, little Johnny has been asked, for his course, to do a student marks program. The aim of the program is to give the student some practice at a certain aspect of C++. Now little Johnny decides that it would look neater to clear the screen, between menu options, and asks for advice on how to achieve this on a forum. While technically it is better to tell little Johnny that he should use a more appropriate user interface, is it the correct approach to helping him? It is kind of like school level physics, when they tell you about centrifugal force knowing that is is wrong but at that level that is what you can handle without going into higher level physics (or just things you have not learnt yet).
Last edited on
closed account (S6k9GNh0)
I would say the only reason I don't like Window based apps is because they become complex and hard to manage. Of course this becomes easier with time and knowledge.
Last edited on
Grey Wolf: That's a valid point. I wonder how often that's the case though. I just get the impression that most of the people asking these questions are exploring because they want to apply what they've learned on something they want to do (like a game -- which seems to be the most common drawing point), rather than them just trying to beef up their homework assignment. But this is all total speculation on my part.
computerquip: I'd strongly disagree. I actually started C++ with windows based programs using MFC (and C++ was my first language). It's not nearly as hard for beginners as it's commonly perceived to be. At the time I wanted to avoid console like the plague (had an dislike of it from day 1 XD).
In fact to this day I don't fully know/understand how to use cin, really (I get the jist, obviously -- but all the little details I'm still fuzzy on). I never needed to. I'm still not convinced I made the wrong decision.
Also -- consider that several "easier" languages like VB throw you into GUI programming right away. I don't think it's that GUI programs are conceptually difficult -- I think it's just that making GUI programs in C/++ takes a bit more effort -- and that's mainly because the APIs are fugly.
Though I recall getting in a similiar discussion as this before -- claiming that newbies should start with a lib like SDL or allegro rather than starting with the console. *shrug*
computerquip: I'd strongly disagree. I actually started C++ with windows based programs using MFC (and C++ was my first language). It's not nearly as hard for beginners as it's commonly perceived to be. At the time I wanted to avoid console like the plague (had an dislike of it from day 1 XD).
In fact to this day I don't fully know/understand how to use cin, really (I get the jist, obviously -- but all the little details I'm still fuzzy on). I never needed to. I'm still not convinced I made the wrong decision.
Also -- consider that several "easier" languages like VB throw you into GUI programming right away. I don't think it's that GUI programs are conceptually difficult -- I think it's just that making GUI programs in C/++ takes a bit more effort -- and that's mainly because the APIs are fugly.
Though I recall getting in a similiar discussion as this before -- claiming that newbies should start with a lib like SDL or allegro rather than starting with the console. *shrug*
closed account (S6k9GNh0)
Well the main purpose beginners starting with console is because it's simple. I can easily make a two line Hello World program but I can't make a two line GUI program. If they start with a GUI library or start coding in the WinAPI they'll start asking questions about things they don't understand which would be just about everything. Or maybe not and simply not understand exactly what they're doing.
Last edited on
Well I don't want to derail myself here. I'm not saying that newbies should start with GUI programs (at least, I'm not making that argument in this thread).
Just a random off-topic question @ grey wolf: what is the problem with centrifugal force?
closed account (z05DSL3A)
It does not exist. ;0)
http://phun.physics.virginia.edu/topics/centrifugal.html
http://phun.physics.virginia.edu/topics/centrifugal.html
| I guess I just don't see the point of making TUIs in the modern world (it's 2009 for crying out loud! It's not the early 90s anymore). |
Saying that the console is obsolete is preposterous.
| I think that's an oversimplified assessment. I'm pretty sure that X is not "output characters on a grid", but rather "draw a map for my game". To which the newbie thinks the solution to that is "output characters on a grid" -- but in reality there are many better solutions to this problem. |
| In fact to this day I don't fully know/understand how to use cin |
| Also -- consider that several "easier" languages like VB throw you into GUI programming right away. |
| I don't think it's that GUI programs are conceptually difficult |
The point I'm trying to make here is that, IMO, it's a mistake to have the programmer and the GUI designer be the same person, and the reason for that is that programmers don't have a very good sense of aesthetics. Or at least not one that matches with that of normal human beings. I think VB only encourage giving the programmer more responsabilities than he should have.
| I think it's just that making GUI programs in C/++ takes a bit more effort -- and that's mainly because the APIs are fugly. |
closed account (S6k9GNh0)
Now that I think about it, a lot of server based operating systems are command based and almost all of linux operating systems are console based. X is an addon.
| I can't agree with this. <4 points> |
point 1: I realize this. I never meant to say console is worthless. I meant to say it's the wrong medium for these types of programs. Learning how to hack together a TUI on the console is a waste of time because you have to learn to do things that are ultimately useless when you eventually move away from the console. Nevermind that most of the solutions are nonportable (so "most systems have a console" argument is moot -- since you can't code the same on any/all of them).
It dawns on me that we might be thinking of different things here. If you're referring to programs that prompt for user input and act on it -- I don't object. It certainly is much simpler to throw together a functional app that way.
http://en.wikipedia.org/wiki/File:Fdedit.png <--- This is the kind of thing I'm saying should not happen any more. In effect, this is what these people are asking how to do. It's completely pointless.
point 2,3: I agree. This is countered by the cons that it doesn't benefit from default/custom user behaviors of the desktop manager (tabbed controls, keyboard shortcuts, etc, etc). The console does not play well with others. Though this is a separate point.
point 4: You go on to mention later in your post that programmers are bad UI designers. Ever think these two might be connected? I talk to people on IRC who insist on using the commandline for everything (some guy uses bash instead of a file manager -- how insane is that!). These people are the exception to the rule, and if you're programming with the intent of having anyone else ever use any of your programs, you probably should not be doing this.
Programs made this way seem cheap, are often hard to use, and are not very appealing to end users.
| Saying that the console is obsolete is preposterous. |
I never said this.
| I don't think it needs to be said what kind of disasters happen when you have a programmer as your GUI designer |
We must live in different worlds. I have always had the impression that the professional world and the hobbyist world are completely different.
Most of the programs I use are extremely user friendly, have fantastic UIs, and were made by a small handful of people (all programmers). It's like this everywhere in the hobbyist world. Yeah there are some poor designs, but to say a programmer can't be a UI designer is a little... well... silly? I design the UIs for all the programs I write and I receive a lot more compliments on them than I do complaints (people even often jest that I should write new versions of Y program because they don't like the interface).
Maybe professional programmers just aren't as good? *shrug* That seems to be the impression I get repeatedly across a myriad of topics. Even in commercial software -- a lot of times (but not everywhere, mind you), if you look in the right places, the commercial stuff isn't any better (and is often worse) than the stuff made by hobbyists that you can get for free.
Talk about a tangent topic, though. Wshew!
| Well, sure, you can always just leave buttons unaligned, undescriptive or misleading labels, poorly thought-out menu bars, and randomly tab-ordered controls, and it will be semi usable. To you, that is. |
I agree that bad UI design is bad. But your solution is to have no GUI? I fail to see how that isn't a million times worse.
Reminds me of those old text based games where you had to type in "move east" and stuff to move around. I never understood how anybody could play those.
| if you're programming with the intent of having anyone else ever use any of your programs, you probably should not be doing this. |
Remember that you are complaining of beginners who make CUI as exercise, their programs would never be used by anyone
Reminds me of those old text based games where you had to type in "move east" and stuff to move around. I never understood how anybody could play those. |
I like those games!
| It's completely pointless. |
https://fermilinux.fnal.gov/distribution/slf-5/installation/large/installation.method.text.png
Also take a look at this: http://img132.imageshack.us/my.php?image=20090522.png
I don't even want to think how long it would've taken me to write that as a GUI. Just a few lines for PDcurses and I was done. And it works freakin' everywhere.
| I talk to people on IRC who insist on using the commandline for everything (some guy uses bash instead of a file manager -- how insane is that!). |
| These people are the exception to the rule, and if you're programming with the intent of having anyone else ever use any of your programs, you probably should not be doing this. |
| We must live in different worlds. (And all the rest.) |
| I agree that bad UI design is bad. But your solution is to have no GUI? |
Sometimes terrible GUI is worse than no GUI at all. If it's going to be a horrible unusable interface, leave me with just a text editor and a command line compiler.
| Reminds me of those old text based games where you had to type in "move east" and stuff to move around. I never understood how anybody could play those. |
Last edited on
Eh, I'll throw in my $0.03.
I'm in education circles, and the vast majority of "how do I clear the screen" questions are little Johnnys'. You have to give lil'J credit -- he's trying to go above and beyond the assignment to make his program look neat.
Those others who actually want to make videogames and the like ask things like: how do I change colors, move the cursor, make the cursor invisible, get input one key at a time, and even "make a video game", and are quickly led to things like <conio.h> (ack!) and NCurses and the Windows Console API.
The standard I/O streams are streams like any other file... you can read and write them and apply fancy formatting to them. Handling I/O is a very important part of writing any program. The problem is, of course, how we perceive the standard streams as somehow 'different' than other streams.
Knowing how to use formatting functions on streams is a worthwhile goal -- a very important one -- and should not be minimalized because cin is the principal exemplar of such streams. Remember, cin and cout (and cerr, of course) are analogous to C's scanf() and printf() -- the C++ std::iostreams do formatted I/O.
Why is handling the standard streams such an important concept? Much of it has to do with the history of the Unix operating system(s) and its revolutionary way of handling I/O: every program gets access to predefined and already opened I/O streams, which default to the user's terminal (tty) but can be redirected to any file or device. This is power! Programs instantly became simpler, portable, and retargetable. This kind of flexibility was quickly recognized and almost every other OS scrambled to update -- and new OSs had it in the protodesign -- to use this paradigm.
Of course, when you really do want to control the console (games, TUI text editors, etc), that becomes another consideration. Which leads me to the underlying question in this discussion (as I see it, of course) that helios touched on.
The idea that UI design is hard is an entrenched one, but false. The problem is that programmers are only taught how to make things happen, but I've never even heard of a class to consider the hows and whys of User Interface design. (Run away! Run away!)
If you are braver than King Arthur (or if you've never seen Monty Python -- shame), the difference is simple:
programmer - program does X, Y, and Z with algorithms A, B, and C.
user - program does Q when I press button N.
LOL. Yes, I'm talking about the same program.
Users don't see or understand the internal workings of your program. All they know is, given what they are looking at (your application's window or console prompt), what do they expect to happen when they do N?
You, as the programmer have only to to learn to correlate the user's expectations with the functional aspects of your program.
Granted, this does take a little getting used to, but it is not difficult. It only takes a little help and imagination. Look here at the Wikipedia.
http://en.wikipedia.org/wiki/User_interface_design#Processes
Notice how much attention is given to the user's point of view:
Which is just a simple way of saying -- What does the user think my program will do? How does the user expect to interact with my program? And does my program do what the user wants it to do?
Don't take my word for it. (Thanks Levar Burton!)
Controlling Your Environment Makes You Happy by Joel Spolsky
http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html
Effective User Interface Design by Ray Konopka
Foo. I've spent a good while looking for this online. Apparently he now offers this knowlege as a product and I can't find a link to his original paper. Alas. If you want it, PM me and I'll email you a copy.)
The Art of Unix Usability
Chapter 2. History: A Brief History of User Interfaces by Eric Raymond
http://www.catb.org/~esr/writings/taouu/html/ch02.html
First Principles of Interaction Design by Bruce Tognazzini
(This is a detailed recap of the points made in the Wikipedia article)
http://www.asktog.com/basics/firstPrinciples.html
User Interface Hall Of Shame (with links to the Hall of Fame)
http://homepage.mac.com/bradster/iarchitect/shame.htm
Here are some good links for more reading
http://www.ambysoft.com/essays/userInterfaceDesign.html
http://www.sylvantech.com/~talin/projects/ui_design.html
http://www.ibm.com/developerworks/library/us-myth.html
And here's a little humor for those who got this far:
http://toastytech.com/guis/uirant.html
Whew. That's all I've got. (For now...) ;-]
| Why I want to CLS |
I'm in education circles, and the vast majority of "how do I clear the screen" questions are little Johnnys'. You have to give lil'J credit -- he's trying to go above and beyond the assignment to make his program look neat.
Those others who actually want to make videogames and the like ask things like: how do I change colors, move the cursor, make the cursor invisible, get input one key at a time, and even "make a video game", and are quickly led to things like <conio.h> (ack!) and NCurses and the Windows Console API.
| Ack! cin! |
The standard I/O streams are streams like any other file... you can read and write them and apply fancy formatting to them. Handling I/O is a very important part of writing any program. The problem is, of course, how we perceive the standard streams as somehow 'different' than other streams.
Knowing how to use formatting functions on streams is a worthwhile goal -- a very important one -- and should not be minimalized because cin is the principal exemplar of such streams. Remember, cin and cout (and cerr, of course) are analogous to C's scanf() and printf() -- the C++ std::iostreams do formatted I/O.
Why is handling the standard streams such an important concept? Much of it has to do with the history of the Unix operating system(s) and its revolutionary way of handling I/O: every program gets access to predefined and already opened I/O streams, which default to the user's terminal (tty) but can be redirected to any file or device. This is power! Programs instantly became simpler, portable, and retargetable. This kind of flexibility was quickly recognized and almost every other OS scrambled to update -- and new OSs had it in the protodesign -- to use this paradigm.
Of course, when you really do want to control the console (games, TUI text editors, etc), that becomes another consideration. Which leads me to the underlying question in this discussion (as I see it, of course) that helios touched on.
| What? You want UI design too? |
The idea that UI design is hard is an entrenched one, but false. The problem is that programmers are only taught how to make things happen, but I've never even heard of a class to consider the hows and whys of User Interface design. (Run away! Run away!)
If you are braver than King Arthur (or if you've never seen Monty Python -- shame), the difference is simple:
programmer - program does X, Y, and Z with algorithms A, B, and C.
user - program does Q when I press button N.
LOL. Yes, I'm talking about the same program.
Users don't see or understand the internal workings of your program. All they know is, given what they are looking at (your application's window or console prompt), what do they expect to happen when they do N?
You, as the programmer have only to to learn to correlate the user's expectations with the functional aspects of your program.
Granted, this does take a little getting used to, but it is not difficult. It only takes a little help and imagination. Look here at the Wikipedia.
http://en.wikipedia.org/wiki/User_interface_design#Processes
Notice how much attention is given to the user's point of view:
| User interface design requires a good understanding of user needs. |
Don't take my word for it. (Thanks Levar Burton!)
Controlling Your Environment Makes You Happy by Joel Spolsky
http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html
Effective User Interface Design by Ray Konopka
Foo. I've spent a good while looking for this online. Apparently he now offers this knowlege as a product and I can't find a link to his original paper. Alas. If you want it, PM me and I'll email you a copy.)
The Art of Unix Usability
Chapter 2. History: A Brief History of User Interfaces by Eric Raymond
http://www.catb.org/~esr/writings/taouu/html/ch02.html
First Principles of Interaction Design by Bruce Tognazzini
(This is a detailed recap of the points made in the Wikipedia article)
http://www.asktog.com/basics/firstPrinciples.html
User Interface Hall Of Shame (with links to the Hall of Fame)
http://homepage.mac.com/bradster/iarchitect/shame.htm
Here are some good links for more reading
http://www.ambysoft.com/essays/userInterfaceDesign.html
http://www.sylvantech.com/~talin/projects/ui_design.html
http://www.ibm.com/developerworks/library/us-myth.html
And here's a little humor for those who got this far:
http://toastytech.com/guis/uirant.html
Whew. That's all I've got. (For now...) ;-]
| https://fermilinux.fnal.gov/distribution/slf-5/installation/large/installation.method.text.png |
This is obviously something too low level to have a GUI (before the desktop manager starts), and therefore a TUI is a necessary evil (but certainly not the ideal choice). This is not the kind of project newbies are asking about. Perhaps I shouldn't speak in absolutes, but my intention was that newbies should not be seeking to write programs like these.
Would you want to something like that in a terminal in your desktop environment, though? I sure wouldn't.
| http://img132.imageshack.us/my.php?image=20090522.png |
While that is certainly functional, it's better to have a progress meter like the ones present in virtually all mainstream torrent clients (see uTorrent, Transmission, etc). I'm too lazy to find and download a bunch of torrents so I can take a screenshot, so here's the first pic I got from google (but probably not the best pic I could've gotten -- but you get the idea):
http://www.snapfiles.com/screenshots/uTorrent.htm
I can see wanting to throw something quick-n-dirty like this together for your own personal use, but if you're intending for others to use this, then this is a poor design decision.
Also this kind of thing isn't really hard to do with widget libs. Yes it takes more code, but I certainly wouldn't call it difficult. And to be honest -- for my own personal use -- I'd rather go through the little extra work to make a proper GUI for something like this than have that console display. But I guess that's a personal preference thing (I really do hate having to deal with the console -- I guess since you don't mind it so much you don't have a problem with these kinds of programs)
| There are many situations where a command line is far more efficient (from the human's, not the machine's, point of view) than a file manager, particularly in unices |
Yes, but for everything? He literally uses no file manager at all. If you don't think that's crazy, then you must be equally crazy. =P
At least that's what he said. I'm still not sure if I believe him.
| Yes! See my comment on RPG Maker's interface here |
Touche. I can't say I disagree with your points there -- I have a deep distaste for game makers -- but they're very popular among end users that just want to make a game. It seems that most of the homebrew games I've tried were either made with Game Maker, RPG Maker, Multimedia Fusion, Flash, or some other similar kind of program. Flash, in particular, has a ginourmous game-dev scene -- and while it certainly isn't "no programming required", it does have a heavy "point and click" design interface.
I guess that's the "great divide" with computer users.
Though I can't really say I disagree with you here. That's a very extreme example of GUI gone horribly wrong.
| In case you don't know, those are still being made, and engines are still being written to make them. Just a while ago one called Inform 7 came out. |
I have no doubt. This is the internet, after all. Though I suspect the only people that play those games now are those who grew up playing them. I could be wrong though. I just never understood how people could play those games -- but I know they did (and still do, apparently).
Duoas: I may have completely misunderstood your post, particularly the last part, but are you suggesting programmers should be taught to design UIs?
I could maybe see that as one class in Software Development, or "Engineering" as they like to call it, but honestly, I don't see why programmers should be concerned with how the user interacts with the application. Okay, that doesn't sound quite right. What I mean is, the UI designer should know how to program (or not, depending on the development environment), but the programmer shouldn't necessarily know how to design UIs.
I sometimes make the programs I distribute, intentionally harder to use. It encourages users to read the documentation. This is particularly easy, for example, by writing a command line interface for Windows. If they can't figure out they have to call program.exe {|-?|-h|--help} (notice how windows commands like COPY conventionally use slashes for switches and I use dashes?) to get help, then they have no business using my code. >:-)
That's exactly the difference between you and me. I really don't care about how I give orders to the computer as long as I can get the job done as fast as possible. In these past five years, I've only encountered a handful of problems I couldn't solve as effectively with the console than with a GUI. The ones I did find involved displaying pictures, so there really was no way out.
Haha. I guess I am. :-)
Since I usually end up using the keyboard on graphical environments, I don't see that much of a difference between 80x50 and 1280x1024. Except for all the nice pictures and more text fitting in the screen, that is.
EDIT: By the way, suppose you want to search for items in a database based on tags, which of these two do you prefer?
"tag0 OR tag1 tag2 -tag3"
OR
"(tag0 | tag1) & tag2 & !tag3 | Tag*"
I could maybe see that as one class in Software Development, or "Engineering" as they like to call it, but honestly, I don't see why programmers should be concerned with how the user interacts with the application. Okay, that doesn't sound quite right. What I mean is, the UI designer should know how to program (or not, depending on the development environment), but the programmer shouldn't necessarily know how to design UIs.
| I can see wanting to throw something quick-n-dirty like this together for your own personal use, but if you're intending for others to use this, then this is a poor design decision. |
| I really do hate having to deal with the console -- I guess since you don't mind it so much you don't have a problem with these kinds of programs |
| Yes, but for everything? He literally uses no file manager at all. If you don't think that's crazy, then you must be equally crazy. =P |
Since I usually end up using the keyboard on graphical environments, I don't see that much of a difference between 80x50 and 1280x1024. Except for all the nice pictures and more text fitting in the screen, that is.
EDIT: By the way, suppose you want to search for items in a database based on tags, which of these two do you prefer?
"tag0 OR tag1 tag2 -tag3"
OR
"(tag0 | tag1) & tag2 & !tag3 | Tag*"
Last edited on
Pages: 12