Developing for the Linux Desktop

Newsforge (part of the sinister OSDN keiretsu ^[?] ) has a nice story about getting starting developing for the GNU/Linux desktop. I'm not totally sure this is the best way to start (any guide that starts off "First, learn C++" is not optimal in my book...) but there are some good tips in there.

Comments

Re:How about people who already know C++

[Anonymous Coward]

Well, first off, know that VC++ isn't really c++ unless you compile with the (cleverly hidden) ansi command line switch - otherwise scoping's all messed up, microsoft-styleee. KDE has on-line tutorials on www.kde.org. www.troll.no has a good Qt tutorial too. Note that KDE/Qt is far easier than GNOME, if you come from a C++ background, despite it's reliance on an obsolete preprocessor ("moc")

And forget everything you know about the MFC - it's pants.

The other alternative would be to just get JDK 1.3.1 for linux from Sun and learn Java/Swing, and netbeans IDE for development. It makes coding desktop windowed applications really easy. Java's like an easier C++, and the large Java 2 standard API is actually pretty cool for graphics (just stay away from old-style AWT stuff, and stick to Swing and Java2D)

Series of projects to learn to code?

[Anonymous Coward]

I know a little C and C++ but right now I'm in the stage of knowing the syntax but without an idea of how to test and really learn it. It would be great if there was a site where a series of programming problems/tutorials to solve. It would be great if they started out small and gradually moved upwards in difficulty.
Perhaps the more difficult problems would make use of various libraries such as the QT lib, or the GTK lib or whatever. Other languages could also be covered.
I guess it could be set up by programmers with possible discussions on good programming practice etc. etc. It seems ideal in an free/open source environment and could lead to better software development instead of producing hundreds of mediocre programs along with the good stuff. If there is already a site like this, could someone list the URL here? Just my $0.02

Re:Series of projects to learn to code?

[rsadasiv]

It focuses on linux desktop apps linked to relational databases, but check out Database Application Programming with Linux.

Hopefully, this would at least help you get started.

Ram Sadasiv

Re:Series of projects to learn to code?

[scompt]

I know at the school I go to, the CS department has a program (custom, I believe) called 'try' that they use to initially evaluate submissions. To my knowledge, what it does is run the program with a certain input and looks to recieve a certain output after execution is complete. The STDOUT & STDERR have to be exactly the same as what it's expecting to perfectly score on the assignment. Everything that goes in and comes out of the program is specified in the assignment so you've got something to work towards. Something like this, wrapped into some kind of web-based form might work. There'd probably be a security issue though of running somebody's compiled program on your server though. Woo-hoo, first post. Ed.

Re:Series of projects to learn to code?

[Tuonenkielo]

This is a very goo idea. How could it work? Maybe some way to acquire a coding task, then way to submit your 'answer' for checking, and if it doesn't check out there'd be some hints on what didn't exactly 'fly'? I think it'd be a whole lot of trouble to set up, but it'd be really nice project. Maybe it could be started small with a mailing-list spreading the coding problems and some people doing the analysis of the submitted answer sources. Hmm... Now, what'd this take to set up? I'd like to enroll in this kind of coursework.

Re:Series of projects to learn to code?

[n2dasun]

I think it makes a lot of sense. I'm an idiot, with the same problem as this guy, and I'd love to learn to program. I've got a little time to kill. If anyone wants to get something like this started, I'd love to help, especially being a guinea pig so they could see guage the difficulty levels of the projects.

Re:Series of projects to learn to code?

[n2dasun]

Maybe we can start here: http://www.inf.bme.hu/contests/tasks/ This lists programming contest problems from ACM contests of the past. We could start out by collecting problems that already exist, and having people rate their difficulty, and have a forum for submitting new problems, which will in turn be rated. Anyone think it can work?

Re:A few things about C++...

[Anonymous Coward]

I think a lot of people's well-worn objections to C++ are going to wear out when C++0x arrives. Then they'll have to stop casually judging a language by its standard library, and look at what you can actually do with it (including what you can do with third party libraries and stuff you -- shock! -- write yourself).

I disagree. Most people already use platform specific or home grown libraries instead of the standard library, either because they don't know any better or their code base predates the standard. These people love to complain about features they don't understand or don't use. Adding more features won't necessarily make them happy.

Besides, Java needed a huge library covering everything under the sun because none of the existing APIs (mostly C & C++) were accessible.

C++?

[Anonymous Coward]

Well, this is kind of off topic... however I don't know where else to look for information on C++ that is easy to understand. Most of the material I've been reading and looking at talks about classes, structs, aliases, and stuff like that in C++. I want to learn to program in C++ very much, but I'm stuck with a very hard to understand Dietel and Dietel book that I had in a C++ class in college. As you can probably tell, I didn't really learn that much from that class in college. I wanted to pick up tihngs on my own, but I don't know where to go from. I'd love to learn to program with sockets, even maybe some X apps or somtehing of the similar, but I don't see that much documentation (well, that's easy to understand and findable) anywhere. I've been googling for the past 3 days and I'm pretty much stuck. I've been slowly working with "LEarn C++ in 21 days" but it's not that great becasue I can't understand a lot of the material at times. I'm going to continue trying (I've done this multiple time over the years, but I guess I might not be cut out for programinng). OH well, anyone that can help me along... it would be a great help... thanks.

Re:C++?

[David Greene]

OO is not needed to do magnificient things. Look at the Linux and other kernels.. Look at the many other applications that are not C++. Granted you can do OO programming In plain C.

You're right that OO is not needed to do magnificent things, but you're wrong that Linux is not OO. It's not explicitly OO in the sense of the language or programming style used in its implementation, but the whole concept of UNIX itself is based on OO principles. The "everything is a file" idea sounds suspiciously like the OO "isa" relationship (A isa B).

Just today I was reading the LWN kernel page, where 64-bit DMA interfaces are discussed. To support 64-bit DMA a new datatype will be declared along with a bunch of new interfaces probably looking very similar to the current 32-bit interfaces. In addition, various devices will require different kinds of DMA transactions based on the type of device and/or the host system configuration. Sounds OO to me.

I have always viewed OO programming as a style not as something very important. Everything you can do with your OO styles I am sure can be done without it.

Well of course, since in the end it's all machine code anyway. :)

I am concerned about the statement that OO is not important. It's not magic pixie dust, but it helps solve real world problems very well. It's an important tool in the programmer's belt. Yes, it's "merely" a style but style is what makes art art. And make no mistake, program design and implementation is an art as much as it is a science.

--

Re:C++?

[David Greene]

Hoo boy...

There are many new features over C, which radically increases the complexity of the language.

This is certainly true. C++ compilers are hard to write. So are C compilers.

C++ maps poorly onto the actual assembly language of the processor

Please back up this statement. It maps no worse than C does, given code with the same functionality.

the code produced in C++ for any program with more than one object will ALWAYS be slower than equivalent C code.

Careful with those absolutes. I don't know what you mean by "more than one object," but I can show you C++ code using standard library constructs that runs much faster than functionally-equivalent C code, even when the C code uses custom implementations tuned to particular data types.

C++ is not, not, not slow.

Finally, it's not possible to write C++ code to maximise code-space or RAM-space efficiency,

This is just plain wrong. As with any language there are multiple entries in the solution space for a given problem. Choose the one to use the least amount of X. In the end you can always resort to "C with classes" if you must (which you shouldn't).

since you are entirely at the mercy of the compiler writer - the best you can do is select from a coarse menu and hope the compiler does it properly.

As is the case with any language.

--

Re:C++?

[David Greene]

The important thing to "get" about OO (at least in the C++ sense) is that you invoke an interface on an object and it does different things depending on the true type of the object. This is nice because you can write code that doesn't really care about the type of thing it's operating on:

void drawAll(const shapeList &shapes)
{
for(shapeList::const_iterator i = shapes.begin();
i != shapes.end();
++i) {
(*i)->draw();
}
}

All we have here is a list of pointers to Shape. Each object could be a Circle, Rectangle, etc. The drawAll code doesn't care. All it knows is that it has to draw everything. This nicely separates the high-level "draw everything" interface from the individual details of how to draw each shape. A good way to look at it is that the C++ virtual function mechanism has replaced the traditional C tagged union and switch construct. That's a lot of code to save. :)

Projects like Linux would really benefit from this. Every time a C++ programmer sees and if-else tree or a switch, she instantly thinks virtual functions and wonders why anyone would go to all the trouble. :)

The UNIX file system is OO in this sense. The user redirects from or to device nodes (i.e. to do audio recording or playback). He doesn't care what type of device it is or even that it is a device. All he knows is that this file causes neet things to happen. Too bad it's not implemented in an OO language in Linux :(

As for minimalist, C++ can do that too. Not only does it generate "as good as C" code for equivalent functionality, it reduces source code size as well. Getting this benefit sometimes requires a bit more overhead than C (i.e. declaring classes, etc.) but in the long run it is a real win. Not to mention the outstanding standard library which saves hours of drudgery.

Of course OO is not needed in every project or even many of them. That is why C++ is so nice to use. We pick the tool that appropriate to the task out of the many provided by the language. Once can write perfectly good advanced C++ code without using inheritence or polymorphism. In fact the cutting edge today seems to involve heavy use of generic programming and metprogramming -- inheritence is only used when necessary.

--

Re:C++?

[elflord]

I want to learn to program in C++ very much, but I'm stuck with a very hard to understand Dietel and Dietel book that I had in a C++ class in college.

I learned from that and it served me well, but you're only going to get so far with just one book.

see my reading list for a bunch of good titles on C++.

I wanted to pick up tihngs on my own, but I don't know where to go from. I'd love to learn to program with sockets, even maybe some X apps or somtehing of the similar, but I don't see that much documentation

Then perhaps you are not looking at the right documentation. Let me explain -- the C++ programming language does not support sockets or X or Qt or anything else. These are third party libraries. In particular, books about C++ don't explain how to do GUI or systems programming.

What you possibly need is not more books on the C++ programming language, but rather, books on UNIX programming. For example, one of my favourites here is "beginning Linux programming" by Stones/Matthew.

I'm also going to plug my webpage which has some interesting bits and pieces.

HTH

Re:C++?

[elflord]

A big part of the reason none of the C++ books you've found talk about socket programming is there is no C++ socket API. There is a fairly standard C socket API (standard across UNIX systems, anyway)

Not really, there isn't a standard socket API for C or C++, strictly speaking, in the sense that sockets are not part of either language. Because of this, C++/C programming books are not going to teach him anything useful about sockets, he really needs a UNIX programming book.

Of course, the assertion that BSD sockets are supported on most platforms is "mostly" correct.

As for learning OO in java, one of the messy things about java is that it makes proceedural programming very awkward. I also found its object model confusing when I started out. For example, why is main static (as opposed to, say, eiffel, where you run the program by instantiating an application ?) Those words "public static void main are a tad intimidating, especially when you're reading a book that doesn't even explain what these mean until 500pages or so in.

Re:C++?

[Syberghost]

What idiot modded the parent post as "Troll?"

Don't worry about it, said idiot has lost shit-tons of karma.

-

Re:C++?

[Delphis]

In summary, everybody learns things a little differently. If you don't already know any programming languages, it might be easier for you to learn something that doesn't use Object Oriented concepts -- such as BASIC or Pascal.

I heartily agree. It's much more important to first gain an understanding of 'how to program' rather than 'what language to learn'. Once you the general ideas behind programming (and hopefully learning good programming practices along the way), then you can program in anything - it tends to be just a case of picking up the language reference book and having a go.

I started on BASIC when I was about 10 on a Dragon32. Enjoyed that a lot and then in my first year of college I taught myself C with the aid of a reference book.

I've done a reasonable amount of VB, and it is easy to learn (IMHO), but I'm wondering if that was because I was already familiar with programming or not. I go back and forth on thinking whether to recommend it to beginners or not. I agree that clouding things with OO can frustrate matters whatever language you're in so it's important to get the 'basics' (no pun intended) down first before moving on to other concepts. I guess you could do that in VB, you can still write functions etc, just tuck them in a button.click procedure or whatever and go from there.

To me, procedural languages work better, but that might be just that they work better for my way of thinking. I tend to find I enjoy C more than VB.

Of course you could always try learning PHP :D .. it's very C like in its syntax, plus you don't have to worry about compiling and things crashing on you, so you could pick up a few simplistic C functions (helloworld.php ?) without too much hassle. Then maybe try doing it in C. Start small and work up.

--
Delphis

Re:C++?

[Lumpy]

Ok that is a bit of a clairification I needed. every one of my CS professors have tried ramming the OO idea as it is absolutely needed. and I have every time proved them wrong. (I was a professors worst nightmare... often taking the opposite stance just because it existed)

Now if one of them would have ever explained it that way or in a similar manner I probably would have been more receptive.

Also... jamming my head inside tiny processors all day starts to create tunnelvision at times :-)

I do admit that I use OO at times (espically in perl scripts that deal with web interfaces) but I have always been the minimalist, probably why I enjoy embedded systems so much.

Re:C++?

[Lumpy]

I reccomend buying ritchie's book on learning C (What better way to learn C than from the creator)
As for C++, I am unsure.. I program in C because of many factors. embedded systems... There are no embedded libs for C++ Yet. I am sure they are on their way, Palm Pilot- C only right now,PIC programming..., etc...

I probably should learn C++ and OO programming one of these days, but remember this...

OO is not needed to do magnificient things. Look at the Linux and other kernels.. Look at the many other applications that are not C++. Granted you can do OO programming In plain C.

I have always viewed OO programming as a style not as something very important. Everything you can do with your OO styles I am sure can be done without it.

If I'm wrong.... Flame away. Otherwise just mercilessy point out the flaws.

Re:C++?

[fusiongyro]

I hate to be a walking endorsement, but there are a few tips I've come to w/ respect to programming.

1. Object orientation is necessary and natural. Beginners are often left wondering how the algorithm has anything to do with the "stuff" they're programming. Oversimplified lessons work to teach the bad habits of procedural programming ("If it works..."), often without fully explaining how results are arrived at, and leave most learners wanting.
2. C++ is not the best object-oriented language for beginners. I heartily recommend Python as an introductory language. It has the perfect combination of huge library and simple language. About the only way to muddy the water is to use functional programming constructs. Beginners don't need the complexity of C++.
3. After you learn Python, start in on Eiffel. I'm currently learning the principles of Eiffel, which are deep and worthy of application in the rest of the world, but it just goes to show you where complexity can get in your way. Eiffel is simple compared to C++: no "friend", no "inline", no "namespace", no "typedef", no "struct". But Eiffel works by removing complexities in the language. Find me a fully-implemented Standard C++ library. There are none. But there's four or five fully implemented Eiffel libraries, and only one Python library at all (which is massive). No beginner should have to worry about platform-dependance, library "issues" or bizarre compiler messages. C++ suffers from all of these faults. Eiffel and Python get out of the way, letting the programmer get right down to the problem and solve it. C++ throws in every possible language feature, putting it in competition with nothing but Ada. And while that does make a very powerful programming language, it also makes it unnecessarily complex for the learner.
4. No one should have to implement a basic container before knowing how to use it. This is a classic failing, mainly of C, that CS courses teach linked-lists and other datatype construction before the student understands the concept or how to use it. This is a big win for OOP in general, not having to re-implement the wheel constantly, yet colleges across the country feel that every student should understand such a "useful" concept in implementation terms first.
   

