Вы любите питон вот за такое?

Еще добавлю

http://google.github.io/styleguide/pyguide.html#215-deprecated-language-features

Use function call syntax instead of apply. Use list comprehensions and for loops instead of filter and map when the function argument would have been an inlined lambda anyway. Use for loops instead of reduce.

2.15.2 Decision

We do not use any Python version which does not support these features, so there is no reason not to use the new styles.

Вопрос: кто притащил в гугль Гвиду, кто притащил питон в университетские программы США

Гвида сам пришел из университета, тем более, европейского - это «свои» люди. Да, питон входил в универститетский программы долго, 15-20 лет - ни разу не «врывался», потому что это консервативная среда, как ты заметил. Потому что читаемость все-таки безупречная у питона.

моего любимого мегарулезного языка программирования

Что за язык то?

Groovy.

Фейсбук не раскручивал пых, более того у них там давно Hack, который хорош, но что-то не особо раскручивается.

Он ни на полшишки не хорош. Это проект для внутренних нужд чтобы существующая кодовая база просто не взорвалась под своей сложностью и тяжестью

Даже гугль плавал на этом днище, как ты верно подметил.

Не «плавал», а «плавает». Новые проекты в том числе делаются на питоне. Например, для AI он прекрасно подходит.

Когда не знаешь как сделать что-то тормозное и говенное еще хуже - запусти его на JVM.

Для не знающих - это тот язык, который автора сказал что не начал бы ни в коем случае если бы знал что есть Scala. Scala уже была, просто автор Groovy не знал.

Читаемость очевидно зависит не столько от языка, сколько от писателя. Я не вижу чем питон так уж выделяется. Чуть в сторону от хеловорлдов и видим такую же кашу, как и в любой императивной скобкоте.

Зависит и от языка, и от писателя. Язык может склонять к нечитаемым конструкциям, и сам программист может склоняться к нечитаемым конструкциям. И именно питон славится тем, что писанный в хорошем стиле код на нем безупречно читается.

С прототипами такая штука, нету ничего более постоянного, чем временное. Прототип переростает во временный продакшн, а потом в постоянный продакшн. Слава богам хоть Typed Python есть, как костыль ничего так справляется

Не напоминает, php был раскручен задолго до фейсбука. Вернее, там и раскручивать не пришлось, он сам взлетел как самое подходящее решение для шаред хостингов.

Я так понимаю, что здесь ты тоже прекрасно знаком с историей, да? И можешь пояснить, почему PHP, а не Perl, не Python, не Ruby, которые все, между прочим, были из близких ниш и имели свои модули к апачу.

В отличие от питона, пхп это честный пролетарский продукт, вытянувший себя сам за уши и эволюционировавший во вполне приличный ЯП.

Не вижу ничего приличного в PHP. Чтобы ему стать приличным, нужно сделать новый язык по мотивам старого. А это делать никто не будет, потому что потеряют всё стойло «опытных профессионалов» на старом языке.

Груви был сделан под впечатлением от руби, и тогда еще емнип даже не было рельсохайпа и jruby, да и скалы вроде еще не было. И вот насчет сделать еще хуже, это сейчас легко рассуждать. А в начале нулевых ничего гуманного еще не было в мейнстриме.

Ну как бы не то чтобы Google реально раскручивал Python когда-то. Просто пользовался.

Самое интересное что даже реально в доску свои языки не то чтобы раскручивал. Просто профинансировал сommunity по Go и все. Dart - вообще тишина.

Возьмите Java как контраст. Рекламная кампания «Java Powered» стоила 500 млн долларов. Пол миллиарда баксов, Карл, на рекламу.

За такие бабки тупо кирпич как ноутбук можно продать.

С прототипами такая штука, нету ничего более постоянного, чем временное

Недостатки организации разработки не имеют отношения к ценности прототипирования. Достаточно новый проект ни за что не получится хорошим с первого раза, потому нужно написать первую реализацию на чем угодно, выбросить ее, и написать начисто. То есть, прототип нужно написать максимально быстро, и так же максимально быстро переписать его на подходящем языке. Если вы этого не сделали - вам конец, вы будете наращивать technical debt, пока не рухнете, как это произошло у данного оратора: Зачем придумывают всё новые языки-велосипеды? (комментарий)

Ну как бы не то чтобы Google реально раскручивал Python когда-то. Просто пользовался.
Самое интересное что даже реально в доску свои языки не то чтобы раскручивал. Просто профинансировал сommunity по Go и все. Dart - вообще тишина.

Да, на одной лишь раскрутке пытался выехать только Sun, и благополучно загнулся. Все-таки, инструмент должен иметь какие-то естественные популяризующие свойства. Тот же Go попал в пустую нишу и взлетел. А вот Dart попал в переполненную нишу, в которой, к тому же, был готовый V8, созданный тем же гуглом.

Ну это если допускать что прототипирование на Python чем то быстрее. Хотя нет.

Может уж в совсем таких языках, вроде плюсов, если в твоей организации нету серьезной стандартной библиотеки.

Но уже начиная с Java, выиграл от написания чего-то Python сильно падает уже после 500-1000 строчек.

И можешь пояснить, почему PHP, а не Perl, не Python, не Ruby

Потому что когда начинали писать cgi-скрипты был только перл. Но он слишком замороченный, нужно было проще. Тот, кто первым выкатил упрощенный вариант, да еще встраиваемый прямо в разметку, тот и захватил нишу. И еще php затачивали под fastcgi, а у других было с этим туго.

Ну вот сейчас Dart/Flutter попадут в пустую нишу языков для Fuschia, посмотрим как будет

Ну это если допускать что прототипирование на Python чем то быстрее. Хотя нет.

Плохо и быстро на питоне можно написать даже сетевой драйвер. Прототип не обязан досконально реализовывать все конечные функции - нужен просто какой-то proof-of-concept, некоторые наброски функций, которые давали бы представление о том, к чему нужно стремиться.

Но уже начиная с Java, выиграл от написания чего-то Python сильно падает уже после 500-1000 строчек.

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

Боюсь, что на каком-нибудь котлине можно писать даже быстрее, чем на питоне, ведь там еще и компилятор помогает. А жавистам код вообще пишет их жирноIDE лол. Вот серьезно, от прототипа на левом язычке больше риска чем пользы.

Если сразу выкатить в джаву овердизайн, тогда будет тяжелее читается. Но речь ведь о прототипе. В нем не надо приседать с интерфейсами разухабистыми спрингами. Есть куча простых библиотек, фреймворков для веба которых для прототипов за глаза

Потому что когда начинали писать cgi-скрипты был только перл. Но он слишком замороченный, нужно было проще. Тот, кто первым выкатил упрощенный вариант, да еще встраиваемый прямо в разметку, тот и захватил нишу. И еще php затачивали под fastcgi, а у других было с этим туго.

И это неправильный ответ. До PHP был еще и питон, релизнутый аж в 1991 году; 8 июня 1995 был релизнут первый публичный пых, а уже 2 июля 1995 был релизнут ColdFusion, который обладал аналогичной смешанной разметкой. Ну и в декабре 1995 вышел Руби.

Ну вот сейчас Dart/Flutter попадут в пустую нишу языков для Fuschia, посмотрим как будет

Всё будет зависеть от успеха Fuschia.

Боюсь, что на каком-нибудь котлине можно писать даже быстрее, чем на питоне, ведь там еще и компилятор помогает. А жавистам код вообще пишет их жирноIDE лол. Вот серьезно, от прототипа на левом язычке больше риска чем пользы.

Даже несмотря на вывод типов, ты вынужден с этими типами мириться. В питоне можно очень жестко забивать на тип и рефакторинг, клепая по 300-500 строчек в день. Что-то не заработало? А черт с ним, напишем еще раз. Жаба такого не потянет.

проблема в том, что reduce - это не метод массива, а таки функция, принимающая аргументом коллекцию и функцию-трансформатор. Да, в рубях конкретно reduce сделан через миксин Enumerable. я не могу взять один лишь reduce, оставив в стороне еще две десятка фукнций Enumerable - это вечная беда наследования

А зачем их оставлять в стороне? reduce имеет смысл только для коллекций, Enumerable это обобщенный интерфейс коллекции (с халявной реализацией к тому же), все логично. Главное, цель достигнута - имеем обобщенный reduce. Даже если бы его не было, ты мог бы сам дописать прямо в Enumerable. В то же время питонщики годами ждут каких-то «крутых» фич, потом радуются как дети когда Гвидо снизойдет.

