Recommeded C++ dev environment ?

it's the people who never study computer science due to being intimidated by the first steps I'd like to fix.

Me too, and my reason for it is the same as Eben gives, that I witnessed personally the very bad drop in technical literacy among degree course applicants back when I was in UK academia. Not only was the number of suitable kids dropping each year, but their technical competency was also steadily reducing, to the extent that we had to organize remedial courses just to get them to the level where they could understand 1st year material. Clearly bad, so I agree that fixing the numbers is priority #1.

Unfortunately though, I also see the other side of the coin. Software Engineering was one of the courses I gave, so I have a keen interest in quality systems engineering. Alas after entering the industry as a contractor, it became abundantly clear that software bridges are collapsing everywhere and the notion of engineering quality isn't even on the radar (the game industry is no exception). Just raising the numbers isn't going to fix that.

We're fixing #1 because we think we know how. #2 we're almost entirely ignoring, and that worries me.


Morgaine.

What they need is:

1. Basic text editor (no code highlighting)
2. Compiler.
3. Assembler.
4. Linker.

For learning programming fundamentals, I recommend an interpreter over a Compiler + Assembler + Linker. IMO the assembler and linker layers add unnecessary complexity, and an interpreter can catch run-time errors and report them in a more useful form to the student. Some compilers like Pascal do have good run-time checking so they may be as good as an interpreter, depending on the implementation.

IMO a simple IDE does not get in the way. I recommend a nice simple mouse-oriented text editor with Smalltalk / Macwrite / MS Word conventions linked to the compiler/interpreter so that the editor can automatically select lines with source code errors -- line numbers are so 20th Century -- and display results in an output window.

But none of this "project" bumpf.

Different folk will have different ideas about the best environment so there is no correct answer. In terms of education though the starting environment should be the command line, text editor and a compiler and linker. Show how the toolchain works, let them discover the problems of working in this way and then show them how, in the real world, engineers use the variety of tools at their disposal to become more efficient at developing/debugging. Be sure to show them solutions to the problems before the problems become intimidating.

No makefiles or IDEs in the beginning, just writing code, compiling, linking and executing.

I'm a professional C++ programmer and I do not use IDEs.

The reason for this is that I work for different clients and they don't always have the same tools installed on their Unix boxes. Therefore, I have made sure I am able to use the basics: vi, make, compiler / linkers. The problem with vi is that it takes time and patience to learn, but once you do you find it quite natural. The main keystrokes are almost hardwired into my fingers.

So. Start with the basics, and use an IDE when you have mastered them.

Hello Morgaine,

"I would have no problem recommending an IDE for educational programming if it did not hide the processes involved nor the inputs and outputs of those processes, and did not add eclectic configs of its own which are quite tangential to the task that students are given. I'm no big fan of extra typing. I'm an advocate of transparency, and in my experience, transparency is essential when trying to educate people."

Amen to the last sentence, which gets to the heart of one of the trends RPi has exposed (i.e. a return to less complexity) As to my interpretation of the overall quote, it seems like you've succinctly defined a set of requirements for a bare-bones IDE that an enterprising software engineer or engineers could convert into an open source project for the benefit of the whole software development community not just neophyte software engineers.
Best regards,
A.D. Heberling

You guys should give acme a try. Compared to vim it is quite lightweight and does more. It has a tiled window interface, organized in columns. Each window can hold a file, a shell, directory view etc. It makes good use of mouse keys. Middle button will execute command under the cursor. RIght button click is pattern sensitive. Filenames open a new window, file: linenumber open it with the cursor placed on the right line, <foo>.ps or <foo>.pdf will open a ps or pdf reader, foo(3) will do man 3 foo and so on. An extensible program called plumber is used to a different command depending on the pattern. Or it will search for that word. Each window has a header line called tag, used to hold the file name or current dir + commands. You can type in names of commands you use often. In any window you can type or paste anything and search it or execute it. This description probably makes no sense to most of you. Here's a three part video tutorial does a better job of explaining its features.

