Without getting into the Sapir-Whorf Hypothesis, I will make the claim that the language, framework and tools (collectively, your programming ecosystem) profoundly influences and shapes the way you think, in terms of writing software.

It’s not hard to see why this is true. Consider a typical line-of-business application. Traditionally, we would have written SQL statements to retrieve data out of a database and produce a report. But then ORM’s came along, and now we can retrieve data into collections of objects. Eventually, someone pointed out “Well, why do we even need SQL at all,” and the NoSQL movement was born.

How do these different paradigms affect the way programmers think? Well, in SQL, if you want to relate two tables of information together, you perform a JOIN. The NoSQL guy has to loop through his collections to find pairs that match. The SQL guy thinks in terms of sets and joins. The NoSQL guy thinks in terms of collections and loops.

In terms of the programming language itself, your programming experience (and the way you think) will be strongly influenced by:

• what facilities the language offers,
• at what level of conceptual abstraction the language is (i.e. is it low-level or high-level),
• what paradigms the language offers (i.e. Functional, Imperative, Object-Oriented), and
• what kind of assumptions the language designers make (e.g. many ways to do a thing vs. the One True Way).

Eric Raymond sums it up eloquently when he speaks of the benefits of learning Lisp:

Lisp is worth learning for the profound enlightenment experience you
will have when you finally get it; that experience will make you a
better programmer for the rest of your days, even if you never
actually use Lisp itself a lot.

For more about how language influences the way we think, see here:
http://scienceblogs.com/cognitivedaily/2005/05/13/does-our-language-affect-our-t/

I think it’s a good question, not easily answered.
All I can give you is my take on it.

There’s something in your head – a problem and its solution.
The separation between those is not always clear, but they are stated in a mental language appropriate to the problem.
You can get a hint of what this language is by discussing the problem with another person.
That reveals a network of concepts in the form of words.

If a computer program is to be part of the solution, then the problem/solution needs to be communicated in keystrokes to the machine. To do this it is probably necessary to educate the machine about the problem domain, so you can tell it what you want.

When you define a datatype or write a procedure or otherwise define things in a computer language, you are augmenting that language with the concepts appropriate to your problem. You are turning it into a DSL (domain-specific-language in the lingo).
There is a lot of skill involved in this step, and different programmers have learned different ways to do this.

Now if you’re asking about different programming paradigms like OOP, functional programming, logic programming, etc. etc., which of those shortens your path to creating the DSL that you want?
Again it depends on training.
(If all you have is a hammer, everything looks like a nail.)
I encourage people to have as diverse a set of mental tools as possible.

The extent to which you’ve created a DSL for your problem is a matter of degree.
In the ideal extreme, it should only be necessary to state your problem, where the solution is built into the DSL.
A measure of how well you’ve done this is to consider incremental changes to the problem and ask how much editing in the language is necessary to effect them without errors.
The ideal is 1:1. 1:5 is not too bad. I’ve seen 1:50 and that’s not good.
The bigger that ratio is, the harder it is to get your idea across to the code, and the harder it is to avoid putting in bugs.

(I don’t know if it would help to give you an idea what I mean to show how I tried to do this in the domain of dynamic user interfaces.)