There are basically two kinds of flow charts: One describes an algorithm (instead of using pseudo code; a good example is here, the other gives a high-level overview over how different components interact in a complex application.

As has been pointed out, both are language independent.

And the second one is usually a lie.

Most complex programs these days are object oriented, and that means that that whenever you obtain data from an object outside your own class/package/module, you call a method from another class or object. So a real-world application crosses the border between classes thousands of times, instead of having a smooth border that is crossed once or twice.

Instead of showing the control flow, it would be far more interesting to know what objects are shared between subsystems, or through which objects subsystems interact with each other.

Which brings me to my main point: For a complex system, a detailed flow chart is usually too complicated to show anything of interest, and a simplified flow chart is usually a lie and often not helpful either.

So if your program is getting so complex that you lose overview over the control flow, it might very well be a sign that you could use a better approach. Like objects which don't care very much about control flow, because they are well encapsulated.