Slashdot Mirror
Open Source Project Management Lessons
cpfeifer writes "Paul Baranowski takes a moment to reflect on Open Source Project Management in his blog. His reflections are based on the first two years of the Peek-a-booty project." Interesting comments on media coverage, choice of programming language, when to release a project, and more.
Story was just released to subscribers and already it's loading slow so here's the article text for when the inevitable /. effect comes:
Peekabooty - Lessons Learned
By Paul Baranowski (paul@paulbaranowski.org)
July 1st 2003
Here is a review of the first two years of the Peekabooty Project. Over that time I have had to re-evaluate many of the things I learned in university and in the working world - many of the engineering lessons that I had been taught turned out not to work so well. The project management of an open source project is very different from old-school engineering project management, so I had to learn a lot about how open source project management works.
All of these problems have been seen before - by no means do I see these as unique. They are simply more data points on the "How To Do Open Source Development" graph.
What did I learn from the first version of Peekabooty?
Open-Source Project Management Lessons
Don't release before it does something useful.
This lesson is recounted in Open Sources: Voices from the Open Source Revolution as well as other places. I had even read about this rule before we released, but I had to learn it for myself. If you release too soon, you spend a lot of your time answering emails instead of developing.
The press is a tool - more like a hammer than a Swiss army knife.
The press is like a hammer - it can help you or hurt you, depending on how you use it. But like a hammer, it can't do everything, like cut a tree in half. It has limited capabilities and you cannot expect too much from it.
How the Press has Helped
The press has helped to bring awareness to key people that have the ability to help the project grow.
Press will get you more downloads. Whether this is good or bad depends on lesson #1.
Press will not get you more developers unless #1 is in place. The fastest way to get more developers is to network with other developers.
How the Press Has Hurt
The press loves infighting because it's a good story. However, the infighting story is bad for a project that is trying to get funding. This creates an air of instability. People only like to fund things they feel will have a high chance of success, and instability erodes that confidence.
95-5 Rule
Usually it's the 80-20 rule, but in open source projects it's more like the 95-5 rule. Open source projects are usually run by one or two people doing most of the work. If you decide to lead an open source project, you must be willing and ready to accept this. If you want to lead an open-source project, it helps to be independently wealthy. This allows you to forget about things like a job and work on the project you want to work on. In hindsight, wouldn't it have been better to take a really long vacation instead? Doh!
Engineering Lessons
C/C++ is no longer a viable development language
This may seem obvious to some people, and other people may recoil in shock. In college/grad school we were taught to believe that C/C++/Java, etc are the best languages in the world, so it was a very difficult transformation to accept that these languages are not viable development languages for application level work.
C++ is seen to be great for execution speed, static binding, object orientation, templates, and more. However, it is absolutely lousy for development time. Here's why:
It requires compilation - as your code grows larger, the wait time to see if your code works increases. This delay directly affects how fast your code is developed.
It's really, really, really hard for people to learn it, and this directly impacts the number of developers you will have on an open-source project.
It uses static binding (Isn't that supposed to be a good thing?)
There are no standard libraries for C++, so there's a lot of reinventing the wheel. (Yeah, there's the STL and ot
I have often regretted my speech, never my silence.
-Xenocrates
Just a suggestion.
The peek-a-booty project is a lot less interesting than I would imagine...
This is a rule in "traditional" project management too.
and the other lessons read just like Project Management 101 too. I would have loved to have seen something insightful or interesting about how open source changes the development environment or the management environment from single location to distributed, but no such luck.
Food not Bombs is a nice platitude but it breaks down when you notice that the Bombees are usually well fed
Anyways, this project has made me think that there's still hope for everyone to be able to have freedom one way or another.
I think the only thing about peek-a-booty was that people were afraid it would open a pedophilia flood gate. This really pissed me off as obviously the juornalists behind these stories hadn't actually taken the time to investigate the actual software. Instead they just brushed over it and made assumptions, hence the bad press.
Anyways, great program, I mean it. I think the fact that it's created by one of the worlds largest trojan creators (cDc) is what gives it such a bad wrap.
Ignore the "p2p is theft" trolls, they're just uninformed
Personally, I dig Common Lisp.
I first heard about this project from a BBC Article where they describe it as a "browser free from censorship or outmoded intellectual property laws," which is something I think we can all get behind! However, they made the point that the project could have been better named.
It seems the author has picked up on that now, too. I think most telling is this passage from the author's blog (weblog):
Hopefully, he'll take these insights to heart!
Consensual sex is boring.
I'll take the inevitable off topic karma hit. But after three or four years, when does this get old? Christ, 99% of the time, the lame ass AC's that try this don't even get first post.
It requires compilation - as your code grows larger, the wait time to see if your code works increases. This delay directly affects how fast your code is developed.
It's really, really, really hard for people to learn it, and this directly impacts the number of developers you will have on an open-source project.
It uses static binding (Isn't that supposed to be a good thing?)
There are no standard libraries for C++, so there's a lot of reinventing the wheel. (Yeah, there's the STL and others, but each one has a huge learning curve associated with it).
So, basically, it has to be compiled (duh). It's hard to learn (no, it's hard to use correctly) and it has no libraries... eh?
I'm sorry, but this guy is not a software developer. The usual comments about "X is the One True Language" notwithstanding, I can't follow that because he thinks it's "too hard" and he thinks it's "not viable" and decides that it simply isn't a good fit for his project, then LanguageX must be dead. Perhaps he'd like to share with us which language his OS is written in. Maybe it's Forth or Scheme. Use the right language/runtime/lib/technology for the job and refrain from saying "X sucks because I don't like it".
Other than the dubious "this is how you do open source" slant I can't see how this article is even worthy of news.
I remember him saying something in a bar once about Scheme. Man, I think he's trashing your language. Are you going to take that shit? Them's fightin' words, if you ask me.
Often time this principle applies to people on the project, not just the software being developed. I've learned from experience that really sharp people with a broken user interface can destroy a project!! You have to try to minimize interaction points with folks like that and find where they can excel and use their talents without creating problems for the others on the team. A difficult nut to crack at times and a far more critical factor to project success that the programming language, source management tools, etc...
Most of this seems pretty basic to me. I wonder what he was doing in "university and in the working world" that didn't teach him these things.
And I really wonder what language he suggests. If not C/C++/Java, then what? VB?
I wish he had spent a little longer on this. I realize it's just a blog, but it would be nice to see some insight into OSS management vs. the alternatives.
Everyone knows that once your code compiles, it will work!
Interesting that viable languages weren't named, just ones the author decided weren't viable for him.
In no way do I believe that open source distributed developement should all take place in perl/java/php/whatever. Code should be written in the best language for that particular code. The Linux kernel is coded in C(or is it C++?), maybe someone should tell Linus that C isn't a good language for an OS project.
There are no standard libraries for C++, so there?s a lot of reinventing the wheel. (Yeah, there?s the STL and others, but each one has a huge learning curve associated with it).
This is a huge error that casts doubt on the author's credibility. What is commonly known as the STL is the C++ standard library, and it has been since C++ became an ISO standard in 1998. Doubters may consult books like the clearly-named "The C++ Standard Library" (Josuttis, 1999) to get themselves up-to-date.
Maybe that's just another drawback of C++... a lot of people don't know what the hell they are talking about and thus repeat misinformation?
... but, regarding 'which language / db to use', maybe his site is an example of why NOT to use MySQL?
/usr291/home/drunkenm/public_html/pbhtml/includes/ sql_layer.php on line 131
/usr291/home/drunkenm/public_html/pbhtml/includes/ sql_layer.php on line 131
/usr291/home/drunkenm/public_html/pbhtml/includes/ sql_layer.php on line 131
/usr291/home/drunkenm/public_html/pbhtml/includes/ sql_layer.php:131) in /usr291/home/drunkenm/public_html/pbhtml/mainfile. php on line 45
/usr291/home/drunkenm/public_html/pbhtml/includes/ sql_layer.php on line 543
/usr291/home/drunkenm/public_html/pbhtml/includes/ sql_layer.php on line 543
/usr291/home/drunkenm/public_html/pbhtml/includes/ sql_layer.php on line 543
/usr291/home/drunkenm/public_html/pbhtml/includes/ sql_layer.php on line 543
/usr291/home/drunkenm/public_html/pbhtml/includes/ sql_layer.php on line 543
/usr291/home/drunkenm/public_html/pbhtml/includes/ sql_layer.php on line 447
/usr291/home/drunkenm/public_html/pbhtml/includes/ sql_layer.php on line 543
/usr291/home/drunkenm/public_html/pbhtml/includes/ sql_layer.php on line 447
/usr291/home/drunkenm/public_html/pbhtml/includes/ sql_layer.php on line 543
Warning: Can't connect to MySQL server on 'localhost.addr.com' (61) in
Warning: MySQL Connection Failed: Can't connect to MySQL server on 'localhost.addr.com' (61) in
Warning: MySQL: A link to the server could not be established in
Warning: Cannot add header information - headers already sent by (output started at
Warning: mysql_fetch_row(): supplied argument is not a valid MySQL result resource in
Warning: mysql_fetch_row(): supplied argument is not a valid MySQL result resource in
Warning: mysql_fetch_row(): supplied argument is not a valid MySQL result resource in
Search
Topics
July 2, 2003 Create an account
Warning: mysql_fetch_row(): supplied argument is not a valid MySQL result resource in
Warning: mysql_fetch_row(): supplied argument is not a valid MySQL result resource in
Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in
Warning: mysql_fetch_row(): supplied argument is not a valid MySQL result resource in
Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in
Warning: mysql_fetch_row(): supplied argument is not a valid MySQL result resource in
>All logos and trademarks in this site are property of their respective owner.
Comments are property of their posters.
>You can syndicate our news using the file backend.php or ultramode.txt
No offense Paul, but if your code was easier to follow it'd probably be a lot more favorable ratio. Might have even made C++ a viable choice. I do a lot of open source work in C, and have had no problems at all -- old timers (like myself) know it as the lingua franca of the *n?x world, and younger folk know it as most of C++.
Not mentioned is the final langauge they used. Is the code in C/C++?
I do agree with the binary protocols vs. text protocols, but I'm not sure that is a recent revelation. Most of the Internet protocols use text based protocols.
It is hard to back the statement up with an "absolute" truth thanks to the fact that you will always choose your tools according to the task at hand. You can't say that language X is better than language Y when both are generally ment for different things.
Oh, and C/C++ are still viable options, but don't dominate the market as much as they used to.
This is the kind of project manager who is really qualified to pass on experience to others.
The same goes for the 90238502934823 sourceforge projects that never got past the FAQ stage of the project. I want to take advice from them!
Wow, beek-a-booty: that well-known highly important open source project. Who would rather learn from the managers of, say, Apache or Linux or PostgreSQL anyway? Teach me how you managed development of PEEK A BOOTY!
June 14, 2003
Dear diary,
I have decided to record my thoughts on managing the project "peek-a-booty". The most important lesson I've learned is not to use booty in a project name!
Sure, it was funny two years ago after a few beers, but I swear the next person that makes a "booty" joke will die. I'm serious. "Dude, is it for peeking up skirts?" "Hey, if you integrate telephony you can call it 'peek-a-booty-call'"
In other news, I'm starting a new project to manipulate network traffic, this time using Java. I'm thinking of calling it 'jAck Off'. I like the sound of that. It will be good to get that whole 'booty' thing behind me...
C++ is still a very viable language. I have not seen that many Visualization or Gaming Apps written in anything but C++. My only dislike of C++ is it's syntax. I personally think it is one of the ugliest languages ever. However, I do not let that beleif stand in front of the fact that it is still very useful.
Not only did you FAIL to get the first post, you also FAILED to even get modded down in reasonable time!
What kind of a lame FAILURE are you?
Well, I rather disagree with him on this point... particularly regarding C++.
There is, indeed, a standard library for C++, one which is widely supported - STL. Is there a learning curve? Sure. And you're going to tell me that there isn't a learning curve for any other language, library, or whatever? Please.
I started at my current job a bit over 15 months ago. I knew only the basics of C++, and nothing at all about the STL (or even templates). It took me about a week to be comfortable using the STL, and I could read the code instantly -- there's nothing radical about it.
Are compile times long? They can be... particularly if you need to compile from scratch or change one of the base libraries used. But on modern hardware it's not a huge issue, and consider how much time you'll end up saving users because it's not an interpreted or pseudo-compiled language. Yeah, I like Perl and Python too, but they're not suitable to really large projects, particularly if you need them to scale very widely.
C and C++ are most certainly viable development languages. Let's see now: Linux, BSD, GNOME, KDE, Apache, Mozilla. Even Perl, Python and Ruby are written in C or C++. But maybe the author is saying those projects aren't viable...
Use the right language for the job. If all you're doing is interfacing to a database, then a scripting language may be the most appropriate. But if you're writing system software, then by all means stick with C and C++ with some shell glue.
Compiled languages are damned convenient to the user. "Here's an executable, just run it", versus, "here's a script, go download compile and install the interpreter first, making sure it's the correct version, set up your environment variables correctly, then run the script."
A Government Is a Body of People, Usually Notably Ungoverned
Friends don't let friends make lame posts.
This is your brain,
This is your brain doing lame posts.
Only you can prevent lame posts.
Give a lame post a change.
Where are the WLPs (Weapons of Lame Posts)?
There are no lames posts here. All the lame posts are being killed as I speak now. Praise Allah that we will roast the bellies of the lame posts.
Funny! Oh wait he was serious?
What are your thoughts on using straight C?
He disparages both C++ and Java as open source development languages, and I agree with his comments on those.
But, besides the compile time issue, straight C seems to me like a good bet. It's such a basic programming language, that it'd be hard to find anyone who programs that doesn't understand the C language. The basic libraries are very standardized. Good debuggers exist. Etc. Etc. Etc.
Any thoughts?
C/C++ is no longer a viable development language
... Ever heard of protocol layering or data marshalling ?
Sure, in the scope of this particular project and in the context of their skillset and development practices.
Don't Use Binary Protocols for Application Development
Bah, I'm speachless. Yeah, right. Better yet convert data to PNG images and pass those along - it will allow you to debug networking layer with a web browser
With all due respect, it looks like Mr.Baranowski either learnt wrong lessons or likes to summarize things beyond reasonable limits.
3.243F6A8885A308D313
Duh, if, say, 4 AC's all try and get the First Post, only one of them will succeed. The rest are FAILURES, which means a FAILURE rate of 75%, with only 25% actually getting the First Post. So you are quite correct, most AC's are FAILURES.
Simple, really when you think about it.
It sounds like he busted his ass on a project no one appreciates because it is generally useless.
they would just call them facts.
"C/C++ is no longer a viable development language..."
"not viable development languages for application level work."
"...It's really, really, really hard for people to learn it."
"...There are no standard libraries for C++, so there's a lot of reinventing the wheel. (Yeah, there's the STL and others, but each one has a huge learning curve associated with it)."
So in otherwords it's shocking that the programmer has to know something about the tool, platform, domain, etc. to be able to code? G~A~S~P!!!
What's the number one complaint of almost all end users to a product? Code bloat and speed . Sorry to tell you this but if your complaining about compile times then you don't have much of an option when it comes to execution speed of the same said program being compiled.
BSD is designed. Linux is grown. C++ libs
When you want it to die a miserable death.
Modern C++ is a wonderful language, at least I think so. But it is much different than the "old" C++, almost to the point of being a different language. So if you've had bad experiences with C++ in the past, perhaps you should give it another look. And C++ is not dead, there are a lot of interesting advancements in the language, and more properly how to use it. There are a whole lot of generic programming and template patterns which are comming out which show that C++ has a lot more power than people ever thought.
Of course C++ does tend to have some problems with Open Source projects, which C usually doesn't have. So I certainly don't frown on C development either. And plain old C is usually very easy to integrate into other languages/environments.
However, C++ is certainly still alive and very viable on a whole. And O'Reilly just published the new C++ in a Nutshell book which covers the ISO standard C++ very well. Also you should look at the Boost Project if you're looking for more advanced C++ libraries (many of the Boost developers actively participate in the C++ standardaization effort, and Boost is often thought of as the testbed for possible language additions for the next round of standardization).
But I do agree, that you need to pick the language according to the project. There is no one best language. When I look for other open source projects with the intent of being able to take advantage of the openness (i.e., modify the code), I tend to look for projects written in Python. I particularly avoid Perl, becuase it is much harder for me to understand. I also avoid Java because it's a proprietary language with no open source JDE/JDK and I think the language sucks when compared to ISO C++. But again, those are my preferences.
Talk about irony, isn't peek-a-booty one of those programs that allows everyone on the internet to (ahem) "open source manage" your computer for you? From the same people with the "system administrator tool" Back Orifice?
I don't understand why this would "piss you off." Any sort of p2p anonymizing software is bound to be exploited not only by political dissidents but by pedophiles and anyone else with an agenda that is reviled in the mainstream. Is there any specific mention on the site of "anti-pedophile" filtering in the program? Any built-in means of policing the users of one's own node? If so, then it's useless for its intended function because the government could simply operate a bunch of nodes and snoop the traffic (which they will probably do anyway if this ever become popular - which brings up a point about this needing at least two levels of encrypted redirection, but that's not my focus here).
So if it's secure, it's going to be used by pedophiles and probably lots of other people you wouldn't like - so what? Isn't the entire point of combatting censorship to give voice to everyone no matter if you agree with their agenda or not? I see no need to be defensive about someone pointing this out; if that is their argument then they obviously embrace censorship and are, therefore, among the very people this software is intended to help others overcome.
what you say is true.
But having to spend time in Purify or Valgrind is not fun...
You should be good with C++ which includes having a knowledge of pthreads, the Standard Template Library (STL), and templates.
Plus the thing only runs under windoze or under WINE...
It's not hard to pick up C, or be able to read a C program.
It IS hard to write a large slab of C code that works, is relatively bug-free, easy to maintain, easy to add features to, and easy to 'understand'.
This is why starting a large-scale program in something like Python, and just rewriting the bits you need in C (for speed), is a GOOD idea. Thankfully, languages like Python make this easy.
> It seems the author has picked up on that now, too. I think most telling is
> this passage from the author's blog (weblog) [peek-a-booty.org]:
No where in the blog does he say that. Prove me wrong and show me _EXACTLY_ where does
he say that?
Karma whores.
There is, indeed, a standard library for C++, one which is widely supported - STL.
I don't think that's what he meant by a "standard library". He's thinking along the lines of Java's standard library -- a standard library that gives you graphics classes, networking classes, XML parser classes, GUI classes, etc. You know, the kind of stuff that would be convenient to have bundled with a language. STL is a standard library full of basic data types like linked lists and hash tables. Big whoop.
forgive me if memory fails, but doesn't python require tabs or whitespacing in certain ways as part of its syntax requirements? i HATE that shit. i have a b.s. in physics, fortran is lingua franca among physicists, i refused to learn it (among other reasons) because of it's lame-assed spacing requirements. i think alot of other people feel the same way.
not to take away from your point, which is valid, just an aside picking on your particular choice of language for your example. =)
You can be an atheist and still not want to succumb to some weird cross-over sheep disease -- AC
So, after two years he still hasn't realized the importance of documentation?
"Document it and they will come."
A good project is nothing without it...
I am not a very active coder, nor will I ever be. Coding is just something that does not come naturally to me. However, I thought that for the most part, C/C++/Java were still the big "players" in the application development world (scripting's a different story). So I would like to know what this fellow suggests for a good language to start projects in?
"Hell hath no fury like a woman scorned for SEGA. ..."
http://goatee.net/2003/07#_02we-a
Design By Committee: "...Yes, you understand me correctly, I'm more worried about the size and character of the community than the actual technical issue."
It's the perfect caption for the goatse.cx link.
As a rule, people who bitch about whitespace in Python are the people who have never coded in Python. Hate it if you like, but you sound the fool when you bash something you admit to never having tried.
Everyone complains about the indenting before they actually see how it works. Just try it once. You may find, as I have, that your indentation does not change at all. The only difference is that you get to drop the braces around your code blocks.
One wonders what he would consider an appropriate language. Which language is easy to learn, doesn't use static binding, isn't compiled, doesn't require a separate download, and has a standard library?
... for me to POOP on!
- Insult Comic Troll
Compiled languages are damned convenient to the user. "Here's an executable, just run it", versus, "here's a script, go download compile and install the interpreter first, making sure it's the correct version, set up your environment variables correctly, then run the script."
Amen. When I'm trying to solve a problem, I like using high-level languages like Perl or Python. But when I need to write an application that I want ordinary users to be able to download and _just use_, I don't have a choice - I have to write it in C or C++.
Luckily, thanks to faster processors (shorter compile times) and tools like valgrind to detect memory errors, programming in C and C++ isn't nearly as bad as it used to be.
No offense intended, but personally I find proper whitespace to make code much more readable. In many cases I find it to be more essential in code than in written English (I take this to be on account of the fact that English is so redundant already, whereas every single symbol means so much in code).
When I'm going through another person's code, it is very irritating to me when that person is a member of your (space|tab)-hating philosophy. Indentation does help with readability.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
Well, not only this, but also he says in the FAQ for the project:
Contradictory ? Yes. To make it even funnier, his project is only made by him and two contributors (what a big project), and to tap it all he recommends you being wealthy.
I would rather read what other people have to say on OSS management (say Linus, RMS, folks from OpenOffice, Mozilla, JBoss, etc.)
As a rule, people who bitch about whitespace in Python are the people who have never coded in Python.
Uhm, yeah. Isn't that what I said? And "looking the fool" is neither new to me nor anathema.
Sorry, but I really dislike languages where what you do with your whitespace is part of the syntax. It's a gimp requirement.
You can be an atheist and still not want to succumb to some weird cross-over sheep disease -- AC
no, I don't think bundling that is particularly convienient... indeed, I think that it's more convienient to have a choice and not have things like that tied tightly to the language.
Right now there are well established libraries in C++ for anything you get from standard libraries that are tightly integrated... just with multiple competing established libraries. A wealth of choices.
There is no standard GUI library that ships with all compilers. That will come, but not before it's time. Java gives such a library... too bad it sucks.
-pyrrho
It does no good to make a statement like that
Yes, it does some good.
The first step in finding or creating a better alternative is to clearly define exactly how the current language is bad.
Having suffered for years under C and C++, I've lately becomed enamored with Python. I believe it solves a lot of the problems he describes.
"Provided by the management for your protection."
So it's either C, or Java (lately). Anything else is considered as scripting (Perl, Shell, SQL).
As much respect as I have for the project and its developers, his broad, sweeping statement to the effect of C/C++ is no longer a viable language is really telling of his ignorance and lack of perspective. Which is too bad, since there are other points he makes that are useful lessons.
To claim the fundamental implementations of all modern OSes (Windows, almost every single UNIX, Linux, and the plethora of other OSes) to be "no longer viable" is way beyond reproach: it's just plain idiotic, and does significant damage to the credibility of his other points.
Unfortunately, my that-was-ridiculously-stupid meter flew off the scale when I read that point, so I stopped reading right there.
*sigh*
Y'know, this seems to be the one thing that people who have never tried Python latch on to as a reason to dislike it. I'll grant that it takes a bit to get used to, but it really is quite comfortable and makes things look clean. Besides, writing readable code requires decent indentation and most IDEs auto-indent anyway, so it's not like you have to go to all kinds of extra effort.
Basic explanation: Python doesn't use {} to denote blocks, it uses indentation. 4 spaces is the convention, but as long as all lines under the parent are indented the same, it'll accept it (1 space, 4 spaces, 15 spaces, doesn't matter as long as they're the same). You can even have, say, two for() loops at the same level, one whose block is indented at 4 spaces and the other whose block is indented at 7.
</rant>
Mark Erikson
I don't understand what's so difficult about C++, espc. if you know C.
C++ is a multiparadigmed language. You don't have to know everything it offers because you also won't want to use everything it offers in any given project, indeed, you will find there are certain paradigms available you will never use. Is that difficult?
If you know C you should at least like C++ to use to create constructors for structures that clear the structure, or to create functions with more than one form of argument input, etc.
I frankly don't understand the problem.
-pyrrho
As an interface designer and technical writer, this has always been my personal mantra. It's finally nice to see that at least one engineer finally actually gets it!
;~)
You probably won't believe how many MMI designers and technical writers are feeling totally vindicated at this point.
Really, it's not often one sees history in the making.
Words to men, as air to birds.
Actualy, if you are about to set out on a new project, its probably best to tell yourself that you are NOT willing and ready to accept this.
6 years ago I started a project called GeoTools and it was, for the main part, excactly that - two people doing most of the work. This was fine for a few years but over time the user/developer ratio got out of hand.
Eventualy it became all but impossible for the two lead developers to support 300+ users and although other developers wanted to contribute it became dificult to 'train' new developers as the knowledge of how things worked existed mainly in the heads of only two individuals who had done 95% of the work.
Two years ago we took the descision to re-design the toolkit from the ground up with as much input from as many people as possible. Since that time we have strived to make sure that as many people as possible have an input into the design process and we keep that process as open as possible by pubishing the IRC sessions in which discussions take place.
The project now has 9 very active developers who are members of a Project Management Committe and a number of other active contributers as well. The end result is that quiries to mailing lists get responded to far more quickly.
Getting other people to work on your project is often - TO START WITH - more effort than just doing the work yourself, but the pay off is HUGE, as you then have someone else who can explain things to others.
If you ever have a contributor who gets stuck or confused and you find yourself thinking 'oh, it will be quicker/easier for me to do this part myself' STOP. Spend the time, help them work out how to do the modification even if it takes a few hours when you could have done it yourself in minutes becuase after you have invested the time in them, they will be able to add things in minutes too, and they can teach others as well.
If you work on a tight, well defined, non-evolving project then most of my ramblings are probably irelelevent if not they they may be of use. The only danger is in investing time in helping developers who then wander off - it happens, but I tend to find that the more you invest in them, the less likely they are to loose intrest.
Spell checker (c) creative spelling inc. (aka my dyslexic brain)
Okay , you
dont't
have to
like using whitespace
so
others can actually
read your code, but
I like the
way
Python lets me
do the
right
thing.
Do you also hate having to end lines with a semi-colon? Or having to use braces as block delimiters? Why is indentation such an onerous syntax requirement when you gladly comply with other languages' rules?
*chuckle*
point taken
You can be an atheist and still not want to succumb to some weird cross-over sheep disease -- AC
I wonder what are the /. editors thinking when they allow this kind of non-sense published on their front page? Ruining their own credibility? I read /. for years everyday, every hour and sometimes they simply loose it. Can't believe.
EVERY good developer knows that circunstances are EVERYTHING. Methodology XPTO was good for project X because of (a), (b) and (c) factors. BUT, methodology ABC was very nice for another project because of (1), (2) and (3). Same goes for technology. C/C++ is overkill for web applications? Fine, get J2EE. Java is overkill for embedded devices? Fine, get assembler. Clearcase is too expensive? Fine, get CVS. RUP is overkill for 4 people team? Fine, get XP. And the alternatives goes on and on.
I am literated in almost every mainstream language and technology that is out there. My personal web site is in PHP (because I made it in a weekend as hobby), but my job requires both J2EE and .NET. But some things I do for SAP requires plain old ABAP. I still like to program things in Python and for quick things I don't mind using VB and even good'ol Delphi. When I am logged in my linux instalation I can do plain old Perl as well, and everything works fine, thanks. And unlike the zealots, I do fine with Windows. Even do VBA sometimes. I don't like ideologies: too much time spent discussing for no profit.
For those that only know hammers, every problem looks like nails. For me, every problem has simple solutions: and I just solve it. Period.
C'mon /. editors, even you use those gorgeous Apple notebooks (I like them). How can you allow such low level material?
Cheers.
You over simplified. As he said, static bindings are both a blessing and a curse.
...X, with or without Altivec), N *nix bases (Sun, HP, IBM, Linux*M, BSD*3)*(2+ GCC versions) = well over 10 popular platforms], you either have to manage binary chaos or you have to start distributing your code as source.
...) is usually harder than installing Java.
For example: Oops, sorry. Mozilla on Linux is now being compiled with gcc3.2 so you'll have to get the source and recompile to run on that older (gcc2) system... Also, your old plugins will need to be recompiled before you can use them with Mozilla on the new system - if you can find the source.
Compare and contrast:
Java - install the compatibility VM; use the same binary on all platforms
C - no VM; compile and distribute different binaries for each platform
As the number of platforms increases [3+ Windows code bases (9x, NT, newer), 3+ Mac bases (system
But wait! Distributing code as source requires the end user to install the compiler, and this (setting up environment variables, binary compatibility, support libraries,
So, we're back to square 1.
Lose a turn; don't pass "Go".
So much of what is said about C++ here on slashdot looks to me to be fear, uncertainty and doubt I find it ironic.
The complaints about C++ are the kind of complaints users make about linux when comparing it to Windows. "It's much easier to click on a big E than to learn another icon..."
And clearly he's talking about GUI libraries... instead of multiple good C++ and C based multi-platform GUI libraries, he prefers another model, more like javas, where you get one crappy library and save yourself a lot of thinking!
If anyone cares about the quality of the software (more than their experience developing), they'll learn to use a good compiled language, period. If you can cut corners on quality, if you buy the idea that CPU cycles are here to waste, then use something lesser (I do in that case). However, I think we are wasting cycles, and there are some amazing things our software is not doing that it could. Moore's Software Law is that every 18 months software gets twice as inefficient doing the same thing.
-pyrrho
i was forced to learn pascal in high school, and quickbasic in college. having learned and thouroughly disliked those languages i came upon C and was joyous. semicolons and bracers make sense out of one's code. but hey, it's just my opinion.
You can be an atheist and still not want to succumb to some weird cross-over sheep disease -- AC
I very much agree with him: C/C++ are no longer viable for rapid development.
;-)
Personally, I prefer Ruby, but Python is almost as good of a choice. (
It's also quite easy to do mixed-language development with Ruby were you write the bits that need to be fast in C/C++ and you write the rest in Ruby (Swig can also help out here). This way you get the best of both worlds. The nice thing about doing this with Ruby is that classes and modules are always open, so a class originally defined in C++ can be extended (you can add methods to it) on the Ruby-side - in fact you could even do this at runtime if you so desire.
None of the lessons learned and reported here are directly related to Project Management per se. They are all by and large implementation issues.
There is also nothing new here. This does not advance the state of the art. History does not advance by people relearning the same lessons again and again. Just because they have been reported here does not make this article special in any way. This article could have been written in any of the decades of 70s, 80s, 90s (substituting en vogue languages for C++/Java) and still make sense.
In order to truly advance the state of the art, we have to think in far more advanced ways about project management and software development. True Software Practice and Experience requires much more planning and critical thinking than evident here.
If Open Source is to provide a useful and stable platform on which to build, then we certainly need a better vision of how to build software. Otherwise, we will be doomed to repeat history by implementing old things in different ways and not really gaining any control over complexity.
In summary, we still have a software crisis; Open Source will not change that; and summaries of software development experience that just say "I made the same mistakes as other people did" are not very helpful.
"Document it and they will come."
A good project is nothing without it...
Good point; somebody should document this.
Java is the blue pill
Choose the red pill
I've heard about Oracle's "wonderful" (cough cough) C code. I don't think it's worth bragging about. C++ would be an improvement.
The shit(tab thing) you HATE makes my life as a programmer easier and codes I should read and write more elegant.At first I thought just like as you do, but once you get accustomed to it, there's no way out. ;-)
He says C/C++ is unacceptable because it takes too long to learn? That's news to me. I wrote my first useful programs after a single college-level course. It was less than a full semester, so call it two months.
Were I recruiting developers, I'd want them to have spent significant time learning how to program well (regardless of language). I also want people who are willing to invest some time, both in the project and in their own skilset. If an applicant only knows some "easy to learn" language like Visual Basic, I don't think I want him working on my project.
The Linux kernel is coded in C(or is it C++?), maybe someone should tell Linus that C isn't a good language for an OS project.
I don't think too many people will dispute that C is probably the best implementation language for an OS kernel that must be fast. However, C/C++ are not appropriate for all projects. And in fact the subset of projects where C/C++ are the best fit is probably fairly small (a lot smaller than current use anyway).
I recall meeting an older sw engineer who used assembly language for everything - in fact some of his colleagues were telling me that he did some kind of web programming project in assembly (ran very fast, but took a long time to develop and debug. Now I tend to look at the "C/C++ are the best languages for every project" folks as falling into a similar catagory as this assembly- language-everywhere guy.
The dynamic languages like Ruby, Lisp/Scheme, SmallTalk deserve more of a look when starting a project. They tend to accelerate development (especially when compared to C/C++ or even Java) so much that they deserve a closer look.
And, in Ruby for example, it's quite easy to do mixed-language development where you develop the parts that need to run fast (typically no more than 20% of your code) in C/C++ and develop the rest in Ruby. Because in Ruby classes and modules are always open, you can extend (add methods to) your C++ classes in Ruby (you could even do this at runtime if you so desire) quite easily. I've done this on some very speed critical projects with very good results (with positive results in both schedule and runtime).
His point that this is not unique to OSS Projects is a good one. While OSS development has unique constraints most are around people and personality. In an office we all have to get along or get fired, in OSS it can sometimes be worse.
...The program should be fun to work with. There should be buttons and things that blink. The interface should be the first thing you do. The interface serves as inspiration and motivation and helps you to learn how the final product should look. Yes, it's going to change a lot. Yes, it's going to have to be rewritten multiple times. Yes, it will never be good enough...But when someone downloads your program they will have something to do. No one likes to look at command lines.
For example:
The press loves infighting because it's a good story. However, the infighting story is bad for a project that is trying to get funding. This creates an air of instability. People only like to fund things they feel will have a high chance of success, and instability erodes that confidence.
It is too bad on so many mailing lists ego/attitude/personality or just plain rudeness show up. Things you would never say to a coworker, make it onto a mailing list for eternity, or at least what looks like one. I hope people take this point to heart before posting.
95-5 Rule
Usually it's the 80-20 rule, but in open source projects it's more like the 95-5 rule. Open source projects are usually run by one or two people doing most of the work. If you decide to lead an open source project, you must be willing and ready to accept this.
Looking at sourceforge I see this lesson again and again. The idea that if I create it they will come, and build. Forgotten, or unknown, is that nearly all had a real need to be built first. I needed application ZAFDE so I built it. I then released it and people thought they could build on it, and so on.
I wanted to learn C++ or JAVA or XYZ is the reason we have 2,134,931 notepad applications, not OpenOffice.
C/C++ is no longer a viable development language
I knew we would see a flamewar as soon as I read it. My thoughts:
- Both are still viable. Much like his hammer analogy, they are not good for everything.
- What makes them "bad" for development, makes them "good" after they are developed.
Does it matter to the user that it took 81 minutes to compile? Nope, they have the binaries or compile it once and run it for years.
Every language has a shortage of people who know it. Or specifically a shortage of the people who know it and are willing to work on OSS project PDQ.
Static binding is good/bad/sometimes both. Yes it is.
All the negatives he spoke of are positives after it is developed. Which we hope is long compared to the time spent developing it.
If there is one thing projects should take away, it is probably this:
Interface is Everything
I like command lines. I use them, but I understand they are power tools. Most people do not like/use them and consider them an indicator of a poor product. Even while it may not be technically true, perception is reality in this.
Ui Matters - It's The Most Important Thing!
Ui Matters - It's The Most Important Thing!
Ui Matters - It's The Most Important Thing!
Ui Matters - It's The Most Important Thing!
I guess that's why Microsoft OWNS the desktop.
Well, seems to me that SMTP, NNTP, HTTP, etc are easier to develop for because they are textual.
HTTP may be just about the ideal balance: use text for things which tend to be small, but capable of sending a large payload (e.g. a PNG image which the protocol just needs to wrap, not do anything with) in binary.
The thing about protocol layering and/or marshalling is: do you have good debugging tools (at a minimum, log what is going across the wire and be able to interactively enter data and see results)? For binary protocols like TCP and IP, largely yes ("telnet" client in the case of TCP; tcpdump for both TCP and IP). And maybe some RPC packages have these kinds of thing (I haven't used them enough to know). But an app which rolls their own binary format generally doesn't.
I doubt that the company that requires you to install three different JVMs with their product is the best to take advice on how to use different programming languages from.
Programming can be fun again. Film at 11.
C is a must when performance is of big importance. If the program structure and APIs within the program modules are designed properly and in a clean way, I don't think it is much more difficult to maintain and improve on the code.
A "mixed" C/C++ approach is probably worthwhile using when the program has extensive GUI requirements and performance is still top requirement. Use C++ for the GUI (qt, wxWindows or whatever gui library you like) but for the performance critical parts and the algorithms that are in the heart of the program just use plain C under simple C++ class wrappers if at all (no abstract classes, overloading, etc.). Personally, I have found this approach quite useful.
However, designing things in C++ and doing it properly is damn tough; many designs may seem easy to begin with, but then run into trouble with things like multiple inheritance from related parents, or simply that encapsulation is difficult because of the need for exposing the inner workings of classes... STL fixes some of this at the expense of code bloat -- it is easy to produce executables tens of megabytes in size.
Another problem with C++ which has been bothering me, and I would presume, the developers of Peekabooty, is the tendency towards static compilation and inclusion of everything. I looked at the source files here, and the sheer number of include-files compared to source files indicate that this probably does not compile quickly.
There is a way around this, if the application can be divided into several major and fairly independent components which then are compiled and linked as a number of dynamical libraries (.DLLs on Windows, .so on Linux and Unix). Now, with proper design, recompiling the whole lot is not necessary for smaller changes within one of the parts where no changes in this part has taken place. The trick here is encapsulation: do not let code in any one part know about any of the internal structure of code in any other part.
SIGBUS @ NO-07.308
Out of curiosity, on what platform without a C++ compiler does Oracle software run?
C and C++ are definitely viable development languages, but I prefer Perl for my projects. Perl and CPAN let you develop apps incredibly quickly. Distribution isn't an issue on UNIX machines - pretty much every UNIX box has perl on it nowadays. And if you need your app to run on Win32, you can ship the same script and all you need to add is one 340K DLL.
Once you use Perl, it's very difficult to go back to other languages.
[shameless_plug]For an example of a large open-source project visit milkbone.org[/shameless_plug]
The comments here (which I strongly agree with) show very clearly that the author's opinions were not well thought out and/or expressed poorly. Yet it shows up on /., since it had one of the magic ingredients, an OSS connection...
The vast majority of OSS projects have one lead developer and a couple of contributors. Linux, Apache, OpenOffice, etc. are the exception, not the rule.
I'll go off on a different track than the other responses I've seen...
:-/
Wouldn't python suffer from roughly the same problem as Java with the JRE? I mean, unless it's compiled (and I'll admit right now, I don't follow python closely enough to know if it has a "compiler" yet), users are going to need to find and download a Python runtime environment of some sort. The latest I've found at python's web site is around 9M. While that's still about 1/3 what a JRE is, it's still either going to be a separate install, or a lot of additional weight to package up with whatever you're distributing.
It would seem that anything interpretted is going to suffer the "separate download" problem... Ease of learning would also be debatable for probably every language out there. I know folks who are wizards with C/C++/Java/perl/$language1 who could couldn't get a working "Hello, world." out of $language2, while at the same time I know others with the skills in $language2 who couldn't do anything in $language1.
It's a shame the linked article's author didn't address what WOULD be an ideal language to use, and enumerate why, but it's probably because any language he did pick would end up sharing criteria with his "these make C/C++/Java bad" statements.
"The urge to save humanity is almost always a false front for the urge to rule." --H.L. Mencken
He disparages both C++ and Java as open source development languages, and I agree with his comments on those.
I don't -- at least not his comments concerning Java.
At one time (before they were bundled) people had to download a web browser if they wanted to view a website. I don't recall any webmasters who felt that they shouldn't work in HTML because people had to go and download a browser in order to view it.
Every software project has prerequisites. Some projects require external libraries, others require external runtime environments. If you code an Open Source project is Perl, I'm not going to be able to run it on my OS/2 systems without downloading the Perl runtimes, for example. The only way to avoid this is to statically compile everything you need into a native executable which, once again, isn't going to work for people running on a different platform(s) than what you're building for. Now they have to go through the pain of installing (and possibly paying for...) a compiler, and then modifying the code to make it compile on their platform of choice.
If your application does something useful that people can't otherwise do, they'll take the one-time hit and download the Java Runtime (or any other project prerequisite).
I think this is a non-issue. As the administrator of a Java-based Open Source project that targets client-side Java (The jSyncManager Project), I can say that using Java hasn't inhibited the growth of my project significantly, as it provides value that people can't get elsewhere (namely, a single application and plug-in architecture that can run on any Java-enabled system, which allows organizations in heterogeneous environments to run the same application on all their platforms, reducing maintenence costs). As such, people who need this sort of value have no problem taking the one-time hit in installing the proper prerequisites.
Yaz.
Or you could add dynamic binding to C++. Wasn't that the idea behind (XP)COM? Anyway, if MS changed the compiler for IE, they wouldn't have this problem.
Visual Basic.
no!!! :-)])
scriptlanguages are comming,
it is all well known(faster development, cool maintaince if your code is good sorted, less code,
less problems to import somethings, [to use it
pythons set of commands is much cleaner,
but perl rules !!! for various reasons.
one is the leck of python like whitspace terror.
perl is more about freedom than eny other lang.
larry written enough(postmodern) about.
perl(6) is always a step ahead(look at php). it seems to learn much faster then other lang, of cource it is older but remind TCL is much older than perl but no step ahead. i believe that
perl 6 will be great cause i enjoy everytime
to read about, it will be in many things ahead of anything(read http://dev.perl.org/perl6//). perl has i great community. this provides a lot of exchange(cpan is easy). haskell is cool to but slow(for a use in apps) and not often used, so you have to fight for yourself. and lua too lighweight for apps. ok some people like python more, and tcl is'nt dead, but script languages will become more important for most apps.
like using high-level languages like Perl or Python. But when I need to write an application that I want ordinary users to be able to download and _just use_, I don't have a choice - I have to write it in C or C++.
.EXE file", Python can do exactly what you need. You can turn your app into a single directory worth of files (all necessary DLL's and a standalone .EXE - no interpreter installation required) using Py2Exe. Most ordinary users are capable of downloading and decompressing a .ZIP file.
Uhhh... unless you mean "when I need to produce a single
Yeah, the guy is trolling, but so are most of the C++ fanboys here.
C is already a nitch language, no question. Device drivers, embedded, and legacy Unix code only. Just because Bill Joy used it 20 years ago doesn't mean it's cool anymore.
C++ is still viable, but it's basically "Only Use It If You Have To". Such as when performance is a consideration, or you are trying to deliver a shrinkwrap "native" desktop app.
And even in the desktop department, MS is shifting over from C++ to C#, and most MS devs will follow. In 5 years, C++ is going to be religated to legacy code and a small market of high performance server apps.
You obviously are not a Macintosh user.
Design the interface. Get user feedback to make it better. Keep your application focused on one simple task per window. Design it so it requires very little documentation.
Only unix geeks like to read man pages. Most users will *never* look at your documentation until they have no other choice.
The most important documentation you'll ever write is in-line, so you and other developers know what the code is for. Second to that in importance is the design and feature documentation. User documentation should be a subset of the design documentation re-written from a workflow view. If the user documentation is long, your workflow is complicated and your application is a pain to understand and use.
Many reasons:
There is no better than C++/ASM, xDDD (Java is worse speed)
open4free
Java - install the compatibility VM; use the same binary on all platforms
MOD UP!
+5, Funny!
I'll grant that it takes a bit to get used to
I'm not even willing to grant that. It takes less than five minutes to get used to, and with a decent editor, it's not even an issue. Most people who like to look at their code five minutes from now use some form of structure - python just enforces the idea, without even being too rigid.
if something:
<tab>do this
<tab>do this
then do this
It's too easy. Only a fool would be confused.
Google for Py2Exe.
That takes care of the windows users. Most other platforms are unlikely to have problems with installing a python distribution (I don't know if there's a Py2exe equivalent for Linux binaries).
(One of my personal bugbears. No-one can agree on the right number of spaces to indent by, it's hard to keep exactly the right number, and it looks silly when you code in a proportional font, as I like to. But if you use a single tab for each indent level, then everything Just Works; in many editors you can set how you want the tab to appear, and they're granular enough to be easy to get right.)
In fact, it sounds as if the indentation thing is to Python what the one-button mouse is to Apple: something that's actually not a bad idea in context, but which people get hung up about so much that they can't see through it to the important stuff? (And which is bound to be mentioned by trolls every time the subject occurs...)
Ceterum censeo subscriptionem esse delendam.
VBRUN100.DLL0 .DLL...
VBRUN200.DLL
VBRUN300.DLL
VBRUN40
And if you need your app to run on Win32, you can ship the same script and all you need to add is one 340K DLL.
I'm not buying that. DLLs don't launch themselves, and Win32 doesn't launch your specific DLL when you click on a file with an unrecognized extension. There must be more to add than just one DLL.
Once you use Perl, it's very difficult to go back to other languages.
Once you've seen the obfuscated perl competition code, it's very difficult to take it seriously, and incredibly easy to move to a similar-scope language, like python.
Actually, he mentions the STL by name.
Jesus saves and takes half damage.
You're forgetting just one thing, he lumps Java with C/C++
Jesus saves and takes half damage.
Java - install the compatibility VM; use the same binary on all platforms
.NET...
I'm laughing so hard Dr. Pepper is spewing out my nose! Let me wipe off my screen...
Trying to get Java applications to work on my Solaris workstation is a nightmare. I can't understand it because the company that makes Java makes Solaris. I try to figure out what the problem is, and hidden way deep in the README is this thing that says I need to install a different version than what Sun provided with Solaris. I fix that and it still doesn't work. Looking deeper into the problem, I see that I need a couple of other components that didn't come with the application. After about two hours of searching for the "myleetclasses.jar" and "ubercoolstuff.jar" files, I put them in a directory, fiddle with the CLASSPATH variable, and finally get the program up and running. And then it crashes five seconds later.
you either have to manage binary chaos or you have to start distributing your code as source.
Binary chaos is a pain. A royal pain. So I distribute my code as source instead. Easy. Painless. Users that don't want to compile can grab a prebuilt package from their distro or another repository.
Of course, I'm writing Open Source, and not cheesy shareware. Perhaps that's the true niche for Java and
A Government Is a Body of People, Usually Notably Ungoverned
-
Existing C++ code in Oracle products has already raised serious portability issues.
-
Oracle RDBMS is one of the first products to be ported to a new platform, often before the official release of the new platform. At the time of porting, a C compiler will be available, but a C++ compiler may not be.
-
C compilers for 64-bit platforms are far ahead of their C++ counterparts.
-
C++ compilers on some platforms are immature. It's far easier to write incompatible C++ code (than C).
<disclaimer> My views; not those of Oracle. </disclaimer>The Mozilla C++ Portability Guide also restricts use of some key C++ features (rtti, exceptions, templates (which rules out the STL by the way!)).
Not so! SCO owns the core patents on Open Source design methods. Its sad to see that criminals like the author of this article continue to infringe on our patents. We plan to file a lawsuit against Mister "Baranowski" (if that is his real name) in the next few days. Try to understand, we're just trying to protect our intellectual property.
Chris Sontag - Senior Vice President and General Manager, SCOsource
Absolutely
One of my personal bugbears. No-one can agree on the right number of spaces to indent by
And Christ, what a retarded thing that is to have a religious issue over!
Anyway, python doesn't care. Spaces, tabs, whatever, just so long as you're consistent. If the line is part of a block (something you would put inside braces in C), it should be indented more than the line just before the block (and subsequent lines should match).
It's hard to deny the simplicity of code like this. If you've programmed in almost any language at all, this is pretty much intuitive. The only problem I can see is if people are using different editors where one expands tabs to spaces, and the other doesn't, and they're continually updating the same blocks. Using any decent text editor cuts out this problem though.
This sig is part of your complete breakfast.
I agree that whitespace makes code much more readable (I'm anally retentive about indentation).
I just can't accept whitespace as a required syntax element of the language.
Delphi compiles a lot faster than C++.
First, STL has so many different implementations on so many platforms. Whoever has wrote a program using STL on Solaris and has to rip the heart out of their code when porting the application to Windows knows what I am talking about.
Second, C++ sorely misses two important standard libraries:
1. A GUI library.
2. A multithread library.
Third, C++ still doesn't use Unicode throughout. And the heart of this problem is: C++ doesn't have a standard string representation! There is C string and the STL string, and STL string has multibyte string and unicode string...
Fourth, to a lesser extend, it doesn't have a standard garbage collection library. I don't think all application needs that, but it's invaluable in many occasions.
Now I know all of these problems have solutions in C++, but the point is they are not standard.
I'm working on a project for central user management on a popular network appliance. At present there's only one commercial solution (that I could find/google) available that lets you manage n+1 of these appliances at once.
I initially looked at the problem and figured, heck I can do it easily with expect and ssh, but then I started thinking about how my employers & co-workers would use it (I contract), and realised a command-line application wouldn't suffice.
So I started pondering how I could integrate a fairly simple backend (that could be implemented by scripting languages) with a portable interface.
I could either:
I eventually chose the tcl/tk option, because of the following reasons:
So I ended up choosing a well-documented language for implementation, which has the benefits of being portable, interepeted (no compiling), and easily updateable (email the latest script). Sure it isn't the sexiest solution, but it works and is easy for new developers (the project will be open-sourced when ready) to pick up on where its at.
Man watching 6 MSCE's around a sun box, looks alot like the opening scene's of 2001:space odyssey...
So he wants a language that's easy to learn yet has access to a huge library base, doesn't need compiling and yet can give performances equal to a native binary? Oh and it has to be cross-platform.
Speaking as someone who is muddling along with his own OSS project (I know it's a shameful plug but hey), it is never going to be easy. Not only are you trying to write that perfect app but you are doing it as a hobby essentially, so you can't be working on it 24/7.
I would like to know exactly what he thinks will replace the troika of C/C++/Java when it comes to writing Apps, either server side or client. C/C++ are both robust well tested languages that have been used to build everything from OS's to Office Suites to the most complex 3D Animation tools while Java has come into it's own as a server side language.
I'm in two minds about his statement on the Interface. Yes a well designed GUI is essential to the success or failure of an App. either OSS or CSS. However if the backend don't work then the front end is just so much fairy dust. Looks pretty but doesn't do anything.
Well that's my uninformed ramblings on the subject. If you do look at my code remember this, at the moment its ugly as sin and doesn't do much. But sometime in the future it could be something.
Contradictory ? Yes.
Yeah, it's called "Lessons LEARNED." In this case, he developed/managed a project in C++. He learned that it was the wrong thing to do.
Personally, I can't believe it, but hey, I've written a lot of stupid things on the spur of the moment (this message probably counts).
I like the STL and I like c++, but I'm not a progammer by profession. that probably makes a difference.
Don't get so defensive! I was asking. I was pointing out that he doesn't try to make a recommendation, or to defend it in his blog.
There are other languages he could be thinking of: Obj C (as another poster pointed out), Perl, Python, Ruby, *Basic, shell scripting, Applescript, Ada, Fortran, Cobol, Smalltalk...
I asked about Visual Basic because it seems the most likely - for all the reasons you mention. I wouldn't write with it, but I don't use Windows and I like to be able to run my programs :)
There are going to be disadvantages to anything he might suggest. But ultimately, I'd like the guy to have actually said what his preference would be at this point. Rather than for Slashdot to bicker defensively about our chosen language being insulted.
I don't think that's what he meant by a "standard library"
Then why did he explicitly mention the STL?
that gives you graphics classes, networking classes, XML parser classes, GUI classes, etc
Oh, you mean all the OS specific stuff that is horrendously outdated rapidly or is so generic as to be devoid of features and richness? Yeah, shower me with that stuff.
STL is a standard library full of basic data types like linked lists and hash tables. Big whoop.
Uh... yes, it is a big whoop. If you don't think so, then might I recommend Pascal? You can even build your own string data type and manipulators!
Oh, btw, the STL does not contain hash tables. GNU's STL has them, but they're an extention to the STL, not part of the actual STL.
As for why it actually is a big deal - the STL is designed, first and foremost, for efficiency. When you ask for a vector you have guarantees about how it's implemented, how efficient certain operations are, and so forth. This is key to an efficient program, and particularly for embedded programming (which was a consideration for anything in the core C++ language or the STL). The same cannot be said for Java, C#, Perl, Python, etc.
I'm not recommending that you use C++ for everything... that's just silly. But for large programs that have to consider execution speed as well as development speed, it's one of the best bets out there right now.
For distributing Python apps under Windows, I like to just copy the installed Python runtime environment and include that as a subfolder to the Python app. The app is started using a .BAT file (py\python.exe main.py). This makes it easy to change the installed source. This takes up less than 2.5M. The equivalent py2exe binary takes up about 900K.
It would seem that anything interpreted is going to suffer the "separate download" problem...
Both of these methods gives the end-user a completely self-contained Python app, no extra downloads needed. It is also possible to do this under Linux.
Ease of learning would also be debatable for probably every language out there. I know folks who are wizards with C/C++/Java/perl/$language1 who could couldn't get a working "Hello, world." out of $language2, while at the same time I know others with the skills in $language2 who couldn't do anything in $language1.
I don't agree, I think it is pretty obvious that different languages have varying levels of abstraction. I have an MSc in Computer Science, and 10 years of professional experience writing hard real-time apps in C + an RTOS. There's no question that C (/C++) will be around for a long time, because for low-level programming you just have to have control over the CPU. But this comes at a pretty high price. Most of the C code I've seen is hard to read and understand because there is so much "plumbing" going on for simple stuff, like managing lists of objects, etc.
About 18 months ago I decided I wanted to learn Python, and I started the Freevo project. Freevo is almost exclusively written in Python, and it has turned out to be a really good choice. Some examples:
As I said, C/C++ will be around for a long time. But for many new apps that I write, I find that Python lets me write them in 1/10th of the time compared to C (that I know very well). Python also has an amazing ability to work on the first try. I'm sure others have similar experiences with other higher-level languages such as Java, Perl, Ruby, etc.
Freevo - Linux Multimedia Jukebox
Don't saddle your wide-appeal product with a narrow-appeal name like "Peek-a-Booty."
[
If end users complained about "code bloat," would anyone buy MS Office?
Honesty. Loyalty. Kindness. Laughter. Generosity. Magic!
Python can be embedded into an application very easily. Yes, this generally adds about 1-2MB to your application size. However, if your application uses enough of it, the python itself is exceptionally compact, especially if you pre-compile the python (it precompiles to a byte-code which can be manipulated like other python types, and then executed at will).
Even though the 'default' behaviour is to have separate python files, I believe it's possible to embed a 'psuedo-directory' of python modules into your application, 'tricking' the python interpretor into thinking it's just another part of the filesystem.
As a side note, naming rule #2 should be:
When I grep Usenet for mentions of Pan, I have to filter out a lot of false positives because the word "Pan" is so common.Had followed these principles, maybe he wouldn't be so bitter.
Actually, the 1.3.1 US JRE for Windows is 5 MB,
a fair bit smaller than any python environment.
-I like my women like I like my tea: green-
But Python code is so ugly it makes me
pine for Basic.
I'd rather become a politician than a Python
programmer.
-I like my women like I like my tea: green-
An alternative is to use something like schlep or Bigloo as a C code generator and try to be functional instead of OO. You'll wind up learning more about pointers to functions and C declarations than you ever wanted to know.
In short, C is good if you can make it work and follow the two main rules of programming:
Oh, BTW, did I mention that C doesn't really do exceptions that well, either?
So, take a look at Cyclone from Cornell, which is a lightly improved C. If that was a viable commercial product, it would be really viable.
Which in turn makes it impossible to read the code.
Exactly.
-I like my women like I like my tea: green-
At least with a Mac tower (unlike a laptop) it's
reasonable to just buy a proper mouse, with
three or four buttons and a wheel. Python, on
the other hand, is hopeless.
-I like my women like I like my tea: green-
Based on the incredible revelation that C is no longer viable we shall be starting a new project, RUBIX: re-write the Linux kernel in Ruby.
'Course, we won't release anything on SourceForge 'till it works... rule #1.
It doesn't suprise me that you're clueless and you go to UIUC. I knew a lot dumbfucks when I went there. I don't know how it ever got such a good reputation.
Signed an NDA yet?
Personally, I feel the key point is extendability. In the end you have some real program code doing the 10% of an ap that is performance critical. That is probably in C or C++. It is easy to call out to this in Perl/Python/Ruby or whatever. Also what Perl in particular has, is CPAN. Some algorithms may be suboptimal or non-portable (not everything there runs on Windows), but it is axcellent starting point.
We don't really need VB on Linux, what we need is for someone to come up with a better IDE for what we have.
See my journal, I write things there
FIRSTOS POSTOS!
You are almost a text book example on how to do things right.
See my journal, I write things there
I do agree he should have mentioned what he would use on the project now - to find out what his preference was (hey, maybe instead of VB it was Delphi/Kylix?).
I also think it is funny the bickering on /. over C++ - I don't think it is the tool for every job. It has its place, but large scale apps can take a long time to create and debug in C++, and he has a point on the compilation cycle (which is another thing I like about VB - the ability to just make a change and run the thing. Then, when you are ready, commit to the full compile). Sometimes, the best thing to do is leverage the strengths of each language (as another poster mentioned, a combo like Python and C/C++ for the intense parts)...
Reason is the Path to God - Anon
GnuCash has basic business methods coded in a very C++ish dialect of C. However the main stuff is coded in Scheme making it relatively easy to extend. It can be a little slow to load though. It also has a bit done in Perl.
See my journal, I write things there
I think hes talking about the development documentation. Having some quality doco on the code base can greatly increase the time it takes to understand and start hacking with a code base. Being presented with a huge monolitic, sometimes cryptic codebase doesnt really appeal to a programmer whose just spent 12 hours coding at work.
There have been several projects I keep meaning to contribute something too... however first I have to sit for a few weeks playing with the codebase before I can make any really significant contribution. Also having coders that dont fully understand the code base cause many arguments in mailing lists("Why the hell did you do it this way ?" "I dunno... didnt implement that and its not documented" "Well Ill change it to suit me better... oh crap its broken... now I see why its done that way... Ill change it back"... all this wastes valuable development time
I don't think that's what he meant by a "standard library". He's thinking along the lines of Java's standard library -- a standard library that gives you graphics classes, networking classes, XML parser classes, GUI classes, etc.
I think you're confusing a _platform_ with a _programming_language_. Java is both a platform and a programming language. C++ is just a programming language, and things like graphics, networking and such have to defined on a platform you use the language with.
Which is the way things should be if you need a general, fast and lightweight language applicable to almost any and all environments you could encounter. The opposite is the way of Java, the 'jack of all trades and master of none' approach.
This guy obviously haven't got a clue, move on people.
I would know. I wrote it.
Apparently, Oracle software runs on more platforms than there are C++ compilers for.
... then ...
So it's either C, or Java (lately)
Name me a platform for which there exists a JVM, but no C++ compiler. The only one I can think of is Java itself, but unless there's a C -> Java bytecode compiler out there it's not a lot of use to Oracle.
" I don't understand what's so difficult about C++, espc. if you know C."
"The C++ Programming Langauge" by Stroustrop is IIRC, over 1000 pages. The langauge is so damn complex.
Have you ever programmed in python? Lots of problems become a lot easier, once you approach problems 'pythonically.'
forgive me if memory fails, but doesn't python require tabs or whitespacing in certain ways as part of its syntax requirements?
Yes, but as a C++ programmer, I've lost count of the number of times where I've made a coding mistake or had trouble fixing nesting because the indenting did not match the bracketing. If you're going to indent anyway, it's reasonable to have that as the sole determinant of nesting.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
-I dont agree with his language critique. I think the advantages of static typing far outweigh any time it takes to (as he describes) figure what type to declare a variable. Have you ever tried to debug a large project written in a dynamically typed language? It can be a fucking bitch.
-He also says it is really, really hard to learn C, C++, and Java. He says this cuts down on your developer base. Any developer who doesn't have the capacity to pick up those three languages, I just do not want on my project.
A fair bit smaller than any python development environment.
.ZIP file that will work on any win32 PC and is a quick tool written entirely in python.
I have a 700KB
No, it makes it incredibly easy to not only read the code, but to understand it on the first go.
If you have trouble, I can only assume you had trouble with the piss-easy SAT tests too. IOW, you're an idiot.
Gee, I can make unproven assertions too.
'aminorex rapes goats'
If you can't back up your statements, you're just trolling python programmers. Grow up, kid.
A fine book! However, my point is you don't have to learn all that. It's perfectly reasonable and wise to start out writing C code with classes. Now, in this day and age it's not as obvious, but when I started using C++ in earnest in 1994 compilers didn't even support (or supported really badly) a lot of the features of C++, so it was all the more reasonable to learn C++ features slowly. But it's still reasonable because C++ is multiparadigmed, like a tool box, a bunch of tools, of course every job doesn't use every tool.
Like a natural language... you aren't expected to memorize a dictionary to speak it! Not even to speak it "well". To be a "guru" or "expert", I suppose you need to at least familiarize yourself with the whole thing, in terms of whats available, so you will know when to learn a specific feature of the language.
About python... I have started using python recently because I last year started using Zope for quick intranet tools because I didn't have to do anything but install it and it's Products (i.e. because I didn't have to learn dtml or python). Then I looked a bit deeper, dtml is easy. Then deeper, only to find Zope is full of pythony goodness inside!
Python: I think I'm in love. To my mind python makes use of the Virtual Machine architecture to grant idioms that really require that approach, unlike Java, which takes the hits of a VM with relatively few of the benefits.
Really, such benefit is clear with Zope, by basing it on Python, you can share namespaces between all the levels of zope and control code-as-data better (loading modules without compile, etc.).
-pyrrho
I suppose that makes sense, but I'm sure it results in a very readable language as a whole.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
Esp. for open source projects, we'd rather see people use these "new languages" instead of C (and, God forbid, C++). That's the only way we can overwhelm the evil monopolies. Build on each other's efforts, instead of re-inventing the wheel.
Unfortunately, it doesn't work that way. C++ was designed specifically as a better C, yet the first generation of C++ code were written by programmers who did not understand how to write C++ effectively. This resulted in bloated code, or code that was only minimally C++ (and really looked more like C). It takes much longer than advocates are willing to admit for a new language to actually improve productivity across the board.
Also, inevitably, a new language will have new classes of bugs. C programmers, for example, don't have to deal with the intricacies of exception handling. I don't want to argue which one is easier, because that's not the point. The point is that the new features to save the world also have to be learned and mastered over time.
Then why do we have more number of Java programmers
Because that statement is a gross generalization for cases where all other factors are equal, not to be taken literally. The number of programmers who know any given language depends on the popularity of the language, the population, how much demand there is for them, and so on. Note key words "tends to" in my original post.
we'd rather see people use these "new languages" instead of C
I'm not arguing that you shouldn't use newer languages. I'm saying that age can have redeeming technical merits that help keep an older language in contention. These technical merits are rarely considered when amateurs simply compare feature lists.
If my life depended on it, I'd rather use the C program that a 20-year C programmer wrote, than the first Java program that the same programmer ever wrote. Again, this is not a literal statement, but something to illustrate a point.
Making software "do something useful" is only a first early step towards having a finished product. It does not really have to have much of an UI in order to "do something useful", and it may only handle the common cases of whatever problem it solves, and only on the common platforms. And it may have bugs with known workarounds.
If the software despite an awkward UI, bugs and silly limitations allows you to do your work faster than you could without it, it "does something useful", and it is time to invite other developers to play with the code.
Not so for traditional project management.
With regard to the first: consider learning thee build tools part of the cost of learning a static compiled language. It is not optional.
With regard to the second: If you have so many cross-dependicies, you will run into problems in any language as the project grow. A bug solved in one module may cause new bugs to appear in any other module.
In general, Based on many years experience with C++ and Lisp, I'd recommend compiled and statically typed languages for large projects, because of the discpline they encourage. Interpreted and run-time typed languages are usually superior for small projects.
I'm with him on this one, with the usual caveats. Textual protocols are so much easier to debug. Just being able to telnet to the server can be a life saver.
The usual caveats is "unless you KNOW you need it.". If your application spend most of its time passing images over a slow network, it may indeed be a good idea to use PNG (binary) instead of XPM (textual).
If the answer to the questions cannot be found in the documentations, add it.
If the answer to the question *can* be found in the documentation, ask the user where he looked for an answer. That place may need a pointer to the place where the question is answered. Then tell the user where he can find the answer, never answer it directly.
The important thing to remember is that, unless the user pay you for support, they have no right to it. If they don't pay you with money, they must pay you in some other way. For example, by supplying enough information to make their questions useful for improving the product.
One kind of abstraction is to separate your program into the "GUI" and "the business rules" and try and put business rules into other objects instead of into customizations of widget classes. Agreed. But there can be a lot of logic associated with the GUI itself -- enabling and graying out menu items depending on what has been selected elsewhere in the GUI, validating edit box fields, and so on. If your GUI is buttons and text boxes that is one thing, but if your GUI is a lot of custom widgets to present graphs that respond to mouse clicks with various kinds of cursors, there is a lot of logic associated with the GUI itself. Try as you may, 60-80 percent of your program modules may contain #include .
Abstraction number two: Model-View-Controller. Instead of a custom widget being one class, it is two classes (Document-View) or three (Model-View-Controller). The Model can obviously be non-GUI, the View is probably GUI, but the Controller could be non-GUI (contain the logic of the widget without reference to a GUI API), but GUI may creep in depending on the signalling and event model.
Abstraction number three: abstract the GUI API into something portable. This is the Java/wxWindows/Eclipse SWT kind of thing. This kind of thing gets into a lot of work because there is a lot to most GUI API's. One approach to try is that you probably don't use the whole GUI API in your application, and you could code your own version of wxWindows/Eclipse SWT that only contains the GUI calls that you actually use. Then you can make your app portable by recoding that layer for different systems. Harder than it looks because you need a good understanding of the abstraction inherent in most GUI API's (I understand the need for the window handle or equivalent in other systems, but I never understood the need for a DC handle (GC handle in SWT, graphics object in .NET) -- why can't you just draw stuff to the window? Also why does Borland call the DC a "canvas" because the DC is not a canvas in the sense of a framebuffer and if you want a framebuffer for your widget you have to go through a whole bunch of rigamarole creating a bitmap object and then getting a DC/GC/Canvas for the bitmap object so you can actually draw to it and then you have to get the DC/GC/Canvas for your windows so you can blit your framebuffer bitmap to it only if you are in a Paint method of your main window you have to use the DC/GC/Canvas given to you.
Making your program easier to port by separating GUI from non-GUI is a good idea, but it is far from an easy thing to do in many cases. The OO programming principle that an object should not be called procedurally but should have verbs that it knows how to carry out has the effect of tying a lot of logic into GUI object classes.
Apart from vanilla buttons and edit box GUI's (like a Farenheit to Celsius calculator), there are no simple answers to portability of GUI's.
I like the way Python lets me do the right thing.
You mean MAKES you do the right thing. You can do the right thing in languages that don't use whitespace like that just as well.
It's a common criticism of powerful languages that they let you do the wrong thing, but that's exactly why they are powerful.