Learning C++

[Balog Pal]

New project -> Console app -> 'A hello word application' -> Finish.
Then press F5 and it builds and runs.

And how is that supposed to help someone learn C++?

By saving time for learning and writing the stuff of his own instead of
sidetrack the activity you set as alternative.

Also having a thing that readily compiles and runs ( the hello world version
for Win API or MFC or ATL or whatever is far from obvious to type in
manually...) is a motivation.

(But the quoted part was answering your question -- phrased implying it
can't be done or more cumbersome using the IDE... shifting context this way
is not really nice...)

 

[Balog Pal]

Yet, that has absolutely nothing to do with C++ and only brings confusion,
needless confusion, to every newbie that is taking his first steps into
programming.

We obvoiusly meed tifferent newbies and your claim of "every" is false to
say it mildly.

And I still see no explanation on how learning use of *make* is less a
distraction.

A suggestion to just use the compiler directly with the command line at
least would make sense.

So, by using an IDE a newbie not only is forced to do more to perform the
same
task

LOL, the part you efficiently deleted showed that it is actually less, but
why bother with facts if they don't fit the dogma.

but he will also end up understanding less.

That is true -- he will not learn to use a tool that is not needed. What is
next, that IDE does not teach to perform lege artis brain surgery either?

It's pretty much settled what is the best tool here.

and we all lobe Big Bother too.

What? Typing in a dozen letters is "extreme amount of redundant typing"?
How
many LoC do your projects usually carry?

12/0 makes a big number. And we should find some common mathematics branch
to compare numbers in the same way.

My project sizes are irrelevant and 'usual' has little sense there.

Why should anyone waste their time writing wizards if they can perform the
same
task faster, easier, cleaner and with greater understanding of what is
going on
by just opening a text file and type away the code?

To save that typing over and over and over, and start with correct code.
Really, why we bother with using compilers too, we could type in the machine
code directly... O,O

I don't understand this problem you have with keyboards

I don't have any problem with the keyboard. I do have problem with false
claims, that state "their way" needs less time or less interface activity of
any kind.

, particularly when the
subject is none other than programming.

Typing in the above text is programming? In C++?

If you wish to program you are forced to
use the keyboard and use it extensively. In fact, being forced to move
your
hands away from the keyboard is a major hindrance in any programmer's work
flow.

So, pointing out large amounts of clicks needed to pass through the
multiple
wizards that you must run through in order to start off terribly basic
projects... Well, it doesn't make IDEs look good.

I wonder what is the amount of false claims allow me to shout cheat and
liar.
Is it so hard to admit "I was wrong, sorry". Or "Ok, I bluffed, it was
called, let's move to next subject."

I'm sure with some more sophisticated trying you could provide an example
that is not covered so frelling directly by a wizard, so it would show
advantage on pushed side however made up... Or just remain with the real
examples, where make have the actual upper hand.

You don't understand the virtues of being able to fine-tune your tools in
order
to have full control over it and therefore make them work exactly as you
want?

No, I don't buy in the hedge-fond like benefits that never cash in. I
want flexibility when it is needed, and go with the simplest thing when is
suffice.

guess I am not a control freak, and to me it is enough to have exactly the
amount of power I have intention to use. Probably comes from the
confidence that I can gain more power as need becomes actual.

If all your needs fitted neatly with all the basic features that an IDE
usually
offer then congrats.

I never said that IDE (especially some single IDE) prevented me from using
anything else too if there was a need. The whole approach is more than
wierd to me -- an IDE is one tool in the box, quite powerful, and usable in
the bulk. For good. It will not file for adultery if some tasks are
solved fith anything even more fit.

Yet, as soon as you are faced with non-trivial tasks, such
as supporting 3rd party compilers or integrating 3rd party tools into your
project (automatic code generators, for example) then you are suddenly
forced
with a usability barrier which is needlessly hard to work around.

Sure, that is what I said a few post upwards.

If we are at it, should add, that '3rd party' normally targets the common
tools, and say VS counts as such. A library intended for use in Windows
development has more than fair chance to include VS compatible project file,
and much work needed to make it plugable is done by the vendor.
Certainly it may be for a different version.

I saw a couple 3rd party compilers/tools aim to integrate in the VS too.
If people spend their own money on them instead of using something
different, I'd wager that way is useful for something. ;-)

On the other hand, if you aren't tied to an IDE and instead rely on a text
editor then, at worse, you can simply edit your Makefile and type in a
couple of
additional targets. And you are done. Easy as that.

Is there any new point here?

What are you talking about?

Which part is not clear?

My CD player has an eject button. It is good for me. I certainly could want
finer control, a slider to control the speed of ejection. Some interface to
adjust how it recognizes the power of push. how on earth could I live with
just one dumb button? It is limiting like hell.

You fail to understand that no one was born knowing how to operate an IDE.

Or make, or anything.

You're back to false claims, that typing magic text in a magic file taking
care of magic punctuation and layout is genuinely easier for anyone to grasp
than some other interface like drag&droping a file into the project manager
pane.

And we're talking about interface patterns that are common to a wide variety
of programs -- you used any one and can figure the next, while make is a
specific program from the distant past that stayed afloat just due to weird
evolutionary accidents.

If it is so perfect why people work on other build systems, and use those?

