Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Comment Re:Conjecture. (Score 5, Insightful) 467

Smalltalk and Lisp are a good example, and they show (to me) that the problem isn't the language. The hard part about programming isn't the code.

The hard part about programming is understanding and decomposing the problem. If you're not any good at that, then no matter what language you use, you're going to struggle and produce crap.

This isn't to say that languages aren't important -- different languages lend themselves to particular problem-spaces by suggesting particular solutions. Picking the right language for the problem is as important as picking the right wrench for the nut.

But there will never be a DWIM language, because the big problem is getting the programmer's brain wrapped around what needs to be done. Once that's done, what's left is only difficult if the programmer doesn't have the figurative toolset on hand.

Comment Not So Ethical (Score 1) 356

Mangham's defense lawyer, Mr. Ventham, pointed out that Mangham is an 'ethical hacker' and runs a tax registered security company.

Doesn't sound so ethical to me.

He's running a business. That means he ought to abide by the rules we expect to apply to businesses. In this case, obtain prior consent, agree on charges/fees/rewards up-front, and do not copy what isn't yours to copy.

(A lot of businesses don't abide by these rules, but that's why we get all pissed at them for being unethical.)

It doesn't look like this "student/business owner" bothered with any of that, and got in trouble for it. Not really much of a story there.

Why Facebook isn't being lambasted for their shoddy system is another matter. Their breach of ethics for failing to design a reasonably secure system is arguably more significant than this unethical 'ethical hacker'.

We don't let banks get away with designing bank vaults made of 3/8" drywall over 2x2 studs. We expect banks to put forth a level of effort securing the valuables in their care proportional to the value of what's being protected. If they do a shoddy job and fake it, and get robbed, we'll punish the robbers, sure... and then ensure that heads roll at the bank.

Comment Re:Just keep calm... (Score 1) 1059

None of my liberal friends are supportive of the president's current stance on civil liberties. Every one of them are unhappy about it.

What's odd is that all of my conservative friends and family who happily supported Bush's attacks on civil liberties are now suddenly *for* civil liberties. What's sad is that it doesn't take much work to get them to both dismiss the need for civil liberties and to bemoan the loss of civil liberties within five minutes. (I have been prohibited from doing this with family.)

Apparently I'm a moderate troublemaker.

Comment Re:No, we need one *better* language, not "more" (Score 1) 421

Sorry, I was not clear that my base assumption is that we're already trying to use the best language for the problem at hand. There are *still* going to be problems that are large, hairy, and complex, given the other constraints we might be working under.

If you don't consider at least three viable different languages for a new project, you're not doing your due diligence.

(Unless, of course, the project is 'use language X on a real-ish problem to see how it really works', and the end result is just a happy side-effect of giving language X an honest go.)

Comment Re:No, we need one *better* language, not "more" (Score 2) 421

Second, we as humans don't really have much success expressing exactly what we want. It's why the most insidious bugs are not in code, but in specification. We so often don't know quite what we want that restrictive languages are actually beneficial, in that they force us to reason consistently.

Oh, god, yes.

One of the more important development skills to have is to be able to extract consistent requirements from stakeholders, and then to be able to write them down in such a way that the requirements will be correct and the stakeholder will agree with them.

When it comes to programming languages, give me a language suited to the problem (all the one-language bigots can go pound sand) that's easier to debug than to rewrite. Large, hairy, complex solutions should eventually result in a new programming language that makes those sorts of things much smaller, far smoother, and simpler.

Comment Re:Other way? (Score 1) 495

Hm. I have an iPhone 3G and an HTC Android.... the android phone needs to be plugged in every day at worst, every other day at best. The iPhone needs to be charged twice a week. All of this is under fairly light load.

This is the problem I have with iPhone-vs-Android debates. The Android suffers from a variety of hardware vendors who can screw up the user experience, and the whole platform suffers as a result.

I really want to like the Android more than I do... but I can't. And it's probably not the fault of the software, but as a consumer, I don't really care about that.

Comment Re:Why even bother specifying INTERNET perms? (Score 1) 97

"The market for users who care about their privacy is way too small to count. "

Just so. I've been considering buying an Android device, and in preparation was playing with Android in a VirtualBox VM. I found it very difficult to find ANY apps I was willing to run, because things that obviously should not require internet access (or some other permission) did require it.

Work has provided me with an Android phone, so I've been looking through the Applications, and most of 'em I won't install because the application (or rather, the developer of the application) demands access far beyond what is needed. It's not so much that an application requires a permission, but how many permissions many of them require.

I want a way to easily change the permissions granted to an application, without the application's knowledge. If I decide that an application has no business making or receiving a text message, I should be able to disable that capability, all without the application being aware that it's attempt to send a text message failed.

Then, I became absolutely bewildered that (apparently!) many millions of people will let some unknown app X have access to capabilities it absolutely should not need to do what it purports to do. To me that means instant distrust. I don't know what everybody else is thinking ... wish I did.

I'm sure that they're thinking that they don't have a choice.

It's *hard* maintaining a decent policy of "Don't Use Apps That Demand Stupid Things". People get tired of it all. So they say "screw it!" and forget about it, and basically wish really hard that they get lucky and don't get compromised, or have their data splashed about. (Then, to make themselves feel better about their lax policy, they harangue others for not "taking advantage" of their similiar device. They scoff at the hesitation of others in allowing unknown and untrusted third parties to have full and unfettered access to personal data. Peer pressure eventually wins.)

Most people don't have much self-discipline, after all.

Whatever your app is, kudos for taking the high road.


Comment Re:Devs can now be more lazy (Score 1) 338

