So, you're saying that Apple software is not proprietary except for the millions of lines of code that happen to be proprietary for no other reason than that Apple likes to lock people into their platform. Seems like we are in agreement.
but anyone can write Mac apps with just gcc / gdb and a bash shell [...] just run X and X apps,
So, you're saying that if I want to use non-proprietary technologies, the Macintosh gives me the option of using it as a UNIX workstation that is less capable than what Sun shipped 15 years ago. You are absolutely right: I can do that. I just can't figure out any reason why I would want to.
The only reason to buy and use a Mac is the proprietary technologies Apple adds. That's not what I'm saying, it's what Apple is saying.
Saying that people can't legally copy DVDs is just as much of a lie by that standard, because they can copy some DVDs.
Stop the semantic bullshitting. We are talking about whether you can go to the store, buy a DVD, and then legally make a useful, working copy of it for personal use. You cannot, and you know full well that you cannot.
All the other senses you imagine that sentence might have are irrelevant.
That's a bogus comparison. First of all, 3G coverage may be poor where they are. Second, Palm's Blazer browser on PalmOS is 5 year old technology and dog slow; it doesn't get higher speed than that even over WiFi. Third, the Palm is $100 cheaper than the iPhone. Overall, I'd still rather have the 3G Palm than the iPhone (but neither is really great).
I have both an EDGE and a 3G phone... trust me, it's a world of difference. Once Apple ships a 3G iPhone, you Apple fanboys will make fun of everybody who doesn't have 3G.
The problem with them is you pretty much have to unlearn so much of the ideas we take for granted in imperative languages,
Oh, nonsense. CommonLisp is an imperative language whose primary difference to Python is that people invested several decades in figuring out language semantics that could be compiled fairly reasonably. There is little difference between
(loop for i from 30 downto 1 by 1 do
(print i))
and
for i in range(30,0,-1):
print i
except that the CommonLisp version is perhaps a little clearer and doesn't require special-casing in the compiler (it started out as a user-contributed macro).
I'll stick with my beloved python and hope one day, just one day, it catches on that I'll regularly get employment doing it.
Python is a pretty nice language, but it took a decade to get to this point, which it wouldn't have if Guido had done his homework from the start. And with all this work, the Python runtime is still pathetic and Python still doesn't have a good IDE.
Instead of reinventing the wheel, the Python community should consider building P3K on top of a good existing dynamic language runtime, maybe SBCL or Mono.
If everyone had waited for heavyweight pros to address the problem, we'd still be waiting, or be working with some horrible kludge (a camel is a horse designed by a committee etc.).
The heavyweight pros did address the problem, many times: Modula-3, Smalltalk, Sather, APL, OCAML, Haskell, Scheme, EuLisp, Icon, and on and on. What those languages lack are user communities.
They aren't perfect, and nothing ever is, but they power a great deal of the web, very effectively and usefully.
Ruby does not power the web; it is late to the party and offers no compelling advantages. If we need simplistic scripting languages, between Perl, Python, and PHP, we really have the bases more than covered. Ruby is superfluous. (Well, I suppose if it managed to kill Perl and replace it, that would be some minor progress, but I don't see that happening.)
MacOS was very proprietary, and Apple went to court protecting whatever proprietary aspects of it could.
OS X may use some open source components and command line UNIX interface, but the administration tools, graphics libraries, development tools, primary scripting language, and user interface are entirely proprietary.
Apple likes to create the impression that this is because their tools are better, but there is little concrete evidence that Quartz, Cocoa, AppleScript, Xcode, or Objective C are better than their open source equivalents. The main areas where Apple clearly wins are design, marketing, and out-of-box experience.
Apple's strategy seems to always have been, and continue to be, to be as proprietary as they can get away with. Nothing wrong with that--they are a for profit company. But don't you forget that they are a company and do what maximizes their profit, not what maximizes your benefit. And don't you forget that companies are very effective at marketing and creating addictive products--Apple products feel good, but so do lots of things that aren't good for you.
You know, the sad thing about all the comparisons you make is that they are all choices between bad technologies. Assembler vs. PL/I, C vs. Java, Windows vs. Linux--they're all questions like whether you want to be drawn or quartered, drowned or burned, poisoned or starved. At each of those choice points, there were better technologies available.
As for PHP vs. Ruby, both technologies suck: except for minor differences in syntax and object model, they are naively designed and implemented. After decades of research in dynamic languages and OOP, it is a testament to widespread ignorance that people would produce and use something like that.
But if I have to work with bad technologies, the one that's more popular, more mature, and more widely supported one is, relatively speaking, better. That's why I prefer to be poisoned with PHP rather than starved by Ruby: poison is quicker and less painful.
Oh wait, where can I get a standards-compliant web browser with a 3.5" screen, and a fully-functional POP/IMAP email client, on a phone again?
Symbian, Windows Mobile, and Palm phones have full web browsers and POP/IMAP. Many of them also have 3G speeds so that you can actually use them, non-crippled Bluetooth implementations, installable applications, chat support for many more networks, etc.
With 3G and installable apps, the iPhone would justify its price in terms of its functionality. EDGE-only and locked down, the iPhone is more expensive and has a lot less functionality than plenty of other smartphones.
The two reasons I can think of for getting one are (1) if you're an OS X user, it's probably the best choice because it's the only smart phone that integrates really well with OS X out of the box, and (2) you like the looks.
I don't care how nice a screen it has, at $400 with a 2 year contract, a locked phone with no extensibility and EDGE-only speeds is still far from cheap. The best one can say is that it has gone from an insanely overpriced phone to merely an expensive fashion phone.
If you were able to make a bit-wise copy of an encrypted DVD (thus ending up with another encrypted DVD) you're not breaking the law
You're also not copying "the DVD", since you're not copying the key, which is an essential part of the DVD. Copying the entire DVD is illegal because it involves copying the key.
This sort of copy may not be currently possible due to technical limitations, but that doesn't mean it's inherently impossible.
If you're trying to copy the keys, you're engaging in circumvention.
Moreover, you could even copy a normal, encrypted DVD in a way similar to some HD-DVD ripping methods: by controlling a software player to display the DVD frame by frame, [...] Such a procedure would definitely be a pita compared to normal DVD-ripping, but at least it's not illegal.
No, you cannot, because computer manufacturers have to disable screen capture during DVD playback, and both Microsoft and Apple do. If you try to work around that, it's circumvention, no matter how easy it may be.
Then, unencrypted DVDs may be as rare as you say (I doubt that somehow, but never mind), but they do exist, they are DVDs and copying them in whatever way is definitely not illegal.
Yes, copying some DVDs is legal. However, copying DVDs (in general) is not, because almost all DVDs cannot legally be copied by any means. Saying that people can legally copy DVDs is therefore a lie because they can't in general.
That's how all languages, mono and assorted crap included, work.
Bullshit: there are CLR implementations that are as fast as C/C++, and Mono is getting there. And if you don't like Mono, there are plenty of other languages, some very C/C++ like, that don't have the problems that C/C++ have.
Just because you glue few nuts and bolts to a text editor and proclaim it's an IDE does not change a thing.
While things like Monodevelop are not great, they are still better than anything that exists for Python.
And python is much more accessible to non-hackers than mono could ever hope to be.
It is. Unfortunately, Python is not a systems programming language; you cannot write a full desktop on Python. You can write a full desktop in Mono.
The author does not report the facts. The law does not prohibit the copying of DVDs or CDs; it disallows the circumvention of anti-copying technologies like Macrovision et al.
That does prohibit the copying of (almost all) DVDs; the fact that it doesn't explicitly say so doesn't change that.
The question then becomes: what do Germans pay fees on blank media for? What copyrighted content can be copied on DVDs? And why should the blank media fees be distributed to companies that put out encrypted (and hence, legally uncopyable) DVDs?
It is NOT illegal to copy CDs/DVDs in Germany. You can still copy your own DVDs or unencrypted discs as much as you like.
This must be a sense of "copy" that I'm not familiar with.
I take a DVD I buy at the store.
I make a full copy to another DVD.
There is a 99.9% probability I have broken German law. (The 0.1% is if the original DVD was not encrypted.)
In what sense is it not "illegal" to copy DVDs in Germany? In what sense can I copy them?
All I seem to be able to do is to make partial copies, those without the key, but a partial copy is not a copy. So, the best you can say is that German copyright law allows me to make partial copies, which is a useless right to have.
I don't think I've seen any conditions on using works that are "related" to the GPL'ed work but not a derived work...
The GPL effectively defines what it considers a "derived work", which is different from what copyright law defines it to be.
It can do that because getting a license for something can impose those kinds of restrictions on things other than derived works in the copyright sense. For example, your wallet is not a derived work of Microsoft Windows, yet obtaining a copy to Microsoft Windows forces you to remove money from your wallet.
using a lot of memory however for me doesn't mean fast and responsive.
Using a lot of memory isn't just a question of size, it's also a question of speed.
however a JIT takes some time. the compiler has to run too, doesn't it?
JIT compilation is amortized over execution of the code, meaning that even if it did exactly what a batch compiler does, it wouldn't be noticeably slower. But, in fact, for equivalent executables, at JIT-based system is often faster simply because the binaries are a lot smaller than native code, which translates into faster load times and less memory usage, both of which improve speed greatly. The time saved in those areas alone makes up for the small overhead of running the JIT. And, in addition, the JIT can actually optimize far more than a C/C++ batch compiler.
well I think, in the end that's the problem of every framework.
Correction: it's a problem of every framework you know.
the responsiveness of Linux has also to do with X.org as far as I can see. MacOSX is quite responsive normally. Windows starts up programs like hell, but it has its downsides, also it lacks features. XFCE is quite fast. downside is, it lacks features.
Again, all these judgments are relative to what you know. In fact, given the power of today's desktop machines, these frameworks objectively run like molasses: there is no reason why response to every desktop operation shouldn't be instantaneous. You simply have gotten around to waiting for things to start up, and for the spinning beach ball on MacOS, etc.
So in the end, a fast and responsive Desktop may rely on more than one factor
Well, it's good that you realize that, because that realization is the beginning of accepting the fact that C/C++ are neither necessary nor sufficient for writing a "fast and responsive desktop".
and also the choice depends on the wishes of the user.
Ah, and what possible "wish" could the user have about using a desktop in C/C++? Could he wish for programs that crash? That have security holes? Could he want software that takes years to develop instead of weeks?
And AFAIK, but I can be wrong, mono lacks a jit, but I have only read that somewhere. could be totally wrong.
Yes, you are totally wrong. Why don't you try to learn something about technology before you dismiss it?
and afaik JIT code can't be optimized in the same manner, because it has to be fast?
Quite to the contrary: JIT code can be optimized far more and far more easily than batch compiled code because the JIT has a lot more information available. For example, a JIT can inline many virtual function calls, and with a JIT, template metaprogramming becomes unnecessary because regular OO code can be optimized the same way.
Again, why don't you try to inform yourself first before condemning a platform?
I *really* love to learn new things, but offensive statements followed up by general assumptions never succeed to wake me up. chrrrr.
Based on almost no technical knowledge about the platform or approach, and plenty of wrong assumptions, you condemn an entire approach to developing software and promote another platform with huge problems.
Please, if you don't know much about a subject (and you have pretty much said that you know next to nothing about JITs, Mono, or optimization), don't make grand pronouncements about the supposed disadvantages of those platforms or why people should use something else. I've used C (and later C++) for a quarter of a century and do most of my programming in it, I know what its problems are. It was fine in the 1970s on PDP-11's with 64kbytes of address space (which is what it was designed for) when used by programmers who knew how to fit software into those kinds of machines; it has no place at all in modern software development.
Choices and ignorance like your are what keeping C and C++ alive, and they have condemned us to two decades of buffer overflows, slow and bloated software, and glacial development time. And that is quite offensive to me, because we really shouldn't be mucking around with this kind of primitive technology anymore.
I don't worry about the gov getting as much on us - the gov is mostly incompetant (that actually works in our favor, as citizens). but google is pretty competant
You are so naive. Do you really think that the people that manage a trillion dollars of our money and can casually send US troops to kill 500k civilians overseas are stupid and bumbled into their jobs? Look at who's running the country now and who was running it half a century ago. These people want power above all and were smart enough to get it, and they have the family and connections to make it work, generation after generation.
Considering the alternatives, it's not even a bad system. Unlike many previous systems of government, if you want it badly enough and are smart and ruthless enough, you can probable make it yourself into that circle. Many of the people, in addition to their egos, are also genuinely concerned about the well-being of the country, even if you wouldn't believe it.
But don't assume for a second that they don't know what they are doing.
Sergey and Larry got where they got because they incredibly lucky in addition to being smart. Many government leaders got where they got through meticulous long term strategizing and planning.
The GPL doesn't just impose conditions on derived works, it also imposes conditions on other kinds of works that are related to the GPL'ed work in some other way.
The best way right now to travel around the solar system is on the interplanetary transport network: slow but low cost transports that are great for moving robotic probes efficiently around the solar system.
I think it's premature to worry about building nuclear powered rockets like that; by the time we will actually be ready to send a human to another planet, we'll have completely different technology. Or, perhaps, we can use suspended animation and use the ITN even for human cargo.
Could this be an effective argument against the proliferation of cameras or will politicians simply ignore the facts and press ahead?"
You're making the assumption that these cameras are being installed in order to be an effective deterrent to crime. Instead, they rather are real-world FUD, making citizens believe that they live in a dangerous society, justifying taking away civil liberties, and giving politicians more power.
We live safer and more healthy lives than any society in human history, yet politicians are trying to create the impression that there are threats everywhere--they have to, otherwise they become less and less relevant.
well my desktop should be fast and responsive. can't think of any downsides for C/C++ in that part...
In fact, C and C++ have plenty of downsides: they are hard to optimize, programmers retain lots of memory unnecessarily, their lack of runtime safety means lots of stuff has to run as separate processes, and pointers inhibit compiler optimizations.
And that's why Gnome, KDE, Windows, and Macintosh are such resource pigs: the trivial little desktop functionality they provide should not take hundreds of megabytes and dozens of processes to implement. You couldn't design a less efficient language and desktop if you tried. It is sill that you think that this bloated crap is "fast and responsive".
but in my opinion the core layer of a desktop environment should definitely not use ANY interpreted language or virtual machine. [...] wake me if those funky high level languages compile into fast and real executable code without need for an interpreter
Yeah, being asleep is about what describes the mental state of people like you; there have been dozens of systems programming languages that are more efficient than C and C++, and they have been around for decades.
Now, as for Mono and the CLR, describing it as "interpreted" or "virtual machine" is misleading. Mono gets compiled into native code, it simply happens to use a portable binary format and perform runtime optimizations.
I do give you this much: Mono is bloated, but the reason for that is not the CLR, it's the libraries. But its libraries are no more bloated than the Gnome or standard C++ libraries.
Look, I like Python, too. But the fact remains that in Python, like in the other languages, you write code in a text editor, save it in files, run it, have it fail sometimes, put it into packages, install it, etc. That is so 1960's.
As for speed and type checking, they are sufficient for some applications, they are not sufficient for others; you have to drop into C.
We need programming languages that don't limit programming to a bunch of hackers, that don't make programming a chore, and that don't tie us to C for speed. Even Python, nice as it is, does.
Slashdot Mirror
So, you're saying that Apple software is not proprietary except for the millions of lines of code that happen to be proprietary for no other reason than that Apple likes to lock people into their platform. Seems like we are in agreement.
but anyone can write Mac apps with just gcc / gdb and a bash shell [...] just run X and X apps,
So, you're saying that if I want to use non-proprietary technologies, the Macintosh gives me the option of using it as a UNIX workstation that is less capable than what Sun shipped 15 years ago. You are absolutely right: I can do that. I just can't figure out any reason why I would want to.
The only reason to buy and use a Mac is the proprietary technologies Apple adds. That's not what I'm saying, it's what Apple is saying.
Saying that people can't legally copy DVDs is just as much of a lie by that standard, because they can copy some DVDs.
Stop the semantic bullshitting. We are talking about whether you can go to the store, buy a DVD, and then legally make a useful, working copy of it for personal use. You cannot, and you know full well that you cannot.
All the other senses you imagine that sentence might have are irrelevant.
That's a bogus comparison. First of all, 3G coverage may be poor where they are. Second, Palm's Blazer browser on PalmOS is 5 year old technology and dog slow; it doesn't get higher speed than that even over WiFi. Third, the Palm is $100 cheaper than the iPhone. Overall, I'd still rather have the 3G Palm than the iPhone (but neither is really great).
I have both an EDGE and a 3G phone... trust me, it's a world of difference. Once Apple ships a 3G iPhone, you Apple fanboys will make fun of everybody who doesn't have 3G.
The problem with them is you pretty much have to unlearn so much of the ideas we take for granted in imperative languages,
Oh, nonsense. CommonLisp is an imperative language whose primary difference to Python is that people invested several decades in figuring out language semantics that could be compiled fairly reasonably. There is little difference between
(loop for i from 30 downto 1 by 1 do
(print i))
and
for i in range(30,0,-1):
print i
except that the CommonLisp version is perhaps a little clearer and doesn't require special-casing in the compiler (it started out as a user-contributed macro).
I'll stick with my beloved python and hope one day, just one day, it catches on that I'll regularly get employment doing it.
Python is a pretty nice language, but it took a decade to get to this point, which it wouldn't have if Guido had done his homework from the start. And with all this work, the Python runtime is still pathetic and Python still doesn't have a good IDE.
Instead of reinventing the wheel, the Python community should consider building P3K on top of a good existing dynamic language runtime, maybe SBCL or Mono.
If everyone had waited for heavyweight pros to address the problem, we'd still be waiting, or be working with some horrible kludge (a camel is a horse designed by a committee etc.).
The heavyweight pros did address the problem, many times: Modula-3, Smalltalk, Sather, APL, OCAML, Haskell, Scheme, EuLisp, Icon, and on and on. What those languages lack are user communities.
They aren't perfect, and nothing ever is, but they power a great deal of the web, very effectively and usefully.
Ruby does not power the web; it is late to the party and offers no compelling advantages. If we need simplistic scripting languages, between Perl, Python, and PHP, we really have the bases more than covered. Ruby is superfluous. (Well, I suppose if it managed to kill Perl and replace it, that would be some minor progress, but I don't see that happening.)
MacOS was very proprietary, and Apple went to court protecting whatever proprietary aspects of it could.
OS X may use some open source components and command line UNIX interface, but the administration tools, graphics libraries, development tools, primary scripting language, and user interface are entirely proprietary.
Apple likes to create the impression that this is because their tools are better, but there is little concrete evidence that Quartz, Cocoa, AppleScript, Xcode, or Objective C are better than their open source equivalents. The main areas where Apple clearly wins are design, marketing, and out-of-box experience.
Apple's strategy seems to always have been, and continue to be, to be as proprietary as they can get away with. Nothing wrong with that--they are a for profit company. But don't you forget that they are a company and do what maximizes their profit, not what maximizes your benefit. And don't you forget that companies are very effective at marketing and creating addictive products--Apple products feel good, but so do lots of things that aren't good for you.
You know, the sad thing about all the comparisons you make is that they are all choices between bad technologies. Assembler vs. PL/I, C vs. Java, Windows vs. Linux--they're all questions like whether you want to be drawn or quartered, drowned or burned, poisoned or starved. At each of those choice points, there were better technologies available.
As for PHP vs. Ruby, both technologies suck: except for minor differences in syntax and object model, they are naively designed and implemented. After decades of research in dynamic languages and OOP, it is a testament to widespread ignorance that people would produce and use something like that.
But if I have to work with bad technologies, the one that's more popular, more mature, and more widely supported one is, relatively speaking, better. That's why I prefer to be poisoned with PHP rather than starved by Ruby: poison is quicker and less painful.
Oh wait, where can I get a standards-compliant web browser with a 3.5" screen, and a fully-functional POP/IMAP email client, on a phone again?
Symbian, Windows Mobile, and Palm phones have full web browsers and POP/IMAP. Many of them also have 3G speeds so that you can actually use them, non-crippled Bluetooth implementations, installable applications, chat support for many more networks, etc.
With 3G and installable apps, the iPhone would justify its price in terms of its functionality. EDGE-only and locked down, the iPhone is more expensive and has a lot less functionality than plenty of other smartphones.
The two reasons I can think of for getting one are (1) if you're an OS X user, it's probably the best choice because it's the only smart phone that integrates really well with OS X out of the box, and (2) you like the looks.
There are so many options: 3G, EDGE, microwave, satellite, laser, mesh networking, etc.
I don't care how nice a screen it has, at $400 with a 2 year contract, a locked phone with no extensibility and EDGE-only speeds is still far from cheap. The best one can say is that it has gone from an insanely overpriced phone to merely an expensive fashion phone.
iPhone doesn't start hitting "Crazy Eddie" pricing until it's below $100.
If you were able to make a bit-wise copy of an encrypted DVD (thus ending up with another encrypted DVD) you're not breaking the law
You're also not copying "the DVD", since you're not copying the key, which is an essential part of the DVD. Copying the entire DVD is illegal because it involves copying the key.
This sort of copy may not be currently possible due to technical limitations, but that doesn't mean it's inherently impossible.
If you're trying to copy the keys, you're engaging in circumvention.
Moreover, you could even copy a normal, encrypted DVD in a way similar to some HD-DVD ripping methods: by controlling a software player to display the DVD frame by frame, [...] Such a procedure would definitely be a pita compared to normal DVD-ripping, but at least it's not illegal.
No, you cannot, because computer manufacturers have to disable screen capture during DVD playback, and both Microsoft and Apple do. If you try to work around that, it's circumvention, no matter how easy it may be.
Then, unencrypted DVDs may be as rare as you say (I doubt that somehow, but never mind), but they do exist, they are DVDs and copying them in whatever way is definitely not illegal.
Yes, copying some DVDs is legal. However, copying DVDs (in general) is not, because almost all DVDs cannot legally be copied by any means. Saying that people can legally copy DVDs is therefore a lie because they can't in general.
That's how all languages, mono and assorted crap included, work.
Bullshit: there are CLR implementations that are as fast as C/C++, and Mono is getting there. And if you don't like Mono, there are plenty of other languages, some very C/C++ like, that don't have the problems that C/C++ have.
Just because you glue few nuts and bolts to a text editor and proclaim it's an IDE does not change a thing.
While things like Monodevelop are not great, they are still better than anything that exists for Python.
And python is much more accessible to non-hackers than mono could ever hope to be.
It is. Unfortunately, Python is not a systems programming language; you cannot write a full desktop on Python. You can write a full desktop in Mono.
The author does not report the facts. The law does not prohibit the copying of DVDs or CDs; it disallows the circumvention of anti-copying technologies like Macrovision et al.
That does prohibit the copying of (almost all) DVDs; the fact that it doesn't explicitly say so doesn't change that.
The question then becomes: what do Germans pay fees on blank media for? What copyrighted content can be copied on DVDs? And why should the blank media fees be distributed to companies that put out encrypted (and hence, legally uncopyable) DVDs?
This must be a sense of "copy" that I'm not familiar with.
In what sense is it not "illegal" to copy DVDs in Germany? In what sense can I copy them?
All I seem to be able to do is to make partial copies, those without the key, but a partial copy is not a copy. So, the best you can say is that German copyright law allows me to make partial copies, which is a useless right to have.
The guy who picked SGML as the basis for an end user markup really shouldn't complain about "geek culture".
I don't think I've seen any conditions on using works that are "related" to the GPL'ed work but not a derived work...
The GPL effectively defines what it considers a "derived work", which is different from what copyright law defines it to be.
It can do that because getting a license for something can impose those kinds of restrictions on things other than derived works in the copyright sense. For example, your wallet is not a derived work of Microsoft Windows, yet obtaining a copy to Microsoft Windows forces you to remove money from your wallet.
using a lot of memory however for me doesn't mean fast and responsive.
Using a lot of memory isn't just a question of size, it's also a question of speed.
however a JIT takes some time. the compiler has to run too, doesn't it?
JIT compilation is amortized over execution of the code, meaning that even if it did exactly what a batch compiler does, it wouldn't be noticeably slower. But, in fact, for equivalent executables, at JIT-based system is often faster simply because the binaries are a lot smaller than native code, which translates into faster load times and less memory usage, both of which improve speed greatly. The time saved in those areas alone makes up for the small overhead of running the JIT. And, in addition, the JIT can actually optimize far more than a C/C++ batch compiler.
well I think, in the end that's the problem of every framework.
Correction: it's a problem of every framework you know.
the responsiveness of Linux has also to do with X.org as far as I can see. MacOSX is quite responsive normally. Windows starts up programs like hell, but it has its downsides, also it lacks features. XFCE is quite fast. downside is, it lacks features.
Again, all these judgments are relative to what you know. In fact, given the power of today's desktop machines, these frameworks objectively run like molasses: there is no reason why response to every desktop operation shouldn't be instantaneous. You simply have gotten around to waiting for things to start up, and for the spinning beach ball on MacOS, etc.
So in the end, a fast and responsive Desktop may rely on more than one factor
Well, it's good that you realize that, because that realization is the beginning of accepting the fact that C/C++ are neither necessary nor sufficient for writing a "fast and responsive desktop".
and also the choice depends on the wishes of the user.
Ah, and what possible "wish" could the user have about using a desktop in C/C++? Could he wish for programs that crash? That have security holes? Could he want software that takes years to develop instead of weeks?
And AFAIK, but I can be wrong, mono lacks a jit, but I have only read that somewhere. could be totally wrong.
Yes, you are totally wrong. Why don't you try to learn something about technology before you dismiss it?
and afaik JIT code can't be optimized in the same manner, because it has to be fast?
Quite to the contrary: JIT code can be optimized far more and far more easily than batch compiled code because the JIT has a lot more information available. For example, a JIT can inline many virtual function calls, and with a JIT, template metaprogramming becomes unnecessary because regular OO code can be optimized the same way.
Again, why don't you try to inform yourself first before condemning a platform?
I *really* love to learn new things, but offensive statements followed up by general assumptions never succeed to wake me up. chrrrr.
Based on almost no technical knowledge about the platform or approach, and plenty of wrong assumptions, you condemn an entire approach to developing software and promote another platform with huge problems.
Please, if you don't know much about a subject (and you have pretty much said that you know next to nothing about JITs, Mono, or optimization), don't make grand pronouncements about the supposed disadvantages of those platforms or why people should use something else. I've used C (and later C++) for a quarter of a century and do most of my programming in it, I know what its problems are. It was fine in the 1970s on PDP-11's with 64kbytes of address space (which is what it was designed for) when used by programmers who knew how to fit software into those kinds of machines; it has no place at all in modern software development.
Choices and ignorance like your are what keeping C and C++ alive, and they have condemned us to two decades of buffer overflows, slow and bloated software, and glacial development time. And that is quite offensive to me, because we really shouldn't be mucking around with this kind of primitive technology anymore.
I don't worry about the gov getting as much on us - the gov is mostly incompetant (that actually works in our favor, as citizens). but google is pretty competant
You are so naive. Do you really think that the people that manage a trillion dollars of our money and can casually send US troops to kill 500k civilians overseas are stupid and bumbled into their jobs? Look at who's running the country now and who was running it half a century ago. These people want power above all and were smart enough to get it, and they have the family and connections to make it work, generation after generation.
Considering the alternatives, it's not even a bad system. Unlike many previous systems of government, if you want it badly enough and are smart and ruthless enough, you can probable make it yourself into that circle. Many of the people, in addition to their egos, are also genuinely concerned about the well-being of the country, even if you wouldn't believe it.
But don't assume for a second that they don't know what they are doing.
Sergey and Larry got where they got because they incredibly lucky in addition to being smart. Many government leaders got where they got through meticulous long term strategizing and planning.
The GPL doesn't just impose conditions on derived works, it also imposes conditions on other kinds of works that are related to the GPL'ed work in some other way.
The best way right now to travel around the solar system is on the interplanetary transport network: slow but low cost transports that are great for moving robotic probes efficiently around the solar system.
I think it's premature to worry about building nuclear powered rockets like that; by the time we will actually be ready to send a human to another planet, we'll have completely different technology. Or, perhaps, we can use suspended animation and use the ITN even for human cargo.
Could this be an effective argument against the proliferation of cameras or will politicians simply ignore the facts and press ahead?"
You're making the assumption that these cameras are being installed in order to be an effective deterrent to crime. Instead, they rather are real-world FUD, making citizens believe that they live in a dangerous society, justifying taking away civil liberties, and giving politicians more power.
We live safer and more healthy lives than any society in human history, yet politicians are trying to create the impression that there are threats everywhere--they have to, otherwise they become less and less relevant.
well my desktop should be fast and responsive. can't think of any downsides for C/C++ in that part...
In fact, C and C++ have plenty of downsides: they are hard to optimize, programmers retain lots of memory unnecessarily, their lack of runtime safety means lots of stuff has to run as separate processes, and pointers inhibit compiler optimizations.
And that's why Gnome, KDE, Windows, and Macintosh are such resource pigs: the trivial little desktop functionality they provide should not take hundreds of megabytes and dozens of processes to implement. You couldn't design a less efficient language and desktop if you tried. It is sill that you think that this bloated crap is "fast and responsive".
but in my opinion the core layer of a desktop environment should definitely not use ANY interpreted language or virtual machine. [...] wake me if those funky high level languages compile into fast and real executable code without need for an interpreter
Yeah, being asleep is about what describes the mental state of people like you; there have been dozens of systems programming languages that are more efficient than C and C++, and they have been around for decades.
Now, as for Mono and the CLR, describing it as "interpreted" or "virtual machine" is misleading. Mono gets compiled into native code, it simply happens to use a portable binary format and perform runtime optimizations.
I do give you this much: Mono is bloated, but the reason for that is not the CLR, it's the libraries. But its libraries are no more bloated than the Gnome or standard C++ libraries.
If these people are against it, the reform must be good.
... it shouldn't be: in a free market, it's essential that people compare prices as efficiently as possible.
If anything, we should really require stores to post pricing information publicly on the Internet in XML format to make comparison shopping easier.
Look, I like Python, too. But the fact remains that in Python, like in the other languages, you write code in a text editor, save it in files, run it, have it fail sometimes, put it into packages, install it, etc. That is so 1960's.
As for speed and type checking, they are sufficient for some applications, they are not sufficient for others; you have to drop into C.
We need programming languages that don't limit programming to a bunch of hackers, that don't make programming a chore, and that don't tie us to C for speed. Even Python, nice as it is, does.