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.
Well, this is kind of off topic... however I don't know where else to look for information on C++ that is easy to understand. Most of the material I've been reading and looking at talks about classes, structs, aliases, and stuff like that in C++. I want to learn to program in C++ very much, but I'm stuck with a very hard to understand Dietel and Dietel book that I had in a C++ class in college. As you can probably tell, I didn't really learn that much from that class in college. I wanted to pick up tihngs on my own, but I don't know where to go from. I'd love to learn to program with sockets, even maybe some X apps or somtehing of the similar, but I don't see that much documentation (well, that's easy to understand and findable) anywhere. I've been googling for the past 3 days and I'm pretty much stuck. I've been slowly working with "LEarn C++ in 21 days" but it's not that great becasue I can't understand a lot of the material at times. I'm going to continue trying (I've done this multiple time over the years, but I guess I might not be cut out for programinng). OH well, anyone that can help me along... it would be a great help... thanks.
If you want to build visually, using GTK (and on the fly rebuild your entire collection of GTK libs, giving the Gimp a completely new look), use Glade ! - it generates C, C++, ada, eiffel or perl; it ports to Windblows and it gives the programming newbie a headstart, in that it doesn't require knowledge about widget-construction or placement. The event-code you must go create yourself, though. But then there's perl (which can be easy to the eye if it wants to be) Get it at http://glade.pn.org
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'm guessing you never even made a serious try to learn it. Your loss.
Yeah, you're guessing. I tolerated the whitespace thing til I had to edit infoseek pages in vi that generated javascript. True, half the problems came from infoseek's begin/end syntax for embedded python, but it was always indent, indent, indent that had me editing and re-editing the same blocks over and over. Someone had used a tab somewhere, and I was busy hunting it down. For a language that puports to promote maintainability between multiple programmers, it certainly isn't very tolerant of differing whitespace conventions. Code shouldn't outright *break* because someone broke a coding standard of style.
If I ever get my motivation back, maybe I'll resurrect ni (stackless python, using foo/endfoo syntax constructs, my favorite form of bracketing). Or maybe perl6 will still be all I need.
Even LambdaMOO figured out the concept of using a pretty printer instead of requiring the programmer to be one.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
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
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.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Speaking as one who has to use that *** thing at work:
The IDE is pretty good, but the help has gone backwards since the last version (that I have: Office 2000).
The language is terrible. I learn languages as a hobby. I love to learn languages. I've been using that thing for over two years, and its inconsistencies are still driving me mad. And that's not the worst. Working programs will suddenly die for no reason. Sometime the only way to fix them is to export them as text files, delete the original, and re-import the exported version. And that's just incrediblly stupid, but that's the fix I finally found, and it worked!
As one who has learned Fortran II, Fortran IV, Snobol, Cobol (well, not really), PL/1, C, Ada (partially), Python (partially), Ruby (partially), Eiffel (nearly), C++ (an old version), etc. Visual Basic is the worst language I've ever encountered. It's worse than Apple Basic for the Apple II. (Well, ok, I didn't try to do as much in that. But it was learnable.) It's worse than BSDC, with all of its inconsistent and undocumented deviations from K&R C (there wasn't any ANSI C).
Please, don't anyone inflict that language on Linux. Please!
Caution: Now approaching the (technological) singularity.
I think we've pushed this "anyone can grow up to be president" thing too far.
> As for Ada, I suppose you could, but I don't know of any such applications
Granted, there aren't many in the OSS world right now. One gnotable exception is the GNU Visual Debugger, which may well become a "standard" application once word about it gets out a bit more.
FWIW, it supposedly runs under Windows too.
--
Sheesh, evil *and* a jerk. -- Jade
> Whitespace is not syntax.
Actually, it is iff the language spec defines it to be.
I'll bet the first language without line numbers raised a lot of eyebrows too.
Truth is, I came up with the "semantic whitespace" idea independently of Python, and quite a few years ago: When observing the flame wars about whether the { should go on the same line or on a new line, it occured to me that any marker that raised that kind of question probably wasn't needed at all. And the obvious solution was to simply rely on the indentation, since most people using {} languages also use indentation to show the intended semantics at a glance (as well they should).
I'm still thinking about writing preprocessors for my favorite languages, so I can show my semantic scoping by indentation and let the preprocessor translate it into bracketized syntax.
--
Sheesh, evil *and* a jerk. -- Jade
> I respect your opinion, but it doesn't really matter whether or not you like C++ if its is one of only two options for Linux desktop programming.
FYI, if you ease on over to gtk.org and look at their bindings page, you'll see that in addition to C there are 4 other languages with bindings described as "complete", plus a number of others that don't merit that flag yet.
--
Sheesh, evil *and* a jerk. -- Jade
The steps in this article are not that far removed from learning any type of coding. Personally I'm more involved in the PHP/ASP scripting world, but most of the points regarding the learning process in this article would apply equally well. Swap Advogato for Evolt.org and talk about base server setups and scripting environments and you're there.
What I did find interesting, are the comments regarding mentoring. I've found that this role is normally taken by several people - it's pretty rare that someone will become an exclusive mentor to one person (imho). My experience is that often a small group of people (often within an online community) are seen as mentors to a fairly large group of people. Perhaps this is different in the more rarefied atmosphere of applications programming and Free Software / Open Source.
"Give the anarchist a cigarette"
A little planning goes a long way...
Am I the only one to think that an Open Source project is not the best way to learn programming?
I sure hope so. Most people learn to program by studying and then modifying the works of others. Open Source is ideal for this.
Programming is not only difficult, it requires a particular kind of thinking.
For the record, programming is not difficult. But you are very correct in that is does require a particular kind of thinking. Being able to think in the way needed for programming is difficult. It's like calculus -- taking the derivative is the easy part. The algebra leading up to that step is where most of the people make their mistakes. Anybody can program. Very few people can think properly.
I forget who said it, but it's something about "standing on the shoulders of giants". Without having other programs to read and learn from, very few programmers would be programmers today. Open Source is a great way to learn about programs and programming. It is far too daunting for the beginning programmer to maintain an Open Source program, but they can still learn from it. Even experienced programmers can still learn from Open Source. It's just good all around.
then it comes to be that the soothing light at the end of your tunnel is just a freight train coming your way
That bothered me for about 30 seconds before I got over it and realised that the language is highly advanced.
Now I'm writing it professionally.
I'm guessing you never even made a serious try to learn it. Your loss.
In other words, you are not going to write something that is CPU intensive in VB like Quake or mr. mega encryption program.
.o files lingering around. You can almost watch the compilation process happenning, if you point Explorer to the directory as you compile.
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 is a perspective correct texture mapping spinning cube engine - please don't email me about it - I don't support it anymore (nor do I use VB anymore at home - work is a different story, unfortunately - but I am doing more Java work here now anyway). But it does show what is possible.
Also, at one time (heck, it may be included in the ZIP) I had a custom scanline renderer (ie, the inner loop of the texture mapping routine) done as a C DLL that I called from the VB program, that dramatically speeded everything up - it was my intent to make the whole triangle texture rasterizer a C DLL, but I never got around to it.
So - it is possible to do fast things in VB - since the time I wrote that app - many other people have done even better things - many involving DirectX or custom routines. I have seen some amazing stuff - too bad it is M$ - I have since long ago moved on to Linux...
Worldcom - Generation Duh!
Reason is the Path to God - Anon
Actually, the limiting factor on the VB cube is the fact that I was only using the GDI SDK calls for everything - the bottleneck is basically the low-level 2D Win32 SDK GDI interface. I am certain that it is more than possible to do great stuff in VB if one goes the DirectX route - DirectX and the video card then would be doing all the heavy lifting.
But hey, that is the way it should be - why should someone have to learn arcane graphics secrets to create a game - they should be able to concentrate on the design and gameplay of the game, and not the underlying low-level stuff. Considering that hardly anyone does low-level graphics engines anymore (what I mean by this is creating engines translating x/y/z coordinates in proper 2D screen coords and doing lighting, etc) - most concentrate on the higher level stuff. That doesn't mean one shouldn't learn the low-level stuff - it is useful knowledge. Just don't expect to use it a lot (though there are a lot of instances of it being useful, just to understand what DirectX or OpenGL are doing, for example).
You are right about 486's and C - I remember several good cube demos done on such equipment. And most certainly, things are going on in the background of that VB program - at minimum, it has to keep checking for messages from the OS, just for the event driven stuff.
So, I am not saying VB is the be-all/end-all of things. But it can be damn good at some things (and actually, if you drop the texture mapping, and rely on straight GDI drawing primitives - line, filled poly, etc - you can get mongo speed - I know of one dude, Jerry Chen, who created an awesome 3D library called Dex3D - I may have a link off the site - ultra-high speed with that). It really excells in the RAD area for business apps - which is something Linux needs.
Worldcom - Generation Duh!
Reason is the Path to God - Anon
Its not a C problem, it is a Linux problem. Linux isn't an OS, and thus must use separate libraries to provide services that are normally standard in Win32. For example, GUI internationalization is a standard part of Win32, but on Linux, it comes in the form of Pango and other libraries. That's where you dependencies come from. Even in Algol, those dependencies would still be there.
A deep unwavering belief is a sure sign you're missing something...
I`m not suggesting write kernals or games or drivers in vb. But for either knocking up demos, or for writing apps where speed isnt too important (stuff like Outlook, or a front end for anything, really), why bother with C/C++? Its just a waste of time. ;)
>>>>>>>>>>
He he. That explains why Outlook is so glacially slow
A deep unwavering belief is a sure sign you're missing something...
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.
Am I the only one to think that an Open Source project is not the best way to learn programming?
;)
;)
Probably.
An Open Source project is the ideal place to start because you can look at what others have done.
You're writing KHelloWorld and don't know how to open a window? Just look at a simple other KDE application to see how they did it.
And, of course, you'll get help from the people on the mailing lists.
Of course, nobody is suggesting you start by joining kde-core-devel and rewriting the IPC subsystem in kdelibs.
Start your own project - something simple (maybe displaying your user ID in a window or such) that can be extended as you learn more features.
This message is provided under the terms outlined at http://www.bero.org/terms.html
You'll want to start at the documentation supplied with the desktops.
For KDE/Qt, check out http://doc.trolltech.com/ and http://developer.kde.org/documentation.
This message is provided under the terms outlined at http://www.bero.org/terms.html
Check out:
This message is provided under the terms outlined at http://www.bero.org/terms.html
Check out BOA at SourceForge as an alternative RAD GUI IDE development environment for visual appications.
It's got much of Delphi's feel, but is based on Python, and has a good interface going to things like Zope.
I think it may be a good free alternative to Kylix.
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 ?
A class in Systems Analysis and design will tell you that you never start off thinking about the implementation. The first thing to do is to figure out your entities and relationships between them, design _everything_, and _then_ pick a language/platform/whatever.
:)
That said, my current personal favourite for cross-platform database-backend stuff is the combination of PHP and PostgreSQL. Using a web interface is completely cross-platform, and I personally think this combination is fast and enjoyable to the programmer. It's easy to maintain as long as you comment your code
PHP always seems to have everything I need, including both Perl and POSIX-compatible regexp syntax. And the online, user-annotated manual is a great reference, as is phpbuilder.com.
MySQL is fine for an obscenely simple project, but for any reasonably complex data (ie, anything with at least a one-to-many relationship), I'd recommend something like PostgreSQL. The database should be ensuring data integrity for you with foreign key constraints; you shouldn't have to do it yourself. And subselects are very nice to have. Again, the online manual is quite good.
I started off learning from a PHP+MySQL Webmonkey tutorial (many online tutorials are terrible WRT security, including this one, so watch yourself), and ran from there. I'm currently rewriting the site for our student newspaper in PHP and PostgreSQL. It's mostly complete; check it out here:
http://trw.umbc.edu
I'll be releasing the code on freshmeat.net as soon as it's reasonably done, which should be right before September.
Sotto la panca, la capra crepa
WMBC freeform/independent online radio.
"Most people learn to program by studying and then modifying the works of others."
:-)
Not exactly, in my experience. I find the structure is more like:-
1) Copy programs from a textbook, and modify them to work out how each bit behaves.
2) Write stuff yourself, from scratch, see what you've learnt in action, and imprint what you've learnt deeply enough that it comes naturally.
3) Look at other ppl's work to see if there's any little tips and tricks to pick up.
But most of your real learning is in stage 2. It's like learning to improvise in music - you can copy other ppl's improvisation as much as you want, to get an idea of how it works, but unless you actually do it yourself you'll never learn it!
An open-source project may be useful for stage 3, but it's certainly not the place for 1 (which is learnt from a beginner's textbook), and 2 is done entirely on your own.
I'd agree with you on programming being easy, but then we're programmers. For Itzsak Perlman, playing the violin is easy, but I personally am never going to play to that level! It just requires a certain innate ability to follow things through logically, which means it's fairly inclusive, but everyone knows a few ppl who couldn't use logic to save their lives! (and the Darwin Awards show a few of those in action
Grab.
"bad habit(which generally they are such as global variables, multiple return points within a single function/procedure, etc) "
:)
No different to C! You can do all of that in both languages!
Speed isnt important for a lot of programs, outside of the tiresome world of game framerates, and server throughput. Some people still spend their time making 2d graphics cards run faster. Faster than what? Oh, faster than `fast enough`. Strange.
I`m not suggesting write kernals or games or drivers in vb. But for either knocking up demos, or for writing apps where speed isnt too important (stuff like Outlook, or a front end for anything, really), why bother with C/C++? Its just a waste of time.
I learned (68000) assembler first, and after i did a bit of C, i couldnt stand to go back. Now i`m doing VB, and the idea of doing tedious low lever stuff like string manipulation in C, now i`m used to :
MyString = "File " & sFilename & "from drive " & !drivename & "is " & nSize " bytes."
strikes horror into my heart!
The gnome-python package is here:
www.gnome.org.
The package includes lots of simple example programs which are easy to read, and handles calling the init functions for you.
There are more tutorials on using python to create Gtk apps here.
This is probably going to be moderated down, but still I think many people can associate with the folloing babble.
I've met a few developers who are completely ignorant about OS and process-level stuff.
I see a trend where people start in a RAD environment languages like VB and VB script, and now Java and Kylix without any fundamental computer concepts. They've never developed in lower level languages like C. They do not have even slightest, general understanding of microprocessors, RAM, stack, heap, pointers, memory allocation/deallocation, memory leaks and so on. IMHO anyone starting out in a RAD environment without understanding of computer primitives is contributing to a trend of writing poor quality software. How many colleges and universities are out there who do not require their students to take C or assembly classes as prerequisites for higher-level languages? The common result is a clueless CS or IT degree graduate (in addition to most establishments' ignorance about their students' real knowledge; heck, my university didn't even provide computers in the classroom ).
The most important concept they are missing is that a computer is a state machine.
Many languages today encourage black-box approach to programming which hides state. For example in some languages objects contain methods that are executed in a sequence that a programmer is not encouraged to track. Which method is doing what at any particular point in time of the execution is not known. Furthermore, some languages like Java for instance, are shipped with a boatload of libraries that hide the plumbing. This leads to assumptions about what those libraries really do, and again poor code.
Often it is simply impossible to imagine what is going on in an OO program at run-time at any particular point in time. Not understanding how the resultant code works down to machine basics leads to hard to find bugs and poor quality and bloated software. I am not even talking about deep technical knowledge down to bits, but one should be aware of state of your application on an OS or even process level even if your language of choice doesn't require it.
It is not to say that RAD should be avoided at all costs, don't get me wrong. RAD environments and bundled languages are there for short time-to-market developement of software. This is justified because programmers are always more expensive than hardware. Nevertheless, a RAD programmer will write better code and design better software with the understanding of the lower-level plumbing. Experience with low-level languages should be a must for success with RAD-type environments and languages.
I love the Dietel and Dietle "C++ how to program". There are alot of homework assignments in it and they do teach more about good software engineering practices then actual c++ commands but that is a good thing.
In the real software engineering world you need good highly structured and easy to read programs. Especially if you work in groups. Alot of IT managers don't want someone who just knows how to type in the programming commands but they want someone who knows good software engineering principles. I am taking a slow pace in the book. I guess its how fast your school is going through it. At the Manhattan community college they only go through half the book a semester. Because it is intense. There are just too many code examples and homework assiggments to type in from the book. Also I actually type in the code they use in the examples so I can understand what they are talking about in the book. You should try this. Practice makes perfect.
I also tried part of the "learn c++ in 21 days" a few years back in highschool. I peaked at it recently and looked through the table of contents and relized its total crap. They teach you a few commands and not good structured programming or methods. For example how do you list the contents of a 2 dimensional array? The answer in the Dietel and Deitel book is to use X amount of Arrays nested in each other. WHere X is the amount of dimensions of the array. WIth the "Learn c++ in 21 days" you may learn the keywords for union or structure but you do not learn how to solve the multidimension index array problems.
If your college only uses part of the dietel and dietal "C++ how to program", then perhaps you shouldn't be a programmer. Programming is hard stuff and good talent is hard to find. They also work like maniacts. If you want something easier try "Visual Basic 6 how to program". Its kind of boring for a techy like me. I loved learning operator overloading for example. VB is more basic but it has its niche market as a quick programming solution for bussiness.
Try to look at it as power in which you can use the awesome power of your computer to do anything. If that deosn't appeal to you, perhaps you should change your major because the IT industry is for of people who live eat and sleep with this stuff. Oh, and by the way I have serve dsylexia and mild autism/aspergers so if I can learn from the book, almost anyone can.
http://saveie6.com/
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 :-)
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++?
My brother had never had a computer until three years ago I bought him one when he went back to University. The first technical thing he learnt was creating HTML pages. Then he moved on to Director and learnt lingo, but only very basic stuff. Then a couple of months ago I started to teach him JScript for use in ASP. This was a good place to start I think, because being a scripting language it doesn't need any complicated compilation. There's no need to learn about data types. The syntax is close to C and Java. And it's possible to do something relatively interesting without too much coding. This is similar to the position BASIC used to play. Except that the step from BASIC to most languages is quite a big one, unless you go to VB, which is obviously a mistake!!
Ho hum for the life of a bear
He's right. Thinking in C++ is helpful. And the electronic version is free. This book is not complete, however.
It is important to know that none of the books are complete. The biggest hurdle to becoming a programmer is learning to accept, and make sense of, poorly written documentation.
All the books that I've seen make object orientation seem much more difficult than it really is. Am I in a position to know? Yes. Powell's bookstore here in Portland, Oregon is the biggest bookstore in the world. I've spent hours looking at all the books there about C++.
The technical publishing world has become very corrupt. Publishers know that people find it difficult to evaluate a book while they are in the bookstore. So, a publisher who provides a poor quality book with big promises on the cover will sell books.
Remember to stay in control. If a book doesn't make sense to you, consider the possibility that it is the fault of the book, not you.
Bush's education improvements were
Micheal,
Being so opposed to developing desktop applications for the Linux desktop using C++, what would you suggest starting out with? Last time I checked, C and C++ were the two best choices for building fast, robust GUI applications (bindings for scripting languages not included), just as this article says. That is, of course, unless the largest Linux desktop players _aren't_ GNOME and KDE, as I've been led to believe.
I respect your opinion, but it doesn't really matter whether or not you like C++ if its is one of only two options for Linux desktop programming. That being said, I feel its a bit unfair to imply that this article may not be worth its salt because it is simply stating the facts.
Nick
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.
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?
Your pizza just the way you ought to have it.
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.
Your pizza just the way you ought to have it.
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. :-)
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. Or this page for more pointers. I will be honest, however, and admit to sometimes coding small parts of programs in C to improve performance. With the emphasis on small. :-) I do think Smalltalk wins hands down as far as anything I know for GUI, but particular Lisp implementations needn't be all that bad; I use Lispworks, and I don't think I'd say that I think GUI building is any harder in that than in a typical C++ or Java environment. I do think you may underestimate how suitable it is for "industrial strength" applications, though. Hang out in comp.lang.lisp for a while (or better, search the archives) and you will discover those who have built very serious, very large apps in Lisp, in part because of its suitability for such projects.
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.)
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.
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.
--
Rome taught me patience and assiduous application to detail. Virtues which temper the boldness of great, general views.
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.