Если сразу выкатить в джаву овердизайн, тогда будет тяжелее читается. Но речь ведь о прототипе. В нем не надо приседать с интерфейсами разухабистыми спрингами. Есть куча простых библиотек, фреймворков для веба которых для прототипов за глаза

Мне нужен список: ['a', 'b', 'c']. Мне нужен объект - пожалста: { a: 1, b: 2 }. Херак-херак - вот уже и что-то похожее на логику. Нужен именно класс - говно вопрос, перепишем:

class A:
    a = 1
    b = 2

Enumerable это обобщенный интерфейс коллекции (с халявной реализацией к тому же), все логично.

Это не интерфейс, а частичная реализация коллекции. Nаким образом, у тебя каждый перечисляемый объект наследует реализацию Enumerable. Интерфейс - это просто объявления функций, без реализации: https://docs.oracle.com/javase/8/docs/api/java/util/Collection.html

Главное, цель достигнута - имеем обобщенный reduce

Которому я не могу передавать свои собственные реализации Enumerable.

свои собственные реализации Enumerable

Ты хочешь странного, но никто не мешает их делать и подмешивать к своим классам. Раз уж Enumerable не угодил, то и reduce реализуешь свой.

Список

l = ['a', 'b', 'c']

var l = List.of("a", "b", "c")

Словарь

m = { a: 1, b: 2 }

var m = Map.of("a", 1, "b", 2)

Data-class

class A:
    a = 1
    b = 2

@lombok.Data 
public class A {
  private int a = 1;
  private int b = 1;
}

Последний пример генерирует все геттеры, сеттеры, хеш код, equals, конструктор, toString.

Ну конечно да, все вышеперечисленное в достаточно новых версиях Java, а последний пример требует Lombok.

Lombok тут нужен для геттеров-сеттеров и прочего, что не дает Python пример. Конечно раз это прототип, то можно было сразу просто делать публичные поля.

Kotlin/Scala конечно решают все проблемы сразу и намного мощнее и удобнее чем Python

Даже несмотря на вывод типов, ты вынужден с этими типами мириться. В питоне можно очень жестко забивать на тип и рефакторинг, клепая по 300-500 строчек в день.

Продумывать типы очень полезно, прочищает мозги. А так пооучается говнокод же. И если не рефакторить быстро, то код столь же быстро становится неуправляемым. Я чот не хочу отлаживать 5000 строк лапши на питоне, например.

На 5000 строчках нетипизированого Python менять даже одну строчку становится страшно. Даже в прототипе.

Особенно шикарно от этого НЕ спасают тесты, которые в теории хороши, но в Python традиционно хорошо мокают правильные типы и неправильные всплывают на продакшне.

Наличие статической типизации как раз помогают для прототипирования. Код со статической типизацией, но без тестов - близок к «золотой середине» для прототипа. Если что, тесты можно добавить точечно, без фанатизма.

С Hindley-Milner еще лучше прототипировать. Явно описываешь типы только там где сам хочешь, чтобы зафиксировать интерфейс и ограничить пропагирование неправильных типов. Идеально для прототипирования

Гвида сам пришел из университета, тем более, европейского - это «свои» люди.

Воот, это СВОЙ. Человек вхож в высшие круги, да у него даже фамилия рептильная аристократическая. Питон мог бы тотально доминировать, но настолько слабый язык получился, что всем гуглом не удалось ему реализацию довести до ума.

намекаешь на руби

Вообще-то я скорее имел в виду js. Хотя и руби тоже годится.

принимающая аргументом коллекцию

И т.о. это adhoc полиморфизм, вместо нормального полиморфизма типов. Я и говорю, говно-ООП.

не могу взять один лишь reduce, оставив в стороне еще две десятка фукнций Enumerable

А зачем их оставлять? Выглядит как натягивание совы на глобус.

где можно разворачивать нотацию аргументов-функций

Это можно прикрутить в любой язык где есть apply.

Раз уж Enumerable не угодил, то и reduce реализуешь свой.

Вот именно. Если я не хочу сохранять все двадцать методов Enumerable в той их реализации, в которой они сделаны в стандартной библиотеке - я должен реализовывать их заново. Или не реализовывать, и надеяться, что нигде не выйду в noMethodError. А всё потому, что Enumerable - это не интерфейс, а реализация.

var l = List.of(«a», «b», «c»)

