После чтения дискуссии на Hacker News, я снова серьезно задумался о языках программирования. Имеет ли какое-то значение, знаешь ты только один или несколько? Могу ли я знать 5 языков одинаково хорошо? Или хотя бы настолько хорошо, чтобы утверждать, что я их «знаю».
Если говорить об объектно-ориентированных языках со статической типизацией, на самом деле разница небольшая. Единственное, о чем действительно стоит помнить, так это управление памятью. Если есть сборщик мусора, то особенно заботиться об указателях и удалении объектов не нужно. Вы жертвуете частью производительности и памяти (на самом деле, не всегда, так как сборщик мусора помогает избежать фрагментации и сегментации памяти, и у вас всегда есть занятая часть памяти, а также память для дальнейшего распределения, разделенные между собой указателем на следующую свободную область памяти). Тем не менее, лучшее понимание стека и кучи, значений, указателей, месседжинга между объектами, приходит из языков, где сборщика мусора по умолчанию нет. Вообще-то, вы можете использовать сборщик мусора (как пример — Boehm GC), но существуют паттерны, такие как, скажем, умные указатели и пулы, которые помогают управлять памятью, и быть уверенным, что объекты освобождаются. То есть, есть вещи, которым можно научиться из обоих «миров»: научиться тому, как управлять памятью, а также тому, как делегировать управление памяти, и понять, по каким принципам осуществляется сбор мусора. Мне это представляется достаточно полезным.
Если говорить о динамических языках, когда вы не можете быть уверены в существовании метода либо поля до вызова программы, это может быть не так просто, если вы привыкли к компиляции и выявлению несоответствий до запуска. Динамические языки позволяют нам расширять объекты, делая систему более гибкой, использовать примеси и добавлять функциональность к стандартным классам. Ruby дает возможность реализации примесей через модули, объявление дополнительных методов для класса. Все эти вещи используются достаточно широко в Rails. В Active Record широко используется method_missing, что само по себе является отличной идеей. Kernel.autoload также удобное решение. Объекты, которые сами по себе являются фабриками в Ruby (метод new/initialize, по сути возвращающий экземпляр объекта) — также несет определенную смысловую нагрузку. Мне кажется, что все эти вещи являются своего рода паттернами, а не просто методами и особенностями языка, то есть эти вещи можно применять также в других областях. То же самое относится с Трейтам (Traits) в Scala. Ruby Gems и Packages в Python — также решения определенного спектра проблем (тут можно также упомянуть Aptitude, RPM, BSD Ports, с возможностью загрузки исходников и хедеров для линкования). S-expressions из Lisp были также успешно применены в C#, и это изменило достаточно много всего, особенно после появления LINQ.
Чтение кода является одним из основополагающих умений для разработчиков. Я знаю несколько человек, которые чувствуют себя достаточно комфортно используя «свой» язык программирования, и не хотят даже пытаться посмотреть на возможности остальных. Но это ведь не так плохо, правда? Не совсем так. При изучении нового языка, люди часто начинают изучать набор библиотек, либо фреймворк, вместо изучения самого языка. Дело в том, что если есть фрейморк, качественно написанный, и отлично функционирующий, с открытым исходным кодом, то можно открыть код и посмотреть на его реализацию, и понять принципы и практики, примененные там, вместо непосредственно изучения верхушки айсберга — его API и функциональности, описанной в туториалах.
Думаю, что все слышали об истории с alias_method_chain в Rails/Ruby. По всей видимости, то же самое произошло и с .NET и моделью ViewState / Postback, и сохранением состояния страницы между загрузками, когда люди перестали думать о том, как это лучше, проще и быстрее реализовать в мире Web разработок. То же самое можно сказать и о моделях и вью в Django (Python): когда по умолчанию модели и вью хранятся, фактически, в двух файлах: models.py и views.py, а многие разработчики не знают, или даже не могут их разделить. И великолепные Expressions Trees в C#, которые (такое впечатление что) использовались только командой LINQ / Enterprise Libraries.
В следующий раз, когда вы смотрите на новый фреймворк, вне зависимости от того, над чем вы работаете, спросите себя, можете ли вы _сами_ реализовать подобную функциональность. Если нет, посмотрите на код, реализацию, постарайтесь понять, по каким причинам все сделано именно так, каким образом можно сделать лучше и удобнее. Я понимаю, что это не всегда возможно, но Open Source разработки с каждым днем становятся все более популярными, и покрывают больше и больше решаемых задач. Не пытайтесь выучить фреймворк. Учите язык. API будут меняться, и со временем, возможно, вам придется изменять код используемого фреймворка для решения собственных задач. Как пример, какая первая мысль приходит вам в голову, когда ваш JS селектор не работает? Если вы гуглите решение проблемы, то решается только половина задачи. Вторая остается на месте: возможность читать, понимать, отлаживать код, добираться до корня проблемы, и реализовывать решение своими руками.
Новые языки — это клево и весело. Вы снова задумываетесь о синтаксисе, и меняете свое восприятие. Задумываясь о том, каким образом подобную проблему можно решить на другом языке, вы смотрите на свой код с другой точки зрения. Мне все же кажется, что изучения любого языка может помочь понять глубже тот набор инструментов, что вы используете сейчас, и найти более элегантные решения. Изучения API, тем не менее, позволят вам чувствовать себя комфортно достаточно длительное время, но существенной пользы не принесут, так как запомнить всего невозможно. Главное — понимать, как устроены библиотеки, и какие основные принципы применяются в их разработке.
UPD: sylvio сказал толковую вещь. Можно многому поучиться:
Не много толку учить еще один фреймоврк и еще один метод решения чего-то, нужно учить более общие тероии, позволяющие выводить эти методы самому, теорию типов, категорий, множеств и тп.
Тем не менее, для решения прикладных задач теории не всегда достаточно. Требуется также знать существующие решения, от которых можно оттолкнуться, взять за основу. Прикладные задачи также требуют хорошей теоретической базы, но она должна быть подтверждена и опытом применения.
В чем вообще разница?
Если говорить об объектно-ориентированных языках со статической типизацией, на самом деле разница небольшая. Единственное, о чем действительно стоит помнить, так это управление памятью. Если есть сборщик мусора, то особенно заботиться об указателях и удалении объектов не нужно. Вы жертвуете частью производительности и памяти (на самом деле, не всегда, так как сборщик мусора помогает избежать фрагментации и сегментации памяти, и у вас всегда есть занятая часть памяти, а также память для дальнейшего распределения, разделенные между собой указателем на следующую свободную область памяти). Тем не менее, лучшее понимание стека и кучи, значений, указателей, месседжинга между объектами, приходит из языков, где сборщика мусора по умолчанию нет. Вообще-то, вы можете использовать сборщик мусора (как пример — Boehm GC), но существуют паттерны, такие как, скажем, умные указатели и пулы, которые помогают управлять памятью, и быть уверенным, что объекты освобождаются. То есть, есть вещи, которым можно научиться из обоих «миров»: научиться тому, как управлять памятью, а также тому, как делегировать управление памяти, и понять, по каким принципам осуществляется сбор мусора. Мне это представляется достаточно полезным.
Если говорить о динамических языках, когда вы не можете быть уверены в существовании метода либо поля до вызова программы, это может быть не так просто, если вы привыкли к компиляции и выявлению несоответствий до запуска. Динамические языки позволяют нам расширять объекты, делая систему более гибкой, использовать примеси и добавлять функциональность к стандартным классам. Ruby дает возможность реализации примесей через модули, объявление дополнительных методов для класса. Все эти вещи используются достаточно широко в Rails. В Active Record широко используется method_missing, что само по себе является отличной идеей. Kernel.autoload также удобное решение. Объекты, которые сами по себе являются фабриками в Ruby (метод new/initialize, по сути возвращающий экземпляр объекта) — также несет определенную смысловую нагрузку. Мне кажется, что все эти вещи являются своего рода паттернами, а не просто методами и особенностями языка, то есть эти вещи можно применять также в других областях. То же самое относится с Трейтам (Traits) в Scala. Ruby Gems и Packages в Python — также решения определенного спектра проблем (тут можно также упомянуть Aptitude, RPM, BSD Ports, с возможностью загрузки исходников и хедеров для линкования). S-expressions из Lisp были также успешно применены в C#, и это изменило достаточно много всего, особенно после появления LINQ.
Чтение кода и применение практик
Чтение кода является одним из основополагающих умений для разработчиков. Я знаю несколько человек, которые чувствуют себя достаточно комфортно используя «свой» язык программирования, и не хотят даже пытаться посмотреть на возможности остальных. Но это ведь не так плохо, правда? Не совсем так. При изучении нового языка, люди часто начинают изучать набор библиотек, либо фреймворк, вместо изучения самого языка. Дело в том, что если есть фрейморк, качественно написанный, и отлично функционирующий, с открытым исходным кодом, то можно открыть код и посмотреть на его реализацию, и понять принципы и практики, примененные там, вместо непосредственно изучения верхушки айсберга — его API и функциональности, описанной в туториалах.
Думаю, что все слышали об истории с alias_method_chain в Rails/Ruby. По всей видимости, то же самое произошло и с .NET и моделью ViewState / Postback, и сохранением состояния страницы между загрузками, когда люди перестали думать о том, как это лучше, проще и быстрее реализовать в мире Web разработок. То же самое можно сказать и о моделях и вью в Django (Python): когда по умолчанию модели и вью хранятся, фактически, в двух файлах: models.py и views.py, а многие разработчики не знают, или даже не могут их разделить. И великолепные Expressions Trees в C#, которые (такое впечатление что) использовались только командой LINQ / Enterprise Libraries.
В следующий раз, когда вы смотрите на новый фреймворк, вне зависимости от того, над чем вы работаете, спросите себя, можете ли вы _сами_ реализовать подобную функциональность. Если нет, посмотрите на код, реализацию, постарайтесь понять, по каким причинам все сделано именно так, каким образом можно сделать лучше и удобнее. Я понимаю, что это не всегда возможно, но Open Source разработки с каждым днем становятся все более популярными, и покрывают больше и больше решаемых задач. Не пытайтесь выучить фреймворк. Учите язык. API будут меняться, и со временем, возможно, вам придется изменять код используемого фреймворка для решения собственных задач. Как пример, какая первая мысль приходит вам в голову, когда ваш JS селектор не работает? Если вы гуглите решение проблемы, то решается только половина задачи. Вторая остается на месте: возможность читать, понимать, отлаживать код, добираться до корня проблемы, и реализовывать решение своими руками.
Выводы?
Новые языки — это клево и весело. Вы снова задумываетесь о синтаксисе, и меняете свое восприятие. Задумываясь о том, каким образом подобную проблему можно решить на другом языке, вы смотрите на свой код с другой точки зрения. Мне все же кажется, что изучения любого языка может помочь понять глубже тот набор инструментов, что вы используете сейчас, и найти более элегантные решения. Изучения API, тем не менее, позволят вам чувствовать себя комфортно достаточно длительное время, но существенной пользы не принесут, так как запомнить всего невозможно. Главное — понимать, как устроены библиотеки, и какие основные принципы применяются в их разработке.
UPD: sylvio сказал толковую вещь. Можно многому поучиться:
Не много толку учить еще один фреймоврк и еще один метод решения чего-то, нужно учить более общие тероии, позволяющие выводить эти методы самому, теорию типов, категорий, множеств и тп.
Тем не менее, для решения прикладных задач теории не всегда достаточно. Требуется также знать существующие решения, от которых можно оттолкнуться, взять за основу. Прикладные задачи также требуют хорошей теоретической базы, но она должна быть подтверждена и опытом применения.
