Comments 62
мой вариант: «Да, переводите книгу по Cи и начните уже писать этот язык как „Си“, буква „С“ в русском читается как „Эс“».
В тексте используется латинская C. Посмотрите на код символа.
UFO just landed and posted this here
В печатной книге как код символа посмотреть?
При возможности разночтений при переводе предпочтительно использовать слово на целевом языке, чтобы читатель, который точно знает целевой язык лучше оригинала (иначе зачем ему перевод?!) прочитал слово без разночтений. «Си» лучше.
Почему бы тогда не писать «Си-плас-плас» вместо C++?
Если вы говорите «плас-плас», то так и пишите. Я говорю «плюс-плюс» и потому так и пишу — «++».
В смысле, вы пишите «Си++»? По вашей логике так и должно быть. И Джава вместо Java — а то вдруг прочитают, как «Ява». Я к тому, что это абсурд. В книге достаточно один раз написать в примечании переводчика, что C читается как «Си».
При переводе торговых марок, терминов, не имеющих стандартного общепринятого названия на целевом языке, предпочтительно оставлять их на языке оригинала или, чтобы глаз не «спотыкался», калькировать их с оригинала с выноской, на которой указано оригинальное написание. «C++» не оставляет разночтений и читается всеми верно.
Мы в школе учили С, и мне уже тогда были непонятны кучи странных абстракций. Только когда на первом курсе нам дали ассемблер, я наконец понял, о чём шла речь раньше.
А на вопрос невозможно ответить, мало данных. Что вы будете делать, если НЕ будете переводить книгу? Какая альтернативная стоимость вашего проекта?
А на вопрос невозможно ответить, мало данных. Что вы будете делать, если НЕ будете переводить книгу? Какая альтернативная стоимость вашего проекта?
А что вам было непонятно, если не секрет? Мне Си всегда казался бронебойно примитивным. Там же вообще ничего нет, помима примитивов и указателей!
Sarcasm detection failed
>>Там же вообще ничего нет, помима примитивов и указателей!
Мне было непонятно, каким образом printf узнаёт форму букв, которые выводит на экран.
Мне было непонятно, как работает функция pset.
Мне было непонятно, почему командная строка снова начинает работать, после того, как моя программа завершилась, если я не давал никакой команды её запускать. (return 0)
Мне было непонятно, как программы могут работать одновременно, если в С для этого нет никаких инструментов, но известно, что windows написан на С.
Мне было непонятно, как работает malloc.
Мне было непонятно, как работает scanf, и почему он иногда читает с клавиатуры, а иногда — нет.
Это я уже не говорю про кеш и «дефрагментацию памяти».
Мне было непонятно, каким образом printf узнаёт форму букв, которые выводит на экран.
Мне было непонятно, как работает функция pset.
Мне было непонятно, почему командная строка снова начинает работать, после того, как моя программа завершилась, если я не давал никакой команды её запускать. (return 0)
Мне было непонятно, как программы могут работать одновременно, если в С для этого нет никаких инструментов, но известно, что windows написан на С.
Мне было непонятно, как работает malloc.
Мне было непонятно, как работает scanf, и почему он иногда читает с клавиатуры, а иногда — нет.
Это я уже не говорю про кеш и «дефрагментацию памяти».
счастливые люди, которым непонятно такое, на не memory barriers, архитектуры памяти и прочие добрые вещи.
А… понял, о чем вы. Ну это же — просто неумение абстрагироваться. Я, когда изучал тот или иной язык, в первую очередь обращал внимание на то, какие возможности он предоставляет внутри себя, его логика, семантика. Скажем, я до сих пор с трудом понимаю некоторые заковыристые синтаксические конструкции из C++ (в boost, например, далеко не весь код понятен). А Си очень прост в смысле своего синтаксиса и логики.
А все вопросы, которые вы тут задали, я относил к числу «как работает операционная система» и разрешались они для меня по мере изучения сами собой… или не разрешались, если не попадали в область моих интересов. Но в любом случае они всегда находились за пределами понятия «возможности языка Си».
А все вопросы, которые вы тут задали, я относил к числу «как работает операционная система» и разрешались они для меня по мере изучения сами собой… или не разрешались, если не попадали в область моих интересов. Но в любом случае они всегда находились за пределами понятия «возможности языка Си».
Так, речь, простите, и шла про «кучи странных абстракций». Про это собственно, «неумение абстрагироваться». Синтаксические кунштюки — они как раз школьнику довольно неплохо объяснимы, потому что у него ещё нет шаблонного мышления. Ну там, в языке много возможностей — ну и отлично, постольку, поскольку их можно самому реализовать, и они просто сокращают запись. Имея malloc, можно реализовать new, и наоборот.
>>Но в любом случае они всегда находились за пределами понятия «возможности языка Си».
Первое, что рассказывают на первом уроке по программированию «все языки программирования эквивалентны, потому что они эквивалентны машине Тьюринга». Значит термин «возможности языка» не имеет смысла.
При этом это замечательная фраза, которая формально верна, а по сути — полное враньё. Но в школе об этом не говорят.
>>Но в любом случае они всегда находились за пределами понятия «возможности языка Си».
Первое, что рассказывают на первом уроке по программированию «все языки программирования эквивалентны, потому что они эквивалентны машине Тьюринга». Значит термин «возможности языка» не имеет смысла.
При этом это замечательная фраза, которая формально верна, а по сути — полное враньё. Но в школе об этом не говорят.
Меня в школе начали учить программированию ровно в тот момент, когда я уже написал и раздал своим друзьям простую игрушку на Паскале. И учили нас уж точно не программированию (учительница его сама знала немного хуже, чем я на тот момент). Так что этого «красивого вранья» избежал.
Я знал, что если хочется быстро нарисовать на экране символы, не используя при этом «writeln» и не двигая курсор, надо объявить массив размером 80x25 и положить его по адресу b800:0 (мать, ведь до сих пор же помню!)
При этом я не понимал, как именно система забирает оттуда этот буфер (я о сих пор этого точно не знаю, хотя очень убедительно догадываюсь ;) ). Я знал, что по 33-му прерыванию с помощью нескольких шаманизмом можно читать координаты мыши, если запущен mouse.com.
Для моих задач этих знаний было достаточно.
Подозреваю, что вы мало что объясняли школьникам. Потому что объяснить школьнику суть и смысл такой вещи, как ООП, чтобы он понял, нагрева вообще это странное слово «class» — задача кропотливая и тяжелая. И всё равно есть риск, что в итоге он спросит «а зачем функции в класс засовывать, ведь их можно снаружи оставить?».
Под «возможностями языков» я, конечно, подразумевал не их теоретическую мощность с точки зрения turing-completeness, а то, как и в какой степени их парадигмы помогают разрабатывать те или иные системы.
Я знал, что если хочется быстро нарисовать на экране символы, не используя при этом «writeln» и не двигая курсор, надо объявить массив размером 80x25 и положить его по адресу b800:0 (мать, ведь до сих пор же помню!)
При этом я не понимал, как именно система забирает оттуда этот буфер (я о сих пор этого точно не знаю, хотя очень убедительно догадываюсь ;) ). Я знал, что по 33-му прерыванию с помощью нескольких шаманизмом можно читать координаты мыши, если запущен mouse.com.
Для моих задач этих знаний было достаточно.
Синтаксические кунштюки — они как раз школьнику довольно неплохо объяснимы
Подозреваю, что вы мало что объясняли школьникам. Потому что объяснить школьнику суть и смысл такой вещи, как ООП, чтобы он понял, нагрева вообще это странное слово «class» — задача кропотливая и тяжелая. И всё равно есть риск, что в итоге он спросит «а зачем функции в класс засовывать, ведь их можно снаружи оставить?».
Под «возможностями языков» я, конечно, подразумевал не их теоретическую мощность с точки зрения turing-completeness, а то, как и в какой степени их парадигмы помогают разрабатывать те или иные системы.
Люблю Си! Даешь больше книжек!
В связи с этой книгой у автора (Zed Shaw) случилась большая драма. Например, вот здесь он пишет, что хотел донести мысль о том, что с самого момента изобретения на Си писали неправильно. С ним много кто не соглашался в интернете.
мне не нравится стиль этого автора, и мне жалко времени которое я примерно 3 года назад потратил на чтение его книги. Это «скучный/нудный» путь, для очень странной целевой аудитории. С одной стороны, очень простые вещи объясняются слишком подробно (т.е. вроде для новичков), а потом сложные темы отдаются на самостоятельный работу.
«сейчас мы к концу 3ей страницы разобрались как складывать числа, а теперь вот этот интеграл посчитайте самостоятельно».
если есть желание и терпение самостоятельно разбираться, то такая книжка не нужна.
«сейчас мы к концу 3ей страницы разобрались как складывать числа, а теперь вот этот интеграл посчитайте самостоятельно».
если есть желание и терпение самостоятельно разбираться, то такая книжка не нужна.
// When I find my code in tons of trouble,
// Friends and colleagues come to me,
// Speaking words of wisdom:
// "Write in C."...
When I find my code in tons of trouble
…
«Write in C.»
Иронично. Вспомнил свой студенческий компилятор C-подобного языка в байткод, написанный на C, в котором был баг, вызванный порчей памяти при генерации кода, который заставил меня попотеть и подружил с gdb. Вот уж где можно легко нарваться на tons of trouble, так это в C. Впрочем, это ничуть не умаляет его важность для системного программирования. На чём ещё писать Linux, в конце концов?
Думаю, автор заметки «What every programmer should know about memory» тоже может поворчать по схожему поводу — многие программисты на Си понятия не имеют как работает динамическая память и какой режим её работы наиболее эффективный.
Почему? Про динамическую память они всё прекрасно знают: если malloc вернул NULL — значит, память кончилась. А всякие глупости вроде сборщика мусора это для тех, кто сам за собой убрать не может.
А всякие глупости вроде устройства аллокаторов, работы кеша и трансляции адресов?
А ещё есть задержки на переключение между банками, автоматическая регенерация, автоматическая калибровка по температуре и т.д.
Я недавно начал работать с DDR3 на FPGA и могу сказать, что работать с памятью эффективно — это сложно. А в зависимости от того какие команды и как часто поступают на чип скорость может различаться от 95% до 1%
Я недавно начал работать с DDR3 на FPGA и могу сказать, что работать с памятью эффективно — это сложно. А в зависимости от того какие команды и как часто поступают на чип скорость может различаться от 95% до 1%
Современная ситуация такова, что асов-разработчиков требуется больше, чем асов-программистов. Разработчики — инженеры. Инженеры отличаются прагматизмом. Они решают реальные задачи в прикладной области с использованием наиболее подходящих инструментов.
Для того же, чтобы понять принцип работы оборудования, С учить не обязательно. Тут скорее нужен курс по ассемблеру, устройству ОС и ЯП
Для того же, чтобы понять принцип работы оборудования, С учить не обязательно. Тут скорее нужен курс по ассемблеру, устройству ОС и ЯП
А разработчик в данном противопоставлении это что такое? Аналитик, архитектор и кодер в одном флаконе?
Аналитики, архитекторы, кодеры — это градации в системах, нацеленных на процесс. Звезд программирования там особо и не встречается. В технологических же системах все устроено немного по-другому. Назовите мне чистого архитектора или аналитка Linux, например, а то вот Линус тоже вроде как аналитик, архитектор и кодер в одном флаконе
Так что вы понимаете под «асом-разработчиком» и «асом-программистом»? В основная особенность каждого из них, выделяющая его из общей массы «девелоперов»?
То же, что и автор статьи. В конце концов, это же его терминология.
Разница между программистом и разработчиком в том, что программист программирует программу по спецификации, его конечная цель — программа. Разработчики-инженеры решают прикладные задачи, которые в том числе требуют применения программирования, но конечная цель — не программа.
Разница между программистом и разработчиком в том, что программист программирует программу по спецификации, его конечная цель — программа. Разработчики-инженеры решают прикладные задачи, которые в том числе требуют применения программирования, но конечная цель — не программа.
Совершенно непонятно. Вот команда разрабатывает какое-то сложное устройство. В нём много механических деталей, много электроники, много программ управления (как встроенных, так и внешних). Что является конечной целью того, кто пишет эти программы — программа или нет? Понятно, что конечная цель — «чтобы всё работало», но и к программам это тоже относится. Не получается ли, что те, кто занимается техникой и электроникой — разработчики, а тот, кто пишет программы — программист?
Да, спецификация разрабатывается совместными усилиями. Часто после того, как программа частично написана.
Да, спецификация разрабатывается совместными усилиями. Часто после того, как программа частично написана.
Курс по устройству ОС и ЯП без C как-то несерьезен.
Почему?
Да хотябы потому, что разбирать примеры из реальной жизни и играться с операционными системами и реализациями языков придется на C. И даже многие учебные системы, типа Minix, написаны на нем же.
Хм, с такой точки зрения изучение С действительно имеет смысл. Но тогда знание языка становится не самоцелью, просто этот инструмент необходим для разбора примеров работы ОС.
Знание языка почти никогда не бывает самоцелью. Кто захочет учить язык просто так, когда другие можно применять в реальной жизни?
Конечно, бывают особые почитатели стиля / красоты / выразительности / etc, но по мне это невероятная редкость.
Конечно, бывают особые почитатели стиля / красоты / выразительности / etc, но по мне это невероятная редкость.
Простейший вариант — чтобы приёмы (типы, структуры данных, идеи устройства библиотек) из этого языка применять в другом языке. Вплоть до реализации микроинтерпретатора, если понадобится.
В статье как-то так написано, что изучение С автоматически даст вам понимание того, как все работает. На самом деле ничего подобного не произойдет.
UFO just landed and posted this here
в иерархии языков программирования заглянуть «вниз» ничуть не проще, чем «вверх».
Хорошо сказал, я аж проникся.
Переводите, только не пожалейте денег на хорошего переводчика и редактора.
Забавная позиция. Си предподносится как низкоуровневый язык для изучения потрохов, и в качестве примера приводится кэш процессора. Так кэш процессора ниже Си! Он даже ниже ассемблера! Кэш процессора — в равной степени «особенность железа» что для сишника, что для питонщика.
Да и любой язык — абстракция. Изучал Си, а теперь все изучают Питон, и хочется возмутиться, что нынче никто не понимает потрохов? В равной степени начавший изучение программирования с ассемблера возмутится, что новое поколение, изучающее программирование на Си, ничего не понимает в машинных инструкциях, и какая операция во что транслируется.
Ну вот я начинал с Logo и C/C++. А про кэш процессора услышал в первый раз при изучении C# много позже, в контексте сборки мусора и упаковки памяти. Это при том, что расстояние от шарпа до машинных инструкций заметно больше, чем от плюсов.
Да и любой язык — абстракция. Изучал Си, а теперь все изучают Питон, и хочется возмутиться, что нынче никто не понимает потрохов? В равной степени начавший изучение программирования с ассемблера возмутится, что новое поколение, изучающее программирование на Си, ничего не понимает в машинных инструкциях, и какая операция во что транслируется.
Ну вот я начинал с Logo и C/C++. А про кэш процессора услышал в первый раз при изучении C# много позже, в контексте сборки мусора и упаковки памяти. Это при том, что расстояние от шарпа до машинных инструкций заметно больше, чем от плюсов.
и там будет машина, которую никто не сможет вести, потому что у нее будет ручное переключение скоростей
Это сделало мой день
Надо было учиться ездить на машине без синхронизатора КПП, вдруг на вечеринке пришлось бы студебеккер перегонять
Проголосовал «Не стоит, вся информация в свободном доступе»: последнюю книгу покупал наверное лет 5 назад. Сейчас все есть онлайн в виде статей, туториалов, материалов, бесплатно да и гораздо новее чем в бумажном виде. Погуглив 10 минут, можно найти онлайн материалы по практически любой тематике. Да и книга по «С» сейчас имхо «не взлетит» в плане объема продаж. Те, кто проголосовал «переводите», ответьте себе сначала — вы купите такую книгу за 500-1000р? Скорее всего нет.
Что касается обучения программированию. Питон удобен тем, что позволяет БЫСТРО начать. Я помню, как мне этого не хватало в школе на факультативах программирования, когда хотелось что-то сделать, а учитель грузил нудными лекциями :) И Питон в этом плане хорош для детей что быстро можно увидеть результат.
Изучать Facebook API для питона наверно действительно не стоит, а те же математические задачи, головоломки, простые игры — для детей в самый раз. Если же курс для взрослых, тут задачи другие, быстро получить прикладной результат, тут и методология должна быть иная.
А насчет С… Даже используя С++, мало кто работает со строками как с char* и с массивами как с указателями через new/alloc, так что низкий уровень даже тут скорее всего весьма закрыт. Честно говоря, сложно даже представить, какой процент использует чистый С, ну может программисты контроллеров разве что.
Еще кстати один минус в копилку «С». На нем легко можно писать разве что консольные программы (вряд ли ученик будет разбираться с winmain, wndproc и HDC). Любому ученику скорее всего захочется показать результаты своим друзьям, а с консолью это хм… проблематично что ли.
Что касается обучения программированию. Питон удобен тем, что позволяет БЫСТРО начать. Я помню, как мне этого не хватало в школе на факультативах программирования, когда хотелось что-то сделать, а учитель грузил нудными лекциями :) И Питон в этом плане хорош для детей что быстро можно увидеть результат.
Изучать Facebook API для питона наверно действительно не стоит, а те же математические задачи, головоломки, простые игры — для детей в самый раз. Если же курс для взрослых, тут задачи другие, быстро получить прикладной результат, тут и методология должна быть иная.
А насчет С… Даже используя С++, мало кто работает со строками как с char* и с массивами как с указателями через new/alloc, так что низкий уровень даже тут скорее всего весьма закрыт. Честно говоря, сложно даже представить, какой процент использует чистый С, ну может программисты контроллеров разве что.
Еще кстати один минус в копилку «С». На нем легко можно писать разве что консольные программы (вряд ли ученик будет разбираться с winmain, wndproc и HDC). Любому ученику скорее всего захочется показать результаты своим друзьям, а с консолью это хм… проблематично что ли.
Ещё кстати один минус в копилку «С». На нем легко можно писать разве что консольные программы (вряд ли ученик будет разбираться с winmain, wndproc и HDC). Любому ученику скорее всего захочется показать результаты своим друзьям, а с консолью это хм… проблематично что ли.
Так навскидку — Gtk+ и вебсайты ( представляете их тоже можно написать на голом си ).
И никаких унылых winmain, lpcwstr
А насчет С… Даже используя С++, мало кто работает со строками как с char* и с массивами как с указателями через new/alloc, так что низкий уровень даже тут скорее всего весьма закрыт. Честно говоря, сложно даже представить, какой процент использует чистый С, ну может программисты контроллеров разве что.Вы явно не в теме системного программирования
Чушь. Я довольно неплохо представляю себе что происходит в компьютере, почему (void*)((int*)+1) == (void*)(char*)+4), и что там с обратной стороны стека.
Однако, каждый раз, когда я натыкаюсь «вверх», я испытываю затруднение и смущение. Есть специальные модули для тестирования? Да ну, это сложно, лучше я тесты руками напишу. У nose есть свой фреймворк для написания моков? Да ну, это сложно, лучше я по-старинке, руками. ОРМ? Да ну его, лучше в базу руками по-старинке. Я же знаю как устроен SQL, я не нуб какой-нибудь.
Так вот, вверх сложнее, чем вниз. Потому что вниз — это лишь детали реализации. Спускаясь вниз каждый уже знает, что там «сверху» (потому что это сверху — это как привык). А поднимаясь вверх изучаешь что-то, о чём не знаешь, как оно устроено и, главное, не знаешь как оно должно быть. Не знаешь терминологии, теоретических идей, принципов построения, характерных паттернов.
Выдайте харкдорному сишнику скомпилированный в Си код на бизоне. Удачи разобраться в таблице состояний и адских goto.
Однако, каждый раз, когда я натыкаюсь «вверх», я испытываю затруднение и смущение. Есть специальные модули для тестирования? Да ну, это сложно, лучше я тесты руками напишу. У nose есть свой фреймворк для написания моков? Да ну, это сложно, лучше я по-старинке, руками. ОРМ? Да ну его, лучше в базу руками по-старинке. Я же знаю как устроен SQL, я не нуб какой-нибудь.
Так вот, вверх сложнее, чем вниз. Потому что вниз — это лишь детали реализации. Спускаясь вниз каждый уже знает, что там «сверху» (потому что это сверху — это как привык). А поднимаясь вверх изучаешь что-то, о чём не знаешь, как оно устроено и, главное, не знаешь как оно должно быть. Не знаешь терминологии, теоретических идей, принципов построения, характерных паттернов.
Выдайте харкдорному сишнику скомпилированный в Си код на бизоне. Удачи разобраться в таблице состояний и адских goto.
Мне понравились ответы на вопрос «какой язык изучать первым» в посте Александра. Замечу, что в основном советуют начинать с функциональных языков. Вот этот оборот
или, упаси Бог, Lispпоказался очень странным.
Однажды ты окажешься на вечеринке и там будет машина, которую никто не сможет вести, потому что у нее будет ручное переключение скоростей.
И что, везти эту пьянную толпу? уж лучше самому выпить и вызвать такси.
Скрытый текст
не коим образом не принижаю достоинства владения управлением машиной на МКПП, сам вожу
Желание/потребность изучать асм или, хотя бы, Си, возникает рано или поздно у любого специалиста, мало знакомого с работой низкого уровня. И это — хорошо.
Книга же может учить более или менее эффективно, быть скучной или не очень - из текста статьи Эвана Миллера никак не понятно, стоит ли читать книгу Зеда Шоу.
В итоге: необходимость изучения Си — понятна, статью можно было не писать. Стоит ли переводить книгу — непонятно.
На мой взгляд, определиться с интересом к автору помог бы перевод каких-нибудь его технических публикаций, находящихся в открытом доступе.
Книга же может учить более или менее эффективно, быть скучной или не очень - из текста статьи Эвана Миллера никак не понятно, стоит ли читать книгу Зеда Шоу.
В итоге: необходимость изучения Си — понятна, статью можно было не писать. Стоит ли переводить книгу — непонятно.
На мой взгляд, определиться с интересом к автору помог бы перевод каких-нибудь его технических публикаций, находящихся в открытом доступе.
Интересно, на каком решении все-таки остановилось издательство? Стоит ждать книгу?
Sign up to leave a comment.
Копают только вниз