The point is that right now, no one needs to do that. Right now, any handset with sufficiently open hardware, I can install my own version of Android without paying anyone.
So, what are they paying Microsoft for? Office compatibility?
I'm not sure when that's a feature. It appeals to my inner software developer, but at the same time, Ruby on Rails has this feature I use all the time -- the ability to deliberately not distinguish between null, an empty string, and a string containing only whitespace.
nil.blank? ''.blank? ' '.blank?
all return true. This more or less matches my experience with Postgres vs MySQL -- Postgres made more sense in many ways, but MySQL had more stuff that just worked, and in the end, neither of them were quite as sexy as CouchDB and friends.
Why would I want to "keep the plebs down"? I want them to become more educated, more self-sufficient, and more nerdy, so I have to do less family tech support.
Given that Android was meant to be free and open source, requiring people to buy Java ME first would kind of undermine that. It's like accusing Mozilla of trying to save money by not implementing H.264.
Well, there's also the fact that Java performance has caught up to the point where it's not quite twice as slow as C++, and faster in pathological cases. And there's the fact that Java, the language, isn't what's in question here -- it's the JVM, which means JRuby, Scala, Clojure, etc.
So it's not just 10 years of Moore's Law, it's 10 years of optimization. Java was pathetically slow. Now it's the fastest thing in its class.
So what would you replace it with? C# isn't necessarily faster, and it's got that wonderful Microsoft lock-in. Anything else is either going to be much slower (perl, python, Ruby) or much more dangerous (C, C++). It's possible there are some obscure Lisps that come close, but we're at the point where all the major optimization research goes into either C/C++ or Java, to the point where CPUs are designed to run C fast, not the other way around.
Oh, and I expect it'll be the other way around -- the free version will be cross-platform, while the premium version will be "vertically integrated" -- might be one Windows implementation, but very likely one more, maybe on Solaris, maybe on "Oracle Unbreakable Linux", but somewhere they can "integrate" it more thoroughly into the system. At least, that'd be the typical move for them, and the smart move -- just another way for them to grab the enterprise by the balls and squeeze, while ignoring everyone else, especially their smaller customers.
When they go out of scope, the object is destroyed... The C++ compiler knows when the object goes out of scope and will call the destructor at that time.
Which means the destructor now needs to be called, along with whatever code the 'delete' keyword actually compiles to. And again, this is extra bytes of code.
But, again, I'd be surprised if a GC-based language wouldn't use reference counting. Perl, for example, uses reference counting exclusively *because* it's much faster than other schemes. It has the same drawback that C++ has which is that circular references may leak.
Well, and I know for a fact Java, Ruby, and any sane JavaScript interpreter at least has some sort of actual garbage collector, vaguely like mark-and-sweep, so they don't have to deal with circular references. Once they have that, I don't see the point of reference counting.
As I said, there's not much more to reference counting other than incrementing a value when the object is assigned a new owner and decrementing that same value when it's being released. The allocation is done once and there is a single delete.
It's that value, plus the actual delete.
If you have a link to that paper I'd like to see it.
Not readily. I think the best I can do at the moment is point out that the wikipedia article seems to agree with me. There's also this, which again suggests that garbage collection can match or beat malloc/free -- and that's without mentioning refcounting, which brings some additional overhead of its own.
When delete is called (or free in C), the memory used by the object is made available immediately. This requires a call to the C or C++ library, if that's what you mean, but this is not a system call.
Right -- this is what I mean by the smart, optimized way. It's not a system call every time (though it is sometimes), and it isn't entirely without cost.
But because it's not a system call, the memory is only available to this program immediately, which is why I'd imagine (though I don't have a link to back it up) that on an embedded system, if you were particularly starved for memory, you might want to make it immediately available to other programs, which necessarily involves talking to the system.
I don't know if GC uses refcounting at all, though I suppose it's possible.
However, the point is that the reference counting itself isn't just the extra bytes of RAM, it's the extra bytes of CPU cache. It's the difference between a chunk of your program fitting in cache and running insanely fast, then being paged out for GC to run (and GC sits in cache during its run), and that same program needing the refcounting, malloc/free, and a bunch of other housekeeping stuff always hot in cache, meaning it's likely your program will have to have chunks of it paged in and out of cache much more often.
Paradoxical, and I'm not convinced, so I'd want to benchmark it. It does seem plausible, and I did read it in a respectable-looking paper.
So no, I wasn't talking about the GC keeping anything "in memory" (as opposed to what?) -- yes, once the object isn't referenced, its data is meaningless.
And yes, I'm pretty sure malloc/new implementations have, at least at one point, been direct system calls. I imagine they still are, on some embedded platforms. When you're starved for memory, it makes sense -- you want everything free'd for other processes to use as soon as you possibly can.
Good to know about boost -- though now I'm curious what the difference is.
That's true. It's also true of other languages but there are probably more issues with C and C++ than there are with many other languages.
Well, in particular, when something goes wrong in Java, the typical result is a NullPointerException, which can be caught and managed, and which is much easier to debug compared to with C, where the typical result is a segfault, and it can be difficult or impossible to track down.
For most purposes, smart pointers will do the job real fine. There's none to little overhead and you get the advantage that you know when your objects get destroyed.
Well, again, what do you mean? If we're talking about std::auto_ptr -- that is, a refcounting pointer -- then while I haven't done the benchmarks to back it up, I'd guess refcounting can actually be worse than GC in terms of performance. In particular, with a garbage-collected language, the garbage collector presumably runs at intervals, and is highly optimized -- the whole thing probably fits in cache. This means when the GC isn't running, there's no memory-management-related code running. By contrast, with refcounting, you're at least dealing with the reference count all the time, and you're making calls to delete or free more often...
On the other hand,
C and C++ will usually have much lower memory requirement and there's no interpreter to load.
I don't think an interpreter alone is an issue, and I'm skeptical that the memory requirements are that significant, but if nothing else, GC would tend to leave objects around for awhile before attempting to collect them, whereas C and C++ can collect them immediately. In practice, for performance reasons, you'd probably retain a pool of allocated memory so you don't have to talk to the OS as often -- I think modern malloc implementations do this -- but on a system truly starved for memory, it helps that every byte is released as soon as it can be.
It's just that for the vast majority of applications, GC and other modern, high-level tools are more than worth a large performance penalty, and the difference is getting smaller all the time.
In theory, it's simple. In practice, not so much -- the bugs which can happen here are numerous and subtle.
There are also plenty of GC libraries for C++
And my point here was that by the time you use a GC library, why not get the full benefit of a safer, saner language? You've already got most of the overhead of something like Java, why not also get the runtime optimizations and the protection from buffer overflows and segfaults, too?
it's possible to select which objects are GC candidates and which are not
And what'd be the criteria for which objects should be GC'd and which you want to handle yourself?
I'd guess the objects which you want to manage yourself are either places where you're interacting with code, or particularly performance-critical parts of your application. But if you're doing it that way, it seems to me that I get most of the same benefit by coding in Ruby, and dropping down to C for those two cases.
It seems you could get similar benefits in Java if JNI wasn't such a bitch -- and even as it is, it isn't that bad compared to pretty much anything else in C.
I just don't think the memory leak issues in C++ are as bad as many people try to make them to be.
I don't think they're particularly bad either, but I don't see any reason I, as a programmer, should have to deal with them. I certainly don't think C++ has any real place in web development -- except, as I mentioned, in particularly performance-critical bits, especially when they can be abstracted into libraries. I trust the HTTP parser in nginx or Apache a lot more than any code I wrote myself, but anything I write, I trust a lot more in Ruby or JavaScript than in C or C++.
You can't ignore IE. Like it or loathe it (the former only happens if you aren't actually a web developer), IE still has a significant market share. Not supporting it on any site with a commercial goal is practically suicide.
Supporting old versions in a limited capacity, with a suggestion to upgrade your browser, doesn't seem to be hurting YouTube any.
And, yes, IE's compatibility issues are significantly worse than native development issues. I can pick a framework to develop with, say Java+SWT, and have the results work on every common target platform with almost no platform-specific work required.
But you're incapable of picking a framework to develop with, say JQuery or IE9.js, which has the results work on every common target platform with almost no platform-specific work required?
And again, throw out IE, particularly old versions of IE, and it becomes a decent platform. If needed, add it back in with something like IE9.js or Chrome Frame.
Yes, Chrome Frame. You're going to make your users download a JVM and your native app, but it's too much to ask them to download a browser, or even a browser plugin?
It's worth mentioning, too: IE has fallen below 50%, and that's in general. Among technically-inclined people, it's far lower. Only about 15% are on IE6, and again, the platform massively improves when you don't have to support that anymore.
It's true that GC'd languages can potentially leak memory, but the possibilities are small and almost require you to deliberately subvert what the garbage collector otherwise does for you.
By contrast, it's trivially easy to leak memory in a non-garbage-collected language, and again, "smart pointers" (just refcounting, right?) are still more likely to leak memory, and potentially add even more overhead than real GC.
So, may as well just use GC, and if you're doing that, may as well just use something like Java. (Though not, I'd hope, Java itself.)
Well, what better keyboard design would you suggest?
I mean, so long as we're still coding in English, most of the keyboard is going to be the standard alphabet. There's not too much space beyond that for us to hit quickly while typing. If you want to add standard logic symbols, that probably means means killing something else -- and what would you suggest?
If it's just a one-to-one substitution, even if you managed to configure your text editor to only swap, say, % for a logical implication symbol (looks vaguely like =>), you've made it truly obnoxious for people to start using your language. If you make it multiple keystrokes -- say you take => and replace that with implication -- then really, the language you've produced would work just as well in ASCII, so you're just introducing unnecessary confusion.
I probably wouldn't mind too much if an editor did the work for me, allowing me to still type in ASCII that looks reasonably close, and see it converted to the appropriate UTF8... But while I appreciate awesome tools, from text editors to full-featured IDEs, I prefer a language which doesn't force me to use any particular software. All my text editors, SCMs, pretty much everything I could ever possibly want to fire at a piece of software knows how to deal with ASCII. While most of it would be fine reading Unicode, I have no idea how any of it deals with allowing me to write Unicode.
It really doesn't matter how you slice it up, the result is that my KDE4-powered desktop and my KDE4-enabled apps are at once a big step forward and a big step back. This was true well after the official 4.0 release of any of the above, and even 4.5 is still missing much of the functionality that made 3.5 great.
Erm, doesn't Safari just use QuickTime for video? My understanding was that all one had to do is install the Theora QuickTime plugin if one wanted Theora H.264 in Safari. It's just that Apple has refused to bundle it in any sense.
It's Mozilla which has been the hold-out -- most of the Mozilla developers I've talked to have been openly hostile to such a design in Firefox, mostly because it would give the users the choice of installing whatever codecs they want, which might lead to H.264 winning the war.
By the time you add real garbage collection to C++, you're rapidly approaching a point where you may as well use Java. Anything short of that, like auto_ptr, is just a band-aid -- you still have plenty of ways to leak memory, and plenty of potential for buffer overflows. Contrast this to a sane, modern language, where these problems cannot exist.
Again, what would you suggest? If you're going to continue dismissing things I propose as crap without offering anything useful in its place, it's really not worth talking to you. If C++ is actually what you're suggesting, say so, and defend it.
Yes, Facebook runs PHP compiled to C++ using HipPop
And that's pretty much my point exactly. Avoids the problems of C++, mostly, and all their existing PHP code gets faster just by tuning the language.
In the meantime, I don't see why I should adopt an ugly, dangerous language to solve a performance problem which, frankly, I just don't see. A properly designed app should be able to scale, which means you can throw hardware at the problem. When you're big enough that this isn't feasible, you're probably big enough that you can afford to build something like HipHop.
I think he's talking about the RoR model, where the view is essentially a template. That annoyed me too, but the framework I used is flexible enough to allow me to use Views as proper objects, which then use Templates.
There's Erector, which allows views to be code which ultimately generates HTML -- similar to a template, but not identical.
But I have to ask: In a Web context, what else would make sense as a view, particularly if you're deliberately doing fat models?
Re:So this is what passes for clever these days
on
USB 'Dead Drops'
·
· Score: 1
You assert there's no concept. By definition there is, or there'd be nothing for you to talk about. It could be a stupid concept, but it'd be a concept nonetheless.
Cities include downtown and suburbs, so yes, "urban" is required. But we can call it "urban kind of place" if "environment" offends your sensibilities.
"To see what happens" is just about every experiment, ever. All scientific progress has, as a necessary component, "Ok, this looks like it might be interesting. Let's try it and see what happens."
Again, more baseless assertions. Keep in mind, I'm not GP, so it doesn't really matter to me that you're deliberately patronizing them here, it's just that you're doing so without adding anything to the discussion. LOLing may be funny for you, but still doesn't tell us why you think GP's crap.
Not true. The best systems are idempotent on the server side, storing any state associated with a single "session" in the cookie itself. This is precisely so that these different servers only have to communicate permanent state, if that.
It would help if you qualified or explained a single one of these blanket assertions you've made.
What data loss is caused by MySQL? And while perhaps a NoSQL database "du jour" causes data loss, are you suggesting that the major ones like Couch, Cassandra, Mongo, etc all have serious data loss issues?
If so, specifics or it didn't happen. File a bug report, at the very least.
I don't have much good to say about PHP, but didn't someone recently roll out a compiler for it? I can't imagine PHP performance is a significant bottleneck, especially as people run successful websites written in everything from Java to Ruby. And what would you suggest in its place, C++? Gee, thanks, now we can spend all our time focusing on memory leaks and buffer overflows instead.
It's possible it's the wrong language for the job, but if you want to make that case, you've got to suggest an alternative.
Similarly, for JavaScript -- say what? Chrome compiles JavaScript to native code, and Firefox just got faster than Chrome. Both of them are now more than competitive with languages typically used for server-side development, where you'd expect performance to be a much bigger bottleneck. Indeed, there's at least one modern server-side JavaScript framework, written for V8, Chrome's JavaScript engine.
And again, is a potential alternative actually better for a given problem? Again, specific examples. There are applications which actually have performance needs which suggest they should be native apps, and people generally don't try those as web apps. Then there's a very, very thin border where a web app makes sense on the Web, but would be faster native -- but often, it's the design that's shite, not the technologies themselves.
If you ignore IE, browser compatibilities aren't so bad. Even if you include IE, are they significantly worse than OS incompatibilities if you decided to go native?
Finally, MVC. Exactly how is this "bastardized"? How would you do it differently, if you were writing a web framework? At least that's a specific example -- but you mentioned "software development and programming theories," plural, and you've only mentioned one.
It's possible you've got some good points, but you haven't backed them up at all.
...and I think you just made the best case for getting a phone which isn't locked down. iOS doesn't let you do this, people had to hack it brutally to force the issue. Some phones, however, welcome it.
They needed this time for refactoring and building the knowledge.
That's fair. This wasn't meant to be a criticism of Mozilla in any way -- rather, I was pointing out how, good or bad, it took them five years with an existing codebase to get a decent browser out. It seems reasonable to expect the same result if they tried again with something like OpenOffice -- which already has its own project anyway.
Slashdot Mirror
The point is that right now, no one needs to do that. Right now, any handset with sufficiently open hardware, I can install my own version of Android without paying anyone.
So, what are they paying Microsoft for? Office compatibility?
I'm not sure when that's a feature. It appeals to my inner software developer, but at the same time, Ruby on Rails has this feature I use all the time -- the ability to deliberately not distinguish between null, an empty string, and a string containing only whitespace.
nil.blank?
''.blank?
' '.blank?
all return true. This more or less matches my experience with Postgres vs MySQL -- Postgres made more sense in many ways, but MySQL had more stuff that just worked, and in the end, neither of them were quite as sexy as CouchDB and friends.
Why would I want to "keep the plebs down"? I want them to become more educated, more self-sufficient, and more nerdy, so I have to do less family tech support.
Given that Android was meant to be free and open source, requiring people to buy Java ME first would kind of undermine that. It's like accusing Mozilla of trying to save money by not implementing H.264.
Well, there's also the fact that Java performance has caught up to the point where it's not quite twice as slow as C++, and faster in pathological cases. And there's the fact that Java, the language, isn't what's in question here -- it's the JVM, which means JRuby, Scala, Clojure, etc.
So it's not just 10 years of Moore's Law, it's 10 years of optimization. Java was pathetically slow. Now it's the fastest thing in its class.
So what would you replace it with? C# isn't necessarily faster, and it's got that wonderful Microsoft lock-in. Anything else is either going to be much slower (perl, python, Ruby) or much more dangerous (C, C++). It's possible there are some obscure Lisps that come close, but we're at the point where all the major optimization research goes into either C/C++ or Java, to the point where CPUs are designed to run C fast, not the other way around.
Oh, and I expect it'll be the other way around -- the free version will be cross-platform, while the premium version will be "vertically integrated" -- might be one Windows implementation, but very likely one more, maybe on Solaris, maybe on "Oracle Unbreakable Linux", but somewhere they can "integrate" it more thoroughly into the system. At least, that'd be the typical move for them, and the smart move -- just another way for them to grab the enterprise by the balls and squeeze, while ignoring everyone else, especially their smaller customers.
JRuby can do that (just by calling Swing directly), so I imagine Scala can, to.
The problem here is the JVM, not Java the language.
That's just it, though:
When they go out of scope, the object is destroyed... The C++ compiler knows when the object goes out of scope and will call the destructor at that time.
Which means the destructor now needs to be called, along with whatever code the 'delete' keyword actually compiles to. And again, this is extra bytes of code.
But, again, I'd be surprised if a GC-based language wouldn't use reference counting. Perl, for example, uses reference counting exclusively *because* it's much faster than other schemes. It has the same drawback that C++ has which is that circular references may leak.
Well, and I know for a fact Java, Ruby, and any sane JavaScript interpreter at least has some sort of actual garbage collector, vaguely like mark-and-sweep, so they don't have to deal with circular references. Once they have that, I don't see the point of reference counting.
As I said, there's not much more to reference counting other than incrementing a value when the object is assigned a new owner and decrementing that same value when it's being released. The allocation is done once and there is a single delete.
It's that value, plus the actual delete.
If you have a link to that paper I'd like to see it.
Not readily. I think the best I can do at the moment is point out that the wikipedia article seems to agree with me. There's also this, which again suggests that garbage collection can match or beat malloc/free -- and that's without mentioning refcounting, which brings some additional overhead of its own.
When delete is called (or free in C), the memory used by the object is made available immediately. This requires a call to the C or C++ library, if that's what you mean, but this is not a system call.
Right -- this is what I mean by the smart, optimized way. It's not a system call every time (though it is sometimes), and it isn't entirely without cost.
But because it's not a system call, the memory is only available to this program immediately, which is why I'd imagine (though I don't have a link to back it up) that on an embedded system, if you were particularly starved for memory, you might want to make it immediately available to other programs, which necessarily involves talking to the system.
I don't know if GC uses refcounting at all, though I suppose it's possible.
However, the point is that the reference counting itself isn't just the extra bytes of RAM, it's the extra bytes of CPU cache. It's the difference between a chunk of your program fitting in cache and running insanely fast, then being paged out for GC to run (and GC sits in cache during its run), and that same program needing the refcounting, malloc/free, and a bunch of other housekeeping stuff always hot in cache, meaning it's likely your program will have to have chunks of it paged in and out of cache much more often.
Paradoxical, and I'm not convinced, so I'd want to benchmark it. It does seem plausible, and I did read it in a respectable-looking paper.
So no, I wasn't talking about the GC keeping anything "in memory" (as opposed to what?) -- yes, once the object isn't referenced, its data is meaningless.
And yes, I'm pretty sure malloc/new implementations have, at least at one point, been direct system calls. I imagine they still are, on some embedded platforms. When you're starved for memory, it makes sense -- you want everything free'd for other processes to use as soon as you possibly can.
Good to know about boost -- though now I'm curious what the difference is.
Chrome does use GTK+ on Linux. Not for everything, but WebKit needs some sort of widget toolkit.
That's true. It's also true of other languages but there are probably more issues with C and C++ than there are with many other languages.
Well, in particular, when something goes wrong in Java, the typical result is a NullPointerException, which can be caught and managed, and which is much easier to debug compared to with C, where the typical result is a segfault, and it can be difficult or impossible to track down.
For most purposes, smart pointers will do the job real fine. There's none to little overhead and you get the advantage that you know when your objects get destroyed.
Well, again, what do you mean? If we're talking about std::auto_ptr -- that is, a refcounting pointer -- then while I haven't done the benchmarks to back it up, I'd guess refcounting can actually be worse than GC in terms of performance. In particular, with a garbage-collected language, the garbage collector presumably runs at intervals, and is highly optimized -- the whole thing probably fits in cache. This means when the GC isn't running, there's no memory-management-related code running. By contrast, with refcounting, you're at least dealing with the reference count all the time, and you're making calls to delete or free more often...
On the other hand,
C and C++ will usually have much lower memory requirement and there's no interpreter to load.
I don't think an interpreter alone is an issue, and I'm skeptical that the memory requirements are that significant, but if nothing else, GC would tend to leave objects around for awhile before attempting to collect them, whereas C and C++ can collect them immediately. In practice, for performance reasons, you'd probably retain a pool of allocated memory so you don't have to talk to the OS as often -- I think modern malloc implementations do this -- but on a system truly starved for memory, it helps that every byte is released as soon as it can be.
It's just that for the vast majority of applications, GC and other modern, high-level tools are more than worth a large performance penalty, and the difference is getting smaller all the time.
It's not that complicated.
In theory, it's simple. In practice, not so much -- the bugs which can happen here are numerous and subtle.
There are also plenty of GC libraries for C++
And my point here was that by the time you use a GC library, why not get the full benefit of a safer, saner language? You've already got most of the overhead of something like Java, why not also get the runtime optimizations and the protection from buffer overflows and segfaults, too?
it's possible to select which objects are GC candidates and which are not
And what'd be the criteria for which objects should be GC'd and which you want to handle yourself?
I'd guess the objects which you want to manage yourself are either places where you're interacting with code, or particularly performance-critical parts of your application. But if you're doing it that way, it seems to me that I get most of the same benefit by coding in Ruby, and dropping down to C for those two cases.
It seems you could get similar benefits in Java if JNI wasn't such a bitch -- and even as it is, it isn't that bad compared to pretty much anything else in C.
I just don't think the memory leak issues in C++ are as bad as many people try to make them to be.
I don't think they're particularly bad either, but I don't see any reason I, as a programmer, should have to deal with them. I certainly don't think C++ has any real place in web development -- except, as I mentioned, in particularly performance-critical bits, especially when they can be abstracted into libraries. I trust the HTTP parser in nginx or Apache a lot more than any code I wrote myself, but anything I write, I trust a lot more in Ruby or JavaScript than in C or C++.
You can't ignore IE. Like it or loathe it (the former only happens if you aren't actually a web developer), IE still has a significant market share. Not supporting it on any site with a commercial goal is practically suicide.
Supporting old versions in a limited capacity, with a suggestion to upgrade your browser, doesn't seem to be hurting YouTube any.
And, yes, IE's compatibility issues are significantly worse than native development issues. I can pick a framework to develop with, say Java+SWT, and have the results work on every common target platform with almost no platform-specific work required.
But you're incapable of picking a framework to develop with, say JQuery or IE9.js, which has the results work on every common target platform with almost no platform-specific work required?
And again, throw out IE, particularly old versions of IE, and it becomes a decent platform. If needed, add it back in with something like IE9.js or Chrome Frame.
Yes, Chrome Frame. You're going to make your users download a JVM and your native app, but it's too much to ask them to download a browser, or even a browser plugin?
It's worth mentioning, too: IE has fallen below 50%, and that's in general. Among technically-inclined people, it's far lower. Only about 15% are on IE6, and again, the platform massively improves when you don't have to support that anymore.
It's true that GC'd languages can potentially leak memory, but the possibilities are small and almost require you to deliberately subvert what the garbage collector otherwise does for you.
By contrast, it's trivially easy to leak memory in a non-garbage-collected language, and again, "smart pointers" (just refcounting, right?) are still more likely to leak memory, and potentially add even more overhead than real GC.
So, may as well just use GC, and if you're doing that, may as well just use something like Java. (Though not, I'd hope, Java itself.)
Well, what better keyboard design would you suggest?
I mean, so long as we're still coding in English, most of the keyboard is going to be the standard alphabet. There's not too much space beyond that for us to hit quickly while typing. If you want to add standard logic symbols, that probably means means killing something else -- and what would you suggest?
If it's just a one-to-one substitution, even if you managed to configure your text editor to only swap, say, % for a logical implication symbol (looks vaguely like =>), you've made it truly obnoxious for people to start using your language. If you make it multiple keystrokes -- say you take => and replace that with implication -- then really, the language you've produced would work just as well in ASCII, so you're just introducing unnecessary confusion.
I probably wouldn't mind too much if an editor did the work for me, allowing me to still type in ASCII that looks reasonably close, and see it converted to the appropriate UTF8... But while I appreciate awesome tools, from text editors to full-featured IDEs, I prefer a language which doesn't force me to use any particular software. All my text editors, SCMs, pretty much everything I could ever possibly want to fire at a piece of software knows how to deal with ASCII. While most of it would be fine reading Unicode, I have no idea how any of it deals with allowing me to write Unicode.
Pretty much.
It really doesn't matter how you slice it up, the result is that my KDE4-powered desktop and my KDE4-enabled apps are at once a big step forward and a big step back. This was true well after the official 4.0 release of any of the above, and even 4.5 is still missing much of the functionality that made 3.5 great.
Erm, doesn't Safari just use QuickTime for video? My understanding was that all one had to do is install the Theora QuickTime plugin if one wanted Theora H.264 in Safari. It's just that Apple has refused to bundle it in any sense.
It's Mozilla which has been the hold-out -- most of the Mozilla developers I've talked to have been openly hostile to such a design in Firefox, mostly because it would give the users the choice of installing whatever codecs they want, which might lead to H.264 winning the war.
By the time you add real garbage collection to C++, you're rapidly approaching a point where you may as well use Java. Anything short of that, like auto_ptr, is just a band-aid -- you still have plenty of ways to leak memory, and plenty of potential for buffer overflows. Contrast this to a sane, modern language, where these problems cannot exist.
Again, what would you suggest? If you're going to continue dismissing things I propose as crap without offering anything useful in its place, it's really not worth talking to you. If C++ is actually what you're suggesting, say so, and defend it.
Yes, Facebook runs PHP compiled to C++ using HipPop
And that's pretty much my point exactly. Avoids the problems of C++, mostly, and all their existing PHP code gets faster just by tuning the language.
In the meantime, I don't see why I should adopt an ugly, dangerous language to solve a performance problem which, frankly, I just don't see. A properly designed app should be able to scale, which means you can throw hardware at the problem. When you're big enough that this isn't feasible, you're probably big enough that you can afford to build something like HipHop.
I think he's talking about the RoR model, where the view is essentially a template. That annoyed me too, but the framework I used is flexible enough to allow me to use Views as proper objects, which then use Templates.
There's Erector, which allows views to be code which ultimately generates HTML -- similar to a template, but not identical.
But I have to ask: In a Web context, what else would make sense as a view, particularly if you're deliberately doing fat models?
You assert there's no concept. By definition there is, or there'd be nothing for you to talk about. It could be a stupid concept, but it'd be a concept nonetheless.
Cities include downtown and suburbs, so yes, "urban" is required. But we can call it "urban kind of place" if "environment" offends your sensibilities.
"To see what happens" is just about every experiment, ever. All scientific progress has, as a necessary component, "Ok, this looks like it might be interesting. Let's try it and see what happens."
Again, more baseless assertions. Keep in mind, I'm not GP, so it doesn't really matter to me that you're deliberately patronizing them here, it's just that you're doing so without adding anything to the discussion. LOLing may be funny for you, but still doesn't tell us why you think GP's crap.
I can definitely see why you'd want it on a tablet, even if you don't on a phone.
What does that tell you about how bad Flash is that HTML5 is such a massive improvement over it?
Not true. The best systems are idempotent on the server side, storing any state associated with a single "session" in the cookie itself. This is precisely so that these different servers only have to communicate permanent state, if that.
It would help if you qualified or explained a single one of these blanket assertions you've made.
What data loss is caused by MySQL? And while perhaps a NoSQL database "du jour" causes data loss, are you suggesting that the major ones like Couch, Cassandra, Mongo, etc all have serious data loss issues?
If so, specifics or it didn't happen. File a bug report, at the very least.
I don't have much good to say about PHP, but didn't someone recently roll out a compiler for it? I can't imagine PHP performance is a significant bottleneck, especially as people run successful websites written in everything from Java to Ruby. And what would you suggest in its place, C++? Gee, thanks, now we can spend all our time focusing on memory leaks and buffer overflows instead.
It's possible it's the wrong language for the job, but if you want to make that case, you've got to suggest an alternative.
Similarly, for JavaScript -- say what? Chrome compiles JavaScript to native code, and Firefox just got faster than Chrome. Both of them are now more than competitive with languages typically used for server-side development, where you'd expect performance to be a much bigger bottleneck. Indeed, there's at least one modern server-side JavaScript framework, written for V8, Chrome's JavaScript engine.
And again, is a potential alternative actually better for a given problem? Again, specific examples. There are applications which actually have performance needs which suggest they should be native apps, and people generally don't try those as web apps. Then there's a very, very thin border where a web app makes sense on the Web, but would be faster native -- but often, it's the design that's shite, not the technologies themselves.
If you ignore IE, browser compatibilities aren't so bad. Even if you include IE, are they significantly worse than OS incompatibilities if you decided to go native?
Finally, MVC. Exactly how is this "bastardized"? How would you do it differently, if you were writing a web framework? At least that's a specific example -- but you mentioned "software development and programming theories," plural, and you've only mentioned one.
It's possible you've got some good points, but you haven't backed them up at all.
...and I think you just made the best case for getting a phone which isn't locked down. iOS doesn't let you do this, people had to hack it brutally to force the issue. Some phones, however, welcome it.
They needed this time for refactoring and building the knowledge.
That's fair. This wasn't meant to be a criticism of Mozilla in any way -- rather, I was pointing out how, good or bad, it took them five years with an existing codebase to get a decent browser out. It seems reasonable to expect the same result if they tried again with something like OpenOffice -- which already has its own project anyway.