The problem you describe isn't one of developers being lazy... it's a problem of developers being *stupid*, and failing to learn anything from the languages they've previously programmed in. Every language you use in anger should inform you about viewpoints and techniques for every subsequent language, even if they don't directly apply.

This is why all programmers should start with a language like Pascal, so they learn the basics of structured programming, lexical scoping, and what the hell the difference is between pass-by-reference and pass-by-value. It would be best if at least one other language were to be learned before the programmer attemps to learn Java.

I would never recommend that any programmer learn C++, except as an example of what NOT to do when designing a language. Learning C is a good idea, so the programmer can learn what a high-level assembler looks like.

A language like Smalltalk or Self should be thrown into the mix somewhere, just for contrast.

Some sort of prolog should prove useful as well. (Although, if you seriously think that adopting the prolog viewpoint for general computing, you need to be shot in the face.)

And if trying all these languages doesn't improve your code... you're in the wrong job.

(As for laziness... that's a virtue, according to Larry Wall, and he's likely right.)

Personally, I found that once Generics and Annotations were imposed on Java, the language became a lot harder to read and maintain. They might as well just gone ahead and mandated the abomination that is hungarian notation and made the language completely stupid.

But then, Java was something like language #11 that I learned. So my viewpoint is biased.

Support for other languages in the JVM might be nice, but I really don't see the point.

Comment Re:Are they -trying- to kill Firefox? (Score 1) 683

Add-ons are the only reason I use Firefox. If they simply start breaking at random I might as well just use Chrome.

I use NoScript, It's All Text, and Greasemonkey.

If a magical upgrade breaks these, I'll be unhappy, and I'll be unhappier still without an ability to indicate to what version I need to roll back TO in order to get 'em to work again. I can see this sort of frustration resulting in simply removing FF from the system entirely, and never bothering to look at subsequent releases again. It's not like I haven't already done that with certain OTHER browsers already.

If some other browser (Opera? Safari?) rolls these add-ins in to their core browser in some form or another, I'll probably seriously look into jumping off the FF ship.

Comment Re:You don't want to do this. (Score 1) 554

Everyone has way too many things to do, so your argument that you have way too many things to do is a bit specious.

Let's look at this logically, on a case-by-case basis:

0) You don't have email.

This is the degenerate case. In this situation, it doesn't matter what I do, you don't have email, you're not going to get them anyway. No problem.

1) You run your own mail-server.

This is a non-typical case, but since you're on /., you're presumably technically astute, so it's a possibility.

If you're running your own mail server, you *choose* which blacklists to use, and you have final control over what is or is not accepted on your system. The responsibility is yours to configure your system to accept valid email, not to blindly follow the dictates of some blacklist service.

2) You use someone else's mailserver.

(a) You have contact information for your service provider.

If I'm sending you email, and your service's mailserver is ignoring my valid email because the blacklist they're using is painting large swaths of the 'net with a rather wide brush, then the fault is theirs. It is your responsibility to contact your service provider and notify them of this problem, and leave it up to them to fix the problem.

(b) You have no contact information for your service provider.

You're doomed. Any sort of problem with your mail will cut you off from the rest of the world. Not getting my email is the least of your problems. and nobody else on the Internet can be expected to take the time to cater to your screwed up situation. Remember, everyone has way too many things to do.

* * * * *

Now, all of this is predicated on a few assumptions that should be called out and made clear. First of all, there's a presumption that I'm running a proper mailserver, and I'm not running an open relay, or spamming people, or engaging in other unsavory activities.

Should my system engage in activities that would get my system blacklisted with good reason, then it *does* become my responsibility to remove my system from the blacklist(s) in question. Why my system is engaged in unsavory activities is irrelevent -- it doesn't matter if my system was compromised, or if I'm actually using it to spam people. My system, my problem.

Second, there's a presumption that my system is abiding by the appropriate network standards and protocols. If I'm sending out email with illegal formats, there's no guarantee that anyone should accept it. Bringing my system into compliance is my responsibility, not yours, or anyone else's.

Third, we're talking about blacklists, and not about the content of the message being sent wrongly being identified as spam. That's a separate issue, and requires a modicum of agreement between the sender and the receiver that's outside of this situation. (It can be a worthwhile discussion all on its own.)

* * * * *

I'm not sure I understand your analogy about a government accepting packages.

Comment Re:You don't want to do this. (Score 1) 554

The minute you hit operation, you'll find that you might already be on spam lists, and that you have to fight to get yourself off of them. The minute you find that you're off the lists, you'll probably end up back on them because someone three ip addresses away has been sending welcome emails from his web site, and someone forgot that they asked for one.

It's partially a matter of what you want to deal with, and how comfortable you are with making some issues somebody else's problem. Set up your own system. Tell friends, family, and employers your new set of email addresses.

If they can't send you email because you're on some blacklist, have *them* tell *you* how to get off that blacklist.

Follow these instructions once, if reasonable.

After that, tell them that their mail server is broken, and it's their problem, not yours. Then stop worrying about it. "YOUR service put ME on a blacklist without cause. YOU should use a better service if you want to hear from me."

Online vendors are even better. They have an incentive to make sure they receive email from you. If they use a blacklist service that drops you... take your business elsewhere. Call them if they have a 1-800 number to tell them about the issue of you're feeling nice.

Part of the problem here is that a lot of people have set up email servers for a commercial enterprise, and they bring home the set of best practices and habits -- so that when they set up their home system, they forget that it isn't a commercial system.

Remember, telling a friend, relative, or business "*Your* system is rejecting my RFC-complaint emails. *You* should look into fixing that if you want to hear from me." is perfectly acceptable, even though a business telling you exactly the same thing isn't.

Slashdot Top Deals

"For the love of phlegm...a stupid wall of death rays. How tacky can ya get?" - Post Brothers comics