I wrote this message, and it is not a post worth a 4 or a 5 (it has now received 3 +1 funny, 1 +1 insightful, and 1 -1 overrated).
When I write posts that are worth a 4 or 5, they look like this informative post, not this smart-ass jab at people who lose track of the real world while lost in a digital one.
Oh, and the obligatory on-topic content:
I've been using various Palm products since the first one, and I'm very pleased with them. For me, I love the ability to run the many third-party apps, which the Rex doesn't seem to have. I have been using a Palm V for about 18 months, and I love the metal casing and the smaller size; despite numerous drops to the pavement, I haven't broken it yet. My only gripe is the relatively small amount of memory, which the Vx solves.
Since you're a Slashdot user, you're probably the type who would enjoy being able to add and remove an endless stream of possibly useful utilities, tools, clever hacks, and games; for that reason I'd encourage you to look to the Palm rather than the Rex, which appears more limited.
But for god sake, make sure to use it unobtrusively. The next Palm user that I catch blocking the middle of a busy sidewalk while trying to figure out Graffiti will get his stylus imbedded in his fleshy parts.
The problem with going to Java from C++, is that when you dumb down the language, you also dumb down the programmers.
As we covered elsewhere in this thread, it's true that Java tends to penalize developers (and users) for programmer error a little less than C/C++. That's not intrinsically good or bad; that's just how it is. It's practical goodness/badness depends on circumstance.
If you're using the language mainly as a training tool, then this insulation is bad. It allows developers to become sloppy, and keeps them from learning why sloppy is bad. A more raw language is a steeper learning curve, but that just means that you get to the high ground more quickly.
But if you're using the language to deliver a real-world product, then this insulation is good. Your goal is to deliver a useful thing quickly. SEGVs are certainly helpful to the developer, but the user of a piece of crashing software generally doesn't share that opinion.
And really, the goals of developer improvement and user satisfaction aren't mutually exclusive; you just have to use different tools than crashing code. Instead, you use things like walk-throughs, design review, code review, and pair programming. All of these techniques results in better people, better code, and happier users. And this is true regardless of how forgiving your language of choice is.
Note also that your argument applies even better to, say, assembler. The closer you are to the hardware, the better your code is likely to be, because there's less to take up your slack. But I take it you don't do most of your work in assembler, right?
[...]chasing marketing-driven rainbows.
The silver-bullet syndrome has been around much longer than Java. Indeed, many people had exactly the same gripes about OO programming or, for that matter, C.
The so called "evils" of C/C++ [...] Are solved quite well with tools [... and] good disciplined techniques.
Instead of C/C++, you can insert any language in that statement. A skilled developer with the right tools and a sense of discipline can do good work in almost any language. Comparing the work of experts in one language with the work of fools in another is not a very useful thing to do.
Although this can be true, for most people it just doesn't matter. Why? A few reasons:
Speed is rarely the primary issue - For most projects, things like reliability, speed of development, features, and cost of development are more important than execution speed.
Profilers are rarely used - Spending a couple of days profiling and tuning your code will make much, much, much more difference than using C++ over Java. Despite that, there are a lot of developers who never touch profilers.
Computers get faster; people don't - Thanks to Moore's Law, 18 months from now you code will be twice as fast. It will not be twice as usable, twice as robust, or have twice as many features, and programmers will not be twice as productive. Generally, if I can trade CPU time for programmer time without harming project goals, I'm glad to do it.
That said, I should mention that I've only done server-side Java stuff. I have no idea how GUI Java programs could still be so damned slow after years of effort, but at least under Linux, they really suck. But this is some sort of GUI library issue, as my console and HTML has all come out surprisingly zippy.
Really, I agree with many of your points in the abstract. As a language for top-tier, ass-kicking developers who are wise, subtle, and wily, Java has a lot of annoying constraints.
They did this for a reason though. For a lot of real-world software development, you have to do the work with painfully small amounts of time, money, and talent. So they banned a number of things that it takes an expert to use wisely. E.g., pointers, multiple inheritance, allowing unreachable code, preprocessor macros, raw memory allocation, random memory access, self-modifying code, and so on. As cool as those features are in the hands of a genius, they are plain dangerous in the hands of a mediocre developer. And 99% of the time, the genius will be doing what Java would be doing anyhow; it's only the 1% of the time that it sucks.
That's why I'd much rather inherit a bunch of J. Random Programmer's code in Java than almost any other language. There will be little impressive wizardry in it, but there are also unlikely to be many sections that will make me bleed through my eye sockets.
And you're also right about some of the other feature lacks; the whole primitive type thing is just ugly, and it's clear that they haven't heard about the whole mutable/immutable thing yet. Really, it saddens me that they are just now catching up with a lot of the things that NeXT was doing right with Objective C 5-10 years ago.
But as far as getting things done in the real world for server side stuff goes, it seems perfectly adequate for all the OO work I do. And to be fair to them, they're making a fair bit of progress; the java.lang.ref package, for example, answered a lot of my gripes about pointers and garbage collection.
One thing I didn't understand in your post was the section "lack of parametrised types"; could you talk more about that?
What Public Display of Affection would I recommend? Really, I don't know that I would; they make many people uncomfortable. And they often make you appear off in your own little world, oblivious to what is going on. But if you have to, I'd recommend the smallest, most modest one that meets your needs; save the heavy stuff for when you're in private.
Oh, and now that I think about it, I'd give the same advice for a Personal Digital Assistant,
I over-reacted, but whenever someone mentions C++ someone says, hey - why not use java and all your problems will go away, I get a little tired of it.
Me too. As far as I can tell, these are people who have never done any serious work in Java. Or if they have, then Java is the only language they've used on a serious project.
Luckily, these people get what they deserve. Eventually they will be dumb enough to say things like this to a boss, who will be dumb enough believe them. And then when their optimistically-scheduled, poorly-scoped, under-budgeted project goes up in flames, they will get fucked with the sandpaper condoms. The smart ones learn after the first time that no tool is perfect for every job. The dumb ones, of course, talk trash about last tool and find the next perfect tool to talk about.
Having the program die horribly would probably suffice, but the high-voltage shock to the nipples would be even better. Immediate catastophic failure is a far more useful reaction to bugs during development than limping along, papering over the cracks.
And people call Java a bondage-and-discipline language! Heh. Maybe we should dress this idea up in a lot of fancy talk about neuropsychology and maximizing feedback loop efficiency and see if we can get VCs to cough up a few million dollars to get us going.
I'm currently building some server-side Java web applications. Since the Java Servlet stuff is inherently multi-threaded, I have indeed occasionally been reminded that multi-threaded applications are tricky.
These are all good tools; when I was having some problems that I suspected were due to my less-than-perfect understanding of threading, I used their thread analysis tool under simulated load, and it immediately identfied my race condition, plus a couple more potential races I hadn't noticed yet.
(This is a little off-topic, but I have to mention that their memory/CPU profiler is, pardon my french, fucking awesome; it is the best thing I have ever seen for visualizing the interior structure of a running program. After a day with the profiler, my Java code was substantially faster than the C it was replacing, despite having more features and being more secure.)
Another tool I'm very pleased with is JUnit, a unit-testing framework. If you're interested in trying out the Extreme Programming-style approach to testing (wherein you make automated, integrated unit tests that are run more or less continuously) then this is for you. And if you are having so many problems with bugs that you are considering changing languages, then I would strongly recommend that you do this. Good unit tests slow initial writing down a little, and save you extraordinary amounts of time and agony later.
Oh, and run out right now and buy several copies of Code Complete and Rapid Development for the team. If you are having such large problems on the project, the problem is probably not with your choice of debugger. These books will help you figure out what the problem actually is, and give you all sorts of solutions.
--
For the record, and I don't have any financial interest in any of the things I've mentioned here; I just use 'em and like 'em.
I was expecting someone to make this stupid suggestion. [...] What the hell has this got to do with his suggestion - he's asking about debugging threads. [...] This is a fact that you pulled out of your ass.
When a developer (or team of developers) is spending a lot of time debugging and still not solving the problems, I ususally take this as a sign that there are more fundamental problems than the quality of the debugger. I've been developing serious software for 15 years in Pascal, C, Perl, C++, Objective-C, and Java, and I rarely need to us anything more than the occasional printf.
Admittedly, developing threaded code is hard stuff, and I don't know enough about the original poster's problems to say what is going on. But it is possible that they are in over their heads, in which case it may behoove them to a) admit that they don't know enough and start again from basics, and b) they may wish to choose a language that is more forgiving of inexperienced developers.
In that case, suggesting Java is a good idea. That's not to say that C is bad; if I am doing something speed-critical and am working with a team of crackerjack developers, then C would be my first choice.
But if I'm doing something where maximizing CPU efficiency isn't our #1 issue, or if I'm working with developers who are less than stellar, then I lean towards Java. Why?
No pointer errors - Experts may not make pointer errors, but average developers sure do. With Java, there are no buffer overruns, no broken pointer arithmetic, no SEGVs. And even better nobody else making some stupid pointer error that hoses one of your data structures, making you spend days looking for a bug that isn't there.
No malloc errors - Java allows you to pay less attention to memory allocation. This makes classic memory leaks impossible, and subtle leaks harder. You're right that novice Java developers take longer to learn the value of reference handling than C developers, but this is mainly because Java extracts a much smaller penalty for those errors. By your logic, presumably, C++ would be even better if each time the developer left a dangling reference they received a high-voltage shock to the nipples.
Exception handling - It's been several years since I've used C++, so maybe the exception handling there has improved. But Java's exception handling is a good thing, making it much easier to track down errors when they do happen.
Multiple VMs - When I am getting some weird-ass error, it's wonderful to be able to try several different VMs on different hardware platforms. That removes all question of OS issues, endian problems, or bugs in the run-time.
So the "maybe you should use Java" is a reasonable answer to the question, especially since the original poster specifically mentioned that they were looking at using java.
Ergo, there was no need for you to be an asshole about it.
Actually, it is a misconception that java doesn't suffer from memory leaks.
A classic memory leak is one where you have memory allocated but no longer have any way to make use of it. These kinds of errors aren't possible in a garbage collected language. Once you let go of your last pointer to something in Java (or, say, Perl) then the GC takes care of everything automatically.
When debugging other people's C code, the most common memory leak I see is the temporary allocation of scratch space in some low-level routine without a corresponding release of the memory. This does not happen in Java.
If you don't explicitly design in creation/destruction of your objects you will leak memory.
Agreed. This is especially a problem with people new to OO design, where they haven't yet developed a good understanding of modular integrity. In practice, though, I find these kinds of errors much less frequent and much easier to find than classic memory leaks.
Given that you're posting around here, I'm guessing you have a Linux box handy. Here are some of my favorite sysadmin tools:
dig - This is a more advanced tool for seeing what's going on with DNS.
nmap - A great tool for probing your server to make sure you haven't left anything open.
Apache Bench (ab) - This simple but effective benchmarking tool comes with the Apache server. It's great to see how your site will perform under load.
wget - a tool for remotely getting web pages; it's very versatile -- you can even use to save a copy of your whole site, just in case.
Ethereal - Having trouble figuring out what's going on between the browser and your server? This will capture all the packets and decode them into a nice conversation for you.
vmstat - want to know why your server is slow? Get used to watching the vmstat numbers while it's fast, so you can see what's different when it's slow. It's raw numbers that are hard to interpret, but it's worth getting to know. Maybe this should be another Ask Slashdot question?
Netsaint - this is my favorite automatic monitoring package. Once your site is in production, you can set this up to patrol things and make sure everything is working. That lets you get on with other stuff, knowing you'll hear about trouble pronto.
MRTG - A tool that makes excellent long-term graphs of bandwidth use.
IPtraf - Where MRTG gives you the broad overview, this gives you the second-by-second nitty gritty.
perl - Last but most is Perl, a Swiss Army chainsaw of languages. If you'll be doing any web stuff, pick up a copy of Learning Perl and spend a little time with it. Once you learn the magic of regular expressions, you will never again say "that's impossible!" to a problem.
As far as non-sysadmin stuff goes, here are some of my other favorites:
Bugzilla - this is a free and flexible bug tracking system. Highly recommended, especially for those people who don't think they need a bug tracking system. Our designers thought it was silly to start, but even they use it all the time now.
CVS - Like bug tracking, most web sites don't think they need version control. Most web sites are wrong! CVSweb is also recommended.
WebTV Simulator - Sure, you and I don't use WebTVs, but a lot of people do. Browse your site with this to see how the other half surfs.
VMWare - Along similar lines, VMWare is a Windows box emulator. I use it to keep a bunch of synthetic windows machines with a variety of OS versions and browser versions. It makes QA much easier.
And if there are particular tasks that have you stumped, come back and ask again. 'Round these parts, we have big toolboxes.
I use an Olympus D400Z, which can be controlled via serial port. I use the program photopc, written by Eugene Crosser, which runs under a number of Unix variants. According to the readme
This is a library and a command-line frontend to manipulate digital
still cameras based on Fujitsu chipset and Sierra Imaging firmware. The
program is known to work with Agfa, Epson, Olympus, Sanyo and Nikon (at
least CoolPix 900, but not CoolPix 600!) cameras.
You can indeed write scripts to regularly take a photo and download it from the camera. Good stuff!
AboveNet has constructed their criteria so that they do have "fig leaf" excuse for their censorship, as is done in virtually all real
world examples of censorship. If you want to be fooled in all of these cases, that is your choice.
Let's just say I'm willing to give them the benefit of the doubt. I've been reading SPAMTOOLS for years, and this issue got quite a bit of play there, and I'd say that rational people can disagree over this issue. Although like the goal of ORBS, I wasn't so sure about their methods. And I was very sure I didn't like their stubbornly boneheaded refusual to see that there might be other points of view.
If ORBS really wants to claim censorship, then they should move their ideas (e.g. their website) away from their actions (their arguably aggressive network probing). If AboveNet suddenly starts blocking their web server, then I'd agree that they are after censorship.
You could also test things yourself. Use an external proxy server to make a mirror of orbs.org on your network and announce it to the world. That way, all AboveNet customers will have access to the ideas of ORBS without risking exposure to what AboveNet sees as network abuse. If you get the smackdown from AboveNet, then you'd have a reasonable claim
In this case, AboveNet's excuse is ridiculous, in light of the fact that AboveNet claims to be doing this for customer welfare, and we, the effected [sic] customer, do not want them to do it.
A quick check of ARIN shows that you guys are about 0.06% of their address space. No offense meant, but I can see how they wouldn't be willing to futz around with their routing tables for such a small customer.
If this is such an important issue to you, you should consider voting with your dollars.
My favorite book on this topic is McConnell's Rapid Development. It's good enough that I give a copy to each new client.
In this case, Chapter 8, Estimation is the one you're after. It mentions:
Most prodcuts overshoot their estimated schedules by anywhere from 25 to 100 percent, but a few organizations have achieved schedule-prediction accuracies to with 10 percent, and 5 percent is not unheard of.
He then goes on to talk about what factors influence accuracy, why so many projects are bad at it, and what all parties can do to improve schedule accuracy.
In my experience, these are the three biggest problems:
Poorly defined scope - Someone will say "We need a little web site to do X, Y, and Z." But everybody will be in too much of a hurry to figure out what 'little' means, or what the various features really imply. The result is either a late but satifactory product or an on-time but inadequate product.
Customer ignores realities of development - Often a customer or boss will say, "Build a site with these features using three people in three months or less." This specifies 1) requirements, 2) resources, and 3) time. This ignores the realities of development. A customer should be allowed to pick any two of those three; the developer must be allowed to use her experience to estimate the third.
Single-shot development - Much software, and especially modern web sites, can be developed incrementally. It's very dangerous to cook up a plan and send the developers into a back room for six months, hoping they'll come out with the perfect product. It's much less risky to use an iterative development process, where they come out with new versions every few weeks.
And for the serious developers out there, I encourage y'all to take a look at Extreme Programming; I don't buy all of it, but it's very thought provoking, and you'll certainly end up using some of its methods.
Many moons ago, I was pretty impressed with Jon Katz's first couple Hellmouth stories; I thought he captured something important. But then I became more and more annoyed with his overstated opinions and flaccid writing. So I went into my user preferences and excluded him from my home page.
It was a pretty good decision. Slashdot is much more pleasant to me now. I had pretty much forgotten he existed until they mentioned him here. Has he improved at all lately? I'm not yet feeling up to looking, but I'd be glad to hear what others feel.
The notion that MAPS is some insidious conspiracy that uses its pod people to push its secret agenda throughout the industry is not one I'm buying without more proof than your assertion.
You should also be careful how you sling around that term censor. From what I can tell, AboveNet blocked ORBS for their behavior, not their opinions. Censorship is the suppression of ideas, not actions.
Personally, I think ORBS is a good idea, but that they go about it in an agressively rude fashion. I wouldn't block 'em, but I see it as a reasonable decision to keep their probes off of one's networks. I've seen no evidence that AboveNet it doing anything more than that.
If you come back with some proof that AboveNet blocks, say, ORBS, mirrors of ORBS pages, and usenet discussions that say nice things about ORBS, then I'll take you a little more seriously.
One of the gripes in the article was that the MAPS evidence file for these guys was scanty. That's because the nomination for the extension was kept here:
I count at least three, maybe four. There's an outfit called SamCo that has at least 8 IP addresses; another one called the PPM group with at least three, somebody named Said Al-Zalzalah with at least two, and a guy called Mike Zuber, with one.
No, if I were an ISP I would not delete spam for my customers.
Then you should start your own ISP and see how far you get. Many large ISPs and mailhosts are very excited to tell people about their anti-spam efforts.
A lot of this is probably customer demand, suggesting that your style of ISP wouldn't be very popular. And as others have pointed out in this thread, spammers shift the cost burden to others, especially the destination ISP, so any ISP takes your view of spam will end up with higher bills (and therefore higher prices) than ISPs that allow their customers to block spam.
But hey, best of luck to you; if it turns out that you are right, then nobody will use MAPS anymore, making the argument moot.
As I've said elsewhere, MAPS started by blocking the spammer site. But it turns out that Media3 is the most spam-friendly ISP around. And as the article mentions, MAPS has been after Media3 for months with no results; they've even taken on new spam-friendly clients in that time.
What do you want MAPS to do? Blow kisses at Media3? Send 'em cookies and say pretty please?
As an RBL subscriber, I'm glad they list spam-friendly ISPs. And maybe Peacefire is an innocent bystander, although perhaps they stay there to make a political statement. If they truly didn't know what was coming, then they should yell at Media3, 'cause Media3 has known this was in the works for months.
But if you don't like it, don't subscribe to the RBL. The Internet I envision doesn't have spammers or their pals on it, and the RBL helps make that vision a reality.
Since you have such a deep insight into this issue, perhaps you can enlighten us as to the many beneficial uses to which a spamming program (plus 25 million addresses, free with every copy) could be put?
And actually, going after tools solves quite a lot. The purchase of explosives, for example, is highly regulated. This a) make it harder for people to blow other people up, and b) makes it easier to track those who use explosives to violate the law. And the purchase of, say, atomic bombs is strictly forbidden, even though an A-bomb, like any other weapon, is just a tool.
Another fine example is the automobile. Before you are allowed to drive one in almost any country, you have to prove that you can use it safely. And before a car is allowed on the road, it has to meet many safety standards. Sure, it's just a tool, but government regulation of this tool has saved a lot of lives.
So which tool is it that has taken the place of the a-bomb or the automobile? And how is the general populace ignorant of the possibilities of misusing them?
My recollection was that eBGP4 was the first format they offered it in; I have the notion that the DNS version came later. But either way, they've offered both for years.
In any case, using MAPS in this way is just plain wrong. I support only blackholing via mail, not anything else.
Well then you should certainly use it that way. I think it's probably right, and I hope you support my right to make my own ethical choices.
Here's why I think it's probably a good call by MAPS: Banning an entire spam-friendly ISP should be a solution of last resort, but MAPS has been after these people for six months to fix things. And still, they are listed as spamhaus's number one spam-friendly ISP. As an RBL subscriber, I fully support their action.
As other posters have mentioned, those of use who use MAPS offerings have indeed elected him policeman of the Internet.
Get off your high horse and try building a constructive way of dealing with spam that does not punish innocent users.
Given that you're shouting this from your own high horse, this is a pretty silly statement to make.
The people at MAPS have carefully thought out their stand on the issue, and then offered their services to anybody who agrees with them. Name-calling probably won't change their minds.
If you have a different view on things, then you're welcome to make your own offering. Once you get it working, I may even subscribe. (Or I may not; ORBS, for example, is to extreme for my tastes.) But put up or shut up; don't just run your mouth telling other people what work they should be doing.
That may be true, but that has nothing to do with MAPS and the RBL; ORBS isn't even listed on the RBL. So even if above.net is choosing to block ORBS traffic on their network, that doesn't seem relevant to this discussion.
The ISP, as far as I'm concerned, is spam-friendly. And I don't want my boxes to talk to spam-friendly ISPs. If Peacefire chooses to to use a spam-friendly ISP, that's their business, I'm not one to stop 'em.
Oh, you say the didn't choose? That they just didn't know? It's funny, isn't it, that Media3 didn't even warn their clients about a possible loss of connectivity to large parts of the Internet?
That's not the behavior of a reputable businessman; it's an ISP trying to shield its spammer clients by mixing in legit sites. The ISP has known this was coming for months; they should have warned their customers.
This could just mean that AboveNet uses the RBL to filter mail delivery to their direct customers. That's what it usually means, as the bulk of RBL subscribers just use it for SMTP as part of a Sendmail ruleset.
People have repeatedly made the claim that AboveNet internally null-routes based on the RBL and then advertises those routes, thereby sucking innocent packets in to their doom. That's the claim I was responding to, and that's the claim for which I still see no evidence.
Slashdot Mirror
I wrote this message, and it is not a post worth a 4 or a 5 (it has now received 3 +1 funny, 1 +1 insightful, and 1 -1 overrated).
When I write posts that are worth a 4 or 5, they look like this informative post, not this smart-ass jab at people who lose track of the real world while lost in a digital one.
Oh, and the obligatory on-topic content:
I've been using various Palm products since the first one, and I'm very pleased with them. For me, I love the ability to run the many third-party apps, which the Rex doesn't seem to have. I have been using a Palm V for about 18 months, and I love the metal casing and the smaller size; despite numerous drops to the pavement, I haven't broken it yet. My only gripe is the relatively small amount of memory, which the Vx solves.
Since you're a Slashdot user, you're probably the type who would enjoy being able to add and remove an endless stream of possibly useful utilities, tools, clever hacks, and games; for that reason I'd encourage you to look to the Palm rather than the Rex, which appears more limited.
But for god sake, make sure to use it unobtrusively. The next Palm user that I catch blocking the middle of a busy sidewalk while trying to figure out Graffiti will get his stylus imbedded in his fleshy parts.
The problem with going to Java from C++, is that when you dumb down the language, you also dumb down the programmers.
As we covered elsewhere in this thread, it's true that Java tends to penalize developers (and users) for programmer error a little less than C/C++. That's not intrinsically good or bad; that's just how it is. It's practical goodness/badness depends on circumstance.
If you're using the language mainly as a training tool, then this insulation is bad. It allows developers to become sloppy, and keeps them from learning why sloppy is bad. A more raw language is a steeper learning curve, but that just means that you get to the high ground more quickly.
But if you're using the language to deliver a real-world product, then this insulation is good. Your goal is to deliver a useful thing quickly. SEGVs are certainly helpful to the developer, but the user of a piece of crashing software generally doesn't share that opinion.
And really, the goals of developer improvement and user satisfaction aren't mutually exclusive; you just have to use different tools than crashing code. Instead, you use things like walk-throughs, design review, code review, and pair programming. All of these techniques results in better people, better code, and happier users. And this is true regardless of how forgiving your language of choice is.
Note also that your argument applies even better to, say, assembler. The closer you are to the hardware, the better your code is likely to be, because there's less to take up your slack. But I take it you don't do most of your work in assembler, right?
[...]chasing marketing-driven rainbows.
The silver-bullet syndrome has been around much longer than Java. Indeed, many people had exactly the same gripes about OO programming or, for that matter, C.
The so called "evils" of C/C++ [...] Are solved quite well with tools [... and] good disciplined techniques.
Instead of C/C++, you can insert any language in that statement. A skilled developer with the right tools and a sense of discipline can do good work in almost any language. Comparing the work of experts in one language with the work of fools in another is not a very useful thing to do.
Although this can be true, for most people it just doesn't matter. Why? A few reasons:
That said, I should mention that I've only done server-side Java stuff. I have no idea how GUI Java programs could still be so damned slow after years of effort, but at least under Linux, they really suck. But this is some sort of GUI library issue, as my console and HTML has all come out surprisingly zippy.
Really, I agree with many of your points in the abstract. As a language for top-tier, ass-kicking developers who are wise, subtle, and wily, Java has a lot of annoying constraints.
They did this for a reason though. For a lot of real-world software development, you have to do the work with painfully small amounts of time, money, and talent. So they banned a number of things that it takes an expert to use wisely. E.g., pointers, multiple inheritance, allowing unreachable code, preprocessor macros, raw memory allocation, random memory access, self-modifying code, and so on. As cool as those features are in the hands of a genius, they are plain dangerous in the hands of a mediocre developer. And 99% of the time, the genius will be doing what Java would be doing anyhow; it's only the 1% of the time that it sucks.
That's why I'd much rather inherit a bunch of J. Random Programmer's code in Java than almost any other language. There will be little impressive wizardry in it, but there are also unlikely to be many sections that will make me bleed through my eye sockets.
And you're also right about some of the other feature lacks; the whole primitive type thing is just ugly, and it's clear that they haven't heard about the whole mutable/immutable thing yet. Really, it saddens me that they are just now catching up with a lot of the things that NeXT was doing right with Objective C 5-10 years ago.
But as far as getting things done in the real world for server side stuff goes, it seems perfectly adequate for all the OO work I do. And to be fair to them, they're making a fair bit of progress; the java.lang.ref package, for example, answered a lot of my gripes about pointers and garbage collection.
One thing I didn't understand in your post was the section "lack of parametrised types"; could you talk more about that?
What Public Display of Affection would I recommend? Really, I don't know that I would; they make many people uncomfortable. And they often make you appear off in your own little world, oblivious to what is going on. But if you have to, I'd recommend the smallest, most modest one that meets your needs; save the heavy stuff for when you're in private.
Oh, and now that I think about it, I'd give the same advice for a Personal Digital Assistant,
I over-reacted, but whenever someone mentions C++ someone says, hey - why not use java and all your problems will go away, I get a little tired of it.
Me too. As far as I can tell, these are people who have never done any serious work in Java. Or if they have, then Java is the only language they've used on a serious project.
Luckily, these people get what they deserve. Eventually they will be dumb enough to say things like this to a boss, who will be dumb enough believe them. And then when their optimistically-scheduled, poorly-scoped, under-budgeted project goes up in flames, they will get fucked with the sandpaper condoms. The smart ones learn after the first time that no tool is perfect for every job. The dumb ones, of course, talk trash about last tool and find the next perfect tool to talk about.
Having the program die horribly would probably suffice, but the high-voltage shock to the nipples would be even better. Immediate catastophic failure is a far more useful reaction to bugs during development than limping along, papering over the cracks.
And people call Java a bondage-and-discipline language! Heh. Maybe we should dress this idea up in a lot of fancy talk about neuropsychology and maximizing feedback loop efficiency and see if we can get VCs to cough up a few million dollars to get us going.
I'm currently building some server-side Java web applications. Since the Java Servlet stuff is inherently multi-threaded, I have indeed occasionally been reminded that multi-threaded applications are tricky.
A few months back, we purchased a suite of tools from an outfit called Sitraka (nee KLGroup). They have three products that are part of the JProbe Suite, a CPU and memory profiler, a thread analysis program, and a code coverage tool.
These are all good tools; when I was having some problems that I suspected were due to my less-than-perfect understanding of threading, I used their thread analysis tool under simulated load, and it immediately identfied my race condition, plus a couple more potential races I hadn't noticed yet.
(This is a little off-topic, but I have to mention that their memory/CPU profiler is, pardon my french, fucking awesome; it is the best thing I have ever seen for visualizing the interior structure of a running program. After a day with the profiler, my Java code was substantially faster than the C it was replacing, despite having more features and being more secure.)
Another tool I'm very pleased with is JUnit, a unit-testing framework. If you're interested in trying out the Extreme Programming-style approach to testing (wherein you make automated, integrated unit tests that are run more or less continuously) then this is for you. And if you are having so many problems with bugs that you are considering changing languages, then I would strongly recommend that you do this. Good unit tests slow initial writing down a little, and save you extraordinary amounts of time and agony later.
Oh, and run out right now and buy several copies of Code Complete and Rapid Development for the team. If you are having such large problems on the project, the problem is probably not with your choice of debugger. These books will help you figure out what the problem actually is, and give you all sorts of solutions.
--
For the record, and I don't have any financial interest in any of the things I've mentioned here; I just use 'em and like 'em.
I was expecting someone to make this stupid suggestion. [...] What the hell has this got to do with his suggestion - he's asking about debugging threads. [...] This is a fact that you pulled out of your ass.
When a developer (or team of developers) is spending a lot of time debugging and still not solving the problems, I ususally take this as a sign that there are more fundamental problems than the quality of the debugger. I've been developing serious software for 15 years in Pascal, C, Perl, C++, Objective-C, and Java, and I rarely need to us anything more than the occasional printf.
Admittedly, developing threaded code is hard stuff, and I don't know enough about the original poster's problems to say what is going on. But it is possible that they are in over their heads, in which case it may behoove them to a) admit that they don't know enough and start again from basics, and b) they may wish to choose a language that is more forgiving of inexperienced developers.
In that case, suggesting Java is a good idea. That's not to say that C is bad; if I am doing something speed-critical and am working with a team of crackerjack developers, then C would be my first choice.
But if I'm doing something where maximizing CPU efficiency isn't our #1 issue, or if I'm working with developers who are less than stellar, then I lean towards Java. Why?
- No pointer errors - Experts may not make pointer errors, but average developers sure do. With Java, there are no buffer overruns, no broken pointer arithmetic, no SEGVs. And even better nobody else making some stupid pointer error that hoses one of your data structures, making you spend days looking for a bug that isn't there.
- No malloc errors - Java allows you to pay less attention to memory allocation. This makes classic memory leaks impossible, and subtle leaks harder. You're right that novice Java developers take longer to learn the value of reference handling than C developers, but this is mainly because Java extracts a much smaller penalty for those errors. By your logic, presumably, C++ would be even better if each time the developer left a dangling reference they received a high-voltage shock to the nipples.
- Exception handling - It's been several years since I've used C++, so maybe the exception handling there has improved. But Java's exception handling is a good thing, making it much easier to track down errors when they do happen.
- Multiple VMs - When I am getting some weird-ass error, it's wonderful to be able to try several different VMs on different hardware platforms. That removes all question of OS issues, endian problems, or bugs in the run-time.
So the "maybe you should use Java" is a reasonable answer to the question, especially since the original poster specifically mentioned that they were looking at using java.Ergo, there was no need for you to be an asshole about it.
Yes and no.
Actually, it is a misconception that java doesn't suffer from memory leaks.
A classic memory leak is one where you have memory allocated but no longer have any way to make use of it. These kinds of errors aren't possible in a garbage collected language. Once you let go of your last pointer to something in Java (or, say, Perl) then the GC takes care of everything automatically.
When debugging other people's C code, the most common memory leak I see is the temporary allocation of scratch space in some low-level routine without a corresponding release of the memory. This does not happen in Java.
If you don't explicitly design in creation/destruction of your objects you will leak memory.
Agreed. This is especially a problem with people new to OO design, where they haven't yet developed a good understanding of modular integrity. In practice, though, I find these kinds of errors much less frequent and much easier to find than classic memory leaks.
Given that you're posting around here, I'm guessing you have a Linux box handy. Here are some of my favorite sysadmin tools:
As far as non-sysadmin stuff goes, here are some of my other favorites:
And if there are particular tasks that have you stumped, come back and ask again. 'Round these parts, we have big toolboxes.
You can indeed write scripts to regularly take a photo and download it from the camera. Good stuff!
AboveNet has constructed their criteria so that they do have "fig leaf" excuse for their censorship, as is done in virtually all real
world examples of censorship. If you want to be fooled in all of these cases, that is your choice.
Let's just say I'm willing to give them the benefit of the doubt. I've been reading SPAMTOOLS for years, and this issue got quite a bit of play there, and I'd say that rational people can disagree over this issue. Although like the goal of ORBS, I wasn't so sure about their methods. And I was very sure I didn't like their stubbornly boneheaded refusual to see that there might be other points of view.
If ORBS really wants to claim censorship, then they should move their ideas (e.g. their website) away from their actions (their arguably aggressive network probing). If AboveNet suddenly starts blocking their web server, then I'd agree that they are after censorship.
You could also test things yourself. Use an external proxy server to make a mirror of orbs.org on your network and announce it to the world. That way, all AboveNet customers will have access to the ideas of ORBS without risking exposure to what AboveNet sees as network abuse. If you get the smackdown from AboveNet, then you'd have a reasonable claim
In this case, AboveNet's excuse is ridiculous, in light of the fact that AboveNet claims to be doing this for customer welfare, and we, the effected [sic] customer, do not want them to do it.
A quick check of ARIN shows that you guys are about 0.06% of their address space. No offense meant, but I can see how they wouldn't be willing to futz around with their routing tables for such a small customer.
If this is such an important issue to you, you should consider voting with your dollars.
In this case, Chapter 8, Estimation is the one you're after. It mentions:
He then goes on to talk about what factors influence accuracy, why so many projects are bad at it, and what all parties can do to improve schedule accuracy.
In my experience, these are the three biggest problems:
- Poorly defined scope - Someone will say "We need a little web site to do X, Y, and Z." But everybody will be in too much of a hurry to figure out what 'little' means, or what the various features really imply. The result is either a late but satifactory product or an on-time but inadequate product.
- Customer ignores realities of development - Often a customer or boss will say, "Build a site with these features using three people in three months or less." This specifies 1) requirements, 2) resources, and 3) time. This ignores the realities of development. A customer should be allowed to pick any two of those three; the developer must be allowed to use her experience to estimate the third.
- Single-shot development - Much software, and especially modern web sites, can be developed incrementally. It's very dangerous to cook up a plan and send the developers into a back room for six months, hoping they'll come out with the perfect product. It's much less risky to use an iterative development process, where they come out with new versions every few weeks.
I also recommend his book The Software Project Survival Guide; for non-techies, it's much less intimidating than Rapid Development.And for the serious developers out there, I encourage y'all to take a look at Extreme Programming; I don't buy all of it, but it's very thought provoking, and you'll certainly end up using some of its methods.
Many moons ago, I was pretty impressed with Jon Katz's first couple Hellmouth stories; I thought he captured something important. But then I became more and more annoyed with his overstated opinions and flaccid writing. So I went into my user preferences and excluded him from my home page.
It was a pretty good decision. Slashdot is much more pleasant to me now. I had pretty much forgotten he existed until they mentioned him here. Has he improved at all lately? I'm not yet feeling up to looking, but I'd be glad to hear what others feel.
The notion that MAPS is some insidious conspiracy that uses its pod people to push its secret agenda throughout the industry is not one I'm buying without more proof than your assertion.
You should also be careful how you sling around that term censor. From what I can tell, AboveNet blocked ORBS for their behavior, not their opinions. Censorship is the suppression of ideas, not actions.
Personally, I think ORBS is a good idea, but that they go about it in an agressively rude fashion. I wouldn't block 'em, but I see it as a reasonable decision to keep their probes off of one's networks. I've seen no evidence that AboveNet it doing anything more than that.
If you come back with some proof that AboveNet blocks, say, ORBS, mirrors of ORBS pages, and usenet discussions that say nice things about ORBS, then I'll take you a little more seriously.
One of the gripes in the article was that the MAPS evidence file for these guys was scanty. That's because the nomination for the extension was kept here:
. txt
http://evfiles.mail-abuse.org/rbl/ev/63.74.120-24
This paints things in a pretty different light; it's a shame that this wasn't read by the author of this article.
I count at least three, maybe four. There's an outfit called SamCo that has at least 8 IP addresses; another one called the PPM group with at least three, somebody named Said Al-Zalzalah with at least two, and a guy called Mike Zuber, with one.
How'd you get two?
No, if I were an ISP I would not delete spam for my customers.
Then you should start your own ISP and see how far you get. Many large ISPs and mailhosts are very excited to tell people about their anti-spam efforts.
A lot of this is probably customer demand, suggesting that your style of ISP wouldn't be very popular. And as others have pointed out in this thread, spammers shift the cost burden to others, especially the destination ISP, so any ISP takes your view of spam will end up with higher bills (and therefore higher prices) than ISPs that allow their customers to block spam.
But hey, best of luck to you; if it turns out that you are right, then nobody will use MAPS anymore, making the argument moot.
As I've said elsewhere, MAPS started by blocking the spammer site. But it turns out that Media3 is the most spam-friendly ISP around. And as the article mentions, MAPS has been after Media3 for months with no results; they've even taken on new spam-friendly clients in that time.
What do you want MAPS to do? Blow kisses at Media3? Send 'em cookies and say pretty please?
As an RBL subscriber, I'm glad they list spam-friendly ISPs. And maybe Peacefire is an innocent bystander, although perhaps they stay there to make a political statement. If they truly didn't know what was coming, then they should yell at Media3, 'cause Media3 has known this was in the works for months.
But if you don't like it, don't subscribe to the RBL. The Internet I envision doesn't have spammers or their pals on it, and the RBL helps make that vision a reality.
Since you have such a deep insight into this issue, perhaps you can enlighten us as to the many beneficial uses to which a spamming program (plus 25 million addresses, free with every copy) could be put?
And actually, going after tools solves quite a lot. The purchase of explosives, for example, is highly regulated. This a) make it harder for people to blow other people up, and b) makes it easier to track those who use explosives to violate the law. And the purchase of, say, atomic bombs is strictly forbidden, even though an A-bomb, like any other weapon, is just a tool.
Another fine example is the automobile. Before you are allowed to drive one in almost any country, you have to prove that you can use it safely. And before a car is allowed on the road, it has to meet many safety standards. Sure, it's just a tool, but government regulation of this tool has saved a lot of lives.
So which tool is it that has taken the place of the a-bomb or the automobile? And how is the general populace ignorant of the possibilities of misusing them?
My recollection was that eBGP4 was the first format they offered it in; I have the notion that the DNS version came later. But either way, they've offered both for years.
In any case, using MAPS in this way is just plain wrong. I support only blackholing via mail, not anything else.
Well then you should certainly use it that way. I think it's probably right, and I hope you support my right to make my own ethical choices.
Here's why I think it's probably a good call by MAPS: Banning an entire spam-friendly ISP should be a solution of last resort, but MAPS has been after these people for six months to fix things. And still, they are listed as spamhaus's number one spam-friendly ISP. As an RBL subscriber, I fully support their action.
As other posters have mentioned, those of use who use MAPS offerings have indeed elected him policeman of the Internet.
Get off your high horse and try building a constructive way of dealing with spam that does not punish innocent users.
Given that you're shouting this from your own high horse, this is a pretty silly statement to make.
The people at MAPS have carefully thought out their stand on the issue, and then offered their services to anybody who agrees with them. Name-calling probably won't change their minds.
If you have a different view on things, then you're welcome to make your own offering. Once you get it working, I may even subscribe. (Or I may not; ORBS, for example, is to extreme for my tastes.) But put up or shut up; don't just run your mouth telling other people what work they should be doing.
That may be true, but that has nothing to do with MAPS and the RBL; ORBS isn't even listed on the RBL. So even if above.net is choosing to block ORBS traffic on their network, that doesn't seem relevant to this discussion.
I think Peacefire is fine, and I'm sure the people from MAPS like them, too.
But the point here is that the ISP has been spam friendly for ages, and they've been warned for at least six months. Despite that, they are still taking on new spam clients. And spamhaus.org considers them the the biggest host of spam-friendly domains.
The ISP, as far as I'm concerned, is spam-friendly. And I don't want my boxes to talk to spam-friendly ISPs. If Peacefire chooses to to use a spam-friendly ISP, that's their business, I'm not one to stop 'em.
Oh, you say the didn't choose? That they just didn't know? It's funny, isn't it, that Media3 didn't even warn their clients about a possible loss of connectivity to large parts of the Internet?
That's not the behavior of a reputable businessman; it's an ISP trying to shield its spammer clients by mixing in legit sites. The ISP has known this was coming for months; they should have warned their customers.
This could just mean that AboveNet uses the RBL to filter mail delivery to their direct customers. That's what it usually means, as the bulk of RBL subscribers just use it for SMTP as part of a Sendmail ruleset.
People have repeatedly made the claim that AboveNet internally null-routes based on the RBL and then advertises those routes, thereby sucking innocent packets in to their doom. That's the claim I was responding to, and that's the claim for which I still see no evidence.