Recommeded C++ dev environment ?

[ReadiesCards]

One of the tasks coming out of the Oxon-RaspberryPi group was to find out the recommended way of developing C/C++ apps for the RPi.

Is it vi, gcc, make etc (not my preference)?
Or is there a C++ IDE that'll run within Debian on the RPi direct?

Being familar with RADStudio, Visual Studio etc on MS-Windows I am a bit reluctant to go 'back' to make files and the like but I am a very novice Linux user...

Paul

[nick.mccloud]

RPi = Linux
Therefore c dev would best follow the standards for c dev on Linux

However, for IDE fans (including me), Geany makes for a softer starting place.

[Max]

Or is there a C++ IDE that'll run within Debian on the RPi direct?

"sudo apt-get install qtcreator" seems to work.




For patching existing code written by others, other programming languages and low level work, I prefer Komodo Edit as text editor and just compile from the command line.
Don't know if that's available for the Pi though.

[Morgaine]

IDEs are a very bad idea in programming education, because they hide the tools in actual use.

They result in students who don't understand the compilation and linking process, and who think that debugging happens by magic. Used in a non-trivial project, they produce programmers who don't understand the dependencies between the program modules they write, because the IDE has sorted all that out for them, and that leads to projects that are hard to maintain and scale poorly.

The end result of IDE-based learning is not a fully proficient programmer, but just a proficient user of the IDE. That may be adequate for vocational training, but not for education which is concerned with principles.

Morgaine.

[woodinblack]

IDEs are a very bad idea in programming education, because they hide the tools in actual use.

They result in students who don't understand the compilation and linking process, and who think that debugging happens by magic.

I would completely disagree with that. I started with tools where you had to build objects, then manually link them together, then progressed to makefiles, programming in editors such as emacs and compling on the command lines, eventually going up to using tools such as XCode and Visual Studio.
It teaches you absolutely nothing about programming, but a lot about configuration and tools, which you may or may not have to do again. All make files teach you is how stupid make files are

Programming C++ (or whatever c based language) in an IDE, such as visual studio doesn't insulate you from dependancies and working out modules, if anything it eases you into them, but you still need to know how it works, and what is needed to compile code and link it together.

[Morgaine]

It teaches you absolutely nothing about programming, but a lot about configuration and tools, which you may or may not have to do again.

And using an even bigger and more esoteric tool, the IDE, doesn't do this? Your implied assertion simply doesn't make sense.

The IDE hides pretty much everything concerned with the tools that really do the job, and worse, it adds a whole pile of IDE configuration knowledge to assimilate that is totally useless to know except within the IDE in question. Knowledge of the individual tools that the IDE invokes is applicable to all IDEs or to development without any IDE, and it acquaints the student with the kinds of problems that appear in each phase. With development under IDEs, it's truly a case of "and magic happens now", and the user is more trained than educated.

I'm not disputing that IDEs are useful for personal productivity. I'm just disputing that their impact on education is a good one. From what I've seen, they result in the creation of less capable software engineers (poor for education) who deliver systems that won't even build unless you happen to be running their particular IDE (poor for portable open source projects).

Morgaine.

[khulat]

... who deliver systems that won't even build unless you happen to be running their particular IDE (poor for portable open source projects).

I am not disagreeing with you completely, but that is a problem with every IDE. If you program on paper (beware the hyperbole) you will have a really hard time compiling with Visual Studio. Personally i think the best way to teach is showing the hard way, and using IDEs. The timing is debatable, and i guess there is no right or wrong way.

[Morgaine]

The timing is debatable, and i guess there is no right or wrong way.

It's the timing issue that I believe is totally critical, from my own experience in academia back when I was teaching programming to undergraduate engineers. Top-down may be equivalent to bottom-up as far as machinery is concerned, but from what I've seen, humans need a foundation before they can layer higher-level ideas on top of it. Unless you lay that foundation first, they don't really understand what they're doing very well, as you can tell quite easily by asking them to explain what they've done.

This is why I'm convinced that if you want effective engineers, you need to explain the principles and get them to understand the low-level tools first. Once they've absorbed that and gained a reasonable amount of experience in it, then sure, I'm all for using high-powered tools to gain productivity. Productivity is particularly important in industry, but education is a rather different kettle of fish to industry. I want my engineers' kettles to be well grounded.

Morgaine.

[ReadiesCards]

Thanks I'll give Geany and QtCreator a go
Paul

[Narishma]

I have to agree with Morgaine. There's nothing wrong with using IDEs once you know how all the underlying tools work together to create the executable from the source code, but I don't think starting with an IDE is a good idea.

Also, +1 for Qt Creator.

[nick.mccloud]

I have to disagree with everyone - and agree with everyone at the same time.

