Изучите все языки программирования

Original author: Ozan Onay
  • Translation
Когда я был ещё первокурсником, то познакомился с другим студентом, который утверждал, что может писать код на любом языке программирования, который я смогу назвать. Я был несколько шокирован и ответил подначкой:

— Что, даже на том нечитаемом эзотерическом языке, где есть всего пара команд, которые едва-едва симулируют машину Тьюринга?
— Да, этот язык называется brainfuck. Я знаю brainfuck.

И это был не трюк — мы проверили. Я называл известный мне язык программирования, он тратил пару минут в Интернете на то, чтобы освежить свои знания по нему — и был способен писать на этом языке работающие алгоритмы. Я никак не мог понять этого. Ему, как и мне, было тогда около 18 лет — как он мог в этом возрасте знать все эти языки?

image
Интерпретатор brainfuck, написанный на brainfuck

Сегодня у меня всё ещё вызывает уважение та демонстрация умений моего однокурсника, но я уже не шокирован ею. После того, как я сам выучил уже не один язык программирования, мне стало понятно, что отличаются друг от друга они значительно меньше, чем того можно было бы ожидать. На каком-то этапе обучения я уже обращал внимание не столько на синтаксис языка программирования, сколько на лежащие в его основе идеи, модель памяти, принципы выполнения инструкций. Всё это можно назвать теорией языков программирования, с точки зрения которой разные языки просто реализуют несколько различные версии одних и тех же базовых идей.

Сегодня я советую своим студентам «постараться изучить все языки программирования». Подумайте сами — ведь эта идея лучше, чем все вот эти «В этом году я выучу Go! Ой, нет, теперь говорят что в моде Rust — выучу лучше Rust! Или Swift ...». Просто выучите все — не ошибётесь. А эта статья, возможно, вам в этом немного поможет.

И сразу — отказ от ответственности :)


  • Я ни разу не говорю о том, что нужно действительно изучить 500+ (или сколько там сейчас актуальных?) языков программирования. Я говорю о том, что нужно понимать основные парадигмы и реализации паттернов, что даст вам возможность понимать почти любые конструкции в почти любом языке. А забывшееся ключевое слово или функцию из стандартной библиотеки всегда можно подсмотреть в документации
  • Это не пятиминутное дело. Возможно, вы далеко продвинетесь на этом пути за какой-то год. Но, знаете, вполне может уйти и десятилетие
  • Придётся изучить некоторые уже устаревшие или ещё не вошедшие в моду концепции
  • В зависимости от вашей основной работы (или жизненных целей) всё это может вам совершенно никогда не пригодиться

Тогда зачем этим заниматься?


Если вы видите какую-то значительную часть своей карьеры связанной с написанием программного обеспечения, то вам неплохо бы быть знакомым с языками программирования:

  • Даже не выбирая каких-то определённых языков программирования (или выбрав всего один) через пару лет работы программистом вы обнаружите, что уже писали (или читали) код на нескольких языках. Так почему-то случается всегда
  • Вы обнаружите, что имея знания о нескольких языках программирования, вам захочется каждый раз иметь возможность выбирать один из них для решения тех или иных задач
  • Языки программирования расцветают и устаревают. Знания нескольких из них дают вам возможность оставаться на острие прогресса, иметь доступ к более интересным проектам или хорошим компаниям
  • Многие важные проекты требуют фундаментального понимания работы компиляторов и знания нескольких языков программирования. Это реализации средств разработки, стандартных библиотек, предметно-ориентированные языки, IDE, браузеры, базы данных, средства статического анализа, и т.д.

Лично мне очень важным кажется именно последний пункт. Ras Bodik хорошо подчеркнул этот момент в своей лекции студентам Беркли, когда объяснял важность изучения курса разработки компиляторов:

Не будьте разработчиками шаблонного ширпотребного софта. Вместо этого, постарайтесь разрабатывать новые инструменты для пользователей и других программистов. Если провести историческую аналогию, то кем бы вам больше хотелось быть: работником за ткацким станком, ежедневно выполняющим рутинные операции или разработчиком новых моделей таких станков?

Шаг номер 0: перестаньте называться себя «программист на Rails (подставьте свой язык\платформу)»


Это простой, но важный шаг. Да, у вас наверняка уже есть какая-то специализация и вы, возможно, гордитесь ею и продолжаете её совершенствовать — это хорошо. Но в то же время такая самоидентификация создаёт ментальный барьер в вашей голове. Каждая новая технология, каждый новый язык воспринимается с оттенком скепсиса или критики, а возможно и пренебрежения — и это уже плохо. Начните называть себя просто «инженер по разработке программного обеспечения» или «программист».

Примером может быть Alex Gaynor — большой специалист по Python, один из Core Developers таких вещей как Django и PyPy, член совета директоров Python Software Foundation. Но однажды его попросил о помощи United States Digital Service — и Алекс провёл несколько лет в проектах на ASP (даже не на ASP.NET, а на том, старом ASP). А знаете, почему? Потому, что он — «инженер по разработке программного обеспечения», а не «Python-разработчик».

Шаг номер 1: перейдите на мета-уровень


Есть такой старый анекдот о том, как прикладной физик случайно попал на конференцию теоретических физиков. Он обратился к одному из докладчиков и спросил, как ему вообще удаётся думать о всех этих вещах, происходящих в 11 измерениях? Теоретический физик ответил: «О, это просто. Просто представь N измерений, а потом зафиксируй N равным 11».

