132,71
рейтинг
20 ноября 2015 в 16:50

Разработка → Копают только вниз перевод

Здравствуйте, уважаемые читатели.

В последнее время нас заинтересовала серия Зеда Шоу "The Hard Way", которую хотелось бы как минимум частично перевести на русский язык. Поскольку порой мы действительно не ищем легких путей, начать хотелось бы с книги о языке C:



Серия ориентирована в первую очередь на начинающих. Для тех, кто любит язык C, а также для их оппонентов, полагающих, что лучше стартовать с чего-нибудь попроще, мы публикуем немного сокращенную статью Эвана Миллера, написанную в конце прошлого года. Возможно, в зависимости от реакции на эту статью, мы решим дополнительно перевести и опубликовать отрывок из книги мистера Шоу либо даже его ответ на критику, высказанную Тимом Хентенааром, а пока приглашаем вас под кат, где, как нам представляется, изложены самые общие соображения в пользу актуальности этой книги.

Когда я учился водить машину (мне тогда было чуть больше 15), мама настаивала, чтобы я практиковался на отцовской Mazda Miata: это был серебристый двухдверный кабриолет с откидным верхом.

Управлять «Миатой» было непросто. Мало того, что в ней не было автоматической коробки передач, вдобавок из этой машины было практически невозможно заглянуть назад. Солнце настолько прожарило пластиковое заднее стекло, что на свернутом откидном верхе, казалось, можно было готовить бутерброды.

«Миата» отнюдь не была и самой безопасной машиной, причем компания «Mazda Motor Corporation» даже не пыталась утверждать обратное. Это была просто доступная машина, на которой приятно кататься, такая бюджетная BMW. Помню, отцовская «Миата» была такой узкой и приземистой, что когда я ездил на ней по федеральной магистрали, даже закрадывались мысли: «А если я попытаюсь проскочить на ней под полуприцепом, дальнобойщик что-нибудь заметит»?

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

«Однажды ты окажешься на вечеринке», — объясняла она мне с уверенностью, которой позавидовал бы Нострадамус, — «и там будет машина, которую никто не сможет вести, потому что у нее будет ручное переключение скоростей. А ты должен суметь, и учиться этому нужно сейчас, иначе никогда не справишься с ручкой переключения».

Осваивать ручную коробку передач — не самое интересное занятие, и я думаю, что никогда бы этим не занялся, если бы не тот пророческий авторитет, которым пользовалась мама у нас дома. Но, напрактиковавшись, я в итоге смог ездить на «Миате» в пределах разрешенной скорости, не заливая водительское сиденье потом и слезами.

С тех пор прошло много лет, и я заметил интересную закономерность. Мы, гордое меньшинство — закаленные мастера ручной передачи — оказались гораздо более умелыми, чем те, кто привык полагаться на коробку-автомат. Мы увереннее владели машиной, лучше представляли себе, как работает двигатель автомобиля. Даже если нам ни разу не доводилось заглянуть внутрь коробки передач, мы знали, что такое «повышающая передача» в автоматической коробке, как с ее помощью экономить бензин. Мы знали, что означают таинственные цифры 1 и 2 под надписью «Drive», какую службу они могут сослужить, когда съезжаешь по склону. И в каждый момент времени мы, вероятно, на интуитивном уровне лучше представляли себе, что происходит с машиной — лучше, чем приверженцы автоматической коробки.

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

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

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

Высказывая это мнение, я оказываюсь в меньшинстве, поэтому тем более хочу пояснить здесь мою точку зрения. Не так давно Python потеснил Java в качестве самого популярного вводного языка программирования, изучаемого в университетах. Эрик Рэймонд, автор программной статьи «How To be a Hacker» рекомендует Python в качестве первого языка. Его безусловно поддерживает Питер Норвиг в своей знаменитой работе “Teach Yourself Programming in Ten Years”. Пол Грэм даже рассказывает о специфическом «Парадоксе Python».

