Hmmm. If patents are only for protecting the implementation of an idea, then software already has something which does that: copyright. Copying someone else's way of doing something is already prohibited. (Or at least, actionable.)
So why do we need patents on software, if the very thing that patents were designed to protect is already protected?
Isn't this an argument against all software patents?
...the gap between scripting languages... has been drastically narrowed
Not sure what you mean here -- I suspect you mean the gap between scripting languages and traditional ones.
If so, then I'd like to disagree:-) (And if not, please ignore the rest!)
While scripting languages have certainly closed the gap in terms of speed, and language features, there are more important considerations where they're still very far apart (and rightly so). I'm thinking particularly here of areas such as methodology, security, portability, and especially maintainability.
Take typing, for example. Dynamic typing is easier to write for: you don't have to restrict yourself to particular types, you don't have to decide things like that in advance, and you don't have to repeat information. But that freedom comes at a price: you don't know what types you'll have to deal with, so you can't guarantee you'll be able to handle them. It's much easier to make subtle bugs. And, what's worse: you can't spot any of this until runtime. You've traded ease of writing for difficulty of testing and fixing.
Similarly, the 'there's more than one way to do it' philosophy is often seen as a plus. How could choice be bad? The trouble is that that choice is the writer's choice -- but the writer isn't the only person to work with the code. Something like 80% of the time spent on code is in maintenance. And if there are 10 subtly different ways to do everything, then the maintainer is 10 times more likely to misunderstand what the code is doing, or to have trouble following the idiom. That's where the argument that 'the programmer doesn't need to understand the whole language' falls right down. And a language that allows the writer the freedom to write an incomprehensible mess isn't one that allows the maintainer much peace of mind!
I could go on about many other aspects too. The roll-your-own object model and we-trust-you data hiding are hardly suited to million-line systems. And so on, and so on.
Of course, I'm not saying that dynamic typing or supernumerary language features or whatever will necessarily lead to bad code. I'm sure some Perl code is a model of elegance, clarity, discipline, and correctness. But is all of it? Hardly... I'd far rather rely on a compiler than a developer to find bugs, any day. And I'd far rather rely on a language to encourage clarity than on the self-discipline of some developers I've worked with...
In short, while the facilities of what used to be known as scripting languages have improved tremendously, their philosophy is now what limits them -- that's what makes them unsuitable for huge, complex or critical systems.
So a mutex only allows one process to access its data and prevents access to other processes (or pauses their execution), right?
Yep, spot on. Stands for mutual exclusion -- each process (or thread) excludes the others, so only one can be running the protected region of code at once. Used to be called a monitor, I think.
Languages like Java have this facility built-in (the synchronized keyword), though it's not really enough for complex systems. And I expect things get much more hairy in the kernel...
Why go to the trouble of linking a page which contradicts you?
If I've understood correctly, Ogg wraps FLAC, just as it wraps Vorbis and other streams. And just as FairPlay wraps AAC, and QuickTime wraps all sorts of stuff.
Sure, FLAC can be encapsulated in an Ogg stream, but it has its own lightweight native format that the command-line FLAC tools use, and which exists quite happily without Ogg.
Tbe fully social solution (educating people) has an enormous cost (both in time and money).
Enormous cost? A simple sign up saying "People making a disturbance, using mobile phones or otherwise, will be asked to leave"? Enforcing it a few times? I think people would learn rather quickly...
the jammer's primary function is probably not so much to stop rude people from phoning, as it is to prevent cell phones whose owner has forgotten to turn them off from ringing.
Same problem. And it's still not a good solution.
My phone, for example, is set to vibrating alert, and a ringtone that starts silently, and only gets really loud if I haven't answered/rejected it after 10 seconds or so. In practice, I've usually felt, retrieved and answered/stopped it before anyone else has even heard it. I still turn it off for performances, anyway, but even if I forget, and (even less likely) it started ringing, chances are it wouldn't annoy anyone else. (And for something important, I'd treat it as a pager -- reject the call, see who it was, and then leave the room to return the call.)
I'm not suggesting that this is exactly what everyone should do, but it does show that even ringing phones need not be a disturbance.
People need to find their own ways to reconcile what they want to do with showing respect for other people; not have cumbersome, partial, troublesome 'solutions' forced on them.
How about another analogy:
I don't like being woken up in the small hours by noisy cars (I'm a light sleeper). Should I lobby to make it illegal to drive between midnight and 7am? Yes, it would harm the milk delivery business, but at least I'd get my sleep! And regulations on noise would never be obeyed, so a total ban is the only sensible solution...
I'm not suggesting that mobile access be a right. Just that there should be a more important reason for jamming it than just "It gives some people an excuse to make a nuisance of themselves."
Of course people shouldn't rely on their phones for anything absolutely vital. Coverage can be lost due to intervening architecture, weather, or heavy use by others. Batteries run out. Networks go down. And so on. You can't assume you'll be in coverage in restaurants, cinemas, or anywhere else.
But the 'Jam them' reaction makes me very uncomfortable. Have we become so intolerant of others that anything we don't personally like should be banned? Do we want to live in a society where we're only allowed to do things if everyone explicitly agrees?
Remember: you can't force people to be nice to each other. You can only encourage them by example, and where necessary punish gross infringements.
Jamming phones is a coward's way out. If people are making a nuisance of themselves, then ask them to stop it, or have them thrown out. After all, that's what would happen if people spoke loudly to their neighbours in a theatre; why should speaking loudly into a phone be any different? If a kid takes in a handheld game that makes loud beeping noises, then it should be removed or disabled; again, why it different if a phone makes loud noises? Just because something's technically possible doesn't make it a good solution.
Jamming treats people like children. It effectively says "Since some of you aren't using their phones responsibly, we'll stop anyone using one." And, like many other childish reactions, it doesn't teach people anything. If someone got bounced out from using their phone inconsiderately, then they'd learn something from that! But is it right to punish the majority because of a small minority of inconsiderate people?
As I said, it's exactly the same argument as for P2P. In fact, more so -- if you believe the figures, then the vast majority of P2P traffic is illegal, whereas it's only a minority of mobile users who behave obnoxiously. Most people argue that the former should be allowed for the small proportion of legitimate traffic; yet you're asking to jam phones where a much larger proportion of use is considerate!
I understand why you're sick of obnoxious bastards using their phones offensively, and I share your feelings. I just think that jamming is the wrong solution. Use your feelings in a constructive manner! Stand up and tell someone that they're disturbing everyone! If you want to say a big 'Screw you' to them, then do so -- to their faces, loudly and publicly! If necessary, threaten to stick the phone somewhere anatomically impossible! (Seriously. I expect you'll get cheers from most of those around you.)
Rudeness is the problem, so fight rudeness. Don't fight phones, otherwise the rest of us will suffer, and rude people will just find some other way to be obnoxious!
As Babbage might have said...
on
Java 1.5 vs C#
·
· Score: 1
I am not able to rightly apprehend the kind of confusion of ideas that could provoke such an article!
Yes, of course a loud ringtone, or answering a phone during a performance, is rude, inconsiderate, disruptive, and insulting. I don't think anyone here disagrees.
BUT a jammer isn't the right answer to that! It prevents perfectly legitimate and polite uses of a phone (silent alerts; text and photo messages; genuine emergencies; leaving the room before answering) without actually stopping people from being rude and inconsiderate!
If they don't jam phones, and instead actually enforce a nuisance policy, then people will have to learn to use their phones responsibly (turning them off, or to 'silent running'). And everyone benefits.
Exactly. If the problem is inconsiderate and antisocial behaviour, then fight inconsiderate and antisocial behaviour!
This is exactly comparable to the current fuss about P2P software. Mobile phones have perfectly legitimate and non-infringing uses. (SMS messages, for example. Genuine life-or-death emergencies. Incoming calls where the user doesn't speak, or leaves the cinema before speaking.) Jamming prevents all those, whilst still allowing all the antisocial behaviour people have the rudeness to pull off!
A jammer is just a tool for management too cowardly to enforce a proper nuisance policy.
And of course, this is the thin end of the wedge. If jammers become accepted in cinemas, theatres and churches, they may well spread to restaurants, galleries, museums, shops, cafés, pubs, stations, workplaces...
What's worse is that in this case there is a possible technological measure that would do pretty much what people want. Instead of jamming the phones, how about a short-range transmitter which told the phones to go into 'silent mode', turning off the ringtone, and maybe the microphone, whilst still allowing vibrating alerts, text messages, and maybe incoming calls. It's a bit more technology than phones currently have, but it can't be too hard to implement.
Well, yes, assertions are (almost) always a good idea. If you can test with an assertion, then great!
I was thinking more of things that couldn't be tested with an assertion; higher-level stuff more to do with thought processes and algorithms than with variables and conditions.
And in your example, I agree that the longer function and parameter names are much more readable. But I think that a comment is often useful too. For example, the name alone doesn't make clear what happens if the employee doesn't exist; does it write an empty string? Write nothing? Display an error? And so on. What format is the name in? Is the function thread-safe? Does it rely on an existing database connection? There are always things to consider that won't fit in a simple name, however long.
As I said: make as much clear in the code as you can, and comment everything else!
Well, yes... That's usually a better solution. But sometimes the separate sections are too closely related, too interdependent to be worth doing that. It's generally better to split stuff up, to reduce dependencies; but ultimately, it depends on what the code's doing and how it's organised -- you have to use your judgement instead of blindly following rules.
Also, often function names don't seem to be as meaningful as the author thought. How many 'processFile' functions have been written, and how much does that name tell you?
Oh, and another type of comment I missed out:
Assumption comments. You know the sort of thing: "// Don't bother checking for <special case> because it will have been handled <above>". Not only do these stop someone else puzzling over why something 'obvious' has been left out, but in making your assumptions explicit, they sometimes show you where those assumptions are wrong, or where later code changes make them so.
I'm still waiting for the much-rumoured ability to record music on my 3G iPod...
And I'm not talking about voice notes, either, but CD-quality, stereo, uncompressed audio, from a mic or line input. The iPod chipset is supposed to support this already, so all it would need is a software update. Apparently...
I do concert recordings (with permission), and that would make things so much easier. [fx: sigh]
Sounds like you've had a rough deal -- or there are some real idiots in your workplace; even code reviews can't solve everything!
But I doubt they've been a total waste. For example, knowing their code is going to be reviewed soon makes some people write better code. And in explaining your design decisions, maybe your listener(s) learned something about design. (Or maybe you did!)
My own feeling is that code reviews can be a great way of sharing knowledge about the system, and about development generally, e.g. best practices; they can help to ensure that code doesn't just work but is maintainable; and they can often spot certain types of mistakes. But everyone needs to treat them as a useful and constructive time, otherwise it won't be...
Comments tend to state the obvious and not tell you what you really want to know.
This is a reason to write better comments, not to avoid them completely!
Of course comments that are flippin' obvious, or wrong, do no good to anyone. But some sorts of comments can be incredibly helpful:
Big-picture comments. Explaining what this function, method, class, file, or interface is doing; how it fits into the app or system; important design decisions. Also authorship and date information, if that's important.
API comments. Describing the implicit (or explicit!) contract that a function, method, class or whatever has with its caller. When you should be calling this code, what the caller needs to have set up beforehand, what the code guarantees to do in return, any gotchas.
Section comments. Within long functions, just a few words every 10-30 lines, breaking it up into logical sections, can make it much easier to understand the flow, or find the particular section you're looking for.
Here-be-dragons comments. Describing tricks, shortcuts and other hacks. Better to make the code clear and obvious, of course, but there are times when a clever technique or bit of magic is needed, and for those rare occasions, a few words of explanation can make things so much clearer -- and prevent someone ignorantly 'fixing' it later!
Of course, there's some overlap. But these are the sorts of things that can make code so much easier to read, and don't take much effort to maintain. The big-picture and API comments tend to be common practice in literate languages like Java (JavaDoc) and Perl (POD), but too many people don't follow it -- and even where those comments aren't extracted automatically, they can still be incredibly useful.
My rule of thumb is: Try to make the code itself obvious. And comment everything else!
Just on the off-chance that you were being at all serious, you should know that methane itself doesn't stink -- it has no odour at all. That's why gas companies have to add in a separate chemical to make it smell. If you associate a smell with methane, it's probably the trace organic chemicals, especially the sulphur-containing ones, that are also produced when digesting food...
I don't have a laptop, so I don't know if there are good answers to your problems. I do know that on my desktop Mac, I have no trouble finding any of the characters you mention, or loads more -- all labelled right on the keytops. My only small keyboard is on my Psion, but I accept having a few characters that are hard to type for the sake of having a keyboard that's both pocketable and touch-typable. (And even on that, I can type curly brackets by holding down only two keys...)
Ditto the mouse pad -- though I note that at least one other/.er finds the single-button-style pad more usable, not less.
If Mac apps hang (which I find pretty rare), then the Dock is perfect for switching to other apps, or killing the problem app. No keypresses needed.
If you don't like your Mac, then you're free to use something else, of course. The world is a big place, with room for more than one opinion.
Yes and no. Yes, you can't get cheap Macs, but for what you get, they seem to be fairly competitive with similarly-specced PCs. (I haven't done the analysis myself, but whenever I've seen it done, the Macs come out not much more expensive, and sometimes cheaper.)
b) they're pretty much closed systems
Again, this depends on your criteria. The hardware is closed, but most of the components are standard off-the-shelf ones. And the core OS is open source -- I should know, I've made a couple of fixes myself (one is apparently in OS X 10.3).
I'd not like to assist one monopoly by running from another.
This is a genuine concern. Give Apple a 95% market share, and who knows whether their current drive for compatibility, open standards, and quality would continue? OTOH, MS never had those in mind, even when it was tiny -- it's used predatory and unfair business practices from the word 'Go'.
However, the choice isn't just between one monopoly and another. The chances of OS X gaining 95% market share are tiny, and even a huge Mac purchase won't make that happen. What it will do is help to level the playing field a bit; once people are freer to choose a platform on merit rather than on MS's marketing and legal spend, then everyone benefits. I look for a day when many different platforms each have a reasonable market share.
I only wish I could get OS X for PC hardware.
You and millions of others... But it won't happen, for two reasons. First, economic: unlike MS, Apple is basically a hardware company; their software is often wonderful, but financed from hardware sales, and ultimately drives hardware purchases. To make economic sense, OS X on x86 would have to cost enough to make up for loss of hardware sales, as well as covering the development cost. Which would make it prohibitively expensive.
And second, technical. One of Apple's main selling points is that stuff Just Works(tm). And that's partly because they control the hardware. They know just what hardware they need to support and test against, and integrate the two quite strongly. (For example, look at how long Macs have been able to 'sleep' -- shutting down almost all the hardware, and yet able to wake within a second or two, with all software carrying on perfectly.) Supporting any old x86 hardware -- just like supporting any old PPC hardware -- would either take an unfeasibly large compatibility, testing and drive development department, or leave lots of OS X installations that were a bit flaky, not supporting some hardware and working badly with other. Or, more likely, both.
Why not start wishing for something more realistic? Why do we never hear Windows users saying "MS should port Windows to PPC"...?
OFGS, how often does this ludicrous stupid mouse button argument come up?
Not that it'll make any difference, but just for the record: Mac OS X supports multiple mouse buttons and scroll wheels. It just doesn't get supplied with them, or need them.
If you want a right mouse button, go and buy any old USB mouse, plug it in, and the right button will instantly bring up context menus just as you expect; and the scroll wheel will scroll windows in most apps ditto.
I wish we could see some sensible arguments in the Mac-vs-PC debate. (For example, I fully agree that Mac OS Classic sucked. Or at least, it sucked for people who'd used something else first. From what I hear, most folk who started with a Mac loved it; but people like me who came from other platforms (mostly Atari and X Terminals in my case) hate it -- I fought against it continually for a year or so until Mac OS X came out and I heaved a long sigh of relief!)
Re: I Am Not Being Shifted, I Am Being Forced
on
The Long Tail
·
· Score: 2, Interesting
The music industry would probably respond to this "Well, if we make off-the-wall stuff, no-one comes to see it. We make movies that we think people will pay money to see."
And to some extent, that's a fair point. Of course, that's assuming that they promote the less formulaic stuff as hard, which I'm not sure they do. But the unusual films tend to get pigeonholed as 'art house' or whatever, and don't get as popular. Look at something fascinating and original like Being John Malkovich, or Cube, or even The Truman Show (though that did rather well I think), or... well, you can probably think of some more.
I guess it's a chicken and egg situation. As long as most people go and see formulaic dross, that's what they'll get. And they'll have trouble finding anything else. So that's what they'll get in the habit of seeing. Rinse and repeat.
My last comment was about the X-Prize, and I find myself saying exactly the same thing here: people need to take risks. The execs need to move out of their comfort-and-predictable-profits zone. Do you think Kubrick worried about approval ratings when he made 2001? Did Kurosawa get a committee to write The Seven Samurai? Did Tarantino base Reservoir Dogs on market research and focus groups? Of course not. They just tried to create something good; the success followed from that. The movie industry would be in a better state if they focused on the good rather than the comfortable.
But it's a risky business! As someone once said, you take a chance getting up in the morning, crossing the road, or sticking your face in a fan.
It's not as if the pilots don't know what they're letting themselves in for; and just like movie stuntmen or bomb disposal experts or soldiers, they choose to do it anyway. Who are we to stop them?
Of course we should aim for a reasonable degree of safety; and by the time we have commercial spaceflight, there may well need to be legislation, just as for other forms of transport. But not before.
This is a challenge. If it doesn't turn out a little bit risky, then you're not working hard enough. If we insist on perfect safety, we'll never go anywhere; humanity will have reached middle age, got 'comfortable', and given up all hopes of growing beyond this planet...
And even if you can't come up with a logical justification for one person voting that way, non-transitive preferences often crop up when trying to combine many people's preferences.
For example, suppose person 1 loves candidate A, doesn't mind B, and hates C. Person 2 loves B, doesn't mind C, and hates A. Person 3 loves C, doesn't mind A, and hates B.
Then the combined preference should prefer A to B, because two of the three people do. Similarly, it should prefer B to C, and C to A. So even though each person individually has a total ordering of their preferences, there's no way to (fairly) get one out of their combined preferences.
But then, there is no fair way to combine preferences... In effect, all voting methods are a compromise. We just have to choose the best compromise!
The original version is small, efficient, can be played on anything from a palmtop to a mainframe, on a variety of interpreters, and doesn't need a net connection. The new one needs a constant net connection, screen space, colour, Flash, JavaScript, and a fast machine; it adds lots of eye candy without actually adding anything to the basic game.
If that's 'bringing it up to date', then I fear for the current state of software...
Slashdot Mirror
So why do we need patents on software, if the very thing that patents were designed to protect is already protected?
Isn't this an argument against all software patents?
Not sure what you mean here -- I suspect you mean the gap between scripting languages and traditional ones.
If so, then I'd like to disagree :-) (And if not, please ignore the rest!)
While scripting languages have certainly closed the gap in terms of speed, and language features, there are more important considerations where they're still very far apart (and rightly so). I'm thinking particularly here of areas such as methodology, security, portability, and especially maintainability.
Take typing, for example. Dynamic typing is easier to write for: you don't have to restrict yourself to particular types, you don't have to decide things like that in advance, and you don't have to repeat information. But that freedom comes at a price: you don't know what types you'll have to deal with, so you can't guarantee you'll be able to handle them. It's much easier to make subtle bugs. And, what's worse: you can't spot any of this until runtime. You've traded ease of writing for difficulty of testing and fixing.
Similarly, the 'there's more than one way to do it' philosophy is often seen as a plus. How could choice be bad? The trouble is that that choice is the writer's choice -- but the writer isn't the only person to work with the code. Something like 80% of the time spent on code is in maintenance. And if there are 10 subtly different ways to do everything, then the maintainer is 10 times more likely to misunderstand what the code is doing, or to have trouble following the idiom. That's where the argument that 'the programmer doesn't need to understand the whole language' falls right down. And a language that allows the writer the freedom to write an incomprehensible mess isn't one that allows the maintainer much peace of mind!
I could go on about many other aspects too. The roll-your-own object model and we-trust-you data hiding are hardly suited to million-line systems. And so on, and so on.
Of course, I'm not saying that dynamic typing or supernumerary language features or whatever will necessarily lead to bad code. I'm sure some Perl code is a model of elegance, clarity, discipline, and correctness. But is all of it? Hardly... I'd far rather rely on a compiler than a developer to find bugs, any day. And I'd far rather rely on a language to encourage clarity than on the self-discipline of some developers I've worked with...
In short, while the facilities of what used to be known as scripting languages have improved tremendously, their philosophy is now what limits them -- that's what makes them unsuitable for huge, complex or critical systems.
Yep, spot on. Stands for mutual exclusion -- each process (or thread) excludes the others, so only one can be running the protected region of code at once. Used to be called a monitor, I think.
Languages like Java have this facility built-in (the synchronized keyword), though it's not really enough for complex systems. And I expect things get much more hairy in the kernel...
Why go to the trouble of linking a page which contradicts you?
If I've understood correctly, Ogg wraps FLAC, just as it wraps Vorbis and other streams. And just as FairPlay wraps AAC, and QuickTime wraps all sorts of stuff.
Sure, FLAC can be encapsulated in an Ogg stream, but it has its own lightweight native format that the command-line FLAC tools use, and which exists quite happily without Ogg.
Enormous cost? A simple sign up saying "People making a disturbance, using mobile phones or otherwise, will be asked to leave"? Enforcing it a few times? I think people would learn rather quickly...
Same problem. And it's still not a good solution.
My phone, for example, is set to vibrating alert, and a ringtone that starts silently, and only gets really loud if I haven't answered/rejected it after 10 seconds or so. In practice, I've usually felt, retrieved and answered/stopped it before anyone else has even heard it. I still turn it off for performances, anyway, but even if I forget, and (even less likely) it started ringing, chances are it wouldn't annoy anyone else. (And for something important, I'd treat it as a pager -- reject the call, see who it was, and then leave the room to return the call.)
I'm not suggesting that this is exactly what everyone should do, but it does show that even ringing phones need not be a disturbance.
People need to find their own ways to reconcile what they want to do with showing respect for other people; not have cumbersome, partial, troublesome 'solutions' forced on them.
How about another analogy:
I don't like being woken up in the small hours by noisy cars (I'm a light sleeper). Should I lobby to make it illegal to drive between midnight and 7am? Yes, it would harm the milk delivery business, but at least I'd get my sleep! And regulations on noise would never be obeyed, so a total ban is the only sensible solution...
I'm not suggesting that mobile access be a right. Just that there should be a more important reason for jamming it than just "It gives some people an excuse to make a nuisance of themselves."
Of course people shouldn't rely on their phones for anything absolutely vital. Coverage can be lost due to intervening architecture, weather, or heavy use by others. Batteries run out. Networks go down. And so on. You can't assume you'll be in coverage in restaurants, cinemas, or anywhere else.
But the 'Jam them' reaction makes me very uncomfortable. Have we become so intolerant of others that anything we don't personally like should be banned? Do we want to live in a society where we're only allowed to do things if everyone explicitly agrees?
Remember: you can't force people to be nice to each other. You can only encourage them by example, and where necessary punish gross infringements.
Jamming phones is a coward's way out. If people are making a nuisance of themselves, then ask them to stop it, or have them thrown out. After all, that's what would happen if people spoke loudly to their neighbours in a theatre; why should speaking loudly into a phone be any different? If a kid takes in a handheld game that makes loud beeping noises, then it should be removed or disabled; again, why it different if a phone makes loud noises? Just because something's technically possible doesn't make it a good solution.
Jamming treats people like children. It effectively says "Since some of you aren't using their phones responsibly, we'll stop anyone using one." And, like many other childish reactions, it doesn't teach people anything. If someone got bounced out from using their phone inconsiderately, then they'd learn something from that! But is it right to punish the majority because of a small minority of inconsiderate people?
As I said, it's exactly the same argument as for P2P. In fact, more so -- if you believe the figures, then the vast majority of P2P traffic is illegal, whereas it's only a minority of mobile users who behave obnoxiously. Most people argue that the former should be allowed for the small proportion of legitimate traffic; yet you're asking to jam phones where a much larger proportion of use is considerate!
I understand why you're sick of obnoxious bastards using their phones offensively, and I share your feelings. I just think that jamming is the wrong solution. Use your feelings in a constructive manner! Stand up and tell someone that they're disturbing everyone! If you want to say a big 'Screw you' to them, then do so -- to their faces, loudly and publicly! If necessary, threaten to stick the phone somewhere anatomically impossible! (Seriously. I expect you'll get cheers from most of those around you.)
Rudeness is the problem, so fight rudeness. Don't fight phones, otherwise the rest of us will suffer, and rude people will just find some other way to be obnoxious!
I am not able to rightly apprehend the kind of confusion of ideas that could provoke such an article!
BUT a jammer isn't the right answer to that! It prevents perfectly legitimate and polite uses of a phone (silent alerts; text and photo messages; genuine emergencies; leaving the room before answering) without actually stopping people from being rude and inconsiderate!
If they don't jam phones, and instead actually enforce a nuisance policy, then people will have to learn to use their phones responsibly (turning them off, or to 'silent running'). And everyone benefits.
This is exactly comparable to the current fuss about P2P software. Mobile phones have perfectly legitimate and non-infringing uses. (SMS messages, for example. Genuine life-or-death emergencies. Incoming calls where the user doesn't speak, or leaves the cinema before speaking.) Jamming prevents all those, whilst still allowing all the antisocial behaviour people have the rudeness to pull off!
A jammer is just a tool for management too cowardly to enforce a proper nuisance policy.
And of course, this is the thin end of the wedge. If jammers become accepted in cinemas, theatres and churches, they may well spread to restaurants, galleries, museums, shops, cafés, pubs, stations, workplaces...
What's worse is that in this case there is a possible technological measure that would do pretty much what people want. Instead of jamming the phones, how about a short-range transmitter which told the phones to go into 'silent mode', turning off the ringtone, and maybe the microphone, whilst still allowing vibrating alerts, text messages, and maybe incoming calls. It's a bit more technology than phones currently have, but it can't be too hard to implement.
I was thinking more of things that couldn't be tested with an assertion; higher-level stuff more to do with thought processes and algorithms than with variables and conditions.
And in your example, I agree that the longer function and parameter names are much more readable. But I think that a comment is often useful too. For example, the name alone doesn't make clear what happens if the employee doesn't exist; does it write an empty string? Write nothing? Display an error? And so on. What format is the name in? Is the function thread-safe? Does it rely on an existing database connection? There are always things to consider that won't fit in a simple name, however long.
As I said: make as much clear in the code as you can, and comment everything else!
Also, often function names don't seem to be as meaningful as the author thought. How many 'processFile' functions have been written, and how much does that name tell you?
Oh, and another type of comment I missed out:
And I'm not talking about voice notes, either, but CD-quality, stereo, uncompressed audio, from a mic or line input. The iPod chipset is supposed to support this already, so all it would need is a software update. Apparently...
I do concert recordings (with permission), and that would make things so much easier. [fx: sigh]
But I doubt they've been a total waste. For example, knowing their code is going to be reviewed soon makes some people write better code. And in explaining your design decisions, maybe your listener(s) learned something about design. (Or maybe you did!)
My own feeling is that code reviews can be a great way of sharing knowledge about the system, and about development generally, e.g. best practices; they can help to ensure that code doesn't just work but is maintainable; and they can often spot certain types of mistakes. But everyone needs to treat them as a useful and constructive time, otherwise it won't be...
This is a reason to write better comments, not to avoid them completely!
Of course comments that are flippin' obvious, or wrong, do no good to anyone. But some sorts of comments can be incredibly helpful:
- Big-picture comments. Explaining what this function, method, class, file, or interface is doing; how it fits into the app or system; important design decisions. Also authorship and date information, if that's important.
- API comments. Describing the implicit (or explicit!) contract that a function, method, class or whatever has with its caller. When you should be calling this code, what the caller needs to have set up beforehand, what the code guarantees to do in return, any gotchas.
- Section comments. Within long functions, just a few words every 10-30 lines, breaking it up into logical sections, can make it much easier to understand the flow, or find the particular section you're looking for.
- Here-be-dragons comments. Describing tricks, shortcuts and other hacks. Better to make the code clear and obvious, of course, but there are times when a clever technique or bit of magic is needed, and for those rare occasions, a few words of explanation can make things so much clearer -- and prevent someone ignorantly 'fixing' it later!
Of course, there's some overlap. But these are the sorts of things that can make code so much easier to read, and don't take much effort to maintain. The big-picture and API comments tend to be common practice in literate languages like Java (JavaDoc) and Perl (POD), but too many people don't follow it -- and even where those comments aren't extracted automatically, they can still be incredibly useful.My rule of thumb is: Try to make the code itself obvious. And comment everything else!
Just on the off-chance that you were being at all serious, you should know that methane itself doesn't stink -- it has no odour at all. That's why gas companies have to add in a separate chemical to make it smell. If you associate a smell with methane, it's probably the trace organic chemicals, especially the sulphur-containing ones, that are also produced when digesting food...
Maybe so*. But this isn't about controlling the content -- it's about controlling what you can do with that content!
(* Though shouldn't they be controlling the format of the communication, not the content?)
Ditto the mouse pad -- though I note that at least one other /.er finds the single-button-style pad more usable, not less.
If Mac apps hang (which I find pretty rare), then the Dock is perfect for switching to other apps, or killing the problem app. No keypresses needed.
If you don't like your Mac, then you're free to use something else, of course. The world is a big place, with room for more than one opinion.
Yes and no. Yes, you can't get cheap Macs, but for what you get, they seem to be fairly competitive with similarly-specced PCs. (I haven't done the analysis myself, but whenever I've seen it done, the Macs come out not much more expensive, and sometimes cheaper.)
Again, this depends on your criteria. The hardware is closed, but most of the components are standard off-the-shelf ones. And the core OS is open source -- I should know, I've made a couple of fixes myself (one is apparently in OS X 10.3).
This is a genuine concern. Give Apple a 95% market share, and who knows whether their current drive for compatibility, open standards, and quality would continue? OTOH, MS never had those in mind, even when it was tiny -- it's used predatory and unfair business practices from the word 'Go'.
However, the choice isn't just between one monopoly and another. The chances of OS X gaining 95% market share are tiny, and even a huge Mac purchase won't make that happen. What it will do is help to level the playing field a bit; once people are freer to choose a platform on merit rather than on MS's marketing and legal spend, then everyone benefits. I look for a day when many different platforms each have a reasonable market share.
You and millions of others... But it won't happen, for two reasons. First, economic: unlike MS, Apple is basically a hardware company; their software is often wonderful, but financed from hardware sales, and ultimately drives hardware purchases. To make economic sense, OS X on x86 would have to cost enough to make up for loss of hardware sales, as well as covering the development cost. Which would make it prohibitively expensive.
And second, technical. One of Apple's main selling points is that stuff Just Works(tm). And that's partly because they control the hardware. They know just what hardware they need to support and test against, and integrate the two quite strongly. (For example, look at how long Macs have been able to 'sleep' -- shutting down almost all the hardware, and yet able to wake within a second or two, with all software carrying on perfectly.) Supporting any old x86 hardware -- just like supporting any old PPC hardware -- would either take an unfeasibly large compatibility, testing and drive development department, or leave lots of OS X installations that were a bit flaky, not supporting some hardware and working badly with other. Or, more likely, both.
Why not start wishing for something more realistic? Why do we never hear Windows users saying "MS should port Windows to PPC"...?
Not that it'll make any difference, but just for the record: Mac OS X supports multiple mouse buttons and scroll wheels. It just doesn't get supplied with them, or need them.
If you want a right mouse button, go and buy any old USB mouse, plug it in, and the right button will instantly bring up context menus just as you expect; and the scroll wheel will scroll windows in most apps ditto.
I wish we could see some sensible arguments in the Mac-vs-PC debate. (For example, I fully agree that Mac OS Classic sucked. Or at least, it sucked for people who'd used something else first. From what I hear, most folk who started with a Mac loved it; but people like me who came from other platforms (mostly Atari and X Terminals in my case) hate it -- I fought against it continually for a year or so until Mac OS X came out and I heaved a long sigh of relief!)
And to some extent, that's a fair point. Of course, that's assuming that they promote the less formulaic stuff as hard, which I'm not sure they do. But the unusual films tend to get pigeonholed as 'art house' or whatever, and don't get as popular. Look at something fascinating and original like Being John Malkovich, or Cube, or even The Truman Show (though that did rather well I think), or... well, you can probably think of some more.
I guess it's a chicken and egg situation. As long as most people go and see formulaic dross, that's what they'll get. And they'll have trouble finding anything else. So that's what they'll get in the habit of seeing. Rinse and repeat.
My last comment was about the X-Prize, and I find myself saying exactly the same thing here: people need to take risks. The execs need to move out of their comfort-and-predictable-profits zone. Do you think Kubrick worried about approval ratings when he made 2001? Did Kurosawa get a committee to write The Seven Samurai? Did Tarantino base Reservoir Dogs on market research and focus groups? Of course not. They just tried to create something good; the success followed from that. The movie industry would be in a better state if they focused on the good rather than the comfortable.
It's not as if the pilots don't know what they're letting themselves in for; and just like movie stuntmen or bomb disposal experts or soldiers, they choose to do it anyway. Who are we to stop them?
Of course we should aim for a reasonable degree of safety; and by the time we have commercial spaceflight, there may well need to be legislation, just as for other forms of transport. But not before.
This is a challenge. If it doesn't turn out a little bit risky, then you're not working hard enough. If we insist on perfect safety, we'll never go anywhere; humanity will have reached middle age, got 'comfortable', and given up all hopes of growing beyond this planet...
And even if you can't come up with a logical justification for one person voting that way, non-transitive preferences often crop up when trying to combine many people's preferences.
For example, suppose person 1 loves candidate A, doesn't mind B, and hates C. Person 2 loves B, doesn't mind C, and hates A. Person 3 loves C, doesn't mind A, and hates B.
Then the combined preference should prefer A to B, because two of the three people do. Similarly, it should prefer B to C, and C to A. So even though each person individually has a total ordering of their preferences, there's no way to (fairly) get one out of their combined preferences.
But then, there is no fair way to combine preferences... In effect, all voting methods are a compromise. We just have to choose the best compromise!
I take your point. But here in the UK an awful lot of roads don't have more than one lane in each direction. Would you moderate your policy here?
The original version is small, efficient, can be played on anything from a palmtop to a mainframe, on a variety of interpreters, and doesn't need a net connection. The new one needs a constant net connection, screen space, colour, Flash, JavaScript, and a fast machine; it adds lots of eye candy without actually adding anything to the basic game.
If that's 'bringing it up to date', then I fear for the current state of software...
It's from The Restaurant At The End Of The Universe, by Douglas Noel Adams ('DNA').