Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  03:46[Войти] | [Зарегистрироваться]
Обсуждение темы:
Книги для программистов. Состояние дел и перспективы.

Все нижеупомянутые названия книг, вопросы и т.д. приведены исключительно в качестве примера. Прошу не считать это рекламой или антирекламой. Да сделает каждый свой выбор сам. И да не обидятся авторы книг, вопросов.

Прочтение материалов <Деньги на ветер> и <За что я не люблю Архангельского> навело на некоторые мысли по поводу современного состояния издания программистских книг. Предлагаю обсудить состояние дел в этой отрасли. Для начала свои комментарии, замечания.
Первое.
Все книжки, выходящие на данный момент можно разделить на такие группы:
1) Новичку (<ХХХ за 24 часа> - название условно, вместо ХХХ подставьте название среды разработки, пакета обработки графики.. да что угодно).
2) Средний уровень. Что-то конкретное назвать трудно. Подразумевается владение базовыми навыками работы в избранной среде, написания простейших приложений.
3) Высший пилотаж. Типовые примеры - Дж. Рихтер <Создание эффективных Win32 приложений с учетом специфики 64-разрядной версии Windows>, Д. Соломон, М. Руссинович <Внутреннее устройство Microsoft Windows 2000>.

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

Кратко остановимся на особенностях теоретических книжек. По моему мнению, основные их отличия это:
- Весьма активное использование математики, причем, так сказать, математики высшего полета.
- Использование фраз типа: "Обычно это так, но не гарантируется".
- Рассмотрение различных фундаментальных понятий на почти бесполезных примерах.
- Почти обязательное использование компиляторов ANSI. (в основном, ANSI C).

Такие книжки очень любят преподаватели предметов наподобие "Теоретические основы программирования", "Логическое программирование" (названия чисто условны, но, думаю, понятно). Результатом изучения последними этой литературы являются вопросы на форумах типа: " Задан граф - не дерево. Проверить, можно ли превратить его в дерево удалением одной вершины вместе с ее ребрами", "Задана система двусторонних дорог. Найти замкнутый путь длинной не более T, проходящий через каждую дорогу ровно один раз" (вопросы списаны с форума www.rsdn.ru . Надеюсь, автор не обидится).

Теперь поговорим о прикладных. Очень часто авторы добросовестно списывают соответствующие разделы MSDN,справки Delphi, разбавляя своими комментариями оригинальный текст и листинги примеров. Но можно выделить и книги другого типа, которых пока не очень много и которые очень нужны. Это книги, посвященные решению различных типовых прикладных задач. К таким бы я отнес труды М.Е. Фленова "Программирование на Delphi глазами хакера", "Программирование на С++ глазами хакера", "Delphi в шутку и всерьез. Что умеют хакеры", А.Я. Архангельский, М. Тагин "Приемы программирования в Borland C++Builder 6. Механизмы Windows и сети". (Прошу не считать рекламой. Мне кажется, книги действительно достойные внимания).

Скажу пару слов о книгах начального уровня. Здесь абсолютно правильно говорили, что там часто бывает очень много недомолвок, формально правильных, но неполных примечаний и т.п. Вообще, мне кажется, что наиболее правильный путь написания таких книг - ознакомление со средой разработки и программированием в ней на различных полезных примерах. К сожалению, я мало видел таких книг. Единственный пример - книги С.Бобровского по Delphi и C++Builder.

О книгах для среднего уровня говорить много не надо. Пример - вышеупомянутые произведения М.Е. Фленова, А.Я. Архангельского.

О профессиональных книгах говорить вообще не буду - профессионалы сами разберутся, чего им надо.

Чего не хватает.
Здесь я скажу, чего не хватает лично мне. А Вы, уважаемые читатели, добавьте свои мнения, что бы Вы хотели прочитать.
Итак, книжки по работе с базами данных, но особой - для ламера от начала до конца. Т.е. я бы хотел видеть что-то типа такого начала книги: "Перед нами стоит задача создать СУБД. Структура таблиц у нас такая (описание структуры). В базе необходимо реализовать такие-то функции( например, вставка/удаление элементов, сортировка, выборка). Эти задачи мы решаем так-то(далее пример кода). И так до конца разработки - тщательный комментарий каждого шага.
Второе, книги по цифровой обработке сигналов и изображений с особым упором на программный код. Т.е. базовые алгоритмы с иллюстрацией на Pascal, C, Delphi, C++Builder. А начать такую книгу следовало бы с чтения данных из звуковых файлов, файлов изображений различных типов

Сергей Лысенко

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 88 сообщений

Добавить свое сообщение

Отслеживать это обсуждение
<<<... | 78—69 | 68—59 | ...>>>
Всего сообщений в теме: 88; страниц: 9; текущая страница: 2


№ 78   03-11-2007 22:51 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 75« (Дядя .СЭМ)
___________________________


Верный способ проверить алгоритм или программу это формально доказать правильность или ошибочность его (ее). Всегда ли это возможно - незнаю. Единственный ли это способ - не знаю.
Работает это не значит - все верно. Вы ничего не можете сказать о поведении программы за пределами тестовой области.


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

Для реальных задач тестирование, с его очевидными недостатками, все таки является единственным способом проверки правильности работы (если, конечно, реализуется достаточно сложная задача, а не на "два действия").


Протестировать программу это значит сказать что мы сделали для поиска ошибок все что смогли (и то что было определено как достаточное), но не более того.


Про проверку программы можно тоже сказать - проверить, значит сказать что "мы сделали для поиска ошибок все что смогли (и то что было определено как достаточное), но не более того". Так что проверка - это тоже не окончательное доказательство правильности программы.



Ответ на »сообщение 76« (Сергей Перовский)
___________________________


Ошибка теоретически простая - не гарантирован выход из цикла. А с точки зрения "практика" все замечательно - многократно успешно тестировалось и использовалось в реальных проектах.
Если программист не замечает, что при S2 = S3 цикл не закончится, то и при тестировании проверить такой вариант он не додумается.


В этом примере как раз подтверждением моих слов. Ведь выявилась ошибка именно при эксплуатации, а не при анализе. То есть правильно построенный тест также мог ее выявить. Да и ошибка ли это? Не зная подробностей, сложно сказать, но может алгоритм и не был расчитан на использование при s2=s3? Ведь логически, если s2=s3, алгоритм замены вызывать не надо. Это я к тому, что при анализе алгоритма и программы исходят из требований, к ним предъявляемых. Поэтому в исходных условиях, когда надо заменять s2 на другую s3 анализ тут бы не помог. Так что еще раз - в современных условиях, когда "чистые алгоритмы" составляют незначительную часть программы, работы программы зависит от множества технических факторов и конфигурации конкретной среды, а само классическое программирование превратилось в программную инженерию, единственный способ проверки правильности работы программы - тестирование.

Кстати, у меня был похожий случай. Звонят с завода - переустановили мою программу на новый компьютер, она не запускается. На старом и других - все хорошо. Все бы ничего, да завод за 4000 км, поэтому на месте не посмотришь. Мучался недели три. Локализовал ошибку быстро - она происходила при инициализации моего графического компонента (таблицы для вывода результатов), если в системе нет принтеров (в данном случае USB принтер обнаруживался только при включении). Но не мог ее исправить, как бы пытался обходить начальные проверки и инициализации, ошибка была. И на "круглом столе" не помогли, видно никто не сталкивался ... Работал в D2005. Наконец методом шаманства решил скомпилировать проект в D7, все заработало без проблем. То есть был глюк именно D2005. В следующих версиях, Turbo Delphi и D2007 его не было - исправили. Но на Delphi я не обижаюсь, понимаю, что система сложная и ошибки будут всегда, как бы не анализируй (тестируй) код. И причина не в плохой подготовке программистов, которые не могут ответственные системы делать, и не в недостатке у них специального "алгоритмического" образования, а именно в сложности системы.



№ 77   03-11-2007 05:33 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 76« (Сергей Перовский)
___________________________

While pos(s1,s2)>0 do
begin
тут алгоритм замены S2 на S3
end;
Понятно, что цикл необходим для замены всех вхождений S2.

Ошибка теоретически простая - не гарантирован выход из цикла. А с точки зрения "практика" все замечательно - многократно успешно тестировалось и использовалось в реальных проектах.
Если программист не замечает, что при S2 = S3 цикл не закончится, то и при тестировании проверить такой вариант он не додумается.


Странно, что такая ошибка прожила целых 2 года. Ведь программа войдёт в бесконечный цикл и в случае, когда S2 является подстрокой S3. А это весьма распространённый вариант замены. Вот, например, мне недавно приходилось заменять в исходнике идентификатор 'Name' на 'AName'.


№ 76   02-11-2007 20:28 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 74« (Павел Трубаев)
___________________________
Здесь вопрос в другом - способ проверки реальных программ.
Каких программ?
К столетию кинематографа один критик написал, что за сто лет было снято несколько тысяч хороших фильмов. И миллион плохих.

К вопросу о тестировании. Одна моя программа на третьем году безупречной службы стала зависать. Быстро выяснилось, что зацикливается обработчик в стороннем компоненте, много раз использованном с неизменным успехом. Слава богу, был найден исходник.
Процедура замены в запросе(S1) параметра(S2) значением(S3) содержала цикл

While pos(s1,s2)>0 do
begin
тут алгоритм замены S2 на S3
end;
Понятно, что цикл необходим для замены всех вхождений S2.

Ошибка теоретически простая - не гарантирован выход из цикла. А с точки зрения "практика" все замечательно - многократно успешно тестировалось и использовалось в реальных проектах.
Если программист не замечает, что при S2 = S3 цикл не закончится, то и при тестировании проверить такой вариант он не додумается.

Чем более распостраненный алгоритм мы реализуем и чем более ответственны приложения, для которых он предназначен, тем более строго необходимо подходить к его проектированию и программированию.


№ 75   02-11-2007 20:10 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 74« (Павел Трубаев)
___________________________

Вы задаете вопросы ответы на которые я не знаю. :)

Но могу сказать определенно что ваше утверждение из »сообщение 60« неверно:

... Ведь единственно верный способ проверить алгоритм или программу - это ввести их в компьютер и запустить на компиляцию/выполнение. Работает - значит, все верно. ...


Верный способ проверить алгоритм или программу это формально доказать правильность или ошибочность его (ее). Всегда ли это возможно - незнаю. Единственный ли это способ - не знаю.

Работает это не значит - все верно. Вы ничего не можете сказать о поведении программы за пределами тестовой области. Протестировать программу это значит сказать что мы сделали для поиска ошибок все что смогли (и то что было определено как достаточное), но не более того.

Не зря же с каждым коммерческим продуктом идет отказ от гарантий.


№ 74   02-11-2007 18:25 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 73« (Дядя .СЭМ)
___________________________


Следствие из первой части этого раздела: Тестирование программ может служить для доказательства наличия ошибок, но никогда не докажет их отсутствия!


Ну, что тестирование всех ошибок не выявит, это и ежику без доказательств ясно, тем более мне. Здесь вопрос в другом - способ проверки реальных программ. Ну, той же Delphi, на которую ссылалась немного выше Панда.



№ 73   02-11-2007 17:57 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 67« (Павел Трубаев)
___________________________


Кстати, в ISO/IEC 12207:1995 «Information Technologies - Software Life Cycle Processes» в качестве доказательства правильности работы программ упоминается только тестирование.

Если меня доказательно опровергнут, буду рад изменить свое мнение.

Цитата из У. Дал, Э. Дейкстра, К. Хоор, Структурное программирование. .пер. с англ. М.:"МИР", 1975, стр. 13:

Следствие из первой части этого раздела: Тестирование программ может служить для доказательства наличия ошибок, но никогда не докажет их отсутствия!


Почитайте, может и убедит.


№ 72   02-11-2007 17:46 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 15« (Geo)
___________________________

Во времена Delphi 1 была замечательная книга для чайников: детективная история про Эйса Брейкпойнта, который всю жизнь мечтал стать частным детективом, а стал нетрадиционным программистом (не помню ни названия, ни автора; если кто помнит назовите плиз).


Дж. Дантеманн, Дж. Мишель, Д. Тейлор, Программирование в среде Delphi./пер. с англ. - К.: НИПФ "ДиаСофт Лтд.", 1995.

указанная в »сообщение 25« книга это продолжение приключений Эйса Брейкпойнта.


№ 71   02-11-2007 16:55 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 69« (panda)
___________________________



Как Вам http://qc.codegear.com/wc/qcmain.aspx?p=10 ?
Это продукт, который хорошо тестируется. Ну и где его правильность (отсутствие дефектов)?


Тут я применю прием "доказательство от противного" - а как доказать правильность этого продукта математически? И если пробежать по темам этой ссылки, какой из багов вызван некорректным алгоритмом (отсутствием у программистов алгоритмической грамотности)? Все дело в том, что программирование в основе этого продукта относится не к научно-алгоритмическому, а к программной инженерии. И методы прикладной (вычислительной) математики здесь уже не подходят.

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




Ответ на »сообщение 67« (Сергей Перовский)
___________________________

Знаете, сам сталкивался с необходимостью обеспечить надежность своих расчетов, потрудится пришлось немало. У меня один из проектов связан с оптимизацией расхода сырьевых материалов, а там ошибешься, и весь завод на брак будет работать. А так как расчеты довольно сложные, а главное, многовариантные, ошибку отловить очень трудно. А найдешь, исправишь ее, в другом месте что-то вылезет. Так что я думаю, тестирование должно лежать целиком на разработчике. Он один знает все ньюансы и может найти слабые места.  Все комбинации, конечно, не проверишь, здесь главное определить наиболее критические. И еще, я обязательно делаю в программе дополнительную, независимую от основной методики, проверку полученных результатов на достоверность, соответствие исходным данным и всем заданным требованиям.


Ну а по теме, я думаю, что в основе как программирования, так и работы с компьютером, находится приобретенный человеком опыт. Это ни в какой книге не опишешь.

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

Поэтому лучшая книга по программированию - это хорошая система помощи с примерами (вроде TP7 или D7) и возможность изучить исходные коды по интересующей теме. И плюс - хорошая математическая подготовка для ясности мышления.


№ 70   01-11-2007 17:05 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 69« (panda)
___________________________
Это продукт, который хорошо тестируется Да, но тестируется он пользователями :)
 Cep


№ 69   01-11-2007 12:46 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 67« (Павел Трубаев)
___________________________

Кстати, в ISO/IEC 12207:1995 «Information Technologies - Software Life Cycle Processes» в качестве доказательства правильности работы программ упоминается только тестирование.

Если меня доказательно опровергнут, буду рад изменить свое мнение.


Как Вам http://qc.codegear.com/wc/qcmain.aspx?p=10 ?
Это продукт, который хорошо тестируется. Ну и где его правильность (отсутствие дефектов)?


<<<... | 78—69 | 68—59 | ...>>>
Всего сообщений в теме: 88; страниц: 9; текущая страница: 2


Добавить свое сообщение

Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
Функция может не работать в некоторых версиях броузеров.

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования