O que é um software?

Algoritmos + Estrutura de Dados = Software

Social Made Easy

Facebook no futuro

Coders (ou seres codantes!)

About Coders (new version!)

A cor do horto gráfico

Testículo: Texto pequeno
Abismado: Sujeito que caiu de um abismo
Pressupor: Colocar preço em alguma coisa
Biscoito: Fazer sexo duas vezes
Coitado: Pessoa vítima de coito
Padrão: Padre muito alto
Estouro: Boi que sofreu operação de mudança de sexo
Democracia: Sistema de governo do inferno
Barracão: Proíbe a entrada de caninos
Homossexual: Sabão em pó para lavar as partes íntimas
Ministério: Aparelho de som de dimensões muito reduzidas
Detergente: Acto de prender seres humanos
Eficiência: Estudo das propriedades da letra F
Conversão: Conversa prolongada
Halogéneo: Forma de cumprimentar pessoas muito inteligentes
Expedidor: Mendigo que mudou de classe social
Luz solar: Sapato que emite luz por baixo
Cleptomaníaco: Mania por Eric Clapton
Tripulante: Especialista em salto triplo
Contribuir: Ir para algum lugar com vários índios
Aspirado: Carta de baralho completamente maluca
Assaltante: Um ‘A’ que salta
Determine: Prender a namorada do Mickey Mouse
Vidente: Aquilo que o dentista diz ao paciente
Barbicha: Bar frequentado por gays
Ortográfico: Horta feita com letras
Destilado: do lado contrário a esse
Pornográfico: O mesmo que colocar no desenho
Coordenada: Que não tem cor
Presidiário: Aquele que é preso diariamente
Ratificar: Tornar-se um rato
Violentamente: Viu com lentidão

Dinheiro é Dívida

Sustentabilidade

Eficiência e Sustentabilidade é un inimigo no atual sitema ecônomico, regido pelos mecanismos de obsolescência programada e percebida.

Alguns Algoritmos de Ordenação

import java.util.Date;

public class Algoritmos {

public static int[] insertionSort(int[] a) {

int i = 0;
int k = 0;

for (int j = 0; j < a.length; j++) { k = a[j]; i = j - 1; while (i >= 0 && a[i] > k) {
a[i + 1] = a[i];
i = i - 1;
a[i + 1] = k;
}

}

return a;
}

public static int[] bubbleSort(int[] a) {

for (int i = 0; i < a.length - 1; i++) { for (int j = 0; j < a.length -1 - i; i++) { if (a[j] > a[j + 1]) {
int k = a[j];
a[j] = a[j + 1];
a[j + 1] = k;
}

}

}

return a;
}

}

TZM

Um Pouco de Arte

The Humble Programmer

The Humble Programmer
by
Edsger W. Dijkstra

As a result of a long sequence of coincidences I entered the programming profession officially on the first spring morning of 1952 and as far as I have been able to trace, I was the first Dutchman to do so in my country. In retrospect the most amazing thing was the slowness with which, at least in my part of the world, the programming profession emerged, a slowness which is now hard to believe. But I am grateful for two vivid recollections from that period that establish that slowness beyond any doubt.

After having programmed for some three years, I had a discussion with A. van Wijngaarden, who was then my boss at the Mathematical Centre in Amsterdam, a discussion for which I shall remain grateful to him as long as I live. The point was that I was supposed to study theoretical physics at the University of Leiden simultaneously, and as I found the two activities harder and harder to combine, I had to make up my mind, either to stop programming and become a real, respectable theoretical physicist, or to carry my study of physics to a formal completion only, with a minimum of effort, and to become....., yes what? A programmer? But was that a respectable profession? For after all, what was programming? Where was the sound body of knowledge that could support it as an intellectually respectable discipline? I remember quite vividly how I envied my hardware colleagues, who, when asked about their professional competence, could at least point out that they knew everything about vacuum tubes, amplifiers and the rest, whereas I felt that, when faced with that question, I would stand empty-handed. Full of misgivings I knocked on van Wijngaarden's office door, asking him whether I could "speak to him for a moment"; when I left his office a number of hours later, I was another person. For after having listened to my problems patiently, he agreed that up till that moment there was not much of a programming discipline, but then he went on to explain quietly that automatic computers were here to stay, that we were just at the beginning and could not I be one of the persons called to make programming a respectable discipline in the years to come? This was a turning point in my life and I completed my study of physics formally as quickly as I could. One moral of the above story is, of course, that we must be very careful when we give advice to younger people; sometimes they follow it!

Another two years later, in 1957, I married and Dutch marriage rites require you to state your profession and I stated that I was a programmer. But the municipal authorities of the town of Amsterdam did not accept it on the grounds that there was no such profession. And, believe it or not, but under the heading "profession" my marriage act shows the ridiculous entry "theoretical physicist"!

So much for the slowness with which I saw the programming profession emerge in my own country. Since then I have seen more of the world, and it is my general impression that in other countries, apart from a possible shift of dates, the growth pattern has been very much the same.

Let me try to capture the situation in those old days in a little bit more detail, in the hope of getting a better understanding of the situation today. While we pursue our analysis, we shall see how many common misunderstandings about the true nature of the programming task can be traced back to that now distant past.

The first automatic electronic computers were all unique, single-copy machines and they were all to be found in an environment with the exciting flavour of an experimental laboratory. Once the vision of the automatic computer was there, its realisation was a tremendous challenge to the electronic technology then available, and one thing is certain: we cannot deny the courage of the groups that decided to try and build such a fantastic piece of equipment. For fantastic pieces of equipment they were: in retrospect one can only wonder that those first machines worked at all, at least sometimes. The overwhelming problem was to get and keep the machine in working order. The preoccupation with the physical aspects of automatic computing is still reflected in the names of the older scientific societies in the field, such as the Association for Computing Machinery or the British Computer Society, names in which explicit reference is made to the physical equipment.

What about the poor programmer? Well, to tell the honest truth: he was hardly noticed. For one thing, the first machines were so bulky that you could hardly move them and besides that, they required such extensive maintenance that it was quite natural that the place where people tried to use the machine was the same laboratory where the machine had been developed. Secondly, his somewhat invisible work was without any glamour: you could show the machine to visitors and that was several orders of magnitude more spectacular than some sheets of coding. But most important of all, the programmer himself had a very modest view of his own work: his work derived all its significance from the existence of that wonderful machine. Because that was a unique machine, he knew only too well that his programs had only local significance and also, because it was patently obvious that this machine would have a limited lifetime, he knew that very little of his work would have a lasting value. Finally, there is yet another circumstance that had a profound influence on the programmer's attitude to his work: on the one hand, besides being unreliable, his machine was usually too slow and its memory was usually too small, i.e. he was faced with a pinching shoe, while on the other hand its usually somewhat queer order code would cater for the most unexpected constructions. And in those days many a clever programmer derived an immense intellectual satisfaction from the cunning tricks by means of which he contrived to squeeze the impossible into the constraints of his equipment.

Two opinions about programming date from those days. I mention them now, I shall return to them later. The one opinion was that a really competent programmer should be puzzle-minded and very fond of clever tricks; the other opinon was that programming was nothing more than optimizing the efficiency of the computational process, in one direction or the other.

The latter opinion was the result of the frequent circumstance that, indeed, the available equipment was a painfully pinching shoe, and in those days one often encountered the naive expectation that, once more powerful machines were available, programming would no longer be a problem, for then the struggle to push the machine to its limits would no longer be necessary and that was all what programming was about, wasn't it? But in the next decades something completely different happened: more powerful machines became available, not just an order of magnitude more powerful, even several orders of magnitude more powerful. But instead of finding ourselves in the state of eternal bliss of all progamming problems solved, we found ourselves up to our necks in the software crisis! How come?

There is a minor cause: in one or two respects modern machinery is basically more difficult to handle than the old machinery. Firstly, we have got the I/O interrupts, occurring at unpredictable and irreproducible moments; compared with the old sequential machine that pretended to be a fully deterministic automaton, this has been a dramatic change and many a systems programmer's grey hair bears witness to the fact that we should not talk lightly about the logical problems created by that feature. Secondly, we have got machines equipped with multi-level stores, presenting us problems of management strategy that, in spite of the extensive literature on the subject, still remain rather elusive. So much for the added complication due to structural changes of the actual machines.

But I called this a minor cause; the major cause is... that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming had become an equally gigantic problem. In this sense the electronic industry has not solved a single problem, it has only created them, it has created the problem of using its products. To put it in another way: as the power of available machines grew by a factor of more than a thousand, society's ambition to apply these machines grew in proportion, and it was the poor programmer who found his job in this exploded field of tension between ends and means. The increased power of the hardware, together with the perhaps even more dramatic increase in its reliability, made solutions feasible that the programmer had not dared to dream about a few years before. And now, a few years later, he had to dream about them and, even worse, he had to transform such dreams into reality! Is it a wonder that we found ourselves in a software crisis? No, certainly not, and as you may guess, it was even predicted well in advance; but the trouble with minor prophets, of course, is that it is only five years later that you really know that they had been right.

