И это хорошо. А ешё там рекламой по увеличению пиписьки подписке на курсы, которые помогут зарабатывать 100500$ в пикосекунду 8334$ в месяц кодя левой пяткой на питоне весь сайт присыпан, да так, что даже адблок не режет.
Единственное пояснение от меня — Автора питона держал в принудительном сексуальном рабстве какой то функциональщик, что то в их отношениях было крепко завязано на рекурсию...
PS
прозреваю еще проблемы аналогичного характера с «передать функцию как параметр», «отдать функцию как результат выполнения функции».
Там не это сказано. Сочетание лямбды с reduce меняется в простых случаях на sum, в сложных - на императивную функцию. Имхо норм, в байткоде такая функциональщина и императивный код будут одинаковыми.
У фанбоев ФП горит потому что «в list comprehensions есть for, а значит это императивщина!». У фанбоев ООП горит от того, что в питоне есть функции и нет приватных методов. Хороший всё-таки язык.
Питон - это новая Java. В смысле, что люби его или не люби, а если потребуется, будешь кодить на нём, куда ты денешься.
А мне как-то удавалось 20 лет петлять от пузона. Правда я и не программист давно в привычном смысле (кодить за доширак на чем прикажут). Даже не знаю что вас заставляет использовать это днище, какие-то совсем суровые жизненнные обстоятельства наверно.
Спасибо, он уже нарешал. Теперь Google сливает потихоньку питон, заменяя его Go. Но проекты и вакансии на питоне еще долго будут существовать, как это случилось с тем же PHP.
Дело в том, что изначально Гвидо делал язык в угоду умственно отсталым; язык, в котором всё кладется на альтарь услады какого-то научного сотрудника, протирающего штаны в своем кабинете, производя макулатуру. Умственно отсталые где-то прочитали/услышали/увидели/унюхали, что есть лучшая на свете парадигма ООП, и ее обязательно нужно сделать в их языке, причем, со множественным наследованием и динамическим описанием классов. Вуаля, получите объекты, дорогие мои детишки.
Потом многие годы у Гвидо политика была простая: если ваша фича не ломает питон и не делает код совсем уж вырвиглазным, то мы ее засунем в питон. Такая политика сыграла в обе стороны: питон стал популярным, и одновременно питон стал непригодным для целого ряда задач. Таким образом, я бы поставил под сомнение статус «ЯП общего назначения». Что в итоге получилось? Язык с огромным кол-вом разношерстных фич, который проектировался из расчета на писателя, но никогда не проектировался из расчета на исполнителя написаного кода. Из-за чего, к слову, питон многими людьми используется как псевдокод. Такой себе псевдокод с опцией выполнения.
Лямбды, filter, reduce, map также были засунуты в язык на радость деткам аж в 1993 году. Тогда еще был в моде лисп, а как же ж с лиспа перепрыгивать на питон, если в питоне нету мап-редьюса? Слава богу, до Гвидо доперло, что мап-редьюс есть говнище в плане читаемости и производительности, потому он сделал list comprehension к 2.0 в двухтясячном.
Давайте же сядем и подумаем, как бы мы задним числом, обладая умом и опытом современных продвинутых enterprise bigdata кодеров, могли бы сделать мап-редьюс «правильно» в питоне. Напрашивается что-то вроде s = reduce(`+`, arr). Красиво, да? А теперь, детишки, давайте посмотрим, почему устройство языка и исполнителя языка в принципе не даст нам сделать выполняемым такой код, хоть в качестве псевдокода это смотрится весьма солидно.
Что такое плюс в питоне? Это метод объекта. Точнее, в случае CPython это встроенная функция binary_op1, которая выбирает из двух покемонов самого красивого, и вызывает его слот функции сложения, известный простому смертному как метод __add__. Но что же будет значить плюсик в reduce(`+`, arr) ? Методом какого объекта он будет являться: суммы или элемента массива? Чтобы решить эту проблему, мы должны явно объявить функцию: reduce(`x, result -> x + result`, arr) или reduce(`x, result -> result + x`, arr). Отсюда, к слову, можно понять такие забавные особенности поведения питона, как разный результат вычисления a = a + b и a += b. Прохладные истории по этому мотиву можно почитать в реализации встроенной функции sum() в Python/bltinmodule.c: builtin_sum_impl:
static PyObject *
builtin_sum_impl(PyObject *module, PyObject *iterable, PyObject *start)
///////////////////////////////////////////////////////////////////////
for(;;) {
item = PyIter_Next(iter);
if (item == NULL) {
/* error, or end-of-sequence */
if (PyErr_Occurred()) {
Py_DECREF(result);
result = NULL;
}
break;
}
/* It's tempting to use PyNumber_InPlaceAdd instead of
PyNumber_Add here, to avoid quadratic running time
when doing 'sum(list_of_lists, [])'. However, this
would produce a change in behaviour: a snippet like
empty = []
sum([[x] for x in range(10)], empty)
would change the value of empty. */
temp = PyNumber_Add(result, item);
Py_DECREF(result);
Py_DECREF(item);
result = temp;
if (result == NULL)
break;
}
Где слэшами вырезана проверка аргументов и включаемая опциями компилирования реализация быстрого суммирования чисел. Это, как бы, в тему о том, что написать-то написали - а как это дерьмо теперь исполнять-то? Мало того, что нужно пытаться угадывать мысли юзера - так нужно еще и оглядываться на объектную модель, которая больше мешает, чем помогает. В итоге, для чисел сложение мы тебе написали, а дальше уже для своих типов любись как хочешь.
Сочетание лямбды с reduce меняется в простых случаях на sum, в сложных - на императивную функцию. Имхо норм, в байткоде такая функциональщина и императивный код будут одинаковыми.
Кем меняется? Джуниором, которого заставят переписывать код по гайдлайнам? Компилятор CPython предельно тупой, и напрямую преобразовывает написанный код в исполняющий те же операции код аля «польская нотация».
Там приводится конкретный код: reduce(lambda x, y: x + y, range(1, 6)). Это была просто сумма. А теперь представь, если туда добавить еще пару функций - как потом это читать?
А мне как-то удавалось 20 лет петлять от пузона. Правда я и не программист давно в привычном смысле (кодить за доширак на чем прикажут). Даже не знаю что вас заставляет использовать это днище, какие-то совсем суровые жизненнные обстоятельства наверно.
У меня два вопроса:
- какие же тогда языки, если не питон;
- можешь ли ты объяснить, почему на этом днище плавает гугль и ютьюб? Я так-то сам на этот вопрос толком не могу ответить.
О каком пороге вхождения идет речь? IDE едва ли попу не подтирают за программистами на Java, а сам язык не относится к ЯП низкого уровня, чтобы создавать сложности в изучении и использовании. Да и под Андроид не понаписали бы столько ПО, если бы Java была сложной. Вот во времена живых Nokia и Symbian писать программки на Symbian C++ могли полтора землекопа во всем мире, потому что там было сложно освоить C++.
Это результат агрессивного маркетинга и промывки мозгов студентоте. Почему именно питон черт знает (хинт: там рептилия на логотипе, понимай как хочешь эту символику). Гугль кстати нахлебался настолько, что вложился в новый язык, а это очень непросто раскрутить новый язык. Т.е. последние 10 лет гугль старательно петлят от пистона.
Питон абсолютно вне конкуренции по читаемости. Покажи мне язык, которые будет сравним с ним. Руби? Мо быть.
Это результат агрессивного маркетинга и промывки мозгов студентоте. Почему именно питон черт знает. Гугль кстати нахлебался настолько, что вложился в новый язык, а это очень непросто раскрутить новый язык. Т.е. последние 10 лет гугль старательно петлят от пистона.
Вот, «черт знает»... В отличие от тебя я ознакамливался с первоисточниками в лице Гвидо и других разрабов питона, которые работали в гугле, которые, в свое время, занимались чем-то вроде V8 для питоне, представлявший собой два или три разной скорости интерпретатора, поочередно хватадщих код. И, к сожалению, ничерта у них толком не получилось, потому питон так и остался для гугля языком для прототипирования или часто меняющегося функционала. То есть, питон - это язык вечного прототипирования, продакшен на нем писать абсурдно - даже у PHP в этом плане побольше потенциала.
Ситуация гугля с питоном чем-то напоминает ситуацию фейсбука с PHP, которые тоже раскрутил до небес PHP, мол «посмотрите, такой гигант, а использует PHP». А фейсбуку просто некуда деваться - очень много наследия уже сделано на пыхе, и куча данных лежат в MySQL - переход будет стоить миллиарды.
теперь представь, если туда добавить еще пару функций
Представил. Надо называть вещи своими именами: лямбды и ООП в питоне — говно, не reduce сложный.
Да, именно об этом я и пытался сказать по поводу лямбд. По поводу ООП я хотел сказать нечто другое: ты можешь привести пример языка, где ООП было бы не говном?
В отличие от тебя я ознакамливался с первоисточниками в лице Гвидо и других разрабов питона, которые работали в гугле, которые, в свое время, занимались чем-то вроде V8 для питоне
Ну и? Я тоже знаю историю. Вопрос: кто притащил в гугль Гвиду, кто притащил питон в университетские программы США? Ты представляешь себе насколько это консервативная среда, и тут вдруг в нее врывается нерд с голландской помойки с очень примитивным языком и наколенной реализацией. Зато с рептилией на флаге лол.
Читаемость очевидно зависит не столько от языка, сколько от писателя. Я не вижу чем питон так уж выделяется. Чуть в сторону от хеловорлдов и видим такую же кашу, как и в любой императивной скобкоте.
Ситуация гугля с питоном чем-то напоминает ситуацию фейсбука с PHP, которые тоже раскрутил до небес PHP
Не напоминает, php был раскручен задолго до фейсбука. Вернее, там и раскручивать не пришлось, он сам взлетел как самое подходящее решение для шаред хостингов. В отличие от питона, пхп это честный пролетарский продукт, вытянувший себя сам за уши и эволюционировавший во вполне приличный ЯП.
Фейсбук не раскручивал пых, более того у них там давно Hack, который хорош, но что-то не особо раскручивается.
Да, он подхватил волну. Как это сделал тот же гугл с питоном. Нужно понимать, что выбор языка индусом часто иррационален. В данном случае это иррациональность «сильный нас подстрахует». То есть, если вдруг разработка языка имеющимися командами скиснет, то останется гугл/фейсбук, которые будут поддерживать разработку. Примерно так люди продолжают писать на мертвом WPF, потому что VisualStudio же на нем, а MS не может забросить студию.
у них там давно Hack, который хорош, но что-то не особо раскручивается.
Хак в опенсорсе очень мало, нужно всегда оглядываться на инерцию, и «5 лет назад» в индустрии является синонимом «только вчера».
вне конкуренции по читаемости. Покажи мне язык, которые будет сравним с ним
КОБОЛ, ПЛ/I, ФОРТРАН.
Да, они по своему хороши, но уже не актуальны вследствие низкоуровневости конструкций.
Любой, где из коробки можно писать [].reduce(f).reduce(q), а не reduce(reduce([], f), q).
Как я понимаю, ты намекаешь на руби. Но проблема в том, что reduce - это не метод массива, а таки функция, принимающая аргументом коллекцию и функцию-трансформатор. Да, в рубях конкретно reduce сделан через миксин Enumerable. я не могу взять один лишь reduce, оставив в стороне еще две десятка фукнций Enumerable - это вечная беда наследования, решить которую можно только избавившись от наследования. К слову, в CPython на низком уровне допустимо исключительно одиночное наследование. То есть, Гвидо понимал, что наследование создает одни проблемы, потому оставил детишкам множественное наследование на высокоуровневых конструкциях, и решительно порезал его на уровне С-реализации.
Красиво это делается в каком-нибудь Elm, где можно разворачивать нотацию аргументов-функций: [] |> reduce f |> reduce q