Насколько вообще полезно изучение книг?

Добрый день

А насколько вообще полезно изучение "книг"? (бумажных сейчас вряд ли, поэтому в кавычках) Ну или вообще, теории? Вот мой личный опыт/мнение

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

По содержанию заметны типовые варианты. Напр "фундаментальные знания". Кстати когда инета не было - "заходило" намного лучше (тот же Вирт). Должен ли нормальный программист знать алгоритмы сортировки? Смутно помню "пузырьковая" и "шейкер", но только названия, по сути знаю только "быструю" что пришлось когда-то писать. Ну вот совершенно тупой подход: освоить std::sort без всяких философий. Чем это плохо? Что мы теряем, и не являются ли все эти чтения чисто понтами? По моим наблюдениям в 98% случаев std::sort прекрасно проходит, никакие фундаментальные познания не нужны. Хотя 2% есть, напр косячат с транзитивностью. Из той же оперы дерево - та запомнил просто что std::set - красно-черное дерево, дежурное O = log(N) - и вся любовь. А если кто доклепается, то всегда можно задавить типа "профессионал не должен тратить свое время на такие детали". "Потому что работы очень много" (Ваня). "Коллеги не поймут" и.т.п.

Другая категория - эффективная разработка программного обеспЕчения. Здесь надо спокойно относиться к само-восторгам типа "какую крутую систему мы сделали!". Как и к упоминаниям о SmallTalk, Ada и, оказывается, Мухтар-то ..собака! Если научиться гонорировать всю эту хрень - такие книги бывают совсем не плохи. Иногда я замечал что они рассказывают вещи к которым я приходил через долгий (и не безошибочный) опыт. Так может внимательно посмотреть что еще говорят (типа "учиться на чужих ошибках")? Увы, это не работает.

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

В общем

С бумагой в стране напряженка

0

Сообщение от steelcraft Регулярно общаюсь с такими из числа научных сотрудников. У них принципиально иной взгляд на разработку, чем у программистов, создающих продукт. Типичное мнение: "работает - и ладно".

Это очень сильно зависит и от человека, и от целей: и "программирующие специалисты" могут писать действительно качественный код, и "просто программисты" - в стиле "х... и в продакшн".

0

Сообщение от Pphantom и "программирующие специалисты" могут писать действительно качественный код,

Безусловно, могут; я даже навскидку могу привести пару примеров: Adam Dunkels (создатель "протопотоков", операционной системы Contiki, стека lwIP и множества других ништяков) и Miro Samek (разработчик фреймворка Quantum Platform и автор нескольких потрясающих книг, раз уж за них зашла речь). Но в большинстве случаев практика все же показывает, что скорее нет, чем да.

Сообщение от Pphantom и "просто программисты" - в стиле "х... и в продакшн".

Тут, к сожалению, примеров неизмеримо больше.

0

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

Сообщение от steelcraft Тут, к сожалению, примеров неизмеримо больше.

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

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

0

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

Допустим Вы получаете такое задание или (что более вероятно) возникает такая подзадача. Варианты

1. Отказываетесь это выполнять мотивируя тем что это не царское/программистское дело. Возможно советуете начальству обратиться к профессиональным математикам

2. Пытаетесь решить занимаясь самообразованием и/или обращаясь за помощью к друзьям/коллегам

3. Ваш вариант

Ваши действия?

0

Сообщение от Igor3D Ваши действия?

Зависит от требований.

Пытаюсь сделать, как умею, используя мои знания математики. То есть, примитивный Гаусс вместо p-адических чисел и Миллер-Рабин вместо (не знаю, что там придумали математики).

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

0

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

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

Сообщение от Pphantom если их не заставлять этого не делать.

Я ни разу не видел, чтобы принуждение здесь давало плоды.

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

Что касается программиста, для которого код - основной продукт, тут я тоже не вижу смысла принуждать. Гораздо лучше работает селекция, благо исходного материала хватает с избытком. Взял код новичка, сделал конструктивное ревью, подробно обсудил с автором все шероховатости, показал альтернативы. Если зашло - начинаешь работать над его обучением. Если в ответ слышишь "и так работает" - указываешь кое-какеру, в какой стороне находится выход. Толку уже не будет.

0

Сообщение от Igor3D Допустим Вы получаете такое задание или (что более вероятно) возникает такая подзадача.