Then, in the mid-sixties, something terrible happened: the computers of the so-called third generation made their appearance. The official literature tells us that their price/performance ratio has been one of the major design objectives. But if you take as "performance" the duty cycle of the machine's various components, little will prevent you from ending up with a design in which the major part of your performance goal is reached by internal housekeeping activities of doubtful necessity. And if your definition of price is the price to be paid for the hardware, little will prevent you from ending up wth a design that is terribly hard to program for: for instance the order code might be such as to enforce, either upon the progrmmer or upon the system, early binding decisions presenting conflicts that really cannot be resolved. And to a large extent these unpleasant possibilities seem to have become reality.

When these machines were announced and their functional specifications became known, quite a few among us must have become quite miserable; at least I was. It was only reasonable to expect that such machines would flood the computing community, and it was therefore all the more important that their design should be as sound as possible. But the design embodied such serious flaws that I felt that with a single stroke the progress of computing science had been retarded by at least ten years: it was then that I had the blackest week in the whole of my professional life. Perhaps the most saddening thing now is that, even after all those years of frustrating experience, still so many people honestly believe that some law of nature tells us that machines have to be that way. They silence their doubts by observing how many of these machines have been sold, and derive from that observation the false sense of security that, after all, the design cannot have been that bad. But upon closer inspection, that line of defense has the same convincing strength as the argument that cigarette smoking must be healthy because so many people do it.

It is in this connection that I regret that it is not customary for scientific journals in the computing area to publish reviews of newly announced computers in much the same way as we review scientific publications: to review machines would be at least as important. And here I have a confession to make: in the early sixties I wrote such a review with the intention of submitting it to the CACM, but in spite of the fact that the few colleagues to whom the text was sent for their advice, urged me all to do so, I did not dare to do it, fearing that the difficulties either for myself or for the editorial board would prove to be too great. This suppression was an act of cowardice on my side for which I blame myself more and more. The difficulties I foresaw were a consequence of the absence of generally accepted criteria, and although I was convinced of the validity of the criteria I had chosen to apply, I feared that my review would be refused or discarded as "a matter of personal taste". I still think that such reviews would be extremely useful and I am longing to see them appear, for their accepted appearance would be a sure sign of maturity of the computing community.

The reason that I have paid the above attention to the hardware scene is because I have the feeling that one of the most important aspects of any computing tool is its influence on the thinking habits of those that try to use it, and because I have reasons to believe that that influence is many times stronger than is commonly assumed. Let us now switch our attention to the software scene.

Here the diversity has been so large that I must confine myself to a few stepping stones. I am painfully aware of the arbitrariness of my choice and I beg you not to draw any conclusions with regard to my appreciation of the many efforts that will remain unmentioned.

In the beginning there was the EDSAC in Cambridge, England, and I think it quite impressive that right from the start the notion of a subroutine library played a central role in the design of that machine and of the way in which it should be used. It is now nearly 25 years later and the computing scene has changed dramatically, but the notion of basic software is still with us, and the notion of the closed subroutine is still one of the key concepts in programming. We should recognise the closed subroutines as one of the greatest software inventions; it has survived three generations of computers and it will survive a few more, because it caters for the implementation of one of our basic patterns of abstraction. Regrettably enough, its importance has been underestimated in the design of the third generation computers, in which the great number of explicitly named registers of the arithmetic unit implies a large overhead on the subroutine mechanism. But even that did not kill the concept of the subroutine, and we can only pray that the mutation won't prove to be hereditary.

The second major development on the software scene that I would like to mention is the birth of FORTRAN. At that time this was a project of great temerity and the people responsible for it deserve our great admiration. It would be absolutely unfair to blame them for shortcomings that only became apparent after a decade or so of extensive usage: groups with a successful look-ahead of ten years are quite rare! In retrospect we must rate FORTRAN as a successful coding technique, but with very few effective aids to conception, aids which are now so urgently needed that time has come to consider it out of date. The sooner we can forget that FORTRAN has ever existed, the better, for as a vehicle of thought it is no longer adequate: it wastes our brainpower, is too risky and therefore too expensive to use. FORTRAN's tragic fate has been its wide acceptance, mentally chaining thousands and thousands of programmers to our past mistakes. I pray daily that more of my fellow-programmers may find the means of freeing themselves from the curse of compatibility.

The third project I would not like to leave unmentioned is LISP, a fascinating enterprise of a completely different nature. With a few very basic principles at its foundation, it has shown a remarkable stability. Besides that, LISP has been the carrier for a considerable number of in a sense our most sophisticated computer applications. LISP has jokingly been described as "the most intelligent way to misuse a computer". I think that description a great compliment because it transmits the full flavour of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts.

The fourth project to be mentioned is ALGOL 60. While up to the present day FORTRAN programmers still tend to understand their programming language in terms of the specific implementation they are working with —hence the prevalence of octal and hexadecimal dumps—, while the definition of LISP is still a curious mixture of what the language means and how the mechanism works, the famous Report on the Algorithmic Language ALGOL 60 is the fruit of a genuine effort to carry abstraction a vital step further and to define a programming language in an implementation-independent way. One could argue that in this respect its authors have been so successful that they have created serious doubts as to whether it could be implemented at all! The report gloriously demonstrated the power of the formal method BNF, now fairly known as Backus-Naur-Form, and the power of carefully phrased English, a least when used by someone as brilliant as Peter Naur. I think that it is fair to say that only very few documents as short as this have had an equally profound influence on the computing community. The ease with which in later years the names ALGOL and ALGOL-like have been used, as an unprotected trade mark, to lend some of its glory to a number of sometimes hardly related younger projects, is a somewhat shocking compliment to its standing. The strength of BNF as a defining device is responsible for what I regard as one of the weaknesses of the language: an over-elaborate and not too systematic syntax could now be crammed into the confines of very few pages. With a device as powerful as BNF, the Report on the Algorithmic Language ALGOL 60 should have been much shorter. Besides that I am getting very doubtful about ALGOL 60's parameter mechanism: it allows the programmer so much combinatorial freedom, that its confident use requires a strong discipline from the programmer. Besides expensive to implement it seems dangerous to use.

Finally, although the subject is not a pleasant one, I must mention PL/1, a programming language for which the defining documentation is of a frightening size and complexity. Using PL/1 must be like flying a plane with 7000 buttons, switches and handles to manipulate in the cockpit. I absolutely fail to see how we can keep our growing programs firmly within our intellectual grip when by its sheer baroqueness the programming language —our basic tool, mind you!— already escapes our intellectual control. And if I have to describe the influence PL/1 can have on its users, the closest metaphor that comes to my mind is that of a drug. I remember from a symposium on higher level programming language a lecture given in defense of PL/1 by a man who described himself as one of its devoted users. But within a one-hour lecture in praise of PL/1. he managed to ask for the addition of about fifty new "features", little supposing that the main source of his problems could very well be that it contained already far too many "features". The speaker displayed all the depressing symptoms of addiction, reduced as he was to the state of mental stagnation in which he could only ask for more, more, more... When FORTRAN has been called an infantile disorder, full PL/1, with its growth characteristics of a dangerous tumor, could turn out to be a fatal disease.

So much for the past. But there is no point in making mistakes unless thereafter we are able to learn from them. As a matter of fact, I think that we have learned so much, that within a few years programming can be an activity vastly different from what it has been up till now, so different that we had better prepare ourselves for the shock. Let me sketch for you one of the posssible futures. At first sight, this vision of programming in perhaps already the near future may strike you as utterly fantastic. Let me therefore also add the considerations that might lead one to the conclusion that this vision could be a very real possibility.

The vision is that, well before the seventies have run to completion, we shall be able to design and implement the kind of systems that are now straining our programming ability, at the expense of only a few percent in man-years of what they cost us now, and that besides that, these systems will be virtually free of bugs. These two improvements go hand in hand. In the latter respect software seems to be different from many other products, where as a rule a higher quality implies a higher price. Those who want really reliable software will discover that they must find means of avoiding the majority of bugs to start with, and as a result the programming process will become cheaper. If you want more effective programmers, you will discover that they should not waste their time debugging, they should not introduce the bugs to start with. In other words: both goals point to the same change.

Such a drastic change in such a short period of time would be a revolution, and to all persons that base their expectations for the future on smooth extrapolation of the recent past —appealing to some unwritten laws of social and cultural inertia— the chance that this drastic change will take place must seem negligible. But we all know that sometimes revolutions do take place! And what are the chances for this one?