I think a soft start with a few lines of code to concentrate on what a program is - a bit more than hello world - a few ifs and loops and things.

Then pick apart what the IDE did to make that text file turn in to a program.

This way the student can concentrate initially on the getting to grips with the language. Rather like teaching someone the basics of driving before popping open the hood to have a look at the wonders & complexity of a modern engine.

[Morgaine]

nick.mccloud, your car analogy is surprisingly good!

To follow your train of thought, what is the goal of programming education? To create drivers, or to create car mechanics?

I'll answer my rhetorical question: it's to create car mechanics. We already have an IT curriculum that creates drivers, and it's universally condemned as not delivering the engineers that the country needs. Eben Upton has mentioned this repeatedly in his many talks.

An IDE will certainly create effective drivers who don't know what goes on under the hood. But that is not what we want in programming education. Driving lessons are equivalent to vocational training in a craft or discipline. It's very different to education, which is about underlying principles and not about pretty tools that hide those principles.

In fact, a programmer who doesn't understand the underpinnings of the discipline is a liability, not an asset, and is the cause of much of the well known Software Crisis that is responsible for "software bridges" falling down millions of times daily across the world. There is no shortage of people who know how to program but lack any background beyond the rectangular window of their IDE. That's fine for them, but it's not what programming education is trying to promote.

Creating more drivers misses the point of this educational effort. At least in this country (UK), what we're trying to deliver is more people with deep insight, our future engineers.

Morgaine.

[nick.mccloud]

I'd have a slightly different interpretation on the drivers definition.

Most computer users are passengers.
There are a quite a number of drivers, many of them think they are mechanics.
There are a few mechanics.
There are hardly any engineers.

Passengers = end users.
Drivers = visual type programmers never getting in to the realms of computer science but relying on the raw power of the computer to compensate for inefficient programming.
Mechanics = lower level programmers who do get involved in efficiency & tuning & longevity.
Engineers = those that can design & build an OS or parts thereof.

We need to increase the pool of drivers, mechanics and engineers, recruiting from one level to the next.

[Max]

Would say an IDE is more like driving a car with automatic transmission.
Yes, they have a reputation problem in Europe (the "real men drive manual gear" macho type of thing), but saying they create worse drivers who are responsible for all accidents, is giving a bit too much credit.


Yes, it is important that you have learned to call a compiler, assembler, linker and debugger manually from the command-line at least once.
As well as written a plain Makefile.
But wouldn't continue doing that after that.

[MBeentjes]

It seems to me that GCC (G++) will run on the Pi?

[Nr90]

Yes gcc is supported.

Another reason to learn how to use vim / gcc / make over a complicated IDE is that it's a very lightweight solution, not exactly a luxury on the Rpi.

[johnbeetem]

Here's my favorite IDE story. When I was a university freshman, I took a senior/grad level course called Computer Organization, which included extensive programming on a PDP-11. (Oh bliss! Oh rapture!) The first programming assignment was to write a small PDP-11 ASM program to input a character from the teletype and print it back 10 times. You were required to hand-assemble the program and toggle the binary machine language in through the front panel. This was intended to get you really programming down at the bare metal, and was very successful and loads of fun.

The next assignment involved using the assembler and linker, usually with punched card source code. Well, it turned out that using the assembler and linker had a steep learning curve and the first assignment did not prepare students for it. So they changed the course so that students had to use the the assembler and linker for the first assignment. It made the first assignment harder and less fun, but created skills needed for the rest of the course.

Personally, I think many programming tools are a distraction from programming and throw in unnecessary complexity. I've never used the Eclipse IDE myself, but from what I've read about it Eclipse sounds like flying a jet airliner with 100,000 switches. I got started with Focal and BASIC which had line number based editors, which is a really simple way to enter programs though it gets pretty old. I did most of my undergrad programming using punched cards, which are actually a terrific way to edit programs: Who needs cut and paste? Just move the cards around in the deck! Punched cards also really encourage you to keep your programs small -- 2000 cards is as much as you can comfortably carry, and after 4000 cards you'd better get a cart.

I'm not advocating a return to line numbers and punched cards: I'm just saying that the editing tools I got started with didn't distract me from programming. If "vi" had been the only thing available, I may have become a physicist instead

Regarding the car analogy: Given that you aren't allowed to drive a car before age 16 in USA, and IMO really shouldn't drive until at least 21 anywhere, there's oodles of time to learn how a car works long before you're allowed to drive one Actually, I did just this with computers -- learned how they worked from public library books long before I was able to play with one.

[Morgaine]

Ive never used the Eclipse IDE myself, but from what I've read about it Eclipse sounds like flying a jet airliner with 100,000 switches.

It's not quite that bad , but your analogy is correct in general terms.

