Actually, 10. doesn't necessarily repeat the last command 10 times, it just runs it again with an argument of 10. For example ">>10." will indent the current line and then indent it and the following 9 lines.
I still haven't found an easy way to indent a line N times without pressing ">" 2N times...
Activate visual mode first. In visual mode, the argument is used for the number of indents (because the lines to indent are selected visually).
So to indent the current line 4 times, type: "V4>". Happy vimming! :)
The advantage of "streams" is that it can be used to elegantly define infinite sequences recursively.
For example, you can define powers of two as:
var powersOf2 = new Stream(1, function() {
return powersOf2.scale(2);
});
(untested) which means that the sequence of powers of 2 begins with 1 follows with the the same sequence scaled by 2!
The implementation in the linked article however seems to be flawed, since it doesn't store the node's tail after computing it. This means that to get each element of the sequence you have to compute all the elements before it (even though you already did in order to get to that element).
This works not only for numbers but for other infinite sequences such as expressions in a language. I recommend the book Higher Order Perl if you're interested in this.
shells were specifically made to operate with external programs (the Unix way) while Python is a more general programming language, so naturally it will be more verbose for this kind of task.
Of course the first syntax breaks when one of the arguments has a space or any other meta-character in it.
I'm fully aware of the reasons why things are as they are, and what the limitations of the different solutions are. My point still stands though, just because something is Python, written in the One True Way, does not guarantee readability.
To be absolutely clear, I actually like Python. I just strongly disagree with the belief that Python magically ensures readability. Particularly because my impression is that people who think that Python magic pixie dust automatically makes for good code are actually more likely to write bad code. (Because they have not thought deeply enough about what makes code good.)
Of course Python doesn't automatically ensure good code.
But the Python code in your example is readable -- pretty match as readable as it gets, considering the constraints I mentioned.
I still disbelieve. Ruby is as much a general programming language as Python, yet supports a syntax that I find much more readable. I even find the deprecated os.popen interface in Python to be more readable than the official Python 2.6 interface. And, of course, the Python 2.7 syntax is better.
Therefore I can't agree that the Python that I presented is as good as is possible for a general purpose programming language.
I'd have to disagree. In this case, the backticks are quite idiomatic, whereas the Python is less so.
The Python example can be broken down by someone who knows OOP concepts in general, but not Python. It says:
Invoke function Popen on the object subprocess, giving the arguments (for example) 'ls' and '-al' in a list. Standard output should be handled in some way that is indicated by the value of PIPE. On the object returned from Popen, call communicate(), which returns an array; take the first element off that returned array.
Now, in order to make sense of this you would need to know what the arguments to Popen are, what communicate() means and what it returns.
Does that require a trip to the documentation? Yes. Is it less readable? No, it's more readable. The understanding of what was read is not immediately conveyed, however.
The Ruby/Perl/Bash backticks mean nothing even if you have an OO background. Maybe if the command is 'ls' and you know some Unix, you can work it out in your head to understand that it's invoking a command in the shell. What if it's calling something obscure with a string of arcane arguments appended? That will tell nothing, and the backticks will also add zero information.
Backticks are more convenient, but readability is the ability of someone who doesn't know that particular concept, or even that language, to still parse a statement and extract some level of understanding.
Disagree with which? That the Python version is as readable as it could be? Don't argue that with me, argue with the decision to add a utility method that makes Python 2.7 better.
As for readability, I emphatically disagree with you on how it should be defined. Readability is the result of the interaction between the programmer and the code. The interaction cannot be left out of this. There is such a thing as well-written, readable Greek. But if you don't speak Greek, it will all be Greek to you. COBOL was designed to be readable. Can you read any significant COBOL program? Old FORTRAN programmers complained that Smalltalk hideously unreadable because they didn't understand the basic concepts of OO.
That said, something that is long and full of moving parts is inherently a challenge to read. Even if you understand every piece of that Python example (I happen to), when you encounter it in code there is a lot of semantic noise to what is written. That complexity can and should be hidden. As the Python 2.7 API does.
I think you've mistaken my argument. I didn't say that the Python version looks good or is the best way to do it. It's not.
I was saying that "something that is long and full of moving parts" is easier to read than something that is short and idiomatic. I am not saying either of them represent the ideal way to do it.
My definition of readability includes the ability to convey the programmer's intention to the mind of the reader. The reader should be able to work out what is intended by the code with minimal requirements placed on them, and I think I detailed earlier why I think the Python code does a better job than simple surrounding a shell command with backticks.
Unless I'm writing training material for novices, I write code with the assumption that anyone else maintaining it is reasonably competent with the languages, libraries, and tools in question. That to me is a minimal requirement.
The mailing list is having some trouble surviving, too. Apparently at some point Google decided our domain was spammy, and all the Gmail subscribers started getting their mail automatically spam-filtered. I contacted a bunch of people directly (via Google Talk or Facebook) to get them to fish the latest mail out of the spambox.
Beyond that, I don't know what to do. I guess I could post more often.
Managing a site through a DVCS is, IMO, a good idea. (I do it for my own site, http://www.gwern.net/ ). But I think your worries are somewhat groundless. If you are interested in preventing patent problems years down the line, there's no need for fancy cryptographic commitment schemes; you could probably just appeal to archive sites like the Internet Archive or WebCitation. When you access their archived pages, the pages come with timestamps in the frame or as part of the URL.
(I know that the Internet Archive has been used by some courts for one purpose or another, though I don't know that it has been employed for demonstrating prior art.)
That said, if you investigated existing cryptographic time-stamping services (http://en.wikipedia.org/wiki/Trusted_timestamping#External_l...) and figured out how to integrate them into a DVCS (a shell script called from cron?), I would certainly find that an interesting thing to read on Hacker News.
The thing that's bothering me about the fail whale -- all the strings that hold the whale are curved. Is this physically possible? (Assuming the birds can hold the whale in the air). Shouldn't at least one of the strings be a straight line?
Even when one of the ends is weighted down rather than fixed, I think it's still going to want to fall into a catenary curve, because that curve minimizes the potential energy of the string itself, and there is some equilibrium between the lower potential energy of the string and the higher potential energy of the object. How far the curvature departs from a straight line is probably a function of the ratio of mass between the lifted object and the string itself. With a whale and some yarn, it's going to asymptotically close to a straight line, but still slightly curved. However, fail whales are apparently light enough to be carried by a handful of birds, so the weight is probably comparable to the string itself.
Their starting point obviously isn't above their ending point, though.
mansr is right, I've been looking at this all wrong because I assumed the weight of the strings was small compared to the weight of the whale. But if the strings are dense they will curve under their own weight. So we're not looking at a super-light whale, we're looking a regular whale supported by super-heavy strings.
(Where do you get strings so dense that the mass of a short stretch is comparable to the mass of a whale? Why, the same place you get those goddamn birds, of course.)
Statement 1 isn't true. If you have 10$ in the envelope, and it's the smaller envelope, you gain 10$. But if it's the larger envelope you don't lose 10$. The fallacy is that "x" refers to different things in each case.
Statement 2 is true but it isn't relevant, since you don't know the posterior probability given y. If the envelope contains the smaller amount of money then there is no way you can lose -- it's not a 50-50 chance.
"a relationship between two anchors, called the head and the tail. The link goes from the tail to the head. The head and tail are also known as destination and source, respectively."
So what we have is "Anchor Head REFerence" when we should simply have "Link DESTination". Think about it when you next design a world changing markup language.
