Fuck all of your kind, and, please, die in a pressure-related explosion and watch me as I weep... but not for you. I weep for those of us who've slaved away our youth to fix the bug that is IE6!
Wow, and a go fuck yourself to you as well sir.
I hope some day you're forced to maintain the most miserable, old piece of software ever written and discover what it really means to be stuck with something like that.
Maybe you'll realize that it isn't always as simple you think. In the mean time, stop acting like such a punk.
Having one sitting on the seat or in a purse receiving texts and emails isn't a risk factor for causing an accident.
No, but picking up the damned thing to see what it says (and likely respond) are risk factors for an accident.
I have seen people nearly drive off the road because they're texting, and I regularly see someone who is trying to text at a red light who isn't paying attention when the light changes to green.
Hell, I once saw the guy in my rear-view mirror with both thumbs on his Blackberry and not looking at the road. If that's not completely "distracted" driving, I have no idea what is. I wanted to get out and slap him silly, because he wasn't paying attention and I don't feel like getting rear-ended by some tool who can't put down his phone long enough to drive to work.
Though, in fairness, the craziest thing I ever saw was a lady eating take-out Chinese with chopsticks while driving and juggling a coffee. The mind reels.
They've actually coded up some horrible hackjob that runs IE6 on Windows 7, rather than fix the horrible in-house app.
Clearly you've never been involved in trying to get rid of an app like that.
It's mission critical, covers a bunch of use-cases that nobody can remember but that are absolutely vital to like two people (but affect millions of dollars of business), and almost nobody who fully understands it is still around. It's impossible to gather requirements because the application has so many exceptions and one-off fixes and tweaks as to make it impossible to know what all it's supposed to do.
I've been on a couple of projects which tried to replace legacy, in-house apps... it's often a very expensive, time-consuming process that leaves you with a solution which does a fraction of what the original did and leaves the users miserable that they've been "upgraded" to a tool which doesn't do the job.
Sadly, once you have that kind of software, the process of getting rid of it is often damned near impossible. At the very least, it can be prohibitively expensive... who wants to spend $40 million to end up with software that does less than what you have now?
Nobody sees it as investing in moving away from old creaky technology, they see it as spending money on something they already have. Hell, I've seen someone go through a multi-year process, tens of millions of dollars, huge amounts of man-power... only to decide that the twenty-year old app that runs on the mainframe is still a better solution because it covers all of their use cases and the users are comfortable with it.
It gets even worse if you try to replace purpose-built with something that does 'most' of what you need. The users won't touch it because they think it's cumbersome, and missing features they can't live without.
Yes, it is short-sighted to not get rid of it, but the sheer cost and amount of pain in ripping it out can make the alternative seem more attractive.
Not that I'm saying MSU is in the wrong here. But the lack of general expertise in the area makes them susceptible to such fraudulant practices
I will be curious to see how this plays out... documenting everything to be able to say that Oracle lied to them about the capabilities of the software and then demanded more money... well, that might make them less susceptible to these fraudulent practices.
If Oracle really did lie to them and try to play a shell game whereby they expected the university to pay extra for functionality they were promised was already there... well, I'd like to see Oracle held to account for that one.
As I've said elsewhere in this thread, I once worked with one a project with some Oracle software which didn't do half of what they claimed it did. I certainly believe the university was sold a bill of goods, only to have Oracle turn around and say "well, it doesn't really do that, this part is an add on you have to buy, and we really have no idea how to do this part, but if you wait for the next revision we're sure we can figure it out".
Sadly, I've seen software sold with half truths and bald-faced lies before. Why it hasn't led more of them into court, I will never understand.
I'm not saying Oracle is in the right here, but I believe the article said they initially made a spec with 3200 items, which apparently became a moving target.
True that the article said they made a spec with 3200 items, but the article doesn't say that spec became a moving target. MSU wasn't changing their requirements (at least, TFA doesn't say that).
It seems to suggest that the demo Oracle presented which showed that it could meet "95 percent of MSU's business requirements" out of the box:
Before it won the bid, Oracle also conducted live demonstrations of its software that used test scripts prepared by the university. One demonstration involved "a robust on-line application process for Undergraduate and Graduate Admissions... that it falsely represented was an existing part of the base system and satisfied the University's requirements," the complaint states.
But in fact, "Oracle's ultimate implementation plan was to sell the University a third-party product called 'Embark' to satisfy those requirements, suggesting the initial 'live' demonstration was rigged," it adds. A "substantial" amount of customization was needed in the end, according to the complaint.
I've seen demos in which the vendor is claiming that the software already does the things you need it to, only to find out that what we actually got shown was an add-on component we'd have to buy, as well as a large amount of customization we'd be expected to pay for. In other words, the demo was pure bullshit, and we called them on it. It also means that the estimate they provided didn't actually include the functionality you said was mandatory... you get some fraction of that, and they expect you to pay for what they didn't provide you. They just don't tell you until after the fact that they didn't sell you what they told you they were going to.
It's like being shown a car, only to find out that it doesn't really come with an engine, the transmission hasn't been done yet, and if you try to use the wipers something will catch fire.
Not saying Oracle did all of this here... but it's far from unprecedented for the demo you get shown that 'proves' you meet all of the criteria has a bunch of huge gaps in it the vendor has no idea of how to address. At that point, it's hard not to see it as a little fraudulent.
Isn't this standard for their Peoplesoft product? We went through hell with it where I work years ago. Cost around 20 million more than it should have.
I worked on a project several years ago involving some collaborative software from Oracle.
The software was not mature enough to be out of beta, definitely not mature enough to be sold to customers, and in the end required vast amounts of resources over and above what we were told it would.
In effect, they were selling snake oil, and they knew it. And, they wanted more money to deliver.
Not saying this is in any way similar to what is happening at this university, but I know first hand Oracle isn't above selling you a product they haven't finished writing yet. In fact, I think it's part of their business model.
My mom has an iPhone. They sell iPhones for Dummies books. Those two criteria right there are reason enough to never buy an iPhone.
What, because it works, is easy to use, and you can get documentation for it that an actual consumer can understand?
So any technology your mom can use is bad? I take it you have eschewed all forms of technology she can operate like TVs, plumbing, and toasters? Or is it just phones?
Oh, you can also get Linux for Dummies, Windows for Dummies, and a whole raft of things... so if the presence of a Dummies book is your criteria, you should stop using anything listed here... they even have your beloved SQL.
Seriously man, I consider any technology my mother can operate to be fairly well implemented; because she's in her 70's and for her to decide she needed a GPS, laptop, scanner, digital camera, digital picture frame, a USB drive for backups, and a PVR... well, that was quite a series of leaps for someone who isn't all that interested in that kind of stuff.
Why should technology be something that your mother couldn't possibly use?
Shrink wrap legal agreements aren't enforceable and it's a shocker that the judge didn't know that.
I'm pretty sure that case precedent actually suggests they maybeenforceable.
They can't make up crazy things that you can't legally sign away via contract (ie slavery or your first born), but they are widely deemed to be a valid contract.
I'm not sure there's been any ruling which categorically says they aren't enforceable... possibly in some countries, but generally I think they're more valid than you think.
What's wrong with wanting to work in a war zone? The pay is usually better, and some people like the daily excitement.
Yeah, a friend just got back from spending most of the last two years in Afghanistan.
Apparently the rocket attacks and periodic deaths on the base were really exciting.
He said pretty much after someone got killed 75 feet from where he was standing, if he heard the warning sirens he'd hit the deck even if he was in the latrine -- he figured crap washed off, but dead didn't. One of his co-workers rattled off the number of rocket attacks, suicide bombers, and other nasties that happened while he was there -- it didn't sound like a recruiting pitch to me.
He did get well paid, but I think he's pretty glad it's over now. They call it 'danger pay' for a reason.
I read it early on in my career and it left quite an impression, the concept of egoless programming being one of the more lasting ones.
Indeed, and not even just for coding. On a recent project where I was sort of the de-facto technical lead, that was pretty much how I approached all problems.. throw it open, discuss the relative merits, try to decide what works best, and then go with it.
If everyone has a say, you weigh the technical merits and inputs from everyone, and then decide on a best course of action... everyone feels included, nobody feels like they're being told "because I told you so", and everybody has buy in to the end decision.
The people who were in charge were consistently impressed at how we did such things, and very pleased with the end results. It's more about learning to play well with other children and arrive at the best available solution as it is about being right.
We managed to deliver a huge software rollout in a very large and complex environment, and the general consensus from management was that we'd managed to do it without any infighting and bruised egos -- and a very good focus on the end goal. My own manager was completely delighted with how we did it and seemed to think that, in part, I had been a key factor in that. I'd like to think that was because I tried to approach it from an egoless angle -- it wasn't about me, it was about what we we trying to do.
The trick to herding cats is to try to convince them all that over here has something really cool and we should all go there. Once that happens, it makes a lot of other things go smoothly. And, in my experience, generally yields better results.
You make a good point about how something which seems obvious and clear now is not several months down the line. I think everyone needs to have the experience of reading code they wrote a year or more ago (and adding features or fixing bugs).
I worked at a company once with a really smart guy, but who tended a little more to the theoretical than the applied.
During an enhancement cycle, he needed to go into one of his components and extend it. Not only couldn't he decipher his own code to figure out where to begin, when he (finally) got there he had designed it so cleverly as to preclude making any changes to it that hadn't been in the original design because he hadn't made any room for it.
He wrestled with it for days and had to refactor a bunch of stuff, and was then grumbling that his 'elegant' design was being hacked up to make the modifications. If it was so elegant, it wouldn't be that tough to modify it.
Far too often I've seen people write code that not even they can maintain, and then they whine and complain when you tell them in a code review that their code isn't written in such a way as to be even close to maintainable by someone else and isn't acceptable.
I will forever be grateful to one of my CS profs who was doing code/architecture reviews with me as far back as 1990 or so... because I learned what he called at the time "Egoless Programming". Which meant we tore it apart with the goal of making better overall code and not just focusing on doing it how someone thought best because they said so. I frequently learned nuance and modularity in design, and occasionally suggested something that made my prof go "OK, that's a better solution, do that".
The end result was better code overall, and some lessons that have carried forward to this day in how I work with people. Man, I need to buy that man a beer next time I'm in town.:-P
I SWEAR I'm not making this up: a manager once criticized my code as being too terse
And, as a developer who has done code reviews for a long time... I've had to tell other developers the exact same thing. Because it was too fscking terse.
In our shop, you needed a comment before your function describing what it was for, magic numbers were strictly verboten, and we expected function/variable names to actually have some descriptive value so we can tell what they're for, and anything non-obvious needed a comment.
We'd still get functions with three-letter names which were meaningless, variables like "b1" and "b2" which conveyed no information whatsoever, and generally crap code. Those guys didn't last long because they couldn't understand why their code was unusable in a production codebase.
"people have to read and understand it before they can modify it". He saw no irony in that statement.
Maybe because there was no irony? I've seen a bunch of young coders who claim that their code is so elegant and obvious as to be easily maintained. I've also shoved the same code back in their face after 3 months and said "fix this", which got me a "what's it do"?
If you think there should have been irony in his statement, maybe your code isn't very good.
Always assume that someone half as clever as you think you are is going to be fixing that code with great time pressures and in the middle of a bad day... because quite likely, even if it's your own code and you fixing it, that will be true. People who act otherwise are likely a liability in the long run.
I have seen far too many coders who thought they wrote clever code, but after six months couldn't follow their own logic in order to be able to debug it. If the original author can't debug it, WTF is anybody else going to do with it besides rewrite it? (Something I've had to do before.)
Every manager knows that quality needs time & resources.
I'm not sure they all do know that... some of them are completely ignorant of 'quality' as a concept so don't see why we spend time testing... some feel that it comes from small budgets, short timelines, and a lot of howling about why it's not ready yet... some think they can just demand a flying car today and have it by Wednesday.
I once said to a PM that 9 women couldn't have a baby in a month, and he didn't understand what I was telling him. You'd be surprised at the number of people who don't really understand what it takes to deliver robust, functional, maintainable software -- even though ostensibly that is their job.
At a previous company, we wouldn't ever demo anything we were playing with in the lab, because it would get immediately sold/included in the spec even though we were telling them this was only in the preliminary stages and definitely not ready for product.
It makes me even more grateful for the managers/PMs I've encountered who do understand these things, because they're actually in the minority.
You keep using those words. I do not think they mean what you think they mean.
So do you.
Look, the reality is when Oxford says "However , over the last 100 years or so another, more general use has arisen: "invite an obvious question"... This is by far the commonest use today and is the usual one in modern standard English."... your definition from formal logic is nice and all, but no longer definitive.
English is a hodge-podge of a bunch of different languages, filled with idioms, and changes over time. Just because they have some of the same words, doesn't mean they're not two completely different expressions.
Unless, of course, you consider yourself more authoritative than Oxford. At which point, you're most likely wrong.
Do we really need to improve on something that works already?
This would work, but better. No, I'm not being flippant.
If you have structured data (say XML), you could target hierarchies like config-root:server-name:name. That way if the text inside "name" is only being looked for in that one field, you won't hit a bunch of other stuff that also happen to be similar strings but are unrelated.
I'm sure you'd still have your regular grep/diff utilities, but there's definitely places where being able to match these strings in-context would be of value.
Of course, someone is going to need to write a corresponding context-free sed (and maybe awk as well) to go along with the grep. But there's actually a lot of places where this would be a huge improvement in terms of certain kinds of automation.
Use of a context-free grammar also lets this be insensitive to whitespace and newlines, so it would work on "prettified" HTML or stuff that's all formatted haphazardly. This is basically how those things are parsed now... the grammar rules define the structure, and don't need it to be all perfectly laid out in order to be able to handle it.
As soon as I see "Context-Free Grep", I immediately think of a Context Free Grammar.
That basically implies we can have much more sophisticated rules that match other structural elements the way a language compiler does. Which means that in theory you could do grep's that take into account structures a little more complex than just a flat file.
Grep and diff that can be made aware of the larger structure of documents potentially has a lot of uses. Anybody who has had to maintain structured config files across multiple environments has likely wished for this before.
I'd like to see a politician sue someone for robocalling them, see if that works out in their favor.
They wrote the laws, gave themselves an exemption, and have better access to law enforcement and legal advice than you or I.
You're more than welcome to test your theory and see how it turns out.
I'm just pointing out that they've stacked the deck in their favor, and that if you or I did the same thing they'd probably find some other laws they can abuse to make us go away.
Me, I'd expect you'd get a visit from the local police or from a Federal Agency. Neither is likely to turn out like you might hope.
I can't speak for the US, but in Canada Robo-calls are already illegal
Yeah, like that's working.
I've gotten to the point where if I don't immediately know the number (or if you can't show me in the first 15 seconds that you are someone I do business with) then I just have to assume the caller is fraudulent and tell them to fsck themselves.
I get so many &^%#^%*( robo-calls in a week the fact that it's ostensibly illegal is almost laughable. There's no teeth to the enforcement, and the people calling from the US or internationally do it with impunity.
I mean, come on, do you really think I believe you work for "the windows service provider" or that my machine seems to be causing alerts when you're calling me from a (probably fake) number in Texas?
The politicians who wrote the laws about such things game themselves an exemption to call you. It is entirely possible that if you turn around it do it to them, you could be doing something illegal.
Remember, the deck is stacked, and not in your favor.
Slashdot Mirror
Wow, and a go fuck yourself to you as well sir.
I hope some day you're forced to maintain the most miserable, old piece of software ever written and discover what it really means to be stuck with something like that.
Maybe you'll realize that it isn't always as simple you think. In the mean time, stop acting like such a punk.
No, but picking up the damned thing to see what it says (and likely respond) are risk factors for an accident.
I have seen people nearly drive off the road because they're texting, and I regularly see someone who is trying to text at a red light who isn't paying attention when the light changes to green.
Hell, I once saw the guy in my rear-view mirror with both thumbs on his Blackberry and not looking at the road. If that's not completely "distracted" driving, I have no idea what is. I wanted to get out and slap him silly, because he wasn't paying attention and I don't feel like getting rear-ended by some tool who can't put down his phone long enough to drive to work.
Though, in fairness, the craziest thing I ever saw was a lady eating take-out Chinese with chopsticks while driving and juggling a coffee. The mind reels.
Clearly you've never been involved in trying to get rid of an app like that.
It's mission critical, covers a bunch of use-cases that nobody can remember but that are absolutely vital to like two people (but affect millions of dollars of business), and almost nobody who fully understands it is still around. It's impossible to gather requirements because the application has so many exceptions and one-off fixes and tweaks as to make it impossible to know what all it's supposed to do.
I've been on a couple of projects which tried to replace legacy, in-house apps ... it's often a very expensive, time-consuming process that leaves you with a solution which does a fraction of what the original did and leaves the users miserable that they've been "upgraded" to a tool which doesn't do the job.
Sadly, once you have that kind of software, the process of getting rid of it is often damned near impossible. At the very least, it can be prohibitively expensive ... who wants to spend $40 million to end up with software that does less than what you have now?
Nobody sees it as investing in moving away from old creaky technology, they see it as spending money on something they already have. Hell, I've seen someone go through a multi-year process, tens of millions of dollars, huge amounts of man-power ... only to decide that the twenty-year old app that runs on the mainframe is still a better solution because it covers all of their use cases and the users are comfortable with it.
It gets even worse if you try to replace purpose-built with something that does 'most' of what you need. The users won't touch it because they think it's cumbersome, and missing features they can't live without.
Yes, it is short-sighted to not get rid of it, but the sheer cost and amount of pain in ripping it out can make the alternative seem more attractive.
I will be curious to see how this plays out ... documenting everything to be able to say that Oracle lied to them about the capabilities of the software and then demanded more money ... well, that might make them less susceptible to these fraudulent practices.
If Oracle really did lie to them and try to play a shell game whereby they expected the university to pay extra for functionality they were promised was already there ... well, I'd like to see Oracle held to account for that one.
As I've said elsewhere in this thread, I once worked with one a project with some Oracle software which didn't do half of what they claimed it did. I certainly believe the university was sold a bill of goods, only to have Oracle turn around and say "well, it doesn't really do that, this part is an add on you have to buy, and we really have no idea how to do this part, but if you wait for the next revision we're sure we can figure it out".
Sadly, I've seen software sold with half truths and bald-faced lies before. Why it hasn't led more of them into court, I will never understand.
True that the article said they made a spec with 3200 items, but the article doesn't say that spec became a moving target. MSU wasn't changing their requirements (at least, TFA doesn't say that).
It seems to suggest that the demo Oracle presented which showed that it could meet "95 percent of MSU's business requirements" out of the box:
I've seen demos in which the vendor is claiming that the software already does the things you need it to, only to find out that what we actually got shown was an add-on component we'd have to buy, as well as a large amount of customization we'd be expected to pay for. In other words, the demo was pure bullshit, and we called them on it. It also means that the estimate they provided didn't actually include the functionality you said was mandatory ... you get some fraction of that, and they expect you to pay for what they didn't provide you. They just don't tell you until after the fact that they didn't sell you what they told you they were going to.
It's like being shown a car, only to find out that it doesn't really come with an engine, the transmission hasn't been done yet, and if you try to use the wipers something will catch fire.
Not saying Oracle did all of this here ... but it's far from unprecedented for the demo you get shown that 'proves' you meet all of the criteria has a bunch of huge gaps in it the vendor has no idea of how to address. At that point, it's hard not to see it as a little fraudulent.
I worked on a project several years ago involving some collaborative software from Oracle.
The software was not mature enough to be out of beta, definitely not mature enough to be sold to customers, and in the end required vast amounts of resources over and above what we were told it would.
In effect, they were selling snake oil, and they knew it. And, they wanted more money to deliver.
Not saying this is in any way similar to what is happening at this university, but I know first hand Oracle isn't above selling you a product they haven't finished writing yet. In fact, I think it's part of their business model.
See, we didn't need to know that ... it's like being a Twitter Shitter; some things are best kept to yourself. :-P
What, because it works, is easy to use, and you can get documentation for it that an actual consumer can understand?
So any technology your mom can use is bad? I take it you have eschewed all forms of technology she can operate like TVs, plumbing, and toasters? Or is it just phones?
Oh, you can also get Linux for Dummies, Windows for Dummies, and a whole raft of things ... so if the presence of a Dummies book is your criteria, you should stop using anything listed here ... they even have your beloved SQL.
Seriously man, I consider any technology my mother can operate to be fairly well implemented; because she's in her 70's and for her to decide she needed a GPS, laptop, scanner, digital camera, digital picture frame, a USB drive for backups, and a PVR ... well, that was quite a series of leaps for someone who isn't all that interested in that kind of stuff.
Why should technology be something that your mother couldn't possibly use?
I'm pretty sure that case precedent actually suggests they may be enforceable.
They can't make up crazy things that you can't legally sign away via contract (ie slavery or your first born), but they are widely deemed to be a valid contract.
I'm not sure there's been any ruling which categorically says they aren't enforceable ... possibly in some countries, but generally I think they're more valid than you think.
Well, according to the Iranians, it's more like putting a camera in your neighbors tree and them finding it and keeping it.
Given that the US has sent drones into Pakistan without telling them, it wouldn't entirely surprise me if this actually was sent into Iran's airspace.
Then again, given how bat-shit crazy Iran seems to act, I'm not sure I put a whole lot of stock in their version either.
Except, outside of the internet, that word doesn't always mean what you describe.
In this case, 'troll' is a perfectly legitimate usage of the word.
Yeah, a friend just got back from spending most of the last two years in Afghanistan.
Apparently the rocket attacks and periodic deaths on the base were really exciting.
He said pretty much after someone got killed 75 feet from where he was standing, if he heard the warning sirens he'd hit the deck even if he was in the latrine -- he figured crap washed off, but dead didn't. One of his co-workers rattled off the number of rocket attacks, suicide bombers, and other nasties that happened while he was there -- it didn't sound like a recruiting pitch to me.
He did get well paid, but I think he's pretty glad it's over now. They call it 'danger pay' for a reason.
Didn't HP recently say they planned on using it in printers?
Maybe (though, admittedly, unlikely) HP is realizing they can use it for commercial products and have it open-sourced.
Of course, I seem to recall HP paying several billion dollars for Palm, so that's gotta leave a mark.
Indeed, and not even just for coding. On a recent project where I was sort of the de-facto technical lead, that was pretty much how I approached all problems .. throw it open, discuss the relative merits, try to decide what works best, and then go with it.
If everyone has a say, you weigh the technical merits and inputs from everyone, and then decide on a best course of action ... everyone feels included, nobody feels like they're being told "because I told you so", and everybody has buy in to the end decision.
The people who were in charge were consistently impressed at how we did such things, and very pleased with the end results. It's more about learning to play well with other children and arrive at the best available solution as it is about being right.
We managed to deliver a huge software rollout in a very large and complex environment, and the general consensus from management was that we'd managed to do it without any infighting and bruised egos -- and a very good focus on the end goal. My own manager was completely delighted with how we did it and seemed to think that, in part, I had been a key factor in that. I'd like to think that was because I tried to approach it from an egoless angle -- it wasn't about me, it was about what we we trying to do.
The trick to herding cats is to try to convince them all that over here has something really cool and we should all go there. Once that happens, it makes a lot of other things go smoothly. And, in my experience, generally yields better results.
I worked at a company once with a really smart guy, but who tended a little more to the theoretical than the applied.
During an enhancement cycle, he needed to go into one of his components and extend it. Not only couldn't he decipher his own code to figure out where to begin, when he (finally) got there he had designed it so cleverly as to preclude making any changes to it that hadn't been in the original design because he hadn't made any room for it.
He wrestled with it for days and had to refactor a bunch of stuff, and was then grumbling that his 'elegant' design was being hacked up to make the modifications. If it was so elegant, it wouldn't be that tough to modify it.
Far too often I've seen people write code that not even they can maintain, and then they whine and complain when you tell them in a code review that their code isn't written in such a way as to be even close to maintainable by someone else and isn't acceptable.
I will forever be grateful to one of my CS profs who was doing code/architecture reviews with me as far back as 1990 or so ... because I learned what he called at the time "Egoless Programming". Which meant we tore it apart with the goal of making better overall code and not just focusing on doing it how someone thought best because they said so. I frequently learned nuance and modularity in design, and occasionally suggested something that made my prof go "OK, that's a better solution, do that".
The end result was better code overall, and some lessons that have carried forward to this day in how I work with people. Man, I need to buy that man a beer next time I'm in town. :-P
And, as a developer who has done code reviews for a long time ... I've had to tell other developers the exact same thing. Because it was too fscking terse.
In our shop, you needed a comment before your function describing what it was for, magic numbers were strictly verboten, and we expected function/variable names to actually have some descriptive value so we can tell what they're for, and anything non-obvious needed a comment.
We'd still get functions with three-letter names which were meaningless, variables like "b1" and "b2" which conveyed no information whatsoever, and generally crap code. Those guys didn't last long because they couldn't understand why their code was unusable in a production codebase.
Maybe because there was no irony? I've seen a bunch of young coders who claim that their code is so elegant and obvious as to be easily maintained. I've also shoved the same code back in their face after 3 months and said "fix this", which got me a "what's it do"?
If you think there should have been irony in his statement, maybe your code isn't very good.
Always assume that someone half as clever as you think you are is going to be fixing that code with great time pressures and in the middle of a bad day ... because quite likely, even if it's your own code and you fixing it, that will be true. People who act otherwise are likely a liability in the long run.
I have seen far too many coders who thought they wrote clever code, but after six months couldn't follow their own logic in order to be able to debug it. If the original author can't debug it, WTF is anybody else going to do with it besides rewrite it? (Something I've had to do before.)
I'm not sure they all do know that ... some of them are completely ignorant of 'quality' as a concept so don't see why we spend time testing ... some feel that it comes from small budgets, short timelines, and a lot of howling about why it's not ready yet ... some think they can just demand a flying car today and have it by Wednesday.
I once said to a PM that 9 women couldn't have a baby in a month, and he didn't understand what I was telling him. You'd be surprised at the number of people who don't really understand what it takes to deliver robust, functional, maintainable software -- even though ostensibly that is their job.
At a previous company, we wouldn't ever demo anything we were playing with in the lab, because it would get immediately sold/included in the spec even though we were telling them this was only in the preliminary stages and definitely not ready for product.
It makes me even more grateful for the managers/PMs I've encountered who do understand these things, because they're actually in the minority.
So do you.
Look, the reality is when Oxford says "However , over the last 100 years or so another, more general use has arisen: "invite an obvious question" ... This is by far the commonest use today and is the usual one in modern standard English." ... your definition from formal logic is nice and all, but no longer definitive.
English is a hodge-podge of a bunch of different languages, filled with idioms, and changes over time. Just because they have some of the same words, doesn't mean they're not two completely different expressions.
Unless, of course, you consider yourself more authoritative than Oxford. At which point, you're most likely wrong.
Seriously, get over it.
And they of course got it from the Mesopotamians ... along with half a dozen other things in the bible.
Everyone just keeps recycling the same stories, keeps pretending it's something new to them.
This would work, but better. No, I'm not being flippant.
If you have structured data (say XML), you could target hierarchies like config-root:server-name:name. That way if the text inside "name" is only being looked for in that one field, you won't hit a bunch of other stuff that also happen to be similar strings but are unrelated.
I'm sure you'd still have your regular grep/diff utilities, but there's definitely places where being able to match these strings in-context would be of value.
Of course, someone is going to need to write a corresponding context-free sed (and maybe awk as well) to go along with the grep. But there's actually a lot of places where this would be a huge improvement in terms of certain kinds of automation.
Use of a context-free grammar also lets this be insensitive to whitespace and newlines, so it would work on "prettified" HTML or stuff that's all formatted haphazardly. This is basically how those things are parsed now ... the grammar rules define the structure, and don't need it to be all perfectly laid out in order to be able to handle it.
As soon as I see "Context-Free Grep", I immediately think of a Context Free Grammar.
That basically implies we can have much more sophisticated rules that match other structural elements the way a language compiler does. Which means that in theory you could do grep's that take into account structures a little more complex than just a flat file.
Grep and diff that can be made aware of the larger structure of documents potentially has a lot of uses. Anybody who has had to maintain structured config files across multiple environments has likely wished for this before.
Sounds really cool.
Looks like checking the box to say I don't want to see stories from samzenpus doesn't actually do anything.
Pity that. I checked it for a reason.
They wrote the laws, gave themselves an exemption, and have better access to law enforcement and legal advice than you or I.
You're more than welcome to test your theory and see how it turns out.
I'm just pointing out that they've stacked the deck in their favor, and that if you or I did the same thing they'd probably find some other laws they can abuse to make us go away.
Me, I'd expect you'd get a visit from the local police or from a Federal Agency. Neither is likely to turn out like you might hope.
Yeah, like that's working.
I've gotten to the point where if I don't immediately know the number (or if you can't show me in the first 15 seconds that you are someone I do business with) then I just have to assume the caller is fraudulent and tell them to fsck themselves.
I get so many &^%#^%*( robo-calls in a week the fact that it's ostensibly illegal is almost laughable. There's no teeth to the enforcement, and the people calling from the US or internationally do it with impunity.
I mean, come on, do you really think I believe you work for "the windows service provider" or that my machine seems to be causing alerts when you're calling me from a (probably fake) number in Texas?
Or, it might get you into trouble.
The politicians who wrote the laws about such things game themselves an exemption to call you. It is entirely possible that if you turn around it do it to them, you could be doing something illegal.
Remember, the deck is stacked, and not in your favor.