Acme was written by Rob Pike and is a Plan9 command. There is a port of many plan9 tools including acme called plan9ports that you can install on a modern Unix (and there is a port of just acme for Windows). See http://swtch.com/plan9ports. I wouldn't claim it is intuitive to use right off the bat but I think you can bootstrap into it much faster than vi!

My typical setup:

• nvi for doing bulk editing (vi commands are hardwired in my fingers! But if you don't know vi, don't bother!)
• acme for more typical edits and code browsing, compiles, driving other tools, looking up manpages, pdf files etc.
• grep -rn pattern for searching
• make for building
• gdb as needed for debugging
• gprof as needed for finding hotspots

If I have to look at 10K+ lines of unfamiliar code, I may use cscope but often grep is good enough.

I have programmed both with and without an IDE. I have used many IDE's and text Editors. I think we need to show both separate tools and at least one IDE. I think writing make files has little to do with c or c++ and this can be shown to be true as when I use Visual Studio, MPLAB or uVision I can write software with no reference to make.

I agree with the notion that learning make is a separate skill and that should NOT be taught in the early exercises.

To me what made the BBC micro easy to program at the start was the text screen input output that is very easy to understand to start with.

Start simple with a text editor with a single c file and gcc.

Then move on to multiple source files with scripted gcc then make then an ide. Small baby steps is best in my view!

I am a professional embedded software engineer by the way. I would like to help out at a raspberry pi computer club at my local school at some point and have a pi on order. I look forward to learning a lot myself there is always lots to learn in the world of software engineering.

FordP, from the Garden of England.

+1 for SciTE. It is a capable editor with syntax highlighting, uses the same shortcut keys as other existing apps such as word processors - should be familiar to most people. More importantly for this discussion, to build your code you have to define the command line you are going to use. So I think it has the best of both worlds. I use it every day to develop C and C++ for embedded systems.
And there is an ARM version - from debian on pi, just type:

sudo apt-get install scite

Even better, download the source and build it (the debian version has lua scripting disabled, which makes it less extensible).

Actually the simplest makefile is no makefile at all . In the same directory as program.cpp, you can type:
make program
Make will run the right commands for you, and you will end up with an executable called program, built from program.cpp. That should get students quite a long way.

I actually rather love make. It's great for building very large software projects with a lot of dependencies. But I totally agree it's not worth learning in any detail until much later.

Without the auto-completion of an IDE, I would be a useless programmer.

[plugwash]

There's no reason Makefiles need to be complex. If a Makefile is complex, IMO it's the fault of its creators and maintainers rather then Make itself, which is very simple in principle though some of its terminology is IMO hard to grok.

The problem with make is it's worldview is overly simplistic. Hacking around this overly simplistic worldview is what leads to horrible makefiles.

make's worldview is one of targets that have dependencies which are specified in the makefile. Trouble is this means you have to specify the dependencies twice (once in the Makefile, once in the file that actually has the dependency) which is tedious and error prone.

The second problem is that while modern make is a pretty powerful language older make implementations were lacking in features.

The result is you end up with the likes of automake to hack arround the limitations in the build tools.

Well this thread was always going to spark a holy war...

Good points from all sides, I will chip in my 2p's worth:
One of the things that stopped me learning coding much earlier than I did was the entry barrier of working out how to use the (command line) tools to arrive at a working executable.
What got me into coding by a roundabout route was when HTML turned up - when you can type something in a text editor and hit "refresh" and the result is there on screen without all the faffing about in hyperspace in between.

The analogies to cars passengers/drivers/mechanics/engineers are all well and good but both here and in the analogy it's over-simplified. The guy who designs the car does not design the nuts & bolts used, nor does he design the spanner. It does not make him any better or worse at designing cars, nor does it affect the quality of the car. Some people are great at designing cars, some people are great and designing nuts and bolts.

