Может ли знание C повредить код, который вы пишете на языках более высокого уровня?
Вопрос, кажется, решен, даже забит до смерти. Умные люди говорили умные вещи на эту тему. Чтобы быть действительно хорошим программистом, вам нужно знать Си.
Или ты?
Я был просветленным дважды на этой неделе. Первая заставила меня понять, что мои предположения не выходят за рамки моих знаний, и, учитывая сложность программного обеспечения, работающего на моей машине, его практически не существует. Но что действительно привело его домой, так это комментарий Slashdot:
Конечным результатом является то, что я замечаю множество наивных способов, с помощью которых традиционные программисты на "голом металле" предполагают, что реализованы языки более высокого уровня. Они принимают плохие "оптимизационные" решения в проектах, на которые они влияют, потому что они понятия не имеют, как работает компилятор, или насколько отличная хорошая среда выполнения может отличаться от наивной модели макрокомпонента, которую они понимают.
Затем меня поразило: C - это просто еще одна абстракция, как и все остальные. Даже сам процессор - только абстракция! Я просто никогда не видел, чтобы это сломалось, потому что у меня нет инструментов для его измерения.
Я не совсем понимаю. Был ли мой ум изуродован до выздоровления, как Дейкстра сказал о Бейсике? Живу ли я в состоянии преждевременной оптимизации? Есть ли надежда для меня, теперь, когда я понял, что ничего не знаю? Есть что-нибудь еще знать? И почему это так увлекательно, что все, что я написал за последние пять лет, могло быть в корне неверным?
Подводя итог: есть ли смысл знать больше, чем говорят мне документы по API?
РЕДАКТИРОВАТЬ: Сделано CW. Конечно, это также означает, что теперь вы должны публиковать примеры оптимизации интерпретатора / среды выполнения лучше, чем мы:)
19 ответов
Ни знание C, ни знание деталей реализации более низкого уровня не навредят вам самим. Что может и будет вам больно, если вы будете постоянно думать и работать с точки зрения низкоуровневых деталей, даже если это неуместно.
Старая поговорка гласила, что "настоящие программисты могут писать на фортране на любом языке". Если вы делаете то же самое с помощью C, это не улучшение. Если ты пишешь Лисп, пиши Лисп. Если вы пишете Python, напишите Python. То, что подходит и разумно для C, не подходит ни для одного из них (или для любого из многих других).
Хороший программист должен уметь мыслить на разных уровнях абстракции и (что более важно) распознавать и применять уровень абстракции, соответствующий поставленной задаче.
Знание уровня абстракции C не повредит. Незнание альтернатив может (и будет).
Знание не вредит. Когда-либо. Те, кто написал плохой код на языке более высокого уровня, это потому, что они плохо овладели языком более высокого уровня, плохие разработчики.
Для плохого разработчика любой тип знаний может быть опасным.
Для хорошего разработчика любой тип знаний является преимуществом.
Использование языков - естественных (разговорных) или искусственных (программирование) - требует, чтобы разум адаптировался определенным образом. У каждого языка есть своя собственная грамматика, свой собственный словарь (API) и т. Д. Если вы в основном программист на Java и переключаетесь на Ruby, вы, по крайней мере, будете следовать шаблонам мышления программиста на Java, если не будете писать то, что в основном является кодом Java в Рубин. Это займет немного усилий и практики, пока вы не почувствуете себя комфортно в новой среде (грамматика Ruby, API Ruby) и не начнете писать код на Ruby.
Таким образом, процесс совершенно нормальный, и любое неблагоприятное воздействие предыдущих моделей очень недолговечно. Что более важно, каждый язык, который вы изучаете, расширяет ваш кругозор и облегчает изучение следующего. Наслаждайся путешествием.:]
Программирование не о языках программирования. Речь идет о решении проблем. Инструменты, используемые для решения проблем, просто языки программирования. Вы не пишете код для написания кода, вы пишете код для его выполнения и решения проблемы.
Чем лучше вы знаете свои инструменты, тем лучше и быстрее вы сможете решить проблемы. Но в то время как у вас будут серьезные проблемы, когда вы будете физически пытаться вбить шуруп в дерево с помощью молотка, у программного обеспечения есть одно приятное свойство: у любой проблемы есть абсурдные разные решения.
Таким образом, вполне возможно написать молоток, который ударяет по винту под таким углом, что винт скажет дереву проделать в себе отверстие, чтобы винт подходил. Затем вы можете спрятать его за кнопку, пользователь не даже не нужно знать, что такое молоток на самом деле.
Хотя это не самое эффективное решение, оно все же является действующим и работающим решением. Когда вы освоитесь с инструментом, который использовали, наконец, вы обнаружите, как можно написать отвертку, если API не предоставляет ее.
Чем больше инструментов вы знаете, и чем больше вы знаете способов решения любой проблемы, тем больше у вас будет выбора и правильных решений о том, какое решение использовать. Выберите правильный инструмент для работы. Но как ты мог, когда ты не знаешь инструментов и возможных решений?
Чтобы расширить комментарии других... Хотя я не уверен, что верю в http://en.wikipedia.org/wiki/Whorfian_hypothesis"> гипотезу Ворфиана, когда речь идет о естественных языках, вполне очевидно, что когда на программирование. Языки, которые вы знаете, влияют на то, как вы решаете проблему. Два примера:
1) От профессора, которого я имел много много лет назад: он пытался выяснить, есть ли какие-нибудь дубликаты в его массиве строк. Это в 70-х годах, поэтому он писал это на Фортране. Его реализация грубой силы n^2 заняла слишком много времени. Так он говорил с другом. Его друг знал PL1 (думаю, возможно, это был APL), у которого есть оператор сортировки. Итак, на этом языке вы учитесь сортировать вещи, и насколько это может быть полезно, потому что это легко. Друг сначала придумал очевидную сортировку, а затем взглянул на алгоритм смежных элементов. Намного быстрее, и это не пришло бы в голову моему профессору, пишущему на Фортране, даже несмотря на то, что это прекрасно реализовывалось в Фортране
2) Когда я учился в аспирантуре, у меня был сосед по физике для соседа по комнате. Он пошел в Массачусетский технологический институт, и только взял один класс программирования, который был, конечно, в Схеме. Однажды я зашел к его офису, и он сказал: "Эй, Брайан, можешь взглянуть на этот код и сказать мне, должен ли он работать?" Это была процедура сортировки. Я взглянул на него и сказал, что это не может сработать, потому что это была явно пузырчатая сортировка, и все же у нее был только один цикл (и нет, это был не тот странный цикл, с которым вы можете написать пузырчатую сортировку, если вы больны и скрученные). Итак, я это сказал. Он ответил: "О, но у него рекурсивный вызов внизу!" Мне никогда бы не пришло в голову написать рекурсивную сортировку пузырей. Но что более важно, HIM никогда бы не подумал написать нерекурсивную функцию!
Дело в том, что языки, которые вы знаете, в значительной степени определяют тип кода, который вы будете писать. Чем больше языков вы знаете, тем больше инструментов у вас есть, и тем больше инструментов никогда не бывает плохо, если вы знаете, когда использовать каждый из них...
Чтобы быть действительно хорошим программистом, вам нужно знать C.
Я согласен с этим.
Но я также согласен с тем, что, чтобы быть действительно хорошим программистом, вы должны действительно знать, как писать код на другом языке (ане как писать код на C на другом языке).
Знание C не повлияет на качество вашего кода, но знание "только C" наверняка
Инженерия программного обеспечения заключается в понимании абстракции и в том, как использовать абстракцию для эффективного решения проблемы (независимо от того, эффективно ли это означает более низкую стоимость, более высокую производительность или кратчайший график предоставления функциональности.) Понимание C - это еще одно понимание уровня абстракции, который мы используем каждый день и умение, необходимое для "увеличения" до этого уровня детализации, является ценным, если вы также развиваете умение "уменьшать масштаб" при необходимости. Этот набор навыков пригодится вам во всех аспектах дисциплины, будь то разработка объектной модели, создание чистых функциональных композиций или даже просто структурирование отдельного метода для ясности и удобства обслуживания.
Знание разных языков является преимуществом. Знание того, как создаются компиляторы и интерпретаторы, также является преимуществом. Наконец, каждый программист должен потратить некоторое время на ассемблер, чтобы оценить языки более высокого уровня.:-)
В моем университете мы взяли курс "Языки программирования", на котором мы изучали LISP, SNOBOL и ADA. Эти языки открывают ваш разум для различного концептуального мышления при решении задач программирования. В итоге нужно было выбрать язык, который лучше всего подходит для данной проблемы.
Знание языка программирования - это только основа. Я был бы не очень далек в своей карьере, если бы не знал других смежных тем: структуры данных, алгоритмы, линейная алгебра, булева алгебра, дизайн микропроцессоров и коммуникации (между людьми). Любой может взять книгу, выучить язык и назвать себя программистом. Это другие умения, которые отличают опытного разработчика от того, который был снят с улицы.
Выучи язык программирования. Изучите это хорошо, чтобы вы могли сосредоточить больше умственных усилий на других задачах под рукой. Вы не должны часто ссылаться на руководство по программированию. Большая часть моей концентрации сосредоточена на требованиях задачи, а также на алгоритмах и структурах данных для ее правильной реализации за минимальное время.
Нет.
Если вы потеряете свое желание знать и улучшать, хотя вы повреждены.
Коротко и сладко:
Чтобы быть хорошим программистом, нужно уметь мыслить организованно. C или LUA или Java, что угодно.
То, что изучение C (или любого другого языка в этом отношении) может причинить вам вред программисту, похоже, зависит от того, что вы не можете научиться чему-либо после изучения C. Урок должен быть не переставать учиться. Кроме того, не думайте, что любой другой язык или технология обязательно работают как C (или ваш любимый компилятор C).
Тем не менее, я думаю, что изучение C может быть хорошим способом узнать, как работает аппаратное обеспечение и что на самом деле происходит в машине. Я не понимаю, как знание этого может повредить вам в любом случае. Я не думаю, что невежество имеет какие-либо преимущества (если они не случайны). Я признаю, что изучение C - не единственный способ узнать о машине, но это всего лишь один из способов сделать это.
Настоящая проблема здесь - предположение. Эти другие разработчики предполагают, что знают, как это работает. Предположения - это дьявол, будь то опытный разработчик, который думает, что он все понял, или новичок, который думает, что он все понял.
По крайней мере, это то, что я предполагаю здесь
Будет больно, только если вы примените эти знания к языкам более высокого уровня, когда это действительно не требуется. Конечно, имея некоторый опыт написания собственных классов C на низком уровне, я мог бы сделать это, скажем, на Java. Но будет ли это лучшей альтернативой существующей библиотеке коллекций (как Java API, так и дополнения Commons Collections)? Может быть.
На практике вам придется рассчитывать, стоит ли потраченное время.
По правде говоря, вы должны просто провести исследование, прежде чем взломать свой код. Посмотрите, можно ли сделать то, что вы пытаетесь сделать, используя встроенные или сторонние инструменты. Если вы можете, то посмотрите, работают ли встроенные или сторонние инструменты так, как вы хотите, и работают ли они хорошо. Если нет, выясните, почему нет. Если они / действительно / нет, перепишите.
Как утверждают другие, все знания стоят того. И под этим я подразумеваю /all/ - как низкоуровневый оптимизированный код C, так и высокоуровневые вызовы хорошо развитых библиотек. Если вы знаете оба, вы будете знать, какой использовать, когда и почему.
Изучение С это хорошая вещь. Пытаться писать C-код на языке более высокого уровня - это плохо.
Нет, знание нескольких реализаций языка программирования может помочь вам лучше понять эти абстракции.
Проблема в том, что вы принимаете одну за лучшую абстракцию, которая заставит вас не преуспеть в использовании других, которые вы считаете менее значительными.
Каждая абстракция разработана с определенной конкретной целью, выберите ту, которая лучше всего подходит для ваших нужд. Знание Linux затрудняет знание Windows или Mac OS? Это признание того, что они разные.
Например, знание C, а затем работа на моем любимом языке очень высокого уровня (Python) - это пример того, почему мне полезно знать C.
Знание C, когда я использую Python, полезно в нескольких отношениях:
(а) Я благодарен за списки, словари и встроенные типы Python, потому что это позволяет легко делать что-то, повторяющееся, в одной строке кода, что потребовало бы от меня выбора некоторой библиотеки кода, изучения ее и ссылки на нее (хеш-таблицы, структуры данных и т. д.) и избегайте попадания в него ногой.
(б) Python написан на C. Быть программистом на C также означает, что если Python поможет мне на 99% пути, но некоторая дополнительная абстракция может быть полезна в Python, я могу написать эту абстракцию на Python. Я могу заглянуть в исходный код интерпретатора CPython и понять, что происходит внутри. По сути, я, как программист на Python, все еще использую нечто, построенное на языке Си. Таким образом, знание этого языка все еще ценно.
Все, что я сказал выше, верно и для людей, использующих Perl, Ruby и PHP.
Понимание нескольких языков / структур и парадигм программирования никогда не должно повредить - это должно быть полезно.
Важным моментом является понимание языка / структуры / среды, в которой вы в настоящее время работаете, в той степени, в которой вы знаете последствия выбора вариантов реализации. Здесь знания, полученные при работе с другими языками, могут открыть вам глаза на более широкий диапазон возможностей, но вы должны оценить эти возможности с точки зрения вашей текущей среды.
Люди, которые попадают в настоящие проблемы, - это те, кто выучил какой-то язык, например, С, а затем выучил другой язык в терминах С, а не изучал его по своим достоинствам, сильным и слабым сторонам (вроде как мастер с молотком как его единственный инструмент - все проблемы для него выглядят как гвозди).