However, I stay clear of Java or Visual Studio only people. They have a truly warped and unrepairable mindset.
Stay clear of anyone who is [anything]-only.
Anyone who will only use one language will warp all problems to that language -- and worse, warp all solutions to only those that they don't have to think about. It doesn't matter if the language is Java, C#, C++, C, Perl, Python, Ruby, or COBOL. If they are only willing to code in one language, let them go.
Nearly every accredited university offers "language survey" courses. This is where a CS degree can be useful -- the graduates have, in theory, been exposed to other languages. Bring this up in the interview. See if they can articulate the tradeoffs of various languages.
Entirely-self-taught developers often require a lot of basic remedial training. I'd suggest investing in them only if they will spend their evenings completing a CS degree. For an intelligent and skilled person, this isn't terribly difficult. The ones to be careful with are the "Meh, I can't be bothered to obtain/complete a degree." types. They might be intelligent, and they might be skilled. But their ego is going to make a lot of work for everyone else, as that can't-be-bothered attitude is a sign.
(Yes, there are lots of people who could only possibly succeed in an academic environment where the problem is carefully structured to be completed in five weeks by a mediocre and distracted person. This is where "what do you do in your free time?" comes in useful. One of the best teams I've ever worked on had "What are the last three books you've read for pleasure, and when?" as a key interview question.)
They can see an artistically choreographed fireworks show next year. They probably saw one last year. Around here they do one every Thursday, all summer. How often do you get to see what happens when all the fireworks go off at once?
Every night during the summer SeaWorld has a fireworks show at 9:45.
The only good reason to complain about this is if you didn't catch it.
The thought might occur, and has occurred to many, but that doesn't make it useful.:)
Typically, on-ramps aren't all of the cloverleaf design - there is an intersection where the on/off ramp meets with the cross-road, and a stop sign or stoplight at the intersection. (Even on-ramps *with* a cloverleaf design often have drivers in heavy squishy-suspension vehicles slowing down traffic behind them to ~10mph, with the resulting excitement. Such driver+vehicles aren't all that uncommon, alas.)
And then there are the congestion-control lights, which are typically put *on* the on-ramp itself, with a little sign indicating that 1 or 2 cars can go when the light turns green. (There are sensors to count how many cars *actually* go through, and whether or not the light was green at the time. They track these things quite carefully.)
"Fixing" such things would be more than what a traffic engineer could manage; businesses and/or employees would have to be relocated to better control the flow of people from one place to another, which has its own huge set of downsides. Engineering-wise, it's a bad tradeoff.
Why the hell do people obsess about 0-60 time? How often do you ever accelerate flat out from 0 to 60?
Freeway on-ramps. I average a half-dozen times a day when I put the foot down and shift > 5k rpm.
Now whether or not that's a good idea is another thing, perhaps worthy of discussion. If we all drove VW microbuses then I imagine we'd not care so much about acceleration or top speeds.
But as it is, our expectations have been set. Given that air resistance is such a big factor, we could probably greatly extend the max distance simply by setting 25mph as a maximum speed for all vehicles -- but it would then take me over an hour to get to work, which is a change I wouldn't be happy with at all.
Doesn't matter, if you are buying one of these to save money, you are making a mistake. If you are buying on of these to save the environment, you'd be better off buying a Honda Civic and spending the $30,000 planting trees or something.
It is amazing how many people don't actually bother to do the math before buying an electric or hybrid vehicle. They may pretend to do the math, but then add in an undefined fudge factor big enough to "fix" the problem, hiding it behind assertions of "it's obvious".
It's not that it's a bad idea to buy these sorts of cars. It's just annoying to hear someone blather about how much money they're (going to be) saving when one has done the math and they haven't.
Then again, I keep a "stupid little book", so I know *exactly* what the TCO is for my vehicles. Most people don't bother, and so they need to wave their hands a lot and go by "gut feeling", so it's no wonder that they get the math wrong. They don't have actual data.
If I am enjoying some music, do I owe the artist for that enjoyment? (Owe in the sense of "some money or obligation is due" rather then the sense of "resulting from".)
Good question.
Here's a principle to live by:
Value given for value received.
If you stand and listen to a busker, toss a few coins into the hat or case.
If you listen to a song on the radio, remember that it's been paid for by advertising (generally). If the commercial isn't actively annoying or stupid[1], let it play -- you're the product, the music is the lure, and the customer is the advertiser, and if you like the music, you want the customer to keep paying, right?
If you buy the CD or pay for a download from iTunes[2], you've purchased _a_ product. Treat it like a book -- you might loan it to friends, you might copy small portions of it to use in your journal or other personal work -- but remember that it isn't yours to distribute widely (yet).
Here's where things start to get tricky... there's a lot of crap out there. A lot of the music is utter drek, and you deserve the three minutes of your life back after listening to something that purports to be "culture", much less paying $18 for a CD or $10 for an album[3].
That's not good value.
With the advent of cassette recorders, we had a try-before-you-buy model: friends would make friends mix-tapes as a way of informing them about artists they liked. If the friend liked that artist, he'd be inclined to go out and buy that artist's work. This was a good thing, and while technically stealing, it was more like grassroots advertising.
The advent of anonymous file-sharing broke the try-before-you-buy model -- broke it hard. People amassed music collections they'd never be able to listen to, solely as virtual currency in the the file-sharing systems. They're receiving value without giving it in one frame of reference, and engaged in some quite serious value exchanges in another frame of reference.
Others announced[4] that they'd no longer be wasting money actually *buying* music, when all this "free" music was available. What's amazing is that these sorts of people tend to hold very dim views of "leeches" -- those who only take shared music, and never share their own. This is the whole purpose of technologies like BitTorrent -- to MAKE people share, rather than to simply consume at the edges. The hypocrisy is rather stunning.
And now we have the new generation that has never bothered with trying to own music. It's just there, freely available, practically an entitlement -- modulo some jerk whining about how it's theft. The implicit agreement has changed: artists are now supposed to create content for all to share -- and some artists are unhappy about this.
However.
The artists and their representatives changed the agreement first. Thank you Sonny Bono.
Copyrights used to be quite limited. And now they look to be effectively forever. That's not the agreement! And when one side unilaterally changes a contract, surely it's fair for the other side to do the same thing.
And that, I think, is where we're at. We had a sort of value-given-for-value-received arrangement, and then one side broke it, and now we have the backlash. A new arrangement[5] is needed, a new agreement between artists, infrastructure, and consumers. We've broken the old one beyond repair[6].
We need a new arrangement. A new agreement. And it needs to have buy-in from all players, not just the one with the upper hand at the moment. Dictating unreasonable terms never results in a lasting solution.
[1] If it is actively annoying or stupid, switch stations. Don't reward advertisers for producing crap advertisements. Their product needs to be entertaining as well. That's part of the game, after all; paying for the music is only half the bargain. They buy a spot, not your actual attention.
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.
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.
"You accessed the very heart of the system of an international business of massive size, so this was not just fiddling about in the business records of some tiny business of no great importance," he said.
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.)
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.)
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.
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.
"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.
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.
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.
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.
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.
You need to sit back and look at your language, and what it says about what you're trying to do.
You have a team that's trusted by customers, and you want to *empower* *them* to think like salespeople? When your corporate culture has produced salespeople so lacking in integrity that your own customer base has come to the conclusion that those salespeople are only interested in "alleviating them of their money"?
Your technical team is working *fine*. Don't break it.
Your sales team sounds dysfunctional and broken. Fix it.
As a general rule, fix what's broken before you mess with what works. This is counter to most corporate cultures (which has a tendency to kill the goose laying the golden eggs by trying to 'fix' the goose to lay larger eggs), so don't try to ape others without some analysis.
In the end, the best sales technique is to make it trivially easy for someone to give you money, and to make something that someone would want to give you money for. In this world, making it easy for the technical staff to say "oh, we have a product that'll solve that problem, let me give you a single-user ninety-day license for that." would go a long way towards exposing your products to your customers without spoiling your technical team's reputation.
(And WTF is this 'service orientated' crap? I doubt the technical team would describe themselves that way, although they might say 'service oriented'.)
And while the easy-bake oven is almost a decent analogy, the existence of relatively more open Android devices kills it. You can't say an Android phone isn't intended for the same things -- both Android and iOS are targeting the exact same users, use cases, etc. It's much more like the difference between two otherwise-identical toasters, one of which can have the temperature and cooking-time adjusted, and the other always produces toast of precisely the shade of brown Steve Jobs favors.
I carry both an Android phone and an iPhone.
I prefer the iPhone.
The Android does *more*, but I find it less pleasant to use overall. The iPhone is a toaster with three settings, while the Android is a toaster-oven with seventeen dials and a bling switch.
And after six months of equivalent use, you'd be sad that you couldn't make pizza in your iPhone toaster, and that the three settings wasn't ideal for toasting your cinnamon bagel. But the Android toaster-oven has burned you at least once a week, has turned itself on for no apparent reason five times, has turned itself off while in use fourteen times, and unplugged itself from the wall three times. Further, despite all the settings, you've never actually managed to get anything toasted exactly the way that you want -- the color might be right, but the texture isn't, or the color is right and the texture is right, but the crusts have been cut off.
So.
I think Android wins on the flexibility front. And I think the iPhone wins on the usability front.
(And this bothers me, since I've long been an advocate for flexibility -- but in practice, it's just not working for me.)
I can do less with the iPhone, but what I *can* do is pretty damn good. I can do more with the Android, but the WTF? rate is much higher, and quite a lot higher in the common usage cases.
How much of these differences are between the hardware or the carrier, I don't know. And as an end-user, I don't care. I want a reliable, predictable, *consistent* experience, and the Android isn't giving me that, for all that it lets me do five gazillion things *more*.
The major flaw *I* find with Java is the incredible mess it makes of I/O (but some people seem to like it). A less basic flaw is the mess it made of generics. I understand that this was to maintain compatibility with older code, but it's not worth it. A different answer should have been found. I guess it's a matter of taste, but I really dislike the classes wrapped around classes wrapped around classes kind of syntax that Java promotes. (It's not inherent in the language, but in the esthetics of the library designers.) I can see the utility, but it's really ugly, and a different approach should have been found. But that might have required either multiple inheritance or mixins.
The wide-char stuff in Java is the messiest part, in my opinion, while the multitude of stream classes were the nicest. What *part* of I/O bothers you the most?
Generics are indeed a mess. All I wanted was covariant return types, but instead the language got screwed up by the type-theory weenies. Of all the problems I had seen in Java code by that time, getting the wrong type out of a container instance resulting in a class cast exception was *not* a common problem. It was a clever solution looking for a problem, which is a recipe for disaster.
Which, really, is the key lesson that isn't being learned by most of the folks who want to improve on Java: clever is a bad idea unless it solves an actual problems encountered by real programmers, as opposed to solving concocted problems by theory-minded boffins.
Slashdot Mirror
Stay clear of anyone who is [anything]-only.
Anyone who will only use one language will warp all problems to that language -- and worse, warp all solutions to only those that they don't have to think about. It doesn't matter if the language is Java, C#, C++, C, Perl, Python, Ruby, or COBOL. If they are only willing to code in one language, let them go.
Nearly every accredited university offers "language survey" courses. This is where a CS degree can be useful -- the graduates have, in theory, been exposed to other languages. Bring this up in the interview. See if they can articulate the tradeoffs of various languages.
Entirely-self-taught developers often require a lot of basic remedial training. I'd suggest investing in them only if they will spend their evenings completing a CS degree. For an intelligent and skilled person, this isn't terribly difficult. The ones to be careful with are the "Meh, I can't be bothered to obtain/complete a degree." types. They might be intelligent, and they might be skilled. But their ego is going to make a lot of work for everyone else, as that can't-be-bothered attitude is a sign.
(Yes, there are lots of people who could only possibly succeed in an academic environment where the problem is carefully structured to be completed in five weeks by a mediocre and distracted person. This is where "what do you do in your free time?" comes in useful. One of the best teams I've ever worked on had "What are the last three books you've read for pleasure, and when?" as a key interview question.)
As for the 10% effect ... Sturgeon's Law.
Every night during the summer SeaWorld has a fireworks show at 9:45.
The only good reason to complain about this is if you didn't catch it.
The thought might occur, and has occurred to many, but that doesn't make it useful. :)
Typically, on-ramps aren't all of the cloverleaf design - there is an intersection where the on/off ramp meets with the cross-road, and a stop sign or stoplight at the intersection. (Even on-ramps *with* a cloverleaf design often have drivers in heavy squishy-suspension vehicles slowing down traffic behind them to ~10mph, with the resulting excitement. Such driver+vehicles aren't all that uncommon, alas.)
And then there are the congestion-control lights, which are typically put *on* the on-ramp itself, with a little sign indicating that 1 or 2 cars can go when the light turns green. (There are sensors to count how many cars *actually* go through, and whether or not the light was green at the time. They track these things quite carefully.)
"Fixing" such things would be more than what a traffic engineer could manage; businesses and/or employees would have to be relocated to better control the flow of people from one place to another, which has its own huge set of downsides. Engineering-wise, it's a bad tradeoff.
Freeway on-ramps. I average a half-dozen times a day when I put the foot down and shift > 5k rpm.
Now whether or not that's a good idea is another thing, perhaps worthy of discussion. If we all drove VW microbuses then I imagine we'd not care so much about acceleration or top speeds.
But as it is, our expectations have been set. Given that air resistance is such a big factor, we could probably greatly extend the max distance simply by setting 25mph as a maximum speed for all vehicles -- but it would then take me over an hour to get to work, which is a change I wouldn't be happy with at all.
And THAT, boys and girls, is how a responsible adult justifies buying this sort of vehicle.
It is amazing how many people don't actually bother to do the math before buying an electric or hybrid vehicle. They may pretend to do the math, but then add in an undefined fudge factor big enough to "fix" the problem, hiding it behind assertions of "it's obvious".
It's not that it's a bad idea to buy these sorts of cars. It's just annoying to hear someone blather about how much money they're (going to be) saving when one has done the math and they haven't.
Then again, I keep a "stupid little book", so I know *exactly* what the TCO is for my vehicles. Most people don't bother, and so they need to wave their hands a lot and go by "gut feeling", so it's no wonder that they get the math wrong. They don't have actual data.
Good question.
Here's a principle to live by:
Value given for value received.
If you stand and listen to a busker, toss a few coins into the hat or case.
If you listen to a song on the radio, remember that it's been paid for by advertising (generally). If the commercial isn't actively annoying or stupid[1], let it play -- you're the product, the music is the lure, and the customer is the advertiser, and if you like the music, you want the customer to keep paying, right?
If you buy the CD or pay for a download from iTunes[2], you've purchased _a_ product. Treat it like a book -- you might loan it to friends, you might copy small portions of it to use in your journal or other personal work -- but remember that it isn't yours to distribute widely (yet).
Here's where things start to get tricky... there's a lot of crap out there. A lot of the music is utter drek, and you deserve the three minutes of your life back after listening to something that purports to be "culture", much less paying $18 for a CD or $10 for an album[3].
That's not good value.
With the advent of cassette recorders, we had a try-before-you-buy model: friends would make friends mix-tapes as a way of informing them about artists they liked. If the friend liked that artist, he'd be inclined to go out and buy that artist's work. This was a good thing, and while technically stealing, it was more like grassroots advertising.
The advent of anonymous file-sharing broke the try-before-you-buy model -- broke it hard. People amassed music collections they'd never be able to listen to, solely as virtual currency in the the file-sharing systems. They're receiving value without giving it in one frame of reference, and engaged in some quite serious value exchanges in another frame of reference.
Others announced[4] that they'd no longer be wasting money actually *buying* music, when all this "free" music was available. What's amazing is that these sorts of people tend to hold very dim views of "leeches" -- those who only take shared music, and never share their own. This is the whole purpose of technologies like BitTorrent -- to MAKE people share, rather than to simply consume at the edges. The hypocrisy is rather stunning.
And now we have the new generation that has never bothered with trying to own music. It's just there, freely available, practically an entitlement -- modulo some jerk whining about how it's theft. The implicit agreement has changed: artists are now supposed to create content for all to share -- and some artists are unhappy about this.
However.
The artists and their representatives changed the agreement first. Thank you Sonny Bono.
Copyrights used to be quite limited. And now they look to be effectively forever. That's not the agreement! And when one side unilaterally changes a contract, surely it's fair for the other side to do the same thing.
And that, I think, is where we're at. We had a sort of value-given-for-value-received arrangement, and then one side broke it, and now we have the backlash. A new arrangement[5] is needed, a new agreement between artists, infrastructure, and consumers. We've broken the old one beyond repair[6].
We need a new arrangement. A new agreement. And it needs to have buy-in from all players, not just the one with the upper hand at the moment. Dictating unreasonable terms never results in a lasting solution.
[1] If it is actively annoying or stupid, switch stations. Don't reward advertisers for producing crap advertisements. Their product needs to be entertaining as well. That's part of the game, after all; paying for the music is only half the bargain. They buy a spot, not your actual attention.
[2] Or iTunes-like service, of course.
[3] Cost of production and di
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.
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.
"You accessed the very heart of the system of an international business of massive size, so this was not just fiddling about in the business records of some tiny business of no great importance," he said.
ooo, that's got to hurt.
Basically, "size does matter".
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.
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.)
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.
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.
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.
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.
Seconded.
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.
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.
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.
Well, duh. Don't start using a personal mailserver for business.
Keep business and personal life separate. If you don't, you'll be screwed in more ways than having email be more unreliable.
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.
Not retaliation. Vengance is not justice.
But those involved, and those who managed those involved, should lose their jobs, pensions, and freedom, as punishment for their misdeeds.
For a business with the resources to make an internship useful, the difference between minimum wage and nothing is lost in the noise.
You need to sit back and look at your language, and what it says about what you're trying to do.
You have a team that's trusted by customers, and you want to *empower* *them* to think like salespeople? When your corporate culture has produced salespeople so lacking in integrity that your own customer base has come to the conclusion that those salespeople are only interested in "alleviating them of their money"?
Your technical team is working *fine*. Don't break it.
Your sales team sounds dysfunctional and broken. Fix it.
As a general rule, fix what's broken before you mess with what works. This is counter to most corporate cultures (which has a tendency to kill the goose laying the golden eggs by trying to 'fix' the goose to lay larger eggs), so don't try to ape others without some analysis.
In the end, the best sales technique is to make it trivially easy for someone to give you money, and to make something that someone would want to give you money for. In this world, making it easy for the technical staff to say "oh, we have a product that'll solve that problem, let me give you a single-user ninety-day license for that." would go a long way towards exposing your products to your customers without spoiling your technical team's reputation.
(And WTF is this 'service orientated' crap? I doubt the technical team would describe themselves that way, although they might say 'service oriented'.)
I carry both an Android phone and an iPhone.
I prefer the iPhone.
The Android does *more*, but I find it less pleasant to use overall. The iPhone is a toaster with three settings, while the Android is a toaster-oven with seventeen dials and a bling switch.
And after six months of equivalent use, you'd be sad that you couldn't make pizza in your iPhone toaster, and that the three settings wasn't ideal for toasting your cinnamon bagel. But the Android toaster-oven has burned you at least once a week, has turned itself on for no apparent reason five times, has turned itself off while in use fourteen times, and unplugged itself from the wall three times. Further, despite all the settings, you've never actually managed to get anything toasted exactly the way that you want -- the color might be right, but the texture isn't, or the color is right and the texture is right, but the crusts have been cut off.
So.
I think Android wins on the flexibility front. And I think the iPhone wins on the usability front.
(And this bothers me, since I've long been an advocate for flexibility -- but in practice, it's just not working for me.)
I can do less with the iPhone, but what I *can* do is pretty damn good. I can do more with the Android, but the WTF? rate is much higher, and quite a lot higher in the common usage cases.
How much of these differences are between the hardware or the carrier, I don't know. And as an end-user, I don't care. I want a reliable, predictable, *consistent* experience, and the Android isn't giving me that, for all that it lets me do five gazillion things *more*.
The wide-char stuff in Java is the messiest part, in my opinion, while the multitude of stream classes were the nicest. What *part* of I/O bothers you the most?
Generics are indeed a mess. All I wanted was covariant return types, but instead the language got screwed up by the type-theory weenies. Of all the problems I had seen in Java code by that time, getting the wrong type out of a container instance resulting in a class cast exception was *not* a common problem. It was a clever solution looking for a problem, which is a recipe for disaster.
Which, really, is the key lesson that isn't being learned by most of the folks who want to improve on Java: clever is a bad idea unless it solves an actual problems encountered by real programmers, as opposed to solving concocted problems by theory-minded boffins.