How to teach humanities to program
Greetings to all!
In this article I would like to highlight the peculiarities of teaching programming to humanities trained by techies, based on my small experience. The specificity lies in the fact that I did not have the opportunity to comprehensively investigate different types of humanities and approaches to them. I mainly worked with those who chose philosophy as the main path. Mainly in the context of philosophers, further and go detail.
')
My experience, on the basis of which I made the described conclusions, arose from approximately 6 years of total work with people who wanted or thought they wanted to learn programming. In the course of work, both group and individual classes were conducted with students (age from 16 to 26 years), the size of the groups was on average about 11 people, several groups in parallel.
The groups were divided according to the ways of thinking and on average had a comparable level of intelligence. This gave me the opportunity to observe live how much the perception speed differs in different areas of programming, which strengthened me in suspicions that by varying the learning paths, the speed of laggards can be significantly increased if we use the basis understood in their coordinate system and at the level of the information processing method. Attempts to find the right approach to people of a humanitarian mentality were made gradually, without using methodological and psychological aids aimed specifically at the humanities. Most of those who completed my course at the end were successfully guided in approaches to solving some of the tasks that they have in their hobbies, and to which the use of programming has (at least, visible to me) meaning.
It should be noted that I divide the solution of the problem “to make a programmer humanity” into 3 big questions.
1. The question of motivation, or "why do I need this?"
2. The question of the way of learning, or “how can I make the computer understand me?”
3. The question of finding the entry point, or "where to start when I faced a specific task?"
Basically, in the article I will try to reveal exactly the second question, but briefly go through the rest.
By the way, the article is big. If you get tired of reading, but the conclusions that I drew are interesting - the results are at the end.
Immediately, I do not claim to be true either in the last or in the penultimate instance, or a broad, generalized approach: all I’m telling is just a statement of the most effective way I found to teach the humanities, mostly a philosopher, to program. Different people have their differences, the article will list only the main, characteristic of the vast majority of humanities students that I have encountered.
I think I’m not mistaken if I say that the overwhelming majority of active programmers, as well as those who teach this, are people of a technical mindset. Among techies the question of motivation - why do they need to learn to program? - it is not particularly painful: many of them understand the benefits of the ability to read, understand or be able to write code, the applicability of programming in their hobbies or their future work. In principle, by experience, only a small number of techies from this occupation are experiencing a strong negative.
The situation is different with the humanities.
The question of the terminology "who is the humanities and how it differs from mathematicians / programmers / theoretical physicists" I propose to set aside. There are quite a few definitions on the Internet, usually based on practical ways to distinguish one type from another. On an intuitive level, the way a person thinks and expresses his thoughts can be understood in a fairly short time what camp this person belongs to. I suggest so far on such an intuitive method of definition and dwell.
The motivation of people of a humanitarian mindset is significantly complicated by the fact that, as a rule, in their field of activity and hobbies, the use of programming (in any case, not of higher order) is extremely limited, and if the tasks that could be solved with the help of the program appear then they are far from simple and require good preparation, for example, in the field of genetic algorithms.
To motivate from the point of view of expanding possible areas of application in the future in order to be more in demand in case of what? In any case, programming will remain an alien discipline for them, disturbing thepeaceful course of the Force, their usual ways of thinking and acting. Spending serious efforts at what will be done in the best case is not very unpleasant, difficult, not bringing pleasure from life and for reasonable time periods not contributing to finding harmony with the world is not a rosy prospect.
Motivate in terms of broadening horizons? In fact, the ways of expanding the horizons of the humanities are not much less than those of techies, these methods simply do not lie in the present-future, but in the past. History, religions, researches of thinkers of various directions - there is a lot of information. So our programming with you is not perceived as any idol to pray for, just completely. Considering the frequency of attacks on "stupid humanists" by human-like humans who identify themselves as human-technical elite, such an attempt at motivation is doomed to failure very quickly.
Any attempt to motivate with the help of orientation towards practical application - so to say, at least something material that will be a direct product of their activity - will also fail. This direct practical application of his gift did not surrender ...
The only way to motivate the humanities to study programming, so that it gives at least minimal positive cravings, for me was a call for their universality. Humanitarians, as a rule, do not like to be very narrow experts in their field. The circle of their education, in which they believe that they should be above average, is rather wide and does not always lie only in the areas adjacent to their profile. For example, linguists often like to educate themselves on religious issues, historians like art criticism (this is, of course, almost a related discipline, but still), and so on. You can play on this as on a substrate to prove that it may be interesting to them at all. After all, programming will form another type of thinking for them, albeit not at a deep level, this is very new and highly unconventional for them, which, in turn, gives rise to - at first, of course - a good craving for fighting “these hated teams”.
Of course, one cannot disregard the possibility of achieving as a result of a better mutual understanding with people of a technical mentality. But before this, the humanities themselves think of it.
So, the humanities are collected, ready to learn and crave for knowledge. Where to start?
Here we should immediately retreat in connection with a qualitatively different level of expectations from the subject. The technician understands that the result is not achieved in a couple of lessons, and that complex programs are assembled from bricks, and that in order to get the final result, you need to be able to collect each cube. The humanist understands this, too, although it is not very thought about this from the very beginning - there is no such a pronounced ladder of skills in the humanities disciplines. When setting several tasks from N bricks, the techie is looking for an opportunity to reuse what has already been written, so that as few bricks as possible should be implemented in the future. Humanities are discouraged, because it is very, very fast that how much small, painstaking, boring work has to be done to reach its realization in order to get even a small result at the output. With the wrong approach, it is very easy to kill any willingness of the humanities to do this hard work, and then you will not be lured by his carrot. It's easier with techies - they need to torment them longer so that they hate programming.
I want to make another digression. The further story in large quantities contains indications that the usual and understandable to the main majority of techies method of understanding a certain thing is not suitable for the humanities. Yes, there is a great desire to clutch at the head and cry out - how is it, is it elementary ?! I tried to emphasize as much as possible that their understanding of the basis differs from the technical one, which does not make these methods globally worse - only makes the perception of programming as a discipline, invented by technical people, much more difficult for them. With the same result, they will need to put more effort into understanding a certain programming trick than the average techie, due to a different mindset. Let's try at least in this article to live in a world "where work is considered a measure of fatigue."
Let's look at how a person is taught in the standard methodology, why a cycle is needed. For example, you need to output numbers from 1 to 30.
At first it is proposed to do this for 1 number Then for 2. Then for 3, and so on. It is clear that initially people will simply write in a column a command to deduce the next number. It quickly reaches the learner that this strategy is not advantageous in case of a large number of repetitions. After that, a transition is made to the general form - to output the numbers from 1 to N, where N will be, for example, equal to 30. Teach the corresponding construction - and on this cycle, one can say, learned.
So, this is how it works - of course, with techies - and only at best with the third part of the humanities.
Practice shows that humanitarians are very clearly divided by at least two signs. This is the initial availability of the extrapolation method for the brain and the category of the size of a brick that a person can perceive . Under the brick in the second sign implies the commonality of the problem, a kind of abstract measure of abstraction, sorry for the tautology. The value of abstraction in parrots, in general.
It may seem that, from the presence or absence of the first feature, it may be logical enough to follow the second feature. However, in practice this does not happen. At a minimum, extrapolation does not always give rise to abstraction. However, let's leave the clarification of the reasons for this to those who are interested; I will only list into which categories people can be divided according to these characteristics:
a) A person may well understand what extrapolation is, and it is good to perceive only the bricks of a small volume.
b) It may have big problems with the use of extrapolation, and it is good to perceive only small pieces.
c) Or - the third option - may not have problems with extrapolation, and at the same time understand only the big bricks of knowledge at once.
Of course, the fourth combination occurs - do not understand extrapolations and be able to perceive only large chunks of knowledge. But it rarely occurs, much less frequently than the other three.
In the future, I will mainly deal with the options when a person can perceive only the great bricks of knowledge at once, because it was with them that I had the most experience with philosophers. Overwhelmingly, they will atrophy the ability to understand and — including as a result — extrapolate small pieces, and the task, devoid of great abstraction, becomes difficult to overcome. I will try to show which approach in a problem with a cycle is easier to digest.
So, we need to teach man the cycle. Take the approach: we have an array (do not count the sum of the numbers from 1 to how many the user enters, because this is a mathematical problem, it is trivial for the humanities). The array is explained as an abstract data type, a container with a bunch of elements of the same type, for example, numbers, inside. We need to get their amount. How to do it?
Problem number 1: to come up with a non-mathematical task that will be interesting to the student, in which it may be needed in an obvious way . For example, counting the number of publications of a particular author in the home library of books. In no case can one use the concepts “here it will be necessary to calculate the average, it will be necessary to calculate the amount, then to divide it into it” ... This is the way to failure. Any connection with mathematical calculations, if it is not baffled, will give rise to a critical internal stress in the student.
Problem number 2: to propose to solve this problem at the conceptual level without drawing an exact algorithm or, God forbid, flowcharts. It is enough for the student to reach the stage “we look at the cabinet, we sort out the books in a row. Every time we find a book by this author, we bend a finger. ” Then, instantly (we are still talking about adults), it comes to the idea that you can draw a stick on a piece of paper instead of bending a finger to count as many large numbers of books as you like.
Problem number 3: to project the solution of the problem, which is already invented at the conceptual level, on ... not an algorithm. Not a flowchart. Immediately into the language in which the person learns to program.
Forget that programming in its true essence is the ability to compose algorithms. Leave it to those of techies who have a head for it is sharpened. Now our task is to teach a person to do something for which his way of thinking is completely unprepared.
It is important not to try to teach "to work on algorithms." In order to do this, the humanities must first create an algorithm, which is always difficult, unpleasant and uninteresting. If there is already such an algorithm, it will find the program where the algorithm will be implemented, or it will count on the calculator. If the algorithm is too complicated, so that it can be calculated on a calculator and a piece of paper - the humanities simply will not solve this problem, if it does not at all, and will be unhappy all this time. In general, the word algorithm deprives them of peace of mind in general and the desire to engage in programming in particular.
In such a projection, a sheet of paper will become a variable that stores the number of elements, and the passage through the bookshelves in a row - viewing the elements of the array one by one. It is important not to simplify the task so that it is solved as a result in one action - for example, immediately switch to OOP and say that this will be our list, but this method will return the number of elements in the filter in the parameters - and not pain. Still, the task is to teach a person programming, which means that with all the features of his brain he will have to learn to build a house of bricks, and it is easier to build a house than a skyscraper of growing panel plates with an initial height of ten meters and self-expanding stairs.
After the story about the next programming technique, it is very important to point out with which such a technique can be used. For many techies, it is intuitively clear that another cycle can be placed in the body of a cycle, or, at worst, a procedure call in which there will be something else. Most humanists have a basic association of programming tools with conventional, for example, home appliances, in which only certain items can be placed, and the output will be one of those items that is specified in the instructions in the list of possible results of this technique. It is necessary to show that a programming tool is also an abstract thing, which has some limits, but as a tool with which this tool will work, a wider class of objects can be used than just a list of concrete examples. The principle of restriction “by contradiction” works well, in the spirit of prohibition to put a cat in the microwave, but always it is necessary to specify with what class, type, input data the tool can work, and also that it can be combined with other programming tools. The phrase “it will work with anything” is incorrect, because they will try to put there some question of existentiality in a general way and will not be able to understand what result to expect.
Also, I very rarely observed the students wanting to try, how a tool behaves, if you put something unexpected / other type of data into it, and so on. After all, the rules by which the tool operates are dictated by algorithms , that is, trying to understand them is painful, time consuming and difficult, so this is not done, at least, at first. Partly this lack of curiosity, let's call it that, is filled by the ability to perceive the types of input data in the abstract, but it still imposes some additional conditions on the teacher when learning dynamic data types and objects begins. In this matter, paradoxically, the humanities are much more specific than the techies.
Special cases and boundary conditions become a sore spot in teaching humanities with a problem perception of small pieces of knowledge. Unfortunately, nothing better than letting me know what the most common boundary conditions for each type of connection between stored data should be considered, I have not found. Further checks will be arranged according to the principle of accumulating experience and filling cones, as little and slowly as possible, and this is good - each such check is a serious test of the determination of the humanities.
Stuffing cones, of course, occurs due to the receipt of errors in the program. An ambush awaits here: you have to train a novice programmer to read in the compiler / interpreter language (hereinafter simply the compiler, as practice shows that the interpreter leads the humanities in thought for several reasons, one of which is “if it does everything in steps, why should we strain and write a program when we ourselves can perform the necessary steps? ”Moreover, in languages ​​with compilers, it is easier to look for errors: the humanities would never think of sticking in the variable the value of the wrong type, for example; having their curiosity so very different nature). The compiler, as a rule, is not too friendly in demonstrating the true error in the program, much more often it is an error in the "unexpected comma" spirit. In such cases it helps to give the learner to look at examples of the same in the structure of the code written earlier and working. It is important that the code is always written in the same style. I have not met with the humanities with this problem. Totally. It is said to write in this style - they will write in that. Then they will correct it if it is somehow more convenient for them.
Important!
As with most people, it is important for humanities scholars to see the result of as few code as possible. No, not like most people - much stronger. This gives them much needed motivation to continue. At the same time - a paradox! - they really do not like to do extra work, that is, to write additional seals, which will have to be removed to get the finished program. A good way is to give them a previously written small function that will write this line, which they want to output, not on the screen, but in a file, and so that the file will be open for them all the time in the background (or the second monitor). The process of contemplating the results of the work significantly reinforces their faith in their own strength.
Practice shows that abstract things that cannot be “touched” (or which are not intended for this at the basic level) are perceived by humanities well and as if easily. For example, this is the case with pointers in C. The main thing - do not go into details of the use of operators, unary, binary, and the presentation of data inside the computer. This is all very concrete and is of no interest, as well as assistance in future programming at the level at which they would like to use it in principle.
Raising the level of abstraction of data presentation is also easy for them. So if learning is hard, you can always temporarily rise above the level of elementary data types, reduce the stress that comes from learning what does not work, and carefully return after that.
Problems arise when it is necessary to work specifically with these abstract things. That is, there are two problems: the first problem is to transfer from a certain task in a rather general way to interaction with particulars (transformation of the particular into the general), and then, having understood what tools are needed to work with these specific components of the task, once again rise to the level of unification of these tools (that is, the transformation of private + methods of working with them in general). Humanitarians are afraid of the tools of the language, perceived by them, in general, quite truthfully, as having some technical basis, and cannot use them outside the framework that they put in when feeding this tool. It is necessary to emphasize repeatedly that nothing globally breaks from their actions, and from the fact that they are not sure what action needs to be carried out further, it is necessary to go on to try differently, and nothing bad will happen . In their view, the task is presented as a kind of global cloud, and the task of condensing it to concretize and isolate objects with which you can interact using the tools that they were given for this type of thinking is very difficult.
Unfortunately, the difficulty of this task is that the attempts to split and, thus, simplify the task, run into rejection as an accessible action. After all, in their thinking, if the abstraction is divided into two parts, you will still get an abstraction (and not two abstractions). In my practice, this was a critical moment in the formation of another type of thinking: if the student created another operation in his brain that says that these programmer abstractions are not like everyone, but are divisible, and they can and should be divided, then much easier.
Attempts to inculcate a reverse, step-by-step method of writing programs did not lead to success, since it goes against the methods of working with humanitarian disciplines. In addition, a great difficulty was encountered in yet another aspect: the integrity of the solution. It turned out to be very difficult for me to teach how to write down what the trainees have already invented, how to do it: if they invented it, then what is so complicated, why write down? I encountered the problem of a shortage of “RAM” of trainees rather quickly, and the need for the integrity of the invented solution appeared before me in all its glory. I was able to overcome this only by giving a strongly consistent increase in the ladder of the proposed solutions, then the method of implementing each step takes very little memory in the solution development process, and the tasks are successfully solved.
This is one of the most difficult issues at the beginning of training.
First, because tasks must first be very strongly deterministic. There should not be allowed things with which I myself when stating tasks I sin quite strongly: the missing conditions are filled at the discretion of the student. For example, the input data input method. Such things must be strictly defined.
The key point for me was the fact that it is necessary to thoroughly tell how the extrapolation of the available data types to the abstractions with which they may have to work is done. That cell analogy is an object that stores parameters and other objects. That DNA can be considered as a set of elements, that is, reduced to an array. In this case, the main direction of explanation for those humanities who understand extrapolation well should be extrapolation of data types to types with which to work later in life, and for the rest - reduction of things to work with, to a certain fixed data type format and programming tools.
Secondly, a certain obligatory integrity of the solution comes to the head of the student again. It is necessary to emphasize that there is nothing shameful or bad to deal with certain problem areas later, when the rest of the solution is ready.The problem is to load an existing object into a data type (or drag a data type onto an existing object) - a frequently occurring problem, and the sooner trainees become familiar with object data types (structures), the easier it will be for them to later learn to put software terms and real-life terms into correspondence.
Thirdly, when the humanist thinks how he will solve the task, a frequent practice in their mind is to recreate “how would I start to solve such a task?” - and therefore, when you start writing a program, the very first question turns out to be “where is everything What did I just work with in my head? ”It is necessary to clearly and several times, with the introduction of each new type of data, explain where the data may appear in this variable / in this object and give examples of filling it with data. Then in the head of the humanities the answer will be born in the spirit of “since I was going to solve the problem through an array, the method of filling it is suitable here next ...” - and the writing of the program will go its own normal way.
In conclusion, I want to say that, although programming training is rather hard at first for people with a humanitarian mindset, in the future they begin to apply the methods that they tried in various combinations, even without cunning and beloved by many programmers, sophisticated sophistication, but quite confidently. And besides, they enjoy the realization that they had the opportunity to look into the world of unusual implications and transformations through the eyes of techies and thus gain new experience.
And as a result, I’ve got a very short list of hints I’ve reached. Suddenly it will be useful to someone, if you urgently need to prepare.
Good luck to everyone who will do this. I hope this article will help and tell you something in this situation.
And I express my great appreciation to all my "test subjects".
PS If someone has found more ways to motivate the humanities to study this discipline well, I will be glad to hear.
In this article I would like to highlight the peculiarities of teaching programming to humanities trained by techies, based on my small experience. The specificity lies in the fact that I did not have the opportunity to comprehensively investigate different types of humanities and approaches to them. I mainly worked with those who chose philosophy as the main path. Mainly in the context of philosophers, further and go detail.
')
My experience, on the basis of which I made the described conclusions, arose from approximately 6 years of total work with people who wanted or thought they wanted to learn programming. In the course of work, both group and individual classes were conducted with students (age from 16 to 26 years), the size of the groups was on average about 11 people, several groups in parallel.
The groups were divided according to the ways of thinking and on average had a comparable level of intelligence. This gave me the opportunity to observe live how much the perception speed differs in different areas of programming, which strengthened me in suspicions that by varying the learning paths, the speed of laggards can be significantly increased if we use the basis understood in their coordinate system and at the level of the information processing method. Attempts to find the right approach to people of a humanitarian mentality were made gradually, without using methodological and psychological aids aimed specifically at the humanities. Most of those who completed my course at the end were successfully guided in approaches to solving some of the tasks that they have in their hobbies, and to which the use of programming has (at least, visible to me) meaning.
It should be noted that I divide the solution of the problem “to make a programmer humanity” into 3 big questions.
1. The question of motivation, or "why do I need this?"
2. The question of the way of learning, or “how can I make the computer understand me?”
3. The question of finding the entry point, or "where to start when I faced a specific task?"
Basically, in the article I will try to reveal exactly the second question, but briefly go through the rest.
By the way, the article is big. If you get tired of reading, but the conclusions that I drew are interesting - the results are at the end.
Immediately, I do not claim to be true either in the last or in the penultimate instance, or a broad, generalized approach: all I’m telling is just a statement of the most effective way I found to teach the humanities, mostly a philosopher, to program. Different people have their differences, the article will list only the main, characteristic of the vast majority of humanities students that I have encountered.
Question of motivation
I think I’m not mistaken if I say that the overwhelming majority of active programmers, as well as those who teach this, are people of a technical mindset. Among techies the question of motivation - why do they need to learn to program? - it is not particularly painful: many of them understand the benefits of the ability to read, understand or be able to write code, the applicability of programming in their hobbies or their future work. In principle, by experience, only a small number of techies from this occupation are experiencing a strong negative.
The situation is different with the humanities.
The question of the terminology "who is the humanities and how it differs from mathematicians / programmers / theoretical physicists" I propose to set aside. There are quite a few definitions on the Internet, usually based on practical ways to distinguish one type from another. On an intuitive level, the way a person thinks and expresses his thoughts can be understood in a fairly short time what camp this person belongs to. I suggest so far on such an intuitive method of definition and dwell.
The motivation of people of a humanitarian mindset is significantly complicated by the fact that, as a rule, in their field of activity and hobbies, the use of programming (in any case, not of higher order) is extremely limited, and if the tasks that could be solved with the help of the program appear then they are far from simple and require good preparation, for example, in the field of genetic algorithms.
To motivate from the point of view of expanding possible areas of application in the future in order to be more in demand in case of what? In any case, programming will remain an alien discipline for them, disturbing the
Motivate in terms of broadening horizons? In fact, the ways of expanding the horizons of the humanities are not much less than those of techies, these methods simply do not lie in the present-future, but in the past. History, religions, researches of thinkers of various directions - there is a lot of information. So our programming with you is not perceived as any idol to pray for, just completely. Considering the frequency of attacks on "stupid humanists" by human-like humans who identify themselves as human-technical elite, such an attempt at motivation is doomed to failure very quickly.
Any attempt to motivate with the help of orientation towards practical application - so to say, at least something material that will be a direct product of their activity - will also fail. This direct practical application of his gift did not surrender ...
The only way to motivate the humanities to study programming, so that it gives at least minimal positive cravings, for me was a call for their universality. Humanitarians, as a rule, do not like to be very narrow experts in their field. The circle of their education, in which they believe that they should be above average, is rather wide and does not always lie only in the areas adjacent to their profile. For example, linguists often like to educate themselves on religious issues, historians like art criticism (this is, of course, almost a related discipline, but still), and so on. You can play on this as on a substrate to prove that it may be interesting to them at all. After all, programming will form another type of thinking for them, albeit not at a deep level, this is very new and highly unconventional for them, which, in turn, gives rise to - at first, of course - a good craving for fighting “these hated teams”.
Of course, one cannot disregard the possibility of achieving as a result of a better mutual understanding with people of a technical mentality. But before this, the humanities themselves think of it.
The question of learning
So, the humanities are collected, ready to learn and crave for knowledge. Where to start?
Here we should immediately retreat in connection with a qualitatively different level of expectations from the subject. The technician understands that the result is not achieved in a couple of lessons, and that complex programs are assembled from bricks, and that in order to get the final result, you need to be able to collect each cube. The humanist understands this, too, although it is not very thought about this from the very beginning - there is no such a pronounced ladder of skills in the humanities disciplines. When setting several tasks from N bricks, the techie is looking for an opportunity to reuse what has already been written, so that as few bricks as possible should be implemented in the future. Humanities are discouraged, because it is very, very fast that how much small, painstaking, boring work has to be done to reach its realization in order to get even a small result at the output. With the wrong approach, it is very easy to kill any willingness of the humanities to do this hard work, and then you will not be lured by his carrot. It's easier with techies - they need to torment them longer so that they hate programming.
I want to make another digression. The further story in large quantities contains indications that the usual and understandable to the main majority of techies method of understanding a certain thing is not suitable for the humanities. Yes, there is a great desire to clutch at the head and cry out - how is it, is it elementary ?! I tried to emphasize as much as possible that their understanding of the basis differs from the technical one, which does not make these methods globally worse - only makes the perception of programming as a discipline, invented by technical people, much more difficult for them. With the same result, they will need to put more effort into understanding a certain programming trick than the average techie, due to a different mindset. Let's try at least in this article to live in a world "where work is considered a measure of fatigue."
Let's look at how a person is taught in the standard methodology, why a cycle is needed. For example, you need to output numbers from 1 to 30.
At first it is proposed to do this for 1 number Then for 2. Then for 3, and so on. It is clear that initially people will simply write in a column a command to deduce the next number. It quickly reaches the learner that this strategy is not advantageous in case of a large number of repetitions. After that, a transition is made to the general form - to output the numbers from 1 to N, where N will be, for example, equal to 30. Teach the corresponding construction - and on this cycle, one can say, learned.
So, this is how it works - of course, with techies - and only at best with the third part of the humanities.
Practice shows that humanitarians are very clearly divided by at least two signs. This is the initial availability of the extrapolation method for the brain and the category of the size of a brick that a person can perceive . Under the brick in the second sign implies the commonality of the problem, a kind of abstract measure of abstraction, sorry for the tautology. The value of abstraction in parrots, in general.
It may seem that, from the presence or absence of the first feature, it may be logical enough to follow the second feature. However, in practice this does not happen. At a minimum, extrapolation does not always give rise to abstraction. However, let's leave the clarification of the reasons for this to those who are interested; I will only list into which categories people can be divided according to these characteristics:
a) A person may well understand what extrapolation is, and it is good to perceive only the bricks of a small volume.
b) It may have big problems with the use of extrapolation, and it is good to perceive only small pieces.
c) Or - the third option - may not have problems with extrapolation, and at the same time understand only the big bricks of knowledge at once.
Of course, the fourth combination occurs - do not understand extrapolations and be able to perceive only large chunks of knowledge. But it rarely occurs, much less frequently than the other three.
In the future, I will mainly deal with the options when a person can perceive only the great bricks of knowledge at once, because it was with them that I had the most experience with philosophers. Overwhelmingly, they will atrophy the ability to understand and — including as a result — extrapolate small pieces, and the task, devoid of great abstraction, becomes difficult to overcome. I will try to show which approach in a problem with a cycle is easier to digest.
So, we need to teach man the cycle. Take the approach: we have an array (do not count the sum of the numbers from 1 to how many the user enters, because this is a mathematical problem, it is trivial for the humanities). The array is explained as an abstract data type, a container with a bunch of elements of the same type, for example, numbers, inside. We need to get their amount. How to do it?
Problem number 1: to come up with a non-mathematical task that will be interesting to the student, in which it may be needed in an obvious way . For example, counting the number of publications of a particular author in the home library of books. In no case can one use the concepts “here it will be necessary to calculate the average, it will be necessary to calculate the amount, then to divide it into it” ... This is the way to failure. Any connection with mathematical calculations, if it is not baffled, will give rise to a critical internal stress in the student.
Problem number 2: to propose to solve this problem at the conceptual level without drawing an exact algorithm or, God forbid, flowcharts. It is enough for the student to reach the stage “we look at the cabinet, we sort out the books in a row. Every time we find a book by this author, we bend a finger. ” Then, instantly (we are still talking about adults), it comes to the idea that you can draw a stick on a piece of paper instead of bending a finger to count as many large numbers of books as you like.
Problem number 3: to project the solution of the problem, which is already invented at the conceptual level, on ... not an algorithm. Not a flowchart. Immediately into the language in which the person learns to program.
Forget that programming in its true essence is the ability to compose algorithms. Leave it to those of techies who have a head for it is sharpened. Now our task is to teach a person to do something for which his way of thinking is completely unprepared.
It is important not to try to teach "to work on algorithms." In order to do this, the humanities must first create an algorithm, which is always difficult, unpleasant and uninteresting. If there is already such an algorithm, it will find the program where the algorithm will be implemented, or it will count on the calculator. If the algorithm is too complicated, so that it can be calculated on a calculator and a piece of paper - the humanities simply will not solve this problem, if it does not at all, and will be unhappy all this time. In general, the word algorithm deprives them of peace of mind in general and the desire to engage in programming in particular.
In such a projection, a sheet of paper will become a variable that stores the number of elements, and the passage through the bookshelves in a row - viewing the elements of the array one by one. It is important not to simplify the task so that it is solved as a result in one action - for example, immediately switch to OOP and say that this will be our list, but this method will return the number of elements in the filter in the parameters - and not pain. Still, the task is to teach a person programming, which means that with all the features of his brain he will have to learn to build a house of bricks, and it is easier to build a house than a skyscraper of growing panel plates with an initial height of ten meters and self-expanding stairs.
After the story about the next programming technique, it is very important to point out with which such a technique can be used. For many techies, it is intuitively clear that another cycle can be placed in the body of a cycle, or, at worst, a procedure call in which there will be something else. Most humanists have a basic association of programming tools with conventional, for example, home appliances, in which only certain items can be placed, and the output will be one of those items that is specified in the instructions in the list of possible results of this technique. It is necessary to show that a programming tool is also an abstract thing, which has some limits, but as a tool with which this tool will work, a wider class of objects can be used than just a list of concrete examples. The principle of restriction “by contradiction” works well, in the spirit of prohibition to put a cat in the microwave, but always it is necessary to specify with what class, type, input data the tool can work, and also that it can be combined with other programming tools. The phrase “it will work with anything” is incorrect, because they will try to put there some question of existentiality in a general way and will not be able to understand what result to expect.
Also, I very rarely observed the students wanting to try, how a tool behaves, if you put something unexpected / other type of data into it, and so on. After all, the rules by which the tool operates are dictated by algorithms , that is, trying to understand them is painful, time consuming and difficult, so this is not done, at least, at first. Partly this lack of curiosity, let's call it that, is filled by the ability to perceive the types of input data in the abstract, but it still imposes some additional conditions on the teacher when learning dynamic data types and objects begins. In this matter, paradoxically, the humanities are much more specific than the techies.
Special cases and boundary conditions become a sore spot in teaching humanities with a problem perception of small pieces of knowledge. Unfortunately, nothing better than letting me know what the most common boundary conditions for each type of connection between stored data should be considered, I have not found. Further checks will be arranged according to the principle of accumulating experience and filling cones, as little and slowly as possible, and this is good - each such check is a serious test of the determination of the humanities.
Stuffing cones, of course, occurs due to the receipt of errors in the program. An ambush awaits here: you have to train a novice programmer to read in the compiler / interpreter language (hereinafter simply the compiler, as practice shows that the interpreter leads the humanities in thought for several reasons, one of which is “if it does everything in steps, why should we strain and write a program when we ourselves can perform the necessary steps? ”Moreover, in languages ​​with compilers, it is easier to look for errors: the humanities would never think of sticking in the variable the value of the wrong type, for example; having their curiosity so very different nature). The compiler, as a rule, is not too friendly in demonstrating the true error in the program, much more often it is an error in the "unexpected comma" spirit. In such cases it helps to give the learner to look at examples of the same in the structure of the code written earlier and working. It is important that the code is always written in the same style. I have not met with the humanities with this problem. Totally. It is said to write in this style - they will write in that. Then they will correct it if it is somehow more convenient for them.
Important!
As with most people, it is important for humanities scholars to see the result of as few code as possible. No, not like most people - much stronger. This gives them much needed motivation to continue. At the same time - a paradox! - they really do not like to do extra work, that is, to write additional seals, which will have to be removed to get the finished program. A good way is to give them a previously written small function that will write this line, which they want to output, not on the screen, but in a file, and so that the file will be open for them all the time in the background (or the second monitor). The process of contemplating the results of the work significantly reinforces their faith in their own strength.
Practice shows that abstract things that cannot be “touched” (or which are not intended for this at the basic level) are perceived by humanities well and as if easily. For example, this is the case with pointers in C. The main thing - do not go into details of the use of operators, unary, binary, and the presentation of data inside the computer. This is all very concrete and is of no interest, as well as assistance in future programming at the level at which they would like to use it in principle.
Raising the level of abstraction of data presentation is also easy for them. So if learning is hard, you can always temporarily rise above the level of elementary data types, reduce the stress that comes from learning what does not work, and carefully return after that.
Problems arise when it is necessary to work specifically with these abstract things. That is, there are two problems: the first problem is to transfer from a certain task in a rather general way to interaction with particulars (transformation of the particular into the general), and then, having understood what tools are needed to work with these specific components of the task, once again rise to the level of unification of these tools (that is, the transformation of private + methods of working with them in general). Humanitarians are afraid of the tools of the language, perceived by them, in general, quite truthfully, as having some technical basis, and cannot use them outside the framework that they put in when feeding this tool. It is necessary to emphasize repeatedly that nothing globally breaks from their actions, and from the fact that they are not sure what action needs to be carried out further, it is necessary to go on to try differently, and nothing bad will happen . In their view, the task is presented as a kind of global cloud, and the task of condensing it to concretize and isolate objects with which you can interact using the tools that they were given for this type of thinking is very difficult.
Unfortunately, the difficulty of this task is that the attempts to split and, thus, simplify the task, run into rejection as an accessible action. After all, in their thinking, if the abstraction is divided into two parts, you will still get an abstraction (and not two abstractions). In my practice, this was a critical moment in the formation of another type of thinking: if the student created another operation in his brain that says that these programmer abstractions are not like everyone, but are divisible, and they can and should be divided, then much easier.
Attempts to inculcate a reverse, step-by-step method of writing programs did not lead to success, since it goes against the methods of working with humanitarian disciplines. In addition, a great difficulty was encountered in yet another aspect: the integrity of the solution. It turned out to be very difficult for me to teach how to write down what the trainees have already invented, how to do it: if they invented it, then what is so complicated, why write down? I encountered the problem of a shortage of “RAM” of trainees rather quickly, and the need for the integrity of the invented solution appeared before me in all its glory. I was able to overcome this only by giving a strongly consistent increase in the ladder of the proposed solutions, then the method of implementing each step takes very little memory in the solution development process, and the tasks are successfully solved.
Question search entry point
This is one of the most difficult issues at the beginning of training.
First, because tasks must first be very strongly deterministic. There should not be allowed things with which I myself when stating tasks I sin quite strongly: the missing conditions are filled at the discretion of the student. For example, the input data input method. Such things must be strictly defined.
The key point for me was the fact that it is necessary to thoroughly tell how the extrapolation of the available data types to the abstractions with which they may have to work is done. That cell analogy is an object that stores parameters and other objects. That DNA can be considered as a set of elements, that is, reduced to an array. In this case, the main direction of explanation for those humanities who understand extrapolation well should be extrapolation of data types to types with which to work later in life, and for the rest - reduction of things to work with, to a certain fixed data type format and programming tools.
Secondly, a certain obligatory integrity of the solution comes to the head of the student again. It is necessary to emphasize that there is nothing shameful or bad to deal with certain problem areas later, when the rest of the solution is ready.The problem is to load an existing object into a data type (or drag a data type onto an existing object) - a frequently occurring problem, and the sooner trainees become familiar with object data types (structures), the easier it will be for them to later learn to put software terms and real-life terms into correspondence.
Thirdly, when the humanist thinks how he will solve the task, a frequent practice in their mind is to recreate “how would I start to solve such a task?” - and therefore, when you start writing a program, the very first question turns out to be “where is everything What did I just work with in my head? ”It is necessary to clearly and several times, with the introduction of each new type of data, explain where the data may appear in this variable / in this object and give examples of filling it with data. Then in the head of the humanities the answer will be born in the spirit of “since I was going to solve the problem through an array, the method of filling it is suitable here next ...” - and the writing of the program will go its own normal way.
In conclusion, I want to say that, although programming training is rather hard at first for people with a humanitarian mindset, in the future they begin to apply the methods that they tried in various combinations, even without cunning and beloved by many programmers, sophisticated sophistication, but quite confidently. And besides, they enjoy the realization that they had the opportunity to look into the world of unusual implications and transformations through the eyes of techies and thus gain new experience.
The content of the article is brief
And as a result, I’ve got a very short list of hints I’ve reached. Suddenly it will be useful to someone, if you urgently need to prepare.
- only non-math problems;
- the accuracy of the framework definitions in which programming methods and tools can be used;
- « » , , ;
- — , ;
- ;
- ;
- , , , - ;
- «» ().
Good luck to everyone who will do this. I hope this article will help and tell you something in this situation.
And I express my great appreciation to all my "test subjects".
PS If someone has found more ways to motivate the humanities to study this discipline well, I will be glad to hear.
Source: https://habr.com/ru/post/209284/
All Articles