После прочтения обсуждения на Hacker News , я снова начал серьёзно задумываться о языках программирования.
Имеет ли значение, знаете ли вы только одного или нескольких? Могу ли я знать 5 языков одинаково хорошо? Или, по крайней мере, достаточно хорошо, чтобы утверждать, что я их «знаю».
Какая вообще разница?
Если мы говорим о объектно-ориентированный языки из статическая типизация , на самом деле разница невелика.Единственное, что действительно стоит запомнить, это управление памятью .
Если здесь уборщик мусора , то вам не придется слишком беспокоиться об указателях и удалении объектов.
Вы жертвуете некоторой производительностью и памятью (на самом деле не всегда, поскольку сборщик мусора помогает избежать фрагментации и сегментации памяти, и у вас всегда есть занятая часть памяти, а также память для дальнейшего выделения, разделенная указателем на следующую свободную память.
область ).
Однако лучшее понимание стека и кучи, значений, указателей и обмена сообщениями между объектами достигается в языках, в которых нет сборщика мусора по умолчанию.
Собственно, можно использовать сборщик мусора (как пример — Бём Г.
К.
), но существуют такие закономерности, как, скажем, умные указатели и пулы, которые помогают управлять памятью и обеспечивать освобождение объектов.
То есть есть вещи, которым можно научиться из обоих «миров»: научиться управлять памятью, а также делегировать управление памятью и понять принципы сборки мусора.
Я считаю это весьма полезным.
Если говорить о динамические языки когда вы не можете быть уверены в существовании метода или поля перед вызовом программы, это может быть не так просто, если вы привыкли компилировать и выявлять несоответствия перед запуском.
Динамические языки позволяют расширять объекты, делая систему более гибкой, используя примеси и добавить функциональность в стандартные классы.
Ruby позволяет реализовывать примеси через модули, объявляя дополнительные методы для класса.
Все эти вещи довольно широко используются в Rails. В Активная запись широко используемый метод_отсутствует , что само по себе является отличной идеей.
autoload тоже удобное решение.
Объекты, которые сами по себе являются фабриками в Ruby (метод new/initialize, по сути возвращающий экземпляр объекта), также несут определенную семантическую нагрузку.
Мне кажется, что все эти вещи — это какие-то закономерности, а не просто методы и особенности языка, то есть эти вещи можно применять и в других областях.
То же самое относится и к Трейтэму ( Черты ) В Скала .
Рубиновые драгоценные камни И Пакеты в Python — тоже решения определенного круга задач (тут еще можно упомянуть Способности , об/мин , BSD-порты , с возможностью скачивания исходников и шапок для ссылки).
S-выражения от Лисп также успешно применялись в C#, и это многое изменило, особенно после введения ЛИНК .
Чтение кода и применение практик
Чтение кода — один из фундаментальных навыков для разработчиков.Я знаю несколько человек, которые вполне комфортно чувствуют себя, используя «свой» язык программирования, и даже не хотят пытаться посмотреть на возможности других.
Но это не так уж и плохо, правда? Не совсем так.
Изучая новый язык, люди часто начинают изучать набор библиотек или фреймворк вместо того, чтобы изучать сам язык.
Дело в том, что если есть фреймворк, который хорошо написан, хорошо работает и имеет открытый исходный код, то вы можете открыть код и посмотреть его реализацию, и понять применяемые там принципы и практики, вместо того, чтобы непосредственно изучать подсказку.
айсберга — его API и функционал, описанные в туториалах.
Я думаю, все слышали об истории с alias_method_chain в Rails/Ruby. Судя по всему, то же самое произошло с .
NET, моделью ViewState/Postback и сохранением состояния страницы между загрузками, когда люди перестали думать о том, как это лучше, проще и быстрее реализовать в мире веб-разработки.
То же самое можно сказать и о модели и представления в Django (Python): когда по умолчанию модели и представления хранятся, по сути, в двух файлах: models.py иviews.py, и многие разработчики не знают или даже не могут их разделить.
И великолепные деревья выражений на C#, которые (похоже) использовались только командой LINQ/Enterprise Libraries. В следующий раз, когда вы посмотрите на новую платформу, независимо от того, над чем вы работаете, спросите себя, можете ли вы реализовать аналогичную функциональность _самостоятельно_. Если нет, посмотрите код, реализацию, попытайтесь понять, почему все сделано именно так, как можно сделать лучше и удобнее.
Я понимаю, что это не всегда возможно, но разработка с открытым исходным кодом становится с каждым днем все популярнее и охватывает все больше задач, требующих решения.
Не пытайтесь изучить структуру.
Выучить язык.
API будут меняться, и со временем вам, возможно, придется изменить код платформы, которую вы используете для решения собственных проблем.
Например, какая первая мысль приходит вам в голову, когда ваш селектор JS не работает? Если вы загуглите решение проблемы, то будет решена только половина проблемы.
Второе остаётся на месте: умение читать, понимать, отлаживать код, добираться до корня проблемы и самостоятельно реализовывать решение.
Выводы?
Новые языки — это круто и весело.Вы снова думаете о синтаксисе и меняете свое восприятие.
Размышляя о том, как аналогичную проблему можно решить на другом языке, вы смотрите на свой код с другой точки зрения.
Я по-прежнему считаю, что изучение любого языка может помочь вам глубже понять набор инструментов, которыми вы сейчас пользуетесь, и найти более элегантные решения.
Изучение API, правда, позволит вам чувствовать себя комфортно довольно долгое время, но существенной пользы не принесет, так как все запомнить невозможно.
Главное — понять, как устроены библиотеки и какие основные принципы используются при их разработке.
УПД: Сильвио сказал разумную вещь.
Есть чему поучиться: Нет смысла изучать другой фреймворк и другой метод решения чего-либо; вам необходимо изучить более общие теории, позволяющие самостоятельно вывести эти методы, теория типов, категории , наборы и так далее.
Однако теории не всегда достаточно для решения прикладных задач.
Также необходимо знать существующие решения, которые можно взять за основу.
Прикладные задачи также требуют хорошей теоретической базы, но она также должна быть подтверждена опытом применения.
Теги: #разработка #программирование #полиглоты #разработка сайтов
-
Прямая Линия С Тм. V3.0
19 Oct, 24 -
Выпущен Debian Gnu/Linux 6.0.1
19 Oct, 24 -
Devconf 2012 Ищет Спикеров
19 Oct, 24 -
Докажи, Что Ты Умный
19 Oct, 24
