I inform the person that if it's a telemarketer and they continue to talk to me anyway, that the fee will be $250. That way, when my friends need to call me from a payphone, they're not screwed. About once every four months a telemarketer gets ballsy, but on the other hand, so far I've scared two supervisors into actually paying out the fee, which pretty much guarantees that firm will never call me again.
That'll teach me to hit submit without checking the preview. I lost a big and important chunk of the reply after operator< because I forgot to write out the entity for <. Here's a repaste; yay form buffers, boo no edit button for the first five minutes of a post.
-----------------
That's the wrong comparison to make, because it assumes that the C++ programmer has unlimited time to make his C++ code efficient and correct.
Well, yes and no. I actually got into this else-thread; there are a hell of a lot of programming jobs where the programmer actually does have time to make their code correct. Not everything behaves like the web; when you're writing a video game, an operating system, a database, embedded or realtime control software, or in fact many many other things, performance just isn't sacrificable.
(And, actually, in most situations, a programmer has all the time in the world to make their software correct; the number of software houses which will willingly release software containing flaws is vanishingly small. Most released flaws are the result of bad development practice and insufficient testing methods, not short schedules.)
In real life, programmers have time constraints, and under given time constraints, the Python program will often be faster than the C++ program.
Yeah. If you'd take a look at the numbers, though, the vast bulk of software is actually embedded software. Embedded software can't tolerate execution delays. Behind embedded software, the next largest group is in-house software; that kind of software generally can't tolerate production delays. Those two groups are a wonderful example of the extreme divergence in needs in development - python is exactly the right thing to do for the second group, but exactly the wrong thing to do for the first.
As far as the Python program often being faster than the C++ program, that sounds an awful lot like an expectation, rather than experience.
In fact, even without time constraints, C++ code often ends up far less efficient than the optimum possible, simply because using the optimal algorithm or memory management strategy is so hard in C++ that programmers can't do it.
Yeah. Now it's time for me to call bullshit. This is such a weirdly interesting myth, that algorithms and memory management in C++ are harder than they are in other languages, that I don't really know what to say.
See, implementing algorithms and memory management in C was really, really hard - you had to, well, keep track of a pointer and an offset. (Because most people confuse the overflows that come from bad engineering practices with something that's just magically too hard to do, presumably because they've never seen anything harder, and they can't imagine a world wherein garbage collection and pointers aren't the alpha and omega of memory management. Wait'll you try COBOL, FORTRAN or machine assembly, all of which are still common languages - in fact, all moreso, if you count all assembly languages as one, than python.)
That said, in C++ it's nowhere near that difficult. If you want garbage collection and can't be bothered to write new in the constructor and delete in the destructor, bust out a smart pointer. Get a container; it'll self allocate just fine, and ridiculously efficiently. Need something more complex, like pooling? No problem - pooling is two lines of code in operator new, or you could just use the policy class in Boost. Algorithms are in fact so fundamental to the design of C++ that there's a specific section on them in the standard, defining how they are to be implemented such that they magically and correctly attach to any correct container. They are trivially easy to implement; a naive bubble sort which is correct can be implemented in a single line of code, in a way that will work for any user defined type implementing operator< and on any ordered container.
That's the wrong comparison to make, because it assumes that the C++ programmer has unlimited time to make his C++ code efficient and correct.
Well, yes and no. I actually got into this else-thread; there are a hell of a lot of programming jobs where the programmer actually does have time to make their code correct. Not everything behaves like the web; when you're writing a video game, an operating system, a database, embedded or realtime control software, or in fact many many other things, performance just isn't sacrificable.
(And, actually, in most situations, a programmer has all the time in the world to make their software correct; the number of software houses which will willingly release software containing flaws is vanishingly small. Most released flaws are the result of bad development practice and insufficient testing methods, not short schedules.)
In real life, programmers have time constraints, and under given time constraints, the Python program will often be faster than the C++ program.
Yeah. If you'd take a look at the numbers, though, the vast bulk of software is actually embedded software. Embedded software can't tolerate execution delays. Behind embedded software, the next largest group is in-house software; that kind of software generally can't tolerate production delays. Those two groups are a wonderful example of the extreme divergence in needs in development - python is exactly the right thing to do for the second group, but exactly the wrong thing to do for the first.
As far as the Python program often being faster than the C++ program, that sounds an awful lot like an expectation, rather than experience.
In fact, even without time constraints, C++ code often ends up far less efficient than the optimum possible, simply because using the optimal algorithm or memory management strategy is so hard in C++ that programmers can't do it.
Yeah. Now it's time for me to call bullshit. This is such a weirdly interesting myth, that algorithms and memory management in C++ are harder than they are in other languages, that I don't really know what to say.
See, implementing algorithms and memory management in C was really, really hard - you had to, well, keep track of a pointer and an offset. (Because most people confuse the overflows that come from bad engineering practices with something that's just magically too hard to do, presumably because they've never seen anything harder, and they can't imagine a world wherein garbage collection and pointers aren't the alpha and omega of memory management. Wait'll you try COBOL, FORTRAN or machine assembly, all of which are still common languages - in fact, all moreso, if you count all assembly languages as one, than python.)
That said, in C++ it's nowhere near that difficult. If you want garbage collection and can't be bothered to write new in the constructor and delete in the destructor, bust out a smart pointer. Get a container; it'll self allocate just fine, and ridiculously efficiently. Need something more complex, like pooling? No problem - pooling is two lines of code in operator new, or you could just use the policy class in Boost. Algorithms are in fact so fundamental to the design of C++ that there's a specific section on them in the standard, defining how they are to be implemented such that they magically and correctly attach to any correct container. They are trivially easy to implement; a naive bubble sort which is correct can be implemented in a single line of code, in a way that will work for any user defined type implementing operatoreveryone knows it's hard" or fall silent. It actually isn't, and you'll find that a talented C++ programmer can often spank the pants off of a Python programmer, except when dealing with string parsing or GUI stuff (at which point it's time to remember that Delphi, REXX, perl and PHP are a bigger threat than Python.)
I'm not saying Python doesn't have its place. What I am saying is
Re:Yeah, but that's not what we need.
on
Python-to-C++ Compiler
·
· Score: 2, Insightful
This was my point exactly. The article says "this thing does a better job of converting Python to C++ in terms of efficiency than did the older one." People are hearing "This thing generates efficient C++." Nobody's tested that yet, though.
You are making a gigantic assumption that because this converter's better than the last one, that it's usable in efficiency arenas. By comparison, you might be looking at the difference between a shoe and a shoe with a spring (that's what air pumps do, don't laugh) when dealing with runners - you can grab another 10-20% speed out of the runner with the new shoe, and it's easier on the knees to boot.
They're still not racing a car.
I'm not saying this thing does a bad job; I honestly have no idea. The point, though, is that neither do you. If you're working a project which has a good reason to be Python, such as in an arena where programmer time is more important than execution time (a lot of programmers unfortunately believe that this is all programming, because they've never done performance-conscious things like operating systems, databases, video games, embedded or realtime software, and so on,) then this is great. Why? Because a new tool gives you an essentially free linear speed multiplier, which means you can crank X% more work out of the same machine farm, or whatever.
But, you've read this differently. You're starting to think of Python as an appropriate tool to write efficiency-conscious software, and there are not yet appropriate tests to display that this is an accomodating such tool. To be frank, I highly doubt that this is actually going to be a real performance-appropriate concern, and whereas a bunch of flametards will jump all over me demanding that I explain a lifetime's worth of instincts and experience to them in two paragraphs or I'm so obviously wrong, I still want to point out that technologies like this have come and gone for scripting languages for decades, that none of them have turned the python of their day to the C++ of their day, and that I don't see any compelling reason to believe that this will be any different.
What you're reading isn't what those tests say. Python is not a performance-appropriate language, and I believe that this tool will not make it so. No tests which determine whether it actually is a performance-appropriate environment have yet been run.
Besides, it's worth pointing out to all the flametards that C++ isn't actually the performance language of choice either. Depending on the nature of your problem, that crown usually goes to forth, erlang, k, mozart-oz or formulaONE. (And, for math-heavy stuff, it still goes to Fortran surprisingly often.)
Hahaha, let me get this straight. First you're going to make a "joke" about how to correctly write something. Then, you're going to try to tell me that I'm wrong to point out several flaws because it's a word following German rules. Then when I point out that that's just as wrong, you're just going to start saying "omg it's a joke don't take it so seriously!" ?
Here's the germane part: it makes you look like a dumbass. Fix it or replace it.
That would be Nazigrammatik. Thanks for playing; you still fail. By the way, Nazi isn't a word in German. It's an acronym. German doesn't allow the adoption of acronyms into compound nouns. Does it embarrass you to be corrected in your native tongue by an American?
The phrase "grammar nazis" is properly spelled as a capitalized compound noun: Grammarnazis.
No.
A phrase is not collapsed into a single word for no apparent reason.
What you're referring to are called compound words, not compound nouns. Adjectives are also frequently compound words, though people have a tendency to mistakenly hyphenate such words almost as frequently.
Compound nouns are not capitalized. Capitalization is used for sentence leading, for specific nouns, for particular nouns, for names, and not for making yourself look stupid on Slashdot.
New compound nouns are essentially not being made; for the last fifty years, hyphenation has been a near-dominant standard for modern English concatenation.
The phrase is correctly written 'grammar Nazis;' Nazis are a particular political group and are as such proper nouns.
You seem to have 'proper' and 'correct' mistakenly backwards. To be proper is to follow appreciable and estimable rules of conduct in a setting of judgement. This by definition excludes things for which there are a correct and an incorrect. For example, two plus two is not properly written as four; it is, rather, correctly written as four. (To use the word proper indicates something different, in the situation where the sum rather than its expression was required, such as on a tax form; the contrasting example would be '2+2' rather than an incorrect result.)
In English, double quotes indicate a specific quotation. This is an inspecific quotation - something which is commonly or theoretically said, rather than something that was said by a specific person on a specific date.
In English, the colon is used to indicate a list of items. Given that English does not have datatypes, whether something is a list is governed by whether there are more than one; otherwise you are dealing with an instance. The correct way to phrase what you said would be to refer to the replacement as the replacement; it is no less a single and specific thing because it's hypothetical (nor because you don't know how to conjoin.) Try ... is spelled as the compound noun 'Grammarnazis.'
Conjoinder of words is a conjugation issue, not a spelling issue.
Perhaps wait until you understand English before condescending to tell grammar Nazis about their own job, kthx.
Great. You now have ONE PASSWORD you have to use everywhere. It's strong, but since you're using it everywhere, it is now vulnerable.
Huhu. Maybe nobody let you in on this amusing little fact: there are more than one memorable phrase in the English language. Other candidates include "so long and thanks for all the fish," "we hold these truths to be self evident, that all men are created equal," "the use of words in meaning something other than their literal intention," "neither rain nor snow nor the dark of night shall keep us from our appointed rounds," "four score and seven years ago our forefathers brought forth on this new continent," "oh baby that's too big i have no idea what we're going to do," "dude there's a satellite dish sticking out of your ass," "i'm sorry mario but our princess is in another castle," or "great, now you have one password you have to use everywhere."
I'm sure with one of those wacky new-fangled security devices - what are they called, library cards? - you'll be able to find others.
Any set of guidelines that only looks at one password is flawed.
Luckily, I never said anything about looking at exactly one password. Do not pretend people said things they didn't in order to invent critcisms.
I certainly can't remember 100 phrases and the mapping of which phrase maps to which account.
Wow. Who would have ever thought of a mnemonic... for a mnemonic? Perhaps, for example, you could choose phrases appropriate to the account you're generating passwords for. The mario quote for your video game account, so long and thanks for all the fish on the work machine named zaphod, your email account would be the postal quote, and the one about wang for your gay porn collection, for example.
It gets even worse when you add punctuation... do I happen to remember which pauses had commas?
Yeah, so don't add punctuation. Take a look at the example I gave. (That said, if you can't remember the punctuation, your grammar isn't all that great.)
I wasn't naming toy languages. I was naming real, in-use languages. Same reason I didn't include brainfuck, befunge, or my personal favorite, homespring.
The problem is, people are now saying that they can write efficient code in python just because it magically translates to C++
No they aren't, if only because ShedSkin doesn't handle modules yet and Python without modules is not really useful.
RTFA. They're saying this verbatim. This means that, in combination with a C++ compiler, it allows for translation of pure Python programs into highly efficient machine language.
Last time I checked, it was the only Python compiler
Then you need to check again. Arguing from ignorance doesn't do much other than to make you feel smart; if looking smart is what you're after, you're out in the cold.
(unless the C++ compiler has some sort of strong AI)
I can't imagine by what process of thought you came to think this was a useful thing to say. Strong AI is AI which is self-aware. It has nothing to do with problem solving capabilities. Furthermore, strong AI does not yet exist. Moreover, compiler optimizations are a set of rule-driven alterations based on mathematical proof that things aren't changed; theoretical AI wouldn't actually help in any way.
Read a Searle book before engaging in this sort of self congratulatory nonsense again, please. You're embarrassing people who know what you're trying to talk about.
I'm not interested in writing native C++ code because it's hypothetically faster (it's not faster if I count coding time). But I am interested in a good python-to-C++ translator. Why wouldn't any python user be?
I never said they wouldn't be. Please feel free to re-read what I said until you understand it. However, please don't reply again and attempt to argue with me over things I didn't say. It's obnoxious.
Wait, if it is just a string of characters, a discreet enumerated set, as you say, then why is my password not considered 10 letters strong if it's two concatenated five letter words? To make that leap you're using information that the cracker won't have, namely that I use two english words.
In context, the scheme requires all people to use two-word passwords. Therefore it is the size of the dictionary, not what's contained inside, which matters. And, of course, dictionary crackers already do try concatenation attacks, so even if they didn't know it wouldn't help you.
I understand where you're coming from, from a cryptographic standpoint.
I really don't think that you do.
But in practice you simply can't enforce passwords to be that good. No really, I've tried.
That's funny. I tried and it worked. So did the company which sparked this discussion in the first place. In fact, BSD has this kind of requirement turned on by default, as do applications like Plesk and cpanel.
In fact, it's quite easy to enforce good passwords. If you'd bothered to read what I said, you'd know how I did it.
Virtually nobody uses the full 96 character set for their passwords and they're certainly not randomly chosen.
Yeah, hi. Did you notice the code I pasted? Not only does it use the full radix as demanded, but MD5's particular reason to exist is to create as even as possible a distribution among a bit series.
So if I use two randomly chosen words from even a simplified dictionary, I think it's better in practice (though not in theory) than what you're saying.
Yeah, and this is why I think you don't know where I'm coming from. Dictionary crackers have been attacking and breaking your scheme since 1970.
Furthermore, I'd say that, depending on the application, 40 billion can be far more than enough.
Yeah, well, a 386 can break a 40-billion-space hash in under five minutes, so it's pretty clear it isn't.
In fact, 10,000 is enough for high security in certain applications. Don't believe me? Check out your ATM PIN number.
Yeah, well I'll tell you what. As soon as you have a video camera hovering over your sign-in forms, and are a purely physical object which consumes the ATM card after three faulty tries, I'll start taking you seriously again. The two situations aren't even remotely similar.
Of course, *my* PIN is actually sixteen digits. Amusingly, your bank will let you use a more secure password if you want to.
The important bit is that it has a physical key that you lose after three tries.
Oh, you know about that? Then explain to me how this is parallel to your dictionary scheme. Do you take away the attacker's computer? Or are you still fooling yourself into believing in network identity control?
Any login system should be set to lock out after a small number of failed attempts, such that the 40 billion possibilities are suitably secure.
Yeah. How? IP addresses are easily faked, as are MAC addresses. Unless you want to lock out the entire internet every time you're attacked, this is preposterously unrealistic. Try thinking the whole scheme through, before saying "this is what you should do."
By the same token, you might as well say that down elevators are silly, and we should all just hang-glide back to the street because it's faster and more fun. Once you bother to actually consider the ramifications of what you're saying, you'll find that the plan falls way, way short of realism.
I am so glad that the security industry has credentials, to keep people like you out. It amazes me how unwilling some people are to admit to themselves their own naïveté.
See, it's all well and good to compile python to speed it up. The problem is, people are now saying that they can write efficient code in python just because it magically translates to C++, and because this translator is faster than other python compilers.
This won't be meaningful until a converted python script is compared to efficient code written natively in C++ in the first place.
Er. The money doesn't come from your competition. It comes from your customers. Once you realize that, you can be less worried about the other people failing all around you and focus more on figuring out what the people pulling down a hundred thousand every two months did.
Yeah, Nintendo's already announced that they've acquired rights to more than 2/3 of the back catalog. Frankly, any company which didn't sell them would be idiots.
My cat broke the DVD player in my bedroom. I moved the player from the guest room, and I'm not replacing that one, because I'll be getting a Wii in a few months and I can just shuffle the one in the living room out. Lots of people won't be getting DVD players for their kids because of the Wii, too.
Apparently you haven't taken the time to figure out what WoW makes in a year (6.2m active players * $14.95/mo * 12mo/y = one point one two billion dollars annually.)
The germane bit is that Second Life is an open market. It's also extremely lucrative. One of the two founders gave a talk at E3 this year, and among his tidbits was that there was a real estate agent who had moved to speculation in Second Life; she was dumping more than $40k into the game monthly, and was cash positive by almost triple.
Sure, it might run like ass. All the way to your wallet.
I think you're better off producing quality elsewhere and shopping it around
Yeah, the shopping it around part is a lot harder than it sounds. I write games for a living, I have a well established business and market, and I've been considering trying out Second Life because the numbers are just huge. The market is way more active than things like PopCap. In Second Life, though, it's a big social win to be the first person to have found something; viral marketing is just part of their culture.
Linden Labs has set up something which makes a whole lot of money for people with the dedication to get past their performance problems. It's worth it.
Sorry, but trying to write a game above the level of tetris in SL is more pain than writing AJAX.
Er. AJAX is trivially easy, and it's just one tiny technique involving DOM updates and a single ECMA class. If that's your idea of hard, Second Life scripting doesn't scare me at all.
Call us when you've seen something scarier than C++. Mozart/OZ, Erlang, K and raw MSIL come to mind.
Neither is blu-ray. That said, HD-DVD devices have been shipping for more than two years, they play HD content, and HD-DVDs look an awful lot like DVDs (they even come in DVD cases.) Given that DVD will never support HD, to suggest that HD-DVD doesn't count when you're talking about DVDs supporting HD is kinda silly.
The player made by Oppo is outselling the PSP (check their sales ranks - #284 and #316 respectively in electronics,) so I think grandparent was in fact quite right to point out that the lack of HD is going to impede sales to a fairly big segment of the customer demographic.
Slashdot Mirror
My LED runs in Planck time.
You're going to need 20 years of Stephen Hawking to beat that. Owned.
I inform the person that if it's a telemarketer and they continue to talk to me anyway, that the fee will be $250. That way, when my friends need to call me from a payphone, they're not screwed. About once every four months a telemarketer gets ballsy, but on the other hand, so far I've scared two supervisors into actually paying out the fee, which pretty much guarantees that firm will never call me again.
Oh, hell.
That'll teach me to hit submit without checking the preview. I lost a big and important chunk of the reply after operator< because I forgot to write out the entity for <. Here's a repaste; yay form buffers, boo no edit button for the first five minutes of a post.
-----------------
That's the wrong comparison to make, because it assumes that the C++ programmer has unlimited time to make his C++ code efficient and correct.
Well, yes and no. I actually got into this else-thread; there are a hell of a lot of programming jobs where the programmer actually does have time to make their code correct. Not everything behaves like the web; when you're writing a video game, an operating system, a database, embedded or realtime control software, or in fact many many other things, performance just isn't sacrificable.
(And, actually, in most situations, a programmer has all the time in the world to make their software correct; the number of software houses which will willingly release software containing flaws is vanishingly small. Most released flaws are the result of bad development practice and insufficient testing methods, not short schedules.)
In real life, programmers have time constraints, and under given time constraints, the Python program will often be faster than the C++ program.
Yeah. If you'd take a look at the numbers, though, the vast bulk of software is actually embedded software. Embedded software can't tolerate execution delays. Behind embedded software, the next largest group is in-house software; that kind of software generally can't tolerate production delays. Those two groups are a wonderful example of the extreme divergence in needs in development - python is exactly the right thing to do for the second group, but exactly the wrong thing to do for the first.
As far as the Python program often being faster than the C++ program, that sounds an awful lot like an expectation, rather than experience.
In fact, even without time constraints, C++ code often ends up far less efficient than the optimum possible, simply because using the optimal algorithm or memory management strategy is so hard in C++ that programmers can't do it.
Yeah. Now it's time for me to call bullshit. This is such a weirdly interesting myth, that algorithms and memory management in C++ are harder than they are in other languages, that I don't really know what to say.
See, implementing algorithms and memory management in C was really, really hard - you had to, well, keep track of a pointer and an offset. (Because most people confuse the overflows that come from bad engineering practices with something that's just magically too hard to do, presumably because they've never seen anything harder, and they can't imagine a world wherein garbage collection and pointers aren't the alpha and omega of memory management. Wait'll you try COBOL, FORTRAN or machine assembly, all of which are still common languages - in fact, all moreso, if you count all assembly languages as one, than python.)
That said, in C++ it's nowhere near that difficult. If you want garbage collection and can't be bothered to write new in the constructor and delete in the destructor, bust out a smart pointer. Get a container; it'll self allocate just fine, and ridiculously efficiently. Need something more complex, like pooling? No problem - pooling is two lines of code in operator new, or you could just use the policy class in Boost. Algorithms are in fact so fundamental to the design of C++ that there's a specific section on them in the standard, defining how they are to be implemented such that they magically and correctly attach to any correct container. They are trivially easy to implement; a naive bubble sort which is correct can be implemented in a single line of code, in a way that will work for any user defined type implementing operator< and on any ordered container.
Exactly what memory management
That's the wrong comparison to make, because it assumes that the C++ programmer has unlimited time to make his C++ code efficient and correct.
Well, yes and no. I actually got into this else-thread; there are a hell of a lot of programming jobs where the programmer actually does have time to make their code correct. Not everything behaves like the web; when you're writing a video game, an operating system, a database, embedded or realtime control software, or in fact many many other things, performance just isn't sacrificable.
(And, actually, in most situations, a programmer has all the time in the world to make their software correct; the number of software houses which will willingly release software containing flaws is vanishingly small. Most released flaws are the result of bad development practice and insufficient testing methods, not short schedules.)
In real life, programmers have time constraints, and under given time constraints, the Python program will often be faster than the C++ program.
Yeah. If you'd take a look at the numbers, though, the vast bulk of software is actually embedded software. Embedded software can't tolerate execution delays. Behind embedded software, the next largest group is in-house software; that kind of software generally can't tolerate production delays. Those two groups are a wonderful example of the extreme divergence in needs in development - python is exactly the right thing to do for the second group, but exactly the wrong thing to do for the first.
As far as the Python program often being faster than the C++ program, that sounds an awful lot like an expectation, rather than experience.
In fact, even without time constraints, C++ code often ends up far less efficient than the optimum possible, simply because using the optimal algorithm or memory management strategy is so hard in C++ that programmers can't do it.
Yeah. Now it's time for me to call bullshit. This is such a weirdly interesting myth, that algorithms and memory management in C++ are harder than they are in other languages, that I don't really know what to say.
See, implementing algorithms and memory management in C was really, really hard - you had to, well, keep track of a pointer and an offset. (Because most people confuse the overflows that come from bad engineering practices with something that's just magically too hard to do, presumably because they've never seen anything harder, and they can't imagine a world wherein garbage collection and pointers aren't the alpha and omega of memory management. Wait'll you try COBOL, FORTRAN or machine assembly, all of which are still common languages - in fact, all moreso, if you count all assembly languages as one, than python.)
That said, in C++ it's nowhere near that difficult. If you want garbage collection and can't be bothered to write new in the constructor and delete in the destructor, bust out a smart pointer. Get a container; it'll self allocate just fine, and ridiculously efficiently. Need something more complex, like pooling? No problem - pooling is two lines of code in operator new, or you could just use the policy class in Boost. Algorithms are in fact so fundamental to the design of C++ that there's a specific section on them in the standard, defining how they are to be implemented such that they magically and correctly attach to any correct container. They are trivially easy to implement; a naive bubble sort which is correct can be implemented in a single line of code, in a way that will work for any user defined type implementing operatoreveryone knows it's hard" or fall silent. It actually isn't, and you'll find that a talented C++ programmer can often spank the pants off of a Python programmer, except when dealing with string parsing or GUI stuff (at which point it's time to remember that Delphi, REXX, perl and PHP are a bigger threat than Python.)
I'm not saying Python doesn't have its place. What I am saying is
This was my point exactly. The article says "this thing does a better job of converting Python to C++ in terms of efficiency than did the older one." People are hearing "This thing generates efficient C++." Nobody's tested that yet, though.
You are making a gigantic assumption that because this converter's better than the last one, that it's usable in efficiency arenas. By comparison, you might be looking at the difference between a shoe and a shoe with a spring (that's what air pumps do, don't laugh) when dealing with runners - you can grab another 10-20% speed out of the runner with the new shoe, and it's easier on the knees to boot.
They're still not racing a car.
I'm not saying this thing does a bad job; I honestly have no idea. The point, though, is that neither do you. If you're working a project which has a good reason to be Python, such as in an arena where programmer time is more important than execution time (a lot of programmers unfortunately believe that this is all programming, because they've never done performance-conscious things like operating systems, databases, video games, embedded or realtime software, and so on,) then this is great. Why? Because a new tool gives you an essentially free linear speed multiplier, which means you can crank X% more work out of the same machine farm, or whatever.
But, you've read this differently. You're starting to think of Python as an appropriate tool to write efficiency-conscious software, and there are not yet appropriate tests to display that this is an accomodating such tool. To be frank, I highly doubt that this is actually going to be a real performance-appropriate concern, and whereas a bunch of flametards will jump all over me demanding that I explain a lifetime's worth of instincts and experience to them in two paragraphs or I'm so obviously wrong, I still want to point out that technologies like this have come and gone for scripting languages for decades, that none of them have turned the python of their day to the C++ of their day, and that I don't see any compelling reason to believe that this will be any different.
What you're reading isn't what those tests say. Python is not a performance-appropriate language, and I believe that this tool will not make it so. No tests which determine whether it actually is a performance-appropriate environment have yet been run.
Besides, it's worth pointing out to all the flametards that C++ isn't actually the performance language of choice either. Depending on the nature of your problem, that crown usually goes to forth, erlang, k, mozart-oz or formulaONE. (And, for math-heavy stuff, it still goes to Fortran surprisingly often.)
Hahaha, let me get this straight. First you're going to make a "joke" about how to correctly write something. Then, you're going to try to tell me that I'm wrong to point out several flaws because it's a word following German rules. Then when I point out that that's just as wrong, you're just going to start saying "omg it's a joke don't take it so seriously!" ?
Here's the germane part: it makes you look like a dumbass. Fix it or replace it.
Man, you're just desperate to be right.
That would be Nazigrammatik. Thanks for playing; you still fail. By the way, Nazi isn't a word in German. It's an acronym. German doesn't allow the adoption of acronyms into compound nouns. Does it embarrass you to be corrected in your native tongue by an American?
Best slashdot bug ever.
The phrase "grammar nazis" is properly spelled as a capitalized compound noun: Grammarnazis.
No.
Perhaps wait until you understand English before condescending to tell grammar Nazis about their own job, kthx.
Great. You now have ONE PASSWORD you have to use everywhere. It's strong, but since you're using it everywhere, it is now vulnerable.
... for a mnemonic? Perhaps, for example, you could choose phrases appropriate to the account you're generating passwords for. The mario quote for your video game account, so long and thanks for all the fish on the work machine named zaphod, your email account would be the postal quote, and the one about wang for your gay porn collection, for example.
Huhu. Maybe nobody let you in on this amusing little fact: there are more than one memorable phrase in the English language. Other candidates include "so long and thanks for all the fish," "we hold these truths to be self evident, that all men are created equal," "the use of words in meaning something other than their literal intention," "neither rain nor snow nor the dark of night shall keep us from our appointed rounds," "four score and seven years ago our forefathers brought forth on this new continent," "oh baby that's too big i have no idea what we're going to do," "dude there's a satellite dish sticking out of your ass," "i'm sorry mario but our princess is in another castle," or "great, now you have one password you have to use everywhere."
I'm sure with one of those wacky new-fangled security devices - what are they called, library cards? - you'll be able to find others.
Any set of guidelines that only looks at one password is flawed.
Luckily, I never said anything about looking at exactly one password. Do not pretend people said things they didn't in order to invent critcisms.
I certainly can't remember 100 phrases and the mapping of which phrase maps to which account.
Wow. Who would have ever thought of a mnemonic
It gets even worse when you add punctuation... do I happen to remember which pauses had commas?
Yeah, so don't add punctuation. Take a look at the example I gave. (That said, if you can't remember the punctuation, your grammar isn't all that great.)
I wasn't naming toy languages. I was naming real, in-use languages. Same reason I didn't include brainfuck, befunge, or my personal favorite, homespring.
The problem is, people are now saying that they can write efficient code in python just because it magically translates to C++
No they aren't, if only because ShedSkin doesn't handle modules yet and Python without modules is not really useful.
RTFA. They're saying this verbatim. This means that, in combination with a C++ compiler, it allows for translation of pure Python programs into highly efficient machine language.
Last time I checked, it was the only Python compiler
Then you need to check again. Arguing from ignorance doesn't do much other than to make you feel smart; if looking smart is what you're after, you're out in the cold.
(unless the C++ compiler has some sort of strong AI)
I can't imagine by what process of thought you came to think this was a useful thing to say. Strong AI is AI which is self-aware. It has nothing to do with problem solving capabilities. Furthermore, strong AI does not yet exist. Moreover, compiler optimizations are a set of rule-driven alterations based on mathematical proof that things aren't changed; theoretical AI wouldn't actually help in any way.
Read a Searle book before engaging in this sort of self congratulatory nonsense again, please. You're embarrassing people who know what you're trying to talk about.
I don't see your point.
Indeed. But you replied anyway.
I'm not interested in writing native C++ code because it's hypothetically faster (it's not faster if I count coding time). But I am interested in a good python-to-C++ translator. Why wouldn't any python user be?
I never said they wouldn't be. Please feel free to re-read what I said until you understand it. However, please don't reply again and attempt to argue with me over things I didn't say. It's obnoxious.
Wait, if it is just a string of characters, a discreet enumerated set, as you say, then why is my password not considered 10 letters strong if it's two concatenated five letter words? To make that leap you're using information that the cracker won't have, namely that I use two english words.
In context, the scheme requires all people to use two-word passwords. Therefore it is the size of the dictionary, not what's contained inside, which matters. And, of course, dictionary crackers already do try concatenation attacks, so even if they didn't know it wouldn't help you.
I understand where you're coming from, from a cryptographic standpoint.
I really don't think that you do.
But in practice you simply can't enforce passwords to be that good. No really, I've tried.
That's funny. I tried and it worked. So did the company which sparked this discussion in the first place. In fact, BSD has this kind of requirement turned on by default, as do applications like Plesk and cpanel.
In fact, it's quite easy to enforce good passwords. If you'd bothered to read what I said, you'd know how I did it.
Virtually nobody uses the full 96 character set for their passwords and they're certainly not randomly chosen.
Yeah, hi. Did you notice the code I pasted? Not only does it use the full radix as demanded, but MD5's particular reason to exist is to create as even as possible a distribution among a bit series.
So if I use two randomly chosen words from even a simplified dictionary, I think it's better in practice (though not in theory) than what you're saying.
Yeah, and this is why I think you don't know where I'm coming from. Dictionary crackers have been attacking and breaking your scheme since 1970.
Furthermore, I'd say that, depending on the application, 40 billion can be far more than enough.
Yeah, well, a 386 can break a 40-billion-space hash in under five minutes, so it's pretty clear it isn't.
In fact, 10,000 is enough for high security in certain applications. Don't believe me? Check out your ATM PIN number.
Yeah, well I'll tell you what. As soon as you have a video camera hovering over your sign-in forms, and are a purely physical object which consumes the ATM card after three faulty tries, I'll start taking you seriously again. The two situations aren't even remotely similar.
Of course, *my* PIN is actually sixteen digits. Amusingly, your bank will let you use a more secure password if you want to.
The important bit is that it has a physical key that you lose after three tries.
Oh, you know about that? Then explain to me how this is parallel to your dictionary scheme. Do you take away the attacker's computer? Or are you still fooling yourself into believing in network identity control?
Any login system should be set to lock out after a small number of failed attempts, such that the 40 billion possibilities are suitably secure.
Yeah. How? IP addresses are easily faked, as are MAC addresses. Unless you want to lock out the entire internet every time you're attacked, this is preposterously unrealistic. Try thinking the whole scheme through, before saying "this is what you should do."
By the same token, you might as well say that down elevators are silly, and we should all just hang-glide back to the street because it's faster and more fun. Once you bother to actually consider the ramifications of what you're saying, you'll find that the plan falls way, way short of realism.
I am so glad that the security industry has credentials, to keep people like you out. It amazes me how unwilling some people are to admit to themselves their own naïveté.
See, it's all well and good to compile python to speed it up. The problem is, people are now saying that they can write efficient code in python just because it magically translates to C++, and because this translator is faster than other python compilers.
This won't be meaningful until a converted python script is compared to efficient code written natively in C++ in the first place.
Er. The money doesn't come from your competition. It comes from your customers. Once you realize that, you can be less worried about the other people failing all around you and focus more on figuring out what the people pulling down a hundred thousand every two months did.
Yeah, Nintendo's already announced that they've acquired rights to more than 2/3 of the back catalog. Frankly, any company which didn't sell them would be idiots.
My cat broke the DVD player in my bedroom. I moved the player from the guest room, and I'm not replacing that one, because I'll be getting a Wii in a few months and I can just shuffle the one in the living room out. Lots of people won't be getting DVD players for their kids because of the Wii, too.
Apparently you haven't taken the time to figure out what WoW makes in a year (6.2m active players * $14.95/mo * 12mo/y = one point one two billion dollars annually.)
The germane bit is that Second Life is an open market. It's also extremely lucrative. One of the two founders gave a talk at E3 this year, and among his tidbits was that there was a real estate agent who had moved to speculation in Second Life; she was dumping more than $40k into the game monthly, and was cash positive by almost triple.
Sure, it might run like ass. All the way to your wallet.
I think you're better off producing quality elsewhere and shopping it around
Yeah, the shopping it around part is a lot harder than it sounds. I write games for a living, I have a well established business and market, and I've been considering trying out Second Life because the numbers are just huge. The market is way more active than things like PopCap. In Second Life, though, it's a big social win to be the first person to have found something; viral marketing is just part of their culture.
Linden Labs has set up something which makes a whole lot of money for people with the dedication to get past their performance problems. It's worth it.
Sorry, but trying to write a game above the level of tetris in SL is more pain than writing AJAX.
Er. AJAX is trivially easy, and it's just one tiny technique involving DOM updates and a single ECMA class. If that's your idea of hard, Second Life scripting doesn't scare me at all.
Call us when you've seen something scarier than C++. Mozart/OZ, Erlang, K and raw MSIL come to mind.
The Wii is essentially an upgraded cube with a badass new controller. That the discs will still spin in reverse is almost guaranteed.
No DVD player supports HD.
Actually, they do. The Samsung HD-841 started shipping in the end of 2004, for example. Here's a review. The Toshiba HD-A1 is only $460 on Amazon.
but HD-DVD isn't really DVD anyhow
Neither is blu-ray. That said, HD-DVD devices have been shipping for more than two years, they play HD content, and HD-DVDs look an awful lot like DVDs (they even come in DVD cases.) Given that DVD will never support HD, to suggest that HD-DVD doesn't count when you're talking about DVDs supporting HD is kinda silly.
The player made by Oppo is outselling the PSP (check their sales ranks - #284 and #316 respectively in electronics,) so I think grandparent was in fact quite right to point out that the lack of HD is going to impede sales to a fairly big segment of the customer demographic.