Prev: Using Boost.Spirit in production code
Next: Arguement against NULLing a pointer after delete?
From: Jorgen Grahn on 23 Nov 2009 12:35
On Wed, 2009-11-11, Michael Aaron Safyan wrote:
....
> Even though YOU like something visual, you should
> start becoming familiar with non-visual setup/configuration, because:
>
> 1.) A visual environment is very difficult to automate, whereas
> commandline invocations are easy to automate.
> 2.) Commandline invocations allow your program to be built quickly.
> 3.) Commandline invocations allow your program to be built
> automatically.
> 4.) As a corollary to #3, commandline invocations make it simple to
> perform CONTINUOUS INTEGRATION TESTING, by enabling the server on
> which your source code repository is hosted to attempt to build the
> project and use the results (fail or success) to determine whether it
> should accept source code changes.
> 5.) As a corollary to #4, commandline invocations make it possible to
> create automatic source code-based installers that can automatically
> fetch your source code archive, compile the source code on the target
> machine using the machine's compiler, and then install the resulting
> binary.

It should be noted here that you don't have to believe in CONTINUOUS
INTEGRATION TESTING (what's up with those capital letters?) to prefer
the command line. I personally see no reason that I should let a
machine prevent me from commiting my changes -- if I want it that way
I just say 'make check && cvs ci -m "something"'.

> I strongly recommend that you use CMake for building your project. The
> CMake build system, though it requires a textual specification, allows
> you to generate various different types of projects in a cross-
> platform manner based on your specification. [...]

It should be noted here that people tend to be religious about their
'make' utilities. Personally, I've never used CMake -- all decent
software I've encountered has used plain Gnu Make (often behind
automake). I'm religious about Gnu Make, and I think Michael is about
CMake.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Jeff Schwab on 25 Nov 2009 23:31
{ This has moved off-topic for clc++m. Accepted as follow-up. -mod }

Le Chaud Lapin wrote:
> On Nov 11, 1:31 pm, Michael Aaron Safyan <michaelsaf...(a)gmail.com>
> wrote:
>> 1.) A visual environment is very difficult to automate, whereas
>> commandline invocations are easy to automate.
>> 2.) Commandline invocations allow your program to be built quickly.
>> 3.) Commandline invocations allow your program to be built
>> automatically.
>
> IMO, this is a common misconception regarding IDE's.
>
> I got my start in VMS, then Unix, then Windows, and have been using
> Visual Studio since the days of Quick C, and whatever can be done with
> using command line, scripts, whatever, I can do that, plus more, with
> the IDE.

That's patently untrue. I really don't think you realize just how
flexible the command-line is, no matter how long or intensively you
claim to have used it. For example, when I've performed a sequence of
actions in an IDE, there is no backscroll buffer for me to copy and
paste into a script or an email. There is no way to store a typescript,
much less to edit the typescript in the same environment from which it
was created; the closest you can come is some kind of effectively
immutable screen-cast. The IDE will not run in the serial console I use
every day, and using it over an ssh connection is either impossible or
painfully slow, depending on the IDE, the bandwidth of the connection,
and the nature of the workstation.

It's also worth noting that not all command lines are created equal. I
recently started training some Windows developers to start using Linux,
and there are some deeply ingrained misconceptions to overcome; for
example, a lot of Windows developers see a terminal emulator, and
immediately assume it has no more power than a Windows "DOS box." I
notice, too, that MS seems to be making a concerted effort to kill even
their own CLI; for example, the MS terminal emulator no longer supports
full-screen mode in Vista, and blatantly lies to the user: "This system
does not support full screen mode."

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Martin B. on 26 Nov 2009 20:28
Jeff Schwab wrote:
> { This has moved off-topic for clc++m. Accepted as follow-up. -mod }
>
> Le Chaud Lapin wrote:
>> On Nov 11, 1:31 pm, Michael Aaron Safyan <michaelsaf...(a)gmail.com>
>> wrote:
>>> 1.) A visual environment is very difficult to automate, whereas
>>> commandline invocations are easy to automate.
>>> 2.) Commandline invocations allow your program to be built quickly.
>>> 3.) Commandline invocations allow your program to be built
>>> automatically.
>>
>> IMO, this is a common misconception regarding IDE's.
>>
>> I got my start in VMS, then Unix, then Windows, and have been using
>> Visual Studio since the days of Quick C, and whatever can be done with
>> using command line, scripts, whatever, I can do that, plus more, with
>> the IDE.
>
> That's patently untrue. I really don't think you realize just how
> flexible the command-line is, no matter how long or intensively you
> claim to have used it. For example, when I've performed a sequence of
> actions in an IDE, there is no backscroll buffer for me to copy and
> paste into a script or an email. There is no way to store a typescript,
> much less to edit the typescript in the same environment from which it
> was created; the closest you can come is some kind of effectively
> immutable screen-cast. The IDE will not run in the serial console I use
> every day, and using it over an ssh connection is either impossible or
> painfully slow, depending on the IDE, the bandwidth of the connection,
> and the nature of the workstation.
>
> (...)

We might note that IDE is a common abbreviation of Integrated
Development Environment. In theory this only implies that all the
components needed to develop software in C++ are well and truly
integrated. (Editor Compiler Linker Debugger ...)
Integration - for example - means that I change a source line and then
hit one button that automagically saves the file, compiles+links the
application and runs it under the debugger.
This means a tremendous productivity increase for the developer and
lower hurdles for newbies as the IDE hides the details for them.
Of course the IDE will invoke some commands under the hood and sometimes
we might have to tweak or analyse them - however, this should be the
exception.

To sum up my opinion:
The C++ developer that is afraid of the CLI is a bad C++ programmer but
the C++ developer that doesn't use an IDE because "CLI rules" is also
wrong, because he misses a great productivity boost.

cheers,
Martin

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Le Chaud Lapin on 28 Nov 2009 09:20
On Nov 26, 10:31 am, Jeff Schwab <j...(a)schwabcenter.com> wrote:
> > I got my start in VMS, then Unix, then Windows, and have been using
> > Visual Studio since the days of Quick C, and whatever can be done with
> > using command line, scripts, whatever, I can do that, plus more, with
> > the IDE.
>
> That's patently untrue. I really don't think you realize just how
> flexible the command-line is, no matter how long or intensively you
> claim to have used it. For example, when I've performed a sequence of
> actions in an IDE, there is no backscroll buffer for me to copy and
> paste into a script or an email. There is no way to store a typescript,
> much less to edit the typescript in the same environment from which it
> was created; the closest you can come is some kind of effectively
> immutable screen-cast. The IDE will not run in the serial console I use
> every day, and using it over an ssh connection is either impossible or
> painfully slow, depending on the IDE, the bandwidth of the connection,
> and the nature of the workstation.

Given that the IDE can be invoked from the command line, and that the
IDE can run any command line script, it is logical to conclude that
the feature set of the IDE is a superset of the features set of the
command line.

Therefore, whatever can be done using the command line can be done
with the IDE, but the reverse is not true.

At that point, it becomes a matter of preference of the user:

1. Some users will prefer the IDE, and never the command line.
2. Some users will prefer the command line, and never the IDE.
3. Some users will lean heavily toward IDE, using command line
occasionally.
4. Some users will lean heavily toward command line, using IDE
occasionally.

In absence of the IDE, three of these possibilities are immediately
eliminated.

In absence of the command line, none of them are eliminated, because
the IDE always includes the command line.

-Le Chaud Lapin-


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2 3 4
Prev: Using Boost.Spirit in production code
Next: Arguement against NULLing a pointer after delete?