Ok, your code examples are beyond wrong-headed. They're just frickin' wrong, and illustrate a very poor grasp of abstraction. What you're essentially saying is that security concerns cannot be abstracted.
They can.
Your DeletePicture(int pictureId) example could be a method of a class (let's call it PictureManager) that depends on an ISecurityContext implementation (or an IPictureDataProvider whose concrete class depends on an ISecurityContext, or any other runtime configuration that happens to be appropriate). The nice bit about that is you can abstract the security portion away, and test your class in isolation. Your example actually is indicative of one of the sources of many bugs: coupling. You're coupling the responsibility of every piece of code to security. What if someone then comes along and says, "We now have a priority to gather analytics on our API. This is just as high a priority and just as critical as security." Your way means modifying the method signatures of every method in the system. That's bad design. Go back to school, kid. You've got a lot to learn.
This is probably the most politically-incorrect thing to say, but have no mercy for people who fail to communicate clearly, both written and verbal, in English. This causes SO MANY problems. If they can't communicate clearly, you can't trust them in front of customers, you can't trust them to do what you ask, and you will constantly struggle with miscommunication. And, FOR THE LOVE OF GOD, tell them why you didn't choose them.
[...]hair brained library written in a language that uses tabs for scoping.
Making comments like this clearly reveal that your 30 years' experience in programming hasn't taught you to appreciate the benefits and drawbacks in any given programming language. I suppose you're probably more liberal with venting your opinions on/. than you would be with your CEOs and CFOs, but still, this ingnorant drivel deflates your argument. I've encountered lots of programmers who've seen it all and been there done that and appear to have a similar attitude to yours about young people. I recommend you should spend some time doing some code maintenance, bug fixing, or even some unit testing in an open-source Python project before you write it off.
That being said, I totally agree about ethics in our craft. I find that the quick fix is far to often applied. Then, when someone mentions that something needs to be revisited in the next release, the managers cover their ears and say "la la la, can't hear you, it's already in the field working right, that means it's perfect!" While it's true that few of us are building software systems for the space shuttle, that doesn't justify building code that behaves like a Rube Goldberg machine.
I live in a neighborhood with a neighborhood covenant that restricts, for one, dishes and antennas that extend beyond the roof of the house or sit on the front of the house. While this may cause some inconvenience, the same neighborhood covenant also prevents someone from leaving a broken-down vehicle up on cinder blocks in his front yard for an indeterminate amount of time. Ultimately, it protects the value of my house and my neighborhood by making sure I don't live near unsightly things that will lower my property value. Neighborhood covenants aren't for everyone, but they do help mitigate risk of property value depreciation if such mitigation is more valuable to you than the "right" to keep the externally-visible parts of your home & yard looking trashy.
This is not suitcase snooping, this is opening a sealed envelope found within my suitcase and reading the contents even though both the suitcase and envelope test negative on the bomb sniffer.
I'm no conspiracy theorist, but to ignore the political knee-jerk reaction that occurred when these events happened is just ignorant. *gasp* No, you think? =)
Heckling aside, you're right - if people are paid to find terrorist plots, they will certainly find them whether they exist or not.
If simplicity is out, why is the iPod doing so well? Because it puts an easy-to-use UI on top of something that's far from trivial for the run-of-the-mill technophobe. The iPod is not a simple device. There's a lot of complexity and innovation under the hood of an iPod; it appears "simple" because it gives you smart UI abstractions to let you get down to what you really want: listening to the song(s) that you want. You don't have to spend much effort "learning" the iPod, yet it's got most of the features you'd ever want for a portable mp3 player.
That's right: "clean and spare design" can not be described as "simplicity".
Spolsky listed (and you even quoted!) plenty of other things besides just "clean and spare design" regarding his take on the reasons behind the iPod's success (building an audience, evangelism, emotional appeal, aesthetics, fast response time, direct and instant user feedback, program models which correspond to the user model resulting in high usability, and putting the user in control). The iPod is not a simple device. It appears simple because it was designed to be easy-to-use; however, its complexities are evident from just a quick test drive. It's just that you're not getting brow-beaten to use features you don't care about, and you don't have to learn some sort of new iPod-ish paradigm just to figure out how to pick which song(s) you want to hear.
Seems like lots of people in this thread are confusing "simplicity" with "ease-of-use". A product can be complex, yet still easy to use.
Every year thousands of votes aren't counted because there's some ambiguity in how the voter intended to vote.
This is ridiculous! If a paper ballot has an ambiguity and won't be counted, it should be flagged as such as soon as it's inserted into the machine so that the voter can have some sort of opportunity to ensure that their vote is counted. This is a terrible argument for touch-screen voting.
Think about this for a moment; this means that things like ballot ordering or candidate name has an influence on whether or not your vote will even be counted, and you wouldn't ever know.
Why would you want a job at a megacorporation [...] coding in one of those ironclad languages with layers upon layers of redundant abstractions and frameworks that in the end do exactly the same as ten lines of Perl?
Because those ten lines of Perl look like line noise.
(-1, Troll)
Just kidding. I don't think the issue here is much about the technology or language, it's all about the work environment. Give the devil his due, Microsoft didn't do a completely terrible job with the.NET languages. They're not bad to work with. The issue here is what kind of work environment you want to be in. Swap the circumstances: put the large company with Perl, and the small company with.NET. It's still the same wrestling match, because you'll still be doing the mundane, never-gonna-make-a-difference programming in the bigger company.
But aren't these emails ALREADY hitting email servers? It sounds like this speculation is FUD-y.
I mean, it's not like Spamhaus somehow redirects the emails to itself like some sort of Intarweb spam-specific black hole.
As I understand it:
1. Spam is sent by spammer (it's taking bandwidth). Because of how mail packets flow through multiple redundant paths, each mail takes up bandwidth many times its raw packet size.
2. Spam hits email server (it's taking CPU time to process)
3. Email server checks against Spamhaus blacklist (dunno if this is bandwidth, CPU, or both - I'm not terribly familiar if Spamhaus caches that information locally at its client sites)
4. Spam is rejected (taking CPU time)
5. Rejection reply generated/sent (? dunno if it does this; would take CPU+bandwidth both)
So Spamhaus disappears. Yes, it would suck as a email user to get flooded with spam, but would this REALLY cause any more work for the mailservers? I could see (if they are generating rejection replies and sending them) that this might actually be LESS work for CPUs and less bandwidth used.
The way that spamhaus works is by blacklisting IP addresses, not email-specific details of mail coming from those IP addresses. Therefore, email servers can reject the TCP connections from the blacklisted IP address ranges; it is no more complicated (and no more resource-intensive) than IP-address-specific firewall rules. Therefore, the spam messages themselves don't ever get sent and the only bandwidth "wasted" on spam is from the TCP SYN packets that never get a reply.
Does Vim still default to starting in command mode? I suppose it does. For me, this is the biggest damn problem with it. It's a text editor, it should start in insert mode like every other editor.
You're half right, Vim is a text editor. However, it shouldn't do anything like every other editor. Vim works differently because it's supposed to work differently.
Pressing some key to start typing is bloody annoying, then pressing Esc to insert commands is also annoying. Ctrl-sequences are much better, and the default insert mode means I can do simple text editing and slowly learn other commands of the editor. To be honest, I also find Vim's shortcuts extremely unintuative. Want to go to the end of the document? 99% of editors, Ctrl-end. Vim, G. Sorry, that's retarded.
Perhaps you're "retarded" for failing to ask "Why does Vim do that?" Again, Vim is supposed to work differently. Let's say you want to perform a regex pattern replacement on all lines from the one where your cursor is until the end of the file. Well, that's simple; highlight the lines using the command
VG
(V for Visual highlight by line, and G, as you complained about, to go to the end of the file). Now, let's put that together with a pattern replacement:
VG:s/that's retarded/I'm too lazy and closed-minded to look beyond my own lack of understanding to appreciate software that's been tried and tested for decades/
That replaces all instances of "that's retarded" with "I'm too lazy and closed-minded to look beyond my own lack of understanding to appreciate software that's been tried and tested for decades". As a bonus, when you use regex pattern replacement, Vim will also automatically mark all places in the file that match the search pattern so that you can easily navigate through them using 'n' and 'N'. Wasn't that fun? For bonus points, you can go figure out why it's easier to modify a macro stored in a named buffer if that macro consists of printable characters instead of CTRL- sequences.
Maybe it's based in the days of legacy terminals that didn't have arrow keys or even control sequences, but we're not in those days anymore; it's the text editor equivalent of still using a green-on-black text-only monitor.
Vim recognizes arrow keys quite well. The Windows port even behaves reasonably well with your standard CTRL- sequences, too. I know this is/., but perhaps you should keep your criticisms to yourself until you've made a reasonable effort to determine why those "retarded" things work as they do.
Slashdot Mirror
Ok, your code examples are beyond wrong-headed. They're just frickin' wrong, and illustrate a very poor grasp of abstraction. What you're essentially saying is that security concerns cannot be abstracted.
They can.
Your DeletePicture(int pictureId) example could be a method of a class (let's call it PictureManager) that depends on an ISecurityContext implementation (or an IPictureDataProvider whose concrete class depends on an ISecurityContext, or any other runtime configuration that happens to be appropriate). The nice bit about that is you can abstract the security portion away, and test your class in isolation. Your example actually is indicative of one of the sources of many bugs: coupling. You're coupling the responsibility of every piece of code to security. What if someone then comes along and says, "We now have a priority to gather analytics on our API. This is just as high a priority and just as critical as security." Your way means modifying the method signatures of every method in the system. That's bad design. Go back to school, kid. You've got a lot to learn.
I find that password-protected zip files work marvelously well on portable media.
This is probably the most politically-incorrect thing to say, but have no mercy for people who fail to communicate clearly, both written and verbal, in English. This causes SO MANY problems. If they can't communicate clearly, you can't trust them in front of customers, you can't trust them to do what you ask, and you will constantly struggle with miscommunication. And, FOR THE LOVE OF GOD, tell them why you didn't choose them.
A no-broadcast policy breaks Wake-on-LAN.
All I want to know is rods to the hogshead!
I think this guy is asking to be whacked in the noggin with a smooth stick, probably for attempting to be funny using an extremely worn-out joke.
Making comments like this clearly reveal that your 30 years' experience in programming hasn't taught you to appreciate the benefits and drawbacks in any given programming language. I suppose you're probably more liberal with venting your opinions on /. than you would be with your CEOs and CFOs, but still, this ingnorant drivel deflates your argument. I've encountered lots of programmers who've seen it all and been there done that and appear to have a similar attitude to yours about young people. I recommend you should spend some time doing some code maintenance, bug fixing, or even some unit testing in an open-source Python project before you write it off.
That being said, I totally agree about ethics in our craft. I find that the quick fix is far to often applied. Then, when someone mentions that something needs to be revisited in the next release, the managers cover their ears and say "la la la, can't hear you, it's already in the field working right, that means it's perfect!" While it's true that few of us are building software systems for the space shuttle, that doesn't justify building code that behaves like a Rube Goldberg machine.
I live in a neighborhood with a neighborhood covenant that restricts, for one, dishes and antennas that extend beyond the roof of the house or sit on the front of the house. While this may cause some inconvenience, the same neighborhood covenant also prevents someone from leaving a broken-down vehicle up on cinder blocks in his front yard for an indeterminate amount of time. Ultimately, it protects the value of my house and my neighborhood by making sure I don't live near unsightly things that will lower my property value. Neighborhood covenants aren't for everyone, but they do help mitigate risk of property value depreciation if such mitigation is more valuable to you than the "right" to keep the externally-visible parts of your home & yard looking trashy.
Two words: Halting Problem.
The phenomenon is known as Tidal Locking.
This is not suitcase snooping, this is opening a sealed envelope found within my suitcase and reading the contents even though both the suitcase and envelope test negative on the bomb sniffer.
Whoa-oh, blackened notebook, bam-ba-lam! Whoa-oh, blackened notebook, bam-ba-lam!
Apparently "coding Gods" am bad at grammar.
Isn't it ironic how Microsoft's site dedicated to open-source has a big, fancy, proprietary Flash movie at its core?
Heckling aside, you're right - if people are paid to find terrorist plots, they will certainly find them whether they exist or not.
Link to the project's homepage
Seems like lots of people in this thread are confusing "simplicity" with "ease-of-use". A product can be complex, yet still easy to use.
Every year thousands of votes aren't counted because there's some ambiguity in how the voter intended to vote.
This is ridiculous! If a paper ballot has an ambiguity and won't be counted, it should be flagged as such as soon as it's inserted into the machine so that the voter can have some sort of opportunity to ensure that their vote is counted. This is a terrible argument for touch-screen voting.
Think about this for a moment; this means that things like ballot ordering or candidate name has an influence on whether or not your vote will even be counted, and you wouldn't ever know.
Why would you want a job at a megacorporation [...] coding in one of those ironclad languages with layers upon layers of redundant abstractions and frameworks that in the end do exactly the same as ten lines of Perl?
.NET languages. They're not bad to work with. The issue here is what kind of work environment you want to be in. Swap the circumstances: put the large company with Perl, and the small company with .NET. It's still the same wrestling match, because you'll still be doing the mundane, never-gonna-make-a-difference programming in the bigger company.
Because those ten lines of Perl look like line noise.
(-1, Troll)
Just kidding. I don't think the issue here is much about the technology or language, it's all about the work environment. Give the devil his due, Microsoft didn't do a completely terrible job with the
Perhaps you're "retarded" for failing to ask "Why does Vim do that?" Again, Vim is supposed to work differently. Let's say you want to perform a regex pattern replacement on all lines from the one where your cursor is until the end of the file. Well, that's simple; highlight the lines using the command (V for Visual highlight by line, and G, as you complained about, to go to the end of the file). Now, let's put that together with a pattern replacement: That replaces all instances of "that's retarded" with "I'm too lazy and closed-minded to look beyond my own lack of understanding to appreciate software that's been tried and tested for decades". As a bonus, when you use regex pattern replacement, Vim will also automatically mark all places in the file that match the search pattern so that you can easily navigate through them using 'n' and 'N'. Wasn't that fun? For bonus points, you can go figure out why it's easier to modify a macro stored in a named buffer if that macro consists of printable characters instead of CTRL- sequences. Vim recognizes arrow keys quite well. The Windows port even behaves reasonably well with your standard CTRL- sequences, too. I know this is
If ever we had a reason to tag articles as 'Flamebait', this one's it.
...as those persons whose technical acuities are slightly greater than "Script Kiddies". Maybe I just hate PHP.
Doc!? What the hell is a jigga-dollar?