In this appendix I insert some errors that I have done, in the hope that a curious person can learn from it.
This suggestion is taken from an extreme programming sites, cited in the credits part:
``Make it work, make it right, then make it fast.
Do not optimize until the end. Never try to guess what the system's bottle neck will be. Measure it!
Never add Functionality.
Early Keep the system uncluttered with extra stuff you guess will be used later. Only 10% of that extra stuff will ever get used, so you are wasting 90% of your time. We are all tempted to add functionality now rather than later because we see exactly how to add it or because it would make the system so much better. It seems like it would be faster to add it now. But we need to constantly remind our selves that we are not going to actually need it. Extra functionality will always slow us down and squander our resources. Turn a blind eye towards future requirements and extra flexibility. Concentrate on what is scheduled for today only. ``I have changed the design a lot of time during Jude development and I have discarded a lot of code. Inside this code there were also optimization and advanced features. More features you have and more code you must adapt when you change design, a common event during the development of a program. If the feature you like is not the most important to insert today than wait and insert it only when all the more important work is done. This helps you to save time. The best solution is to add a comment inside the code that explain the proposed features and how to implement it, in order to not loose the idea that you have in the ``moment of illumination''.
If there is a bug inside a complex code the better thing to do is to refactor the code. Apply design by contract as explained in [Meyer 1997] or the techniques described in [Fowler 2000]. This helps to clarify the contract between class, find bad design and bad class usage. Often a bug is not the problem but the symptom of a bad design.
Remember: if you fix only the bug you are loosing your time, if you improve the design you are investing your time.
I have not applied in his full power a Design by Contract tool for adding this capabilities to Java. I'm very glad of this because I think that DbC is one of the powerful debug techniques. I have applied it in some case during design phase and as documentation tool. I have not followed all the guidelines described [Fowler 2000]. However an incomplete use of these tecniques is better than nothing.
I have spent some time writing and maintaining the Simple-Logic to XSB-Prolog compiler. I think that SableCC is a good tool (more usable than lex/yacc tools) but it does not resolve the problem of mapping a syntax tree to an abstract syntax tree. I have spent a lot of time rewriting all the compiler in order to produce an abstract syntax tree from the syntax tree. My first bad implementation used an enormous amount of memory and I must to redesign some part of the compiler. At the end I was disappointed by the unexpected amount of work.
Recently I have discovered Elegant, described in [Jansen 1993]:
``a compiler generator system which is supported by a high level programming language. ``I'm not an expert of this field, so probably there are better tools than Elegant. However reading the introduction of Elegant I have found a lot of solution to my problems. I want to report the consideration about abstract syntax tree, as expressed in [Jansen 1993]:
``If you are able to detect whether an arbitrary input text can be mapped onto a syntax tree you have a syntax checker. In the previous sections we have built such a syntax checker. A syntax tree however does not hold the essential concepts of the source language. It only tells how an input text is structured syntactically. What we are really interested in are the real abstractions of the source language. If a formal language must be translated into another formal language syntactic details are not important. A data structure which only holds the semantically relevant information of an input text is called an abstract syntax tree. Before an abstract syntax tree can be filled, one has to define what the abstractions of the source language are. These are laid down in the so called static semantics.
[..]The static semantics is a specification of the data structure which will be used as an intermediate between source and target language. The static semantics is so important that it is sometimes called the heart of a compiler. In this section we explain what static semantics is about and how it can be specified in Elegant.``I have a lot of problem specifying a syntax without ambiguities.