Most non-trivial programs can be drawn as diagrams at a conceptual level, which is probably the level you're talking about when you say you "think about algorithms but don't program" (I'm paraphrasing). Sounds like you're looking for an excuse not to learn programming. As soon as you do the answer to your question will be obvious: there's so much detail and complexity in a real program that a picture can't capture the information in a succinct way.
Sure, you can actually describe every variable and data structure and nuance of any program as a diagram, but it's going to be very complex and unmaintainable (ie very messy to debug) and have a lot of text in it to describe exactly what you want.
Some programming languages can be very good at simply defining certain types of programs - APL can do some awesome matrix and vector calculations in a few lines, or Perl can describe some very complex data manipulation in a few lines. In both cases you'd spend much, much longer describing it in a diagram that includes every nuance of the program, or trying to describe them in sentences.
All these things are self evident to programmers. They know there's fiddly detailed things you have to do in C or Assembler sometimes, or graphics that easier/faster done in Python/Tk or text manipulation best done in Awk or Perl or symbolic manipulation best done in Lisp or whatever. And to those programmers those programs ARE the most efficient way to encode ("draw") the problem. Furthermore other programmers look at well written code and quickly build an understanding of what code is doing. Comments help her a lot, depending on the familiarity of the programmer with the kind of code. (eg a programmer specialising in interrupt driven driver writing for a living is going to have trouble understanding a program with simulates sonar echoes in water).
Again, bite the bullet, learn how to program in a few languages and all this is obvious.
Then there's complex systems that can be described AT A HIGH LEVEL in diagrams, but the caveats and exceptions and nuances to describe it fully might cover 1000s of pages, or much more, of design documents. In many cases the final programs of hundreds of megabytes of definition documents (like an autopilot system I worked on for an air force jet) ends up much bigger than the final source code (and then the final programs are way smaller again).
Stop pussy footing around though, teach yourself to code and write some substantial programs (at least a few 1000 lines, but probably a fews 10k lines) and do that a few times, then in a few languages and you'll understand coding these days is pretty efficient. I'm sure it'll be improved upon but for now you'll get insight into why your question so obviously shows you just need to learn how to program.