It has always puzzled me why this should be so. There is no inherent reason why an IDE needs to be made obscure through having a zillion little config windows and no obvious relationships between them. You have to learn those relationships by rote, and it takes quite some time to become proficient in using the tool. This detracts from what you really want to do which is to become proficient in understanding computers and programming them. Learning an IDE is not programming, it's just a largely unnecessary barrier that stands in the way of programming.

Now I know that dyed in the wool IDE supporters will immediately answer that learning the commandline tools is likewise an unnecessary barrier, which is true in principle, but they'd be missing the key point about the size of the two barriers. In both cases you need an editor, so that balances out. With commandline tools, since you've edited your program source file you already know it's name. Beyond that, all you need to know is the name of the compiler to run, and if you don't know that then you don't deserve to be in computing. This alleged "barrier" is orders of magnitude smaller than learning an IDE and setting up "projects" that have no a priori known relationship with your directory structure and filling in configuration windows containing fields that are completely opaque to you at this stage. And then figuring out where all this info was stored and what needs to be backed up and how to export all this stuff in a portable and IDE-independent way.

The above isn't really specific to any particular IDE, because they all have elements of this --- it's called the Big Tool Syndrome. It appears to be mandatory that designers of programming IDEs must aim for that "jet airliner with 100,000 switches" ... and the labels on the switches must be obscure.

OK, I'm exaggerating a bit, I know. But if there is an "consciously transparent" IDE around, one which just provides a visual interface to commandline tools so that your project is automatically portable and not IDE-dependent, I've yet to find it.

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.


Morgaine.

[MBeentjes]

Nice to read that gcc will be supported on RPi, that means I will use the RPi for programming software for Linux.

Thank you for the information.

[rurwin]

'With commandline tools, since you've edited your program source file you already know it's name. Beyond that, all you need to know is the name of the compiler to run

Often you don't even need to know that. The smallest Makefile is:

Code: Select all

program: program.c

If make is set up with the right defaults, which is fairly likely, it will compile the program without you telling it how.

As regards an IDE, I use jEdit. I'm hesitating to recommend it here because it's a java program and I don't know how fast it will be on the RaspPi. It also does not (yet) have a push-button make. But it is very easy to write extensions for it, so it could have. (I believe it might have push-button ant, but that is over-complex for education.)

[dmsuse]

so...

what do we use?? nano ? a text editor?

"Recommeded C++ dev environment ?" -- Those arguing for a GUI-less development environment have not said what should be used

[redneon]

Personally, I find X far too slow to be usable at the minute so I'm using Emacs (with integrated gdb) for all my coding so far and it suits me fine.

[mccp]

With commandline tools, since you've edited your program source file you already know it's name. Beyond that, all you need to know is the name of the compiler to run, and if you don't know that then you don't deserve to be in computing. This alleged "barrier" is orders of magnitude smaller than learning an IDE

I think that you make some very good points about using tools like compilers before learning an IDE. I am able to recall that it took me several weeks to become comfortable with Eclipse a few years ago after many years of Microsoft tools.

However, although it is perfectly reasonable to train new programmers how to manually build a project with command line tools, there comes a point when you have to use a Make-style tool. I would argue that it is easier to work out how to build a more complex project when the idiosyncrasies of Make are dealt with by an IDE.

By all means come back to Make further down the line, but it seems like an avoidable, and very steep, part of the learning curve.

Anyhow, there's no way that Eclipse will be useful with RasPi unless you create a cross-compile/remote GDB setup. I'm very interested to see the recommendations for more lightweight IDEs.

Paul.

[rurwin]

I got all the way through university without ever writing a program that consisted of more than one source file.

Making allowances for the younger start and more modular style these days, maybe there will be some use of make, but not much. Using complex Makefiles will be necessary at post-grad level either in acedemia or industry, but not before. Of course you always get the geniuses, but geniuses tend learn stuff easily.

[johnbeetem]

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.

IDEs can be simple or complex, and it depends entirely on the UI talent of its designers and maintainers. I do a lot of Verilog-based FPGA design. I find the Xilinx IDE to be reasonably usable, once you figure out that the silly "Sigma" symbol gives you the project summary. OTOH, I find the Actel/Microsemi IDE hard to use properly and I'm terrified that a client will ask me to explain how to use it.

OTOOH, for serious rebuilding of a Xilinx FPGA, I find using the command line tools with a Make file to be the most reliable way to rebuild with all the correct options. It's pretty easy to take the command log generated by the IDE and convert it into a Make file.

For my own programming, I primarily use my own language (follow my link if you're curious) which includes its own GUI editor with simple IDE capabilities such as automatically scrolling to and selecting expressions that have syntax or semantic errors. I use the same editor for C programs, and run GCC under Make in a separate Terminal or Xterm window.