Developing for the Linux Desktop 163
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.
Re:How about people who already know C++ (Score:1)
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 [sun.com] and learn Java/Swing, and netbeans [newtbeans.org] 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? (Score:1)
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:A few things about C++... (Score:1)
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++? (Score:2)
GLADE ! (Score:3)
kylix (Score:4)
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:C++? (Score:1)
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.
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++? (Score:1)
Hoo boy...
This is certainly true. C++ compilers are hard to write. So are C compilers.
Please back up this statement. It maps no worse than C does, given code with the same functionality.
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.
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).
As is the case with any language.
--
Re:C++? (Score:1)
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.
--
Good Article; Don't forget the Less/Non Techs (Score:4)
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.
like a Monty Python skit... (Score:1)
"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 (Score:4)
$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 (Score:1)
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++" (Score:5)
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
Learn to program in a nicer language first (Score:1)
There are a variety of languages that people recommend as a first language. My old university used Haskell [haskell.org]. 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:Whitespace is not syntax (Score:2)
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:C++? (Score:2)
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 [rutgers.edu] 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++? (Score:2)
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:Learning C++? (Score:2)
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:C++? (Score:1)
Don't worry about it, said idiot has lost shit-tons of karma.
-
Re:C++? (Score:1)
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
--
Delphis
Re:It does _not_ start out "learn c++" (Score:1)
Of course he didn't.. do you think
--
Delphis
Re:Start programming with Open Source project? (Score:1)
Re:C++? (Score:1)
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++? (Score:2)
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:kylix (Score:2)
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:Start programming with Open Source project? (Score:2)
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 (Score:2)
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++ (Score:1)
Re:GLADE ! (Score:2)
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 [mmdc.net]
Re:Question for Micheal (Score:2)
Granted, there aren't many in the OSS world right now. One gnotable exception is the GNU Visual Debugger [act-europe.fr], 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 (Score:2)
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 (Score:3)
FYI, if you ease on over to gtk.org and look at their bindings page [gtk.org], 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 (Score:1)
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 (Score:3)
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? (Score:3)
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:kylix (Score:1)
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:Whitespace is not syntax (Score:2)
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! (Score:1)
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
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!!"
Re:kylix (Score:1)
Komodo (Score:1)
Have you tried Komodo? [activestate.com]
--
Fast VB... (Score:2)
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
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 [goodnet.com] 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 [worldcom.com] - Generation Duh!
Re:Fast VB... Maybe (Score:2)
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 [worldcom.com] - Generation Duh!
Re:C++? (Score:3)
Daniel
Fixed link (Karma whore :P) (Score:1)
Try this one:
here [newsforge.com]
(http://www.newsforge.com/article.pl?sid=01/07/11
for goat phoebia
Re:like a Monty Python skit... (Score:1)
Re:Ease of Use (Score:2)
Re:Visual Basic (Score:2)
>>>>>>>>>>
He he. That explains why Outlook is so glacially slow
Re:C++? (Score:1)
seeya.
Re:Best language to write database program? (Score:1)
Delphi and OO programming (Score:1)
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.
Re:C++? (Score:3)
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.
A couple other nits: (Score:2)
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? (Score:2)
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:C++? (Score:2)
It's a pretty good introduction to C++ for people who are already familiar with basic C.
Re:How about people who already know C++ (Score:2)
For KDE/Qt, check out http://doc.trolltech.com/ [trolltech.com] and http://developer.kde.org/documentation [kde.org].
Re:Visual Basic (Score:3)
Check out:
Boa Contructor as alternative to Kylix (Score:2)
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.
Re:Series of projects to learn to code? (Score:1)
Hopefully, this would at least help you get started.
Ram Sadasiv
Re:C++? (Score:2)
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++? (Score:4)
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.
A book that doesn't suck (Score:3)
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:Best language to write database program? (Score:2)
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 (Score:1)
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:C++? (Score:2)
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:Start programming with Open Source project? (Score:3)
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 (Score:1)
Re:Visual Basic (Score:1)
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 (Score:2)
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:C++? (Score:2)
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
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:How about people who already know C++ (Score:1)
I found a little tutorial on QT/KDE programming on the KDE-Women site [kde.org].
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 (Score:3)
The gnome-python package is here:
www.gnome.org [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 [sf.net].
Re:RAD == BAD (Score:1)
RAD == BAD (Score:2)
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:/Dfor="if(false);else for" (Score:1)
Re:Read the parent again (Score:1)
Re:C++? (Score:3)
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++ [mindview.net]
You'll have to pay for these:
Accelerated C++ [aw.com]
C++ Primer [aw.com]
The Dietel & Dietel is a great pogramming book (Score:2)
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++... (Score:2)
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++... (Score:2)
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++?
Teaching my brother (Score:2)
Re:A book that doesn't suck (Score:2)
Have a look at the Qt C++ GUI library [trolltech.com] 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!
Learning C++? (Score:2)
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 [powells.com] 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 (Score:2)
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 (Score:2)
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:Good Article; Don't forget the Less/Non Techs (Score:3)
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 [sdmagazine.com] from Software Development [sdmagazine.com] magazine useful.
Re: Tools verus techniques (Score:4)
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 [comp.risks], The Mythical Man-Month, Code Complete [construx.com], Programming Pearls [programmingpearls.com], 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 [mkp.com] by Patterson and Hennessy. A hard-core introduction to programming, used at MIT, is Structure and Interpretation of Computer Programs [mit.edu] 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.
Re:Question for Micheal (Score:2)
Re:A few things about C++... (Score:2)
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:C++? (Score:2)
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:A few things about C++... (Score:2)
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++... (Score:2)
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.
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++... (Score:2)
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 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 [cons.org]. Or this [bbn.com] 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++... (Score:2)
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++... (Score:2)
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.
Re:C++? (Score:2)
One of the best and most easy to understand guides to socket programming is Beej's Guide To Network Programming [csuchico.edu]. Have a look at that, I think you will find it very useful.
Start programming with Open Source project? (Score:3)
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:C++? (Score:4)
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
--
The most important thing to become a good coder (Score:4)
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!!
A few things about C++... (Score:4)
I like the general tone of this post, but some of the facts are glaringly wrong...
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.
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.
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.