Want to avoid SQL injection? Use an escaping function specific to your database of choice such as mysql_escape_string().
No. Use a system that supports prepared statements (or which simulates the functionality by doing the proper quoting for you behind the scenes). If PHP cannot do this, drop it in favour of a non-toy language; there's many of them out there that will integrate as well (or better) with Apache.
Come on, everyone! We've known the answer to this one for donkey's years!
In theory a smart syntax highlighter could do this but it would probably have to almost be a compiler to handle this, especially if you want it to be correct, even in the face of macros. And I don't want to have to wait for a compilation every time I load a file up into my editor.
FYI, this is what modern IDEs do using things like incremental compilation. Not that you should take this as meaning I'm a fan of them though; they're also slow memory-hungry pigs (and they tend to not let me use either emacs or vi key-bindings either, the heathens!)
Without those algorithms, Doom 3's shadows would approach *polynomial* time just to get it to render!
Trust me, as a coder of much experience, that linear time and constant time are both polynomial. What you said just doesn't mean what you seem to think it means...
the "write once" mantra has been with us for 30+ years... and, in that regard, java beats the living pants off the other contenders.
Call me cynical if you wish, but the only way that works is if you define everything that beats the pants off Java in this area (Tcl for sure, and reportedly also Perl and Python) as being "not a contender". As far as I can tell, the only reason for doing this is if you've decided what you want the answer to be ahead of time and don't want to admit that something else might be better... "Write once, run anywhere" perhaps fits Java, but don't think that Java's anywhere close to the best solution for that style of program deployment.
That won't work; it just tests whether you can create an instance of the object, but you still need the class around for when you do the load of the calling class (or perhaps that can be postponed until the creation of the object, but still at a point when it is annoyingly inconvenient). To do that check, you need something more elaborate, perhaps like this.
boolean haveXYZ = false; try { // You might want to keep the object around...
Class.forName("XYZClass").newInstance();
haveXYZ = true; } catch (Throwable ex) {}
But even once you've done this check, you still have to come up with a way of using the class without requiring the caller to actually know about the class. OK, there's a design pattern for this...:^)
20 years later, more office workers are familiar with the "desktop" than with hanging file folders. Most "civilians" are familiar with a desktop on their computer than in their home. The office prop simulations are the starting reference for reality now, and are more of a straitjacket than a life preserver. We need a new paradigm, especially because mobile devices need a desktop about as much as a desktop needed a papertape reader, or a fish needs a bicycle.
Err, maybe in another ten or twenty years. There are lots of users for whom physical objects are still far more familiar than virtual ones. They're getting there, but changing paradigm on them will confuse them. It's not so much that they're slow, but they just don't use computers much. I suspect it's a largely generational thing.
// Java // people is a Vector for(Iterator it = people.iterator(); it.hasNext(); Person x = (Person) it.next()) { // do something with x }
Actually it was even messier than that since you had to put the code to get the next element inside the loop and not as the "next" clause. All in all, it was a common piece of code that was easy to make stupid mistakes in, and so the new for syntax is a great improvement, allowing Java programmers to take advantage of iteration over collection types in a way similar to Ruby (and Perl, Python, Tcl, and probably many others) has done for ages.
Looking at this, I see that Ibis is based on the GridLab project and is therefore going to be a set of very low-level operations. This lets you get something medium-sized up and going very quickly, but won't scale well to very big problems; the world in general is far too large, wild and wooly for any low-level approach to approach anything like efficiency (you just have to ship too much metadata around.)
I'm more of a high-level guy myself; I'd much rather tell a system what it is to do and let it pick whether to use Ibis for particular components of my workflows, depending on whether it is actually cost-effective. YMMV...
"arbitrary code of the attacker's choice" can still be executed in such languages, just at a higher level = e.g. SQL Injection. Or "shell/script".
However one can avoid "SQL injection" with minimal performance AND programmer workload impact by enforcing saner interfaces e.g. prepared statements, bind variables etc.
How does one do the same thing with respect to buffer overflows and C or C++, AND still have things look and work like C or C++?
You avoid buffer overflows in C (and C++ too) by using a better I/O lib (and yes, they do exist, and as free software too!) and a string library that does bounds checking. You test those rigorously to make sure they do what they say on the tin. You make sure your functions do bounds checking on their input (and you write tests to make sure that the bounds checking works.) You make sure that your code fails fast if it can't succeed in the expected way. It's all basic software-engineering stuff.
Microsoft's real problem is almost certainly that they have too many people with commit access to their source tree; it's too easy for some fsckwit to check in a bad change and too easy to punt responsibility to someone else. Not that MS are alone in having this problem, but they do demonstrate it quite clearly.
The problem for them is that the fix is to reduce the size of the development team, split up responsibility clearly, and force everyone to use clear APIs. This is a problem for MS because it has a serious side effect, in that it can slow down the rate at which new features get added (for example, it might involve only adding new features that are a good idea!!!) and this is at odds with their basic business model.
It looks like Philips (through their tame spin-off Handshake Solutions) are letting the world see Tangram again (or something very like it.) Back in around 1994/1995 the Amulet team (already mentioned accurately by others) were looking into using the Tangram language to develop their asynchronous microprocessor technology - it was a fairly neat solution that did most of the things we wanted, though there were a few things it was crap at at the time - but then Philips decided to cut us off. It would be entirely fair to say that this was very annoying! Now it looks like they're letting the cat get its whiskers out of the bag again.
FWIW, ARM have probably known (at least informally and at a level not much deeper than your average slashdot article) a large fraction of what Philips have been up to in this area for at least a decade.
BTW, I am not sure that evolution is incompatible with the idea of "intelligent design" as long as one is careful about defining intelligent design....
Actually, there have been studies of this (and someone else will have to pick up the karma for tracking down a URL) and you get differently shaped family trees with evolution and intelligent design.
For some reason, I keep thinking of "design of cornets" was a case study...
If the range is not that far, why the concern about being tracked?
What do you bet that there won't be some clever person in the next ten years that figures out how to build an ultra-sensitive focussed RFID reader that reads tags at a distance?
You should look at the latest Unicode specs which now allow the encoding of just about every kind of character ever conceived of by humanity (though some are not yet allocated code-points) instead of speculating wildly.
Ah, this reminds me of scientific FORTRAN use with the NAG library. To use an operation, you had to go to your (paper) documentation and look up what function you wanted to perform (according to what types you were manipulating, what numerical methods you wanted to use, how much memory you had available, what the phase of the moon was, etc.) and found out what its magic symbol was. That was the function name to use. They were utterly un-mnemonic IIRC.
For modern coders, just think on this: it was worse than the Win32 API. Well, most of Win32; there are some seriously scary corners in there...
On the face of it from having skimmed the patents and looked at those summaries (i.e. this is not a trustable opinion and IANAPatentL), that looks like CORBA and RMI are the primary routes of exposure, though I'm not 100% sure that the scheme of ClassLoaders is not also hit.
By contrast, the streams approach taken in c++ is type-safe, extensible, and easy to use.
There are three things wrong with C++ streams.
They are anti-i18n. (Look up XPG3 format specifiers and the java.text package for reasons why both C and Java are ahead of C++ in this area.)
They are really much more verbose when you want to do complex formats (if you only ever use the %f, %d and %s formats in C like that, you're missing the strength of printf().)
Irrespective of everything else, operator overloading is evil because it is a facility that too many people insist on abusing.
<RANT>
If I'm about to do a function/method call, I'd lilke to know goddamnit, because it matters when you're trying to analyze the system performance. (Yes, Java's overloading of + for Strings is bad too, and that leads to a lot of awful code too.) Overloading looks great and can be used to great effect; it just doesn't work out that way in the real world.:^(
</RANT>
To me, C++ streams feel very noddy and do not seem to be tools fit for high quality production code. No doubt some weenie will disagree...
Almost every basic I/O library, from C's printf() to Java's System.out.println() to Perl's print(), forces you to specify the order that the arguments are displayed.
Not exactly. If your printf() has the XPG3 format extensions (what, yours doesn't?!) then you can completely disconnect the order in which values are placed in the output from the order in which they are specified. If you then pull that format string from a message catalog, you've got i18n-aware printf() for virtually no effort on your part.
FWIW, many large organizations use fake monetary units in their accounting systems, often because the conversion rate to real currencies depends on factors that are not easy to control.
For example, supposing you buy (for a fixed price) a share of the total compute time on a supercomputer. How many minutes of CPU time is that a month? Well, that really depends on how much unscheduled down-time there is (ideally none, but this is the Real World here) and you won't know how much that is until the end of the month, and hence you won't know (for reselling purposes) how much each of those minutes of CPU time actually cost you. The easiest way to do that is to charge CPU minutes in a fake currency and reconcile that to real money every so often. You could try monetarizing up front, but that's very tricky to get right and likely to end up with either your customers cross for overcharging or your management furious for undercharging...
What C# did was tip the balance between the keep-it-all-static guys and the put-new-features-in guys. Let's not forget that keeping the language static has many advantages, notably that it is much easier to write tools that work with the language (e.g. Eclipse).
The features add together. Taken as one, you can now just make a big extensible list of interesting integers and then do something with each of those list items, and you don't need to write lots of extra code to make it happen. You might not think this is a big deal, but it really helps in practice because it lets you write code that is closer to what you're thinking about instead of having to put in irritating book-keeping hoops all over the place. It's this sort of thing that makes languages like Perl, Python, REXX and Tcl so much more productive.
Slashdot Mirror
No. Use a system that supports prepared statements (or which simulates the functionality by doing the proper quoting for you behind the scenes). If PHP cannot do this, drop it in favour of a non-toy language; there's many of them out there that will integrate as well (or better) with Apache.
Come on, everyone! We've known the answer to this one for donkey's years!
FYI, this is what modern IDEs do using things like incremental compilation. Not that you should take this as meaning I'm a fan of them though; they're also slow memory-hungry pigs (and they tend to not let me use either emacs or vi key-bindings either, the heathens!)
Trust me, as a coder of much experience, that linear time and constant time are both polynomial. What you said just doesn't mean what you seem to think it means...
Call me cynical if you wish, but the only way that works is if you define everything that beats the pants off Java in this area (Tcl for sure, and reportedly also Perl and Python) as being "not a contender". As far as I can tell, the only reason for doing this is if you've decided what you want the answer to be ahead of time and don't want to admit that something else might be better... "Write once, run anywhere" perhaps fits Java, but don't think that Java's anywhere close to the best solution for that style of program deployment.
I'm more of a high-level guy myself; I'd much rather tell a system what it is to do and let it pick whether to use Ibis for particular components of my workflows, depending on whether it is actually cost-effective. YMMV...
Microsoft's real problem is almost certainly that they have too many people with commit access to their source tree; it's too easy for some fsckwit to check in a bad change and too easy to punt responsibility to someone else. Not that MS are alone in having this problem, but they do demonstrate it quite clearly.
The problem for them is that the fix is to reduce the size of the development team, split up responsibility clearly, and force everyone to use clear APIs. This is a problem for MS because it has a serious side effect, in that it can slow down the rate at which new features get added (for example, it might involve only adding new features that are a good idea!!!) and this is at odds with their basic business model.
It looks like Philips (through their tame spin-off Handshake Solutions) are letting the world see Tangram again (or something very like it.) Back in around 1994/1995 the Amulet team (already mentioned accurately by others) were looking into using the Tangram language to develop their asynchronous microprocessor technology - it was a fairly neat solution that did most of the things we wanted, though there were a few things it was crap at at the time - but then Philips decided to cut us off. It would be entirely fair to say that this was very annoying! Now it looks like they're letting the cat get its whiskers out of the bag again.
FWIW, ARM have probably known (at least informally and at a level not much deeper than your average slashdot article) a large fraction of what Philips have been up to in this area for at least a decade.
Actually, you only need to single-step the instructions that write to memory. That's what memory-debugging tools like Purify do.
You should look at the latest Unicode specs which now allow the encoding of just about every kind of character ever conceived of by humanity (though some are not yet allocated code-points) instead of speculating wildly.
No, but they do make for a good opportunity to eat popcorn...
For modern coders, just think on this: it was worse than the Win32 API. Well, most of Win32; there are some seriously scary corners in there...
On the face of it from having skimmed the patents and looked at those summaries (i.e. this is not a trustable opinion and IANAPatentL), that looks like CORBA and RMI are the primary routes of exposure, though I'm not 100% sure that the scheme of ClassLoaders is not also hit.
Yeah, and there's already been a dwarven city built under Cheyenne Mountain...
- They are anti-i18n. (Look up XPG3 format specifiers and the java.text package for reasons why both C and Java are ahead of C++ in this area.)
- They are really much more verbose when you want to do complex formats (if you only ever use the %f, %d and %s formats in C like that, you're missing the strength of printf().)
- Irrespective of everything else, operator overloading is evil because it is a facility that too many people insist on abusing.
To me, C++ streams feel very noddy and do not seem to be tools fit for high quality production code. No doubt some weenie will disagree...<RANT> :^(
If I'm about to do a function/method call, I'd lilke to know goddamnit, because it matters when you're trying to analyze the system performance. (Yes, Java's overloading of + for Strings is bad too, and that leads to a lot of awful code too.) Overloading looks great and can be used to great effect; it just doesn't work out that way in the real world.
</RANT>
So? If you want to code up an EJB container that's fine with me. There's even an OSS container (JBoss) if you want to build off other people's work.
FWIW, many large organizations use fake monetary units in their accounting systems, often because the conversion rate to real currencies depends on factors that are not easy to control.
For example, supposing you buy (for a fixed price) a share of the total compute time on a supercomputer. How many minutes of CPU time is that a month? Well, that really depends on how much unscheduled down-time there is (ideally none, but this is the Real World here) and you won't know how much that is until the end of the month, and hence you won't know (for reselling purposes) how much each of those minutes of CPU time actually cost you. The easiest way to do that is to charge CPU minutes in a fake currency and reconcile that to real money every so often. You could try monetarizing up front, but that's very tricky to get right and likely to end up with either your customers cross for overcharging or your management furious for undercharging...
What C# did was tip the balance between the keep-it-all-static guys and the put-new-features-in guys. Let's not forget that keeping the language static has many advantages, notably that it is much easier to write tools that work with the language (e.g. Eclipse).
The features add together. Taken as one, you can now just make a big extensible list of interesting integers and then do something with each of those list items, and you don't need to write lots of extra code to make it happen. You might not think this is a big deal, but it really helps in practice because it lets you write code that is closer to what you're thinking about instead of having to put in irritating book-keeping hoops all over the place. It's this sort of thing that makes languages like Perl, Python, REXX and Tcl so much more productive.