Хороший программист может использовать тот же трюк. Вы можете слушать все эти россказни маркетологов о том, что «Go — это новый и амбициозный язык программирования», а можете просто определить его для себя, как компилируемый статически типизируемый язык со сборщиком мусора и CSP-стилем конкурентности. Swift может быть «новым и тщательно спроектированным» ну или просто компилируемым мультипарадигменным языком общего назначения реализованным на базе LLVM.

Для тех, кто никогда не имел возможности пройти курс изучения компиляторов, я могу посоветовать несколько отличных книг и онлайн-материалов. Во-первых, это курс от Alex Aiken, который когда-то был доступен на Coursera, а теперь — на собственной платформе Стенфорда (Lagunita). Неплох и курс от Беркли — CS164. Правда, они перестали публиковать в открытом доступе его обновления, но материалы 2012 вроде бы ещё доступны.

Каноническая настольная книга о компиляторах: «Compilers: Principles, Techniques & Tools». Она же — Книга Дракона. Как и все книги такого уровня, она имеет как неистовых фанов, так и непримиримых критиков. Лично я считаю её отличным материалом, но будьте готовым к тому, что некоторые её части придётся перечитывать не один раз до полного понимания. Есть более простая и направленная на практиков книга — это Language Implementation Patterns. Если ваш интерес ограничен какой-то конкретной практической задачей небольшого масштаба (вроде написания предметно-ориентированного языка), то эта книга подойдёт лучше, чем классическая Книга Дракона.

image
Книга Дракона

Шаг номер 2: начните с первоисточников


С хорошим теоретическим базисом будет проще изучать новые языки, но всё же не так легко взять и выучить все 500+ более-менее актуальных сегодня языков программирования. Поэтому начать можно с определения языков, в которых впервые были исследованы и реализованы некоторые принципиально новые идеи. На их основе изучение аналогичных инструментов в более новых языках будет уже тривиальной задачей.

Peter Norvig даёт несколько советов о том, какие парадигмы действительно важны, а также в каких языках они были впервые реализованы:

Выучите хотя бы 5 языков программирования. В ваш багаж знаний должен входить хотя бы один язык с классической абстракцией «классов» (это может быть Java или С++), один функциональный язык (вроде Lisp, ML или Haskell), один язык с поддержкой синтаксической абстракции (вроде Lisp), один декларативный язык (Prolog или шаблоны С++), один язык с продвинутой поддержкой параллелизма (Clojure или Go).

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

Я также рекомендую изучить какой-нибудь ассемблер. Это может быть MIPS (если вы хотите потратить меньше времени на обучение) или x86 (если хотите иметь практическую пользу). Это даст вам больше знаний о компьютерной архитектуре и устройстве процессора, чем о языках программирования, но, если в будущем вы захотите написать компилятор, то именно эти знания вам и понадобятся. Возможно, когда-нибудь вместо ассемблера можно будет порекомендовать изучение формата промежуточного кода LLVM.

Peter Norvig рекомендует изучение декларативных языков, но я был бы здесь более конкретным и посоветовал бы изучить язык логического программирования. Это может быть как классический Prolog, так и miniKanren.

В разделе «языков с поддержкой параллелизма» к упомянутым вариантам я бы добавил ещё и CUDA. Это качественно другой масштаб параллелизма, ведь сотни ядер GPU не сравнятся с какими-то 4 ядрами обычных процессоров. Вы не только поймёте лучше устройство GPU, но и заложите для себя хороший фундамент для дальнейшего изучения машинного обучения (там параллелизм и вычисления на GPU очень пригодятся). Но важно понимать, что вам нужны как знания CUDA, так и один из упомянутых языков с параллелизмом для CPU (вроде Go, Clojure или Erlang).

Векторное программирование является ещё одной мощной парадигмой. Norvig зря пропустил языки с его поддержкой, ведь они имеют достаточно конкретное прикладное применение. Классическими примерами могут быть APL/J/K/Q, а также Matlab.

Также есть такая вещь, как узкоспециализированные языки. Иногда создание своего узкоспециализированного языка для каких-то конкретных задач может быть верным решением. Но для того, чтобы решиться на это, нужно изучить конкретные примеры того, когда такой подход оказался успешным. Я советую для этого посмотреть на вещи типа Frink.

Возможно, меня уже несколько понесло, но так трудно остановиться, когда вокруг столько всего вкусного! Кто-то скажет, что нельзя пропустить изучение Forth, чтобы понять стековые языки (хотя мне кажется работу стеков можно понять и в других языках). Кто-то скажет, что я упустил очень важный язык Х или целую категорию языков Y — и это будет правдой, ведь их немало.

Шаг номер 3: практикуйтесь


Достаточно просто составить список языков, которые вы планируете изучить. Но вот действительно взять и изучить — займёт какое-то время. Если вам повезёт, то какие-то из них вы сможете применить в своей основной работе. Но даже если этого не произойдёт, вы должны стараться сами найти способ изучить новый язык не только с теоретической, но и с практической точки зрения. Без теории прогресс будет медленным, но без практики вы вообще застрянете.

Хорошим способом начать изучение нового языка будет прочесть короткую выжимку на Hyperpolyglot или Learn X in Y Minutes. Это даст приблизительное понимание ключевых идей языка и уберёт страх перед незнакомым синтаксисом. Если вы уже знакомы с каким-то похожим языком, то Hyperpolyglot имеет очень удобную функцию сравнения языков — это может на удивление быстро продвинуть вас в изучении нового языка.

