The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

GitHub опубликовал статистику за 2023 год и назвал победителей GitHub Awards 2023, opennews (??), 10-Ноя-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


117. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +2 +/
Сообщение от freehckemail (ok), 10-Ноя-23, 23:33 
Ребята, остыньте. Если бы вы знали достаточно языков, вы бы давно поняли, что их качество с их массовостью никак не коррелирует. Языки становятся массовыми не за счёт своих технических преимуществ, а за бабло, которое в них вливают заинтересованные компании. И к слову, это относится далеко не к одним только языкам.
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

123. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от Аноним (48), 11-Ноя-23, 00:25 
Массовость коррелирует с экосистемой и её развитостью.
Ответить | Правка | Наверх | Cообщить модератору

154. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +2 +/
Сообщение от freehckemail (ok), 11-Ноя-23, 11:48 
> Массовость коррелирует с экосистемой и её развитостью.

Конечно нет.

Вы посмотрите на Python: ребята за 30 лет не смогли сделать нормальную стандартную библиотеку, о какой экосистеме тут может вообще идти речь. Или посмотрите на Ansible: на него вообще плохо ложится логика сложнее, чем "создай файл из шаблона и положи по заданному пути". Публичные репозитории обоих полнятся кодом, который нельзя использовать ни при каких обстоятельствах. Это ли не показатель плохой неразвитой экосистемы? Однако при всём при этом оба --  инструменты массовые.

В противовес можно взять те же Perl с CPAN, или Ocaml с OPAM, либо даже Racket с этими его collections. В хранилищах -- масса высококачественного кода, он точно так же легко доступен, зачастую даже имеет более проработанный менеджмент зависимостей, и кое-где даже встроен в компилятор. Это -- хорошая развитая экосистема. Но эти языки -- не массовые.

upd: я сказал в данном посте плохо про питон, и конечно же сейчас понабегут питонисты с литрами желчи, так что я сворачиваю данный тред, чтобы никому больше не портить чтение комментариев (мб разверну позже, когда ажиотаж пройдёт)
upd2: ажиотаж прошёл

Ответить | Правка | Наверх | Cообщить модератору

157. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от Аноним (48), 11-Ноя-23, 12:23 
>высококачественного

Хорошая шутка, спасибо. Иного и не ожидали.

>проработанный менеджмент зависимостей

Ну это уже коровье дерьмо. Недавно Шляпа добавила очередную зависимость от перла в иксы, что притянуло около 1000 пакетов разложившейся на плесень и липовый мёд мертвячины, причём, вручную всё замечательно отвязывалось (патчами). Просто замечательно проработанный менеджмент.

Я не понимаю, какие могут быть претензии к тому же питону, таких ситуаций (1000 неиспользуемых зависимостей у пакета) с ним не бывает никогда (в основном, проблемы с пакетами, в которые проникла ржавчина, ржавчинописатели плохо понимают особенности и ограничения ржавчины -- см. issues таких проектов для посмеяться), а стандартная библиотека стабильна и на хорошем уровне, вполне отвечает всем требованиям и позволяет решать широкий спектр задач. Если чего-то в ней нет, то на то есть объективные причины. При этом, есть куча серьёзных проектов, отлично её дополняющих в любой области. С которыми не возникает регулярных проблем с обновлением и сопровождением, как это происходит с перлом.

Ответить | Правка | Наверх | Cообщить модератору

163. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от freehckemail (ok), 11-Ноя-23, 15:05 
>> проработанный менеджмент зависимостей
> Ну это уже коровье дерьмо. Недавно Шляпа добавила очередную зависимость от перла в иксы

С характеристикой согласен. Речь-то шла не про те зависимости.

> стандартная библиотека [питона] <...> вполне отвечает всем требованиям

Вот прямо всем, да? А огласите весь список, пожалуйста.

> Если чего-то в ней нет, то на то есть объективные причины

Ну давайте подробнее, чего уж.

Попробуйте объяснить, почему за тридцать лет развития языка в стандартной библиотеке не реализована абстракция Stream? Неужели разработчики на python настолько продвинутые, что программирование на continuation-ах (по-вашему -- через генераторы) им даже проще и понятнее, чем работать через всем известные и давно отлаженные абстракции?