That
means that in order to first find out that the "special field" you mention
exists, that person is forced to needlessly comb through piles of
documentation
and waste their time waltzing around the IDE's menus and absurd amount of
dialogs.

You push hard on my bullshit threshold, please admit that you neves have
actually seen any of those dialogs, just heard some fairy tales like that
about the 12-head dragon. Please execute at least one, than you can report
the correct count and amount, and not mislead anyone.

To use the project wiz for the task starting this post you don't need
anything and can proceed with the info on screen. At least for one having
at least an IQ of 90 and able to read the language of the interface.
Okay, I counted in ability to use common UI like push buttons and edit
boxes.

The field is there well visible and is filled with the compiler switches, so
anyone actually knowing the needed switch shall only do as much mental work
to discover a non-readonly editbox is there to enter the text...

Knowing what the needed switch is asks for fair amount of RTFM, so I wager
whoever has that level will not have problem with entering.

A common case is different: one has no clue whatsoever about the options,
don't bother with RTFM ever, for anything, and then gets annoyed that the
explanation/reminder text in the options UI is not enough to do the imagined
thing. (what may be just not doable too)

That part of IDE IMO serves only those who have a fair clue what they want.
And the make version does not have even that much spoilers.

To add insult to injury, that pseudo-skill is rendered useless as soon
as the next IDE is released.

Well, there are controls I use much so I expect them to be at a place I got
used to. Possibly up to the pixel.

Project/compile options are definitely NOT in that category, and it never
occoured to me to memorize or rely on the current interface there. (As I
wrote it changed a lot -- guess for that very reasoning. Peoplegetting
there will push the button wherever it is.) Other parts of the interface
are stable for rearrange would mean a ton of complaints.

On the other hand, if you rely on a text editor then just open a file and
tweak
your option. That's it. You are done.

In that case I need to actually memorize that the option is /Fg /K12x --
on the interface version I just pick from "Use/not use precompiled headers"
or "optimize speed" or "want assy output". I read about the effect of them
some 15 years ago and just select the one I want not caring the
ciphertext -- that is more efficient than the whole RTFM.

As already stated, if you can provide the switch itself entering it is
exactly as easy.

If what a newbie wants is simply to learn how to write C++ code then why
on
earth should he be forced to waste time with tutorials targeting some
application's unending, bloated UI and multitude of features? It appears
that
your idea of simplicity carries a heavy burden of unjustified complexity
and
extra work.

Err, is there any well-established method for a newbie to "simply learn how
to write C++ code"?

Or for one already having a base in C++ to create, say a Windows application
that is an editor of some kind?

Do you mix distinct use cases for reason or really can't separate them?

If the part of the work is like "calculate the 100th digit of pi and print
it on stdout" then all you use from the IDE is to create a windows console
application, initiate build, navigate on errors, initiate debugger, debugger
basics.

If the task is to create an application with a dialog and do something with
the input, you need shall learn the parts to edit resources, description of
support classes for that dialog and common controls, steps to take so data
on UI appears in variables.

If it is a document-view app, then also to add message handlers, paint and
deal with GDI and so on.

Those are not distractions but parts of what needed for the work -- but
you're welcome to go back and do sutuff Petzold-style on a bare API. Or
skip the whole thing and claim that digits of pi should be enough for
anyone, and wanting UI is for the devil. ;-)

And yet it got you nowhere in your knowledge of that specific API and you
were
forced to waste your time learning how to handle a wizard which, if you
are any
serious with your programming projects and your projects are anything
beyond the
1k LoC, you only end up doing a handfull of times in a time frame of
years.

You sure know too well where I got. ;-)

That's irrelevant, as debugging isn't an exclusive domain of the IDE.

No, but it is (regretfully) integral part of SW development. And having a
single interface instead of several saves much time.

Unfortunately that is a problem which the IDE imposes on everyone, not
only
newbies. If you are expected to do anything with an IDE then you are
forced to
waste your time learning how to use it instead of just writing the damn
code.

Uh oh, and I many people shall waste like 12+5 years on going to school too,
instead just starting to work.

And waste time on learning C++ (or other language to program) instead of
just conjure working out of thin air.

My experience is clearly that time invested in learning in general -- also
time to learn to use and/or create sharp tools is an investment that pays
off multiplied.

One important property of good tools is intuitive interface (that is either
naturally fits the problem/solution space or builds on elements already
learnt elsewhere).


If you pick any alternative, those also have learning to do. That may be
less, but may be just the same -- as launching a build must happen some way
whatever you use.
Also, you can learn an item the same time that is useul for more things in a
more sophisticated tool.

Then, most importantly the amount of learning needed in SW development on a
regular basis (that covers languages, existing SW components and the problem
domain) exceeds the loerning need for IDE-like tools by 2-3 magnuitudes at
least, so it hardly worth mentioning. *If* actually happens -- as skipping
that little part may lead to inefficiency, dragging -- or inefficient
handling of preventable problems that are pretty expensive.

If, instead, you use a text editor then you just open it and code away.
There
is no bloat, there are no irrelevant, distracting, useless features which
end up
doing more harm than good. It's just you and the text file. And that
means
being far more productive.

You keep repeating empty claims.

For one features that irrelevant are not distracting. If a feature is
useless, I don't use it. One man's irrelevant useless feature is anothers
life essence.

Not long time ago in a Spolsky he talked about some doc/text editor, and
that it was undergo trimming, discarding some of the bloat. I.e. they
discarded the char/word count statistics. "Great idea" I thought, i surely
never used that and could not think a sane mind to be interested.

Then reading ahead I found that complaints started pouring in, that
journalists and similar folks are no longer able to use the editor for work.
As they are supposed to deliver some measure of that very count.

There is an observation, that most people use maybe 10% of an application's
interface or less. But you can't cut the other 90%, as it is different
for different users.

The features of the IDEs I use are definitely needed in my work and save
much time and accuracy. I would use simple editor, or other tool, if it
were more effective. (I use too, without hesitation, or write a tool if the
time spent on that is less than the estimated alternative -- or that has a
hateful/boring effect).

If a simple editor is good for your work, use that, I don't care as long as
I am not responsible for your output end effectivity -- and it remains
abstract whether your performance is optimal or not.

But you should not pass judgement about other people's work you have no clue
about.

No, that means that if you only need to do simple, straight forward
projects
then you start, at best, at the same level as if you hadn't picked an IDE
to
begin with and picked a text editor instead.

More repeated falseness.

Yet, you don't have any freedom, as you are kept firmly wedged between
what the
IDE supports and what the IDE forces you to avoid.

The freedom to chose the IDE itself suffice -- asmy using it implies more
freedom is not needed. And I surely won't sacrifice real features and
benefits for some imaginary "more freedom". That in another context you'd
apostrophe as "bloat" and "irrelevant" and other fine words quoted above.

So if meanwhile you find
your project in need for some tool or feature which your IDE doesn't
support...
Well, you are screwed. That doesn't happen if you don't work with IDEs.

Like in don't use plane, as it may crash, you rather walk thousand miles
than risk the chance.

Btw getting screwed time to time appears a fundamental part of SW
development (or life in general), regardless usage if IDE. So the
possibility does not scare me too much. ;-)

I don't believe that being forced to waste time to try to figure a way to
force
your IDE to do anything that it wasn't built to do does anyone any good.
It's
still your IDE burdening you with extra work which you shouldn't be doing
to
begin with and you would easily avoid by using a text editor.
Huh?


No, it's the burden of being forced to do far more to accomplish less.

more false claims.

So you not only advocate that a person should waste their time by learning
how
to work with a piece of software which pretty much ends up making you work
less
efficiently but, if that wasn't enough, you also suggest that a person, on
top
of that, should waste even more time learning how to work with multiple
software > packages just to be able to chose one among them.

Oh, come on, I can't be that stupid or evil to advocate that -- everyone
(else?) knows that there is the one and ony ultimate text editor (and build
tool, and guess language, and os, and...) that solve every possible need of
anyone.

The world got on the wrong track to ever try to write more than one editor
and the writes of surplus should have been sent to room 101 in due time.

People should stick to use thet one true thing and learning about
possibility (let alone featires) of the others is a serious sin to be
banished.

O,O

And, keeping in mind the
subject of this discussion, you suggest that a person should waste all
that time
doing all that as a prerequisite to simply learn how to program.

Actually for the language-learning context my claim was that the newbie
could just fire ahead. And learn along following the tutorial. But never
mind.

Before jump to learning I'd certainly suggest some exploration of whats and
whys, and I still see a world before banishing, and there is more than one
kind of thing open to possible learning. So some choice must be made
before start. ;-)

That, compared to just picking up pretty much any text editor and just
hack
away.

*Any* text editor? Ah, I see, text editors have four legs, and IDEs have
two, right, so the rest figures.

And using an IDE is supposed to do what? Save you time? It doesn't look
like
it.

why bother looking

That doesn't make any sense.

Too bad, it is easier to refuse the clear parallel than admit a poor claim
and retract it.

And why is this relevant?

You tell me -- you implied my experience is limited in some ways while it is
not. Now what? ;-)


But never mind, so much fun was enough for a couple of weeks.

Everyone has a right to believe in whatever

 

[Bo Persson]

Yet, that has absolutely nothing to do with C++ and only brings
confusion, needless confusion, to every newbie that is taking his
first steps into programming.

So, by using an IDE a newbie not only is forced to do more to
perform the same task but he will also end up understanding less.

If the poor guy is already using Windows, you wouldn't assume that he
has already seen the "File->New->Create Dcoument" approach? If that is
a big hurdle, perhaps he shouldn't start programming yet?

It's pretty much settled what is the best tool here.

Right!


Bo Persson

 

[Rui Maciel]

If the poor guy is already using Windows, you wouldn't assume that he
has already seen the "File->New->Create Dcoument" approach? If that is
a big hurdle, perhaps he shouldn't start programming yet?

Could you please point the relation between the level of experience navigating
through a given UI and the level of preparedness to start learning how to program?


Rui Maciel

 

[Rui Maciel]

By saving time for learning and writing the stuff of his own instead of
sidetrack the activity you set as alternative.

You got to be kidding. The text editor way consists of just opening a text
editor and writing code away as you see fit. How does being forced to learn how
to navigate the IDE's UI and being forced to deal with the IDE's automatic code
generation and code templates "saves time for learning and writing stuff of his
own"? How does writing the stuff on his own "sidetracks the activity" of
writing stuff of his own?

