daivd

The "sorry vegans" remark seems silly. Let me remind any meat-eater (including myself) that some of the greatest minds in history, including Albert Einstein, Leonardo da Vinci and possibly Isaac Newton were vegetarians. http://en.wikipedia.org/wiki/List_of_vegetarians

His diet suggestions seem to be the opposite of crazy. He was very early with "more fat, less carbs, no sugar" which seems to be more or less common wisdom now. That coupled with generally few calories (CR must be the most well studied diet there is) and vegetables is basically what he recommends dietwise. His early and seemingly correct conclusions on diet allowed him to cure his diabetes type 2. That you would suggest those as crazy makes you seem poorly researched and makes me less likely to believe your other statements.

In this case it obviously doesn't matter, but in the general case it is better to be explicit on which type of cast you are doing. That way the compiler can statically stop you from doing stupid things. Read the link I gave.

"Hell, stop programming in C++ and start using Rust!" I plan to try to do that, when Rust has become more stable.

Internet popular means libraries on github and good tutorials, means useful.

Yes, of course a POD is better, but that would be cheating, since this is supposed to show that you can do the Python stuff, including tuples and tuple deconstruction, just like in the linked Python original.

Perhaps I should have mentioned that, though.

That does not look like C++11. You don't use initializer lists. You don't use new-style for-loops. I'll give you that those don't add much to safety, though. A functional style with Boost ranges, adapters and algorithms do, however. I clearly write in the post that you shouldn't use for-loops. Use ranges and pipes.

Even in Hindley-Miller type systems it is considered good practice to add types as documentation to top-level constructs (see Haskell). In Python it is also considered good practice to add argument and return type info in the doc string. In a dynamic language you would also have to add a unit test or two for cases for some of the things that the compiler can catch for you.

Looking at the complete picture makes a language with local type inference (like C++11) more or less as verbose as one with complete type inference.

Is there really such a bandwagon?

Yes, to_string would have been better

The C-style cast is shorter, but less safe, so you should not use it: http://stackoverflow.com/questions/1609163/what-is-the-diffe...

Yeah, I couldn't quite decide if I should include const refs. On the one hand, it is idiomatic, but on the other hand I didn't want to clutter the code with something that is just an optimization on paper.

But that is sort of the point. You should not write C++ like C. If a C-programmer thinks your code is nice and readable, you are not using C++. The C-stuff was just added to lure C-programmers over.

I agree, it is much uglier. Part of it is that Python thinks a character is unsigned, whereas C++ thinks it is signed. This arbitrarily works in Python's favor here. Part of it is that Python just handles this better.

Go is certainly a fine language. One common instance where I would prefer C++, though, is when you are writing libraries for others to use. A language that runs on a VM can not easily be used as a library inside a language that uses another VM. You cannot easily write a library for Python in Go or vice versa. If you use a VM-less language like C or C++, your work can be used (through various wrappers, like SWIG or that Apache thing) by everyone.

It is only unreadable bullshit the first time you read it. If you use ranges, filtered and transformed for these kinds of tasks, it looks idiomatic.

I wrote this post.

The program is I/O-bound, so the only speed improvement comes from not having to start up the Python interpreter.

If the task was CPU bound, you would get a great performance boost (sometimes 100x over CPython), but that is well known.

There can be other reasons than performance for writing in C++. Used well, the strong static type system can catch many bugs. I suspect (but I cannot prove) that it could be almost as good as Haskell.

I use Python for most things, though, so I don't really advocating switching to C++ for every little scripting task.

You misunderstand the purpose of ord. The mp3 metadata uses one byte to encode an integer between 0 and 255, which represents genre. It is not a string.

The underlying motivation is to write it specifically for a few people, whose current way of working I know, and who have asked me for some information on zsh. If it were not for them, I would not have written it, since I don't add anything new, just summarize in a different way.

Having written it, though, I thought I might share it. For most people, like me, the timing has to be right to try something new. You have to have the time and the motivation and everything else. By sharing it, I hope to hit some people with the right timing (and based on some comments, upvotes, etc, I know I did).