Или если говорить про стандартную библиотеку, то почему в shutil функция copytree по умолчанию копирует stat-ы файлов (тоесть atime/mtime/ctime)? Или почему в python3 она наконец получила параметр, который позволяет подменить функцию копирования файла, однако копируемые директории всё равно будут копировать stat-ы, и это никак нельзя изменить? Кому вообще пришло в голову, что копировать stat-ы -- это хорошая идея? В чём прикол делать лишний сисколл на каждый файл и каждую директорию?

Вот всему этому есть объективные причины, да? Я очень в этом сомневаюсь.

Ответить | Правка | Наверх | Cообщить модератору

170. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от Аноним (48), 11-Ноя-23, 17:19 
Насчёт стримов, если я правильно понимаю суть, существует несколько замечательных сторонних реализаций, с асинхронностью и всем остальным. Только что-то пользоваться ими не слишком удобно и популярности особой не снискали (но, я уверен, можно найти походящие применения при необходимости). Да, генераторы были выбраны совершенно осознанно. Это всё же более полноценный язык, чем тот же жс. Возможно, именно благодаря тому и снискал популярность.

Не знаком с проблемами copytree, но, описанное поведение звучит логично и ожидаемо, я всецело его приветствую. Что такое копируемые директории и почему они не должны быть приведены к идентичному виду? Тем более, при чём тут доисторические времена, когда питон ещё не был таким основополагающим компонентом (т.е. когда лишний вызов не мог быть критичным при типичном использовании)? Разве это не ожидаемое поведение? В угловых случаях, манки-патчинг никто не отменял. Конечно, shutil это не лучший образец. Были случаи, когда я смотрел в этот код, и он мне не нравился, в итоге приходилось реализовывать как-то ещё. Нужно понимать, однако, если добавить РЕДКИЕ случаи в стандартную библиотеку, это ощутимо замедлит код в обычных частых случаях. Это интерпретируемый язык. А универсальность это хорошо, но, чем интерфейс более загружен, тем хуже для практики.

>Речь-то шла не про те зависимости.

Вот и нет, именно про те и шла, более неудачной дряни, не приносящей ничего кроме боли всем причастным, ещё поискать. А потом киваете на leftpad.

Ответить | Правка | Наверх | Cообщить модератору

194. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от freehckemail (ok), 11-Ноя-23, 23:07 
> Насчёт стримов, если я правильно понимаю суть

Ну что значит "если правильно понимаю суть". Вот определение: https://en.wikipedia.org/wiki/Stream_(abstract_data_type)

Номинально -- это тип, для которого должны быть определены: конструктор (привет, кэп!), функция взятия следующего элемента, nil-чекер (опционально, это зависит от реализации).
Может предоставлять конструкторы с разных типов данных, может предоставлять итераторы, редукторы и фильтры -- всё, естественно, строится на основе выше перечисленных функций.

Вот например как это реализовано в OCaml: https://v2.ocaml.org/releases/4.04/htmlman/libref/Stream.html
Или вот как это определено в Haskell: https://hackage.haskell.org/package/Stream-0.4.7.2/docs/Data...
Вот как это реализовано в Scala: https://www.scala-lang.org/api/2.12.7/scala/collection/immut...
В Java: https://docs.oracle.com/javase/8/docs/api/java/util/stream/S...
В Racket: https://docs.racket-lang.org/reference/streams.html

Вот где это в Python? Я последний раз искал в 2017-м, так и не нашёл. Yield-ить, это конечно здорово. С yield-ом я безусловно могу собственную абстракцию стрима сделать. Но почему за 30 с лишним лет нет готовой?

> Не знаком с проблемами copytree, но, описанное поведение звучит логично и ожидаемо, я всецело его приветствую

Ну так я Вам поясню, почему это не логично и не ожидаемо. Вы при копировании дерева создаёте *новые* файлы и директории. Вполне логично и ожидаемо то, что эти новые файлы и директории должны иметь новые stat-ы, в которых будет содержаться время их создания. Вы спрашиваете почему?

Ну например потому, что так оно предполагается на уровне glibc и ядра: https://pubs.opengroup.org/onlinepubs/9699919799/functions/o...
Я ведь про сисколлы вспомнил не потому, что их надо экономить, а потому что при создании файлов согласно спецификации должны быть выставлены актуальные ctime/atime/mtime, и это прямым текстом написано по ссылке выше (прошу, проверяйте). Именно это я подчёркиваю, когда напоминаю, что смена stat-ов -- это *отдельный* сисколл.