Другим полезным упражнением будет изучение даже не синтаксиса языка, а документа, в котором описывается мотивация его создателей. Это даст вам понимание того, почему люди вообще тратили своё время и силы на создание этой вещи, какова была их мотивация и может ли она сейчас или в будущем совпасть с вашей. Например, если вы побаиваетесь глубоко изучать С++ или скептически относитесь к некоторым решениям Страуструпа, вам определённо стоит прочесть книгу The Design and Evolution of C++. Большинство других языков программирования тоже имеют в некоторой мере аналогичные публикации.

image

После этого можно уже почитать книгу по языку или сразу перейти к попыткам написать на нём что-нибудь не очень сложное. Что касается книг, то трудно давать какие-то общие рекомендации, но я бы всё-таки советовал выбирать наиболее устоявшиеся, проверенные годами вещи, написанные для опытных программистов, изучающих новый язык. Такие книги часто написаны самими авторами языка и подчёркивают их основные идеи, в то время как более современные публикации направлены скорее на практическое применение языков в тех или иных сферах.

Наиболее быстрый путь приобщиться к новому языку, по моему мнению, это найти набор небольших задач и постепенно их решать. Хорошим источником может быть Exercism.io. Кроме задач там даже есть тесты, дающие возможность быстро оценить качество вашей реализации. Решение маленьких задач хорошо согласуется с изучением теории и с основной работе над другими проектами.

Как только вы освоитесь с синтаксисом и небольшие задачи уже не будут вызывать у вас проблем, я советую найти большой проект на этом языке. И это должен быть проект именно в той сфере, для которой был создан этот язык. Например, если вы изучаете C или Go — пишите утилиту командной строки с большим количеством системных вызовов. Если изучаете Python или Ruby — попробуйте написать что-то алгоритмическое и не очень требовательное к производительности (ИИ для крестиков ноликов :) ) ну и т.д.

Продолжайте копать


Учитывая количество языков программирования в мире и тот факт, что мы действительно используем даже очень старые языки вроде С, легко сделать вывод, что человечество уже изобрело все необходимые ему языки программирования. Но это очень спорное предположение. Есть очень существенный пробел между тем, что считается возможным запрограммировать и тем, что мы на сегодняшний день уже научились программировать. И проблема не в вычислительных ресурсах — со всеми существующими сегодня аппаратными платформами и облаками у нас есть где погонять код. Проблема именно в наших способах общения с компьютером, с тем, что мы не всегда можем удобно выразить, что же мы хотим получить на выходе программы и как это должно быть рассчитано.

Gerald Jay Sussman обратил внимание на это в его потрясающем докладе We Really Don’t Know How To Compute. Он использует несколько устаревший инструментарий, но и существующие сегодня инструменты не дают нам каких-то качественно иных подходов к решению освещённых им проблем.

image
Треугольник иллюзий. Человек сразу видит на этом рисунке треугольник, но нужно потратить изрядные усилия, чтобы научить компьютерную программу делать это.