Yes it would be nice if everyone knew the full ins & outs of how the entire thing works, but to get kids (or adults) into coding, you need something immediate and a basic IDE gives you an easy "in" to arrive at working software, the choice to go deeper into the rabbit hole is then yours. The tools you use are just that - tools, the quality of the result is a function of your skill, not the tools you use.

Although some IDE's will create code that does not port without tweaking, as long as you're coding in a portable language you're not a million miles off. There's nothing you can't do in an IDE that you can do via the command line & vice-versa. Some kid could develop the next google on a Pi using Scratch, or you could spend years hacking away in assemlber and produce nothing of value at all.

As the boss says, real programmers use 8 toggle switches and a "store" button.

[rurwin]

One of the things that stopped me learning coding much earlier than I did was the entry barrier of working out how to use the (command line) tools to arrive at a working executable.
What got me into coding by a roundabout route was when HTML turned up - when you can type something in a text editor and hit "refresh" and the result is there on screen without all the faffing about in hyperspace in between.

Was that because you could not get your head around the edit-compile-execute cycle, or was it that you were trying to produce a windows (small w) program? Starting from a GUI I can imagine that it gets complex. You edit a file, and then you start up a command prompt, and you've got to find the file you edited and the directories look different even if the CD command made sense. Then you have to type a strange command. Then you have to start up explorer, find a file with a subtly different name from the one you edited, and double-click it. All that on top of windows programming not being simple at the best of times. So I can understand if you found that overwhelming. On the other hand, from the command line it's just three commands: edit, compile, execute. They are a bit magic, but only a bit. So I would be interested if that tripped you up, because if it tripped you up it will trip up others.

The guy who designs the car does not design the nuts & bolts used, nor does he design the spanner. It does not make him any better or worse at designing cars, nor does it affect the quality of the car. Some people are great at designing cars, some people are great and designing nuts and bolts.

But it would affect the quality of the design if he did not understand nuts and bolts; how big they must be for a given load for example. Similarly he might put a nut in a tight corner where no spanner that will fit can torque the nut tight enough. He doesn't have to be able to design a bolt or a spanner, but he should be acquainted with the issues involved. Up until the age of 14 or so, we are not training children to enter industry as programmers; we are giving them an introduction to the issues involved. I imagine that your car designer, when he was in college, was taught about bolt and spanner design in some rudimentary way. Maybe there was some homework involving tensile strength and depth and pitch of threads. Maybe his friend was really into that and those few lessons made him take up a career designing bolts. How else do bolt designers find out about the subject?

I don't think we are going to convince the kids not to go into X; they are used to a windowed environment. I just hope that whatever IDE they get taught, it eases them into understanding the edit-compile-execute cycle, so that when they finally have to use the command line, it is not entirely unexpected.

As the boss says, real programmers use 8 toggle switches and a "store" button.

Tell him that without "Load-Address" and "Execute" buttons, he wont get very far.

I understand the argument that in education, that students should learn the fundamentals first, and the fundamentals do not require an IDE.

That said, once a program goes about a certain size, not using an IDE is a huge cost to productivity. IDEs give instant feedback to if you are referencing something out of scope, or a method that no longer exists. IDEs let you refactor intelligently without using search and replace which may lead to bugs when you search and replace something with the same token name but different meaning.

IDEs allow me to use new APIs with a minimum of fuss because I can use autocomplete to look at the menu of API methods available at any one time. IDEs let me incrementally compile rather than go through a full build when making a change. IDEs let me use multiple languages together at the same time and allow me to cross reference between those languages in realtime.

I would be 90% less productive without an IDE. Unless you have a photograpic memory for the 100s of APIs that you will use on an annual basis, correct use of IDEs is an essential modern programming skill that leads to less errors and faster turnaround times.

