In any case, let me introduce position #4: The system I run today has all kinds of elements in it, from all kinds of projects, open and closed. GNU is one of them, along with KDE, QT, X.org, Perl, Apache, PostgreSQL, the Ubuntu/Kubuntu projects... Hell, the next version of KHTML (Konqueror's rendering engine) will be incorportaing code from Apple, for fuck's sake!
To be completely fair to all parties, I'd have to call it: GNU/TrollTech/KDE/X.org/Perl/Apache/Postgres/Ubuntu/Kubuntu/iLinux.
Oh wait! I forgot the hardware manufacturers! What was I thinking? I guess I better add an AMD/nVidia/BioStar/KOSS/SysKonnect/Realtek/Creative/Sceptre/Logitech to the mix.
Starting to get the idea?
Frankly, I'd rather call it whatever I want and deal with RMS complaining, than have to read the entire list of contributors every time someone asks me what OS I run. So I call it Linux, KDE, Ubuntu, and Kubuntu. The GNU project has plenty of visibility -- I see it every time I look up the docs for a tool I'm using (GNU Make, Gnu C Compiler, etc), not to mention the occasional time I fire up the Gimp.
And what does GNOME run on? The GNU Windowing system?
Ok, we can ignore tar/grep for most desktop users. We can ignore gcc/make/etc, as they are development tools -- not relevant to anyone but developers. (After all, I'll bet Doom 3 for Linux was built with GCC, but we hardly call it "GNU/Doom3", now, do we?)
No one calling it "Linux" wants to discredit the GNU people, but frankly, I'm glad we don't have to acknowledge every little contributor in the name. I run an operating system which I call "Kubuntu", and occasionally "Linux" so people have something to refer to. I use KDE, some GNU utilities, some Perl and various other things not even GPL'd, and some things I'm not sure are entirely legal, like libdvdcss.
GNU is pervasive in my system -- but no more pervasive than any other random element, like X.org.
Of course, I imagine they could provide, as an option, on first boot, a script to download and install the "illegal" free ones. That's what I'd do, if I were going to try to be a Linux OEM.
But, this being the corporate world, they're probably much better off going with the legal version.
Anyway, support is a non-issue. The only problem here is the initial price, and the only reason that's possibly a problem is that the price of Windows gets offset by crapware. Remove the crapware, and I'll bet Linux+codecs is cheaper than Windows+PowerDVD+Office+etc
Now moving into the realm of I-have-no-idea-what-I'm-talking-about. That said, here's something from the ODE mailing list:
Bullet Collision Detection can work with ODE, or it can use Bullet's native
Dynamics. The Dynamics part of Bullet is very limited. No limits, no motors,
only point to point and contact constraint. It uses a sequential impulse
based method which is very similar to PGS in the end.
I'm amazed how rarely it gets mentioned, but you know, there is an open competitor, sort of. I say "sort of" because I've never actually written a game that needed physics, so I don't know whether ODE is to Havok as OpenGL/SDL is to DirectX/D3D.
Also raises the question: Will Intel force everyone to use Havok to take advantage of any physics-related silicon they develop? Or will they be friendlier to ODE? Or will they not create any physics-specific silicon, and make this whole discussion moot?
And I still haven't heard of anything approaching a release candidate for perl6, or ponie, or pynie. Maybe I just haven't been paying attention...
Another question is whether pynie has a chance of becoming the default Python environment. There's been Jython and IronPython, and probably others, but they suffer from lacking some features and generally being less popular than CPython. I imagine most people would agree that a standard VM is probably a good thing.
I agree, in this day and age, not having a plug to remove the GIL is beyond stupid.
Well... Not so much stupid as lazy. Stupid that they don't think it's worth spending the effort, but also, they do claim it'd be hard to do -- and, for some things, it would be.
It is worth pointing out that the situation isn't as bad as you imply as multi-core support most definitely has not been removed. Threading works great when python is I/O bound.
Yeah, at which point, it doesn't matter, because when your process is I/O bound, you can write it in Ruby, PHP, JavaScript, whatever you want. It has nothing to do with multiple cores, then.
The only way it could possibly involve the second core is if it's reading from / writing to a CPU intensive process, in which case, it really doesn't matter whether Python uses OS threads or green threads, the result is the same.
CPU bound tasks, on the other hand, essentially means python is single threaded unless your work is being done outside of the interpretor, which likely means there is no point in writing it in python.
Well, there is one: If you are very careful, you can use external libraries to do the heavy lifting -- stuff like crypto, compression, image processing, whatever -- stuff that's all been done many times over in C. Modules that are written properly can release the GIL, do some CPU crunching with stuff that doesn't touch Python internals, then acquire the GIL again to pass the results back to the script. The point of Python here is to be a high-level scripting language, to tie all these pieces together.
However, this attitude annoys the hell out of me. It's pervasive -- Perl, Python, Ruby, PHP, pretty much all so-called general-purpose high-level "scripting" languages use the cop-out of C-based extensions as an excuse for poor performance. To me, this says that these are not general-purpose languages. They're more architectural languages -- more powerful than Bash, maybe, but basically doing the same job Bash does with init scripts.
So, yes, there's still a point in writing in Python -- it's one of the best we've got. But what does that say about us?
To add insult to injury, python's process model sucks so if you want to go the fork model, things which should be easy in a high level language like python are as much a pain as they are in C, or almost so.
This was discussed awhile ago -- it may be possible to take one of the various micro-thread models, or even just a threading model, and port it to processes. Not a lot of them, just one per core, maybe. Python does have ways to access shared memory (as a method of IPC), and it's possible that other models could be used -- pipes would suck for performance, but would be cool for transparently porting a program to the cluster.
But at this point, we'd basically be building a scheduler / process model on top of another scheduler / process model, because they're too lazy to remove the GIL.
Python has multicore support; it's called "spawn a process".
Hey, why didn't I think of that?
Yeah, I'll file that right along with having my program invoke gcc as a way to add dynamism. Yes, it can be done, but it's ugly and slow compared to the right way.
I'll give you this much, though: Processes are a lot easier to scale across machines. However, I'd much rather see the distinction start to disappear -- there are cases where, even if you're OK with the semantics of copying data back and forth, you simply can't deal with the performance implications.
Oh, and by the way, one other thing Java did right: You can run untrusted code in the same process as trusted code. An operating system written in Java would not need traditional processes, except for legacy apps that don't run on the JVM. (I'm not advocating either Java or the JVM for this purpose, though; there are better ways of doing the same thing.)
Didn't he find it odd that people who actually ran computer companies couldn't see it that way? "There's some benefit to youth," he says. "It's a lot like physicsEinstein saw relativity, the others didn'tbut then he didn't understand quantum dynamics, that next generation came along, and he became the old guard.
I wonder if Gates realizes how much this might apply to his company (old guard) versus open source / open standards (next generation)?
Meh. I imagine he pays someone to write his crap, anyway. He could certainly afford it, with what he spends trying to hold progress back.
I mean, I could tell you to use OpenGL -- everything you said about DirectX is true of OpenGL/SDL -- but I don't know if it would be any better with this particular problem.
But 2D turn-based games? Are you really doing so much animation that you need to accelerate it at all?
(Oh, and regardless, it's poor encapsulation if you're tied to one graphics API anyway. Most visible example, probably: Unreal (specifically Unreal Tournament 2003/04), which runs on DirectX, OpenGL, and various consoles, with the same engine. I know UT04 can change resolution without restarting the program, along with most settings, so it's even possible that it can change APIs in the middle of a firefight.)
There are good reasons for the whitespace thing, actually. If that's your biggest complaint, hell, my biggest complaint about other languages is that I'm forced to use these silly brackets when I'm already indenting anyway.
In fact, PHP is harder, because you need the version number.
If you look at hello world programs, it's pretty similar.
The only difference I see is that PHP, early on, was very easy to embed into existing web pages, so it was sort of the logical next step to learn, once you know HTML. So, among the newbie web developers, PHP is synonymous with server-side scripting. Fortunately, no one is stupid enough to try to use it for anything other than the web.
Unfortunately, PHP is also ubiquitous among the newbie web dev crowd that when they get ambitious enough to try something really big, even innovative, they do it in PHP. Example: Drupal. But really, once you start designing your app properly, separating content and presentation, there's no advantage that PHP has over Python, except that you already know it.
I guess when Linus does it, it's a noble independent spirit, when Guido does it he's being an asshole.
More like, Linus actually bothers to listen to and understand the opposing viewpoint. He also tends to not make unilateral decisions that everyone is going to hate.
Saying he's "not that different than Linus" is like saying Linus is not that different than Stalin. Just because they're dictators doesn't make them even remotely comparable.
Multicore support is a nonissue. CPython is too slow to need it.
It is actually two issues.
First is Psyco, and any similar efforts in the future. Psyco, aside from not supporting anything but 32-bit x86, also is limited to a single core, despite being very, very fast -- in some cases, supposedly faster than C. In any case, that is the goal.
And if CPython is that slow, I'll take any performance boost I can get.
Second, it means that any other implementation that doesn't have a GIL is likely going to expose obscure bugs in existing python programs. Well, not bugs, but assumptions that only one Python instruction can run at a time. Not to mention the C extensions...
It means you can't have an optimizing compiler. (Well, maybe you could, with one that goes to immense lengths to detect when "something funny" is going on and reworks the code on the fly. Won't be easy to implement.)
Well, first, no compiler is "easy". If it is, write me a C compiler that's half as good as gcc.
Second, it's been done. You mention LISP:
Years ago, LISP hackers used to talk about how great it was that LISP programs could modify themselves while they were running. Few useful programs ever actually did so.
And yet today, there are very fast and useful LISP compilers, which do just what you said an "optimizing compiler" can't do -- they make LISP fast enough that it could probably be used as a replacement for C or Java (for most things), if it weren't for all those damned parentheses...
Libraries are someone else's problem. Python is better than Perl as a language, but CPAN is better than Python's Cheese Shop.
Well, CPAN is better than just about any language. Also, you were expecting to find cheese in the Cheese Shop? They're all out of that!
In any case, CPAN doesn't seem to be much better supported -- often, yes, a developer or two, working in isolation, maybe a bit of peer review.
Also, this is like the argument of Windows being better than Linux, due to number of apps. It's a sad reality that it limits options, but in my experience, Linux is better enough that I'd often rather do a little extra work to make Linux do what I want than buy a Windows program to do the same thing.
I don't think Python is quite there yet, though. Notice how pretty much every one of your Python complaints holds for Perl, except CPAN. But, if Python were fast enough, and had threading that worked, I'd be using it instead of Perl, no question. (For that matter, if Perl6 ever gets released, and if Python gets ported to Parrot -- not very likely, I know, but if it happened -- CPAN would suddenly become available to Python people.)
Or you discover that you need racks of servers to compensate for the painfully slow implementation.
Which would be great, if it weren't for the fucking GIL. I hate that thing.
Then again, people are willing to deploy Ruby, so at a certain point, CPU is cheaper than programmers. Although I still wish I didn't have to choose.
That's why Python hasn't even replaced Perl, over fifteen years into the deployment of Python.
Well, Perl hasn't replaced Java, and Java hasn't replaced C.
Frankly, I think one of these languages needs to step up and offer something compelling -- or I need to find the one that already has, and still isn't dominating. But I've been looking for years, and still haven't found something that's as dynamic and easy as perl/python/ruby, as portable as Java (even CORA, please), and as fast as C, even though I'm convinced it's possible.
It's not even an issue of better support for concurrency in the language itself.
Personally, I like some of the ideas of Python better than Haskell and Erlang. There have been some very good ways of doing multithreading, even massive multithreading (see Stackless, some of which is now back in the main Python), and making it natural, even with an imperative style of programming. Some implementations (again, see Stackless) make threads so lightweight that you can spawn thousands without being concerned about performance, and the structures used make it natural to do that without any kind of locking issues -- sometimes, without explicit locks at all.
The problem is not with python, the language. It's with python, the interpreter, and all the associated C modules, embedded versions, etc, not to mention Python programs that might assume the same behavior.
Specifically, it's the Global Interpreter Lock. The GIL is the most retarded move I've ever seen in a language. Basically, Python said "We don't want to make the Python interpreter too complicated, so we're going to deliberately remove multicore support." They even support real OS threads, but only one Python instruction may be executed at a time. Which is fucking stupid.
There are a lot of really good things in Python. I'd like to be able to write a good, modern game with Python, but if you figure it may be half as fast as C already, I'm not going to lose another 50% speed because it can't use both cores. (Yes, psyco can make it MUCH faster, close to C. But, psyco doesn't work on 64-bit, which is another kick in the balls for performance.)
Our beliefs are every bit as strong as facts and evidence used by Evolutionists
Stronger, if by "strong" you're talking about how tightly you cling to that belief. Evolutionists are generally pretty convinced of the accuracy of Evolution, but we are open to a new theory, if it was presented with sufficient evidence.
and should be treated with exactly the same respect.
Sorry, no.
Firefly quote time:
Inara: You have a strange sense of nobility, Captain. You'll lay a man out for implying I'm a whore, but you keep calling me one to my face. Mal: I might not show respect for your job, but he didn't respect you. That's the difference.
I can respect you, as a person. I respect most people that way -- it takes a lot to convince me that a particular person is beyond help, that it would be impossible to ever teach them to be a decent, intelligent person.
But there is no way in hell you'll get me to respect your beliefs. They are laughably wrong and unfounded, with their closest real proof being a book that is not only old and dusty, but frequently self-contradictory, even in Genesis.
If you are really open to other beliefs and facts, take a read here, but be warned -- not for the faint of heart, and you most certainly will lose some faith when you read that. Have a copy of your Bible ready...
And that's for Counter-Strike Source, which, if you don't know, is a very fast-paced FPS which absolutely needs to be as accurate as possible (so people can get headshots, etc). It probably uses several orders of magnitude more bandwidth per player than your typical MMO.
Note, also, that this is server bandwidth needed, not client bandwidth. I'll bet, too, that some of that would go away if we could actually use multicast... *sigh*
There is no legal agreement between you and the newspaper company either, but it's expected that when you plop a quarter into a paperbox that you don't take the entire stack of papers.
Yes. There are also usually signs there which say "take one", as well as a slot that clearly expects 25 cents.
It's called the honor system.
There's generally little chance of anyone being confused about this "honor system", or much incentive for circumventing it -- after all, what use would you have with more than one newspaper?
But notice: In places where there is significant incentive to break the honor system, there's usually significantly more security in place than an honor system. That newspaper box, for instance, might be sitting next to a Coke machine, which, short of vandalism, is only going to give you one Coke for your dollar. (Or your $1.25, as the case may be.)
Why? Well, I don't know about you, but I could drink two cokes. Or drink one, and save one for later. Or drink one, and get one for my friend. None of which is especially true of the newspaper -- I can easily share my one copy with my friend, and there'd be no point in reading two copies, now or later.
Moral or not, when you build your business model on the honor system, don't expect much sympathy when it fails.
By circumventing that implied intent, you are morally in the wrong.
Where's it implied?
And, you are under no moral imperative to watch any ad, but you do not morally have the right to disregard the owners wishes and block ads, not even giving him the opportunity to interest you in ads.
If the owner has such a wish, they should state it for me, clearly.
And by the way, how do you explain the moral right of a webmaster to push content to me that I don't want, using my bandwidth, CPU, and attention? Sorry, but it's my computer.
If you start paying for my bandwidth, hardware, and power, then we'll talk about me watching your ads. Until then, consider yourself lucky that I generally do not use filtersets, but rather block things manually -- and only after they've sufficiently pissed me off.
it's possible the right ad will come up just when you're looking for something, and you'll click it.
Not if it's a gigantic, animated Flash thing that popped up right on top of whatever I was actually looking at. Do that, and you guarantee that ad gets blocked, even if it was what I was looking for. Do it enough, and you guarantee some negative brand recognition -- you guarantee that I absolutely will not buy your product, ever.
Even if you're not going to buy something, if a brand gets tied to a purpose in your head, you may tell someone else about it if they ask on that topic.
Which goes back to brand recognition.
The whole reason they NEED the animations is because people are not interested in it.
In which case, why is it my moral imperative to look at those animations?
I mean, if they have an inherently uninteresting product that I don't want to buy, then their advertisement is a waste of my bandwidth, attention, and patience. If they want my intention, then follow the iPhone's example -- make a product that's interesting enough that a text ad will catch my eye, because I don't block text ads.
with browsing you're incurring direct costs for the host each time you visit and not fulfilling your half of the bargain in letting them deliver the ads to you.
A "bargain" which is never spelled out. Period.
I don't mean legally. I mean it's absolutely fucking nowhere to be found, which just leaves a bad taste in my mouth.
Have you ever been to a third-world country? Everyone will be very helpful in some way, but depending on the country and the place, they will often expect some reward -- after the fact. That's right -- some adorable little kid will guide you across the river or whatever, and then demand payment.
This isn't naivete -- they know you might not accept their service, if you knew the cost. And they know you might feel guilty enough to pay them anyway -- after all, you're a foreigner, so you're used to feeling like you've violated local custom, because often, you have -- but in this case, they're just preying on you.
In this case, I would say to the child, if you want to be paid, name your price up front. And I would say that to the webmaster, as well -- if you are so convinced that there's a bargain here, name your terms up front, before I enter the website. Or block me, with an explanation of which ads I must allow through to be unblocked. Or better yet -- use ads that I won't block!
Otherwise, I'll block them, and you'll whine all day about how it's immoral, and you'll get nowhere.
If you don't like the ads, don't visit the site.
You should be grateful more people don't actually take this attitude. Your revenue would collapse overnight.
My guess is, if people are deliberately blocking your ads, chances are, you have some pretty intrusive ones. Thus, the people who actually manage to make it to your content are those who either don't like the ads, but don't know how to block them, and those who happily block them, and are maybe blissfully unaware.
Slashdot Mirror
Skype essentially solved this with a UDP hack.
But, I really, really hope this doesn't happen -- even though it already is.
Could you back up #3 with some quotes?
In any case, let me introduce position #4: The system I run today has all kinds of elements in it, from all kinds of projects, open and closed. GNU is one of them, along with KDE, QT, X.org, Perl, Apache, PostgreSQL, the Ubuntu/Kubuntu projects... Hell, the next version of KHTML (Konqueror's rendering engine) will be incorportaing code from Apple, for fuck's sake!
To be completely fair to all parties, I'd have to call it: GNU/TrollTech/KDE/X.org/Perl/Apache/Postgres/Ubuntu/Kubuntu/iLinux.
Oh wait! I forgot the hardware manufacturers! What was I thinking? I guess I better add an AMD/nVidia/BioStar/KOSS/SysKonnect/Realtek/Creative/Sceptre/Logitech to the mix.
Starting to get the idea?
Frankly, I'd rather call it whatever I want and deal with RMS complaining, than have to read the entire list of contributors every time someone asks me what OS I run. So I call it Linux, KDE, Ubuntu, and Kubuntu. The GNU project has plenty of visibility -- I see it every time I look up the docs for a tool I'm using (GNU Make, Gnu C Compiler, etc), not to mention the occasional time I fire up the Gimp.
And what does GNOME run on? The GNU Windowing system?
Ok, we can ignore tar/grep for most desktop users. We can ignore gcc/make/etc, as they are development tools -- not relevant to anyone but developers. (After all, I'll bet Doom 3 for Linux was built with GCC, but we hardly call it "GNU/Doom3", now, do we?)
No one calling it "Linux" wants to discredit the GNU people, but frankly, I'm glad we don't have to acknowledge every little contributor in the name. I run an operating system which I call "Kubuntu", and occasionally "Linux" so people have something to refer to. I use KDE, some GNU utilities, some Perl and various other things not even GPL'd, and some things I'm not sure are entirely legal, like libdvdcss.
GNU is pervasive in my system -- but no more pervasive than any other random element, like X.org.
If he's that good at C, wouldn't he be better at another language? (Given time to learn, of course.)
Of course, I imagine they could provide, as an option, on first boot, a script to download and install the "illegal" free ones. That's what I'd do, if I were going to try to be a Linux OEM.
But, this being the corporate world, they're probably much better off going with the legal version.
Anyway, support is a non-issue. The only problem here is the initial price, and the only reason that's possibly a problem is that the price of Windows gets offset by crapware. Remove the crapware, and I'll bet Linux+codecs is cheaper than Windows+PowerDVD+Office+etc
Now moving into the realm of I-have-no-idea-what-I'm-talking-about. That said, here's something from the ODE mailing list:
I'm amazed how rarely it gets mentioned, but you know, there is an open competitor, sort of. I say "sort of" because I've never actually written a game that needed physics, so I don't know whether ODE is to Havok as OpenGL/SDL is to DirectX/D3D.
Also raises the question: Will Intel force everyone to use Havok to take advantage of any physics-related silicon they develop? Or will they be friendlier to ODE? Or will they not create any physics-specific silicon, and make this whole discussion moot?
I know about this. And I know about ponie.
And I still haven't heard of anything approaching a release candidate for perl6, or ponie, or pynie. Maybe I just haven't been paying attention...
Another question is whether pynie has a chance of becoming the default Python environment. There's been Jython and IronPython, and probably others, but they suffer from lacking some features and generally being less popular than CPython. I imagine most people would agree that a standard VM is probably a good thing.
Well... Not so much stupid as lazy. Stupid that they don't think it's worth spending the effort, but also, they do claim it'd be hard to do -- and, for some things, it would be.
Yeah, at which point, it doesn't matter, because when your process is I/O bound, you can write it in Ruby, PHP, JavaScript, whatever you want. It has nothing to do with multiple cores, then.
The only way it could possibly involve the second core is if it's reading from / writing to a CPU intensive process, in which case, it really doesn't matter whether Python uses OS threads or green threads, the result is the same.
Well, there is one: If you are very careful, you can use external libraries to do the heavy lifting -- stuff like crypto, compression, image processing, whatever -- stuff that's all been done many times over in C. Modules that are written properly can release the GIL, do some CPU crunching with stuff that doesn't touch Python internals, then acquire the GIL again to pass the results back to the script. The point of Python here is to be a high-level scripting language, to tie all these pieces together.
However, this attitude annoys the hell out of me. It's pervasive -- Perl, Python, Ruby, PHP, pretty much all so-called general-purpose high-level "scripting" languages use the cop-out of C-based extensions as an excuse for poor performance. To me, this says that these are not general-purpose languages. They're more architectural languages -- more powerful than Bash, maybe, but basically doing the same job Bash does with init scripts.
So, yes, there's still a point in writing in Python -- it's one of the best we've got. But what does that say about us?
This was discussed awhile ago -- it may be possible to take one of the various micro-thread models, or even just a threading model, and port it to processes. Not a lot of them, just one per core, maybe. Python does have ways to access shared memory (as a method of IPC), and it's possible that other models could be used -- pipes would suck for performance, but would be cool for transparently porting a program to the cluster.
But at this point, we'd basically be building a scheduler / process model on top of another scheduler / process model, because they're too lazy to remove the GIL.
Hey, why didn't I think of that?
Yeah, I'll file that right along with having my program invoke gcc as a way to add dynamism. Yes, it can be done, but it's ugly and slow compared to the right way.
I'll give you this much, though: Processes are a lot easier to scale across machines. However, I'd much rather see the distinction start to disappear -- there are cases where, even if you're OK with the semantics of copying data back and forth, you simply can't deal with the performance implications.
Oh, and by the way, one other thing Java did right: You can run untrusted code in the same process as trusted code. An operating system written in Java would not need traditional processes, except for legacy apps that don't run on the JVM. (I'm not advocating either Java or the JVM for this purpose, though; there are better ways of doing the same thing.)
I wonder if Gates realizes how much this might apply to his company (old guard) versus open source / open standards (next generation)?
Meh. I imagine he pays someone to write his crap, anyway. He could certainly afford it, with what he spends trying to hold progress back.
I mean, I could tell you to use OpenGL -- everything you said about DirectX is true of OpenGL/SDL -- but I don't know if it would be any better with this particular problem.
But 2D turn-based games? Are you really doing so much animation that you need to accelerate it at all?
(Oh, and regardless, it's poor encapsulation if you're tied to one graphics API anyway. Most visible example, probably: Unreal (specifically Unreal Tournament 2003/04), which runs on DirectX, OpenGL, and various consoles, with the same engine. I know UT04 can change resolution without restarting the program, along with most settings, so it's even possible that it can change APIs in the middle of a firefight.)
Wait -- your keyboard didn't work, and you had to prove it with an operating system?
Have these fucktards never heard of a BIOS??
Think about why you got modded that way.
There are good reasons for the whitespace thing, actually. If that's your biggest complaint, hell, my biggest complaint about other languages is that I'm forced to use these silly brackets when I'm already indenting anyway.
Both Python and PHP required about the same amount of effort to get started, at least for me:
In fact, PHP is harder, because you need the version number.
If you look at hello world programs, it's pretty similar.
The only difference I see is that PHP, early on, was very easy to embed into existing web pages, so it was sort of the logical next step to learn, once you know HTML. So, among the newbie web developers, PHP is synonymous with server-side scripting. Fortunately, no one is stupid enough to try to use it for anything other than the web.
Unfortunately, PHP is also ubiquitous among the newbie web dev crowd that when they get ambitious enough to try something really big, even innovative, they do it in PHP. Example: Drupal. But really, once you start designing your app properly, separating content and presentation, there's no advantage that PHP has over Python, except that you already know it.
More like, Linus actually bothers to listen to and understand the opposing viewpoint. He also tends to not make unilateral decisions that everyone is going to hate.
Saying he's "not that different than Linus" is like saying Linus is not that different than Stalin. Just because they're dictators doesn't make them even remotely comparable.
Not only can you use 2 spaces for indentation if you like, but you can also use hard tabs and set your tabstop to two spaces.
Next you'll be telling me that you hate any language that defines subroutines with anything other than a "function" keyword... Deal with it.
It is actually two issues.
First is Psyco, and any similar efforts in the future. Psyco, aside from not supporting anything but 32-bit x86, also is limited to a single core, despite being very, very fast -- in some cases, supposedly faster than C. In any case, that is the goal.
And if CPython is that slow, I'll take any performance boost I can get.
Second, it means that any other implementation that doesn't have a GIL is likely going to expose obscure bugs in existing python programs. Well, not bugs, but assumptions that only one Python instruction can run at a time. Not to mention the C extensions...
Well, first, no compiler is "easy". If it is, write me a C compiler that's half as good as gcc.
Second, it's been done. You mention LISP:
And yet today, there are very fast and useful LISP compilers, which do just what you said an "optimizing compiler" can't do -- they make LISP fast enough that it could probably be used as a replacement for C or Java (for most things), if it weren't for all those damned parentheses...
Well, CPAN is better than just about any language. Also, you were expecting to find cheese in the Cheese Shop? They're all out of that!
In any case, CPAN doesn't seem to be much better supported -- often, yes, a developer or two, working in isolation, maybe a bit of peer review.
Also, this is like the argument of Windows being better than Linux, due to number of apps. It's a sad reality that it limits options, but in my experience, Linux is better enough that I'd often rather do a little extra work to make Linux do what I want than buy a Windows program to do the same thing.
I don't think Python is quite there yet, though. Notice how pretty much every one of your Python complaints holds for Perl, except CPAN. But, if Python were fast enough, and had threading that worked, I'd be using it instead of Perl, no question. (For that matter, if Perl6 ever gets released, and if Python gets ported to Parrot -- not very likely, I know, but if it happened -- CPAN would suddenly become available to Python people.)
Which would be great, if it weren't for the fucking GIL. I hate that thing.
Then again, people are willing to deploy Ruby, so at a certain point, CPU is cheaper than programmers. Although I still wish I didn't have to choose.
Well, Perl hasn't replaced Java, and Java hasn't replaced C.
Frankly, I think one of these languages needs to step up and offer something compelling -- or I need to find the one that already has, and still isn't dominating. But I've been looking for years, and still haven't found something that's as dynamic and easy as perl/python/ruby, as portable as Java (even CORA, please), and as fast as C, even though I'm convinced it's possible.
It's not even an issue of better support for concurrency in the language itself.
Personally, I like some of the ideas of Python better than Haskell and Erlang. There have been some very good ways of doing multithreading, even massive multithreading (see Stackless, some of which is now back in the main Python), and making it natural, even with an imperative style of programming. Some implementations (again, see Stackless) make threads so lightweight that you can spawn thousands without being concerned about performance, and the structures used make it natural to do that without any kind of locking issues -- sometimes, without explicit locks at all.
The problem is not with python, the language. It's with python, the interpreter, and all the associated C modules, embedded versions, etc, not to mention Python programs that might assume the same behavior.
Specifically, it's the Global Interpreter Lock. The GIL is the most retarded move I've ever seen in a language. Basically, Python said "We don't want to make the Python interpreter too complicated, so we're going to deliberately remove multicore support." They even support real OS threads, but only one Python instruction may be executed at a time. Which is fucking stupid.
There are a lot of really good things in Python. I'd like to be able to write a good, modern game with Python, but if you figure it may be half as fast as C already, I'm not going to lose another 50% speed because it can't use both cores. (Yes, psyco can make it MUCH faster, close to C. But, psyco doesn't work on 64-bit, which is another kick in the balls for performance.)
Stronger, if by "strong" you're talking about how tightly you cling to that belief. Evolutionists are generally pretty convinced of the accuracy of Evolution, but we are open to a new theory, if it was presented with sufficient evidence.
Sorry, no.
Firefly quote time:
I can respect you, as a person. I respect most people that way -- it takes a lot to convince me that a particular person is beyond help, that it would be impossible to ever teach them to be a decent, intelligent person.
But there is no way in hell you'll get me to respect your beliefs. They are laughably wrong and unfounded, with their closest real proof being a book that is not only old and dusty, but frequently self-contradictory, even in Genesis.
If you are really open to other beliefs and facts, take a read here, but be warned -- not for the faint of heart, and you most certainly will lose some faith when you read that. Have a copy of your Bible ready...
Exactly. It's an arms race, and one which you will lose. Your kids are younger, faster, and smarter than you. If they aren't already, they will be.
And yes, talk to them. No nanny is a substitute for proper parenting.
Even if it did, there's still other possibilities -- compression, for example. (A lot of those movements are going to look the same.)
Let's look at some real numbers, hmm?
And that's for Counter-Strike Source, which, if you don't know, is a very fast-paced FPS which absolutely needs to be as accurate as possible (so people can get headshots, etc). It probably uses several orders of magnitude more bandwidth per player than your typical MMO.
Note, also, that this is server bandwidth needed, not client bandwidth. I'll bet, too, that some of that would go away if we could actually use multicast... *sigh*
Yes. There are also usually signs there which say "take one", as well as a slot that clearly expects 25 cents.
There's generally little chance of anyone being confused about this "honor system", or much incentive for circumventing it -- after all, what use would you have with more than one newspaper?
But notice: In places where there is significant incentive to break the honor system, there's usually significantly more security in place than an honor system. That newspaper box, for instance, might be sitting next to a Coke machine, which, short of vandalism, is only going to give you one Coke for your dollar. (Or your $1.25, as the case may be.)
Why? Well, I don't know about you, but I could drink two cokes. Or drink one, and save one for later. Or drink one, and get one for my friend. None of which is especially true of the newspaper -- I can easily share my one copy with my friend, and there'd be no point in reading two copies, now or later.
Moral or not, when you build your business model on the honor system, don't expect much sympathy when it fails.
Where's it implied?
If the owner has such a wish, they should state it for me, clearly.
And by the way, how do you explain the moral right of a webmaster to push content to me that I don't want, using my bandwidth, CPU, and attention? Sorry, but it's my computer.
If you start paying for my bandwidth, hardware, and power, then we'll talk about me watching your ads. Until then, consider yourself lucky that I generally do not use filtersets, but rather block things manually -- and only after they've sufficiently pissed me off.
Could work. I'm still going to block it.
Not if it's a gigantic, animated Flash thing that popped up right on top of whatever I was actually looking at. Do that, and you guarantee that ad gets blocked, even if it was what I was looking for. Do it enough, and you guarantee some negative brand recognition -- you guarantee that I absolutely will not buy your product, ever.
Which goes back to brand recognition.
In which case, why is it my moral imperative to look at those animations?
I mean, if they have an inherently uninteresting product that I don't want to buy, then their advertisement is a waste of my bandwidth, attention, and patience. If they want my intention, then follow the iPhone's example -- make a product that's interesting enough that a text ad will catch my eye, because I don't block text ads.
A "bargain" which is never spelled out. Period.
I don't mean legally. I mean it's absolutely fucking nowhere to be found, which just leaves a bad taste in my mouth.
Have you ever been to a third-world country? Everyone will be very helpful in some way, but depending on the country and the place, they will often expect some reward -- after the fact. That's right -- some adorable little kid will guide you across the river or whatever, and then demand payment.
This isn't naivete -- they know you might not accept their service, if you knew the cost. And they know you might feel guilty enough to pay them anyway -- after all, you're a foreigner, so you're used to feeling like you've violated local custom, because often, you have -- but in this case, they're just preying on you.
In this case, I would say to the child, if you want to be paid, name your price up front. And I would say that to the webmaster, as well -- if you are so convinced that there's a bargain here, name your terms up front, before I enter the website. Or block me, with an explanation of which ads I must allow through to be unblocked. Or better yet -- use ads that I won't block!
Otherwise, I'll block them, and you'll whine all day about how it's immoral, and you'll get nowhere.
You should be grateful more people don't actually take this attitude. Your revenue would collapse overnight.
My guess is, if people are deliberately blocking your ads, chances are, you have some pretty intrusive ones. Thus, the people who actually manage to make it to your content are those who either don't like the ads, but don't know how to block them, and those who happily block them, and are maybe blissfully unaware.
Maybe you should talk to these guys.
I think their homepage pretty much sums up the typical marketer's mindset, and why I tend to agree with Bill Hicks about this.