По-моему, главная проблема МЦСТ в том, что она не понимает, как правильно презентовать свои процессоры рынку. Почему-то всё время сравнивает с Intel и AMD, говоря при этом, что у монструозных западных компаний намного больше денег на разработку, производство и т.д. В этом главная ошибка, мне кажется, не надо пытаться бросать вызов существующим решениям сразу во всём, особенно в том, в чём они заведомо выиграют - в общих задачах со сложной логикой и тем более в попытках запустить программы с трансляцией в x86, показать выполнение Windows и прочее - не нужно этого делать. Автор данного повествования тоже зря ограничился "для бенчмарков это запрещено делать" - ничего не запрещено, такая честность никого не интересует, и вообще честность - это бред, в рынке надо полностью раскручивать все преимущества, даже полностью спекулятивные и фиктивные. Наоборот, надо брать особенности данной архитектуры и читить так, как недоступно для других архитектур, перекомпилировать с флагами и оптимизировать, по ситуации представляя данные процессоры не как общего серверного назначения, а специалированного. Даже статья получилась бы намного интереснее, если бы удалось полностью раскрыть именно особенности этой архитектуры, и если бы при этом эльбрусы ушли в отрыв.
Сейчас МЦСТ ещё не вклинилась в рынок, живёт за счёт господдержки, но, лично я бы не стал рассчитывать в российских реалиях на это в долгосрочной перспективе. Пусть сейчас есть господдержка, но её надо использовать, чтобы постепенно найти себя в рынке.
Ну хорошо, ладно) Трудно, правда, представить, но, наверное, это действительно разумно в некоторых случаях.
Я представляю так, сидят на хорошей зарплате штат scala-программистов, тут приходит директор и говорит: "Так, есть идея, но на чём же будем писать... хм... а давайте напишем пробный проект на Python..." ))
Ребят, вы спорите ни о чём, нет разницы, в Java или не в Java. Во всех языках для лямбды/замыкания создаётся объект, просто в Java до версии 8 он создавался явно, чтобы эмулировать callback, вы так же могли его кэшировать в переменную, чтобы он не создавался каждый раз заново, где это колбэк нужен, а с Java 8, Scala, Kotlin, C#, да и вообще во всех языках, где есть объекты, для этого есть краткие синтаксические конструкции, но создают они концептуально то же самое, что и в старой яве. Даже в современном C++ лямбды [] () {} неявно создают классы с перегруженным operator()
С пунктом про время компиляции всё-таки соглашусь с @Yuribtr , в остальном с вашими доводами согласен. Сам пишу на Scala, реально долго идёт компиляция. На С++ ситуация со временем компиляции тоже не лучше. На счёт сильной типизации в Python тоже не совсем понятно, как это поможет, ну да, там не сложишь строку с числом как в JS, но вылезет-то это всё равно в рантайме.
Не понятен момент, когда говорят, что Python используется для прототипирования, что это значит? Писать какой-то проект в упрощенном виде на Python, потратить время, потом удалить его к фигам и начать писать уже на нормальном языке заново? Вообще не вижу смысла, всегда пишу прототип, проясняю концептуальные моменты на том языке, на котором и будет создаваться проект, то что можно использовать - не переписываю.
Пайтону действительно не хватает функционального программирования, даже его там почти нет, почти всюду используются мутабельные данные. Мутабельные данные с распараллеливанием ещё с динамической типизацией, ещё и без компиляции, всё в рантайме - действительно, что может лучше для хорошего бэкэнда. В приведённом фрагменте вообще не стоило бы строить логику на бросании исключения как, например, в Scala + cats
val allTheSame = ids.zip(ids.tail).forall { case (previous, current) =>
previous == current
}
val result = Either.cond(allTheSame, "All right", new IllegalStateException("All ids must be the same"))
Какие трогательные отношения у вас с Пайтоном, что сами вызывают умиление. В ООП языках, и вашем любимом Python в том числе, создаётся объект-обёртка вокруг любой функции, в том числе и лямбды. То есть lambda в Python так же создаёт объект с методом `__call__` . А в C++ всюду, в том числе и в подключаемых библиотеках используется обобщённое определение функции - нечто такое, что можно вызывать через круглый скобки () - это может быть хоть обычная функция, хоть указатель на функцию, хоть объект с определённым методом operator(). И это нормально, больших накладных расходов с объектами-функциями нет, к тому же объекты позволяют захватывать значения переменных из внешнего окружения, превращая функцию в замыкание. Я писал здесь статью об этом в далёком 2012м (https://habr.com/ru/post/149882/), правда я там перемудрил малость, но не важно.
MVP - веб приложение? Было бы здорово, если бы кто-нибудь более развернуто поднял этот вопрос на Хабре, но вот вкратце моё видение. Где нужен Python? В мобильной разработке он не используется, для десктопа тоже почти, на бэкэнде только и для аналитики и обучения сетей (тоже в основном для бэкэнда)? Если для бэкэнда, я даже не беру производительность в расчёт, странно писать на скриптовом динамически-типизируемом языке для серьезного бэкэнда, к тому же где фреймворков с поддержкой асинхронного программирования раз два и обчёлся для этого языка, и вообще асинхронное программирование - это не стезя пайтона, это вообще не его идея, и даже её реализация далеко не влучшем виде. По поводу MVP, MVC, MVVM и прочее на бэкэнде, тенденция идёт к созданию одностраничных web-приложений react, angular, vue, которые сами поддерживают эти архитектуры, двойной MVC на бэкэнде и фронтенде - тоже та ещё идея. По сути на бэкэнде нужен мощный высокопроизводительный высокораспараллеленный надёжный API, для которого Python крайне слабый выбор в сравнении с тем что вообще есть.
По поводу обучения сетей, сложной аналитики, да - для Python написаны кучи готовых решений, но они все на C++, потому что на самом пайтоне писать сложные вычиселения - идея та ещё из-за его низкой производительности.
Если брать скриптовую автоматизацию на сервере, то для меня это Perl, который, на мой взгляд, отличная более мощная замена Bash, и который кстати идеологически близок к Bash, так что продолжаешь писать в одном ключе. Я одновременно использую и Bash, и Perl, больше Bash.
Если всё же захочешь нечто скриптовое и динамически-типизиуремое на сервере, то лучше JS/CoffeeScript/Node вряд ли что-то найдётся, широчашая экосистема, отличные сборщики и, главное, асинхронное програмиирование на высочайшем уровне. И, кстати, JS в Node так же динамически-типизируемый, как правильно вы сказали, слабо-типизируемый, что ещё хуже влияет на производительность, но как тогда объяснить, что при этом JS в сотню раз производительнее Python?
В общем для меня Python главное разочарование за всё время. То что он популярен, ну что ж, у кого-то будет преимущество, когда дело касается конкурентных работ.
Я изучал и использовал много языков, но более примечателен один из них, который из самого любимого превратился в самый нелюбимый. Это Python. Раньше меня просто потрясало как гибко в этом языке можно менять объекты, добавлять/удалять методы, менять поведение через дескрипторы и декораторы, а уж что можно было вытворять через метаклассы - вообще молчу. В общем абсолютно потрясающая гибкость, можно было взять пустой объект и создать из него целый мир, чистое творчество, я просто обожал Python.
Но сложилось всё так, что стал работать в командах где пайтон не жаловали, посмеивались над ним хлеще чем над пхп. Всё-таки статическая типизация - главный аргумент, это абсолютно необходимый инструмент, позволяющий сразу отлавливать большое количество багов. Сейчас не то что на бэкенде (где как раз и Python живёт), даже на фронтенде всё чаще используется TypeScript, добавляющий к JS типизацию. Сейчас для меня в пайтоне нет вообще никакого смысла, динамически-типизируемый, отстающий язык по внедрению асинхронных техник программирования, а если взять в расчёт, что это ещё один из самых тормозных языков в рантайме, даже новые версии PHP его уделывают в разы, то сейчас Python - это трэш-язык номер один. То что Python так популярен и используется многими разработчиками, меня радует - значит, у меня есть неплохие преимущества перед стартапами и командами, использующими его.
Линукс и есть линукс, после десятка лет его использования, по-моему, единственная заметная разница между дистрибутивами заключается в способе поиска и установки пакетов, то есть в пакетном менеджере. В остальном какой бы ни был дистрибутив, всё равно он существенно перенастраивается под себя и всегда приводится к более-менее одному и тому же виду, к которому привык.
В той статье, где программист не должен париться проблемами бизнеса, при голосовании автора полностью поддержали более 60% респондентов, а в это статье, главный тезис которой в общем-то противоположный, автора поддержали более 70%. Возникает вопрос, какова репрезентати́вность голосования и вообще что оно отражает. Возможные варианты:
— красноречие авторов склоняет читателей на свою сторону, хабралюди — это люди, в общем-то, с ещё несложившимися мировоззрениями, на их мнение можно легко повлиять, красноречиво выразив свою точку зрения;
— в целом голосовать склонны более те читатели, которые настроены позитивно к теме статьи, а те, что отрицательно, — скорее воздержатся от голосования.
Как по вашему мнению, для чего проводится голосование и что оно отражает, есть ли в нём какие-то более интересные факты, чем те что на поверхности?
Главная идея статьи о том, что эксперимент стоит выше всего теоретизирования, мне лично не нравится. Я в данном вопросе встал бы на сторону Пуассона. Неужели эксперименты в физике всегда были решающим фактором, неужели физика как и любая другая наука не была озабочена тем, чтобы совершенствоать свою доказательную базу, разве могут просто результаты экспериментов без их глубокого осмысления и изложения в соответствии с прежними положениями теории составить хоть сколько-нибудь серъёзные знания? Пуассон в попытках опровергнуть умозаключения Френеля не только не сделал «величайшую ошибку», но и внёс не менее значимый вклад в науку, чем те, кто в итоге поставили эксперимент. Вообще метод доказательства от противного, когда вместо того, чтобы явно напрямую доказать что-либо, доказывает что-то иное, чем то, что в предположении проверяется, то есть при допущении истинности главного объекта доказательства приводит к ложности каких-то других положений, из чего делается вывод, что главный объект доказательства ложный. Многие великие умы искали в этом методе некий подвох, и почему на этот метод вообще можно так наивно полагаться. Поэтому оттачивание теоретизирования является нисколько не менее значимым процессом в физике, чем постановка экспериментов.
Недостаточно следовать только новым веяниям, улавливать модные направления, чтобы быть в тренде и оставаться гуру. Движение вглубь зачастую предполагает и освоение фундаментальных технологий. Мне не так давно достался один ios-проект, где значительная часть написана на C++. Но больше всего что меня сначала смутило, что помимо свойственных ios техник многопоточности также использовался API POSIX Threads, который я изучал еще лет пятнадцать назад и который давно считал безнадежно устаревшим в наши-то времена thread-пулов, экзекьюторов, фьюч, akka и других новомодных штуковин. Но в процессе поддержки этого кода оказалось, что в некоторых местах гораздо удобнее использовать C++ классы-обертки над примитивами pthreads, чем тащить логику в objective-c и использвать там мощные GCD и Operations. Вопрос, как мне кажется, не в том, модная ниша или нет, а насколько ты профессионал в своей области.
Долгое время был уверен во всемогуществе таких именитых программ как Matlab, Mathematica, Maple… до тех пор пока не столкнулся с более-менее серъёзными вещами. Оказалось, например, Matlab, впрочем как и другие известные пакеты, не ахти как поддерживает тензоры, и решение задач математической физики за некторыми исключениями, касающихся некоторых простых случаев, крайне затруднительно в нём, в реальности возникает необходимость писать в нём реализацию численных схем с почти нуля, что само по себе устраняет преимущество его использования как набора эффективных готовых решений. Правда, в самых последних версиях Matlab данные расчётные инструменты были дополнены, но тем не менее, впечатление о Matlab и других гигантах индустрии как о всемогущих универсальных математических пакетах на все случаи жизни было испорчено. В итоге пришлось смотреть в сторону более специфических программ таких как ANSYS, COMSOL и прочих пакетов для решения задач математической физики. Но как и прежде остановился на открытом и опенсорсном варианте в виде OpenFOAM, потому как считаю, что использование открытых программ не только имеет те преимущества, которые описаны в статье, в частности, то, что открытый код всегда можно перепроверить и тем самым обосновать результат, получаемый с помощью этого открытого ПО, но и позволяет лучше разобраться в самих применяемых математических методах. Что касается Octave, хороший пакет, не то что для серъёзных научных работ, но, как было сказано, для категории студент+ прекрасная вещь. Много его использовал, правда, некоторых нужных мне в свое время возможностей, что были в Matlab по обработке сигналов в нем не оказалось.
Теперь мы полностью решили загадку эффективности математики.
Отлично, лихо вы справились! Помню, несколько лет назад я тоже в основном ради удовлетворения личных интересов задался этим вопросом, правда, чтение многочисленной многоуважаемой и потрясающе интересной литературы так и не дало мне столь категоричного ответа, который вы получили уже на второй страницы (стоило только немного пролистнуть ниже от начала) вашей статьи. Не вдаваясь в премудрости философии и методологии науки, лично для меня этот вопрос остался на следующем уровне. Математика, в первую очередь, это язык изложения описываемых положений, вещей. В связи с этим эффективность математики, по моему настоящему пониманию, может изучаться методами филологии и лингвистики не в меньшей степени результативности, чем в её связи с физикой и другими естественными науками. При этом, заметьте, я математику вообще вынес за рамки естественных наук, потому как считаю, что математика настолько же стоит за рамками, но в то же время настолько же близка как к естественным, так и к гуманитарным наукам. Математика — это всего лишь язык, и заметьте, та же физика помимо математики с требуемой точностью описывается и естественным языком, который мы используем для общения. Почему эффективна математика, по моему скромному мнению, это такой же вопрос, как и почему эффективен язык (русский, английский), почему, если дать описание, инструкцию, сообщение на естественном разговорном языке, подобные выражения мысли оказываются «удачно» связанными с действительностью… если не вводить, конечно, поправки на адекватность индивидуума, их произнесшего. Математика развивается исходя из своих собственных возможностей, правил. И сложные выводы, теоремы получены математиками не в связи с осмыслением их применимости к реальному миру, а исходя из возможностей использования самого языка математики, включая логику (правила вывода) построения новых объектов, исходные положения и т.д. Если исходные положения с достаточной очевидностью накладываются на реальность (прямая, точка, число и пр.), то, следует ожидать, что и результаты сложных выводов, полученные с нашим пониманием очевидности (логика), также окажутся весьма эффективными к применению к реальности. При этом, заметьте, нерешённые проблемы математики не доказывают нелегкую судьбу нашего с вами бытия, реальности, Вселенной и т.д., они лишь показывают ограниченность математики как человеческого (используемого людьми) языка и всего лишь навсего. Теорема Гёделя о неполноте ни коем образом не говорит, что мы оказались в ущербной Вселенной, где могут происходить не поддающиеся никакой логике казусы, она лишь показывает что у используемой в математики логики, по сути дела языка, есть свои ограничения, которые на данном этапе развития этого языка ещё не разрешены. Ещё раз повторюсь, изложенное — просто мое нынешние понимание, которое я счёл приемлемым для своего внутреннего использования, для своего мировоззрения, так сказать, которое не претендует на какой-либо научный статус. Вообще очень рекомендую литературу по данной тематике, которая доставила мне массу удовольствия:
Владимир Успенский. Апология математики. Р. Курант, Г. Роббинс. Что такое математика? Клайн М. Математика. Утрата определённости. Клайн М. Математика. Поиск истины.
Прошу простить меня за не по правилам оформленный библиографический список. Вообще очень люблю книги Рихарда Куранта, любой его учебник, любой труд по любому разделу математики изложен настолько живо, интересно, что погружает не только в суть означенной темы, но и почему математика и здесь эффективна, рекомендую )
Кстати, хотел высказать ещё одну точку зрения в подкрепление основной мысли своей статьи. По C# я привёл достаточно примеров, но мало рассказал о Java, а ведь как раз Java развивается совершенно иначе, нежели C#. Многие говорили, и на хабре в частности, что C# развивается быстрее, чем Java. Но на мой взгляд, C# обрастает разного рода «хаками», в то время как в Java объектная модель остаётся более консервативной. Можно ли сказать, что Java от этого в убытке? Не думаю, да и внешне это никак не видно, рейтинг по версии TIOBE — второе место. Казалось бы, в Java синтаксис в разы проще, чем в C#, но язык от этого не слабее. Да, в Java нет таких сомнительных хаков, в частности над объектной моделью, как типы-значения (исключая примитивы, которые полностью за рамками объектной модели), структуры, невиртуальные функции. Да и от того, что в Java нет замыканий и генераторов, проигрыша от этого тоже нет. В Java есть нестатические внутренние классы, в том числе и анонимные, а это стоит больше, чем разного рода замыкания и больше соответствует «нормальной» объектной модели. В Java перечисления — действительно объекты, которые могут удовлетворять заданным интерфейсам, чего не скажешь о перечислениях в C#. А то, что в Java 7 всё же не включили замыкания — не велика потеря. Так что меня полностью устраивает, как развивается Java, и ей, в частности, были навеяны идеи, которые я изложил в статье.
Логично пишите, я могу согласиться с вами и по части того, что сравнивать prototype-based и class-based подходы не корректно, и по части того, что ничто не застрахует программистов от «кривых рук». Даже, чего скрывать, я полностью с вами согласен. Но всё же есть «но». Я сам уже вижу, что недостаточно чётко раскрыл главную тему статьи. Моя цель заключалась вовсе не в том, чтобы вызвать сравнение прототипо-ориентированных языков с класс-ориентированными, и даже не в том, чтобы задеть за живое функциональщиков. Да, я имею представление о функциональном программировании, сам писал реальные приложения на Lisp и знаю, что ФП мощная вещь и не нуждается в объектной подстилке.
А в статье главное, что я хотел подчеркнуть, это то что многие возможности современных языков программирования, в том числе замыкания, управляемый полиморфизм (как в C#), и даже генераторы (которые не были рассмотрены в статье, но упомянуты позже в комментарии) не дают столь больших возможностей, как многие это считают. Я хотел рассмотреть язык с минимальной сложностью синтаксиса, но состояние реального положения дел таково, что минимальной сложностью обладает прототипо-ориентированный язык. Поэтому я и заострил внимание на этом подходе. Замыкания, карринг, обёртки функций в чистом виде нужны именно в ФП-языках и именно так, как вы описали в первом комментарии. Но в ООП-языках так или иначе они имеют меньше возможностей, чем вариант на базе явного решения в виде явного создания объекта. В ФП языках (это одна из характерных черт) нет состояния, все функции чисты в том смысле, что извне они обладают ровно пустым состоянием, то есть преобразуют «вход» в «выход» без памяти о том, что было сделано в прежних вызовах. Но в этом и сила ФП-программирования. Сила же ООП-программирования как раз в «программирование с состояниями». Теперь я хочу привести даже не моё мнение, а чисто факты:
1. Вынесение логики в виде замыкания в ООП-языках преобразуется в объект строго определённого типа, который может замыкаться на внешний контекст и хранить состояние только во внешним контексте, но в собственном.
2. Вынесение логики в явно определённый объект позволяет этому объекту сохранять состояние не во внешнем контексте, на который он замыкается, а внутри себя.
3. Объект, полученный при явном определении (п. 2), может иметь любой тип, наследовать любой класс, реализовывать любые интерфейсы (протоколы, трейты). В частном случае, он может нести ровно ту же самую нагрузку, что и неявно созданный с помощью синтаксического замыкания объект, описанный в п. 1.
4. Из пп 1-3 следует, что функциональность явно определённого объекта больше либо равна функциональности объекта, созданного через замыкание.
Кстати, в подтверждение этого заключения я в статье и привёл два примера на C#.
Почти то же самое можно сказать и о генераторах. А чтобы использовать решения на базе явного определения объектов достаточно языка с очень простым синтаксисом как, например, Smalltalk. Я не говорю, что замыкания на уровне синтаксиса — это плохо, наоборот они очень даже хорошо смотрятся и, главное, нужно писать меньше. Я хотел сказать, что они более ограничены. Вообще, я хотел сказать, что все хаки более ограничены, чем явное определение объектов.
Вообще, я уже почувствовал, что написание общетеоретических статей — совершенно проигрышное дело. Спасибо, что не забанили статью. В будущем буду писать статьи только с конкретикой.
1. Я знаком с C++ как и ещё полутра десяткой языков и с его невиртуальными методами тоже. Я о нём просто не написал.
2. В моём «сферическом языке» Class.new() выполняется для создания новых объектов и Class — это объект. Так есть, например, в Smalltalk, где класс Object содержит всё необходимое, чтобы делать новые объекты, но сам он является объектом. В Smalltalk, как и в Self, нет синтаксической конструкции для наследования классов — подкласс создаётся путём отправки сообщения subclass классу-объекту, от которого производится наследование.
3. Мой язык не такой уж и «сферический», я описал его, используя, в частности, знание Smalltalk и Self, где нет лексических конструкций для определения наследования, инкапсуляции, конструкторов и классов.
4. В таких языках как C#, Python, Smalltalk замыкание не что иное как объект (замыкание преобразуется в настоящий объект компилятором/интерпретатором).
5. В некоторых ранних версиях Objective-C представлял собой препроцессор над C++, поэтому и был чистым расширением не C, а C++. Впрочем и сейчас есть сборки, позволяющие использовать C++ в Objective-С, например, вот и вот.
6. Я делаю вывод, что чистая объектная модель не приводит к плохо структурированному коду, что видно при внимательном прочтении.
7. Я знаком с yield как в Python, так и в C#. Например, в C# конструкция yield преобразуется не во что иное как в объект IEnumerable. То, как это происходит, хорошо описано здесь.
По-моему, главная проблема МЦСТ в том, что она не понимает, как правильно презентовать свои процессоры рынку. Почему-то всё время сравнивает с Intel и AMD, говоря при этом, что у монструозных западных компаний намного больше денег на разработку, производство и т.д. В этом главная ошибка, мне кажется, не надо пытаться бросать вызов существующим решениям сразу во всём, особенно в том, в чём они заведомо выиграют - в общих задачах со сложной логикой и тем более в попытках запустить программы с трансляцией в x86, показать выполнение Windows и прочее - не нужно этого делать. Автор данного повествования тоже зря ограничился "для бенчмарков это запрещено делать" - ничего не запрещено, такая честность никого не интересует, и вообще честность - это бред, в рынке надо полностью раскручивать все преимущества, даже полностью спекулятивные и фиктивные. Наоборот, надо брать особенности данной архитектуры и читить так, как недоступно для других архитектур, перекомпилировать с флагами и оптимизировать, по ситуации представляя данные процессоры не как общего серверного назначения, а специалированного. Даже статья получилась бы намного интереснее, если бы удалось полностью раскрыть именно особенности этой архитектуры, и если бы при этом эльбрусы ушли в отрыв.
Сейчас МЦСТ ещё не вклинилась в рынок, живёт за счёт господдержки, но, лично я бы не стал рассчитывать в российских реалиях на это в долгосрочной перспективе. Пусть сейчас есть господдержка, но её надо использовать, чтобы постепенно найти себя в рынке.
Ну хорошо, ладно) Трудно, правда, представить, но, наверное, это действительно разумно в некоторых случаях.
Я представляю так, сидят на хорошей зарплате штат scala-программистов, тут приходит директор и говорит: "Так, есть идея, но на чём же будем писать... хм... а давайте напишем пробный проект на Python..." ))
Ребят, вы спорите ни о чём, нет разницы, в Java или не в Java. Во всех языках для лямбды/замыкания создаётся объект, просто в Java до версии 8 он создавался явно, чтобы эмулировать callback, вы так же могли его кэшировать в переменную, чтобы он не создавался каждый раз заново, где это колбэк нужен, а с Java 8, Scala, Kotlin, C#, да и вообще во всех языках, где есть объекты, для этого есть краткие синтаксические конструкции, но создают они концептуально то же самое, что и в старой яве. Даже в современном C++ лямбды [] () {} неявно создают классы с перегруженным operator()
С пунктом про время компиляции всё-таки соглашусь с @Yuribtr , в остальном с вашими доводами согласен. Сам пишу на Scala, реально долго идёт компиляция. На С++ ситуация со временем компиляции тоже не лучше. На счёт сильной типизации в Python тоже не совсем понятно, как это поможет, ну да, там не сложишь строку с числом как в JS, но вылезет-то это всё равно в рантайме.
Не понятен момент, когда говорят, что Python используется для прототипирования, что это значит? Писать какой-то проект в упрощенном виде на Python, потратить время, потом удалить его к фигам и начать писать уже на нормальном языке заново? Вообще не вижу смысла, всегда пишу прототип, проясняю концептуальные моменты на том языке, на котором и будет создаваться проект, то что можно использовать - не переписываю.
Пайтону действительно не хватает функционального программирования, даже его там почти нет, почти всюду используются мутабельные данные. Мутабельные данные с распараллеливанием ещё с динамической типизацией, ещё и без компиляции, всё в рантайме - действительно, что может лучше для хорошего бэкэнда. В приведённом фрагменте вообще не стоило бы строить логику на бросании исключения как, например, в Scala + cats
Какие трогательные отношения у вас с Пайтоном, что сами вызывают умиление. В ООП языках, и вашем любимом Python в том числе, создаётся объект-обёртка вокруг любой функции, в том числе и лямбды. То есть lambda в Python так же создаёт объект с методом `__call__` . А в C++ всюду, в том числе и в подключаемых библиотеках используется обобщённое определение функции - нечто такое, что можно вызывать через круглый скобки () - это может быть хоть обычная функция, хоть указатель на функцию, хоть объект с определённым методом operator(). И это нормально, больших накладных расходов с объектами-функциями нет, к тому же объекты позволяют захватывать значения переменных из внешнего окружения, превращая функцию в замыкание. Я писал здесь статью об этом в далёком 2012м (https://habr.com/ru/post/149882/), правда я там перемудрил малость, но не важно.
MVP - веб приложение? Было бы здорово, если бы кто-нибудь более развернуто поднял этот вопрос на Хабре, но вот вкратце моё видение. Где нужен Python? В мобильной разработке он не используется, для десктопа тоже почти, на бэкэнде только и для аналитики и обучения сетей (тоже в основном для бэкэнда)? Если для бэкэнда, я даже не беру производительность в расчёт, странно писать на скриптовом динамически-типизируемом языке для серьезного бэкэнда, к тому же где фреймворков с поддержкой асинхронного программирования раз два и обчёлся для этого языка, и вообще асинхронное программирование - это не стезя пайтона, это вообще не его идея, и даже её реализация далеко не влучшем виде. По поводу MVP, MVC, MVVM и прочее на бэкэнде, тенденция идёт к созданию одностраничных web-приложений react, angular, vue, которые сами поддерживают эти архитектуры, двойной MVC на бэкэнде и фронтенде - тоже та ещё идея. По сути на бэкэнде нужен мощный высокопроизводительный высокораспараллеленный надёжный API, для которого Python крайне слабый выбор в сравнении с тем что вообще есть.
По поводу обучения сетей, сложной аналитики, да - для Python написаны кучи готовых решений, но они все на C++, потому что на самом пайтоне писать сложные вычиселения - идея та ещё из-за его низкой производительности.
Если брать скриптовую автоматизацию на сервере, то для меня это Perl, который, на мой взгляд, отличная более мощная замена Bash, и который кстати идеологически близок к Bash, так что продолжаешь писать в одном ключе. Я одновременно использую и Bash, и Perl, больше Bash.
Если всё же захочешь нечто скриптовое и динамически-типизиуремое на сервере, то лучше JS/CoffeeScript/Node вряд ли что-то найдётся, широчашая экосистема, отличные сборщики и, главное, асинхронное програмиирование на высочайшем уровне. И, кстати, JS в Node так же динамически-типизируемый, как правильно вы сказали, слабо-типизируемый, что ещё хуже влияет на производительность, но как тогда объяснить, что при этом JS в сотню раз производительнее Python?
В общем для меня Python главное разочарование за всё время. То что он популярен, ну что ж, у кого-то будет преимущество, когда дело касается конкурентных работ.
Я изучал и использовал много языков, но более примечателен один из них, который из самого любимого превратился в самый нелюбимый. Это Python. Раньше меня просто потрясало как гибко в этом языке можно менять объекты, добавлять/удалять методы, менять поведение через дескрипторы и декораторы, а уж что можно было вытворять через метаклассы - вообще молчу. В общем абсолютно потрясающая гибкость, можно было взять пустой объект и создать из него целый мир, чистое творчество, я просто обожал Python.
Но сложилось всё так, что стал работать в командах где пайтон не жаловали, посмеивались над ним хлеще чем над пхп. Всё-таки статическая типизация - главный аргумент, это абсолютно необходимый инструмент, позволяющий сразу отлавливать большое количество багов. Сейчас не то что на бэкенде (где как раз и Python живёт), даже на фронтенде всё чаще используется TypeScript, добавляющий к JS типизацию. Сейчас для меня в пайтоне нет вообще никакого смысла, динамически-типизируемый, отстающий язык по внедрению асинхронных техник программирования, а если взять в расчёт, что это ещё один из самых тормозных языков в рантайме, даже новые версии PHP его уделывают в разы, то сейчас Python - это трэш-язык номер один. То что Python так популярен и используется многими разработчиками, меня радует - значит, у меня есть неплохие преимущества перед стартапами и командами, использующими его.
Линукс и есть линукс, после десятка лет его использования, по-моему, единственная заметная разница между дистрибутивами заключается в способе поиска и установки пакетов, то есть в пакетном менеджере. В остальном какой бы ни был дистрибутив, всё равно он существенно перенастраивается под себя и всегда приводится к более-менее одному и тому же виду, к которому привык.
— красноречие авторов склоняет читателей на свою сторону, хабралюди — это люди, в общем-то, с ещё несложившимися мировоззрениями, на их мнение можно легко повлиять, красноречиво выразив свою точку зрения;
— в целом голосовать склонны более те читатели, которые настроены позитивно к теме статьи, а те, что отрицательно, — скорее воздержатся от голосования.
Как по вашему мнению, для чего проводится голосование и что оно отражает, есть ли в нём какие-то более интересные факты, чем те что на поверхности?
Отлично, лихо вы справились! Помню, несколько лет назад я тоже в основном ради удовлетворения личных интересов задался этим вопросом, правда, чтение многочисленной многоуважаемой и потрясающе интересной литературы так и не дало мне столь категоричного ответа, который вы получили уже на второй страницы (стоило только немного пролистнуть ниже от начала) вашей статьи. Не вдаваясь в премудрости философии и методологии науки, лично для меня этот вопрос остался на следующем уровне. Математика, в первую очередь, это язык изложения описываемых положений, вещей. В связи с этим эффективность математики, по моему настоящему пониманию, может изучаться методами филологии и лингвистики не в меньшей степени результативности, чем в её связи с физикой и другими естественными науками. При этом, заметьте, я математику вообще вынес за рамки естественных наук, потому как считаю, что математика настолько же стоит за рамками, но в то же время настолько же близка как к естественным, так и к гуманитарным наукам. Математика — это всего лишь язык, и заметьте, та же физика помимо математики с требуемой точностью описывается и естественным языком, который мы используем для общения. Почему эффективна математика, по моему скромному мнению, это такой же вопрос, как и почему эффективен язык (русский, английский), почему, если дать описание, инструкцию, сообщение на естественном разговорном языке, подобные выражения мысли оказываются «удачно» связанными с действительностью… если не вводить, конечно, поправки на адекватность индивидуума, их произнесшего. Математика развивается исходя из своих собственных возможностей, правил. И сложные выводы, теоремы получены математиками не в связи с осмыслением их применимости к реальному миру, а исходя из возможностей использования самого языка математики, включая логику (правила вывода) построения новых объектов, исходные положения и т.д. Если исходные положения с достаточной очевидностью накладываются на реальность (прямая, точка, число и пр.), то, следует ожидать, что и результаты сложных выводов, полученные с нашим пониманием очевидности (логика), также окажутся весьма эффективными к применению к реальности. При этом, заметьте, нерешённые проблемы математики не доказывают нелегкую судьбу нашего с вами бытия, реальности, Вселенной и т.д., они лишь показывают ограниченность математики как человеческого (используемого людьми) языка и всего лишь навсего. Теорема Гёделя о неполноте ни коем образом не говорит, что мы оказались в ущербной Вселенной, где могут происходить не поддающиеся никакой логике казусы, она лишь показывает что у используемой в математики логики, по сути дела языка, есть свои ограничения, которые на данном этапе развития этого языка ещё не разрешены. Ещё раз повторюсь, изложенное — просто мое нынешние понимание, которое я счёл приемлемым для своего внутреннего использования, для своего мировоззрения, так сказать, которое не претендует на какой-либо научный статус. Вообще очень рекомендую литературу по данной тематике, которая доставила мне массу удовольствия:
Владимир Успенский. Апология математики.
Р. Курант, Г. Роббинс. Что такое математика?
Клайн М. Математика. Утрата определённости.
Клайн М. Математика. Поиск истины.
Прошу простить меня за не по правилам оформленный библиографический список. Вообще очень люблю книги Рихарда Куранта, любой его учебник, любой труд по любому разделу математики изложен настолько живо, интересно, что погружает не только в суть означенной темы, но и почему математика и здесь эффективна, рекомендую )
нев собственном».А в статье главное, что я хотел подчеркнуть, это то что многие возможности современных языков программирования, в том числе замыкания, управляемый полиморфизм (как в C#), и даже генераторы (которые не были рассмотрены в статье, но упомянуты позже в комментарии) не дают столь больших возможностей, как многие это считают. Я хотел рассмотреть язык с минимальной сложностью синтаксиса, но состояние реального положения дел таково, что минимальной сложностью обладает прототипо-ориентированный язык. Поэтому я и заострил внимание на этом подходе. Замыкания, карринг, обёртки функций в чистом виде нужны именно в ФП-языках и именно так, как вы описали в первом комментарии. Но в ООП-языках так или иначе они имеют меньше возможностей, чем вариант на базе явного решения в виде явного создания объекта. В ФП языках (это одна из характерных черт) нет состояния, все функции чисты в том смысле, что извне они обладают ровно пустым состоянием, то есть преобразуют «вход» в «выход» без памяти о том, что было сделано в прежних вызовах. Но в этом и сила ФП-программирования. Сила же ООП-программирования как раз в «программирование с состояниями». Теперь я хочу привести даже не моё мнение, а чисто факты:
1. Вынесение логики в виде замыкания в ООП-языках преобразуется в объект строго определённого типа, который может замыкаться на внешний контекст и хранить состояние только во внешним контексте, но в собственном.
2. Вынесение логики в явно определённый объект позволяет этому объекту сохранять состояние не во внешнем контексте, на который он замыкается, а внутри себя.
3. Объект, полученный при явном определении (п. 2), может иметь любой тип, наследовать любой класс, реализовывать любые интерфейсы (протоколы, трейты). В частном случае, он может нести ровно ту же самую нагрузку, что и неявно созданный с помощью синтаксического замыкания объект, описанный в п. 1.
4. Из пп 1-3 следует, что функциональность явно определённого объекта больше либо равна функциональности объекта, созданного через замыкание.
Кстати, в подтверждение этого заключения я в статье и привёл два примера на C#.
Почти то же самое можно сказать и о генераторах. А чтобы использовать решения на базе явного определения объектов достаточно языка с очень простым синтаксисом как, например, Smalltalk. Я не говорю, что замыкания на уровне синтаксиса — это плохо, наоборот они очень даже хорошо смотрятся и, главное, нужно писать меньше. Я хотел сказать, что они более ограничены. Вообще, я хотел сказать, что все хаки более ограничены, чем явное определение объектов.
Вообще, я уже почувствовал, что написание общетеоретических статей — совершенно проигрышное дело. Спасибо, что не забанили статью. В будущем буду писать статьи только с конкретикой.
1. Я знаком с C++ как и ещё полутра десяткой языков и с его невиртуальными методами тоже. Я о нём просто не написал.
2. В моём «сферическом языке» Class.new() выполняется для создания новых объектов и Class — это объект. Так есть, например, в Smalltalk, где класс Object содержит всё необходимое, чтобы делать новые объекты, но сам он является объектом. В Smalltalk, как и в Self, нет синтаксической конструкции для наследования классов — подкласс создаётся путём отправки сообщения subclass классу-объекту, от которого производится наследование.
3. Мой язык не такой уж и «сферический», я описал его, используя, в частности, знание Smalltalk и Self, где нет лексических конструкций для определения наследования, инкапсуляции, конструкторов и классов.
4. В таких языках как C#, Python, Smalltalk замыкание не что иное как объект (замыкание преобразуется в настоящий объект компилятором/интерпретатором).
5. В некоторых ранних версиях Objective-C представлял собой препроцессор над C++, поэтому и был чистым расширением не C, а C++. Впрочем и сейчас есть сборки, позволяющие использовать C++ в Objective-С, например, вот и вот.
6. Я делаю вывод, что чистая объектная модель не приводит к плохо структурированному коду, что видно при внимательном прочтении.
7. Я знаком с yield как в Python, так и в C#. Например, в C# конструкция
yieldпреобразуется не во что иное как в объект IEnumerable. То, как это происходит, хорошо описано здесь.