Сначала он говорит о лексемах, но не знает что они называются термином "лексема", а придумывает свой термин — "элемент". Потом он упоминает, что не понимает что такое регулярный язык. Странно все это...
А вообще, если судить именно по краткости, то самыми краткими языками являются декларативные языки, например, Пролог — по краткости (по количеству лексем) он "сделает" любой императивный язык программирования.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Пол Грэм. Краткость — сила.
В статье ни разу не употреблено важное слово: библиотека (например, си++ с boost-ом и без — две большие разницы). Без его учета все рассуждения о краткости идут лесом.
Да и про IDE тоже ничего не говорится
Здравствуйте, eugals, Вы писали:
E>В статье ни разу не употреблено важное слово: библиотека (например, си++ с boost-ом и без — две большие разницы). Без его учета все рассуждения о краткости идут лесом.
1. Библиотеки ведь тоже кто-то пишет.
2. Лисп с библиотеками и Лисп без библиотек — тоже "две большие разницы". Но можно сравнить Лисп с библиотеками
си++ с библиотеками или их же, но без. E>Да и про IDE тоже ничего не говорится
А как IDE влияет на краткость
Здравствуйте, Трурль, Вы писали:
Т>1. Библиотеки ведь тоже кто-то пишет.
Кто бы их ни писал, факт в том, что само их наличие существенно влияет на краткость получаемых решений.
При всей лаконичности языка, если под него существует мало библиотек, он однозначно хуже более многословного, но хорошо расширяемого соперника. По критериям самого же Грема:
Думаю, лучшей мерой величины программы может быть количество элементов, где элементом является что-либо, могущее стать отдельной вершиной в дереве исходного кода. Имя переменной или функции есть элемент; целое или вещественное число есть элемент; сегмент текстового литерала есть элемент; элемент паттерна или форматной директивы есть элемент.
Использование библиотек (стандартных или сторонних) во многих случаях помогает сокращать указанное "количество элементов кода". Тем более в рамках предложенного способа сравнения:
Такие исследования, как сравнение языков программирования Лутца Прекельта, хоть и приводят к ожидаемым результатам, но склонны использовать задачи, которые слишком малы для осмысленного теста. Лучший тест для языка — это то, что происходит в программах, написанных за месяц.
Во всей статье речь идет не о гипотетических преимуществах какого-либо из языков программирования. Сравнение предполагается именно с позиции промышленного программирования, а в нем наличие библиотек является существенным (даже главным) криерием выбора средства разработки. Странно, что приходится это объяснять.
Т>2. Лисп с библиотеками и Лисп без библиотек — тоже "две большие разницы".
Я по поводу Лиспа ничего плохого и не говорил.
Т>А как IDE влияет на краткость
Она напрямую влияет на скорость разработки, ради достижения которой всё это сравнение и затевается.
Здравствуйте, eugals, Вы писали: E>Здравствуйте, Трурль, Вы писали:
Т>>1. Библиотеки ведь тоже кто-то пишет. E>Кто бы их ни писал, факт в том, что само их наличие существенно влияет на краткость получаемых решений.
Я просто предлагал посмотреть с точки зрения разработчика библиотеки. Вопрос краткости встает в первозданной чистоте.
E>При всей лаконичности языка, если под него существует мало библиотек, он однозначно хуже более многословного, но хорошо расширяемого соперника.
Наличие большого количества уже написанных библиотек не означает автоматически хорошей расширяемости.
Насчет "однозначно хуже": если среди всей кучи библиотек нет того, что нужно для решения данной задачи, то она абсолютно бесполезна.
E>Во всей статье речь идет не о гипотетических преимуществах какого-либо из языков программирования. Сравнение предполагается именно с позиции промышленного программирования, а в нем наличие библиотек является существенным (даже главным) криерием выбора средства разработки. Странно, что приходится это объяснять.
Для самого Грэма наличие библиотек не являлось ни главным, ни даже существенным критерием выбора.
Т>>А как IDE влияет на краткость E>Она напрямую влияет на скорость разработки, ради достижения которой всё это сравнение и затевается.
Во-первых, влияние IDE на скорость разработки не столь уж существенно.
Во-вторых, скорость разработки не рассматривается как единственный критерий.
программы, написанные на более сильных языках, имеют тенденцию содержать меньше ошибок. Этого уже вполне достаточно, и вероятно в таких задачах, как сетевые коммутаторы, это важнее, чем производительность программиста.
Здравствуйте, Трурль, Вы писали:
Т>>>1. Библиотеки ведь тоже кто-то пишет. E>>Кто бы их ни писал, факт в том, что само их наличие существенно влияет на краткость получаемых решений. Т>Я просто предлагал посмотреть с точки зрения разработчика библиотеки. Вопрос краткости встает в первозданной чистоте.
Ты — да. У него я такого не увидел (особенно, в контексте упоминаемой в начале статью "Мести зануд").
Что же касается проблем разработчика библиотек (первозданной чистоты), то тут тоже не всё ясно. Считать ли STL или boost или, скажем, builtin-функции python-а частью языка или же независимыми "элементами кода"...
спорный вопрос, а про него не сказано ни слова.
Т>Наличие большого количества уже написанных библиотек не означает автоматически хорошей расширяемости.
+1 Т>Насчет "однозначно хуже": если среди всей кучи библиотек нет того, что нужно для решения данной задачи, то она абсолютно бесполезна.
Да конечно, но это ведь не значит, что про существование библиотек нужно забывать вообще, рассматривать язык в отрыве от наработанных под него паттернов, сред разработки и т.п.
Т>Для самого Грэма наличие библиотек не являлось ни главным, ни даже существенным критерием выбора.
Вот я про это и говорю
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Сначала он говорит о лексемах, но не знает что они называются термином "лексема", а придумывает свой термин — "элемент". Потом он упоминает, что не понимает что такое регулярный язык. Странно все это...
Насчет лексем (tokens) — действительно странно для человека, создающего языки и компиляторы. Но это всего лишь вопрос терминов.
Регулярность языка программирования: вот этого и я тоже не понимаю. В математическом смысле "регулярность" — это прибл. правильность. Правильный язык программирования? Вы знаете такой язык?
Проще говорить, например, о естественности языков программирования, да и языков вообще. Надо полагать эсперанто и подбные ему создавались как "регулярные" языки, однако не прижились именно ввиду своей неестественности. Это не означает, что "придуманный" язык не может стать естественным для человека, но такой язык еще не создан.
Пол Грэм по сути хочет подвести нас к мысли, что естественность есть краткость. По крайней мере так я его понимаю. Но это спорное утверждение, чего и сам автор не отрицает. Это всего лишь гипотеза стоящая того, чтобы задуматься над ней.
Но такая сверхчувствительность обернется тем, что неуклюжие языки станут для вас невыносимыми. Я нахожу программирование на языках, которые не имеют макросов, невыносимо ограничивающим, так же как если бы кто-то привыкший к динамической типизации посчитал бы невыносимо ограничивающим возврат в языки, где следует описывать типы для каждой объявляемой переменной и невозможно объявить список, состоящий из элементов разных типов.
Здесь надо вспомнить, что Грэм — поклонник языка Lisp, и под словом "макросы" он подразумевает Lisp-макросы, а не макросы C.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Cron Tab, Вы писали:
CT>Регулярность языка программирования: вот этого и я тоже не понимаю. В математическом смысле "регулярность" — это прибл. правильность. Правильный язык программирования? Вы знаете такой язык?
Регулярный язык — это язык порождаемый регулярной грамматикой.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Регулярный язык — это язык порождаемый регулярной грамматикой.
Здесь проблема перевода. "Regular language" — необязательно "регулярный язык".
Здравствуйте, Трурль, Вы писали:
Т>Одна такая вакуумная лошадка принесла авторам $40M.
Особенно вот это:
Следуя парадоксу Блаба, нельзя доверять мнению других: другие программисты довольны тем языком, который используют, потому что этот язык определяет способ их программистского мышления.
Здравствуйте, Дарней, Вы писали:
Д> Д>Особенно вот это: Д>
Д> Следуя парадоксу Блаба, нельзя доверять мнению других: другие программисты довольны тем языком, который используют, потому что этот язык определяет способ их программистского мышления.
Да. Цитата в точку. Я бы дополнил бы эти слова еще тем, что большинство людей противятся новооведениям.
Видимо поэтому на рэнок вылезает только то, что хорошо пропихивается.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Дарней, Вы писали:
Д>>А кто-нибудь в курсе, что такое "лексическое замыкание"? (lexical closure) Т>То же самое, что "лямбда-выражение".
А почему "лексикал"?
ЗЫ
Замыкание — чертовски не подходящий перевод для closure.
Мне кажется, что именно некудышные названия затрудняют понимание этой простой идеи. Безымянные функции было бы куда более понятно.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
