Choice of Programming Language Doesn't Matter For Security 192
An anonymous reader writes "The Security Ninja has written a blog post which discusses web programming languages and the fact that they are all insecure. It's based on a report from WhiteHat Security and aims to dispel the myth that some languages will guarantee that an application will be more or less secure than other languages. '... secure code is the product of a secure development process and real business commitment to deliver secure applications which includes developer education. The absence of these processes and business commitments will lead to web applications being developed insecurely regardless of the language being used.'"
It's a good point but... (Score:2, Informative)
It's a great point that security awareness is paramount in any web programming...
But I dare you to write a more secure web service in , than in Java. Sure you have to be security aware, but it's still the case that some languages make acting on that awareness easier than others.
Re:It's a good point but... (Score:4, Funny)
But I dare you to write a more secure web service in , than in Java.
I didn't know Whitespace [wikipedia.org] supported web services.
Of course it does (Score:5, Funny)
I didn't know Whitespace supported web services.
Sure it does, I had a full shopping cart system at the end of my post by way of example.
Prove me wrong... :-)
Re: (Score:2)
I tried to compile it, but I think you had a misplaced tab.
Oh say can you C (Score:2)
Don't know where it went, but there was supposed to be a "C" in there and I swear there was one when I hit submit...
As it is though, I guess you can fill in your least favorite language!
Re: (Score:2)
Don't know where it went, but there was supposed to be a "C" in there and I swear there was one when I hit submit...
Between pressing 'S-c' and 'Enter', you had a race condition.
Re: (Score:3, Insightful)
Usually when you see claims that Java is more secure than C, it is based on people finding more security bugs in C than in Java, but I am not sure that is a good measurement because C and Java are used in different places, and that makes a huge difference. For example, a buffer overrun in a desktop app (excel, photoshop, whatever) is not a security breach, it's just annoying. C is use
Re: (Score:2)
You fail it.
If you're worried about security, you don't assume a best case scenario. "lalala, ladee dah, I'll just make sure my C code is perfect with no exploits and it'll be just as secure as Java."
The reality is it only takes one simple, hard to find and debug fuck up and your application will be owned. In the same scenario using Java, the app would still be secure.
In a perfect world, C and Java are just as secure as one another. In reality, it's not even comparable, Java wins hands down.
Re: (Score:2)
Re: (Score:2)
Your argument implies that you think it is impossible to make one simple, hard to find and debug fuck-up in Java.
But this is exactly the point: for certain types of f-ups, it is impossible to make them in some languages. You cannot overflow a string in Java. You can in C. Java is unambiguously safer in this respect.
This is not a black and white issue. It is safer to use a language where there are fewer opportunities for human error, even if there are still some such opportunities.
Re: (Score:3, Insightful)
The problem is that *because* people are protected from certain very basic screw ups in Java companies automatically downgrade the quality of programmer and the level of oversight they use. The result, I believe, is that the end product is *even worse* than it would have been for the "more vulnerable" language.
So - if you are talking academically about languages - Java is more secure by a long way. C has all the vulnerabilities that Java has plus a lot more. If you are talking about actual outcomes in
Re:It's a good point but... (Score:5, Insightful)
Bad choice of examples. That's what we were saying and thinking in 1998: IT to PHB: "Don't open any EXE files mailed to you, however Excel spreadsheets, Word docs etc, are fine".
A exploitable buffer overrun in any application where malicious inputs exist is a security hole.
Re: (Score:2)
Never underestimate incompetence (Score:3, Insightful)
Never underestimate incompetence. Sure, Java protects you against some kinds of buffer overflows (but then a couple of versions had such vulnerabilities in their native parts of the JRE instead), but it doesn't protect against any other kind of incompetence.
There are probably a few SQL injection vulnerabilities and an XSS exploit being written somewhere right now. And someone out there is writing a servlet which reads and writes files off the hard drive, but isn't checking the paths, so really you can reque
Re: (Score:2)
Just because a bunch of Java programmers are morons doesn't mean the language sucks.
Never said that Java sucks (Score:2)
I never said that Java sucks. But it seems to me like TFA has a point. You still need to educate your devs and take security seriously. There is no magic amulet that you can just put on and be immune from security problems.
Not that huge a difference (Score:3, Insightful)
As you probably know already, virtually any CPU manufactured in the last years has some form or another of "no execute" flag. So someone could overflow your buffer all right, and... simply not be able to execute any code injected that way. And someone from the BSD gang could even add here that in their world they had a solution for that even before that.
And someone who is security-minded, since that was the thrust of the article anyway, will have used some C++ library or another that checks string bounds. H
Obviously... (Score:2, Interesting)
More at 11
Re: (Score:2)
That seems like a no brain statement. It doesn't matter what language I use if I write insecure code the application will be insecure.
The point is that it's easier to write insecure code in some languages than in others. In fact, in some of them, it practically writes itself.
That said, TFA is pointless. Let's see what the guy is comparing:
- ASP (languages: VBScript, JScript)
- ASP.NET (languages: C#, VB)
- ColdFusion
- JSP & Struts (language: Java)
- PHP
- Perl
Now, one thing that stands out: there's no C or C++ here. In fact, there's no memory-unsafe language here at all. You know, the kind where you can actually get things such as buffer
I have an hypotheses (Score:5, Insightful)
Re: (Score:3, Funny)
The problem is that the set of all haskell applications is too small to be statistically significant. OK, I'm just kidding.
Re: (Score:2)
I think the opposite because the better programmer will be rendered an average programmer by the difficulties of the language.
Re: (Score:2)
If that were true, we could prove evolution wrong.
That which does not kill us makes us stronger, not weaker.
The difficulties of the language are negligeable compared to the difficulty of writing a secure, complex app, simply because the language's complexity is negligeable compared to the sum complexity of all the apps that can be written in it.
Easy-to-use, "simple" languages, ought to be more secure than C, but in the real world, only logo is really safer than anything else, just because you can do almost
There's also the fact that (Score:2)
There's also the fact that in Haskell (or, say, O'Caml) you can structure your application's interface to the web such that you cannot (by abstraction) do unsafe things unless you really want to(*). If you have such a framework the programmer has to be actively working against you to do unsafe things. (And there's nothing that can save you from an actively destructive/malevolent programmer inside your organization.)
(*) Define Unsafe/Safe string variants and force all strings trough Escape/Unescape for all t
language safety vs programmer ability (Score:2)
I don't know if I agree; haskell programmers tend to be demographically more experienced (it's the only language I know of where it seems that the median programmer has or is working on a PhD), but I would also trust a relatively inexperienced programmer to write fairly good code in Haskell, especially if they used an existing web framework like HappStack. Static typing and well-defined libraries go a long way towards making it hard to do the wrong thing. This is one of the things I find compelling about
Perl most secure (Score:5, Funny)
Re: (Score:3, Informative)
Re: (Score:2)
IFFEN(Nawt Sek Ewer) DEN Apply(Bite) ADN Apply(PoynteeEnds)
Its not black & white (Score:5, Insightful)
Anyone who says all programming languages are equally exploitable is a fool. Sure, secure coding practices and standards are the way to approach the issue- not language selection, but it is, for instance, impossible to overrun a buffer in interpreted byte code and executed native code. The fact that stack crashing doesn't exist in interpreted code alone demonstrates that languages (or their runtime environments that are inherent to a language) are not all equal in exploit-ability levels. To say they are all the same is simplifying things too much. Yes, all languages have their exploitable bad practices, but some have more than others.
Re: (Score:2, Insightful)
Re:Its not black & white (Score:5, Insightful)
Yeah, except this isn't a comparison by language. It's a comparison by platform technology. For example, JSP shows as one of the highest vulnerability ratios, whereas Struts (Apache's Java MVC framework) has just about the lowest vulnerability ratio (on par with ASPX).
Clearly they are measuring *something* but it seems to have relatively little to do with languages themselves.
If anything, it seems like web apps written in frameworks that don't actively discourage mixing code and presentation are more likely to have vulnerabilities, whereas frameworks that encourage separation more actively (and perhaps are newer frameworks) are less likely to have vulnerabilities. The worst two measured, Perl and JSP, are older technologies that date from the era before frameworks that enforced more MVC separation were common and before web app best practices really existed.
Re: (Score:2)
Re:Its not black & white (Score:4, Insightful)
The test itself already has bias, precisely because it works on a family of programs that happen to have a very limited set of inputs, and where the avenues of attack are relatively limited in some very important ways. The core vulnerabilities of websites have been done to death, so at this point, barring utter stupidity, I'd have been surprised if the security problems were noticeably different depending on the language.
Re: (Score:2)
I think you're right to say that it's better to trust empirical evidence than go on seemingly logical assumptions. However, to me it looks like the study is making a _business case_ that all the tested languages are likely to produce roughly the same number of flaws. That is to say, as a business decision the programming language viewed by itself is not a significant factor. However I don't think it can be extended out to saying the language doesn't matter. It's not accounting for quality of programmer, des
Re: (Score:2)
I read the link, and since it requires registration of sorts to dl the pdf, I won't do that.
But it seems like a very macro level type of study, and that seems to gloss over technical details that you need when judging a language.
To use a car analogy, if you're measuring accident avoidance, and you note that the prius has the least amount of accidents, therefor it's the best for avoiding accidents. Ignoring the fact that what you're doing if your driving a prius, or the type of person that typically would u
Re:Its not black & white (Score:5, Insightful)
They made a statistical analysis of web languages. That's not generalizable to all programming languages as the Slashdot headline implies. All of these languages have several things in common:
In short, all of these programming languages eliminate entire classes of potential exploits that other programming languages allow. Therefore, although these programming languages happen to be similar, that does not mean that programming language choice has no bearing on security. It just means that choice of programming language within a very narrow range of languages that are not a representative sample of programming languages as a whole has no bearing on security.
Re:Its not black & white (Score:4, Informative)
Well, the full paper is behind nag-ware, but here are the "top 3 findings"
Gosh. To me that says that they found significant differences between the languages and platforms.
However, I am not ready to make any claims based on this, other than, they sampled a bunch of websites and then recorded information about vulnerabilities, and did "group by" on language/framework.
Isn't it likely that there is some selection bias here?
Rather than making claims about the intrinsic nature of some language or framework [like all of them are equal, or one is better than the others], don't you need to correct for the lack of control.. like same coders in the same organization trying to implement the same _type_ of application?
If I gave the same group of developers equal traning time, equal implementation time, and equal specs... and then said "do this in ASP.NET", and then "do it in Perl". And i did this with 10 groups of developers, and i changed the order of which application came first (i.e. some groups did perl first, some did asp.net first).
__then__ I would feel comfortable saying something about the relationship between language/framework and security vulnerabilities. What we really want to know is, given developers _like yours_, who've had equal training, expertise, and time, when trying to produce equivalent functionality.. how is _their_ production of security defects, and is there a difference between toolchains?
Now, I didn't read the PDF because if the nag-wall infront of it. But that doesn't sound like what they did here.
The goal out here in the real world is this: make an application that is secure-enough, cheaply-enough. "Cheaply-enough" means what caliber of people you need to hire, and how long it takes them to produce value-adding output. Secure enough means that the cost of fixing your bugs is higher than the cost of (risk of penetration * financial impact of penetration).
Re: (Score:3, Insightful)
Please show me the interpreted byte code langauge/runtime that has never had a buffer overflow exploit.
I promise you that I can count one one finger higher than you can show me systems without a buffer overflow exploit.
The fact that your saying what you're saying tells me you really have no understanding of how exploits happen at all, let alone any reason you should be talking about secure code.
Re: (Score:2)
Please show me the interpreted byte code langauge/runtime that has never had a buffer overflow exploit.
What about this one [readscheme.org]?
Re:Its not black & white (Score:5, Insightful)
"All languages are exploitable" != "all languages are equally exploitable".
You're the first person to bring the word "equally" into the conversation, and have missed the point.
Re: (Score:2)
it does if you language is caps insensitive and can handle a maximum string length of 19.
Re: (Score:3, Informative)
The fact that stack crashing doesn't exist in interpreted code alone demonstrates that languages (or their runtime environments that are inherent to a language) are not all equal in exploit-ability levels.
You are totally wrong, since Javascript, which is interpreted, has numerous exploits involving stack crashing.
http://en.wikipedia.org/wiki/Heap_spraying [wikipedia.org]
with an example here:
http://stackoverflow.com/questions/381171/help-me-understand-this-javascript-exploit [stackoverflow.com]
ActionScript (from Flash) is also an interpreted language, and full of security bugs !
Re:Its not black & white (Score:5, Insightful)
The difference is that flaws in the Java runtime (or any runtime) are A. infrequent, B. somebody else's fault, C. quickly fixed once discovered, and D. not specific to your individual installation. Thus, as long as you pay attention to the security notices, you're probably fine.
Put another way, there are thousands of people looking for flaws in the Java runtime. When you're talking about flaws in your code, the only people looking for bugs in it are you and the bad guys. This means that it is much more problematic to have 1,000 bugs in your code than to have 1,000 bugs in the Java runtime. With the latter, the odds are in your favor that the flaws will be first discovered against somebody else's website. WIth the former, the only place those flaws can be discovered is on your website.
culture (Score:2)
I've done a lot of embedded development, some of it in the security sector, which is not tolerant of sloppiness.
One of the products had a web interface implemented in PHP, which I partly coded. I don't use PHP regularly, so I was entirely at the mercy of the PHP online documentation. This was a few years back, but my god was it a struggle to glean from the documentation the bounds of validity of the different PHP function calls. In many cases I had to resort to untangling a long and often contradictory d
Beat up any straw men lately? (Score:2)
"That aims to dispel the myth that some languages will guarantee that an application will be more or less secure than other languages."
Whoever said, besides your 16-year-old cousin that just figured out how to add a flaming skull animation to his MySpace page, that there is any web application programming language that will guarantee security. Sheesh.
Bloody hell... (Score:2, Funny)
Yes...but (Score:2)
If you know what programming language a programmer uses you can tell if they know what they are doing or not.
Re: (Score:2)
Sure, as long as you have the language spec.
The Python Paradox (Score:4, Informative)
If you haven't heard of it, the python paradox is an interesting read: http://www.paulgraham.com/pypar.html [paulgraham.com]
Simply put, the kind of people who learn a language out of interest than out of wanting to get a job tend to be better programmers on average. (This was written awhile ago, when Python had little use outside the FOSS community. Now that Python is looking like it may someday replace Java, perhaps the Haskell Paradox is a better term).
Anyway, perhaps the same issue is at play here. Perhaps the people who use PHP tend to be less aware of security or more apathetic toward it, and thus there is a two way feedback between language and programmer (the last time I used Visual Basic the compiler was as full of holes as a piece of swiss cheese and Microsoft wanted me to pay $100 each to report counterexample bugs, but that was 6.0, back in middle school)
Re:The Python Paradox (Score:5, Insightful)
People who do anything because it interests & fascinates them on a personal level do better than those who are only in it for the paycheck. Doesn't matter whether it's programming, auto repair, landscaping, or anything else.
Re: (Score:2)
People who do anything because it interests & fascinates them on a personal level do better than those who are only in it for the paycheck. Doesn't matter whether it's programming, auto repair, landscaping, or anything else.
Except gambling/poker.
Re: (Score:2)
People who do anything because it interests & fascinates them on a personal level do better than those who are only in it for the paycheck. Doesn't matter whether it's programming, auto repair, landscaping, or anything else.
I paid for my undergrad degree by landscaping, and I can say with some certainty that it is neither an interesting nor a fascinating subject.
Re: (Score:3, Insightful)
Re:The Python Paradox (Score:5, Insightful)
Exactly. The culture of a language is as or more important than the language itself. Indeed, the culture shapes the language (but of course, to a degree, the language shapes the culture).
Java itself isn't a very good language, but it's the hordes of incompetent Java programmers who make it such a terrible choice for everything. This goes back to the Python paradox: companies want Python programmers to write Java for them.
I will say this in Java's favor, however: It's a language where the smartest can't write code that confuses the dumbest, and where the dumbest can't write code that does too much damage.
Re: (Score:2)
I will say this in Java's favor, however: It's a language where the smartest can't write code that confuses the dumbest
Not really. They dug the grave for the dumb in 1.1 already, with inner classes; and nailed the coffin shut in 5, with generics. In 7, they are going to finally bury it with lambdas [java.net].
Me, I'm waiting eagerly to see what the next incarnation of COBOL turns out to be...
Re: (Score:3, Insightful)
That alone makes it the best language for large business projects. Your coworkers will be a mix of good and bad, and pretending the bad programmers is a more damaging mistake than anything you can do to the code.
Re: (Score:2)
I will say this in Java's favor, however: It's a language where the smartest can't write code that confuses the dumbest, [...].
In my AP computer science class, some of my classmates don't seem to grok the whole OO concept (i.e. if I create multiple interacting classes, it confuses them. They do however understand "[Type] foo=new [Type]();", but only for predefined types).
Re: (Score:2)
It's an interesting essay, but it's just speculation. Not any more insightful than the serious posts on Slashdot.
Re: (Score:2)
This a very good point. It is the programmers that are important, not so much the languages, but languages do bias what kinds of programmers will use them.
See also why Linus' Torvalds prefers C to C++ [cat-v.org], it has not so much to do with the language itself but with the kind of programmers that use the language.
Turing-completeness isn't the point. (Score:2)
Any language that lacks an inherent insecurity can be used to write secure apps, just as any language (Brainfuck, anyone?) can be used to write any program.*
You choose a language not because it makes it possible for you to do anything, but because it makes it easier than another language.
*I realize that there are cases where performance-per-core is critical, and that narrows your choices considerably. Still, in that situation, some use C, others use C++, and still others use Lisp.
Only web applications (Score:2)
OVERSOLD/HYPED: 'Web programming language' (Score:4, Interesting)
1. The languages being considered/charted are ASP, ASPX, CFM, DO, JSP, PHP and PL (I can guess at most of these acronyms).
What's missing, obviously, are 'real' programming languages such as C, Java, FORTRAN, Ada, C++, Eiffel, etc.
2. A lot of these languages share a common (C) heritage, and I'd assert "inherit" a lot of the security weaknesses of C. That's particularly true of weak typing for scalars, including array bounds.
The conclusion I think can be drawn from this is that we need a substantial increase in Web Programming practices, including languages. Any other conclusion is overreach.
Re: (Score:2)
Re: (Score:2)
You forgot the functional programming languages, like Haskell, Ocaml, standard ML, Erlang, etc.
They usually have a track record of higher security without loss in performance (that Java has), since the checks can happen at compile time.
Of course you can still mess up things even in Haskell. E.g. [0,1,2,3,4,5]!!10 will cause a runtime exception. But the functions that can cause errors are well-known and can be avoided. Also, QuickCheck is a really great tool to test out all the possibilities.
If I ever had a
Re: (Score:2)
... "inherit" a lot of the security weaknesses of C. That's particularly true of weak typing for scalars, including array bounds.
Can you explain what you mean here?
Steve Ciarcia on programming languages: (Score:3, Funny)
Re: (Score:2)
Reminds me of one of my roommates in college.
He had a poster of the saying (IIRC) "real programmers don't use operating systems they write directly on the hardware as god intended."
Some truths are eternal (Score:2)
If anyone knows who deserves the credit for that one, BTW ...
Re: (Score:2)
Java designers made a cunning workaround for that by removing "goto" from the language, though.
Java (Score:3, Insightful)
One of the things I liked about Java was that there aren't any buffer overflows to worry about. Well, apart from ones in the JVM, but they are few and far between.
I don't understand when people say that all languages are as insecure as each other. Sure, people can do stupid things like not check input, etc - but when it comes to finding some sort of buffer overflow in a function/library?
If I had to write a website that would be deployed onto a box which was not touched for 5 years, I imagine that a Java-based site would have a better chance of faring than a PHP one.
A poor craftsman blames his tools (Score:2, Insightful)
False dichotomy much? (Score:2)
There isn’t just “secure” and “not secure”, you know? Some are more and others less secure.
And I have only one thing to say:
Haskell > Java > C :)
(Java has built-in checks that prevent the worst errors of C. And Haskell also has them, but at compile time, so you get back the performance. Of course those language are just examples, and any similar languages could be placed in there instead.)
Re: (Score:3, Insightful)
In the case of an advanced JVM like HotSpot (the official Sun/Oracle JVM), you also get the performance back.
If the array bounds checking can be removed without compromising security, HotSpot's JIT compiler will do so when compiling the Java bytecode into native instructions.
COBOL (Score:2)
Thousands of Banks can't be wrong! Right?
This is absurd. (Score:2)
Sure, if you take extra precautions with the buffer-overflow languages, your software can be just a secure. But in the real world, that's almost never the case. Projects are always rushed and mistakes happen. Every team has one or more weak links. And what coder prefers burdensome process to development anyway? Anyone who promotes C/C++ over Java for a back-end enterprise application is not a professional IMO. They come across as stubborn basement hackers who can't keep their resumes up to date. C/C++ was n
But who provides the language implementation DOES (Score:2)
http://www.c-program.com/kt/reflections-on-trusting.html [c-program.com] is worth another read. Apple can make a reasonable case that allowing other development tools in their little garden reduces their ability to ensure a secure system.
I concur with posters who observe that some languages do have more protections than others; but in the end the application programmer needs to be careful and security aware, and there has to be complete trust in every step of the processing from what the programmer writes to what is run on
gets(), the C standard library standard bug. (Score:2)
Languages maybe. Standard libraries, oh boy for sure.
From the man(3) page for the set of functions including gets():
Re: (Score:3, Informative)
gets() is officially deprecated in ISO C99 standard, though, and will be removed entirely in ISO C1X. Most compilers today (even non-C99 ones) will output a warning if they see it, and warnings-as-errors is standard development practice for C/C++ these days.
Also the "secure" functions in TR 24731 (strcpy_s, strcat_s etc [us-cert.gov]) will be part of the base standard library in C1X.
self-proclaimed "ninja" it would seem.... (Score:2)
a security "ninja" who uses windows xp for everything? its a bit like a design "guru" who uses mspaint on a monochrome monitor.
and yeah its kind of obvious its not really down to the language, its down to the programmer. a little surprised by the stats though - i'd have thought perl hackers would have more security know-how than your average java monkey.
Bogus article title and bogus conclusion (Score:2)
There''s a hell of a lot more to programming than just Web programming and there are a lot of real programming languages that go to great lengths
to make secure programming easier.
The Security Ninja is a paper tiger.
Re: (Score:2)
Re: (Score:2, Interesting)
Re: (Score:3, Funny)
Careful. You might get him so mad that he'll have a buffer overflow and then core dump.
Re:Duh (Score:4, Insightful)
Yeah cause a language that makes it trivially easy to overrun a buffer, dereference null pointers and smash the stack is clearly a highly secure language. Oh wait...
Re:Duh (Score:5, Insightful)
Ye Olde Excuse: “you’re just not good enough”
You know, in modern languages, you can once abstract that concept out that you don’t want buffer overflows and dereference null pointers, and you’re done.
In C, you have to re-invent the wheel again and again and do the same micromanagement over and over. It’s like the man with three buttocks on Monty Python: We’ve done that! We’ve solved it. We have nice standardized solutions. (Java doing runtime checks by default. And Haskell doing them at compile time.) Use them!
With modern languages, you can use your mental resources to tackle the actual problem, instead of having to constantly think about decades old and long solved problems that should long be included by default.
And the biggest joke is, that most C programmers manually implement those systems themselves, and then act all proud, because they re-invented the wheel, except that it never received the literally decades of testing of the well-studied existing solutions.
It’s dumb. Like those people re-implementing standard library functions. It’s unprofessional and inefficient. And very error-prone for no reason at all.
Re: (Score:2)
It's dumb. Like those people re-implementing standard library functions. It's unprofessional and inefficient.
I thought that too until I found the bottleneck that is converting from float to int using (int) casting. I found the following to be multiple times faster:
unsigned floatToInt(double d) // 1 52
{
d += 4503599627370496.0;
return (unsigned &)d;
}
Re: (Score:2)
You mean like using std::vector and std::string instead of malloc, smart pointers instead of raw pointers and manual memory management?
We did all that years ago...it's only the uneducated C hackers who keep giving C++ a bad name.
Re: (Score:3, Insightful)
We did all that years ago...it's only the uneducated C hackers who keep giving C++ a bad name.
Well, that and the facts that
anyway.
Re:Duh (Score:4, Insightful)
There are still tasks that are better suited for languages like C and C++. The interesting ones. The alternatives?
"You mean I get to build another boring business web application using the latest kludgy framework du jour so that it's obsolete two weeks later when the more popular kludgy framework comes out. Oh boy!" (OK, it's a little bit better than that. But not much. :) )
Games development, systems development, OS development, embedded programming and the like are places where it pays for development to be done by people who know what they're doing using tried and true programming tools that demand such expertise. When did Slashdot become so dull that nobody was interested in this stuff anymore?
Re: (Score:2)
>Games development
Game developers are desperately looking for something, anything better than C++. C# is looking better each day.
Unfortunately, the choice of C++ is often dictated by externalities (no C# on PS3, etc.)
>systems development, OS development
There are several OSes developed in Java, C# and other languages. I'm pretty sure we'll move away from C-based OSes in 'near' future.
>embedded programming and the like
And it's more and more irrelevant (Moore's law). It's quite often easier to use mor
Re: (Score:2)
Citation needed. Maybe some tools in addition to C or C++ in some cases.
Just because you can develop OSes in Java or C# (or parts of it anyway) does not mean it's a good idea. Web development can be done in C or C++, and it's equally stupid to do so. Unix variety OSes moving away from C is not
Re: (Score:3, Insightful)
Sure these categories of applications occasionally have bugs. They're difficult to do. What do you expect?
However, how often they happen are pretty exaggerated as well. The Linux kernel is mostly written in C, of course. How often do you see it lock up for as difficult of a piece of software that is to write? How about all the millions of embedded pieces of code for mission-critical application that perform flawlessly day after day to the point that nobody notices them?
Besides for every C++ desktop app
Re: (Score:3, Insightful)
I didn't RTFA but I agree with the sentiment of the summary. It's NOT THE LANGUAGE, it's the programmer and their knowledge of the interfaces they are working with.
plenty of things can and should be written in C. It is perhaps a sharper blade than Java, but were professionals. There's 100 other mistakes you will make being uncareful when programming that have nothing to do with language choice that are far more important t
Re: (Score:2)
You got a nice statement there. Care to back it up with some actual arguments? You know:
I'm afraid it's you who is insecure, not C, because...
Re: (Score:2, Funny)
>Oh cool, is C ellipsis the new C sharp?
No, C... is secure and C# is not.
Re: (Score:2)
C...
Oh cool, is C ellipses the new C sharp?
No, it's just another form of object notation in the next version of Objective-C. sigh ...
Everybody hatin' on PHP (Score:2)
Re:Everybody hatin' on PHP (Score:5, Insightful)
Re: (Score:2)
A more secure PHP option, Quercus [caucho.com].
Re:Everybody hatin' on PHP (Score:5, Informative)
Changes in PHP 6
Issue: Register globals are the source of many application's security problems and cause a constant grief.
Discussion: We shortly discussed how we want to attend users on the disappearance of this functionality. We decided that if we find the setting during the startup of PHP we raise an E_CORE_ERROR which will prevent the server from starting with a message that points to the documentation. The documentation should explain why this functionality was removed, and some introduction on safe programming.
Conclusions:
We are going to remove the functionality.
We throw an E_CORE_ERROR when starting PHP and when we detect the register_globals setting
http://www.php.net/~derick/meeting-notes.html#id12 [php.net]
Issue: Magic_quotes can be cumbersome for application developers as it is a setting that can be set to on or off without any influence from within the script itself as input parameters are escaped before the script starts.
Discussion: In the same way as with the remove of the register_globals functionality, we decided that if we find the setting during the startup of PHP we raise an E_CORE_ERROR which will prevent the server from starting with a message that points to the documentation. The documentation should explain why this functionality was removed, and point the users at the input_filter extension as replacement.
Conclusions:
We remove the magic_quotes feature from PHP.
We throw an E_CORE_ERROR when starting PHP and when we detect the magic_quotes, magic_quotes_sybase or magic_quotes_gpc setting.
http://www.php.net/~derick/meeting-notes.html#id13 [php.net]
They are also planning on getting rid of the non-PDO db stuff at a future date.