Daniel

Re:C++?

[Zapper]

For those of you struggling with OO concepts (I starting to get it but brain hurts) try Sun's Java Tutorial: Object-Oriented Programming Concepts .

seeya.

Re:C++?

[aunchaki]

While I do believe that some people are not cut out for programming, anyone who's as persistent as you seem to have been should get there eventaully.

I tried again and again over the years to "get it" without much success. Eventually, I started getting results with Perl CGI.

I think the threshhold for programming can be very steep in some places (er... C++) and people can't even take baby steps. I found that to be the case for C programming in a Windows environment. I needed to get to the command line (whew!) and start simpler to get over the first hurdles. After that, no problem!

I like the O'Reilly "chipmunk" book: Practical C++ Programming, but I'll confess it didn't turn me into a C++ guy.

Good Luck! Don't give up.

Re:C++?

[bero-rh]

If you can do C already, try taking a look at http://www.icce.rug.nl/docs/cplusplus/

It's a pretty good introduction to C++ for people who are already familiar with basic C.

Re:C++?

[slamb]

Not really, there isn't a standard socket API for C or C++, strictly speaking, in the sense that sockets are not part of either language. Because of this, C++/C programming books are not going to teach him anything useful about sockets, he really needs a UNIX programming book.

Hmm, you're right. It's easy for me to forget that just because the C stuff is common on many platforms, it isn't going to be in the same book. There is a lot more stuff about it than C++, but not as integrated as Java.

But that doesn't really take away from the point of my post - that API-wise, Java is much easier. This is true for Perl and Python as well, but Perl can teach some really bad habits and Python isn't as widely spoken.

As for learning OO in java, one of the messy things about java is that it makes proceedural programming very awkward. I also found its object model confusing when I started out. For example, why is main static (as opposed to, say, eiffel, where you run the program by instantiating an application ?) Those words "public static void main are a tad intimidating, especially when you're reading a book that doesn't even explain what these mean until 500pages or so in.

True as well. But I still think Java would be an easier language to learn for this AC since it sounds like he would have a much easier time if he could get into some practical code and have one book that would cover a pretty broad range of API stuff.

Re:C++?

[slamb]

I'd love to learn to program with sockets, even maybe some X apps or somtehing of the similar, but I don't see that much documentation (well, that's easy to understand and findable) anywhere. [...] I've done this multiple time over the years, but I guess I might not be cut out for programinng

It's not you. You're absolutely right that there isn't much C++ documentation out there that is easy to understand.

A big part of the reason none of the C++ books you've found talk about socket programming is there is no C++ socket API. There is a fairly standard C socket API (standard across UNIX systems, anyway) and all C code is callable from C++. So, theoretically there is everything you need to do socket programming, it just isn't as easy as you might like. A lot of people have tried to solve this by creating wrapper classes (a class that is intended to repackage existing code into an easier form) but for the most part, each do a fairly subset of what any program needs to do and don't fit together with each other very well.

There are a few exceptions. TrollTech has done a good job of creating a cross-platform C++ API with Qt. And KDE builds on that further. So if seeing practical examples would help you out, maybe you should jump right in to something more specific to Qt and KDE. I don't think there's much stuff out there introducing Qt and KDE to C++ beginners though, so you will still need to refer to another C++ book.

Another alternative would be to learn OO stuff with Java. Java has been criticized a lot for its speed, but I don't remember anyone who says it doesn't have a good API. There are lots and lots of existing classes to help you write useful code right away. It is all well-documented...plenty of books on Java, and they all describe the API as well as the language, unlike most C++ books. Sun has a really nice tool, javadoc for creating reference documentation as well. Just about any Java package, whether one from Sun or elsewhere, will have nice documentation in the same format. And there are tutorial's available on Sun's website.

There are a few problems with learning Java first. The one that comes to mind right now is garbage collection. This is a nice feature because you don't have to write specific code to handle memory deallocation. This is a terrible feature for a learning language because you don't have to know anything about memory deallocation. Some people who learn Java first write some pretty terrible code memory-wise when they switch to C++, and this is why. Still, in your case I'd say that learning Java is probably the best option.

Re:C++?

[Grab]

C++ for embedded systems is on its way. Whether this is a good thing or not depends on your POV, and on what application you're developing for.

C is a stable language. It is reasonably well-defined, and where it is not well-defined, there are numerous books out there to tell you what to steer clear of (bit-fields, precedence problems etc), so you can produce code which consistently works how you expected it to. It is a relatively simple language in terms of the number of language features available, which helps since the number of possible interactions between features will increase exponentially with the number of features available, and it's quite easy for someone to pick up the language quickly. Finally, it's possible to code your programs to maximise code-space and/or RAM-space efficiency.

Then we come to C++. According to Les Hatton who used to serve on the C++ committee, there are so many undefined corners of the language that the committee literally GAVE UP trying to record them all, after they'd filled more undocumented features in 5 years than C had recorded in its entire lifespan! There are many new features over C, which radically increases the complexity of the language. C++ maps poorly onto the actual assembly language of the processor (which is why OO is such a radical diversion from "traditional" programming languages) and therefore the code produced in C++ for any program with more than one object will ALWAYS be slower than equivalent C code. Finally, it's not possible to write C++ code to maximise code-space or RAM-space efficiency, since you are entirely at the mercy of the compiler writer - the best you can do is select from a coarse menu and hope the compiler does it properly.

This is not to say that C is a good language to program in, or that C++ is inherently broken. What I am saying is that there is NO WAY to be sure that the executable you produce in C++ will work correctly - the subset of features which are 100% reliable for C++ (or the techniques required to make these features 100% reliable) is not yet known. For a safety-related or safety-critical system, therefore, C++ is a poor choice. MISRA (Motor Industry Safety and Reliability Association, IIRC) has produced guidelines for software development and for developing in particular languages, and the recommendation so far is that C++ not be used due to its immaturity. If anything went wrong with your embedded controller and someone died, the very fact that you were using C++ would therefore imply that you were not following best practice for development, therefore not exercising due diligence - punitive damages, fines and jail-time result from this!

As for PICs and other smaller processors, there often isn't the RAM available to allow any high-level language to be used. Even when a HLL can be used, C++ is often too memory-hungry to be applicable (the most RAM I've ever seen on a car engine controller is a few hundred K), and unlike GUIs, speed of execution is a major issue on most embedded systems.

Some embedded systems (mobile phones, etc) do use C++, but mainly for user interface work where speed of response is not an issue. Where there's real processing to be done, it'll always be done in C, or if there's a real crisis, then in assembler. I can't ever see this changing - if you make the executable more inefficient, you need a faster processor, and that always costs more. Build a few million of these, and even a few cents difference mounts up!

Grab.

Re:C++?

[jeremyp]

Here's how I did it. First I learned C. Actually, I did that before C++ was invented. Then I learned about object oriented programming through a variety of means. Note that you can apply object oriented techniques to virtually any computer language and you'll probably end up with a better program than if you don't.

Finally, I learned C++. But this was not an instantaneous thing. Basically, I found a book on programming with Borland C++ and read the thing from start to finish (doing the exercises as I went along). I wasn't too bothered about understanding everything - C++ is a big and complicated language - I just made sure I had a good overview of what was possible. Then I started using bits of C++ in my coding. I started with the obviously useful bit - classes. Every now and then I'd come across a problem that would make me think "I remember reading something about feature X in C++ that would help me here." Then I'd go back to the book (or read the relevant reference docs) to find out how to do it. I'd say that my coding style has evolved from C to C++ over a period of time (about 5 years). You can look at some of my early C++ code and say it probably isn't optimal C++, but it would be good C (IMHO :-))with some C++ features.

Programming sockets and X should be regarded as separate exercises. Get a good grounding in C or C++ and then tackle sockets. The Unix Network Programming book by Richard Stevens is a good way to learn about sockets. His examples are given in C, but are easily translatable to any other language (with access to the Berkeley Socket API) by a programmer proficient in that language (and with some knowledge of C).

Re:C++?

[partingshot]

imho...

C++ isn't easy to understand for a beginner.
The books listed below are the best at explaining it.

This book is online:

Thinking in C++



You'll have to pay for these:

Accelerated C++

C++ Primer

Re:C++?

[sumengen]

For java, I suggest Bruce Eckel's "Thinking in Java".

And, I think there is also java bindings for QT.

Re:C++?

[swoopx]

Another good book for socket programming in linux is "The pocket guide to tcp/ip sockets". I just recently picked it up and it seems very good so far. I'm starting to realize, the smaller the book the better.

Re:C++?

[su steve]

IMHO there are better ways to start programming than with C++. A type checked language such as Pascal (now Kylix), which enforces rules at compile time and will save oh-so-many mistakes that can be made by the newbie.

"Don't run before you can walk" is probably the key to all of this. There are so many things you need to know about a language before you should even say 'socket' or 'X-app' (even if you can pronounce the hyphen).

Kernighan and Ritchie (who did the "C" thing in the first place) wrote a brilliant manual for C, which you would do well to familiarize yourself with, and it covers all the basics of types and program control you need. BEGIN WITH THE COMMAND LINE, it ain't that bad.

Re:C++?

[MSBob]

OK. The easy answer would be you need Lippmans "C++ Primer". It's a good book and very complete.

I'll play the devil's advocate though and say that you should also get Herb Schildt's "Teach yourself C++". Schildt has a reputation for publishing books that are incomplete and miss out on many more advanced topics BUT what he does choose to explain in his writing he does it very well. I know people who read his book and shortly afterwards moved on to Lippman. I think it's not a bad route to take although some people run screaming horror on the sound of Schildt's name.

Re:C++?

[Persistence]

You might want to look at "C++ Primer Plus" by Stephen Prata (and its various translations to other languages). It's the best book I've found by far for C++, both for newbies and as a reference. Also, you should know that it's important to understand the language itself before trying to proceed with things like sockets, graphical user interfaces, etc. The best way is probably to start with text based command line applications until you are fully comfortable with the C++ language.

One of the best and most easy to understand guides to socket programming is Beej's Guide To Network Programming. Have a look at that, I think you will find it very useful.

Re:C++?

[d3l3t3_m3]

First: C++ isn't a simple language! It takes time (between a year or two...) to understand all the caracteristics that makes C++ the language it is! The Deitel & Deitel book isn't the greatest C++ book on the market but it's a good starting point. (Actually I learned C++ with this book and then moved to Bjarne's book right after!). remember: a year or two forget learn C++ in 21 days beuark! "The software engineer must learn to mimic nature,...,from the most elementary to the most complex, always searches for a stable balance and minimal energy consumption;..." -Pierre-Alain Muller

Re:C++?

[GreyPoopon]

IMHO, it's far better to learn OOA/OOD first, in a manner independent of language.

Absolutely agreed. However, I learned the OO concepts independent of the language, but still had trouble wrapping my brain around it when I started learning a language. It was really odd the way I suddenly "got it." It was like my brain decided to stop fighting and give in. (Resistance was futile)

Another downside is that the features, limitations, and mechanics of the language you choose will color your perception of OO.

Definitely very very true.

GreyPoopon
--

Re:C++?

[GreyPoopon]

What idiot modded the parent post as "Troll?" This is a perfectly legitimate question. It's also something that many people struggle with.

I'll offer what little I can. I was a C programmer for years. When I left college, there was no C++. Object Oriented languages were just starting to form. Unfortunately, I didn't really learn any of them in school. I wasn't incredibly interested in C++, but I WAS interested in Java. Although I had studied some Object Oriented concepts in school, applying them with a programming language is a completely different ball of wax. I started trying to learn Java, and was very frustrated. My brain just "didn't get it." I think I had actually been hurt by programming in "C" all of those years.

Oddly enough, it was Visual Basic that brought me around. (I can almost hear the gasps from readers). While Visual Basic falls far short of being a true object oriented language, it does employ some of the concepts. At work, I was forced to implement a project in VB because nobody there knew anything else. I first wrote the program by ignoring object oriented concepts. Then, when I was trying to make some of the functions I wrote more reusable for others, the whole object oriented concept suddenly snapped into my brain. I completed the VB program (using what OO concepts VB supports), and was anxious to try my hand at learning Java again. Suddenly, concepts that were foreign to me made sense. It was much easier to learn than before.

In summary, everybody learns things a little differently. If you don't already know any programming languages, it might be easier for you to learn something that doesn't use Object Oriented concepts -- such as BASIC or Pascal. These languages are often more restrictive, but are usually good training tools. The only caution is that if you get used to programming without objects, you may have the same problem I did in starting to use them.

GreyPoopon
--

Re:C++?

[Genoaschild]

Don't buy or use "Learn XXX in 21 days" books. They kind of suck. My advise to you is learn the basic libraries. I would start with "stdio.h" "stdlib.h" and "string.h". Learn basic commands like printf, scanf, fgets, strcpy, strncat, etc. These you will have to learn out of a book, no way else except sitting through 50 min. boring lectures. After that, learn about files. FILE *inputfile. inputfile=fopen(string_name, "rb+"); Then learn some basic commands to use with them including fprintf, fscanf, and my favorite fgets. After you learn files, learn about pointers. Pointers are very confusing at first. You'll pull your hair-out trying to figure out why something didn't work until truely understand them. Flip to this chapter third. Their are many many samples out their and you can't truely know C unless you understand and can use pointers. If you don't want pointers, use JAVA, but using java won't teach you the lower level principles about C. After pointers, learn an API. I recommend QT. Very easy to use, cross-platform, and is free. Good luck. You'll need it.
----

Re:C++?

[BrandenTimm]

Sams "Learn C++" books are about as simplified as you're going to find it. The only advice that I can offer as far as documentation or understanding the concepts is the OSDN library that comes with Microsoft Visual suites (Microsoft Visual C++ or Visual Studio). They are pricey, but they come with 4 cd's of documentation on anything you could ever want to know, including sockets. C++ is not a great language for a first timer either...why not try basic or something along those lines first? These are much more newbie-friendly and in most cases you don't have to worry about compiling or linking errors...it's a line by line interpreter. Good luck.

GLADE !

[Anonymous Coward]

If you want to build visually, using GTK (and on the fly rebuild your entire collection of GTK libs, giving the Gimp a completely new look), use Glade ! - it generates C, C++, ada, eiffel or perl; it ports to Windblows and it gives the programming newbie a headstart, in that it doesn't require knowledge about widget-construction or placement. The event-code you must go create yourself, though. But then there's perl (which can be easy to the eye if it wants to be) Get it at http://glade.pn.org

Re:GLADE !

[wirefarm]

I just took another look at Glade. (It came with this distro of Linux...)
Well, it looks pretty nice and I'm sure people like it and find it useful and all, but...
Where is the help file?
Why doesn't it have a sample project available?
How am I supposed to *start* using this thing?
You say it does Perl - I'd love to write my perl code in a really snappy IDE that has a code folding, chromatic editor that offers command completion, the way Kylix does. Until I find one that doesn't crash too often, I'll keep doing it in vi.
Back when I was learning to program, (
on VB and Access, yeah, go ahead, snicker...) I found that the VB IDE, which is the absolute best IDE I have seen, (no matter how bad the language is,) gave you an opportunity to actually learn more about the language while you were writing the code. If you're using an object, as soon as you type its name, you get an unobtrusive drop-down of all of the properties and methods for that object.
Even before it had that, there was a useful helpfile (with examples) that was always just one "F1" away.

