суббота, 20 июня 2009 г.

[life] “You and Your Research” Ричарда Хэмминга

Случайно наткнулся на доклад “You and Your Research”, который Ричард Хэмминг сделал в 1986-м году в Bell Labs. На мой взгляд, этот доклад относится к тем вещам, которые обязательно стоит прочитать. Хэмминг говорит о том, как, по его мнению, становятся выдающимися учеными. Думаю, что практически все из сказанного им может быть использовано для того, чтобы стать выдающимся программистом.

Позволю себе привести несколько цитат из доклада. А начну делать это с цитирования заключительных слов:

In summary, I claim that some of the reasons why so many people who have greatness within their grasp don't succeed are: they don't work on important problems, they don't become emotionally involved, they don't try and change what is difficult to some other situation which is easily done but is still important, and they keep giving themselves alibis why they don't. They keep saying that it is a matter of luck. I've told you how easy it is; furthermore I've told you how to reform. Therefore, go forth and become great scientists!

А теперь начнем с начала:

I have to get you to drop modesty and say to yourself, ``Yes, I would like to do first-class work.'' Our society frowns on people who set out to do really good work. You're not supposed to; luck is supposed to descend on you and you do great things by chance. Well, that's a kind of dumb thing to say. I say, why shouldn't you set out to do something significant. You don't have to tell other people, but shouldn't you say to yourself, ``Yes, I would like to do something significant.''

Вот так – хочешь быть выдающимся ученым, заставь себя захотеть делать первоклассную работу. И найди в себе смелость заняться этим:

One of the characteristics of successful scientists is having courage. Once you get your courage up and believe that you can do important problems, then you can. If you think you can't, almost surely you are not going to.

После чего не нужно сдаваться и придумывать себе оправданий:

Now self-delusion in humans is very, very common. There are enumerable ways of you changing a thing and kidding yourself and making it look some other way. When you ask, ``Why didn't you do such and such,'' the person has a thousand alibis. If you look at the history of science, usually these days there are 10 people right there ready, and we pay off for the person who is there first. The other nine fellows say, ``Well, I had the idea but I didn't do it and so on and so on.'' There are so many alibis. Why weren't you first? Why didn't you do it right? Don't try an alibi. Don't try and kid yourself. You can tell other people all the alibis you want. I don't mind. But to yourself try to be honest.

И не нужно спрашивать разрешение:

After all, if you want a decision `No', you just go to your boss and get a `No' easy. If you want to do something, don't ask, do it. Present him with an accomplished fact. Don't give him a chance to tell you `No'. But if you want a `No', it's easy to get a `No'.

Но если уж взялся за работу, то нужно работать. Много работать:

Given two people of approximately the same ability and one person who works ten percent more than the other, the latter will more than twice outproduce the former. The more you know, the more you learn; the more you learn, the more you can do; the more you can do, the more the opportunity - it is very much like compound interest. I don't want to give you a rate, but it is a very high rate. Given two people with exactly the same ability, the one person who manages day in and day out to get in one more hour of thinking will be tremendously more productive over a lifetime. I took Bode's remark to heart; I spent a good deal more of my time for some years trying to work a bit harder and I found, in fact, I could get more work done. I don't like to say it in front of my wife, but I did sort of neglect her sometimes; I needed to study. You have to neglect things if you intend to get what you want done. There's no question about this.

Но просто много работать – недостаточно. Нужно знать, к чему прикладывать свои силы:

On this matter of drive Edison says, ``Genius is 99% perspiration and 1% inspiration.'' He may have been exaggerating, but the idea is that solid work, steadily applied, gets you surprisingly far. The steady application of effort with a little bit more work, intelligently applied is what does it. That's the trouble; drive, misapplied, doesn't get you anywhere. I've often wondered why so many of my good friends at Bell Labs who worked as hard or harder than I did, didn't have so much to show for it. The misapplication of effort is a very serious matter. Just hard work is not enough - it must be applied sensibly.

А для этого нужно следить за своей областью и за тем, что в ней является самым важным, и не только:

You can't always know exactly where to be, but you can keep active in places where something might happen. And even if you believe that great science is a matter of luck, you can stand on a mountain top where lightning strikes; you don't have to hide in the valley where you're safe. But the average scientist does routine safe work almost all the time and so he (or she) doesn't produce much. It's that simple. If you want to do great work, you clearly must work on important problems, and you should have an idea.

Но и этого всего недостаточно, если не вкладывать душу:

Great contributions are rarely done by adding another decimal place. It comes down to an emotional commitment. Most great scientists are completely committed to their problem. Those who don't become committed seldom produce outstanding, first-class work…

…The people who do great work with less ability but who are committed to it, get more done that those who have great skill and dabble in it, who work during the day and go home and do other things and come back and work the next day. They don't have the deep commitment that is apparently necessary for really first-class work. They turn out lots of good work, but we were talking, remember, about first-class work. There is a difference.

Естественно, все это не просто. Для этого нужно, чтобы выполнение первоклассной работы было самой важным моментом, самой целью. Все остальное – уже последствия:

Well I now come down to the topic, ``Is the effort to be a great scientist worth it?'' To answer this, you must ask people. When you get beyond their modesty, most people will say, ``Yes, doing really first-class work, and knowing it, is as good as wine, women and song put together,'' or if it's a woman she says, ``It is as good as wine, men and song put together.'' And if you look at the bosses, they tend to come back or ask for reports, trying to participate in those moments of discovery. They're always in the way. So evidently those who have done it, want to do it again. But it is a limited survey. I have never dared to go out and ask those who didn't do great work how they felt about the matter. It's a biased sample, but I still think it is worth the struggle. I think it is very definitely worth the struggle to try and do first-class work because the truth is, the value is in the struggle more than it is in the result. The struggle to make something of yourself seems to be worthwhile in itself. The success and fame are sort of dividends, in my opinion.

Одним из следствий может быть удача:

You've got to work on important problems. I deny that it is all luck, but I admit there is a fair element of luck. I subscribe to Pasteur's ``Luck favors the prepared mind.'' I favor heavily what I did. Friday afternoons for years - great thoughts only - means that I committed 10% of my time trying to understand the bigger problems in the field, i.e. what was and what was not important. I found in the early days I had believed `this' and yet had spent all week marching in `that' direction. It was kind of foolish. If I really believe the action is over there, why do I march in this direction? I either had to change my goal or change what I did. So I changed something I did and I marched in the direction I thought was important. It's that easy.

И еще одна очень важная цитата, которая непосредственно касается выбора направления для прикладывания усилий:

Another trait, it took me a while to notice. I noticed the following facts about people who work with the door open or the door closed. I notice that if you have the door to your office closed, you get more work done today and tomorrow, and you are more productive than most. But 10 years later somehow you don't know quite know what problems are worth working on; all the hard work you do is sort of tangential in importance. He who works with the door open gets all kinds of interruptions, but he also occasionally gets clues as to what the world is and what might be important. Now I cannot prove the cause and effect sequence because you might say, ``The closed door is symbolic of a closed mind.'' I don't know. But I can say there is a pretty good correlation between those who work with the doors open and those who ultimately do important things, although people who work with doors closed often work harder. Somehow they seem to work on slightly the wrong thing - not much, but enough that they miss fame.

Ну и в завершении несколько поучительных баек, которые были рассказаны Хэммингом.


Now Alan Chynoweth mentioned that I used to eat at the physics table. I had been eating with the mathematicians and I found out that I already knew a fair amount of mathematics; in fact, I wasn't learning much. The physics table was, as he said, an exciting place, but I think he exaggerated on how much I contributed. It was very interesting to listen to Shockley, Brattain, Bardeen, J. B. Johnson, Ken McKay and other people, and I was learning a lot. But unfortunately a Nobel Prize came, and a promotion came, and what was left was the dregs. Nobody wanted what was left. Well, there was no use eating with them!

Over on the other side of the dining hall was a chemistry table. I had worked with one of the fellows, Dave McCall; furthermore he was courting our secretary at the time. I went over and said, ``Do you mind if I join you?'' They can't say no, so I started eating with them for a while. And I started asking, ``What are the important problems of your field?'' And after a week or so, ``What important problems are you working on?'' And after some more time I came in one day and said, ``If what you are doing is not important, and if you don't think it is going to lead to something important, why are you at Bell Labs working on it?'' I wasn't welcomed after that; I had to find somebody else to eat with! That was in the spring.

In the fall, Dave McCall stopped me in the hall and said, ``Hamming, that remark of yours got underneath my skin. I thought about it all summer, i.e. what were the important problems in my field. I haven't changed my research,'' he says, ``but I think it was well worthwhile.'' And I said, ``Thank you Dave,'' and went on. I noticed a couple of months later he was made the head of the department. I noticed the other day he was a Member of the National Academy of Engineering. I noticed he has succeeded. I have never heard the names of any of the other fellows at that table mentioned in science and scientific circles. They were unable to ask themselves, ``What are the important problems in my field?''


There was a fellow at Bell Labs, a very, very, smart guy. He was always in the library; he read everything. If you wanted references, you went to him and he gave you all kinds of references. But in the middle of forming these theories, I formed a proposition: there would be no effect named after him in the long run. He is now retired from Bell Labs and is an Adjunct Professor. He was very valuable; I'm not questioning that. He wrote some very good Physical Review articles; but there's no effect named after him because he read too much. If you read all the time what other people have done you will think the way they thought. If you want to think new thoughts that are different, then do what a lot of creative people do - get the problem reasonably clear and then refuse to look at any answers until you've thought the problem through carefully how you would do it, how you could slightly change the problem to be the correct one. So yes, you need to keep up. You need to keep up more to find out what the problems are than to read to find the solutions. The reading is necessary to know what is going on and what is possible. But reading to get the solutions does not seem to be the way to do great research. So I'll give you two answers. You read; but it is not the amount, it is the way you read that counts.


I had computing in research and for 10 years I kept telling my management, ``Get that !&@#% machine out of research. We are being forced to run problems all the time. We can't do research because were too busy operating and running the computing machines.'' Finally the message got through. They were going to move computing out of research to someplace else. I was persona non grata to say the least and I was surprised that people didn't kick my shins because everybody was having their toy taken away from them. I went in to Ed David's office and said, ``Look Ed, you've got to give your researchers a machine. If you give them a great big machine, we'll be back in the same trouble we were before, so busy keeping it going we can't think. Give them the smallest machine you can because they are very able people. They will learn how to do things on a small machine instead of mass computing.'' As far as I'm concerned, that's how UNIX arose. We gave them a moderately small machine and they decided to make it do great things. They had to come up with a system to do it on. It is called UNIX!

Вместо послесловия. Программирование (по крайней мере в части производства программного обеспечения) – это не наука, это производство. И понятие “выдающийся программист” несет в себе совсем другой смысл, чем “выдающийся ученный” (если в понятии “выдающийся программист вообще есть смысл). Думаю, что это обязательно нужно помнить при чтении “You and Your Research”.

PS. Мне особенно понравилось “I don't like to say it in front of my wife, but I did sort of neglect her sometimes; I needed to study.” Ничто не ново под Луной, однако… :(

среда, 17 июня 2009 г.

[life] Стоматологи: от ведь как :(

Мое отношение к стоматологам до сих пор было навеяно анекдотом о том, что лучше учиться на стоматолога, чем окулиста, поскольку зубов у человека 32, а глаз – всего 2. А оказывается, что все совсем не радужно:

В результате по имеющейся статистике из всех врачебных специальностей стоматологи меньше всего живут. Кроме того, у них еще и самый высокий уровень самоубийств.

От ведь как оно на самом-то деле :(

[comp.prog] Трудности перевода: C vs Verilog

Вот здесь наткнулся на фразу, которая поставила меня в тупик:

Working in cooperation with Dr. Adam Alessio of the UW Department of Radiology, the two researchers converted and refactored an existing back-projection algorithm, using both Impulse C and Verilog HDL, to evaluate design efficiency and overall performance. This conversion, which included refactoring the algorithm for parallel execution in both C and Verilog, took 2/3 of the time when working in C than when working in Verilog. Perhaps more importantly, the two researchers found that later design revisions and iterations were much faster when working in C, with as little as 1/7 the time being required to make algorithm modifications when compared to Verilog.

Мои скудные познания в английском приводят к следующему пониманию написанного: переделка алгоритма для параллельной обработки на C заняла на 1/3 меньше времени, чем на Verilog. А дальнейшие модификации алгоритма оказывались гораздо быстрее, чем на Verilog-е (в районе 1/7 времени, требующегося для Verilog-а).

Что заставляет сомневаться в собственном понимании этого текста? А то, что за последние годы прочитал столько обвинений в адрес C/C++, что уже просто не верится, что на этих языка можно что-нибудь делать быстро.

PS. О Verilog HDL знаю только из поверхностного просмотра статьи в Wikipedia. Подозреваю, что для данной задачи Verilog оказался гораздо более низкоуровневым языком, что должно было бы объяснить разрыв в сроках.

вторник, 16 июня 2009 г.

[comp.prog] Вот как был использован SObjectizer

Сегодня наткнулся в Интернете на статью “Архитектура высокопроизводительной системы многоагентного моделирования”, в которой рассказывается о фреймворке для моделирования под названием ASF. В реализации этого фреймворка использован SObjectizer. А один из авторов статьи, Олег Набиуллин, если я правильно помню, когда-то нашел проблему в so_sysconf_2 (которая, к сожалению, не может быть исправлена в рамках so_sysconf_2, но которую мы устраним в so_sysconf_3).

Статья интересная, проект ребята сделали серьезный. Поэтому приятно было увидеть, как SObjectizer нашел свое применение вне компании Интервэйл.

Интересны и выводы, которые были сделаны в статье. В частности, обсуждение проблем, с которыми столкнулись разработчики ASF. Позволю себе упомянуть часть из них в контексте SObjectizer-5.

Асинхронность. Пока SObjectizer-5 видится мне исключительно как фреймворк для реализации асинхронного взаимодействия. Так что подобная проблема (для некоторых задач это действительно будет проблемой) сохранится. Хотя… Если задействовать возможности C++0x, то может получиться, что в качестве реакций на события можно будет назначать лямбда-функции. Что может упростить некоторые операции. Скажем, агент A отсылает сообщение-запрос агенту B, а агент B должен отослать что-то агенту A в ответ, и этот ответ должен быть каким-то образом обработан (например, сгенерировано сообщение агенту C). В SObjectizer-4 особо ничего уже не придумаешь. Но в SObjectizer-5 можно будет реакцию на ответ от B оформить в виде лямбды, что сократит объем прикладного кода и уменьшит его сложность.

Ненадежность соединения. В статье в качестве возможной альтернативы SObjectizer для реализации ASF упоминался MSMQ. И такие его достоинства, как способность работы в offline и гарантированная доставка. Ничего этого в SObjectizer нет, поэтому при реализации ASF разработчикам приходилось бороться с разрывами соединений и потерями сообщений. В SObjectizer-5 хочется вообще отделить транспортный слой от ядра SObjectizer. Это может позволить сделать иерархию транспортных средств с разными характеристиками. На нижнем уровне будут лежать коммуникационные агенты, аналогичные существующим в SObjectizer-4. А над ними могут быть реализованы средства, характерные для систем обмена сообщениями (TIBCO Rendezvous, MSMQ, JMS) – транзакционность, гарантированная доставка, механизмы publish/subscribe и пр. Что может существенно упростить разработку аналогичных ASF приложений.

Производительность. Разработчики ASF провели сравнение скорости проведения тестового вычислительного эксперимента HeatBugs с аналогичными реализациями в Swarm (Java) и RePast (.NET). ASF-решение оказалось в 1.3 раза медленнее Swarm, и в два раза быстрее RePast. Это значит, что производительность SObjectizer нужно поднимать. Статья была опубликована, как я понимаю, весной 2008, поэтому у разработчиков еще не было возможности попробовать шестую бета версию SObjectizer 4.4.0 (в которой производительность была еще чуть-чуть поднята). Но все равно, хотелось бы получить в SObjectizer-5 производительность на порядок большую, чем в SObjectizer-4.

[comp.prog] The Case for D

В журнале Dr.Dobb появилась статья Андрея Александреску The Case for D, в которой коротко рассказывается о наиболее интересных и важных (на данный момент) особенностях языка D.

В частности, приводится хоть какой-то осмысленный пример alias this, возникновению которого я когда-то удивлялся. С виду похоже на оператор приведения типа в C++. А предназначено это, похоже, для компенсации отсутствия нормального множественного наследования. Мне так кажется.

Очень интересно описание новых функциональных возможностей языка D и пакета std.ranges из Phobos. Даже некая ленивость присутствует.

Нужно отметить, что с подключением Александреску к развитию языка D с языком происходят интересные метаморфозы. Но главной проблемой D до сих пор оставалась его константная изменчивость и нестабильность. Что и поставило на нем крест в моих планах. Так что самое интересное сейчас – сможет ли Александреску повлиять на Брайта так, чтобы D все-таки стабилизировался?

[life.cinema] Немного о кино

На прошедшей неделе посмотрел несколько фильмов. Захотелось поделиться впечатлениями (т.е. поддаться особо острому приступу графомании).

Терминатор 4

Сходили на него с женой в кинотеатр. В последние годы выбирались в кино еще два раза – сначала на Терминатор-3, затем на Пиратов Карибского Моря-3. Было очень приятно обнаружить полный зал.

Сам фильм, как говорится, немного предсказуем. Как-то быстро стало понятно, что Маркус является еще одной вариантом киборга. Ближе к концу фильма стало понятно, что одного из терминаторов обольют металлом из предусмотрительно расположенной в сердце Skynet-а домны (можно выводить новую кинематографическую примету – если где-то в фильме про терминаторов появляется домна с расплавленным металлом, то какого-то из терминаторов в нее окунут). Потом стало понятно, что Маркус отдаст свое сердце Коннору. Ну а то, что с самим главным героем ничего не случится и так было понятно – ведь ему же еще предстояло прожить несколько лет и отправить в прошлое своего будущего отца. Так что интриги в фильме не было вообще.

Еще меня по ходу фильма мучил один вопрос – ну хорошо, роботы под управлением Skynet-а мочат людей. Довольно успешно, надо сказать. А остальная живность где? Где птицы, где звери? Ведь людей, которые сейчас являются главным их врагом уже практически не осталось. Вот и из-за этого момента у меня было сильное впечатление, что смотрю какую-то сказочку, и поверить в происходящее не получается.

Зато по фильму сразу было понятно, что в него вложили $200M. Визуальный ряд отличный. Так что вложенные средства отработаны на все сто. И если есть какие-то причины посмотреть четвертого Терминатора, так это сам факт просмотра четвертого Терминатора (ну надо же глянуть, как в очередной раз не удалось приблизиться к планке, так высоко поднятой вторым фильмом) и из-за спецэффектов.

Тринадцать (он же Халтурщики, он же Botched, со Стивеном Дорффом)

Отлично сделанная пародия на фильмы ужасов. Вор приезжает в Москву для кражи уникального золотого креста, принадлежавшего Ивану Грозному. После кражи лифт с бандитами и несколькими случайными попутчиками застревает на 13-м этаже. Где, как выясняется, окопалась семейка сумасшедших потомков Ивана Грозного занимается ритуальными убийствами. Так что далеко не все из попавших на этаж смогут выжить.

Фильм, наверняка, на любителя. Но мне понравилось – актеры, похоже, стебаются и над своими героями, и над самими собой.

Иллюзия допроса (от же Tortured, с Коулом Хаузером и Лоуренсом Фишберном)

Муть редкая. Суть в том, что главный герой был внедрен под прикрытием в жутко законспирированную банду. Настолько крутую, что даже не все ее участники знали друг про друга. И через полгода после внедрения ему поручили важное задание – пытать негра-бухгалтера с целью поиска пропавших денег. Причем пытать неспешно. По полчаса в день. После чего внедренный агент спокойно уезжал к себе домой, к своей цивильной сожительнице. Но мало того, что агент совсем не задумывался о том, что за ним могут проследить. Оказалось, что его папашка – не кто-нибудь, а директор Бюро. Который как-то взял и пригласил своего сына с подругой на официальный банкет с разными сенаторами и прочим истеблишментом. Дальше больше. Оказалось, что папашка главного героя когда-то сам был агентом под прикрытием и сам охотился на главаря этой самой банды, но безуспешно.

Финал был вообще феноменальный – чуть ли не замученный до полусмерти негр-бухгалтер оказался тем самым главарем. И все это (включая, как я понял, собственные пытки) он подстроил чтобы отомстить директору Бюро путем убийства его сына (т.е. главного героя). Но это у него, естественно, не получилось. Ну хоть папашку завалили, и то хлеб.

Как мы с женой любим шутить, именно из-за таких фильмов финансовый кризис в США и произошел – потратят деньги на какую-то фигню, а потом вернуть кредиты не могут :)

Платон (с Павлом Волей)

Нормально снят, динамично, с юмором. Смысла фильма не понял. Как и не понял, из-за чего все влюблялись в Любу, главную героиню. Так что после просмотра стало жалко потраченного на него времени.

Баксы (с ударением на последний слог)

А вот этот фильм откровенно порадовал. Сюжет очень простой. Снят, такое впечатление, с минимальным бюджетом. От самого фильма веет каким-то старым, советским стилем. Но смотрится на одном дыхании. Мне понравилось. Может быть из-за того, что ничего хорошего от фильма изначально не ожидал. Так что получился очень приятный сюрприз.

понедельник, 15 июня 2009 г.

[life] Для чего же нужен технический прогресс? А вот…

А вот нужен он для того, чтобы по Skype можно было в реальном времени обсуждать свежие сплетни и бытовые новости, находясь друг от друга в тысячах километров. Обсуждать сплетни. Сплетни!

[life.politic] Чуть-чуть про молочный скандал

Наши белорусские новости смотрю редко, а тут на выходных умудрился попасть сразу на несколько выпусков. О скандале, связанном с недопуском белорусских молокопродуктов на российский рынок я знал и до этого, во многом по новостным лентам блоггеров. А тут увидел, какую пропаганду завели по нашему государственному телевидению. Полное возвращение во времена застоя – мы белые и пушистые, а вокруг злобные империалистические враги. Трындец, короче.

Вот некоторые моменты, которые излагаемую по телевидению официальную точку зрения превращают в фарс. Во-первых, всегда рассказ ведется в такой плоскости, что Россию перестало удовлетворять качество нашей продукции. Хотя местами в белорусских источниках и в российской блогосфере говорится лишь о несоответствии маркировки на упаковках, а претензий к качеству нет (по крайней мере в начале всего этого безобразия не было). При этом те же самые телеведущие с гордостью говорят о том, что наши масло и сыр в России продолжают закупать. Спрашивается, если Россия стала давить на качество молока и кефира, то почему же она не задавила заодно и масло с сыром? Как будто их из другого молока делают :)

Во-вторых, очень трогательно прозвучали слова ведущего “Контуров” о том, что наши молокопродукты с удовольствием собираются закупать в Германии. Мол, нам и Россия не нужна будет. Блин. Деятели. Если Германия готова закупать – так продавайте и забейте на Россию. Зачем об этом говорить в новостях? Типа напугать кого-то? Детский сад :(

Вообще, все происходящее мне напоминает детей младшего школьного возраста. Когда первоклассник посылает третьеклассника в жопу и вполне ожидаемо получает подсрачника. После чего отбегает в сторону и начинает вопить, что мол я тебе тоже могу пендаля дать. А потом догнать и еще раз дать. На что офигевший третьеклассник смотрит со стороны и думает, что негоже гоняться за такой мелюзгой.

Что во всей этой истории хреново: если мы действительно поставляли в Россию изрядный процент молочных продуктов, то это серьезная рыночная ниша. Из которой Белоруссию сейчас пинком выбьют. Но свято место пусто не бывает. Поэтому эта ниша будет быстро занята кем-то еще. Но не нами. И вернуться туда будет ой как не просто, если вообще возможно. А не вернемся, что тогда наши производители молока будут делать? В Германии нас вряд ли ждут. Так что грустная, на самом деле, история.

[comp.prog] Safe and Secure Software: An invitation to Ada 2005

На linux.org.ru в последние дни появилось две новости, касающиеся языка Ada:

Вышел GNAT GPL 2009 – о выходе FOSS версии компилятора языка Ada (есть еще и платная версия).
Вышел релиз связки библиотеки Qt и языка Ada - QtAda-3.0.0 – о создании связки Ada и Qt.

Язык Ada я пытался изучать где-то в 1994-95. У меня дома даже книжка валяется “Язык программирования Ада”. Но то была Ada 83 (если не ошибаюсь с годом принятия первого стандарта). С тех пор утекло много воды. Сначала появилась Ada 95 с поддержкой объектно-ориентированного программирования. Затем Ada 2005. Поэтому при появлении обсуждений на linux.org.ru захотелось восстановить в памяти приблизительные знания о языке. Что удалось сделать с помощью электронной книги Safe and Secure Software: An invitation to Ada 2005.

Сразу хочу сказать, что некоторые главы я не прочитал. А из остальных нельзя составить полного представления о том, что же из себя представляет язык Ada 2005. Но общее впечатление все-таки складывается. Так что, в качестве развития общей эрудиции книга вполне может подойти.

Мне в ней понравились сравнения некоторых конструкций в C/C++ и Ada. Благодаря этому становится хорошо видно, как программирование на одном нативном языке может быть безопаснее программирования на другом нативном языке. Но, что поразительно, из данной книги вовсе не складывается впечатления, что Ada на порядок лучше и удобнее C++. С другой стороны, это может объясняться моей ангажированностью, а с другой стороны – уж очень большой многословностью Ada.

Из того, что меня поразило, я бы отметил:

  • оказывается, в Ada реализована эффективная передача массивов переменной длины через стек. Что, по словам автора книги существенно уменьшает количество операций с динамической памятью в программе. А это не маловажно, т.к. в нативном варианте Ada не предоставляет механизмов сборки мусора;
  • оказывается, в Ada для объектов так же можно определять собственные операции инициализации, копирования и уничтожения (аналогично C++ным конструкторам, операторам копирования и деструктором). Так что в Ada можно, похоже, использовать замечательную идиому RAII;
  • оказывается, в Ada есть специальные директивы компилятора, которые запрещают использование “позднего связывания” (т.е. вызовов виртуальных функций в терминологии C++) в коде. Что используется при разработке критически важных фрагментов кода, в которых все ветви исполнения кода должны быть строго определены;
  • оказывается, что “избыточный” синтаксис для завершающих конструкций end (например, end if, end loop и т.д.) существенно повышает читабельность кода с распечатки. Я этого не ожидал и был удивлен. Но, действительно, когда в рамках примера объявляется пакет с несколькими типами и функциями, то именованные end-ы четко указывают, к чему именно они относятся. Что удобно.

Резюмируя. Если есть поверхностные знания Ada и хочется чуть углубить и расширить их, или если просто есть желание понять, за счет чего Ada позволяет писать надежное ПО, то эту книгу имеет смысл просмотреть.

PS. Интересный список ссылок по Ada-ресурсам: Resources on Ada: Managing Complexity.