I must have seen 20 Haskell advocacy posts before I actually tried writing something in it. Same with you for some new technologies?

Yeah, I thought as much. I just mentioned it to help a new user, because the standard in Bash seems to be PgUp and beginning-of-line search, while in Zsh it is Up and full search.

Great!

It worked fine for me. I asked an obscure stack overflow question about the Google App Engine SDK and an OpenSSL bug in Ubuntu 12.04 a few days ago and got prompt support.

Besides that it is trendy to pick on Google, I think that the problem people have had with customer support is mostly with ads.

I agree that you need to keep a direction for SE, but there is one type of open-ended conversation starters that often works really well there - the list. E.g "What feature would you like to see in C++15 (or whatever the next one will be called)?", "What is your favourite bit twiddling trick?", "What is your favourite language outside the TIOBE top-20 and why?", etc. With one list item per answer and the help of the voting structure, those tend to produce interesting reading.

Since Nix keeps multiple versions of almost the same binaries, it seems to me that something like ZFS, where several files can share the same physical block on disk, is the perfect match. Is that something you recommend when using NixOS?

There are good tutorials to Haskell, but it seems to me that Haskell best practices still evolves fairly quickly. After "Real World Haskell" and "Learn you a Haskell", I still did not know what most of the GHC extensions are for (especially those related to generalizing types seem interesting), how to write idiomatic IO-code (conduits now, apparently? Or is it Pipes?), or how I should choose between the many ways of computing on many cores. Is Data Parallel Haskell mature enough? STM? The par combinator? accelerate? I don't think they mention Template Haskell (which seems powerful). The recommended way to connect to SQL is also in a state of flux (possibly "persistent"?).

It is real brute force, but I do not investigate some stupid nodes. If I choose to not use an available jar during a timestep, I disqualify that jar, until another jar has been used, since there is no point in waiting to use a jar unless you want to save your balls for another jar.

The code is ugly and undocumented. I think the same could be accomplished in less than 10 lines of Haskell :). http://pastebin.com/MfXK9fwS

An implementation detail is that my branches are actually "jar1" "jar2" and "stepforward". To use a jar many times, you do jar1, jar1, stepforward.

How about the same problem, but with each Jar having:

a) a known fail percentage - 40% of the time the Jar fails and produces nothing. Maximize expected win.

b) an unknown fail percentage, evenly distributed between 0 and 100%. Find a strategy that maximizes expected win over many runs (each run has new fail probabilities), by perfectly balancing between exploration of jars and exploitation. If you can find an optimal (and practical) strategy for this one I applaud you!

Also, I solved your example with a simple Python brute-forcer with < 1s run time. I don't know if I care enough to write a parser of your file format just to mail it in ;).

Ytterby is not an island. It is a village _on_ an island: http://en.wikipedia.org/wiki/Ytterby

If I understand this correctly, saying that vowels tend to be close to vowels is just a special case of using n-grams. If you have a fingerprint with the common n-gram distribution for the target language (or even subject), you get an optimization problem where you try to guess the substitutions such that the angle between the fingerprint vectors are minimized.

If it cannot be solved analytically, it seems something like a GA should solve it well.

Is there a standard method for solving substitution cryptos?

OK, I will try it. And if you had said that it would be almost impossible, because there are too many local minima, I would have believed you.

A serious try with GA would require abandoning Python for a faster fitness function in C, that does not copy dozens of lists back and forth. I estimate that just about anyone could make it more than 100 times as fast. The slow implementation will have to suffice for now.

The interesting part is of course not the absolute times, but if the complexity scales differently. If a real Sudoku solver takes about 50 times as long to solve that problem, I will consider it a victory if the GA does the same.

It is the refusal to exploit any specific properties that makes it fun :). Real Sudoku solvers have been around for ages.

Not those kinds of entertainment games, but dual-n-back might do something. See for example http://en.wikipedia.org/wiki/Dual-n-back and http://www.brainboffin.com/