If you want to see what it takes to get developers to use an IDE, go read "Dynamics of Software Development" by Jim McCarthy. (Microsoft Press. ISBN 1-55615-823-8)
Jim was in charge of getting Visual C++ 1.0 out the door, back in the days when they were a far second to Borland.
He goes into a lot of the fears that developers feel when facing a new technology and how to overcome them.
Since the world is getting motivated to move to Linux, the old-school Linuxers had better be prepared to perform some triage for the people coming to Linux from Windows - It's not just about getting a good word processor for people to use, it's about giving developers the capability of writing in-house apps for data entry into the company database. Something with a learning curve comparable to VB. Something your typical mid-sized company developer can pick up in a few weekends, because as much as he might love the idea of using Linux, without a great development IDE, it's just not a viable platform for any business that I know of.
If glade can't get helpfiles together fast enough, how about a bunch of tutorial-style apps?
"Hello, World"; "Hello, Database" kind of stuff - It didn't take me many of those to become pretty useful in perl...
Am I completely alone in feeling like this?

Just a thought...
Jim in Tokyo

MMDC Mobile Media

kylix

[Anonymous Coward]

Already posted something like this over on newsforge, but we'll see what the slashdotters make of it.

The article completely forgot about Kylix. Beautful language, easy to learn and a true RAD environment. Plus for beginners it teaches you good programming habits like declaring variables at the start of a function or procedure, which makes for clearer code.

Drag and drop visual components make it easy for a beginner to quickly get a visual application up and running.

People joke about bring Visual Basic to the gnu/linux desktop, but Kylix will be great for all those beginner programmers who don't need or want the complexity of c/c++, who just want to get a quick application up and running. It has all of the ease of use of VB with none of the bitter aftertaste. And Borland will be making a free version available for download.

I think that will be really sweet.

And the best part of all will be that applications will be easily ported back and forth between gnu/linux and windows. Easily being a relative term of course, but if you only use the kylix/delphi native functions instead of direct api calls the code should be easily ported.

Re:kylix

[Sloppy]

The language is indeed good, but the "drag and drop visual components" stuff is something that I just can't recommend to beginners. It hides too much. I have met many people who learned using super-high-level-tools like this, and there's the damnedest gaps in their understanding of computers. These are long-time professionals, and it's really sad to find out their experience is so narrow.

I realize you have to start somewhere and there's gotta be at least some black boxes that they don't initially understand, but IMHO GUI components are a bad candidate. Same for databases, in my opinion.

Trivial details and I/O can be hidden from beginners. Learning how to deal with data structures, and strange-looking-at-first contructs like event loops, should not.

---

Re:kylix

[tcopeland]

Declaring variables at the start of a function is NOT a good programming practice. It is, however, a good way to ensure that you forget to delete them once you remove the associated code - and then you have a wasted variable declaration.

Besides, functions/methods should be short enough so that you don't have to have a "variables used" block at the top.

Yours,

Tom

Re:kylix

[NavySpy]

>>Why lock your product to a proprietary compiler and a proprietary language? Why? Because Kylix increases your productivity by orders of magnitude, maybe?

Re:kylix

[xjimhb]

I haven't tried Kylix yet, but I have used Delphi extensively and it's GREAT! Last time I suggested Pascal as a good language for beginners I got modded down as a Troll, but I don't care - it IS one of the best to learn on. And as far as OO goes, it's very good for doing "visual" stuff - the user interface - but to get any real work done you do need to learn (and learn well) the underlying principles of programming with ifs and loops and all those other horrible things the OO people seem to want to avoid.

And by the way, I have been around a long time (when I started in computers, they taught us assembler because that and Fortran was all there was!) and I have programmed in a large number of languages, so I have some perspective on this.

Re:kylix

[mazor]

Declaring variables at the start of a function is NOT a good programming practice. It is, however, a good way to ensure that you forget to delete them once you remove the associated code - and then you have a wasted variable declaration.

Oh please. As if any self-respecting optimizing compiler (such as Kylix) isn't going to strip out unused variables?

We're in the 21st century here. Try to keep up.

--mazor

Good Article; Don't forget the Less/Non Techs

[Kojo]

Yes, this is the same comment I posted at NewsForge. I have been absorbed by the sinister OSDN keiretsu!!

First, let me say I really enjoyed this article (Good Job Tina!). I'm starting a CS degree in the fall (I'm changing careers), so I've been looking for a 'guide' to contributing to Free Software and Open Source projects when I become more skilled. I'll be learning C programming in Unix as part of my curriculum (duh), so this article was very helpful to me. Lots of useful pointers for the chyrsalic (is that a word?) CS major wanting to give back.

My only concern with the article is that it seems to suggest that you can't make contributions without being a "hard-core" programmer. This seems to contradict much of what I've heard from other Free and Open Source projects. They generally take the position that if you can write a decent bug report (what happened and under what circumstances, not 'it broke!'), or create documentation, you can be helpful too by using the software and doing the above.

True, this may not make you a "developer" in the strictest sense, but it could be the starting point for people who don't want to or cant' "learn C or C++". Also, while I realize C/C++ are the core languages for GNOME/KDE, I've also seen many different language bindings (Python, Perl,etc) for both projects. As these languages may already be known to casual programmers or are easier to learn for first-timers, I don't think they should be overlooked.

Finally, although this article focuses on DESKTOP development, I'm sure there are quite a few things not related to the two dominant desktops that could use some help as well. I'm not sure if Tina G. has written another article dealing with that, but it would also be helpful.

Getting people involved in helping develop the desktop may be the best way to bring new users to GNU/Linux. Newer users tend to want to use a desktop instead of a CLI, and showing them relatively easy ways to 'scratch their own itch', or at least be involved in getting someone else to scratch it (an option not truly available under proprietary OS's) brings home the advantages of Free and Open Source software. My perception (I have no data to back this up) is that most people, especially newer/less computer literate users, don't see the point of having access to the source code or the freedom to change a program. They're used to the proprietary software model. Drawing more people into the various phases of development (including bug reports and docs) could raise the level of awareness. Imagine the pride of someone who considers themselves "non-technical" who sees a bug they reported get fixed or their documentation being used. "I am 31337 4ax0r!!"
:-)

Another good article by Tina G.

Re:Good Article; Don't forget the Less/Non Techs

[plcurechax]

My only concern with the article is that it seems to suggest that you can't make contributions without being a "hard-core" programmer. This seems to contradict much of what I've heard from other Free and Open Source projects. They generally take the position that if you can write a decent bug report (what happened and under what circumstances, not 'it broke!'), or create documentation, you can be helpful too by using the software and doing the above.

Another good way to get involved in a project is testing. If you some limited programming or scripting skills you can write unit tests, and test scripts to help find bugs. In the process you'll help the project, learn more about the project, and hopefully improve your own skills. Adding test routines that detect old bugs can help to prevent them from creeping back into the code, and help look for similar bugs elsewhere.

My first programming job was doing maintance on a large system, and it taught me some key concepts that young and inexperienced programmers don't always take to heart, myself included. I learnt the benefit of defensive programming, of useful code comments, of writing proper documentation and of testing.

Interested people might find this article about getting into QA work from Software Development magazine useful.

like a Monty Python skit...

[bobalu]

This reminds me of the skit where they say "And today we're going to learn how to cure all the world's diseases and build a suspension bridge"!

"First, you do briliantly in medical school then invent a vaccine for everything!

To make the bridge, string a few miles of steel cables across the North Atlantic and drive over it!"

Learn C, then C++. (Notice the name.)

perl not as bad as some might think for beginners

[VAXGeek]

Perl is actually a very logical language to use to teach beginners. Start out gradual, like:

$a = "hello world\n";
print "$a";

From there, even the casual beginner can progress to (code excerpt taken from slashcode):

($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&}%p;$_=$d[$q];sleep rand(2)if/\S/;print

As you can see, the syntax is non-threatning even to the most novice of programmers and is very intuitive.


------------
a funny comment: 1 karma
an insightful comment: 1 karma
a good old-fashioned flame: priceless

Re:Whitespace is not syntax

[armb]

> I'll bet the first language without line numbers raised a lot of eyebrows too.

Not for having line numbers. Eyebrows were raised about the whole idea of wasting computer time in compilation when people could write machine code by hand. (Still earlier there were objections to wasting processor time on conversion to decimal output when people could learn to read hex).

FORTRAN had no line numbers when it first appeared. Nor did Algol. Nor COBOL.

--

It does _not_ start out "learn c++"

[khuber]

Did michael read the article?

She said learn C or C++, depending on whether
you want to do Gnome or KDE programming. I think
that is sound advice. Yes, there are bindings
for other languages but I think you need to
be able to comprehend the library source at
least at some level.

But she also emphasizes finding a project you
like, reading documentation, starting off with
simple examples and changes.

I think encouraging people to go for it if
they're interested is a good idea. Becoming
a great programmer is hard, but you have to
start somewhere and you can still contribute
even if you're not a master.

-Kevin

Re:It does _not_ start out "learn c++"

[Delphis]

Did michael read the article?

Of course he didn't.. do you think /. editors read the shit they waffle about? Especially Michael it seems.

--
Delphis

Learn to program in a nicer language first

[Goonie]

Learning to program in C++ is like trying to learn to drive in a NASCAR. You can do it, but the language has all these complex doo-dads tacked on to a pretty old and ugly base. Sure, experts can drive C++ pretty damn well - some of them even think it's the best thing since sliced bread (as you might gather, I don't - but for some tasks it's not bad). For somebody who is struggling, picking a nicer language can let you get your head around *programming* rather than the arcana of the C++ specification and the particular wrinkles of the various implementations out there.

There are a variety of languages that people recommend as a first language. My old university used Haskell. It was very effective in a university situation, but because it's kind of obscure you might find it hard to get anyone to help you with it. A lot of people recommend either Python or Java - Python is a nice language, and probably a good choice. Java is also nice, and also apparently in demand by employers, but while much cleaner than C++ has a fair bit of required "boilerplate code" which is required to write anything in the language but won't make any sense to you initially.

Perl is a wonderful language for non-programmers. It's very easy to get things to work in Perl. However, Perl makes it particularly easy to write messy code. If you're serious about programming, it's probably not a great language to start with.

Oh, and as a rule, avoid any book that ends in "for {idiots, dummies, complete fools}", or "in {time X}" - basically, if you're a dummy, you're not going to able to program effectively anyway, and it's not something you can be proficient in quickly. Once you pick your language, go see if there is a USENET FAQ on the language and see what's recommended. For instance, for C++, some commonly recommended books are The C++ Primer, by Lippman and Lajoie, or Stroustrup's The C++ Programming Language (written by the original designer of C++ - a decent book but probably a little dense for the newbie).

Go you big red fire engine!

Re:Learn to program in a nicer language first

[ShadeARG]

The previous post is NOT a troll.

I completely agree with it. What is psuedo-code? Code that describes the programming process in simple terms. Most psuedo-code is modeled after BASIC, so wouldn't it make the most sense to learn that way? If nothing else, a new programmer could lay out the basis of what a program is going to accomplish without taking into account the ramifications of a more complex syntax and data (memory) management.

I learned how to program with DOS batch files because of the simplicity of a file holding a series of commands. After I found that it didn't offer the power I needed, I moved on to QBASIC with ease. Constantly reviewing my syntax, It allowed me to keep better track of files and gave me a simple interface to do my own graphical programming, and I could get help on just about any situation by pressing F1. After I grew too big for QBASIC, I moved onto QuickBASIC. This allowed expansion with seperate source files and larger source sizes, and enabled me to create my own independant executables with ease so I could run them on any DOS system.

Now I find myself programming in a variety of other languages (Perl, C, C++, etc.) and I don't even think about the difficulties associated with them. I have been using Linux solid for a couple of years now, and I found the transistion to be easier than I could have ever imagined.

The moral of this story is to learn what you can, but don't bite off more than you can chew. If you learn the basic fundamentals of programming, you can take it with you anywhere.

Re:Whitespace is not syntax

[scrytch]

> I'm guessing you never even made a serious try to learn it. Your loss.

Yeah, you're guessing. I tolerated the whitespace thing til I had to edit infoseek pages in vi that generated javascript. True, half the problems came from infoseek's begin/end syntax for embedded python, but it was always indent, indent, indent that had me editing and re-editing the same blocks over and over. Someone had used a tab somewhere, and I was busy hunting it down. For a language that puports to promote maintainability between multiple programmers, it certainly isn't very tolerant of differing whitespace conventions. Code shouldn't outright *break* because someone broke a coding standard of style.

If I ever get my motivation back, maybe I'll resurrect ni (stackless python, using foo/endfoo syntax constructs, my favorite form of bracketing). Or maybe perl6 will still be all I need.

Even LambdaMOO figured out the concept of using a pretty printer instead of requiring the programmer to be one.


--

Re:Learning C++?

[elflord]

The technical publishing world has become very corrupt. Publishers know that people find it difficult to evaluate a book while they are in the bookstore. So, a publisher who provides a poor quality book with big promises on the cover will sell books.

I'd have to say you're right on the money here. Most C++ books are written by incompetent authors, who often commit various transgressions varying from failing to explain (or even demonstrate that they understand) polymorphism, to confusing Windows specific functions with the standard library.

The only credible publisher for C++ books is Addison-Wesley, nearly all titles from other publishers are junk (with a couple of exceptions from Prentice-Hall, who also publish a lot of the better C books.)

-- Donovan

Re:Start programming with Open Source project?

[muggs]

You foget Newton?!?

Re:Start programming with Open Source project?

[Sloppy]

One of the fastest/easiest ways to get started at learning programming, is to study and modify existing source code. Maybe the Unix-history-laden GNU system is indeed inappropriate because there's so many tools to learn, but the availability of source code that comes with Open Source, is very good for beginners.

---

Re:Visual Basic

[HiThere]

Speaking as one who has to use that *** thing at work:
The IDE is pretty good, but the help has gone backwards since the last version (that I have: Office 2000).
The language is terrible. I learn languages as a hobby. I love to learn languages. I've been using that thing for over two years, and its inconsistencies are still driving me mad. And that's not the worst. Working programs will suddenly die for no reason. Sometime the only way to fix them is to export them as text files, delete the original, and re-import the exported version. And that's just incrediblly stupid, but that's the fix I finally found, and it worked!