Also having a thing that readily compiles and runs ( the hello world
version for Win API or MFC or ATL or whatever is far from obvious to type
in manually...) is a motivation.

Learning how to use a set of APIs does not have anything to do, nor should it
have anything to do, with learning how to program in a programming language.

More to the point, this is yet another example of why newbies should just stay
away from IDEs, as IDEs (such as the ones in Microsoft's VS line) impose on the
user it's non-standard APIs, which, as a negative effect, leads the newbie to
believe that somehow those APIs are a standard component of language.

(But the quoted part was answering your question -- phrased implying it
can't be done or more cumbersome using the IDE... shifting context this
way is not really nice...)

No one has claimed that it isn't possible to write "hello, world" programs with
an IDE. But yes, when compared with simply using a text editor (opening a file
and just write the damn code) it's more cumbersome (and needlessly so) and less
educational to do it in a full blown IDE.


Rui Maciel

 

[Bo Persson]

Could you please point the relation between the level of experience
navigating through a given UI and the level of preparedness to
start learning how to program?

Right!

The argument is that if you think "File->New" is too difficult,
perhaps trying to learn C++ isn't the best idea. Especially not by
starting from an empty page in a text editor.


Bo Persson

 

[Rui Maciel]

Right!

The argument is that if you think "File->New" is too difficult,
perhaps trying to learn C++ isn't the best idea. Especially not by
starting from an empty page in a text editor.

I don't see how that makes any sense, as starting a project on a IDE isn't merely a
"File->New" task (there are myriads of options presented to the user) and you also
need to "File->New" to open a new file through a text editor.


Rui Maciel

 

[Öö Tiib]

Yet, that has absolutely nothing to do with C++ and only brings confusion,
needless confusion, to every newbie that is taking his first steps into
programming.

First steps into programming should be something simpler and more
interactive than C++ anyway. Some interpreted language like Basic,
Python or Javascript supports the first steps better.

So, by using an IDE a newbie not only is forced to do more to perform the same
task but he will also end up understanding less.  It's pretty much settled what
is the best tool here.

None of alternatives are best. It might be good to let newbie to type
in program in text editor. Save it. Try to compile. Understand from
compilers messages what went wrong. Then fix the file, save it again
and try to compile again. Then when it compiles to link it. Then if it
links to run it. And once he succeeds then reveal that there exist
IDEs that let to do the things in a bit more convenient way. Making
makefiles by hand right away is perhaps bit too lot for first
lessons.

What? Typing in a dozen letters is "extreme amount of redundant typing"? How
many LoC do your projects usually carry?

You guys just argue? It does not link as C++ anyway, so what was
the point of typing it?

Why should anyone waste their time writing wizards if they can perform the same
task faster, easier, cleaner and with greater understanding of what is going on
by just opening a text file and type away the code?

You do not have to write or use the wizards in IDE. You may use it as
convenient text editor. With syntax highlighting and auto-complete.

I don't understand this problem you have with keyboards, particularly when the
subject is none other than programming. If you wish to program you are forced to
use the keyboard and use it extensively.  In fact, being forced to move your
hands away from the keyboard is a major hindrance in any programmer's work flow.

You can write and use that makefile in particular IDE you are arguing
about. (Visual Studio) You may set it up to use various compilers. It
is good idea to let your code to be compiled with as lot of compilers
you can reach since each has extensions you want to avoid and grey
areas of standard they interpret differently that you also want to
avoid. But that has nothing to do with newbie.

So, pointing out large amounts of clicks needed to pass through the multiple
wizards that you must run through in order to start off terribly basic
projects... Well, it doesn't make IDEs look good.

Again, wizards are fine for newbie but you know what you do, so do not
touch these.

You don't understand the virtues of being able to fine-tune your tools in order
to have full control over it and therefore make them work exactly as you want?

MS Visual Studio is quite powerful in that respect. It is not hard to
learn to make custom build rules and to integrate external tools into
it. Since it tries to use all your processor cores during build you
got to think about the order in what things are made and dependencies
between these but that is again extended task, newbie does not need it
with his single module containing single main.cpp.

That doesn't make sense, as there are quite a lot of tools which automatically
generate build scripts from the code contained in a source tree. For example,
even the autotools family, which is accused of being hard to use, provides the
autoscan script, which does just that, pain-free.

Yes, similarly i can just drag files from windows explorer into visual
studio project and press F7 to compile them.

If all your needs fitted neatly with all the basic features that an IDE usually
offer then congrats.  Yet, as soon as you are faced with non-trivial tasks, such
as supporting 3rd party compilers or integrating 3rd party tools into your
project (automatic code generators, for example) then you are suddenly forced
with a usability barrier which is needlessly hard to work around.

I already told. It all works. I have integrated perl scripts, gettext
files, various yak & bison parser generators and so on into Visual
Studio. Piece of cake.

On the other hand, if you aren't tied to an IDE and instead rely on a text
editor then, at worse, you can simply edit your Makefile and type in a couple of
additional targets. And you are done. Easy as that.

And that i already told too. Makefiles integrate into Visual Studio
just fine.

What are you talking about?



You fail to understand that no one was born knowing how to operate an IDE..  That
means that in order to first find out that the "special field" you mention
exists, that person is forced to needlessly comb through piles of documentation
and waste their time waltzing around the IDE's menus and absurd amount of
dialogs. To add insult to injury, that pseudo-skill is rendered useless as soon
as the next IDE is released.

Every tool you have to learn to use. Be it compiler, make, debugger,
text editor, profiler, script generator or what not. IDE is just that
"Integrated Development Environment" where some tools are integrated
and some other tools are not yet integrated (but you may integrate
them). For deciding if you want to use the tools in IDE or some other
tools you have anyway to learn about them. Or how else you decide?

On the other hand, if you rely on a text editor then just open a file and tweak
your option. That's it. You are done.

Yes. Click on the file it is opened, tweak option and press F7. That
is exactly what IDE does.

If what a newbie wants is simply to learn how to write C++ code then why on
earth should he be forced to waste time with tutorials targeting some
application's unending, bloated UI and multitude of features?  It appears that
your idea of simplicity carries a heavy burden of unjustified complexity and
extra work.

When someone wants to learn C++, then it has very few to do with
typing code in text editor. It is all about where to get libraries,
API-s and code generators, how to tweak and integrate them and how to
test and debug the result. Code that some experienced developer types
in is below 10% (may be below 5%) of what is actually compiled into
his project.

And yet it got you nowhere in your knowledge of that specific API and you were
forced to waste your time learning how to handle a wizard which, if you are any
serious with your programming projects and your projects are anything beyond the
1k LoC, you only end up doing a handfull of times in a time frame of years.

MFC is particular API that particular tools integrated into particular
IDE support. Listen how it sounds: "HTML is text file. Period. When
you need web page then type that HTML into a text file in text editor.
All tools are so lot more complex than text editors so people who use
them are fools and waste their time."

That's irrelevant, as debugging isn't an exclusive domain of the IDE.

No tool is. Tools are simply *integrated* into there in convenient
manner. In logical relation with each other.

Unfortunately that is a problem which the IDE imposes on everyone, not only
newbies.  If you are expected to do anything with an IDE then you are forced to
waste your time learning how to use it instead of just writing the damn code.  
If, instead, you use a text editor then you just open it and code away.  There
is no bloat, there are no irrelevant, distracting, useless features which end up
doing more harm than good.  It's just you and the text file. And that means
being far more productive.

It is perhaps best for everyone if that "the damn code" is not written
at all. The more years pass the more i start to avoid relations with
such code that some moron who hates to learn and to think did type in
and all he cared was kilos of LoC produced.

No, that means that if you only need to do simple, straight forward projects
then you start, at best, at the same level as if you hadn't picked an IDE to
begin with and picked a text editor instead.

Simple and straight forward products are all mostly made. Most of
these are available as open source.

Yet, you don't have any freedom, as you are kept firmly wedged between what the
IDE supports and what the IDE forces you to avoid.  So if meanwhile you find
your project in need for some tool or feature which your IDE doesn't support...
Well, you are screwed.  That doesn't happen if you don't work with IDEs..

If IDE forces you to avoid a favorite tool then switch the IDE and
learn again. But your favorite tool seems to be text editor and that
is present in all IDEs i have seen.

I don't believe that being forced to waste time to try to figure a way to force
your IDE to do anything that it wasn't built to do does anyone any good.  It's
still your IDE burdening you with extra work which you shouldn't be doing to
begin with and you would easily avoid by using a text editor.

IDE was built to integrate development tools. It does not replace or
enforce these. It integrates these.

No, it's the burden of being forced to do far more to accomplish less.

Strangely most developers these days use IDE and are annoyed when
platform lacks decent IDE. There are always emacs and eclipse but
these do not suit everyone.

So you not only advocate that a person should waste their time by learning how
to work with a piece of software which pretty much ends up making you work less
efficiently but, if that wasn't enough, you also suggest that a person, on top
of that, should waste even more time learning how to work with multiple software
packages just to be able to chose one among them.  And, keeping in mind the
subject of this discussion, you suggest that a person should waste all that time
doing all that as a prerequisite to simply learn how to program.

No. Person should of course first try to do it from command line.
Before 1985 there were no IDE's. Also there were no compilers. Were
translators that did translate into assembler. So you had to edit,
translate, assemble and link. Borland Turbo Pascal 1.0 did look like a
miracle. You type code, tell it to run and it runs. There was no
question back then, what is easier to learn and to use. Strange, that
you make it questionable 25 years later when IDEs are so widespread.

Ok, happy arguing.
--

 

[Jorgen Grahn]

In my terminology emacs is an IDE by most practical means...

When there are IDE-or-no-IDE discussions, the Emacs and Vim users tend
to be on one side and the IDE people on the other. But I see what you
mean -- you can drive Make and the debugger from inside Emacs.
I personally never learned to do that.

(I should add that I *do* belive that one's editor must have a C++ mode.
People programming in Notepad or plain old vi *do* waste their time,
and also probably produce misindented code.)

"fiddling" I mean extra time/effort spent on loading, reloading sources, go
to desired locations (say where the compile error is), to watch related
code, etc. Also related documentation.

Never had any major problems with that in my environment. I also use
grep, Perl one-liners etc quite a lot on the command line -- I guess
IDEs only can offer some of those features.

During all the usual cases -- primary code writing, review, raw-compile,
debug...


Pobably so -- but the alternative is to not have the whole problem set at
all.

You *do* pay a price for not using a C++-specific tool for building.
But you win the other things a Makefile offers, like building
documentation, running unit tests, installing ...


I wrote a lot more, but deleted it. I claim to have a good
command-line workflow, you claim to have a good IDE workflow. And
neither of us know what we're missing: I've never really used an IDE,
and to be frank I don't think your experience with MS-DOS is relevant
to a current Unix environment.

/Jorgen

 

[Andrew Poelstra]

When there are IDE-or-no-IDE discussions, the Emacs and Vim users tend
to be on one side and the IDE people on the other. But I see what you
mean -- you can drive Make and the debugger from inside Emacs.
I personally never learned to do that.

(I should add that I *do* belive that one's editor must have a C++ mode.
People programming in Notepad or plain old vi *do* waste their time,
and also probably produce misindented code.)

I find that I get used to a lack of code highlighting very quickly, and
while it's difficult to search through old code (for that I use vim or
kate or something intelligent), day-to-day coding is just as fast in
ordinary vi as it is with a more featureful editor.

