Python против C: сравнение строк кода с временем разработки

Question

Привет! В настоящее время я изучаю Python, поскольку синтаксис кажется таким лаконичным, и идиомы хорошо сочетаются с моей ментальной моделью.

Однако я также заинтересован в изучении внутренних компонентов ОС и программного обеспечения для реинжиниринга, что в конечном итоге означает знание C в довольно тщательной форме.

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

1) Для среднестатистического программиста на Си это 100-200 строк кода на Python идиома где-то почти точные?

Поскольку C не поставляется с Python-подобными конструкциями, такими как словари / списки (со всеми их хорошими методами и т. Д.):

2) Имеют ли программисты на С возможность создавать эти конструкции с нуля, а затем повторно использовать их между проектами, чтобы значительно сократить фактическое количество ручного кодирования для своих проектов?

Я предполагаю, что повторное использование библиотек, таких как boost :: stuff, также снова, сокращает также часть ручного кодирования ...

3) Но использует ли популярные библиотеки и повторно использует общий код, написанный ранее на C для базовых конструкций / etc, сколько это пересматривает строк кода, написанных на C, по сравнению с кодом на Python для энтузиастов кодовая база?

Я знаю, что конкретные числа невозможны, но возможно ли с библиотеками, повторным использованием кода и т. Д. Иметь время разработки в C, близкое к Python, не будучи машиной кодирования в стиле Линуса Торвальдса?

Спасибо!

Answer 1

но возможно ли с библиотеками, повторным использованием кода и т. Д. Иметь время разработки в C, близкое к Pythonсамый важный момент.

Интерактивный Python.Это не edit-compile-link-execute-break-debug.Это редактирование-отладка.

Answer 2

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

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

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

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

Answer 3

Я думаю, что Python более продуктивен для небольших проектов (до нескольких тысяч строк кода).

С другой стороны, C лучше подходит для больших проектов (даже несмотря на то, что ИМХО для этого есть языки лучше, например Ada): статическая проверка типов во время компиляции позволяет находить много ошибок, которые гораздо сложнее обнаружить во время выполнения, особенно в большой программе.

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

Answer 4

Это зависит.

Попробуйте написать обработчик прерываний на python.Кто-то может заставить это работать, но это будет танцующий медведь, танцы не очень хороши, но удивительно, что медведь может это сделать.Хотите написать OS или заняться встроенным программированием , вы не сможете использовать Python.Это говорит о том, что основная реализация Python написана на C.

При этом я поражен некоторыми низкоуровневыми вещами , которые вы можете делать с python.Материал высокого уровня почти дан, если вы измеряете строки кода.Python - это просто язык более высокого уровня.

Они оба очень полезные инструменты, только для разных типов проектов.Знание обоих было бы очень полезно, особенно когда вам нужно взаимодействовать с некоторыми новыми функциями в Python, которые еще не имеют привязки к Python.

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

Answer 5

1. Поскольку я занимался серьезным программированием на c, я прочитал книгу, в которой утверждалось, что библиотеки заслуживают того, чтобы их написать. (Особенно в C, который считается языком низкого уровня)

2. Библиотеки построены для повторного использования.

3. Если вы используете библиотеки, вы пишете одну строку, например detectFace( faceDesriptor ) или renderPDF( document), не имеет значения, является ли идиома на другом языке более краткой или нет. Строки кода не являются правильной метрикой, если речь идет о том, что будет более эффективным.

Answer 6

сильно зависит от задачи и размера проекта.Для многих небольших интересных задач я не удивлюсь меньшему коду Python на 100: 1 просто потому, что стандартные библиотеки очень хороши.Если вы найдете, купите или создадите библиотеки C / C ++, которые будут делать то, что вы хотите, я думаю, что соотношение будет больше, чем 3: 1 в больших проектах.

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