Console application worthless?

Pages: 123
closed account (3hM2Nwbp)
Sure, cout << "Image Description"; and App.Draw(Image); are about equally as difficult to use. That's as hard as the console gets, but let's not forget about the shading, transformations, rotations, interpolation, meshes, textures, particle effects, etc, that are involved with graphics. It should be well stated that while graphics programming may be just as easy as the console in the beginning, it will become much more difficult than the console eventually...it's a little misleading to say that graphical programming in general is just as easy as the console imo.

$.02
Edit- Not directly or indirectly directed @ any posts here.
Last edited on
1
2
3
4
5
6
7
I prefer console applications :)

unoriginal wrote:
Because, console applications have nearly died out.


This is a fantastically ignorant comment that actually means "I use console applications all the time, but because I only see a GUI, I assume GUIs are all there is." 


It is not a comment; it is a factual statement. Right now, you're using a GUI for posting and remarking just like I am.
Why would you want to use 16 bit applications where you cannot even display images and all colours properly?
I see no point in going back in time; for I am no historian nor do I wish to be.

The only time when you'll use console applications is when building boot strap loaders and low level GUIs where development has just begun or resources are scarce. You can see this on many Linux systems.

When your computer starts, it doesn't load the GUI right away, you have to use the "console" application or boot loader which is running (GRUB on modern Linux systems). In that case, it is acceptable.

But otherwise, would you write console applications? If yes then are you sure your customers will buy it compared to those fancy GUIs which everyone is so used to?

I, sir, dare you to post back using LYNX. A command line tool for accessing and browsing web pages.
You know, you won't be able to. Why? Because you can't. Don't you love your console applications?
Your customers will love it even more.
Well, the point here was to use console applications for practise and maybe small programs that you may find useful, not for selling them.
@unoriginal
The whole point is to LEARN C++ USING CONSOLE APPS, not creating console apps for sale. I don't think anyone can deny the fact that 99% of console applications won't make you any money to live off of if you're selling them. The purpose of console applications in this sense is to have a simple and very short code to teach certain aspects of the language.
@unoriginal
To be honest I think your statements are ridiculous. You assume that all the programs one makes are professional applications to be sold. My experience shows that it is completely untrue. Besides, I know a few commercial console applications (often hidden after some kind of GUI, but still). We may not live in 70ies, but it doesn't mean that every program you make must have 3D graphics with per-pixel lighting.

Most of the programs I make are console applications. If you make a short utility program then it is simply stupid to waste 2x time to make a pretty GUI for it. Testing some concepts, algorithms, libraries you make is usually easier to do in the console environment. Apart from that, creating GIU is usually boring.
Last edited on
unoriginal wrote:
It is not a comment; it is a factual statement. Right now, you're using a GUI for posting and remarking just like I am.
Why would you want to use 16 bit applications where you cannot even display images and all colours properly?
I see no point in going back in time; for I am no historian nor do I wish to be.


It's not really a factual statement, for one console apps haven't been strictly 16 bit for quite a while. The question is whats best for the job/problem. If your writing a business app to be used by an end user you would probably want an easy to use GUI, but you wouldn't write a GUI for a daemon would you? And lynx is VERY useful. For me personally, I feel learning the console first has helped me understand the language, but that's me. Some people need to see the results of their work to feel motivated to continue learning.
CMD.EXE and the *Nix CLI are NOT 16-bit and niether have been for more then a decade. In both cases they run as shells for the host app. For Windows this is possible because of a module called "WOW" or "Windows on Windows" that intercepts and translates most 16-bit commands for use on newer systems.

As for always using a GUI, I personally don't put on a suit and tie when I got to the gorcery store to buy eggs; ALSO the CLI was not included to "educate" new users. Why would I write a GUI for an application that checks when the last time a PC on my network was rebooted for example? So that I can navigate to the folder, find the icon, then scroll through a list of 200+ machines to find the one that I want, select it and press "GO"? Not to mention having to query my network and enumerate the systems so that you can HAVE a functional GUI to begin with. FTS,
Start -> Run -> NameOfApp NameOfSystem
and poof I have my results. No enumeration of systems on my network I simply use the UDP path to the pagefile on the target system if(!Exist){std::cout << ErrorCode();}. Do you want to know the status on multiple systems? The GUI method would have me finding and selecting every individual system I want to know about. The CLI is
Start -> Run -> NameOfApp @ ListOfSystems.txt
.

I'm not saying your completly wrong unorigional, you seem to be more experianced then you are letting us think you are. I also agree with you that marketability of an appication is the number one aspect that you should be concerned with if that's the direction you are going. But always consider your options and choose the right tool for the job.
Last edited on
Ever heard of grep?
unoriginal wrote:
Don't you love your console applications? Your customers will love it even more.


If I turned everything I work on at work into a GUI, the customers would refuse to accept it and wouldn't pay. All your experience is probably in the colourful world of GUIs. I work elsewhere, where serious workhorse programmes have no need for a GUI and to add one would be unwanted and unwelcome.

I'm not calling you Sir because I think you're ignorant and close-minded, refusing to accept that the pretty colours on your screen are not the only kind of output that someone might find useful.

unoriginal wrote:
Why would you want to use 16 bit applications where you cannot even display images and all colours properly?


I generally write 64 bit applications which don't show images or colours, because there are no images to show and when you're not putting anything to screen the concept of colour is somewhat irrelevant.


Last edited on
Attention all participants,

This is just a friendly reminder that the compiler you are using is probably a console program. Thank you.

-Albatross
This is just a friendly reminder that the compiler you are using is probably a console program.


Are there any compilers that aren't console programmes? I'd be quite surprised.
I don't know, though I don't think so. The VS compiler is a console program, GCC is as well, clang is too, Sun Studio's C++ compiler is, Borland C++ (and derivatives) are, Watcom C++ is, Digital Mars C++ is...

-Albatross
In *nix systems (and sometimes even in windows), GUI applications are often a combination of a console application and a graphical front end, sometimes written by a completely different developer. Examples include various file managers, package managers, configuration tools, FTP clients, BitTorrent clients, archive managers, network managers, etc. Console application are definitely still alive.
What I said holds true for my case. Reminiscing, I can still recall that my first console application was deigned "worthless".
It was because much better menu driven GUIs alternatives were available which not only looked pretty but were easier to use.

Also, I did use BCC (Borland C++ Compiler) for a short while. Now I simply let my IDE handle the compilation part.

I cannot seem to agree with you, for it seems our perspective of how programs should appear differs immensely.
Also, contrary to what above has been said. You need not always select something from 50,000 items via a menu or through intense scrolling in GUI.

A new innovation which my group proposed to use in future programs was to entwine GUI with CLI. A similar technology is underway which is being called ZUI -- the next big thing ("Zooming User Interface").

Still, pure CLI is something that I just cannot make a profit with. Let's just hope ZUI brings the better out of both CLI and GUI, apart from the completely new "Zooming" feature which is supposed to kill the Windowing system entirely.

[Edit:]
Pardon me, It seems I have unintentionally strayed from the main topic. As far as learning in C++ goes, I strongly discourage C++ as the first language.
If it is not the first language, then, as the Disch user pointed out: using cout/printf and cin/scanf is just as easy as using any other library input/output function.
Last edited on
My take is for normal end users they definitely prefer GUI. For developers, CLI is best. I don't think developers really have a need to have GUI unless it is for some specialized tasks. Using CLI is good for trouble-shooting bugs when the executable does not execute to what we expect.
unoriginal wrote:
I cannot seem to agree with you, for it seems our perspective of how programs should appear differs immensely.


I believe the program should appear in the way most suitable for performing its task(s). Sometimes this is a GUI, sometimes this is a command line, sometimes it's completely invisible, sometimes it's a handful of LEDs and a serial port to monitor, sometimes it's weird and wonderful interfaces I've never even considered.

sohguanh wrote:
My take is for normal end users they definitely prefer GUI.


Where, presumably, you define a "normal end user" to be someone using a desktop PC with a standard, widespread graphical operating system? That's the most visibly obvious kind of user, but "normal"? I'd disagree.

Last edited on
this is getting ridiculous. this thread is going nowhere at this point. close perhaps?
Topic archived. No new replies allowed.
Pages: 123