As for indentation, notepad is (that I know of) the only text editor on
the face of the earth that does not use tabstops correctly. But most
people I know don't use tabs for indentation; only for aligning ='s
and comments.

 

[Balog Pal]

When there are IDE-or-no-IDE discussions, the Emacs and Vim users tend
to be on one side and the IDE people on the other. But I see what you
mean -- you can drive Make and the debugger from inside Emacs.
I personally never learned to do that.

It really depends on the application. You can integgrate Emacs with other
tools, making it IDE. Or use VS as notepad...

If the editor does not soak up the build's error output one trivial source
of inefficiency is all the actions to navigate to look/edit the error
places. (All IDE's provide 1-key means of going through the list, and it is
a very common case in development).

(I should add that I *do* belive that one's editor must have a C++ mode.
People programming in Notepad or plain old vi *do* waste their time,
and also probably produce misindented code.)

LOL, especially as there is notepad2 that is suggested to replace the stock
notepad, is light, aware of many languages, pure joy...

When we talked 'normal editor' upstream I ormally associate with stuff like
that notepad2, the ones you mentioned are too deep WTFs to be worth arguing.
;-)

And the plain editor s okay for simple tasks, but as the project grow the
inefficiencies grow steeply.

As I mentioned upstream, using real browse info has a great edge compared to
just grep.

Never had any major problems with that in my environment. I also use
grep, Perl one-liners etc quite a lot on the command line -- I guess
IDEs only can offer some of those features.

To me IDE is just what the word means, integrated & environment. The point
is that you shall spend no ecess UI activity on feeding the external tools
and process their result.

Like navigating on all places of a certain function call is a 1-click
activity. Simple local or global find also has auto-pick text and history
for input and 1-click navigation. ('click' includes keypress not jsut
mouse)

Where using those requires extra actions, even as mnuch as copy/paste where
really avidable, I see inefficiency. But especially if all you get is a
textual list, and shall take actions to open the files and go to lines.

You *do* pay a price for not using a C++-specific tool for building.
But you win the other things a Makefile offers, like building
documentation, running unit tests, installing ...

Whoever read me on this thread knows I'm in no way a bigot of one build
tool. Someone just recently wrote that you can integrate the other
translators without problem, so it is there, I once had .asm files, and
recall no problems to include them. but admit that the possibility is
there, and one may run into the case a built-in project manager handles
badly or not at all.

Then you have to deal with the problem of feeding back the build's
information. If that one solved, you're back to fine IDE, just with a
different build tool, aren't you? ;-)

If not, then it is a price. I'd probably look for solution to build the
renitent components separately. (As pre- and post build steps are
supposedly supported why not put the source generators and the dox/packaging
there, and keep the cpp compilation in? )

I wrote a lot more, but deleted it. I claim to have a good
command-line workflow, you claim to have a good IDE workflow. And
neither of us know what we're missing: I've never really used an IDE,
and to be frank I don't think your experience with MS-DOS is relevant
to a current Unix environment.

Well, I do have a deal od command-line experience, and spent like 3 years
recently on a big unix project -- many observations mentioned are right from
there. So I believe I can compare the things from both my personal work and
observations.

But if you have a good workflow and is content with the progress, the
results and the kind of activities you do, good for you.

 

[Öö Tiib]

Seems it is gone far from "how novice should learn c++?"

You *do* pay a price for not using a C++-specific tool for building.
But you win the other things a Makefile offers, like building
documentation, running unit tests, installing ...

The activities that you do for packaging and deploying certain piece
of software on OSX, Linux and Windows differ quite significantly from
each other. When you write something that is supposed to install on
all three platforms (plus say on some PS2 console) you need at least
one person per platform to keep things testable and installable there.
Does not really matter if he is IDE or Vim person, main attribute is
ability to get things done. I have never heard reason that one can not
build documentation, run unit tests, debug, profile or install because
of IDE or lack of IDE. That would sound like "kick me out, i am
wuss".

I wrote a lot more, but deleted it.  I claim to have a good
command-line workflow, you claim to have a good IDE workflow.  And
neither of us know what we're missing: I've never really used an IDE,
and to be frank I don't think your experience with MS-DOS is relevant
to a current Unix environment.

C++ is platform independent and lots of C++ code is written for
platforms that are (sort of) more closed than MS-DOS. All these
embedded devices, cellphones and game consoles. So experience with
primitive things is as handy as ever. BTW ... how you for example
detect memory leaks (or lack of these) in your product with your tests
in good command-line workflow?

 

[Rui Maciel]

Öö Tiib wrote:

None of alternatives are best. It might be good to let newbie to type
in program in text editor. Save it. Try to compile. Understand from
compilers messages what went wrong. Then fix the file, save it again
and try to compile again. Then when it compiles to link it. Then if it
links to run it. And once he succeeds then reveal that there exist
IDEs that let to do the things in a bit more convenient way. Making
makefiles by hand right away is perhaps bit too lot for first
lessons.

That's exactly the learning path that a newbie should take when taking his first
steps into the programming world. No frills, no cruft, no mysterious bloat to deal
with. He only needs to focus on the programming language he set off to learn,
which is a great help when you are first starting off and you don't have quite a
good grasp of what is going on around you.

After a person gets an healthy grasp of the language then that person should use
the tools that better suit his/her needs, where all that needless cruft and bloat
can actually be of some use instead of being constantly in the way and clouding the
judgment and their concept of what a programming language really is. Until then,
keep it simple and you'll get up to speed faster than if you are forced to deal
with irrelevant details.


Rui Maciel

 

[Balog Pal]

I've missed something. Who mentioned MS-DOS?(It's been dead for years,
and I don't think there was ever a proper IDE for C++ on it)

Borland C++ 3.x (even 2.x) was as decent IDE as you can get. (then B. lost
its dev team, and the windows versions were a monotonous march downhill...)

 

[LR]

I've missed something. Who mentioned MS-DOS?(It's been dead for years,

I'm not sure it's entirely dead.
I think there are still new versions or variations still being produced.
http://en.wikipedia.org/wiki/MS-DOS
http://www.chebucto.ns.ca/~ak621/DOS/DOS-Head.html

and I don't think there was ever a proper IDE for C++ on it)

According to wikipedia there was at least one.
http://en.wikipedia.org/wiki/Turbo_C++

Evidently, it's still available for download.
http://edn.embarcadero.com/article/21751

Personally, I started programming on punch cards at school (ok, ok, I
started on an Olivetti teletype with paper tape but after that it was
punch cards for a while) so I'm getting a kick out of all the talk in
this thread about productivity.

All you have to do is save all your cards and then use a sorter to get
the one you want so you rarely have to type anything more than once.
You can write programs to punch new cards if you don't like the ones you
have. This also makes copying files a breeze. When you're reading cards
you know exactly what the number of characters per line is, making it
easier to read text. And you don't have to worry about horizontal
scrolling to read something or if you should break a line or not. With
punch cards there's no mystery about what an "overpunch" is.

Plus, line printer listings provide an easy interface for that other
useful device, the pencil, and can be read anywhere almost like having
access to your code via a mobile phone.

http://en.wikipedia.org/wiki/Line_printer
http://en.wikipedia.org/wiki/IBM_80_series_Card_Sorters
http://www.museumwaalsdorp.nl/computer/en/punchcards.html
and
http://www.pencilrevolution.com/2006/04/pencil-hero-henry-petroski/

LR

 

[Rui Maciel]

IMHO, the notion that a GUI interface would be "mysterious" to a new
developer seems completely out of touch with the modern world. This
is 2010; whether you personally like them or not, the fact is that GUIs
have been the mainstream for the past couple of decades. Even if an
IDE has a "new project wizard," such a thing is speaking a "language"
with which the newbie is already quite familiar; the instructor can
simply say "just accept the defaults and click through the wizard"
without causing undue confusion.

GUI stands for Graphical User Interface. That means that you do have text
editors with a GUI. In fact, you need to intentionally look for a non-GUI text
editor in order to find one and even then no one forces you to do that.
Therefore, that is clearly irrelevant in this whole text editor vs IDE debate.

Moreover, this notion of "non-GUI apps are all outdated with the modern world"
is astonishingly silly and doesn't make any sense. For example, do programs
such as gcc, valgrind, git, gdb and the like all belong to the ancient world?
Would they be dragged kicking and screaming into the modern world if someone
wrote a small dialog with a file chooser and a big button labeled "run" that did
nothing more than pick a file and run one of those apps in the background?

By contrast, command lines and make files introduce new languages

Could you explain how sporadically using the "command line" can be seen as
"introducing a new language"?

Regarding makefiles, it is in fact a separate language. Nonetheless, It's a new
language which pretty much boils down to this:

target: precedent
command to be executed

If you know that then you basically know how to write any makefile that you will
ever need for any of your "hello, world" projects. As anyone can attest to,
when compared with learning any concept related to C++ programming this one is
laughably trivial to master. Trivial and, as we are talking about "hello,
world" projects, unnecessary.

in
addition to the programming language the newbie set off to learn. They
are certainly powerful tools that are worth learning eventually, but for
a new developer they're a distraction that forces him to learn several
unfamiliar concepts at once.

And that's why the newbies are better off by keeping away from IDEs. All those
irrelevant bells and whistles do nothing more than distracting them from what
they are doing and should be doing. More to the point, they actively contribute
to build up, in the eyes of the newbie, that in order to write even the most
simple, trivial programs you are forced to use incredibly complex tools which
take a lot of time and effort to master. We all can do without that nonsense.


Rui Maciel

 

[LR]

LR wrote:

[snip stuff about why punch cards are better than GUIs and command lines]

Yes, but...

didn't you ever trip over and drop the entire deck on the floor?

No. Never.

Being a programmer means that you should always be careful about
possible error conditions and act defensively to avoid them.

I used rubber bands for large decks and paper clips for very small ones.

However, I've heard that the school I was learning/working at once had a
termite problem. OTOH my cards will survive the next one of these,
http://en.wikipedia.org/wiki/Solar_storm_of_1859.

LR

 

[Andrew Poelstra]

You're right - it doesn't. Fortunately for me, that's not what I wrote.


IDEs are "incredibly complex"?!?!? Wow, speaking of "astonishingly
silly" notions. Have you considered that, to someone who's 20+ years
younger than you or I, GUIs are the *normal* way they've been doing
things for as long as they've been using a computer?

I'm eighteen. I grew up on a Unix prompt and still program that way
most of the time. (At work we use VS; it's a lot nicer than any text
editor available for Windows, but on Linux I like vi.)

And most programmer kids these days use Linux, and I'm sure many of
them will agree with me.

Please note - I'm not saying that no one should ever learn command-
line compilers and make files. I'm just saying that, on the first week
of class, learning to program is difficult enough; allowing students to
use a familiar graphical environment that resembles the applications
they've grown up with will be less jarring for them.

I don't think so. The first time I used an IDE, it was Visual C++ 6,
and I was very thrown. I didn't understand why my output disappeared
instantly, and didn't know how to run my code from a command line.

Whereas with a text-based system, you just run one command

gcc hello.c

and progress to

gcc main.c linkedlist.c readfile.c

over the course of an intro course.

 

[Balog Pal]

There are exceptions to every rule. You're a geek. So am I. The fact
that we're here on usenet instead of something trendy like Facebook
or MySpazz, pretty much proves that we're not normal.

When you're teaching a class though, you can't develop the curriculum
based solely on the needs of the quickest kid in class - you'd lose the
majority if you did that. On the other hand, if I were teaching a C++
class, I'd teach it using VS, but if an advanced student wanted to use
something else, I'd let them.

I' doubt on the "most" part, but anyway, that is pretty clearly a simple
childish group-creting and showing-off behavior that has nothing to do with
professional programming whatsoever.

Teenagers just must do a lot of things differently, don't they? And have a
strong built-in belief that that way is cooler and superior, to the common
one.

It is interesting, yhat for many cases the youngsters have an actual edge --
using *new* technology naturally as while the old folks stick to gadgets of
prevus decades, having problems with the new.

This case is quite the opposite: the 30-year old archaic **** is preferred
to the 10-year old one.

Good evidence poresented hete in the previous post: someone is so high up
with himself so brags about inability to even find out how ho launch a
command prompt when he needs one. And the soulution is supposed to be to
strip everyone of the interface with a choice -- to present him the command
line and nothing else.

The king has no clothes, whatsoever. Just our broken society thinks its
is impolite to point out. :-/

I think you're underestimating how foreign and intimidating a command-
line is to most people - again, I'm talking about the majority here,
not just a few exceptionally talented and motivated "programmer kids."

What misses the point by a lightyear. Real talented "programmer kids" have
no need of a programming school whatsoever, and will not benefit there
anything. They an learn the stuff from real practicioners or the "scene",
or do whatever they like at home.

And if there is a class like that in high-school or uni, they can side-step
it after a single talk with the teacher. Or if they chose to attend, can
complete any assignment in zero time.

If there is a complaint, of "how I couln't" it is a clear indication facing
a fake/whiner. I recalling the scene -- "I can't do" was a thing you
never heard. It was about "see what I did" on one side, and paying close
attention of the others.

To most folks, "just run one command" is technobabble that makes no
more sense to them than "just adjust the phase harmonics of the shield
generator" would make.

Indeed, however those who uinderstand the technobabble can point out that
the claims are false -- and the babble serves only this obfuscating purpose
that works well only with the outsiders.

Trying the same bullshitting in a pro forum does not indicate a high WIS
allocation.

 

[Andrew Poelstra]

I' doubt on the "most" part, but anyway, that is pretty clearly a simple
childish group-creting and showing-off behavior that has nothing to do with
professional programming whatsoever.

Teenagers just must do a lot of things differently, don't they? And have a
strong built-in belief that that way is cooler and superior, to the common
one.

It is interesting, yhat for many cases the youngsters have an actual edge --
using *new* technology naturally as while the old folks stick to gadgets of
prevus decades, having problems with the new.

This case is quite the opposite: the 30-year old archaic **** is preferred
to the 10-year old one.

Either that, or the ten thousand features vi has offered for 30 years are
actually useful. There's a reason people still use vi and emacs, why mail
servers still use sendmail, and why people still use RSA and ethernet and
binary computers.

Suggesting any of those to be "youthful rebellion" is purely nonsense.