Anyway I stand by my previous comment: "Super VHS looks just as quality" as any DVD Camcorder's output.
That's not what you said. You said "Super VHS looks just as "quality" as any DVD", which is outright false. I can well believe that some particular HD based camcorder produced worse output than some other particular SVHS one, but to claim that this holds for all DVDs is simply wrong.
Super VHS looks just as "quality" as any DVD.... I will even go so far as to say "better quality" since S-VHS doesn't have annoying compression blur, blocking, or mosquitos.
Lies, frankly. Watch them close up if you can't see the difference from far away, or compare still images.
A programmer needs to know why if he allocates 2 million empty string classes why his memory gets chewed up.
No, no he really doesn't. Not while he's getting started. He has enough on his hands learning what the operations do, without having to worry about managing all his own memory as well.
Yes, Java is a terrible language to start with, because it forces OOP, but C is if anything worse. To start with you want a modern, friendly dynamic language; something like perl, python or ruby. (My preference is for python, but honestly, any of them would make a good choice). Something where hello world is just 'print "hello world"'.
And I say this as a functional programming zealot. It's hard to learn a new paradigm at the same time as you're learning to program at all, and both functional and object-oriented programming require you to shift your perspective a lot. So teach imperative programming first, because it requires the least adjustment to one's way of thinking.
Are you really claiming that it is not a win to have tail recursion for traversing a list, tree or any bunch of complex data structures in a functional language?!
It's not a win. It's a nice feature, sure, and I'd like for python to have it, but it is not my any means necessary when python has more easily comprehensible ways of doing the same thing. Just as map and filter are nice, but I don't at all mind python toning them down in favour of list comprehensions, which are a better way of doing the same thing.
(Didn't Python also lack continuations?)
Of course it has continuations; they're expressed slightly differently to how you see them elsewhere, but they're there all the same.
Please. If you're writing that condescendingly I'd wager I've written more ML than you've written code full stop. The example you give is an extremely unnatural way of doing a loop control structure, and in a language that has more normal flow control there is truly no need for it. That one doesn't have to go through the contortions you do to get regular flow control in a pure functional language in python doesn't make it unsuitable for functional programming; on the contrary, it makes it the best language for functional programming. Once you've rewritten a perfectly clear function to a convoluted version using an accumulator so that you can get reasonable performance doing something that wouldn't require any of that in a slightly less dogmatic language, it quickly loses its appeal.
Tail recursion is a performance hack, and python's not about those. If you really want it, I think some of the alternative implementations have it (the official cpython isn't the only one). Claiming C is better suited to FP is pure trolling.
It does make it a pain in the ass to play around and test with because often cut-n-paste (from random sources) completely fucks up the indention which you then have to fix.
Cut-n-paste is not a good way to learn.
Between Python's extremely verbose syntax (not very script-friendly-like)
It's not extremely verbose; take a look at Java if you want that. If you compare with e.g. perl, yes it's longer, but the difference is because it's using words rather than random characters, which in my book is worth it for the ease of remembering wtf to write. Compare it with Ruby or, *struggles to think of another scripting language* TCL, say, and the verbosity is pretty similar.
and relatively poor performance...
Really? It's not going to win races against C, but performance is very much on a par with say Perl (which yes, has a lot of improvements coming in v6, but that's not here yet), and ahead of other similar languages. Couple with the fact that it's easier to bind from python than any of the alternatives, and you end up with code that in practice is as fast as you could write anywhere (because you use e.g. NumPy, which just binds to the fastest libraries available for doing what it does).
Of course python does sacrifice some things - but the ease of code writing and most of all maintainability are well worth it in most cases, in my experience.
Firewalls are inefficient and wasteful because of the amount of trouble they cause legitimate use, and the little they do to prevent illegitimate use. It's like putting six padlocks on your flimsy wooden door.
No, really. Look at the happiness, general welfare, health or any other factor you care to name as applied to a typical citizen in a more developed country. The US is being left behind.
It is our duty as citizens to follow the laws, to follow the moral contract made by our ancestors who founded the country and the sovereign people among which we live now
No. I am a free man, and will do as I see right. The only difference whether or not a certain action is illegal makes to me is the possibility of responses to it - police, etc. In short, if there is an action that you would consider morally justified but is against the law, your only question should be whether you are willing to run the risk of getting caught.
Why the hell shouldn't I be able to do that? In the computer age it's not like they need to pay someone to read through each transaction. If I feel the best boy grip wasn't really up to scratch, but the stylist to Mr. Star had done a great job, why shouldn't I be able to pay one more than the other?
I realized this the other day when I was thinking the same thing about the browser and I stopped being so upset about the odd crash. I'm not saying forgive all the crashing, but cut your phone a little slack for not being a laptop replacement.
A phone is something that costs a tenner. I'm annoyed when my PDA doesn't act as a laptop replacement, because as far as I can tell it should be perfectly capable of doing so - it has a faster processor than the laptop I was quite happily using five years ago, memory to match, and it only seems to be PC makers wanting to keep their income sources that mean it's got a crippled OS that refuses to manage windows properly or use my actual screen resolution preventing it from being the same experience.
Hardware encryption is never as effective as claimed - and even in the highly unlikely event they've gotten the algorithm right, as I said, the key has to be somewhere. It's not a hard problem.
In other words, all scientific theories will eventually be proven wrong when better data is available.
Um, no. There is no proof that a theory of everything, and, with science's excellent track record, every reason to hope that we will be able to find one.
Not all platforms can execute ActionScript. To my knowledge, only desktops or laptops running Windows, Mac OS X, or Linux can execute ActionScript because only these platforms have Flash Player 10 or will have it any time soon. This rules out handheld devices and devices primarily designed to use multiple game controllers and display on a large monitor.
Sure, but it seems like an actionscript-to-C compiler would be a better solution to your problem than a C-to-actionscript one.
Sorry, what? Why would C running on Flash get worse performance than ActionScript running on Flash?
Because as a language designed for that platform, ActionScript is likely to be a much better fit for the bytecode. E.g. as a modern bytecode it probably has specific support for e.g. objects and perhaps some common data structures like linked lists or hash tables (I don't know the specifics of this particular bytecode), which the C-to-flash compiler won't be able to use because C doesn't have primitives for those things. (Of course, a super-smart compiler could try and figure out when you've written a linked list in C and rearrange your code to use the bytecode's support, but at that point you're essentially solving the same problem as a decompiler, which is hard, and at some point you get eaten by the halting problem).
Why the hell would you need that many different versions of something anyway? And if you're talking about programmer-efficiency then writing C where you could be writing actionscript seems the height of lunacy.
This seems to further cement flash as a worthy application environment, especially given the perceived problem in flash appeared to be its inefficiency.
Huh? You think this method is going to give anything remotely resembling the efficiency of native code? Unless the flash script language is really badly written, the performance will be even worse than programs that were manually written in flash.
Slashdot Mirror
This is actually worth doing: I run 64-bit vista, and many older programs that don't work with it will run perfectly under wine.
That's not what you said. You said "Super VHS looks just as "quality" as any DVD", which is outright false. I can well believe that some particular HD based camcorder produced worse output than some other particular SVHS one, but to claim that this holds for all DVDs is simply wrong.
Super VHS looks just as "quality" as any DVD.... I will even go so far as to say "better quality" since S-VHS doesn't have annoying compression blur, blocking, or mosquitos.
Lies, frankly. Watch them close up if you can't see the difference from far away, or compare still images.
A programmer needs to know why if he allocates 2 million empty string classes why his memory gets chewed up.
No, no he really doesn't. Not while he's getting started. He has enough on his hands learning what the operations do, without having to worry about managing all his own memory as well.
Yes, Java is a terrible language to start with, because it forces OOP, but C is if anything worse. To start with you want a modern, friendly dynamic language; something like perl, python or ruby. (My preference is for python, but honestly, any of them would make a good choice). Something where hello world is just 'print "hello world"'.
And I say this as a functional programming zealot. It's hard to learn a new paradigm at the same time as you're learning to program at all, and both functional and object-oriented programming require you to shift your perspective a lot. So teach imperative programming first, because it requires the least adjustment to one's way of thinking.
It's not a win. It's a nice feature, sure, and I'd like for python to have it, but it is not my any means necessary when python has more easily comprehensible ways of doing the same thing. Just as map and filter are nice, but I don't at all mind python toning them down in favour of list comprehensions, which are a better way of doing the same thing.
(Didn't Python also lack continuations?)
Of course it has continuations; they're expressed slightly differently to how you see them elsewhere, but they're there all the same.
Please. If you're writing that condescendingly I'd wager I've written more ML than you've written code full stop. The example you give is an extremely unnatural way of doing a loop control structure, and in a language that has more normal flow control there is truly no need for it. That one doesn't have to go through the contortions you do to get regular flow control in a pure functional language in python doesn't make it unsuitable for functional programming; on the contrary, it makes it the best language for functional programming. Once you've rewritten a perfectly clear function to a convoluted version using an accumulator so that you can get reasonable performance doing something that wouldn't require any of that in a slightly less dogmatic language, it quickly loses its appeal.
Tail recursion is a performance hack, and python's not about those. If you really want it, I think some of the alternative implementations have it (the official cpython isn't the only one). Claiming C is better suited to FP is pure trolling.
Cut-n-paste is not a good way to learn.
Between Python's extremely verbose syntax (not very script-friendly-like)
It's not extremely verbose; take a look at Java if you want that. If you compare with e.g. perl, yes it's longer, but the difference is because it's using words rather than random characters, which in my book is worth it for the ease of remembering wtf to write. Compare it with Ruby or, *struggles to think of another scripting language* TCL, say, and the verbosity is pretty similar.
and relatively poor performance...
Really? It's not going to win races against C, but performance is very much on a par with say Perl (which yes, has a lot of improvements coming in v6, but that's not here yet), and ahead of other similar languages. Couple with the fact that it's easier to bind from python than any of the alternatives, and you end up with code that in practice is as fast as you could write anywhere (because you use e.g. NumPy, which just binds to the fastest libraries available for doing what it does).
Of course python does sacrifice some things - but the ease of code writing and most of all maintainability are well worth it in most cases, in my experience.
That's OK. We don't want the kind of programmers who let a superficial difference like that put them off actually trying a language.
from __future__ import braces has been there for a while.
Firewalls are inefficient and wasteful because of the amount of trouble they cause legitimate use, and the little they do to prevent illegitimate use. It's like putting six padlocks on your flimsy wooden door.
Fuck NAT users. If they want to break their internet, they can. It's stupid trying to code every protocol to work around their stupidity.
No, really. Look at the happiness, general welfare, health or any other factor you care to name as applied to a typical citizen in a more developed country. The US is being left behind.
No. I am a free man, and will do as I see right. The only difference whether or not a certain action is illegal makes to me is the possibility of responses to it - police, etc. In short, if there is an action that you would consider morally justified but is against the law, your only question should be whether you are willing to run the risk of getting caught.
Why the hell shouldn't I be able to do that? In the computer age it's not like they need to pay someone to read through each transaction. If I feel the best boy grip wasn't really up to scratch, but the stylist to Mr. Star had done a great job, why shouldn't I be able to pay one more than the other?
A phone is something that costs a tenner. I'm annoyed when my PDA doesn't act as a laptop replacement, because as far as I can tell it should be perfectly capable of doing so - it has a faster processor than the laptop I was quite happily using five years ago, memory to match, and it only seems to be PC makers wanting to keep their income sources that mean it's got a crippled OS that refuses to manage windows properly or use my actual screen resolution preventing it from being the same experience.
Hardware encryption is never as effective as claimed - and even in the highly unlikely event they've gotten the algorithm right, as I said, the key has to be somewhere. It's not a hard problem.
Not if you're using the built-in hardware encryption, it can't.
Yes it can. The key has to be stored somewhere, it might take a bit of effort but you can get it if you're dedicated enough.
Of course, if you're using a strong passphrase with a good encryption scheme, you're safe - but you were anyway.
Um, no. There is no proof that a theory of everything, and, with science's excellent track record, every reason to hope that we will be able to find one.
Sure, but it seems like an actionscript-to-C compiler would be a better solution to your problem than a C-to-actionscript one.
Because as a language designed for that platform, ActionScript is likely to be a much better fit for the bytecode. E.g. as a modern bytecode it probably has specific support for e.g. objects and perhaps some common data structures like linked lists or hash tables (I don't know the specifics of this particular bytecode), which the C-to-flash compiler won't be able to use because C doesn't have primitives for those things. (Of course, a super-smart compiler could try and figure out when you've written a linked list in C and rearrange your code to use the bytecode's support, but at that point you're essentially solving the same problem as a decompiler, which is hard, and at some point you get eaten by the halting problem).
Why the hell would you need that many different versions of something anyway? And if you're talking about programmer-efficiency then writing C where you could be writing actionscript seems the height of lunacy.
Huh? You think this method is going to give anything remotely resembling the efficiency of native code? Unless the flash script language is really badly written, the performance will be even worse than programs that were manually written in flash.
Physics is a science, but cosmology is not.