Don't let the language dictate your thought processes #1
The problem I have found of coming to a different discipline (graphics to programming) is that I forgot how I learned the disciplines that I was familiar with in the first place. Today I was able to untangle some of this conundrum.
It started with the statement 'Don't let the language dictate your thought processes' which is similar to 'Don't let the media mask the message' but in a different guise.
For a long time I have been trying to understand why I find it difficult to think in Perl or indeed any other language. It all seems so easy when following a tutorial but when I have a problem to solve there did not seem to be any way of starting. I do regular problem solving every day so it is not a strange concept. I can intellectually understand the starting point and what it required and indeed the steps in between. However putting that into practice has prove more elusive than I first would have thought.
In designing graphics, logos, pictures and stuff I use the shapes as ways of communicating an idea. Someone gives me an outcome they want to achieve and a load of things that vaguely have something to do with it. I ask questions or not and then process the information giving them a graphical representation of the thing they said they wanted to achieve. I have techniques and mental patterns that let me get those odd scribblings or random conversations that people give me to produce something coherent.
In programming I do the same thing but in information not shapes. The bits of information to me internally have shapes and so I have tried to use the same techniques that I have always used for producing designs. I have struggle to understand why that was not working. The processes all seemed the same but when I came to write the code after making my plan I was always left with the question 'Now what do Ido? An the answer never seemed to come.
I have accepted up until now that perhaps I just did not have it in me and just to carry on do the odd script and a bit of cut and pasting there. I also accepted the perceived wisdom of the conventions used and best programming practices and all that. When trying to ask for help I have not been able to ask the right question to get the help. Everyone has been as helpful as they can. The most popular answers to my question 'Why don't I get it?' are 'Some people just do and others don't', 'Don't know what you're talking about' and 'I don't know it just happens'. Not a great start.
I have followed the tutorials and bought and read books by the ton. I have understood them to a certain degree and been able to use what I have learned to do what I have needed to do, but it has been a struggle. I am not averse to hard mental gymnastics however the whole thing is not intuitive for me. So my frustration was knowing that I deal with similar problems and come up with the goods in graphic design and that the mental processes are similar.
In the explanations and examples that I followed I could see how they got to where they wanted to be but I was unable to allegorically use that pattern to solve another problem. I was being shown one way to do it which is the natural way for that person or is the perceived best convention. There are of course more than one way to do it but I was only being shown one or at least I was not familiar enough to know how to find all the different ways and so I had this seemingly mad idea that I had to fit the whole of Perl into my head before I could do anything. Which of course is madness. Its not the way I approached using computers to do graphic design, I did not understand everything about the programs and processes before I was able to give a printer an eps file which separated the tints out for 2 colour printing that would appear that it was done in 7 colours.
So how had I got the wrong end of the stick? After I had decided what my program needed to do and mapped it out and then said 'So now what do I do?' I had not been able to get any further, I could not see the next step because I was trying to write Perl in the way that the tutorials and books ahd told me but it is not the way that I can write Perl. On of the reasons using Perl was because I had read at length that it was flexible and there was a myriad of ways to do the same thing. Ah yes unless it seemed you did not think like the people who wrote the tutorials (not a criticism) or that you had not come up through the same paths, which include neural ones too.
Graphically (image manipulation) my tools are the programs which I had transposed wrongly to be editors in programming (inli> manipulation). This may be correct if I was using a gui development environment but that only allows me to do the things that the program allows me to do not the programming language. Its the tools within the programming language that I needed to be comfortable with, than I would be able to think of a goal and then (as I do in graphics) be able to make that possible with the manipulations of the data. Intellectually of course there is no different but the methods are less so.
Today I traced the exact process by which I design things both on a drawing board and in a computer environment. I then applied this to the way I have been trying to do the same sort of process in a programming language. I came up with the following plan.
So I will start with a simple goal and then go questing, which will give me the broad spectrum of the different ways things can be done to acheive that same goal which in turn allows the language to adapt to my neural pathways. By cracking this nut all the others will be easier and I will not have to get the whole of Perl in my head. What a relief.
By doing this I will discover all the TMTOWTDI ness that Perl really has and will then understand enough to make my own path through the language to get to the desired outcome. The important thing is that it is my own way, everyone sees the world in a different way and has got to the position that they are now via many different routes and if the way that you are shown something does not fit into that way of thinking then all the book reading in the world will not cure it. Reading the source code as I have been doing has helped me to understand this.
It may seem blindingly obvious to you but it is not. What I had been doing is trying to make my mind think like Perl or at least he tutorials and not making Perl think like me. I had to learn not to let the language dictate my thought process because Perl can't think but I can. By discovering all the different ways Perl does things I will have a matrix to find my way to the outcome in a way that follows the way I think.
To the people who could not give me the answer to the question I did not know how to ask I apologise, you could not have understood the question because you have probably not had to ask a similar one yourself or if you did you would not have asked it from where I am. I could tell that from the perplexed expressions on your faces. Yes I can see your expression when you type.
It is probably just as well to note that the methods by which information is found is as important as the information that is provided, if there is not a track to it you can't visit.
I chose Perl because it promised that there was more than one way to do it. I took this to apply to every aspect and that it would allow me to do it my way which I will now test. I then got bogged down in doing what convention said because I was learning and thought that it new better but of course it doesn't do it better otherwise we would not improve things or find different ways to do things or find new things to do with the things we already have. I am aware of other considerations like efficiency and refactoring and endless boring list but make the programming language suit you, and if it won't let you do that, ditch it.
Re:Go backwards.
redspike on 2010-01-28T19:55:34
Interestingly I was chatting this over with a friend and he asked if I generally worked from the beginning or the end. Usually I visualise what I want and then start at the beginning keeping the end in sight. He suggested visualising what I wanted and then asking '..what would be the previous step..' and so on. My immediate reaction was that I was not too comfortable with that way of looking at it, however your method now looks quite appealing so I will have a look at it.
It is also interesting that when I was working some of this stuff out on paper I drew blocks to represent the code, so perhaps this may work for me too.Something else also dawned on me that in my comparison with the way I design graphics I equated buttons in a graphics program with buttons/shortcuts in the the ide or text editor rather than seeing that the buttons in a graphics program as being equal to the functions/methods in Perl
Thanks for the feedback and book reference, I will take a look
