Comments 182
По поводу книги «Структура и интерпретация компьютерных программ» помню, что в прошлом один хороший человек выкладывал перевод субтитров видео лекций, но по каким то причинам не смог завершить начатое. Первые три лекции находятся тут. А вот тут скорее мертвый, чем живой проект по переводу всех лекций. %username%, как ты думаешь, есть ли смысл объединиться неравнодушным, попробовать довести начатое до конца и тем самым сделать подарок начинающим программистам?
Программисты должны начинать с английского языка, а не с языков программирования
Я с вами полностью согласен, но вопрос не об этом)
Иногда, оценивая качество кода и комментарии к нему, создается впечатление, что все-таки с русского, а не с английского
Когда мне купили первый компьютер (программируемый калькулятор) в третьем классе вся документация (и материалы в СМИ) к которому была на русском, я должен был требовать от родителей, чтобы они меня к нему не подпускали, а отправляли меня английский учить?
С нынешних позиций — конечно, да.
У меня в школе был выбор в 7 классе: испанский или английский. Родители выбрали испанский — как более легкий (я переходил из другой школы, там вообще был французский). Потом я с огромным трудом устраивал себе учебу с этим испанским в ВУЗе и аспирантуре, хоть язык и не последнее место в мире занимает, но оказался ненужной обузой.
Короче, жалею всю жизнь.
У меня в школе был выбор в 7 классе: испанский или английский. Родители выбрали испанский — как более легкий (я переходил из другой школы, там вообще был французский). Потом я с огромным трудом устраивал себе учебу с этим испанским в ВУЗе и аспирантуре, хоть язык и не последнее место в мире занимает, но оказался ненужной обузой.
Короче, жалею всю жизнь.
Вы серьезно? В 10 лет я должен был требовать отдать меня на курсы английского (которых, кстати, не припомню в то время в принципе)? Я, конечно, жалею, что не потребовал и что сам им занимался в то время, только в словари заглядывая, что понять, что такое PRINT GOTO JMP и MOV, а остальное из-под палки для оценки. Но не настолько же.
И вообще, в последнее время появилось много топиков про ИТ-образование (сессия-каникулы?), но что-то никто (ни студенты, ни преподаватели) не утверждал, что студентам программирование надо давать только курсе на третьем, когда английский подтянут.
И вообще, в последнее время появилось много топиков про ИТ-образование (сессия-каникулы?), но что-то никто (ни студенты, ни преподаватели) не утверждал, что студентам программирование надо давать только курсе на третьем, когда английский подтянут.
Ключевая фраза «с нынешних позиций». Тогда же конечно все представлялось иначе. Иными словами, знал бы прикуп…
Речь не о школе или ВУЗе, а о том, что реально нужно чтобы стать профи в программировании.
Английского+желание — достаточно. Все программы как минимум грубо говоря на нём. ООП DB и прочие основы — год, два. А вот в SDK да API ковыряться — всю жизнь (программерскую).
И, кстати да, я как преподаватель, считаю, и в реале наблюдаю, что лучше сразу сходу дать на 3-м курсе сложный, но интересный курсовой (где язык метод, а не цель), чем возиться с циклами да ветвлениями на первых курсах (лентяи все равно не дадут нормально сработаться). А вот постарше — уже толковые мысли у некоторых ребят есть, картинка тогда примерно такая: пробуют в лоб MathCAD (причем сами), скорости явно не хватает, пробуют Mathlab, опять тормоза, но поменьше, затем берут ЯП (тут важно грамотно библиотеки подпрограмм толковые подсунуть) — офигевают от разницы в производительности, и вуаля, программер готов (идеологически). А вот дальше английский нужен кровь из носу.
В условиях Интернета оказалась гораздо важнее не система обучения, а мотивация учащегося. Нагуглить инфу про примитивы (циклы, пп и т.п) — это секунды. В идеале же — обучение это НИС, т.е. сотрудничество со студентами, а не вдалбливание на лекциях очевидных вещей.
Программирование — не наука, а ремесло. Кому интересно, разберутся мгновенно, кому неинтересно — бесполезно даже начинать.
Речь не о школе или ВУЗе, а о том, что реально нужно чтобы стать профи в программировании.
Английского+желание — достаточно. Все программы как минимум грубо говоря на нём. ООП DB и прочие основы — год, два. А вот в SDK да API ковыряться — всю жизнь (программерскую).
И, кстати да, я как преподаватель, считаю, и в реале наблюдаю, что лучше сразу сходу дать на 3-м курсе сложный, но интересный курсовой (где язык метод, а не цель), чем возиться с циклами да ветвлениями на первых курсах (лентяи все равно не дадут нормально сработаться). А вот постарше — уже толковые мысли у некоторых ребят есть, картинка тогда примерно такая: пробуют в лоб MathCAD (причем сами), скорости явно не хватает, пробуют Mathlab, опять тормоза, но поменьше, затем берут ЯП (тут важно грамотно библиотеки подпрограмм толковые подсунуть) — офигевают от разницы в производительности, и вуаля, программер готов (идеологически). А вот дальше английский нужен кровь из носу.
В условиях Интернета оказалась гораздо важнее не система обучения, а мотивация учащегося. Нагуглить инфу про примитивы (циклы, пп и т.п) — это секунды. В идеале же — обучение это НИС, т.е. сотрудничество со студентами, а не вдалбливание на лекциях очевидных вещей.
Программирование — не наука, а ремесло. Кому интересно, разберутся мгновенно, кому неинтересно — бесполезно даже начинать.
Вы шутите, что ли? Программа, написанная студентов в большинстве случаев будет в 10 раз медленней вычислений, который делает маткад.
На велосипедах — да. А к примеру так?
>А вот в SDK да API ковыряться — всю жизнь (программерскую).
Мне хватает своего английского для SDK и API, а книга несколько другое — где автор пытается юмарить на сленге, где даже словарь не всегда поможет. Вот и получается «картинки и таблицы пропускаем, в суть вникаем» (с), только наверно тут наоборот :)
Мне хватает своего английского для SDK и API, а книга несколько другое — где автор пытается юмарить на сленге, где даже словарь не всегда поможет. Вот и получается «картинки и таблицы пропускаем, в суть вникаем» (с), только наверно тут наоборот :)
А я вообще постигал азы Бейсика по урокам с журнала «Наука и жизнь».
В школе было что-то про программирование, по в последних трех классах и без компьютера.
Это заставляло думать и просчитывать все варианты алгоритма в уме.
В университете хоть появился Pascal на компьютерах, но Visual Basic на доске, почти без машинного времени. Потом фортран для спецкурсов.
Книги «Искусство программирования» купил лет 8 назад, когда работал дизайнером полиграфии :)
Сейчас у меня практика в написание скриптов на shell, Perl и PHP.
В школе было что-то про программирование, по в последних трех классах и без компьютера.
Это заставляло думать и просчитывать все варианты алгоритма в уме.
В университете хоть появился Pascal на компьютерах, но Visual Basic на доске, почти без машинного времени. Потом фортран для спецкурсов.
Книги «Искусство программирования» купил лет 8 назад, когда работал дизайнером полиграфии :)
Сейчас у меня практика в написание скриптов на shell, Perl и PHP.
Бэйсик я по манаулу к ПЭВМ «Микроша» учил и исследуя программы с заводской кассеты. Pascal в школе был с 9-го класса под MSX-DOS. В библиотеке книги только по Си были и хорошо учительница нашла-таки где-то дискетку с компилятором для меня, библиотеками и линковщиком (ассемблер уже не помню был или нет). Потом научил её Си немножко, но она сказала другим это давать не будет, с Паскалем-то еле справляются. А я программу для расчёта биоритмов написал и продавал результаты, даже в местную газету объявление дал :)
Да, уж, ностальгия налетела. У меня другая история. ПК собирал сам, тогда был выбор: Радио-РК-86, синклер-ленинград (тренд), Орион-128. Последний был по железу самый продвинутый, но совершенно без софта. Пришлось на бумажке ваять на асме дизассемблер+отладчик, переводить ручками в коды, получилась программулина на 4 килобайта. Это было моё первое… По молодости да сдуру. Зато после этого ЯП высокого уровня — это было просто, весело и приятно.
Не в наших краях выбор был, помнится на КР573РФ2, чтоб хотя бы с Радио-86РК совместимый был, чуть ли не всё лето работал.
У меня хоть со скрипом но подошли ASM и DASM от 86-го. Первые прогу что написал на ASM была расчёт CRC по способу 86-го, чтоб проверить, что с журнала всё правильно ввёл :)
Ага, увидишь новую конструкцию, представишь как она в машкодах реализуется и понятно куда её ставить, куда нет. Ну это образно, конечно.
У меня хоть со скрипом но подошли ASM и DASM от 86-го. Первые прогу что написал на ASM была расчёт CRC по способу 86-го, чтоб проверить, что с журнала всё правильно ввёл :)
Ага, увидишь новую конструкцию, представишь как она в машкодах реализуется и понятно куда её ставить, куда нет. Ну это образно, конечно.
Мой первый комп бк0010ш. И уже следующий Радио86РК(сборка дяди при моем участии). Синклеровский появился еще несколько позже.
Большую часть жизни учил английский. Пригодилось конечно, но только как разработчику. В человеческом общении английский тоже был уместен — но были трудности от незнания французского (решено путем изучения в минимальном необходимом объеме). Теперь когда предстоит освоить кое что полезное на Кубе, мне как-то стало неуютно без испанского (интересно, а на сколько его можно усвоить до лета?).
Это я к тому, что помимо программирования в жизни есть много интересных вещей, и сожалеть о том что учил не тот язык как-то странно на мой взгляд.
З.Ы. Есть тут коллега который усвоил технический английский за полгода — по бразильской системе :)
Это я к тому, что помимо программирования в жизни есть много интересных вещей, и сожалеть о том что учил не тот язык как-то странно на мой взгляд.
З.Ы. Есть тут коллега который усвоил технический английский за полгода — по бразильской системе :)
Я сожалею, что не учил, когда учили :(
мне как-то стало неуютно без испанского (интересно, а на сколько его можно усвоить до лета?).
У меня за месяц экспресс-курса (пять дней в неделю по два академических часа) получилось выучить от уровня «звучит приятно, но ничего непонятно» до «могу объясниться в кафе/отеле». Главное — не забивать на домашние задания.
Жалеть о полученных знаниях, да ещё и «всю жизнь» — довольно странная позиция, не находите?
Нет абсолютно никаких препятствий к тому, что бы знать больше одного иностранного языка.
Английский до уровня «читать техническую литературу» и вовсе можно выучить по методу «берём словарь и ищем непонятное слово».
Нет абсолютно никаких препятствий к тому, что бы знать больше одного иностранного языка.
Английский до уровня «читать техническую литературу» и вовсе можно выучить по методу «берём словарь и ищем непонятное слово».
Не соглашусь. Сейчас вполне достаточно переведенной литературы и источников на русском.
Когда у меня появился компьютер и я начал программировать, все что я смог найти на русском 2 книги: 1 по Бэйсику, одна с алгоритмами. У меня до сих пор 2 параллельных английских языка, «компьютерный» и «разговорный» с абсолютно разным произношением.
На мой взгляд на начальном этапе изучения программирования, отсутствие знания языка, позволяет легче абстрагироваться. Не отождествлять if, then, else и прочие со словами лингвистическими. Всегда с ужасом смотрел на программы на 1С Бэйсике с русским синтаксисом.
Если пытаться достичь высот, то английских язык разумеется необходим, впрочем как и в других областях знаний.
Когда у меня появился компьютер и я начал программировать, все что я смог найти на русском 2 книги: 1 по Бэйсику, одна с алгоритмами. У меня до сих пор 2 параллельных английских языка, «компьютерный» и «разговорный» с абсолютно разным произношением.
На мой взгляд на начальном этапе изучения программирования, отсутствие знания языка, позволяет легче абстрагироваться. Не отождествлять if, then, else и прочие со словами лингвистическими. Всегда с ужасом смотрел на программы на 1С Бэйсике с русским синтаксисом.
Функция КвадратЧисла(прЧисло)
Возврат прЧисло * прЧисло;
КонецФункцииЕсли пытаться достичь высот, то английских язык разумеется необходим, впрочем как и в других областях знаний.
Не соглашусь. Время затраченное на обучение языку прямопропорционально недополученному опыту в разработке. Английский нужен, спору нет, да вы без него и не сможете начиная с определенного уровня, но до него огого расти как надо
думаю, что были бы благодарны
У SICP существует полный перевод на русский язык.
Книжка же есть. Или в лекциях все тоже самое, только попроще для усвоения? Тогда, безусловно — смысл в этом есть. :)
Я думаю стоит, а то, действительно, энтузиазма одного человека не хватит для перевода такого количества текста. Этого энтузиазма не хватило ни первому переводчику, ни Sahon'у (тобиш мне).
Открывая топик, ожидал увидеть «Совершенный код» Стива Макконнелла. Не ошибся.
Предполагал Кормена и Макконелла на первых местах.
А оказывается даже «Язык программирования C» Кормена обогнал.
А оказывается даже «Язык программирования C» Кормена обогнал.
Читал только Совершенный код и Керниган-Ритчи :(
А можно их архивчиком и ссылку? А то уже раз пять порывался, а так и не взялся читать.
Мне кажется архив вам не поможет
Вы, конечно, извините, но вам не стыдно такое просить?
1) Эти книги не бесплатные. Обычно каждый сам решает этот вопрос: качать или купить. Обычно на Хабре скромно умалчивают, когда скачивают нелегально.
2) Хотите чтобы кто-то за вас сделал архив и выложил нелегально?
3) И вооще это 10-минутное дело.
4) Если вам лень потратить эти 10 минут, то и читать тоже не будете.
5) И пользоваться гуглом не сложнее, чем писать комментарии, попробуйте.
1) Эти книги не бесплатные. Обычно каждый сам решает этот вопрос: качать или купить. Обычно на Хабре скромно умалчивают, когда скачивают нелегально.
2) Хотите чтобы кто-то за вас сделал архив и выложил нелегально?
3) И вооще это 10-минутное дело.
4) Если вам лень потратить эти 10 минут, то и читать тоже не будете.
5) И пользоваться гуглом не сложнее, чем писать комментарии, попробуйте.
Помимо SICP еще и HtDP стоит почитать.
Читал-читал-на полке-читал-читал, хм, круто!
знал, что тут будет Кормен)
вот только стоит читать либо оригинал, либо первое издание — во втором кривой перевод
вот только стоит читать либо оригинал, либо первое издание — во втором кривой перевод
Кнут в пятерку не попал — я удивлен.
Посмотрим правде в глаза. Много ли людей вы знаете, которые действительно прочитали Кнута, а не только купили его?
А теперь возьмем Кормена.
Нет, я не устраиваю холивар, просто Кнут значительно более сложная книга и всем бы я его точно не рекомендовал.
А теперь возьмем Кормена.
Нет, я не устраиваю холивар, просто Кнут значительно более сложная книга и всем бы я его точно не рекомендовал.
Кнут тот еще тролль.
Помнится, странице на тридцатой первого тома он предлагал читателям доказать Великую теорему Ферма.
Помнится, странице на тридцатой первого тома он предлагал читателям доказать Великую теорему Ферма.
Говорят «программисты делятся на тех кто читал Кнута полностью, и тех кто говорит правду»)
Кнут вызывает ощущение археологического копания в окаменевших останках. Культовая книга, но для ушедшего поколения, работавшего с IBM-360. Кормен более живой.
Не соглашусь. Искусство программирования — фундаментальный труд направленный в первую очередь на довольно узкий круг специалистов занимающихся анализом или разработкой алгоритмов, в том или ином виде. Устаревать там в общем-то и нечему. Кормен и компания — больше походит на справочник по алгоритмам для прикладников. Как он может быть «более живым» ума не приложу.
Согласен! Кроме этого Кнут периодически выпускает «апдейты»/«патчи» к своим книгам, так что, думаю труды этого великого программиста будут читать еще очень долго, ну, может и счастливо)
«Более живой» — это я о читабельности. Собственно, тут речь о субъективных ощущениях от процесса чтения, так что я не буду развивать тему.
Использование Кнутом ассемблера для изложения алгоритмов существенно затрудняет понимание алгоритмов. Изложение стоит переписать на С-подобный язык — но Кнут вряд ли будет это делать.
Там есть, конечно, неактуальные ныне вещи, вроде оптимизации структур данных для хранения на магнитных лентах, но в основном вещи базовые.
Базовые, да. Но было чувство, будто написано для уже знающих эти базовые вещи, и знающих глубоко. Я читал Кнута во студенчестве двадцать пять лет назад.
А от Кормена впечатление совсем другое: ликбез по верхам тем, не углубляясь, шло легко, алгоритмистам, наверное, скучно, а для развития кругозора — в самый раз.
А от Кормена впечатление совсем другое: ликбез по верхам тем, не углубляясь, шло легко, алгоритмистам, наверное, скучно, а для развития кругозора — в самый раз.
Так и скажите, что не осилили
Книга может плохо идти не только потому, что у читателя нехватает мозгов осилить. Она может быть, например, написана тяжелым корявым языком, как перевод первого издания Страустрапа. Или рассказывать о вещах, которые данному читателю не актуальны.
«тяжелым корявым языком» частный случай «нехватает мозгов осилить» :)
Я лично кнута как справочник по алгоритмам использовал. Лучших сборник алгоритмов, который я читал. Читать от корки до корки и в мыслях не было :)
Да и еще плохо то, что SICP на русском уже не найти, а на английском заказывать накладно и долго ждать, да и книга для начинающего и начинающему даже с хорошим знанием английского будет трудновато что-либо понять.
UFO just landed and posted this here
Искусство программирования, а также «Книга Дракона» — однозначно глубже перечисленного
Чем они «глубже»? Абсолютно разные книги, нацеленные на абсолютно разную аудиторию. Причем аудитория у «Искусства прогроммирования» и «Компиляторов» гораздо уже, чем у того же «Совершенного кода». В названии списка есть слова «которую должен прочесть каждый разработчик программного обеспечения». В этом плане, например, для среднестатистического программиста, Кормен гораздо «полезнее» Кнута.
Тут не об аудитории речь, а о влиянии на ход мысли программиста. Обе книги — самая база. Глубина заключается в умении строить алгоритмы у первой, и понимании принципов работы инструмента программиста у второй. Я говорю за себя, какие книги произвели сильнейшее впечатление. Кормен — это набор рецептов, а Кнут — это инструкция к созданию своих.
Ну, в статье речь как раз о аудитории, о чем говорят слова «каждый разработчик». Стоит ли читать каждому разработчику «Искусство программирования»? По-моему, ответ нет, не стоит. Это гораздо более узкоспециализированная литература. Требующая как минимум неплохой математической подготовки. Поэтому к этой монографии и слово «читать» вообще не совсем подходит. Это «Совершенный код» я читал в свободное время перед сном. С Кнутом это вряд ли удастся. И я не соглашусь, что для рядового разработчика «Искусство программирования» станет полезней, чем тот же «Совершенный код». Я долго занимался олимпиадным программированием, где алгоритмы играют значительную роль. Кормен и компания для меня были гораздо полезней, хотя отдельные главы Кнута я тоже с большой пользой изучил. «Я говорю за себя, какие книги произвели сильнейшее впечатление.» у меня ощущение, что мы Достоевского или Джойса обсуждаем. Я не могу себе представить человека прочитавшего от корки до корки все доступные тома «Искусства программирования», по-моему, в этом просто нет смысла :)
А вообще все это напоминает какой-то форсед-мем. Безусловно, все слышали о «Искусстве программирования», но далеко не все имеют представление, что там вообще внутри. Может тому виной название монографии. Я семестр назад заменял препода и читал лекции по ООП, предложил интересующимся рассмотреть некоторые темы в соответствующей литературе, на что из аудитории последовал вопрос «А Исскуство программирования в качестве литературы пойдет?».
Книга Дракона хороша, но уже довольно специализирована.
UFO just landed and posted this here
Интересно, что топик называется «прочитать должен каждый разработчик ПО», но странно почему в этот список попадают книги по C/C++. Это очень неправильно судить что, все разработчики ПО должны его знать. Я хоть и являюсь разработчиком ПО, но С/C++ знаю постольку поскольку я его не изучал подробно и не писал на нем, т.к. как мне он все таки не нужен. полагаю в данном списке должны быть книги только по общим принципам в программировании, которые можно приложить ко всем или хотя бы к большинству «живых» языков программирования. а так это список для программистов C/C++.
Согласен. Для этого хорошо подходит SICP, а Scheme выбран там чисто как самый наглядный и простой язык. Обеими руками за SICP – ее должен прочитать каждый!
C/C++ в программировании — это что-то типа английского языка в нынешнем мире. Непосредственно на нём можно и не писать, но нужно быть готовым читать программы на нем, понимать прототипы, уметь подключать его библиотеки и т.д. Потому как ничего более «стандартного» и шире распространенного нету.
Вы правы, но точно так же как в приведённой вами аналогии, читать и понимать английский язык и свободно им владеть — две большие разницы.
Для чтения программ на С++ эти книги не нужны.
Для чтения программ на С++ эти книги не нужны.
На С — с нятяжкой соглашусь, но для уверенного чтения программ на С++ нужно знать С++. Я уже 4 года не программирую на С++, кое-что подзабыл, и мне уже сложно читать С++-код. А тем, кто его совсем не знает — почти невозможно (разве что выдрать какой-нибудь алгоритм, не вдаваясь в архитектуру программы)
Наверное тоже есть разница читать научную работу на английском (код на C++ со всеми фичами последнего стандарта) или новость в обычной газете (нагугленный демонстрационный код), а то и адаптированный для иностранцев текст (код в книгах, где C++ используется для демонстрации общих практик, может вперемешку с другими языками).
Volch сказал прямо в точку, я писал много лет на Delphi и постоянно приходилось читать описания разннобразнейших API естественно на С++. Особых проблем я не испытывал. Если какая-то конструкция была совершенно непонятно — всегда можно было нагуглить (точно также как google Translate для ин.яз'а)
Да, но только после Scheme. C в частности и императивные языки убивают в человеке способность мыслить абстрактно. Вот что сказал Э. Дейкстра, например:
цитата отсюда.
Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации.
цитата отсюда.
я ничего не буду говорить плохого о Scheme, поскольку его не знаю. Из примерно сотни знакомых мне лично айтишников на нем не пишет никто. Как этот язык может выступать в роли общей комуникативной базы?
Мы ведь говорим об обучении основам программирования, а не о практическом применении того или иного языка. И я лишь предположил, что C, Java, PHP – менее удачные языки для знакомства с программированием, чем Scheme, Lisp, Haskell по причине своей сложности.
Не сложности, нет. Концентрации внимания на ненужных начинающему деталях в ущерб принципам. Можно сравнить обучению плаванью методом «бросили в воду, жить захочешь — выплывешь» и занятиям в «лягушатнике» под руководством тренера. Первое эффективно для быстрого достижения цели с нуля, а второе для выработки эффективных навыков её достижения. Пускай второе и займёт больше времени с нуля, но впоследствии будет более эффективно, не запрещая использовать «неправильные» способы в случае необходимости повышения эффективности, но сознавая их недостатки.
Может такая аналогия уместна: C — грамматика программирования, а Scheme — семантика. C и прочие императивные языки приучают мыслить категориями типа «цикл по целому от 1 до 10», а Scheme (да и другие функциональные) чем-то вроде «перебор значений диапазона целых чисел от 1 до 10». Вроде разница небольшая, но в первом случае идёт речь о, прежде всего, деталях реализации («как делаем»), а во втором — об абстракциях, скрывающимися за ними («что делаем»). Что важнее, по-вашему?
По мне так лучше сделать неудачную реализацию удачной абстракции, чем удачную реализацию неудачной абстракции. В первом случае придётся переделывать только реализацию, во втором — сначала абстракцию (грубо говоря, архитектуру), а потом и реализацию. Второе очевидно сложнее даже для тех, кто не умеет считать больше единицы.
По мне так лучше сделать неудачную реализацию удачной абстракции, чем удачную реализацию неудачной абстракции. В первом случае придётся переделывать только реализацию, во втором — сначала абстракцию (грубо говоря, архитектуру), а потом и реализацию. Второе очевидно сложнее даже для тех, кто не умеет считать больше единицы.
Это очень старая цитата. Когда Дейкстра об этом писал, программы на бейсике через три строки состояли из инструкций GOTO, да и нумерация строк была в ходу.
Думаю, к VB.NET у него не было таких претензий.
По поводу «убивают способность мыслить абстрактно» — с чего бы?
Я считаю, что C знать должны все, потому что это более простой по сравнению с Ассемблером, но всё-таки адекватный способ прочувствовать реальную околожелезную аппаратуру, а это важно.
Думаю, к VB.NET у него не было таких претензий.
По поводу «убивают способность мыслить абстрактно» — с чего бы?
Я считаю, что C знать должны все, потому что это более простой по сравнению с Ассемблером, но всё-таки адекватный способ прочувствовать реальную околожелезную аппаратуру, а это важно.
Именно. И писалась она в поддержку предложенного им и Виртом структурного программирования, которое нашло отражение прежде всего в столь «любимых» на Хабре Паскале и «водопаде». Причём структурное программирование не столько парадигма типа процедурного, объектного, функционального и прочих императивных и декларативных подходов, сколько методология разработки, сейчас бы её назвали Structure Driven Development — SDD — в противовес прежде всего TDD :)
Убивают — не совсем точно, но понижают — есть такое, особенно когда ООП в них даётся вдогонку к процедурному стилю даже в полностью ООП языках типа Java. Сначала учат реализации, а потом пытаются показать, что их можно абстрагировать. А ведь абстрагированию учит по, сути, и то же SDD :)
Но не первым языком — это точно. Слишком много деталей, слишком мало абстракций.
Убивают — не совсем точно, но понижают — есть такое, особенно когда ООП в них даётся вдогонку к процедурному стилю даже в полностью ООП языках типа Java. Сначала учат реализации, а потом пытаются показать, что их можно абстрагировать. А ведь абстрагированию учит по, сути, и то же SDD :)
Но не первым языком — это точно. Слишком много деталей, слишком мало абстракций.
Важно, но я считаю, пусть они как-нибудь сами изучат C потом. И вот почему.
Я полностью согласен со своим бывшим преподавателем предмета Функциональное и логическое программирование в университете, когда она сказала, что сначала нужно изучать декларативное программирование, а потом уже изучать C и т. д.
Я считаю, что после того, как студент научится писать алгоритмы на языке без побочных эффектов – о которых им непременно пришлось бы беспокоиться в языках императивных, что только затрудняло бы обучение – он быстрее получит навыки абстрактного мышления. А ведь яркий пример науки, везде и всюду использующей абстракций, – это математика.
Т. е. правильно уже сказали, что прежде всего лучше знать, «что решить», а не «как решить». Как решить – это уже о производительности (если мы о коде на C), написании драйверов для конкретной архитектуры, написании оптимизирующего компилятора для ОС.
Я за свертки, отображения, полиморфизм типов и функций. Я за рекурсивные функции без переполнения стэка. Я за отсутствие побочных эффектов, когда нет необходимости беспокоиться о переменных, которые могут быть случайно изменены любой функцией. Я за абстракции сейчас и железо – потом.
И я очень жалею, что учась в своих учебных заведениях узнал о декларативном (и функциональном в частности) программировании так поздно, ведь я потом понял, как проще было бы студентам мыслить в терминах Scheme, Haskell, Erlang.
Простите, наболело.
Я полностью согласен со своим бывшим преподавателем предмета Функциональное и логическое программирование в университете, когда она сказала, что сначала нужно изучать декларативное программирование, а потом уже изучать C и т. д.
Я считаю, что после того, как студент научится писать алгоритмы на языке без побочных эффектов – о которых им непременно пришлось бы беспокоиться в языках императивных, что только затрудняло бы обучение – он быстрее получит навыки абстрактного мышления. А ведь яркий пример науки, везде и всюду использующей абстракций, – это математика.
Т. е. правильно уже сказали, что прежде всего лучше знать, «что решить», а не «как решить». Как решить – это уже о производительности (если мы о коде на C), написании драйверов для конкретной архитектуры, написании оптимизирующего компилятора для ОС.
Я за свертки, отображения, полиморфизм типов и функций. Я за рекурсивные функции без переполнения стэка. Я за отсутствие побочных эффектов, когда нет необходимости беспокоиться о переменных, которые могут быть случайно изменены любой функцией. Я за абстракции сейчас и железо – потом.
И я очень жалею, что учась в своих учебных заведениях узнал о декларативном (и функциональном в частности) программировании так поздно, ведь я потом понял, как проще было бы студентам мыслить в терминах Scheme, Haskell, Erlang.
Простите, наболело.
Я ещё больше жалею о том, что о декларативном программировании (если не считать SQL) узнал уже после многих лет прошедших с формальной учебы и выбора направления развития. Хорошо хоть в PHP появились в более-менее приличном виде средства работы с функциями высшего порядка. Можно пытаться (незаметно для других) применять знания из книг о других языках (прежде всего SICP, если её можно назвать «книгой о языке») в своих проектах.
И не о языке эта книга, а о программировании. И вполне мог быть там Haskell, а не Scheme.
Но Scheme там совершенно неслучайно, ведь он проще C. Ведь интерпретатор Scheme с поддержкой лямбда-функций и каррирования можно реализовать сотней строк на популярных сегодня императивных языках.
А Вижуал Бейсик изменился, да – включил себя много вещей, традиционно относимых к миру ФП и декларативного программирования: LINQ, например, дженерики в Java и т. д., всего и не перечислить.
Но Scheme там совершенно неслучайно, ведь он проще C. Ведь интерпретатор Scheme с поддержкой лямбда-функций и каррирования можно реализовать сотней строк на популярных сегодня императивных языках.
А Вижуал Бейсик изменился, да – включил себя много вещей, традиционно относимых к миру ФП и декларативного программирования: LINQ, например, дженерики в Java и т. д., всего и не перечислить.
Я уважаю декларативные языки, но сам я, скорее, пришёл из «железа», и для меня декларативный язык — это надстройка над ассемблером, а не ассемблер — кривая реализация декларативных инструкций.
В конце концов, декларативное программирование — это в известном смысле фикция. Две одинаковые с точки зрения декларативного смысла программы будут выполняться по-разному, с разной сложностью и скоростью. Как на эту тему писал Иван Братко (Пролог), лучше иметь хоть какой-то декларативный смысл, чем не иметь никакого вообще. Т.е. даже он признаёт, что декларативное программирование — это приятная и удобная абстракция, но забывать о железе нельзя.
Кроме того, мне не кажется, что языки вроде Haskell хоть чем-то более «абстрактны» и «декларативны», чем C. Всё зависит от того, в каких абстракциях вы мыслите. Машина Тьюринга — это вполне себе абстракция, и любой императивный язык попросту позволяет вам удобно мыслить в терминах машины Тьюринга.
В общем, это попросто холивар на тему курицы и яйца. Что важнее — модели, которые выполняются на железе или железо, которое умеет выполнять сложные модели.
В конце концов, декларативное программирование — это в известном смысле фикция. Две одинаковые с точки зрения декларативного смысла программы будут выполняться по-разному, с разной сложностью и скоростью. Как на эту тему писал Иван Братко (Пролог), лучше иметь хоть какой-то декларативный смысл, чем не иметь никакого вообще. Т.е. даже он признаёт, что декларативное программирование — это приятная и удобная абстракция, но забывать о железе нельзя.
Кроме того, мне не кажется, что языки вроде Haskell хоть чем-то более «абстрактны» и «декларативны», чем C. Всё зависит от того, в каких абстракциях вы мыслите. Машина Тьюринга — это вполне себе абстракция, и любой императивный язык попросту позволяет вам удобно мыслить в терминах машины Тьюринга.
В общем, это попросто холивар на тему курицы и яйца. Что важнее — модели, которые выполняются на железе или железо, которое умеет выполнять сложные модели.
Я однажды слышал, как кто-то сказал, что лучшим пользовательским
интерфейсом из когда-либо разработанных является карандаш. Его
назначение тотчас же понятно, для него не нужно руководство
пользователя, он готовится к работе без особой суеты. Однако наиболее
важным свойством является прозрачность. Когда вы пользуетесь
карандашом, то думаете о том, что вы пишите, а не о самом карандаше.
Подобно карандашу, лучшими компьютерными интерфейсами являются
те, которые скрывают сам факт того, что вы обращаетесь к компьютеру:
замечательный пример — интерфейс с системой зажигания вашего
автомобиля. Вы поворачиваете зажигание, включаете скорость и жмете на
газ, как если бы все эти объекты интерфейса (ключ, рычаг скоростей,
педаль) были прицеплены прямо на двигатель. Тем не менее, это не так:
они теперь обычно просто устройства ввода в компьютер, который
управляет двигателем.
© Allen Holub, Веревка достаточной длины, чтобы выстрелить себе в ногу.
Вы напротив предлагаете зарыться поближе к железу. Но зачем?..
Декларативные языки разрабатываются для быстрой разработки качественного кода, а не ради прикола. Иначе ничего не было бы кроме C. К тому же вы сами выше сказали, что C – абстракция над языком ассемблера.
Я пока не понял, что вы имели в виду, говоря «ассемблер — кривая реализация декларативных инструкций». Я вспоминаю, например, команды
inc eax, mov eax, [eax] и понимаю, что они не очень-то декларативны, а вполне императивны, поскольку говорят «как», а не «что», модифицируя глобальное состояние (регистры).Вот эта последняя операция «разыменования», указатели на указатели на символы, возможность повторного присвоения значения уже объявленной когда-то переменной создают в головах познающих программирование путаницу.
Они не понимают, зачем им нужна математика и как она им помогает в программировании, потому что когда им показываешь код
int c = 40; c = c + 2;, у них возникает внутреннее противоречие и они не видят связи абстрактной математики без побочных эффектов с побочными эффектами в ассемблере и чуть более абстрактным C.Я уверяю, Haskell, Scheme и прочие функциональные и декларативные языки и призваны оградить программиста от того пласта непреходящих проблем, которые приходилось бы решать в процессе программирования на императивном языке.
Во-первых, по Голубу. Это красиво звучит, но «прозрачность» далеко не всегда эффективна. Возьмём тот же карандаш. Я пишу от руки гораздо медленнее, чем печатаю на клавиатуре. Однако работа с клавиатурой требует навыка. Далее, интерфейс, где кнопки нажимаются мышью, понятен мгновенно, однако заучивание горячих клавиш даст явный прирост производительности в будущем. То есть «простота и интуитивная понятность интерфейса» хороша для быстрого погружения, однако может оказаться, что более сложный интерфейс выгоднее в перспективе.
Я немного работал с декларативными языками и понимаю, что к чему. Но мне в принципе термин «декларативный язык» не нравится. Это звучит как реклама (наши языки декларативны, а другие не декларативны". Всё зависит от того, как человек мыслит.
Если я хочу написать сортировку пузырьком, язык C вполне себе декларативен, т.к. на нём я могу просто и естественно изложить то, что я хочу сделать. Аналогично, если я хочу написать скрипт, который проводит робота по некоей траектории, я мыслю как раз в терминах «шагов», «операций», «действий». И в этом случае декларативный язык оказывается совершенно неадекватным пошаговой природе программы.
Я немного работал с декларативными языками и понимаю, что к чему. Но мне в принципе термин «декларативный язык» не нравится. Это звучит как реклама (наши языки декларативны, а другие не декларативны". Всё зависит от того, как человек мыслит.
Если я хочу написать сортировку пузырьком, язык C вполне себе декларативен, т.к. на нём я могу просто и естественно изложить то, что я хочу сделать. Аналогично, если я хочу написать скрипт, который проводит робота по некоей траектории, я мыслю как раз в терминах «шагов», «операций», «действий». И в этом случае декларативный язык оказывается совершенно неадекватным пошаговой природе программы.
А на каких языках пишете, если не секрет?
Основной язык COS
Нет такого языка — C/C++. Есть язык C и совершенно другой по своей философии язык C++. Книг по C++ в списке нет, и недаром. А вот книга по C есть, и тоже недаром.
Я уже выше писал, что C по сути является высокоуровневым ассемблером, и любому начинающему разработчику было бы неплохо почувстовать себя программистом сравнительно низкого уровня, чтобы понять, почему сравнение строк не так быстро, как сравнение целых чисел или почему ассоциативный массив медленнее обычного, с целочисленным индексом. Язык C помогает ближе понять аппаратуру компьютера, а это важно.
Я уже выше писал, что C по сути является высокоуровневым ассемблером, и любому начинающему разработчику было бы неплохо почувстовать себя программистом сравнительно низкого уровня, чтобы понять, почему сравнение строк не так быстро, как сравнение целых чисел или почему ассоциативный массив медленнее обычного, с целочисленным индексом. Язык C помогает ближе понять аппаратуру компьютера, а это важно.
А я против такого отношения. Исходя из основных концепций разработки, программист не должен общаться с железом, ему не надо знать аппаратуру. Вы предлагаете делать программы по принципам вселенной Флинстоунов, все на каменной дощечке, молотком и зубилом. Это лишнее, тогда как в нынешнее время для львиной доли задач хорошо подходят языки высокого уровня. А изучение С только усложнит понимание. Учиться программировать надо с простых языков. Да и в первую очередь для программиста это теория программирования, а не практика.
У меня информатика началась в 9м классе, и за весь 9й класс мы ниразу не видели компьютер, у нас была голимая теория и довольно мощная. Когда в 10м классе начали программировать, то все шло на ура (было это в начале 90х, дома был ток спектрум для игрушек, мало что на нем программил). И начинал я с бейсика, потом перешел на паскаль, разобрался, понял что и как, а потом ушел познавать на всю катушку асм на спектруме. Затем когда занялся C++, то по началу была проблемной работа с памятью, но сел и разобрался. Но вот я не знаю как бы я смог научиться программировть, если начал учиться с асма.
В итоге я сторонник: сначала теория, потом практика. А не наоборот. Да и настоящий программист, это не знание языков программирования, а знание теории, язык выучить просто, а теорию заметно сложнее, но при этом теория одна для всех языков.
У меня информатика началась в 9м классе, и за весь 9й класс мы ниразу не видели компьютер, у нас была голимая теория и довольно мощная. Когда в 10м классе начали программировать, то все шло на ура (было это в начале 90х, дома был ток спектрум для игрушек, мало что на нем программил). И начинал я с бейсика, потом перешел на паскаль, разобрался, понял что и как, а потом ушел познавать на всю катушку асм на спектруме. Затем когда занялся C++, то по началу была проблемной работа с памятью, но сел и разобрался. Но вот я не знаю как бы я смог научиться программировть, если начал учиться с асма.
В итоге я сторонник: сначала теория, потом практика. А не наоборот. Да и настоящий программист, это не знание языков программирования, а знание теории, язык выучить просто, а теорию заметно сложнее, но при этом теория одна для всех языков.
Ну, я не понимаю о чём спор. Язык C не должен быть первым языком программирования — по-моему, это и так очевидно. Он не был создан для обучения, для этого гораздо лучше подойдёт Small Basic, Oberon или что-то в этом роде.
Но вот выше мне предлагают поближе держаться к декларативным языкам, а их «простота» мне кажется весьма неочевидной.
Но вот выше мне предлагают поближе держаться к декларативным языкам, а их «простота» мне кажется весьма неочевидной.
Просто попробуйте читать SICP и выполнять предлагаемые задания. Где-то до 70ой страницы у вас гарантированно не будет сложностей, хоть язык – Scheme – для вас внове. Для выполнения этих заданий на C вам пришлось бы изучить значительное количество моментов, оттягивающих выполнение заданий.
«Чтобы понять, нужно гонять» ©
«Чтобы понять, нужно гонять» ©
K&R, конечно, среди остальных книг смотрится немного странно, но только если воспринимать её как книгу по Си.
На мой взгляд, K&R — это ещё и прекрасный образец того, какой должна быть книга по какому-либо языку. В 300 страниц умещается полное описание языка вместе с введением, более сложными темами и справочником. В общем, всё. Некоторым авторам для этого нужно никак не менее 600-700 страниц, десятка два отвлечённых примеров и заданий на повторение или всяких тестов в конце каждой главы.
На мой взгляд, K&R — это ещё и прекрасный образец того, какой должна быть книга по какому-либо языку. В 300 страниц умещается полное описание языка вместе с введением, более сложными темами и справочником. В общем, всё. Некоторым авторам для этого нужно никак не менее 600-700 страниц, десятка два отвлечённых примеров и заданий на повторение или всяких тестов в конце каждой главы.
А вот заданий и тестов часто не хватает при входе в новый язык. «Копи-пастить» код из книги в комп с заранее известным результатом (особенно, если книга читается не за компом) смысла мало. А вот когда предлагаются задания на закрепление материала, то достигается куда лучшее понимание, даже если их выполнять или прикидывать план выполнения в уме, а не за компом. А за компом ещё и визуальная и моторная память развивается — глаз будет резать лишняя точка с запятой, а нужную рука будет сама ставить.
Наверно мы говорим немного о разных заданиях. Вот, например, из книжки «С++. Вводный курс» (талмуд на 1000+ страниц, кстати):
Вроде бы и неплохо, вопрос на закрепление, но с другой стороны такие ответы надо знать на уровне понимания, а не запоминания. Как по мне, так лучше перечитать нужную часть главы (которую, кстати, в небольшой книге проще найти) ещё раз, чем решать такие вот тесты и проверять на всё ли ты можешь ответить. К тому же, в главе ведь уже есть примеры кода.
Упражнение 8.9
Объясните разницу между следующими инструкциями:
int *pi0 = p2.get(); int *pi1 = p2.release();
Для каких случаев более приемлем тот или иной вызов?
Вроде бы и неплохо, вопрос на закрепление, но с другой стороны такие ответы надо знать на уровне понимания, а не запоминания. Как по мне, так лучше перечитать нужную часть главы (которую, кстати, в небольшой книге проще найти) ещё раз, чем решать такие вот тесты и проверять на всё ли ты можешь ответить. К тому же, в главе ведь уже есть примеры кода.
Так для того такие тесты и предназначены, чтоб выявлять необходимость перечитать. Не смог ответить — перечитывай, смог (желательно какой-то фидбэк о правильности ответа) — читай дальше.
Но вообще да, немного о других заданиях говорил. О написании коротких, но полноценных программ, делающих что-то конкретное. Даны вход и выход, может быть алгоритм, нужно написать реализацию, заведомо доступную в рамках изученного. Тестирование правильности реализации — соответствие выходу, эффективности — разбор в следующей главе или, хотя бы, «правильные ответы» в конце, по которым желающий разберется что предлагаемый способ лучше его. Или не разберется, но хотя бы будет знать, что вариантов решения больше чем один.
Естественно всё это о тех, кто сам хочет научиться, а не потому что сказали: «копать отсюда и до обеда».
Но вообще да, немного о других заданиях говорил. О написании коротких, но полноценных программ, делающих что-то конкретное. Даны вход и выход, может быть алгоритм, нужно написать реализацию, заведомо доступную в рамках изученного. Тестирование правильности реализации — соответствие выходу, эффективности — разбор в следующей главе или, хотя бы, «правильные ответы» в конце, по которым желающий разберется что предлагаемый способ лучше его. Или не разберется, но хотя бы будет знать, что вариантов решения больше чем один.
Естественно всё это о тех, кто сам хочет научиться, а не потому что сказали: «копать отсюда и до обеда».
Странно, что в список не попали книги Стевенса. Имхо, мало хорошо разбираться в своей области, нужно еще уметь доносить свои знания до аудитории. И ему это удалось! И даже в переводе очень хорошо читается.
Поскольку все присутствующие так или иначе связанны с программированием для сети, независимо от используемого языка, то в список обязательных добавил бы эту:
У. Р. Стивенс, Б. Феннер, Э. М. РудоффЖ: «UNIX. Разработка сетевых приложений»
А это по желанию (читай, в зависимости от языка/платформы):
У. Ричард Стивенс, Стивен А. Раго: «UNIX. Профессиональное программирование»
Поскольку все присутствующие так или иначе связанны с программированием для сети, независимо от используемого языка, то в список обязательных добавил бы эту:
У. Р. Стивенс, Б. Феннер, Э. М. РудоффЖ: «UNIX. Разработка сетевых приложений»
А это по желанию (читай, в зависимости от языка/платформы):
У. Ричард Стивенс, Стивен А. Раго: «UNIX. Профессиональное программирование»
Тогда уж и «The UNIX Programming Environment».
Книги, безусловно, must have, но я думаю что в список они не попали потому, что это не учебники помогающие научиться программировать — это справочники, объясняющие что происходит «под капотом» и почему, без которых почти невозможно писать действительно надёжный код.
Ну Макконел, стоящий тут на первом месте, на учебник тоже не тянет. Он не научит программировать на чем либо конкретном. Ничуть не пытаюсь умалить этот труд, но не считаю, что приведенные мною книги не могут быть учебниками. В этом плане «разработка сетебых приложений» книга более близкая в конкретным реалиям кода.
UFO just landed and posted this here
Заставил себя на всякий случай прочесть SCIP, уже имея довольно большой опыт коммерческого программирования. Честно говоря, не оценил общего восторга :(. Очень тяжелая для чтения и мутная книга. Scheme (диалект LISP), чуть алгоритмов и структур данных, большая часть книги посвящена решению практических задач вида «а теперь мы будем делать то, в чем сама суть программирования — решать уравнения и создавать свои языки программирования!». Может, десятки лет назад это и было основной «университетского» программирования, но сейчас как-то не впечатляет.
Это все, естественно, мое сугубо личное мнение :). С наступивгим всех.
Это все, естественно, мое сугубо личное мнение :). С наступивгим всех.
Эм… “data-directed programming” — это алгоритм, структура данных или решение конкретной практической задачи?
Если она показалась вам тяжёлой и мутной — отдохните и позже возьмитесь за неё ещё раз. Это вам не художественная литература с пространными рассуждениями на тему всем (кто закончил хоть один проект) известных истин как Брукс или Макконнел.
Если она показалась вам тяжёлой и мутной — отдохните и позже возьмитесь за неё ещё раз. Это вам не художественная литература с пространными рассуждениями на тему всем (кто закончил хоть один проект) известных истин как Брукс или Макконнел.
Где Кнут? =)
А как же «Алгоритмы и структуры данных» Никлауса Вирта?
А я уж подумал, что сейчас под заголовком будут перечислены 5 томов Кнута
> Тот самый Стив Макконнелл, которому приписывают фразу…
Между прочим, эта фраза приведена в книге «Совершенный код» с подписью «Аноним».
Между прочим, эта фраза приведена в книге «Совершенный код» с подписью «Аноним».
А где же «Паттерны проектирования»?
К своему ужасу, не прочел целиком ни одной из этих книг. 8 лет успешной профессиональной деятельности коту под хвост :)
Разве это то, чем стоит хвалиться? И потом, деньги часто платят за быстро написанную программу, за правильный и «красивый» код доплачивают единицы.
Красивый код мы пишем для себя (и для тех, кто будет его поддерживать).
Красивый код мы пишем для себя (и для тех, кто будет его поддерживать).
они чуть ниже.
я бы расширил до топ10:
6. Гамма, Хелм, Джонсон, Влиссидес — Паттерны проектирования
7. Фаулер — Рефакторинг
8. Брукс — Мифический человеко-месяц
9. Кнут — Искусство программирования
10. Ахо, Лам, Сети, Ульман — Компиляторы
я бы расширил до топ10:
6. Гамма, Хелм, Джонсон, Влиссидес — Паттерны проектирования
7. Фаулер — Рефакторинг
8. Брукс — Мифический человеко-месяц
9. Кнут — Искусство программирования
10. Ахо, Лам, Сети, Ульман — Компиляторы
Простите за честность, но мне одному Фаулер показался Капитаном Очевидность? Нет, и написана книга интересно, и автор достаточно грамотный разработчик, и вроде как структурирует знания, по крайней мере узнаешь как называлось то, что ты делал из года в год, но даже дочитав до конца не было ни одного нового открытия для меня, разве что изменилось отношение к написанию тестов, которых толдычат на каждой странице. В остальном алгоритм каждого метода выглядит так:
Видите говнокод?
1) Напишите тест
2) Запустите тест
3) Уберите говнокод (скопируйте, разбросайте, инкапсулируйте, etc)
4) Запустите тест
5) Profit
Мне казалось, что любой разработчик должен так поступать и без чтения книжек. Разве что тесты не все любят писать, оставим это на совести каждого.
Видите говнокод?
1) Напишите тест
2) Запустите тест
3) Уберите говнокод (скопируйте, разбросайте, инкапсулируйте, etc)
4) Запустите тест
5) Profit
Мне казалось, что любой разработчик должен так поступать и без чтения книжек. Разве что тесты не все любят писать, оставим это на совести каждого.
Просто вы опытный разраб. Для матерых профессионалов там крупицы интересного, но все же есть немного. И, согласитесь, приятно в столь признанной книжке всюду встречать тезисы, до которых вы допёрли сами давным давно :)
Это да, приятно, но вот тот же «Совершенный Код» или «Банду Четырех» читать было просто захватывающе, хотя казалось бы. С удовольствием приобрел их бумажные варианты после прочтения. Наверное стоит делать оговорку, что Фаулера нужно читать до них (тем более в них на него часто ссылаются). Но вот начало у него действительно хорошо написано, когда он сразу берет пример говнокода и начинает его прогонять почти по всем своим правилам, описанным далее.
«Патерны проектирования» захватывающе?? По мне так довольно нудно написано, столь нужный труд можно было как-то поинтереснее подать. Как справочник, впрочем, великолепен.
Если хочется захватывающе, есть еще одна книга по паттернам (в оригинальном топике приведена), но она скорее как «разгон» перед Бандой. Честно говоря я тоже не сразу осилил банду, сначала тоже казалась нудной и «усложненной», но как втянулся, так с тех пор остается одной из самых любимых книг. И тоже до сих пор использую как справочник. С удовольствием прочитал бы какое-нибудь продолжение :)
Захватываюего в Совершенном кода? Там половина интересна, да, или скорее четверть. А остальное точно так же как и у Фаулера, очевидна. Например, про наименование переменных.
Коллеги, а что из предложенного стОит почитать с пользой для проектирования архитектуры средних и крупных программных систем? А то большинство самых популярных книг помогают в решении тактических задач, затрагивая архитектуру как-то вскользь.
Средние и крупные системы надо разбивать на слабосвязанные подсистемы и решать тактические задачи :) Какая область программирования?
Спасибо, кэп, до этого я как-то уже допёр сам :) Области — CRM, ERP
Спасибо, посмотрю. Жаль, что, похоже, на русский не переведены.
Не угадали, обе они переведены :)
имхо
Джо == Джозеф && Джо != Джоэль
Джо == Джозеф && Джо != Джоэль
Как здорово у меня есть все пять книг, но к сожалению Томас Кормен, лежит целый год без внимания.
А вообще как уже сказали список можно расширить, не попали в число призеров очень многие отличные труды.
А вообще как уже сказали список можно расширить, не попали в число призеров очень многие отличные труды.
А «Разработчик ПО» это кто? Если речь идет именно о Разработчике программного обеспечения, а не о среднестатистическом штатном программисте выполняющим «ряд задач по программированию». То я бы безусловно поставил Фредерика Брукса в ТОП-5, не ниже.
UFO just landed and posted this here
По процессорам (и около хардварной области) могу порекомендовать
Computer Architecture, A Quantitative Approach
Inside the Machine
Memory Systems: Cache, DRAM, Disk
Inside NAND Flash Memories
Ежели кто еще может добавить годных книг в список — милости присим.
Computer Architecture, A Quantitative Approach
Inside the Machine
Memory Systems: Cache, DRAM, Disk
Inside NAND Flash Memories
Ежели кто еще может добавить годных книг в список — милости присим.
В защите K&R напишу, что эта книга очень хорошо подходит начинающим программистам. Как доказательство, я прочитал её от корки до корки в 12 лет и почти всё понял и мог применять, хотя интеллекта и широкого образования в ту пору ещё не хватало.
Я в 12 лет даже не знал, что есть вообще такой язык как С )) Уговорил купить себе МС1502, в школе и компцентре в нашей глубинке давали только бейсик (о других языках даже не сообщали что они есть), книг не было вообще по программированию, кроме распечаток по бейсику из компцентра, про интернет вообще молчу (до сих пор в моей исторической родине 512Кб анлима за 500эрэ)…
Так что мой мозг обезображен бейсиком :(
Так что мой мозг обезображен бейсиком :(
UFO just landed and posted this here
Я узнал из какого-то журнала общества «Знания» когда вам было 10 лет. K&R нашёл в областной библиотеке, но только в читальном зале, куда меня одного ещё и не пускали первое время :( А учительницу в школе я сам Си учил :)
Не думаю, что моя глубинка глубже вашей :) У нас анлим 128 — 1200, и то непонятно для всех желающих или нет. :(
Но бэйсик — да, первый язык, если не считать МК-61
Не думаю, что моя глубинка глубже вашей :) У нас анлим 128 — 1200, и то непонятно для всех желающих или нет. :(
Но бэйсик — да, первый язык, если не считать МК-61
Ехх… Мне не повезло, нигде не всплыло в свое время упоминание об этом языке ) Только в старших классах уже занялся им…
Но зато какие чудеса мы творили на бейсике ) Писали своего диггера, анимационные картинки и тд и тп… ) И весь код хранился в тетрадке, который каждый раз нужно было набирать заново ) И домашние задания делали в тетради, чтобы придти в школу и набрать его на деревянных БК0010 ))
Но зато какие чудеса мы творили на бейсике ) Писали своего диггера, анимационные картинки и тд и тп… ) И весь код хранился в тетрадке, который каждый раз нужно было набирать заново ) И домашние задания делали в тетради, чтобы придти в школу и набрать его на деревянных БК0010 ))
Для PHP программистов реквестирую замену четвёртой книги на Шлосснейгла.
Книгу про программирование на справочник по шаблонизатору? Нормально, да. Только не стОит потом обижаться, когда «пхп-программистов» классифицируют отдельно от всех прочих. Примерно как «1С-программистов». И пишут именно в кавычках.
Хмм… Паттерны, ООП, индексы и другие оптимизации баз данных, принципы работы баз данных, ActiveRecord, DataMapper, разнообразные механизмы кеширования, юнит-тестирование как таковое, проксирование серверов, схемы масштабирования, механизмы безопасности — это всё справочник по шаблонизатору?
Да ведь вы сами и ответили на вопрос. Паттерны, ООП, индексы и другие оптимизации баз данных, принципы работы баз данных, ActiveRecord, DataMapper, разнообразные механизмы кеширования, юнит-тестирование как таковое, проксирование серверов, схемы масштабирования, механизмы безопасности — каждая из этих тем достойна хорошей книги и не одной. А, учитывая, что любой справочник по шаблонизатору — это описание мегатонны хаков, рассказов что НЕ следует использовать, а из того что следует как выбрать наиболее православный метод из десятка одинаковых… и причия и прочия лабуда, не имеющая к собственно обучению программированию никакого отношения, то по скольку страниц там уделено каждой из перечисленных тем? По две? Ах, по десять! :)
От себя бы добавил Гради Буча «Объектно-ориентированный анализ и проектирование». Хоть эта книга уже более узкоспециализированна но дает понять, как надо и как не надо делать.
Забыли: Таненбаум Э. С. «Архитектура компьютера».
Джоэла Спольски зовут Джоэл, а не Джо. Всегда ваш, К.О.
Sign up to leave a comment.
Топ-5 самых впечатляющих книг, которые должен прочесть каждый разработчик ПО