As one who has learned Fortran II, Fortran IV, Snobol, Cobol (well, not really), PL/1, C, Ada (partially), Python (partially), Ruby (partially), Eiffel (nearly), C++ (an old version), etc. Visual Basic is the worst language I've ever encountered. It's worse than Apple Basic for the Apple II. (Well, ok, I didn't try to do as much in that. But it was learnable.) It's worse than BSDC, with all of its inconsistent and undocumented deviations from K&R C (there wasn't any ANSI C).

Please, don't anyone inflict that language on Linux. Please!

Caution: Now approaching the (technological) singularity.

Re:How about people who already know C++

[DGolden]

AFAIK, Sun's JDK only segfaults on redhat 7, thanks to redhat's insistence on doing weird things to glibc. It's fine on on Mandrake 8 or Debian, as far as I can tell.

Re:Question for Micheal

[Black Parrot]

> As for Ada, I suppose you could, but I don't know of any such applications

Granted, there aren't many in the OSS world right now. One gnotable exception is the GNU Visual Debugger, which may well become a "standard" application once word about it gets out a bit more.

FWIW, it supposedly runs under Windows too.

--

Re:Whitespace is not syntax

[Black Parrot]

> Whitespace is not syntax.

Actually, it is iff the language spec defines it to be.

I'll bet the first language without line numbers raised a lot of eyebrows too.

Truth is, I came up with the "semantic whitespace" idea independently of Python, and quite a few years ago: When observing the flame wars about whether the { should go on the same line or on a new line, it occured to me that any marker that raised that kind of question probably wasn't needed at all. And the obvious solution was to simply rely on the indentation, since most people using {} languages also use indentation to show the intended semantics at a glance (as well they should).

I'm still thinking about writing preprocessors for my favorite languages, so I can show my semantic scoping by indentation and let the preprocessor translate it into bracketized syntax.


--

Re:Question for Micheal

[Black Parrot]

> I respect your opinion, but it doesn't really matter whether or not you like C++ if its is one of only two options for Linux desktop programming.

FYI, if you ease on over to gtk.org and look at their bindings page, you'll see that in addition to C there are 4 other languages with bindings described as "complete", plus a number of others that don't merit that flag yet.

--

Re:Not an article about developing for the desktop

[nd]

No kidding.

I read the article, and was ready to click "Next" for page 2, only to find that I had already read the entire thing. The article was advertised as a tutorial/howto document, yet I found "quotes" from developers in it (looked really out of place, almost as if a journalist was writing a technical tutorial rather than a competent teacher).

No mention of Glade, no mention of Kylix, or the Qt form designer. No mention of Python or Perl for beginners, and really nothing helpful at all.

Why exactly did Slashdot link this piece of crap?

Mentorship

[Ratface]

The steps in this article are not that far removed from learning any type of coding. Personally I'm more involved in the PHP/ASP scripting world, but most of the points regarding the learning process in this article would apply equally well. Swap Advogato for Evolt.org and talk about base server setups and scripting environments and you're there.

What I did find interesting, are the comments regarding mentoring. I've found that this role is normally taken by several people - it's pretty rare that someone will become an exclusive mentor to one person (imho). My experience is that often a small group of people (often within an online community) are seen as mentors to a fairly large group of people. Perhaps this is different in the more rarefied atmosphere of applications programming and Free Software / Open Source.

"Give the anarchist a cigarette"

Re:Start programming with Open Source project?

[kmcardle]

Am I the only one to think that an Open Source project is not the best way to learn programming?
I sure hope so. Most people learn to program by studying and then modifying the works of others. Open Source is ideal for this.

Programming is not only difficult, it requires a particular kind of thinking.
For the record, programming is not difficult. But you are very correct in that is does require a particular kind of thinking. Being able to think in the way needed for programming is difficult. It's like calculus -- taking the derivative is the easy part. The algebra leading up to that step is where most of the people make their mistakes. Anybody can program. Very few people can think properly.

I forget who said it, but it's something about "standing on the shoulders of giants". Without having other programs to read and learn from, very few programmers would be programmers today. Open Source is a great way to learn about programs and programming. It is far too daunting for the beginning programmer to maintain an Open Source program, but they can still learn from it. Even experienced programmers can still learn from Open Source. It's just good all around.

Re:Whitespace is not syntax

[jfunk]

That bothered me for about 30 seconds before I got over it and realised that the language is highly advanced.

Now I'm writing it professionally.

I'm guessing you never even made a serious try to learn it. Your loss.

This tutorial snapped my brain in programmer-mode!

[tarkin]

Many years ago I downloaded two tutorials about C and C++
I never actually used the C++ tutorial, but since the C tutorial is the best I've ever read the C++ one *must* be usefull to you! If you're still having problems with C, check that one out too!
Unfortunately, they aren't free anymore but you can download trial chapters. And *my* guess is that they'll convince you ;-)
I could always print them on a series of t-shirts for you ? ( DeCSS ? )
It touches subjects through the use of example program code ( shocking - isn't it ;), and at the end there are problems you've got to solve yourselves.
The C-tut. snapped my brain into programming mode, if you know what i mean.

And for those of you who think I'm affiliated with the owners/publishers, In CmdTaco's words :

"You're, wrong!!"

Komodo

[hawkestein]

I'd love to write my perl code in a really snappy IDE that has a code folding, chromatic editor that offers command completion, the way Kylix does.

Have you tried Komodo?
--

Fast VB...

[cr0sh]

In other words, you are not going to write something that is CPU intensive in VB like Quake or mr. mega encryption program.

Actually, it is possible - to a certain extent.

Both VB 5 and VB 6 are different from previous version of VB - the VB code is first translated into C++ code, then compiled and linked using the regular Visual C compilation tools. In fact, sometimes if you look into a larger project directory in VB - where the EXE is generated - you may find .o files lingering around. You can almost watch the compilation process happenning, if you point Explorer to the directory as you compile.

Unfortunately, it appears that the conversion to C++ is done in memory, and not to disk - so there is no way (at least that I know of currently) to get to the C++ code to tweak it further, prior to sending it on the the linker and compiler.

As far as speed is concerned - it is possible to get it - to an extent. My own personal example is a perspective correct texture mapping spinning cube engine - please don't email me about it - I don't support it anymore (nor do I use VB anymore at home - work is a different story, unfortunately - but I am doing more Java work here now anyway). But it does show what is possible.

Also, at one time (heck, it may be included in the ZIP) I had a custom scanline renderer (ie, the inner loop of the texture mapping routine) done as a C DLL that I called from the VB program, that dramatically speeded everything up - it was my intent to make the whole triangle texture rasterizer a C DLL, but I never got around to it.

So - it is possible to do fast things in VB - since the time I wrote that app - many other people have done even better things - many involving DirectX or custom routines. I have seen some amazing stuff - too bad it is M$ - I have since long ago moved on to Linux...

Worldcom - Generation Duh!

Re:Fast VB... Maybe

[cr0sh]

Actually, the limiting factor on the VB cube is the fact that I was only using the GDI SDK calls for everything - the bottleneck is basically the low-level 2D Win32 SDK GDI interface. I am certain that it is more than possible to do great stuff in VB if one goes the DirectX route - DirectX and the video card then would be doing all the heavy lifting.

But hey, that is the way it should be - why should someone have to learn arcane graphics secrets to create a game - they should be able to concentrate on the design and gameplay of the game, and not the underlying low-level stuff. Considering that hardly anyone does low-level graphics engines anymore (what I mean by this is creating engines translating x/y/z coordinates in proper 2D screen coords and doing lighting, etc) - most concentrate on the higher level stuff. That doesn't mean one shouldn't learn the low-level stuff - it is useful knowledge. Just don't expect to use it a lot (though there are a lot of instances of it being useful, just to understand what DirectX or OpenGL are doing, for example).

You are right about 486's and C - I remember several good cube demos done on such equipment. And most certainly, things are going on in the background of that VB program - at minimum, it has to keep checking for messages from the OS, just for the event driven stuff.

So, I am not saying VB is the be-all/end-all of things. But it can be damn good at some things (and actually, if you drop the texture mapping, and rely on straight GDI drawing primitives - line, filled poly, etc - you can get mongo speed - I know of one dude, Jerry Chen, who created an awesome 3D library called Dex3D - I may have a link off the site - ultra-high speed with that). It really excells in the RAD area for business apps - which is something Linux needs.

Worldcom - Generation Duh!

Fixed link (Karma whore :P)

[Giant Robot]

For some reason the link didn't link to the article!
Try this one:
here
(http://www.newsforge.com/article.pl?sid=01/07/11/ 185221&mode=thread)
for goat phoebia

Re:like a Monty Python skit...

[be-fan]

Actually, in the beginning, C++ *is* C. Until you get into the OO stuff, they are mostly the same. This is generally the way C++ is taught in courses anyway. Besides, learning C first is a little dumb, since the C syntax of C++ is a little nicer.

Re:Ease of Use

[be-fan]

Its not a C problem, it is a Linux problem. Linux isn't an OS, and thus must use separate libraries to provide services that are normally standard in Win32. For example, GUI internationalization is a standard part of Win32, but on Linux, it comes in the form of Pango and other libraries. That's where you dependencies come from. Even in Algol, those dependencies would still be there.

Re:Visual Basic

[be-fan]

I`m not suggesting write kernals or games or drivers in vb. But for either knocking up demos, or for writing apps where speed isnt too important (stuff like Outlook, or a front end for anything, really), why bother with C/C++? Its just a waste of time.
>>>>>>>>>>
He he. That explains why Outlook is so glacially slow ;)

Re:Best language to write database program?

[joib]

Definitely use a RDBMS as backend. The problems a database solves for you (eg. concurrency, transactions, querying) are among the more difficult tasks in computer science.. as for free databases, my favourite is PostgreSQL. It rules. As for implementation language, a high level language will save you lots of time. Consider python. Java is also quite nice, with lots of documentation. As a final note, instead of reinventing the wheel, check out www.freepm.org and www.freemed.org and the Linux Medicine HOWTO at http://mobilix.org/Medicine-HOWTO.html

Delphi and OO programming

[KenSeymour]

I beg to differ about OO being only usefull for GUI programming.
At my last job, we impelemnted a factory automation system with a fairly large inheritance hierarchy.
The main areas of the heirarchy were business classes (thinks like equipment, lots), process classes and message classes.
The project was successful and ran in 4 plants in four seperate countries.

The classes were all implemented in Delphi/Object Pascal. Everything was designed with UML in Rational Rose.

So I would have to agree with you that Delphi is a great tool.
OO is also a great tool, but you may have a hard time finding someone that knows how to apply it correctly -- especially in the Linux/Unix world.

A couple other nits:

[DrCode]

First, I wish writers wouldn't confuse Gnome with GTK. I like KDE for my desktop, but often prefer GTK applications because it's easier to keep up with the library dependencies needed to build them.

Second, there's no reason why you can't program in C++ and use GTK, which is my preferred way to do GUI's in Linux. Plus, there was no mention of GLADE, which, although it seems a bit clunky at first, has turned out to be one of my favorite development apps.

Re:Start programming with Open Source project?

[bero-rh]

Am I the only one to think that an Open Source project is not the best way to learn programming?

Probably. ;)
An Open Source project is the ideal place to start because you can look at what others have done.
You're writing KHelloWorld and don't know how to open a window? Just look at a simple other KDE application to see how they did it.

And, of course, you'll get help from the people on the mailing lists.

Of course, nobody is suggesting you start by joining kde-core-devel and rewriting the IPC subsystem in kdelibs. ;)

Start your own project - something simple (maybe displaying your user ID in a window or such) that can be extended as you learn more features.

Re:How about people who already know C++

[bero-rh]

You'll want to start at the documentation supplied with the desktops.

For KDE/Qt, check out http://doc.trolltech.com/ and http://developer.kde.org/documentation.

Re:Visual Basic

[bero-rh]

Actually, there are a couple of simple ways to write Linux applications, even with graphical GUI builders for those who like them.

Check out:

• Qt Designer
• KDevelop
• KDE Studio
• PyQt/PyKDE (Python bindings for Qt/KDE)
• KBasic

Boa Contructor as alternative to Kylix

[Domini]

Check out BOA at SourceForge as an alternative RAD GUI IDE development environment for visual appications.

It's got much of Delphi's feel, but is based on Python, and has a good interface going to things like Zope.

I think it may be a good free alternative to Kylix.

A book that doesn't suck

[Bert Peers]

Can somebody actually recommend a book that explains how to develop for Linux to experienced Win32 developers ? Most books I found either focus too much on the programming languages available (introducing C, perl, awk etc), on Linux itself (yeayea I know what a pipe is), or just assume a too basic experience level. What's needed is a book that is the bomb for getting professional Win32 developers to code for the Linux desktop : no-nonsense discussion of the best way to setup makefiles (don't explain what an .so is, but show how to port over a .dll; how to manage large projects; etc), discussion of the available packages (don't explain what TCP/IP is, instead show how winsock maps to posix or whatever), in short, a huge mapping of Win32 concepts to their Linux counterparts (including the IDE and debuggers).

It's fun to scrap together the bits and pieces myself (checking wxWindows today, KDevelop tomorrow, Bugzilla after that etc) but it's too slow and confusing to get productive. If the desktop must boom, you'll need to educate the win32 guys on how to get going (just like MS educated the DOS guys) and such a book would be a big help.. Any hints ?

Re:A book that doesn't suck

[infiniti99]

No need for a book.

Have a look at the Qt C++ GUI library from Trolltech. Qt is the basis of KDE development, and the library works 100% on Windows. doc.trolltech.com has a tutorial section with many example programs. Try making a few applications on Windows first, and then switch over to Linux. They recently released a non-commercial version of Qt/Windows, so check it out!

Re:Best language to write database program?

[autechre]

A class in Systems Analysis and design will tell you that you never start off thinking about the implementation. The first thing to do is to figure out your entities and relationships between them, design _everything_, and _then_ pick a language/platform/whatever.

That said, my current personal favourite for cross-platform database-backend stuff is the combination of PHP and PostgreSQL. Using a web interface is completely cross-platform, and I personally think this combination is fast and enjoyable to the programmer. It's easy to maintain as long as you comment your code :)

PHP always seems to have everything I need, including both Perl and POSIX-compatible regexp syntax. And the online, user-annotated manual is a great reference, as is phpbuilder.com.

MySQL is fine for an obscenely simple project, but for any reasonably complex data (ie, anything with at least a one-to-many relationship), I'd recommend something like PostgreSQL. The database should be ensuring data integrity for you with foreign key constraints; you shouldn't have to do it yourself. And subselects are very nice to have. Again, the online manual is quite good.

I started off learning from a PHP+MySQL Webmonkey tutorial (many online tutorials are terrible WRT security, including this one, so watch yourself), and ran from there. I'm currently rewriting the site for our student newspaper in PHP and PostgreSQL. It's mostly complete; check it out here:

http://trw.umbc.edu

I'll be releasing the code on freshmeat.net as soon as it's reasonably done, which should be right before September.

Sotto la panca, la capra crepa

Re:Whitespace is not syntax

[Grab]

Unless you're in a language where it is. I used Occam (a parallel-processing language) for a few years - in that, the sequential/parallel structure of the program was set by statements SEQ and PAR, and the indentation under those statements. Yeah, brackets would have been nicer, but anyway.

The thing is, it's too damn easy to write obfuscated code if there's no requirement to put whitespace anywhere. I agree with you though that it's not the language's purpose to deal with that - this is the job of anyone teaching you or working with you to give you a swift kick in the backside when you obfuscate!

Grab.

Re:Start programming with Open Source project?

[Grab]

"Most people learn to program by studying and then modifying the works of others."

Not exactly, in my experience. I find the structure is more like:-

1) Copy programs from a textbook, and modify them to work out how each bit behaves.
2) Write stuff yourself, from scratch, see what you've learnt in action, and imprint what you've learnt deeply enough that it comes naturally.
3) Look at other ppl's work to see if there's any little tips and tricks to pick up.

But most of your real learning is in stage 2. It's like learning to improvise in music - you can copy other ppl's improvisation as much as you want, to get an idea of how it works, but unless you actually do it yourself you'll never learn it!

An open-source project may be useful for stage 3, but it's certainly not the place for 1 (which is learnt from a beginner's textbook), and 2 is done entirely on your own.

I'd agree with you on programming being easy, but then we're programmers. For Itzsak Perlman, playing the violin is easy, but I personally am never going to play to that level! It just requires a certain innate ability to follow things through logically, which means it's fairly inclusive, but everyone knows a few ppl who couldn't use logic to save their lives! (and the Darwin Awards show a few of those in action :-)

Grab.

Visual Basic

[pallex]

If this (or a language this simple, yet powerful) were available on Linux, it would do more good than any other single act, in terms of increasing awareness and use of this OS.

Re:Visual Basic

[pallex]

"I know I'll never be able to change your mind since its already made up so their is really no reason to continue. "

Nonono! i agree with you about the pros and cons of each! i use both!! i still find my knowledge of assembler useful (and i`ve done a touch of intel, and yes, its a dog). i`ll use either C or VB where appropriate. I just happen to prefer VB, cos i like sitting down and writing a whole, small but useful app in an evening/week. C is cool for writing little dos command line apps, or thing which require speed, or which must be easily portable to other platforms!

Re:Visual Basic

[pallex]

"bad habit(which generally they are such as global variables, multiple return points within a single function/procedure, etc) "

No different to C! You can do all of that in both languages!

Speed isnt important for a lot of programs, outside of the tiresome world of game framerates, and server throughput. Some people still spend their time making 2d graphics cards run faster. Faster than what? Oh, faster than `fast enough`. Strange.

I`m not suggesting write kernals or games or drivers in vb. But for either knocking up demos, or for writing apps where speed isnt too important (stuff like Outlook, or a front end for anything, really), why bother with C/C++? Its just a waste of time.

I learned (68000) assembler first, and after i did a bit of C, i couldnt stand to go back. Now i`m doing VB, and the idea of doing tedious low lever stuff like string manipulation in C, now i`m used to :

MyString = "File " & sFilename & "from drive " & !drivename & "is " & nSize " bytes."

strikes horror into my heart! :)

Re:Visual Basic

[freezingD]

If this (or a language this simple, yet powerful) were available on Linux, it would do more good than any other single act, in terms of increasing awareness and use of this OS

It's called Python.

Re:Visual Basic

[Transwarp Conduit]

True, and I don't think anyone is seriously suggesting that "LinuxBASIC" (or whatever you want to name it) would be a useful tool for development work on the kernel, or for writing drivers, or whatever. Clearly, that sort of task is best left to languages which don't rely on runtime modules, and which don't try to second-guess you or prevent you from doing things they don't think you should be doing. However, BASIC does have its uses - especially in its modern incarnations, where you have access to a lot of language features that used to be found only in "serious" languages like Pascal or, yes, even 'C'. (If you think BASIC is still mired in what it was back in the days of your old Commodore=64, or of GWBASIC, you really should check out what's being done with languages like PowerBASIC. While you're there, drop 'em a note encouraging them to finish up the PB For Linux version. :) ) Many of the programs I write in PowerBASIC (which, unlike VB, does not require a runtime DLL!) are one-off, single-function utilities to perform a specific task - usually, something simple and stupid, like running a custom test rig by trading sixteen-byte data packets with a board full of 8-bit microcontrollers, or searching a directory full of graphics files to make sure their extensions match their file types, or to act as a simple quick-n-dirty shell for a command-line utility. For these kinds of applications, a language which hides all of the gory details from you and takes care of them on its own can be quite desirable; it makes it possible for me to say "sure, no problem, give me fifteen minutes" to a co-worker who's trying to get into a file that was created ten years ago on some weird program that terminated all of the lines with instead of . :) A language like BASIC, with its English-like syntax, also opens up the world of programming to a larger group of hobbyist types who either can't, or don't necessarily want to, get their heads around the highly compressed (and somewhat arcane) syntax of 'C' and 'C++'. Many of them don't have any ambition to become professional programmers, and don't care that BASIC may be teaching them bad habits (or what 'C' programmers think are bad habits, anyway); all they want to do is throw together a small program to let them automate some tedious task, or implement a simple game, or control their latest electronics project through the parallel port. A good, Visual LinuxBASIC would go a long way towards attracting these kinds of people to the Linux world; right now, most of them stick with DOS or Windows because of the perception that they'll have to learn 'C++' before they can use it.

Re:Visual Basic

[Genoaschild]

The problem with VB is that it is slower than CPP. Cpp is probably the closest you are going to get to assembly(speed and control of code) without programming in assembly. VB is nowhere near assembly. It is based on an API that calls libraries that calls win32 api to finally perform the function. This is a higher level language then C(you can't write Operating Systems in Visual Basic where you can in C(I know, I wrote a very small one in C that could execute Assembly programs, could print, talk to the serial ports, and had its own command shell)), which might be a good thing for the casual programmer or where speed or size of executables is not an issue but it has its limitations.
----

Re:Visual Basic

[Genoaschild]

The right tool for the right job. VB is certainly not the fastest thing in the world but it can be useful, look at XL, completely written in VB. For something quick and dirty, it might be useful. It might take a good cpp programmer 20 minutes to write the same program that a good VB program maybe able to write in five(then again, maybe not.) I have personal problems with VB like you said, creation of bad habits or what I think is a bad habit(which generally they are such as global variables, multiple return points within a single function/procedure, etc) but anything that is useful and saves time programming might be helpful. I used to program in GWBasic years ago, it got me started. What I thought then was real programming is nothing compared to what I think of programming today. Everybody has to start somewhere and those who really don't care about being a professional about it or doing anything other than writing pong, this might be good. Personally, I'm avoiding it as much as possible. I am fond of having as much control over a a program as possible, being as fast as possible, and being as portable as possible. VB lacks in all three categories and that's why most game designers are not active VB programmers.
----

Re:Visual Basic

[Genoaschild]

"bad habit(which generally they are such as global variables, multiple return points within a single function/procedure, etc) " No different to C! You can do all of that in both languages! Well, duh. I couldn't think of any strict VB samples so I wrote what I've seen others do in C and C++.

Speed isnt important for a lot of programs, outside of the tiresome world of game framerates, and server throughput. Some people still spend their time making 2d graphics cards run faster. Faster than what? Oh, faster than `fast enough`. Strange Speed is very important to me. I'm willing to sacrifice memory for speed(back when computers were less then or =640k, it was switched) Unless you're writing a console program or something simple like the Tower of Hanoi where these programs don't usually require a huge amount of CPU cycles or something that is very object or event oriented, VB is not the answer. In other words, you are not going to write something that is CPU intensive in VB like Quake or mr. mega encryption program.

I learned (68000) assembler first, and after i did a bit of C, i couldnt stand to go back. Now i`m doing VB, and the idea of doing tedious low lever stuff like string manipulation in C, now i`m used to : I hate assembly too. I've wrote programs in x86 assembly, not 68000, and it truely is a pain in the butt. As resources, memory, cpu cycles, etc. approach infinity, more and more people are likely to write games and major projects in very high level languages like VB and Python. It's almost impossible to write a good encryption in these high level languages because they don't allow you to easily modify individual bits without calling lower level programs.

MyString = "File " & sFilename & "from drive " & !drivename & "is " & nSize " bytes." This is why people invented PERL so they could save time doing this. String manipulation in C can be done but is a pain and too often enough leads to string overflow. Using char_string=(char *) malloc(512) will often waste more memory then needed. Since memory is not a top priority at the current prices, it is not a big deal.

The bottom line is, if you really want control of what you are doing and do exactly what you want the program the do, C is best. If you really don't want to think about it and let the OS/VM/API handle it and look approximately how you want it to look, VB might be a better answer.

I've programmed in both and I'm always going to prefer C(I do way too much low level programming). I know I'll never be able to change your mind since its already made up so their is really no reason to continue.
----

Re:How about people who already know C++

[pcardoso]

I found a little tutorial on QT/KDE programming on the KDE-Women site.

I haven't got the time to try it all out, as I'm still struggling with work and exams, it seemed very complete, showing how to use KDevelop, adding widgets, all in a step-by-step-with-pictures sort of way.

Python

[tal197]

Python has bindings to Gtk and gnome-libs and is a much gentler introduction.

The gnome-python package is here:
www.gnome.org.

The package includes lots of simple example programs which are easy to read, and handles calling the init functions for you.

There are more tutorials on using python to create Gtk apps here.

Re:Python

[umeboshi]

I'll agree, python is exetremely easy to learn.

I have been able to make a load of unimpressive applications very quickly. This can be much easier than finding the 'right' thing, i can just make it.

Python also has the powerful ability to let you create your apps on the fly in the interpreter.

All of the libraries that I have used so far are very intuitive, and your actual code seems to resemble pseudocode.

I highly recommend python to anyone who is in need of dodging headaches.

Re:RAD == BAD

[dmelomed]

Uh oh, my bad. What about Kylix and VB?

RAD == BAD

[dmelomed]

This is probably going to be moderated down, but still I think many people can associate with the folloing babble.

I've met a few developers who are completely ignorant about OS and process-level stuff.

I see a trend where people start in a RAD environment languages like VB and VB script, and now Java and Kylix without any fundamental computer concepts. They've never developed in lower level languages like C. They do not have even slightest, general understanding of microprocessors, RAM, stack, heap, pointers, memory allocation/deallocation, memory leaks and so on. IMHO anyone starting out in a RAD environment without understanding of computer primitives is contributing to a trend of writing poor quality software. How many colleges and universities are out there who do not require their students to take C or assembly classes as prerequisites for higher-level languages? The common result is a clueless CS or IT degree graduate (in addition to most establishments' ignorance about their students' real knowledge; heck, my university didn't even provide computers in the classroom ).

The most important concept they are missing is that a computer is a state machine.

Many languages today encourage black-box approach to programming which hides state. For example in some languages objects contain methods that are executed in a sequence that a programmer is not encouraged to track. Which method is doing what at any particular point in time of the execution is not known. Furthermore, some languages like Java for instance, are shipped with a boatload of libraries that hide the plumbing. This leads to assumptions about what those libraries really do, and again poor code.

Often it is simply impossible to imagine what is going on in an OO program at run-time at any particular point in time. Not understanding how the resultant code works down to machine basics leads to hard to find bugs and poor quality and bloated software. I am not even talking about deep technical knowledge down to bits, but one should be aware of state of your application on an OS or even process level even if your language of choice doesn't require it.

It is not to say that RAD should be avoided at all costs, don't get me wrong. RAD environments and bundled languages are there for short time-to-market developement of software. This is justified because programmers are always more expensive than hardware. Nevertheless, a RAD programmer will write better code and design better software with the understanding of the lower-level plumbing. Experience with low-level languages should be a must for success with RAD-type environments and languages.

Re:RAD == BAD

[mazor]

I see a trend where people start in a RAD environment languages like VB and VB script, and now Java and Kylix without any fundamental computer concepts. They've never developed in lower level languages like C. They do not have even slightest, general understanding of microprocessors, RAM, stack, heap, pointers, memory allocation/deallocation, memory leaks and so on.

The trend is not new. It's what created and fueled the PC revolution. Back in the days of the IBM PC and XT, the CEO of DEC stated flatly that DEC would not waste time on developing a PC because there was no reason for a worker to have a PC on their desk, since all real software should be run (and developed) in the controled environment of a big iron mainframe. The market success of the PC caught IBM by surprise - the PC was not being bought by the engineers IBM expected, it was being bought by non-engineers, non-technicals, people who didn't fit the IT profile.

The vast majority of PC users have never had technical understanding of a PC, just as the vast majority of automobile users have never had technical understanding of how their car is built or what makes it go.

To further the analogy: Just as the vast majority of people who adjust ignition timing or change carbuerators do not have formal training in mechanical engineering or auto repair, the vast majority of people who write software are not formally trained ivory tower CS or IT druids. Programming is not part of the job description of most people who buy software development tools. They write code or scripts or spreadsheet macros to help them get their actual job done.

Should such accidental coders attempt to write an OS, or an inventory management system? Certainly not. But that does not mean that they should be shunned or spat upon by ivory tower elitists.

The existance of software development tools that can be used by the common man is not a threat to the technical superiority of the uber-geeks. So get over it already.

--mazor

Re:/Dfor="if(false);else for"

[Frizzle Fry]

You are not the first person to suggest that #define for="if(false);else for" is a good solution. I disagree. This is not legal C++ code and therefore (even though it might work on your compiler), it is not guaranteed to work. According to the C++ standard, the compiler doesn't even have to warn you that you are doing anything illegal, and it's behaviour in response to this #define is undefined. This may work on your compiler, but cause problems in a silent and nonobvious way on another. If you are going to complain the VC++ is not real C++ because it doesn't follow standards, then your code should follow standards too. Don't use this #define.

Re:Read the parent again

[Frizzle Fry]

As I suggested a compiler switch and not what you said

Sorry, I thought that you were suggesting the #define. What is the compiler switch? I've never seen that before. How does one use a compiler switch (at the command line when you compile, or in the code)? Is there more info somewhere?

The Dietel & Dietel is a great pogramming book

[Billly Gates]

I love the Dietel and Dietle "C++ how to program". There are alot of homework assignments in it and they do teach more about good software engineering practices then actual c++ commands but that is a good thing.

In the real software engineering world you need good highly structured and easy to read programs. Especially if you work in groups. Alot of IT managers don't want someone who just knows how to type in the programming commands but they want someone who knows good software engineering principles. I am taking a slow pace in the book. I guess its how fast your school is going through it. At the Manhattan community college they only go through half the book a semester. Because it is intense. There are just too many code examples and homework assiggments to type in from the book. Also I actually type in the code they use in the examples so I can understand what they are talking about in the book. You should try this. Practice makes perfect.

I also tried part of the "learn c++ in 21 days" a few years back in highschool. I peaked at it recently and looked through the table of contents and relized its total crap. They teach you a few commands and not good structured programming or methods. For example how do you list the contents of a 2 dimensional array? The answer in the Dietel and Deitel book is to use X amount of Arrays nested in each other. WHere X is the amount of dimensions of the array. WIth the "Learn c++ in 21 days" you may learn the keywords for union or structure but you do not learn how to solve the multidimension index array problems.

If your college only uses part of the dietel and dietal "C++ how to program", then perhaps you shouldn't be a programmer. Programming is hard stuff and good talent is hard to find. They also work like maniacts. If you want something easier try "Visual Basic 6 how to program". Its kind of boring for a techy like me. I loved learning operator overloading for example. VB is more basic but it has its niche market as a quick programming solution for bussiness.

Try to look at it as power in which you can use the awesome power of your computer to do anything. If that deosn't appeal to you, perhaps you should change your major because the IT industry is for of people who live eat and sleep with this stuff. Oh, and by the way I have serve dsylexia and mild autism/aspergers so if I can learn from the book, almost anyone can.

Re:A few things about C++...

[CraigoFL]

This isn't a flame, I'm genuinly interested in your opinions...

Java is a disaster.

(My background: Several years of Java exp, started out in C and a little C++. Currently working on a pretty successful Java project. Love programming in Java, and haven't come across many areas where I find it lacking).

Unusable gui library,

While "unusable" might be a little strong, it's certainly bad, no arguement there. :-)

very poorly implemented containers

This was the comment I was most interested in; can you elaborate?

broken threading

I know that there's a lot of cross-platform inconsistencies in the Java threading system. Does it really deserve to be called "broken"?

horrible runtime environment

I won't make any arguements here, since there's plenty of JVM/C++ comparisons elsewhere. Sun's JVM has been good enough for our purposes thusfar.

without any half decent debugging tools

True, although in my development I've worked around this (I can debug my apps without an actual debugging tool), so I don't really miss it. I can't claim that I wouldn't be more efficient with one though.

no good java desktop apps

No arguements here.

the 'standard' library ballooned to the extent that nobody ... can claim to know all of it.

Very true, but is there really much harm in having too much in the standard library? I only use a fraction of it on a daily basis, and I wish they would spend more time refactoring the more usefull classes rather than adding new ones, but the core of the standard library is still decent IMHO.

stop hyping java until it proves itself to be a stable and reliable development environment

Can you explain this comment? We've had good experiences with the stability and reliability of the Java *runtime* environment...

I'm really interested in hearing your reply :-)

Re:A few things about C++...

[CraigoFL]

Thanks for the good comments...

More specifically we're using EJB

Oh, THAT explains quite a bit actually. :-) I've used EJBs in the past, but am not using them currently.

The fact that they do not support parametrized types (templates) is obviously a big drawback

Yeah, that makes sense... although JDK 1.4 is supposed to be getting parameterized types so your arguement MAY be eroding somewhat (wether Sun can implement it decently remains to be seen). I myself don't really need that particular feature; I generally know exactly what types of objects are going in & coming out of a collection, and I very rarely get any ClassCastExceptions because of this. But that's not to say that it wouldn't be a good feature to have.

Additionally not being able to store simple types (only derivatives of Object are allowed) always sacrifices performance.

The inability to treat primitive types as Object is a pain, I'll agree.

I've yet to come across a decent Java IDE beside (Viusal J++)

Yeah, I'm using J++ too; it's a pretty nice editor, especially when you compare it to the other Java/AWT-based ones.

You're obviously not an EJB shop. If you were you'd be having similar experiences... The same cannot be said about EJB apps.

Nope, we're not, thank god. However, the problems with reliability and stability that you mentioned seem to be due to the app/ejb server software, not the JVM iteself, correct?

claims about...productivity gains in java shops are ridiculous. They don't take into account the time between coding java apps and getting them to a state where they are usable enought to be shipped/deployed.

I don't really agree with you here... how much real difference is there between a C++ app and a Java app, in terms of building stability and usability? EJB-based apps don't count IMO, since you are relying on a 3rd-party based app environment, and C++ could be equally flaky here. Besides, Java != EJB. I'm also not counting GUI apps; the faults of Java's GUI libraries are well known. As a core language though, it Java really worse than C++?

Kylix!

[red_crayon]

A lot of people learn/learned Pascal as their first language. It's popular in teaching environments. If you are just starting out coding for Linux, and Pascal is what you know, then Borland's Kylix will let you write programs for Linux.

There is talk of a free (beer) kylix command-line compiler dowload, and the desktop edition is $100- for students, $200- for non-students. Kylix is easy to use. It won't take over from C/C++ but for a lot of people it could be a great way to get them started coding under Linux.

Bad news...

[QwkHyenA]

> If you want to become established as a coder for GNOME or KDE, learn C (for GNOME) or C++ (for KDE)

If anyone who was coding in another language, would you please leave your keys and badge with the security desk by the front door.

*QH hands them two boxes*
And please clear out your desk. We'll miss you.

*Intern walks up*
Can I have your chair?

Re:A few things about C++...

[akc]

I like the general tone of this post, but some of the facts are glaringly wrong...

Object orientation is necessary and natural.

No, it's not (necessary). I like OO, but it is not the silver bullet that kills all programming problems. Other, radically different styles (functional programming springs to mind) have shown big increases in effectiveness over OO languages, by any useful metric you care to choose, at least in certain areas. OO is good, but hardly perfect and clearly not necessary based on the number of non-OO projects in the world.

I too like the tone of the top level post, and I think the quoted bit above starts to make a valid point.However I think it misses one fundemental ...

Programming in an object oriented way is fundementally different from programming in an functional way. In the first "processes" are smeared across a number of actors (objects) which cluster the parts in a number of separate functions around the data they are working on. In the second "processes" are implemented (as functions) in one place.

Just using an object oriented language does not guarentee that you use an object oriented approach. In fact a programmer has to almost make a complete philosophy shift to move to an OO way having gained experience of functional programming. For programmers who try and do this as a day job (ie work as programmers for a living) this shift often takes about 6 months.

This means, I think that the effectiveness that you refer to above is as a result of this bias towards a functional style and the difficulty many OO projects have in getting it right.

However an OO project that does get it right makes massive and rapid progress once the basics are in place.

In my view - we are seeing KDE make rapid advances at the moment precisely because (at least with KDE 2 - I have no experience of KDE 1)they have got some fundementals right. The challenge they will face as they attract more supporting developers will be that the layers above which probably won't have as rigourous architectural control over them will suffer from people with a different approach start to work on the applications.

On the other hand, I don't think a new and better C++ will solve the problem and be the saviour that Anonymous Brave Guy thinks.

Re:Teaching my brother

[jamesots]

When I say it's obviously a mistake, I was pandering to the majority of slashdot readership. I don't have anything against VB per se, but then, I'm not sure what 'per se' stands for.

I know that VB is widely used and its useful for getting work, but I'll have to agree with the person I'm replying to - that the syntax of VB is not very uniform.

My brother (who, by the way, has become pretty adept with JScript now), has now had a look at VBScript, and asks questions like "why do I have to put brackets round the arguments to this function, but not the other one?".

Fortunately VB.NET will iron out a lot of these foibles. But .NET also introduces C#, which I'm afraid I'm going to have to admin to loving to bit! What I'd really like to see now if a version of C# for *nix. Doesn't have to compile to MSIL - native code would be good. I'd just like to be able to use C# rather than C++. (I wonder, how easy would a translator be.

Right, I'm wandering around all over the place except for on topic, so I'd better wrap up!

I'm going to pieces

[jamesots]

It's the end of the day. My brain is tired. I don't normally spell half my words wrong and make mistakes with my punctuation.

Teaching my brother

[jamesots]

My brother had never had a computer until three years ago I bought him one when he went back to University. The first technical thing he learnt was creating HTML pages. Then he moved on to Director and learnt lingo, but only very basic stuff. Then a couple of months ago I started to teach him JScript for use in ASP. This was a good place to start I think, because being a scripting language it doesn't need any complicated compilation. There's no need to learn about data types. The syntax is close to C and Java. And it's possible to do something relatively interesting without too much coding. This is similar to the position BASIC used to play. Except that the step from BASIC to most languages is quite a big one, unless you go to VB, which is obviously a mistake!!

Re:Teaching my brother

[ednopantz]

Um, are you sure that you are talking about VB here, not VBS?

JS and VBS are roughly similar in that neither supports any kind of variable typing, don't compile in the least, etc.

In VB the difference between a Sub and a Function is pretty clear. A Function returns a value and a Sub doesn't. What is so arcane about that?Likewise ByVal and ByRef aren't exactly rocket science.

Pure it ain't but neither is it complicated.

Re:A few things about C++...

[joswig]

> I get the impression that larger Lisp projects will not approach the team size you mention above.

Evidence from for example the AT&T switching project is that a team of one hundred working with Lisp technology is as productive as a team of 1000 working in C++ technology (building ATM switching systems).

The hard part is to keep the technology alive over a longer period of time inside a company, since most companies are not prepared to use Lisp technology at that scale.

Re:Question for Micheal

[The Troll Catcher]

You're certainly on to something here - I don't think anyone would seriously try to write a major GUI app in either Perl or Python. Maybe Python's different (I doubt it), but from my experience with Perl (I've built some fairly sizeable CGI apps), you just get to a point where the language just doesn't scale any more, unlike C/C++. Somehow there comes a point where you need a "real" language, with robust type-checking, real data structures, etc.

I've seen a bunch of GUI programs written in Perl, Python, and Tcl, and you know what? None of them were particularly complex - mostly things like configuration programs, with the most complex being a very kludgy e-mail client.

So sure, you can write GUI apps in scripting languages, but if you want to do more than fairly simple stuff, you need another language.

Re:How about people who already know C++

[The Troll Catcher]

Just curious - why do you call moc an "obsolete preprocessor"? This is like saying that GCC is an "obsolete compiler". It's really a very minor thing - it just adds a few features that C++ lacks, and makes things OH SO MUCH nicer. Just because it's a preprocessor doesn't mean that it's bad.

Sure, it's a bit of a hack. But who cares?

Re:Bjarne Stroustrup???

[The Troll Catcher]

BZZZT! It IS Bjarne.

BTW, the 'wait 20 seconds before posting' thing is really annoying...

Re:How about people who already know C++

[Evil Grinn]

The other alternative would be to just get JDK 1.3.1 for linux from Sun and learn Java/Swing, and netbeans IDE for development.

No, get the IBM version of the JDK. Sun's version has a tendency to segfault that the IBM version does not share, in my experience.

Re:How about people who already know C++

[Evil Grinn]

AFAIK, Sun's JDK only segfaults on redhat 7

Also RH6.

Ease of Use

[lostchicken]

The language you write your app in makes no difference to any user, except those wanting to change your code. The programmer should choose whatever language allows him/her to make the fastest, most stable, and most importantly, the most usable final binary.

This is coding for the desktop, and for all I care you could use ALGOL if it helps you make a working app. Make sure it works straight out of the RPM, or Debian package, and I can use it without reading 40 man pages first. I don't use Galeon, because I don't want to have to resolve 20 deps. This is a C problem, and there is no reason to have it. Win32 doesn't see these problems, so why should we? We have to think of the end-user first, and always.

twb

Learning C++?

[Futurepower(tm)]

He's right. Thinking in C++ is helpful. And the electronic version is free. This book is not complete, however.

It is important to know that none of the books are complete. The biggest hurdle to becoming a programmer is learning to accept, and make sense of, poorly written documentation.

All the books that I've seen make object orientation seem much more difficult than it really is. Am I in a position to know? Yes. Powell's bookstore here in Portland, Oregon is the biggest bookstore in the world. I've spent hours looking at all the books there about C++.

The technical publishing world has become very corrupt. Publishers know that people find it difficult to evaluate a book while they are in the bookstore. So, a publisher who provides a poor quality book with big promises on the cover will sell books.

Remember to stay in control. If a book doesn't make sense to you, consider the possibility that it is the fault of the book, not you.

Question for Micheal

[nick13]

Micheal,

Being so opposed to developing desktop applications for the Linux desktop using C++, what would you suggest starting out with? Last time I checked, C and C++ were the two best choices for building fast, robust GUI applications (bindings for scripting languages not included), just as this article says. That is, of course, unless the largest Linux desktop players _aren't_ GNOME and KDE, as I've been led to believe.

I respect your opinion, but it doesn't really matter whether or not you like C++ if its is one of only two options for Linux desktop programming. That being said, I feel its a bit unfair to imply that this article may not be worth its salt because it is simply stating the facts.

Nick

Re: Question for Micheal

[nick13]

As someone pointed out in another post, there's more to this issue of C++ bashing than just writing code in a given language. Knowing how to read library sources in their native language is important, though admittedly not required for taking the first steps.

Fledgling Linux developers may also benefit from learning C++ because the OS, most core administration tools, and the majority of userland utilities and applications use C or C++. I don't believe any other language can offer this benefit.

Keep in mind I don't personally enjoy C++ more than any other language, so I am not defending one language over another. I'm just trying to get the facts straight. If we're going to bash authors of articles for suggesting a supposedly poor choice of language for beginners to use, I'd at least like some explanation.

Nick

PS -

I didn't know GTK+ had bindings for so many other languages. Pretty cool.

Re:Question for Micheal

[Proud Geek]

I'll byte. What you say is true, but entirely beside the point. He meant C for GNOME or C++ for KDE, and the bindings for Qt/ KDE are not so varied as for Gtk. Also, two of those languages, Perl and Python, are unsuited for developing sizeable desktop applications. As for Ada, I suppose you could, but I don't know of any such applications, so finding an existing project to work on would be a difficult task itself.

Re: Tools verus techniques

[plcurechax]

one of my development guys has suggested PERL well so im going to give it and C a look

Ah, I would recommend you reconsider. I like Perl, I program in Perl, I program professionally in C, but in my opinion these are not a good "learning language."

What makes a good learning language?
Clean, modern design that encourages good programming technique. I suggest you look at languages like Python, Klyix/Delphi, and Java.

You may not choose them in real-world development, but in my opinion they are nice clean designs which encourage good programming habits rather than Perl and C that can be nice and clean, but do not encourage or require good habits. BTW, you can get started in two out of three of those languages for free, which is a bonus for anyone learning to program.

Visual C++ is a Microsoft product, a C and C++ compiler, and is typically used in referring to meaning to develop within their environment, i.e. Win32, Platform SDK, MFC (Microsoft Foundation Classes), etc.

C itself is just a language, it is platform independant, and highly portable, from embedded processors and smartcards to vector supercomputers. Often people refer to ANSI C, which contain the last major changes to the language (as in The C Programming Language), while minor changes were made in ISO 1989 and 1999 international standards.

Re: Tools verus techniques

[plcurechax]

Many (nearly all) people new to programmer get distracted or become obsessed with "which language/tool/platform/etc."

It doesn't matter. It doesn't matter because the techniques are basically the same. You want to learn the concepts of programming, of abstractly representing information, writing a series of logical statements. Concepts like structured programming, modular programming, object-oriented programming, functional programming, and software engineering are vastly more important then whether you use GKT+ or KDEfoobar.

For ground-zero programming experience, I think Deitel& Deitel ___ How to Program books are a good choice.

Practice what you learnt in step zero.

Step two, I would strongly recommend reading comp.risks, The Mythical Man-Month, Code Complete, Programming Pearls, and The Practice of Programming. These focus on high-level knowledge, which is more important that low-level details. Other requirements include understanding computers, see Computer Architecture : A Quantitative Approach by Patterson and Hennessy. A hard-core introduction to programming, used at MIT, is Structure and Interpretation of Computer Programs by Hal Abelson and Gerald Sussman.

Honestly the details will become clearer and easier if you have a good understanding of the big picture first.

Best language to write database program?

[sangretoro]

I am looking to write a good free-software database program to be used to keep patient records at doctor's offices. Mostly contact info with some user-specified classification schemes, searchable and able to automate printing of call-back notices etc. Ideally would run in linux with a nice, intuitive GUI, and fast to write, easy to maintain.

My guestion, coming at programming 100% fresh, what is the best language to write this program in? Should I be looking at certain (or *specific*)database programs to use as backends (i.e. MySQL or PostGreSQL)? Thanks for your help.

Re:Best language to write database program?

[sangretoro]

Thanks! I also found an apparently slashcode using site called LinuxMedNews. I think I'll try asking/snooping arround for similar programs. Wouldn't want to reinvent the wheel... Or do I? :) Thanks a lot.

