Assassin's Creed 2 on PC has a confirmed release date on Tuesday 09 March 2010. It is 1 days left until you can play Assassin's Creed 2 on your PC in the USA. View below for more Assassin's Creed 2 release date details.
For US gamers, it's not even out yet, so the only people playing in the US have illicit copies in one way or another.
So we should allow censorship because of your anecdotal evidence about your nephew-in-law? Thanks, but no thanks.
I flatly refuse to accept that what we watch does not affect us. Movies like Saw and Hostel simply cannot be psychologically inert, the content is just too potent.
Yeah, and I flatly believe that you're qualified to tie your own shoes, much less determine what other people can and cannot do.
I've always found that testing was simpler when you could outright reject so many bad usages of methods at compile-time.
Maybe you're testing the wrong thing?
First, why do you need to see what happens when you call a method the wrong way? Call it the right way.
Now, how do you know you're calling it the right way, if you don't have a compiler or IDE telling you so? Because you test the point at which you're calling it.
In other words, test the behavior you actually expect, which is more or less the same kinds of tests you'd do in a strictly-typed language anyway. Ignore types. If there's a type issue, it should throw an exception at some point during testing. If it doesn't, your tests aren't thorough enough and you're going to be bitten, sooner or later, by another, non-type-related issue.
See, that's the exact problem, I reject the concept of testing code via an audit of all it's callers. You can't test a future callsite when you write your code now, especially when it may be someone else doing it. Yes, you can throw a runtime error, but then the same guy who used your interface incorrectly ALSO has to handle an exception correctly, and you're asking a lot of a junior programmer doing piddly work. In a typed language, it's impossible to get a method you're not explicitly expecting (and can test for).
I'd honestly be happier without a lot of the boilerplate in C++ (and doubly so in java!), but at the same time I don't want someone accidentally sending an object representing the database table of employees to the network.Serialize() method because they used a CamelCase variable name instead of an lower_underscores somewhere. It gets doubly bad when it's in an unlikely error handler that they didn't test properly - I don't want the validity of MY code depending on someone else implementing their tests perfectly, that's the antithesis of encapsulation.
I prefer static types,
I guess the next question is, how much real work have you done in a dynamically-typed lanugage?
Mostly cleanup of other people's work. Most of my work is in systems or embedded level, and as you pointed out below, that's not something you can generally throw 10x the hardware at. I'm most fluent in the C-syntax languages (C, C++, Java, PHP which is... well, PHP), although I've hit a good chunk of the procedural languages over the years (Python, ruby, lisp being the big names).
Is sendmail.cf considered turing complete?
it's a serious PITA to hunt down every caller and see what types they can possibly call the broken method with.
Why would you want to? This is why I ask what work you've done -- I can't recall ever, in all the Ruby or Javascript work I've done, seeing a method called with the wrong type, or wondering what type a method should be (or is being) called with.
And I was doing crazier things than you seem to be suggesting -- in JavaScript, I can quite literally pull a method out of one object and insert it into another object, on the fly. Yet somehow, proper design meant I never had type issues.
It's probably because most of my work on dynamically typed languages are when someone DIDN'T properly design, and I get to fix it. Or more commonly, someone did design it properly, but they went on to bigger and better things, and someone else made some changes that seemed to work, until another piece somewhere else came online and.... The normal bitrot you see on projects.
Runtime typechecking is more accurately "crashtime type checking",
Or, if you've done your job right, test-time checking. Static type checking could be seen as a subset of unit testing.
"testing" gets pre-empted by "deadlines". You don't get called in to panic-bugfix a system when they implemented "testing" properly.
I see more usage of dynamic typing in webwork than anywhere else.
I think that has to do with two things -- the need to get to market first, and the choice of hardware platform. If you wrote a new video game in Ruby, and your competitors used C++, your framerate would suck relative to theirs, and you can't exactly tell your users to buy ten times the hardware to make up for it. But if you wrote a new webapp in Ruby, and your competitors used C++, you'll hit the market before they have a working prototype, and you can buy ten times the hardware if you need to.
That honestly depends on a lot of things, I wouldn't write a 3d rendering engine in ruby, but it might be the right call for the slower-paced scripting of game events. Right tool for the job and all that. Back to dynamic typing - what's a specific thing that you can do (in a well-designed system) with a dynamic type that you can't do with polymorphism or templating? I've always found that testing was simpler when you could outright reject so many bad usages of methods at compile-time.
I prefer static types, because when I deal with a project in maintenence mode it's a serious PITA to hunt down every caller and see what types they can possibly call the broken method with.
Runtime typechecking is more accurately "crashtime type checking", good luck managing to keep a system completely operational after you throw an exception deep within a legacy library.
I suppose it depends on what you're doing, I see more usage of dynamic typing in webwork than anywhere else.
And it wouldn't hurt the users to become carpenters and build their own houses, and farmers and grow their own food, and mechanics and fix their own car, and programmers to write their own software, and actors to star in their own plays, and lawyers to argue their own cases, and neurosurgeons to perform brain surgury on themselves, and pilots to fly themselves....
It's an idiotic statement when used for any other profession, patently ridiculous when applied to everything at once, yet strangely common among computer geeks. Why? "Because I know it" is an invalid answer for anyone who is not perfect at every possible profession.
Why is it SO IMPORTANT that every machine have these tools so that you, the hotshot computer guy who knows everything about windows (HAH!) can avoid having to keep a USB stick on your keychain?
And what happens when there's two paths to the same physical disk? That's not impossible now, under configurations that the tool is supposed to handle. The OS really needs to be able to handle the situation because it IS the same - the physical disk and virtual disks are different 'paths' to the same thing.
The other part is a nice cartel of purchasers who set minimum prices and maintain large backstock in warehouses to avoid reducing the value of the market.
And marketing! Don't forget marketing!
A diamond is forever, indeed.
In slashdot math, 180 lines is better then 480.
Well, I suppose 180 vs 240 isn't completely terrible, but it in no way compares to broadcast. There's a reason broadcast video was on minimum 3/4" tapes - there were actual FCC standards about what quality you could broadcast in, how much noise, how black your black could be, etc.
Good news everybody! 10 seconds of research has discovered that copyright infringment involves SENDING copyrighted material, not receiving it! Usenet is only dangerous to contributors.
Leech away!
I suppose that no googlites in their ivory tower has heard about the firefox trademark issue, and certainly has no idea how trivial it is to determine if a browser is firefox based despite it's silly name.
No, they insist I go from Iceweasel 3.5 to Official firefox 2.0 in order to try out their toys.
Let me think about this tradeoff for a second. Hrm. no.
except you're completely and utterly wrong and have probably never read the standard boilerplate employment agreements.
Unless you have a 'nice' employer, or you've specifically negotiated your contract, many (most? all?) standard contracts claim everything you've ever done as theirs.
I've had that clause signed away on my agreements in the past, and won't work anywhere that doesn't agree to that. Taking the money or not is immaterial, it's the employment agreement that specifies what they own.
Example:
You never work from home, ever. You have no "work" laptop, only a desktop. You don't connect between them at all. At 5pm every day you go home and quit thinking about work. The software you're creating in your free time on your own hardware at your own house? Yeah, you signed that over to them.
The $1250 is a red herring.
Don't hit the keys so hard, it hurts.
