Pull to refresh

Comments 30

Какие-то «откровения 60х годов». Я, конечно, извиняюсь, но вокруг идеи «чем сложнее у вас язык тем проще программирование, но и тем сложнее метапрограммирование» LISP построен. И Forth. И много чего ещё. Зачем ломиться в открытую дверь? Про это и так все всё знают. Одна проблема: до метапрограммирования нужно ещё дожить — потому зачастую будущая сложность приносится в жертву текущей.
Про это и так все всё знают

Не все здесь активно программировали в 60-е.

Спасибо автору за интересную тему и хорошую подачу.
во многих случаях нам нужны менее мощные языки программирования
Мощность языка программирования не обязывает никого использовать её полностью. Вы хотите сказать что более простой язык будет проще понимать, но возможности восприятия зависят от конкретного индивидуума. Не забывайте что тех, кто не понимает ни одного языка программирования на нашей планете большинство.
помните: менее мощный язык, как это ни парадоксально, дает больше возможностей
Ну это вообще пушка. Вы говорили про долгосрочную поддержку, но это лишь вопрос к чистому коду и культуре разработки, но никак не к языку. На любом языке можно говнокодить.
including the need to produce efficient code, and long term maintainability, less powerful languages are actually more powerful — “slavery is freedom”.
Возникает ощущение, что автор текста просто троллит.
Похоже меня не поняли. По пунктам:
а. У меня нет претензий к переводчику, меня смущает лишь оригинальный текст.
б. Автор оригинального текста вывернул мысль, вероятно, просто не подобрал слова.
в. Как по-моему должна звучать фраза, чтобы не вводить мозг в заблуждение:
less powerful languages are actually more efficient — «Simplicity is the key to brilliance»
г. Заодно переведу эту мысль на русский:
менее мощные языки могут быть более эффективными — «Простота высшая ступень искусства»
д. Всё что я называю троллингом это метание фразами «Slavery is freedom».
Мощность языка обязывает разработчика компилятора или транслятора реализовать ее полностью, даже если ей никто пользоваться не будет.
Неважно, что, например, лично вы не будите использовать ее полносью. Кто-то будет. И когда у вас возникнет задача сделать что-то гарантированно с кодом (банальный пример — автоматический рефакторинг), вам придеться учитывать тех неудобных людей, что решили воспользоваться всеми возможностями языка. Именно об этой проблеме работы с черезчур мощными языками говорит автор. Иногда хочется каких-то гарантий.
Странно, как вы пропустили доклад Рича Хикки «Simple Made Easy».
http://www.infoq.com/presentations/Simple-Made-Easy
UFO just landed and posted this here
К сожалению, этого никто не будет делать, пока создание новых языков будет требовать больших усилий. Так что намного эффективнее было бы выбирать такую программную экосистему, которая позволит легко создавать очень маленькие и слабые языки.


Даже боюсь представить мир где прогрессивным программистам ничего не стоит создать себе подходящий язык, удобный и лаконичный.
Даже сейчас когда каждая компания и хипстер считает своим долгом придумать новый, самый, самый язык программирования, хаос уже ощущается.
С каждым годом энтропия в отрасли увеличивается.
В этом месте соглашусь с автором статьи — в общем-то он предлагает то, что называется DSL. Делается язык под задачу и в нём будет сложнее накосячить, а разбирать и обрабатывать его, наоборот, проще. Примеров уже и так полно, языки для описания звуковых эффектов, языки для графики типа GLSL и т.п.
Это если domain постоянно не меняется, а вот в противном случае dsl начинает превращаться в кашу из разных фич.
Если domain постоянно меняется, то это уже не domain, а непонятно что. В таких случаях надо либо редизайнить систему, чтобы разобраться, какой же у вас всё-таки domain, либо действительно признать, что его нет и вам нужен язык общего назначения.
GLSL — это же костыль. Потому что не осилили поддерживать(на уровне железа) весь C целиком. Сейчас GLSL по сути пришел к С. А уж его альтернативы так вообще обычный С.
Вообще C — это тоже прекрасный пример очень упрощённого языка, так уж. Никаких запутанных фич, всё понятно и предсказуемо.
Но я согласен, пример получился не самый удачный. В любом случае есть ещё SQL, конфиги и куча других мест, где успешно применяется DSL.
Это ж как усложнится язык дифов, если он будет поддеживать такие *мощные* выражения как «Функция foo переименована в bar»? :-)

