You'll note that I'm not responding to some of your bullet points...
It's quite obvious you don't respond because you don't feel like admitting your mistakes.
If developers will not embrace a platform that does not allow them to use legacy code, they're not going to embrace a platform that doesn't allow them to use legacy code.
Of course Java allows them to.
Since you haven't answered my question as to what you'd propose instead
The question is an awkward since it's a very basic one, and out of incredulity I hesitated to embarass you by answering directly. Almost every single Java application converses with non-Java applications. Since you persist, Java (which is vastly more widely adopted than.NET despite not implementing and encouraging native interop the way.NET does - already categorically proving you wrong, but let's humor you) works with legacy code the way most distinct systems do: through network sockets (using any protocol you like), database APIs, file APIs, and at the outer limits, rarely, the Runtime APIs... which invoke external programs in the host in a separate process, without exposing them to the VM's address space.
The bare fact is that you have it backwards. Why write anything in Java in the first place? There are many tradeoffs to the VM, as you (might?) know. Some of the big reasons to go that way are the guarantees of safety/reliability and security the VM gives you. If you mix unsafe code into the VM all those upsides disappear, but you keep all of the downsides plus you pay performance penalties and there are other problems as well, these are just the big issues. And this is where I see I am repeating myself yet again... honestly if you haven't gotten it by now, I'm not sure why I'm still trying, but...
Imagine, on/. all you need to bring is a bad idea and an obnoxious attitude, and you get a free education. What a country.
Yet you don't ever say that developers shouldn't be allowed to do this, exactly.
I don't ever say it, period.
your problem with.NET is not that it allows the use of unmanaged code, but that, in your mind, the documentation says it's OK to do that.
It's more than that "it's OK." Users are bluntly encouraged to misuse the feature. It's "promoted" as a long-term solution.
I've not only shown that MS promotes and encourages interop misuse, but I've illustrated (quite vividly) how even they understand the problem, and their published best practices are contradicted by their own MSDN documents.
Microsoft promotes this practice for two reasons; first because they know you can win over some less experienced or skilled developers with sugary misfeatures like this ("look how easy and fun it is to do this stupid thing! those java guys never let me have any fun..."), and second because they know encouraging pervasive native interop locks code into their platform.
My first link shows they promote it, my second does too, and there is even more out there, and you either know it already, because you're familiar with.NET and realize they had a marketing campaign that sold the platform with this "feature," or you're not really that familiar with.NET...
I don't believe I ever wrote "incidental-ness."
Of course you didn't. I hope you take my meaning, though?
yet I was recently offered a relatively lucrative position doing OCaml precisely because I had OCaml experience, unlike most other applicants
So your theory is, don't learn what's in demand. Learn something that's not.
Got it.
I mean, if you really love.NET, by all means, become an.NET developer and damn the consequences. But... if you're asking, hey, I don't have a preference... should I learn.NET or Java? Don't say ".NET, cause those fewer jobs you can get might pay better, (when you can
All good points. Thank you very much! You're certainly correct in that those cases are not slam-dunks against EULAs themselves - each came in its own context. They're hopefully useful for setting a tone, and overall I hope the point is nonetheless made - the EULA is not some bedrock legal principle handed down from Thomas Jefferson. It's a wacky new thing someone threw against the wall to see if it would stick. It's caught on in certain circles but by no means does it get the treatment in court that its haughty and forbidding language might suggest to a layman.
I still have some serious questions about your conclusions; I hope you can forgive my persistence.
1) Step-Saver notwithstanding, fitness/implied warranty don't seem to require a phone conversation or other existing deal to be established when I go into a store and buy something like a video game or a word processor - certainly not to the point where an officious piece of short fiction written inside the box could override it let alone if.... 2) The "click-wrap" license can't even be read until after you purchase and open the merchandise, and... 3) There is no way to tell if the user assented to it or not, after the fact. I know what you're thinking when I say this, and it's even worse than you think. It's ultimately reducible to the "paperless voting machine" conundrum. I say I didn't agree, the other party says I did, and the only way of determining it is to query a hard drive... 4) Not to mention that almost no clickwrap code even records a decision explicitly... that's because everyone knows its a joke, even the people who program it... 5) To even make the blanket statement that "a click-wrap agreement will be enforceable" seems rather odd, since let's be frank, it entirely depends on what's in it, and I think we can agree that its degree of enforceability depends quite substantially on the intersection between what it is attempting to enforce (usually the legal equivalent of a consturction worker's sex fantasy) and its credibility as a formal, verifiable binding agreement that all parties have entered into with good representation and fully informed consent (virtually nil by conventional standards). 7) Leaving aside what is, think about what should be. Do you really want to live in a world where every exchange of data is a legal negotiation of unlimited dimensions? Is that even really feasible, when taken to its logical conclusion? Isn't this just another "software patent-esque" legal doctine, where it only appears to work until everyone stops ignoring it and actually takes it seriously? 8) Have we really admitted the death of the UCC? Are we ready to abandon common law? By saying a 20 page legal document in a tiny window that 99% of the U.S. isn't qualified to read (and to retain an attorney to read it for you is vastly more expensive than the price of the commodity it "governs") and therefore doesn't read... is binding anyway... you have effectively given carte blanche to those who write the documents, to do anything they wish. Well, I've said "anything," but I must ask: do you imagine there are limits on the practice at all? If so, what? Do you think reasonable expectations and commercial or industry standards play any role at all, anymore? Does each sale of a piece of music really start at the tabula rasa of a new contract, between a team of 30 world-class corporate lawyers in New York and an 11 year old in Tulsa who just wanted to listen to Eminem?
Step-Saver Data Systems, Inc. v. Wyse Technology, 939 F.2d 91 (3rd Cir. 1991) was case in which the legality and history of computer EULAs was explored. The court noted, "When these form licenses were first developed for software, it was, in large part, to avoid the federal copyright law first sale doctrine" thus the intent of EULAs after 1990 were to preempt federal statutes using contract law and that they serve no purpose besides attempts to preempt consumer rights in other statutes.
In this case, the U.S. Court of Appeals for the Third Circuit held that a EULA disclaimer waiving all express and implied warranties, printed on the outside of the box, was not binding. Step-Saver repeatedly bought Multilink Advanced, an allegedly MS-DOS compatible operating system, from The Software Link (TSL). On each box was a shrink wrap license disclaimer; "software sold AS IS, without warranty; TSL disclaims all express and implied warranties; if you don't agree to this disclaimer return the product, unopened, to TSL for a refund.". Step-Saver sued TSL, claiming that Multilink Advanced was not MS-DOS compatible. The court ruled that the EULA was not enforceable and that the sole reason of the EULA after 1990 was to preempt federal statutory and constitional laws. This matter, however, involved a negotiated transaction between two businesses, and the licenses varied terms between the shrink wrap license and the sale terms which were already negotiated, over the telephone.
Leave aside the U.C.C. and common law for a minute and just do a thought exercise.
Once upon a time, a contract was a formal agreement between parties. It required certain standards of execution in order to be enforceable in certain ways. Signatures on paper, for instance. Representation. Notaries. My buying a hotdog has some legal dimensions - but we do not get our expectations down on paper (that my money won't be counterfiet, that the hotdog won't poison me). Also, let me add, copyright was a right to prevent people from making a copy.
We have numerous laws that deal with the common scams of the world, that basically require you to not have fine print tricks, unusual or surprising conditions, to take advantage of unequal representation or basically get a deal through subterfuge (within reason, obviously), to make reasonable efforts to record a deal (i.e. a signature, not a button and a slab of rewriteable media)...
One day an audacious attorney decided to invent a completely fictitious legal procedure - the "end-user licence." It imagines that we live in a world where every exchange of information is actually a formal contractual negotiation with potentially unlimited dimensions. And that these contracts can be foisted on consumers in a surprising and ridiculous way, and impose absurd conditions on them, and can be entered into through completely unconventional, even bizarre, methods of assent.
The state of this on the ground is painfully illustrated by Sony itself in this case - the EULA so fictitious even to them that they did not bother to implement the "Does Not Accept" behavior.
Ask yourself where you think the principles behind EULA end? What can't constitute agreement to a contract? Blinking your eyes? Not saying no? What is a reasonable commercial standard or practice at that point?
But don't take my word for it.
For reference (emphasis mine):
The forceability of an EULA depends on several factors, one of them being the court that the case is heard in. Most courts that have addressed the validity of the shrinkwrap license have found them to be invalid, characterizing them as contracts of adhesion, unconscionable, and/or unacceptable pursuant to the U.C.C. --see, for instance, Step-Saver Data Systems, Inc. v. Wyse Technology (939 F.2d 91), Vault Corp. v. Quaid Software Ltd. (at harvard.edu) and Rich, Mass Market Software and the Shrinkwrap License (23 Colo. Law 1321.17). A minority of courts have determined that the shrinkwrap license is valid and enforceable: see ProCD, Inc. v. Zeidenberg (at findlaw.com), Microsoft v. Harmony Computers (846 F. Supp. 208, 212, E.D.N.Y. 1994), Novell v. Network Trade Center (at harvard.edu), and Arizona Cartridge Remanufacturers Association Inc. v. Lexmark International Inc. may have some bearing as well.
The 7th Circuit and 8th Circuit subscribe to the "license" and "not sold" arguments, while most other circuits do not. In addition, the contracts' enforceability depends on whether the state has passed Uniform Computer Information Transactions Act (UCITA) or Anti-UCITA (UCITA Bomb Shelter) laws. In Anti-UCITA states, the Uniform Commercial Code (UCC) has been amended to either specifically define software as a good (thus making it fall under the UCC), or to disallow contracts which specify that the terms of contract are subject to the laws of a state that's passed UCITA.
Recently, publishers have begun to encrypt their software packages to make it impossible for a user to install the software without agreeing to the license or violating the Digital Millennium Copyright Act (DMCA) and foreign counterparts.
The DMCA specifically provides for reverse engineering of software for interoperability purposes, so there was some controversy as to whether software license clauses which restrict this are enforceable. The case of Blizzard v. BnetD (at eff.org) is an illustration of this controversy.
U.S. courts have shown repeatedly that they aren't prepared to punish businesses properly.
True. But by studying history we can see that the judicial system is acutely aware of it's social context, and (as has happened in the past) if we stop taking it lying down, we will find that the courts can hold even the most powerful men and women accountable once they see the climate for doing so is favorable.
If I think you're stealing my hotdogs, and I break into your house and spy on you to find out, and while I'm there I take piss on your carpet, your solution is not to... not buy my hotdogs anymore?
Fuck no, I go to jail. I'm "moderately" suggesting Sony could skip harsher criminal penalties that would be leveled at non-mega-rich, non-multinational-corporation ordinary people who tried to do what they did, and at least get a proportionate financial penalty.
These people literally have their boot on Sony's throat. This could be a watershed moment in the "IP" war for individual rights. And instead, what do we get?
Sony does not have to undo their vandalism to anyone's computers or provide cash compensation for their victims to do so (although they may have to fix unintentionally created security vulnerabillities)
Future similar DRM schemes are legitimized as long as they are disclosed on the jewel case and in the EULA, and an uninstaller is provided
The role of the EULA in this fiasco is implicitly legitimized (the entire concept of a "EULA," for those few who don't know, is largely an obnoxious legal fiction - sans UCITA, anyway)
Collection of personal information in media products is legitimzed ("only for purposes of providing enhanced functionality" - LOL!)
This is a love letter to Sony, and a "go ahead" signal to expand "open season on your computer" into the entire market. It is a shocking, audacious outrage, and I have no doubt Sony et al would love to see it made the basis for future statute.
Ladies and gentlemen, this is it. We have to immediately mobilize and derail this "settlement."
This is not settled until Sony repairs each vandalized computer... and then we can talk punitive damages...
My goodness. Your degree of obnoxiousness and audacity is simply stunning.
I will keep it very short and simple since reading the things (and people) you snipe at seems to fatigue you. Will bullet points do?
You brought up bias and vitriol. You talk about who should be labeled troll and who shouldn't. But then you don't actually want to talk about it once you realize you'll have to (gasp) support your vacant insults with argument. OK, fine, you lose.
You continue to not really see (or admit to seeing) the problems with a VM platform where app developers are encouraged to misuse native interop. I've made this abundantly clear with references etc. but you have now conclusively demonstrated your impenetrability on the subject. Go ahead, the next VM segfault is on me.
You claimed that MS does not "promote" the practice, and now two references into proving that they do, you have not apologized or even ceased repeating yourself. You're so busted it's not funny.
There are many, many, many more jobs for Java developers than.NET developers - a "small" consideration given the parent article. This seems to bug both you and njyoder; he humorously asks for "evidence" and you have a goofy attempt to change the subject with nitpicking about "incidental-ness" and specious (and unsourced) rambling about salaries or desirability. You could go ahead and have the balls to bluntly claim what you're obviously dreaming, which is that "soon" there will be more.NET jobs than Java jobs, but you didn't. Too bad.
You claim "maybe half" my arguments were "straw men." Which half?
You jumped in to defend the goofiest troll I met in the whole discussion, but you don't actually have to defend him. Don't worry about it, you can't defend yourself.
If the rest of your comment weren't so vitriol-filled and pointless
Let's talk about what makes a good troll.
Lots of people make mistakes, especially me. But over the years I've noticed that a few people don't just make mistakes. Rather, they make a post or series of posts that is beyond simple error - it's outrageous and silly. Like njoyder here. Practically every sentence he wrote was wrong or deceptive in some way. Add in childish and obnoxious rhetoric and (forgive me for correctly predicting him) a complete refusal to bend to facts, evidence, or subsequent rational discussion, and you have... well, a troll in my opinion anyway.
The label isn't important. The point is that he's not only wildly wrong, but nothing productive is going to come from talking to him, either.
Now take you, for example. You passed over that outrageous post, and your criticism is for me - merely pointing out the errors and responding in a way that is more than justified. You speak of bias, not in the most biased (and frankly ridiculous) post in the whole discussion, but of my corrections to it.
You do not actually rebut most these corrections, and you slyly try to imply you don't need to, even though it's obvious you're not defending almost all of his errors - and we both know this is why you haven't tried.
Now let's look at what you did write.
You say you don't understand my point about the problems with unmanaged code and pervasive native interop. Let me repeat myself, since apparently you simply didn't read my earlier posts: "Thus eliminating the boundaries on the well-defined, well-tested native stack and ruining most of the advantages of a VM while keeping most of its disadvantages." Please let me help you - what part of this are you unable to understand?
And then you dispute that Microsoft promotes the practice.
I point out an MSDN link where Microsoft literally says.NET "promotes" this practice. Your way of arguing it is to say that when they say "promotes" they really don't mean "promotes?"
Humorous.
However, sadly, you have demonstrated ignorance of Microsoft's literature on the subject.
Ironically, even within Microsoft, there is awareness of security, reliability, and performance (see headers in linked doc) issues related to interop. ("Calling unmanaged code presents a major security risk.") ("When you use any type of interop technology, your code might not be as reliable or robust as pure managed code.") ("Every interop call introduces some overhead. Depending on how often these calls occur and the significance of the work happening inside the method implementation, the per-call overhead can range from negligible to very noticeable.") ("It is suggested that, whenever possible, you use.NET Framework functionality instead of calling unmanaged APIs.")... If you were smarter or more knowledgeable I would have expected you to cite this.
Someone inside MS is obviously aware of the issues you claim not to understand. Unfortunately MS contradicts itself in its own literature (references) and, sadly, you are wrong, despite knowing better, they really do promote the nonsensical mixing of VM and native code in a way that almost defeats the purpose of having a VM. For instance, in this "best practices" document, in the section titled "Interoperability vs. Migration":
The first thing to consider in terms of a migration is whether to migrate the code at all. The COM interoperability features of the.NET Framework are very powerful and, in nearly all cases, allow you to continue to use your existing code without migrating it to managed code. As you develop new parts of your application or reuse components of your application from newer managed code applic
In some paragraphs you have an egregious error in almost every sentence.
Sun can do this to an even greater extent, since they control who is allowed to implement VMs.
No, they do not. They control who can call their Java VM's "Java compliant."
Their standards are 100% proprietary and closely controlled.
No, they are not "closely controlled" - they collaborate extensively through the JCP, and indeed much of Java 5 was defined that way. OS developers like the Apache Group are behind many of the new parts of the spec...
They also protect themselves with patents.
Which their license explicitly grants you the use of, when implementing JVMs...
Microsoft actually has open standards
Unlike MS, who has the option of potentially GPL-incompatible RAND licensing for C# and the CLR, and doesn't standardize the rest of.NET APIs at all... what are you smoking, really?
You are basically saying you can take your.NET app to some other server? Or ever will be able to, at some point in the future? Lies this obvious just make you look foolish.
Sun is in a much better position to lock Java down and prevent people from using it.
So as you can see, this is wrong.
Same with C#.
Except all those class not found errors.... Oops, your API didn't come with you... I guess you don't mind rewriting everything?
Sort of like Sun's constantly changing GUI APIs which become very popular then have support for them dropped, right?
What are you smoking? Seriously? No APIs have been dropped yet. They have added new, never removed the old...
Like COBOL and Fortran, right?
I notice you ignored the point about the spec and the standard and the VM. Not surprising.
C#/.NET is also well specified and even more unencumbered.
So you are aware this is a blatant lie, right?
Oh it's OK. Just point me to the other vendor that implements.NET. Not C#, not the CLR..NET... Oh wait, you can't! Bzzzzzzzzzzzzt.
And Sun's VM is not open source
Poor reading comprehension. The source is available. Not the same as open source. As I pointed out, it is not FSF or OSI compliant.
GNU classpath implementations have only recently come to a half-decent level of completeness.
The compiler and VM are done for some time. They are doing the entire API, and that is also pretty far along now. Mono is nowhere near this, and you probably even know it.
Hell, even commercial alternatives to Java's tend to be a pain to set up and suck donkey balls.
I had no problem with IBM's system. Actually I didn't have too much trouble with BEA's either. Perhaps you're just bad at it?
What's that thing called? Oh yeah, evidence. When you make bold claims, you better back them up.
I don't think you would recognize evidence if a worm delivered it to your IIS server's homepage. You've certainly overlooked everything I've provided thus far.
Let's see these numbers then. Evidence.
Duh OK. The fact that you don't already know this, though, is by itself basically proof that you're an ignorant fanboy kid who likes to shoot their mouth off without having any idea what you're saying... If you did, you would try to change the subject rather than dig your hole this much deeper: Reference 1.Reference 2.
Unsafe code mixing is RARE and requires you specifically telling the compiler to allow it. But hey, don't let things like facts get in your way.
The same thing that happens when you want to leave any other development platform in existence.
Wow. You really don't understand this?
If the platform is based on a standard (rather than just parts of it), then you can leave without much penalty to anyone else who implements the same standard.
I have very little desire or need to be migrating.
Trust me, it happens.
Perfect example. We use a Java servlet container. One day we discover it has a bug. We go to the vendor. The vendor refusese to fix the bug. We switch to another container. Presto. The bug is gone.
Imagine, too, that if there is only one vendor and you are locked into them, they no longer care so much about fixing bugs or keeping you happy at all, because they have a monopoly, and they act like it. And I've had exactly this problem with MS. I catch IIS blowing up? I debug it with MS support, who actually talk to me because the client is fortune 50, and what do they say when we catch them red-handed? "Sorry, we know about that bug. It's marked WONTFIX."
Imagine never having to hear that kind of thing again, because now you have a market instead of a monopoly. That's what standards do. That's what scares MS to death.
accept the miniscule risk that we *may* have to rewrite some code should we choose to migrate.
As you get more experience, you realize this no longer sounds so good when you have 400,000 lines to worry about.
In time, I'd say it's pretty reasonable there will be equal demand sometime in the near future.
Man just listen to yourself. That's a pretty contrived way of admitting that there is greater demand for Java than C#.
And by the way, if you really think C# will equal Java for job demand in the near future, I would take that bet, depending on when you think that is. Within 5 years? 10?
If you are in need of that much performance,
In the enterprise the term is "scalability."
I don't think it would make a significant difference what language you did use -- It would depend on the compiler.
You know, I don't actually see a lot of what you like in.NET that isn't also in Java. Form editors for GUI work? Java has them. Attributes? Java. Reflection? Java. ADO? Java's Hibernate is a great persistence mechanism... Remoting? Java has it. In fact I did some Java to.NET remoting the other day with glue. It took about 5 minutes to get going.
I find Java development tools like Intellij Idea significantly superior to anything available for C#/.NET. I would go so far as to say it basically defines the state of the art in development tools. I've never seen code-as-structured-DB, effortless search and refactoring integrated so completely in anything before. You should seriously check it out. (As it happens the Jetbrains guys have ported some of their refactoring tools to C# - I think the product is called Resharper, worth checking out out as well...)
The vastly greater number of people doing Java development, and its many-year lead in the space have resulted in a rich ecosystem of vendors, open source, and free software projects that are totally unmatched in the.NET world. The result is that there is a lot of great code out there to use (even BSD licensed) and a lot of interesting research going on in the space...
Again, I'm asking for a specific reason why you should or should not believe the hype
I'd put it the other way around. I've laid out massive problems with.NET. What's so special about C# that could overcome them?
the new does not mean throwing away the old completely. That would be a frankly insane design fom MS to contemplate at this stage of it's installed base.
If you want to make a VM that adds all of the associated overhead and headaches... and doesn't throw away the old ways of doing things, so is just as unsafe, then that is basically stupid, as far as I can tell.
You said "practice of mixing VM and non-VM code at every opportunity" which is much more than having documentation on easy ways of interop, it means overuse of the feature, partularly the old "unsafe code" slur. That is not shown at all.
I have indeed shown that MS promotes exactly this bizarre approach to application development - within MSDN and around the documentation for this feature.
Explain it if you can.
Oh that's easy. I don't consider Python to be sufficiently different.
I don't think there's as strong a case, or as evil a plan as you like to think.
You're a trusting soul, considering they're already bankrolling SCO.
How exactly have the mono team managed to break patents despite being aware of the issue, and how does it benefit MS to shut them down?
Simple. Even the standardized portions of the platform, C# and the CLR, are patented and the standards body only requires RAND licensing which may be incompatible with the GPL. MS has conspicuously arranged it this way and refuse to say they won't do so.
In other words... it doesn't look good.
If you can seriously even ask what benefit MS thinks they get from hurting their competitors, free and otherwise, I guess I'll stop here. I don't think you're serious anymore.
Your post here is basically redundant, but I can also see you didn't read, or couldn't understand, the link.
The key is that MS was conspicuously careful that even the standardized parts of.net can be subjected to RAND terms by MS that could lock out free software. Let alone the rest of the platform, which openly locks you in.
Now compare: "If you read the license that you are granted by the Java specifications, you'll find that they give you an unrestricted blanket grant of all the patents Sun has that might be infringed by Java implementations. " -link
Everybody builds a portfolio. But do you love operator overloading so much that you'll go with someone who won't make decent arrangements with the community... And by the way who also finances fun stuff like sco? Or maybe it seems like you've just been confused?
Sun has a program for certifying people who clone their platform. MS wont even promise not to sue people who clone.net.
There is even a cloud over MS' C# and CLR RAND terms...
So basically, you're exactly wrong and you've now as much as admitted it. But hey, no skin off my back. You think the risk is worth it? Go commit some projects to that platform and see what happens.:D
What, pray tell, is encumbering about C#? It's almost exactly like Java.
I don't get it. Why does nobody understand this?
Java is a language, and a runtime, and an API.
The standardized portions of.NET are the language and the runtime.
Notice the critical missing piece?
What do you think happens when you want to leave MS?
I can just picture the post now. "Hey ECMA said it's a standard but strangely when I tried to leave MS I got all these errors about missing classes? I don't understand."
You didn't write an app to add numbers forever without doing input or output. You wrote an actual app that uses the API. And now you can't leave. You are locked in.
What do you think MS does when they've got you locked in? What they always do. What any vendor that gets you locked in does. They bend you over a barrel.
You will be stuck watching Java people migrate from machine to machine, OS to OS, VM to VM, App Server to App Server... taking advantage of actual marketplaces full of innovation and competition... while you stagnate in MS's walled garden.
What numbers are you looking at? In Dallas at least, there is extremely high demand for C#/.NET developers.
I never refuse to provide sources, but I can't believe you have the audacity to ask me this.
Have you even picked up a newspaper?
The picture is abundantly clear... I doubt it's even that different in Dallas (although it's possible I suppose)...
Unsafe code is rarely used throughout the actual framework itself, but when it is, it's primary purpose is performance.
I've already produced references for others to prove Microsoft itself actively promotes the use of interop and unmanaged code.
Of course, people may recognize that it's a bad feature and not use it... Not exactly a badge of honor for.NET though.
I've already made my rather obvious point about why this is bad... now you have the same loss of guarantees and stability of native, with all the overhead of the VM... so this begs the question...
I suppose that they should have bit the bullet and used a slower method, so you could complain about performance instead?...why use the VM?
the runtime can, theoretically, support any language
Theoretically has nothing to do with practicality; if you read me, I am speaking about performance. I have no doubt you can shoehorn a shitty implementation of anything you want onto CLR or the JVM for that matter...
Not surprisingly, people are more interested in optimizing C code.
So you apparently concede the point that CLR is not as flexible in terms of practical support for other languages that significantly different from C/C++/Java as its proponents sometimes claim...?
Which is unfortunate, I've had occasion to want to use Mono, and I'd love to run ASP.NET 2.0 code on a linux box (I still think Apache > IIS).
It comes down to pure, hardboiled obstinancy.
If Microsoft wanted to beat the crap out of Java all they'd need to do would be to put down the patent gun, open up their sources, and let.NET embrace cross platform. They could perhaps out-Java Java.
We both know very well they wont. It's because.NET is not designed to win the language wars or be the best language. It is designed to stop the bleeding from developers breaking out of MS's jail, by providing a new way of locking developers (and their code) into the proprietary Microsoft platform.
...This is just another iteration of the same deception... standardize part of the platform but keep part proprietary (in this case, the APIs) and maybe you can fool some people (like this person) into thinking they're not trapped.
Yes, and if you were paying attention, you would have noticed that the question was about learning C#, not.NET
Zealotry... is pretending you can do the equivalent of standardizing the C language but then making half of/usr/include patented and proprietary...
There is a reason that K&R is as much concerned with functions as it is with syntax... and there's a reason most of what you need to know as a C programmer isn't even in K&R, since what you spend the most time dealing with are your APIs...
You think you can learn C# without learning.NET? Well, it's true, Mono gives you an alternative set of APIs... Until MS sues them and (according to the SCO model) you...
It's rather obvious, since any application of any consequence is written against it.
And to think, people complain about portability on Java, where the platform actually is standardized...
But I guess that's your point here - to fool people into thinking they're not being locked into a Microsoft proprietary system when they write against.NET? By willfully obfuscating the difference between C#/CLR and the.NET platform APIs they will actually use to write their apps?
Mono will either clone.NET to the point where they are vulnerable (and patent law makes no special provision for interoperability that I'm aware of), or they won't. Have you seen their patent portfolio? It's not a casual operation. Why take this risk?
Furthermore, permitting interoperability is an exception in the current patent and DMCA regime.
Even just looking at the DMCA, it's carefully crafted to appear to allow interoperability, whil always providing the pretext for an expensive civil, if not criminal, proceeding every time anyone interoperates anyway... which is exactly what happens almost every time... As you well know, unless you don't follow the news.
If Java "standardized" the langauge and the VM, but not the API, then it would be equivalent to.NET. Fortunately they made their whole platform a standard, unlike MS.
How does using Mono and Gnome lock me into Microsoft?
That is C#, not.NET.
Mono has claimed they want to be.NET compatible. I don't think they ever can, because unlike the language, the platform is proprietary and heavily patented.
So as I say, they might someday be.NET compatible, but I doubt it. Or you might end up writing "dirty.NET" - C# in Mono... which is fun until MS sues you.
I thought this would be clear already from what I wrote, but I figure I'll reiterate anyway, just in case...
Sun's J2SE implementation has caused me numerous problems,
Yeah, any VM, from any vendor has bugs... fortunately...
there is no sensible alternative
I can't believe you'd have the audacity or the ignorance to say this... There are a number of alternatives from FS/OS to IBM and BEA...
Sun's willingness to fix bugs has been poor,
Can't argue with that, I've had some nasty bugs that hurt me in the VM go unfixed for years too... but...
and since it's closed source
Wrong...
there is no way of fixing it.
Wrong.
Switch to another VM, or fix it yourself.
And don't cry about how things aren't really compatible from one VM to another, since A) it's not often as bad as some people say, and B) I think you're talking about.NET as an alternative...
Slashdot Mirror
You'll note that I'm not responding to some of your bullet points...
.NET despite not implementing and encouraging native interop the way .NET does - already categorically proving you wrong, but let's humor you) works with legacy code the way most distinct systems do: through network sockets (using any protocol you like), database APIs, file APIs, and at the outer limits, rarely, the Runtime APIs... which invoke external programs in the host in a separate process, without exposing them to the VM's address space.
/. all you need to bring is a bad idea and an obnoxious attitude, and you get a free education. What a country.
.NET is not that it allows the use of unmanaged code, but that, in your mind, the documentation says it's OK to do that.
.NET and realize they had a marketing campaign that sold the platform with this "feature," or you're not really that familiar with .NET...
.NET, by all means, become an .NET developer and damn the consequences. But... if you're asking, hey, I don't have a preference... should I learn .NET or Java? Don't say ".NET, cause those fewer jobs you can get might pay better, (when you can
It's quite obvious you don't respond because you don't feel like admitting your mistakes.
If developers will not embrace a platform that does not allow them to use legacy code, they're not going to embrace a platform that doesn't allow them to use legacy code.
Of course Java allows them to.
Since you haven't answered my question as to what you'd propose instead
The question is an awkward since it's a very basic one, and out of incredulity I hesitated to embarass you by answering directly. Almost every single Java application converses with non-Java applications. Since you persist, Java (which is vastly more widely adopted than
The bare fact is that you have it backwards. Why write anything in Java in the first place? There are many tradeoffs to the VM, as you (might?) know. Some of the big reasons to go that way are the guarantees of safety/reliability and security the VM gives you. If you mix unsafe code into the VM all those upsides disappear, but you keep all of the downsides plus you pay performance penalties and there are other problems as well, these are just the big issues. And this is where I see I am repeating myself yet again... honestly if you haven't gotten it by now, I'm not sure why I'm still trying, but...
Imagine, on
Yet you don't ever say that developers shouldn't be allowed to do this, exactly.
I don't ever say it, period.
your problem with
It's more than that "it's OK." Users are bluntly encouraged to misuse the feature. It's "promoted" as a long-term solution.
I've not only shown that MS promotes and encourages interop misuse, but I've illustrated (quite vividly) how even they understand the problem, and their published best practices are contradicted by their own MSDN documents.
Microsoft promotes this practice for two reasons; first because they know you can win over some less experienced or skilled developers with sugary misfeatures like this ("look how easy and fun it is to do this stupid thing! those java guys never let me have any fun..."), and second because they know encouraging pervasive native interop locks code into their platform.
My first link shows they promote it, my second does too, and there is even more out there, and you either know it already, because you're familiar with
I don't believe I ever wrote "incidental-ness."
Of course you didn't. I hope you take my meaning, though?
yet I was recently offered a relatively lucrative position doing OCaml precisely because I had OCaml experience, unlike most other applicants
So your theory is, don't learn what's in demand. Learn something that's not.
Got it.
I mean, if you really love
All good points. Thank you very much! You're certainly correct in that those cases are not slam-dunks against EULAs themselves - each came in its own context. They're hopefully useful for setting a tone, and overall I hope the point is nonetheless made - the EULA is not some bedrock legal principle handed down from Thomas Jefferson. It's a wacky new thing someone threw against the wall to see if it would stick. It's caught on in certain circles but by no means does it get the treatment in court that its haughty and forbidding language might suggest to a layman.
I still have some serious questions about your conclusions; I hope you can forgive my persistence.
1) Step-Saver notwithstanding, fitness/implied warranty don't seem to require a phone conversation or other existing deal to be established when I go into a store and buy something like a video game or a word processor - certainly not to the point where an officious piece of short fiction written inside the box could override it let alone if....
2) The "click-wrap" license can't even be read until after you purchase and open the merchandise, and...
3) There is no way to tell if the user assented to it or not, after the fact. I know what you're thinking when I say this, and it's even worse than you think. It's ultimately reducible to the "paperless voting machine" conundrum. I say I didn't agree, the other party says I did, and the only way of determining it is to query a hard drive...
4) Not to mention that almost no clickwrap code even records a decision explicitly... that's because everyone knows its a joke, even the people who program it...
5) To even make the blanket statement that "a click-wrap agreement will be enforceable" seems rather odd, since let's be frank, it entirely depends on what's in it, and I think we can agree that its degree of enforceability depends quite substantially on the intersection between what it is attempting to enforce (usually the legal equivalent of a consturction worker's sex fantasy) and its credibility as a formal, verifiable binding agreement that all parties have entered into with good representation and fully informed consent (virtually nil by conventional standards).
7) Leaving aside what is, think about what should be. Do you really want to live in a world where every exchange of data is a legal negotiation of unlimited dimensions? Is that even really feasible, when taken to its logical conclusion? Isn't this just another "software patent-esque" legal doctine, where it only appears to work until everyone stops ignoring it and actually takes it seriously?
8) Have we really admitted the death of the UCC? Are we ready to abandon common law? By saying a 20 page legal document in a tiny window that 99% of the U.S. isn't qualified to read (and to retain an attorney to read it for you is vastly more expensive than the price of the commodity it "governs") and therefore doesn't read... is binding anyway... you have effectively given carte blanche to those who write the documents, to do anything they wish. Well, I've said "anything," but I must ask: do you imagine there are limits on the practice at all? If so, what? Do you think reasonable expectations and commercial or industry standards play any role at all, anymore? Does each sale of a piece of music really start at the tabula rasa of a new contract, between a team of 30 world-class corporate lawyers in New York and an 11 year old in Tulsa who just wanted to listen to Eminem?
It's really worth looking at a specific case like Step-Saver Data Systems, Inc. v. Wyse Technology. Again, from the reference:
Step-Saver Data Systems, Inc. v. Wyse Technology, 939 F.2d 91 (3rd Cir. 1991) was case in which the legality and history of computer EULAs was explored. The court noted, "When these form licenses were first developed for software, it was, in large part, to avoid the federal copyright law first sale doctrine" thus the intent of EULAs after 1990 were to preempt federal statutes using contract law and that they serve no purpose besides attempts to preempt consumer rights in other statutes.
In this case, the U.S. Court of Appeals for the Third Circuit held that a EULA disclaimer waiving all express and implied warranties, printed on the outside of the box, was not binding. Step-Saver repeatedly bought Multilink Advanced, an allegedly MS-DOS compatible operating system, from The Software Link (TSL). On each box was a shrink wrap license disclaimer; "software sold AS IS, without warranty; TSL disclaims all express and implied warranties; if you don't agree to this disclaimer return the product, unopened, to TSL for a refund.". Step-Saver sued TSL, claiming that Multilink Advanced was not MS-DOS compatible. The court ruled that the EULA was not enforceable and that the sole reason of the EULA after 1990 was to preempt federal statutory and constitional laws. This matter, however, involved a negotiated transaction between two businesses, and the licenses varied terms between the shrink wrap license and the sale terms which were already negotiated, over the telephone.
I wholeheartedly disagree.
Leave aside the U.C.C. and common law for a minute and just do a thought exercise.
Once upon a time, a contract was a formal agreement between parties. It required certain standards of execution in order to be enforceable in certain ways. Signatures on paper, for instance. Representation. Notaries. My buying a hotdog has some legal dimensions - but we do not get our expectations down on paper (that my money won't be counterfiet, that the hotdog won't poison me). Also, let me add, copyright was a right to prevent people from making a copy.
We have numerous laws that deal with the common scams of the world, that basically require you to not have fine print tricks, unusual or surprising conditions, to take advantage of unequal representation or basically get a deal through subterfuge (within reason, obviously), to make reasonable efforts to record a deal (i.e. a signature, not a button and a slab of rewriteable media)...
One day an audacious attorney decided to invent a completely fictitious legal procedure - the "end-user licence." It imagines that we live in a world where every exchange of information is actually a formal contractual negotiation with potentially unlimited dimensions. And that these contracts can be foisted on consumers in a surprising and ridiculous way, and impose absurd conditions on them, and can be entered into through completely unconventional, even bizarre, methods of assent.
The state of this on the ground is painfully illustrated by Sony itself in this case - the EULA so fictitious even to them that they did not bother to implement the "Does Not Accept" behavior.
Ask yourself where you think the principles behind EULA end? What can't constitute agreement to a contract? Blinking your eyes? Not saying no? What is a reasonable commercial standard or practice at that point?
But don't take my word for it.
For reference (emphasis mine):
The forceability of an EULA depends on several factors, one of them being the court that the case is heard in. Most courts that have addressed the validity of the shrinkwrap license have found them to be invalid, characterizing them as contracts of adhesion, unconscionable, and/or unacceptable pursuant to the U.C.C. --see, for instance, Step-Saver Data Systems, Inc. v. Wyse Technology (939 F.2d 91), Vault Corp. v. Quaid Software Ltd. (at harvard.edu) and Rich, Mass Market Software and the Shrinkwrap License (23 Colo. Law 1321.17). A minority of courts have determined that the shrinkwrap license is valid and enforceable: see ProCD, Inc. v. Zeidenberg (at findlaw.com), Microsoft v. Harmony Computers (846 F. Supp. 208, 212, E.D.N.Y. 1994), Novell v. Network Trade Center (at harvard.edu), and Arizona Cartridge Remanufacturers Association Inc. v. Lexmark International Inc. may have some bearing as well.
The 7th Circuit and 8th Circuit subscribe to the "license" and "not sold" arguments, while most other circuits do not. In addition, the contracts' enforceability depends on whether the state has passed Uniform Computer Information Transactions Act (UCITA) or Anti-UCITA (UCITA Bomb Shelter) laws. In Anti-UCITA states, the Uniform Commercial Code (UCC) has been amended to either specifically define software as a good (thus making it fall under the UCC), or to disallow contracts which specify that the terms of contract are subject to the laws of a state that's passed UCITA.
Recently, publishers have begun to encrypt their software packages to make it impossible for a user to install the software without agreeing to the license or violating the Digital Millennium Copyright Act (DMCA) and foreign counterparts.
The DMCA specifically provides for reverse engineering of software for interoperability purposes, so there was some controversy as to whether software license clauses which restrict this are enforceable. The case of Blizzard v. BnetD (at eff.org) is an illustration of this controversy.
-Wikipedia
U.S. courts have shown repeatedly that they aren't prepared to punish businesses properly.
True. But by studying history we can see that the judicial system is acutely aware of it's social context, and (as has happened in the past) if we stop taking it lying down, we will find that the courts can hold even the most powerful men and women accountable once they see the climate for doing so is favorable.
I'm a hotdog vendor.
If I think you're stealing my hotdogs, and I break into your house and spy on you to find out, and while I'm there I take piss on your carpet, your solution is not to... not buy my hotdogs anymore?
Fuck no, I go to jail. I'm "moderately" suggesting Sony could skip harsher criminal penalties that would be leveled at non-mega-rich, non-multinational-corporation ordinary people who tried to do what they did, and at least get a proportionate financial penalty.
entire concept of a "EULA," for those few who don't know, is largely an obnoxious legal fiction - sans UCITA, anyway)
This is a love letter to Sony, and a "go ahead" signal to expand "open season on your computer" into the entire market. It is a shocking, audacious outrage, and I have no doubt Sony et al would love to see it made the basis for future statute.
Ladies and gentlemen, this is it. We have to immediately mobilize and derail this "settlement."
This is not settled until Sony repairs each vandalized computer... and then we can talk punitive damages...
I will keep it very short and simple since reading the things (and people) you snipe at seems to fatigue you. Will bullet points do?
What a great, succinct way to put it.
If the rest of your comment weren't so vitriol-filled and pointless
.NET "promotes" this practice. Your way of arguing it is to say that when they say "promotes" they really don't mean "promotes?"
.NET Framework functionality instead of calling unmanaged APIs.")... If you were smarter or more knowledgeable I would have expected you to cite this.
.NET Framework are very powerful and, in nearly all cases, allow you to continue to use your existing code without migrating it to managed code. As you develop new parts of your application or reuse components of your application from newer managed code applic
Let's talk about what makes a good troll.
Lots of people make mistakes, especially me. But over the years I've noticed that a few people don't just make mistakes. Rather, they make a post or series of posts that is beyond simple error - it's outrageous and silly. Like njoyder here. Practically every sentence he wrote was wrong or deceptive in some way. Add in childish and obnoxious rhetoric and (forgive me for correctly predicting him) a complete refusal to bend to facts, evidence, or subsequent rational discussion, and you have... well, a troll in my opinion anyway.
The label isn't important. The point is that he's not only wildly wrong, but nothing productive is going to come from talking to him, either.
Now take you, for example. You passed over that outrageous post, and your criticism is for me - merely pointing out the errors and responding in a way that is more than justified. You speak of bias, not in the most biased (and frankly ridiculous) post in the whole discussion, but of my corrections to it.
You do not actually rebut most these corrections, and you slyly try to imply you don't need to, even though it's obvious you're not defending almost all of his errors - and we both know this is why you haven't tried.
Now let's look at what you did write.
You say you don't understand my point about the problems with unmanaged code and pervasive native interop. Let me repeat myself, since apparently you simply didn't read my earlier posts: "Thus eliminating the boundaries on the well-defined, well-tested native stack and ruining most of the advantages of a VM while keeping most of its disadvantages." Please let me help you - what part of this are you unable to understand?
And then you dispute that Microsoft promotes the practice.
I point out an MSDN link where Microsoft literally says
Humorous.
However, sadly, you have demonstrated ignorance of Microsoft's literature on the subject.
Ironically, even within Microsoft, there is awareness of security, reliability, and performance (see headers in linked doc) issues related to interop. ("Calling unmanaged code presents a major security risk.") ("When you use any type of interop technology, your code might not be as reliable or robust as pure managed code.") ("Every interop call introduces some overhead. Depending on how often these calls occur and the significance of the work happening inside the method implementation, the per-call overhead can range from negligible to very noticeable.") ("It is suggested that, whenever possible, you use
Someone inside MS is obviously aware of the issues you claim not to understand. Unfortunately MS contradicts itself in its own literature (references) and, sadly, you are wrong, despite knowing better, they really do promote the nonsensical mixing of VM and native code in a way that almost defeats the purpose of having a VM. For instance, in this "best practices" document, in the section titled "Interoperability vs. Migration":
The first thing to consider in terms of a migration is whether to migrate the code at all. The COM interoperability features of the
Wow.
.NET APIs at all... what are you smoking, really?
.NET app to some other server? Or ever will be able to, at some point in the future? Lies this obvious just make you look foolish.
.NET. Not C#, not the CLR. .NET... Oh wait, you can't! Bzzzzzzzzzzzzt.
I think you win an award.
In some paragraphs you have an egregious error in almost every sentence.
Sun can do this to an even greater extent, since they control who is allowed to implement VMs.
No, they do not. They control who can call their Java VM's "Java compliant."
Their standards are 100% proprietary and closely controlled.
No, they are not "closely controlled" - they collaborate extensively through the JCP, and indeed much of Java 5 was defined that way. OS developers like the Apache Group are behind many of the new parts of the spec...
They also protect themselves with patents.
Which their license explicitly grants you the use of, when implementing JVMs...
Microsoft actually has open standards
Unlike MS, who has the option of potentially GPL-incompatible RAND licensing for C# and the CLR, and doesn't standardize the rest of
You are basically saying you can take your
Sun is in a much better position to lock Java down and prevent people from using it.
So as you can see, this is wrong.
Same with C#.
Except all those class not found errors.... Oops, your API didn't come with you... I guess you don't mind rewriting everything?
Sort of like Sun's constantly changing GUI APIs which become very popular then have support for them dropped, right?
What are you smoking? Seriously? No APIs have been dropped yet. They have added new, never removed the old...
Like COBOL and Fortran, right?
I notice you ignored the point about the spec and the standard and the VM. Not surprising.
C#/.NET is also well specified and even more unencumbered.
So you are aware this is a blatant lie, right?
Oh it's OK. Just point me to the other vendor that implements
And Sun's VM is not open source
Poor reading comprehension. The source is available. Not the same as open source. As I pointed out, it is not FSF or OSI compliant.
GNU classpath implementations have only recently come to a half-decent level of completeness.
The compiler and VM are done for some time. They are doing the entire API, and that is also pretty far along now. Mono is nowhere near this, and you probably even know it.
Hell, even commercial alternatives to Java's tend to be a pain to set up and suck donkey balls.
I had no problem with IBM's system. Actually I didn't have too much trouble with BEA's either. Perhaps you're just bad at it?
What's that thing called? Oh yeah, evidence. When you make bold claims, you better back them up.
I don't think you would recognize evidence if a worm delivered it to your IIS server's homepage. You've certainly overlooked everything I've provided thus far.
Let's see these numbers then. Evidence.
Duh OK. The fact that you don't already know this, though, is by itself basically proof that you're an ignorant fanboy kid who likes to shoot their mouth off without having any idea what you're saying... If you did, you would try to change the subject rather than dig your hole this much deeper: Reference 1. Reference 2.
Unsafe code mixing is RARE and requires you specifically telling the compiler to allow it. But hey, don't let things like facts get in your way.
You say "RARE" and make a childish insult. However I point to Microsoft promoting the practice
The same thing that happens when you want to leave any other development platform in existence.
.NET that isn't also in Java. Form editors for GUI work? Java has them. Attributes? Java. Reflection? Java. ADO? Java's Hibernate is a great persistence mechanism... Remoting? Java has it. In fact I did some Java to .NET remoting the other day with glue. It took about 5 minutes to get going.
.NET world. The result is that there is a lot of great code out there to use (even BSD licensed) and a lot of interesting research going on in the space...
Wow. You really don't understand this?
If the platform is based on a standard (rather than just parts of it), then you can leave without much penalty to anyone else who implements the same standard.
I have very little desire or need to be migrating.
Trust me, it happens.
Perfect example. We use a Java servlet container. One day we discover it has a bug. We go to the vendor. The vendor refusese to fix the bug. We switch to another container. Presto. The bug is gone.
Imagine, too, that if there is only one vendor and you are locked into them, they no longer care so much about fixing bugs or keeping you happy at all, because they have a monopoly, and they act like it. And I've had exactly this problem with MS. I catch IIS blowing up? I debug it with MS support, who actually talk to me because the client is fortune 50, and what do they say when we catch them red-handed? "Sorry, we know about that bug. It's marked WONTFIX."
Imagine never having to hear that kind of thing again, because now you have a market instead of a monopoly. That's what standards do. That's what scares MS to death.
accept the miniscule risk that we *may* have to rewrite some code should we choose to migrate.
As you get more experience, you realize this no longer sounds so good when you have 400,000 lines to worry about.
In time, I'd say it's pretty reasonable there will be equal demand sometime in the near future.
Man just listen to yourself. That's a pretty contrived way of admitting that there is greater demand for Java than C#.
And by the way, if you really think C# will equal Java for job demand in the near future, I would take that bet, depending on when you think that is. Within 5 years? 10?
If you are in need of that much performance,
In the enterprise the term is "scalability."
I don't think it would make a significant difference what language you did use -- It would depend on the compiler.
Unfortunately this isn't actually true. The topic has been covered extensively.
You know, I don't actually see a lot of what you like in
I find Java development tools like Intellij Idea significantly superior to anything available for C#/.NET. I would go so far as to say it basically defines the state of the art in development tools. I've never seen code-as-structured-DB, effortless search and refactoring integrated so completely in anything before. You should seriously check it out. (As it happens the Jetbrains guys have ported some of their refactoring tools to C# - I think the product is called Resharper, worth checking out out as well...)
The vastly greater number of people doing Java development, and its many-year lead in the space have resulted in a rich ecosystem of vendors, open source, and free software projects that are totally unmatched in the
Again, I'm asking for a specific reason why you should or should not believe the hype
.NET. What's so special about C# that could overcome them?
I'd put it the other way around. I've laid out massive problems with
the new does not mean throwing away the old completely. That would be a frankly insane design fom MS to contemplate at this stage of it's installed base.
If you want to make a VM that adds all of the associated overhead and headaches... and doesn't throw away the old ways of doing things, so is just as unsafe, then that is basically stupid, as far as I can tell.
You said "practice of mixing VM and non-VM code at every opportunity" which is much more than having documentation on easy ways of interop, it means overuse of the feature, partularly the old "unsafe code" slur. That is not shown at all.
I have indeed shown that MS promotes exactly this bizarre approach to application development - within MSDN and around the documentation for this feature.
Explain it if you can.
Oh that's easy. I don't consider Python to be sufficiently different.
I don't think there's as strong a case, or as evil a plan as you like to think.
You're a trusting soul, considering they're already bankrolling SCO.
How exactly have the mono team managed to break patents despite being aware of the issue, and how does it benefit MS to shut them down?
Simple. Even the standardized portions of the platform, C# and the CLR, are patented and the standards body only requires RAND licensing which may be incompatible with the GPL. MS has conspicuously arranged it this way and refuse to say they won't do so.
In other words... it doesn't look good.
If you can seriously even ask what benefit MS thinks they get from hurting their competitors, free and otherwise, I guess I'll stop here. I don't think you're serious anymore.
Your post here is basically redundant, but I can also see you didn't read, or couldn't understand, the link.
.net can be subjected to RAND terms by MS that could lock out free software. Let alone the rest of the platform, which openly locks you in.
The key is that MS was conspicuously careful that even the standardized parts of
Now compare: "If you read the license that you are granted by the Java specifications, you'll find that they give you an unrestricted blanket grant of all the patents Sun has that might be infringed by Java implementations. " -link
Everybody builds a portfolio. But do you love operator overloading so much that you'll go with someone who won't make decent arrangements with the community... And by the way who also finances fun stuff like sco? Or maybe it seems like you've just been confused?
So where do you get far worse?
.net.
:D
Sun has a program for certifying people who clone their platform. MS wont even promise not to sue people who clone
There is even a cloud over MS' C# and CLR RAND terms...
So basically, you're exactly wrong and you've now as much as admitted it. But hey, no skin off my back. You think the risk is worth it? Go commit some projects to that platform and see what happens.
So what?
That's so what.
You have to read the fine print.
The fools are people like you; Java is far worse than even .NET in terms of patents.
So... now that you've dropped this bombshell...
Have anything to back it up?
Or are you just "spreading FUD?"
You are completely off your rocker.
You may have hidden under a rock for the whole discussion, but this is a good summary, if you want to catch up...
You're actually pretty funny, considering it's actually MS who spreads FUD... with things like the SCO case.
But if you think C#'s meager sugar is worth the risk... go for it. I'll find it funny to see how it turns out...
Microsoft would be absolutely insane to even think about dropping .NET
.NET are the language and the runtime.
.NET though.
...why use the VM?
.NET embrace cross platform. They could perhaps out-Java Java.
.NET is not designed to win the language wars or be the best language. It is designed to stop the bleeding from developers breaking out of MS's jail, by providing a new way of locking developers (and their code) into the proprietary Microsoft platform.
Just like they'd be crazy to break backwards compatibility with VB?
What, pray tell, is encumbering about C#? It's almost exactly like Java.
I don't get it. Why does nobody understand this?
Java is a language, and a runtime, and an API.
The standardized portions of
Notice the critical missing piece?
What do you think happens when you want to leave MS?
I can just picture the post now. "Hey ECMA said it's a standard but strangely when I tried to leave MS I got all these errors about missing classes? I don't understand."
You didn't write an app to add numbers forever without doing input or output. You wrote an actual app that uses the API. And now you can't leave. You are locked in.
What do you think MS does when they've got you locked in? What they always do. What any vendor that gets you locked in does. They bend you over a barrel.
You will be stuck watching Java people migrate from machine to machine, OS to OS, VM to VM, App Server to App Server... taking advantage of actual marketplaces full of innovation and competition... while you stagnate in MS's walled garden.
What numbers are you looking at? In Dallas at least, there is extremely high demand for C#/.NET developers.
I never refuse to provide sources, but I can't believe you have the audacity to ask me this.
Have you even picked up a newspaper?
The picture is abundantly clear... I doubt it's even that different in Dallas (although it's possible I suppose)...
(Reference 1) (Reference 2)
Unsafe code is rarely used throughout the actual framework itself, but when it is, it's primary purpose is performance.
I've already produced references for others to prove Microsoft itself actively promotes the use of interop and unmanaged code.
Of course, people may recognize that it's a bad feature and not use it... Not exactly a badge of honor for
I've already made my rather obvious point about why this is bad... now you have the same loss of guarantees and stability of native, with all the overhead of the VM... so this begs the question...
I suppose that they should have bit the bullet and used a slower method, so you could complain about performance instead?
the runtime can, theoretically, support any language
Theoretically has nothing to do with practicality; if you read me, I am speaking about performance. I have no doubt you can shoehorn a shitty implementation of anything you want onto CLR or the JVM for that matter...
Not surprisingly, people are more interested in optimizing C code.
So you apparently concede the point that CLR is not as flexible in terms of practical support for other languages that significantly different from C/C++/Java as its proponents sometimes claim...?
Which is unfortunate, I've had occasion to want to use Mono, and I'd love to run ASP.NET 2.0 code on a linux box (I still think Apache > IIS).
It comes down to pure, hardboiled obstinancy.
If Microsoft wanted to beat the crap out of Java all they'd need to do would be to put down the patent gun, open up their sources, and let
We both know very well they wont. It's because
You realize this comment is both senseless, wrong, and deceptive, right?
...This is just another iteration of the same deception... standardize part of the platform but keep part proprietary (in this case, the APIs) and maybe you can fool some people (like this person) into thinking they're not trapped.
Yes, and if you were paying attention, you would have noticed that the question was about learning C#, not .NET
/usr/include patented and proprietary...
.NET? Well, it's true, Mono gives you an alternative set of APIs... Until MS sues them and (according to the SCO model) you...
Zealotry... is pretending you can do the equivalent of standardizing the C language but then making half of
There is a reason that K&R is as much concerned with functions as it is with syntax... and there's a reason most of what you need to know as a C programmer isn't even in K&R, since what you spend the most time dealing with are your APIs...
You think you can learn C# without learning
You don't have to standardize the API.
.NET? By willfully obfuscating the difference between C#/CLR and the .NET platform APIs they will actually use to write their apps?
.NET to the point where they are vulnerable (and patent law makes no special provision for interoperability that I'm aware of), or they won't. Have you seen their patent portfolio? It's not a casual operation. Why take this risk?
Yes, you do.
It's rather obvious, since any application of any consequence is written against it.
And to think, people complain about portability on Java, where the platform actually is standardized...
But I guess that's your point here - to fool people into thinking they're not being locked into a Microsoft proprietary system when they write against
Mono will either clone
Furthermore, permitting interoperability is an exception in the current patent and DMCA regime.
Even just looking at the DMCA, it's carefully crafted to appear to allow interoperability, whil always providing the pretext for an expensive civil, if not criminal, proceeding every time anyone interoperates anyway... which is exactly what happens almost every time... As you well know, unless you don't follow the news.
If Java "standardized" the langauge and the VM, but not the API, then it would be equivalent to .NET. Fortunately they made their whole platform a standard, unlike MS.
Why try to confuse people about it?
How does using Mono and Gnome lock me into Microsoft?
.NET.
.NET compatible. I don't think they ever can, because unlike the language, the platform is proprietary and heavily patented.
.NET compatible, but I doubt it. Or you might end up writing "dirty .NET" - C# in Mono... which is fun until MS sues you.
.NET as an alternative...
That is C#, not
Mono has claimed they want to be
So as I say, they might someday be
I thought this would be clear already from what I wrote, but I figure I'll reiterate anyway, just in case...
Sun's J2SE implementation has caused me numerous problems,
Yeah, any VM, from any vendor has bugs... fortunately...
there is no sensible alternative
I can't believe you'd have the audacity or the ignorance to say this... There are a number of alternatives from FS/OS to IBM and BEA...
Sun's willingness to fix bugs has been poor,
Can't argue with that, I've had some nasty bugs that hurt me in the VM go unfixed for years too... but...
and since it's closed source
Wrong...
there is no way of fixing it.
Wrong.
Switch to another VM, or fix it yourself.
And don't cry about how things aren't really compatible from one VM to another, since A) it's not often as bad as some people say, and B) I think you're talking about