У меня, например, подобные задачи значительно чаще возникают, чем у "профессионального программиста". Хоть я и упираюсь всеми руками и ногами в сторону baremetal (и "не троньте меня, я - железячник"), все-то знают, что я по образованию — астрофизик, и дергают: то обработку изображений запили, то еще какую-нибудь клиент-серверную дичь.
Обожаю микроконтроллеры: один суперлуп и редкие прерывания, никаких проблем. А на ПК: клиент в несколько потоков, сервер в несколько потоков, да еще и каждый запускается как форк от гипервизора… Благо, хоть народ смирился, что GUI я ни в коем разе не собираюсь. Максимум - "на коленке" сляпанная веб-морда.
А я зачастую на очередной аттестации вопрошаю: а почему мне в "хирш" не зачесть бы и плюсики с форками на гитхабе? Вот здесь, например, 39 форков и 153 плюсика… Считали бы форки аналогом цитат… ☺

0

Сообщение от steelcraft Сам этот код больше никому не нужен, важен результат, который он выдает. Этот результат будет опубликован в статье/доложен на конференции/включен в диссертацию, и код уйдет в архив.

Это не так, причем сразу по нескольким причинам. Например, коды в науке зачастую оказываются очень долгоживущими, их используют (и, естественно, адаптируют) десятилетиями. А в последние лет 10-20 достаточно стандартной практикой стало написание пакетов или фреймворков, которые используют не только и даже не столько их разработчики, сколько другие исследователи. Очевидно, что и то, и другое приводит к необходимости качественной разработки.

Сообщение от steelcraft Что касается программиста, для которого код - основной продукт, тут я тоже не вижу смысла принуждать. Гораздо лучше работает селекция, благо исходного материала хватает с избытком.

Я не имел в виду принуждение в буквальном смысле слова. Просто даже желание как-то улучшать качество должно чем-то стимулироваться. Вариант "не работать с тем, кто не понимает" - тоже метод.

0

Сообщение от Igor3D Боюсь что формализация таких понятий как "программист" или "фреймворк" заведет наше обсуждение туда "куда Макар телят не гонял"

Чего там формализовать? Пишет программы - значит программист. Дальше уже можно классифицировать какой это подвид программиста - по языкам делить, по решаемым задачам, системный там, или прикладной, или embedded - десятки разных подвидов можно придумать. Но в целом программист он и есть программист.

Сообщение от Igor3D Разработать свой фреймворк - ну а кому он нафиг нужен и кто его купит? А уж люди мнящие себя "генераторами идей" - это головная боль. Обычно такой кадр ни хрена не знает и ни хрена не умеет, но почему-то уверен что тупые программисты (обезьяны) должны/обязаны реализовывать его гениальную идею.

Странный вывод. Генератором идей может быть например опытный программист, которых набил шишек на существующих решениях и придумал новый фреймворк, решающий эти проблемы.

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

Ну книги могут быть, а могут и не быть источником креатива. Из них можно получить необходимые знания, в процессе изучения чего то могут возникать идеи и т.д. Но книгами все не ограничивается. Идеи могут приходить и в процессе работы, как у вышеупомянутого опытного программиста. Так что книги - один из источников, не более.

Добавлено через 6 минут

Сообщение от steelcraft У "программирующего специалиста" нет мотивации писать чистый код.

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

Добавлено через 1 минуту

Сообщение от steelcraft Что касается программиста, для которого код - основной продукт

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

0

Сообщение от Shamil1 Пытаюсь сделать, как умею.. Если ... не удовлетворяет требованиям, то начинаю изучать математику.

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

Сообщение от steelcraft Взял код новичка, сделал конструктивное ревью, подробно обсудил с автором все шероховатости, показал альтернативы. Если зашло - начинаешь работать над его обучением. Если в ответ слышишь "и так работает" - указываешь кое-какеру, в какой стороне находится выход.

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

А вот дальше, с достаточно опытным программистом - нет. По сути опять все упрется в предметную часть.

Сообщение от Shamil1 Настоящие идеи от настоящих программистов вполне востребованы (среди тех, кто в состоянии их понять).

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

Все зависит от каждого индивидуума в отдельности. Одни из вас играют хорошо, другие играют плохо. И никакие лекции не изменят этого соотношения сил.

0

Сообщение от Igor3D А насколько вообще полезно изучение "книг"?

Книги - способ хранить и передавать информацию (накопитель). Соответственно, полезность определяется содержимым и читающим содержимое.

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

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

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

0

Storm Screamer, у Кнута есть отличная книга "Все про ТеХ". Можно, конечно, Львовским обойтись, но чтобы стать настоящим ТеХником - только Кнут. А без латеха пытаться писать техническую литературу - мазохизм чистой воды. А вот "Искусство" кнутовское - да, дрянь та ещё. Но не будь "искусства", не было бы и теха - жизни бы не было!
Что до Страуструпа, мне 20+ лет назад отлично понравилось, и задания интересные. Но таки потом я полностью на С перешёл, а сейчас, видя, в какую дрянь превратили С++, понимаю, что кроме С (и ТеХ, конечно) никакого ЯП я больше никогда не буду осваивать - бессмысленно.

0

Сообщение от Eddy_Em А без латеха пытаться писать техническую литературу - мазохизм чистой воды.

С учетом особенностей деятельности, этим занимается 1.5 землекопа.

Сообщение от Eddy_Em не было бы и теха - жизни бы не было!

Вы фанатик, похоже. Тот самый академический фанатизм.

Сообщение от Eddy_Em никакого ЯП я больше никогда не буду осваивать - бессмысленно.

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

0

Storm Screamer, если вы вместо того, чтобы за день получить прекрасно сверстанную статью, тратите на "верстку в Ворде" неделю - это ваш собственный мазохизм, как и неовладевание слепым набором или использование игровой прошивки вместо операционной системы!
Что до ЯП, если вдруг появится достойная замена С, я готов. Но только где она, замена эта? Уже сотню недоЯП придумали, а софт и ядра ОС как писали на С, так и пишут. Разве что всякое гуишное убожество иногда ещё и на С++ пишут.

0

Сообщение от Storm Screamer Вы фанатик, похоже.

Похоже?

Сообщение от Eddy_Em тратите на "верстку в Ворде" неделю - это ваш собственный мазохизм

Тут понимаешь в чём дело. Если ты не знаешь нормально ворд, то потратишь на верстку неделю. А если не знаешь тех - то вообще никогда не напишешь. Ну а если знаешь, то напишешь быстро и легко.

0

Сообщение от Eddy_Em за день получить прекрасно сверстанную статью, тратите на "верстку в Ворде" неделю - это ваш собственный мазохизм

Нет, не мой. Я версткой не занимаюсь.

Сообщение от Eddy_Em неовладевание слепым набором

Speech to text в помощь.

Сообщение от Eddy_Em а софт

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

Сообщение от Eddy_Em ядра ОС как писали на С, так и пишут

Да что вы говорите. И много новых ядер ОС вам известно? Каждый год под 10 штук, наверное, выходят. Или может С используется потому что нужна поддержка уже написанных ядер на С. Не приходило в голову?

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

0

Сообщение от Storm Screamer Что касается более конкретного использования книг в профессиональной подготовке, то в начале пути они могут задать структуру знаниям. Помочь выстроить ровный фундамент с четким представлением о изучаемом предмете. Потом, после освоения базы, приходят книги-справочники (или веб-ресурсы справочники), которые используются непосредственно в работе.

Ну что же, вполне разумная точка зрения: книги нужно читать в юношестве/студенчестве, а когда начал работать - гуглить. Роль примерно та же что ВУЗа: аса конечно не сделают, но какой-то толк точно есть.

0

Сообщение от Катафалк Чего там формализовать? Пишет программы - значит программист.

Если провести аналогию со спортом, то бегает - значит бегун?
Футболисты бегают постоянно и делают это хорошо. Самые быстрые футболисты показывают результат на уровне мастера спорта в беге на 100 метров. Тем не менее, умение бегать не является главным в их профессии.

Сообщение от Катафалк Все это исключительно религиозные верования, что якобы "чистый код" приводит к более качественному продукту, меньшему количеству багов и т.д.

Чистый код проще читать и исправлять. А более качественный продукт и т.п. - это уже следствие.

Сообщение от Катафалк Код это всегда инструмент решения какой-то задачи, а не самоцель.

Профессионала как раз и отличает хорошее владение инструментом.

0

Сообщение от Igor3D Ну вот совершенно тупой подход: освоить std::sort без всяких философий. Чем это плохо? Что мы теряем, и не являются ли все эти чтения чисто понтами? По моим наблюдениям в 98% случаев std::sort прекрасно проходит, никакие фундаментальные познания не нужны

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

0

Сообщение от Shamil1 Если провести аналогию со спортом, то бегает - значит бегун?

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

Сообщение от Shamil1 Чистый код проще читать и исправлять. А более качественный продукт и т.п. - это уже следствие.

Есть такое. Но не все это понимают. Что чистый код это не самоцель, а лишь инструмент. И тратят кучу времени и ресурсов на "очистку", когда это вообще ни разу не нужно. Программисту дай волю, он утонет в бесконечных рефакторингах для "очистки", при этом каждый ещё и будет переписывать код соседа, потому что понятие чистоты не формализовано и каждый понимает по своему. А что там при этом будет с продуктом, их вообще не интересует, до тех пор пока не придёт начальник и по голове не настучит.

Сообщение от Shamil1 Профессионала как раз и отличает хорошее владение инструментом.

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

0