Автор во многом путает перпендикулярные понятия: декларативность и мощность. Декларативный язык тоже может быть мощным (тот же лисп), а императивный слабомощным (тот же ява-байткод). Но именно декларативность позволяет работать с языком как с данными, а не как с программой. Впрочем, любую программу можно превратить в данные, но для этого потребуется глубоко проанализировать потоки данных, что довольно сложно.

Думаю 90% (если не больше) читателей не поймут сути Вашей статьи. И судя по комментариям — так оно и есть.
Вообще автор существенно перегибает палку. Прямо начиная с баз данных. Неструктурированные данные всегда первичны, и зачастую содержат больше информации, чем структурированные. Потому что заранее неизвестно, какие сигналы из них могут потребоваться, не всегда структура, покрывающая все возможные случаи, удобна.

Например, почтовые адреса: чтобы не рассказывать своими словами, дам ссылку на публикацию об удивительных адресах нашей страны. Можно декомпозировать адрес, предусмотреть сто уровней вложенности, предусмотреть, что для некоторых адресов «город» может превращаться в «городской округ», а внутри него может быть квартал, а в квартале — ещё один город. А потом изобретать способы собрать из этого строковое представление и ловить баги. Проще просто хранить готовое представление. Или хранить его для сложных случаев, а в простых использовать простую схему типа той, что в КЛАДР.

Например, тексты: казалось бы, что может быть проще текстов? Оцифровать всё, распознать, получить профит. Допотопные книги — на свалку. Так? Нет, говорят более прошаренные люди. А как же провести анализ материала книги и чернил, установить её возраст, проверить, вдруг это вообще фальсификация? Провели, результаты записали в базу, книги выбросили, успокоились. Тем временем кому-то приходит в голову ещё как-нибудь поизгаляться над книгой и из неё внезапно удаётся получить ещё немножечко информации. Трудно достать всю информацию из аналоговой неструктурированной книги. Здесь, кстати, всё как в бигдате: мало иметь очень-много-данных, надо уметь извлечь из них сигналы и проанализировать. Конечно, книги надо оцифровывать, составлять по ним индексы для поиска и максимально использовать структурированную информацию. Просто не надо доходить до абсурда, исходная неструктурированная информация тоже полезна, не стоит ради неё придумывать какую-то схема, потому что мы заранее не знаем, какая она нам будет нужна.

Например, код: автор пишет про классный diff, который надо использовать вместо этих ваших строк. Настолько классный, что я даже на секунду задумался, а может правда, написать такой diff, не для питона, конечно, но для языка, где действительно можно построить AST. Потом, конечно, меня отпустило. Вот простой случай переименования автор описал, классный случай. А если взять чуть более сложный случай, был у нас метод из трёх строк: объявили переменную X, вызвали функцию A, вернули результат. Мы тело этого метода переписали в виде четырёх строк: объявили переменную Y, в цикле вызвали функцию B, вернули результат. Представьте себе этот дифф в виде модификаций AST. Удобно ли это читать? А ведь это простая структурированная информация, готовая к потреблению. Можно собирать дифф в виде AST, в простых случаях писать «function renamed», а в сложных опять генерировать текстовый дифф, обязательно скажет мне кто-нибудь. А зачем? Это тройная работа, невообразимое усложнение, только ради диффа? В рефакторинге это полезно, для диффа — нет. Не нужно усложнять алгоритм там, где хорошо работают простые средства. Простые решения работают надёжнее сложных.

Или вот ещё про код: долгие десятки лет большая часть веба была написана на Perl. На языке известном своей парадигмой TIMTOWTDI. Невообразимо усложнённый язык, про который даже доказывали, что его невозможно распарсить. А ведь в моём детстве, когда почти все динамические сайты содержали в себе путь /cgi-bin/, я был уверен, что CGI == Perl. Почему так получилось? Потому что код писался простой, никто не выдумывал адских и сложных решений. Когда вы пишете простой и очевидный инструмент, вам важнее написать его быстро и просто. И прочитать его должно быть просто. Когда «менее мощный» язык зарезает ваши возможности, код становится очевиднее и предсказуемее для машины, но не всегда — для человека. В этом был секрет популярности Perl и PHP, на них было просто разрабатываться, и основным потребителем был человек, а отнюдь не машина. Сейчас, когда задачи, которые решают программисты, в том числе и в вебе, усложнились, сдвинулся баланс: нам надо рефакторить сложный запутанный код, анализировать большие модули с кучей зависимостей и связей, мы перекладываем эту задачу на машину. И вот уже машине удобнее упрощённый язык. Фактически, вместо того чтобы писать для людей, мы теперь пишем для машин. И именно для этого приходится переходить на «менее мощные» языки, придумывать декларативные парсеры MANIFEST.in вместо императивных. Человеку удобнее и понятнее последовательность: «включили одно, потом выкинули другое», а более сложное декларативное описание удобнее только машине.

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