Gnome docs

[beri-beri]

Well, I've tried recently to get into developing small GNOME applications: the ride was fairly smooth, some bumps at places. All the docs are at www.gnome.org, there are tutorials, API references, etc. Most are C, for C++ bindings to GNOME/GTK, look for Gnomemm, the first comlete release came out a few days ago.

Be aware that some of the APIs (mostly the newer ones) are under revision and the docs/tutorials are not allways updated. It might happen that you need to look into the .h files to find the right parameters for some API functions. But even like that, I like the GNOME architecture a lot, it's really flexible for programming.

Re:A few things about C++...

[MSBob]

Can't agree more. I'm a long toothed C++ developer who recently got a position in programming Java. Java is a disaster. Why can't people see how broken that platform is? Unusable gui library, very poorly implemented containers, broken threading and a horrible runtime environment without any half decent debugging tools. There are no good java desktop apps to speak of (no, JBuilder and TogetherJ are shit) and while Java seems like an easier path than C++ the 'standard' library ballooned to the extent that nobody (possibly not even Gossling himself) can claim to know all of it. I really hope people stop hyping java until it proves itself to be a stable and reliable development environment. Until then I'll take my trusty C++ compiler with QT and ACE any day.

C++ is not hard to learn but it requires one to understand how computers work in more detail than when they code Java. What's wrong with having to learn what pointers are and what stack unwinding means? I always thought they were concepts covered in CS101? Why so much hatred for the language that is open, stable and mature?