В наши дни, если вы увидите рекламу в духе «Как научиться программировать за X недель» — можете быть практически уверены, что вам предложат изучить Python.

Вопреки поверхностной привлекательности Python — его синтаксиса, интерактивности, библиотечной поддержки, широкого сообщества и превосходной документации — выбирая его в качестве первого языка программирования, вы сталкиваетесь с серьезной проблемой. Программист, знающий только Python, не обладает достаточными представлениями о работе компьютера. Он может воспринимать C в качестве мистического искусства, вызывающего смешанные чувства страха и неприязни. Страха — потому что программисту рассказали, что C сложен, а неприязни — потому, что сложности C якобы являются морально устаревшими пережитками более аскетичных времен. Появился даже новый трюизм: «человеческое время ценнее процессорного».

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

Пол Грэм подобрал красивую метафору (как всегда, правда?) о потенциале языков программирования, который он описывает в качестве своеобразного вертикального континуума. Языки с минимальными возможностями расположены внизу, с максимальными — вверху. Где-то посередине находится гипотетический язык Blub, который чуть менее чем полностью напоминает C. Грэм считает, что пользователи Blub будут презирать все языки, лежащие ниже Blub в этом континууме — Cobol, машинный язык, т.д. — и просто не смогут понять возможности тех языков, что лежат выше.

Это великолепный образ, но давайте рассмотрим данную метафору с другой стороны. Возможно, Python лежит выше C, а Lisp подобен вишенке на торте абстракций, но изучение Python или Lisp не слишком помогает понять, как именно работает компьютер, на котором зиждется этот континуум. Таким образом, несмотря на то, что Lisp-программисты кажутся всеведущими небожителями, в иерархии языков программирования заглянуть «вниз» ничуть не проще, чем «вверх».

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

Популярность Python связана с тем, что он занимает в описанном континууме позицию выше среднего. Он абстрактнее C и производительнее в работе, но не настолько абстрактен, чтобы у вас голова пошла кругом от метапрограммирования и рекурсии.

Беда в том, что равно как Lisp кажется вычурным и избыточным среднему Blub-программисту, так и C производит аналогичное впечатление на питонщика. Что это за указатели, о которых все говорят? «Звучит мудрено (размышляет питонщик) и если я до сих пор как-то работаю без этих указателей, обойдусь без них и дальше».

Поэтому питонщики в большинстве своем никогда не станут изучать C.

Бесспорно, можно сделать долгую и успешную карьеру в IT, не зная C. Однако культура программирования без изучения C дает ряд порочных эффектов, которые непосредственно связаны с тем, что человек знакомится с программированием на примере Python.

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

Вы можете возразить, что в данный исторический момент важнее написать больше программ, чем больше качественных программ. Возможно, с экономической точки зрения так и есть. Технологии развиваются очень быстро, незачем писать филигранно сработанную программу, которая никому не нужна. Но культура «просто используй Python», «компьютеры сейчас достаточно быстрые» и «пусть проблему решает железо» приводят к глубокому системному кризису: когда в профессию входят через Python и третируют C, все меньше настоящих умников будут попадать в профессиональное программирование.

Умерьте гнев на минуточку и выслушайте мои аргументы.

Я считаю, что для таких «умников», собирающихся изучать программирование, Python в качестве первого языка непривлекателен по двум причинам. Во-первых, изучить Python не так уж и сложно. Ключевые концепции этого языка как следует не цепляют технарей-интеллектуалов и, соответственно, не вызывают особого интереса. Изучать Python, я бы сказал, несколько скучно. Все равно как ходить в школу, где нет профильных классов.

Второй механизм описала моя знакомая, которая недавно записалась на воркшоп по Python. Она сказала, что с большим удовольствием учила циклы и функции. Они были маленькими, понятными, самодостаточными. Но потом преподаватель решил продемонстрировать «всю мощь Python» и потратил оставшуюся часть занятия на написание какой-то бесполезной программки с Python Twitter API.

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

«Просто плохой воркшоп попался», — скажете вы. Но на этом примере я хочу подчеркнуть более масштабную проблему: не изучив для начала C, программист оказывается лишен необходимых орудий, позволяющих понять, что именно происходит в используемой системе. Если вы — умный и пытливый питонщик, то вскоре докопаетесь до плотных пород языка C. Под этими горизонтами, скажут вам, «бойся драконов, костей и отладчиков». Соответственно, если вы не будете достаточно отважны и не проигнорируете предупреждений «да не берись ты за этот C», вы никогда не исследуете глубин, на которые можно забраться просто из любопытства.

Напротив, сишник, пытающийся понять фрагмент кода на C, в худшем случае должен будет перелопатить кучу заголовочных файлов, man-справки и исходного кода. Но едва ли ему попадется какой-нибудь странный пакет Lisp или Python. Копают всегда вниз, а не вверх. Такова суть компьютеров.

**
Мотивация программиста бывает двоякой: либо как можно лучше решить задачу, либо понять, как работают те или иные вещи. Бесспорно, Python отлично подходит для решения задач. Об этом свидетельствует популярность Python на стартапах и университетских курсах (в том числе, по Data Science). Если вы собираетесь за всю жизнь изучить только один язык программирования, то Python — надежный, эффективный и разумный выбор.

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

В этом, полагаю, и заключается реальная проблема с «программированием без C» — а также с более глобальной идеей о том, что вводные языки программирования должны быть «выразительными» и «доступными для начинающих». Гильдия программистов теряет как раз тех людей, которые могли бы собой ее украсить.

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

Вкратце остановлюсь и на том, почему в университетах преподают именно Python (а раньше преподавали Java). Основная причина в том, что задача университетов – не в том, чтобы воспитывать программистов-асов. На большинстве факультетов стараются просто подготовить как можно больше успешных выпускников, которые пойдут в аспирантуру или найдут высокооплачиваемую работу. Ни то, ни другое не требует исключительного программерского мастерства.

С точки зрения преподавателя, язык программирования — это материал, на котором нужно изучить основы информатики: алгоритмы, структуры данных и т.д. Python — золотая середина, поскольку его легко изучить (профессора довольны), а еще он используется в коммерческих проектах (профессора просто ликуют). Добавьте сюда популярность Python в университетах, изобилие онлайновых материалов, а также повсюду цитируемое (и редко оспариваемое) утверждение, что Python — «хороший учебный язык». Ну что с ним может пойти не так?

Мне кажется, что люди, попадающие в программирование через Python, упускают массу всего интересного. Существует распространенное мнение, что кайф программирования — решать разнообразнейшие задачи в минимальном объеме кода, вовсю используя клиентские библиотеки, т.п. Это справедливо в случаях, когда человек должен управиться с работой, уложившись в сроки. Но если ваша основная мотивация — чему-то научиться и стать первоклассным программистом, то гораздо интереснее будет писать программы, работающие не столь эффективно, но оставляющие пищу для размышлений.

Для людей, которые никогда раньше не программировали, язык C — отличный тренажер. Указатели и их арифметика не имеют близких аналогов в повседневном мире. Изучая этот язык, вы будете натыкаться на, казалось бы, бессмысленные сообщения об ошибках и иметь дело с недетерминированными отказами. Если у вас проблемы с арифметикой, то вы можете повредить стек вызовов; забудете о простой проверке граничных условий — и куча посыплется как карточный домик. Иногда вам захочется вломить монитору или порыдать на клавиатуре.

Но дело того стоит: язык C помогает получить хорошее представление о том, что именно делает компьютер. Вы почувствуете себя как подросток, сражающийся с ручной коробкой передач. Задавая вопросы «почему?» и закапываясь все глубже, вы постепенно усвоите модель процессов, архитектуру процессора, иерархию памяти, разберетесь в операционной системе и т.д. Именно эта ментальная модель, а не язык C как таковой, поможет вам сориентироваться в абстракциях, которые написали другие и создавать программы, которые некогда казались вам немыслимыми.

