— Что, даже на том нечитаемом эзотерическом языке, где есть всего пара команд, которые едва-едва симулируют машину Тьюринга?
— Да, этот язык называется brainfuck. Я знаю brainfuck.
И это был не трюк — мы проверили. Я называл известный мне язык программирования, он тратил пару минут в Интернете на то, чтобы освежить свои знания по нему — и был способен писать на этом языке работающие алгоритмы. Я никак не мог понять этого. Ему, как и мне, было тогда около 18 лет — как он мог в этом возрасте знать все эти языки?
Интерпретатор 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. Если ваш интерес ограничен какой-то конкретной практической задачей небольшого масштаба (вроде написания предметно-ориентированного языка), то эта книга подойдёт лучше, чем классическая Книга Дракона.
Книга Дракона
Шаг номер 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++. Большинство других языков программирования тоже имеют в некоторой мере аналогичные публикации.
После этого можно уже почитать книгу по языку или сразу перейти к попыткам написать на нём что-нибудь не очень сложное. Что касается книг, то трудно давать какие-то общие рекомендации, но я бы всё-таки советовал выбирать наиболее устоявшиеся, проверенные годами вещи, написанные для опытных программистов, изучающих новый язык. Такие книги часто написаны самими авторами языка и подчёркивают их основные идеи, в то время как более современные публикации направлены скорее на практическое применение языков в тех или иных сферах.
Наиболее быстрый путь приобщиться к новому языку, по моему мнению, это найти набор небольших задач и постепенно их решать. Хорошим источником может быть Exercism.io. Кроме задач там даже есть тесты, дающие возможность быстро оценить качество вашей реализации. Решение маленьких задач хорошо согласуется с изучением теории и с основной работе над другими проектами.
Как только вы освоитесь с синтаксисом и небольшие задачи уже не будут вызывать у вас проблем, я советую найти большой проект на этом языке. И это должен быть проект именно в той сфере, для которой был создан этот язык. Например, если вы изучаете C или Go — пишите утилиту командной строки с большим количеством системных вызовов. Если изучаете Python или Ruby — попробуйте написать что-то алгоритмическое и не очень требовательное к производительности (ИИ для крестиков ноликов :) ) ну и т.д.
Продолжайте копать
Учитывая количество языков программирования в мире и тот факт, что мы действительно используем даже очень старые языки вроде С, легко сделать вывод, что человечество уже изобрело все необходимые ему языки программирования. Но это очень спорное предположение. Есть очень существенный пробел между тем, что считается возможным запрограммировать и тем, что мы на сегодняшний день уже научились программировать. И проблема не в вычислительных ресурсах — со всеми существующими сегодня аппаратными платформами и облаками у нас есть где погонять код. Проблема именно в наших способах общения с компьютером, с тем, что мы не всегда можем удобно выразить, что же мы хотим получить на выходе программы и как это должно быть рассчитано.
Gerald Jay Sussman обратил внимание на это в его потрясающем докладе We Really Don’t Know How To Compute. Он использует несколько устаревший инструментарий, но и существующие сегодня инструменты не дают нам каких-то качественно иных подходов к решению освещённых им проблем.
Треугольник иллюзий. Человек сразу видит на этом рисунке треугольник, но нужно потратить изрядные усилия, чтобы научить компьютерную программу делать это.
Одним из людей, работающих на передовом крае науки в направлении разработки языков программирования, является Chris Granger, работающий над Eve. Он хочет разработать не только язык, но и весь сопутствующий инструментарий. Язык будет лишь одной из важных компонентов общей платформы. Я не знаю, станет ли его Eve новым поколением мейнстрим-платформ, но верю, что подобный подход, расширяющий и дополняющий язык вспомогательным инструментарием, может стать частью будущего. По крайней мере, это даст возможность лучше объяснить компьютеру, что же мы хотим от него получить. Как уже говорил выше Ras Bodik (и повторил я), мне бы хотелось, чтобы вы были частью этого прогресса. Изучайте все языки программирования, а не один какой-то язык. Понимание основ и принципов позволяет видеть дальше и быть готовым к появлению нового.
Комментарии (92)
sfi0zy
29.06.2017 13:56+6… и уберёт страх перед незнакомым синтаксисом
Страх сам собой пропадает после того, как приходит понимание, что есть грубо говоря три варианта синтаксиса:
— «синтаксис в стиле Си» (C++, Java, C#, Javascript, Go, Vala...)
— «жизнь без скобок» (Python, Ruby, CoffeeScript… ассемблер? Хотя нет, не будем про него)
— «жизнь в шоколаде)))))))» (Clojure, Scheme, Common Lisp...)
Стоит разобраться с одним языком из каждой «языковой группы», как сразу появляется возможность относительно спокойно читать код и на остальных языках.
P.S.: Было бы здорово, если бы мысли, описанные в статье, применялись в наших вузах. А то сейчас часто берут какой-то один язык и мучают только его, даже не сравнивая с другими.
Lamaster
29.06.2017 14:13+6Языки подразделяются не только по стилю. Есть ещё функциональные (Erlang, Scala, F#), декларативные (SQL, QML, XML) и совсем экзотические (Prolog)
sfi0zy
29.06.2017 17:46+1Я говорю не о методах классификации языков, не о парадигмах (тот же самый JS позволяет как писать в функциональном стиле, так и строить систему классов, хотя и немного странную), а именно о синтаксисах. Упомянутые вами Erlang или F# синтаксически похожи на CoffeeScript.
nwalker
29.06.2017 19:29+3Упомянутые вами Erlang или F# синтаксически похожи на CoffeeScript.
Не, это совсем мимо. CoffeeScript сам по себе очень искусственный гибрид.
Erlang — говорят, синтаксически Prolog.
F# — довольно типичный ML(SML, OCaml, множество их).
potan
30.06.2017 17:51Синтаксис Erlang создавался под влиянием синтаксиса Prolog, F# — на базе ML. Даже с точки зрения синтаксиса у них мало общего с CoffeeScript, на который повлияли js, python и ruby.
japan007
30.06.2017 13:58не экзотические, а языки логического программирования, обертка над исчислениям высказываний или предикатов, только и всего
DrZlodberg
29.06.2017 14:41+3Не всё так однозначно даже с синтаксисом.
Синтаксис PERL (да и не только синтаксис) основан на С, однако зная второй, но не первый — читать его будет ой как не просто.sfi0zy
29.06.2017 18:06+6Спорное утверждение. Скрипты на perl обычно сложно читать из-за того, что люди делают на нем однострочники с кучей регулярных выражений. Если бы мы на С писали все в одну строку и активно пользовались регулярками — это тоже было бы довольно сложно воспринимать. Тут уже вопрос стиля конкретного программиста/проекта/задач, которые ставятся. И на perl можно писать чисто и красиво, и на С можно сделать что-то страшное.
Pakos
30.06.2017 15:23+1Чем Perl отличается от PHP? В Perl сразу всё не понятно, а в PHP — только в регэкспах.(Ц) баш
PS. Мне те же скрипты удобнее написать на perl под виндой, чем на powershell, а у cmd возможностей просто не хватает.
mxms
29.06.2017 19:44+4А Forth вы куда отнесёте? ;-)
sfi0zy
29.06.2017 20:33Сам на нем не работал, поэтому посмотрел случайные примеры на rosettacode, особенно понравилась инициализация OpenGL — https://rosettacode.org/wiki/OpenGL#Forth. Непривычно видеть все написанным «в обратную сторону», но в целом многие конструкции сразу узнаются. Можно отнести к «перевернутому» варианту без скобочек :)
Jef239
30.06.2017 08:16+2В принципе правы — это обратная польская запись.
FForth
01.07.2017 01:58-1Далеко не так. Не надо упрощать и однобоко и ограниченно рассматривать основы Форт.
Как говорится, почувствуйте разницу.
https://ru.wikipedia.org/wiki/Конкатенативный_язык_программированияJef239
01.07.2017 02:13А вы напишите свою форт-систему — тогда начнете лучше понимать основы.
В порядке ликбеза.«Конкатенативный» — означает стековый. Это практически синонимы.
Обратная польская запись — это форма записи выражения в стековом языке. Собственно их всего две: прямая и обратная. И любой стековый (конкатенативный) язык относится к одной из двух форм.
P.S. я соавтор двух форт-системFForth
01.07.2017 02:25Конкатенация (соединение) слов программы это не прямая иерархия "пассивных" аргументов и "активных" действий по их обработке. СЛОВО (в рамках концепции Форт языка) это произвольно семантически наполняемая абстракция без необходимости формально фиксировать иерархию подчинения слов. СЛОВО может быть как активным (беря обработку входного потока программы) так и пассивным. Полиз нотация это только частный взгляд на возможность упрощённого понимания точки применения действия в сформированном контексте.
P.S. Предпочитаю не писать без необходимости свою Форт систему, а использовать уже существующие.
Jef239
01.07.2017 12:21Immediate — это частный случай. Вы же не называете С++ макро-языком? Хотя у него аж две стадии макроообработки.
FForth
01.07.2017 13:52Immediate, да это частный случай дизайна Форт как и другие частные механизмы введённые в дизайнм языка и позволяющие создавать произвольную синтаксис-семантику (DSL) в процессе трансляции программы для поддержания любой парадигмы программироания при создании ПО (без ограничений) минимальными штатными средствами.
P.S. Если бы Форт ограничивался пониманием Полиз, то возможно было бы его формально перетранслировать в Си выполняемый листинг. :)
Jef239
01.07.2017 17:14Не вижу никаких проблем в трансляции в исполняемый код или Си. Если сильно заплатят — готов сделать. Это все делается JIT-компиляцией (или полной), к которой форт отлично приспособлен (получше JAVA).
Как пример кросс-компиляции — игрушка "Ну погоди". Там явно вычищены заголовки словарных статей и все неиспользуемое, включая механизм компиляции. Иначе бы не влезли.
То есть компиляции форта в Си выглядит так
1) Компиляция самого форта в словарь и назначение главного слов
2) Обход дерева и маркировка используемых слов.
3) Пословная кодогенерация на нужный язык. Проще в машинный код, но можно и в Си.
4) Если в Си — маркировка часто-используемых слов как inline и прочие оптимизации.
FForth
01.07.2017 02:31Можете подсказать каких 2-ух Форт систем автор?
Jef239
01.07.2017 12:14+2Соавтор на М-6000 и БК-0010. Это 1986 год примерно
FForth
01.07.2017 13:58Это интересно с исторической точки зрения т.к. далее был принят стандарт на язык 94года и развитие Форт реализаций продолжилось до настоящего времени.
P.S. В тоже время где то был в развитии ДССП (диалоговая система структурного программирования)
FForth
01.07.2017 15:22http://www.twirpx.com/library/comp/forth/ Некоторое количество доступной литературы по Forth (Форт) (современных рускоязычных изданий нет)
Jef239
01.07.2017 16:56Ну вот у Баранова что-то было про нашу реализацию на M-6000. Основной авторы — Вова Патрышев, но я там достаточно багов исправил.
FForth
01.07.2017 04:09Jef239
01.07.2017 12:16+1А теперь покажите безстековую реализацию форта. :-)))
FForth
01.07.2017 14:05Это будет уже не совсем Форт, но ничего не мешает использовать механизм "ленты" или буфера ввода/вывода. В Форте можно и сейчас со стэком работать как с индексируемым или использовать именованные локальные переменные.
P.S. Использование стэка в Форт имеет ряд очевидных плюсов и меньшее количество минусов.
Jef239
01.07.2017 17:03Вот поэтому и обратная польская запись.
Вас не удивляет, что в С++ — отдельный макропроцессор со своим собственным синтаксисом? И второй способ макрогенерации через темплейты. Ну вот и в форте — в компилируемой части обратная польская запись. А интерпретируемая часть (immediate) — это аналог макропроцессора, темплейтов и contexpr в С++.
Собственно immeduate-слова все равно работают со стеком, только есть ещё и вычитка последующих аргументов из потока. Но эта вычитка — не является конкатенативной!!! То есть immedaite программирование не подпадает под определение конкатенативного языка.
0xd34df00d
05.07.2017 18:33Вас не удивляет, что в С++ — отдельный макропроцессор со своим собственным синтаксисом? И второй способ макрогенерации через темплейты.
Это два принципиально разных инструмента для принципиально разных задач. Хотя области их применений немного перекрываются, конечно.
Jef239
06.07.2017 12:52-2Согласен. В форте слова, исполняемые во время компиляции, (immediate) предназначены в первую очередь для создания ключевых слов (операторов) языка форт. Кроме того, они могут заменить оба способа макрогенерации в СИ. А синтаксис… синтаксис может быть какой угодно. У immedaite полный доступ к компилятору, более того, сам процесс компиляции идет через immediate-слова.
Поэтому, если учитывать написание своих immediate-слов, форт просто нельзя отнести к какой-то синтаксической группе. Хитрый разработчик способен настолько изменить синтаксис, что это будет уже совсем не похоже на обратную польскую запись.
Но! Никто так не делает. И в основе форта — именно обратная польская запись. Хотя да — можно извратиться.
FForth
01.07.2017 02:11Более полные примеры OpenGL известных уроков NeHe на Forth
https://sites.google.com/site/win324th/sources#_source%20NeHeLessonsIn4th
fiskus_boulder
30.06.2017 11:09+1Я бы езе семейство ML выделали: Ocaml, Haskell, Rust, PureScript, Elm
maxru
29.06.2017 13:58+9Это всё прекрасно, только в текущих реалиях "знание языка" — это не только возможность что-либо на нём написать, но и знание его преимуществ / недостатков / специфических конструкций, знания об "окружении" языка (библиотеки, фреймворки) и умение это знание использовать.
grossws
30.06.2017 02:25+1Просто очередной провокационный заголовок, где под знанием языка стали понимать знание синтаксиса. Знать синтаксис тех же плюсов и знать их так, чтобы более-менее нормально писать без UB каждые десять строк (особенно, если использовать стандарт младше C++11) — две большие разницы.
maxru
30.06.2017 13:28Ну да.
Я код на ruby вполне прилично читаю, если он в контексте, при том что ни строчки не написал на нём.grossws
30.06.2017 13:33Руби в целом приятный и понятный, но за счёт большой гибкости самой объектной системы, которая мне крайне импонирует, в нём очень развито метапрограммирование и им периодически злоупотребляют ради удобных dsl'ей и convention over configuration.
В итоге часто читать легко, а понять как работает — куда сложнее. И это даже без monkey patching'а, который добавляет ещё радости.
zagayevskiy
30.06.2017 14:15-1Писать без UB довольно просто. А вот писать на С++ хорошо — это уже другое дело.
grossws
30.06.2017 14:37+1Писать без UB только изучив синтаксис просто?! Куча довольно опытных программистов достаточно регулярно наступают на UB на C и C++, поэтому ваше утверждение порождает во мне некоторые сомнения..
cranium256
29.06.2017 15:01+6Во-первых, слишком много воды. Всю полезную информацию можно было уместить в пяток абзацев и десяток ссылок.
Во-вторых, «изучить я зык программирования» в статье понимается как «понять идеи, на которых основан язык» + «изучить синтаксис». Это — как правило, не проблема. Но что бы практически использовать язык, необходимо достаточно свободно ориентироваться в «стандартной библиотеке» (а она в том или ином виде всегда есть) и иметь навык комбинирования возмножностей, предоставляемых языком и стандартной библиотекой, для получения оптимальных результатов. А это уже совсем другие затраты сил и времени.
Хотя с основной мыслью статьи о полезности изучения базовых принципов, на которых строятся языки программирования, полностью согласен. Глупо было бы спорить.Alexey2005
29.06.2017 20:50+2С иностранными язывками то же самое. Научиться читать без словаря и воспринимать на слух речь не так уж сложно, а вот чтобы самостоятельно писать на уровне, существенно превышающем Google Translate, и тем более говорить — даже и 10 лет не хватит.
Причём причина в общем-то одна и та же: отсутствие обратной связи. Если где-то налажали с синтаксисом, компилятор вам об этом просигналит. А вот если не знаете особенностей управления памятью или обработки IP-пакетов, всё работать будет, но время от времени без видимых причин тормозить или крашиться под высокой нагрузкой. И совершенно непонятно почему и как это исправить.
То же и с естественными языками. Если вы не знаете какого-то слова или не можете распарсить предложение, потому что там 5 глаголов и все в разной форме, вам сразу понятно, что тут есть пробел и даже понятно, как его исправить.
А вот если вы накорябали фразу, то чёрт его знает, как определить степень корявости и чем заменить корявые участки. Нет обратной связи — нет обучения.Idot
01.07.2017 08:49С иностранными язывками то же самое. Научиться читать без словаря и воспринимать на слух речь не так уж сложно, а вот чтобы самостоятельно писать на уровне, существенно превышающем Google Translate, и тем более говорить — даже и 10 лет не хватит.
Смотря как учить.
Чтобы говорить и так далее — для неплохого уровня хватит и трёх курсов интенсива (мой реальный опыт: три курса интенсива, каждый курс брал раз в год). А чтобы говорить на уровне "моя твоя понимать", хватит и одного хорошего курса.
Barafu
29.06.2017 18:13+1С точки зрения "сначала поржать, а потом подумать" очень интересен псевдодекларативный, объектный, заточенный для написания игр, язык Inform7. Обладая совершенно необычным синтаксисом, он тем не менее позволяет "на лету" городить сложные иерархии объектов и связывать их сигналами, а на них уже писать бота-говорилку. Это, в общем то, всё, что он умеет. Познавательно. Позволяет понять, что код может и не состоять из блоков — не единственная возможная.
Ну а для тех, кто хочет всерьёз задуматься о мире и своём месте в нём, всегда есть Haskell.0xd34df00d
01.07.2017 03:13+2Haskell уже не так модно, лучше погружаться в экзистенциальный кризис в
языках с нормальной поддержкой экзистенциальных типоввсяких Idris.
KirillGuzenko
29.06.2017 20:04Множество интересных синтаксических конструкций есть в Wolfram language.
Он не только мультипарадигмальный, но и приемлет большое количество синтаксических стилей, и синтаксис там можно сильно изменять.
Да что уж там говорить – графические файлы, математические формулы – валидные компоненты кода, у операторов настраивается приоритет, запросто можно ввести свою мудрёную нотацию, картинку использовать как переменную, использовать префиксную/постфиксную/инфиксную/надфиксную или любые другие формы записи, ну и так далее.
Это мой любимый язык в плане вариативности и кастомизируемости синтаксиса.
Если кому интересно, буду рад подискутировать**cranium256
30.06.2017 00:10+4большое количество синтаксических стилей, и синтаксис там можно сильно изменять… у операторов настраивается приоритет, запросто можно ввести свою мудрёную нотацию
А есть ли это хорошо?
Wolfram language был спроектирован таким, видимо, исходя из каких-то достаточно веских оснований. Для универсального языка программирования такие возможности скорее минус, чем плюс. Вот, кстати, Ruby: одно и то же действие можно описать 2-3 разными синтаксическими конструкциями. Типа «кто как привык, пусть так и пишет». Но такой подход приводит к тому, что при разборе чужого кода надо помнить эти 2-3 вида конструкций. И это уже не хорошо.
Люди разрабатывают code style для того, что бы ограничить разнообразие использования пробелов, отступов, переводов строк. А тут полная «демократия» на уровне конструкций языка.
akzhan
30.06.2017 07:31Идея отличная, и сам ей следую. Но я никогда не буду учить Brainfuck, мне жалко свой мозг.
Jef239
30.06.2017 08:21Самое смешное, что после изучения 5-10 языков, можно отлаживаться и на незнакомых языках.
1986ой год. Приехал в пионерлагерь к приятелю, работавшему вожатым. Весь вечер помогал деткам отлаживаться на БК-0010. И только ночью наконец-то почитал, что такое FOCAL.mxms
04.07.2017 11:53+1Совершенно верно. Как-то прочитал что, де, "я настолько давно программирую, что у меня уже нет любимого языка программирования". Собственно, принимая во внимание 30 летний стаж работы (читай — программирования) с компьютерами у меня эта стадия наступила уже давно. В принципе, на этой стадии можно не зная языка читать и понимать программы на нём, и, даже более того, находить и успешно патчить баги.
Кстати, начал я именно в 1986, а в 1988 уже имел свой БК-0010.Jef239
04.07.2017 16:29У меня примерно так же, начал в 1981ом, первое домашнее УПД на перфоленте — 1982ой, с 1983его — работаю программистом. А первый «свой» комп — тоже в 1988, только это была СМ-1420 и занимала она комнату метров 30 квадратных.
TimsTims
30.06.2017 09:15+5> Если провести историческую аналогию, то кем бы вам больше хотелось быть: работником за ткацким станком, ежедневно выполняющим рутинные операции или разработчиком новых моделей таких станков?
Извините, но для преподавателя он слишком узко мыслит… Можно знать как работают станки и быть директором завода. Можно быть отличным мастером станка и создавать шедевры на все времена. Можно быть средненьким задротом станка, но увидеть, где можно его оптимизировать и ускорить производство. А можно быть full-stack на заводе и мыть там полы, а когда сломался станок — починить его. Это как Микеланджело сказали бы: «зачем ты рисуешь? лучше придумывай новые краски и кисточки!»
guai
30.06.2017 11:52-5Зачем рекомендовать людям изучить сишку? Ее даже если даже захочешь, на козе не объедешь. Вот уж вездесущий язык! Тем более, растащенный по подавляющему большинству других языков.
Учите что-нибудь новое, сишка там всё равно будет.
EFG
30.06.2017 14:01+1В статье не хватает упоминания о совсем другом мире языков — HDL (hardware definition language, verilog, vhdl). Крайне полезно попробывать себя в HDL даже для расширения кругозора, не обязательно быть инженером в области цифровой электроники. Принципиальный паралелизм языков описания электронных схем помогает взглянуть с другой стороны на понятия «одновременно» и «последовательно», и соответственно развить возможности сверх паралельного мышления, а значит и программирования.
potan
30.06.2017 18:00Принципы работы HDL очень хорошо демонстрируются моделями на Haskell. Думаю, начинать надо с него, если есть желание двигаться в сторону железа.
dimack
30.06.2017 14:01+1Имхо, чтобы стать инженером разработчиком, а не программистом X-языка, нужно изучать в порядке важности:
Предметную область(или несколько), в которой вы хотите быть профессионалом. Например, структуры данных, алгоритмы или WEB итп.
Различные парадигмы и подходы, которые применяются в языках. ООП, функциональщина итд
И только потом уже смотреть на синтаксис языка и его особенности. Зная всё выше написанное, конкретный язык будет изучить не так сложно.
WantToBelieve
30.06.2017 14:02Тут бы один выучить хорошо, куда там все. Согласен, можно добиться общего понимания программирования как процесса и это позволит после изучения синтаксиса писать алгоритмы на разных языках, но какая от этого практическая польза?
Недавно как раз пытался понять условный «Путь программиста». К сожалению, какого-то единого, поддерживаемого большинством, мнения на этот счет найти не удалось. Что еще хуже, представленные взгляды практически не объясняют почему поступать следует так, а не иначе.
Приходится искать свой путь. На текущий момент считаю, что познания синтаксиса, даже определенных паттернов программирования, даже если удается создавать что-то рабочее не позволяет говорить о себе, как о программисте.
Стоит появиться задачи на построении более-менее сложного алгоритма и всё, приплыли. Конечно можно написать много строчек кода, который в конечном счете решит проблему, но от понимания своей несостоятельности это не избавит.
В итоге, думаю что следует погрузиться в Structure and Interpretation of Computer Programs, а там видно будет.
shaman_timon
30.06.2017 14:02+1Как говорится:«Хороший программист на фортране, может написать на любом языке хороший код фортрана». Или что-то вроде того…
calvin_rus
30.06.2017 14:03Странно. Большая часть статей на хабре\ГТ рекомендует учить один-два-три языка и хорошо, дабы резюме не выглядело как «Фотограф\тамада\автослесарь». А тут про «минимум пять».
Написать небольшую программу на 100-200 строк не проблема после нескольких дней чтения мануалов практически на любом современном языке, для человека, выучившего хотя бы паскаль уровня школького кружка по информатике. Но зачем? Единственное положительное, что я в данном моменте вижу это открытие для себя новых горизонтов — «почувствовать» язык. Но для этого хватит недели-месяца.
Другое дело, что для «промышленного» программирования нужно более глубокое понимание принципов. Даже на ругаемом многими РНР написать гостевуху с $sql = «insert into soobshenia (text) values ('».$_GET['text']."')"; (Ну вы понимаете, к чему клоню =) ) и участвовать в разработке сложного проекта на каком-нибудь популярном фреймворке это совсем вещи разные. Сейчас мало знать чистый РНР или Питон, надо знать фреймворки, библиотеки и уметь их применять.
Очень многие не пишут в таких статьях, что между ИИ крестиков-ноликов и многопользовательской игрой лежит огромная пропасть взлетов, падения, мата, пота и кипения мозга. Поэтому лично мне изучения двух-трех языков ближе. На работе пользуюсь РНР по ряду причин и для специфичных задач (радует работающий из коробки snmpget(), например) учу Питон ну и JS для личных проектов.
ozkriff
30.06.2017 14:09+1Большая часть статей на хабре\ГТ рекомендует учить один-два-три языка и хорошо, дабы резюме не выглядело как «Фотограф\тамада\автослесарь». А тут про «минимум пять».
Можно иметь несколько резюме по разным профилям или просто писать в резюме пару языков где есть наибольший практический опыт, если есть опасения показаться неглубоким.
Написать небольшую программу на 100-200 строк не проблема после нескольких дней чтения мануалов практически на любом современном языке, для человека, выучившего хотя бы паскаль уровня школького кружка по информатике.
Да ладно. Не верю что все будет так гладко если взять обычного императивщика, который никогда не видел функциональщину, и посадить написать алгоритм средней сложности на том же хаскеле. Там на одно чтение статей о буррито может пара недель уйти легко.
LynXzp
30.06.2017 23:33Странно. Большая часть статей на хабре\ГТ рекомендует учить один-два-три языка и хорошо, дабы резюме не выглядело как «Фотограф\тамада\автослесарь». А тут про «минимум пять».
Джейми Хайнеман (разрушители легенд) родился в США, имеет диплом по русскому языку и литературе, работал сертифицированным мастером погружения, был капитаном яхты, экспертом по выживанию в дикой природе, был владельцем магазина домашних животных, машинистом, строительным инспектором по бетону, шеф-поваром, делал спец эффекты и атрибутику для кино и рекламы, и конечно же был главным разрушителем легенд. И это без перечисления периодических участий в разных ТВ-шоу и тому подобных акций (сражения роботов, симпсоны, и т.п.)
potan
30.06.2017 18:06Ну изучение C будет полезно далеко не для всех языков — учить потом Haskell или Prolog будет даже сложнее.
Из параллельных языков стоит отметить незаслуженно забытый Sisal. Он бы хорошо на видеокарты лег.Gryphon88
30.06.2017 20:56А где in the wild используется Пролог? Не, его поверхностно изучить стоит, просто чтоб знать, что так вообще можно, но пролог по умолчанию медленный.
potan
30.06.2017 21:12Не такой уж он и медленный. Просто стиль программирования на нем не поощряет эффективное программирование, а эффективный код выглядит кривовато.
Логическое программирование сейчас почти не применяется. Все, что я видел — это использование библиотеки core.logic в Clojure (вариация на тему mikiKanren).
Про Пролог слушал, что он применялся в программировании правил управления питанием в какой-то мобильной системе.
Я думаю, его с успехом можно было бы применять сейчас в разработке чатботов, в том числе с использованием индуктивного логического программирования (машинного обучения на базе Пролога).Gryphon88
01.07.2017 00:54А можете посоветовать какую-ть книгу по отсечению обхода и про то, как сделать так, чтобы порядок строк не влиял на поведение программы (т.е. как грамотно защититься от зацикливания)? У Братко я ничего такого не помню
potan
01.07.2017 23:45К сожалению, ни чего посоветовать не могу.
Пролог очень ограниченно умеет использовать отрицательные ограничения. Скорее всего надо смотреть в сторону CLP, оно поддержано в большинстве реализаций.
Idot
01.07.2017 08:18Учитывая, что в классическом Прологе — строгая бинарная логика без каких-либо случайностей или неясностей, то для практических реальных задач лучше подойдёт Fuzzy Prolog, но он, вроде, увы, существует только "на бумаге" :(
PS кто в курсе как обстоят дела с Curry и Mercury?
Эти языки помимо логического программирования поддерживают ещё и функциональное, а значит должны лучше подойти для практических задач.potan
01.07.2017 23:39Нечеткая логика — вещь сомнительная. Она не соответствует теории вероятности, то есть может выдать внутренне противоречивые рекомендации. Хотя для работы с зашумленными данными действительно требуется что-то новое.
Про Curry давно ни чего не слышал. По моему проект не развивается, несмотря на две независимые реализации. В Merury вроде есть какая то жизнь, но я не очень слежу. Он уж слишком ориентирован на производительность, думаю это не очень актуально.
Idot
01.07.2017 06:53один декларативный язык (Prolog
А почему не SQL?
Я конечно понимаю, что идея Пролога — красивая. Но, на практике вряд ли кому придётся разбирать код на Прологе, скорее всего это будет код на SQL.
potan
01.07.2017 23:47Есть еще язык запросов SPARQL, синтаксисов похожие на SQL, но семантикой ближе к Prolog. Он вполне может пригодиться.
xonix
02.07.2017 02:35Недавно удивился, обнаружив в разрабатываемой спецификации Java Value Classes куски кода описания на прологе http://cr.openjdk.java.net/~dlsmith/values.html
safinaskar
01.07.2017 12:32Во-первых, я не понял, как от темы изучить все языки программирования автор так ловко перешёл к теме написания компиляторов. То есть если я хочу изучить все языки программирования, мне нужно уметь компилировать?
Во-вторых, про книгу дракона. Я как-то пытался её прочитать, но не смог, слишком сложно. Хотя как написать компилятор, я представляю. В общем, книга дракона слишком сложная. Читайте что-нибудь попроще. Ну или попытайтесь просто представить себе, как бы вы стали делать компилятор. И напишите. Вот отличная ссылка в тему, она необходима этому посту: http://prog21.dadgum.com/30.html
AnutaU
04.07.2017 11:30Мне кажется, автор немного путает теорию языков программирования и разработку компиляторов. Это хоть и рядом, но не одно и то же.
Именно теорию языков программирования можно изучать, на мой взгляд, двумя основными способами:
1. Практический: брать незнакомые языки разной степени упоротости и пробовать на них писать, попутно стараясь смотреть «вглубь», отмечая принципы, которые лежат в их основе, а так же идиомы, отличия от других языков и так далее.
Здесь могу порекомендовать книжку 7 языков за 7 недель, она весьма неплоха для поиграться с пользой.
2. Теоретический: писать на каком-нибудь лиспе интерпретаторы языков с разными свойствами, чтобы понимать, как оно внутри устроено, попутно копая в лямбда-исчисление и прочее.
Где-то посередине между двумя подходами находится отличный курс Дэна Гроссмана Языки программирования. Его я очень, очень рекомендую.
NeoCode
Могу добавить что для компиляции и запуска несложных программ на очень многих языках программирования (несколько десятков) очень удобной оказалась среда разработки Geany (под Linux, но вроде и под Винду есть порт). Раньше под виндой приходилось держать кучу сред разработки (да, конечно можно и из командной строки… но лично мне удобнее и писать код, и компилировать и запускать из одной программы).