Comments 14
Тема важная но писал либо дилетант либо нейронка. В целом, много переизобретённых терминов, но фактические ошибки указывают скорее на нейронку
Так в 1979 язык Си был дополнен классами.
Чем чем? Структуры (не классы) появились раньше, а c++ - это другой язык и появился позже.
В 1994 году появился Python, в котором были реализованы анонимные функции.
В 1991-ом.
Так открылась эра функционального программирования в языках общего назначения (анонимные функции были добавлены в C# в 2007, а в Java в 2014).
Ну это положим, расхожее заблуждение что анонимные функции немедленно превращают любой язык в функциональный.
Аспектно-ориентированное программирование появилось в Python в 2008 вместе с языковой конструкцией декоратор.
PEP-318 принят в 2003-2004.
Я правильно понимаю, что в статье проблемы только с датами? Все остальное по делу?
Спасибо за поправки к датам. Я торопился и искал их в гугл. Возможно, он мне неверно даты посоветовал. В 1979 началась разработка «C with Classes» Бьярном Страуструпом. В 1983 язык получает название С++. Что касается Си и С++. Структуры Си - это уже начало объектного-ориентированного программирования, но изначально наследования между структурами не было. Так что это ООП в урезанном виде. Добавление в Си классов порождает новый язык - С++. Считать ли его совсем новым? Знаю людей, которые писали код Си, но на С++.
Статья посвящена мультипарадигменным языкам, а конкретно - пайтону. Возможно, вы поборник чистых функциональных языков, например, Lisp. С этой точки зрения, анонимные функции не делают язык функциональным. Но ведь отсутствие анонимных функций тем более свидетельствует о том, что язык не функциональный. Так что анонимные функции - это движение в сторону функциональности.
Тема статьи - декларативное программирование. Какой язык считать функциональным, какой - нет - вопрос философский. И это не является важным в рамках этой статьи. Я упоминаю функциональное программирование, потому что в самом общем смысле оно - тоже декларативное. Ну и на нем строится вся "внутренняя кухня" - техническая реализация библиотек с декларативными элементами.
Ну ладно, положим.
Про парадигмы. Я вижу, что вы делаете свой язык, но самостоятельно - выдают "три уровня интеграции" (хотя термины устоялись - внешний и внутренний dsl) и другие похожие моменты. А тема богатая, интересная, и сложная конечно. В отрыве от сообщества или не прочитав хотя бы пары книг (база - SICP, конечно же) можно нагородить всякого разного.
Я подумаю, как можно поменять терминологию, прочитав SICP. Это, действительно, классика. Там правда LISP. Я его когда-то немного преподавал и сейчас, по правде говоря, вспоминаю как страшный сон. Например, карринг на Lisp и карринг на C# или Python для студенческого восприятия - это совершенно разные вещи. Насчет терминологии - это вообще большая проблема. Что, например, выбрать в качестве терминологии - кортежи или факты? В одном случае обидятся поклонники Prolog, в другом - SQL. А если эти языки назвать dsl, то обидятся и те и другие. Причем обзовут меня дилетантом, сказав, что их языки полные по Тьюрингу, и на них можно написать любой алгоритм. Из терминологических неточностей даже в самом пайтоне, например, большая проблема, как перевести list comprehension. Генератор списков? А если генерируется множество или словарь? И как тогда различить с конструкцией yield? В общем, с единой терминологией - проблема. Но со своей стороны, обязуюсь не порождать дополнительную путаницу.
В целом согласен, по отдельным терминам хочу заметить:
карринг на Lisp и карринг на C# или Python
Честно говоря, тоже на Лиспе плотно не работал, зато много работал на Хаскелле. Мне кажется, вы путаете карринг и частичное применение функции. Второе - забава для узкого класса задач, первое - одна из основ функциональных языков, упрощает компиляторы и естественно ложится в парадигму. Карринг в Питоне можно сделать, но как библиотеку с неясным назначением.
факты
Забавно, поизучаю Пролог на досуге.
пайтоне, например, большая проблема, как перевести list comprehension
Я хоть и сам питонист, но мнение питонщиков тут неважно, потому что это урезанная реализация monad comprehension, что вы справедливо сами отметили. В Хаскелле и функционал богаче и для любой монады работае (и мб ограниченно для аппликаторов, через ApplicativeDo?). Списки тут частный случай.
Представьте, я замучился студентам объяснять разницу между каррингом и частичным применением функции! Когда-то делал её на С# - там разница в коде - буквально в пару пустых скобок. Кстати, автор книги "C# для профессионалов", кажется, не делает разницы между этими приемами программирования. На Python теперь рассказываю о частичном применении функции и карринге на разных лекциях.
Я новичок, поэтому не судите строго, но лично мне кажется, что данный код:
print(sum(t for t in Table if t>50))
Не декларативный. Ну, просто для меня, он выглядит как запись всё той же функции с циклом и условием (if-else) просто в одну строку.
Можете объяснить, чем он стал декларативным?
Не стал, конечно же. Немного питоновского синтаксического сахара, чтобы записать цикл по коллекции и запись в другую коллекцию в 1 строчку.
вполне себе декларативный стиль, или может вы считаете что SELECT * FROM users WHERE age > 25 это тоже императивный подход?
я конечно могу где-то ошибаться в своих суждениях, но генераторы в python ближе к чему-то функциональному, а оно в свою очередь подмножество чего-то декларативного
если вы все же настаиваете на своем мнении, я бы попросил вас привести хотя бы как должна выглядеть данная строчка в декларативном стиле по вашему мнению
t for t in Table if t>50for t in Table:
if t> 50:
some_list.append(t)
Кмк, та же конструкция, с явно прописанным циклом и условием. Но записанная, благодаря сахару, в 1 строчку, и, наверное, оптимизированная внутри.
Так и Си можно в декларативный записать - никто не знает точно, в какие именно инструкции будет скомпилирован код.
В том-то и дело, что это - декларативное программирование! Когда я познакомился с этой языковой конструкцией, я тоже думал, что это просто синтаксический сахар - короткая удобная запись в одну строчку. И так её почти все и воспринимают - это совершенно нормально. Очень уж она не похожа на SQL. Но сделаем мысленную замену на аналогичные операторы: if заменим на where, in на from, а for на select - и вы получите код, очень похожий на SQL
На тему известных декларативных языков ещё добавлю XPath и RegExp, хоть к классу самостоятельных ЯП и не относятся.
Эх, Пролог - удивительный язык... Совсем не сложный. По сути вся программа состоит из предикатов, то есть, определения фактов и их связей между собой. Сложно - это мозг перестроить с поиска итерационных алгоритмов на поиск эффективных эвристик.
А тестирование и отладка программы на прологе - как отдельный вид искусства...
Декларативное программирование на Python