Человеку удобнее и понятнее последовательность: «включили одно, потом выкинули другое», а более сложное декларативное описание удобнее только машине.
Да ладно, все типичные машины выполняют как раз последовательность шагов. А вот людям это менее интересно, ибо «невыразительно».
Ну вот тот же пример из статьи с инклюдами: декларативный пример вам правда кажется более понятным?
Или вот, например, декларативные языки популярных систем сборки: Makefile, CMake. Каких только извращений не приходится придумывать людям, чтобы заставить их вести себя как надо. Причём в Makefile всё ещё относительно по-божески: декларативно описывается только граф целей, а сами цели пишутся в императивном стиле. Это позволяет в сложных местах плюнуть на кэширование каких-нибудь промежуточных звеньев, например, и написать просто явную последовательность команд. А в CMake декларативно по умолчанию вообще всё, и сборка сложного проекта выглядит… достаточно адово. В каком-нибудь qbs с его структурированным декларативным описанием из-за этого некоторые вещи в принципе нельзя сделать by design, хотя казалось бы, система сборки должна позволять собирать что угодно и как угодно.
У меня практика использования cmake обратная, ну и кроме того последовательность действий вполне можно описать через зависимости. Но с прошлым вашим постом я соглашусь.
А что касается невозможности сохранить: основной смысл моего высказывания был не в точности сохранения какой-то аналоговой информации. В конце концов, если речь идёт, например, о классической звукозаписи, то как правило звук и обложка ­— это вся полезная информация, которую мы можем извлечь с той или иной точностью, потому что в отличие от средневековья, хитрых полустёртых миниатюр и рисунков неопознанными красителями процесс производства пластинок доподлинно известен и под печатью рисунка на диске никогда не скрывается другой рисунок.

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

Точно так же, как в вышеупомянутых адресах мы балансируем между тем, чтобы создать сверхсложную структуру, в которую будем пытаться сложить любые данные и тем, чтобы потерять какую-нибудь возможно (не)важную информацию. Это как сверхуниверсальные стандарты типа SOAP или 7-уровневой модели OSI — настолько универсально, что даже неудобно и люди предпочитают использовать более простые и менее универсальные вещи.
По адресам: учитывая, что в КЛАДРе бывает не всё правильно и что нужно, никогда не удастся найти универсальное решение с хранением адреса. Тут надо смотреть необходимый уровень детализации: для областной больницы важна детализация до населённого пункта, в то время как для городской поликлиники придётся помучиться.

Что касается diff-ов: чтобы определить, что я сейчас перенёс функцию A в другое место, переименовал в B и поменял местами несколько строк, или же просто удалил, а в другом месте написал новую, которая по случайному совпадению оказалась немного похожей — для этого никакого искусственного интеллекта не хватит. Тут и естественному интеллекту без телепатии не обойтись. Однако если делать коммиты частыми и осмысленными, то в этом нет никакой необходимости. Перенёс функцию — закоммитил, переименовал — закоммитил, удалил ненужные строки — закоммитил.
Вы говорите об очень маленьких частных задачах. Ну кому, правда, нужно в диффе переименование функции? Как часто это встречается? Люди на ревью же не переименования функций читают? Такие маленькие частные случаи можно сделать чуть ли тривиальным постпроцессингом обычного дифф-файла, без какого-либо анализа AST — и это будет гораздо более простое решение.
С переименованием может быть и соглашусь, но смысл не в этом, а в том, что коммитить надо не скопом всё что накодил за день, а небольшими, и главное — осмысленными порциями.
С этим я и не подумаю спорить, боже упаси) Но я там выше привёл пример даже очень маленького диффа — замена тела функции из трёх строк на четыре других строки.
Ну вы все же поосторожнее с громкими заголовками, а то так и до восхваления Go или Oberon можно докатиться.
Бред. Автор видит связи там где их нет.
Sign up to leave a comment.