He's not saying the UK version is the main version, he's saying that the one with Vine Street and whatnot is what's on the most common version in the UK. If you scroll down to the "London Version", you'll see that it has the three properties mentioned in the article. There are doubtless other versions sold in the UK, just as there are in the US, and that was why the "main" qualifier was in there.
BTW, if you're curious, here's the rank of the different color groups based upon the average rate of return of that group with hotels. What that means is that every time someone completes a circuit of the board, a player that owns that color group with hotels will make back that percentage of their initial investment. I've also included the dollar amount that translates to. (I tried to space this nicely, but neither tt nor ecode kept whitespace; sorry.)
# Group %ret $ret 1 Orange 23.5 484.10 2 Lite Blue 20.7 221.49 3 Red 17.8 521.54 4 Lt Purple 17.7 343.38 5 Dark Blue 17.3 475.75 6 Yellow 17.2 524.60 7 Railroads 16.0 128.00 8 Green 15.1 591.92 9 Dk Purple 13.6 84.32 A Utilities 7.5 22.50
You can also see from this list that oranges are only best if you're using % return. The way to interpret this is that if you're reasonably early in the game, and people are just building, you want oranges because they are cheap to develop, and you need to get three houses up ASAP. However, if you're late in the game and hotels are already up, you should look to the absolute income for the best property, and there the rank changes:
I believe they're called New York, Tennessee Avenue and St. James Place. And this is just common sense - their relationship with jail, and the fact that they're on the end of a row (More bang for buck, house/hotel wise, and a 6,8, or 9 after jail yields a hit), makes them ideal.
Not just that:
The hit rate is further increased by the fact that the most-landed on chance square (hit it with a 12 after leaving jail) is three spaces after New York, and there's a move back three chance card.
There's also a move to the nearest utility chance card that puts you 4, 6, and 7 spaces from the oranges. (Two of the three chance squares will send you to electric if if you draw that card; only 1 will send you to water works.)
Still, I think it's pretty far from "common sense." Once you see it, it makes sense, but if you ask most people what properties they want they'll probably say the dark blues.
(And this has also been known for a LOT longer than the last year...)
Considering how little we really know about what goes on beneath the surface of the Earth, I'd say that these last two options still have a whole lot of merit
Exactly. You just explained yourself why they don't know where it's coming from, and where the mystery lay!
Is it coming from greater depths or is the shallow chamber bigger than we thought?
And implicit in the article, IF it's coming from greater depths, why isn't it creating earthquakes?
no return value -- so your program will return whatever junk is on the stack at the time to your OS. Any shell script using this value to determine the success of hello world would be in for random behaviour
I can't say for C, but at least in C++ if execution falls off the end of main() the return value is guranteed to be 0 in a compliant compiler, rather than random stack crap.
I watch L&O all the time. I think SVU is the best of the three versions I've seen (I haven't seen Trial by Jury; it was cut before I got the chance) because it's got by far the best cast and characters, though the stories often get way into the "very disturbing" category. The original bugs me because there are too many examples of the cops doing the exact things that make me hate cops. (One episode they refused someone who wasn't under arrest both a lawyer and needed medical attention, and refused to let him leave.) And Gorin or however it's spelled is somewhat obnoxious, and I don't like how every CI episode ends the exact same way.
Anyway. The example question I gave is in no way leading. In fact, that's about as UN-leading a question as you'll find. An example of a leading question would be "Freddy Freddinson earlier said this, but you don't agree with him, do you?", or "Sarah Sarahinson earlier said this. Your experience was about the same, wasn't it?", or probably even "Don't you watch Law & Order?"
Leading questions have the expected answer pretty much implicit in the question. If I could ask "You agree, don't you?" in a direct, chances are the question would be "yes". (There are times when you might want to emphasize the contrast between the expected answer and what the defendant actually thinks; like if they didn't agree, you might ask that question as phrased above anyway and let the defendant answer "no".) "Do you agree" doesn't suggest an answer at all. (And BTW, leading questions are usually not allowed for direct examinations, so you couldn't ask that question.)
IANAL, but I've play one in Mock Trial and in class
However, the OP was objecting to calling the bad guys such, apparently because the RIAA was worse. (It also sounds like he doesn't agree that copyright infringement is wrong, but my reading is that he objects to that phrasing mostly because the 'bad guys' term applies better to the RIAA.) I'm saying it doesn't matter if the RIAA is lying and cheating to make their case; if the person in the defendant's chair pirated music, than I think that they are a 'bad guy'. Others may disagree, but not for the reasons expressed.
Replace "SOMETHING" with "copyright infringement" and you're set. You've got to admit that probably most people they file against -- or their children -- are guilty of this. As sucky as their techniques are, they aren't just picking up a phone book, throwing it up in the air, and seeing what page it opens to when it lands.
And it's my contention -- and I infer from the article its author's too -- that in most (read: almost all) circumstances copyright infringement IS wrong.
(If you're referring to the first part, most people who are brought to trial are guilty of what they are charged with, or something similar. Even defense attorneys will tell you that.)
The difference is that if you commit perjury, you lie under oath. Lawyers are never under oath (unless not in their capacity as lawyer) so cannot commit perjury. (Maybe for opening or closing statements; I'm not sure what happens if they say something then. But most definitely NOT in an off-the-books meeting.)
Suborning perjury is if you either make or let someone lie. For instance, if a lawyer knows that if they call a witness that witness will lie, in my understanding they cannot call that witness, or at least can't ask about what they will lie about. Otherwise they are suborning perjury.
It seems that in this case the lawyers didn't even do that; my impression is that the girl never reached the witness stand. (If she did, then it would be suborning perjury.) Even assuming the girl is telling the truth, I don't know there's a crime here. It's certainly an ethical violation worthy of getting disbarred, but no tort and no crime.
And who exactly would those "bad guys" be? Hmmm? You don't see them breaking the law and using mafia-style racketeering techniques to win cases...
And cops and prosecutors often present questionable evidence, lie about how it was obtained to keep it in, etc. in order to get a conviction. That's certainly wrong. But does that mean that most of the people they're trying to get a conviction against isn't a 'bad guy'?
Just 'cause one side is in the wrong doesn't mean that the other side is in the clear.
it does mean that of all the people sued for downloading copyrighted materials, SOME were "bad guys", which IMHO isn't true...
And, unless the RIAA has a 0% hit rate of offenders (probably almost impossible), the author (and I, to a large extent) disagrees with you. There's no slip of the tongue.
I believe there are times when lawyers can make statements. Probably if something is not in dispute. For instance, in testimony a lawyer can have earlier testimony read back and say "Freddy Freddinson earlier said this. Do you agree?" and stuff like that. Probably this was something like that, and if he was more precise he would have said something like "And you say this isn't true. And you felt that..."
Though it does sound like the actual question is leading... rules must be different for depositions than for testimony...
He goes on about how hard it is to add attachments - it's really not that hard.
Actually he's referring to EXE attachments, which Google won't let you send. Even if it's in a ZIP file. If you want to send an exe you have to change the extension first, and that IS starting to tread into the realm of a pain. It's not hard to do, especially if you usually have Windows set to display extensions, but it's still an extra step on both ends. (And even then it's possible it wouldn't work; I haven't tried it.) But if you try to send an EXE or a ZIP with an EXE in it, it (after uploading it no less, which is really bothersome) displays a javascript alert saying that you can't do that for security and virus propogation reasons.
Wait a second...Didn't we just determine that Gmail is still in beta? Don't we all know that beta == issues?
At least the part with not being able to send zip files and exes is NOT because it's in beta; that's an explicit policy decision. Try it and you're told that you can't for security reasons. It's not like it just hasn't been implemented yet.
If I recall, the people who did that were hired by the company who made the scoreboard because they did stuff (display lowercase letters) that you couldn't even do with the official hardware.
With a typical file system, you'd probably see failures much sooner than a typical hard drive failure. At the very least you'd have to find one that's meant for flash drives so you don't burn out frequently written-to areas. (E.g. inode blocks, journal areas. It seems a log-structured file system might be called for here.)
I take this back, perhaps. Drives can do what's called wear leveling automagically under the file system's nose (and transparently) and even out where the writes fall, so you wouldn't necessarily need to use a special purpose file system.
From what I'm reading it probably is theoretically possible to make a flash hard drive that will last plenty long enough.
(I still hold that the cost will be more than a typical hard drive for a long time to come.)
It's also that hard drives have a high overhead cost. No matter what size the hard drive, you need some controlling stuff, a motor to drive the head, the head itself, and a hermetically sealed container. Compare that to what has to be a very small amount of electronics and a couple cents worth of plastic that goes with your typical flash drive.
That said, I think it will be a LONG TIME before you see solid state parts be priced competitively with hard drives. Looking at Pricewatch, a 2 gig flash card is a little over $100. From Circuit City, there's a 2 gig one for $99.99 after $30 savings and $70 rebate. I paid only a bit more than that (maybe $120?) for a 250 gig Segate a couple weeks ago when my older hard drive decided to go meet the great head of light entertainment in the sky. That means that even if hard drives make no priceing improvements over the following year, flash would have to drop about 50 times in price. Given that about 14 months ago I got a 120 GB hard drive for about the same price (btw, this isn't the one that went kaput), that means that hard drives are a little less than doubling in size for any given price every year. If this trend continues, that means that flash must drop in price 100 times -- that's two orders of magnitude! Do you *really* think that's going to happen?
Secondly, what would you do if flash DID? You couldn't replace your hard drive with it; flash has a much lower life span for writes. With a typical file system, you'd probably see failures much sooner than a typical hard drive failure. At the very least you'd have to find one that's meant for flash drives so you don't burn out frequently written-to areas. (E.g. inode blocks, journal areas. It seems a log-structured file system might be called for here.)
However, where Eclipse shines is that the code assist can also be linked to the documentation and the source code of that particular library. With a few simple keystrokes I can be looking at the Javadocs in another window or even in a separate web browser. Even the code assist drop down box in Eclipse can be set to include Javadocs explaining the methods, parameters etc. of that particular class/method/interface etc. So basically I have the source code of the library (if available) and the Javadocs, all with very easy navigational hyperlinks.
Ah, okay. Gotcha.
I tried to be clear in my original post that I was only referring to Visual C# Express. A number of my complaints are not valid when talking about the full version of Visual Studio\Visual C# etc.
Well, I'm not entirely convinced that it's not in Express. There's talk of how to do stuff with the class designer in the help files, which are explicitly marked for the express editions, and there's no mention that things like that are valid only for the full version. So I'm not sure if I just didn't find it or if it's not there and there was either a miscommunication, late decision, or just no effort on the part of the help people to specialize it for the express editions.
I hold that Java development in Eclipse is better than any other IDE I've used for any other language, but there's nothing I dislike more than unfair comparisons (okay, that's not true; there's a lot I like less, like, say, wars, but let's stay on topic), so let's remove a couple things from the list.
If you're programming in Java, Eclipse's code assist can be linked to the source code and the documentation for not just the standard library but ANY library that the project uses. IIRC, you can do this with Visual C# Express but it's a pain in the ass and it makes you jump through hoops for everything other than the standard library.
I must say that I'm talking out of my ass here, but I can't see this as being true. You need to include the library in the project in Eclipse to get it to give you code assist (or run), and I can't see it taking much more in VC#. But I could be wrong because I don't have any 3rd party libraries to test...
Eclipse also has a wonderful Javadoc engine which can make writing good Javadocs extremely simple and less time consuming.
I don't remember exactly what all Eclipse has, but Visual C# does the couple things I tested. (Specifically, if you're writing a function int foo(int i) it will insert the returns and param lines for you.)
That said, after a quick experimentation can't figure out how to get from the generated XML files (which aren't generated by default) to something like a webpage, but I'm sure there's a way.
And while I'm at it, let me add that the project configuration is completely different in VC# and VC++. Why is that?
Eclipse has very nice database integration plug-ins available. Including plug-ins that generate diagrams, UML etc.
At least the professional versions of VS will generate class diagrams for you. Don't know how close they are to being fully UML compliant (but they look pretty good), how easy it is to use, etc. The help files indicate that the ability SHOULD be in the Express editions, but I can't find it.
(BTW, I found this when looking for how to refactor stuff in C++, since they are trumping that as a big feature. Turns out it's pretty limited, but you can rename things from the class diagram.)
In any case, VC++ Express will give you call graphs. (Though not very nice ones; they're set up just using a standard tree control. But it works)
Finally, I have one gripe about the Eclipse UI. This is based off of 3.0 I think, so it's possible it's been fixed in 3.1. But for things where you right click and do something to an entitiy, say right click - refactor - rename or right click - find references, the basis for what the action is done to is not what you clicked on but the text cursor location. This is a pretty minor thing in comparison to most of the benefits, but it's still maddening.
Also (okay, I lied about the finally before), Eclipse is decidedly less snappy in terms of response than the Visual Studio Express editions. It's not a big thing, but the computers I've used it on (which are aged but still more than fine for most things) have ever-so-slight delays when opening menus and whatnot.
I don't know if you're talking USD or CAD there, but it's not too far off. I paid 30 USD over summer, but that was a promotion for new customers. I think usually it's 40 or 45 USD.
The $200 is probably for high speed internet + digital cable + HBO + land line + cell phone + TiVo subscription + who knows what else. (It still does seem high though; adding that up gives me about 150 maybe...)
It's more than that though, and that's not really what I'm addressing. You're talking about the [im]mutability of a specific object, I'm talking about the mutability of an entire class, and, even more generally, having always-throw methods. The mutability issues are somewhat independent, and both are completely independent from the always-throw problm.
For instance, look at the String class. The same could be said for the Integer, Double, etc. classes. In this case the class itself is immutable. (More precisely, every String object is immutable.) There aren't any methods to change it. Contrast this with a TreeMap, which has add and remove methods. This is the sort of immutability I'm talking about.
What you're saying doesn't require this distinction. For instance, if Java had const, a method could take, for example, a const TreeMap. That object would be immutable from the view of that method, but the overall class isn't.
But more generally, the whole issue of mutability isn't really what I'm talking about; it's just the best vehicle I've found for talking about the always-throw function. (And I submit that they are to be avoided when possible as they reduce the checking that the compiler can [reasonably] do.)
However, this leads us into the situation of having a method that always throws an exception. My claim is that this is a bad state to be in, and that that method would be better off unimplemented
This is a bit long-winded and I fear not totally coherent, but here you go:
The reason is that currently immutable collection classes must either forsake using the Collection interface (thus giving up compatibility with existing objects that demand a Collection, such as Collections.binarySearch() (okay, the latter takes a List, but same idea)) or must provide dummy implementations of functions such as add() and remove(). The latter functions can do nothing (so just public void add(Object o) { } essentially) or throw an exception. (Okay, so there are other options too, but those are probably the most appealing ones, and, in fact, the Java API says that "The 'destructive' [mutating] methods contained in this interface... are specified to throw UnsupportedOperationException if this collection does not support the operation.")
The reason that it's important that the objects throw an exception in these methods is that if you call a method that calls, say, add(), that method probably depends on add() succeeding. If add() doesn't succeed and doesn't signal its failure, the calling method might break, enter an infinite loop, etc.
However, this leads us into the situation of having a method that always throws an exception. My claim is that this is a bad state to be in, and that that method would be better off implemented. The reason is that if the method isn't present then the compiler can detect the problem. If I write someImmutableCollection.add(foo), the compiler will yell and say "ImmutableCollection doesn't have a method add." But if I write someCollection.add(foo) where someCollection is a type that implements add() as a throw-only method, the compiler will happily accept it. (At least probably; in this case it's possible to detect it statically. However, in the following case it isn't.) Note that it's still a bug; if that line runs the app will break.
But it gets worse. Because if a method bar() takes a Collection as a parameter, it might call add(). In that case, you can't call bar() with an immutable collection. But the compiler will let you. And, unlike in the last case, it's essentially completely impractical for a compiler to try to detect this.
What this all comes down to is that something that the compiler could tell you easily with a better design has been moved so that it won't be detected until you either run the code (and maybe not always -- perhaps it's a transient bug!) or review it, and neither of those are guranteed to happen. (It's the same reason programs such as Lint have been developed, and why compilers give you warnings.)
(One other comment I have goes back to the JFrame.add() method that originally brought this up. I was working on a program and ran into that design issue. But problem was that it works in 1.5, which is what I was using to develop with. But 1.5 binaries are backward compatible with the JRE 1.4 runtime, so I sent out the binary to other people in my group who then hit the bug. They still would have hit it if it were a compile-time thing because they would have probably had to recompile, but it goes back to a sure thing vs. a not sure thing. Stuff like the library incompatibilities decrease the chance, however small, that these bugs will be found.)
Finally is just the documentation aspect. If I call a method that takes an ImmutableCollection, I *KNOW* it won't add anything to the collection. I know that there isn't a bug in the method that will add something; I know that the documentation in that regard is up-to-date because the documentation IS The code, etc.
(I'll also point out that the particular case I'm talking about could also be rectified by providing something akin to C++'s const. Then ImmutableCollection becomes const Collection, size() and the other non-mutating functions are marked const, add() and the other mutating functions are not marked const, and voila. However, there are still other places where this principal can be applied. There are places where the cost of applying them is prohibitive compared to the benefits though.)
Sun is basically an engineering company, and they make nice clean hardware and software from a theoretical standpoint.
OTOH, there are also a lot of rough edges. Like how you access the number of elements in a Collection with the size() method, the number of elements in an array with the length property, and the number of characters in a String with the length() method. Oh, and that length property? Essentially unique; it's the only place in the language with a read only property.
Or how JFrame.add() used to universally throw an exception telling you to call JFrame.getContentPane().add() instead. ("Fixed" in 1.5 by just calling that method directly.) And while we're on that subject, the whole idea that the API has classes with (and condones implementing interfaces with, as is the case with the Collection interfaces) methods that always throw is smelly. If a method isn't supported, it shouldn't be there in the first place. Moving it out of the class/interface moves error detection from runtime to compile time -- and this is a good thing. (IMO the "proper" way to do this would be to have instead of Collection, have two interfaces. Collection would have only accessors. MutibleCollection would add the add(), remove(), etc. methods that change it.)
Or the fact that Java literature doesn't talk about pointers. They're called references in Java. Except for NullPointerException. Why not NullReferenceException?
Or the fact that String types are in a world of their own. They are more priviledged than user classes because they have operator+ defined on them, but less priviledged than the build-in types because (among other things) you can't use them in switch statements.
I could go on with just small, little details that I think make the statement that Java is a nice clean piece of work from a theoretical sense silly. (I could also go on with things I think are substantial omissions from the language/library, but that's off topic.)
Not to mention that theories which have been flat-out DISPROVEN (*cough* Newton's laws *cough*) are still taught and used because they are more than good enough 99.99% of the time.
Well, I can use it. I did read the manual, but is it such a horrible thing to trade off a small learning curve for a huge power payoff?
That depends. If it's something you'll be using fairly frequently, no.
On the other hand, if you want to toy around and try your hand at 3D modeling, or do a quick illustration for a class or something like that, then yes, because the learning curve becomes prohibitive. With Blender it's almost like you have to work through several tutorials before you can even think about doing what you want to do.
I used to have the 3D Studio knowledge to show someone in probably 30 minutes what it took me a few hours to learn to do in Blender. It's been a while since I used Max, so I don't know if I still do.
BTW, there's no reason that the goals have to be mutually exclusive. The Blender crew could add a beginner mode to the UI. Even if they didn't want to do that, they could still make leaps and bounds of improvements without sacrificing your power.
Slashdot Mirror
He's not saying the UK version is the main version, he's saying that the one with Vine Street and whatnot is what's on the most common version in the UK. If you scroll down to the "London Version", you'll see that it has the three properties mentioned in the article. There are doubtless other versions sold in the UK, just as there are in the US, and that was why the "main" qualifier was in there.
1. Green
2. Yellow
3. Red
4. Orange
5. Dark Blue
I believe they're called New York, Tennessee Avenue and St. James Place. And this is just common sense - their relationship with jail, and the fact that they're on the end of a row (More bang for buck, house/hotel wise, and a 6,8, or 9 after jail yields a hit), makes them ideal.
Not just that:
The hit rate is further increased by the fact that the most-landed on chance square (hit it with a 12 after leaving jail) is three spaces after New York, and there's a move back three chance card.
There's also a move to the nearest utility chance card that puts you 4, 6, and 7 spaces from the oranges. (Two of the three chance squares will send you to electric if if you draw that card; only 1 will send you to water works.)
Still, I think it's pretty far from "common sense." Once you see it, it makes sense, but if you ask most people what properties they want they'll probably say the dark blues.
(And this has also been known for a LOT longer than the last year...)
Considering how little we really know about what goes on beneath the surface of the Earth, I'd say that these last two options still have a whole lot of merit
Exactly. You just explained yourself why they don't know where it's coming from, and where the mystery lay!
Is it coming from greater depths or is the shallow chamber bigger than we thought?
And implicit in the article, IF it's coming from greater depths, why isn't it creating earthquakes?
no return value -- so your program will return whatever junk is on the stack at the time to your OS. Any shell script using this value to determine the success of hello world would be in for random behaviour
I can't say for C, but at least in C++ if execution falls off the end of main() the return value is guranteed to be 0 in a compliant compiler, rather than random stack crap.
I watch L&O all the time. I think SVU is the best of the three versions I've seen (I haven't seen Trial by Jury; it was cut before I got the chance) because it's got by far the best cast and characters, though the stories often get way into the "very disturbing" category. The original bugs me because there are too many examples of the cops doing the exact things that make me hate cops. (One episode they refused someone who wasn't under arrest both a lawyer and needed medical attention, and refused to let him leave.) And Gorin or however it's spelled is somewhat obnoxious, and I don't like how every CI episode ends the exact same way.
Anyway. The example question I gave is in no way leading. In fact, that's about as UN-leading a question as you'll find. An example of a leading question would be "Freddy Freddinson earlier said this, but you don't agree with him, do you?", or "Sarah Sarahinson earlier said this. Your experience was about the same, wasn't it?", or probably even "Don't you watch Law & Order?"
Leading questions have the expected answer pretty much implicit in the question. If I could ask "You agree, don't you?" in a direct, chances are the question would be "yes". (There are times when you might want to emphasize the contrast between the expected answer and what the defendant actually thinks; like if they didn't agree, you might ask that question as phrased above anyway and let the defendant answer "no".) "Do you agree" doesn't suggest an answer at all. (And BTW, leading questions are usually not allowed for direct examinations, so you couldn't ask that question.)
IANAL, but I've play one in Mock Trial and in class
I fully agree with you.
However, the OP was objecting to calling the bad guys such, apparently because the RIAA was worse. (It also sounds like he doesn't agree that copyright infringement is wrong, but my reading is that he objects to that phrasing mostly because the 'bad guys' term applies better to the RIAA.) I'm saying it doesn't matter if the RIAA is lying and cheating to make their case; if the person in the defendant's chair pirated music, than I think that they are a 'bad guy'. Others may disagree, but not for the reasons expressed.
ah, the old "straw man" tact, well done.
Replace "SOMETHING" with "copyright infringement" and you're set. You've got to admit that probably most people they file against -- or their children -- are guilty of this. As sucky as their techniques are, they aren't just picking up a phone book, throwing it up in the air, and seeing what page it opens to when it lands.
And it's my contention -- and I infer from the article its author's too -- that in most (read: almost all) circumstances copyright infringement IS wrong.
(If you're referring to the first part, most people who are brought to trial are guilty of what they are charged with, or something similar. Even defense attorneys will tell you that.)
The difference is that if you commit perjury, you lie under oath. Lawyers are never under oath (unless not in their capacity as lawyer) so cannot commit perjury. (Maybe for opening or closing statements; I'm not sure what happens if they say something then. But most definitely NOT in an off-the-books meeting.)
Suborning perjury is if you either make or let someone lie. For instance, if a lawyer knows that if they call a witness that witness will lie, in my understanding they cannot call that witness, or at least can't ask about what they will lie about. Otherwise they are suborning perjury.
It seems that in this case the lawyers didn't even do that; my impression is that the girl never reached the witness stand. (If she did, then it would be suborning perjury.) Even assuming the girl is telling the truth, I don't know there's a crime here. It's certainly an ethical violation worthy of getting disbarred, but no tort and no crime.
IANAL
And who exactly would those "bad guys" be? Hmmm? You don't see them breaking the law and using mafia-style racketeering techniques to win cases...
And cops and prosecutors often present questionable evidence, lie about how it was obtained to keep it in, etc. in order to get a conviction. That's certainly wrong. But does that mean that most of the people they're trying to get a conviction against isn't a 'bad guy'?
Just 'cause one side is in the wrong doesn't mean that the other side is in the clear.
it does mean that of all the people sued for downloading copyrighted materials, SOME were "bad guys", which IMHO isn't true...
And, unless the RIAA has a 0% hit rate of offenders (probably almost impossible), the author (and I, to a large extent) disagrees with you. There's no slip of the tongue.
I believe there are times when lawyers can make statements. Probably if something is not in dispute. For instance, in testimony a lawyer can have earlier testimony read back and say "Freddy Freddinson earlier said this. Do you agree?" and stuff like that. Probably this was something like that, and if he was more precise he would have said something like "And you say this isn't true. And you felt that..."
Though it does sound like the actual question is leading... rules must be different for depositions than for testimony...
He goes on about how hard it is to add attachments - it's really not that hard.
Actually he's referring to EXE attachments, which Google won't let you send. Even if it's in a ZIP file. If you want to send an exe you have to change the extension first, and that IS starting to tread into the realm of a pain. It's not hard to do, especially if you usually have Windows set to display extensions, but it's still an extra step on both ends. (And even then it's possible it wouldn't work; I haven't tried it.) But if you try to send an EXE or a ZIP with an EXE in it, it (after uploading it no less, which is really bothersome) displays a javascript alert saying that you can't do that for security and virus propogation reasons.
Wait a second...Didn't we just determine that Gmail is still in beta? Don't we all know that beta == issues?
At least the part with not being able to send zip files and exes is NOT because it's in beta; that's an explicit policy decision. Try it and you're told that you can't for security reasons. It's not like it just hasn't been implemented yet.
If I recall, the people who did that were hired by the company who made the scoreboard because they did stuff (display lowercase letters) that you couldn't even do with the official hardware.
With a typical file system, you'd probably see failures much sooner than a typical hard drive failure. At the very least you'd have to find one that's meant for flash drives so you don't burn out frequently written-to areas. (E.g. inode blocks, journal areas. It seems a log-structured file system might be called for here.)
I take this back, perhaps. Drives can do what's called wear leveling automagically under the file system's nose (and transparently) and even out where the writes fall, so you wouldn't necessarily need to use a special purpose file system.
From what I'm reading it probably is theoretically possible to make a flash hard drive that will last plenty long enough.
(I still hold that the cost will be more than a typical hard drive for a long time to come.)
It's also that hard drives have a high overhead cost. No matter what size the hard drive, you need some controlling stuff, a motor to drive the head, the head itself, and a hermetically sealed container. Compare that to what has to be a very small amount of electronics and a couple cents worth of plastic that goes with your typical flash drive.
That said, I think it will be a LONG TIME before you see solid state parts be priced competitively with hard drives. Looking at Pricewatch, a 2 gig flash card is a little over $100. From Circuit City, there's a 2 gig one for $99.99 after $30 savings and $70 rebate. I paid only a bit more than that (maybe $120?) for a 250 gig Segate a couple weeks ago when my older hard drive decided to go meet the great head of light entertainment in the sky. That means that even if hard drives make no priceing improvements over the following year, flash would have to drop about 50 times in price. Given that about 14 months ago I got a 120 GB hard drive for about the same price (btw, this isn't the one that went kaput), that means that hard drives are a little less than doubling in size for any given price every year. If this trend continues, that means that flash must drop in price 100 times -- that's two orders of magnitude! Do you *really* think that's going to happen?
Secondly, what would you do if flash DID? You couldn't replace your hard drive with it; flash has a much lower life span for writes. With a typical file system, you'd probably see failures much sooner than a typical hard drive failure. At the very least you'd have to find one that's meant for flash drives so you don't burn out frequently written-to areas. (E.g. inode blocks, journal areas. It seems a log-structured file system might be called for here.)
However, where Eclipse shines is that the code assist can also be linked to the documentation and the source code of that particular library. With a few simple keystrokes I can be looking at the Javadocs in another window or even in a separate web browser. Even the code assist drop down box in Eclipse can be set to include Javadocs explaining the methods, parameters etc. of that particular class/method/interface etc. So basically I have the source code of the library (if available) and the Javadocs, all with very easy navigational hyperlinks.
Ah, okay. Gotcha.
I tried to be clear in my original post that I was only referring to Visual C# Express. A number of my complaints are not valid when talking about the full version of Visual Studio\Visual C# etc.
Well, I'm not entirely convinced that it's not in Express. There's talk of how to do stuff with the class designer in the help files, which are explicitly marked for the express editions, and there's no mention that things like that are valid only for the full version. So I'm not sure if I just didn't find it or if it's not there and there was either a miscommunication, late decision, or just no effort on the part of the help people to specialize it for the express editions.
I hold that Java development in Eclipse is better than any other IDE I've used for any other language, but there's nothing I dislike more than unfair comparisons (okay, that's not true; there's a lot I like less, like, say, wars, but let's stay on topic), so let's remove a couple things from the list.
If you're programming in Java, Eclipse's code assist can be linked to the source code and the documentation for not just the standard library but ANY library that the project uses. IIRC, you can do this with Visual C# Express but it's a pain in the ass and it makes you jump through hoops for everything other than the standard library.
I must say that I'm talking out of my ass here, but I can't see this as being true. You need to include the library in the project in Eclipse to get it to give you code assist (or run), and I can't see it taking much more in VC#. But I could be wrong because I don't have any 3rd party libraries to test...
Eclipse also has a wonderful Javadoc engine which can make writing good Javadocs extremely simple and less time consuming.
I don't remember exactly what all Eclipse has, but Visual C# does the couple things I tested. (Specifically, if you're writing a function int foo(int i) it will insert the returns and param lines for you.)
That said, after a quick experimentation can't figure out how to get from the generated XML files (which aren't generated by default) to something like a webpage, but I'm sure there's a way.
And while I'm at it, let me add that the project configuration is completely different in VC# and VC++. Why is that?
Eclipse has very nice database integration plug-ins available. Including plug-ins that generate diagrams, UML etc.
At least the professional versions of VS will generate class diagrams for you. Don't know how close they are to being fully UML compliant (but they look pretty good), how easy it is to use, etc. The help files indicate that the ability SHOULD be in the Express editions, but I can't find it.
(BTW, I found this when looking for how to refactor stuff in C++, since they are trumping that as a big feature. Turns out it's pretty limited, but you can rename things from the class diagram.)
In any case, VC++ Express will give you call graphs. (Though not very nice ones; they're set up just using a standard tree control. But it works)
Finally, I have one gripe about the Eclipse UI. This is based off of 3.0 I think, so it's possible it's been fixed in 3.1. But for things where you right click and do something to an entitiy, say right click - refactor - rename or right click - find references, the basis for what the action is done to is not what you clicked on but the text cursor location. This is a pretty minor thing in comparison to most of the benefits, but it's still maddening.
Also (okay, I lied about the finally before), Eclipse is decidedly less snappy in terms of response than the Visual Studio Express editions. It's not a big thing, but the computers I've used it on (which are aged but still more than fine for most things) have ever-so-slight delays when opening menus and whatnot.
I don't know if you're talking USD or CAD there, but it's not too far off. I paid 30 USD over summer, but that was a promotion for new customers. I think usually it's 40 or 45 USD.
The $200 is probably for high speed internet + digital cable + HBO + land line + cell phone + TiVo subscription + who knows what else. (It still does seem high though; adding that up gives me about 150 maybe...)
It's more than that though, and that's not really what I'm addressing. You're talking about the [im]mutability of a specific object, I'm talking about the mutability of an entire class, and, even more generally, having always-throw methods. The mutability issues are somewhat independent, and both are completely independent from the always-throw problm.
For instance, look at the String class. The same could be said for the Integer, Double, etc. classes. In this case the class itself is immutable. (More precisely, every String object is immutable.) There aren't any methods to change it. Contrast this with a TreeMap, which has add and remove methods. This is the sort of immutability I'm talking about.
What you're saying doesn't require this distinction. For instance, if Java had const, a method could take, for example, a const TreeMap. That object would be immutable from the view of that method, but the overall class isn't.
But more generally, the whole issue of mutability isn't really what I'm talking about; it's just the best vehicle I've found for talking about the always-throw function. (And I submit that they are to be avoided when possible as they reduce the checking that the compiler can [reasonably] do.)
Please correct a small but important typo:
However, this leads us into the situation of having a method that always throws an exception. My claim is that this is a bad state to be in, and that that method would be better off unimplemented
This is a bit long-winded and I fear not totally coherent, but here you go:
... are specified to throw UnsupportedOperationException if this collection does not support the operation.")
The reason is that currently immutable collection classes must either forsake using the Collection interface (thus giving up compatibility with existing objects that demand a Collection, such as Collections.binarySearch() (okay, the latter takes a List, but same idea)) or must provide dummy implementations of functions such as add() and remove(). The latter functions can do nothing (so just public void add(Object o) { } essentially) or throw an exception. (Okay, so there are other options too, but those are probably the most appealing ones, and, in fact, the Java API says that "The 'destructive' [mutating] methods contained in this interface
The reason that it's important that the objects throw an exception in these methods is that if you call a method that calls, say, add(), that method probably depends on add() succeeding. If add() doesn't succeed and doesn't signal its failure, the calling method might break, enter an infinite loop, etc.
However, this leads us into the situation of having a method that always throws an exception. My claim is that this is a bad state to be in, and that that method would be better off implemented. The reason is that if the method isn't present then the compiler can detect the problem. If I write someImmutableCollection.add(foo), the compiler will yell and say "ImmutableCollection doesn't have a method add." But if I write someCollection.add(foo) where someCollection is a type that implements add() as a throw-only method, the compiler will happily accept it. (At least probably; in this case it's possible to detect it statically. However, in the following case it isn't.) Note that it's still a bug; if that line runs the app will break.
But it gets worse. Because if a method bar() takes a Collection as a parameter, it might call add(). In that case, you can't call bar() with an immutable collection. But the compiler will let you. And, unlike in the last case, it's essentially completely impractical for a compiler to try to detect this.
What this all comes down to is that something that the compiler could tell you easily with a better design has been moved so that it won't be detected until you either run the code (and maybe not always -- perhaps it's a transient bug!) or review it, and neither of those are guranteed to happen. (It's the same reason programs such as Lint have been developed, and why compilers give you warnings.)
(One other comment I have goes back to the JFrame.add() method that originally brought this up. I was working on a program and ran into that design issue. But problem was that it works in 1.5, which is what I was using to develop with. But 1.5 binaries are backward compatible with the JRE 1.4 runtime, so I sent out the binary to other people in my group who then hit the bug. They still would have hit it if it were a compile-time thing because they would have probably had to recompile, but it goes back to a sure thing vs. a not sure thing. Stuff like the library incompatibilities decrease the chance, however small, that these bugs will be found.)
Finally is just the documentation aspect. If I call a method that takes an ImmutableCollection, I *KNOW* it won't add anything to the collection. I know that there isn't a bug in the method that will add something; I know that the documentation in that regard is up-to-date because the documentation IS The code, etc.
(I'll also point out that the particular case I'm talking about could also be rectified by providing something akin to C++'s const. Then ImmutableCollection becomes const Collection, size() and the other non-mutating functions are marked const, add() and the other mutating functions are not marked const, and voila. However, there are still other places where this principal can be applied. There are places where the cost of applying them is prohibitive compared to the benefits though.)
Sun is basically an engineering company, and they make nice clean hardware and software from a theoretical standpoint.
OTOH, there are also a lot of rough edges. Like how you access the number of elements in a Collection with the size() method, the number of elements in an array with the length property, and the number of characters in a String with the length() method. Oh, and that length property? Essentially unique; it's the only place in the language with a read only property.
Or how JFrame.add() used to universally throw an exception telling you to call JFrame.getContentPane().add() instead. ("Fixed" in 1.5 by just calling that method directly.) And while we're on that subject, the whole idea that the API has classes with (and condones implementing interfaces with, as is the case with the Collection interfaces) methods that always throw is smelly. If a method isn't supported, it shouldn't be there in the first place. Moving it out of the class/interface moves error detection from runtime to compile time -- and this is a good thing. (IMO the "proper" way to do this would be to have instead of Collection, have two interfaces. Collection would have only accessors. MutibleCollection would add the add(), remove(), etc. methods that change it.)
Or the fact that Java literature doesn't talk about pointers. They're called references in Java. Except for NullPointerException. Why not NullReferenceException?
Or the fact that String types are in a world of their own. They are more priviledged than user classes because they have operator+ defined on them, but less priviledged than the build-in types because (among other things) you can't use them in switch statements.
I could go on with just small, little details that I think make the statement that Java is a nice clean piece of work from a theoretical sense silly. (I could also go on with things I think are substantial omissions from the language/library, but that's off topic.)
Not to mention that theories which have been flat-out DISPROVEN (*cough* Newton's laws *cough*) are still taught and used because they are more than good enough 99.99% of the time.
Well, I can use it. I did read the manual, but is it such a horrible thing to trade off a small learning curve for a huge power payoff?
That depends. If it's something you'll be using fairly frequently, no.
On the other hand, if you want to toy around and try your hand at 3D modeling, or do a quick illustration for a class or something like that, then yes, because the learning curve becomes prohibitive. With Blender it's almost like you have to work through several tutorials before you can even think about doing what you want to do.
I used to have the 3D Studio knowledge to show someone in probably 30 minutes what it took me a few hours to learn to do in Blender. It's been a while since I used Max, so I don't know if I still do.
BTW, there's no reason that the goals have to be mutually exclusive. The Blender crew could add a beginner mode to the UI. Even if they didn't want to do that, they could still make leaps and bounds of improvements without sacrificing your power.