If they try to install Windows on their Ubuntu system, Windows will destroy their access to their Ubuntu partition with no questions asked.
Maybe it would be a good idea to suggest those things in the manual, but its not big enough of a deal for Ubuntu or Windows to do it.
Either put up with the (admittedly horrible) norms of reliability in the computing world, or improve it yourself. There is nothing to gain by bitching about it for so long.
How hard would it be for a C++ coder to dig into this book?
Should be pretty easy. All the code examples are valid C++. All you need to do is remember that "class" is called "struct" and that you have to mangle your own names.
C++ is not a superset of C, and is definitely not supposed to be written like C.
For example variable-length arrays (added by C99) are not supported by C++ (which has vector objects instead).
Anything that can be created by evolution Evolution is not the origin of life, it is the origin of species.
The origin of life is thought to be some event whereby a self-copying structure was formed. Many believe this event is extremely rare. Perhaps it happens so rarely, that on one out of trillions of planets, in one of trillions of seconds, it happened by chance.
It is possible that this event cannot reasonably be catalyzed in a non-intrusive way. For example, maybe you can increase the odds by a factor of many millions, by putting forth the correct chemicals, but you might still be a factor of billions behind if some rare reaction is necessary. If you try to catalyze it by causing the chemical reaction then the experiment may lose credibility.
Hellman therefore did a preliminary analysis and found the risk to be 'equivalent to having your home surrounded by thousands of nuclear power plants. Which begets the question: How risky is it to have thousands of nuclear power plants around your home?
NFA supports returning the first-match, and other trivialities that the Perl implementors thought it doesn't. It may take actually understanding the algorithm involved, however.
I would take up your challenge, if I wasn't deeply involved with many others already. However, others I have mentioned these problems to have said that they intend to use this as a project.
The article speaks of extended regular expressions - and those indeed require backtracking. The idea is there are plenty (perhaps a majority) of regular expressions that do NOT use the extended unregular features, and the engine could use a simple FSM for those.
You got the regexp wrong, take another look at the one in the article, you're missing a ? there. Also, it may work very quickly with the constant 29, and take years with the constant 35 or 40, such are the wonders of exponential complexities.
it is much simpler and you get the same performance for non-pathological cases. Its not that much simpler, as the NFA approach is quite simple. And they indeed speak of the backtracking required in some cases in the article. For backtracking regexps, use this approach, sure. But many (perhaps a majority) of regexps ARE regular and don't need to backtrack.
Claiming that "real world regexps" are not pathological cases may be true - but there is a middle-ground. We have hit, in my workplace, cases of regular expressions scaling much worse than O(N) on the text - and they were completely regular! So real-world regular (truly regular) expressions could benefit a lot from the NFA approach. It was done correctly in the 60's, but nobody seems to get it right now.
If you read the link I posted, you will see that they are indeed evil and slow - and not for any good reason. The implementation of good regular expression engines is not difficult and known in CS theory for many decades.
"Premature optimization" is a nice slogan - but the regexp performance problems are real, and I have encountered them before (I was extremely surprised to see that the regexp matching is scaling far worse than O(N) as it was clear to me that matching that regexp should be at worst O(N)).
The reason it is depressing is because they got it right in the 60's, and are getting it wrong now. Stalling progress is sad. Deteriorating is depressing.
As for elisp regexps being faster than other elisp methods - its not very indicative, as the regexp engine is implemented in C. If you compare, however, the pathological regexps (see my original link) in elisp, compared to a naive elisp char-by-char iteration of strings, you'll see that the elisp code performs better.
About your link, it doesn't seem that he is prejudiced against Perl, it seems that he hates Perl and that implies no prejudice. Many of us dislike or even hate Perl because we find it less suitable for all tasks than other tools that we use, and because we find that it an extremely ugly hack that strongly encourages write-once read-never code.
Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. --Jamie Zawinski, in comp.lang.emacs
I'll close with a somewhat depressing fact: Regular expression and string processing can be done quickly and efficiently (and was done that way back decades ago, with grep and awk), but is actually done in a horribly inefficient way in all modern/popular programming language regexp engines.
I agree and I'd typedef that as well, but you missed the point.
I used a ridiculously complicated example in order to show that C's syntax is over-complicated. So over-complicated that long-time C programmers do not understand it. I suggested a simple replacement which would be capable of simplifying it.
It simplifies very complicated examples by a lot, and simple examples by a little.
Apple fanboyism and the Israeli/Palastenian conflict Except Apple fanboyism is about silly computers, and the Israeli/Palestinian conflict is about human lives.
Create policies like "maximum function call depth" I would rather have a policy of maximum function size (which may increase function call depth) than this policy.
Do you want to encourage people to inline their functions manually, and not divide things into small, cute trivial functions?
Is this a misguided attempt to increase efficiency?
Now, if anyone can tell me why C's indirection operator is the same as 'multiply', and its address operator is the same as bitwise AND?
I always thought it would make more sense to use '$' = 'value of' and '@' = 'address of' for these. To be fair, "$" and "@" meant currency and apple pie back in that day:-)
I think that by far C's main syntatic problem is using a prefix operator for pointer types and pointer dereferences, when the other type operators (arrays and functions) are postfixes. Because of this mistake, virtually all C programmers to this day, do not fully understand C's declaration syntax.
For example, to declare a function that takes a pointer to a void function(int) as an argument, and returns a pointer to a function(void) that returns a pointer to an array[SIZE] of chars, you would have to write:
char (*(*func(void (*func)(int)))(void))[SIZE];
It also means we have to write:
m->x
because: (*m).x is required with a prefix operator, and is hard to type.
There are few C programmers who can read that first example. Now lets try a Pointer-as-postfix syntax for the same thing. We shall not use * as a postfix operator, because it would make the expression: "a * - b" ambiguous ("a*(-b)" or "(a*)-b"?). Instead, let us use your suggestion, and make "$" the postfix type operator, and dereference operator, and see the consequences. Lets also put the base-type after the expression instead of before it, and see what happens to the above declaration:
func(function$(int) void)$(void)$[SIZE] char
Note that this simply reads left-to-right now (because we removed the mishmash of prefix/postfix operators), and there is no need for parenthesis to denote precedence, just functions.
The "->" syntax is no longer needed, as like in Pascal, we can have:
m$.x
which clearly means: dereference m and then get the x member.
A. Kubuntu is not as polished as Ubuntu (At least in Gutsy). Ubuntu pops up scripts to download missing codecs, plugins, etc. In Kubuntu you are left on your own, with google and howto's. Some of Kubuntu's applications (restricted drivers manager) seem to be less stable than their Ubuntu counterparts.
B. KDE is more powerful than Gnome: The KDE IOSlaves and KDE's architecture is indeed more powerful. All protocols and all kinds of data can be used from any file/run prompt. For example, Konqueror's web shortcuts work in the run dialog ("wt:Efficiency" opens up the wiktionary page directly from the run dialog), and you don't have to open web links in firefox and other links in other programs - KDE just does all that for you.
C. KDE applications are significantly slower to start than Gnome. On all hardware I tried, Gnome apps take less than a second to start, even when not in cache. KDE applications, even smaller ones (kate) on modern hardware, take at least 3-4 seconds to start. This was my primary reason to stop using KDE.
D. I think both KDE and Gnome have tons of great applications, and its hard to say which one is winning in this regard.
I spent the last week or so finally going ahead and learning Haskell, and I am now very sad that I took so long to start.
Haskell is an amazingly enlightening language. When you approach it, like I did, you are likely to hit some overly-academic descriptions of its features, which are extremely hard to understand. Don't let this discourage you, Haskell can be learned without getting a PhD in mathematics.
I find it far more enlightening than Lisp, and that it is quite amazing what a powerful world was built with such simple primitives.
Another note is that most languages (even C and Lisp) are far more similar to one another than they are to Haskell, so even an experienced programmer will take longer to learn Haskell than just any new language.
For example, protesting the Church of Mormon is to forget their holy book says that black people are black because of sin and they can become white with prayer.
Slashdot Mirror
Newbies don't install OS's.
If they try to install Windows on their Ubuntu system, Windows will destroy their access to their Ubuntu partition with no questions asked.
Maybe it would be a good idea to suggest those things in the manual, but its not big enough of a deal for Ubuntu or Windows to do it.
Either put up with the (admittedly horrible) norms of reliability in the computing world, or improve it yourself. There is nothing to gain by bitching about it for so long.
There doesn't seem to be a single working human speech synthesizer that doesn't sound like metal squeaking.
:-)
I'd say first they should "emulate" human speech, then move to more difficult targets
http://www.theregister.co.uk/2008/04/16/esa_german_schoolboy_apophis_denial/
Should be pretty easy. All the code examples are valid C++. All you need to do is remember that "class" is called "struct" and that you have to mangle your own names.
C++ is not a superset of C, and is definitely not supposed to be written like C.For example variable-length arrays (added by C99) are not supported by C++ (which has vector objects instead).
I don't think Ariel Sharon is conscious.
A simple DNA molecule is a "self copying" structure, only it copies itself very very slowly.
The origin of life is thought to be some event whereby a self-copying structure was formed. Many believe this event is extremely rare. Perhaps it happens so rarely, that on one out of trillions of planets, in one of trillions of seconds, it happened by chance.
It is possible that this event cannot reasonably be catalyzed in a non-intrusive way. For example, maybe you can increase the odds by a factor of many millions, by putting forth the correct chemicals, but you might still be a factor of billions behind if some rare reaction is necessary. If you try to catalyze it by causing the chemical reaction then the experiment may lose credibility.
Are people finally admitting that Vista is worse than XP was when it was first launched?
NFA supports returning the first-match, and other trivialities that the Perl implementors thought it doesn't. It may take actually understanding the algorithm involved, however.
I would take up your challenge, if I wasn't deeply involved with many others already. However, others I have mentioned these problems to have said that they intend to use this as a project.
You can fall back to backtracking when the obscure backtracking features are used - and use the regular engine when they are not.
:-)
The majority of regexps ARE regular and there is no reason for them to pay the price of rare and obscure features that they do not use.
Appearently the regexp implementors are a bunch of idiots after all
The article speaks of extended regular expressions - and those indeed require backtracking. The idea is there are plenty (perhaps a majority) of regular expressions that do NOT use the extended unregular features, and the engine could use a simple FSM for those.
You got the regexp wrong, take another look at the one in the article, you're missing a ? there.
Also, it may work very quickly with the constant 29, and take years with the constant 35 or 40, such are the wonders of exponential complexities.
Claiming that "real world regexps" are not pathological cases may be true - but there is a middle-ground. We have hit, in my workplace, cases of regular expressions scaling much worse than O(N) on the text - and they were completely regular!
So real-world regular (truly regular) expressions could benefit a lot from the NFA approach.
It was done correctly in the 60's, but nobody seems to get it right now.
Oh, if so, what are those reasons really?
If you read the link I posted, you will see that they are indeed evil and slow - and not for any good reason. The implementation of good regular expression engines is not difficult and known in CS theory for many decades.
"Premature optimization" is a nice slogan - but the regexp performance problems are real, and I have encountered them before (I was extremely surprised to see that the regexp matching is scaling far worse than O(N) as it was clear to me that matching that regexp should be at worst O(N)).
The reason it is depressing is because they got it right in the 60's, and are getting it wrong now. Stalling progress is sad. Deteriorating is depressing.
As for elisp regexps being faster than other elisp methods - its not very indicative, as the regexp engine is implemented in C. If you compare, however, the pathological regexps (see my original link) in elisp, compared to a naive elisp char-by-char iteration of strings, you'll see that the elisp code performs better.
About your link, it doesn't seem that he is prejudiced against Perl, it seems that he hates Perl and that implies no prejudice. Many of us dislike or even hate Perl because we find it less suitable for all tasks than other tools that we use, and because we find that it an extremely ugly hack that strongly encourages write-once read-never code.
I'll start with an Obligatory quote.
Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. --Jamie Zawinski, in comp.lang.emacs
I'll close with a somewhat depressing fact: Regular expression and string processing can be done quickly and efficiently (and was done that way back decades ago, with grep and awk), but is actually done in a horribly inefficient way in all modern/popular programming language regexp engines.
I agree and I'd typedef that as well, but you missed the point.
I used a ridiculously complicated example in order to show that C's syntax is over-complicated. So over-complicated that long-time C programmers do not understand it.
I suggested a simple replacement which would be capable of simplifying it.
It simplifies very complicated examples by a lot, and simple examples by a little.
Do you want to encourage people to inline their functions manually, and not divide things into small, cute trivial functions?
Is this a misguided attempt to increase efficiency?
I always thought it would make more sense to use '$' = 'value of' and '@' = 'address of' for these. To be fair, "$" and "@" meant currency and apple pie back in that day
I think that by far C's main syntatic problem is using a prefix operator for pointer types and pointer dereferences, when the other type operators (arrays and functions) are postfixes. Because of this mistake, virtually all C programmers to this day, do not fully understand C's declaration syntax.
For example, to declare a function that takes a pointer to a void function(int) as an argument, and returns a pointer to a function(void) that returns a pointer to an array[SIZE] of chars, you would have to write: It also means we have to write: because:
(*m).x is required with a prefix operator, and is hard to type.
There are few C programmers who can read that first example. Now lets try a Pointer-as-postfix syntax for the same thing. We shall not use * as a postfix operator, because it would make the expression: "a * - b" ambiguous ("a*(-b)" or "(a*)-b"?). Instead, let us use your suggestion, and make "$" the postfix type operator, and dereference operator, and see the consequences. Lets also put the base-type after the expression instead of before it, and see what happens to the above declaration: Note that this simply reads left-to-right now (because we removed the mishmash of prefix/postfix operators), and there is no need for parenthesis to denote precedence, just functions.
The "->" syntax is no longer needed, as like in Pascal, we can have: which clearly means: dereference m and then get the x member.
A. Kubuntu is not as polished as Ubuntu (At least in Gutsy).
Ubuntu pops up scripts to download missing codecs, plugins, etc. In Kubuntu you are left on your own, with google and howto's. Some of Kubuntu's applications (restricted drivers manager) seem to be less stable than their Ubuntu counterparts.
B. KDE is more powerful than Gnome: The KDE IOSlaves and KDE's architecture is indeed more powerful. All protocols and all kinds of data can be used from any file/run prompt. For example, Konqueror's web shortcuts work in the run dialog ("wt:Efficiency" opens up the wiktionary page directly from the run dialog), and you don't have to open web links in firefox and other links in other programs - KDE just does all that for you.
C. KDE applications are significantly slower to start than Gnome. On all hardware I tried, Gnome apps take less than a second to start, even when not in cache. KDE applications, even smaller ones (kate) on modern hardware, take at least 3-4 seconds to start. This was my primary reason to stop using KDE.
D. I think both KDE and Gnome have tons of great applications, and its hard to say which one is winning in this regard.
Since their computers and math skills were behind those of the US, I thought they became bionic super humans in order to make up for it :-)
I spent the last week or so finally going ahead and learning Haskell, and I am now very sad that I took so long to start.
Haskell is an amazingly enlightening language. When you approach it, like I did, you are likely to hit some overly-academic descriptions of its features, which are extremely hard to understand. Don't let this discourage you, Haskell can be learned without getting a PhD in mathematics.
I recommend Yet Another Haskell Tutorial as a more down-to-earth explanation of what's going on in there.
I find it far more enlightening than Lisp, and that it is quite amazing what a powerful world was built with such simple primitives.
Another note is that most languages (even C and Lisp) are far more similar to one another than they are to Haskell, so even an experienced programmer will take longer to learn Haskell than just any new language.
And what horrors are those? That Israel accepts Jewish (and sometimes others) into it, but not any other random person?