Re:A few things about C++...

[MSBob]

I'm working with J2EE on a daily basis. More specifically we're using EJB. So far I haven't found a single implementation that would be stable enough for anything more serious than an average e-commerce site. I definitely wouldn't use any of the currently available ejb containers for a mission critical application.

On java containers. The fact that they do not support parametrized types (templates) is obviously a big drawback. This is how people did containers in C++ around 1991. This is bad because you're seriously sacrificing type safety. Every time I create a java container I MUST put a comment next to it clearly explaining what is stored in the container. Imagine creating a map that uses strings as keys and vectors of Sets as values. If you don't comment exactly what you're doing nobody will stand a chance of figuring out what's in your containers. Additionally not being able to store simple types (only derivatives of Object are allowed) always sacrifices performance. Don't say it's miniscule because it's not. It may be insignificant in a web application where no serious computation is performed anyway but for desktop apps and especially scientific apps it makes the language worthless.

I can debug my apps without an actual debugging tool
In the same spirit you can say that everything is implementable in assembler. But sometimes even programmers enjoy having their life made easier. I'm a sworn hater of JBuilder. This tool has so many bugs in it that it shouldn't be sold as shareware nevermind selling it for two thousand bucks. The kind of bugs they have in that thing would make any other software company shut doors long ago. Borland is surviving purely on the virtue of their brand recognition. I've yet to come across a decent Java IDE beside (Viusal J++) which was obviously written in C++ :).

We've had good experiences with the stability and reliability of the Java *runtime* environment...
You're obviously not an EJB shop. If you were you'd be having similar experiences. Some people (disgusted with EJB) are trying to use JINI for enterprise apps. While not ideal at least they can claim it works to some degree. The same cannot be said about EJB apps.

When I talked about horrible runtime environment what I had in mind was the 70MB footprint for even a simple application very slow process of dynamic loading of classes that increases the performance penalty and reentrance issues within the JVM core libraries themselves. Instead of creating more and more APIs every week they (SUNW) should concentrate on fixing the damn thing.

I think all the claims about incredible productivity gains in java shops are ridiculous. They don't take into account the time between coding java apps and getting them to a state where they are usable enought to be shipped/deployed. In my experience that time is quite significant. The fact that the incredible hype around the language attracte a very mixed pool of talent is probably part of the problem but so are all the bugs in the JVM.

Re:A few things about C++...

[hding]

Smalltalk would be great for building UI intensive applications if only there were more good toolkits for it. If that flavor of OO suits you, you're better off using GNUStep or OS X and coding in Objective-C. Smalltalk still doesn't have the performance or library support to make it a true general purpose language.

Given that Smalltalks, typically, are mostly self-contained enviroments with built in GUI building tools, it seems rather unlikely that there will be a big proliferation of toolkits for them. On the other hand, I doubt most people who use Smalltalk feel that such is necessary, as the ones that exist with the environments are typically well thought out and useful and pretty complete already. I'm not qualified to say very much about performance aspects of Smalltalk, since I don't use it for such tasks (but primarily for building GUIs), but you might possibly be surprised at how well something like VW or VA can do.

And Lisp is a fun language, but I can't really think of anything it particularly excels at.

I use (Common) Lisp as my main general purpose language, and I think it works pretty darn well for most tasks (well enough that I choose it above anything else). I suspect most Lisp programmers would agree with your statement with C++ swapped for Lisp, except few of them would claim that it's fun. :-)

Re:A few things about C++...

[hding]

What I mean is that Smalltalk would be more widely accepted if there were variants that duplicated the look & feel and object model of a common C++ toolkit & framework like MFC or KDE. The idea being that developers could work in Smalltalk but produce applications that seem more native to the end user.

No one can really say if making the GUI aspects of Smalltalks more like a C++ toolkit would make it more popular among (non Smalltalking) programmers. However, it doesn't seem that it would make much sense to do that. The GUI frameworks in Smalltalk are set up to (as you might expect) work logically, consistenty, and robustly with Smalltalk. There's little reason to try to bolt things from a different langauge onto it, and as always, trying to use one language like another instead of using it like itself is not likely to produce good results. As far as producing native-seeming apps for an end user, some Smalltalks take this approach. For example, at work I use Dolphin Smalltalk, whose GUI system is based around native Windows widgets. Build an app and it looks just like it would if you built it with VC++ or VB. It would certainly be possible for a Smalltalk vendor to do this on other platforms (and in fact VW or VA may well work that way; I don't know).

I guess I think Lisp is fun because I spend all day working in procedural OO languages and get bored. However, it doesn't have blazing speed and low level control of C, the GUI friendliness of Smalltalk or Obj-C, or the industrial strength of Ada, C++, or Java.

I doubt too many people would argue that with current machines/OSes something like C is better for getting close to the machine. Of course, there are examples like the Symbolics Lisp Machine where everything was in Lisp, so that wasn't true.(As far as speed goes, that's really an implementation rather than language issue. If one knows how to optimize Lisp code properly and has an implementation with a good compiler, one can do pretty well. See, for example, CMUCL. Or this page for more pointers. I will be honest, however, and admit to sometimes coding small parts of programs in C to improve performance. With the emphasis on small. :-) I do think Smalltalk wins hands down as far as anything I know for GUI, but particular Lisp implementations needn't be all that bad; I use Lispworks, and I don't think I'd say that I think GUI building is any harder in that than in a typical C++ or Java environment. I do think you may underestimate how suitable it is for "industrial strength" applications, though. Hang out in comp.lang.lisp for a while (or better, search the archives) and you will discover those who have built very serious, very large apps in Lisp, in part because of its suitability for such projects.

Re:A few things about C++...

[hding]

Before I say anything else, let me say that it's refreshing to have a reasonable discussion with an AC. :-)

Also let me say that I'm the lone programmer at my company, and do not have first hand experience at "large-scale" Lisp development, so some (though not all) of the things I might relate about that have to be taken in that light. They come mostly from reading others' accounts of the same.

I get the impression that larger Lisp projects will not approach the team size you mention above. Lisp advocates will tell you that this is because not so many are necessary to achieve the same results. I'm inclined to believe this, but keep in mind my caveat above.

Lisp's type system is strong (i.e. things are of definite types and don't automatically and mysteriously switch between them, as in Perl), it's just not static (i.e. variables may contain values of different types, which makes compile time type checking difficult or impossible - although, there are implementations that are able to do it to some extent). I don't know if that makes the distinction clear, but there is a difference between the static/dynamic and weak/strong axes. Lisp would be dynamic/strong. Since dynamic/static types and their advantages/disadvantages are rather religious issues, it's unlikely that any discussion of that would be of benefit. IMHO it's perfectly possible to make robust applications with dynamic typing, but I can also see where the static typing people are coming from, so let's leave it at that. (Incidentally, something like ML or OCaml might be of interest to you if you're committed to static typing. I'd say their type systems are a considerable improvement on C++/Java style. And actually they meet some of your other requirements well too.)

Lisp does have the kinds of features that you need for larger programs. Packages (think namespaces) allow you to keep things hidden and to keep people out of each other's way. CLOS provides an object system which is at least as powerful and is much used in Lisp projects. The condition system is not radically different from the exception systems. Finally, macros, while rather a dirty word in C++ circles, are much more useful and sane in Lisp, and can help tremendously in some of the engineering needs that you mention.

You would be right that Lisp chooses more to give you the ability to use these things properly and usefully rather than forcing such use. Put another way, for best use one must assume that the programmers, designers, etc. are competent. With packages, for example, there is a notion of exported symbols. So if I'm using someone else package, I should only use the exported symbols (which one might think of as the interface to the package). However, if I want to be devious about it (okay, you don't actually have to be that devious), I can get to the internal symbols. (I'm not a C++ expert, but I'd suspect that you can do similar things with respect to private variables, etc. if you know how to fool around with pointers properly, and so on.) A programmer is expected to know that while this is possible, it's not a good idea. And so on. Since IMHO the most important thing one can do to get a robust application is to get good people working on it (and I don't have much sympathy for those who neglect this), this doesn't disturb me that much, but others' requirements may vary.

(And, in case it's not evident, I'm certainly not saying that Lisp is best for every large scale project, just that it is appropriate for many of them.)

Re:A few things about C++...

[hding]

If I'm not mistaken, one of my compadres from comp.lang.lisp :-) (ok, I'm really more of a lurker than a contributer). Glad to see you have more concrete information, as much of what I was spouting off about was gleaned from places like comp.lang.lisp.

Have any insight into why your last point is so? Given the productivity boost I've seen by using things like Lisp in my own work, and evidence as you present on another scale, I'd think companies would want to embrace such techology.

How about people who already know C++

[Strangely Unbiased]

I am develpoing on C++ on VC++/MFC (I also do console programming). What reading material do you recommend so I can code for GNOME or KDE (In general, code a windowed application)? Thank you.

Re:How about people who already know C++

[Strangely Unbiased]

Thank you for the links. Btw: Well, first off, know that VC++ isn't really c++
I doesn't matter, I also use DJGPP and that's C++.
And I'm sorry but I won't forget everything I know about MFC. I will still be using it for Windows( until .NET programming gets common)

Start programming with Open Source project?

[OpenSourced]

Am I the only one to think that an Open Source project is not the best way to learn programming? Sure, you get help and support, but I don't think at that level. I can answer a difficult question (or make it), or a simple one in some particular environment. But if somebody just doesn't know how to program, I would feel rather daunted by the task.

Programming is not only difficult, it requires a particular kind of thinking. Some people are never going to get the hang of it. But even if you can get the hang of it, the environment of an Open Source project is probably going to overwhelm you a bit.

I think that Open Source projects are a way to go when you want to give something back to the community, or when you want to learn something new in a particular environment, or simply when you need something and cannot find it, so you create it. But for starting with programming? Not the best way IMHO.

--

Re:Start programming with Open Source project?

[damiam]

I forget who said it, but it's something about "standing on the shoulders of giants".

"If I have seen farther than others, it is because I have stood on the shoulders of giants." --Isaac Newton

Re:/Dfor="if(false);else for"

[TheAwfulTruth]

Thanks for the rational post. I'd also like to add that the MS's current scoping of the for loop variable is in fact in the 3.0 C++ standard! There is an appendix that deals with the effects of the sever rescoping of the loop var that took place and it basicly says that compiler vendors are free to implement the new scoping rules or stick with the old as they wish. There are good and bad effects of the new scoping rules and it's completely wrong to just say MS "Did it wrong". THey made a choice that is completely within the 3.0 ANSI C++ spec. The logical thing to do is, if you plan on doing cross platform development, just define the variable outside the for loop and get on with life. It's hardly such a big deal that it requires this constant battle.

Not an article about developing for the desktop.

[r41nm4n]

The article didn't really point out anything new, and really didn't give much insight into developing a GUI application on Linux/UNIX; it definitely has an amateurish feel to it and reads like a bad high-school paper. The article seems like it was more about approaches to open-source software development for people without a computer science background and could really be applied to developing any application, not just applications for the desktop.

It would have been more interesting to summarize the architectures of the two primary desktop environments, describe what libraries are available and what they offer, discuss deprecated libraries, and to list current projects so that effort is not duplicated. It would be even better to mention future enhancements and trends, such as the move to GTK 2.0. By the way, does anybody know where to find a FAQ or how-to on GTK 2.0? Does anybody know of applications written using GTK 2.0?

Re:The most important thing to become a good coder

[melatonin]

Now I've landed in a small dotcom and have been forced to learn Perl, PHP and SQL. I use them everyday and after a few months of practice I have ecountered all the pitfalls.

All the pitfalls? Whoa there boy, you are way too optimistic.

Re:A few things about C++...

[melatonin]

I think a lot of people's well-worn objections to C++ are going to wear out when C++0x arrives.

Have you used any other OO languages? Besides Java? Because C++ is not the holy grail of OOP. I have a hard time considering it an OO language. The problem gets worse when you use the STL, which shoots programming complexity through the roof.

OOP is supposed to make things simpler, to encapuslate stuff and take crap out of your way. Hopefully, you sit there coding the logic that goes with your data, and get everything to work together as one big happy family. With C++, you spend time figuring out why the hell you can't get this innocent-looking line of code to work:

const Foo &bar = myMap[foo];

The answer is that foo is a const object (something like that anyway). Then you have to figure out how to get something out of a map without using overloaded operators (I'm not a fan of overloaded operators, in any language).

I've heard people say things like Java is a lesser language, because it doesn't have templates. Java doesn't need templates. C++ needs templates as a hack to support wickedly (and I mean that in a bad way) strong typing.

C++ is best as a compromise between C and object oriented programing. The STL is "nice" because it allows you to put plain structs and any other C type into containers. If you have to mix C code and object oriented programming, C++ can be very convenient. Personally, I'd rather use C with Object Oriented Design.

Stroustrup's book has 40 pages of technicalities for C++. That's far more pages than what covers the standard library for K&R's C book. C is a well designed language that's easy to use and very productive. As it says on the back of K&R, C wear's well as one's experience with it grows. I've been using C++ for a long time (pre-exceptions, pre-multiple inheritance), and as time goes on, I learn more and more about the intricacies of the language. There's much less to appreciate about it. I spend more time programming the language (templates, constructor initializer lists, overloading operators, making stupid function objects, and all the specific syntax you have to use to support that stuff) than I do programming my own code. If you want to use the STL, you need to waste your time doing these things.

Try Objective-C, try Smalltalk. Even try Python. The thing is you can't approach these languages as a C++ programmer; it's like a Windows user using a Mac and saying "The Mac's GUI sucks." You need to learn how this stuff (and proper OO) is used properly, and then the power you can get from it.

This article discusses SmallTalk versus Java. The same can be said for Java versus C++.

http://www.smalltalkchronicles.net/edition3-1/whyj ava.html

I am not a Java fan (its library is junk, IMO), but as a language it's not worse than C++. The only advantage that C++ has is that there are much fewer penalties for writing your own "standard" library.

Re:A few things about C++...

[melatonin]

I'd like to see a real example where you have this sort of problem, instead of some contrived (and clearly untrue) version. Enough with the FUD, please.

FUD? I dealt with that yesterday. Too often you write code that you would expect to work, but have to break it down because the compiler doesn't like it, because C++ is enforcing its overly complex design on you.

not least a forced mix of value and reference semantics, which is the root of one of the article's main complaints.

I was talking about the section on language syntax complexity.

Re:A few things about C++...

[melatonin]

Ah, I think I see what you were getting at. Was your map const?

No it wasn't! After looking at the situation for a few minutes, I was able to undertand why the compiler barfed at me. But that's exactly my point...

In time I've come to prefer simple designs that scale well. I find that C++ is the exact opposite of that :P

I personally think the best way to get Linux Desktop development off the ground would be to pour resources into GNUstep.

Re:Fast VB... Maybe

[Genoaschild]

That's not really fast. considering the same thing could probably be done on a 50 mhz 486 written in C. It just seems jast because computers are relatively fast compared to the task you are doing. If you don't use every single CPU cycle in calculation then, naturally, it will seem faster than it actually is. More then likely, your program is execution several times more instructions in the background(housekeeping) then you actually know. By the way, your spinning cube is cool. I like it.
----

Re:Does VB need to be fast?

[Genoaschild]

Does VB need to be fast in an environment where computing power doubles every eighteen months? We don't want to get too inefficient and lazy, do we? If you let them get too high level and too bloated, they'll become a stability problem(via. no one can write a really large ap without making atleast one bug and without infinite amount of time to fix them.) Their is nothing wrong with VB but programmers shouldn't wander too far from the roots.
----

Now, that's funny!

[budalite]

That 'article' was one of the funniest (and worst) things I have ever read. Here's a summary of it: 1. "First, ... learn a programming language." (Details, always details.) 2. Find a project that "meets your standards". (Ka-ching! Standards have been met.) 3. "Seek out a programming Mentor." (Everybody sing with me: "Catch a falling star and put it in your pocket, save it for a rainy day! One more time..) 4. "Those with enough skills to successfully be trained usually have a need to earn a living at programming, and only use the software which they can convince their employers to allow them to use." (How did reality sneak into this article?) 5. "some people program to see the code run" (We just wanna have fun. May you all love what you do and get to do what you love!! Sincerely, budalite.)

Specifically...

[then, it was nigh]

This reminds me of the skit where they say "And today we're going to learn how to cure all the world's diseases and build a suspension bridge"!

Spefically, the "How to Rid the World of All Known Diseases" sketch from Episode 28. A good one indeed.
--
#/usr/bin/perl
require 6.0;

The most important thing to become a good coder

[buglord]

is practice. Code every day, always review your code, try out new things, refine your code. Rewrite your programs until they're also aesthetically pleasing. Enjoy the creative process and become part of it.

That at least is my experience. I'm a compsci student, and although I could program Delphi, Pascal, C, C++ etc because I've taken the courses I can't. I always did enough to pass the classes and promptly forgot about everything.

Now I've landed in a small dotcom and have been forced to learn Perl, PHP and SQL. I use them everyday and after a few months of practice I have ecountered all the pitfalls. The job has formed my thinking and my approach to programming a lot - and that's something you'll always need, no matter what language.

And most of all, I found out that coding is cool . My geekiness has increased enormously in the last half year!!

Re:A few things about C++...

[mrm677]

This guy knows his stuff. I agree. C++ is not the silver bullet, but it is a work-horse language for serious development. I personally think the core Java language is decent, but I don't like the idea of JVMs. The only place where a JVM is great is through the WWW, not the desktop. Why do I make such a claim? Just last night, I attempted to run a Java Swing program on my P166/128mb machine. Granted the machine is old, but it does everything else I want it to do (Linux 2.4, WindowMaker, Python, C++ development, Perl, WWW development). I was just utterly amazed at how unusable a JAVA GUI was on this machine. I would press a menu button, and the menu would gradually appear 3 seconds later!

Re:A few things about C++...

[Anonymous Brave Guy]

On the other hand, I don't think a new and better C++ will solve the problem and be the saviour that Anonymous Brave Guy thinks.

I don't think I ever used the word "saviour". :-)

But seriously, I don't believe C++ will ever be a perfect language. It has too many fundamental flaws, not least the bits it inherited from C (love those type declarations). What C++ is, is a good language. What C++0x will be, if they get it right, is a great language, which fixes many of the current version's real world problems.

Re:A few things about C++...

[Anonymous Brave Guy]

Have you used any other OO languages? Besides Java?

Um... Yep. Including most of the ones mentioned in this thread, at some point.

Because C++ is not the holy grail of OOP. I have a hard time considering it an OO language.

I never said it was, and I don't think any good C++ programmer would claim that it is. One of C++'s great strengths is that it allows you to program using multiple paradigms at once. I can write a plain old function when that's what I want. C++ isn't, and isn't meant to be, a pure OO language.

With C++, you spend time figuring out why the hell you can't get this innocent-looking line of code to work: const Foo &bar = myMap[foo];

I'd like to see a real example where you have this sort of problem, instead of some contrived (and clearly untrue) version. Enough with the FUD, please.

Then you have to figure out how to get something out of a map without using overloaded operators (I'm not a fan of overloaded operators, in any language).

To get something out without using [], just use iterators. (OK, they use operator overloading, too, but what the hell.) As for overloaded operators, they are a blessing or a curse depending on who you talk to. Personally, I've seen and used many classes where operator overloading was used to good effect, and the code using those classes was much cleaner as a result. YMMV, of course.

By the way, yes, some parts of the STL are awkward at the moment. Adding proper in-place function definitions, or something equivalent, in C++0x will do a lot to alleviate these problems.

This article discusses SmallTalk versus Java. The same can be said for Java versus C++.

I read that article some time ago. I assume you meant SmallTalk versus C++, BTW, but if so, you're wrong. C++ does not have many of the disadvantages of Java, not least a forced mix of value and reference semantics, which is the root of one of the article's main complaints.

Re:A few things about C++...

[Anonymous Brave Guy]

OK, fair 'nuff, it did come across as a bit of a rant. I'd just read yet another /. post wherein C++ was slagged off repeatedly by someone with no idea what they were talking about, and I was annoyed.

Not all of those who rail against the bloated, unevenly implemented mess that is C++ are "ill-informed s'kiddies".

That's certainly true. There are many fair criticisms that can be levelled at C++, some fixable, some not. However, most of the criticisms levelled at it around here are by ill-informed s'kiddies.

IMHO, rather than trying to pile more crap into an already bloated language, C++0x would do better to follow Hoare's (perhaps Dijkstra's - I don't remember) dicta about better languages being designed by removing things rather than adding them.

FWIW, I think many of the people involved in the standardisation process have a similar viewpoint. It hasn't gone unnoticed that everyone in the real world hates the 700+ page volume that is the C++ standard, thinks C++ is grossly overcomplicated and would like to see things simplified.

Re:A few things about C++...

[Anonymous Brave Guy]

FUD? I dealt with that yesterday. Too often you write code that you would expect to work, but have to break it down because the compiler doesn't like it, because C++ is enforcing its overly complex design on you.

Ah, I think I see what you were getting at. Was your map const? If it was, then of course you can't use [] on it, because [] creates an entry in the map if it's not already there. Whether you like the behaviour or not is a personal preference, of course, but it is correct and it is logical.

I was talking about the section on language syntax complexity.

Fair enough; over-complex syntax is certainly a major criticism you can fairly make of C++. A better syntax would be a big improvement, but I'm prepared to put up with some obscure syntax in exchange for a power of expression not available in any other similar language. This is, of course, a religious issue, though.

Re:A few things about C++...

[Anonymous Brave Guy]

Ah, I think I see what you were getting at. Was your map const?

No it wasn't! After looking at the situation for a few minutes, I was able to undertand why the compiler barfed at me. But that's exactly my point...

OK, fair enough, you've made your point, not that I don't feel C++ is unclear at times, anyway. :-) Put me out of my misery, then: what was going on that was so misleading?

Don't learn from Schdilt!

[Anonymous Brave Guy]

Don't touch Schildt if you want to learn decent C++. His books have many well-known problems. A couple of the earlier C ones were so bad that people wrote lengthy pages about them to make the point. There was a running joke that his The Annotated ANSI C Standard contained the complete text from the C standard, but was published at a fraction of the cost. This was said to represent the value added by his comments.

If you really want to know what his books are like, you could visit Amazon and read their reviews, which are written by people who purchased the beginners' books, and are therefore by definition not qualified to review them for technical merit. Or, you could do the smart thing and visit the Association of C and C++ Users web site, and check out their book reviews. These are generally regarded as being fair and accurate, and there are an awful lot of bad reviews of an awful lot of Schildt books.

</rant>

:-)

A few things about C++...

[Anonymous Brave Guy]

I like the general tone of this post, but some of the facts are glaringly wrong...

Object orientation is necessary and natural.

No, it's not (necessary). I like OO, but it is not the silver bullet that kills all programming problems. Other, radically different styles (functional programming springs to mind) have shown big increases in effectiveness over OO languages, by any useful metric you care to choose, at least in certain areas. OO is good, but hardly perfect and clearly not necessary based on the number of non-OO projects in the world.

Find me a fully-implemented Standard C++ library. There are none.

Rubbish. There are any number of them, supplied with most major compilers. What there isn't is a fully-implemented compiler itself; notable features such as export are still missing. (Don't complain; languages like Java don't need export because they don't even have generics.) Several compilers are expected to address these last few issues and reach pretty much 100% compliance by the end of this year. Don't use MSVC++ as the benchmark; it's ****.

I think part of the problem with C++ is that its standard library doesn't include all the funky (but platform-specific) toys, such as GUI work, threading, RPC, sockets, yada yada. It's a great shame that certain companies (rhymes with "bun") try to write libraries that include absolutely everything. They assume the whole world is full of McProgrammers who want to write three lines of code and draw a dialog box, and then have the library do everything else. Unfortunately, what you get is a bloated and constantly changing Java library, which has become so huge that no-one can really take it all in and make best use of it any more. Why /.ers think Java's library is good is a continual mystery to me. It's not bad, but it's hardly the pinnacle of great OO design and/or usefulness.

No one should have to implement a basic container before knowing how to use it.

True (although they ought to learn how to implement one reasonably soon afterwards). That's why the C++ standard library includes string, vector, map and other such useful classes. Why do people keep ignoring these? Worse, why do people prefer the inferior alternatives (e.g., MFC or Java containers) -- is "iterator" really that long a word? :-)

By the way, for those who didn't know already, the powers-that-be in the C++ world have started working on C++0x, the second formal version of the C++ standard. High up on the agenda is extending the standard library in ambitious terms, quite probably including GUI work, multithreading, and so on. Issues such as distributed computing (read: over the 'net) are also up for consideration.

I think a lot of people's well-worn objections to C++ are going to wear out when C++0x arrives. Then they'll have to stop casually judging a language by its standard library, and look at what you can actually do with it (including what you can do with third party libraries and stuff you -- shock! -- write yourself).

By the way, in case you're wondering, yes I rate C++. I dislike many things about it, but I retain a balanced perspective. The fact remains that, unlike many of the over-hyped toys /.ers frequently mention, C++ is used, and will continue to be used, for serious development, because it's up to the job. Few other languages can make that claim, and it constantly annoys me when ill-informed s'kiddies around here spout **** against C++ and give newbies bad info. This doesn't relate to Daniel's post particularly, I'm just trying to head off the "you're just a C++ luser" rubbish before it starts.

Re:Not a programmer but i have some questions

[qxjit]

I learned programming on my own starting in the 7th grade and now with 8 years of experience I am well equipped to code professionally (I have for the last 4 summers). The only way to get started is to do it. No matter what language you choose first, it's gong to be difficult. The second language is exponentially easier and so on. Along the way, however, there are two things I found most valuable for me. The first is variety. I have written in C, C++, Java, Python, Perl, Lisp, Basic, Visual Basic, JavaScript, HTML, XML. There are probably a few I forgot too. Now, most of these I've only written a bit in, I've concentrated on Java, C, Perl, and Lisp (in that order). But each language gives me a new perspective on programming and new ideas. This is valuable and can be applied no matter what you are writing in any language. The second thing is a good mentor. Having a mentor in the professional world is how I changed status from Hacker to Programmer. I learned about things such as code maintainance and commenting. If your just looking to hack around and play at home, this is not as necessary, but if you want to write a full blown application it becomes necessary very quickly. Hope that helps! if you have more questions, dv@nthroot.com

Not a programmer but i have some questions

[q-soe]

I will say from the start that i cant write code - i work in servers and networks, yet i found this article interesting and it has some good ideas.

I have purchased a couple of books on c++, java and perl only beacuse i support developers and i think its only fair to get some idea of how they work and i have always found my guys to be wiling to help and advise and encourage if they have the time.

So i read this with interest - dont get me wrong i would probably never be good enough to write code for other people to use but i would love to be ablw to play around in my own way and thats where these sort of tips and articles come into their own

I work all my days in an MS shop and find Linux to be something i more and more play with at home as it lets you see what is going on in the backend and what the changes you make impact on - and this article gives me some tips to start out on learning how to write apps.

My questions is in light of these posts and comments whats the best language to start with ? by that i mean will C or C++ help me develop an understanding of basic constructs and programming skills that will be portable ? IS there another language i should think about ? Am i wrong in trying to do this ?

Or am i thinking in the wrong way ? i mean i just want to learn to write code so i can see it work - not for any other reason than my own enjoyment (sounds sick doesnt it)

ideas, thoughts, help ?

Re: Tools verus techniques

[q-soe]

Guys thanks for that - i am checking out some of the sites and one of my development guys has suggested PERL as well so im going to give it and C a look and start with some of the tutuorials.

Maybe i can ask one last thing - what then is the difference between C and Visual C ?

(i really dont know that one and feel silly asking one of my guys about it)

Does VB need to be fast?

[ednopantz]

Does VB need to be fast in an environment where computing power doubles every eighteen months?

I am writing a VB database app (back end is MSSQL, 20 users) that is so fast people don't believe that it is really saving the data. I have to write a one second delay into every single save routine so people actually believe that it is working.

Sure, it isn't graphics or heavy computation, but VB really shines is in these boring, quick and dirty business apps, and those only need to be as fast as the end user.

Re:This tutorial snapped my brain in programmer-mo

[Coronado Leora]

Thank you for your pleasing review of the C tutorial as posted above.

You are indeed correct, the tutorials aren't free anymore. The excessive download rates versus the actual shareware fees received caused the original site to close down for nearly two years. The cost of bandwidth was prohibitive to keeping the tutorials alive back then. The site was operating at a serious loss.

As I "inherited" the tutorial suite this year, I decided to once again offer the tutorials online. Having done extensive research into the venture I quickly became aware of the popularity the tutorials had once enjoyed.

The cost of the tutorials today is the same as originally requested. Revenues allow me to host the site and pass a profit along to my father, Gordon Dodrill. Although he is nearing retirement, he plans to stay in the mix, update the existing tutorials, develop further example programs and write a few projects he has put off for years now.

He is excited about my having revived Coronado Enterprises and looks forward to working with me in the years to come. I'm glad to see him active in the online programming community once again, and enjoy working with him as a father/daughter team. Can't beat that!

Thank you for your support!
Coronado Enterprises, http://wwww.coronadoenterprises.com