Или например потому, что прочие инструменты, с которыми мы работаем каждый день, например тот же cp из комплекта coreutils -- по умолчанию при рекурсивном копировании директории stat-ы не копирует.

Ну или например потому, что системы автоматической сборки пакетов (deb/rpm) зачастую определяют список файлов просто проверяя destdir на предмет появления в нём новых файлов посредством поиска по времени. И эта логика гарантировано ломается, если какой-нибудь умник использует дефолтный copytree в install-скрипте.

Надеюсь, этих аргументов достаточно?

> В угловых случаях, манки-патчинг никто не отменял.

Да, конечно. Ничто не мешает взять дефиницию copytree и переписать под свои нужды. Или просто использовать os.system("cp -R <...>"), кстати. Но всё-таки если тебе приходится прибегать к манки-патчингу библиотеки, это плохо говорит о библиотеке. А что это кстати за библиотека, в которой находится модуль shutil? Ну надо же какие дела, это The Python Standard Library.

> Нужно понимать, однако, если добавить РЕДКИЕ случаи в стандартную библиотеку, это ощутимо замедлит код в обычных частых случаях.

Да в том-то и дело, что случай не редкий. Я согласен, что в *стандартную* библиотеку нужно добавлять часто используемые строительные кирпичики, из которых можно что-либо построить интуитивным образом. И copytree как раз идёт этому видению наперекор.

В заключение, что тут хотелось бы отметить, так это то, что всё выше перечисленное -- это только верхушка айсберга. Мне довелось плотно поработать с Python где-то в 2017м, и я находил подобных косяков тогда пачки. Описанное мною выше это лишь то, что я удосужился записать, чтобы не забылось. А всего остального я просто уже не вспомню, поскольку поставил крест на Python, и по возможности стараюсь с ним лишний раз не связываться.

Ответить | Правка | Наверх | Cообщить модератору

196. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от Аноним (48), 11-Ноя-23, 23:44 
Но только при чём тут питон? Он никому ничего не должен, это нигде не заявлено. Скажем, ctime -- change time, а не creation time (что многие ошибочно полагают, по какой-то причине). Как вариант последнего придумали различные платформозависимые birth time (и даже добавили в glibc наконец). Это дата изменения атрибутов файла. Если атрибуты не менялись, то и дата меняться не должна. То же самое и с данными. Поскольку это _копия_, она должна быть полной (включая расширенные атрибуты, о чём все забывают). Шаг с новыми статами необходим, чтобы было видно прервавшуюся операцию. Если операция завершена, данные должны быть приведены к нормальному виду. Ну а кто там свои кривые скрипты наворачивает основываясь на atime (которого вообще не существует в адекватно настроенной системе), то это его проблемы.
Ответить | Правка | Наверх | Cообщить модератору

197. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от freehckemail (ok), 12-Ноя-23, 00:20 
> Но только при чём тут питон? Он никому ничего не должен, это нигде не заявлено.

А, ну вот мы и дошли до сути. Ничего, я в целом был готов к тому, что меня нахрен пошлют даже при хорошей аргументации. Не первый раз, как бы. Да, да, когда этот разговор ведётся с питонистом, он всегда так кончается: питон никому ничего не должен.

Что ж, я даже больше того скажу: и Python-разработчики тоже никому ничего не должны. Они никому не должны что-то знать про алгоритмы, системы типов, программирование, системные вызовы, лямбда-исчисление, командную строку. Думать они тоже никому не должны.

Ну вот примерно поэтому я и не связываюсь с питоном. Явно чуждое мне комьюнити.

Ответить | Правка | Наверх | Cообщить модератору

160. Скрыто модератором  +/
Сообщение от Аноним (160), 11-Ноя-23, 14:21 
Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

126. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +1 +/
Сообщение от Аноним (126), 11-Ноя-23, 00:35 
Если еще немного продолжить мысль, то бабло чаще вливают чтобы проще было найти разрабов и поддерживать эти строения. А их гораздо проще найти на языки и стеки, вотэвер с более технически конкурирующими возможностями и дешевизной в разработки.
Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

152. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от freehckemail (ok), 11-Ноя-23, 11:34 
> Если еще немного продолжить мысль

Я пожалуй тоже ещё немного продолжу.

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

