Комментарии 94
… и уберёт страх перед незнакомым синтаксисом
Страх сам собой пропадает после того, как приходит понимание, что есть грубо говоря три варианта синтаксиса:
— «синтаксис в стиле Си» (C++, Java, C#, Javascript, Go, Vala...)
— «жизнь без скобок» (Python, Ruby, CoffeeScript… ассемблер? Хотя нет, не будем про него)
— «жизнь в шоколаде)))))))» (Clojure, Scheme, Common Lisp...)
Стоит разобраться с одним языком из каждой «языковой группы», как сразу появляется возможность относительно спокойно читать код и на остальных языках.
P.S.: Было бы здорово, если бы мысли, описанные в статье, применялись в наших вузах. А то сейчас часто берут какой-то один язык и мучают только его, даже не сравнивая с другими.
Упомянутые вами Erlang или F# синтаксически похожи на CoffeeScript.
Не, это совсем мимо. CoffeeScript сам по себе очень искусственный гибрид.
Erlang — говорят, синтаксически Prolog.
F# — довольно типичный ML(SML, OCaml, множество их).
Синтаксис PERL (да и не только синтаксис) основан на С, однако зная второй, но не первый — читать его будет ой как не просто.
Чем Perl отличается от PHP? В Perl сразу всё не понятно, а в PHP — только в регэкспах.(Ц) баш
PS. Мне те же скрипты удобнее написать на perl под виндой, чем на powershell, а у cmd возможностей просто не хватает.
Далеко не так. Не надо упрощать и однобоко и ограниченно рассматривать основы Форт.
Как говорится, почувствуйте разницу.
https://ru.wikipedia.org/wiki/Конкатенативный_язык_программирования
Обратная польская запись — это форма записи выражения в стековом языке. Собственно их всего две: прямая и обратная. И любой стековый (конкатенативный) язык относится к одной из двух форм.
P.S. я соавтор двух форт-систем
Конкатенация (соединение) слов программы это не прямая иерархия "пассивных" аргументов и "активных" действий по их обработке. СЛОВО (в рамках концепции Форт языка) это произвольно семантически наполняемая абстракция без необходимости формально фиксировать иерархию подчинения слов. СЛОВО может быть как активным (беря обработку входного потока программы) так и пассивным. Полиз нотация это только частный взгляд на возможность упрощённого понимания точки применения действия в сформированном контексте.
P.S. Предпочитаю не писать без необходимости свою Форт систему, а использовать уже существующие.
Immediate, да это частный случай дизайна Форт как и другие частные механизмы введённые в дизайнм языка и позволяющие создавать произвольную синтаксис-семантику (DSL) в процессе трансляции программы для поддержания любой парадигмы программироания при создании ПО (без ограничений) минимальными штатными средствами.
P.S. Если бы Форт ограничивался пониманием Полиз, то возможно было бы его формально перетранслировать в Си выполняемый листинг. :)
Как пример кросс-компиляции — игрушка "Ну погоди". Там явно вычищены заголовки словарных статей и все неиспользуемое, включая механизм компиляции. Иначе бы не влезли.
То есть компиляции форта в Си выглядит так
1) Компиляция самого форта в словарь и назначение главного слов
2) Обход дерева и маркировка используемых слов.
3) Пословная кодогенерация на нужный язык. Проще в машинный код, но можно и в Си.
4) Если в Си — маркировка часто-используемых слов как inline и прочие оптимизации.
Можете подсказать каких 2-ух Форт систем автор?
Это интересно с исторической точки зрения т.к. далее был принят стандарт на язык 94года и развитие Форт реализаций продолжилось до настоящего времени.
P.S. В тоже время где то был в развитии ДССП (диалоговая система структурного программирования)
http://www.twirpx.com/library/comp/forth/ Некоторое количество доступной литературы по Forth (Форт) (современных рускоязычных изданий нет)
Это будет уже не совсем Форт, но ничего не мешает использовать механизм "ленты" или буфера ввода/вывода. В Форте можно и сейчас со стэком работать как с индексируемым или использовать именованные локальные переменные.
P.S. Использование стэка в Форт имеет ряд очевидных плюсов и меньшее количество минусов.
Вас не удивляет, что в С++ — отдельный макропроцессор со своим собственным синтаксисом? И второй способ макрогенерации через темплейты. Ну вот и в форте — в компилируемой части обратная польская запись. А интерпретируемая часть (immediate) — это аналог макропроцессора, темплейтов и contexpr в С++.
Собственно immeduate-слова все равно работают со стеком, только есть ещё и вычитка последующих аргументов из потока. Но эта вычитка — не является конкатенативной!!! То есть immedaite программирование не подпадает под определение конкатенативного языка.
Поэтому, если учитывать написание своих immediate-слов, форт просто нельзя отнести к какой-то синтаксической группе. Хитрый разработчик способен настолько изменить синтаксис, что это будет уже совсем не похоже на обратную польскую запись.
Но! Никто так не делает. И в основе форта — именно обратная польская запись. Хотя да — можно извратиться.
Более полные примеры OpenGL известных уроков NeHe на Forth
https://sites.google.com/site/win324th/sources#_source%20NeHeLessonsIn4th
Я бы езе семейство ML выделали: Ocaml, Haskell, Rust, PureScript, Elm
Это всё прекрасно, только в текущих реалиях "знание языка" — это не только возможность что-либо на нём написать, но и знание его преимуществ / недостатков / специфических конструкций, знания об "окружении" языка (библиотеки, фреймворки) и умение это знание использовать.
Просто очередной провокационный заголовок, где под знанием языка стали понимать знание синтаксиса. Знать синтаксис тех же плюсов и знать их так, чтобы более-менее нормально писать без UB каждые десять строк (особенно, если использовать стандарт младше C++11) — две большие разницы.
Ну да.
Я код на ruby вполне прилично читаю, если он в контексте, при том что ни строчки не написал на нём.
Руби в целом приятный и понятный, но за счёт большой гибкости самой объектной системы, которая мне крайне импонирует, в нём очень развито метапрограммирование и им периодически злоупотребляют ради удобных dsl'ей и convention over configuration.
В итоге часто читать легко, а понять как работает — куда сложнее. И это даже без monkey patching'а, который добавляет ещё радости.
Писать без UB довольно просто. А вот писать на С++ хорошо — это уже другое дело.
Во-вторых, «изучить я зык программирования» в статье понимается как «понять идеи, на которых основан язык» + «изучить синтаксис». Это — как правило, не проблема. Но что бы практически использовать язык, необходимо достаточно свободно ориентироваться в «стандартной библиотеке» (а она в том или ином виде всегда есть) и иметь навык комбинирования возмножностей, предоставляемых языком и стандартной библиотекой, для получения оптимальных результатов. А это уже совсем другие затраты сил и времени.
Хотя с основной мыслью статьи о полезности изучения базовых принципов, на которых строятся языки программирования, полностью согласен. Глупо было бы спорить.
Причём причина в общем-то одна и та же: отсутствие обратной связи. Если где-то налажали с синтаксисом, компилятор вам об этом просигналит. А вот если не знаете особенностей управления памятью или обработки IP-пакетов, всё работать будет, но время от времени без видимых причин тормозить или крашиться под высокой нагрузкой. И совершенно непонятно почему и как это исправить.
То же и с естественными языками. Если вы не знаете какого-то слова или не можете распарсить предложение, потому что там 5 глаголов и все в разной форме, вам сразу понятно, что тут есть пробел и даже понятно, как его исправить.
А вот если вы накорябали фразу, то чёрт его знает, как определить степень корявости и чем заменить корявые участки. Нет обратной связи — нет обучения.
С иностранными язывками то же самое. Научиться читать без словаря и воспринимать на слух речь не так уж сложно, а вот чтобы самостоятельно писать на уровне, существенно превышающем Google Translate, и тем более говорить — даже и 10 лет не хватит.
Смотря как учить.
Чтобы говорить и так далее — для неплохого уровня хватит и трёх курсов интенсива (мой реальный опыт: три курса интенсива, каждый курс брал раз в год). А чтобы говорить на уровне "моя твоя понимать", хватит и одного хорошего курса.
один язык с продвинутой поддержкой параллелизма (Clofure или Go).
исправьте, опечатка
Принято в ЛС такое писать
summon tangro
С точки зрения "сначала поржать, а потом подумать" очень интересен псевдодекларативный, объектный, заточенный для написания игр, язык Inform7. Обладая совершенно необычным синтаксисом, он тем не менее позволяет "на лету" городить сложные иерархии объектов и связывать их сигналами, а на них уже писать бота-говорилку. Это, в общем то, всё, что он умеет. Познавательно. Позволяет понять, что код может и не состоять из блоков — не единственная возможная.
Ну а для тех, кто хочет всерьёз задуматься о мире и своём месте в нём, всегда есть Haskell.
Множество интересных синтаксических конструкций есть в Wolfram language.
Он не только мультипарадигмальный, но и приемлет большое количество синтаксических стилей, и синтаксис там можно сильно изменять.
Да что уж там говорить – графические файлы, математические формулы – валидные компоненты кода, у операторов настраивается приоритет, запросто можно ввести свою мудрёную нотацию, картинку использовать как переменную, использовать префиксную/постфиксную/инфиксную/надфиксную или любые другие формы записи, ну и так далее.
Это мой любимый язык в плане вариативности и кастомизируемости синтаксиса.
Если кому интересно, буду рад подискутировать**
большое количество синтаксических стилей, и синтаксис там можно сильно изменять… у операторов настраивается приоритет, запросто можно ввести свою мудрёную нотацию
А есть ли это хорошо?
Wolfram language был спроектирован таким, видимо, исходя из каких-то достаточно веских оснований. Для универсального языка программирования такие возможности скорее минус, чем плюс. Вот, кстати, Ruby: одно и то же действие можно описать 2-3 разными синтаксическими конструкциями. Типа «кто как привык, пусть так и пишет». Но такой подход приводит к тому, что при разборе чужого кода надо помнить эти 2-3 вида конструкций. И это уже не хорошо.
Люди разрабатывают code style для того, что бы ограничить разнообразие использования пробелов, отступов, переводов строк. А тут полная «демократия» на уровне конструкций языка.
Как же про Rust то не сказали. Вот уж там конструкции так конструкции.
Идея отличная, и сам ей следую. Но я никогда не буду учить Brainfuck, мне жалко свой мозг.
Ну вообще-то из второго первое вовсе не следует. В случае данных примера и утверждения так совсем ложь.
Совершенно верно. Как-то прочитал что, де, "я настолько давно программирую, что у меня уже нет любимого языка программирования". Собственно, принимая во внимание 30 летний стаж работы (читай — программирования) с компьютерами у меня эта стадия наступила уже давно. В принципе, на этой стадии можно не зная языка читать и понимать программы на нём, и, даже более того, находить и успешно патчить баги.
Кстати, начал я именно в 1986, а в 1988 уже имел свой БК-0010.
Извините, но для преподавателя он слишком узко мыслит… Можно знать как работают станки и быть директором завода. Можно быть отличным мастером станка и создавать шедевры на все времена. Можно быть средненьким задротом станка, но увидеть, где можно его оптимизировать и ускорить производство. А можно быть full-stack на заводе и мыть там полы, а когда сломался станок — починить его. Это как Микеланджело сказали бы: «зачем ты рисуешь? лучше придумывай новые краски и кисточки!»
Предметную область(или несколько), в которой вы хотите быть профессионалом. Например, структуры данных, алгоритмы или WEB итп.
Различные парадигмы и подходы, которые применяются в языках. ООП, функциональщина итд
И только потом уже смотреть на синтаксис языка и его особенности. Зная всё выше написанное, конкретный язык будет изучить не так сложно.
Недавно как раз пытался понять условный «Путь программиста». К сожалению, какого-то единого, поддерживаемого большинством, мнения на этот счет найти не удалось. Что еще хуже, представленные взгляды практически не объясняют почему поступать следует так, а не иначе.
Приходится искать свой путь. На текущий момент считаю, что познания синтаксиса, даже определенных паттернов программирования, даже если удается создавать что-то рабочее не позволяет говорить о себе, как о программисте.
Стоит появиться задачи на построении более-менее сложного алгоритма и всё, приплыли. Конечно можно написать много строчек кода, который в конечном счете решит проблему, но от понимания своей несостоятельности это не избавит.
В итоге, думаю что следует погрузиться в Structure and Interpretation of Computer Programs, а там видно будет.
Написать небольшую программу на 100-200 строк не проблема после нескольких дней чтения мануалов практически на любом современном языке, для человека, выучившего хотя бы паскаль уровня школького кружка по информатике. Но зачем? Единственное положительное, что я в данном моменте вижу это открытие для себя новых горизонтов — «почувствовать» язык. Но для этого хватит недели-месяца.
Другое дело, что для «промышленного» программирования нужно более глубокое понимание принципов. Даже на ругаемом многими РНР написать гостевуху с $sql = «insert into soobshenia (text) values ('».$_GET['text']."')"; (Ну вы понимаете, к чему клоню =) ) и участвовать в разработке сложного проекта на каком-нибудь популярном фреймворке это совсем вещи разные. Сейчас мало знать чистый РНР или Питон, надо знать фреймворки, библиотеки и уметь их применять.
Очень многие не пишут в таких статьях, что между ИИ крестиков-ноликов и многопользовательской игрой лежит огромная пропасть взлетов, падения, мата, пота и кипения мозга. Поэтому лично мне изучения двух-трех языков ближе. На работе пользуюсь РНР по ряду причин и для специфичных задач (радует работающий из коробки snmpget(), например) учу Питон ну и JS для личных проектов.
Большая часть статей на хабре\ГТ рекомендует учить один-два-три языка и хорошо, дабы резюме не выглядело как «Фотограф\тамада\автослесарь». А тут про «минимум пять».
Можно иметь несколько резюме по разным профилям или просто писать в резюме пару языков где есть наибольший практический опыт, если есть опасения показаться неглубоким.
Написать небольшую программу на 100-200 строк не проблема после нескольких дней чтения мануалов практически на любом современном языке, для человека, выучившего хотя бы паскаль уровня школького кружка по информатике.
Да ладно. Не верю что все будет так гладко если взять обычного императивщика, который никогда не видел функциональщину, и посадить написать алгоритм средней сложности на том же хаскеле. Там на одно чтение статей о буррито может пара недель уйти легко.
Странно. Большая часть статей на хабре\ГТ рекомендует учить один-два-три языка и хорошо, дабы резюме не выглядело как «Фотограф\тамада\автослесарь». А тут про «минимум пять».Джейми Хайнеман (разрушители легенд) родился в США, имеет диплом по русскому языку и литературе, работал сертифицированным мастером погружения, был капитаном яхты, экспертом по выживанию в дикой природе, был владельцем магазина домашних животных, машинистом, строительным инспектором по бетону, шеф-поваром, делал спец эффекты и атрибутику для кино и рекламы, и конечно же был главным разрушителем легенд. И это без перечисления периодических участий в разных ТВ-шоу и тому подобных акций (сражения роботов, симпсоны, и т.п.)
Из параллельных языков стоит отметить незаслуженно забытый Sisal. Он бы хорошо на видеокарты лег.
А где in the wild используется Пролог? Не, его поверхностно изучить стоит, просто чтоб знать, что так вообще можно, но пролог по умолчанию медленный.
Логическое программирование сейчас почти не применяется. Все, что я видел — это использование библиотеки core.logic в Clojure (вариация на тему mikiKanren).
Про Пролог слушал, что он применялся в программировании правил управления питанием в какой-то мобильной системе.
Я думаю, его с успехом можно было бы применять сейчас в разработке чатботов, в том числе с использованием индуктивного логического программирования (машинного обучения на базе Пролога).
А можете посоветовать какую-ть книгу по отсечению обхода и про то, как сделать так, чтобы порядок строк не влиял на поведение программы (т.е. как грамотно защититься от зацикливания)? У Братко я ничего такого не помню
Учитывая, что в классическом Прологе — строгая бинарная логика без каких-либо случайностей или неясностей, то для практических реальных задач лучше подойдёт Fuzzy Prolog, но он, вроде, увы, существует только "на бумаге" :(
PS кто в курсе как обстоят дела с Curry и Mercury?
Эти языки помимо логического программирования поддерживают ещё и функциональное, а значит должны лучше подойти для практических задач.
Про Curry давно ни чего не слышал. По моему проект не развивается, несмотря на две независимые реализации. В Merury вроде есть какая то жизнь, но я не очень слежу. Он уж слишком ориентирован на производительность, думаю это не очень актуально.
один декларативный язык (Prolog
А почему не SQL?
Я конечно понимаю, что идея Пролога — красивая. Но, на практике вряд ли кому придётся разбирать код на Прологе, скорее всего это будет код на SQL.
Недавно удивился, обнаружив в разрабатываемой спецификации Java Value Classes куски кода описания на прологе http://cr.openjdk.java.net/~dlsmith/values.html
Во-вторых, про книгу дракона. Я как-то пытался её прочитать, но не смог, слишком сложно. Хотя как написать компилятор, я представляю. В общем, книга дракона слишком сложная. Читайте что-нибудь попроще. Ну или попытайтесь просто представить себе, как бы вы стали делать компилятор. И напишите. Вот отличная ссылка в тему, она необходима этому посту: http://prog21.dadgum.com/30.html
Именно теорию языков программирования можно изучать, на мой взгляд, двумя основными способами:
1. Практический: брать незнакомые языки разной степени упоротости и пробовать на них писать, попутно стараясь смотреть «вглубь», отмечая принципы, которые лежат в их основе, а так же идиомы, отличия от других языков и так далее.
Здесь могу порекомендовать книжку 7 языков за 7 недель, она весьма неплоха для поиграться с пользой.
2. Теоретический: писать на каком-нибудь лиспе интерпретаторы языков с разными свойствами, чтобы понимать, как оно внутри устроено, попутно копая в лямбда-исчисление и прочее.
Где-то посередине между двумя подходами находится отличный курс Дэна Гроссмана Языки программирования. Его я очень, очень рекомендую.
Треугольник иллюзий. Человек сразу видит на этом рисунке треугольник, но нужно потратить изрядные усилия, чтобы научить компьютерную программу делать это.Это утверждение статьи вызвало недоумение. Преобразованием Хафа находим отрезки прямых, далее отрезки, лежащие на одной прямой, и точки пересечения этих прямых. Проще простого!
Изучите все языки программирования