There seem to be three major conditions that must be fulfilled. The world at large must recognize the need for the change; secondly the economic need for it must be sufficiently strong; and, thirdly, the change must be technically feasible. Let me discuss these three conditions in the above order.

With respect to the recognition of the need for greater reliability of software, I expect no disagreement anymore. Only a few years ago this was different: to talk about a software crisis was blasphemy. The turning point was the Conference on Software Engineering in Garmisch, October 1968, a conference that created a sensation as there occured the first open admission of the software crisis. And by now it is generally recognized that the design of any large sophisticated system is going to be a very difficult job, and whenever one meets people responsible for such undertakings, one finds them very much concerned about the reliability issue, and rightly so. In short, our first condition seems to be satisfied.

Now for the economic need. Nowadays one often encounters the opinion that in the sixties programming has been an overpaid profession, and that in the coming years programmer salaries may be expected to go down. Usually this opinion is expressed in connection with the recession, but it could be a symptom of something different and quite healthy, viz. that perhaps the programmers of the past decade have not done so good a job as they should have done. Society is getting dissatisfied with the performance of programmers and of their products. But there is another factor of much greater weight. In the present situation it is quite usual that for a specific system, the price to be paid for the development of the software is of the same order of magnitude as the price of the hardware needed, and society more or less accepts that. But hardware manufacturers tell us that in the next decade hardware prices can be expected to drop with a factor of ten. If software development were to continue to be the same clumsy and expensive process as it is now, things would get completely out of balance. You cannot expect society to accept this, and therefore we must learn to program an order of magnitude more effectively. To put it in another way: as long as machines were the largest item on the budget, the programming profession could get away with its clumsy techniques, but that umbrella will fold rapidly. In short, also our second condition seems to be satisfied.

And now the third condition: is it technically feasible? I think it might and I shall give you six arguments in support of that opinion.

A study of program structure had revealed that programs —even alternative programs for the same task and with the same mathematical content— can differ tremendously in their intellectual manageability. A number of rules have been discovered, violation of which will either seriously impair or totally destroy the intellectual manageability of the program. These rules are of two kinds. Those of the first kind are easily imposed mechanically, viz. by a suitably chosen programming language. Examples are the exclusion of goto-statements and of procedures with more than one output parameter. For those of the second kind I at least —but that may be due to lack of competence on my side— see no way of imposing them mechanically, as it seems to need some sort of automatic theorem prover for which I have no existence proof. Therefore, for the time being and perhaps forever, the rules of the second kind present themselves as elements of discipline required from the programmer. Some of the rules I have in mind are so clear that they can be taught and that there never needs to be an argument as to whether a given program violates them or not. Examples are the requirements that no loop should be written down without providing a proof for termination nor without stating the relation whose invariance will not be destroyed by the execution of the repeatable statement.

I now suggest that we confine ourselves to the design and implementation of intellectually manageable programs. If someone fears that this restriction is so severe that we cannot live with it, I can reassure him: the class of intellectually manageable programs is still sufficiently rich to contain many very realistic programs for any problem capable of algorithmic solution. We must not forget that it is not our business to make programs, it is our business to design classes of computations that will display a desired behaviour. The suggestion of confining ourselves to intellectually manageable programs is the basis for the first two of my announced six arguments.

Argument one is that, as the programmer only needs to consider intellectually manageable programs, the alternatives he is choosing between are much, much easier to cope with.

Argument two is that, as soon as we have decided to restrict ourselves to the subset of the intellectually manageable programs, we have achieved, once and for all, a drastic reduction of the solution space to be considered. And this argument is distinct from argument one.

Argument three is based on the constructive approach to the problem of program correctness. Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer's burden. On the contrary: the programmer should let correctness proof and program grow hand in hand. Argument three is essentially based on the following observation. If one first asks oneself what the structure of a convincing proof would be and, having found this, then constructs a program satisfying this proof's requirements, then these correctness concerns turn out to be a very effective heuristic guidance. By definition this approach is only applicable when we restrict ourselves to intellectually manageable programs, but it provides us with effective means for finding a satisfactory one among these.

Argument four has to do with the way in which the amount of intellectual effort needed to design a program depends on the program length. It has been suggested that there is some kind of law of nature telling us that the amount of intellectual effort needed grows with the square of program length. But, thank goodness, no one has been able to prove this law. And this is because it need not be true. We all know that the only mental tool by means of which a very finite piece of reasoning can cover a myriad cases is called "abstraction"; as a result the effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer. In this connection it might be worth-while to point out that the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise. Of course I have tried to find a fundamental cause that would prevent our abstraction mechanisms from being sufficiently effective. But no matter how hard I tried, I did not find such a cause. As a result I tend to the assumption —up till now not disproved by experience— that by suitable application of our powers of abstraction, the intellectual effort needed to conceive or to understand a program need not grow more than proportional to program length. But a by-product of these investigations may be of much greater practical significance, and is, in fact, the basis of my fourth argument. The by-product was the identification of a number of patterns of abstraction that play a vital role in the whole process of composing programs. Enough is now known about these patterns of abstraction that you could devote a lecture to about each of them. What the familiarity and conscious knowledge of these patterns of abstraction imply dawned upon me when I realized that, had they been common knowledge fifteen years ago, the step from BNF to syntax-directed compilers, for instance, could have taken a few minutes instead of a few years. Therefore I present our recent knowledge of vital abstraction patterns as the fourth argument.

Now for the fifth argument. It has to do with the influence of the tool we are trying to use upon our own thinking habits. I observe a cultural tradition, which in all probability has its roots in the Renaissance, to ignore this influence, to regard the human mind as the supreme and autonomous master of its artefacts. But if I start to analyse the thinking habits of myself and of my fellow human beings, I come, whether I like it or not, to a completely different conclusion, viz. that the tools we are trying to use and the language or notation we are using to express or record our thoughts, are the major factors determining what we can think or express at all! The analysis of the influence that programming languages have on the thinking habits of its users, and the recognition that, by now, brainpower is by far our scarcest resource, they together give us a new collection of yardsticks for comparing the relative merits of various programming languages. The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. In the case of a well-known conversational programming language I have been told from various sides that as soon as a programming community is equipped with a terminal for it, a specific phenomenon occurs that even has a well-established name: it is called "the one-liners". It takes one of two different forms: one programmer places a one-line program on the desk of another and either he proudly tells what it does and adds the question "Can you code this in less symbols?" —as if this were of any conceptual relevance!— or he just asks "Guess what it does!". From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz. to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language. Another lesson we should have learned from the recent past is that the development of "richer" or "more powerful" programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. I see a great future for very systematic and very modest programming languages. When I say "modest", I mean that, for instance, not only ALGOL 60's "for clause", but even FORTRAN's "DO loop" may find themselves thrown out as being too baroque. I have run a a little programming experiment with really experienced volunteers, but something quite unintended and quite unexpected turned up. None of my volunteers found the obvious and most elegant solution. Upon closer analysis this turned out to have a common source: their notion of repetition was so tightly connected to the idea of an associated controlled variable to be stepped up, that they were mentally blocked from seeing the obvious. Their solutions were less efficient, needlessly hard to understand, and it took them a very long time to find them. It was a revealing, but also shocking experience for me. Finally, in one respect one hopes that tomorrow's programming languages will differ greatly from what we are used to now: to a much greater extent than hitherto they should invite us to reflect in the structure of what we write down all abstractions needed to cope conceptually with the complexity of what we are designing. So much for the greater adequacy of our future tools, which was the basis of the fifth argument.

As an aside I would like to insert a warning to those who identify the difficulty of the programming task with the struggle against the inadequacies of our current tools, because they might conclude that, once our tools will be much more adequate, programming will no longer be a problem. Programming will remain very difficult, because once we have freed ourselves from the circumstantial cumbersomeness, we will find ourselves free to tackle the problems that are now well beyond our programming capacity.

You can quarrel with my sixth argument, for it is not so easy to collect experimental evidence for its support, a fact that will not prevent me from believing in its validity. Up till now I have not mentioned the word "hierarchy", but I think that it is fair to say that this is a key concept for all systems embodying a nicely factored solution. I could even go one step further and make an article of faith out of it, viz. that the only problems we can really solve in a satisfactory manner are those that finally admit a nicely factored solution. At first sight this view of human limitations may strike you as a rather depressing view of our predicament, but I don't feel it that way, on the contrary! The best way to learn to live with our limitations is to know them. By the time that we are sufficiently modest to try factored solutions only, because the other efforts escape our intellectual grip, we shall do our utmost best to avoid all those interfaces impairing our ability to factor the system in a helpful way. And I cannot but expect that this will repeatedly lead to the discovery that an initially untractable problem can be factored after all. Anyone who has seen how the majority of the troubles of the compiling phase called "code generation" can be tracked down to funny properties of the order code, will know a simple example of the kind of things I have in mind. The wider applicability of nicely factored solutions is my sixth and last argument for the technical feasibiilty of the revolution that might take place in the current decade.

