Shoot people who are terrorizing and holding hostage civilians in their own city
You know, it's the US that refused to allow any males between 15 and 50 to leave, so I think if anyone's to blame for civilians being trapped in Fallujah...
Yeah, that's possible, too, but it seems more likely that a minority of the people (and not all of them Iraqis) are interested in attacking US (and coalition, and Iraqi) troops.
That's exactly what I suggested.
The rest of them are just trying to live there lives.
Sure, but that it not a sign that they are in favour of the occupation.
What about all the Iraqis signing up for the police and armed forces? Are they all 5th columnists, too?
No, but the Iraqi police aren't a great deal more popular than the US military.
How else could you interpret it?? Were they friendly bombs?
Look, the original argument was something like "if the Iraqis wanted the US out, they wouldn't be afriad to [do bad things] to US troops, and therefore soldior testimonies of Iraqi happiness are valid."
This argument has apparently lead you to the bizarre conclusion that Iraqi attacks on American troops are a sign that the Iraqis are content!
Of course, it might just be that most Iraqis are too scared to attack US troops despite being angry at them, but some aren't. Seems more likely to me.
Although having said that the US doesn't have a desparate shortage of oil, see http://observer.guardian.co.uk/international/story/0,6903,882512,00.html
Who do you think owns Iraqi oil? Try the government and people of Iraq. Who owned it before? Saddam.
Right, and who owns the Iraqi government right now? (Hint: there haven't been any elections yet).
It's pretty obvious that the US plan to buy up everything in Iraq worth a dime on the "free market" (i.e. large US corporations buying up the war-ravaged Iraqi economy before it can get off its feet) and secure effective US control of the country and its strategic energy resources.
Re Kuwait, it is not oil per se, but control over oil resources that the US wants. It's not like the US has a desparate oil shortage at the moment, but the power which comes from control over oil production and distribution is inestimable.
Ask the people who throw rocks at the US embassy and soldiers stationed there. Sometimes the rocks are bullets or bombs.
Right, which kind of suggests that the US isn't very popular, doesn't it?
"That's a good deal of what I meant by, "Thought patterns are learned and largely cultural," and "The system would have to be tailored to each. ..culture it would serve."
Hmm, it isn't obviously what you meant because the only concrete example you gave involved syntax, which has virtually no effect on the structure of thought. It's also not the case the infering the attitudes, knowledge and intentions of the speaker will necessarily require much cultural background (unless you want "say something funny" to be a well formed program...) With someone who's writing a program, most of the assumptions you make will have nothing to do with their culture (e.g. the assumption that they want the program not to crash or go into an infinite loop). Presumably no-one would expect their programming system to know that bears shit in the woods or that red wine is served at room temperature. After all, any system which knew as much as the programmer could program itself.
Of course, this does not change the fact that mind-reading is a hard problem, even if it doesn't require a great deal of information about the speaker in certain artificial situations. Humans do it almost effortlessly most of the time, but it'll be a very long time before machines can come close to our ability. Cultural differences are the least of our worries -- it's not like we have perfect NLP systems for English speakers which we can't adapt to Swahili.
Unfortunately if you use a vague phrase like "thought patterns", it's easy to say stuff which sounds good but which is actually completely unfalsifiable. Your statement that thought patterns are learned and largely cultural is virtually meaningless, so it's difficult to criticise.
English speakers (at least the grammatical ones) are familiar with a handful of verb inflections -- singular vs. plural; present or past tense -- but Old English actually inflected the nouns of a sentence as well, to indicate the subject and the predicate. You could say either "Dick hit Jane" or "Jane hit Dick" and the noun inflection, not the word order, determined who actually got hit. I'm no linguist, but I believe there are contemporary languages with similar features.
Well yes, of course there are contemporary languages with similar features.
That's a vast conceptual shift, that a person's name can be said differently according to whether he's the subject or the object of an action.
No it isn't. What you're missing here is that the underlying argument structure of natural languages is pretty universal: inflection and word order are just two different ways of encoding the same agent-patient-theme hierachy. A parser could extract the same semantic information from two languages which on the face of it appear to be quite different. The hypothetical natural language programming system would interpret sentences based on their argument structure rather than their syntax per se.
There are no natural ways of thinking; thought patterns are learned and largely cultural.
Says who? Certainly not modern cognitive science, or indeed modern linguistics. What is a "thought pattern", anyway? If it's any technique for thinking which is learned, then, by definition, anyone who isn't already familiar with it can...learn it. Problem solved.
For "natural programming" to really work, the system would have to be tailored to each native language and culture it would serve.
Obviously the system would have to be tailored to each language, but this would just be a matter of rewriting the parser and vocabulary (and in fact it should be possible to share a lot of the parsing infrastructure between languages). There's no reason to expect any "cultural" issues would extend further than this.
As a linguist, I'm very sceptical of the general utlity of NLP. While it's perfectly possible to parse natural language, it's an impossible problem to reliably extract meaning from it. This is because most meaning in a natural language sentence is not encoded -- it is infered by the hearer based on assumptions about the attitudes, knowledge and intentions of the speaker. Clearly, for a computer to do this it would require a massive encyclopaedic knowledge, and (more or less) a fully functioning human-like mind. I doubt we'll be seeing this any time soon.
The C lanaguage does NOT do that. The OS does. If your program runs on top of an OS that does segmentation/paging and so on, then *ANY* such program, written in *ANY* language, is still going to be one level removed from the hardware due to segmentation/paging. It *must* be that way or else the OS has no memory protection.
The C language does do it. Pointers in C do not correspond directly to any hardware concept. It's true that if you're not writing kernel code, you are prevented to some extent by the OS from manipulating addresses at the hardware level, but it's still the case that C pointers have different semantics to hardware memory addresses. For example, a C pointer becomes invalid if it's incremented beyond the bounds of the block of allocated memory its pointing within, according to the ANSI standard, and C pointers abstract away from segmentation/paging/whatever. It is not possible to have direct access to any hardware features in a portable language -- there is necessarily a layer of abstraction.
(Yes, C may be a little less abstract than other languages, see below for discussion of this...)
But, if you're writing the OS kernel itself, then that's not true anymore - you *can* (and must) get down to pointers on raw hardware. It is entirely possible in C to have pointers to raw hardware addresses, if you are writing a program that is not running on top of a protected memory OS. (for example, a vending-machine embedded program, or the linux kernel itself).
Yes, but those pointers still abstract away from details of the memory architecture somewhat because they're single numbers rather than segment-offset pairs (or whatever), and have less richly-defined semantics. I'm not saying that there's anything wrong with this, just stating it as a fact. If you want to do low-level pointer manipulation in C, you have to extend its semantics beyond those defined in the ANSI standard (by writing inline asm code, using extended pointer arithmetic semantics, etc.) As I said, the situation is no different with a higher level language -- you just extend the semantics of the language to cover low-level features of the hardware when necessary. Low-level access doesn't have to be built into a language any more than database querying does. C comes with a little bit more builtin capability in this regard, but the task of adding the necessary stuff to another language is completely trivial compared to the task of (say) writing an operating system. You basically just need a MemoryAddress abstract datatype and a few (inline) functions to manipulate it and interface pointers with arrays.
C is unsafe, yes. But that's becuase it manipulates memory exactly how you ask it to, and lets you shoot yourself in the foot. But that is not a sufficient reason to stop using it, because some tasks need to be approached that way, like writing a kernel, or passing byte buffers around as is often done in network programming.
C does not in any sense give you complete control over memory management. You can ask for a block of memory and reference elements within the block. You can pass pointers to elements within a block around. Most of the other stuff you can do leaves memory useage up to the compiler (e.g. the internal structure of unions is very loosly defined by the standard; the semantics of pointers are very constrained). Given that C is designed to be portable to just about any architecture (even a VM), it's obviously impossible for it to provide complete control over how memory is managed. Most people who think that they are getting low-level control from C are not in fact programming ANSI-standard C. You could get the same effect using non-standard Lisp or non-standard ML.
As for the rest: only kernel code really needs to manpiulate memory directly, although there may be a few rare cases where you need to do this in userland; byte buffers can be passed around in most any language.
C is a middle-ground between assembly code and a high-level
But, I still have to wonder about this: You claim O'Caml is just as close to the hardware as C except for having GC, but then went on to say that it doesn't have the pointer issues of C. Those are incompatable statements. You need pointers to be close to the hardware. Imagine trying to write a kernel in a language that doesn't let you move chunks of memory around as you wish. (I'm not denying that it sounds like a good language. I'm denying that it could ever be a drop-in replacement for C, used for the same tasks.)
Not sure I agree. Virtually all the sensible things you can do with pointers you can do with arrays and references (by which I mean pointers without pointer arithmetic). If you're writing an OS kernel and need to do some non-sensible things, then you're going to be writing some ASM anyway, and it wouldn't be hard to hack up an O'Caml interface to pointers if you really needed it (assuming O'Caml can be linked with ASM fairly easily -- never tried to do this). In any case, the notion that C pointers are some direct representation of actual hardware pointers is a bit of a myth, since they abstract away from segmentation/paging and so on. The things which you can do with pointers while remaining within the behaviour defined by the C standard are basically exactly the same things you can do with arrays, iterators and references. If you want to do something more, then you may just as well use OCaml-with-extended-semantics as C-with-extended-semantics, given that hacking up the extended semantics will be trivial compared to writing a kernel, or whatever.
Kernel's are admittedly a special case, and even I think that you can make good arguments for writing them in C;) The trouble is that C has a tendency to percolate up the levels of the OS. One minute you have a kernel written in C, the next you have a web browser written in C which depends upon layers and layers of C code, with thousands of lines of manual buffer management code, all of which is potentially buggy.
I don't have any particular brief for O'Caml btw, I could have said the same things about a decent Lisp implementation. And of course there's a bit more proof of concept in Lisp land what with Lisp machines, etc.
This is a non-problem, because if you don't trust the kernel code that strongly, you've got much, much bigger problems than this to deal with, such that arguments over string libraries in languages become piddly and irrelevant if you can't even trust that the kernel is managing your program's memory correctly, for example.
It's not entirely a non-problem. You could have a kernel which was perfect except for one bug involving a string buffer passed to a system call. Such a bug might be less serious if the kernel was not written in C. I'm not trying to say that this is a likely scenario, merely pointing out that it is not inevitable that any high-level language must trust tens of thousands of lines of low-level code to handle memory correctly. If you have a kernel in a high-level language, (many) string memory management problems could be localised to a few hundred/thousand lines of very heavily tested code. My argument is not that people should genuinely be worried about bugs in kernel functions most of the time, merely that having lots and lots of unsafe low-level code is not the only option.
It's good that this isn't my argument, then. I don't have to believe that C is perfectly safe in order to deny your claim that C is unsafe so you should use something else. There *IS* a middle-ground between the two.
Well, you keep telling me what your argument isn't but I (honestly) can't work out what it is. To stop this getting into a silly metadiscussion, I'll instead give my argument, which I think is relevant to your argument (whatever that is). However good you are, it is possible to write buggy C code which is buggy in ways unique to low-level languages. Therefore, it's likely that software written by equally good programmers
Opendarwin does not necessarily have better hardware support than Linux. There are no third party drivers for anything available, so for example I couldn't get my Alcatel Speedtouch modem working on Opendarwin.
It might technically be possible to use OS X drivers (I don't know enough about the two systems to say), but it's certainly not easy given that their installer programs rely on all the Cocoa infrastructure.
If you're going to spend the money for a Mac you owe itself to yourself to use OS X. It has a superior gui (i'm not trolling!), there's absolutely no hardware compatibility program... <snip>
What if I want to spend the money for a Mac, but don't want to spend the money for a new version of OS X every year? My powerbook came with 10.2 (which is now not very well supported, e.g. latest Apple dev tools won't run on it, Fink doesn't really support it) and the cost of upgrading isn't worth it when I can run Linux (Gentoo) instead.
You could take a look at the great computer language shootout. It's also a pretty general consensus wrt O'Caml, and not in the least bit surprising because O'Caml's high level features are mostly related to its type/module system, rather than to automagical features (such as you tend to find in scripting languages, etc.) As far as closeness to the hardware is concerned, basically all that distinguishes O'Caml and C is that O'Caml is GC'd. This doesn't create much of a performance hit, as the benchmarks show. O'Caml is also a better candidate for optimisation than C because it doesn't have so many pointer issues (pointer aliasing, etc.)
True. But since this is also true of every other language, this isn't relevant to your point. (If you think high-level languages never end up dropping down to doing things in a low-level C way inside their libraries, you are kidding yourself. Eventually every program talks to the OS at some point, even if it's just in the libraries, and that's going to mean the libraries will have C calls in them.)
Only if the OS is written in C. You're correct that since most popular OSs are written in C, it's pratically impossible to write safe string manipulation code (and lots of other kinds of code, natch), in any language unless you trust the kernel code very strongly. This is just one more black mark against C, so far as I can see.
I agree that that statement is bullshit. Your claim that it is a summary of what I said, however, is also bullshit.
You implied that a programmer who was good enough to do [various complex coding tasks] could be trusted not to make errors in simple string manipulation code. Erm, bullshit. If you do in fact believe that any coder, however good, is capable of writing buggy string manipulation code, then the argument that C is safe if you know how to use it properly doesn't go through, i.e. there would still be a class of bugs which a grade A programmer could make in C that they couldn't make in (say) Java. Being unable to know for sure the length of any array created by untrusted code would be one example.
If that's all you want to use your computer for, then don't waste your money on a faster computer. For those who do want more speed, stop dictating that they must waste it on needs which are already served by cheaper hardware.
1) It's not all I want to do, but you did not qualify your statement that "there is no such thing as fast enough". As a point of fact, there is such a thing as fast enough for many, many applications which currently tend to be written in C/C++.
I repeatedly hear claims of this, but it doesn't seem like it in practice. I find it really hard to believe. In an optimized test that doesn't excercise the problem areas much, I could see a hit of only 15%, but that would have to be a program that just prints out strings, and maybe does some math. But in practice a real program is going to contain lots of data structure manipulations, and that's where the performance hit is (and that's the main point of using a 'safer' language, too.)
Just because you find it hard to believe doesn't mean it isn't true. There are plenty of very high level languages (e.g. O'Caml) that have no more overhead in manipulating data structures than C does. O'Caml does (verifiably) have performance comparable to C.
But I am of the opinion that a programmer that makes those errors that often should not be writing my operating system's core programs (e-mail server, web server, etc). I *want* a programmer for whom bit-twiddling and memory tricks is second nature. If you can't keep strncpy() straight, then I don't want you writing TCP/IP socket code, or writing programs that fork() and have to avoid zombies or any of that sort of thing. These programs aren't entirely OS, and aren't entirely application. They sit at the bridge between them.
In other words "if you're a good programmer, you will never make trivial mistakes". Bullshit.
Then you are using an undocumented call, just as much as if the documentation had forgotten to tell you the return type, or forgotten to tell you if a variable was pass-by-value or pass-by-reference. Not once have I encountered this problem with the stuff in stdlib. The manpage documentation for every function call that deals with strings is very explicit about null termination.
Ah, but what if there's a bug in the library? In C, you depend not only on the correctness of your own memory management code, but also on that of any library which you use.
No. Not at all. When I pay Intel a pile of cash to buy a faster chip, I want that cash to buy me faster programs. There is no such thing as "fast enough". For example, if the computer gets fast enough to render a realtime 3d animation at 30 fps, and still have plenty of cycles to space, then great - that means there's now an opportunity to use that extra clock time to add more details to the scene, or perhaps render more than one scene at a time.
Of course there's such a thing as fast enough. My email client and web browser have been running fast enough for years. Now I'd rather have an (unnoticable) 20% performance decrease than have them crash every few days.
Note that there's also no such thing as "clever enough". If you want to write a smart program, it's easier to do it in a high level language.
Regular Expressions to Context Sensitive (at least) Parsing. I'm not a big Perl Geek, but I use it on a daily basis.
No, the grammars this system parses are a subset of the context-free grammars (if we exclude any context-sensitive behaviour created at a higher level using actions).
'Mind your own business' is something I'd like to think is uniquely American.
Erm, whatever. Sounds more stereotypically English to me, certainly not uniquely American. Anyway, now the US has the best of both worlds: if you forget to mind your own business for a little while, John Ashcroft will mind it for you;)
Adding buffer overflow checks to a programming language does not turn an incorrect program into a correct program. It turns an incorrect program into an incorrect program with less of a license to kill.
Which is a good thing, right?
At the same time, there are many programmers out there who never make a bounds mistake in any language.
That must be why there are so many C/C++ network programs which have never had any buffer overrun bugs. Come on, this is one of the most common security bugs in C/C++ programs. Some programmers rarely make bounds mistakes would be more accurate.
When I program in a bounds checked language, I don't sigh inwardly to myself "oh, I can program much faster now". I continue to put exactly as much work into the program as required to make my C code correct.
That's great. The point is that if you do make a mistake: a) it's easier to find where the out-of-bounds access occured, and b) there's a lot fewer opporunities for exploits.
Bounds checking (either compile-time or runtime) is not a pancea, obviously, but it's still a good thing.
Well, for one, at the time C++ was designed, I doubt there were many (if at all) higher level, compiled languages around. And if C was integrated with such a language, wouldn't that language have suffered from the same backward compatibility problems that C++ has ?
Completely and utterly wrong. Lisp compilers had been around for a decades, and statically-typed functional languages with type inference (e.g. Miranda, ML) were just starting to come onto the scene. They don't suffer from backwards compatibility problems (although, as I said, they could do with a lot more work on integration, as opposed to compatibility, with C).
The advantage of garbage collection over reference counting is something I never understood.
Yes, there are overhead to reference counting, but on the other hand, I understand that garbage collection has to find out whether objects are still used or not at a time where there isn't any informations around to help this, thus it has to walk through all objects in memory to check which are to be deleted.
Looks like you don't understand GC, then. You're describing an extremely simple mark/sweep algorithm. This is not how modern generational GCs work: they incrementally free garbage, starting with garbage which is easy to find and quick to deallocate (roughly speaking -- there are lots of different algorithms). If reference counting was more efficient than other algorithms, GCs for fast compiled languages would use reference counting (it's certainly possible, many scripting languages use reference counting GC). Also bear in mind the space overhead of reference counts, which is significant for small objects.
You can have terminate functions in your objects to make them free these kind of resources, but doesn't it defeat the whole purpose of garbage collection, which is to automatize resource management ?
Resource aquisition/release idioms don't have to be parasitic on constructor/destructor idioms. Lisp, for example, has an elegant solution to this kind of problem with its unwind-protect macro. I agree that some GC'd language come up short here (e.g. Java, where you have to release resources explicitly in a finally block).
Yes, but if C++ wasn't backward compatible with C, most of the stuff today would still be in C. Or would be in another language which would have been backward compatible with C.
Not necessarily. The effort spent writing C++ would have been more profitably spent integrating C with higher level (but still compiled) languages. This is not a criticism of C++ implementors, it's obviously up to them how they spend their time.
Or only that proper usage of the tool just isn't widely enough documented...
Oh come on;) Every man and his dog is iterating the "C++ is a very powerful tool if only you know how to use it properly" meme. There is no lack of documentation here, quite the opposite.
Just for the same reason that people won't just rewrite their existing code in java, or c#, or whatever else you consider a better tool.
Sure, I didn't suggest rewriting existing C/C++ programs. That's usually a bad idea.
Besides, what would constitute a better tool is highly debatable.
Naturally, but that doesn't mean that there isn't a better tool. It's debatable what's a better tool for hunting than a spear (is it gun X, gun Y, etc.?), but that doesn't mean that no better tool exists.
A lot of the allegedly better tools enforce the usage of stuff (like garbage collectors) that are not suited for everything using C or C++ today.
GC is almost always a good thing given a decently optimized implementation (i.e., we're not talking Perl5/Python/Tcl here, more like OCaml, Lisp, etc.) The overhead is small and tends to be less than that of reference counting smart pointers and their ilk. Reference counting is not particularly efficient, especially when implemented manually.
Generally, a lot of time these days is spent implemeting high-level languages on top of C++ using its metaprogramming facilities. This is broadly a good thing, but these HLLs on top of C++ tend to be less well implemented and less efficient than real HLLs. Safe code is usually either going to be fast and very hard to understand, or slow(er) and easy to understand.
And less efficient than error checking built into the compiler ? Why ? It's error checking done by the compiler, only the error checks aren't hardcoded in the compiler, but implemented by the standard library.
Because the compiler can somtimes optimise away range checking if it can prove that a section of code is safe.
It's because of backwards compatibility with C. If you program in C++, you're supposed to use the standard library containers. The thing is, without the backward compatibility with C, C++ wouldn't have been quite as successful, anyway.
Exactly, backwards compatibility with C is a major source of security bugs.
It's enough, only if properly used. There's no need for new tools. What's the point of creating new tools when the old one are rarely ever used properly, anyway ? I also though that C++ sucked until I learned to use it properly.
Ah, another arrogant C++ programmer who thinks the only reason there are bugs in C++ programs is "improper" usage of the language. If a tool is rarely used properly, this is often a sign that the tool sucks, or at least that it's too hard to use properly. In the case of C++, I'd say it's sometimes practically impossible to use properly. Why not use a better tool?
The compiler source code is part of the documentation. Admittedly, it's a highly advanced topic; but it's not one you should be afraid of. Of course, if you assumed without checking that b[0] would follow a[199], and you failed to comment in your code what you were doing when you mucked about with a[200], then you deserve what you get.
It's not part of the documentation of ANSI C, and it's not part of the documentation of the compiler.
Admittedly, it's a highly advanced topic; but it's not one you should be afraid of. Of course, if you assumed without checking that b[0] would follow a[199], and you failed to comment in your code what you were doing when you mucked about with a[200], then you deserve what you get.
Why on earth would you want to do this, making you dependant one one version of one compiler? Why not just write the code using one array and make it portable.
It's decorative in the sense of a thin paper screen in front of an open fire. In other words, it doesn't actually offer you any real protection at all; but a person who did not fully appreciate what would be the likely consequence of a hot piece of fuel being ejected from the fireplace towards such a screen, might nonetheless feel lulled into a false sense of security by its presence -- and end up getting burned worse than if the screen wasn't there.
This is just silly. Shouldn't have to work for so little money? Then perhaps they should pick up a skill which would make them worth more to their employers.
Perhaps they should. In the meantime I think they should get enough money to live on. People ought to be able to live decently whether or not some company happens to think they're worth >X amount of money.
The employers tend to give things called raises to employees who show that they're worth keeping.
Hmm, yeah, like most minimum wage jobs have great career opportunities...
The government shouldn't be in the business of picking up the slack of people who aren't skilled enough to get decent jobs.
Sorry, but I think it should be in that business. It's supposed to represent everyone, not just the people who have nice jobs and want to keep all their money.
It already pays for their entire freaking education through high school including work study programs and grants.
That's because the government provides universal education, which is a good thing, both for the people it educates and the economy. It seems ridiculous to say "since we've provided you with an education, any economic difficulty you find yourself in is entirely your fault and we're not going to help".
You're also forgetting immigrants who have not been educated here anyway, and who perhaps have very little education.
Quite possibly, but they shouldn't have to work for so little money in the first place. Like I said, if some unemployment is caused by a minimum wage, the government can always pick up the slack. It's worth it for the improvement in overall standard of living, IMO.
I don't see economists agreeing on this one as much as you suggest: http://www.epinet.org/content.cfm/minwagestmt2004
The minimum wage in the US is so tiny that I find it hard to believe that it has much real effect on employment. This sounds to me like businesses threatening to cut jobs unless the government upholds their (non-existant, IMHO) right to employ people on pitifully low wages. The government should call their bluff.
If there really are people who can't be employed because they aren't worth $minimum_wage dollars an hour, they'll just have to be supported by the government. If there are so many of these people that this starts to cost significant amounts of money, then there are clearly problems with the economy and standards of education which extend further than the minumum wage issue.
There are of course plenty of people who don't have to support themselves, and so don't need to get >=$minumum_wage. Either you modify minimum wage laws to take this into account, or you put up with it. It's no big deal.
Slashdot Mirror
Shoot people who are terrorizing and holding hostage civilians in their own city
You know, it's the US that refused to allow any males between 15 and 50 to leave, so I think if anyone's to blame for civilians being trapped in Fallujah...
Yeah, that's possible, too, but it seems more likely that a minority of the people (and not all of them Iraqis) are interested in attacking US (and coalition, and Iraqi) troops.
That's exactly what I suggested.
The rest of them are just trying to live there lives.
Sure, but that it not a sign that they are in favour of the occupation.
What about all the Iraqis signing up for the police and armed forces? Are they all 5th columnists, too?
No, but the Iraqi police aren't a great deal more popular than the US military.
How else could you interpret it?? Were they friendly bombs?
Look, the original argument was something like "if the Iraqis wanted the US out, they wouldn't be afriad to [do bad things] to US troops, and therefore soldior testimonies of Iraqi happiness are valid."
This argument has apparently lead you to the bizarre conclusion that Iraqi attacks on American troops are a sign that the Iraqis are content!
Of course, it might just be that most Iraqis are too scared to attack US troops despite being angry at them, but some aren't. Seems more likely to me.
Although having said that the US doesn't have a desparate shortage of oil, see http://observer.guardian.co.uk/international/story /0,6903,882512,00.html
Who do you think owns Iraqi oil? Try the government and people of Iraq. Who owned it before? Saddam.
Right, and who owns the Iraqi government right now? (Hint: there haven't been any elections yet).
It's pretty obvious that the US plan to buy up everything in Iraq worth a dime on the "free market" (i.e. large US corporations buying up the war-ravaged Iraqi economy before it can get off its feet) and secure effective US control of the country and its strategic energy resources.
Re Kuwait, it is not oil per se, but control over oil resources that the US wants. It's not like the US has a desparate oil shortage at the moment, but the power which comes from control over oil production and distribution is inestimable.
Ask the people who throw rocks at the US embassy and soldiers stationed there. Sometimes the rocks are bullets or bombs. Right, which kind of suggests that the US isn't very popular, doesn't it?
"That's a good deal of what I meant by, "Thought patterns are learned and largely cultural," and "The system would have to be tailored to each. . .culture it would serve."
Hmm, it isn't obviously what you meant because the only concrete example you gave involved syntax, which has virtually no effect on the structure of thought. It's also not the case the infering the attitudes, knowledge and intentions of the speaker will necessarily require much cultural background (unless you want "say something funny" to be a well formed program...) With someone who's writing a program, most of the assumptions you make will have nothing to do with their culture (e.g. the assumption that they want the program not to crash or go into an infinite loop). Presumably no-one would expect their programming system to know that bears shit in the woods or that red wine is served at room temperature. After all, any system which knew as much as the programmer could program itself.
Of course, this does not change the fact that mind-reading is a hard problem, even if it doesn't require a great deal of information about the speaker in certain artificial situations. Humans do it almost effortlessly most of the time, but it'll be a very long time before machines can come close to our ability. Cultural differences are the least of our worries -- it's not like we have perfect NLP systems for English speakers which we can't adapt to Swahili.
Unfortunately if you use a vague phrase like "thought patterns", it's easy to say stuff which sounds good but which is actually completely unfalsifiable. Your statement that thought patterns are learned and largely cultural is virtually meaningless, so it's difficult to criticise.
English speakers (at least the grammatical ones) are familiar with a handful of verb inflections -- singular vs. plural; present or past tense -- but Old English actually inflected the nouns of a sentence as well, to indicate the subject and the predicate. You could say either "Dick hit Jane" or "Jane hit Dick" and the noun inflection, not the word order, determined who actually got hit. I'm no linguist, but I believe there are contemporary languages with similar features.
Well yes, of course there are contemporary languages with similar features.
That's a vast conceptual shift, that a person's name can be said differently according to whether he's the subject or the object of an action.
No it isn't. What you're missing here is that the underlying argument structure of natural languages is pretty universal: inflection and word order are just two different ways of encoding the same agent-patient-theme hierachy. A parser could extract the same semantic information from two languages which on the face of it appear to be quite different. The hypothetical natural language programming system would interpret sentences based on their argument structure rather than their syntax per se.
There are no natural ways of thinking; thought patterns are learned and largely cultural.
Says who? Certainly not modern cognitive science, or indeed modern linguistics. What is a "thought pattern", anyway? If it's any technique for thinking which is learned, then, by definition, anyone who isn't already familiar with it can...learn it. Problem solved.
For "natural programming" to really work, the system would have to be tailored to each native language and culture it would serve.
Obviously the system would have to be tailored to each language, but this would just be a matter of rewriting the parser and vocabulary (and in fact it should be possible to share a lot of the parsing infrastructure between languages). There's no reason to expect any "cultural" issues would extend further than this.
As a linguist, I'm very sceptical of the general utlity of NLP. While it's perfectly possible to parse natural language, it's an impossible problem to reliably extract meaning from it. This is because most meaning in a natural language sentence is not encoded -- it is infered by the hearer based on assumptions about the attitudes, knowledge and intentions of the speaker. Clearly, for a computer to do this it would require a massive encyclopaedic knowledge, and (more or less) a fully functioning human-like mind. I doubt we'll be seeing this any time soon.
The C lanaguage does NOT do that. The OS does. If your program runs on top of an OS that does segmentation/paging and so on, then *ANY* such program, written in *ANY* language, is still going to be one level removed from the hardware due to segmentation/paging. It *must* be that way or else the OS has no memory protection.
The C language does do it. Pointers in C do not correspond directly to any hardware concept. It's true that if you're not writing kernel code, you are prevented to some extent by the OS from manipulating addresses at the hardware level, but it's still the case that C pointers have different semantics to hardware memory addresses. For example, a C pointer becomes invalid if it's incremented beyond the bounds of the block of allocated memory its pointing within, according to the ANSI standard, and C pointers abstract away from segmentation/paging/whatever. It is not possible to have direct access to any hardware features in a portable language -- there is necessarily a layer of abstraction.
(Yes, C may be a little less abstract than other languages, see below for discussion of this...)
But, if you're writing the OS kernel itself, then that's not true anymore - you *can* (and must) get down to pointers on raw hardware. It is entirely possible in C to have pointers to raw hardware addresses, if you are writing a program that is not running on top of a protected memory OS. (for example, a vending-machine embedded program, or the linux kernel itself).
Yes, but those pointers still abstract away from details of the memory architecture somewhat because they're single numbers rather than segment-offset pairs (or whatever), and have less richly-defined semantics. I'm not saying that there's anything wrong with this, just stating it as a fact. If you want to do low-level pointer manipulation in C, you have to extend its semantics beyond those defined in the ANSI standard (by writing inline asm code, using extended pointer arithmetic semantics, etc.) As I said, the situation is no different with a higher level language -- you just extend the semantics of the language to cover low-level features of the hardware when necessary. Low-level access doesn't have to be built into a language any more than database querying does. C comes with a little bit more builtin capability in this regard, but the task of adding the necessary stuff to another language is completely trivial compared to the task of (say) writing an operating system. You basically just need a MemoryAddress abstract datatype and a few (inline) functions to manipulate it and interface pointers with arrays.
C is unsafe, yes. But that's becuase it manipulates memory exactly how you ask it to, and lets you shoot yourself in the foot. But that is not a sufficient reason to stop using it, because some tasks need to be approached that way, like writing a kernel, or passing byte buffers around as is often done in network programming.
C does not in any sense give you complete control over memory management. You can ask for a block of memory and reference elements within the block. You can pass pointers to elements within a block around. Most of the other stuff you can do leaves memory useage up to the compiler (e.g. the internal structure of unions is very loosly defined by the standard; the semantics of pointers are very constrained). Given that C is designed to be portable to just about any architecture (even a VM), it's obviously impossible for it to provide complete control over how memory is managed. Most people who think that they are getting low-level control from C are not in fact programming ANSI-standard C. You could get the same effect using non-standard Lisp or non-standard ML.
As for the rest: only kernel code really needs to manpiulate memory directly, although there may be a few rare cases where you need to do this in userland; byte buffers can be passed around in most any language.
C is a middle-ground between assembly code and a high-level
But, I still have to wonder about this: You claim O'Caml is just as close to the hardware as C except for having GC, but then went on to say that it doesn't have the pointer issues of C. Those are incompatable statements. You need pointers to be close to the hardware. Imagine trying to write a kernel in a language that doesn't let you move chunks of memory around as you wish. (I'm not denying that it sounds like a good language. I'm denying that it could ever be a drop-in replacement for C, used for the same tasks.)
Not sure I agree. Virtually all the sensible things you can do with pointers you can do with arrays and references (by which I mean pointers without pointer arithmetic). If you're writing an OS kernel and need to do some non-sensible things, then you're going to be writing some ASM anyway, and it wouldn't be hard to hack up an O'Caml interface to pointers if you really needed it (assuming O'Caml can be linked with ASM fairly easily -- never tried to do this). In any case, the notion that C pointers are some direct representation of actual hardware pointers is a bit of a myth, since they abstract away from segmentation/paging and so on. The things which you can do with pointers while remaining within the behaviour defined by the C standard are basically exactly the same things you can do with arrays, iterators and references. If you want to do something more, then you may just as well use OCaml-with-extended-semantics as C-with-extended-semantics, given that hacking up the extended semantics will be trivial compared to writing a kernel, or whatever.
Kernel's are admittedly a special case, and even I think that you can make good arguments for writing them in C ;) The trouble is that C has a tendency to percolate up the levels of the OS. One minute you have a kernel written in C, the next you have a web browser written in C which depends upon layers and layers of C code, with thousands of lines of manual buffer management code, all of which is potentially buggy.
I don't have any particular brief for O'Caml btw, I could have said the same things about a decent Lisp implementation. And of course there's a bit more proof of concept in Lisp land what with Lisp machines, etc.
This is a non-problem, because if you don't trust the kernel code that strongly, you've got much, much bigger problems than this to deal with, such that arguments over string libraries in languages become piddly and irrelevant if you can't even trust that the kernel is managing your program's memory correctly, for example.
It's not entirely a non-problem. You could have a kernel which was perfect except for one bug involving a string buffer passed to a system call. Such a bug might be less serious if the kernel was not written in C. I'm not trying to say that this is a likely scenario, merely pointing out that it is not inevitable that any high-level language must trust tens of thousands of lines of low-level code to handle memory correctly. If you have a kernel in a high-level language, (many) string memory management problems could be localised to a few hundred/thousand lines of very heavily tested code. My argument is not that people should genuinely be worried about bugs in kernel functions most of the time, merely that having lots and lots of unsafe low-level code is not the only option.
It's good that this isn't my argument, then. I don't have to believe that C is perfectly safe in order to deny your claim that C is unsafe so you should use something else. There *IS* a middle-ground between the two.
Well, you keep telling me what your argument isn't but I (honestly) can't work out what it is. To stop this getting into a silly metadiscussion, I'll instead give my argument, which I think is relevant to your argument (whatever that is). However good you are, it is possible to write buggy C code which is buggy in ways unique to low-level languages. Therefore, it's likely that software written by equally good programmers
Opendarwin does not necessarily have better hardware support than Linux. There are no third party drivers for anything available, so for example I couldn't get my Alcatel Speedtouch modem working on Opendarwin.
It might technically be possible to use OS X drivers (I don't know enough about the two systems to say), but it's certainly not easy given that their installer programs rely on all the Cocoa infrastructure.
If you're going to spend the money for a Mac you owe itself to yourself to use OS X. It has a superior gui (i'm not trolling!), there's absolutely no hardware compatibility program... <snip>
What if I want to spend the money for a Mac, but don't want to spend the money for a new version of OS X every year? My powerbook came with 10.2 (which is now not very well supported, e.g. latest Apple dev tools won't run on it, Fink doesn't really support it) and the cost of upgrading isn't worth it when I can run Linux (Gentoo) instead.
Provide a link to this proof.
You could take a look at the great computer language shootout. It's also a pretty general consensus wrt O'Caml, and not in the least bit surprising because O'Caml's high level features are mostly related to its type/module system, rather than to automagical features (such as you tend to find in scripting languages, etc.) As far as closeness to the hardware is concerned, basically all that distinguishes O'Caml and C is that O'Caml is GC'd. This doesn't create much of a performance hit, as the benchmarks show. O'Caml is also a better candidate for optimisation than C because it doesn't have so many pointer issues (pointer aliasing, etc.)
True. But since this is also true of every other language, this isn't relevant to your point. (If you think high-level languages never end up dropping down to doing things in a low-level C way inside their libraries, you are kidding yourself. Eventually every program talks to the OS at some point, even if it's just in the libraries, and that's going to mean the libraries will have C calls in them.)
Only if the OS is written in C. You're correct that since most popular OSs are written in C, it's pratically impossible to write safe string manipulation code (and lots of other kinds of code, natch), in any language unless you trust the kernel code very strongly. This is just one more black mark against C, so far as I can see.
I agree that that statement is bullshit. Your claim that it is a summary of what I said, however, is also bullshit.
You implied that a programmer who was good enough to do [various complex coding tasks] could be trusted not to make errors in simple string manipulation code. Erm, bullshit. If you do in fact believe that any coder, however good, is capable of writing buggy string manipulation code, then the argument that C is safe if you know how to use it properly doesn't go through, i.e. there would still be a class of bugs which a grade A programmer could make in C that they couldn't make in (say) Java. Being unable to know for sure the length of any array created by untrusted code would be one example.
If that's all you want to use your computer for, then don't waste your money on a faster computer. For those who do want more speed, stop dictating that they must waste it on needs which are already served by cheaper hardware.
1) It's not all I want to do, but you did not qualify your statement that "there is no such thing as fast enough". As a point of fact, there is such a thing as fast enough for many, many applications which currently tend to be written in C/C++.
2) I wasn't dictating anything.
I repeatedly hear claims of this, but it doesn't seem like it in practice. I find it really hard to believe. In an optimized test that doesn't excercise the problem areas much, I could see a hit of only 15%, but that would have to be a program that just prints out strings, and maybe does some math. But in practice a real program is going to contain lots of data structure manipulations, and that's where the performance hit is (and that's the main point of using a 'safer' language, too.)
Just because you find it hard to believe doesn't mean it isn't true. There are plenty of very high level languages (e.g. O'Caml) that have no more overhead in manipulating data structures than C does. O'Caml does (verifiably) have performance comparable to C.
But I am of the opinion that a programmer that makes those errors that often should not be writing my operating system's core programs (e-mail server, web server, etc). I *want* a programmer for whom bit-twiddling and memory tricks is second nature. If you can't keep strncpy() straight, then I don't want you writing TCP/IP socket code, or writing programs that fork() and have to avoid zombies or any of that sort of thing. These programs aren't entirely OS, and aren't entirely application. They sit at the bridge between them.
In other words "if you're a good programmer, you will never make trivial mistakes". Bullshit.
Then you are using an undocumented call, just as much as if the documentation had forgotten to tell you the return type, or forgotten to tell you if a variable was pass-by-value or pass-by-reference. Not once have I encountered this problem with the stuff in stdlib. The manpage documentation for every function call that deals with strings is very explicit about null termination.
Ah, but what if there's a bug in the library? In C, you depend not only on the correctness of your own memory management code, but also on that of any library which you use.
No. Not at all. When I pay Intel a pile of cash to buy a faster chip, I want that cash to buy me faster programs. There is no such thing as "fast enough". For example, if the computer gets fast enough to render a realtime 3d animation at 30 fps, and still have plenty of cycles to space, then great - that means there's now an opportunity to use that extra clock time to add more details to the scene, or perhaps render more than one scene at a time.
Of course there's such a thing as fast enough. My email client and web browser have been running fast enough for years. Now I'd rather have an (unnoticable) 20% performance decrease than have them crash every few days.
Note that there's also no such thing as "clever enough". If you want to write a smart program, it's easier to do it in a high level language.
Regular Expressions to Context Sensitive (at least) Parsing. I'm not a big Perl Geek, but I use it on a daily basis.
No, the grammars this system parses are a subset of the context-free grammars (if we exclude any context-sensitive behaviour created at a higher level using actions).
Is the distinction of any significance in this context? I'm English myself so I know the geography...
'Mind your own business' is something I'd like to think is uniquely American.
Erm, whatever. Sounds more stereotypically English to me, certainly not uniquely American. Anyway, now the US has the best of both worlds: if you forget to mind your own business for a little while, John Ashcroft will mind it for you ;)
Adding buffer overflow checks to a programming language does not turn an incorrect program into a correct program. It turns an incorrect program into an incorrect program with less of a license to kill.
Which is a good thing, right?
At the same time, there are many programmers out there who never make a bounds mistake in any language.
That must be why there are so many C/C++ network programs which have never had any buffer overrun bugs. Come on, this is one of the most common security bugs in C/C++ programs. Some programmers rarely make bounds mistakes would be more accurate.
When I program in a bounds checked language, I don't sigh inwardly to myself "oh, I can program much faster now". I continue to put exactly as much work into the program as required to make my C code correct.
That's great. The point is that if you do make a mistake: a) it's easier to find where the out-of-bounds access occured, and b) there's a lot fewer opporunities for exploits.
Bounds checking (either compile-time or runtime) is not a pancea, obviously, but it's still a good thing.
Well, for one, at the time C++ was designed, I doubt there were many (if at all) higher level, compiled languages around. And if C was integrated with such a language, wouldn't that language have suffered from the same backward compatibility problems that C++ has ?
Completely and utterly wrong. Lisp compilers had been around for a decades, and statically-typed functional languages with type inference (e.g. Miranda, ML) were just starting to come onto the scene. They don't suffer from backwards compatibility problems (although, as I said, they could do with a lot more work on integration, as opposed to compatibility, with C).
The advantage of garbage collection over reference counting is something I never understood. Yes, there are overhead to reference counting, but on the other hand, I understand that garbage collection has to find out whether objects are still used or not at a time where there isn't any informations around to help this, thus it has to walk through all objects in memory to check which are to be deleted.
Looks like you don't understand GC, then. You're describing an extremely simple mark/sweep algorithm. This is not how modern generational GCs work: they incrementally free garbage, starting with garbage which is easy to find and quick to deallocate (roughly speaking -- there are lots of different algorithms). If reference counting was more efficient than other algorithms, GCs for fast compiled languages would use reference counting (it's certainly possible, many scripting languages use reference counting GC). Also bear in mind the space overhead of reference counts, which is significant for small objects.
You can have terminate functions in your objects to make them free these kind of resources, but doesn't it defeat the whole purpose of garbage collection, which is to automatize resource management ?
Resource aquisition/release idioms don't have to be parasitic on constructor/destructor idioms. Lisp, for example, has an elegant solution to this kind of problem with its unwind-protect macro. I agree that some GC'd language come up short here (e.g. Java, where you have to release resources explicitly in a finally block).
Yes, but if C++ wasn't backward compatible with C, most of the stuff today would still be in C. Or would be in another language which would have been backward compatible with C.
Not necessarily. The effort spent writing C++ would have been more profitably spent integrating C with higher level (but still compiled) languages. This is not a criticism of C++ implementors, it's obviously up to them how they spend their time.
Or only that proper usage of the tool just isn't widely enough documented...
Oh come on ;) Every man and his dog is iterating the "C++ is a very powerful tool if only you know how to use it properly" meme. There is no lack of documentation here, quite the opposite.
Just for the same reason that people won't just rewrite their existing code in java, or c#, or whatever else you consider a better tool.
Sure, I didn't suggest rewriting existing C/C++ programs. That's usually a bad idea.
Besides, what would constitute a better tool is highly debatable.
Naturally, but that doesn't mean that there isn't a better tool. It's debatable what's a better tool for hunting than a spear (is it gun X, gun Y, etc.?), but that doesn't mean that no better tool exists.
A lot of the allegedly better tools enforce the usage of stuff (like garbage collectors) that are not suited for everything using C or C++ today.
GC is almost always a good thing given a decently optimized implementation (i.e., we're not talking Perl5/Python/Tcl here, more like OCaml, Lisp, etc.) The overhead is small and tends to be less than that of reference counting smart pointers and their ilk. Reference counting is not particularly efficient, especially when implemented manually.
Generally, a lot of time these days is spent implemeting high-level languages on top of C++ using its metaprogramming facilities. This is broadly a good thing, but these HLLs on top of C++ tend to be less well implemented and less efficient than real HLLs. Safe code is usually either going to be fast and very hard to understand, or slow(er) and easy to understand.
And less efficient than error checking built into the compiler ? Why ? It's error checking done by the compiler, only the error checks aren't hardcoded in the compiler, but implemented by the standard library.
Because the compiler can somtimes optimise away range checking if it can prove that a section of code is safe.
It's because of backwards compatibility with C. If you program in C++, you're supposed to use the standard library containers. The thing is, without the backward compatibility with C, C++ wouldn't have been quite as successful, anyway.
Exactly, backwards compatibility with C is a major source of security bugs.
It's enough, only if properly used. There's no need for new tools. What's the point of creating new tools when the old one are rarely ever used properly, anyway ? I also though that C++ sucked until I learned to use it properly.
Ah, another arrogant C++ programmer who thinks the only reason there are bugs in C++ programs is "improper" usage of the language. If a tool is rarely used properly, this is often a sign that the tool sucks, or at least that it's too hard to use properly. In the case of C++, I'd say it's sometimes practically impossible to use properly. Why not use a better tool?
The compiler source code is part of the documentation. Admittedly, it's a highly advanced topic; but it's not one you should be afraid of. Of course, if you assumed without checking that b[0] would follow a[199], and you failed to comment in your code what you were doing when you mucked about with a[200], then you deserve what you get.
It's not part of the documentation of ANSI C, and it's not part of the documentation of the compiler.
Admittedly, it's a highly advanced topic; but it's not one you should be afraid of. Of course, if you assumed without checking that b[0] would follow a[199], and you failed to comment in your code what you were doing when you mucked about with a[200], then you deserve what you get.
Why on earth would you want to do this, making you dependant one one version of one compiler? Why not just write the code using one array and make it portable.
It's decorative in the sense of a thin paper screen in front of an open fire. In other words, it doesn't actually offer you any real protection at all; but a person who did not fully appreciate what would be the likely consequence of a hot piece of fuel being ejected from the fireplace towards such a screen, might nonetheless feel lulled into a false sense of security by its presence -- and end up getting burned worse than if the screen wasn't there.
It's better than nothing.
This is just silly. Shouldn't have to work for so little money? Then perhaps they should pick up a skill which would make them worth more to their employers.
Perhaps they should. In the meantime I think they should get enough money to live on. People ought to be able to live decently whether or not some company happens to think they're worth >X amount of money.
The employers tend to give things called raises to employees who show that they're worth keeping.
Hmm, yeah, like most minimum wage jobs have great career opportunities...
The government shouldn't be in the business of picking up the slack of people who aren't skilled enough to get decent jobs.
Sorry, but I think it should be in that business. It's supposed to represent everyone, not just the people who have nice jobs and want to keep all their money.
It already pays for their entire freaking education through high school including work study programs and grants.
That's because the government provides universal education, which is a good thing, both for the people it educates and the economy. It seems ridiculous to say "since we've provided you with an education, any economic difficulty you find yourself in is entirely your fault and we're not going to help".
You're also forgetting immigrants who have not been educated here anyway, and who perhaps have very little education.
Quite possibly, but they shouldn't have to work for so little money in the first place. Like I said, if some unemployment is caused by a minimum wage, the government can always pick up the slack. It's worth it for the improvement in overall standard of living, IMO.
I don't see economists agreeing on this one as much as you suggest: http://www.epinet.org/content.cfm/minwagestmt2004
The minimum wage in the US is so tiny that I find it hard to believe that it has much real effect on employment. This sounds to me like businesses threatening to cut jobs unless the government upholds their (non-existant, IMHO) right to employ people on pitifully low wages. The government should call their bluff.
If there really are people who can't be employed because they aren't worth $minimum_wage dollars an hour, they'll just have to be supported by the government. If there are so many of these people that this starts to cost significant amounts of money, then there are clearly problems with the economy and standards of education which extend further than the minumum wage issue.
There are of course plenty of people who don't have to support themselves, and so don't need to get >=$minumum_wage. Either you modify minimum wage laws to take this into account, or you put up with it. It's no big deal.