Блин, ну так я могу сам написать

char myArray[3] = { 'a', 'b', 'c' };

Последний пример генерирует все геттеры, сеттеры, хеш код, equals, конструктор, toString.

И все равно это лишь часть интерфейса, который получают объекты питона автоматом. Хотя да, согласен, пытаются подобраться к этому уровню.

Lombok тут нужен для геттеров-сеттеров и прочего, что не дает Python пример. Конечно раз это прототип, то можно было сразу просто делать публичные поля.

Зачем в питоне геттеры-сеттеры? Конструктор здесь в питоне не нужен - его и не объявлено вовсе. Хэш-коды, превращение в строку - уже само есть.

Kotlin/Scala конечно решают все проблемы сразу и намного мощнее и удобнее чем Python

К сожалению не могу толком ответить на этот аргумент.

Продумывать типы очень полезно, прочищает мозги.

Про-то-ти-пи-ро-ва-ние. Можно посмотреть в википедии: https://ru.wikipedia.org/wiki/Прототипирование

На 5000 строчках нетипизированого Python менять даже одну строчку становится страшно. Даже в прототипе.

Herak-herak-driven develompent. Правда, тут важно не запускать сильно, а вовремя исправлять самые жесткие ошибки, и проблем не будет. Потому что есть особо одаренные, которые будут ошибки экранировать, из-за чего они будут вылазить в совершенно другом месте.

Справедливости ради, нужно отметить, что с применением элементов herak-herak-driven development были созданы оракл, линукс, винда, сам CPython. И ничо, работают. Правда, вон, на презентации у била синий экран вылез - с кем не бывает. Просто, нужно тестов побольше и подольше - глядишь, и вылезет что-то.

Наличие статической типизации как раз помогают для прототипирования.

Только проблема в том, что код все равно будет выкинут.

С Hindley-Milner еще лучше прототипировать. Явно описываешь типы только там где сам хочешь, чтобы зафиксировать интерфейс и ограничить пропагирование неправильных типов. Идеально для прототипирования

Спасибо, мне в хаскеле уже рассказали про вывод типов. Это когда у тебя ошибка на весь экран с описанием связей типов, а ты чешешь репу и не можешь понять, где ты не тот символ поставил.

Вообще-то я скорее имел в виду js. Хотя и руби тоже годится.

JS - близкий претендент. И система классов (а.к.а. прототип) похожа на питон. Проблема JS заключается в том, что он не умеет в абстракции. Язык просто не собирались проектировать под большие проекты, а сделали простой жавоподобный язык за 10 дней. По этой причине на JS хронически отсутствуют какие бы то ни было крупные фреймворки. Какие-нибудь крупные «монстры», вроде react или quasar, содержат в себе менее 100 тыс строк - детский сад.

принимающая аргументом коллекцию

И т.о. это adhoc полиморфизм, вместо нормального полиморфизма типов. Я и говорю, говно-ООП.

Я не знаю, что такое «нормальный полиморфизм». Параметрический, что ли?

не могу взять один лишь reduce, оставив в стороне еще две десятка фукнций Enumerable

А зачем их оставлять? Выглядит как натягивание совы на глобус.

«Вы можете выбрать машину любого цвета, если этот цвет - черный». Проблема становится всё более актуальной по мере удаление от стандартной библиотеки и погружения в некую предметную область, по сути указывая на простую проблему: Enumerable не нужен.

Если говорить про JS к контексте reduce, то он, к сожалению, имеет серьезные проблемы с организацией кода, из-за чего приходится привязывать функцию к прототипу массива, иначе она потеряется и попадет куда-то не туда.

Красиво это делается в каком-нибудь Elm, где можно разворачивать нотацию аргументов-функций: [] |> reduce f |> reduce q

Это можно прикрутить в любой язык где есть apply.

Так лаконично это позволяет делать только Elm. С Apply код получается только хуже.

https://www.tiobe.com/tiobe-index/

Что там на первой строчке?

Вопрос риторический.

Про-то-ти-пи-ро-ва-ние.

Так и что, если прототип, то мозг задействовать вообще нельзя? Только бескомпромиссный херак-херак?

А потом продать этот херак-прототип на пистоне как готовый продукт и вечно окучивать клиентов «поддержкой». Мечта дефективного минетжера прям. Не зря пистон такой популярный.