Вот зачем было развивать Go, когда уже был например тот же Ocaml? А всё просто: Go хоть и слабее по возможностям, но куда проще в освоении, и главное -- в переходе с C. Почему он выстрелил? Потому что лично Google вбухивал деньги в проекты на нём. Язык получился в общем-то неплохой, но факт остаётся фактом: его разработали исключительно как промежуточное звено, чтобы получить отдельные фишки высокоуровневых языков, но при этом обеспечить массовому прикладному разработчику возможность его выучить, в меру своих способностей.

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

Поэтому development cost и technical merits языка находятся в противофазе. Массовыми всегда становятся откровенные среднячки. Это не делает их хуже, ибо рынок нуждается в огромном количестве специалистов, и высоко квалифицированных кадров в таком количестве просто нет в природе, а вот прикладников -- хоть отбавляй. Но надо отдавать себе отчёт в том, что когда вы смотрите на рейтинги использования различных языков -- это нельзя рассматривать как аргумент за качество языка, потому что прямой корреляции тут нет.

Ответить | Правка | Наверх | Cообщить модератору

165. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от Прохожий (??), 11-Ноя-23, 15:56 
Go выстрелил в первую очередь как раз из-за своей простоты. Деньги Гугла - вторичны, хотя и важны.
Ответить | Правка | Наверх | Cообщить модератору

171. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от freehckemail (ok), 11-Ноя-23, 17:40 
> Go выстрелил в первую очередь как раз из-за своей простоты. Деньги Гугла - вторичны, хотя и важны.

Простота сама по себе не является тем камнем преткновения, из-за которого технология обретает популярность. Вот D позволяет очень многое делать проще и лучше, чем C++. Однако скоро уже 20 лет пройдёт, а что-то D остаётся нишевым языком, и основная масса крестовиков так и не перешла на D. Потому что бизнес должен открывать вакансии на этих языках, чтобы они шли в массы. Сами же массы никогда никуда не идут, их обязательно надо вести.

Деньги -- первичны.

Ответить | Правка | Наверх | Cообщить модератору

173. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от _ (??), 11-Ноя-23, 18:39 
>Деньги -- первичны.

Ну то есть тот же Линус начал писать свой эмулятор терминала чтобы сделать бабала?! :)
рЫлали кул сториЮ бро! :-D

Ответить | Правка | Наверх | Cообщить модератору

184. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от Прохожий (??), 11-Ноя-23, 19:43 
Ты сам с собою споришь, и, похоже, не замечаешь этого. Деньги первичны, когда речь идёт о стоимости разработки, а не о продвижении того или иного языка. Второе всегда намного дороже, чем первое из-за масштабирования.

Предположу, что D не стал популярным, потому что только упрощал, но не предлагал ничего нового в дополнение к тому, что уже есть. И вот перед тобой выбор: то ли пользоваться имеющейся рабочей силой, которая худо-бедно освоила Плюсы на приемлемом уровне, то ли вкладываться в обучение персонала с непредсказуемым или плохо предсказуемым результатом. Конечно, бизнес предпочитает не рисковать и идти проторенной дорожкой. Кроме того, к моменту появления D уже были языки, заполняющие его нишу. Вот и не взлетел.

> Сами же массы никогда никуда не идут, их обязательно надо вести.

Расскажи это адептам Питона.

Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

189. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от Прохожий (??), 11-Ноя-23, 19:56 
Чёрт, опечатка.

"Второе всегда намного дороже, чем первое из-за масштабирования."

Первое всегда намного дороже, чем второе из-за масштабирования.

Ответить | Правка | Наверх | Cообщить модератору

195. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от freehckemail (ok), 11-Ноя-23, 23:34 
> Ты сам с собою споришь, и, похоже, не замечаешь этого. Деньги первичны,
> когда речь идёт о стоимости разработки, а не о продвижении того
> или иного языка. Второе всегда намного дороже, чем первое из-за масштабирования.

Вот хоть Вы, Прохожий, и написали, что это-де опечатка, но на самом деле оговорочка, что называется, "по Фрейду". Как писал когда-то Фредерик Брукс, четверть времени занимает разработка, три четверти -- интеграционное тестирование. Как нынче широко известно по сфере синематографа, продакшен картины занимает четверть бюджета, а продвижение и реклама -- три четверти. Точно также и с продвижением языка в массы, аналогия проявляется довольно чётко.