Одним из людей, работающих на передовом крае науки в направлении разработки языков программирования, является Chris Granger, работающий над Eve. Он хочет разработать не только язык, но и весь сопутствующий инструментарий. Язык будет лишь одной из важных компонентов общей платформы. Я не знаю, станет ли его Eve новым поколением мейнстрим-платформ, но верю, что подобный подход, расширяющий и дополняющий язык вспомогательным инструментарием, может стать частью будущего. По крайней мере, это даст возможность лучше объяснить компьютеру, что же мы хотим от него получить. Как уже говорил выше Ras Bodik (и повторил я), мне бы хотелось, чтобы вы были частью этого прогресса. Изучайте все языки программирования, а не один какой-то язык. Понимание основ и принципов позволяет видеть дальше и быть готовым к появлению нового.
Инфопульс Украина
96.92
Creating Value, Delivering Excellence
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 94

    –6
    Могу добавить что для компиляции и запуска несложных программ на очень многих языках программирования (несколько десятков) очень удобной оказалась среда разработки Geany (под Linux, но вроде и под Винду есть порт). Раньше под виндой приходилось держать кучу сред разработки (да, конечно можно и из командной строки… но лично мне удобнее и писать код, и компилировать и запускать из одной программы).
      +6
      … и уберёт страх перед незнакомым синтаксисом

      Страх сам собой пропадает после того, как приходит понимание, что есть грубо говоря три варианта синтаксиса:
      — «синтаксис в стиле Си» (C++, Java, C#, Javascript, Go, Vala...)
      — «жизнь без скобок» (Python, Ruby, CoffeeScript… ассемблер? Хотя нет, не будем про него)
      — «жизнь в шоколаде)))))))» (Clojure, Scheme, Common Lisp...)
      Стоит разобраться с одним языком из каждой «языковой группы», как сразу появляется возможность относительно спокойно читать код и на остальных языках.

      P.S.: Было бы здорово, если бы мысли, описанные в статье, применялись в наших вузах. А то сейчас часто берут какой-то один язык и мучают только его, даже не сравнивая с другими.
        +6
        Языки подразделяются не только по стилю. Есть ещё функциональные (Erlang, Scala, F#), декларативные (SQL, QML, XML) и совсем экзотические (Prolog)
          +1
          Я говорю не о методах классификации языков, не о парадигмах (тот же самый JS позволяет как писать в функциональном стиле, так и строить систему классов, хотя и немного странную), а именно о синтаксисах. Упомянутые вами Erlang или F# синтаксически похожи на CoffeeScript.
            +3
            Упомянутые вами Erlang или F# синтаксически похожи на CoffeeScript.
            Не, это совсем мимо. CoffeeScript сам по себе очень искусственный гибрид.
            Erlang — говорят, синтаксически Prolog.
            F# — довольно типичный ML(SML, OCaml, множество их).
              0
              Синтаксис Erlang создавался под влиянием синтаксиса Prolog, F# — на базе ML. Даже с точки зрения синтаксиса у них мало общего с CoffeeScript, на который повлияли js, python и ruby.
              0
              XML это не язык программирования. это язык разметки
                0
                Скажите это Apache Ant (:
                  0

                  Ant — не язык программирования общего назначения. Скорее можно назвать это dsl'ем, использующим xml разметку. Другой пример — xslt.

                  –1

                  Скажите это XSLT :)

                  0
                  не экзотические, а языки логического программирования, обертка над исчислениям высказываний или предикатов, только и всего
                  +3
                  Не всё так однозначно даже с синтаксисом.
                  Синтаксис PERL (да и не только синтаксис) основан на С, однако зная второй, но не первый — читать его будет ой как не просто.
                    +6
                    Спорное утверждение. Скрипты на perl обычно сложно читать из-за того, что люди делают на нем однострочники с кучей регулярных выражений. Если бы мы на С писали все в одну строку и активно пользовались регулярками — это тоже было бы довольно сложно воспринимать. Тут уже вопрос стиля конкретного программиста/проекта/задач, которые ставятся. И на perl можно писать чисто и красиво, и на С можно сделать что-то страшное.
                      +1

                      Чем Perl отличается от PHP? В Perl сразу всё не понятно, а в PHP — только в регэкспах.(Ц) баш
                      PS. Мне те же скрипты удобнее написать на perl под виндой, чем на powershell, а у cmd возможностей просто не хватает.

                      +2

                      prolog?

                        +3

                        А также Pascal/Modula/Ada, MLи (начиная от непосредственно семейства: SML, OCaml, заканчивая Scala и Rust), всякие вещи типа APL/J/K/R. В общем, не очень получилась классификация групп синтаксиса.

                          0
                          Да
                          +4
                          А Forth вы куда отнесёте? ;-)
                            0
                            Сам на нем не работал, поэтому посмотрел случайные примеры на rosettacode, особенно понравилась инициализация OpenGL — https://rosettacode.org/wiki/OpenGL#Forth. Непривычно видеть все написанным «в обратную сторону», но в целом многие конструкции сразу узнаются. Можно отнести к «перевернутому» варианту без скобочек :)
                              +2
                              В принципе правы — это обратная польская запись.
                                –1

                                Далеко не так. Не надо упрощать и однобоко и ограниченно рассматривать основы Форт.
                                Как говорится, почувствуйте разницу.
                                https://ru.wikipedia.org/wiki/Конкатенативный_язык_программирования

                                  0
                                  А вы напишите свою форт-систему — тогда начнете лучше понимать основы.

                                  В порядке ликбеза.
                                  «Конкатенативный» — означает стековый. Это практически синонимы.
                                  Обратная польская запись — это форма записи выражения в стековом языке. Собственно их всего две: прямая и обратная. И любой стековый (конкатенативный) язык относится к одной из двух форм.
                                  P.S. я соавтор двух форт-систем
                                    0

                                    Конкатенация (соединение) слов программы это не прямая иерархия "пассивных" аргументов и "активных" действий по их обработке. СЛОВО (в рамках концепции Форт языка) это произвольно семантически наполняемая абстракция без необходимости формально фиксировать иерархию подчинения слов. СЛОВО может быть как активным (беря обработку входного потока программы) так и пассивным. Полиз нотация это только частный взгляд на возможность упрощённого понимания точки применения действия в сформированном контексте.


                                    P.S. Предпочитаю не писать без необходимости свою Форт систему, а использовать уже существующие.

                                      0
                                      Immediate — это частный случай. Вы же не называете С++ макро-языком? Хотя у него аж две стадии макроообработки.
                                        0

                                        Immediate, да это частный случай дизайна Форт как и другие частные механизмы введённые в дизайнм языка и позволяющие создавать произвольную синтаксис-семантику (DSL) в процессе трансляции программы для поддержания любой парадигмы программироания при создании ПО (без ограничений) минимальными штатными средствами.


                                        P.S. Если бы Форт ограничивался пониманием Полиз, то возможно было бы его формально перетранслировать в Си выполняемый листинг. :)

                                          0
                                          Не вижу никаких проблем в трансляции в исполняемый код или Си. Если сильно заплатят — готов сделать. Это все делается JIT-компиляцией (или полной), к которой форт отлично приспособлен (получше JAVA).

                                          Как пример кросс-компиляции — игрушка "Ну погоди". Там явно вычищены заголовки словарных статей и все неиспользуемое, включая механизм компиляции. Иначе бы не влезли.

                                          То есть компиляции форта в Си выглядит так
                                          1) Компиляция самого форта в словарь и назначение главного слов
                                          2) Обход дерева и маркировка используемых слов.
                                          3) Пословная кодогенерация на нужный язык. Проще в машинный код, но можно и в Си.
                                          4) Если в Си — маркировка часто-используемых слов как inline и прочие оптимизации.
                                      0

                                      Можете подсказать каких 2-ух Форт систем автор?

                                        +2
                                        Соавтор на М-6000 и БК-0010. Это 1986 год примерно
                                          0

                                          Это интересно с исторической точки зрения т.к. далее был принят стандарт на язык 94года и развитие Форт реализаций продолжилось до настоящего времени.


                                          P.S. В тоже время где то был в развитии ДССП (диалоговая система структурного программирования)

                                            0

                                            http://www.twirpx.com/library/comp/forth/ Некоторое количество доступной литературы по Forth (Форт) (современных рускоязычных изданий нет)

                                              0
                                              Ну вот у Баранова что-то было про нашу реализацию на M-6000. Основной авторы — Вова Патрышев, но я там достаточно багов исправил.
                                          +1
                                          А теперь покажите безстековую реализацию форта. :-)))
                                            0

                                            Это будет уже не совсем Форт, но ничего не мешает использовать механизм "ленты" или буфера ввода/вывода. В Форте можно и сейчас со стэком работать как с индексируемым или использовать именованные локальные переменные.


                                            P.S. Использование стэка в Форт имеет ряд очевидных плюсов и меньшее количество минусов.

                                              0
                                              Вот поэтому и обратная польская запись.

                                              Вас не удивляет, что в С++ — отдельный макропроцессор со своим собственным синтаксисом? И второй способ макрогенерации через темплейты. Ну вот и в форте — в компилируемой части обратная польская запись. А интерпретируемая часть (immediate) — это аналог макропроцессора, темплейтов и contexpr в С++.

                                              Собственно immeduate-слова все равно работают со стеком, только есть ещё и вычитка последующих аргументов из потока. Но эта вычитка — не является конкатенативной!!! То есть immedaite программирование не подпадает под определение конкатенативного языка.
                                                0
                                                Вас не удивляет, что в С++ — отдельный макропроцессор со своим собственным синтаксисом? И второй способ макрогенерации через темплейты.

                                                Это два принципиально разных инструмента для принципиально разных задач. Хотя области их применений немного перекрываются, конечно.

                                                  –2
                                                  Согласен. В форте слова, исполняемые во время компиляции, (immediate) предназначены в первую очередь для создания ключевых слов (операторов) языка форт. Кроме того, они могут заменить оба способа макрогенерации в СИ. А синтаксис… синтаксис может быть какой угодно. У immedaite полный доступ к компилятору, более того, сам процесс компиляции идет через immediate-слова.

                                                  Поэтому, если учитывать написание своих immediate-слов, форт просто нельзя отнести к какой-то синтаксической группе. Хитрый разработчик способен настолько изменить синтаксис, что это будет уже совсем не похоже на обратную польскую запись.

                                                  Но! Никто так не делает. И в основе форта — именно обратная польская запись. Хотя да — можно извратиться.
                                    0

                                    Более полные примеры OpenGL известных уроков NeHe на Forth
                                    https://sites.google.com/site/win324th/sources#_source%20NeHeLessonsIn4th

                                  +1

                                  Я бы езе семейство ML выделали: Ocaml, Haskell, Rust, PureScript, Elm

                                    0

                                    Синтаксически ржавчина не то что бы сильно ML.

                                      0

                                      Плюс-минус. ML с привкусом плюсовых шаблонов ,)

                                        0
                                        Да в общем то. И C влияние чувствуется. Но let и: из ML туда пришли.
                                    +9

                                    Это всё прекрасно, только в текущих реалиях "знание языка" — это не только возможность что-либо на нём написать, но и знание его преимуществ / недостатков / специфических конструкций, знания об "окружении" языка (библиотеки, фреймворки) и умение это знание использовать.

                                      +1

                                      Просто очередной провокационный заголовок, где под знанием языка стали понимать знание синтаксиса. Знать синтаксис тех же плюсов и знать их так, чтобы более-менее нормально писать без UB каждые десять строк (особенно, если использовать стандарт младше C++11) — две большие разницы.

                                        0

                                        Ну да.
                                        Я код на ruby вполне прилично читаю, если он в контексте, при том что ни строчки не написал на нём.

                                          0

                                          Руби в целом приятный и понятный, но за счёт большой гибкости самой объектной системы, которая мне крайне импонирует, в нём очень развито метапрограммирование и им периодически злоупотребляют ради удобных dsl'ей и convention over configuration.


                                          В итоге часто читать легко, а понять как работает — куда сложнее. И это даже без monkey patching'а, который добавляет ещё радости.

                                          –1

                                          Писать без UB довольно просто. А вот писать на С++ хорошо — это уже другое дело.

                                            +1

                                            Писать без UB только изучив синтаксис просто?! Куча довольно опытных программистов достаточно регулярно наступают на UB на C и C++, поэтому ваше утверждение порождает во мне некоторые сомнения..

                                        +6
                                        Во-первых, слишком много воды. Всю полезную информацию можно было уместить в пяток абзацев и десяток ссылок.

                                        Во-вторых, «изучить я зык программирования» в статье понимается как «понять идеи, на которых основан язык» + «изучить синтаксис». Это — как правило, не проблема. Но что бы практически использовать язык, необходимо достаточно свободно ориентироваться в «стандартной библиотеке» (а она в том или ином виде всегда есть) и иметь навык комбинирования возмножностей, предоставляемых языком и стандартной библиотекой, для получения оптимальных результатов. А это уже совсем другие затраты сил и времени.

                                        Хотя с основной мыслью статьи о полезности изучения базовых принципов, на которых строятся языки программирования, полностью согласен. Глупо было бы спорить.
                                          +2
                                          С иностранными язывками то же самое. Научиться читать без словаря и воспринимать на слух речь не так уж сложно, а вот чтобы самостоятельно писать на уровне, существенно превышающем Google Translate, и тем более говорить — даже и 10 лет не хватит.
                                          Причём причина в общем-то одна и та же: отсутствие обратной связи. Если где-то налажали с синтаксисом, компилятор вам об этом просигналит. А вот если не знаете особенностей управления памятью или обработки IP-пакетов, всё работать будет, но время от времени без видимых причин тормозить или крашиться под высокой нагрузкой. И совершенно непонятно почему и как это исправить.
                                          То же и с естественными языками. Если вы не знаете какого-то слова или не можете распарсить предложение, потому что там 5 глаголов и все в разной форме, вам сразу понятно, что тут есть пробел и даже понятно, как его исправить.
                                          А вот если вы накорябали фразу, то чёрт его знает, как определить степень корявости и чем заменить корявые участки. Нет обратной связи — нет обучения.
                                            0
                                            С иностранными язывками то же самое. Научиться читать без словаря и воспринимать на слух речь не так уж сложно, а вот чтобы самостоятельно писать на уровне, существенно превышающем Google Translate, и тем более говорить — даже и 10 лет не хватит.

                                            Смотря как учить.
                                            Чтобы говорить и так далее — для неплохого уровня хватит и трёх курсов интенсива (мой реальный опыт: три курса интенсива, каждый курс брал раз в год). А чтобы говорить на уровне "моя твоя понимать", хватит и одного хорошего курса.

                                          +1
                                          один язык с продвинутой поддержкой параллелизма (Clofure или Go).

                                          исправьте, опечатка
                                            0

                                            Принято в ЛС такое писать

                                              –1

                                              summon tangro

                                                0
                                                Fixed
                                              +1

                                              С точки зрения "сначала поржать, а потом подумать" очень интересен псевдодекларативный, объектный, заточенный для написания игр, язык Inform7. Обладая совершенно необычным синтаксисом, он тем не менее позволяет "на лету" городить сложные иерархии объектов и связывать их сигналами, а на них уже писать бота-говорилку. Это, в общем то, всё, что он умеет. Познавательно. Позволяет понять, что код может и не состоять из блоков — не единственная возможная.
                                              Ну а для тех, кто хочет всерьёз задуматься о мире и своём месте в нём, всегда есть Haskell.

                                                +2

                                                Haskell уже не так модно, лучше погружаться в экзистенциальный кризис в языках с нормальной поддержкой экзистенциальных типов всяких Idris.

                                                0

                                                Множество интересных синтаксических конструкций есть в Wolfram language.
                                                Он не только мультипарадигмальный, но и приемлет большое количество синтаксических стилей, и синтаксис там можно сильно изменять.
                                                Да что уж там говорить – графические файлы, математические формулы – валидные компоненты кода, у операторов настраивается приоритет, запросто можно ввести свою мудрёную нотацию, картинку использовать как переменную, использовать префиксную/постфиксную/инфиксную/надфиксную или любые другие формы записи, ну и так далее.
                                                Это мой любимый язык в плане вариативности и кастомизируемости синтаксиса.
                                                Если кому интересно, буду рад подискутировать**

                                                  +4
                                                  большое количество синтаксических стилей, и синтаксис там можно сильно изменять… у операторов настраивается приоритет, запросто можно ввести свою мудрёную нотацию

                                                  А есть ли это хорошо?

                                                  Wolfram language был спроектирован таким, видимо, исходя из каких-то достаточно веских оснований. Для универсального языка программирования такие возможности скорее минус, чем плюс. Вот, кстати, Ruby: одно и то же действие можно описать 2-3 разными синтаксическими конструкциями. Типа «кто как привык, пусть так и пишет». Но такой подход приводит к тому, что при разборе чужого кода надо помнить эти 2-3 вида конструкций. И это уже не хорошо.

                                                  Люди разрабатывают code style для того, что бы ограничить разнообразие использования пробелов, отступов, переводов строк. А тут полная «демократия» на уровне конструкций языка.
                                                  0

                                                  Как же про Rust то не сказали. Вот уж там конструкции так конструкции.

                                                    0

                                                    Идея отличная, и сам ей следую. Но я никогда не буду учить Brainfuck, мне жалко свой мозг.

                                                      +1
                                                      Ирония в сторону названия понятна, но если серъёзно — Haskell, например, больше brainfuck чем brainfuck )
                                                        0

                                                        Позвольте поинтересоваться, как именно вы сталкивались с обоими?

                                                      0
                                                      Самое смешное, что после изучения 5-10 языков, можно отлаживаться и на незнакомых языках.

                                                      1986ой год. Приехал в пионерлагерь к приятелю, работавшему вожатым. Весь вечер помогал деткам отлаживаться на БК-0010. И только ночью наконец-то почитал, что такое FOCAL.
                                                        0

                                                        Ну вообще-то из второго первое вовсе не следует. В случае данных примера и утверждения так совсем ложь.

                                                          0
                                                          А в чем ложь-то? Свидетели ещё живы, могут подтвердить. Большинство багов — в алгоритмах, они от языка не зависят.
                                                          +1

                                                          Совершенно верно. Как-то прочитал что, де, "я настолько давно программирую, что у меня уже нет любимого языка программирования". Собственно, принимая во внимание 30 летний стаж работы (читай — программирования) с компьютерами у меня эта стадия наступила уже давно. В принципе, на этой стадии можно не зная языка читать и понимать программы на нём, и, даже более того, находить и успешно патчить баги.
                                                          Кстати, начал я именно в 1986, а в 1988 уже имел свой БК-0010.

                                                            0
                                                            У меня примерно так же, начал в 1981ом, первое домашнее УПД на перфоленте — 1982ой, с 1983его — работаю программистом. А первый «свой» комп — тоже в 1988, только это была СМ-1420 и занимала она комнату метров 30 квадратных.
                                                          +5
                                                          > Если провести историческую аналогию, то кем бы вам больше хотелось быть: работником за ткацким станком, ежедневно выполняющим рутинные операции или разработчиком новых моделей таких станков?

                                                          Извините, но для преподавателя он слишком узко мыслит… Можно знать как работают станки и быть директором завода. Можно быть отличным мастером станка и создавать шедевры на все времена. Можно быть средненьким задротом станка, но увидеть, где можно его оптимизировать и ускорить производство. А можно быть full-stack на заводе и мыть там полы, а когда сломался станок — починить его. Это как Микеланджело сказали бы: «зачем ты рисуешь? лучше придумывай новые краски и кисточки!»
                                                          • UFO just landed and posted this here
                                                              +1
                                                              В статье не хватает упоминания о совсем другом мире языков — HDL (hardware definition language, verilog, vhdl). Крайне полезно попробывать себя в HDL даже для расширения кругозора, не обязательно быть инженером в области цифровой электроники. Принципиальный паралелизм языков описания электронных схем помогает взглянуть с другой стороны на понятия «одновременно» и «последовательно», и соответственно развить возможности сверх паралельного мышления, а значит и программирования.
                                                                0
                                                                Принципы работы HDL очень хорошо демонстрируются моделями на Haskell. Думаю, начинать надо с него, если есть желание двигаться в сторону железа.
                                                                +1
                                                                Имхо, чтобы стать инженером разработчиком, а не программистом X-языка, нужно изучать в порядке важности:

                                                                Предметную область(или несколько), в которой вы хотите быть профессионалом. Например, структуры данных, алгоритмы или WEB итп.

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

                                                                И только потом уже смотреть на синтаксис языка и его особенности. Зная всё выше написанное, конкретный язык будет изучить не так сложно.
                                                                  0
                                                                  Тут бы один выучить хорошо, куда там все. Согласен, можно добиться общего понимания программирования как процесса и это позволит после изучения синтаксиса писать алгоритмы на разных языках, но какая от этого практическая польза?

                                                                  Недавно как раз пытался понять условный «Путь программиста». К сожалению, какого-то единого, поддерживаемого большинством, мнения на этот счет найти не удалось. Что еще хуже, представленные взгляды практически не объясняют почему поступать следует так, а не иначе.

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

                                                                  Стоит появиться задачи на построении более-менее сложного алгоритма и всё, приплыли. Конечно можно написать много строчек кода, который в конечном счете решит проблему, но от понимания своей несостоятельности это не избавит.

                                                                  В итоге, думаю что следует погрузиться в Structure and Interpretation of Computer Programs, а там видно будет.
                                                                    +1
                                                                    Как говорится:«Хороший программист на фортране, может написать на любом языке хороший код фортрана». Или что-то вроде того…
                                                                      0
                                                                      Странно. Большая часть статей на хабре\ГТ рекомендует учить один-два-три языка и хорошо, дабы резюме не выглядело как «Фотограф\тамада\автослесарь». А тут про «минимум пять».

                                                                      Написать небольшую программу на 100-200 строк не проблема после нескольких дней чтения мануалов практически на любом современном языке, для человека, выучившего хотя бы паскаль уровня школького кружка по информатике. Но зачем? Единственное положительное, что я в данном моменте вижу это открытие для себя новых горизонтов — «почувствовать» язык. Но для этого хватит недели-месяца.

                                                                      Другое дело, что для «промышленного» программирования нужно более глубокое понимание принципов. Даже на ругаемом многими РНР написать гостевуху с $sql = «insert into soobshenia (text) values ('».$_GET['text']."')"; (Ну вы понимаете, к чему клоню =) ) и участвовать в разработке сложного проекта на каком-нибудь популярном фреймворке это совсем вещи разные. Сейчас мало знать чистый РНР или Питон, надо знать фреймворки, библиотеки и уметь их применять.

                                                                      Очень многие не пишут в таких статьях, что между ИИ крестиков-ноликов и многопользовательской игрой лежит огромная пропасть взлетов, падения, мата, пота и кипения мозга. Поэтому лично мне изучения двух-трех языков ближе. На работе пользуюсь РНР по ряду причин и для специфичных задач (радует работающий из коробки snmpget(), например) учу Питон ну и JS для личных проектов.
                                                                        +1
                                                                        Большая часть статей на хабре\ГТ рекомендует учить один-два-три языка и хорошо, дабы резюме не выглядело как «Фотограф\тамада\автослесарь». А тут про «минимум пять».

                                                                        Можно иметь несколько резюме по разным профилям или просто писать в резюме пару языков где есть наибольший практический опыт, если есть опасения показаться неглубоким.


                                                                        Написать небольшую программу на 100-200 строк не проблема после нескольких дней чтения мануалов практически на любом современном языке, для человека, выучившего хотя бы паскаль уровня школького кружка по информатике.

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

                                                                          0
                                                                          Странно. Большая часть статей на хабре\ГТ рекомендует учить один-два-три языка и хорошо, дабы резюме не выглядело как «Фотограф\тамада\автослесарь». А тут про «минимум пять».
                                                                          Джейми Хайнеман (разрушители легенд) родился в США, имеет диплом по русскому языку и литературе, работал сертифицированным мастером погружения, был капитаном яхты, экспертом по выживанию в дикой природе, был владельцем магазина домашних животных, машинистом, строительным инспектором по бетону, шеф-поваром, делал спец эффекты и атрибутику для кино и рекламы, и конечно же был главным разрушителем легенд. И это без перечисления периодических участий в разных ТВ-шоу и тому подобных акций (сражения роботов, симпсоны, и т.п.)
                                                                          0
                                                                          Напоминает универсальный совет Кнышева «Старайся чаще бывать везде».
                                                                            0
                                                                            А ещё можно изучить QuickBasic, потом С++ и писать на С++ в стиле QuickBasic.
                                                                              0
                                                                              Ну изучение C будет полезно далеко не для всех языков — учить потом Haskell или Prolog будет даже сложнее.
                                                                              Из параллельных языков стоит отметить незаслуженно забытый Sisal. Он бы хорошо на видеокарты лег.
                                                                                0

                                                                                А где in the wild используется Пролог? Не, его поверхностно изучить стоит, просто чтоб знать, что так вообще можно, но пролог по умолчанию медленный.

                                                                                  0
                                                                                  Не такой уж он и медленный. Просто стиль программирования на нем не поощряет эффективное программирование, а эффективный код выглядит кривовато.
                                                                                  Логическое программирование сейчас почти не применяется. Все, что я видел — это использование библиотеки core.logic в Clojure (вариация на тему mikiKanren).
                                                                                  Про Пролог слушал, что он применялся в программировании правил управления питанием в какой-то мобильной системе.
                                                                                  Я думаю, его с успехом можно было бы применять сейчас в разработке чатботов, в том числе с использованием индуктивного логического программирования (машинного обучения на базе Пролога).
                                                                                    0

                                                                                    А можете посоветовать какую-ть книгу по отсечению обхода и про то, как сделать так, чтобы порядок строк не влиял на поведение программы (т.е. как грамотно защититься от зацикливания)? У Братко я ничего такого не помню

                                                                                      0
                                                                                      К сожалению, ни чего посоветовать не могу.
                                                                                      Пролог очень ограниченно умеет использовать отрицательные ограничения. Скорее всего надо смотреть в сторону CLP, оно поддержано в большинстве реализаций.
                                                                                      0

                                                                                      Учитывая, что в классическом Прологе — строгая бинарная логика без каких-либо случайностей или неясностей, то для практических реальных задач лучше подойдёт Fuzzy Prolog, но он, вроде, увы, существует только "на бумаге" :(


                                                                                      PS кто в курсе как обстоят дела с Curry и Mercury?
                                                                                      Эти языки помимо логического программирования поддерживают ещё и функциональное, а значит должны лучше подойти для практических задач.

                                                                                        0
                                                                                        Нечеткая логика — вещь сомнительная. Она не соответствует теории вероятности, то есть может выдать внутренне противоречивые рекомендации. Хотя для работы с зашумленными данными действительно требуется что-то новое.

                                                                                        Про Curry давно ни чего не слышал. По моему проект не развивается, несмотря на две независимые реализации. В Merury вроде есть какая то жизнь, но я не очень слежу. Он уж слишком ориентирован на производительность, думаю это не очень актуально.
                                                                                  0
                                                                                  один декларативный язык (Prolog

                                                                                  А почему не SQL?


                                                                                  Я конечно понимаю, что идея Пролога — красивая. Но, на практике вряд ли кому придётся разбирать код на Прологе, скорее всего это будет код на SQL.

                                                                                    0
                                                                                    Есть еще язык запросов SPARQL, синтаксисов похожие на SQL, но семантикой ближе к Prolog. Он вполне может пригодиться.
                                                                                      0

                                                                                      Недавно удивился, обнаружив в разрабатываемой спецификации Java Value Classes куски кода описания на прологе http://cr.openjdk.java.net/~dlsmith/values.html

                                                                                      0
                                                                                      Во-первых, я не понял, как от темы изучить все языки программирования автор так ловко перешёл к теме написания компиляторов. То есть если я хочу изучить все языки программирования, мне нужно уметь компилировать?

                                                                                      Во-вторых, про книгу дракона. Я как-то пытался её прочитать, но не смог, слишком сложно. Хотя как написать компилятор, я представляю. В общем, книга дракона слишком сложная. Читайте что-нибудь попроще. Ну или попытайтесь просто представить себе, как бы вы стали делать компилятор. И напишите. Вот отличная ссылка в тему, она необходима этому посту: http://prog21.dadgum.com/30.html
                                                                                        0

                                                                                        Как по мне, наоборот, dragon book достаточно простая книга.

                                                                                        0
                                                                                        Мне кажется, автор немного путает теорию языков программирования и разработку компиляторов. Это хоть и рядом, но не одно и то же.

                                                                                        Именно теорию языков программирования можно изучать, на мой взгляд, двумя основными способами:
                                                                                        1. Практический: брать незнакомые языки разной степени упоротости и пробовать на них писать, попутно стараясь смотреть «вглубь», отмечая принципы, которые лежат в их основе, а так же идиомы, отличия от других языков и так далее.
                                                                                        Здесь могу порекомендовать книжку 7 языков за 7 недель, она весьма неплоха для поиграться с пользой.
                                                                                        2. Теоретический: писать на каком-нибудь лиспе интерпретаторы языков с разными свойствами, чтобы понимать, как оно внутри устроено, попутно копая в лямбда-исчисление и прочее.

                                                                                        Где-то посередине между двумя подходами находится отличный курс Дэна Гроссмана Языки программирования. Его я очень, очень рекомендую.
                                                                                          +1
                                                                                          Спасибо за интересный перевод. Жаль, не успел принять участие в обсуждении. Обсуждение показалось мне интереснее, чем статья. Немного в сторону:
                                                                                          Треугольник иллюзий. Человек сразу видит на этом рисунке треугольник, но нужно потратить изрядные усилия, чтобы научить компьютерную программу делать это.
                                                                                          Это утверждение статьи вызвало недоумение. Преобразованием Хафа находим отрезки прямых, далее отрезки, лежащие на одной прямой, и точки пересечения этих прямых. Проще простого!

                                                                                          Only users with full accounts can post comments. Log in, please.