Learning C++
Harold A. Climer
his library. He gave me quite a few books on programming using
different computer languages. BASIC,PASCAL, C,C++, etc.
I have had some experience programming in TRUEBASIC.
I would like to learn to program using C or C++.( Not professionally I
am too old for that)
What software do I need?(Something inexpensive) I have two computers.
The one at work is running Vista Home SP1 and the one at home is
running Windows XP MCE SP3.
I have seen some C++ stuff by Borland and Microsoft. I really do not
need the latest software,but I would like to be able for it to work
properly on XP and Vista.
Harold A Climer
Dept. Of Physics Geology, and Astronomy
U.T, Chattanooga
Rm. 406A Engineering, Math & Computer Science Building
615 McCallie Ave. Chattanooga TN 37403
Harold...@utc.edu
Sam
> A friend of mine is moving to California and did not want to move all
> his library. He gave me quite a few books on programming using
> different computer languages. BASIC,PASCAL, C,C++, etc.
> I have had some experience programming in TRUEBASIC.
> I would like to learn to program using C or C++.( Not professionally I
> am too old for that)
> What software do I need?(Something inexpensive) I have two computers.
> The one at work is running Vista Home SP1 and the one at home is
> running Windows XP MCE SP3.
> I have seen some C++ stuff by Borland and Microsoft. I really do not
> need the latest software,but I would like to be able for it to work
> properly on XP and Vista.
Borland, on this particular subject, is practically dead, monopolized out of
existence, by MSFT.
Somewhere on MSFT's web site you should find a free download of Visual
Studio Express, or something named along those lines. That'll suffice for
beginners. I don't know if MSFT updated their freeware for Vista, but it'll
definitely work on XP.
Full development tools from MSFT are pricy, since developers are a revenue
source for MSFT. However, given that you're @.edu, you should be able to
easily get a rather steep educational discount for the full Visual Studio
kit. MSFT wants mindshare from young skulls full of mush, so they shove
their wares into .edus for peanuts.
The microsoft.* usenet groups would be your most appropriate channel for
getting help for MS development tools. comp.lang.c++ is purely for
language-specific topics, which are independent of any vendor.
dragan
> A friend of mine is moving to California and did not want to move all
> his library.
Wow, I CAN relate!! And who is he that KNOWS C++ cannot?! An appropriate
post for the season (if there is season for such) "lament"?. I will pose the
question as a separate thread.
> He gave me quite a few books on programming using
> different computer languages. BASIC,PASCAL, C,C++, etc.
> I have had some experience programming in TRUEBASIC.
> I would like to learn to program using C or C++.( Not professionally I
> am too old for that)
That is relevant, more than you think maybe.
> What software do I need?(Something inexpensive)
You need: inquisitiveness, desire, drive (a purpose? an alterior
motive?).... The software is pretty much irrelevant. Though I can recommend
the MS free compilers (at least the behemoths gave SOMEthing back!).
> I have two computers.
> The one at work is running Vista Home SP1 and the one at home is
> running Windows XP MCE SP3.
> I have seen some C++ stuff by Borland and Microsoft. I really do not
> need the latest software,but I would like to be able for it to work
> properly on XP and Vista.
You should focus on building something first, before you get into deployment
scenarios. That is, unless you wanna try the way the way of General Moters.
> Harold A Climer
> Dept. Of Physics Geology, and Astronomy
Your ignorance and lack of research on the matter makes me question whether
you are a TROLL. Read: I don't believe you!
nick
> Harold A. Climer writes:
> > A friend of mine is moving to California and did not want to move all
> > his library. He gave me quite a few books on programming using
> > different computer languages. BASIC,PASCAL, C,C++, etc.
> > I have had some experience programming in TRUEBASIC.
> > I would like to learn to program using C or C++.( Not professionally I
> > am too old for that)
> > What software do I need?(Something inexpensive) I have two computers.
> > The one at work is running Vista Home SP1 and the one at home is
> > running Windows XP MCE SP3.
> > I have seen some C++ stuff by Borland and Microsoft. I really do not
> > need the latest software,but I would like to be able for it to work
> > properly on XP and Vista.
>
> Borland, on this particular subject, is practically dead, monopolized out of
> existence, by MSFT.
>
Poor Borland. They sold their entire line of development tools last
year, but apparently some of the software is still going to see new
development. I doubt this gets much serious use these days.
www.embarcadero.com/products/cbuilder
> Somewhere on MSFT's web site you should find a free download of Visual
> Studio Express, or something named along those lines. That'll suffice for
> beginners. I don't know if MSFT updated their freeware for Vista, but it'll
> definitely work on XP.
The newer releases work with post-XP Windows editions. The debugger
and code completion are excellent, great for beginners. Be prepared
for some registration key nonsense though. www.microsoft.com/Express/VC/
> Full development tools from MSFT are pricy, since developers are a revenue
> source for MSFT. However, given that you're @.edu, you should be able to
> easily get a rather steep educational discount for the full Visual Studio
> kit. MSFT wants mindshare from young skulls full of mush, so they shove
> their wares into .edus for peanuts.
The Express Edition should be more than adequate for casual use,
though... You probably won't need to bother with anything more.
The only alternative to the Microsoft toolchain that really gets any
use on Windows as far as I know is MinGW (Windows port of gcc, the
standard-issue gnu/linux compiler). It might be worth trying as well,
but I'm willing to bet it's a bit more trouble to get set up.
-- Nick
osmium
> The only alternative to the Microsoft toolchain that really gets any
> use on Windows as far as I know is MinGW (Windows port of gcc, the
> standard-issue gnu/linux compiler). It might be worth trying as well,
> but I'm willing to bet it's a bit more trouble to get set up.
MinGW is about as easy to set up as anything you are likely to see, it is
what I use. I am not in love with the debugger or the documentation and
there is no Usenet newsgroup. Why use it? I have had some traumatic
experiences with Microsoft products and avoid them when possible, 'nuff
said. Since you and I are both guessing, my guess is that the VC footprint
is huge compared to MinGW. I tried to install a version of VC once and it
bombed during the process, I said screw it, and never looked back.
Andy Champ
<snip>
> You should focus on building something first, before you get into deployment
> scenarios. That is, unless you wanna try the way the way of General Moters.
>
>> Harold A Climer
>> Dept. Of Physics Geology, and Astronomy
>
> Your ignorance and lack of research on the matter makes me question whether
> you are a TROLL. Read: I don't believe you!
>
>> U.T, Chattanooga
>> Rm. 406A Engineering, Math & Computer Science Building
>> 615 McCallie Ave. Chattanooga TN 37403
>> Harold...@utc.edu
>
Whether this is him or not I can't say but:
http://www.utc.edu/Faculty/Harold-Climer/
The guy exists.
On the other hand...
http://www.utc.edu/Academic/ComputerScienceAndEngineering/
They have a comp sci department - why ask here, and not there?
Andy
Harold A. Climer
Ron AF Greve
Microsoft visual C++ express edition is a free download from :
http://www.microsoft.com/express/
You might also want to download the MSDN docs.
"Harold A. Climer" <Harold...@utc.edu> wrote in message
news:nu3oj5lfhug5cva05...@4ax.com...
--
Regards, Ron AF Greve
http://informationsuperhighway.eu
BGB / cr88192
"osmium" <r124c...@comcast.net> wrote in message
news:7q3qad...@mid.individual.net...
yeah, MinGW has a few of its own little issues, but tends to be easier to
set up than getting all of MS's free stuff to play well together...
then again, I tend to use a kind of "oddball" setup for MSVC, where I
generally use MSVC (via the Windows SDK) in conjunction with some of the
tools from Cygwin (mostly GNU make).
added fiddling is needed to plug together the Windows SDK and DirectX SDK.
one would think MS would make them "auto-plug", but apparently not (unless
maybe one has to install them in a certain order?...).
then in this custom setup, I also ended up using WinDbg and AMD CodeAnalyst,
...
dunno about Visual Studio, not really used it much and not really sure what
it really has to offer (or, at least, what it could offer that would be
worth trying to get an approx 600 kloc project loaded into a VS project
file...).
...
>
Michael Tsang
Hash: SHA1
Harold A. Climer wrote:
> I have seen some C++ stuff by Borland and Microsoft. I really do not
> need the latest software,but I would like to be able for it to work
> properly on XP and Vista.
I use tools from GNU (g++) but g++ for 64-bit Windows is not ready for
production yet (it is in B stage). You may consider Microsoft tools for 64-
bit Windows (Borland is nearly dead). Grab a copy of MSVC Express 2010 (or
2008 if you don't need to use C++0x) from Microsoft website. (but I admit:
Microsoft tools are too heavy-weighted. It takes hours for me to install
MSVC Express 2010 on a Windows 7 machine. It only takes seconds for me to
install a complete set of GNU toolchain (build-essential) on Ubuntu)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAktANBsACgkQG6NzcAXitM/sUACgku4P8JQ9gM4W8tkAT5/Hi70I
U3gAn30pNdvCAHygA0KSpKwvk8Lgbhvg
=Ch3A
-----END PGP SIGNATURE-----
red floyd
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Harold A. Climer wrote:
>
>> I have seen some C++ stuff by Borland and Microsoft. I really do not
>> need the latest software,but I would like to be able for it to work
>> properly on XP and Vista.
>
> I use tools from GNU (g++) but g++ for 64-bit Windows is not ready for
> production yet (it is in B stage). You may consider Microsoft tools for 64-
> bit Windows (Borland is nearly dead). Grab a copy of MSVC Express 2010 (or
> 2008 if you don't need to use C++0x) from Microsoft website. (but I admit:
> Microsoft tools are too heavy-weighted. It takes hours for me to install
> MSVC Express 2010 on a Windows 7 machine. It only takes seconds for me to
> install a complete set of GNU toolchain (build-essential) on Ubuntu)
For XP and Vista, I'd probably agree. The MinGW chain may not be fully
64-bit ready.
Warning, if you do choose VS2008 Express, when you build projects, do
the following:
1. MAKE SURE YOU SELECT NATIVE CODE, NOT MANAGED!!!!! MS's "Managed"
code is something other than ISO Standard C++.
2. Start with empty console projects. Do not use a wizard, other than
to create an empty console project. This will allow you to start
learning ISO C++ as opposed to MFC, ATL, or .NET.
Once you are comfortable and familiar with Standard C++, you can then
try one of the frameworks for GUI apps (again, I wouldn't recommend
.NET, as it uses MS specific extensions to the language).
Jorgen Grahn
> A friend of mine is moving to California and did not want to move all
> his library. He gave me quite a few books on programming using
> different computer languages. BASIC,PASCAL, C,C++, etc.
> I have had some experience programming in TRUEBASIC.
> I would like to learn to program using C or C++.( Not professionally I
> am too old for that)
What C++ books were those? The other languages you mention (BASIC and
Pascal) make me think the collection is from the late 1980s. You will
not learn decent C++ from them; the language and its users have
improved so much since.
BR,
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
James Kanze
[...]
> Warning, if you do choose VS2008 Express, when you build projects, do
> the following:
> 1. MAKE SURE YOU SELECT NATIVE CODE, NOT MANAGED!!!!! MS's "Managed"
> code is something other than ISO Standard C++.
Isn't this the default. (I've used VS 2008, or at least, the
compiler in VS 2008, and I've never had managed C++. And as far
as I know, I've not done anything particular.)
> 2. Start with empty console projects. Do not use a wizard, other than
> to create an empty console project. This will allow you to start
> learning ISO C++ as opposed to MFC, ATL, or .NET.
Regardless of where you get the compiler from, start by using a
decent editor and a simple makefile, and don't hassle all the
extra complexities of the IDE. It only makes life more
difficult and introduces additional complexities.
--
James Kanze
Balog Pal
>> 2. Start with empty console projects. Do not use a wizard, other than
>> to create an empty console project. This will allow you to start
>> learning ISO C++ as opposed to MFC, ATL, or .NET.
>
> Regardless of where you get the compiler from, start by using a
> decent editor and a simple makefile, and don't hassle all the
> extra complexities of the IDE. It only makes life more
> difficult and introduces additional complexities.
Should we also drop using matches and gas lighters and restrict to "natural"
methods of creating fire?
Makefile is certainnly easy to whoever already learned to use it, and does
so for a decade. For novices it just sucks. Especially compared to an IDE
with a project manager -- there all the supposed complexity is using "add
new" menu adding a new item and "add existing" otherwise...
For the other part -- if the aim of learning C++ is not an abstract one, but
to create some useful stuff, starting with an app framework that fits that
aim may be a good idea too. It has a fair amount of dangers, but so does
going barefoot for too long.
Alf P. Steinbach
> "James Kanze" <james...@gmail.com>
>
>
>>> 2. Start with empty console projects. Do not use a wizard, other than
>>> to create an empty console project. This will allow you to start
>>> learning ISO C++ as opposed to MFC, ATL, or .NET.
>>
>> Regardless of where you get the compiler from, start by using a
>> decent editor and a simple makefile, and don't hassle all the
>> extra complexities of the IDE. It only makes life more
>> difficult and introduces additional complexities.
>
> Should we also drop using matches and gas lighters and restrict to
> "natural" methods of creating fire?
>
> Makefile is certainnly easy to whoever already learned to use it, and
> does so for a decade. For novices it just sucks. Especially compared to
> an IDE with a project manager -- there all the supposed complexity is
> using "add new" menu adding a new item and "add existing" otherwise...
Well I've had a lot of feedback on this topic from students. And although that
was more than ten years ago, they all agreed uniformly that after learning the
command line that was what they generally preferred. The situation with
professional development is different, because it's often much larger scale.
> For the other part -- if the aim of learning C++ is not an abstract one,
> but to create some useful stuff, starting with an app framework that
> fits that aim may be a good idea too. It has a fair amount of
> dangers, but so does going barefoot for too long.
I'm now pretty sure that for most people C++ can only be suitable as a first
language in a very supportive environment, essentially, in school.
I think that a person who has sufficient knowledge of programming to learn C++
on his/her own, will not have a problem with going barefoot. :-)
Cheers,
- Alf
Balog Pal
>> Makefile is certainnly easy to whoever already learned to use it, and
>> does so for a decade. For novices it just sucks. Especially compared to
>> an IDE with a project manager -- there all the supposed complexity is
>> using "add new" menu adding a new item and "add existing" otherwise...
>
> Well I've had a lot of feedback on this topic from students. And although
> that was more than ten years ago, they all agreed uniformly that after
> learning the command line that was what they generally preferred. The
> situation with professional development is different, because it's often
> much larger scale.
I don't have feedback from students, only see what people that practice do
around. My experience is pretty sour -- I heard too many claims on how
command line, make, (vim, etc) development is good, and how much and IDE is
just distracton. The I found their work pretty inefficient, doing extreme
amount of "fiddling".
(OTOH certainly an IDE will not make anyone smart or able, and I saw
inefficient work in IDE too...)
>> For the other part -- if the aim of learning C++ is not an abstract one,
>> but to create some useful stuff, starting with an app framework that fits
>> that aim may be a good idea too. It has a fair amount of dangers, but
>> so does going barefoot for too long.
>
> I'm now pretty sure that for most people C++ can only be suitable as a
> first language in a very supportive environment, essentially, in school.
>
> I think that a person who has sufficient knowledge of programming to learn
> C++ on his/her own, will not have a problem with going barefoot. :-)
You mean a theoretic or a practical problem? ;-))
For example I have no problem wit *ability* to go barefoot. But I absolutely
refuse to do so unless there is a very good reason. Guess some people think
it is sexy or romantic -- just as many programmers inclined to recreate the
wheel instead of use a stock one -- to me that is just excess pain without
gain.
The argument is noce, how about using it the other way around, having a
person bright enough to use C++ well shall we realisticly expect him getting
lost in a *good* IDE? ( my roll of good IDE's include Borland C++ 3.1
(and some earlier) and Visual C++/Studio, all versions I used... )
The usual suggestion goes as to learn command line first -- use IDE only
after mastering that to see behind, I am still skeptic about it.
An IDE leaves way more time to real issues in learning and jump-start to see
something "work", also straightforward way to edit/compile/fix/experiment.
The learning examples are okay with a single translation unit for long, and
with a couple of sources located in a small directory tree for whatever.
Without a need for custom build steps, extra generators, etc -- anything
that would overload the simplest project manager. Which at least handles
the dependances, correctly, without any black magic.
red floyd
> * Balog Pal:
>> "James Kanze" <james...@gmail.com>
>>
>>
>>>> 2. Start with empty console projects. Do not use a wizard, other than
>>>> to create an empty console project. This will allow you to start
>>>> learning ISO C++ as opposed to MFC, ATL, or .NET.
>>>
>>> Regardless of where you get the compiler from, start by using a
>>> decent editor and a simple makefile, and don't hassle all the
>>> extra complexities of the IDE. It only makes life more
>>> difficult and introduces additional complexities.
>>
>> Should we also drop using matches and gas lighters and restrict to
>> "natural" methods of creating fire?
>>
>> Makefile is certainnly easy to whoever already learned to use it, and
>> does so for a decade. For novices it just sucks. Especially compared
>> to an IDE with a project manager -- there all the supposed complexity
>> is using "add new" menu adding a new item and "add existing" otherwise...
>
> Well I've had a lot of feedback on this topic from students. And
> although that was more than ten years ago, they all agreed uniformly
> that after learning the command line that was what they generally
> preferred. The situation with professional development is different,
> because it's often much larger scale.
>
Honestly, for professional development, I prefer makefiles to IDEs,
simply because I have complete control -- I'm not constrained by what
the IDE (*cough*VS*cough*) thinks is a legit way of building stuff.
Andy Champ
>
> Honestly, for professional development, I prefer makefiles to IDEs,
> simply because I have complete control -- I'm not constrained by what
> the IDE (*cough*VS*cough*) thinks is a legit way of building stuff.
>
We all use the IDE day-to-day, and MSBuild under Kinook's Visual Build
Pro for the automated overnight builds.
Andy
Ian Collins
> red floyd wrote:
>>
>> Honestly, for professional development, I prefer makefiles to IDEs,
>> simply because I have complete control -- I'm not constrained by what
>> the IDE (*cough*VS*cough*) thinks is a legit way of building stuff.
>>
> I beg to differ. But you have looked at MSBuild?
A lot of us don't use windows. While there are good cross platform
IDEs, they are fine for green field hosted development but they don't
support cross-compiling for non-native targets.
When a project mixes code from different sources (open source libraries
for example), makefiles are usually the best, if not only, option.
Every project I work on has a mix of local and open source code, so the
build system has to cope with both. There's so much open source code
out there, the sooner a developer gets to know how to build form the
command line, the better.
--
Ian Collins
Jorgen Grahn
> "Alf P. Steinbach" <al...@start.no>
>
>>> Makefile is certainnly easy to whoever already learned to use it, and
>>> does so for a decade. For novices it just sucks. Especially compared to
>>> an IDE with a project manager -- there all the supposed complexity is
>>> using "add new" menu adding a new item and "add existing" otherwise...
>>
>> Well I've had a lot of feedback on this topic from students. And although
>> that was more than ten years ago, they all agreed uniformly that after
>> learning the command line that was what they generally preferred. The
>> situation with professional development is different, because it's often
>> much larger scale.
>
> I don't have feedback from students, only see what people that practice do
> around. My experience is pretty sour -- I heard too many claims on how
> command line, make, (vim, etc) development is good, and how much and IDE is
> just distracton. The I found their work pretty inefficient, doing extreme
> amount of "fiddling".
What kind of fiddling was that? I use Emacs, Make, version control
and the Unix shell are my usual tools, so I have a hard time imagining
what those inefficiencies were.
The Makefile can be an issue if you don't understand that it needs
to capture all dependencies (i.e. you have to have autogeneration
for them, using something like makedepend), or that you can rely on
the default *.cpp -> *.o rules. Once you have seen a decent
Makefile *once*, the problem is gone.
There are various kinds of pressures at my workplace to use Eclipse
For Everything, so I genuinely want to know what, if anything, I'm
missing. Most things I've seen so far have been functions I already
have and use, only here they are wrapped in a clumpsy GUI.
>> I think that a person who has sufficient knowledge of programming to learn
>> C++ on his/her own, will not have a problem with going barefoot. :-)
>
> You mean a theoretic or a practical problem? ;-))
>
> For example I have no problem wit *ability* to go barefoot. But I absolutely
> refuse to do so unless there is a very good reason. Guess some people think
> it is sexy or romantic -- just as many programmers inclined to recreate the
> wheel instead of use a stock one -- to me that is just excess pain without
> gain.
On Windows with its weak command-line and lack of tools, that seems
likely to be true, but the Unix development environment I mentioned
above doesn't feel very "barefoot" or manual to me.
Balog Pal
>> I don't have feedback from students, only see what people that practice
>> do
>> around. My experience is pretty sour -- I heard too many claims on how
>> command line, make, (vim, etc) development is good, and how much and IDE
>> is
>> just distracton. The I found their work pretty inefficient, doing
>> extreme
>> amount of "fiddling".
>
> What kind of fiddling was that? I use Emacs, Make, version control
> and the Unix shell are my usual tools, so I have a hard time imagining
> what those inefficiencies were.
In my terminology emacs is an IDE by most practical means...
"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.
During all the usual cases -- primary code writing, review, raw-compile,
debug...
> The Makefile can be an issue if you don't understand that it needs
> to capture all dependencies (i.e. you have to have autogeneration
> for them, using something like makedepend), or that you can rely on
> the default *.cpp -> *.o rules. Once you have seen a decent
> Makefile *once*, the problem is gone.
Pobably so -- but the alternative is to not have the whole problem set at
all.
What btw is pretty shocking. I recall Borland 3.x' exported makefile had
just the list of .c sources, and .AUTODEPEND up front -- the dependencies
were compiled into .obj and make itself read them, if the file was present.
20 years ago. Then in today's sytems I still see the need for separete .d
outputs and cryptic rules to make them picked up? It is crazy.
> There are various kinds of pressures at my workplace to use Eclipse
> For Everything, so I genuinely want to know what, if anything, I'm
> missing. Most things I've seen so far have been functions I already
> have and use, only here they are wrapped in a clumpsy GUI.
I don;t have any personal experience with Eclipse, have one friend who likes
it all the way, and saw many comments on forums that say it is nuts and very
counter-intuitive.
>>> I think that a person who has sufficient knowledge of programming to
>>> learn
>>> C++ on his/her own, will not have a problem with going barefoot. :-)
>>
>> You mean a theoretic or a practical problem? ;-))
>>
>> For example I have no problem wit *ability* to go barefoot. But I
>> absolutely
>> refuse to do so unless there is a very good reason. Guess some people
>> think
>> it is sexy or romantic -- just as many programmers inclined to recreate
>> the
>> wheel instead of use a stock one -- to me that is just excess pain
>> without
>> gain.
>
> On Windows with its weak command-line and lack of tools, that seems
> likely to be true, but the Unix development environment I mentioned
> above doesn't feel very "barefoot" or manual to me.
Just like you have a selection of shells on unix, you can do the same on
windows. And certainly all the unix "tools" are available.
Just appear much less needed.
There was a good joke about ATM with unix interface. ;-) Unfortunately the
keywords are not google-friendly, but I'm sure you can imagine it.
And the point is, that if you can carry out what you want with a single
keypress or click (sometimes with 2, other times with 0) why use more? Why
re-type the info before you (or paste it) if avoidable?
You know, 2 decades ago, when Windows (3.0) started to enter the picture
(and some other shells on DOS), I was a very loud fan of command line and
similar tools. the archives have my posts about how much faster I can do
anything by typing (or selection) than by fiddling with the mouse. And
that was the case too.
Thoug then the filenames were 8.3 and we didn't have too much of them (a 40
Mb disk was quite huge).
But eventually the picture changed -- on one hand the interface improved
drasticly with context menus, on the other the amount of information grew,
and working with text-based proggies became increasingly suboptimal.
James Kanze
> "James Kanze" <james.ka...@gmail.com>
> >> 2. Start with empty console projects. Do not use a wizard, other than
> >> to create an empty console project. This will allow you to start
> >> learning ISO C++ as opposed to MFC, ATL, or .NET.
> > Regardless of where you get the compiler from, start by using a
> > decent editor and a simple makefile, and don't hassle all the
> > extra complexities of the IDE. It only makes life more
> > difficult and introduces additional complexities.
> Should we also drop using matches and gas lighters and
> restrict to "natural" methods of creating fire?
Irrelevant.
> Makefile is certainnly easy to whoever already learned to use
> it, and does so for a decade. For novices it just sucks.
> Especially compared to an IDE with a project manager -- there
> all the supposed complexity is using "add new" menu adding a
> new item and "add existing" otherwise...
Makefiles are certainly something additional that you have to
learn. And they shouldn't be necessary for a beginner. I used
to believe that IDE's were a good thing for beginners, because
they allowed deferring the learning of makefiles and such---one
thing at a time. For the last couple of months, however, I've
had to work under an IDE, and I now realize that they represent
even more complexity than make. So until someone comes out with
something better, we're stuck with make as the simplest
solution: the easiest to learn and use.
--
James Kanze
James Kanze
> On Tue, 2010-01-05, Balog Pal wrote:
> > "Alf P. Steinbach" <al...@start.no>
> >> programming to learn C++ on his/her own, will not have a
> >> problem with going barefoot. :-)
> > You mean a theoretic or a practical problem? ;-))
> > For example I have no problem wit *ability* to go barefoot.
> > But I absolutely refuse to do so unless there is a very good
> > reason. Guess some people think it is sexy or romantic --
> > just as many programmers inclined to recreate the wheel
> > instead of use a stock one -- to me that is just excess pain
> > without gain.
> On Windows with its weak command-line and lack of tools, that
> seems likely to be true, but the Unix development environment
> I mentioned above doesn't feel very "barefoot" or manual to
> me.
On Windows, you can install any number of Unix-like toolkits.
And even the native tools, like cmd.exe, are getting better.
What I can say is that it's usually a lot faster to type in a
short command than to rummage around in dozens of menus, just to
find that the particular command you need wasn't provided.
All of which explains why professional programmers in a Unix
environment regularly outperform those in a Windows environment.
What surprised me, having to use a IDE, is just how difficult it
is to do the things that were provided. Even for the simple
tasks of a beginner, an IDE just slows things down and makes
them more difficult to do correctly.
--
James Kanze
James Kanze
> "Jorgen Grahn" <grahn+n...@snipabacken.se>
[...]
> > The Makefile can be an issue if you don't understand that
> > it needs to capture all dependencies (i.e. you have to have
> > autogeneration for them, using something like makedepend),
> > or that you can rely on the default *.cpp -> *.o rules.
> > Once you have seen a decent Makefile *once*, the problem is
> > gone.
> Pobably so -- but the alternative is to not have the whole
> problem set at all.
> What btw is pretty shocking. I recall Borland 3.x' exported
> makefile had just the list of .c sources, and .AUTODEPEND up
> front -- the dependencies were compiled into .obj and make
> itself read them, if the file was present. 20 years ago.
> Then in today's sytems I still see the need for separete .d
> outputs and cryptic rules to make them picked up? It is
> crazy.
The problem is that in most cases, the authors of make aren't
speaking with the authors of the compiler. When they do: Sun's
make has a similar feature. Which only works with Sun CC, of
course.
There is a middle road between everything graphic and in menus,
and having to write every dependency yourself, or even write
some complicated code in make to generate them automatically.
[...]
> > On Windows with its weak command-line and lack of tools,
> > that seems likely to be true, but the Unix development
> > environment I mentioned above doesn't feel very "barefoot"
> > or manual to me.
> Just like you have a selection of shells on unix, you can do
> the same on windows. And certainly all the unix "tools" are
> available.
> Just appear much less needed.
Do they? I don't know any really good programmer under Windows
who doesn't use them.
> There was a good joke about ATM with unix interface. ;-)
> Unfortunately the keywords are not google-friendly, but I'm
> sure you can imagine it.
Yes, but the target audience isn't the same.
> And the point is, that if you can carry out what you want with
> a single keypress or click (sometimes with 2, other times with
> 0) why use more? Why re-type the info before you (or paste
> it) if avoidable?
The point is that you can't. Regardless of the IDE. You can't
enter code with a single click, and you can't do any advanced
editing with a single click.
--
James Kanze
peter koch
Could you exemplify? I am on of those who grew up with make-files,
entered IDE-land and ended back with make-files. But for me, the step
back to make-files was not a step forwards: I find the IDE simpler and
faster to use.
/Peter
Andy Champ
Sure, no arguments there. I;ve been in that position myself.
But when he's using "the IDE (*cough*VS*cough*)" he's probably Windoze only.
Andy
nick
> [...]
>
> > "Jorgen Grahn" <grahn+n...@snipabacken.se>
> > [...]
> > And the point is, that if you can carry out what you want with
> > a single keypress or click (sometimes with 2, other times with
> > 0) why use more? Why re-type the info before you (or paste
> > it) if avoidable?
>
> The point is that you can't. Regardless of the IDE. You can't
> enter code with a single click, and you can't do any advanced
> editing with a single click.
>
Sure I can... I can enter whatever code's in my paste buffer by
clicking my middle mouse button.
Balog Pal
> There is a middle road between everything graphic and in menus,
> and having to write every dependency yourself, or even write
> some complicated code in make to generate them automatically.
Sure. Just like many people wrote here -- make & co. is used to have "all
the power" and to suffice the "I f...ing rule" approach. While IDEs are
built around pre-thought defaults and use cases. And outrside that you're
often hosed or handicapped. But if the supported stuff is along your path,
you can sit back and enjoy.
This thread was about learning, I said that IMO in the phase one learns the
language -- or I could add, a system API, or a library/framework -- there is
no need for the excess power and customization level.
The "new project" wizards' idea of a project layout may not fit some
expert's fine-tuned layout, but I doubt it is not good to try out whatever
is subject of learning. You won't keep that stuff anyway, do you?
And while, as you told, make-writers do not speak with many
compiler-writers, the advice to use the resulting mess is IMO only good for
the lucky situation when they did. ;-)
>> Just like you have a selection of shells on unix, you can do
>> the same on windows. And certainly all the unix "tools" are
>> available.
>
>> Just appear much less needed.
>
> Do they? I don't know any really good programmer under Windows
> who doesn't use them.
What I wanted to say, they will be sitting there installed, almost sure, but
most time just collecting dust. (Hm, I exclude the cases when they are
invoked by specialized scripts/programs made to cover some use case...)
>> There was a good joke about ATM with unix interface. ;-)
>> Unfortunately the keywords are not google-friendly, but I'm
>> sure you can imagine it.
>
> Yes, but the target audience isn't the same.
Do you really think that interface dexterity shall count that much in that
kind of design? So if the most common use case is "withdraw $50" it is put
on a button only for "idiots", while the experts are damned to type in the
whole command and the actual amount? Because they can, reliably? And may
want to fetch $3.1415 more often then others?
>> And the point is, that if you can carry out what you want with
>> a single keypress or click (sometimes with 2, other times with
>> 0) why use more? Why re-type the info before you (or paste
>> it) if avoidable?
>
> The point is that you can't. Regardless of the IDE. You can't
> enter code with a single click,
I what? Thinking up and writing code was never the task of the IDE (or any
editor). It is environment to work, not replacement of the programmer.
I don't expect code written. (Though simple editors do have ability to
insert common code fractions on up to 2 clicks or keys).
But I do expect to
- have instant and easy access to most relevant information (like in code
definition windows, call/caller graphs, man/msdn pages)
- navigation around all the interesting locations (like mentioned before +
error spot from build)
- sensible management of windows and panes that present the stuff I am
working with
- easy access to most/all tools I need along the road (editors for different
kinds of sources, the build, debuggers, source control)
And I certainly welcome additional intelligent behavior, like auto-checkout
files I type into, collect TODOs, pending checkins, etc.
> and you can't do any advanced editing with a single click.
What is "advanced editing" mean?
Refactoring actions? I never used such an editor yet, but would welcome --
it certainly sounds like an IDE functionality and hardly doable by atomic
tools.
Reformatting code? That is basic in most anything.
Search/replace in all project files? I can do it in IDE, not sure how it is
doable for a general case with make-build... Especially ad-hoc and without
pain.
Please give some example what case were you thinking here.
dragan
"Andy Champ" <no....@nospam.invalid> wrote in message
news:A9adnVyujtZvUKHW...@eclipse.net.uk...
> dragan wrote:
> <snip>
>> You should focus on building something first, before you get into
>> deployment scenarios. That is, unless you wanna try the way the way of
>> General Moters.
>>
> Motors. But WTH.
No, that would be treading toward defamation of a real company. ;)
>
>>> Harold A Climer
>>> Dept. Of Physics Geology, and Astronomy
>>
>> Your ignorance and lack of research on the matter makes me question
>> whether you are a TROLL. Read: I don't believe you!
>>
>>> U.T, Chattanooga
>>> Rm. 406A Engineering, Math & Computer Science Building
>>> 615 McCallie Ave. Chattanooga TN 37403
>>> Harold...@utc.edu
>>
>
> Whether this is him or not I can't say but:
>
> http://www.utc.edu/Faculty/Harold-Climer/
>
> The guy exists.
>
> On the other hand...
>
> http://www.utc.edu/Academic/ComputerScienceAndEngineering/
>
> They have a comp sci department - why ask here, and not there?
>
I was just wondering why someone claiming to be a professor (in math and
comp sci no less!) would not do some basic research, but maybe I was being
to harsh, as I find it easy to just ask occassionally also (just not
usually. Rarely actually). I don't really care who the dude is, it just made
me wonder if he was trolling.
dragan
Now I'm sorry I even bothered to try to help you. (Damn!).
Balog Pal
> Makefiles are certainly something additional that you have to
> learn. And they shouldn't be necessary for a beginner. I used
> to believe that IDE's were a good thing for beginners, because
> they allowed deferring the learning of makefiles and such---one
> thing at a time. For the last couple of months, however, I've
> had to work under an IDE, and I now realize that they represent
> even more complexity than make.
Please write an example.
And do you mean that the excess complexity you are discovering is something
that is genuinely present in beginner's projects, or it is tied to the
project you (as a seasoned expert) were summoned?
> So until someone comes out with
> something better, we're stuck with make as the simplest
> solution: the easiest to learn and use.
This sounds like your bunch of make experts could manage the build of a
project that was not fit an IDE's idea. And found it easier too -- that is
hardly surprising.
But I don't see how actual easyness follow.
IMO if you come to production, and any non-trivial project, managing the
build is an expert area in its own right.
I certainly wouldn't start to rig my lamelist-candidate if put in the
situation (despite having worked with make, and have clues). But ask somene
really fit, to create the initial solution, and before gone, playing
expected scenarios of maitainance.
After all there are candidates, and why learn them all? Or why go with the
likely suboptimal system built on limited knowledge/familiarity?
Then going back to subject -- production and learnnig do not mix so well.
>
> --
> James Kanze
Balog Pal
> All of which explains why professional programmers in a Unix
> environment regularly outperform those in a Windows environment.
I heard that claim repeated over and over but yet to observe it in
practice...
> What surprised me, having to use a IDE, is just how difficult it
> is to do the things that were provided. Even for the simple
> tasks of a beginner, an IDE just slows things down and makes
> them more difficult to do correctly.
Please some examples. Which IDE and what tasks?
(btw as said before jsut something being 'IDE' has little relation with
'good' -- like in the old times on DOS Borland's IDEs are excellent, while
MS' Programmer's Workbench or how it was called was a simple nightmare. The
firt one could make you fly the other rather dreagged in a swamp. )
Squeamizh
> "Harold A. Climer" <Harold-Cli...@utc.edu> wrote in messagenews:gojpj59d06736mm51...@4ax.com...
>
>
>
>
>
> > On Wed, 30 Dec 2009 22:09:51 -0600, "dragan" <spambus...@prodigy.net>
>
> > DROP DEAD
>
> Now I'm sorry I even bothered to try to help you. (Damn!).
Then rest assured you were no help whatsoever.
James Kanze
> > There is a middle road between everything graphic and in menus,
> > and having to write every dependency yourself, or even write
> > some complicated code in make to generate them automatically.
> Sure. Just like many people wrote here -- make & co. is used
> to have "all the power" and to suffice the "I f...ing rule"
> approach. While IDEs are built around pre-thought defaults
> and use cases. And outrside that you're often hosed or
> handicapped. But if the supported stuff is along your path,
> you can sit back and enjoy.
Of course, it almost never is in practice:-).
> This thread was about learning, I said that IMO in the phase
> one learns the language -- or I could add, a system API, or a
> library/framework -- there is no need for the excess power and
> customization level.
That's what I generally used to think: you wouldn't really want
an IDE in a professional environment, but for learning, they
would permit you to abord one thing at a time. Now that I've
actually used one a bit, I'm less sure. (But maybe that's just
because of my frustration.)
> The "new project" wizards' idea of a project layout may not
> fit some expert's fine-tuned layout, but I doubt it is not
> good to try out whatever is subject of learning. You won't
> keep that stuff anyway, do you?
> And while, as you told, make-writers do not speak with many
> compiler-writers, the advice to use the resulting mess is IMO
> only good for the lucky situation when they did. ;-)
Or for the situation where someone expert in make wrote the
global makefiles. At least with GNU make (and probably some
others), it's quite possible to create a situation where the
client makefile is no more than a list of sources, the name of
the binary, and a single include which does the rest.
Without such support, I guess I'd have to agree. (I was very
frustrated with the restrictions in the IDE when I wrote my
first posting.) On the other hand, can you really learn C++
effectively without some initial support?
> >> Just like you have a selection of shells on unix, you can do
> >> the same on windows. And certainly all the unix "tools" are
> >> available.
> >> Just appear much less needed.
> > Do they? I don't know any really good programmer under Windows
> > who doesn't use them.
> What I wanted to say, they will be sitting there installed,
> almost sure, but most time just collecting dust. (Hm, I
> exclude the cases when they are invoked by specialized
> scripts/programs made to cover some use case...)
I don't find that to be the case, at least not in professional
environments. Everywhere I've been before, most people worked
most of the time from the shells. Where I am now (the first
100% Windows environment for me), it's not so much the case, but
the shells are used for any number of scripts and other things.
And very often, when there's something more complicated that
needs to be done, I can get it done faster from the shell than
the Windows experts can do from the GUI.
> >> There was a good joke about ATM with unix interface. ;-)
> >> Unfortunately the keywords are not google-friendly, but I'm
> >> sure you can imagine it.
> > Yes, but the target audience isn't the same.
> Do you really think that interface dexterity shall count that
> much in that kind of design? So if the most common use case
> is "withdraw $50" it is put on a button only for "idiots",
> while the experts are damned to type in the whole command and
> the actual amount? Because they can, reliably? And may want
> to fetch $3.1415 more often then others?
That isn't the issue. In practice, you really only want to do
one thing at an ATM. Developing software requires a large
number of different activities, from designing UML, writing HTML
documentation, writing code, compiling, setting up code reviews,
etc. Some of this is supported by the usual tools, but in
practice, you're almost always doing something a little bit
more than what they offer.
> >> And the point is, that if you can carry out what you want with
> >> a single keypress or click (sometimes with 2, other times with
> >> 0) why use more? Why re-type the info before you (or paste
> >> it) if avoidable?
> > The point is that you can't. Regardless of the IDE. You
> > can't enter code with a single click,
> I what? Thinking up and writing code was never the task of
> the IDE (or any editor). It is environment to work, not
> replacement of the programmer.
> I don't expect code written. (Though simple editors do have
> ability to insert common code fractions on up to 2 clicks or
> keys).
> But I do expect to
> - have instant and easy access to most relevant information (like in code
> definition windows, call/caller graphs, man/msdn pages)
> - navigation around all the interesting locations (like mentioned before +
> error spot from build)
> - sensible management of windows and panes that present the stuff I am
> working with
> - easy access to most/all tools I need along the road (editors for different
> kinds of sources, the build, debuggers, source control)
All of which is present with a good editor/shell combination
under Unix (or Windows, with bash and gvim). I suppose that you
could call it partially integrated, but if you invoke make from
vim, it will position you on the error. Plus a lot of other
things. (I find that when restructuring code, I make a lot of
use of :argdo g/.../... for example.) In fact, what I most
dislike about Visual Studios is that it doesn't support your
third point; it presents a lot of not particularly relevant
information, but still makes it very hard to find the relevant
information.
> And I certainly welcome additional intelligent behavior, like
> auto-checkout files I type into, collect TODOs, pending
> checkins, etc.
We're using subversion, so there is no check-out. I'm not sure
I like this aspect, however. I don't like the fact that I can
accidentally modify a file I happen to be looking at. (Of
course, in vim, I'll open it read only, so there's no problem.
If Visual Studios has this option, I'm not aware of it.) For
the rest, it's all there from a normal editor and the shell.
> > and you can't do any advanced editing with a single click.
> What is "advanced editing" mean?
Search and replace, for starters. You still have to enter the
regular expression and the replacement text. By the time you've
gotten the dialog box open and your hands back to the keyboard,
I've finished the command.
When editing (entering text), anything which requires using the
mouse is a minus, since it requires taking your hands away from
the base position on the keyboard. (When just browsing, of
course, other rules hold, and I do tend to use the mouse for
most browsing.)
> Refactoring actions? I never used such an editor yet, but
> would welcome -- it certainly sounds like an IDE
> functionality and hardly doable by atomic tools.
> Reformatting code? That is basic in most anything.
> Search/replace in all project files? I can do it in IDE, not
> sure how it is doable for a general case with make-build...
> Especially ad-hoc and without pain.
One frequent operation for me is grepping for every place where
some function is used. Then invoking the editor on just those
files, running through the first modification, memorizing the
keystrokes in a macro as I do, then undoing it, and invoking it
on all of the files I'm editing (and only on those files---with
a bit of care in my original search string, I can only modify
specific uses of my function).
> Please give some example what case were you thinking here.
As above. Or modifying all of the project files (in about
twenty different projects in the solution) in a similar way (but
the modification depends partially on the directory in which the
project file is found).
--
James Kanze
James Kanze
> > Makefiles are certainly something additional that you have to
> > learn. And they shouldn't be necessary for a beginner. I used
> > to believe that IDE's were a good thing for beginners, because
> > they allowed deferring the learning of makefiles and such---one
> > thing at a time. For the last couple of months, however, I've
> > had to work under an IDE, and I now realize that they represent
> > even more complexity than make.
> Please write an example.
Well, in my old home environment, a makefile was basically:
# Copywrite text...
buildRoot = whereever
sources = toto.cc titi.cc tata.cc
testSources = test1.cc test2.cc test3.cc
binary = prog
#include $(buildRoot)/Makefiles/component.mk
If there were addtional steps, of course, it would be more
complicated, but even in cases where I had to first build a
local binary to build one of the sources, 10 or 15 lines would
suffice. And most of the above would be inserted automatically
when I opened a new file named GNUmakefile.
Of course, $(buildRoot)/Makefile/component.mk is pretty
complicated, but a beginner, working in my environment, doesn't
have to deal with it.
> And do you mean that the excess complexity you are discovering
> is something that is genuinely present in beginner's projects,
> or it is tied to the project you (as a seasoned expert) were
> summoned?
To be honest, it's hard to say. I'll admit some frustration,
because I am dealing with a fairly complex environment, in which
many of the sources are either built automatically or are
modified by other programs, with several DLL's, etc. But I was
somewhat surprized at how awkward the GUI interface was, even
for simple things that might actually be part of a beginner's
project.
> > So until someone comes out with something better, we're
> > stuck with make as the simplest solution: the easiest to
> > learn and use.
> This sounds like your bunch of make experts could manage the
> build of a project that was not fit an IDE's idea. And found
> it easier too -- that is hardly surprising.
> But I don't see how actual easyness follow.
> IMO if you come to production, and any non-trivial project,
> managing the build is an expert area in its own right.
I'd certainly agree with you there. Where I was before, we
managed for three different platforms, using the same codebase
(and the same makefile for each component), but it did take some
expert knowledge to create the build system.
> Then going back to subject -- production and learnnig do not
> mix so well.
Yes. And until actually using them, I always thought that IDE's
had their place in learning process. Maybe it's just my recent
frustrations, but now I'm not so sure.
--
James Kanze
Ian Collins
That sounds like one case where an IDE like NetBeans or Eclipse would
have an advantage. They both can list all the uses of a function and
perform basic refactoring tasks.
--
Ian Collins
Andy Champ
>
> Well, in my old home environment, a makefile was basically:
>
> # Copywrite text...
> buildRoot = whereever
> sources = toto.cc titi.cc tata.cc
> testSources = test1.cc test2.cc test3.cc
> binary = prog
> #include $(buildRoot)/Makefiles/component.mk
>
That better be copyright, not copywrite, or it won't be very effective... :P
Andy
Pete Becker
>
> Search and replace, for starters. You still have to enter the
> regular expression and the replacement text. By the time you've
> gotten the dialog box open and your hands back to the keyboard,
> I've finished the command.
>
You haven't been in the same room as me. <g> cmd-F, type the search
expression, tab, type the replacement text, enter. And if I want to make
the change for all files, its shift-cmd-F. Or I can do the search, then
pick out the particular matches that I want to change.
Granted, that's on a Mac. But VC++ can probably do pretty much the same
thing.
One of the difficulties in adjusting to an IDE is learning the shortcuts.
And, I must confess, those steps are for the text editor that I use. I
haven't found an IDE for the Mac that I like.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
Balog Pal
> On Jan 7, 2:15 am, "Balog Pal" <p...@lib.hu> wrote:
>> "James Kanze" <james.ka...@gmail.com>
>
>> > Makefiles are certainly something additional that you have to
>> > learn. And they shouldn't be necessary for a beginner. I used
>> > to believe that IDE's were a good thing for beginners, because
>> > they allowed deferring the learning of makefiles and such---one
>> > thing at a time. For the last couple of months, however, I've
>> > had to work under an IDE, and I now realize that they represent
>> > even more complexity than make.
>
>> Please write an example.
>
> Well, in my old home environment, a makefile was basically:
>
> # Copywrite text...
> buildRoot = whereever
> sources = toto.cc titi.cc tata.cc
> testSources = test1.cc test2.cc test3.cc
> binary = prog
> #include $(buildRoot)/Makefiles/component.mk
>
> If there were addtional steps, of course, it would be more
> complicated, but even in cases where I had to first build a
> local binary to build one of the sources, 10 or 15 lines would
> suffice. And most of the above would be inserted automatically
> when I opened a new file named GNUmakefile.
Now, that makes sense, but let's put it back in the original context.
A forum suggestion could go as
A) Forget the IDE's project manager, instead open http://myhome/mybuild
there I list the versions on make to install and rules file and description
where to paste your source list -- then just issue make from cmmand line and
have good life.
B) Forget the IDE and use command line with make.
The usual suggestion goes as the B) version, however out of the box make
will not have that magic rules file. And creating it in my guess is about
as easy as implement boost/type_traits.
OTOH, let's see ahead. The beginner installs that rule file and pastes the
source filenames where due, and is happy. But how is that ahead to the
alternative, where he pastes the same list in the "add files" dialog, and
press F7 or clicks on the toolbar or whatever to build?
I really miss the fundamental difference except for the "not invented here"
factor. (no pun intended)
> Of course, $(buildRoot)/Makefile/component.mk is pretty
> complicated, but a beginner, working in my environment, doesn't
> have to deal with it.
Just like with the IDE case. Then when he wants to change the stuff to
build a GUI application instead of a console one, or a dll, he reads the
dox for your rules to define some magic symbol -- or if there is a direct
compiler option line, the compiler dox. While in the IDE he starts wit
selecting a different project in the wizard -- or opens the settings and set
the switches on UI, or on the direct line...
Is there a fundamental difference? If so, favor to which way?
>> And do you mean that the excess complexity you are discovering
>> is something that is genuinely present in beginner's projects,
>> or it is tied to the project you (as a seasoned expert) were
>> summoned?
>
> To be honest, it's hard to say. I'll admit some frustration,
> because I am dealing with a fairly complex environment, in which
> many of the sources are either built automatically or are
> modified by other programs, with several DLL's, etc.
Sure. That is the very situation, where we want fine control. Where
make -- and tools that allow you closer to the metal are too likely needed.
Or having familiarity, are picked up, even if the other systems also may
cover the case.
And you have a ton of existing stuff, that already builds somehow, also
possibly source control system with its own quirks, etc. Not the other
way around -- that you start with nothing, but components that are
compatible with the IDE, and add more sources as you go -- bending to the
preferred way of the chosen system.
> But I was
> somewhat surprized at how awkward the GUI interface was, even
> for simple things that might actually be part of a beginner's
> project.
awkward is subjective. I mostly used MSVC versions 2, 4, 5, 6, (and 1, 1,52
for 16 bit), the interfaces IIRC were different for most versions, and in
the usable category -- it is painfully easy to forget selevting "all
versions" and issue a change to jsut the active (Debug) and looking back the
special options is nearly impossible.
OTOH the settings are in a text file, that you can as easily diff in version
control, and for special tasks you can edit that... what is hardly different
to dealing with a makefile with an external rules include.
With the VS2008 the interface is changed again, I made just a few projects,
I woudn't say it was any awkward for (what I think is) normal use. If it
chokes on defining a custiom translator, well, life's a bitch.
>> Then going back to subject -- production and learnnig do not
>> mix so well.
>
> Yes. And until actually using them, I always thought that IDE's
> had their place in learning process. Maybe it's just my recent
> frustrations, but now I'm not so sure.
Guess frustration comes from (among other things) that you know what you
want to do, and not how to do it. And must deliver in time too.
Learning goes another path, you're shown how-do's and what the result. Then
eventually you figure out to use the learned working ways to selct for a
particular task.
Actually people experienced in a certain way are in danger here -- and tend
to skip a vital learning-from-start phase on a new installation, instead try
to force some light mapping of what they did before. Where the new
thing may have it, or even better, just needs a different approach. Hard
to fill a cup that is already full... ,-)
Balog Pal
> That's what I generally used to think: you wouldn't really want
> an IDE in a professional environment
All good pragmatic methodology I read had a chapter "Sharp tools".
>, but for learning, they
> would permit you to abord one thing at a time.
That sounds like massive prejudice.
> Now that I've
> actually used one a bit, I'm less sure. (But maybe that's just
> because of my frustration.)
James, please, from what you write it is evident you didn't *use* one in the
professional sense. So your conclusions are premature.
Looking back, i started quite every new thing with RTFM. Really. Before
(maybe instead :) the install. Not aiming to memorize all the details,
but make a point to read through all the all the controls and use cases.
So later I have some figure if something is or is not there.
I see many other people just jump into it, and try to pick up as it goes --
the result is ceratinly they never discover 95% of the functionality, and
loudly express what sucks -- or just stay improductive and frustrated about
it.
My experience is that doing the tutorials absolutely worth the time
investment. :)
And the usual wisdom -- never be shy to ask those who are ahead. Especially
if they gladly offer the help.
The software is full of genuine sources of frustration, why increase it
voluntarily?
> Without such support, I guess I'd have to agree. (I was very
> frustrated with the restrictions in the IDE when I wrote my
> first posting.) On the other hand, can you really learn C++
> effectively without some initial support?
I did it, so it is possible -- but no way would I suggest anyone that way :)
when by now support is easily available. Some support at least.
Certainly the ideal way is (IMO) to get into a team with a good expert
mentor. (hardly easy in practice, while getting into a WTF environment has
wide chances...)
>> What I wanted to say, they will be sitting there installed,
>> almost sure, but most time just collecting dust. (Hm, I
>> exclude the cases when they are invoked by specialized
>> scripts/programs made to cover some use case...)
>
> I don't find that to be the case, at least not in professional
> environments. Everywhere I've been before, most people worked
> most of the time from the shells.
And that "everywhere: is mostly unix-or-like? ;-)
But sure, of course people use shells, what would they. explorer.exe in win
is a shell too. Certainly a single shell hardly good for all tasks, so we
use more than one. I use FAR manager for traditional reasons, to company to
explorer, most people I saw use Total Commander. but there is no
shortage...
And they are there to work -- though during development I'm sure spend most
of the time in an editor.
> Where I am now (the first
> 100% Windows environment for me), it's not so much the case, but
> the shells are used for any number of scripts and other things.
> And very often, when there's something more complicated that
> needs to be done, I can get it done faster from the shell than
> the Windows experts can do from the GUI.
Of course. Different tasks ask for different tools. And a professional
development env surely use many stock ustils, and even more homegrown ones
that cover for the usual cases.
Having graphics and mouse is an ability -- not a handcuff that would deny
other ways. TMK "usable without mouse" is still an aim un UI design for
graphic desktops, wherever makes sense. (And is pretty frustrating indeed to
see that some applications did not bother to straighten the tab order or use
duplicate or missing accelerators. What doesn't need a line of code....)
What I was trying to say above in the () is that IME the atomic tools are
not executed directly from the command line all that often. But from more
specific tools.
Eg. I can't recall when I launched pkzip directly the last time. But have a
plenty of "scripts" that use it.
>> Do you really think that interface dexterity shall count that
>> much in that kind of design? So if the most common use case
>> is "withdraw $50" it is put on a button only for "idiots",
>> while the experts are damned to type in the whole command and
>> the actual amount? Because they can, reliably? And may want
>> to fetch $3.1415 more often then others?
>
> That isn't the issue. In practice, you really only want to do
> one thing at an ATM. Developing software requires a large
> number of different activities, from designing UML, writing HTML
> documentation, writing code, compiling, setting up code reviews,
> etc. Some of this is supported by the usual tools, but in
> practice, you're almost always doing something a little bit
> more than what they offer.
That is the whole point.
Deep inside the machine there sit the atomic elements, maybe that non-quoted
image that is invoked like
atm -withdraw -v:$ -amount:50
but on the face there exist a single button that can be punched to that
effect.
Like on my last unix project, how many times I issued make on command line?
Quite never. There was a script buildPackage, that asked what platform, what
target kind, label, etc, then invoked ant here, make there. How many times
I invoked buildPackage? Again quite never, I fixed it to accept answers from
command line, then has a script 'bp' that issued the params that were fixed.
And for partial builds there was 'm' that issued make in the directory with
some magic arguments and capture the output and filters it and presents me
the errors/warnings at the end.
Also there was a dozen aliases that navigated to the most used
directories -- and you could make the observation of "using the shell all
day" though it was most time sitting there and the history like
cdm
m
m
m
cdvox
bp
cdm
... repeat ... ;-)
In my vocubulary that part in not the "work".
(I also shall mention my sad observation that some other people got stuck at
the buildPackage level and typing the answer to the 5-6 question every time;
one answer being like XXXX-64-java-linux that could be pasted from the list
of possibilities written to the terminal. And hope the problems stay within
terminal's history range, as redirection does not play with
interactivity...)
Back to the point, IME the *bulk* of the commands issued on command line.
And so could be invoked from something else -- hotkey, menu, button, etc.
>> But I do expect to
>> - have instant and easy access to most relevant information (like in code
>> definition windows, call/caller graphs, man/msdn pages)
>> - navigation around all the interesting locations (like mentioned before
>> +
>> error spot from build)
>> - sensible management of windows and panes that present the stuff I am
>> working with
>> - easy access to most/all tools I need along the road (editors for
>> different
>> kinds of sources, the build, debuggers, source control)
>
> All of which is present with a good editor/shell combination
> under Unix (or Windows, with bash and gvim). I suppose that you
> could call it partially integrated, but if you invoke make from
> vim, it will position you on the error.
Will it? Interesting, my people did use vim and didn't have that feature.
Guess it is not out of the box, or is picky to something -- or they were
just ignorant. While those using IDE not really had the option to miss the
auto-navigation to errors.
OTOH, if you have your environment with all those featires, in my vocabulary
it is an IDE. And surely not "just an editor" when it actually invokes
build on one end, and processes the build's output on the other.
And we hopefully adree that professional development needs that kind of
integration, and it brings better productivity compared to really separate
editors that have no feed to or from, and have no clue about usual cases
like the compile-fix-typos cycle and the others.
> Plus a lot of other
> things. (I find that when restructuring code, I make a lot of
> use of :argdo g/.../... for example.)
And why typing :argdo more sexy than ctrl-H (or alt-E R or hitting the
Replace button on the toolbar?)
Actually you can do it even almost that way, as the toolbar box for the
search text can invoke macros, and it is no problem to write a macro that
separates the arguments then invoke replace with the all-open-files
option=yes. Customization only goes 99.5%, so possibly it should look look
like
>argdo_g(from/to)
but I'd rather keep a 1-key and try to open the regular dialog with the
option set to all-files, and type in the text. I use that operation way
to rarely to bother about the extra click.
> dislike about Visual Studios is that it doesn't support your
> third point; it presents a lot of not particularly relevant
> information, but still makes it very hard to find the relevant
> information.
My experience is different. For very long (in up to 6.0) I mostly used just
the find-in-files (the builtin grep on steroids).
In my last project, that was some 3MLOC monster with every possible and
impossible WTF put together in 15 years, starting with
"no-documentation-figure out from code", I pushed it under VS2008, and
switched to the code-browser facilities. The difference is drastic. (
Like you need all invocations of Foo::Process(void) -- hopeless case for
grep )
Still not perfect, and it is really annoying that it does not present some
info it surely knows (i.e. calls of auto-generated funcitions), or that I
can't query the browser database sql-like (or just export it to text to
solve some cheesy questions myself...)
But it is tremendous help, and way superior to anything dumb and "just text"
based.
Also it actually *can* search in the files that belong to the project, as
the IDE knows the fileset -- while non-integrated tools are limited to crude
approach, like directories.
IUC your argdo g/... works on files opened in the editor -- can you do it
for the project's all files? That is just another option seletcion....
>> And I certainly welcome additional intelligent behavior, like
>> auto-checkout files I type into, collect TODOs, pending
>> checkins, etc.
>
> We're using subversion, so there is no check-out. I'm not sure
> I like this aspect, however. I don't like the fact that I can
> accidentally modify a file I happen to be looking at. (Of
> course, in vim, I'll open it read only, so there's no problem.
I'm lazy to start VS to check, but for-readonly is traditionally part of the
open interface of programs.
But that is not the mainstream approach -- keep the files with read-only
flag in the filesystem. Then it will not edit, or you get prompted.
VSS works like that.
We used CVS, and I tried a free plugin that integrated it with VS, (Maybe
Iglo-something?) it worked, though I didn't like it. The source control
interface was made wth VSS in mind, and doesn't fit too well with others,
though you might find it so. As 'editors' can be used non-exclusively, and
provide info for the team. The non-free plugin was quite impressive on
its brag-sheet, I didn't try that one.
> If Visual Studios has this option, I'm not aware of it.) For
> the rest, it's all there from a normal editor and the shell.
If you insist that an editor that reads compiler output like ctags is
'normal'... ;)
To me having a single frame around the whole bunch of editors (like those
for resources) and the debugger is also a gain on productivity.
I'm light on debugger usage, so wouldn't die from separation, but don't see
its virtue. Like DRY in coding. ;-)
>> > and you can't do any advanced editing with a single click.
>
>> What is "advanced editing" mean?
>
> Search and replace, for starters. You still have to enter the
> regular expression and the replacement text. By the time you've
> gotten the dialog box open and your hands back to the keyboard,
> I've finished the command.
Huh? What hands back? The box can open on any kind of trigger -- including
keyboard. And starts with the search part prepopulated with text under the
cursor or selected, that is quite usual. And history in the box, that is
the other usual case.
If something bugs me it is redundant typing. May be some fundamental viring
difference in brains -- as in the "fill-the-query" case mentioned above.
But for search I rarely use the full dialog, just the "what" box on the
toolbar (activated by ctrl-D instead of ctrl-F) or even more frequently
ctrl-F3 F3/shift-F3 that captures the selected text or the current word if
no selection. (And selection certainly does not need the mouse either, just
shift...)
> When editing (entering text), anything which requires using the
> mouse is a minus, since it requires taking your hands away from
> the base position on the keyboard.
Yep. Now do you really think that all the zillion users of VS, or
mouse-capable systems in general are all unaware of that? instead of
using the mouse when that fits, and the keyboard otherwise?
> (When just browsing, of
> course, other rules hold, and I do tend to use the mouse for
> most browsing.)
And the wheel is the greatest invention since sliced bread too -- I feel
like maimed ocasionally sitting on a wheel-less mouse.
>> Refactoring actions? I never used such an editor yet, but
>> would welcome -- it certainly sounds like an IDE
>> functionality and hardly doable by atomic tools.
>
>> Reformatting code? That is basic in most anything.
>> Search/replace in all project files? I can do it in IDE, not
>> sure how it is doable for a general case with make-build...
>> Especially ad-hoc and without pain.
>
> One frequent operation for me is grepping for every place where
> some function is used.
You can do that? How? I couln't figure a method. (unless you mean to find
every place plus all the zillion other places that is not that function call
just a textual match.)
Though the operation is indeed one really important, and I can do it with
the browse info. (that in vs2008 painfully misses to point the place where
the function is not invoked but its address stored. :-( )
> Then invoking the editor on just those
> files, running through the first modification, memorizing the
> keystrokes in a macro as I do, then undoing it, and invoking it
> on all of the files I'm editing (and only on those files---with
> a bit of care in my original search string, I can only modify
> specific uses of my function).
Well, macros are really count as normal function of editor. With VS you
certainly can record at will or write, all the MS palette speaks VBA for
whatever. So beyond editing you can do practically anything.
>> Please give some example what case were you thinking here.
>
> As above. Or modifying all of the project files (in about
> twenty different projects in the solution) in a similar way (but
> the modification depends partially on the directory in which the
> project file is found).
Well, if the stock "search/replace" in whole project is no player, then
indeed you either go half-manual or write the if-logic into the macro.
but if you can do it in vim I don't see why you couldn't do it just the
same/similar way -- the 'argdo' equivalent is surely more verbose, I'd guess
some foreach in application.documents, but if it is usual task, you write it
once and can call argdo for the rest of life.
Like written on top (no offense) this story reads to me not as whet an IDE
or VS can do, just you know how to do it in X and not (yet) in Y.
Just for completeness' sake, there's no problem to bring your shell to
windows and execute the tasks in your familiar way if the whole run is not
big. After all when the text-editing is done, no one can tell how it got
in the state. (I recall myself using "ms-word for dos" for semi-automated
text reshaping waaaay long, havin a bunch of other editors that also have
macros. The one thing that counts is to do the job with least sweat.
who cares how a one-shot macro or script looked like? ;-)))
Rui Maciel
> Should we also drop using matches and gas lighters and restrict to
> "natural" methods of creating fire?
>
> Makefile is certainnly easy to whoever already learned to use it, and does
> so for a decade. For novices it just sucks. Especially compared to an IDE
> with a project manager -- there all the supposed complexity is using "add
> new" menu adding a new item and "add existing" otherwise...
...which means that the newbie ends up not having a clue about what he is in
fact doing or even what he is supposed to do. As a consequence, the newbie is
in effect barred from learning how to program in a certain language, as he is
actually forced to learn how to use a very specific tool (the IDE). That means
that, in his own eyes, he builds up this nonsensical idea that this particular
IDE is somehow the language.
> For the other part -- if the aim of learning C++ is not an abstract one,
> but to create some useful stuff, starting with an app framework that fits
> that aim may be a good idea too.
Starting off with a project is a good suggestion. Nonetheless, suggesting that
the newbie starts off with a automatically generated pile of code, full of cruft
such as platform-specific components and a ton of irrelevant objects floating
around, what in the surface appears to be helping you is in fact damaging your
ability to build up the faintest understanding of what you are doing, what you
should be doing and what is really happening around you. Moreover, it builds up
the false notion of what the programming language is.
You don't get any of that by using a compiler and a text editor. If a newbie
starts off without being burdened by all that needless crap that an IDE imposes
on a user, he will be able to clearly understand what he is doing and what he is
in fact getting from the code he is writing. That is, by far, a richer learning
environment and a far faster way to competency.
> It has a fair amount of dangers, but
> so does going barefoot for too long.
What do you mean by "going barefoot for too long" ?
Rui Maciel
Rui Maciel
> "James Kanze" <james...@gmail.com>
>
>> Makefiles are certainly something additional that you have to
>> learn. And they shouldn't be necessary for a beginner. I used
>> to believe that IDE's were a good thing for beginners, because
>> they allowed deferring the learning of makefiles and such---one
>> thing at a time. For the last couple of months, however, I've
>> had to work under an IDE, and I now realize that they represent
>> even more complexity than make.
>
> Please write an example.
How do you start a small command-line app project in your IDE of choice?
Without an IDE you just open a text editor and write:
<code>
int main(void){ return 0; }
</code>
Done. You don't need to click through a set of wizards, you don't need to clean
up any cruft that was automatically generated. You just code away.
If you wish to automate your build process (which you probably want) then, if
you wish to rely on plain old make and use a custom makefile then you only need
to open a text editor and save the following in a file named Makefile:
<code>
all: myapp
myapp:
g++ main.c++ -o main
</code>
Done. And as you wish to have a finer control on your project, the IDE will
become more and more of a bloated nuisance than a solution. You will be
gradually pushed to hunt obscure options in a vast sea of bloated dialogs, all
of which force you to only use the set the options that the people behind the
IDE thought were reasonable, which could easily clash with what you intend to
do.
> And do you mean that the excess complexity you are discovering is
> something that is genuinely present in beginner's projects, or it is tied
> to the project you (as a seasoned expert) were summoned?
I believe it is easy to understand that all the options that the IDE's
interfaces push into the newbie's eyes are a terribly (and needlessly) big
source of confusion. Emphasis on the "needless".
>> So until someone comes out with
>> something better, we're stuck with make as the simplest
>> solution: the easiest to learn and use.
>
> This sounds like your bunch of make experts could manage the build of a
> project that was not fit an IDE's idea. And found it easier too -- that is
> hardly surprising.
>
> But I don't see how actual easyness follow.
With an IDE you are firmly wedged into what the IDE imposes on you and what the
project templates support. On the other hand, if you rely on a text editor to
write your code then you are perfectly free from those hindrances. You don't
have any weird workflow forced on you and if you need to perform a task then you
are free to use whatever 3rd party app you wish to adopt and which lets you
easily accomplish your task in your own terms. More than that, if meanwhile you
opt to replace some tool then you are also free to do so. You don't have
anything bolted down and, in fact, you are free to fully use your system to your
own advantage.
> IMO if you come to production, and any non-trivial project, managing the
> build is an expert area in its own right.
If your experience is limited to what is offered by an IDE then it is only
natural that you perceive "managing the build" as being an "expert area in its
own right".
Rui Maciel
Balog Pal
> How do you start a small command-line app project in your IDE of choice?
New project -> Console app -> 'A hello word application' -> Finish.
Then press F5 and it builds and runs.
I do it quite often.
> Without an IDE you just open a text editor and write:
>
> <code>
> int main(void){ return 0; }
> </code>
>
> Done.
Extreme amoun of redundant typing if you ask me. Ok, I forgot from above to
state the name, but it is common in both versions.
>You don't need to click through a set of wizards, you don't need to clean
> up any cruft that was automatically generated. You just code away.
There are certainly options for 'empty project' fro those who like type
main. And you can make your own wizard if have a pattern in usual work.
The stock selection in VS IME covers about anything usually done from
scratch.
> If you wish to automate your build process (which you probably want) then,
> if
> you wish to rely on plain old make and use a custom makefile then you only
> need
> to open a text editor and save the following in a file named Makefile:
>
> <code>
> all: myapp
>
> myapp:
> g++ main.c++ -o main
> </code>
>
> Done.
Is that supposed to win over 0 (as in zero) typing?
Please someone take a little time and finally explain me the vitue of that.
I understand the case where the project is a complex build or has some
special way of tuning, but these cases just beat me. Completely.
(Certainly without IDE a caring person would IMO probably have saved a first
such empty project, and merely unzip it on use, but whatever...)
> And as you wish to have a finer control on your project, the IDE will
> become more and more of a bloated nuisance than a solution.
Worked for me for the last ~20 years. And on my list of nuicances it is
hardly a contender. (btw all versions before the last had option to export
makefile, so there is not even a lock-in.
If something is a nuicance, solve it. Addressing the specific way. What is
the point of the preemptive strike, to tune the build system for what
believed for version 4.0, when you may never go beyond the first? And pay
up the price up front?
> You will be
> gradually pushed to hunt obscure options in a vast sea of bloated dialogs,
> all
> of which force you to only use the set the options that the people behind
> the
> IDE thought were reasonable, which could easily clash with what you intend
> to
> do.
You make this up, do you? ;-) If you know the option directly just insert
it in the special field, and it will be used -- and if has representation in
some dialog will appear there by itself.
>> And do you mean that the excess complexity you are discovering is
>> something that is genuinely present in beginner's projects, or it is tied
>> to the project you (as a seasoned expert) were summoned?
>
> I believe it is easy to understand that all the options that the IDE's
> interfaces push into the newbie's eyes are a terribly (and needlessly) big
> source of confusion. Emphasis on the "needless".
Guess those are the kind not taking the Tutorial tour.
I recall doing over the Scribble sample set that explains creating a MFC
application (with fairly fophisticated features too), along with showing
most elements of the IDE used.
All in a very thoughtful, step-by-step way.
Sun's IDE also came with that Freeway sample and tutorial on how to use the
debugger to fix a multi-threaded application, fow to profile, etc
I also encountered very fine books from Wrox tuned for all kind of public.
If a beginner just sits down and expects the IDE magically fill his head
with knowledge, no wonder he gets confused -- I mean he started pretty deep
being that way.
>>> So until someone comes out with
>>> something better, we're stuck with make as the simplest
>>> solution: the easiest to learn and use.
>>
>> This sounds like your bunch of make experts could manage the build of a
>> project that was not fit an IDE's idea. And found it easier too -- that
>> is
>> hardly surprising.
>>
>> But I don't see how actual easyness follow.
>
> With an IDE you are firmly wedged into what the IDE imposes on you and
> what the
> project templates support.
What means if your project fits a template -- that it too often does, you're
ahead. Whjen it doesn't you are on the same square as in the alternative.
The empty project is always there. And you can download additional
templates if the case is at least so common -- or capture yours if done
once.
> On the other hand, if you rely on a text editor to
> write your code then you are perfectly free from those hindrances.
This resembles the argument on how much burden having a million dollar is
compared to being poor. ( Which btw have some ground, but i believe I could
deal with the expected problems ;)
>You don't
> have any weird workflow forced on you and if you need to perform a task
> then you
> are free to use whatever 3rd party app you wish to adopt and which lets
> you
> easily accomplish your task in your own terms.
weird workflow ===> prejudice.
While if the workflow of certain IDE does not match yours, simply chose one
which does, or forget it. Chosing the *fit* tool is part of the
development work.
> More than that, if meanwhile you
> opt to replace some tool then you are also free to do so. You don't have
> anything bolted down and, in fact, you are free to fully use your system
> to your
> own advantage.
And you can write anything in assembly, why we bother with all the other
languages I wonder. ;-) Why accept restraints instead of having the
absolute freedom and power? O,O
>> IMO if you come to production, and any non-trivial project, managing the
>> build is an expert area in its own right.
>
> If your experience is limited to what is offered by an IDE then it is only
> natural that you perceive "managing the build" as being an "expert area in
> its
> own right".
I have a huge deal of experience on quite many platform and project sizes --
that statement applies to cases of big and non-trivial projects.
Also spet some time debugging the build -- it is about as easy as find the
real source of a random crash in a big C application (caused by a hidden
race condition or dangling pointer or overrun). Resembles mur black
magic than science ;-)
red floyd
> "Rui Maciel" <rui.mac...@gmail.com>
>
> > How do you start a small command-line app project in your IDE of choice?
>
> New project -> Console app -> 'A hello word application' -> Finish.
> Then press F5 and it builds and runs.
>
> I do it quite often.
And how is that supposed to help someone learn C++?
[redacted]
>
> Is that supposed to win over 0 (as in zero) typing?
>
> Please someone take a little time and finally explain me the vitue of that.
>
Again, the idea is to learn the language, not how to use the IDE.
Rui Maciel
> "Rui Maciel" <rui.m...@gmail.com>
>
>> How do you start a small command-line app project in your IDE of choice?
>
> New project -> Console app -> 'A hello word application' -> Finish.
> Then press F5 and it builds and runs.
>
>
> I do it quite often.
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. It's pretty much settled what
is the best tool here.
>> Without an IDE you just open a text editor and write:
>>
>> <code>
>> int main(void){ return 0; }
>> </code>
>>
>> Done.
>
> Extreme amoun of redundant typing if you ask me.
What? Typing in a dozen letters is "extreme amount of redundant typing"? How
many LoC do your projects usually carry?
>>You don't need to click through a set of wizards, you don't need to clean
>> up any cruft that was automatically generated. You just code away.
>
> There are certainly options for 'empty project' fro those who like type
> main. And you can make your own wizard if have a pattern in usual work.
> The stock selection in VS IME covers about anything usually done from
> scratch.
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?
>> If you wish to automate your build process (which you probably want)
>> then, if
>> you wish to rely on plain old make and use a custom makefile then you
>> only need
>> to open a text editor and save the following in a file named Makefile:
>>
>> <code>
>> all: myapp
>>
>> myapp:
>> g++ main.c++ -o main
>> </code>
>>
>> Done.
>
> Is that supposed to win over 0 (as in zero) typing?
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.
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.
> Please someone take a little time and finally explain me the vitue of
> that.
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?
> I understand the case where the project is a complex build or has some
> special way of tuning, but these cases just beat me. Completely.
>
> (Certainly without IDE a caring person would IMO probably have saved a
> first such empty project, and merely unzip it on use, but whatever...)
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.
>> And as you wish to have a finer control on your project, the IDE will
>> become more and more of a bloated nuisance than a solution.
>
> Worked for me for the last ~20 years. And on my list of nuicances it is
> hardly a contender. (btw all versions before the last had option to
> export makefile, so there is not even a lock-in.
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.
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.
> If something is a nuicance, solve it. Addressing the specific way. What
> is the point of the preemptive strike, to tune the build system for what
> believed for version 4.0, when you may never go beyond the first? And
> pay up the price up front?
What are you talking about?
>> You will be
>> gradually pushed to hunt obscure options in a vast sea of bloated
>> dialogs, all
>> of which force you to only use the set the options that the people behind
>> the
>> IDE thought were reasonable, which could easily clash with what you
>> intend to
>> do.
>
> You make this up, do you? ;-) If you know the option directly just
> insert it in the special field, and it will be used -- and if has
> representation in some dialog will appear there by itself.
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.
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.
>>> And do you mean that the excess complexity you are discovering is
>>> something that is genuinely present in beginner's projects, or it is
>>> tied to the project you (as a seasoned expert) were summoned?
>>
>> I believe it is easy to understand that all the options that the IDE's
>> interfaces push into the newbie's eyes are a terribly (and needlessly)
>> big source of confusion. Emphasis on the "needless".
>
> Guess those are the kind not taking the Tutorial tour.
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.
> I recall doing over the Scribble sample set that explains creating a MFC
> application (with fairly fophisticated features too), along with showing
> most elements of the IDE used.
>
> All in a very thoughtful, step-by-step way.
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.
> Sun's IDE also came with that Freeway sample and tutorial on how to use
> the debugger to fix a multi-threaded application, fow to profile, etc
That's irrelevant, as debugging isn't an exclusive domain of the IDE.
> If a beginner just sits down and expects the IDE magically fill his head
> with knowledge, no wonder he gets confused -- I mean he started pretty
> deep being that way.
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.
>> With an IDE you are firmly wedged into what the IDE imposes on you and
>> what the
>> project templates support.
>
> What means if your project fits a template -- that it too often does,
> you're ahead. Whjen it doesn't you are on the same square as in the
> alternative.
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.
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.
> The empty project is always there. And you can download additional
> templates if the case is at least so common -- or capture yours if done
> once.
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.
> This resembles the argument on how much burden having a million dollar is
> compared to being poor. ( Which btw have some ground, but i believe I
> could deal with the expected problems ;)
No, it's the burden of being forced to do far more to accomplish less.
>>You don't
>> have any weird workflow forced on you and if you need to perform a task
>> then you
>> are free to use whatever 3rd party app you wish to adopt and which lets
>> you
>> easily accomplish your task in your own terms.
>
> weird workflow ===> prejudice.
>
> While if the workflow of certain IDE does not match yours, simply chose
> one
> which does, or forget it. Chosing the *fit* tool is part of the
> development work.
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.
That, compared to just picking up pretty much any text editor and just hack
away.
And using an IDE is supposed to do what? Save you time? It doesn't look like
it.
>> More than that, if meanwhile you
>> opt to replace some tool then you are also free to do so. You don't have
>> anything bolted down and, in fact, you are free to fully use your system
>> to your
>> own advantage.
>
> And you can write anything in assembly, why we bother with all the other
> languages I wonder. ;-) Why accept restraints instead of having the
> absolute freedom and power? O,O
That doesn't make any sense.
>>> IMO if you come to production, and any non-trivial project, managing the
>>> build is an expert area in its own right.
>>
>> If your experience is limited to what is offered by an IDE then it is
>> only natural that you perceive "managing the build" as being an "expert
>> area in its own right".
>
> I have a huge deal of experience on quite many platform and project sizes
> -- that statement applies to cases of big and non-trivial projects.
>
> Also spet some time debugging the build -- it is about as easy as find the
> real source of a random crash in a big C application (caused by a hidden
> race condition or dangling pointer or overrun). Resembles mur black
> magic than science ;-)
And why is this relevant?
Rui Maciel
Balog Pal
> > How do you start a small command-line app project in your IDE of choice?
>
> 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
>>> How do you start a small command-line app project in your IDE of choice?
>>
>> New project -> Console app -> 'A hello word application' -> Finish.
>> Then press F5 and it builds and runs.
>>
>
> 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.
>>> Without an IDE you just open a text editor and write:
>>>
>>> <code>
>>> int main(void){ return 0; }
>>> </code>
>>>
>>> Done.
>>
>> Extreme amoun of redundant typing if you ask me.
>
> 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.
>>>You don't need to click through a set of wizards, you don't need to clean
>>> up any cruft that was automatically generated. You just code away.
>>
>> There are certainly options for 'empty project' fro those who like type
>> main. And you can make your own wizard if have a pattern in usual work.
>> The stock selection in VS IME covers about anything usually done from
>> scratch.
>
> 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
>>> If you wish to automate your build process (which you probably want)
>>> then, if
>>> you wish to rely on plain old make and use a custom makefile then you
>>> only need
>>> to open a text editor and save the following in a file named Makefile:
>>>
>>> <code>
>>> all: myapp
>>>
>>> myapp:
>>> g++ main.c++ -o main
>>> </code>
>>>
>>> Done.
>>
>> Is that supposed to win over 0 (as in zero) typing?
>
> 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.
>> Please someone take a little time and finally explain me the vitue of
>> that.
>
> 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. :)
>>> And as you wish to have a finer control on your project, the IDE will
>>> become more and more of a bloated nuisance than a solution.
>>
>> Worked for me for the last ~20 years. And on my list of nuicances it is
>> hardly a contender. (btw all versions before the last had option to
>> export makefile, so there is not even a lock-in.
>
> 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?
>> If something is a nuicance, solve it. Addressing the specific way. What
>> is the point of the preemptive strike, to tune the build system for what
>> believed for version 4.0, when you may never go beyond the first? And
>> pay up the price up front?
>
> 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 will be
>>> gradually pushed to hunt obscure options in a vast sea of bloated
>>> dialogs, all
>>> of which force you to only use the set the options that the people
>>> behind
>>> the
>>> IDE thought were reasonable, which could easily clash with what you
>>> intend to
>>> do.
>>
>> You make this up, do you? ;-) If you know the option directly just
>> insert it in the special field, and it will be used -- and if has
>> representation in some dialog will appear there by itself.
>
> 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.
>>>> And do you mean that the excess complexity you are discovering is
>>>> something that is genuinely present in beginner's projects, or it is
>>>> tied to the project you (as a seasoned expert) were summoned?
>>>
>>> I believe it is easy to understand that all the options that the IDE's
>>> interfaces push into the newbie's eyes are a terribly (and needlessly)
>>> big source of confusion. Emphasis on the "needless".
>>
>> Guess those are the kind not taking the Tutorial tour.
>
> 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. ;-)
>> I recall doing over the Scribble sample set that explains creating a MFC
>> application (with fairly fophisticated features too), along with showing
>> most elements of the IDE used.
>>
>> All in a very thoughtful, step-by-step way.
>
> 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. ;-)
>> Sun's IDE also came with that Freeway sample and tutorial on how to use
>> the debugger to fix a multi-threaded application, fow to profile, etc
>
> 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.
>> If a beginner just sits down and expects the IDE magically fill his head
>> with knowledge, no wonder he gets confused -- I mean he started pretty
>> deep being that way.
>
> 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.
>>> With an IDE you are firmly wedged into what the IDE imposes on you and
>>> what the
>>> project templates support.
>>
>> What means if your project fits a template -- that it too often does,
>> you're ahead. Whjen it doesn't you are on the same square as in the
>> alternative.
>
> 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. ;-)
>> The empty project is always there. And you can download additional
>> templates if the case is at least so common -- or capture yours if done
>> once.
>
> 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?
>> This resembles the argument on how much burden having a million dollar is
>> compared to being poor. ( Which btw have some ground, but i believe I
>> could deal with the expected problems ;)
>
> No, it's the burden of being forced to do far more to accomplish less.
more false claims.
>>>You don't
>>> have any weird workflow forced on you and if you need to perform a task
>>> then you
>>> are free to use whatever 3rd party app you wish to adopt and which lets
>>> you
>>> easily accomplish your task in your own terms.
>>
>> weird workflow ===> prejudice.
>>
>> While if the workflow of certain IDE does not match yours, simply chose
>> one
>> which does, or forget it. Chosing the *fit* tool is part of the
>> development work.
>
> 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
>>> More than that, if meanwhile you
>>> opt to replace some tool then you are also free to do so. You don't
>>> have
>>> anything bolted down and, in fact, you are free to fully use your system
>>> to your
>>> own advantage.
>>
>> And you can write anything in assembly, why we bother with all the other
>> languages I wonder. ;-) Why accept restraints instead of having the
>> absolute freedom and power? O,O
>
> That doesn't make any sense.
Too bad, it is easier to refuse the clear parallel than admit a poor claim
and retract it.
>>>> IMO if you come to production, and any non-trivial project, managing
>>>> the
>>>> build is an expert area in its own right.
>>>
>>> If your experience is limited to what is offered by an IDE then it is
>>> only natural that you perceive "managing the build" as being an "expert
>>> area in its own right".
>>
>> I have a huge deal of experience on quite many platform and project sizes
>> -- that statement applies to cases of big and non-trivial projects.
>>
>> Also spet some time debugging the build -- it is about as easy as find
>> the
>> real source of a random crash in a big C application (caused by a hidden
>> race condition or dangling pointer or overrun). Resembles mur black
>> magic than science ;-)
>
> 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
> Balog Pal wrote:
>
>> "Rui Maciel" <rui.m...@gmail.com>
>>
>>> How do you start a small command-line app project in your IDE of
>>> choice?
>>
>> New project -> Console app -> 'A hello word application' -> Finish.
>> Then press F5 and it builds and runs.
>>
>>
>> I do it quite often.
>
> 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
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
>
> >> How do you start a small command-line app project in your IDE of choice?
>
> > New project -> Console app -> 'A hello word application' -> Finish.
> > Then press F5 and it builds and runs.
>
> > I do it quite often.
>
> 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.
> >> Without an IDE you just open a text editor and write:
>
> >> <code>
> >> int main(void){ return 0; }
> >> </code>
>
> >> Done.
>
> > Extreme amoun of redundant typing if you ask me.
>
> What? Typing in a dozen letters is "extreme amount of redundant typing"? How
> many LoC do your projects usually carry?
You guys just argue? :D It does not link as C++ anyway, so what was
the point of typing it?
> >>You don't need to click through a set of wizards, you don't need to clean
> >> up any cruft that was automatically generated. You just code away.
>
> > There are certainly options for 'empty project' fro those who like type
> > main. And you can make your own wizard if have a pattern in usual work.
> > The stock selection in VS IME covers about anything usually done from
> > scratch.
>
> 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.
> >> If you wish to automate your build process (which you probably want)
> >> then, if
> >> you wish to rely on plain old make and use a custom makefile then you
> >> only need
> >> to open a text editor and save the following in a file named Makefile:
>
> >> <code>
> >> all: myapp
>
> >> myapp:
> >> g++ main.c++ -o main
> >> </code>
>
> >> Done.
>
> > Is that supposed to win over 0 (as in zero) typing?
>
> 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.
> > Please someone take a little time and finally explain me the vitue of
> > that.
>
> 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.
> > I understand the case where the project is a complex build or has some
> > special way of tuning, but these cases just beat me. Completely.
>
> > (Certainly without IDE a caring person would IMO probably have saved a
> > first such empty project, and merely unzip it on use, but whatever...)
>
> 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.
> >> And as you wish to have a finer control on your project, the IDE will
> >> become more and more of a bloated nuisance than a solution.
>
> > Worked for me for the last ~20 years. And on my list of nuicances it is
> > hardly a contender. (btw all versions before the last had option to
> > export makefile, so there is not even a lock-in.
>
> 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.
> > If something is a nuicance, solve it. Addressing the specific way. What
> > is the point of the preemptive strike, to tune the build system for what
> > believed for version 4.0, when you may never go beyond the first? And
> > pay up the price up front?
>
> What are you talking about?
>
> >> You will be
> >> gradually pushed to hunt obscure options in a vast sea of bloated
> >> dialogs, all
> >> of which force you to only use the set the options that the people behind
> >> the
> >> IDE thought were reasonable, which could easily clash with what you
> >> intend to
> >> do.
>
> > You make this up, do you? ;-) If you know the option directly just
> > insert it in the special field, and it will be used -- and if has
> > representation in some dialog will appear there by itself.
>
> 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.
> >>> And do you mean that the excess complexity you are discovering is
> >>> something that is genuinely present in beginner's projects, or it is
> >>> tied to the project you (as a seasoned expert) were summoned?
>
> >> I believe it is easy to understand that all the options that the IDE's
> >> interfaces push into the newbie's eyes are a terribly (and needlessly)
> >> big source of confusion. Emphasis on the "needless".
>
> > Guess those are the kind not taking the Tutorial tour.
>
> 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.
> > I recall doing over the Scribble sample set that explains creating a MFC
> > application (with fairly fophisticated features too), along with showing
> > most elements of the IDE used.
>
> > All in a very thoughtful, step-by-step way.
>
> 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."
> > the debugger to fix a multi-threaded application, fow to profile, etc
>
> 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.
> > If a beginner just sits down and expects the IDE magically fill his head
> > with knowledge, no wonder he gets confused -- I mean he started pretty
> > deep being that way.
>
> 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.
> >> With an IDE you are firmly wedged into what the IDE imposes on you and
> >> what the
> >> project templates support.
>
> > What means if your project fits a template -- that it too often does,
> > you're ahead. Whjen it doesn't you are on the same square as in the
> > alternative.
>
> 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.
> > The empty project is always there. And you can download additional
> > templates if the case is at least so common -- or capture yours if done
> > once.
>
> 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.
> > This resembles the argument on how much burden having a million dollar is
> > compared to being poor. ( Which btw have some ground, but i believe I
> > could deal with the expected problems ;)
>
> 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.
> >>You don't
> >> have any weird workflow forced on you and if you need to perform a task
> >> then you
> >> are free to use whatever 3rd party app you wish to adopt and which lets
> >> you
> >> easily accomplish your task in your own terms.
>
> > weird workflow ===> prejudice.
>
> > While if the workflow of certain IDE does not match yours, simply chose
> > one
> > which does, or forget it. Chosing the *fit* tool is part of the
> > development work.
>
> 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
> "Jorgen Grahn" <grahn...@snipabacken.se>
>
>>> I don't have feedback from students, only see what people that practice
>>> do
>>> around. My experience is pretty sour -- I heard too many claims on how
>>> command line, make, (vim, etc) development is good, and how much and IDE
>>> is
>>> just distracton. The I found their work pretty inefficient, doing
>>> extreme
>>> amount of "fiddling".
>>
>> What kind of fiddling was that? I use Emacs, Make, version control
>> and the Unix shell are my usual tools, so I have a hard time imagining
>> what those inefficiencies were.
>
> 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...
>
>> The Makefile can be an issue if you don't understand that it needs
>> to capture all dependencies (i.e. you have to have autogeneration
>> for them, using something like makedepend), or that you can rely on
>> the default *.cpp -> *.o rules. Once you have seen a decent
>> Makefile *once*, the problem is gone.
>
> 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
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
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.
Miles Bader
> 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.
One problem I run across is that if I write code using highlighting, the
resulting code can sometimes be less readable when read without
highlighting (typically things like not putting in enough whitespace
because the highlighting provides visual separation, etc).
So to maintain consistent readability, I have to occasionally look at my
code with highlighting turned off, and fix any issues I find...
-miles
--
What the fuck do white people have to be blue about!? Banana Republic ran
out of Khakis? The Espresso Machine is jammed? Hootie and The Blowfish
are breaking up??! Shit, white people oughtta understand, their job is to
GIVE people the blues, not to get them! -- George Carlin
Balog Pal
>>> What kind of fiddling was that? I use Emacs, Make, version control
>>> and the Unix shell are my usual tools, so I have a hard time imagining
>>> what those inefficiencies were.
>>
>> 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.
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.
>> "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.
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.
>> During all the usual cases -- primary code writing, review, raw-compile,
>> debug...
>>
>>> The Makefile can be an issue if you don't understand that it needs
>>> to capture all dependencies (i.e. you have to have autogeneration
>>> for them, using something like makedepend), or that you can rely on
>>> the default *.cpp -> *.o rules. Once you have seen a decent
>>> Makefile *once*, the problem is gone.
>>
>> 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 ...
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
On Jan 10, 1:58 am, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>
> 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
<snip/>
> 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
Sherm Pendley
> 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
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.
By contrast, command lines and make files introduce new languages 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.
sherm--
Andy Champ
>
> 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.
>
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)
Andy
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
> Jorgen Grahn wrote:
>>
>> 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.
>>
>
> 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%2B%2B
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
Andy Champ
<snip>
> 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.
Yes, but...
didn't you ever trip over and drop the entire deck on the floor?
Andy
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
Sherm Pendley
> Moreover, this notion of "non-GUI apps are all outdated with the
> modern world" is astonishingly silly and doesn't make any sense.
You're right - it doesn't. Fortunately for me, that's not what I wrote.
> forced to use incredibly complex tools which
> take a lot of time and effort to master.
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?
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.
sherm--
Andrew Poelstra
> Rui Maciel <rui.m...@gmail.com> writes:
>
>> Moreover, this notion of "non-GUI apps are all outdated with the
>> modern world" is astonishingly silly and doesn't make any sense.
>
> You're right - it doesn't. Fortunately for me, that's not what I wrote.
>
>> forced to use incredibly complex tools which
>> take a lot of time and effort to master.
>
> 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.
Sherm Pendley
> On 2010-01-10, Sherm Pendley <spam...@shermpendley.com> 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
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.
> And most programmer kids these days use Linux, and I'm sure many of
> them will agree with me.
I'm sure they would. But I'm talking about a whole class here, not just
the "programmer kids." Unless you're lucky enough to attend a school
that's large enough to justify a separate AP-level class, the population
of a programming class is going to vary in skill level and background,
and will need a curriculum that's appropriate to the majority.
> Whereas with a text-based system, you just run one command
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."
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.
sherm--
Balog Pal
>> I'm eighteen. I grew up on a Unix prompt
>
> 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.
>
>> And most programmer kids these days use Linux, and I'm sure many of
>> them will agree with me.
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.
>> Whereas with a text-based system, you just run one command
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.
>
> sherm--
Andrew Poelstra
> "Sherm Pendley" <spam...@shermpendley.com>
>> 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.
>>
>>> And most programmer kids these days use Linux, and I'm sure many of
>>> them will agree with me.
>
> 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.
Balog Pal
>> 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.
It is similar to std::string. Indeed vi has a feature other stuff lacks: it
is *there*. Out of the box. Back in time some of my friends learned to use
edlin of DOS. For that same purpose. Because going around they could edit a
file on any random computer.
Btw it is just wild luck vi got in -- we could have the same conversation
you protecting ed. And there probably were similar debates at the proper
time point why vi is needless. :)
>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.
The usual shifting of context. "Use" is fundamentally different to "Use for
XXXX purpose". vi is certainly useful for the maitainance guy to fix the
.profile on a random computer. It in no way imply that it is also fit
for professional software development where being effective and accurate is
on the target list.
> Suggesting any of those to be "youthful rebellion" is purely nonsense.
And I did not claim sensible usage of "tool for the purpose" like that.
However claiming tha raw general tool being superior to the one developed
with the clear purpose -- and btw used in greater numbers around the globe
too, just by people who are not loud in forums -- sounds like that.
With all the "supporting" other statements :)
Andrew Poelstra
>
>>> 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.
>
> It is similar to std::string. Indeed vi has a feature other stuff lacks: it
> is *there*. Out of the box. Back in time some of my friends learned to use
> edlin of DOS. For that same purpose. Because going around they could edit a
> file on any random computer.
>
This is true - and it's actually the biggest reason that I do use vi.
Because I can ssh home from any system, anywhere, or onto any system
for that mattter, and it's there and it works. I'm using it right now
to compose this message.
> Btw it is just wild luck vi got in -- we could have the same conversation
> you protecting ed. And there probably were similar debates at the proper
> time point why vi is needless. :)
>
Well, I would submit that not only was vi designed for professional
development, it does a mighty fine job. But that's a debate I don't
want to get into. :)
Rui Maciel
> Rui Maciel <rui.m...@gmail.com> writes:
>
>> Moreover, this notion of "non-GUI apps are all outdated with the
>> modern world" is astonishingly silly and doesn't make any sense.
>
> You're right - it doesn't. Fortunately for me, that's not what I wrote.
I have to say you are right, I've completely misread what you wrote. Sorry
about that.
>> forced to use incredibly complex tools which
>> take a lot of time and effort to master.
>
> 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?
Just because you slap a GUI onto a tool it doesn't mean it becomes simple (or
even simpler) to master. IDEs are packed with lots of features and, in order to
make them accessible to a user, they need to include ungodly amounts of menus,
buttons and dialogs. If a user is placed in front of an IDE he isn't familiar
with then he is faced with a sea of options that, at least at first, he won't be
able to navigate through without taking his fair share of time to think things
through, even being forced to rely on trial and error to find what he is
searching for.
Now, you place a newbie in front of that same IDE. The newbie's difficulties
are even greater because not only he isn't familiar with that IDE but he also
doesn't have a clue about what he is supposed to do to begin with.
On the other hand, that becomes a non-issue if the newbie doesn't make the
mistake of jumping on the IDE bandwagon and simply relies on a text editor to
write his code. After all, there's a reason people pay good money for IDE
courses and you don't see any of those scams being done with text editors.
> 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.
...which, as you will be hard-pressed to find a single text editor which is not
a GUI application (and let alone force anyone to use it), may be applied to any
case.
Yet, it is far better to let the newbie compile things manually. If he falls
under the impression that "compiling" means pressing that funny looking button
then, without even mentioning the rest of the abstractions IDEs impose on their
users, you will end up with a "programmer" who doesn't even have the faintest
clue about how his code manages to be turned into a binary. It will all be
magic to them. And that isn't in the newbie's best interests.
Rui Maciel
Sherm Pendley
> Sherm Pendley 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?
>
> Just because you slap a GUI onto a tool it doesn't mean it becomes
> simple (or even simpler) to master.
Of course not! It's a complex subject, and no amount of wallpapering
over the complexity will change that. What the GUI provides is a certain
level of comfort and familiarity with the interface.
> IDEs are packed with lots of features and, in order to make them
> accessible to a user, they need to include ungodly amounts of menus,
> buttons and dialogs.
I'm thinking in terms of a class with an instructor. In such a class,
the instructor can simply say "click File / New Project, then click
OK to accept the wizard's default options."
It's not that the IDE is easier, per se, it's that new students who have
grown up using a GUI (as most students today have) already have a
certain comfort level with "ungodly amounts of menus, buttons and
dialogs." It's complex, but it's a kind of complexity with which they
are familiar, so it's less intimidating to them than the (no argument
here) objectively simpler alternative would be.
> Yet, it is far better to let the newbie compile things manually. If
> he falls under the impression that "compiling" means pressing that
> funny looking button then, without even mentioning the rest of the
> abstractions IDEs impose on their users, you will end up with a
> "programmer" who doesn't even have the faintest clue about how his
> code manages to be turned into a binary. It will all be magic to
> them.
How is typing "gcc" any less magical to them? What a compiler actually
does is unrelated to how one invokes it, and in neither case does the
invocation method provide any insight into what's actually going on
behind the scenes.
We're not really talking about different levels of abstraction here,
just different types. And I'm not talking about teaching one type of
abstraction to one level, and then stopping there - that would indeed
not be in anyone's best interest. I'm talking about which abstraction
type to use first, allowing the newbie to get his or her feet wet in a
relatively familiar environment. Command-line compilers and make files
should certainly be taught too, just not on the first day of class.
sherm--
Brian
> Andy Champ wrote:
> > red floyd wrote:
>
> >> Honestly, for professional development, I prefer makefiles to IDEs,
> >> simply because I have complete control -- I'm not constrained by what
> >> the IDE (*cough*VS*cough*) thinks is a legit way of building stuff.
>
> > I beg to differ. But you have looked at MSBuild?
>
> A lot of us don't use windows. While there are good cross platform
> IDEs, they are fine for green field hosted development but they don't
> support cross-compiling for non-native targets.
>
> When a project mixes code from different sources (open source libraries
> for example), makefiles are usually the best, if not only, option.
> Every project I work on has a mix of local and open source code, so the
> build system has to cope with both. There's so much open source code
> out there, the sooner a developer gets to know how to build form the
> command line, the better.
>
The following comments are from the review of the new
book "You Are Not A Gadget" in the Wall Street Journal --
"There's a dominant dogma in the online culture of the moment
that collectives make the best stuff, but it hasn't proven to
be true. The most sophisticated, influential and lucrative
examples of computer code—like the page-rank algorithms in the
top search engines or Adobe's Flash— always turn out to be the
results of proprietary development. Indeed, the adored iPhone
came out of what many regard as the most closed, tyrannically
managed software-development shop on Earth."
(I suspect there's some truth to that tyrannical comment
and thank G-d I don't need to seek employment with Apple.)
There's no denying there's tons of open source out there,
but so much of it is of low quality. In case anyone needs
another example of that --
http://webEbenezer.net/comparison.html.
Brian Wood
http://webEbenezer.net
(651) 251-9384
Ian Collins
> On Jan 5, 4:14 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>>
>> When a project mixes code from different sources (open source libraries
>> for example), makefiles are usually the best, if not only, option.
>> Every project I work on has a mix of local and open source code, so the
>> build system has to cope with both. There's so much open source code
>> out there, the sooner a developer gets to know how to build form the
>> command line, the better.
>
> The following comments are from the review of the new
> book "You Are Not A Gadget" in the Wall Street Journal --
>
> http://online.wsj.com/article/SB10001424052748703481004574646402192953052.html?mod=article-outset-box
>
> "There's a dominant dogma in the online culture of the moment
> that collectives make the best stuff, but it hasn't proven to
> be true. The most sophisticated, influential and lucrative
> top search engines or Adobe's Flash� always turn out to be the
> results of proprietary development. Indeed, the adored iPhone
> came out of what many regard as the most closed, tyrannically
> managed software-development shop on Earth."
>
> but so much of it is of low quality.
There are also a lot of high quality, long standing opens source
projects as well. The products my team develops use several and they
are a lot better quality than a large piece of smelly proprietary
software we have to use.
--
Ian Collins
Jerry Coffin
9c6542...@j5g2000yqm.googlegroups.com>, james...@gmail.com
says...
[ ... ]
> > What is "advanced editing" mean?
>
> Search and replace, for starters. You still have to enter the
> regular expression and the replacement text. By the time you've
> gotten the dialog box open and your hands back to the keyboard,
> I've finished the command.
With VS, opening the dialog only takes a ^h -- no need to remove
hands from the keyboard at all. If you prefer a different key
combination, you can reassign it (actually, I should add that I'm not
sure control-h is really the default, but that's what I have it set
to, and at least offhand I don't recall having changed it).
The one thing about search and replace that IS really annoying is
that they require you to hit the tab key _twice_ to move from the
"search for" to the "replace with" fields in the dialog. You get used
to that fairly quickly, but it still strikes me as a poor design.
> When editing (entering text), anything which requires using the
> mouse is a minus, since it requires taking your hands away from
> the base position on the keyboard. (When just browsing, of
> course, other rules hold, and I do tend to use the mouse for
> most browsing.)
At least with the VS IDE, you can assign virtually any command on any
menu to a key-combination of your choice. Quite a few of them already
have keys assigned, of course, but you can change the assignments at
will -- though I'd admit that it borders on ironic that (at least by
default) no key combination is assigned to open the dialog to do key
assignments, so you need to select Tools | Customize, then click the
"keyboard..." button at the bottom left of the dialog that shows up
(at least the first time -- though this is something you do rarely
enough that I've never seen a reason to assign a key-combo to do it).
Here again we find a bit of poor design: I've never tried to count
them, but at a guess, there are at least a few hundred commands you
can assign to keys of your choice -- but on the dialog they're
displayed in a tiny list box that will only show about four at a
time. Just finding a particular command can be pretty painful.
> One frequent operation for me is grepping for every place where
> some function is used. Then invoking the editor on just those
> files, running through the first modification, memorizing the
> keystrokes in a macro as I do, then undoing it, and invoking it
> on all of the files I'm editing (and only on those files---with
> a bit of care in my original search string, I can only modify
> specific uses of my function).
Control-shift-f opens a "find in files" that supports regular
expressions. That puts the names of the files in a "find results"
window. Control-tab to select that as the current window. In that
window, control-a to select all, then Return to open all the files.
Control-shift-r to record your macro. Do your editing, then control-
shift-r again to stop recording. Control-z to undo the macro run on
that file, then Control-shift-p to run it. Control-s to save that
file, and control-F4 to close it.
If you really do that a lot, I'm pretty sure you can create a macro
to automate it so about all you'd do is one key combo to run the
macro, type in your RE, and do the editing you're going to do in your
macro. It can handle everything from there... The only part I'm not
sure about is having one macro record another macro -- I'm pretty
sure you can probably do that, but I've never tried, so I can't say
with real certainty.
--
Later,
Jerry.
dragan
> A friend of mine is moving to California and did not want to move all
> his library.
"Brokeback Mountain"?
gwowen
> There's no denying there's tons of open source out there,
> but so much of it is of low quality.
In what regard is that different from closed source software?
Or music, film, books or food?
Or, for that matter, politicians, athletes, priests, computer
programmers or traffic wardens?
James Kanze
> Brian wrote:
> > On Jan 5, 4:14 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> >> When a project mixes code from different sources (open
> >> source libraries for example), makefiles are usually the
> >> best, if not only, option. Every project I work on has a
> >> mix of local and open source code, so the build system has
> >> to cope with both. There's so much open source code out
> >> there, the sooner a developer gets to know how to build
> >> form the command line, the better.
> > The following comments are from the review of the new book
> > "You Are Not A Gadget" in the Wall Street Journal --
> >http://online.wsj.com/article/SB1000142405274870348100457464640219295...
> > "There's a dominant dogma in the online culture of the
> > moment that collectives make the best stuff, but it hasn't
> > proven to be true. The most sophisticated, influential and
> > lucrative examples of computer code like the page-rank
> > algorithms in the top search engines or Adobe's Flash always
> > turn out to be the results of proprietary development.
> > Indeed, the adored iPhone came out of what many regard as
> > the most closed, tyrannically managed software-development
> > shop on Earth."
> > There's no denying there's tons of open source out there,
> > but so much of it is of low quality.
> There are also a lot of high quality, long standing opens
> source projects as well. The products my team develops use
> several and they are a lot better quality than a large piece
> of smelly proprietary software we have to use.
I don't know about lots; there are some reasonably good open
source projects, even if they're far from the majority. And a
lot of closed source is pretty poor as well. (Of course, when
the projects aren't open source, it's hard to know whether
they're good, or just lucky.) The very best software (in terms
of reliability) generally comes from more or less rigorously
organized environments, which puts most freeware at a
disadvantage, but a lot of commercial firms aren't that well
organized either. In the end, if you are purely interested in
statistics, all it takes for an open source to survive is
stubbornness on the part of the author---a commericial project
which is really, really bad finishes by going out of business.
But does it make sense to include all of the open software that
no one uses in the statistics?
In the end, if you need a program to do something, evaluate it
on its merits. Without letting open source or not influence
your judgement.
--
James Kanze
Ian Collins
> On Jan 11, 10:05 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>> Brian wrote:
>
>>> There's no denying there's tons of open source out there,
>>> but so much of it is of low quality.
>
>> There are also a lot of high quality, long standing opens
>> source projects as well. The products my team develops use
>> several and they are a lot better quality than a large piece
>> of smelly proprietary software we have to use.
>
> I don't know about lots; there are some reasonably good open
> source projects, even if they're far from the majority.
I never said they were the majority. But everything on my home and work
desktops and servers is open source (OpenSolaris and Linux) and quality
wise it's up with any closed source alternative. The products my
company ships are based on a plethora of opensource packages and build
with gcc plus the one large piece of smelly proprietary software. We
have the source for the latter, so we know how bad it can be!
> The very best software (in terms
> of reliability) generally comes from more or less rigorously
> organized environments, which puts most freeware at a
> disadvantage, but a lot of commercial firms aren't that well
> organized either.
Based on my fairly extensive experience, the organisation of open source
projects and commercial firms is pretty similar. There is a similar mix
of chaos and order. It comes down the the individual(s) who drive the
projects.
> In the end, if you need a program to do something, evaluate it
> on its merits. Without letting open source or not influence
> your judgement.
I basically agree with that, although the issue is more complex (did
anyone mention licensing?) when one is evaluation a piece of software to
be included within a bigger product.
--
Ian Collins
Brian
> On Jan 11, 10:05 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>
> > There are also a lot of high quality, long standing opens
> > source projects as well. The products my team develops use
> > several and they are a lot better quality than a large piece
> > of smelly proprietary software we have to use.
>
> I don't know about lots; there are some reasonably good open
> source projects, even if they're far from the majority.
I thought about challenging the "a lot" also. The only
open source project that uses C that I like is bzip2.
I use linux and gcc, but they both have caused me some
grief. Boost and Loki I think are two C++ based, open
source projects that I think sometimes do pretty well.
There are so many others that don't do as well. Recently
I've been looking at openssl. That is really disappointing.
I tried searching for a C++ alternative but haven't found
anything. There's something called crypto++ but it doesn't
seem to have an ssl implementation. I sent an email to the
author and he said he was too busy and referred me to the
mailing list. The answer on the mailing list was to
consider using openssl. I am reconsidering openssl, but
only because beggars can't be choosers or something like
that.
> And a
> lot of closed source is pretty poor as well. (Of course, when
> the projects aren't open source, it's hard to know whether
> they're good, or just lucky.)
Well, some companies allow you to download their software
for a free trial. Others have free on line services that
you can evaluate at your leisure. So the "hard to know"
is maybe more like it takes a little effort to figure out
if they're good or not.
tanix
>On Jan 11, 10:05 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>> Brian wrote:
>> > On Jan 5, 4:14 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>
>> >> When a project mixes code from different sources (open
>> >> source libraries for example), makefiles are usually the
>> >> best, if not only, option. Every project I work on has a
>> >> mix of local and open source code, so the build system has
>> >> to cope with both. There's so much open source code out
>> >> there, the sooner a developer gets to know how to build
>> >> form the command line, the better.
>
>> > The following comments are from the review of the new book
>> > "You Are Not A Gadget" in the Wall Street Journal --
>
>> >http://online.wsj.com/article/SB1000142405274870348100457464640219295...
>
>> > "There's a dominant dogma in the online culture of the
>> > moment that collectives make the best stuff,
There is no rule one way or the other.
It all depends on awareness of individuals.
>> > but it hasn't
>> > proven to be true. The most sophisticated, influential and
>> > lucrative examples of computer code like the page-rank
>> > algorithms in the top search engines or Adobe's Flash always
>> > turn out to be the results of proprietary development.
>> > Indeed, the adored iPhone came out of what many regard as
>> > the most closed, tyrannically managed software-development
>> > shop on Earth."
>
>> > There's no denying there's tons of open source out there,
>> > but so much of it is of low quality.
>
>> There are also a lot of high quality, long standing opens
>> source projects as well.
I doubt it. Haven't seen a single one to date.
>> The products my team develops use several
The only advantage I see is the abscence of commercial pressure.
So, it is more relaxed environment. But that often means
sloppiness.
>> and they are a lot better quality than a large piece
>> of smelly proprietary software we have to use.
Well, the proprietary code IS smelly in that in vast majority
of cases it is non documented and written in such a way as to
make it virtually unreadable by someone else. Job security issue.
>I don't know about lots; there are some reasonably good open
>source projects,
I wish I saw one.
> even if they're far from the majority. And a
>lot of closed source is pretty poor as well.
Indeed. Except because of typical viciousness in the sw
business, it tends to be much less documented and much less
readable.
> (Of course, when
>the projects aren't open source, it's hard to know whether
>they're good, or just lucky.) The very best software (in terms
>of reliability) generally comes from more or less rigorously
>organized environments,
Well, it immediately associates with viciousness in my mind.
The most disgusting environments I had to deal with use this
"rigorous" approach, which turns out to be a living hell.
There is a subtle balance between precision and humaneness.
Long subject.
> which puts most freeware at a disadvantage,
With freeware people somehow think that the only think they have
to do is to write there "latest and greatest", "revolutionary"
piece of code and documentation and clarify part of it is not
their concern. Most of that code ends up being unreadable
without wasting days on trying to understand their densely
packed piles of totally undocumented crap.
> but a lot of commercial firms aren't that well organized either.
Well, when you are too much concerned with the "bottom line",
you have not much time left and no incentive for people to
take it to the level of elegance and document it so it would be
a breeze to read. Just the other way around, the more unreadable,
the more undocumented your code, the better is it for your
"job security". Sick stuff basically.
> In the end, if you are purely interested in statistics,
Which is meaningless.
>all it takes for an open source to survive is
>stubbornness on the part of the author
True.
>---a commericial project
>which is really, really bad finishes by going out of business.
>But does it make sense to include all of the open software that
>no one uses in the statistics?
Well, the open source gives you at least one consolations:
if something does not work as you expect it, you can change it
and make your own verions. Except you never seem to have enough
time to even BEGIN to read all those piles of totally undocumented
spaghetti code. So it does not work out at the end.
But at least you do have the option.
>In the end, if you need a program to do something, evaluate it
>on its merits. Without letting open source or not influence
>your judgement.
Well, all equal, i do prefer the open source version.
At least you are not locked in into some dead end situation.
I think the major problem with sw business is the pricing issue.
If companies like microsoft would not set a precedence of charging
an arm and a leg for their stuff, it would be much more beneficial
to the whole industry.
Sure, everybody wants a "free ride". But most people can afford
to pay some small amount of money to be able to play with some
fancy sw toy. Say like $50 for someting that really gives you some
joy for a least a couple of months.
The idea of "open source" has its limitations in that those,
who spend a considerable amount of time to write some piece of
code, are forced to simply give it away for free. And to whom?
To some parasites that are forever looking for a "free lunch"?
If you spend years of your life writing some piece of code,
why aren't you compensated for your effort? Are any of those
parasites, using your code, are willing to dedicate years of
THEIR lives to do the same? Or are they simply interested in
sucking?
Basically, people need to pay more attention to the fact that
you have to pay something to get something of value. You need to
be greatful to those, that gave you some joy by writing such a
beautiful piece of code.
And if you are NOT greatful, you are ripping YOURSELF,
and not the other as you might think.
That's the verdict.
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP,
organized by major topics of language, tools, methods, techniques.
tanix
Agreed. The "environment" factor.
But it is not easy to maintain the healthy environment in the
commercial situation, where you are forever stressed out to the hilt.
>> In the end, if you need a program to do something, evaluate it
>> on its merits. Without letting open source or not influence
>> your judgement.
>
>I basically agree with that, although the issue is more complex (did
>anyone mention licensing?) when one is evaluation a piece of software to
>be included within a bigger product.
To my opinion, it is time to reconsider all the major principles
of "doing business" and "licensing" is one of them.
The models that exist right now are not based on principles of life.
They are based on principles of sucking. As much as you can manage.
As a result, we have the whole planet in the miserable state it is in.
tanix
>On Jan 12, 5:10=A0pm, James Kanze <james.ka...@gmail.com> wrote:
>> On Jan 11, 10:05 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>>
>
>> > There are also a lot of high quality, long standing opens
>> > several and they are a lot better quality than a large piece
>> > of smelly proprietary software we have to use.
>>
>> I don't know about lots; there are some reasonably good open
>
>I thought about challenging the "a lot" also. The only
>open source project that uses C that I like is bzip2.
>I use linux and gcc, but they both have caused me some
>grief. Boost and Loki I think are two C++ based, open
>source projects that I think sometimes do pretty well.
>There are so many others that don't do as well. Recently
>I've been looking at openssl. That is really disappointing.
>I tried searching for a C++ alternative but haven't found
>anything. There's something called crypto++ but it doesn't
>seem to have an ssl implementation. I sent an email to the
>author and he said he was too busy and referred me to the
>mailing list. The answer on the mailing list was to
>consider using openssl. I am reconsidering openssl, but
>only because beggars can't be choosers or something like
>that.
Well, what I see is that people somehow underestimate the
value of something added to something.
Look at it this way. The guy(s) wrote some piece of code.
It works. It does something of value to you.
But...
As it oftent happens, it is poorly documented and quite often
poorly structured. Not necessarily a good architecture.
But...
That is ALL that is avaiable to you.
Something HAS been done.
So, what are your options?
Well, either you live with it as it is, or...
Tadaaam!
Add something of value to it and give it another spin.
If the value you have added is available to others, then
they can do the same thing.
The basic principle is care-ness. You need to CARE.
If you care, it is life affirmating.
It ADDS to the equasion.
The very radical idea of "free software" or "open source"
has basically to do with this.
Yes, it takes some inner strength to be able to afford to give
something to others without getting a penny in return.
It kinda contradicts the whole "modern world" ideology.
But...
It is not such a "stoopid" idea, just as open source approach
shows. It is alive. It does produce value. And millions of people
enjoy that value and enjoy that very feeling of not being tied
up with their hands to some mega-sucking enterprise, such as
microsoft, google or poogle.
It IS a life affirmative approach.
>> And a
>> lot of closed source is pretty poor as well. =A0(Of course, when
>> the projects aren't open source, it's hard to know whether
>> they're good, or just lucky.) =A0
>
>Well, some companies allow you to download their software
>for a free trial. Others have free on line services that
>you can evaluate at your leisure. So the "hard to know"
>is maybe more like it takes a little effort to figure out
>if they're good or not.
I bet it would be more beneficial to reconsider the pricing issue.
Sure, free trial gives you at least something.
You don't have to shell out an arm and a leg just to see if
you like something enough to get married to it for a while.
But at the same time, one way or the other, you need to pay for
things. You need to pay for water. You need to pay for electricity.
You need to pay for food.
In today's world, software is like water or food.
And you can not expect to get something for nothing.
I would rather see Sun charging a small fee for Java
instead of giving it for free and eventually going out of business,
being bought by some sharks of Oracle, Microsoft of Google type.
You don't have to go to extremes.
Either you charge an arm and a leg or give it for free.
Just look at how they managed the issue with television in UK.
Everybody simply pays some annual fee and is guaranteed to have
a more or less unbiased television. What is wrong with THAT kind
of approach? After all, there seems to be no rebellion of people.
The same kind of thing could be done with software,
and it would be MORE beneficial to whole life at the end.
And I bet there are quite a few ways to solve this situation
so everyone gets a benefit and at the same time realizes there
is price for everything. But, as long as it is reasonable and
afofdable to ALL, regarless of how big is their wallet, it should
be no problem to even mention.
If you are interested in playing with ideas of writing some code
and that code turns out to be interesting enough to others,
why can't you get paid for it enough for you to get some bread
on your table? Sure, if you have great ambitions, you are welcome
to enter the land of sharks of Microsoft caliber and pay an arm
and a leg for using their "revolutionary technology" of suckology.
Because you are going to get some tangible financial benefit out
of it. But that is a different story.
Interesting thing about sofware is that it is essentially a toy
in most cases.
There are very few pieces of software you use every single day
as a "professional occupation". If you do, that is another matter.
You should pay a fair share of benefit you get from using it.
But MOST of what we use are toys. Those things that give you fun
and provide challenge to your mind to move into new dimensions.
I would not mind to pay some reasonable fee for using Linux.
I don't have to get it for "free". That is just illusion.
PLENTY of people contibuted to it. Why can't we find a way
for them to get paid?
Basically, what I see is two different categories:
1) Commerical use, when you expect to get a tangible financial
benefit out of it.
2) Non commercial use. Such as self-education and fun.
Those are totally different issues and different principles
ought to apply.
To have a reasonably priced software of ANY kind you'd like to
play with will benefit the mankind as a whole and will help to
solve the most urgent issues we have on our hands.
If I can have ANY kind of software I can imagine, that would
stimulate me to play with new and different things. Who knows,
may be one of these days I will find something I am willing
to spend a significant enough time on, which will inevitably
translate into some value.
>Brian Wood
>http://webEbenezer.net
>(651) 251-9384
Ian Collins
> James Kanze wrote:
>
>> I don't know about lots; there are some reasonably good open
>> source projects,
>
> I wish I saw one.
Pretty much everything in the web stack: Apache, MySQL/PostgreSQL, PHP,
your open source OS of choice and MediaWiki to document it.
--
Ian Collins
Brian
> On Jan 11, 9:46 pm, Brian <c...@mailvault.com> wrote:
>
> > There's no denying there's tons of open source out there,
> > but so much of it is of low quality.
>
> In what regard is that different from closed source software?
I think closed source software is generally with some sort
of company that is seeking to make a profit from their
investment in creating the software. Open source projecta
are sometimes nothing more than a negative reaction companies
making money from their products. If that is the primary
basis of an open source project, I think they tend to not
be very good. If generosity is the basis of an open source
project, I think it tends to be better. Some open source
projects are probably a mixture of motivations. One thing's
for sure, the difficult nature of the times is testing the
foundations of a lot of companies and projects. We are,
more than ever, in a survival of the fittest time. I'm
no Darwinian though.
> Or, for that matter, politicians, athletes, priests, computer
> programmers or traffic wardens?
What's a traffic warden? Speaking of politicians, I liked
an article by Frank Rosenbloom about Nancy Pelosi titled,
The Bad Lady Flies a Boeing 757. http://frankrosenbloom.com
Rui Maciel
<snip/>
> In the end, if you are purely interested in
> statistics, all it takes for an open source to survive is
> stubbornness on the part of the author---a commericial project
> which is really, really bad finishes by going out of business.
Not necessarily. There are commercial software packages exist for quite a while
and although they have their fair share of weaknesses they are still here and don't
appear to go away. Possibly it's just due to lack of competition, serving niche
markets and requiring quite a lot of know-how but they do exist.
Rui Maciel
nick
Not to mention gecko and webkit... at least second best to the closed-
source alternatives, if not better. Drupal is good enough for
whitehouse.gov.
And then there's cmake, and so many great code libraries are published
under non-restrictive (LGPL-like) open-source licences (qt, boost,
zlib, png, the list goes on and on).
Plus, many of the leading software architecture tools offer both
commercial and open-source licenses, and some of the commercial tools
are built on open-source tools -- for example ArgoUML / Poseidon.
In other words, I don't see how there's any way anyone _hasn't_ seen,
used, or at least benefited unknowingly from some "reasonably good
open source projects" unless they've been living under a rock for the
last 20 years.
-- Nick
Brian Wood
In an ideal world you wouldn't have to go to extremes, but
this is not an ideal world. Given the pressures that
politicians face from their people to do something to help
them out of their difficult circumstances, the politicians
of countries like China and Russia will throw even large
companies like Microsoft under the bus when it comes to
issues of software piracy. The on line, free model works
out best I think since control over the software is
maintained by the authors and because its free it spreads
more quickly. It is exactly what you want from a business
model perspective. Garage sales are popular where I'm
from. This is 100 times better than a garage sale because
everything is free. People need quality software that
is free just like they need decent but cheap stuff at
garage sales.
Brian Wood
http://webEbenezer.net
651) 251-9384
Brian Wood
> James Kanze wrote:
> > On Jan 11, 10:05 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> >> Brian wrote:
>
> >>> There's no denying there's tons of open source out there,
> >>> but so much of it is of low quality.
>
> >> There are also a lot of high quality, long standing opens
> >> source projects as well. The products my team develops use
> >> several and they are a lot better quality than a large piece
> >> of smelly proprietary software we have to use.
>
> > I don't know about lots; there are some reasonably good open
> > source projects, even if they're far from the majority.
>
> I never said they were the majority. But everything on my home and work
> desktops and servers is open source (OpenSolaris and Linux) and quality
> wise it's up with any closed source alternative.
I'm using Linux -- Fedora 12 -- but I don't think it is very
good. It hangs on me fairly often -- it seems to have a
problem with extensive use of ssh -- and I have to reboot.
I guess OpenSolaris is better, but Sun is going out of
business and has to be bought out.
> The products my
> company ships are based on a plethora of opensource packages and build
> with gcc plus the one large piece of smelly proprietary software. We
> have the source for the latter, so we know how bad it can be!
Gcc isn't much to write home about.
>
> > The very best software (in terms
> > of reliability) generally comes from more or less rigorously
> > organized environments, which puts most freeware at a
> > disadvantage, but a lot of commercial firms aren't that well
> > organized either.
>
> Based on my fairly extensive experience,
This reminds me of David and Goliath. Remember Goliath was
the experienced warrior. David was the young man who didn't
want Saul's armor because it slowed him down too much. He
would have been a sitting duck in that.
> the organisation of open source
> projects and commercial firms is pretty similar. There is a similar mix
> of chaos and order. It comes down the the individual(s) who drive the
> projects.
I don't like the phrase "drive the projects." That sounds like
the tyrannical Apple again. Whether it's politically or business
wise, kind/thoughtful leadership is hard to find. "The Bad Lady
Flies a Boeing 757" is another example of poor leadership that
we've had to endure in the US.
Ian Collins
> On Jan 12, 5:25 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>> James Kanze wrote:
>> I never said they were the majority. But everything on my home and work
>> desktops and servers is open source (OpenSolaris and Linux) and quality
>> wise it's up with any closed source alternative.
>
> I'm using Linux -- Fedora 12 -- but I don't think it is very
> good. It hangs on me fairly often -- it seems to have a
> problem with extensive use of ssh -- and I have to reboot.
> I guess OpenSolaris is better, but Sun is going out of
> business and has to be bought out.
Unfortunate FUD.
>> the organisation of open source
>> projects and commercial firms is pretty similar. There is a similar mix
>> of chaos and order. It comes down the the individual(s) who drive the
>> projects.
>
> I don't like the phrase "drive the projects." That sounds like
> the tyrannical Apple again. Whether it's politically or business
> wise, kind/thoughtful leadership is hard to find.
Do you drive your car? Or do you use kind/thoughtful leadership?
--
Ian Collins
tanix
Well, I mean in terms of documentation.
Yes, there are plenty of good open source projects.
No question about it.
But what I mean is a central issue that is the same for open source
or commercial sw and that is documentation. Most of the code I had
to deal with is not only not sufficiently commented to make it easy
for someone to read it like a news article, but not documented at
all.
Also, user documentation is horrible in most cases.
One example comes to mind is Apache log4j - the logging system
for Java. That thing looked like a disaster to me. It was a while
back and I do not recall the specifics at the moment, but the
"learning curve" was something astronomical. You'd have to literally
study a bible sized pile of information that is pretty much a set
of disassociated ideas, poorly interlinked and and things like that.
tanix
Well, no question, I did benefit "unknowingly" from plenty of
open source projects. The most noticeable to me in terms of doing
what I need to do every day is Kate editor. That thing is beautiful.
Right now I am getting into Lucene search engine.
Looked at it for a few minutes and was pleasantly surprised
to see the well documented sources and nice Javadoc.
You could not expect anything better even in commercial projects.
Someone is working on it right now so we'll have a chance to see
some results.
But documentation argument still stands in my mind.
My point was presented before and that is:
you should be able to read someone elses code as you read a news
article and should be able to understand what is going on within
seconds. That means well documented sources and simple and clear
code structure, uncluttered with all the unnecessary complications
that produce lil or no benefit overall.
>-- Nick
tanix
>On Jan 12, 8:18=A0pm, ta...@mongo.net (tanix) wrote:
>> In article <9c44dedc-1d35-4cdc-a38a-0417a8415...@j5g2000yqm.googlegroups.=
>com>, Brian <c...@mailvault.com> wrote:
>>
>>
>>
>>
>>
>> >On Jan 12, 5:10=3DA0pm, James Kanze <james.ka...@gmail.com> wrote:
>> >> On Jan 11, 10:05 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>>
>> >> > There are also a lot of high quality, long standing opens
>> >> > several and they are a lot better quality than a large piece
>> >> > of smelly proprietary software we have to use.
>>
>> >> I don't know about lots; there are some reasonably good open
>>
>> >I thought about challenging the "a lot" also. =A0The only
>> >open source project that uses C that I like is bzip2.
>> >I use linux and gcc, but they both have caused me some
>> >source projects that I think sometimes do pretty well.
>> >I've been looking at openssl. =A0That is really disappointing.
>> >I tried searching for a C++ alternative but haven't found
>> >seem to have an ssl implementation. =A0I sent an email to the
>> >author and he said he was too busy and referred me to the
>> >consider using openssl. =A0I am reconsidering openssl, but
>> >> the projects aren't open source, it's hard to know whether
>>
>> >Well, some companies allow you to download their software
>> >you can evaluate at your leisure. =A0So the "hard to know"
>> >is maybe more like it takes a little effort to figure out
>> >if they're good or not.
>>
>> I bet it would be more beneficial to reconsider the pricing issue.
>>
>> Sure, free trial gives you at least something.
>> You don't have to shell out an arm and a leg just to see if
>> you like something enough to get married to it for a while.
>>
>> But at the same time, one way or the other, you need to pay for
>> things. You need to pay for water. You need to pay for electricity.
>> You need to pay for food.
>>
>> In today's world, software is like water or food.
>> And you can not expect to get something for nothing.
>> I would rather see Sun charging a small fee for Java
>> instead of giving it for free and eventually going out of business,
>> being bought by some sharks of Oracle, Microsoft of Google type.
>>
>> You don't have to go to extremes.
>> Either you charge an arm and a leg or give it for free.
>
>In an ideal world you wouldn't have to go to extremes, but
>this is not an ideal world.
Understood.
But let us even attempt to look at the ways to make it more
workable. I think people just accepted the capitalist model
as some kind of ultimate reality, while paying lil or no
attention to the fact that that model eventually resulted
in what we have and that is devastation and rootless exploitation
of anyting that moves or does not.
Times have changed.
The game is different now.
Totally different.
Time for a wakeup call.
> Given the pressures that
>politicians face from their people to do something to help
>them out of their difficult circumstances, the politicians
>of countries like China and Russia will throw even large
>companies like Microsoft under the bus when it comes to
>issues of software piracy.
Good. I fully support that. Except I do not think what you
are saying is true.
Companies like Microsoft have been probably the biggest
disaster. Because the only thing they are interested in
is maximization of the rate of sucking.
At this very moment I am having an issue of my new box
totally locking up. My suspicion it is an OS issue.
The problem is I am working on XP and that thing is basically
abandoned. Microsoft is not likely to move a finger to fix
the problem because they are interested in making me pay
again and again and again. For the same thing.
That is why I fully support the open source approach
regardless of how "imperfect" it is, and it is getting to
be quite competitive with commercial version.
In fact, by this time, I basically have everything I need
in the open source version. What is left is more or less
"would be nice to have".
As soon as I see one of my major "would be nice to have"
implemented, I'll HAPPILY say "good buy" to Microsoft,
and add "thanks God. What a hell that was! What a nightmare!"
> The on line, free model works
>out best I think since control over the software is
>maintained by the authors and because its free it spreads
>more quickly. It is exactly what you want from a business
>model perspective. Garage sales are popular where I'm
>from. This is 100 times better than a garage sale because
>everything is free. People need quality software that
>is free just like they need decent but cheap stuff at
>garage sales.
I do not agree with this "free code" idea.
Would you like to do some work for someone and not get a
piece of bread on your table?
I think this isssue is LONG due to be resolved.
We just need to start looking at it and pass our ideas
and words to politicians, employees and to each other.
With the brains of software guys I BET you there is a reasonable
solution that will allow everyone to get a benefit of it
at a MUCH more attractive prices and, at the same time,
to assure that people that do some crative work do get taken
care of. For one thing, they'll have more time to document
their code and hopefully write a better user documentation.
Because they know they are going to get paid and not merely
waste their lives away doing something for nothing.
There is no free cheese.
>Brian Wood
>http://webEbenezer.net
>651) 251-9384
>
--
gwowen
> On Jan 12, 8:03 am, gwowen <gwo...@gmail.com> wrote:
>
> > On Jan 11, 9:46 pm, Brian <c...@mailvault.com> wrote:
>
> > > There's no denying there's tons of open source out there,
> > > but so much of it is of low quality.
>
> > In what regard is that different from closed source software?
>
> I think closed source software is generally with some sort
> of company that is seeking to make a profit from their
> investment in creating the software.
Some of it is certainly. Where the software *is* the product --
Oracle or Quicken or Microsoft -- its often very good indeed. Where
the software is secondary -- say software written by a hardware
manufacturer to interface with their new Gizmo9000, or the firmware on
a cheap DVD player, (or Lotus Notes ;)), it's frequently terrible.
The Darwinian pressure on software companies (as opposed to companies
who make software but for whom its not their primary product) kills
many producers of bad software. Sadly, there are often two springing
up to take their place.
PS: A traffic warden is a meter maid.
PPS: That Rosenbloom article was just awful.
gwowen
> Would you like to do some work for someone and not get a
> piece of bread on your table?
I frequently don't mind, especially if my unremunerated work has some
sort of societal benefit. I have sufficient bread. The only
criterion is that I get to pick and choose what work I do.
Have you never helped a stranger without thought of remuneration or
reciprocation?
It's not a big leap from their to the Open Source culture, especially
if you're the sort of person who finds programming to be enjoyable.
Andrew Poelstra
For a lot of open source programmers, they're writing code for their
own use, and given that they have zero to no interest in marketing or
sales, make it freely available since they wouldn't be making money
anyway. (Nor do they need the money, if they're volunteer coding.)