I read up to when you demonstrate you know not what you're talking about.
The fundamental problem with C was the "array=pointer" concept You can't do pointer arithmetics on arrays, C or C++. Please shut up.
If array sizes were carried along with arrays, we'd have far less trouble. Even FORTRAN has conformant array parameters. That should have been fixed in C++ Ever heard of STL containers? Vector? List? Tried reading TFA? They're mentioned there. Please shut up.
You don't know C++, the STL, and are commenting on things you don't understand. While up to know I've read many sensible critics on the language in this thread, unfortunately, the majority of C++ detractors just don't understand the language and are frustrated by the fact, it seems.
I'm not saying that C++ is the ultimate tool. But it is a very good and powerful one, as are C#, Java, and many others, for that matter, with their strengths and weaknesses. It just seems it is the one that is the least understood.
Shift? What shift? With the Vista debacle, one would expect Linux to grow in the desktop market share. Did that happen? Not as it was expected. If Vista didn't caught up, people also didn't switch to Linux. They stuck with XP. Linux in the Desktop will take some 4 more years to come. And it won't be all that great, as it will be the time it takes to make it more "windowsy" (KDE and Gnome, that is).
Yes I've lost any hope on Linux taking over. Linux was taken over by Windows, in the desktop front, at least. I'd bet we'll see Windows 'round for a very good time yet. And very live. Only then it will begin to decline (some 4 years still).
I hope you're trying to say that the metaphor was poor. If not, then I can only understand you're trying to say that HTTP should be designed specifically to transport flash content. I really hope that is not the case, because it would be the same as having every truck in the world being designed to transport horses, even those which would end up being used to transport pigs or whatever.
Assuming the first, replace horses by potatoes, or whatever suits you better, it really doesn't matter as long as you get the general idea.
Well, I see everything inside the browser as content, but as I am miles away from web development (and happy for it;) ) my view is pretty myopic in that sense. In other words, I think a usefull flash application is yet to be born. But then again, I might not be getting the whole picture. That said, I agree that W3C should pay more attention to this "black hole" in the web infrastructure, given it proves to really be a black hole.
You're missing the point the parent was focusing on. The question is not whether flash is useful or not, and should be standardized or not. The question is wtf flash standardization has to do with the HTTP protocol. The summary is (miserably) trying to imply there is something which should be modified in the next version of HTTP so as to benefit the usage of flash in some (mysterious, IMO) way.
Flash is a content format, HTTP a network protocol. They're as related as horses and trucks carrying horses.
If that large program (mark I) wasn't built on top of a library (or somethin'), which in turn was designed for reuse, you'll get in trouble trying to reuse that code. Either:
1. You refactor the large program to reach that structure, or;
2. You start the new one from scratch.
Scavenging is scavenging, be it code or corpses, and is a lowly thing to do no matter what. You want tools for that? Go grab some cutlasses and shovels, they've been around for quite some time.
That's a pretty specific database/case. I for one, would rather be on the (IMHO) safer side, and have the infrastructure ready in case a DB server change is required, and the new one does not support that functionality.
OK, this was 4 years ago, but what guarantees it won't happen again? Granted, SSH and friends also have had/will have their own bunch of problems. But that's beside the point, all software will. However, I'd like to ask, in which would you trust more, on a DB for implementing encryption or on an SSH server?
Given, I think TFA goes a little bit too far on the sensationalism, but I doubt all those servers are properly configured with encrypted connections, and god knows what else might be open besides the DB server.
Bottom line: it's not the end of the world, but it's not good news either.
Even if you need to go through "teh internets" to access your (your application's) DB server, you should at the very least do so through an SSH tunnel, preferably using certificate authentication. That in itself eliminates the need for the open DB server port on the remote interface. Otherwise, AFAIK, someone could sniff your SQL queries and find out the database user/password, just to mention one possible issue.
Even at the low end, however, image is everything. The gPC is built using tiny components, but put inside a full-size case because research indicates that Wal-Mart shoppers are so unsophisticated they equate physical size with capability. I'm speechless.
Although her opinion is not completely out of track, IMHO, it seems Ms. Schroeder doesn't know much about code. You can have pretty shinning code which does all that awful samsung stuff she talks about, for example. What the code does and how it was written are very different things.
Also, have they fixed the damn thing (OOo)? Last I checked, the thing it enjoyed spending its (and mine) time the most was crashing and "restoring" its own documents. I think they didn't take that into account in TFA (and no, I didn't read it; any article which chooses OOo over office, heck, even '97, as of now, isn't worth reading, unfortunately).
This concept of 'process expression' is, he says, a common thread running through the various disciplines of computer science. "A logic circuit is an expression of a logical process; an architecture is an expression of a continuously acting process to interpret symbolically expressed processes; a program is a symbolic expression of a process; a programming language is an environment within which to create symbolic process expression; a compiler is an expression of a process that translates between symbolic process expressions in different languages; an operating system is an expression of a process that manages the interpretation of other process expressions; any application is an expression of the application process." Marijuana is baaaad, mmkay? Drugs are baaad... don't do drugs, mmkay? Or else you'll also be baaaad, mmkay?
Well, under *nixes, there's a little thingy called "su", and its partner, "sudo", with which you do all the "privileged" work you have to without the annoying "elevation prompts". I use vista at work and ubuntu at home. Ask me which of the two is the most "friendly" (to me) in this respect. Sure, users who aren't familiar with the command line are doomed to be harassed by annoying dialogs. Poor bastards, but hey, it's their fault spammers rule the nets, so it's well deserved (HA!).
It would be interesting that you keep an eye in compatibility with some solutions which build upon the debian package system, such as debtags: http://debtags.alioth.debian.org/, for instance.
You will be surprised to know that O(1) is really too good not to have any side-effects on fairness to all tasks. No I won't. AFAIK, O(1) is generally too good for any algorithm that does something useful, given the size of your input varies (n processes). With an input of size n, O(n^k) is generally (i.e. not considering a specific algorithm) acceptable, O(n) is generally good, O(log n) is generally very good and O(1) is generally suppa-duppa doubleplusgood.
DbC doesn't incur any runtime cost if you choose not to bother - any good contract system allows you to turn off contract checking for production code. Runtime checks should be left turned on even on production environment, methinks. The performance hit you suffer is not that great, generally. If it *really* is that great, you should be somehow able to identify where the runtime check is mostly contributing for the performance hit and disable the checks only in those most affected modules. By using such strategy, you are then able to take the most advantage (i.e. greater return of your investment) from that checking code you wrote (by using assertions, DbC, or whatever else will do the type of checking you need).
[...] and there are some times you will be typing arcane commands into a terminal window, hoping for the program to do what you want. Mwwwahaaaaa, I am a great magician! Your clothes are red!
"Quick web scripts are way easier than developing an application if only for the fact that you don't need to figure out how to use networking in whatever language you'd be working in."
Uhmm... exactly when the HTTP protocol was banned from the networking family? Granted, you don't need to implement it into your CGI web app, but if you don't have at least a very basic understanding of it you won't get to far, IMO.
There's another reason why a person with a businness degree will succeed better than one with a CS degree in a businness environment. Code in comercial applications sucks, for the most part. So, any code writing person with a Businness degree is able to do it. If you don't have good and solid understanding of semantics, algorithm complexity, data structures and the underlying computing model(s), you are a code writing person, no matter how good you claim you are in your pet language. But you are no programmer. I'm not saying that in order to be a programmer you must have written a compiler. But you really should understand how one would be built, and be able to do so, if it be the case.
Slashdot Mirror
Shift? What shift? With the Vista debacle, one would expect Linux to grow in the desktop market share. Did that happen? Not as it was expected. If Vista didn't caught up, people also didn't switch to Linux. They stuck with XP. Linux in the Desktop will take some 4 more years to come. And it won't be all that great, as it will be the time it takes to make it more "windowsy" (KDE and Gnome, that is). Yes I've lost any hope on Linux taking over. Linux was taken over by Windows, in the desktop front, at least. I'd bet we'll see Windows 'round for a very good time yet. And very live. Only then it will begin to decline (some 4 years still).
I hope you're trying to say that the metaphor was poor. If not, then I can only understand you're trying to say that HTTP should be designed specifically to transport flash content. I really hope that is not the case, because it would be the same as having every truck in the world being designed to transport horses, even those which would end up being used to transport pigs or whatever.
Assuming the first, replace horses by potatoes, or whatever suits you better, it really doesn't matter as long as you get the general idea.
Well, I see everything inside the browser as content, but as I am miles away from web development (and happy for it ;) ) my view is pretty myopic in that sense. In other words, I think a usefull flash application is yet to be born. But then again, I might not be getting the whole picture. That said, I agree that W3C should pay more attention to this "black hole" in the web infrastructure, given it proves to really be a black hole.
Perhaps the acronyms the original poster was searching for could be found here: http://developers.slashdot.org/article.pl?sid=07/12/16/1656245&from=rss
You're missing the point the parent was focusing on. The question is not whether flash is useful or not, and should be standardized or not. The question is wtf flash standardization has to do with the HTTP protocol. The summary is (miserably) trying to imply there is something which should be modified in the next version of HTTP so as to benefit the usage of flash in some (mysterious, IMO) way. Flash is a content format, HTTP a network protocol. They're as related as horses and trucks carrying horses.
If that large program (mark I) wasn't built on top of a library (or somethin'), which in turn was designed for reuse, you'll get in trouble trying to reuse that code. Either: 1. You refactor the large program to reach that structure, or; 2. You start the new one from scratch. Scavenging is scavenging, be it code or corpses, and is a lowly thing to do no matter what. You want tools for that? Go grab some cutlasses and shovels, they've been around for quite some time.
That's a pretty specific database/case. I for one, would rather be on the (IMHO) safer side, and have the infrastructure ready in case a DB server change is required, and the new one does not support that functionality.
http://vil.nai.com/vil/Content/v_99992.htm
OK, this was 4 years ago, but what guarantees it won't happen again? Granted, SSH and friends also have had/will have their own bunch of problems. But that's beside the point, all software will. However, I'd like to ask, in which would you trust more, on a DB for implementing encryption or on an SSH server?
Given, I think TFA goes a little bit too far on the sensationalism, but I doubt all those servers are properly configured with encrypted connections, and god knows what else might be open besides the DB server.
Bottom line: it's not the end of the world, but it's not good news either.
Even if you need to go through "teh internets" to access your (your application's) DB server, you should at the very least do so through an SSH tunnel, preferably using certificate authentication. That in itself eliminates the need for the open DB server port on the remote interface. Otherwise, AFAIK, someone could sniff your SQL queries and find out the database user/password, just to mention one possible issue.
Although her opinion is not completely out of track, IMHO, it seems Ms. Schroeder doesn't know much about code. You can have pretty shinning code which does all that awful samsung stuff she talks about, for example. What the code does and how it was written are very different things.
Just my 2c.
Also, have they fixed the damn thing (OOo)? Last I checked, the thing it enjoyed spending its (and mine) time the most was crashing and "restoring" its own documents. I think they didn't take that into account in TFA (and no, I didn't read it; any article which chooses OOo over office, heck, even '97, as of now, isn't worth reading, unfortunately).
INCOMING!
Well, under *nixes, there's a little thingy called "su", and its partner, "sudo", with which you do all the "privileged" work you have to without the annoying "elevation prompts". I use vista at work and ubuntu at home. Ask me which of the two is the most "friendly" (to me) in this respect. Sure, users who aren't familiar with the command line are doomed to be harassed by annoying dialogs. Poor bastards, but hey, it's their fault spammers rule the nets, so it's well deserved (HA!).
It would be interesting that you keep an eye in compatibility with some solutions which build upon the debian package system, such as debtags: http://debtags.alioth.debian.org/, for instance.
...
But really, no ponies? Awwww
Who needs LSD, nowadays? Hmmmm, I think that pig is trying to tell me something ...
Righto. In this case, O(1) is just good enough, then.
Ugh, size n or less, I mean.
Perhaps what you really meant is using *sockets* instead of using networking. Very different things, methinks.
"Quick web scripts are way easier than developing an application if only for the fact that you don't need to figure out how to use networking in whatever language you'd be working in." Uhmm ... exactly when the HTTP protocol was banned from the networking family? Granted, you don't need to implement it into your CGI web app, but if you don't have at least a very basic understanding of it you won't get to far, IMO.
There's another reason why a person with a businness degree will succeed better than one with a CS degree in a businness environment. Code in comercial applications sucks, for the most part. So, any code writing person with a Businness degree is able to do it. If you don't have good and solid understanding of semantics, algorithm complexity, data structures and the underlying computing model(s), you are a code writing person, no matter how good you claim you are in your pet language. But you are no programmer. I'm not saying that in order to be a programmer you must have written a compiler. But you really should understand how one would be built, and be able to do so, if it be the case.