Here (http://linuxtortures.blogspot.fr/2012/0 ... ing-c.html) you can find a post just written by me where you can learn step by step how to cross develop on your Raspberry using eclipse. I hope you enjoy it reading as much as I did writing it

Best Regards!!

Big thanks Javierbravoconde, this is exactly the info I was looking for - including how to debug the code

Cheers!
Paul

I would recommend a combination of Sublime Text (link) and the standard tools (GNU Make, GNU GCC). Make is already integrated into Sublime Text I believe.

Only drawback with Sublime Text is that is around $60. Not cheap.

Here (http://linuxtortures.blogspot.fr/2012/0 ... ing-c.html) you can find a post just written by me where you can learn step by step how to cross develop on your Raspberry using eclipse. I hope you enjoy it reading as much as I did writing it

Best Regards!!

I tried to get this to work on Ubuntu VM but at the stage where I select new C++ project, I don't have an option for "Cross-Compile Project"

Any suggestions would be welcome.
Cheers,Ears.

[jamesh]

I understand the argument that in education, that students should learn the fundamentals first, and the fundamentals do not require an IDE.

That said, once a program goes about a certain size, not using an IDE is a huge cost to productivity. IDEs give instant feedback to if you are referencing something out of scope, or a method that no longer exists. IDEs let you refactor intelligently without using search and replace which may lead to bugs when you search and replace something with the same token name but different meaning.

IDEs allow me to use new APIs with a minimum of fuss because I can use autocomplete to look at the menu of API methods available at any one time. IDEs let me incrementally compile rather than go through a full build when making a change. IDEs let me use multiple languages together at the same time and allow me to cross reference between those languages in realtime.

I would be 90% less productive without an IDE. Unless you have a photograpic memory for the 100s of APIs that you will use on an annual basis, correct use of IDEs is an essential modern programming skill that leads to less errors and faster turnaround times.

And yet the code that runs on the Raspi GPU is developed without the aid of an IDE, and is generally of a very high quality. Are IDE's making things too easy? So when something difficult comes up people are no longer able to deal with it?

I think some of the analogies used here, and more worryingly, the way others extrapolate ideas from them based on their own perceived intelligence is worrying..

Bottom line?
Whether you use an IDE or not, your still a developer, (in other words e-n-g-i-n-e-e-r-s)
Turning a computer on and running a piece of software? That would be a 'Driver'

I use both methods depending on what I am coding, and my [url]personal[/url] preference is to use an IDE for big projects - it helps me visualise the whole project. Maybe this makes me a poor programmer?

For small jobs, I don't need the IDE.

Using an IDE doesn't make you a bad programmer. Using an IDE incorrectly makes a bad programmer. So does writing un-commented, untidy code without an IDE. If we teach people how to use an IDE correctly, then I don't see an issue.

The whole idea of this project was to reach as many people as possible and teach them - you can either try and teach the masses, or the elite few. The masses will find an IDE easier to grasp.

Progress, you cant stop it.

Using an IDE doesn't make you a bad programmer. Using an IDE incorrectly makes a bad programmer. So does writing un-commented, untidy code without an IDE. If we teach people how to use an IDE correctly, then I don't see an issue.

Similarly comments aren't a panacea. There is plenty of great code without comments. Quite a number of luminaries see them as a bad smell.
Tim Ottinger says "A comment is an apology for not choosing a more clear name, or a more reasonable set of parameters, or for the failure to use explanatory variables and explanatory functions. Apologies for making the code unmaintainable, apologies for not using well-known algorithms, apologies for writing 'clever' code, apologies for not having a good version control system, apologies for not having finished the job of writing the code, or for leaving vulnerabilities or flaws in the code, apologies for hand-optimizing C code in ugly ways."

My experience is that comments very often go stale. I think this is more likely to happen these days with a nice refactoring browser in most IDEs.

Writing good code is about making it work, and making it right (good clean readable code with unit tests). Unfortunately most people stop once it is working.

Writing good code is about making it work, and making it right (good clean readable code with unit tests). Unfortunately most people stop once it is working.

Well said

Writing good code is about making it work, and making it right (good clean readable code with unit tests). Unfortunately most people stop once it is working.

Well said

+1

In music, the difference between a professional and an amateur is that the amateur practices until they get it right. The professional practices until they can't get it wrong.

Similarly comments aren't a panacea. There is plenty of great code without comments. Quite a number of luminaries see them as a bad smell.
Tim Ottinger says "A comment is an apology for not choosing a more clear name, or a more reasonable set of parameters, or for the failure to use explanatory variables and explanatory functions. Apologies for making the code unmaintainable, apologies for not using well-known algorithms, apologies for writing 'clever' code, apologies for not having a good version control system, apologies for not having finished the job of writing the code, or for leaving vulnerabilities or flaws in the code, apologies for hand-optimizing C code in ugly ways."

I completely disagree with this. To me, comments are the most important part of the code, particularly comment blocks at the beginning of functions and other large blocks of code. If you have excellent comments, you can derive the code, but if you just have uncommented code, understanding it is reverse-engineering unless the function is trivial.

One of the chief complaints I hear about FLOSS is inadequate documentation. Sure, you have all the source code, but trying to understand it well enough to improve it or use it in a new environment is often more difficult than rewriting the functionality from scratch.

The primary purpose of a programming language is to tell the computer what to do. Since the computer isn't interested in how the program works, it doesn't need comments. The secondary purpose of a programming language is to tell other humans what the program does, and how, and why, and when other approaches were considered and why they were rejected, etc. Comments are IMO the best way to capture this information.

Similarly comments aren't a panacea. There is plenty of great code without comments. Quite a number of luminaries see them as a bad smell.
Tim Ottinger says "A comment is an apology for not choosing a more clear name, or a more reasonable set of parameters, or for the failure to use explanatory variables and explanatory functions. Apologies for making the code unmaintainable, apologies for not using well-known algorithms, apologies for writing 'clever' code, apologies for not having a good version control system, apologies for not having finished the job of writing the code, or for leaving vulnerabilities or flaws in the code, apologies for hand-optimizing C code in ugly ways."

I completely disagree with this. To me, comments are the most important part of the code, particularly comment blocks at the beginning of functions and other large blocks of code. If you have excellent comments, you can derive the code, but if you just have uncommented code, understanding it is reverse-engineering unless the function is trivial.

You make it sound like deriving the code is simple it isn't - English is far less precise than any programming language. And of course it implies that the comments are correct. That is far from being the normal case in my experience.

Also you don't just have the code. You have the unit tests - which should test the external interface to your class (or test the function). That is far better documentation than most comment headers.

By reducing the length of functions and methods - sometimes drastically, by strictly adhering to DRY, and naming variables and methods and functions sensibly the code becomes much easier to read. So much so that nearly all comments become unnecessary. Now some "why comments" are still useful but those are very much in the minority.

Instead of sitting here trading comments - how about a test. Someone suggest a smallish (but non-trivial) piece of code - I would prefer C or Java it has been ages since I have touched C++, which they think is a good exemplar of commenting (or just some code without comments). I will try and refactor and remove the comments I feel are redundant. This will probably need to be done on a wiki rather than here. That way people can see and judge for themselves how readable and understandable a low-to-no comment piece of code can be,

<clip> Now some "why comments" are still useful but those are very much in the minority.<clip>

This is where your argument fails. The whole point of comments is 'why', not 'what'. Of course you can see what has been done by reading the code. That is not true for why it was done.

For example, it is impossible to write maintainable code that is derived from standards without including a significant amount of information that either refers back to the exact part of the relevant standard or includes much of the standard within the code.

By standards I mean things like http://www.dvb.org/technology/standards/En50221.V1.pdf. These are documents that are often hard to understand and can be extraordinarily pithy. There have been many times when I find the one vital bit of information is a short sentence in the middle of a page. If I didn't clearly comment this in my code, I'd be right up s**t creek without a paddle when I'm looking back at the same code years later. Right now, I'm refactoring code I wrote in 2007. The comments that I wrote back then are making it easier to refactor without introducing regressions. Perhaps it's just my age and failing memory, but somehow I rather think not.

Arguments over comments are not the same as arguments over IDEs vs the command line. You can make software just as well with or without an IDE. Software without comments will never be as maintainable as software with comments.