Люди не станут изучать новый инструмент, на котором нет хорошо оплачиваемых вакансий. Но и бизнес не станет внедрять новый инструмент, если к открытой для него вакансии не прилагается толпа специалистов, жаждущих пройти собеседование. Этот парадокс "курицы и яйца" решается вливанием денег вендором: он спонсирует не только разработку инструмента, но и создаёт первую пачку вакансий, организует конференции, где первопроходцы пиарят новый инструмент (естественно не задаром), организует присутствие упоминаний нового инструмента в новостной шумихе. И вот после этого -- начинается процесс вовлечения как более мелких бизнесов, так и разработчиков. Маховик раскручивается, и инструмент становится массовым.

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

> вот перед тобой выбор: то ли пользоваться имеющейся рабочей силой, которая
> худо-бедно освоила Плюсы на приемлемом уровне, то ли вкладываться в обучение
> персонала с непредсказуемым или плохо предсказуемым результатом. Конечно, бизнес предпочитает
> не рисковать и идти проторенной дорожкой.

Да. И чтобы бизнес и кандидаты решили опробовать новую дорожку -- для этого и надо вливать деньги описанным выше способом.

>> Сами же массы никогда никуда не идут, их обязательно надо вести.
> Расскажи это адептам Питона.

А смысл?

Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

180. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от _ (??), 11-Ноя-23, 19:09 
>Go выстрелил в первую очередь как раз из-за своей простоты. Деньги Гугла - вторичны, хотя и важны.

Не знаю, вот прямо - не знаю :-\

Го мне нравится, причём настолько что я снова программить стал :)
Но вот чего он взлетел - не знаю. Язык как язык кому то - вдоль (мне), кому то поперёк (ооп-щикам), но тля - просто "ещё один ЯП"(С) - не больше!!!.
И меня таки "терзают смутные сомнения"(С), да :)

Раньше многое всё таки зависело от качества самого языка, и всего вокруг него (компилы\тулзы\либы\софт на нём сделанный) и всё это варилось в узком кругу профессионалов. У которых в силу "узкости круга" ;) - хоть какие то общие критерии водились и можно было хоть как то оценить ...
Потом проггер стал чем то типа office clerk и вотЪ :(
Нынче люди с баблом могут взять "блестящу, вонючую, собачью какашку"(С) влить в рекламу и ... вот уже даже "явное оно"(С) обсуждается везде, даже у этих "those russians"(C) (тут к примеру) ... и все ручные "тЫоби вреЙтинги" верещат - вот же оно - "ШЕДЕВР!"(С) ...

Ну то есть используется та-же технология, как для продвигания на продажу ну скажем нового сорта кока-колы, к примеру - __никаких__ отличий  :) И что характерно результат - тот же. Кто коку жрал - все жрутЪ и новую, и нахваливают! ... Вплоть до выхода новой версии коки "теперь в розовой баночке, а это меняет ВСЁ"(С) :)

А "старпёры" как цедили своё вино\коньяк\виски хрензнаетскольки-летней выдержки - так и цедят. :)
(это я уже тут так шпильку вставляю :-р :-D )

  

Ответить | Правка | К родителю #165 | Наверх | Cообщить модератору

164. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от Прохожий (??), 11-Ноя-23, 15:52 
Качество - действительно не коррелирует. А вот простота использования и претензия на независимость от кого-либо - да, коррелирует. Бабло, если и играет какую-то роль, то второстепенную.
Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

181. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от _ (??), 11-Ноя-23, 19:18 
Я (как уже говорил выше) - совершенно в этом не уверен.

На мой взгляд случилось страшное (за-скриньте этот пост!):

.... языки программирования каким то образом попали в нищу дешманских поп-товаров 8-\

И соответственно - их проектируют, изготавливают и вливают (методы рекламы) покупателям методами доказавшими свою эффективность именно в этой категории 8-\

ОдинадЦАтоГО дня Ноября, 2к23 года

ваш _

;-D

Ответить | Правка | Наверх | Cообщить модератору

186. "GitHub опубликовал статистику за 2023 год и назвал победител..."  +/
Сообщение от Прохожий (??), 11-Ноя-23, 19:47 
> языки программирования каким то образом попали в нищу дешманских поп-товаров

Я уже ответил каким. Да ты и сам это предположил чуть выше. Важен уровень вхождения, если речь идёт не о каких-то сверхкритичных к производительности или надёжности программах. Не понимаю, почему у тебя до сих пор сомнения. Кстати, таких непритязательных задач подавляющее большинство. Следовательно, для таких задач не нужна сверхквалифицированная рабочая сила, достаточно студентов третьего курса (бакалавров).

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру