This week's book giveaway is in the Reactive Progamming forum. We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line! See this thread for details.
What makes you say that people don't use console? I use the console all the time.
posted 3 years ago
almost all applications are now GUI but are there companies still using console? And what is the advantage of using console ahead of GUI and why is console still relevant in most programming language. I don't understand, and am curious to know
IMO, most of the people use console for the programs at initial stage until they understand the basics of language. I really adore to use console while doing programs because it doesn't help me like IDE's do by autogenerating syntax, showing CE and name of methods etc. etc.
Using console, I my self have to write each line manually and makes me understand semantics and grammer of the langauge way better. Even I'm going to learn JSP and Servlet ASAP but definitely using console. NO IDE's at the begining. I think that's is one of the reasons why console is still there.
Being Java programmer.
Stephan van Hulst
posted 3 years ago
I write a lot of exploratory code: Before I commit myself to a fully thought out design with unit tests, I write small programs to see if a preliminary design is viable. To test if method implementations produce the correct output, I write their results to the console and check if it matches what I want expect. It's a lot faster than designing a full-fledged GUI for what's essentially a throwaway application.
Secondly, there are many applications that don't need a GUI, such as command line tools and background services.
Finally, there is no reason to disallow consoles. What could possibly be the downside of using a console?
People don't write console applications for general users. Most people who are not into computers have probably never heard of the Windows command prompt or the Mac OS X terminal. The console is a useful tool for developers and other computer-minded people.
In tutorials you often start with writing console programs because it's simple and easy. You only have to know System.out.println(...); to display text on the screen. If you want to write a GUI program in Java (using Swing or JavaFX, for example), you'd first have to learn how the GUI framework works, which is a (very) big step, especially if you're really new to programming.
I run multiple production servers, many of which have Java applications installed on them. To run a GUI on a Linux computer adds more than 100MB to the system RAM usage and that's 100MB I could pack one or more additional applications into. It's also much easier to log into a remote server using Secure Shell than to set up a remote terminal session - and in addition to my local farm, I manage servers in remote locations, including some at the exact opposite corner of the USA from me. Running a GUI over long-haul Internet can be less than pleasant sometimes.
Many of the services I run are managed via batch scripts. There's very little standardization in automated GUI control for that kind of stuff - plus a single GUI command line is a lot more efficient than having an automation push a mouse around what is often a series of dialogs.
But the question was "GUI for training". If by training, you mean learning programming, you don't program graphically using a GUI, you program graphically using an IDE. And there are many IDEs, ranging from the primitive non-GUI add-ons to the vi and Emacs editors (I've done Java using that), to the full-pixel oriented Eclipse, IntelliJ, JDeveloper and even the extinct Symantec Visual Café. There's no one "GUI" (IDE) that trains everyone.
In any event, I learned many years ago that depending on a GUI IDE to build software is extremely perilous. I got into a situation where in the middle of the night I had to make a 1-line change to a critical application, but the application couldn't be built with the current version of the GUI. You had do install an antique copy of the GUI and then apply a series of maintenance fixes to it. It could have been worse. The IDE version I needed might have required installing an older version of Windows and accompanying fix packs, in which case I would have had to wipe my entire system disk and spend 3-4 hours just getting to the point where I even could compile this one-line program change.
And that's not even counting the fact that almost every GUI design setup I've run into was customized to the particular disk organization that the machine's owner had set up. I worked at a company where the official policy was that the different departments would be using common in-house resources, but in practice we couldn't because the resources in question required a completely different file structure than we had. Every time I'm tempted to curse Maven's rigid directory name and location requirements, I remind myself of this and become grateful.
Because of that and similar traumatic incidents, I now have a firm policy that whether I develop an app under a GUI IDE or not, the production build MUST be done in a command-line environment. Tools like Maven and Ant aren't totally immune to obsolescence, but they are OS-independent (including OS version-independent) and like most Java products, they are designed to maintain backwards compatibility as much as possible.
Being persecuted doesn't in any way prove your righteousness or your beliefs. Many people get persecuted because they are repugnant or annoying. Or just because they can be.
I knew I would regret that burrito. But this tiny ad has never caused regrets:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop