Slashdot Mirror
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.
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.
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.
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
this sig limit is too small to put anything good h
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
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.
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.
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
--
GreyPoopon
--
Why is it I can write insightful comments but can't come up with a clever signature?
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!!
-- sigs are like parking spaces - all the good ones are occupied
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.