In principle I leave it to you to decide for yourself how much weight you are going to give to my considerations, knowing only too well that I can force no one else to share my beliefs. As each serious revolution, it will provoke violent opposition and one can ask oneself where to expect the conservative forces trying to counteract such a development. I don't expect them primarily in big business, not even in the computer business; I expect them rather in the educational institutions that provide today's training and in those conservative groups of computer users that think their old programs so important that they don't think it worth-while to rewrite and improve them. In this connection it is sad to observe that on many a university campus the choice of the central computing facility has too often been determined by the demands of a few established but expensive applications with a disregard of the question how many thousands of "small users" that are willing to write their own programs were going to suffer from this choice. Too often, for instance, high-energy physics seems to have blackmailed the scientific community with the price of its remaining experimental equipment. The easiest answer, of course, is a flat denial of the technical feasibility, but I am afraid that you need pretty strong arguments for that. No reassurance, alas, can be obtained from the remark that the intellectual ceiling of today's average programmer will prevent the revolution from taking place: with others programming so much more effectively, he is liable to be edged out of the picture anyway.

There may also be political impediments. Even if we know how to educate tomorrow's professional programmer, it is not certain that the society we are living in will allow us to do so. The first effect of teaching a methodology —rather than disseminating knowledge— is that of enhancing the capacities of the already capable, thus magnifying the difference in intelligence. In a society in which the educational system is used as an instrument for the establishment of a homogenized culture, in which the cream is prevented from rising to the top, the education of competent programmers could be politically impalatable.

Let me conclude. Automatic computers have now been with us for a quarter of a century. They have had a great impact on our society in their capacity of tools, but in that capacity their influence will be but a ripple on the surface of our culture, compared with the much more profound influence they will have in their capacity of intellectual challenge without precedent in the cultural history of mankind. Hierarchical systems seem to have the property that something considered as an undivided entity on one level, is considered as a composite object on the next lower level of greater detail; as a result the natural grain of space or time that is applicable at each level decreases by an order of magnitude when we shift our attention from one level to the next lower one. We understand walls in terms of bricks, bricks in terms of crystals, crystals in terms of molecules etc. As a result the number of levels that can be distinguished meaningfully in a hierarchical system is kind of proportional to the logarithm of the ratio between the largest and the smallest grain, and therefore, unless this ratio is very large, we cannot expect many levels. In computer programming our basic building block has an associated time grain of less than a microsecond, but our program may take hours of computation time. I do not know of any other technology covering a ratio of 10¹⁰ or more: the computer, by virtue of its fantastic speed, seems to be the first to provide us with an environment where highly hierarchical artefacts are both possible and necessary. This challenge, viz. the confrontation with the programming task, is so unique that this novel experience can teach us a lot about ourselves. It should deepen our understanding of the processes of design and creation, it should give us better control over the task of organizing our thoughts. If it did not do so, to my taste we should not deserve the computer at all!

It has already taught us a few lessons, and the one I have chosen to stress in this talk is the following. We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.

Fonte: http://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html

Novas ideias: 20 potenciais facilitadores.

Quando principalmente o CEO fala que é a favor da inovação, quem será contra mais inovação? De fato, ao longo dos últimos anos à medida que o tema inovação ganha destaque, percebo que são poucos aqueles nas organizações que se perguntam prá valer de onde virão as ideias de grande impacto.

Sendo assim, resolvi colocar aqui um pouco do que aprendi nestes últimos 20 anos estudando, trabalhando ou prestando consultoria em aspectos ligados à inovação. Segue abaixo uma lista sem nenhuma ordem ou hierarquia

O que facilita?

1. Contratar gente com formação diferente.
2. Estimular conversas relaxadas (isto é diferente de reuniões com power point).
3. Incentivar as pessoas a encontrarem outras pessoas de fora da empresa.
4. Embutir à gestão do conhecimento no dia a dia, na cultura e nos processos da organização.
5. Criar espaços de trabalho agradáveis. Oferecer bons cafés.
6. Dar liberdade para as pessoas se aprofundarem em áreas de seu interesse.
7. Contratar pessoas apaixonadas pelo que fazem.
8. Contratar pessoas com histórico de boas ideias e inovação.
9. Evitar a lógica massacrante dos analíticos. Analíticos ao extremo são bons para matar ideias nascentes e que ainda não podem virar um business case detalhado.
10. Visitar outras empresas, outros países.
11. Tirar férias.
12. Ler coisas diferentes. Visitar exposições, feiras, museus e outros lugares que congregam gente com ideias e produtos distintos.
13. Criar fóruns presenciais e virtuais frequentes para discussão de tendências emergentes
14. Alocar os principais talentos da empresa para trabalhar com inovação
15. Alta administração não apenas cobrando, mas participando e ajudando nos projetos menos óbvios, mas com grande potencial.
16. Colocar pessoas de diferentes gerações, diferentes níveis hierárquicos, diferentes departamentos e/ou diferentes países trabalhando juntos em um desafio ou oportunidade
17. Observar, observar e observar potenciais clientes ou consumidores. Ninguém gera insights ou inova só olhando para a tela do computador.
18. Abrir espaço e processos amigáveis para clientes, fornecedores, parceiros, etc trazerem ideias. Recompensá-los por isso, de preferência criando situações ganha-ganha.
19. Dar dinheiro de forma crescente para pesquisas, testes, protótipos, etc.
20. Aceitar erros calculados. Não aceitar desleixo.

 O que dificulta?

Fazer o oposto da lista acima

One In A Million

Guess I needed sometime to get away
I needed some piece of mind
Some piece of mind that'll stay
So I thumbed it down to Sixth and L.A.
Maybe a Greyhound could be my way

Police and Niggers, that's right
Get out of my way
Don't need to buy none of your
Gold chains today
I don't need no bracelets
Clamped in front of my back
Just need my ticket; 'til then
Won't you cut me some slack?

You're one in a million
Yeah, that's what you are
You're one in a million, babe
You're a shooting star
Maybe someday we'll see you
Before you make us cry
You know we tried to reach you
But you were much too high
Much too high, much too high,
Much too high, yes, ow!

Immigrants and faggots
They make no sense to me
They come to our country
And think they'll do as they please
Like start some mini Iran,
Or spread some fuckin' disease
They talk so many goddamn ways
It's all Greek to me

Well some say I'm lazy
And others say that's just me
Some say I'm crazy
I guess I'll always be
But it's been such a long time
Since I knew right from wrong
It's all the means to an end, I
I keep it movin' along

You're one in a million
Oo, you're a shooting star
You're one in a million, babe
You know that you are
Maybe someday we'll see you, Oo
oh, Before you make us cry
You know we tried to reach you
But you were much too high
Much too high, Oo, much too high
Yeah,
Much too high, huh, no, no, oh
Ow!

Radicals and Racists
Don't point your finger at me
I'm a small town white boy
Just tryin' to make ends meet
Don't need your religion
Don't watch that much T.V.
Just makin' my livin', baby
Well that's enough for me

You're one in a million
Yeah that's what you are
You're one in a million, babe
You're a shooting star
Maybe someday we'll see you
Before you make us cry
You know we tried to reach you
But you were much too high
Much too high, ow, much too high,
Much too high, much too high
Yeah, yeee, yeah, yeee, igh!
Ow! Much too high

(Oh, much too high, ah,
much too high, ah, much too high
much too high, ow, much too high)

Consumo de Água por Pessoa

Efeito Estufa

Concebendo Ideias

A velocidade da concepção de novas (originais, inesperadas,...) boas (úteis, apropriadas,...) ideias é o que define os profissionais de sucesso. Seja na indústria ou na academia, o pensamento criativo não só instiga novos produtos, como mantem o ambiente agradável e renovado (Por um Ócio mais Criativo). Na esfera social, a criatividade pode conduzir a novas descobertas científicas, novos movimentos de arte, novas invenções tecnológicas e novos paradigmais sociais. Indivíduos, organizações e sociedades devem adaptar os recursos existentes às novas demandas, a fim de manter-se competitivos comercialmente ¹ .
A metodologia que eu descreverei neste post pode ser apenas mais uma entre tantas, mas é a que mais se aproxima do meu feeling e aquela que, de certa forma, formalizou a minha estratégia. Ela foi montada pelo professor Ramesh Raskar no MIT há alguns anos e é usada frequentemente por seu grupo de trabalho.

As seis dimensões de Raskar (se lê Ráskar)

A metodologia assume a recém invenção, descoberta ou lançamento de um produto ou conceito X e questiona: o que vem após X? Qual o próximo passo? O que fazer agora, dado que X foi descoberto? X pode ser um produto, um artigo, uma patente, ou um conceito, próprio ou de terceiros, não importa.  
A existência de X representa uma nova oportunidade de negócios e inovação, pra quem for suficientemente criativo, claro. As seis dimensões de Raskar são seis maneiras de pensar em novas ideias e estão sumarizadas no hexagrama ao lado, onde cada um dos vértices representa uma dimensão conceitual a ser explorada:
X + Y : Fusão de X com Y;
- X : Inverter X e trabalhar na direção oposta;
X ^d : Aumentar os graus de liberdade;
X ↑ : Dado uma ferramenta, encontre as aplicações;
X ↓ : Dado uma aplicação / problema, encontre as ferramentas;
X + + : Adicionar um adjetivo a X, tornando-o melhor.

Z = X + Y  

A fusão conceitual ocorre quando dois produtos existentes X e Y, e de áreas distintas, são unidos para a criação de um terceiro produto Z. Quanto mais distintos forem X e Y, mais impactante é o resultado de Z e, portanto, mais valor comercial / acadêmico Z terá. Diferente de uma integração simples, a fusão entrelaça X e Y de uma forma que ajudem um ao outro. Por exemplo, unir um telefone celular com uma câmera digital no mesmo aparelho é integração. A câmera digital acessar um serviço na internet através da rede do celular, onde o serviço retorna a melhor configuração da câmera para o ambiente atual, é fusão. Da mesma forma, esta maneira de pensar pode unir diferentes campos de pesquisa e diferentes modelos de negócio em prol de algo novo.
Exemplos:  

• Integrar uma câmera WI-FI em um helicóptero e permitir o controle deste a partir do celular, cria uma nova forma de fotografar e filmar sem incomodar terceiros;
  
• Criar um algoritmo de page rank para twitters baseado em processamento de linguagem natural, criaria trending topics com classificação positiva e negativa em relação ao que os internautas falam sobre o tópico;
  
• Realidade aumentada é, por si só, uma área onde adiciona-se informações visuais a uma realidade comum, fundindo real e virtual.
  

Dado que se tenha X, liste os possíveis parceiros de X e as diferentes formas de fusão. Liste os dispositivos do futuro (possíveis Zs) e leia muitos livros de outras áreas de atuação. Lembre-se, pode ser uma ideia maluca no início, mas se ela desenvolver-se bem há uma grande chance de virar um produto de sucesso.

Z = - X

O oposto de X é normalmente difícil de ser imaginado em primeira instância. Por exemplo, o oposto direto de uma câmera digital é um projetor: o primeiro captura uma imagem do mundo e a armazena, enquanto que o segundo tem uma imagem armazenada e a projeta no mundo real. Dualidades como esta existem em muitos produtos e em técnicas, algoritmos e metodologias. Se um algoritmo é executado durante a captura, o inverso deste algoritmo pode ser usado na projeção.
Outra maneira de fazer o oposto é analisar o hype da indústria ou academia e seguir em uma direção diferente. Se todo mundo busca celulares com mais processamento, porque não lançar algo com menos processamento, mas com alguma característica a mais (iPhone)? Lembre-se muitas vezes, menos é melhor (SMS).
Exemplos:

