Hacker News new | past | comments | ask | show | jobs | submit login

And you only need to recompile when the software can't run directly

You've come around to actually making my argument! :)

As I said, as long as I have my installer for .Net, the software I write for that platform will still work.




> You've come around to actually making my argument! :)

Not even close. Unless you can recompile your .NET installer for a new computer architecture. If you can't, it's as dead as my Apple II word processor.

I can run that Python code on SPARC box I have. Can you do the same with your .net installer?

Again, since you seem not to understand, there is a difference between being able to install your jurassic .net framework on a current version of Windows and having its source code, something that would allow you not only to run it on current computers but also on almost any future computer that may possibly exist. Forever.


there is a difference between being able to install your jurassic .net framework on a current version of Windows and having its source code, something that would allow you not only to run it on current computers but also on almost any future computer that may possibly exist. Forever.

You're simply assuming that someone will continue to port Python 2 ad infinitum. Granted there's no reason to suspect that they will not (Except that at some point, Python 3 really catches on, and decades down the road people stop caring about 2. At that point you could port an interpreter -- but you won't, which is my point).

But there's also no reason to expect that I'll be unable to run my MS-based code. I mean, MS has ensured compatibility for, say, ancient Visual Basic code for forever. Real world experience shows us that there's no reason to be concerned about future compatibility. You're right that in principle it might be left behind, but experience shows us that this doesn't happen. The code I wrote 16 years ago for Win95 (and much earlier, for that matter) still runs.

That's the philosophical argument. The practical argument is Mono. It's open source, so anything good you can say about FOSS applies equally to .Net. It has the backing of both open source and corporate muscle. (although I have to grant that Mono doesn't cover 100% of the platform, I can plan my system to stay within those bounds)

Why is it that you assume that MS will dump backwards compatibility, but you're also willing to assume that someone will be interested in keeping and old FOSS platform alive (and that the tools to do so will still be functional)? It seems that in this argument, you want to have your cake and eat it, too.


In the specific case of Mono, you are right and I would advise you to always plan to stay within its limits to ensure you have a runtime that you can maintain yourself if you really need to. As for future compatibility, remember, companies come and go and Microsoft won't be around forever. What did you do with your dBase II code and your Lotus 123 spreadsheets? In 100 years, Mono may be all that's left from Microsoft.

OTOH, I still find Mono a bit risky: I think Microsoft is capable of finding a way to kill it if it becomes too popular. They can't avoid it. It's their competitive nature.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: