What are your opinions on developing for the command line first, then adding a GUI on after the fact by simply calling the command line methods?
eg.
W:\ todo AddTask "meeting with John, re: login peer review" "John's office" "2008-08-22" "14:00"
loads todo.exe
and calls a function called AddTask
that does some validation and throws the meeting in a database.
Eventually you add in a screen for this:
============================================================ Event: [meeting with John, re: login peer review] Location: [John's office] Date: [Fri. Aug. 22, 2008] Time: [ 2:00 PM] [Clear] [Submit] ============================================================
When you click submit, it calls the same AddTask function.
Is this considered:
Addendum:
I'm noticing a trend here for "shared library called by both the GUI and CLI executables." Is there some compelling reason why they would have to be separated, other than maybe the size of the binaries themselves?
Why not just call the same executable in different ways:
"todo /G"
when you want the full-on graphical interface"todo /I"
for an interactive prompt within todo.exe
(scripting, etc)"todo <function>"
when you just want to do one thing and be done with it.Addendum 2:
It was mentioned that "the way [I've] described things, you [would] need to spawn an executable every time the GUI needs to do something."
Again, this wasn't my intent. When I mentioned that the example GUI called "the same AddTask
function," I didn't mean the GUI called the command line program each time. I agree that would be totally nasty. I had intended (see first addendum) that this all be held in a single executable, since it was a tiny example, but I don't think my phrasing necessarily precluded a shared library.
Also, I'd like to thank all of you for your input. This is something that keeps popping back in my mind and I appreciate the wisdom of your experience.
I can go back through my history of commits and the high frequency periods definitely correlate with times I was learning at a faster pace. But if you really want to master Git, and hundreds of other extremely useful developer tools, you'll need to master the command line first.
Using detailed commands through a command-line interface can be faster and more efficient than scrolling across GUI tabs and dialogs. This can be particularly powerful when handling highly repetitive tasks across many systems, and it demonstrates the advantages of a command-line interface.
The command line (aka Terminal or Command Prompt) refers to a type of program that comes preinstalled with Windows, Linux and Mac computers and allows you to execute commands, run programs and navigate through the folders on your computer.
I would go with building a library with a command line application that links to it. Afterwards, you can create a GUI that links to the same library. Calling a command line from a GUI spawns external processes for each command and is more disruptive to the OS.
Also, with a library you can easily do unit tests for the functionality.
But even as long as your functional code is separate from your command line interpreter, then you can just re-use the source for a GUI without having the two kinds at once to perform an operation.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With