• Até 2004 o poder computacional dos processadores aumentou exponencialmente (Moore's Law). A partir de 2004, as empresas seguiram uma linha diferente, onde o paralelismo é mais importante que o poder de processamento.
  
• Quando o mundo caminhava para a integração total em um único dispositivo móvel, a Amazon lançou o Kindle, um dispositivo específico para leitura e só.
  
• Apesar de todos os esforços dos cientistas e engenheiros para criar o video phone, a moda não pegou. Ao invés disso, muitos usuários preferiram abandonar a voz e voltar ao texto (SMS).
  
• Ao invés de usar um dispositivo engenhoso para colocar tags em suas imagens, o Google desenvolveu um jogo onde você compete com outra pessoa para descobrir quem adiciona mais tags em uma única imagem.
  
• Em sistemas de motion tracking, o ator sempre possui marcas no corpo para facilitar o rastreamento das câmeras posicionadas ao seu redor. O que acontece quando ao invés de marcas, colocamos as câmeras no corpo do ator?  
  
• Ao invés de criar a camera digital com a melhor qualidade de imagem do planeta, porque não criar uma câmera digital que captura caricaturas/desenhos?
  

Assim como a dimensão anterior, o objetivo é surpreender. Nadar contra a maré. Apesar desta linha ser difícil de acontecer sem que a pessoa tenha ciência que ela existe, com o passar do tempo, o raciocínio por produtos inversos acaba virando frequente, e você se acostuma a pensar desta forma em todas as empreitadas.
Dica de leitura “ Why Not? ”, de Barry Nalebuff e Ian Ayres

Z = X ^d

Aumentar a dimensionalidade do problema é uma técnica clássica da pesquisa científica. Se você tem um algoritmo baseado em imagens (2D), a extensão dele para vídeos (3D) gera um novo produto ou, neste caso, artigo. Esta linha de pensamento de fato generaliza produtos. Ao adicionar uma dimensão, o produto atende a uma classe maior de problemas, incluindo a inicial.
Exemplos:

• Se X é um modelo de física óptica, pode-se adaptar X para suportar qualquer onda eletromagnética: som, raios-x, etc (link ainda não disponível).

• Se X é um iPod, Z pode ser o suporte a vídeos, jogos ou aplicações médicas no aparelho. Cada um destes grupos de aplicações é uma nova dimensão.
  
• Se X é o Google Maps, pontos turísticos e comerciais, informações de tráfico e o street view são 3 novas dimensões.
  

A dica aqui é listar todas as dimensões do problema em questão e mapear o que já foi feito para cada uma delas. Lembre-se que as dimensões extras podem ser ortogonais ou não e que adicionar dimensão é diferente de apenas incrementar X. Novas dimensões permitem criar um produto cartesiano de todas as possibilidades.

Z = X ↓

Dado um prego, encontre o melhor martelo. Dado um aplicação ou problema, busque as técnicas que possam resolvê-lo. É muito provável que as técnicas usadas para criar X não sejam as únicas disponíveis. Explore outras possibilidades de produzir X. Técnicas mais baratas, mais limpas ou rápidas que a usada atualmente. Mesmo que a solução não seja a melhor, em casos de patentes, por exemplo, ela te permitirá criar produtos competitivos a X sem pagar royalties. A academia é campeã nesta abordagem. Para todo o problema existe mais de uma solução publicada onde o resultado é semelhante mas produzido com técnicas diferentes.
Exemplos:

• Para ajustes de cor em fotografias, as técnicas variam desde ajuste de brilho e contraste até métodos que buscam imagens semelhantes na internet para recolorir a imagem atual.
  
• Soluções de mobilidade com a família vão desde motocicletas a caminhões trailer.
  
• Solução para sistemas operacionais existem desde gratuitas até bem caras.
  

Buscar novas ferramentas nem sempre é simples, demanda muito estudo e felling em áreas desconhecidas. Mantenha-se informado sobre os novos lançamentos de áreas que para você se transformam em ferramentas.

Z = X ↑

Dado um martelo, encontre os pregos. O inverso da estratégia anterior. Dado que você possui X, considere X uma ferramenta e procure uma aplicação para X, onde o resultado possa ser alcançado de forma mais eficiente que a atual. Aplicar X em outras áreas é algo que artistas adoram fazer. Use X para atender uma demanda que ninguém nunca pensou. Crie um problema que antes não existia ou não era percebido.
Exemplos:

• A Apple lançou o iPad (Z), que é um iPod Touch (X) com foco em outro público.
  
• Produtores de gado usam música clássica para acalmar os animais durante o abate, produzindo carnes mais macias. Aposto que a indústria de CDs nunca imaginou esse propósito.
  
• Diana Domingues da Universidade Caxias do Sul colocou um robô cobra com uma webcam no meio de um covil de cobras. As pessoas experimentam a convivência com as cobras através de head mounted displays.
  

Se X for uma ferramenta, mostre e disponibilize a ferramenta para outras áreas de pesquisa. Se X for proveniente de outra área, tente encaixá-lo em uma de suas expertises. Uma lista de problemas da área é sempre importante nestas horas.

Z = X + + ou Z = adjetivo + X

Esta é a dimensão mais comum encontrada. Dado X, basta alterar X em busca de melhorias adicionando adjetivos. Mais rápido, mais barato, mais limpo, mais leve, menor, maior, mais qualidade, mais informação. Procure e liste as palavras-chave da área, exemplo: temporalmente coerente, hierárquico, adaptativo, paralelizado, distribuído, real-time, contextual, etc.
Exemplos:

• O artigo Interactive Rendering of Suggestive Contours with Temporal Coherence resolve o problema antigo de Rendering de Suggestive Contours, que foi uma vez melhorado em uma versão interativa que, neste artigo, ganhou coerência temporal,
  
• O artigo Adaptive marching cubes nada mais é do que o original Marching Cubes em uma versão adaptativa.
  

A dica para esta dimensão é explorar as assunções e limitações do problema e da técnica. No entanto, antes de começar verifique a quantidade de palavras chave publicadas para o X em questão. Se já há muitas palavras-chave, a nova abordagem a não chamará muita atenção.

Armadilhas

As seis dimensões não são as únicas e cada uma delas tem seus riscos. A metodologia foi criada para ser um treinamento mental, não para ser a resposta definitiva para o pensamento criativo.
Lembre-se que uma ideia raramente é desenvolvida em uma única parte do planeta. As pessoas tem ideias semelhantes ao mesmo tempo. Coloca o nome na história aquela que implementar a ideia primeiro.
Procure sempre fundir coisas distintas. Evite trabalhos que revelam-se um mero pipeline de técnicas, sem qualquer integração entre elas. Não siga o hype, há muita competição e os prêmios não são bons. Ao invés, crie o novo hype.
Pensar diferente nem sempre é inovar. Afinal, todos nós pensamos de maneira diferente uns dos outros. Abordagens diferentes, também não são sinônimos de abordagens melhores. No entanto, o exercício de pensar diferente, a longo prazo, sempre traz benefícios.
Cuidado com os desafios. Escalar uma montanha é um desafio tremendo, pode até te trazer um sentimento de satisfação ao cumprir o objetivo, mas somente os primeiros que chegaram lá serão lembrados. Os outros, trabalharam a toa.

Dicas comuns:  

Think outside the box é uma conhecida expressão que instiga os inventores a pensar diferente, em um novo contexto, uma nova perspectiva. Se você é o autor principal do trabalho, ou está envolvido demais no processo, é provável que você esteja dentro de uma caixa preta, sem saída ou de um labirinto, complexo demais para sair. Converse com seus colegas, pois eles estarão te observando de cima, numa visão privilegiada, e podem te dar sugestões dos caminhos corretos a seguir.
Certo dia Cristóvão Colombo, depois de ouvir que descobrir as Américas não tinha sido um feito muito importante, desafiou seus críticos a fazer com que um ovo de galinha ficasse em pé (com o lado gordinho pra baixo e a ponta pra cima) sobre uma superfície plana por 5 minutos sem usar nenhum outro objeto. Após a desistência de seus críticos, Cristóvão pegou o ovo e bateu levemente na mesa, quebrando a parte de baixo, mas fazendo-a ficar plana. O ovo, apesar de quebrado, ficou em pé. Dica: nem sempre as restrições que não foram escritas de fato existem.
Keep it simple, stupid (KISS) é uma frequente expressão da área de desenvolvimento de software. Quando uma ideia é complicada demais ou muito complexa, dificilmente será utilizada por alguém além do inventor. Uma invenção de sucesso não é só nova e brilhante, também deve ser simples de reproduzir. Lembrem-se, as melhores ideias são muito mais simples do que o processo de colocá-las em um museu.

Liderança  

As seis dimensões de Raskar também podem ser aplicadas a pessoas, conduzindo-as a inovação:
X + Y : Una pessoas com backgrounds completamente diferentes. Faça-as trabalhar no mesmo projeto.
X ↑ : Aplique pessoas em outras áreas. Envie seus profissionais para outros setores ou para estágios em outras faculdades / empresas. Vivenciando uma outra realidade, além de tirar férias da realidade atual, elas voltam cheias de novas ideias.
X ↓ : Permita que as pessoas explorem diferentes ferramentas de trabalho. Ter um hall de ferramentas a disposição aumenta a performance e a disposição dos funcionários.
- X : Contrate os opostos. Diversidade e discussão são sempre positivos.
X ^d : Mantenha pessoas trabalhando em paralelo em mais de um projeto.
X + + : Instigue a participação em cursos e palestras da área.

Descoberta vs Invenção

Invenção é aquilo que se pode planejar, pensar muito a respeito e ainda não ter a resposta. É um problema comum e conhecido que os pesquisadores tentam resolver. Exemplo: Muitos homens gastaram suas vidas pesquisando formas de criar o avião. O mesmo acontece hoje com a cura da AIDS e o do Câncer.
Descoberta é algo que acontece quase que por acaso. Ao trabalhar num projeto, acaba-se identificando outros problemas e soluções. Em uma descoberta, a solução é, na verdade, descobrir o problema. Assim que o problema é descoberto, a solução já existe. Exemplo: Colombo descobriu as Américas quando tentava criar uma nova roda para a Índia. Duvido que alguém planejou a invenção do fogo, ou a invenção da roda.
Desta forma, uma das técnicas de inovação é incitar a descoberta por meio de um trabalho inventivo relacionado. O processo inventivo pode ser visto como um trabalho de engenharia, por exemplo, construir o Large Hadron Collider. Durante a construção, vários problemas ocorreram e várias descobertas aconteceram. Incitar o processo inventivo é uma das melhores formas de inovar, e é a principal técnica usada no MIT.  

Exercício

Dado que X é a teoria das dimensões de Raskar, derive as novas possibilidades de teorias.  

Fonte: http://vitorpamplona.com/lastChanges.pr?page=2

Um Pouco de Arte!

Um Pouco de Arte!

TABELA PRICE: JUROS SIMPLES OU COMPOSTOS?

1. Introdução
Estabeleceu-se no sistema jurídico nacional uma polêmica entre os operadores de direito sobre uma questão que tem sido objeto de muitas demandas. Trata-se da discussão da validade, da legalidade de utilização da Tabela Price ou Sistema de Amortização Francês para diversos tipos de operações de crédito ou de arrendamento mercantil (Leasing) a serem liquidados por uma série de pagamentos iguais e sucessivos.

O argumento principal nessas ações é de que a Tabela Price contempla juros compostos, juros sobre juros, o que seria vedado por lei, já que só se admite a capitalização composta de juros em operações financeiras para as quais haja lei autorizativa e que conste expressamente do contrato a previsão de aplicação de juros compostos. O assunto se tornou mais tormentoso ainda, pois até entre peritos ocorre dissenso, uns interpretando que ocorre a aplicação de juros sobre juros e outros entendendo que não. Nos propomos, no decorrer deste trabalho, tentar desmistificar a questão, contribuindo para que se aclare o entendimento da matéria.

2. O que é o Sistema Francês de Amortização
Segundo o Prof. Mário Geraldo Pereira, em sua dissertação de Doutoramento na USP, este sistema de amortização foi criado no século XVIII pelo filósofo, teólogo e matemático inglês Richard Price, incorporando a teoria de juros compostos nos empréstimos de pagamentos iguais e sucessivos. Segundo este mesmo estudioso a denominação “Tabela Price” é utilizada somente no Brasil, visto que em outros países é conhecido por “Sistema Francês de Amortização, devido ao fato de ter se desenvolvido efetivamente na França, no século XIX.

A Tabela Price nada mais é que uma tábua de fatores através dos quais se pode calcular, mediante simples operações matemáticas de multiplicação, o valor da prestação, assim como o valor de cada parcela de juros e amortização e o saldo devedor (estado da dívida) a qualquer momento durante a evolução da série de pagamentos.

Convém deixar claro que os fatores embutem, quando do cálculo do valor da prestação inicial, os juros contratados, com o critério de capitalização composta. Já quanto à correção monetária, geralmente há a previsão de um indexador a ser aplicado para a preservação do poder aquisitivo da moeda.

3. Contexto histórico da criação da "Tabela Price"
Importante ainda salientar que na época em que foi criada a Tabela Price, no século XVIII, não existiam nem mesmo calculadoras, sendo os cálculos realizados por instrumentos rudimentares que não permitiriam o cálculo exponencial dos juros compostos. Esta tábua de fatores chamada Tabela Price veio possibilitar que os cálculos fossem feitos com simples operações matemáticas, adequadas aos instrumentos disponíveis à época, caso contrário seriam necessárias calculadoras financeiras que não existiam àquele tempo.

Para melhor ilustrar a dificuldade do homem médio de se elaborar cálculos financeiros, em 1971, quando cursávamos o primeiro ano de Engenharia na UFMG, somente dois alunos em nossa classe possuíam calculadoras manuais. Todos os outros alunos se utilizavam da régua de cálculo para fazer todos os cálculos, desde os mais simples até os mais complexos. Nesta ocasião já havia o curso de programação Fortran na Escola de Engenharia, mas o computador era único, situado na Reitoria da UFMG, funcionava a cartões perfurados e ocupava parte apreciável da enorme sala onde se localizava.

Com a elaboração da Tabela Price de fatores para diferentes situações de taxas e de prazos possibilitou-se ao leigo o acesso à evolução de sua operação de crédito ou arrendamento mercantil. Em 1970 o Prof. Abelardo de Lima Puccini publicou um livro intitulado “Tabela Price – Impressa em Computador”, onde apresentou fatores para taxas de juros variando de 5% a 36% ao ano e prazos de financiamento de um a vinte anos. Até então e ainda por algum tempo consultava-se na Tabela Price os fatores necessários para se fazer os cálculos de financiamentos ou arrendamento mercantil neste sistema. Com a grande disponibilidade, a custos acessíveis, de calculadoras financeiras e computadores pessoais, deixou-se de consultar os referidos fatores e passou-se a usar estes equipamentos, onde se entra com os parâmetros necessários e se obtém imediatamente os valores procurados.

4. Outros sistemas de amortização
No decorrer deste trabalho nos referiremos sempre ao Sistema Francês de Amortização, ou Tabela Price, que é um sistema de prestações constantes, convencionando-se que com a ocorrência de pagamentos e deduzindo-se os juros sobre o saldo devedor, a diferença entre estes e o valor fixo da parcela é lançado a título de amortização. Há entretanto outros sistemas de financiamento, quais sejam:

          SAC – Sistema de Amortizações Constantes
          SAM – Sistema de Amortizações Misto (Média aritmética de Price + SAC)
          SACRE – Sistema de Amortizações Crescentes

Estes sistemas, apesar de distintos na forma da distribuição dos juros e da amortização ao longo do financiamento, são todos baseados em capitalização composta, configurando também o anatocismo, como ocorre com a Tabela Price. Por isto quando nos referimos à Tabela Price no decorrer deste trabalho estamos nos referindo a todos estes sistemas de amortização.

5. Capitalização simples ou composta?
Várias argumentações são colocadas contra a interpretação de que a Tabela Price contempla capitalização composta, juros sobre juros, anatocismo. Abordaremos a seguir cada uma dessas motivações, com o intuito de alcançarmos uma visão clara e definitiva da matéria sob exame.

    5.1 Mercado x Sistema Jurídico
   Argumenta-se que não é razoável guerrear a Tabela Price, visto que é um sistema mundialmente utilizado e que a utilização de juros compostos é comum no mercado financeiro, que seria um absurdo tentar mudar todo o cálculo de juros no sistema financeiro para juros simples. Alega-se, ainda, que se os juros no mercado financeiro passarem a ser simples isto certamente vai causar reflexo no aumento das taxas de juros, de tal forma a preservar o lucro líquido dos agentes financeiros. Nesta linha de abordagem reputa-se como mais importante o vulto da taxa de juros aplicada e não se são simples ou compostos.

Primeiramente há que se ressaltar que o mercado pode sim influenciar os procedimentos nas operações financeiras, mas somente através de Lei. Entenda-se, portanto, que enquanto uma Lei estiver em vigor, mesmo que contrarie toda a prática do mercado e o bom senso, esta lei tem que ser cumprida, sob pena de não ser possível manter a ordem jurídica no País.

Para a manutenção do Estado de Direito é preciso que as regras sejam claras e sejam cumpridas, pois do contrário se instalaria a anarquia. Se as leis não foram mudadas, o sistema financeiro tem que se adequar a elas, mesmo que com reflexo no aumento das taxas nominais de juros, os quais, aliás, são livremente estipulados pelas instituições financeiras.

Examinando-se no sentido contrário, poderíamos concluir que se o sistema adotado fosse o de juros simples e depois a lei mudasse para juros compostos, seria de se esperar que houvesse a respectiva redução nas taxas nominais. Insistimos mais uma vez: É necessário que as regras sejam claras e respeitadas, o que não significa que elas não possam ser mudadas, através de leis que o façam.

    5.2 Juros sobre saldo devedor não implicam em juros sobre juros.
    Nesta linha de abordagem os defensores da tese de que não se contempla juros compostos na Tabela Price alegam que neste sistema os juros são lançados mês a mês sobre o saldo devedor e que a diferença entre o pagamento e os juros é lançada como amortização, não ocorrendo a incidência de juros sobre juros.

Ora, os juros são lançados a débito mensal na planilha financeira da operação de crédito apenas através de convenção utilizada pelo criador do sistema.
Convencionou-se que a cada mês são calculados os juros e só a diferença pode ser lançada a título de amortização do principal. Na linguagem da matemática financeira, entretanto, esta convenção é absolutamente irrelevante, pois dento dos princípios matemáticos só faz sentido raciocinar em termos de um valor presente que é obtido numa data zero e cujos pagamentos são feitos sucessivamente através de várias parcelas futuras.

     5.3 Critério universal: Fluxo de caixa descontado
    A única forma de se aferir os efeitos financeiros na operação de crédito ou arrendamento mercantil é trazer todos os pagamentos a valor presente, utilizar-se o que se chama “fluxo de caixa descontado”. Como premissa da matemática financeira só interessa que foi transferida uma importância numa data inicial e são feitos vários pagamentos para retornar o capital, não interessando se a título de juros ou de amortização. Como os juros são frutos do capital, são tratados na mesma unidade do capital e não faz a menor diferença de como se convencionou lançá-los contabilmente.

Há que se frisar que em todas as operações de crédito e arrendamento mercantil de prazo de pagamento sucessivo de dois meses ou mais, em havendo lançamento mensal de juros ocorre a incidência de juros sobre juros, ou seja, o simples fato de que os juros incidem sobre o saldo devedor não significa que são juros simples.

    5.4 Os juros compostos são utilizados no cálculo da prestação, a planilha de evolução do financiamento apenas os confirma
É muito importante ressaltar, outrossim, que a aplicação da fórmula da Tabela Price para o cálculo da prestação já insere imediatamente em si os efeitos da capitalização composta na operação. A tentativa de se deslocar a discussão para o sistema de amortização, de como são lançados juros e amortização do principal é, via de conseqüência, totalmente inócua, pois o efeito da capitalização composta já se faz presente quando se utiliza a fórmula abaixo e se calcula o valor da prestação:

          R = P x [ i (1 + i)ⁿ ] ÷ [ (1 + i )ⁿ -1]

       Onde:
       R = Prestação
       P = Principal
       i  = Taxa
       n = Número de parcelas

A alegação de alguns de que a divisão de uma expressão exponencial por outra expressão exponencial suprimiria os efeitos da capitalização composta é uma aberração matemática que nem merece comentários.

Argumenta-se também que tomando-se apenas uma parcela de pagamento no sistema Price constata-se que os juros são simples. A afirmação é destituída de fundamento, pois como se trata de um sistema de financiamento, não se concebe matematicamente que seja comparado apenas um mês, há que se considerar todo o sistema em seu contexto geral e não em partes visto que a capitalização composta só se configura para um número de parcelas maior que um.

     5.5 Argumentações sob o ponto de vista contábil
    Outras motivações para atacar a hipótese dos juros compostos na Tabela Price abordam a Teoria Geral do Conhecimento Contábil e a correta interpretação da origem do fenômeno patrimonial. Nesta linha de trabalho considera-se cada parcela de pagamento isoladamente, sem a análise do sistema em seu contexto geral, o que não é permitido, conforme expusemos no final do item anterior. Obviamente que as empresas obrigadas a elaborar demonstrações contábeis têm que apropriar separadamente os valores a título de juros e a título de amortização do principal.

A intenção do legislador e a função jurisdicional do Judiciário, porém, é a análise em termos financeiros e não contábeis, abrangendo tanto empresas como pessoas físicas. Como já afirmamos linhas atrás a matemática financeira analisa todas as operações como um fluxo de caixa descontado, onde se transfere uma quantia inicialmente, a qual retorna através de vários pagamentos. Não importa, para os efeitos que a Lei intenta prevenir, o valor individual dos juros e da amortização, mas sim os efetivos pagamentos realizados que, levados a valor presente, serão confrontados com o principal, aferindo os demais parâmetros da operação.

     5.6 Juros sobre juros e capitalização composta não se confundem
    Há alegações de que os juros sobre juros não são a mesma coisa que capitalização composta, pois se os juros foram vencidos e não pagos incorporam-se ao capital, desaparecendo a figura dos juros sobre juros. Este argumento procede nos casos em que o vencimento dos juros ocorre em períodos menores que o período da operação de crédito. Mas o sistema Price tem a abordagem muito mais ampla e diferenciada.

É um sistema que tem por objetivo determinar prestações iguais e sucessivas para retornar um capital cedido, não se falando de vencimento de juros durante o financiamento, mas apenas da forma de apropriá-los contabilmente.

     5.7 Há a capitalização composta, mas não juros sobre juros ou anatocismo
    Esta argumentação também falece de fundamento, tendo em vista que a matemática financeira, através de conceitos e fórmulas, só admite duas formas de aplicação de juros: simples ou compostos. Se não são simples, só podem ser compostos. Pela simples utilização da fórmula já se embutem os juros compostos nas prestações a serem pagas. Matematicamente só se consegue retornar o mesmo capital, no Sistema Francês de Amortização,  se as prestações forem retornadas a valor presente pela fórmula de juros compostos.

Ademais, entendemos que a intenção do legislador foi de fixar o critério de juros simples, vedando qualquer outra forma mais onerosa. Em pesquisa bibliográfica que realizamos só encontramos textos que identificam entre si, e não diferenciam, os efeitos de capitalização composta, juros sobre juros e anatocismo.

6. Conclusão
Esgotam-se, portanto, todas as tentativas de contestar o óbvio: A Tabela Price contempla juros compostos, ou seja, juros sobre juros, configurando o anatocismo. A melhor forma de se testar esta assertiva é fazer o fluxo de caixa descontado retornando a valor presente todas as parcelas pela fórmula de juros compostos, chegando-se, assim, ao valor da operação de crédito. Se, ao contrário, for utilizada a fórmula de juros simples para retornar as prestações a valor presente, chegar-se-á a um valor que não coincide com o valor do principal da operação.

Comparação Price x SAC

Vamos fazer a comparação de um financiamento com as seguintes características:

• Valor do financiamento: R$ 50.000,00
• Período do financiamento: 50 meses
• Taxa de juros do financiamento: 1% ao mês

Colocando lado a lado os gráficos para os dois sistemas:

Financiamento Price		Financiamento SAC

Financiamento Price		Financiamento SAC
Valor da parcela: Total de Juros: Total Pago:	R$ 1.275,64 R$ 13.781,77 R$ 63.781,77	Valor da parcela 01: Valor da parcela 50: Total de Juros: Total Pago:	R$ 1.500,00 R$ 1.010,00 R$ 12.750,00 R$ 62.750,00

Falácias Lógicas

As falácias lógicas são erros de raciocínio ou de argumentação, erros que podem ser reconhecidos e corrigidos por pensadores prudentes. Este ensaio lista e descreve todas as falácias lógicas conhecidas. O ponto central de um argumento é expor razões que sirvam de suporte para alguma conclusão. Um argumento comete uma falácia quando as razões apresentadas, de fato, não sustentam a conclusão.

Lista de Falácias

Falácias de Dispersão
      Falso Dilema: são dadas duas alternativas quando de fato há três ou mais
      Apelo à Ignorância: conclui-se que uma proposição é falsa (ou verdadeira) porque não se sabe se é verdadeira (ou falsa)
      Declive Escorregadio: conseqüências cada vez mais inaceitáveis são derivadas em série
      Pergunta Complexa: duas proposições são ligadas no que aparenta ser uma só pergunta.

Apelo a Motivos em Vez de Razões
      Apelo à Força: o ouvinte é persuadido a concordar pela força
      Apelo à Piedade: apela-se à compaixão ou simpatia do ouvinte
      Conseqüências: o ouvinte é prevenido contra conseqüências inaceitáveis
      Linguagem Preconceituosa: associam-se valores morais positivos à causa defendida pelo autor
      Apelo ao Povo: defende-se que uma proposição é verdadeira porque segundo a maioria da população ela é verdadeira

Fugir do Assunto
      Ataques Pessoais:
            (1) ataque ao caráter da pessoa
            (2) referem-se circunstâncias relativas à pessoa
            (3) invoca-se o fato da pessoa não praticar o que diz

      Apelo à Autoridade:
            (1) a autoridade não é um perito no campo em questão
            (2) não há acordo entre os peritos do campo em questão
            (3) a autoridade não pode, por algum motivo ser levada a sério - porque estava brincando, estava bêbada, etc.

      Autoridade Anônima: a autoridade em questão não é declarada
      Estilo Sem Substância: sente-se que o modo como o argumento (ou o argumentador) é apresentado afeta a verdade da conclusão

Falácias Indutivas
      Generalização Precipitada: a amostra é demasiado pequena para apoiar uma generalização indutiva sobre o domínio em questão
      Amostra Não Representativa: a amostra não é representativa do domínio em questão
      Falsa Analogia: desprezam-se diferenças relevantes entre os objetos ou acontecimentos comparados
      Indução Preguiçosa: nega-se, apesar dos indícios favoráveis, a conclusão de um forte argumento indutivo
      Falácia de Omissão: não é considerada toda a informação relevante que devia pesar na conclusão de um forte argumento indutivo

Falácias Envolvendo Silogismos Estatísticos
      Acidente: uma generalização é feita quando as circunstâncias sugerem que deve haver exceções
      Inversa do Acidente : generaliza-se o que apenas devia ser tomado como exceção

Falácias Causais
      Post Hoc: pelo fato de algo acontecer após outra coisa pensa-se que a coisa causa a algo em questão
      Efeito Conjunto: conclui-se que uma coisa é causa de outra coisa quando, de fato, ambas as coisas são o efeito conjunto de uma causa subjacente
      Insignificância: conclui-se que uam coisa é causa de algo, mas apesar de também o ser, é insignificante quando comparada com outras causas deste algo
      Direção Errada ou Contramão: a relação entre causa e efeito é invertida
      Causa Complexa: a causa identificada é apenas uma parte da totalidade da causa do efeito

Errando o Alvo
      Petição de Princípio: a verdade da conclusão já estava presumida nas premissas
      Conclusão Irrelevante: um argumento apresentado para defender uma conclusão prova, em vez disso, outra conclusão
      Espantalho: o autor ataca um argumento diferente (e/ou mais fraco) do que o melhor argumento do opositor

Falácias da Ambiguidade
      Equívoco: o mesmo termo é usado em dois sentidos diferentes
      Anfibologia: a estrutura de uma frase permite duas interpretações diferentes
      Ênfase: a ênfase numa palavra sugere um sentido diferente daquele que de fato é enunciado

Erros de Categorização
      Composição: como os atributos das partes de um todo têm certa propriedade, argumenta-se que o todo tem esta propriedade
      Divisão: como o todo tem uma certa propriedade, argumenta-se que as partes têm essa propriedade

Non Sequitur
      Afirmação do Conseqüente: qualquer argumento na seguinte forma: Se A então B, B, portanto A
      Negação do Antecedente: qualquer argumento na seguinte forma: Se A então B, Não A, portanto Não B
      Inconsistência: o argumentador usa premissas que não podem ser simultaneamente verdadeiras

Erros Silogísticos
      Falácia dos Quatro Termos: um silogismo possui quatro termos
      Meio Não Distrubuido: diz-se que duas categorias separadas estão ligadas porque elas compartilham uma propriedade em comum
      Ilícito Maior: o predicado da conclusão fala sobre a totalidade de algo mas as premissas mencionam apenas alguns casos do termo no predicado
      Ilícito Menor: o sujeito da conclusão fala sobre a totalidade de algo mas as premissas mencionam apenas alguns casos do termo no sujeito
      Falácia de Premissas Exclusivas: um silogismo possui duas premissas negativas
      Falácia de Criar uma Conclusão Afirmativa de uma Premissa Negativa: como o nome já diz
      Falácia Existencial: uma conclusão em particular é criada de premissas universais

Falácias da Explicação
      Inventando Fatos: o fenômeno que se pretende explicar não existe
      Torcendo os Fatos: a evidência para o fenômeno que está sendo explicado é tendenciosa
      Irrefutabilidade: a teoria usada para explicar algo não pode ser testada
      Âmbito Limitado: a teoria só pode explicar uma coisa
      Profundidade Limitada: a teoria explicativa não apela a causas subjacentes

Falácias de Definição
      Demasiado Ampla: a definição inclui mais do que devia incluir
      Demasiado Restrita: a definição não abrange tudo o que devia abranger
      Falta de Clareza: a definição é mais difícil de entender do que a palavra ou conceito que está sendo definido
      Circularidade: a definição inclui o termo que está sendo defido como parte da definição
      Condições Conflitantes: a definição é auto-contraditória

Proposição
Valor da Verdade
Tabela da Verdade
Operadores Lógicos
      Disjunção ( ou )
      Negação ( não )
      Condicional ( se-então )
      Conjunção ( e )
      Bicondicional ( se-e-apenas-se )