Итак, если вы хотите научиться мастерски программировать — на любом языке — то не поддавайтесь на уговоры изучать Python или, упаси Бог, Lisp, а начинайте путь с C. Сверху открываются шикарные виды, но если вы хотите покорить гору, то взбираться на нее лучше всего снизу.
О книгах Зеда Шоу

Проголосовал 561 человек. Воздержалось 147 человек.

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

Автор: @ph_piter Evan Miller

Комментарии (62)

  • +6
    мой вариант: «Да, переводите книгу по Cи и начните уже писать этот язык как „Си“, буква „С“ в русском читается как „Эс“».
    • +10
      В тексте используется латинская C. Посмотрите на код символа.
      • –11
        >латинская C
        Тавтология.
      • +8
        В печатной книге как код символа посмотреть?
      • +3
        При возможности разночтений при переводе предпочтительно использовать слово на целевом языке, чтобы читатель, который точно знает целевой язык лучше оригинала (иначе зачем ему перевод?!) прочитал слово без разночтений. «Си» лучше.
    • –2
      Почему бы тогда не писать «Си-плас-плас» вместо C++?
      • 0
        Если вы говорите «плас-плас», то так и пишите. Я говорю «плюс-плюс» и потому так и пишу — «++».
        • –2
          В смысле, вы пишите «Си++»? По вашей логике так и должно быть. И Джава вместо Java — а то вдруг прочитают, как «Ява». Я к тому, что это абсурд. В книге достаточно один раз написать в примечании переводчика, что C читается как «Си».
          • +1
            При переводе торговых марок, терминов, не имеющих стандартного общепринятого названия на целевом языке, предпочтительно оставлять их на языке оригинала или, чтобы глаз не «спотыкался», калькировать их с оригинала с выноской, на которой указано оригинальное написание. «C++» не оставляет разночтений и читается всеми верно.
  • +7
    Мы в школе учили С, и мне уже тогда были непонятны кучи странных абстракций. Только когда на первом курсе нам дали ассемблер, я наконец понял, о чём шла речь раньше.

    А на вопрос невозможно ответить, мало данных. Что вы будете делать, если НЕ будете переводить книгу? Какая альтернативная стоимость вашего проекта?
    • 0
      А что вам было непонятно, если не секрет? Мне Си всегда казался бронебойно примитивным. Там же вообще ничего нет, помима примитивов и указателей!
      • 0
        Sarcasm detection failed
      • +1
        >>Там же вообще ничего нет, помима примитивов и указателей!

        Мне было непонятно, каким образом printf узнаёт форму букв, которые выводит на экран.

        Мне было непонятно, как работает функция pset.

        Мне было непонятно, почему командная строка снова начинает работать, после того, как моя программа завершилась, если я не давал никакой команды её запускать. (return 0)

        Мне было непонятно, как программы могут работать одновременно, если в С для этого нет никаких инструментов, но известно, что windows написан на С.

        Мне было непонятно, как работает malloc.

        Мне было непонятно, как работает scanf, и почему он иногда читает с клавиатуры, а иногда — нет.

        Это я уже не говорю про кеш и «дефрагментацию памяти».
        • 0
          счастливые люди, которым непонятно такое, на не memory barriers, архитектуры памяти и прочие добрые вещи.
          • 0
            Ну, с этим всё-таки не сталкиваешься в 10 классе. А что такое «архитектура памяти» я и сейчас не знаю. Просветите?
            • 0
              Имелось ввиду uniform/non-uniform, но вообще правильный термин который тут должен был быть, это CPU memory model. Так, что из просвещения могу только к нему отослать, чтобы лишний раз не запутать.
        • 0
          А… понял, о чем вы. Ну это же — просто неумение абстрагироваться. Я, когда изучал тот или иной язык, в первую очередь обращал внимание на то, какие возможности он предоставляет внутри себя, его логика, семантика. Скажем, я до сих пор с трудом понимаю некоторые заковыристые синтаксические конструкции из C++ (в boost, например, далеко не весь код понятен). А Си очень прост в смысле своего синтаксиса и логики.

          А все вопросы, которые вы тут задали, я относил к числу «как работает операционная система» и разрешались они для меня по мере изучения сами собой… или не разрешались, если не попадали в область моих интересов. Но в любом случае они всегда находились за пределами понятия «возможности языка Си».
          • 0
            Так, речь, простите, и шла про «кучи странных абстракций». Про это собственно, «неумение абстрагироваться». Синтаксические кунштюки — они как раз школьнику довольно неплохо объяснимы, потому что у него ещё нет шаблонного мышления. Ну там, в языке много возможностей — ну и отлично, постольку, поскольку их можно самому реализовать, и они просто сокращают запись. Имея malloc, можно реализовать new, и наоборот.

            >>Но в любом случае они всегда находились за пределами понятия «возможности языка Си».

            Первое, что рассказывают на первом уроке по программированию «все языки программирования эквивалентны, потому что они эквивалентны машине Тьюринга». Значит термин «возможности языка» не имеет смысла.

            При этом это замечательная фраза, которая формально верна, а по сути — полное враньё. Но в школе об этом не говорят.
            • 0
              Меня в школе начали учить программированию ровно в тот момент, когда я уже написал и раздал своим друзьям простую игрушку на Паскале. И учили нас уж точно не программированию (учительница его сама знала немного хуже, чем я на тот момент). Так что этого «красивого вранья» избежал.

              Я знал, что если хочется быстро нарисовать на экране символы, не используя при этом «writeln» и не двигая курсор, надо объявить массив размером 80x25 и положить его по адресу b800:0 (мать, ведь до сих пор же помню!)

              При этом я не понимал, как именно система забирает оттуда этот буфер (я о сих пор этого точно не знаю, хотя очень убедительно догадываюсь ;) ). Я знал, что по 33-му прерыванию с помощью нескольких шаманизмом можно читать координаты мыши, если запущен mouse.com.

              Для моих задач этих знаний было достаточно.

              Синтаксические кунштюки — они как раз школьнику довольно неплохо объяснимы

              Подозреваю, что вы мало что объясняли школьникам. Потому что объяснить школьнику суть и смысл такой вещи, как ООП, чтобы он понял, нагрева вообще это странное слово «class» — задача кропотливая и тяжелая. И всё равно есть риск, что в итоге он спросит «а зачем функции в класс засовывать, ведь их можно снаружи оставить?».

              Под «возможностями языков» я, конечно, подразумевал не их теоретическую мощность с точки зрения turing-completeness, а то, как и в какой степени их парадигмы помогают разрабатывать те или иные системы.
              • 0
                Хм, ну личный опыт — штука такая. Мне в своё время классы легко дались. Но у нас на физтехе лектор был хороший.
  • +7
    Люблю Си! Даешь больше книжек!
  • +1
    В связи с этой книгой у автора (Zed Shaw) случилась большая драма. Например, вот здесь он пишет, что хотел донести мысль о том, что с самого момента изобретения на Си писали неправильно. С ним много кто не соглашался в интернете.
  • +1
    мне не нравится стиль этого автора, и мне жалко времени которое я примерно 3 года назад потратил на чтение его книги. Это «скучный/нудный» путь, для очень странной целевой аудитории. С одной стороны, очень простые вещи объясняются слишком подробно (т.е. вроде для новичков), а потом сложные темы отдаются на самостоятельный работу.
    «сейчас мы к концу 3ей страницы разобрались как складывать числа, а теперь вот этот интеграл посчитайте самостоятельно».
    если есть желание и терпение самостоятельно разбираться, то такая книжка не нужна.
  • +7
    // When I find my code in tons of trouble,
    // Friends and colleagues come to me,
    // Speaking words of wisdom:
    // "Write in C."...
    

    • +1
      When I find my code in tons of trouble

      «Write in C.»

      Иронично. Вспомнил свой студенческий компилятор C-подобного языка в байткод, написанный на C, в котором был баг, вызванный порчей памяти при генерации кода, который заставил меня попотеть и подружил с gdb. Вот уж где можно легко нарваться на tons of trouble, так это в C. Впрочем, это ничуть не умаляет его важность для системного программирования. На чём ещё писать Linux, в конце концов?
  • +5
    Думаю, автор заметки «What every programmer should know about memory» тоже может поворчать по схожему поводу — многие программисты на Си понятия не имеют как работает динамическая память и какой режим её работы наиболее эффективный.
    • –6
      Почему? Про динамическую память они всё прекрасно знают: если malloc вернул NULL — значит, память кончилась. А всякие глупости вроде сборщика мусора это для тех, кто сам за собой убрать не может.
      • +7
        А всякие глупости вроде устройства аллокаторов, работы кеша и трансляции адресов?
        • 0
          Вряд ли работа кеша и трансляция адресов имеют отношение конкретно к динамической памяти. Скорее, они относятся к памяти вообще. И про них программисты на Си могут знать больше, чем работающие на языках более высокого уровня. Но могут и меньше…
      • +6
        А ещё есть задержки на переключение между банками, автоматическая регенерация, автоматическая калибровка по температуре и т.д.

        Я недавно начал работать с DDR3 на FPGA и могу сказать, что работать с памятью эффективно — это сложно. А в зависимости от того какие команды и как часто поступают на чип скорость может различаться от 95% до 1%
        • +5
          Самая большая подстава в том, что эта «Random Access Memory» как раз в полностью рандомном режиме работает хуже всего, а максимальную скорость выдаёт в строго последовательном режиме.
  • +2
    Современная ситуация такова, что асов-разработчиков требуется больше, чем асов-программистов. Разработчики — инженеры. Инженеры отличаются прагматизмом. Они решают реальные задачи в прикладной области с использованием наиболее подходящих инструментов.

    Для того же, чтобы понять принцип работы оборудования, С учить не обязательно. Тут скорее нужен курс по ассемблеру, устройству ОС и ЯП
    • +2
      А разработчик в данном противопоставлении это что такое? Аналитик, архитектор и кодер в одном флаконе?
      • +1
        Аналитики, архитекторы, кодеры — это градации в системах, нацеленных на процесс. Звезд программирования там особо и не встречается. В технологических же системах все устроено немного по-другому. Назовите мне чистого архитектора или аналитка Linux, например, а то вот Линус тоже вроде как аналитик, архитектор и кодер в одном флаконе
        • 0
          Так что вы понимаете под «асом-разработчиком» и «асом-программистом»? В основная особенность каждого из них, выделяющая его из общей массы «девелоперов»?
          • 0
            То же, что и автор статьи. В конце концов, это же его терминология.

            Разница между программистом и разработчиком в том, что программист программирует программу по спецификации, его конечная цель — программа. Разработчики-инженеры решают прикладные задачи, которые в том числе требуют применения программирования, но конечная цель — не программа.
            • 0
              Совершенно непонятно. Вот команда разрабатывает какое-то сложное устройство. В нём много механических деталей, много электроники, много программ управления (как встроенных, так и внешних). Что является конечной целью того, кто пишет эти программы — программа или нет? Понятно, что конечная цель — «чтобы всё работало», но и к программам это тоже относится. Не получается ли, что те, кто занимается техникой и электроникой — разработчики, а тот, кто пишет программы — программист?
              Да, спецификация разрабатывается совместными усилиями. Часто после того, как программа частично написана.
    • +2
      Курс по устройству ОС и ЯП без C как-то несерьезен.
      • 0
        Почему?
        • +1
          Да хотябы потому, что разбирать примеры из реальной жизни и играться с операционными системами и реализациями языков придется на C. И даже многие учебные системы, типа Minix, написаны на нем же.
          • 0
            Хм, с такой точки зрения изучение С действительно имеет смысл. Но тогда знание языка становится не самоцелью, просто этот инструмент необходим для разбора примеров работы ОС.
            • +1
              Знание языка почти никогда не бывает самоцелью. Кто захочет учить язык просто так, когда другие можно применять в реальной жизни?
              Конечно, бывают особые почитатели стиля / красоты / выразительности / etc, но по мне это невероятная редкость.
              • 0
                Простейший вариант — чтобы приёмы (типы, структуры данных, идеи устройства библиотек) из этого языка применять в другом языке. Вплоть до реализации микроинтерпретатора, если понадобится.
                • 0
                  Тут конкретная цель — изучать язык, чтобы использовать полученные знания. Самоцель, как я понимаю, это когда изучаешь язык просто чтобы изучить, наслаждаться процессом. Ничего больше, никакого результата.
                  • 0
                    Я сейчас примерно в таком режиме изучаю ассемблер ARM. Не знаю, пригодятся ли полученные знания.
              • 0
                В статье как-то так написано, что изучение С автоматически даст вам понимание того, как все работает. На самом деле ничего подобного не произойдет.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    в иерархии языков программирования заглянуть «вниз» ничуть не проще, чем «вверх».

    Хорошо сказал, я аж проникся.
  • 0
    Переводите, только не пожалейте денег на хорошего переводчика и редактора.
  • +2
    Забавная позиция. Си предподносится как низкоуровневый язык для изучения потрохов, и в качестве примера приводится кэш процессора. Так кэш процессора ниже Си! Он даже ниже ассемблера! Кэш процессора — в равной степени «особенность железа» что для сишника, что для питонщика.

    Да и любой язык — абстракция. Изучал Си, а теперь все изучают Питон, и хочется возмутиться, что нынче никто не понимает потрохов? В равной степени начавший изучение программирования с ассемблера возмутится, что новое поколение, изучающее программирование на Си, ничего не понимает в машинных инструкциях, и какая операция во что транслируется.

    Ну вот я начинал с Logo и C/C++. А про кэш процессора услышал в первый раз при изучении C# много позже, в контексте сборки мусора и упаковки памяти. Это при том, что расстояние от шарпа до машинных инструкций заметно больше, чем от плюсов.
    • 0
      В C# «расстояние до машинных инструкций» примерно такое же, как в С++. JIT генерирует очень хороший код. Разве что надо следить за проверками индексов массивов.
  • +3
    и там будет машина, которую никто не сможет вести, потому что у нее будет ручное переключение скоростей

    Это сделало мой день
  • +1
    Надо было учиться ездить на машине без синхронизатора КПП, вдруг на вечеринке пришлось бы студебеккер перегонять
  • –3
    Проголосовал «Не стоит, вся информация в свободном доступе»: последнюю книгу покупал наверное лет 5 назад. Сейчас все есть онлайн в виде статей, туториалов, материалов, бесплатно да и гораздо новее чем в бумажном виде. Погуглив 10 минут, можно найти онлайн материалы по практически любой тематике. Да и книга по «С» сейчас имхо «не взлетит» в плане объема продаж. Те, кто проголосовал «переводите», ответьте себе сначала — вы купите такую книгу за 500-1000р? Скорее всего нет.

    Что касается обучения программированию. Питон удобен тем, что позволяет БЫСТРО начать. Я помню, как мне этого не хватало в школе на факультативах программирования, когда хотелось что-то сделать, а учитель грузил нудными лекциями :) И Питон в этом плане хорош для детей что быстро можно увидеть результат.
    Изучать Facebook API для питона наверно действительно не стоит, а те же математические задачи, головоломки, простые игры — для детей в самый раз. Если же курс для взрослых, тут задачи другие, быстро получить прикладной результат, тут и методология должна быть иная.
    А насчет С… Даже используя С++, мало кто работает со строками как с char* и с массивами как с указателями через new/alloc, так что низкий уровень даже тут скорее всего весьма закрыт. Честно говоря, сложно даже представить, какой процент использует чистый С, ну может программисты контроллеров разве что.

    Еще кстати один минус в копилку «С». На нем легко можно писать разве что консольные программы (вряд ли ученик будет разбираться с winmain, wndproc и HDC). Любому ученику скорее всего захочется показать результаты своим друзьям, а с консолью это хм… проблематично что ли.
    • 0
      Ещё кстати один минус в копилку «С». На нем легко можно писать разве что консольные программы (вряд ли ученик будет разбираться с winmain, wndproc и HDC). Любому ученику скорее всего захочется показать результаты своим друзьям, а с консолью это хм… проблематично что ли.

      Так навскидку — Gtk+ и вебсайты ( представляете их тоже можно написать на голом си ).
      И никаких унылых winmain, lpcwstr
      • 0
        EFL сегодня модно еще, вроде.
  • +4
    А насчет С… Даже используя С++, мало кто работает со строками как с char* и с массивами как с указателями через new/alloc, так что низкий уровень даже тут скорее всего весьма закрыт. Честно говоря, сложно даже представить, какой процент использует чистый С, ну может программисты контроллеров разве что.
    Вы явно не в теме системного программирования
  • +7
    Чушь. Я довольно неплохо представляю себе что происходит в компьютере, почему (void*)((int*)+1) == (void*)(char*)+4), и что там с обратной стороны стека.

    Однако, каждый раз, когда я натыкаюсь «вверх», я испытываю затруднение и смущение. Есть специальные модули для тестирования? Да ну, это сложно, лучше я тесты руками напишу. У nose есть свой фреймворк для написания моков? Да ну, это сложно, лучше я по-старинке, руками. ОРМ? Да ну его, лучше в базу руками по-старинке. Я же знаю как устроен SQL, я не нуб какой-нибудь.

    Так вот, вверх сложнее, чем вниз. Потому что вниз — это лишь детали реализации. Спускаясь вниз каждый уже знает, что там «сверху» (потому что это сверху — это как привык). А поднимаясь вверх изучаешь что-то, о чём не знаешь, как оно устроено и, главное, не знаешь как оно должно быть. Не знаешь терминологии, теоретических идей, принципов построения, характерных паттернов.

    Выдайте харкдорному сишнику скомпилированный в Си код на бизоне. Удачи разобраться в таблице состояний и адских goto.
  • +3
    Мне понравились ответы на вопрос «какой язык изучать первым» в посте Александра. Замечу, что в основном советуют начинать с функциональных языков. Вот этот оборот
    или, упаси Бог, Lisp
    показался очень странным.
  • 0
    Однажды ты окажешься на вечеринке и там будет машина, которую никто не сможет вести, потому что у нее будет ручное переключение скоростей.

    И что, везти эту пьянную толпу? уж лучше самому выпить и вызвать такси.
    Скрытый текст
    не коим образом не принижаю достоинства владения управлением машиной на МКПП, сам вожу
  • 0
    Желание/потребность изучать асм или, хотя бы, Си, возникает рано или поздно у любого специалиста, мало знакомого с работой низкого уровня. И это — хорошо.
    Книга же может учить более или менее эффективно, быть скучной или не очень - из текста статьи Эвана Миллера никак не понятно, стоит ли читать книгу Зеда Шоу.

    В итоге: необходимость изучения Си — понятна, статью можно было не писать. Стоит ли переводить книгу — непонятно.
    На мой взгляд, определиться с интересом к автору помог бы перевод каких-нибудь его технических публикаций, находящихся в открытом доступе.

  • 0
    Интересно, на каком решении все-таки остановилось издательство? Стоит ждать книгу?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка