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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

Прочтение материалов <Деньги на ветер> и <За что я не люблю Архангельского> навело на некоторые мысли по поводу современного состояния издания программистских книг. Предлагаю обсудить состояние дел в этой отрасли. Для начала свои комментарии, замечания.
Первое.
Все книжки, выходящие на данный момент можно разделить на такие группы:
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 сообщений

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

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


№ 88   Удалено модератором


№ 87   04-12-2007 14:26 Ответить на это сообщение Ответить на это сообщение с цитированием
Прочитал я сей роман еще раз и удивился. Народ (возможно, и я в том числе) от жиру бесится. И это сущая правда!
В первые месяцы появления Delphi (конец 1994 - начало 1995 года и почти все лето 1995 года) почти ни одной книжки по Delphi не было. И когда моя сотрудница прибежала с вытаращенными глазами, глотая слова, стала рассказывать, что она видела книжку по Delphi, мы немедленно ей выдали деньги и отправили в магазин. Тогда речь не шла о качестве. Любая книжка помимо документации была как глоток воздуха. В основном знания черпались из консультаций с фирмой, сотрудничавшей с Борландом. Спасибо им!
Сегодня только дурак не сможет подобрать книжку для изучения среды Delphi, освоения приемов разработки программ на Delphi, познания технологий Delphi-программирования. Так что не рассчитывайте на шедевр - Delphi в целом освещен в литературе весьма подробно и почти во всех аспектах. А так, чтобы все это собрать в одной книге - дак это глупость. Не может такой океан технологий поместиться в одной книге.

Но водятся и другие крайности.
Существует и процветает среда, называется SAP R3. Рынок перегрет, стоимость бешеная, сотни гигабайт весит. А вот литературы - почти круглый ноль!!! По программированию ABAP (язык такой в ней есть) издана всего одна книжка в 1999 году! Она уже перекопирована многократно, но никто с тех пор не осмелился переиздать эту книгу. Так и продается в первоначальной редакции, хотя сама среда SAP уже претерпела несколько версий. Вот где голод настоящий! Недавно в интернете нашел библиотеку компонет Delphi для доступа к SAP (Автоматизацию-то SAP поддерживает!). Не сразу обратил внимание, а потом глянул - ба! да это тот же 199х год! Т.е. и тут с потрохами выдрали грибное поле!

К чему я это?
На рынке IT-технологий иногда действуют довольно странные на первый взгляд законы. И надо радоваться, что для счастливых Delphi-цев море литературы. Спасибо их авторам, хорошим и не очень.
Будьте счастливы!


№ 86   Удалено модератором


№ 85   13-11-2007 03:14 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 84« (panda)
___________________________

Вы знаете, мы ведь об одном и том же говорим. Я то же считаю, что проверять программы надо всеми возможными способами, и верификацию кода делать, и тестировать, и все это субъективно и от всех ошибок не избавит. Просто в разных задачах разные нюансы этой проверки и единственного алгоритма для проверки нет. Вы работаете в команде, я свои задачи делаю индивидуально, поэтому у нас и немного разные предпочтения. Но несмотря на предпочтения, есть система ГОСТ и ISO по оценке качества программных средств, где тестирование является обязательным и единственным доказательством правильности работы готовой программы. Да и есть мнения отдельных уважаемых людей, например "Когда один программист пытается убедить другого в правильности своей программы, он обычно прибегает к помощи тестов" - Дж. Бентли, Жемчужины программирования.

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

А разные формальные определения, что бы не выдумывать своего, есть, например, в ГОСТ 28806—90 "Качество программных средств. Термины и определения".

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

Но, еще раз повторяю, все сказанное выше мое скромное мнение, хотя и подтвержденное рядом авторитетных источников. С ним можно соглашаться или не соглашаться. Самое главное в программах не как их проверяют, а что бы они работали.

Мне кажется, надо дискуссию прекращать, так как за последнее время ничего конкретного из разговоров "не родилось".

Кстати, возвращаясь к теме БП. Есть очень хорошее издание В.А.Кирьянчиков, Э.А.Опалева.  Качество и надежность программного обеспечения (для программы UPROG подготовки магистров для фирмы «Моторола»). Конспект лекций. СПб.: СПбГЭУ (ЛЭТИ), 2002.


№ 84   12-11-2007 23:43 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 83« (Павел Трубаев)
___________________________

Если у Вас есть другие определения, пожалуйста, приведите, мне это, правда, очень интересно.
Формального определения нет. Я обычно оперирую фразой "к тестированию относятся ...".

Code Review, как и проверка листинга автором, обладает большим недостатком - субъективностью, то есть зависит от квалификации, опыта работы, настроения и т.д. автора или проверяющего. Да и представьте два монолога у заказчика при сдачи проекта:
Вы не поверите, но традиционное тестирование - столь же субъективно ;-)
Чтобы подобрать действительно хороший набор входных данных для сложной системы, надо обладать некоторым талантом.

1. "Мы проверяли неоднократно программы (следует список с регалиями авторов  и проверяющих) - все верно".
Э... я вроде нигде не утверждал, что для тестирования программы достаточно только code review.

2. "Давайте зададим Ваши данные и проверим результаты".
Не знаю, как у других, а у меня обычно "катит" второй вариант.

Я рад за вас. У меня ситуация несколько иная. Код должен пройти review, автоматическое модульное и функциональное тестирование, ручное тестирование (имитацию работы пользователя).


№ 83   12-11-2007 18:01 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 82« (panda)
___________________________

Под тестированием я понимаю следующее.

"ТЕСТИРОВАНИЕ ПРОГРАММЫ — способ семантической отладки программы, заключающийся в том, что программе предоставляется для обработки последовательность различных контрольных наборов данных (тестов), результат обработки которых известен. Так как полное, исчерпывающее Т.п. (т. е. гарантирующее правильность программы) невозможно, то тесты подбирают так, чтобы программа в процессе работы охватила как можно больше различных типов ситуаций обработки. ... В нек-рых случаях, кроме Т.п., применяется верификация, т. е. доказательство правильности программ." - Словарь по кибернетике. Киев: УСЭ, 1989 (подготовлен институтом кибернетики им. Глушкова).

Если у Вас есть другие определения, пожалуйста, приведите, мне это, правда, очень интересно.

Code Review, как и проверка листинга автором, обладает большим недостатком - субъективностью, то есть зависит от квалификации, опыта работы, настроения и т.д. автора или проверяющего. Да и представьте два монолога у заказчика при сдачи проекта:

1. "Мы проверяли неоднократно программы (следует список с регалиями авторов  и проверяющих) - все верно".

2. "Давайте зададим Ваши данные и проверим результаты".

Не знаю, как у других, а у меня обычно "катит" второй вариант.

Ну а соотношение стоимости ошибки (в денежном выражении) от стадии ее обнаружения зависит от вида задач. Например, возьмем распространенные у нас системы "Зарплата/Накладные/Склад/т.д. т.п.". Сейчас у нас уже нет городков, где не работают конторы по разработке таких систем. В них объем математического обеспечения (алгоритмов, формул, зависимостей, структур данных) во много раз  меньше объема выходных данных. Поэтому здесь легче проверять код, чем результаты. А в инженерных расчетах и моделировании, наоборот, имеется небольшое количество результатов при огромном объеме алгоритмов. При этом сами алгоритмы, в отличие от бухгалтерских задач, не определены и при разработке программ главное - это как раз найти, создать, отладить алгоритмы, а не переложить известные алгоритмы в программный код.

Подитоживая, я еще раз приведу свое мнение. Есть теоретическая фундаментальная подготовка - Высшая математика, вычислительная математика, теоретические дисциплины информационных специальностей. Это, без вариантов, необходимо для формирования квалифицированного специалиста. Но программирование, по моему скромному ИМХО, это практическая дисциплина, которую по бумажкам и книгам не изучишь. Здесь главное - практика.


№ 82   06-11-2007 00:40 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 71« (Павел Трубаев)
___________________________

а как доказать правильность этого продукта математически?
Это теоретически возможно ;-)
На практике, понятное дело, неприменимо. Но я хотел сказать, что тестирование - не панацея. Особенно то, тестирование, на которое упираете Вы (я так понял, что Code Review Вы за тестирование не считаете).

И утверждение, что современный программист должен уметь логически или математически доказывать правильность своих алгоритмов, для разработки сложных систем неактуально.
Скажите, Вы когда-нибудь работали в команде, выпускающей коммерческий продукт? Если да, то была ли у вас зависимость стоимости ошибки (в денежном выражении) от стадии ее обнаружения? Мой опыт вполне коррелирует с тем, что описывается в книгах - ошибка, обнаруженная сразу после написания алгоритма, стОит намного дешевле, чем ошибка, найденная при плановом (например, бета-) тестировании.


№ 81   05-11-2007 09:58 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 80« (Павел Трубаев)
___________________________
Про "часто используемые системы". Не нравится Windows, используйте MS(PS)DOS. Там ошибок мало, алгоритмы доказаны.
MS-DOS такой же пример имперического программирования, как и Windows :(
Никто там ничего не доказывал и ошибок в расчете на строку кода не многим меньше.

Это я еще возвращаюсь к тому, что необходимо понимать - предоставляемые возможности всегда обратно пропорциональны надежности.
Более-менее согласен, меня не устраивает коэффициент пропорциональности :)
Причем для ОС надежность гораздо важнее объема предоставляемых услуг.


№ 80   04-11-2007 20:35 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 79« (Сергей Перовский)
___________________________

Но считать, что теории учить не надо...

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

Про "часто используемые системы". Не нравится Windows, используйте MS(PS)DOS. Там ошибок мало, алгоритмы доказаны. Единственно, что практического применения в настоящее время нет. Это я еще возвращаюсь к тому, что необходимо понимать - предоставляемые возможности всегда обратно пропорциональны надежности.


№ 79   04-11-2007 11:36 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 78« (Павел Трубаев)
___________________________
Не зная подробностей, сложно сказать, но может алгоритм и не был расчитан на использование при s2=s3?
Если название корабля случайно совпадет с названием пристани, то корабль не будет тормозить при подходе к ней :)
Ну не расчитывал программист на такое совпадение.

Ведь логически, если s2=s3, алгоритм замены вызывать не надо.
Тут речь как раз о теории. Простейший анализ показывает, что завершение цикла не гарантировано. И, если s2=s3, алгоритм замены вызывать НЕЛЬЗЯ.
Значит требуется соответствующая проверка.
Да, доказать правильность сложного алгоритма дело практически невозможное. Тут необходим баланс. Но считать, что теории учить не надо...
В результате даже такие "часто используемые" программы, как операционные системы, полны недоказанных алгоритмов.
Например, 90% уязвимостей Windows приходится на переполнение буфера, расположенного в стеке. Все это знают и в каждом новом продукте эта ошибка выползает вновь и вновь.


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


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

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

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

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

Перейти на конкретную страницу по номеру
  
Время на сайте: 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» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

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