Hmm. I used to be bilingual in Fortran. I spent a lot of time trying to figure out someone elses code. Most of the time the problem is with the programmer not the compiler.
I have seen C and VB and even Pascal that is tough to understand.
I have also seen Fortran that was well documented and easy to follow.
It's definitely true that it is quite possible to write well-commented and easy-to-understand code using Fortran.
The vast majority of Fortran I've seen, however, does not fall into this category. Some old-school optimization tricks, like variable reuse, are partly to blame for the poor readability, as is poor programming ( usually done by engineers, not programmers ). In my experience, most folks writing Fortran programs are scientists and engineers, not programmers, and they approach the problem as if they're writing some little function that will only ever be written once, and never modified. They get it to compile and move on to some "real work". If there's some edge case where the program errors out, users learn by trial and error to avoid that case. User interaction is an afterthought. This is mostly the programmer's fault, although I notice you didn't touch my statement about Fortran I/O routines being uh, not the easiest to use.
Still, ANY language with a "GOTO" construct and unclear if-branching is going to be hard to read. Fortran has both. Not to mention limited symbol length and non-sequential line numbering. It actually takes a great deal of care to create a readable Fortran program, and they are, as a result, rare.
Not to start a flamewar about Fortran, though, it definitely has it's uses, and it is possible to write a reasonably readable Fortran program, but... the language not only doesn't help you do so, it actually includes some limitations and conventions which make it difficult.
But support on OS X? Shoot, Fortran support on OS X rocks! It's frickin' Fortran-lover heaven. You even get Altivec calls from Fortran. All you lack is a decent way to do I/O;-)
Seriously... although it may well be plausable that a good number of places which once would have installed a free Linux will now instead install a free Solaris x86, everyone knows good and well that even that scenario wouldn't "kill" Linux.
Depending on how "open" Solaris code turns out to be, it's success may indeed make all of Open Source stronger, prompting more companies to follow suit, releasing their core products under some sort of Open Source license and placing more engineers on open-source-based projects.
In any event, it's going to take a lot more than a free and open Solaris to "kill" Linux. Seriously, show me the Solaris fanatics... I haven't seen them. The Linux fanatics, on the other hand, are everywhere... and as long as they are alive, Linux will be alive as well. Which is a good thing.
$45K/yr take-home, $23K/yr rent. You do the math. Not homeless at all. $22K/yr to live on. Sucky, but not homeless.
You can support a family of 3 ( after rent ) on $22k a year!?! Wow, I'm impressed!! Do you send your kid to school? Do you dress him when you do?!?
Actually, I used my "so I can save to buy a house" income level in my original post, you could _get by_ on $80-90k on the peninsula, but... shouldn't a professional also be able to save and ( eventually, maybe out-of-area ) buy real estate? Or is that just a sad, old dream now??
But with if you want to work in a language other than Objective-C,C, C++ or Java?
(1) No problem. XCode's build system is extremely flexible. You can have a custom script or binary run instead of the more standard targets. Just make a new project of "Empty Project" type, add a build target ( Project/New Target ) and pick either "external target" or "Shell Script Target" as appropriate. It'd be hard for it to be a lot easier without being language/tool specific, like the 'canned' target types ( of which there are already quite a few ).
(2)You want to use something that's not the most developer-friendly language ever created ( Objective-C ), the most commonly used language ever created ( C ), the most commonly used in commercial products OO language ( C++ ) nor the best mulitplatform language ever ( Java ) ?? What's your reasoning there?
I understand that there are reasons for using "none of the above" when writing code for OS X, like say, you have a big group of Fortran programs that you don't have time or need to rewrite, or you just rock at Python and don't have time to learn something else, or know you can do what you want in Pearl... but if you're developing a completely new codebase, with a full GUI-based app as your goal? Learn Objective-C. Learn Cocoa. You'll be glad you did.
First, let me just say "yuck!", because I've had few less enjoyable experiences than trying to figure out what is wrong with someone's fortran code. Fortran IO functions must die. Just a personal preference, I understand plenty of people like Fortran for whatever reason, and it will always be used to write little, fast, hard to maintain programs with bad I/O routines.
Second, we've successfully recompiled scads of old ( and not-so-old ) fortran code for OS X already. I guess the programs we had didn't need to much in terms of special support- we used g77. It's good to hear GCC is ( of course ) keeping up with the times.
A quick google search and a peak at the ADC website and it does look like GCC and the Macintosh are being used by the HPCfolks. Altivec libraries available and everything, pretty much like you'd hope for, if FORTRAN is your bag.
If Silicon Valley companies are having a hard time getting employees, it's because people can't afford to move there in order to take their jobs.
Seriously. I used to live on the peninsula. I would like to live there again. But without a job paying *at least* $120k, I wouldn't even be able to rent a place for my family of 3, much less own a house.
While I don't want to defend bloat across- the-board, what's the real issue? I'm sure you're not worried that business logic will be filling up your hard drive, right?
What does CPU have to do with big binaries, besides an increase in paging, which is arguably a memory thing, even if you're talking about CPU cache...
I'm fairly certain I heard about this over a month ago, granted, it was from a completely fanatical Evil Dead fan.
Man, you've got too many big projects going on when you can't even be bothered to direct your own re-make. The time is right to do it, someone in Hollywood smelled the money of yet another special-effects humor zombie blockbuster, Jackson said what the heck, I'll take that paycheck, but I'm a little busy, how about my buddy directs?
Hey, what do you guys want from Raimi?
Would you ask Peter Jackson to make all of his movies look like Bad Taste and Meet the Feebles? Actually, *I* wouldn't complain, but all the same... cut the guy some slack, he's making cash. If you like the original better than the remake... hey, unlike Lucas' flicks, you can at least still *get* the original!!
Well, so far, this whole Apple flash player thing is a rumor. It's a strong rumor, and not inconcievable, but don't be shocked if it _doesn't_ happen, that's all I'm saying.
Then again, there _do_ exist people who don't listen to music all that much, they just want 20 or 30 songs they can listen to at the gym and don't get that having your entire music collection in your pocke is heaven. Maybe it's just cheap enough for Apple to rev some flash players that they figure why not, it's not really going to cut from their iPod sales, just cut into other folks' sales.
But price is a big problem, if they're talking 1GB. I'm guessing they're talking about less. Actually, the whole price thing is what makes me think this rumor is just that, and nothing more. If you're spending over a hundred bucks on a flash player, what's stopping you from taking out a small loan or whatever it takes to get another $149 and pick up an iPod mini?
The only way Apple's going to make a $200 flash-based player is if it's frickin' unbelieveably small, stylish and has a super-long battery life. I guess it could happen, but I remain fairly skeptical. I guess they could always introduce a flash-based model only to eventually pull it, introducing new slightly cheaper iPod minis to replace it at some point.
Simply put, it's not difficult to get a pretty accurate (again, within 2-4 hours) time frame of when the person died.
Please cite a source, even if it's "my friend took a class" like my source. Unless the body is still frickin' _warm_, what you've said just isn't true. You've basically made my point that this type of fiction is bad, because you clearly believe something that just isn't so.
It was once thought ( by forensics pros ) that you could estimate TOD by measuring fluid in the eye, but that's been debunked ( relatively recently ). Experiments at the body farm have proved how varied the rate of insect infestation, decomposition, and other means of estimating TOD can really be. Time ranges on estimates have increased as more research has been done in this field.
In other words, you know someone who is nothing more than a student on forensic, he gave you a second-hand account of what an expert said, and now you're giving us a third hand account of what the expert said.
Right. That's my reference. Where's your expert? If you have a current authoritative source that tells you the temperature of the liver or the vicosity of the eyeball or somesuch can lead to an exact time of death, please reference it. Otherwise, my statement ( unless you're going to assume I or my fiend are lying, which I'd take issue with ) of fact is quite nearly as good as if it came from the expert themselves, isn't it?
Would it make you feel better if I'd read about it in a book?!??
I don't recall police indiscriminantly shooting and killing a few thousand unarmed protestors ever in your history.
I guess the Cherokee don't count, huh, since they weren't protesting, just being forcibly marched from South Carolina to Oaklahoma during the winter? Just to pre-empt your objection to that comparison, the supreme court, at least, did not consider them a foreigners at that point.
Oh, and let's not forget about those WWII Japanese interment camps. Please. That wasn't so long ago. But I guess we didn't just shoot folks there, we just took all of their stuff, land, separated them from their families, and put them in camps.
Right, we don't shoot our protesters, generally we just tear gas them, shoot them with "non-lethal" pellet/bag guns, and lead covert ops against their organizers, arrest them, and in many cases, they just end up 'mysteriously murdered'... that is a little better, I suppose...
Don't get me wrong, we're not quite to the point of having a ruthless dictatorship in this country, but... I don't know, I mean, those guys killed in China weren't just protesting, they were calling for something akin to revolution. Do you really think a serious bid at revolution or basic government restructuring or even large grassroots protest reform movement in the US would be treated kindly right now?? I'd like to think so, but an awful lot of protesters in the US have been injured, and yes, more than just a couple killed by police in the past 4 years...
Anyway, my real point? Don't think it couldn't happen here. Prevent it from happening here. At least, be aware that it could happen here, and check your historical knowledge of some of the events found in responses to your (IMHO) not-terribly-insightful post...
As a chemist who's had a little forensics training, the science is not bad.
Let's talk about how easily and accurately one can estimate the time of death of a corpse, shall we?
If you believe these shows, it's an easy and exact science. In reality, it's neither.
If your 'little forensics training' indicates otherwise, please inform us... but if you really are trained, you'll know that these shows are quite wrong often on this detail.
IMHO, that's a basic enough failing in the "science accuracy" department to make it all quite suspect. These are short TV shows, with TV show hack script writers and limited schedules. Facts are frequently bent to make a better story. Real forensics experts have a hard time watching these shows, they're so full of mistakes.
Actually from what I understand the ad with directly be for whatever ad is showing at the time.
That's definitely a level of detail I didn't find in any of the articles on this that I've seen ( 3 total, I think ).
The current "thumbs up" thing that they do is of course targeted towards specific commercials, and they could continue to do it that way- only show banners for commercials currently being skipped- but they wouldn't need to be limited to that. There'd be at least one problem with that approach- 30 seconds at full-speed fast-forward is nothing, that banner would just flick on and off. I'm willing to bet the banners would be set for the duration of the fast-forward. How would they interact with the current thumbs-up thingie? Interesting question, we'll find out, I guess...
I know a couple of people who are really into forensics. Honest, I swear, it's not me, it's just the crowd I hang out with. They do stuff like take classes in forensics, just for fun, even though they aren't part of any degree program. Total sickos. I love 'em, and would find the stuff just as interesting if I didn't have some strange aversion to dead bodies.
Anyway, my friends took a lecture series on forensics, and came back after every session talking about how much time each guest speaker put into informing the class of just how wrong CSI is about so very many very basic, important things.
The science on the show is junk. Almost nothing is right- it's wrong way more often than right.
Just one blatant example? It's apparently really, really, really, really difficult to estimate time of death from a body alone. On these shows, they pretend to be able to estimate TOD very accurately. It's a joke, except that it sets up people to expect a real-life forensics expert to do things they can't possibly do.
So, in the final analysis, it's a double-edged sword, but it's more bad than good, just because it spreads soooo much disinformation, without enough warning that "the science in this show is fake, fake, fake; you won't learn anything true; don't believe a thing you see here, this is written by a TV show hack without review for technical validity of any kind". Really, it should have that kind of warning, the science to these shows is so far off.
The real value-add from TiVo here (for me, anyway) is not so much avoiding commercials as it is saving time.
The ability to record shows with a click of a button or ala 'Season Pass' is _really_ the killer feature.
Still, skipping commercials is the other killer DVR feature, and since I'm not watching what's on the screen ( except to look for the start of the show ), the idea of a NOT TOO LARGE banner add is no big deal at all. *Especially* if it keeps Tivo in business and keeps their subscription rates down.
Where this will kill Tivo is if the add gets too large and makes skipping not viable. Then they won't get the ad views, they'll just lose customers to competing DVRs. I don't think they're dumb enough to do that, they're a little too worried about competition as it is.
The bottom line is, I'll trade 2 minutes of annoying TV commercials for a 4 second static add *any* day. I'd prefer it wasn't there, but if they put one on, it's not like I'm getting rid of my Tivo.
The trade group said the program would be available for the Windows computer operating system on a special Web site established to educate consumers about copyrights.
No OS X or Linux version of the program available?
DRAT!
Re:The examples sound great, but...
on
Holub on Patterns
·
· Score: 1
You can't subclass a class without having to do the same with 5 or more others, to create your own little bubble of functionality. Java-heads seem to be obsessed with objectizing everything.
Well, to be fair, I'm not sure you're right. I've personally used "extend" to do all sorts of good things in Java. Often the subclass is simple and just adds one or two methods. Why would you have to subclass other classes just because you subclass one, again?
If someone writing in Java seems obsessed with making objects of everything, that's because in Java, everything is an object, with the exception of a few primitives ( which have object wrapper classes )... so in a sense, you have no real choice. If it's more complex than an int or float, you're talking object- there ain't no 'struct'.
Heck, even when you create *any* object, you're using 'extend', on the class "java.lang.Object"! The trick is to come up with a design that models your problem well, and break the problem in to tiny pieces the _first_ time, so you don't end up 'refactoring'.,, which basically means you didn't do a good design the first time. Which is typical. Knowing what to do before you start working on something is difficult, to say the least. That problem has nothing to do with OO or even programming, specifically, it's a problem with design and implementation of any system. Nobody builds a car from scratch on the first try without a few subsystem redesigns.
Having said that, just because you have to refactor doesn't mean you have to throw away your old API, you can wrap your refactored classes inside a 'compatability' class which supports your 'old' code. Again, I think the problem ( and danger , and badness ) of accessors and subclassing is being overstated to fan flames and attract traffic.
The examples sound great, but...
on
Holub on Patterns
·
· Score: 4, Interesting
I'd like to see the details of the first section.
I mean, yea, "getters/setters are bad", in public APIs. Getters are bad- unless you need to vend an object and can't afford the overhead of creating entirely new instances when you do so. Setters are _definitely_ bad- unless they're private or are data that act as input for your object, which it recieves from controller-layer objects.
Sure, "inheritance is dangerous" as anyone who has ever written an object-oriented program from scratch and had to modify it can tell you. Inheritance is also the key to code reuse, and can be very powerful when done correctly- do you really want to re-write a section of logic that's shared by 5 other objects ?
These things have their place. They're good targets for "is evil"-type articles because they're often used when they should not be. But to call them "evil" and "bad" without proper qualification? It smacks of unprofessional behavior, at best.
I'm a bit puzzled by claims that use of getter/setter methods and, more puzzling, inheritance, are indications that you haven't solved your problem in an object-oriented manner, or that your problem isn't object-oriented... because, well... not all problems are best solved by object-oriented methods, even if you're using an object-oriented language to do so. Sometimes, you need a variable and a loop... what's wrong with that?
At some point, my model code is going to have to give my view code some objects to display... what, I'm not supposed to use getters there? At some point my view code is going to want to tell my model code about an object the user modified... I'm not supposed to use a setter there? I often think folks who write such blanket statements as "accessors are bad" are just trying to spark some flames.
Why do you think that Disney movies don't flop due to brand recognition?
Need examples? How about "Treasure Planet"? "80 Days"?
"The Alamo"? "The Ladykillers"? "Raising Helen"?
Oh, you want animated movies that were flops? There sure were those as well...
Or do you mean the brand recognition of Toy Story, which is probably better than Disney right now?
Maybe Disney will make a direct-to-video movie, like they did for The Lion King, Lilo & Stitch, etc... I rate that as highly likely. They'll make the movie on a budget, it'll suck, test audiences will tell them so, and it'll end up being a big direct-to-DVD money maker for them, but hardly ever see the light of a theater, if at all.
That's my half-assed prediction, anyway. I'm going to do my best to avoid letting my son see any Disney-only Toy Story movie, lest the first two be ruined for him.
The article states that what is "natural" is defined very specifically by the problem area and how people working in it "naturally" think about that specific set of problems. Which makes sense... but doesn't lend itself well to general-purpose programming environments. Like some other poster said, oh god, COBOL... general purpose programming environments are going to require constructs and data structures which are well, general, flexible, and thus maybe not "natural" for some problems. But does that mean you need a different programming language?
If you have a specific problem area, what do you do as a programmer? You write a set of data structures and methods, aka APIs, that are specific to that problem area, then use them again and again. You might have heard of it, it's often called a library. You write those APIs in your general purpose programming language and go from there. These folks are trying to solve a problem that isn't as helpful to solve as they think, IMHO. Learning one language and several libraries of APIs is more useful to me than learning several different languages. Writing domain-specific APIs in a powerful general-purpose programming language seems more practical than creating entire new languages for every problem area.
I've already said some of this in a different thread, but I think it's important enough to the article to state clearly in a separate thread here. Mod me redundant if you somehow can't think of something better to do with mod points ( geesh, really... )
Not that it's not powerful and fairly easy to use ( you can do a *lot* of fairly amazing stuff with AppleScript that can't really be done otherwise ), but it is _not_ as straightforward as it should be... doing something relatively simple, like string manipulation, just isn't easy. How do you take a path name and add a few characters to it? It's kinda hard to figure out.
Of course, you could blame some of AppleScripts' difficulty-of-use on the unstructured, somewhat here-and-there nature of Apple's documentation of AppleScript, such as the ton of useful, important stuff that appears only in an "AppleScript Additions" PDF ( unlike *any* other AppleScript documentation ).
Something that really jumped out at me from the article is the notion that what's "natural" is defined very specifically by the problem area. Which makes sense... but doesn't lend itself well to general-purpose programming environments. Like some other poster said, oh god, COBOL... general purpose programming environments are going to require constructs and data structures which are well, general, flexible, and thus maybe not "natural" for some problems.
Big deal. If you have a specific problem area, what do you do as a programmer? You write a set of APIs that are specific to that problem area, then use them again and again. You write those APIs in your general purpose programming language and go from there. These folks are trying to solve a problem that isn't as helpful to solve as they think, IMHO. Learning one language and several libraries of APIs is more useful to me than learning several different languages.
Darn it, as soon as I posted the above, I realized that they did have _one_ keyboard on the list that was only $45... but my complaint stands. I'd like to see a few more neat things that someone might _actually_ get as a gift.
Slashdot Mirror
I have seen C and VB and even Pascal that is tough to understand. I have also seen Fortran that was well documented and easy to follow.
It's definitely true that it is quite possible to write well-commented and easy-to-understand code using Fortran.
The vast majority of Fortran I've seen, however, does not fall into this category. Some old-school optimization tricks, like variable reuse, are partly to blame for the poor readability, as is poor programming ( usually done by engineers, not programmers ). In my experience, most folks writing Fortran programs are scientists and engineers, not programmers, and they approach the problem as if they're writing some little function that will only ever be written once, and never modified. They get it to compile and move on to some "real work". If there's some edge case where the program errors out, users learn by trial and error to avoid that case. User interaction is an afterthought. This is mostly the programmer's fault, although I notice you didn't touch my statement about Fortran I/O routines being uh, not the easiest to use.
Still, ANY language with a "GOTO" construct and unclear if-branching is going to be hard to read. Fortran has both. Not to mention limited symbol length and non-sequential line numbering. It actually takes a great deal of care to create a readable Fortran program, and they are, as a result, rare.
Not to start a flamewar about Fortran, though, it definitely has it's uses, and it is possible to write a reasonably readable Fortran program, but... the language not only doesn't help you do so, it actually includes some limitations and conventions which make it difficult.
But support on OS X? Shoot, Fortran support on OS X rocks! It's frickin' Fortran-lover heaven. You even get Altivec calls from Fortran. All you lack is a decent way to do I/O ;-)
Seriously... although it may well be plausable that a good number of places which once would have installed a free Linux will now instead install a free Solaris x86, everyone knows good and well that even that scenario wouldn't "kill" Linux.
Depending on how "open" Solaris code turns out to be, it's success may indeed make all of Open Source stronger, prompting more companies to follow suit, releasing their core products under some sort of Open Source license and placing more engineers on open-source-based projects.
In any event, it's going to take a lot more than a free and open Solaris to "kill" Linux. Seriously, show me the Solaris fanatics... I haven't seen them. The Linux fanatics, on the other hand, are everywhere... and as long as they are alive, Linux will be alive as well. Which is a good thing.
You can support a family of 3 ( after rent ) on $22k a year!?! Wow, I'm impressed!! Do you send your kid to school? Do you dress him when you do?!?
Actually, I used my "so I can save to buy a house" income level in my original post, you could _get by_ on $80-90k on the peninsula, but... shouldn't a professional also be able to save and ( eventually, maybe out-of-area ) buy real estate? Or is that just a sad, old dream now??
(1) No problem.
XCode's build system is extremely flexible. You can have a custom script or binary run instead of the more standard targets. Just make a new project of "Empty Project" type, add a build target ( Project/New Target ) and pick either "external target" or "Shell Script Target" as appropriate. It'd be hard for it to be a lot easier without being language/tool specific, like the 'canned' target types ( of which there are already quite a few ).
(2)You want to use something that's not the most developer-friendly language ever created ( Objective-C ), the most commonly used language ever created ( C ), the most commonly used in commercial products OO language ( C++ ) nor the best mulitplatform language ever ( Java ) ?? What's your reasoning there?
I understand that there are reasons for using "none of the above" when writing code for OS X, like say, you have a big group of Fortran programs that you don't have time or need to rewrite, or you just rock at Python and don't have time to learn something else, or know you can do what you want in Pearl... but if you're developing a completely new codebase, with a full GUI-based app as your goal?
Learn Objective-C. Learn Cocoa. You'll be glad you did.
Second, we've successfully recompiled scads of old ( and not-so-old ) fortran code for OS X already. I guess the programs we had didn't need to much in terms of special support- we used g77. It's good to hear GCC is ( of course ) keeping up with the times.
A quick google search and a peak at the ADC website and it does look like GCC and the Macintosh are being used by the HPC folks. Altivec libraries available and everything, pretty much like you'd hope for, if FORTRAN is your bag.
Seriously. I used to live on the peninsula. I would like to live there again. But without a job paying *at least* $120k, I wouldn't even be able to rent a place for my family of 3, much less own a house.
What does CPU have to do with big binaries, besides an increase in paging, which is arguably a memory thing, even if you're talking about CPU cache...
Man, you've got too many big projects going on when you can't even be bothered to direct your own re-make. The time is right to do it, someone in Hollywood smelled the money of yet another special-effects humor zombie blockbuster, Jackson said what the heck, I'll take that paycheck, but I'm a little busy, how about my buddy directs?
Hey, what do you guys want from Raimi?
Would you ask Peter Jackson to make all of his movies look like Bad Taste and Meet the Feebles? Actually, *I* wouldn't complain, but all the same... cut the guy some slack, he's making cash. If you like the original better than the remake... hey, unlike Lucas' flicks, you can at least still *get* the original!!
Then again, there _do_ exist people who don't listen to music all that much, they just want 20 or 30 songs they can listen to at the gym and don't get that having your entire music collection in your pocke is heaven. Maybe it's just cheap enough for Apple to rev some flash players that they figure why not, it's not really going to cut from their iPod sales, just cut into other folks' sales.
But price is a big problem, if they're talking 1GB. I'm guessing they're talking about less. Actually, the whole price thing is what makes me think this rumor is just that, and nothing more. If you're spending over a hundred bucks on a flash player, what's stopping you from taking out a small loan or whatever it takes to get another $149 and pick up an iPod mini?
The only way Apple's going to make a $200 flash-based player is if it's frickin' unbelieveably small, stylish and has a super-long battery life. I guess it could happen, but I remain fairly skeptical. I guess they could always introduce a flash-based model only to eventually pull it, introducing new slightly cheaper iPod minis to replace it at some point.
Please cite a source, even if it's "my friend took a class" like my source. Unless the body is still frickin' _warm_, what you've said just isn't true. You've basically made my point that this type of fiction is bad, because you clearly believe something that just isn't so.
It was once thought ( by forensics pros ) that you could estimate TOD by measuring fluid in the eye, but that's been debunked ( relatively recently ). Experiments at the body farm have proved how varied the rate of insect infestation, decomposition, and other means of estimating TOD can really be. Time ranges on estimates have increased as more research has been done in this field.
Please, site a reference. CSI doesn't count...
Right. That's my reference. Where's your expert? If you have a current authoritative source that tells you the temperature of the liver or the vicosity of the eyeball or somesuch can lead to an exact time of death, please reference it. Otherwise, my statement ( unless you're going to assume I or my fiend are lying, which I'd take issue with ) of fact is quite nearly as good as if it came from the expert themselves, isn't it?
Would it make you feel better if I'd read about it in a book?!??
I guess the Cherokee don't count, huh, since they weren't protesting, just being forcibly marched from South Carolina to Oaklahoma during the winter? Just to pre-empt your objection to that comparison, the supreme court, at least, did not consider them a foreigners at that point.
Then there was Wounded Knee. No, the one in 1973.
Oh, and let's not forget about those WWII Japanese interment camps. Please. That wasn't so long ago. But I guess we didn't just shoot folks there, we just took all of their stuff, land, separated them from their families, and put them in camps.
Right, we don't shoot our protesters, generally we just tear gas them, shoot them with "non-lethal" pellet/bag guns, and lead covert ops against their organizers, arrest them, and in many cases, they just end up 'mysteriously murdered'... that is a little better, I suppose...
Don't get me wrong, we're not quite to the point of having a ruthless dictatorship in this country, but... I don't know, I mean, those guys killed in China weren't just protesting, they were calling for something akin to revolution. Do you really think a serious bid at revolution or basic government restructuring or even large grassroots protest reform movement in the US would be treated kindly right now?? I'd like to think so, but an awful lot of protesters in the US have been injured, and yes, more than just a couple killed by police in the past 4 years...
Anyway, my real point? Don't think it couldn't happen here. Prevent it from happening here. At least, be aware that it could happen here, and check your historical knowledge of some of the events found in responses to your (IMHO) not-terribly-insightful post...
Let's talk about how easily and accurately one can estimate the time of death of a corpse, shall we?
If you believe these shows, it's an easy and exact science. In reality, it's neither.
If your 'little forensics training' indicates otherwise, please inform us... but if you really are trained, you'll know that these shows are quite wrong often on this detail.
IMHO, that's a basic enough failing in the "science accuracy" department to make it all quite suspect. These are short TV shows, with TV show hack script writers and limited schedules. Facts are frequently bent to make a better story. Real forensics experts have a hard time watching these shows, they're so full of mistakes.
That's definitely a level of detail I didn't find in any of the articles on this that I've seen ( 3 total, I think ).
The current "thumbs up" thing that they do is of course targeted towards specific commercials, and they could continue to do it that way- only show banners for commercials currently being skipped- but they wouldn't need to be limited to that. There'd be at least one problem with that approach- 30 seconds at full-speed fast-forward is nothing, that banner would just flick on and off. I'm willing to bet the banners would be set for the duration of the fast-forward. How would they interact with the current thumbs-up thingie? Interesting question, we'll find out, I guess...
Anyway, my friends took a lecture series on forensics, and came back after every session talking about how much time each guest speaker put into informing the class of just how wrong CSI is about so very many very basic, important things.
The science on the show is junk. Almost nothing is right- it's wrong way more often than right.
Just one blatant example? It's apparently really, really, really, really difficult to estimate time of death from a body alone. On these shows, they pretend to be able to estimate TOD very accurately. It's a joke, except that it sets up people to expect a real-life forensics expert to do things they can't possibly do.
So, in the final analysis, it's a double-edged sword, but it's more bad than good, just because it spreads soooo much disinformation, without enough warning that "the science in this show is fake, fake, fake; you won't learn anything true; don't believe a thing you see here, this is written by a TV show hack without review for technical validity of any kind". Really, it should have that kind of warning, the science to these shows is so far off.
Sure enough, they went Bush/Chenney.
The ability to record shows with a click of a button or ala 'Season Pass' is _really_ the killer feature.
Still, skipping commercials is the other killer DVR feature, and since I'm not watching what's on the screen ( except to look for the start of the show ), the idea of a NOT TOO LARGE banner add is no big deal at all. *Especially* if it keeps Tivo in business and keeps their subscription rates down.
Where this will kill Tivo is if the add gets too large and makes skipping not viable. Then they won't get the ad views, they'll just lose customers to competing DVRs. I don't think they're dumb enough to do that, they're a little too worried about competition as it is.
The bottom line is, I'll trade 2 minutes of annoying TV commercials for a 4 second static add *any* day. I'd prefer it wasn't there, but if they put one on, it's not like I'm getting rid of my Tivo.
No OS X or Linux version of the program available?
DRAT!
Well, to be fair, I'm not sure you're right. I've personally used "extend" to do all sorts of good things in Java. Often the subclass is simple and just adds one or two methods. Why would you have to subclass other classes just because you subclass one, again?
If someone writing in Java seems obsessed with making objects of everything, that's because in Java, everything is an object, with the exception of a few primitives ( which have object wrapper classes )... so in a sense, you have no real choice. If it's more complex than an int or float, you're talking object- there ain't no 'struct'.
Heck, even when you create *any* object, you're using 'extend', on the class "java.lang.Object"! The trick is to come up with a design that models your problem well, and break the problem in to tiny pieces the _first_ time, so you don't end up 'refactoring'.,, which basically means you didn't do a good design the first time. Which is typical. Knowing what to do before you start working on something is difficult, to say the least. That problem has nothing to do with OO or even programming, specifically, it's a problem with design and implementation of any system. Nobody builds a car from scratch on the first try without a few subsystem redesigns.
Having said that, just because you have to refactor doesn't mean you have to throw away your old API, you can wrap your refactored classes inside a 'compatability' class which supports your 'old' code. Again, I think the problem ( and danger , and badness ) of accessors and subclassing is being overstated to fan flames and attract traffic.
I mean, yea, "getters/setters are bad", in public APIs. Getters are bad- unless you need to vend an object and can't afford the overhead of creating entirely new instances when you do so. Setters are _definitely_ bad- unless they're private or are data that act as input for your object, which it recieves from controller-layer objects.
Sure, "inheritance is dangerous" as anyone who has ever written an object-oriented program from scratch and had to modify it can tell you. Inheritance is also the key to code reuse, and can be very powerful when done correctly- do you really want to re-write a section of logic that's shared by 5 other objects ?
These things have their place. They're good targets for "is evil"-type articles because they're often used when they should not be. But to call them "evil" and "bad" without proper qualification? It smacks of unprofessional behavior, at best.
I'm a bit puzzled by claims that use of getter/setter methods and, more puzzling, inheritance, are indications that you haven't solved your problem in an object-oriented manner, or that your problem isn't object-oriented... because, well... not all problems are best solved by object-oriented methods, even if you're using an object-oriented language to do so. Sometimes, you need a variable and a loop... what's wrong with that?
At some point, my model code is going to have to give my view code some objects to display... what, I'm not supposed to use getters there? At some point my view code is going to want to tell my model code about an object the user modified... I'm not supposed to use a setter there? I often think folks who write such blanket statements as "accessors are bad" are just trying to spark some flames.
What I'm saying is it's already started.
Need examples? How about "Treasure Planet"? "80 Days"? "The Alamo"? "The Ladykillers"? "Raising Helen"?
Oh, you want animated movies that were flops? There sure were those as well...
Or do you mean the brand recognition of Toy Story, which is probably better than Disney right now?
Maybe Disney will make a direct-to-video movie, like they did for The Lion King, Lilo & Stitch, etc... I rate that as highly likely. They'll make the movie on a budget, it'll suck, test audiences will tell them so, and it'll end up being a big direct-to-DVD money maker for them, but hardly ever see the light of a theater, if at all.
That's my half-assed prediction, anyway. I'm going to do my best to avoid letting my son see any Disney-only Toy Story movie, lest the first two be ruined for him.
If you have a specific problem area, what do you do as a programmer? You write a set of data structures and methods, aka APIs, that are specific to that problem area, then use them again and again. You might have heard of it, it's often called a library. You write those APIs in your general purpose programming language and go from there. These folks are trying to solve a problem that isn't as helpful to solve as they think, IMHO. Learning one language and several libraries of APIs is more useful to me than learning several different languages. Writing domain-specific APIs in a powerful general-purpose programming language seems more practical than creating entire new languages for every problem area.
I've already said some of this in a different thread, but I think it's important enough to the article to state clearly in a separate thread here. Mod me redundant if you somehow can't think of something better to do with mod points ( geesh, really... )
Not that it's not powerful and fairly easy to use ( you can do a *lot* of fairly amazing stuff with AppleScript that can't really be done otherwise ), but it is _not_ as straightforward as it should be... doing something relatively simple, like string manipulation, just isn't easy. How do you take a path name and add a few characters to it? It's kinda hard to figure out.
Of course, you could blame some of AppleScripts' difficulty-of-use on the unstructured, somewhat here-and-there nature of Apple's documentation of AppleScript, such as the ton of useful, important stuff that appears only in an "AppleScript Additions" PDF ( unlike *any* other AppleScript documentation ).
Something that really jumped out at me from the article is the notion that what's "natural" is defined very specifically by the problem area. Which makes sense... but doesn't lend itself well to general-purpose programming environments. Like some other poster said, oh god, COBOL... general purpose programming environments are going to require constructs and data structures which are well, general, flexible, and thus maybe not "natural" for some problems.
Big deal. If you have a specific problem area, what do you do as a programmer? You write a set of APIs that are specific to that problem area, then use them again and again. You write those APIs in your general purpose programming language and go from there. These folks are trying to solve a problem that isn't as helpful to solve as they think, IMHO. Learning one language and several libraries of APIs is more useful to me than learning several different languages.
Darn it, as soon as I posted the above, I realized that they did have _one_ keyboard on the list that was only $45... but my complaint stands. I'd like to see a few more neat things that someone might _actually_ get as a gift.