Совет начинающему программисту. Никогда не исправляйте найденные ошибки, ибо это повлечет за собой появление неизвестного числа ненайденных. Лучше опишите их в сопроводительной документации как особенность программы. Закон Брукса. Увеличение числа участников при подготовке опаздывающей программы только замедляет процесс. Я только что нашел последнюю ошибку. Фредерик Брукс Большой программистский проект ... включает в себя много отдельных задач, каждая из которых может зависеть от окончания другой. Вероятность того, что каждая задача будет идти нормально, становится исчезающе малой. "Мысли о программировании" Пользователь не знает, чего он хочет, пока не увидит то, что он получил. Э. Йодан Чтобы понять программу, необходимо отождествить себя и с машиной, и с программой. "Афоризмы программирования" Отлаживать код вдвое сложнее, чем писать. Поэтому, если при написании программы вы используете весь свой интеллект, вы по определению недостаточно умны, чтобы ее отладить. Б. Керниган Стремление упростить приводит в перспективе лишь к избыточной сложности при попытке описания сложных вещей. "К вопросу об ублюдочности PHP" Истинные макросы, а не всякое препроцессорное говно. О Лиспе High level languages claim to offer simpler or more appropriate structures, but often fall short of this goal when needs change or one is forced to reason about lower levels anyway. A regular dose of assembly programming will remind us what we should demand of our higher level languages. www.c2.com I said that I thought that the components were more important than trying to solve the whole problem at once. Once you have the components, then you can solve the whole problem. Peter Norvig Nonetheless, we often put too much focus on code and not enough on process. You can rearchitect and rebuild all you want; but if you keep doing what you've always done, you'll keep getting what you've always gotten. www.c2.com High quality is expensive. Low quality is expensive. Play with some other parameters. www.c2.com Real Programmers can write assembly code in any language. Larry Wall If you don't run experiments before you start designing a new system, your entire system will be an experiment! Mike Williams (original ErLang developer) If you're working sixty hour weeks, you're too tired to be doing good software. Ron Jeffries Given ten days for a project, a good engineer spends nine days figuring out how to finish it in one day. www.c2.com Концептуальное единство является самым важным соображением при проектировании системы. Ф. Брукс The single most important thing you must do to improve your programming career is improve your ability to communicate. Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. Philip Greenspun's Tenth Rule of Programming Q: How can you tell when you've reached Lisp Enlightenment? A: The parentheses disappear. Наиболее радикальное возможное решение при создании программ - вообще не создавать их. Ф. Брукс Simplicity of the language is not what matters, but simplicity of use. Richard A. O'Keefe Software quality has almost nothing to do with algorithmic elegance, compactness, or speed - in fact, those attributes do more harm to quality than good. The objective is to make things as clear as possible to the designer and to yourself, and excessive formality can destroy clarity just as easily as modest formality can enhance it. Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. Anonymous, Revised Report on the Algorithmic Language Scheme Weeks of programming can save you hours of planning. Anonymous LISPеры пользуются технологией «ленивого программирования», аналогичной lazy evaluation. При этом программа не пишется, а сразу объявляется написанной. Фактическое формирование кода программы должно происходить при первом непосредственном обращении к ней, но поскольку никто не обращается, код тоже не формируется. Благодаря этому LISP разработчики экономят много времени, которое могут с пользой использовать для эффективного троллинга. www.rsdn.ru I won't pretend to remember Lisp inventor John McCarthy's exact words which is odd because there were only about ten but he simply asked if Python could gracefully manipulate Python code as data. "No, John, it can't," said Peter [Norvig] and nothing more, graciously assenting to the professor's critique, and McCarthy said no more though Peter waited a moment to see if he would and in the silence a thousand words were said. Lisp is not designed to make easy things short (a la Perl). It does however, make difficult things easier. www.c2.com LISP will become obsolete when someone makes a more comprehensive language that dominates LISP practically and also gives a clear mathematical semantics to a more comprehensive set of features. John McCarthy Language serves not only to express thought but to make possible thoughts which could not exist without it. Bertrand Russell The most important thing in the programming language is the name. A language will not succeed without a good name. I have recently invented a very good name and now I am looking for a suitable language. D. E. Knuth Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. Jamie Zawinski Edsger Dijkstra's great strength is that he is uncompromising. It would make him physically ill to think of programming in C++. Donald Knuth Needs Python 2.1 or better. "Cooking with Python" Для меня ППП (процесс программирования с псевдокодом) - идеальная методика создания классов и методов. Макконнелл С. Совершенный код AsFastAsCee www.c2.com You might be better off focusing your reuse work on the creation of small, sharp, specialized components rather than on large, bulky, general components. Developers who try to create reusable software by creating general components rarely anticipate future users' needs adequately. Future users will look at the large, bulky component, see that it doesn't meet all of their needs, and decide not to use the component at all. "Large and bulky" means "too hard to understand," and that means "too error-prone to use." Data from the NASA Software Engineering Lab suggests that if a component needs to be modified by more lhan 25 percent, it's as cost-effective to develop a new one-off component as it is to reuse an old one. McConnell S. Rapid Development Computer Science is in deep trouble. Structured design is a failure. Systems, as currently engineered, are brittle and fragile. They cannot be easily adapted to new situations. Small changes in requirements entail large changes in the structure and configuration. Small errors in the programs that prescribe the behavior of the system can lead to large errors in the desired behavior. Indeed, current computational systems are unreasonably dependent on the correctness of the implementation, and they cannot be easily modified to account for errors in the design, errors in the specifications, or the inevitable evolution of the requirements for which the design was commissioned. (Just imagine what happens if you cut a random wire in your computer!) This problem is structural. This is not a complexity problem. It will not be solved by some form of modularity. We need new ideas. We need a new set of engineering principles that can be applied to effectively build flexible, robust, evolvable, and efficient systems. In the design of any significant system there are many implementation plans proposed for every component at every level of detail. However, in the system that is finally delivered this diversity of plans is lost and usually only one unified plan is adopted and implemented. As in an ecological system, the loss of diversity in the traditional engineering process has serious consequences for robustness. This fragility and inflexibility must not be allowed to continue. The systems of the future must be both flexible and reliable. They must be tolerant of bugs and must be adaptable to new conditions. To advance beyond the existing problems we must change, in a fundamental way, the nature of the language we use to describe computational systems. We must develop languages that prescribe the computational system as cooperating combinations of redundant processes. Gerald Jay Sussman I can't tell you how many times I've heard people say they wouldn't use Ruby because it lacks automated refactoring tools. Ruby doesn't actually need them in the way Java does; it's like refusing to switch to an electric car because there's no place to put the gasoline. But programmers are a stubborn bunch, and to win them over you have to give them what they think they want. www.steve-yegge.blogspot.com And to anyone who says syntax isn't important, may I point out the vast scale of the cosmetics industry? Like it or not, looks count. Laurence Tratt There are substantial gaps in the knowledge about how to make programming languages effective for people, and how to apply this knowledge to the design of new programming languages. Brad A. Myers XSLT suffers from many of the readability problems of LISP. Different things should really look different to take advantage of the brain's amazing pattern matching abilities, and avoid spending all our time parsing instead of reading. Ken McNeil There is an important distinction between, "What does this tool do well?" and, "What can you write that uses this tool to do something else well?" Ken Arnold Many people are much more likely to think about what they have in hand and what they can do. They think from the implementation out, instead of thinking from the user in. Ken Arnold When you're in a world of optimizing compilers and VMs, you have to profile, because the compilers and VMs are doing things that you can't even imagine. So don't predict, just measure. Martin Fowler on optimization Rather than choosing a process and then fitting the team to the process, teams should chose their software process. Martin Fowler Don't use tools just because they're there. Use them because they fit into the overall philosophy of how you want to develop. Dave Thomas If you give yourself constant feedback, then gradually you'll get better at doing what you do. That's absolutely critical, but most people don't do that. They rush onto the next project, without going back and thinking how they did this last one. Without that feedback, you're never going to improve. Dave Thomas So rather than make a whole bunch of decisions up front and start the meter running, we try to defer each decision as long as we can. We end up with a lot of small cost of change curves, because each one hasn't had a chance to get up too high. Cumulatively, the effect of adding up those small curves is a lot less than having one curve that starts at zero that ramps up to infinity real quickly. Dave Thomas All things considered, I came out from the conference with a pessimistic impression about the future of Common Lisp. I hope I am wrong. In this moment my advice to a young programmer wanting to start with a Lisp-like language would be "forget about Common Lisp, look at Clojure if you feel enterprise-oriented or at Scheme if you feel research-oriented". Michele Simionato ...scale fragile sequential algorithmic paradigms where they were never meant to go, and where they can’t go. Alan Kay The Ruby community seem to be more willing to experiement and evolve, whilst the Smalltalk community is still holding onto Smalltalk-80 as the common Smalltalk dialect. I guess the question is whether the Ruby community can evolve together and stay as one, avoiding the fragmentation that occurred with Smalltalk. pab-data.blogspot.com The test of a language is not simply how clean the finished program looks in it, but how clean the path to the finished program was. Paul Graham The key to performance is elegance, not battalions of special cases. McIlroy and Bentley "Lisp? Isn't that, like, dead?" The canonical response is: "Not any more than usual." I think macros can make the code more difficult to understand, make the semantics less uniform (despite the uniform syntax), and can become an abused ugly hack. Tomasz Zielonka It takes 15 years for a programming language to mature. It was guaranteed that those venture companies in 90's which used Java failed. Fritz Kunze (President of Franz Inc.) Парнас проводит свою идею значительно дальше. Он предлагает распространить ее на алгоритмы и структуры данных. Упрятывание информации - а не структура принятия решений или иерархия вызовов - вот что должно лежать в основе проектирования! 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. Edsger Dijkstra Основной критерий качества ЯП: язык тем лучше, чем более он способствует СНИЖЕНИЮ СЛОЖНОСТИ производства программных услуг. Кауфман В. Ш. Object-oriented design is the roman numerals of computing. Rob Pike With the ever-increasing size of software systems, the explosive growth of distributed computing on the Internet, and the development of highly portable object-oriented languages (Java) and binary object standards (.NET [WHA03], CORBA [Sie96]/JavaBeans [Sun97]), object-oriented programming will clearly play a central role in 21st-century computing. Programming Language Pragmatics Doing a few things right doesn't guarantee rapid development. You also have to avoid doing anything wrong. To slip into slow development, all you need to do is make one really big mistake. McConnell S. Rapid Development РЕФАЛ-машиной называется абстрактное устройство, которое выполняет РЕФАЛ-программы. Руководство по РЕФАЛу-5 Here's what's keeping me with Python: my code reads like pseudocode, and I love that. When I come back to Python code I haven't seen in months, it takes me all of five seconds to grok it again. Neil Toronto Language designers are solving the wrong problem. Users don't need benchmarks to run fast. What they need is a language that can show them what parts of their own programs need to be rewritten. That's where speed comes from in practice. So maybe it would be a net win if language implementors took half the time they would have spent doing compiler optimizations and spent it writing a good profiler instead. Paul Graham Очень многие разработчики начинают проектирование с вопроса: «Каковы задачи?». Такой подход дает возможность сделать работу, но не позволяет даже приблизиться к наилучшему решению, а также совершенно не удовлетворяет пользователя. Проектирование, ориентированное на задачи вместо целей, - вот одна из основных причин раздражающего и неэффективного взаимодействия. Вопрос «каковы цели пользователя?» позволяет нам смотреть через незамутненное стекло и создавать более качественный и уместный дизайн. Алан Купер На момент придумывания Go, D уже вполне существовал. Авторов Go этот язык не устроил в первую очередь тем, что он стал представлять собой настоящую свалку всевозможных фич, что не идёт ему на пользу. Хороший язык программирования должен быть лаконичен. This is very hard to beat and probably not worth the effort. It's likely that the end result of any new attempt will have similar messy odds and ends as Common Lisp currently has. I think this is an inevitable side effect of the goal to integrate a large number of features, and an inevitable side effect of a language that has been organically grown over several decades. Not even Scheme seems to be able to avoid these issues, if you look closely enough. The idea that choosing a minimalist approach is a remedy here doesn't seem to work either. Pascal Costanza Parsifal is an interesting choice of name for a software company. In the Arthurian Legend Parsifal was only knight among the Knights of the Round Table who found the holy grail. The grail itself is loaded with symbolism. In compiler design and implementation, the holy grail is a tool (or tool set) that will create a compiler, from parser to code generator, from a set of formal descriptions (a grammar and instruction set description, for example). When this grail is found, it is said, compiler developers will all be out of work and cost of creating a new compiler will be low. Like Arthur's knights, many have searched for this grail, but no one has found it, at least for production quality compilers. Ian Kaplan Influenced by natural language Wikipedia article on Inform language