Part of the problem I see after 11 years in the business, is that now I can see problems like you describe. I try and push as much work to the database as possible, not for performance (though that is a consideration) but because it is declarative, so you get less side effects. Its not as natural to think in sets as it is to think imperatively. But do people want to pay me more for this knowledge? Not here (in Spain). They want to pay extra for people using the latest fad technology, not people who know how to avoid problems at the design stage.
On the other hand, people pay first of all for working solutions. If you keep building robust and simple solutions, your managers will see it eventually - even though many managers don't recognize design talent when they see it, for fear of having to increase your salary.
Or the incompetent ones aren't seeing it because their metric is in the lines of code written, whereas a good developer always avoids writing unneeded code - this can be extended to other areas as well - people really good at solving concurrency issues for example, avoid concurrency issues like the plague they are. If that's the case, then it's time to search for something better. I live in Romania, our situation is similar, but I discovered that I have no problems in finding interesting work remotely - I stopped doing that because it's boring for me to not have colleagues nearby and found a small local company that's pretty cool. But yeah, you don't have to stay within the local market if you can't find something you like.
How do you go about getting remote clients? I am keen to work remotely for a few reasons. Seems that you need a portfolio, but all my work is in house (though I am working on a small app to show I can code to a decent standard).
It's not natural to think imperatively, otherwise people would have no trouble with learning programming. It's just the way we were taught to write programs.
Its generally easier that thinking in sets. Certainly my not so talented team leader always describes database queries in terms of "if it has this then do this". I translate these into "give me the set where".
No, it's not generally easier. You can't generalize because people around you, who were taught to think imperatively, are thinking imperatively. You don't know how would it be if they were taught to think in terms of set theory. It might be the other way around or it could be not. That's the point: we don't have the data to generalize on which thinking is easier.
Ok, have you got any non anecdotal evidence that proves it is "being taught imperatively" that makes imperative programming the "mainstream"? In 11 years I have met very few people who program functionally, and usually those people are good enough to know multiple paradigms. As far as I know most universities teach both.
Most of the universities I have seen or heard about teach C, C++, Java, Python
or the like on their courses. Only a subset of them teach also functional
languages (which is still quite far from declarativeness, but let's ignore
this for the time being), but even those don't require functional programming
throughout the whole time and people fall back to imperative languages.
Let's go further. Most of the materials in the internet are about programming
in imperative languages. Those are the most popular, including popularity
among newcommers.
I have never heard about anybody who started learning programming by
learning Lisp, Haskell, OCaml, SML or any other functional language. Similarly
I haven't heard about somebody, who learned one of those as his second
language and got any proficiency in them.
Please provide any data that contradicts the common sense conclusion (at least
common sense for me) that vast majority of people who were taught programming,
were taught programming imperatively.
Comments
Part of the problem I see after 11 years in the business, is that now I can see problems like you describe. I try and push as much work to the database as possible, not for performance (though that is a consideration) but because it is declarative, so you get less side effects. Its not as natural to think in sets as it is to think imperatively. But do people want to pay me more for this knowledge? Not here (in Spain). They want to pay extra for people using the latest fad technology, not people who know how to avoid problems at the design stage.
I can feel your pain :-)
On the other hand, people pay first of all for working solutions. If you keep building robust and simple solutions, your managers will see it eventually - even though many managers don't recognize design talent when they see it, for fear of having to increase your salary.
Or the incompetent ones aren't seeing it because their metric is in the lines of code written, whereas a good developer always avoids writing unneeded code - this can be extended to other areas as well - people really good at solving concurrency issues for example, avoid concurrency issues like the plague they are. If that's the case, then it's time to search for something better. I live in Romania, our situation is similar, but I discovered that I have no problems in finding interesting work remotely - I stopped doing that because it's boring for me to not have colleagues nearby and found a small local company that's pretty cool. But yeah, you don't have to stay within the local market if you can't find something you like.
How do you go about getting remote clients? I am keen to work remotely for a few reasons. Seems that you need a portfolio, but all my work is in house (though I am working on a small app to show I can code to a decent standard).
It's not natural to think imperatively, otherwise people would have no trouble with learning programming. It's just the way we were taught to write programs.
Its generally easier that thinking in sets. Certainly my not so talented team leader always describes database queries in terms of "if it has this then do this". I translate these into "give me the set where".
No, it's not generally easier. You can't generalize because people around you, who were taught to think imperatively, are thinking imperatively. You don't know how would it be if they were taught to think in terms of set theory. It might be the other way around or it could be not. That's the point: we don't have the data to generalize on which thinking is easier.
I was taught both. Who is generalising now?
And now you support your general claim by anecdotal evidence? Note that I don't make any claim apart from "it can't be generalized for now".
Ok, have you got any non anecdotal evidence that proves it is "being taught imperatively" that makes imperative programming the "mainstream"? In 11 years I have met very few people who program functionally, and usually those people are good enough to know multiple paradigms. As far as I know most universities teach both.
Most of the universities I have seen or heard about teach C, C++, Java, Python or the like on their courses. Only a subset of them teach also functional languages (which is still quite far from declarativeness, but let's ignore this for the time being), but even those don't require functional programming throughout the whole time and people fall back to imperative languages.
Let's go further. Most of the materials in the internet are about programming in imperative languages. Those are the most popular, including popularity among newcommers.
I have never heard about anybody who started learning programming by learning Lisp, Haskell, OCaml, SML or any other functional language. Similarly I haven't heard about somebody, who learned one of those as his second language and got any proficiency in them.
Please provide any data that contradicts the common sense conclusion (at least common sense for me) that vast majority of people who were taught programming, were taught programming imperatively.