- 1
https://www.php.net/manual/en/intro.parallel.php-
PHP / Говнокод #26586
0
Покайтесь! Пока вы называли пиздецом пандемию и всё с ней связанное, незаметно подкралось нечто действительно страшное.
Запостил:
Fike,
15 Апреля 2020
Follow us!
Нода - годная и удобная питушня. Одна из лучших систем в мире программ.
* Мультипарадигменность - можно писать в терминах предметной области, а не пердолиться с языком. Парадигма не навязывается. С функциями и прототипами можно сделать как ФП, так и ООП и мощнее.
* Не надо пердолиться с памятью.
* Не надо пердолиться с многопоточностью.
* Не надо пердолиться с переизбытком исключений.
* Не надо пердолиться с типами, в языке сделано логичное поведение: 1/2=0.5, 1+' рубль'='1 рубль', '1'/'2'=0.5.
* Встроенный гуй на человекопонятном HTML. Не нужно пердолиться с IDE.
* Истинная инкапсуляция. Переменные - в скоупах, за счёт замыканий можно всё скрыть, оставить только нужный интерфейс.
* Высокая абстрактность. Я могу практически всё засунуть в функцию и параметризовать. Не будет питушни с ранним переполнением стека или невозможностью вернуть из функции массив или потребности пользователя моей функции удалить этот массив. Единственная проблема - изменяемое состояние.
* Акцент на программиста, а не на байтоёбство: производители ВМ постоянно улучшают компилятор, а не заставляют учить кишки CPU и ОС.
* В языке исправляют баги и добавляют относительно адекватные фичи. В ES5 добавили функциональную питушню для массивах, в ES2016-ES2018 пофиксили коллбекоад, добавили модули и итерацию по массивам, для ноющих йажарабов сделали сахарок для ООП. Впилили BigInt, Map, Set и прочую питушню.
* Высокая доступность как по уровню знаний и простоте установки, так и по областям, где этот язык поддерживается - WSH, .NET, серверы, веб-сайты, приложения, даже микроконтроллеры. В браузерах - отличные IDE, с которыми не надо пердолиться; под V8 недавно сделали вычисление выражений до нажатия на Enter!
Конечно, не хватает в языке шаблонов и перегрузки операторов и функций, не хватает метатаблиц как в Lua, иногда печалит многословность и конфликт ООП и ФП из-за непроуманности местами. Но в целом это язык, на котором ты решаешь проблемы реального мира, а не пердолишься с инструментами.
'1' + '2' = 12
'1' - '2' = -1
'1' + '2' = '12'
+ '1' + '2' = 3
Всё отлично. Все возможности для получения адекватного результата без пердолинга.
А теперь попробуйте то же самое в "python".
в тендерной системе такое не пройдет
О, прикольная фича. Кстати в firefox тоже завезли.
Дык вроде уже несколько лет назад как завезли.
А годы назад были подсказки вида "Array.prototype.m... map?"
> А годы назад были подсказки вида "Array.prototype.m... map?"
Хз, точно не помню. Может, и были.
Упрощение жизни. console.log([1,2,3,4].join(', ')).python.png
> * Нету библиотек
Заинклюдил в HTML нужное - и работаешь. Можно было бы и без ES-модулей обойтись, но их уже завезли.
> * Ебучий груз обратной совместимости. Где еще такое есть?
Этот груз порою легче, чем в других языках. Кстати, arguments.callee и arguments.caller выпилили же вроде.
> "Мы ниасилили ООП, вот тебе пердольная эмуляция"
private static inline final const void* MyClass::myMethod () const; vs function () {}
Не надо помнить 50 оттенков статуса переменной, ты просто пишешь как есть. Если внутри функции - значит не увидят, если в this - увидят.
> Это называется сборка мусора, праграмист.
Я ему про инкапсуляцию, ортогональность, абстрактность и чуть-чуть сборку мусора, а он ухватил только последнее. Комментарий не читай, одно слово вылавливай.
>> скоупы
> Как давно они появились?
Не помню. 10 лет назад уже точно были. Может, с начала языка ещё.
Кстати, в ES2016 зачем-то ввели ещё более узкие скоупы с let.
> Что за ад?
Усложнение написания программы из-за коллбеков на коллбеках коллбеков }); }); });
> А ничего что жс в браузере и ноде отличается по апи?
Ничего. Питушни-то принципиально разные.
Хотя, было бы интересно, если бы сделали аналог printf, sprintf, fprintf и объединили бы файлы и HTML элементы.
fs.writeFileSync(form.field1, 'myvalue');
fs.writeFileSync(element.classList, 'myclass');
> А вот вне веба он нахера нужен?
Простой и удобный язык общего назначения. Нужен, чтобы писать код.
В этом плане JS ничем не отличается от других языков, где есть функции. Зависит только от конкретного программиста.
> сайт должен считаться с тем, что на него могут зайти с браузера 5+ летней давности
Не так актуально. Десктопная питушня обновляется сама, смартфоны старше пары лет тормозят, их выносят на свалку на потеху Сёме, который их перепродаёт туристам.
Есть питушня для унификации. Проверенная jQuery и уже целый зоопарк готовых решений - как библиотек, так и трансляторов кода.
>>хрюююю!
>Ясно.
Ко-ко-ко
> Это все - сборка мусора, праграмист. Ты кроме js на чем писал?
На C++.
Восьмишок, это не сборка мусора.
Длинный стек в функциональных языках - это не сборка мусора, это стек.
Невозможность вернуть массив - не отсутствие сборки мусора, а ошибка проектирования языка. В Паскале возвращают строки без сборки мусора. В C/C++ можно было сделать то же самое. double 64битный вернуть можно, а соединить 32 бита указателя на начало и 32 бита размера и вернуть почему-то не осилили.
Байтоёбство - это не свойство языков без сборки мусора. Байтоёбство связано с уровнем абстракции. Байтоёбить можно и в JS, благо там Buffer и typed arrays. Можно умножать сдвигами, работать с байтами. Там есть и asm.js и спецпитушня под видеокарты.
>из-за той самой обратной совместимости
> Вроде бабель есть
> await еще не везде зашел.
На клиенте он не так сильно нужен, там нет таких длинных цепочек асинхронной питушни. А на сервере не требуется поддерживать иные версии.
> И зачем ты их объединяешь?
Один и тот же удобный язык.
> Чем он лучше того же фитона?
Более адекватная парадигма, красивые скобочки как в сишке, адекватные лямбды вместо кастрированного говна. Конец коллекции - не исключение, console.log(1 + ' рубль') работает. Нормальный тернарник вместо рандомно перемешанных ключевых слов, нормальные x++, возвращающие выражение, а не костыльное :=, появившееся только недавно.
Есть кэш.
> И всё?
Не всё.
> Покажи мне язык со сборкой мусора где с этим проблемы.
Как ни странно, JavaScript и python. Вернул некоторую питушню, а она не прозрачна ссылочно. И вот, с одними объектами (строки, числа) можно работать безопасно, а с другими (коллекции, пользовательские) - нет.
Есть обратный пример по поводу возвращения массива. В C++ можно вернуть массив, хотя нет сборки мусора.
>> Можно умножать сдвигами, работать с байтами.
> И ты проиграешь, а не выиграешь.
То же самое в C/C++. Хотя нет, в них есть UB как шанс проиграть.
> Но слабая типизация на сервере? Накуа?
Для удобства.
> У тебя другие библиотеки, другой подход. Что там общее? Синтаксис?
Синтаксис, парадигмы, встроенные типы и коллекции. Как ни странно, есть много библиотек, которые работают и там, и там. Скажем, длинной арифметике пофиг, где её запускают.
> Это как питон для веб разработки и обертка напитоне для апи.
Как будто что-то плохое.
Я давно говорю, что надо иметь возможность выбрать любой язык, и что это команда программистов должна решать, с какими скобочками, в каких терминах и с какими сборками мусора реализовывать конкретный проект, а не авторы языка.
> Тебе не похуй?
Нет.
> Зачем тебе лямбды? Для коллбеков? Тебе await завезли наконец-то.
Для map/reduce/filter (for-of не предлагать, он хуже масштабируется), для параметризации функций кодом, когда надо выбрать одно дейтсвие из произвольного множества.
> а в ноде?
То же самое, там тоже есть консоль.
> Ок, а чем жс лучше %рандомный скриптовый язык с сиподобным синтаксисом%?
жс не нужно второй раз учить ради скриптушни. ну и дальше надо конкретно смотреть, что за язык.
Если в этом языке можно включать/выключать сборку мусора, строгость и явность типизации, отдельно включать/выключать конкретные фичи и произвольно менять синтаксис, чтобы настроить диалект под себя, то жс можно выкидывать на свалку в тот контейнер, откуда его никто не захочет подбирать.
не надо вдалбливать, я сам знаю, сам написал где-то тут в комментариях
> не надо второй раз учить сам язык, если всё остальное поменялось?
не всё, я же говорил
> В питоне для этого есть списковые выражения
Узкоспециализированная плохо расширяемая питушня, которую не везде применишь.
В питоне для этого есть map/reduce/filter
> основное назначение лямбд
Зависит от проекта.
Не гони. Возвращающий выражение «=» в булевом контексте — это одно из самых хуёвых рахитектурных решений сишки, которое как рак расползлось по многость языкам. Баги вида «if (user.id = ROOT) { print('You are root!'); }» на регулярной основе пишут все, а вылавливать их в коде длиннее джвух функций — абсолютно нереально без подсказок конпелятора. Поэтому отказ от этого наихуёвейшего поведения — правильное и грамотное решение Гвидо, который не зассал сделать «не как в цэ». Неправильное — то, что он не запилил оператор «:=», явным образом указывающий на происходящее присваивание, с самого начала.
Хорошо, когда язык ортогональный, ты можешь создавать из выражений конструкции, которые являются выражениями и нет из этого исключений.
Это не всегда хорошо, как прекрасно видно на реальном примере присваивания в условном операторе.
Множественные присваивания — это в 95% случаях тяжёлое наследие сишного режима, при котором переменные должны были быть объявлены в начале блока и обязательно явно инициализированы. В современных динамических языках без UB они нинужны.
> int i = if (x) y; else z;
Ну да, четыре строчки вместо одной. Зато в них нельзя запутаться; их назначение видно мгновенно, с первого взгляда; в них легко добавить произвольный код. Они максимально просты и понятны даже полному нубу — а я убеждён, что чем код проще и понятнее, тем он лучше.
> int j = (i = if (x) y; else z);
Аналогично, это код сишного хакера, экономящего на байтах, а никак не современного модного высокоуровневого JavaScript-программиста.
Это вообще проблема не условного оператора, а самого присваивания. Был, конечно какой-то язык, где в условиях "=" значил сравнение, а просто так - присваивание, но такая ко-ко-контекстая питушня - сложное говно.
Налажать с "=" vs "==" можно и в обычном коде.
Если бы сравнение описывалось оператором "=", а присваивание - ":", то проблемы бы не было.
Опять же, ортогональность всегда приятнее. Не какие-то исключения для отдельных операторов и конструкций, а консистентность. Язык - как конструктор, из маленьких кирпичиков создаются более крупные. Имея консистентность, надо учить меньше исключений, а значит программисты в среднем будут знать больше про язык без излишнего забивания головы.
Почему я могу писать a+b+c, а не могу a-b+c - только потому, что кому-то "-" показался выделенной операцией?
Кстати, C/C++ тоже говно. В отличие от JS/C# я не могу там нормально записать x=x++; из-за того, что компилятор мешает такой код в кашу и не соблюдает порядок в грязноимперативных конструкциях.
Да, разумеется. В «Паскале» всё именно так и сделано — присваивать значения через «:=», сравнивать — через «=». Подозреваю, что изначально это было предназначено для математухов, чтобы не вводить их в заблуждение (у них «:=» — это именно «присваивание», если точнее — «равно по определению»).
> Опять же, ортогональность всегда приятнее. Не какие-то исключения для отдельных операторов и конструкций, а консистентность.
Ну я же уже продемонстрировал, что «приятная» консистентность присваивания в итоге приводит к трудноуловимым и крайне опасным багам.
Более того, в реальных примерах языков полной ортогональности быть не может просто в силу того, что для её достижения необходимо определить операции для всех пар всех существующих типов, включая пользовательские.
Да, конечно, можно попробовать сделать «разумные» преобразования типов по-умолчанию… Но вот беда: у каждого человека есть своё мнение по поводу «разумности».
Ярчайший пример: Эйх решил, что преобразовывать всё в строку и складывать — это разумно. Результат — тонны полнейшего говна в духе «[1,2] + [3,4] == "1,23,4"».
Другой пример — как ни странно, «Питон» с его умножением. Да, «'x' * 3 == 'xxx'» выглядит круто, удобно и интуитивно. И «[1] * 3 == [1, 1, 1]» выглядит круто, удобно и интуитивно… Пока в очередной раз не выстрелишь себе в ногу мутабельностью списка.
И так — всегда: любая попытка выстроить идеальную систему неизбежно напорется на кучку мелких и вредных проблем.
А что мешает-то?
Вот я, например, конструкцию «x = x++» прочитал как «x присвоить значение x; после этого увеличить x на один». А как её понимаешь ты?
1. x++ === x=x0+1, return x0
2. x=(x++) === x=x0 === x=x
не понимаю, чем "x=y=1" плохо и чем оно хуже "x+y+1".
«x=y=1» «плохо» тем, что в современных динамических ЯВУ оно в большинстве случаев попросту нинужно.
>>> Множественные присваивания — это в 95% случаях тяжёлое наследие сишного режима, при котором переменные должны были быть объявлены в начале блока и обязательно явно инициализированы. В современных динамических языках без UB они нинужны.
UPD: но, конечно, его я выбрасывать не предлагаю, оно хотя бы в ногу не стреляет (чаще всего).
когда нумерация с 1, подход тоже работает:
Есть в этом деле какая-то красивая математика, какой-то функци­анальный подход.
Сильная типизация - вынужденное говно. Появилась из-за того, что
* на старых компьютерах легче было производить однотипные вычисления
* сложно было подумать и спроектировать адекватное межтиповое поведение
Сильная типизация чаще всего означает синдром вахтёра у автора языка. В "Haskell" нельзя сложить 1 и 1.0, если их положили в переменный. Но ради сохранения здравого смысла поехали кукухой и сделали литералы чисел полиморвными. 1+1.0 сработает, а (1::Int) + 1.0 - уже нет. Хотя сама математическая операция определена. Более того, математике эта сумма не противоречит.
Имеем костыли и недостаток проектирования в языке.
Сложение числа и строки - естественная операция с ожидаемым поведением, которую удобно использовать. Языки со "строгой" питуизацией используют её то тут, то там.
"Строгий" "python" на кой-то ляд даже специально ввёл умножение списка на число. Венец слабой типизации. Однако, более нужное ', '.join([1,2,3,4]) там всё ещё не работает.
По сути, строгопипизационные языки накидывают кучи явного точечного говна, чтобы добавить удобные операторы, чтобы языком можно было хоть как-то пользоваться и не блевать от "1+1 not defined exception". Вроде полиморфных чисел в хаскелях, умножения списков на число и булевания списков в питонах. В итоге, на выходе всё равно получается неконсистентное говно, где местами есть какие-то вольности, а местами вопреки математике не дают два числа банальных сложить.
В случае со слабой типизацией обычно хорошо продумывается, как будут работать операторы и как это поможет программисту, на выходе имеем консистентное поведение, но некоторое усложнение эффектов, если нагромоздить дохрена слабого говна. Однако, тут программист может легко распутать клубок и расставить asserts в нужных местах. Тогда, если нужно число, строка не пройдёт.
> Умножение списка на число - это не приведение типов
Фактически не важно, типизация слабая или нет и что там с приведением типов. Важно, какой интерфейс предоставляет язык для пользователя.
Какая мне, программисту, разница, 'a'+1 будет явно прописанным оператором, который аллоцирует строку побольше и делает туда sprintf(..., "%s%d", ...), либо же приводит 1 к строке, а затем совершает конкатенацию? Результат будет совершенно одинаковый. После прохода оптимизатором и код будет совершенно одинаковый.
Какая мне разница, [1,2,3]*3 - это исполнение оператора умножения или набор кастов, если результат одинаковый?
Важно только то, насколько удобный интерфейс предоставляет язык.
> Доведение до абсурда
Я просто показал отдельные примеры плохого проектирования. Дальше внимательный читатель может подумать и экстраполировать самостоятельно.
Я только показал общую тенденцию: чтобы спасти интерфейс языка, вместо слабой типизации в язык втыкают набор явных операций для частичной эмуляции эффекта слабой типизации.
> это незнание и отсутствие опыта за пределами
Это попытка поразмыслить не по шаблону. Вчера хвалили ООП и сильную типизацию, сегодня хвалят ФП и 100500 пакетов в Node, завтра ещё что-то похвалят. Но следует не присоединяться к сектам, а самостоятельно проверять.
Вывод типов и генерация кода под конкретные типы, конечно, удобны. Но не нужно бросаться в крайности. Послабление типизации удобно на практике.
> Кому настолько важно не писать лишний map?
Мне. Мне сказали, что python - язык для удобного написания программ, а не пердолинга с конвертацией очевидных данных.
> Слабая типизация - это и есть то от чего надо спасать. Дискасс?
Спасать надо от нелогичного поведения или поведения, вызывающего баги.
а) 1+1.0 вызывает ошибку - говно, т.к. язык становится неудобным и многословным говном. Больше кода - больше багов. Причина: недопущение математически корректной операции.
б) 1+'1' = '11' - потенциальное говно, т.к. в нетривиальном коде порождает нетривиальные баги. Чем больше граф кода - тем сложнее распутать. Причина: смешение двух операций под одним символом.
в) 1-'1' = 0 - ожидаемое и удобное поведение. Не вызывает проблем, работает как положено.
Соответственно, правильным вариантом было бы ввести слабую типизацию, где
а) можно сложить 1 и 1.0
б) оператор плюс всегда кастует к числу и осуществляет сложение
в) для конкатенации есть отдельный символ, он не-строки приводит к строке
г) оператор минус всегда кастует к числу и осуществляет вычитание
> самое важное в питоне - то, что он не складывает число со строкой
Самое важное - что он не складывает строки со строками. И ты пердолишься со всем графом программы, чтобы понять, где подписать u, где убрать u, где как правильно явно кастануть к какой-то питушне. То ли дело JS: там сразу Unicode без пердолинга, а Buffer просто так нигде не вылезает, он явно создаётся и явно/неявно кастуется в строку по желанию программиста.
> для конкатенации есть отдельный символ
Привет, Perl.
В общем, проблемы сильной/слабой типизации сводятся к тому, то
1. легальную операцию не дают выполнить без пердолинга и поклонов языку
2. создаётся возможность сделать неоднозначную питушню
Соответственно, нужно делать полиморфные однозначные операции, которые делают то и только то, что они должны делать, и делают это хорошо. Тогда продуманная слабая типизация посадит на флешку непродуманные слабую/сильную.
Например, как по мне
* null и undefined в JS - говно, достаточно чего-то одного
* преобразование [] к False в python (привет, слабый питух) - удобная фича, преобразование [] к true в JS - неудобное говно
* неравенство '' и null в SQL и JS, а также NULL и "" в C - неудобное говно
* синтаксис вида $arr[] = 1; (точно не помню) в PHP для добавления элементов в массив, которого даже может не быть - лютый вин, который поднимает динамическую неявняю питуизацию PHP выше уровня C++, где то же осуществляется за счёт явного задания типа переменной.
* синтаксис x['aaa'] ++; в C++ - лютый вин, т.к. не надо писать явно и козлу понятные if(find != end) x['aaa'] = 0;
* x['not_an_element'] = undefined в JS - вин, а exception в python - говно
* x['y']['z'] в JS - лютое говно, т.к. не работает, если x.y не объект
То есть различие нулевого указателя и пустой строки/массива - питушня, интересная только для сборщика мусора или владельца блока памяти, пользователю значения это уже не важно. Алгоритмы - не алкаши у ларька, для алгоритмов совсем не важно, элементов "нет", "совсем нет" или "совсем-совсем нет". И сравнение с пустотами различных порядков - лишняя трата времени программиста.
Явное хранение undefined или отсутствие элемента - неважное отличие. Исключением может быть только эмуляция set в JS на {} - проверять элемент как x['aaa'] или как 'aaa' in x, но об этом можно договориться и проверять как x['aaa'].
Возможность иметь операцию, которая сделает неявное if (not exists) create; - экономия времени и повышение корректности программы.
Сейчас его просто надо не передавать.
> дефолтовый аргумент
Кстати да, интересная проблема. Об этом не подумал, эта штука всё портит, т.к. подразумевает три класса значения - пустое присутствующее, непустое присутствующее и отсутствующее. Интересно, можно ли как-то упростить, чтобы и вызов функций явный работал, и всякие call/apply с подстановкой аргументов, и аргументы по умолчанию тоже работали?
Или тупо считать, что если у аргумента есть значение по умолчанию, то оно вставляется вместо отсутствующего/пустого?
А то иначе начинается 16+ вариантов инициализации полей в C++ с хитрым графом правил.
> x.get('not_an_element). Ты всё остальное о чем тут рассуждаешь знаешь так же хорошо?
Да. Так же хорошо.
Когда дело касается языка, можно рассматривать код с разных точек зрения. Можно анализировать функциональность и плевать на конкретное выражение. Можно смотреть с точки зрения написания.
Я смотрю с точки зрения написания. Разумеется, x['not_an_element'] и x.get('not_an_element) - разные конструкции. И поведение JS на x['not_an_element'] отличается от поведения python на x['not_an_element'].
Аналогично, в C++ есть проверка границ, только нужно писать x.at(2) вместо x[2].
Я бы сделал какое-то включение/выключение проверки, чтобы в одном случае x['not_an_element'] возвращало пустое значение, а в другом - бросало исключение. Что-то вроде того, как можно настроить, чтобы арифметические операции вырабатывали сигнальный NaN и программа падала, а можно - обмазываться NaNами и решать вопрос накопившейся питушни при выводе результатов.
get_a возращает None, внутри func a должно быть именно эквивалентно None, но не default?
Не уверен, нужно ли это. В JS из-за этого возникла какая-то параша, где различие null/undefined/отсутствие особо не помогает. Получается пердолинг с лишними проверками.
В JS может быть null, undefined и не переданное значение (arguments.length < func.length). А в объекте - null, undefined, отсутствие значения, значение null/undefined в прототипе и т.д. Приходится разбираться в сортах всего этого говна.
Если мы вошли в парашу, где можно использовать значение функции, которая ничего не возвращает, то не надо различать отсутствие аргумента и аргумент-пустоту.
передать не переданное - либо явно его не писать, либо передать массив покороче в Function.prototype.apply
Бинарные строки - это атавизм питона. Больше такой хуйни нигде нет. У остальных это называется байтовым массивом, без какого-либо намёка на строки. В жс это ArrayBuffer.
Спасибо! Приятно поговорить со вдумчивым человеком.
> а как вы читаете файлы?
Если рассматривать Node.js, то там универсальный интерфейс, который работает как со строками, так и с Buffer.
Чтение возвращает Buffer, ему можно сделать String() или +''. Или .toString('myencoding'), если там что-то хитрое с кодировкой.
Запись принимает String или Buffer, всё прозрачно работает.
Есть версии функций для чтения/записи целиком, есть для append в конец - всё по имени файла. Есть которые принимают дескриптор файла, буфер, размеры и смещения.
Как под WSH - не помню.
* Можно назначать элементы-числа от 0 до 255.
* Можно передавать буфер по ссылке, в отличие от строки.
* Можно преобразовать в строки и обратно.
* Есть вспомогательный набор методов для расширенного пердолинга (например, writeBigInt64LE).
В js удобных слайсов нет, питоняшкам придётся пердолиться.
And what is about python? You get a runnable script if and only if you had been fuckering yourself a lot with the python mystery rustery for a long time. It's not the python way, it's the C++ ugly rusteraic road.
А вот чтобы поставить «Node.js», который «just works fine», мне на своём «Дебиане» пришлось довольно длительное время пердолиться, потому что по-умолчанию из дебиановских реп ставится какое-то древнее говно, в котором даже примеры из туториала с официального сайта не работают. Для установки нового надо посетить https://nodejs.org/en/download/package-manager, оттуда перейти по ссылке «Node.js binary distributions are available from NodeSource» (https://github.com/nodesource/distributions/blob/master/README.md), понять, какая версия нужна (10.x, 12.x, 13.x), выполнить
получить трояна в системе и потом ещё думать, нужно ли тебе «To compile and install native addons from npm you may also need to install build tools». Ну и после этого там ещё идёт целый экран мануала по добавлению нужного репозитория «If you're not a fan of curl <url> | bash -».
Точно «just works fine»?
Помню, хотел установить на чуть-чуть (несколько лет) устаревший луникс ноду (линтухи любят говорить о стабильности, но когда линукс долго стабильно работает, оказывается, что он внезапно отстал от остального мира, и на нём уже ничего не работает, в то время как анскильная виндушня годы получает обновление на вин7). В итоге, в репозитории была какая-то питушня, которая ещё и не собиралась. Я долго пердолился с установкой каких-то отдельных зависимостей, но ничего так и не завелось, кроме очень-очень-очень старой версии.
Потом до меня дошло, что можно просто скачать экзешник с официального сайта ноды. И тут вдруг оказалось, что всё работает в один клик. Ты просто берёшь готовое приложение. Десяток мегабайт исполняемого кода, в который вкомпилены все нужные библиотеки. И он просто работает, ты не пердолишься с зависимостями, которые ко-ко-ко-кетный менеджер не хочет резолвить!
Я так и не понял, зачем раскладывать зависимости по отдельным сущностям и в то же время запрещать иметь установленные несколько версий библиотеки одновременно, вызывая невозможность одновременно иметь две разные софтины, которые хотят видеть разные версии какой-то библиотеки одновременно, если можно всё нужное собрать вместе и получить гарантированную работу?
> две разные софтины, которые хотят видеть разные версии какой-то библиотеки одновременно
Проблема — в «хотят видеть». Так уж сложилось, что вся эта система зависимостей и пакетов проектировалась во времена, когда весь* софт был написан на сишке или ещё чем подревнее, а ни в сишке, ни в чём подревнее попросту нет инструментов, позволяющих сказать «заинклудь мне либу такую-то, версий от 1.2.3 до 1.3.5».
— какую версию «Буста» я заинклудил?
Ни в сишке, ни в крестах нет «параметра -I». Средствами языка я не могу указать, какая версия зависимости требуется моей программе. Вот в «NodeJS» я (1024-- поправит, если что) могу сказать: моему пакету для работы требуется пакет left-pad версий 1.2.*, другие не нужны — и менеджер пакетов поставит точно то, что мне нужно. В «Python» то же самое делается через жопу «requirements.txt», который хоть и со скрипом, но всё же является частью спецификации языка.
А вот в сишке и крестах попросту нет стандартного способа сказать, какие нужны версии библиотек. В них, если уж на то пошло, даже стандартного пакетного менеджера нет.
Во втором комментарии я даже отдельно подчеркнул слово NodeJS.
> в половине пакетов нет никакого requiremnets.txt, а есть setup.py.
«requirements.txt» предназначен для установки зависимостей приложения, «setup.py» — средство для установки пакетов. И да, оно полностью поддерживается pip-ом и имеет доку на официальном сайте: https://docs.python.org/3/distutils/setupscript.html.
> а еще есть pipenv, а еще есть poetry
Круто. И чо?
> в питоне есть более одного способа описать версии пакетов
Но они есть, и работают поверх де-факто стандартного пакетного менеджера.
Для си и крестов не существует и не существовало стандартного способа указать, какую версию зависимости требует приложение.
Ну нет, там нельзя указать произвольную версию либы, да и имеющаяся обычно довольно старая. Всё-таки это далеко не npm и не pip.
А у питона и жс такой де-факто репозиторий есть. И даже изкоробки инструменты для него ставятся.
Программировать на «Debian» не умею, сорри.
> да почему он стандартный то?
Потому что он описан на официальном сайте языка: https://packaging.python.org/tutorials/installing-packages/. То, что датасаентисты придумали себе какие-то нестандартные инструменты — это только их дела.
> для питона и на JS тоже, только для конкретной тулы или для конкретной реализации
Хоспади…
Хорошо, вот пример: я пишу прогу, проге требуется либа OhuennyLiba версий 1.2.*. В «Питоне» я написал прогу, добавил к проге requirements.txt с «OhuennyLiba>=1.2,<1.3», загрузил на «Гитхаб» — и всё. Все пользователи стандартных поставок «Питона» (а это — абсолютное большинство) смогут без пердолинга запустить моё приложение на любой поддерживаемой платформе. Поставят они OhuennyLiba в системный pip, создадут virtualenv, запакуют в «Докер» — это уже совершенно неважно. Важно то, что есть стандартный, кроссплатформенный инструмент для указания и разрешения зависимостей.
Ни для сей, ни для крестов такого инструмента нет. Есть только куча разрозненных, некроссплатформенных и принципиально несовместимых решений. Единственный действительно универсальный метод — указать нужные либы в README.md, а дальше пусть пользователи сами ебутся, как им нужные версии искать и как их устанавливать.
В последнее время ситуация стала улучшаться: появились, например, «conan.io» и «vcpkg» (последним я сам успешно пользуюсь, хорошая штука), но до звания хотя бы де-факто стандарта им очень-очень далеко.
> но в рамках одной ОС эта проблема легко решается
Ограничиваться рамками одной ОС было нормально лет двадцать-тридцать назад (да и то, «Java» с её реально революционной идеей «write once, run everywhere» вышла аж двадцать пять лет назад). Сейчас, к счастью, есть куча инструментов, благодаря которым можно писать действительно универсальный и кроссплатформенный код, который можно спокойно и без пердолинга запускать пусть и не совсем everywhere, но на огромном спектре устройств и систем — точно.
> и да: ни то, ни другое не часть языка
И то, и другое — это инструменты, про которые написано на официальных сайтах соответствующих языков/платформ. И тот, и другой инструмент входят в официальные сборки соответствующих языков/платформ. И про тот, и про другой инструмент написано в абсолютном большинстве туториалов.
Совокупность этих факторов и делает соответствующие инструменты стандартными.
Вот ещё один пример стандартного инструмента для разрешения зависимостей: https://doc.rust-lang.org/cargo/index.html. Описан на официальном сайте, входит в официальные сборки, упомянут во всех туториалах.
Однако вакансии «Программист Node.JS» я видел, а вот «Программист Debian» — нет.
> Debian позволяет тебе запускать написанный на си код под x86
А как мне его запустить на «Windows 7»? Только, пожалуйста, без виртуалок: они тормозят. Нужен нативный .exe.
> Это всего лишь его реализация
Это не реализация, это кроссплатформенное окружение.
> Я же не называю МСДН официальным сайтом языка С++
Я тоже не называю nodejs.org официальным сайтом языка JavaScript.
Т.е. C, C++ и C# — это тоже не языки?
> А как мне запустить твой NodeJS на vxworks? А на ios как?
Собери из исходников и запусти, делов-то.
> тогда зачем говорить, что в JS есть способ описания зависимостей?
Ты издеваешься?
https://govnokod.ru/26586#comment541105
>>> Ни в сишке, ни в крестах нет «параметра -I». Средствами языка я не могу указать, какая версия зависимости требуется моей программе. Вот в «NodeJS» я (1024-- поправит, если что) могу сказать
Ну да, если приёбываться к запятым, то мне следовало добавить «средствами языка/платформы». Однако де-факто «NodeJS» — это отдельный язык, надстройка над «JS», хотя бы потому, что в «JS» нет никакого «require», а в «NodeJS» он есть.
И зачем приёбываться к запятым, если и так всё понятно?
Впрочем, мы отклонились от темы: в «Python», «Rust», «NodeJS» и «Debian» есть стандартные способы описания зависимостей, в «C» и «C++» их нет.
Нет.
> нет.
Де-факто — да.
> Так что VisualC это отдельный язык, так что ли?
Удивительно, но да, его можно считать отдельным языком. Просто потому, что знающий C + позиксную линушню не сможет сколько-нибудь эффективно писать под винапи.
Вся проблема в том, что ты рассматриваешь понятие «язык» так, как это делали дедушки айти, создавшие старые добрые коболы, сишки, кресты и даже — отчасти — джаву. Собственно, с их точки зрения «язык» — это просто набор правил синтаксиса, ключевые слова и стандартная библиотека. Однако многолетняя практика показала, что такой подход — ошибочен. Большинство более-менее современных и популярных ЯП расширяют понятие «языка программирования» до «экосистемы». Поэтому в наше время «язык» — это не просто тупой список кивордов, а вообще всё то, что позволяет программисту взять и написать требуемую программу при помощи того самого списка ключевых слов. Самый же главный инструмент в экосистеме — это пакетный менеджер, который даёт программисту возможность не ебаться с ключами компиляции, способом линковки либ и компиляцией их из исходников, а взять и сделать. It just works!
Максимально простой и удобный пакетный менеджер «Ноды» (пожертвовавший гигабайты места в пользу удобства) — это одно из главнейших достижений её создателей, обеспечивший ей ошеломительный успех.
> Ну вот оказалось, что и в JavaScript их нет...
Приведи мою цитату, в которой я утверждаю обратное. Со ссылкой на соответствующий комментарий.
> практика показала — ошибочен. ЯП расширяют понятие «языка программирования» до «экосистемы».
Прости, Юра...
Очень печально, что сейчас популярна эта говноидеология. Языки должны быть именно набором правил синтаксиса - ключевыми словами и скобочками.
И программист должен выбирать язык под задачу исходя из его выразительности, а не исходя из того, что это единственный язык, для которого есть компилятор под целевую архитектуру или единственный язык, для которого написана библиотека для его предметной областти.
Спасибо JS за его говнистость, которая убедила 100500 человек написать свою питушню, транслирующуюся в JS и трансляторы нового говна в старое говно так, чтобы напердоленные потом и кровью библиотеки не пришлось выкидывать.
Сразу видно человека, который мало ебался с попыткой кроссплатформенно впилить в крестопроект очередную либу.
Отсутствие в экосистеме стандартных инструментов приводит только к тому, что в ней появляются охулиарды нестандартных говноутилит, никакие две из которых не совместимы между собой. И на удобстве программирования это сказывается фатально.
> И программист должен выбирать язык под задачу исходя из его выразительности, а не исходя из того, что это единственный язык, для которого есть компилятор под целевую архитектуру или единственный язык, для которого написана библиотека для его предметной областти.
Не понимаю, как это относится к утверждению о том, что создатели языка программирования должны думать о том, как будет выглядеть цикл разработки ПО на их языке целиком, а не просто придумывать ключевые слова и течь.
Это проблемы экосистемы, а не языка. Когда я говорю, что языки должны быть только правилами и ключевыми словами, я не добавляю "а экосистемы - пустым репозиторием, куда никто не может ничего добавлять". Конечно же, экосистемы должны быть достойными.
> Не понимаю, как это относится к утверждению о том, что создатели языка программирования должны думать о том, как будет выглядеть цикл разработки ПО на их языке целиком
Сейчас создатели языка (не только авторы самого языка, но и авторы популярных библиотек, если говорить о новом значении языка) пердолятся и создают всё говно заново. Максимум красят сишные вызовы в свои "методы", "операторы" и "глаголы".
Язык приравнен и привязан к своей экосистеме. И это говно.
У одной экосистемы должно быть несколько языков. Авторам языка должно быть вовсе пофиг на цикл разработки ПО. Они придумывают удобные скобочки и то, как выглядит функция (одни красят сишные, другие добавляют исключения по краям, ..) и уходят в закат. Авторы библиотек смотрят, как было бы удобно взаимодействовать с реальным миром и решать проблемы поудобнее и делают библиотеки, выбирая языки реализации по своему усмотрению. Пользователи видят языки и библиотеки и выбирают их кобенацию под задачу.
Это устаревший и ошибочный подход. Гуест8 ниже привёл реальный пример: Эйху было пофиг на цикл разработки ПО, он просто придумал скобочки и потёк. А теперь, когда оказалось, что в любом более-менее крупном ПО используются модули, стандартизаторам «ДжаваСкрипта» (кто они, кстати?) приходится устраивать блядский цирк с несовместимыми версиями и представления «2 -> 3» в миниатюре.
Язык, который разрабатывается оторванным от реального мира, получится, как это ни странно, оторванным от реального мира и никому не нужным. Создатель языка, если он хочет получить хороший, годный продукт, должен продумывать, как его язык будут использовать конечные пользователи (т.е. программисты).
Да, во времена сишки никому не было дела до менеджеров пакетов, автоматических тестов, CI/CD и прочей зумерской питушни, поэтому Ритчи мог просто придумать скобочки и уйти в запой. Но увы, те времена давно прошли.
> У одной экосистемы должно быть несколько языков.
Нереализуемо.
Может быть, но это не обязательно. Плохие языки сами отомрут в конкурентной борьбе, если есть выбор.
Какие-то языки удобны только для написания факториалов или конструирования примеров в научных статьях, и думать, как на них пишут ПО, просто не нужно.
> Нереализуемо.
Телеграмма: платформы .NET не существует, F# умер в гараже.
Я специально перед слово «должен» добавил условие: «если он хочет получить хороший, годный продукт».
> Телеграмма: платформы .NET не существует, F# умер в гараже.
И кому из этой платформы нужно что-то кроме «C#»? Её на ГК уже о(б)суждали и пришли к выводу, что любой <язык>.NET — это тот же «C#», только кривой и с костылями. Просто потому, что если платформа диктует наличие, например, исключений, то во всех языках платформы должны быть либо исключения, либо убогие костыли для их эмуляции. Если платформа диктует наличие потоков — в языках должны быть потоки. Если платформа диктует наличие фиксированных интов — в языках должны быть фиксированные инты, а языки с бигинтами идут нахуй.
А «F#»… https://www.tiobe.com/tiobe-index/: «Logo», «Lisp», «F#», «Fortran», «Lua», «Ada». Так что да, умер в гараже.
А мы его закопали.
Какой багор (((
Но так-то у них фешарп выше луа, эрланга, тайпскрипта, джулии, груви и баша.
То её шлют нахер!
Я не зря как пример привёл F#. Платформа диктовала какую-то ООПитушню, но всё же сделали нормальный язык.
И вскукареки платформы никто не слушал. Чего не хватало - добили в платформу. Чего не было в языке - проэмулировали.
Кстати, в JScript.NET есть eval. Хотя, программы на этом языке необходимо компилировать с помощью jsc, они сами по себе не работат.
И да, в C# строгая питуизация, и хотя платформа что-то там кукарекает, в JScript.NET, как и в TypeScript (вореятно, M$ переиспользовало код между этими двумя языками) можно как оставить всё без типов, так и прихреначить конкретные. И в итоге всё работает. И даже строку можно из числа вычесть.
JS диктовал коллбекоад, но к нему прикрутили генераторы и сделали await.
А пистон - это сишка (см. стандартную библиотеку - калька сишки), но там добавили длинный шмель инт. И хаскель - тоже сишка, но там тоже длинты есть.
Если мне нужен длинт, то я делаю библиотеку для его поддержки всей платформой. Если нужны литералы длинта, я вставляю в транслятор преобразование "123bi" -> "new BigInt(123)".
Даже в C# этот функционал "распаян" через ключ.слово "dynamic" (хотя и не приветствуется).
Который никому не нужен.
> Чего не хватало - добили в платформу. Чего не было в языке - проэмулировали.
В результате эмулированное говно тормозит, а добавленное в платформу неимоверно раздувает её, что можно делать только до некоторого предела.
Рассуждая об универсальной платформе, ты забываешь одну простую вещь: чем крупнее система — тем больше в ней багов, причём количество ошибок от размера растёт далеко не линейно (просто потому, что с каждым добавленным в систему элементом количество связей между элементами растёт квадратично). В том числе и по этой причине «KISS» — один из главных принципов программирования.
> И в итоге всё работает.
*Тормозит, как и любая многослойная эмуляция.
> JS диктовал коллбекоад, но к нему прикрутили генераторы и сделали await.
Совсем не в тему, «JS» не привязан ни к какой экосистеме.
> А пистон - это сишка (см. стандартную библиотеку - калька сишки)
Слишком толсто.
> Если мне нужен длинт, то я делаю библиотеку для его поддержки всей платформой.
И добавляешь его поддержку во все остальные библиотеки платформы. Иначе у тебя получится не платформа, а неконсистентное говно.
Разумеется, на каждый экзотический язык найдётся свой юзер, но общей тенденции это не отменяет.
PS,
UPD: упс, проебался с «#».
ну тогда скала, груви и даже котлин не нужны
>Haskell
хаскель нужен, разумеется.
Они существенно больше нужны, как в абсолютных числах, так и в относительных.
9197 vs 346
точно существенно больше?
К тому же, ты взял самый малопопулярный язык из названной тройки, в рейтинге TIOBE он почти в два раза отстаёт от «F#» (при этом «Kotlin» и «Scala» его обгоняют, а последняя вообще чуть-чуть не дотягивает до захайпанного «Rust»).
Мы сравнивали "флагманский" язык виртуальной машины с его альтернативами же.
TIOBE вообще странный. Смотри, как растет полуярность VB:
https://www.tiobe.com/tiobe-index/visual-basic/
Да.
Честно говоря, особо странного на графике не вижу, это же относительные цифры, на них влияет популярность всех языков из рейтинга.
Тем не менее, вступаться за абсолютную объективность «TIOBE» я тоже не могу (поэтому и принял предложенный гуестом8 рейтинг популярности по количеству компаний). Других похожих рейтингов я не знаю, только «RedMonk Programming Language Rankings», но они там считают исключительно «SO»/«Github», а наличие в рейтинге некоего языка под названием «Arduino» внушает некоторые опасения в качестве анализируемых данных: https://redmonk.com/sogrady/files/2020/02/lang.rank_.120.wm_.png (NB: и даже в этом рейтинге «F#» сидит рядом с «Фортраном»).
Ну правильно. В Сишке нету никаких public, bool и private.
Так же в Сишке нету бойлерплейтных конструкторов.
Сишка — самая выразительная.
Подтверждаю.
Ну и кто после этого бойлерплейтное говно?!
[/tsar]
Скриптухи всё украли из Сишки:
>public class Employee
>struct Employee
> Guid.NewGuid()
Guid_NewGuid()
Или вообще {0x8f38f1b1, 0x1a270x4f1a, 0xba3600d34, 0x209fc92}, нахрена этот боейлерплейт?!
[/tsar]
Крупнейшная розничная сеть, годовой оборот 512,283 млрд дол.
И вот эта компания вот
https://devblogs.nvidia.com/jet-gpu-powered-fulfillment/
Поэтому оценивать популярность языка как обобщённый показатель его удобства нужно именно по новым, стильным, молодёжным компаниям (см. «Discord» — как бы я его не презирал, но эти ребята используют самые bleeding-edge технологии, зачастую в самом прямом смысле из nightly-сборок).
«Python», «Rust» и «Elixir».
https://blog.discord.com/tagged/engineering
Не нужны.
>Haskell
В особенности не нужен.
УРА!
Боже Царя храни!
>GitHub
Кот бы сомневался. Git написан на сишке.
Питушня. Не понял, мы тут обсуждаем толпы макак, которые лавинообразно выбрали язык из-за того, что толпы макак его выбрали, или конкретно языки?
> эмулированное говно тормозит
Питушня. У процессора есть указатели и нет шаблонов.
В C есть указатели и нет шаблонов.
В C++ шаблоны прикручены сверху - эмулированное говно.
Но код с void* тормозит больше, чем эмулированный шаблонный код.
> Тормозит, как и любая многослойная эмуляция.
Компиляция убивает многослойную эмуляцию.
> «JS» не привязан ни к какой экосистеме.
Не важно, уровень абстракции тот же. Новая фича безболезненно реализована, могла бы быть просто трансляцией кода.
> добавляешь его поддержку во все остальные библиотеки платформы.
Это в худшем несбыточном случае. Фактически будет какое-то подмножество, на которое должны будут распространиться изменения, да.
Обсуждать языки вне контекста их использования — затея малополезная, таким заниматься имеет смысл разве что математикам.
Вместо того чтобы называть «толпы макак» макаками, выбравшими неправильный язык, необходимо понять, почему они его выбрали. И нет, легаси — это только один из многих факторов, а не единственный (хотя, конечно, в случае самых «крупных»
и старых языков — один из самых главных).
Я категорически против подхода «программирование ради программирования». Любой полезный программный продукт необходим для того, чтобы его использовали люди. Неважно, будут это обычные юзеры, программисты, девопсы, тестеры, интеграторы или кто-нибудь ещё. Важно, что это будут люди. И языки программирования — не исключение.
И именно поэтому среди семейства языков с плюс-минус одинаковыми возможностями и областью применения популярным будет не тот, который «выразительный», «безопасный», «крутой», а всего-навсего тот, который удобен. Причём удобен не для бородатых математиков из Раш-ки, а для среднестатистической макаки.
Собственно, твоя идея с единой платформой и множеством языков, конечно, выглядит круто… Но популярной она не будет. Просто потому, что среднестатистической макаке не нужно много языков на все случаи жизни, для неё учить эти самые «много языков» тяжело (как и для любого человека, кстати). Среднестатистической макаке нужен один язык, которым среднестатистическая макака будет решать все возникающие перед ней задачи.
> Компиляция убивает многослойную эмуляцию.
Но только в нативный код, а не в байт-код ВМ. См. «JIT».
> Новая фича безболезненно реализована
Настолько «безболезненно», что аж надо идти на caniuse.com и проверять, можно её использовать, или отвалится слишком много клиентов.
Снобство в духе «макаки тупые, поэтому пишут на похапэ, а не на хачкеле» хоть и в некотором смысле верно, но абсолютно бесполезно.
Это плохой пример. «Вайбер», «Воцап» и «Зум» нужны исключительно для того, чтобы общаться с другими макаками, никакого иного применения у них нет. Поэтому если у человека всё окружение сидит в одном из этих говн — человеку придётся выбирать говно, и к стайности это не имеет никакого отношения.
> Может быть VS Code удобнее всех?
Да. Несмотря на то, что это жабаскриптное говно, «VS Code» — удобное и универсальное говно, позволяющее максимально быстро и просто организовать рабочую область из нескольких проектов на разных языках. «NGK», например, я правлю именно через него, потому что он мне даёт подсветочку, IntelliSense и тайпчекер как для «Python», так и для «JavaScript» (в последнем случае, правда, без тайпчекера — он у них для «TypeScript», но это наверняка можно исправить расширениями). А ещё, в отличие от всяческих IDE на «Java», у него нет уёбищных микролагов ввода.
Подтверждаю.
> Почему они ушли со скайпа, где сидели в 2008-м?
Потому что «Скайп» не предоставлял тех фич, которые были в упомянутых говнах. Как самый базовый пример — удобный мобильный клиент и привязку к номерам телефонов, благодаря которой тот же «WhatsApp» может почти прозрачно заменить обычный телефон.
Ну и да, а о том, чтобы макаки узнали про наличие этих фич, позаботились те самые маркетологи.
> Может быть они были хуже яблов и андроида?
Это неправильная постановка вопроса. Правильная: чем они были лучше яблов и андроида?
> Spyder
>>> Spyder is a powerful scientific environment written in Python, for Python, and designed by and for scientists,
Я не scientist, и мне не нужно* environment for Python.
Ну и вот я решил его скачать и попробовать, а мне предлагают «Download Spyder with Anaconda». В разделе «full installation instructions» есть только «Spyder is also included in the WinPython scientific Python distribution». А мне не нужна эта научная питушня, мне нужна IDE! Ну ок, листаю дальше, в раздел для «экспертов», вижу там такое сообщение:
Охуенно! То ли дело этот парашный «VS Code», который просто скачиваешь и просто устанавливаешь.
Ну да ладно, ставлю через «pip», попробую.
> именно потому, что у них нет маркетологов
В таком случае, кто платит миллиарды долларов маркетологам за то, чтобы они пиарили «PHP» (раньше), «JavaScript», «Python» и «NodeJS»?
Ситуация как с современным тяжеловесным говном.
"У тебя компьютер новый - разберётся" (Хотя, можно было написать программу как надо, чтоб не тормозила)
"У тебя научный работник умный - разберётся" (Хотя, можно было сделать как для тупых скриптухоы)
Вот, он у меня успешно установился через «pip» (попутно откатив «parso» и «jedi» до старых версий, но да хуй с ними). Заебись, запускаем!..
Так, стоп, а как? На «Рабочем столе» ярлычка не появилось, в «Пуске» — пусто, и даже прыщепердольные «spyder» и «python -m spyder» в консоли не работают. Ну ладно, видимо, я недостаточно «expert», возвращаемся на офсайт, доку читать.
Ой, а на сайте в разделе «для экспертов» ничего нет!
— всё, дальше идёт раздел «запуск из исходных кодов» (спасибо, не надо).
В «FAQ» и «Wiki» аналогично: по вопросу запуска сего поделия — пустота.
Багор, как есть багор!
Ну ладно, мы не гордые, мы пойдём в «Гугл» и накопаем древний вопрос с SO (слава SO!): https://stackoverflow.com/questions/44956371/how-to-start-spyder-ide-on-windows: оказывается, сию бандуру надо запускать через «spyder3». Очень интуитивно.
Итак, момент истины! Запускаю!
…И нихуя не происходит. Вот уже больше пяти минут передо мной открыто совершенно белое зависшее окно: https://i.imgur.com/otHFh8f.png (причём зависло оно сурово, похоже на дедлок — из всей кучки запущенных процессов активен только «pythonw.exe», да и тот кушает 0.1% проца).
Ладно, пришибаем, пробуем заново. Минута, висим. Пробуем из другой консоли. Висим с теми же симптомами. Пробуем указанный в том же вопросе «from spyder.app import start; start.main()» — висим.
Ну ладно, видимо, это — те самые обещанные «tricky issues». Попробую поставить этот продукт в отдельное окружение и написать третью часть эпопеи.
PS, но вот ведь какие макаки тупые — повелись на маркетологов «Майкрософта», скачали инсталлер, установили, запустили этот треклятый «VS Code» двумя щелчками мышки и потекли! А как же попердолиться?!
Ну что же, давайте пердолиться!
gost@gost-pc F:\dev\spyder
$ virtualenv spyder
created virtual environment CPython3.8.2.final.0-64 in 306ms
[...]
gost@gost-pc F:\dev\spyder
$ cd spyder
gost@gost-pc F:\dev\spyder\spyder
$ call Scripts\activate.bat
(spyder) gost@gost-pc F:\dev\spyder\spyder
$ pip install spyder
Collecting spyder
[...]
Successfully built numpydoc intervaltree watchdog [...]
(spyder) gost@gost-pc F:\dev\spyder\spyder
$ spyder3
«Хер тебе в рыло, сраный урод!», — как бы говорят мне разработчики этой, наверняка очень крутой, IDE. То же белое окно, те же зависшие в дедлоке процессы. «from spyder.app import start; start.main()» ничего не меняет, да и не должно, в принципе.
Ещё немного погуглив и поприменяв разные волшебные заклинания вроде «spyder --reset» и «pip install --upgrade --force-reinstall pyqt5 spyder», я решил последовать советам с «Гитхаба» этой софтины и перезагрузить ПК (2020 год, здравствуйте!).
Как можно догадаться, перезагрузка (разумеется, с заново установленным окружением) не помогла. Правда, теперь эта питушня зависала не на большом белом окошке, а на окне поменьше: https://i.imgur.com/9ZLk0hF.png (а ещё в списке процессов обнаружился pythonw.exe, в котором не было потоков: https://i.imgur.com/8fA21f7.png. Как такое может быть и как это чудо смогли сотворить на «Питоне» — а хуй знает).
Ну что же, видимо, эти «issues» слишком «tricky» для меня: пытаться лезть в дебаггер ради этой хуйни я не хочу.
Тем не менее, желание всё таки попробовать это чудо инженерной мысли меня так и не оставило, а потому в следующей части я буду ставить его через «Анаконду» (просто, блядь, ставить IDE…).
Ну что же, большая красная кнопка с сайта «Spyder» ведёт нас на сайт «Анаконды», на котором, в свою очередь, мне предлагают скачать либо «Python 3.7», либо «Python 2.7». Заебись: самый новый «Python 3.8» с очень вкусными «assignment expressions» и ещё кучей полезных изменений и багфиксов (см. https://docs.python.org/3/whatsnew/3.8.html) в пролёте. Ладно, жрём, что дают.
«Анаконда» хрустела моим стареньким HDD минут десять, но всё таки встала.
Невероятно! Оно добавило значок в меню «Пуск» и даже запустилось: https://i.imgur.com/AUMLhIz.png! 7 секунд до открытия (возможности вводить код) против 3 у «VS Code». Ну ладно, семь — не семьдесят.
Итак, создаём проект с сорцами «NGK» (а в «VS Code» не надо ничего создавать, достаточно открыть папку), видим красиво подсвеченный код, заебись. Однако секундочку, что это такое?
«Spyder»: https://imgur.com/a/fP1riTM
«VS Code»: https://imgur.com/a/jZEnryQ
Что это? Тормоза?
Небольшая сессия гуглинга показывает, что нет: это сделано намеренно, чтобы макаки подумали, что «Spyder» тормозит, и не оскверняли его своим присутствием, и после смены настроек всё работает как надо. Ну, почти: «VS Code», в отличие от, подсвечивает не текст, а идентификатор, что хорошо видно на примере подсветки user_id как параметра и как переменной класса User («Spyder» подсветил их оба, «VS Code» — только тот идентификатор, что находится под курсором). Вдобавок, «VS Code» подсвечивает голубым цветом объявление идентификатора, что тоже очень удобно (и чего «Spyder», судя по всему, не может).
Хорошо, а как обстоят дела с тултипами?
«Spyder»: https://imgur.com/a/inr3yPt
«VS Code»: https://imgur.com/a/wPCGjD1
Ну так, на троечку. Определения функций и стандартные аннотации он подтягивает, а вот показать тип параметра функции (явно указанный) или выведенный тип локальной переменной «Spyder» не может, в отличие от «VS Code». Да, а ещё у «Spyder» тултип периодически выскакивает в какой-то жопе, это тоже видно на видео.
Ладно, а что с тайпчекингом?
Чот как-то хуёво всё. Сравним:
«Spyder»: https://i.imgur.com/wws0lLk.png
«VS Code»: https://i.imgur.com/MWgqAg0.png
Пойдём дальше, к одной из самых важных фишек IDE: автокомплиту, оно же IntelliSense.
«Spyder»: https://imgur.com/a/ZfczhB1
«VS Code»: https://imgur.com/a/HMRhzEk
«Spyder» мало того, что не показывает окошко автокомплита сразу (возможно, это настраивается), так ещё и вываливает в него целую тонну совершенно ненужного говна вроде «for». Зачем? Зачем?
Итог.
Наверное, «Spyder» — это крутой инструмент для своих пользователей, о которых его создатели пишут на главной странице сайта — для учёных.
Но если сравнивать его с «VS Code», то выглядит он откровенно… плохо. Его неудобно устанавливать. Для него нужно устанавливать кучу всякого ненужного мне говна (N.B.: «Anaconda» с зависимостями — это наверняка очень крутые и удобные инструменты, но когда их нужно тянуть просто для установки IDE, они становятся ненужным говном). Наконец, многие нужные и важные фичи, которые нормально работают в «VS Code», в «Spyder» работают хуёво.
Так что утверждение гуеста8 о том, что «всё тоже самое есть и в Spyder» — ложное. И маркетологи тут совершенно не причём.
Спокойной ночи.
Тема!
Сильный человек взял и поставил widows на флешку, пока остальные гыгыкали.
"Анаконда" - та ещё змея. Однако, она несёт много полезной питушни. Например, колёса, которые едут сами. Если обходиться обычным питоном и его пип-кой, придётся пердолиться и искать колёса на помойке, ведь иначе что-то не самое попсовое не заставишь работать. Анаконда тяжестью собственного хвоста давит эти проблемы на корню.
И ладно, что питонушня чуть старовата, но зато пердолиться не надо.
Однако для моих задач (потестировать что-нибудь, написать простенький скриптик, поправить «NGK», поюзать «Питон» как калькулятор) она попросту нинужна. Поэтому то, что «Spyder» нельзя без пердолинга заставить работать с системным «Питоном» и не тащить за собой громоздкие и ненужные мне инструменты, в моём случае является жирным минусом.
Проблемы и решения уровня C++.
* Присоединить трубу к ещё одной трубе.
* Увидеть, что там какашки плавают.
* Звонить всем и просить купить чугунную трубу.
А главное - уверенность, что какую-то питушню использует слишком много людей, что её нельзя выкинуть. Поэтому обкладывать её ватой, говном и порохом.
То ли дело npp, там подсветка явная по двойному клику. Автоматически только скобочки подсвечиваются.
Ну в случае ЯП примерно то же самое.
Варианты:
* придётся выбирать говно, на котором пишет большинство, чтобы удовлетворять требованиям рынка
* придётся выбирать говно, которое поддерживает большинство, чтобы не пердолиться с установкой пакетов и многолетними багами, которые некому править
Стадо макак определяет, на чём будет писать мир.
Хипстер из московского барбершопа считает, что у всех есть фейсбук. Как может не быть фейсбука? Это всё равно, что не иметь телефона.
Учительница из уральского села может сидеть в Одноклаccниках, и считать, что все там сидят. Ни про какие фейсбуки она не знает.
Питушок может считать PHP не просто естественным, а единственным выбором для написания вебсайтов.
Его друг пишет на ПХП, вконтакте написано на ПХП, вордпресс написано на пхп, под ucoz пишут на пхп, под битрикс пишут на пхп, форум пхпклуба написан на пхп, очевидно, что веб пишут на пхп.
Какие еще могут быть варианты?
Поэт -- пушкин, фрукт -- яблоко, язык для вебсайтов -- пхп
Однако есть один нюанс: если для среднестатистической макаки язык не удобен, то сколько миллиардов долларов в его пиар не вливай — он так и останется нишевым и малопопулярным.
Каноничный пример: ASP.NET. Казалось бы, Microsoft, охулиарды денег на маркетинг, из конкурентов только всякие нищие пхп и пыхтоны — впереди захват мира! Но нет, не судьба, макаки не одобрили.
Она продвигала asp.net среди крупных компаний, с которых можно состричь бабло. И это дало эффект: в америконском энтерпрайзе и окологосударственных конторах (пилящих американский бюджет) довольно много .NET.
А вот виндофон -- это чисто маркетинговый факап.
- виндофон это просто факап. Купить Нокию (сykablyad, целую Нокию!). Потом несколько лет вешать лапшу, что вот у нас одна платформа для десктопа/мобайла, вот бета тулзовин для конвертации iOS/Android проектов на винфон, вот нихуясечобывает телефон, который можно запускать, как кампутир!
Нормально там денег вбухано было на маркетинг. Проблема в том, что саму ось они немножечко забывали доделывать. В итоге вендоры послали их нахуй, у писателей приложений не было пользователей, а у пользователей не было приложений. Ну, были конечно те приложения, ладно, какие-то.
Всё-таки запердолить новую конкурентоспособную ось на рынке, где сидят вечно голодные акулы с 95% охвата, немножко сложнее, чем взять электрон и наклеить на него шильдик или даже изобрести более лучший асп.нет с нескучными веб-обоями.
Его друг пишет на HTML, вконтакте написано на HTML, вордпресс написано на HTML, под ucoz пишут на HTML, под битрикс пишут на HTML, форум пхпклуба написан на HTML, очевидно, что веб пишут на HTML.
Какие еще могут быть варианты?
PHP просто идеальное дополнение для создания динамических HTML.
Опросили k программистов на «PHP», у которых x лет работы, и они получают в среднем y баксов?
Уровень 0: "я выбираю windows, потому что.. ээ.. а разве бывают другие операционные системы? Виндуос же вроде встроен во все компьютеры"
Уровень 1: "я выбираю windows, потому что мне надо открывать файлы из access 2003, запускать приложение с WinForms, и переписывать файлы по сети с SMB3, а еще под нее есть дрова для моего железа"
Кажется что скриптушня изначально более сложна, так как требует от программиста больше всего держать в голове, и налажать в ней проще.
Первые скриптухи (такие как Perl) и делались скорее для хакеров.
А вот Паскаль очень простой язык: его дети в школе учат.
Если бы сайты делали на паскале с его строгой статической типизацией, то огромного количества ошибок из PHP и JS можно было бы избежать: их тупо ловил бы компилятор.
Макаки отлично писали на дельфи в нулевые: зачем сайты стали делать на пхп?
Конечно, в JS много "крутых фич" типа протопиооринтированного наследования и функциональщины, но нужна ли она мокаке?
У скриптушни очень маленькие коэффициенты, но большая асимтушня. В итоге, на маленьких проектах и простых людях они ведут себя очень эффективно. Но если проекты большие, а люди умные и пишут мудрёный код, побеждают какие-нибудь C#. Но на уровне анскильного питушка и мелких скриптов C# доставляет больше проблем.
Да, совершенно верно.
Судя по тому, что в индексе TIOBE он с 31-23 места в начале нулевых (2000-2005) поднялся до 9-10 и стабильно держится там последние десять лет (см. раздел «Very Long Term History») — это неверное утверждение.
Повторюсь, я не считаю TIOBE истиной в последней инстанции, однако это единственный известный мне инструмент для хоть сколько-нибудь объективной оценки популярности языков, в том числе в исторической перспективе. Если у тебя есть какие-либо другие инструменты для этой задачи, более подходящие — пожалуйста, поделись ими, мне действительно это интересно.
> Или может питон (суперпопулярный сейчас) сильно удобный язык?
Для среднестатистической макаки? Да, определённо: благодаря (навскидку) простому менеджеру пакетов, динамичности и утиной типизации. А, ну и ещё он скучный, это тоже важно.
> Почему в 2003-м был пых, а в 2020-м -- питон?
Видимо, потому что «Python» оказался более удобен для среднестатистической макаки, чем «PHP». Ещё возможно, что изменились сами макаки (ведь двадцать лет — это смена поколения человечества).
> Пых вдруг стал менее удобен, а питон стал более удобен?
Чтобы язык A стал удобнее языка B не обязательно снижать удобство языка B. Достаточно увеличить удобство языка A.
> джаваскрипта
А это вообще отличный показатель. «JavaScript» изначально спроектирован так, чтобы быть максимально удобным для любой домохозяйки, так, чтобы можно было просто хуярить код и течь. Этот подход к проектированию ЯП можно осуждать, но игнорировать его крайнюю эффективность — глупо.
Это значит, что он набирал свою «фан-базу» постепенно. Потому что если язык потенциально удобен для, например, 10% макак, эти 10% не выучат его на следующий день после выхода. Количество пользователей языка будет в течение N лет подниматься до этих условных 10%.
Также определённый вклад в этот рост, скорее всего, внесло изменение самих макак (как я уже сказал, за двадцать лет произошла смена поколений, это очень важный фактор).
> Всеми этими парамтерами обладают и PHP, Perl и Ruby.
Почему ты считаешь, что удобство использования перечисленных фич — это бинарные параметры?
> Очевидно, перл был более удобен.
Удобство — это комплексный параметр. Отсутствие пакетного менеджера вносит в него отрицательный вклад, но на тот момент, очевидно, не являлось определяющим.
> что именно изменилось?
Образование, психология, мировоззрение. Хотя бы то, что в начале двухтысячным быть программистом не было модно.
> А другие скриптовые языки этого не позволяют?
И ты опять видишь бинарность там, где её нет.
В той мере, в которой это позволяет «JavaScript» — нет, не позволяют.
Почему ты считаешь это странным? Сначала про язык никто не знал, носителей было мало, и рост числа заражённых был крайне медленным, как и любой экспоненциальный рост в самом начале.
Потом экспонента вошла в главную фазу, количество заражённых резко увеличилось (это сопровождалось характерными процессами в виде ездящих по конференциям людей), а потом оно достигло насыщения (т.е. все, кому язык был потенциально интересен, его выучили) и рост закончился. Посмотри, например, графики на https://www.worldometers.info/coronavirus/ — первые две фазы там уже видны, а после окончания эпидемии будет прекрасно видна и третья (для Китая они уже сейчас).
> По твоему удобство пакетных менеджеров питона и руби чем-то отличается?
Почему ты выбрал единственный параметр из трёх перечисленных мной? И да, удобство пакетных менеджеров может различаться.
> Что же являлось?
Простота деплоя, например. Ты пишешь в блокноте код, заливаешь его по «FTP» в /var/www/root и течёшь. Всё.
Ещё — толерантность к ошибкам: можно писать сколь угодно забагованный код, а все ошибки просто затыкать собачками — и сайт будет работать. Кое-как, но будет — а не выдавать 500 на любой необработанный эксепшон.
Слабая типизация: тебе не нужно думать о типах, ты просто складываешь строку с числом и течёшь.
Разумеется, скорее всего я пропустил ещё много определяющих моментов, чтобы узнать их все — нужно подробно опросить много тысяч макак, выбравших в то время «PHP» (причём спрашивать нужно не только про то, почему они выбрали «PHP», но и почему на нём остались — это тоже важно).
* Если нет переменной xs, создать её
* xs - массив
* добавить элемент в массив
Выбор языка — это действие человека. Психология и мировоззрение напрямую влияет на любое действие человека по определению.
Образование же влияет хотя бы тем, что макака с тремя классами образования попросту не осилит какой-нибудь «Хаскель», а вот с «PHP» уже есть вореанты.
> Приведи пример пожалуйста того, что позволяет JS, а другие языки не позволяют.
Складывать строку с числом, получать undefined (а не падать с ошибкой) от доступа к несуществующим ключам, стирать разницу между массивом и словарём, получать атрибуты объекта как через ., так и через [], принимать «(value, index, array)» в map() и ещё охулиард разных мелочей, о которых тебе 1024-- расскажет.
Да, практически всё это можно эмулировать в любом Тьюринг-полном языке, особенно динамическом (хотя со слабой типизацией есть проблемы). Да, многое из этого встречается во многих языках. Однако наиболее простым и естественным для макаки способом (т.е. без каких-либо дополнительных действий вообще) это можно делать только в «JavaScript»
конечно умел, тупое ты хуйло.
https://en.wikipedia.org/wiki/Zope
А иначе и обсуждать нечего.
* Выбирай язык 1, т.к. на нём пишут там, можно взять бабла.
* Выбирай язык 2, т.к. есть библиотека У.
* Выбирай язык 3, т.к. вообще все макаки в восторге.
> Я категорически против подхода «программирование ради программирования». Любой полезный программный продукт необходим для того, чтобы его использовали люди. Неважно, будут это обычные юзеры, программисты, девопсы, тестеры, интеграторы или кто-нибудь ещё. Важно, что это будут люди. И языки программирования — не исключение.
И да, и нет.
Одно дело - write-only языки вроде bash или регулярок. Тебе ставят задачу (например, удалить 100000 старых файлов), ты пишешь скрипт, который её решает и уходишь. Твой скрипт выкинут при удалении следующих 100000 файлов уже под другой операционкой. Скрипт нужен 1 раз. Пишешь на удобном языке "bash".
Другое дело - долгоживущий код, в который постоянно вносят изменения. Тебя наняла лаборатория, и ты пишешь код для работы с лекарствами. Завтра лаборатория откроет все лекарства и будет изучать самолёты под шубой, послезавтра - ручных диванных амёб. Задача каждый раз меняется, хотя принципы науки, по которым работает твой код - нет. В итоге ты пердолишься и пишешь на каком-нибудь C++, вставляя везде const и удаляя глобальные переменные или на Haskell и ворчишь на то, что сука нельзя переменную поменять. Но в итоге через 10 лет оказывается, что твой регулярный пердолинг с небольшими неудобствами сэкономил стране 100500 миллионов евро.
Среднестатистической макаке нужен один язык, которым среднестатистическая макака будет решать все возникающие перед ней задачи.
А я сразу хвалил JS, который прост для всех макак, и на нём можно писать всё, что угодно от микроконтроллеров до вебтушни.
И все языки знать не надо. Зачем? Вообще почему наличие языка должно приводить к его тотальному изучению?
Я просто хочу иметь возможность выбрать инструменты более гранулированно.
Помните мои изначальные тезисы? Какого хрена, если мне надо GC или ещё какую питушню, я должен вообще нахрен менять весь синтаксис? Или наоборот, если я хочу блоки пробелами и английские and/or вместо закорючек, мне вместе с питоном поставляют GC и ещё кучу всякого говна.
Нет какого-то языкового континуума, есть лишь 100500 рандомных островков, причём в каждом из случаев с нуля выбирают синтаксис, принципы и библиотеки! Это же говно. Дайте мне C с отступами как в питоне, это же не несбыточная мечта!
…Которое тоже будет расти квадратично. И которое ещё надо будет вычислить, а это можно сделать только проанализировав все библиотеки платформы, т.е. опять получается квадрат.
Множество самих библиотек растёт линейно и причин для квадратичного роста нет. Подмножество не может расти быстрее множества бесконечно.
Приведи реальный пример использования фа-диез-мажор в пердакшене, находясь в здравом уме и твердой памяти, торжественно.
Это не форум театра, спросите что попроще.
> Язык это синтаксис, семантика и стандартная библиотека.
Что такое «стандартная библиотека»?
>Значит ли это, что сраныйпых был другим языком?
Из версии в версию у сраногопыха меняется стандартная библиотека, а иногда ещё и синтаксис с семантикой (например, в «PHP3» добавили ООП, а в «PHP5» — магические методы вроде «__construct()»). По твоему же определению это означает, что да, «PHP5» !== «PHP7». Как и «C++11» != «C++17», например.
> JavaScript до недавнего времени вообще не имел синтаксиса для описания зависимостей и даже просто инклуда файла.
Ну вот: в «JavaScript» не было, а в «NodeJS» был.
И да, повторюсь: я нигде не утверждал, что в «JavaScript» был/есть/будет способ разрешения зависимостей.
> Но даже теперь в JS нету возможности указать версию во время импорта.
И это совершенно правильно. Представь ситуацию, когда у тебя 100 файлов импортят [email protected], и внезапно возникла необходимость обновить её до [email protected].
> И это совершенно правильно.
Это философский вопрос.
Когда-то нужна конкретная версия, когда-то - диапазон версий, когда-то версия одинакова на весь проект - версия как в проекте, когда-то - одинакова на все проекты - версия как в системе.
Например, если мой пакет проверяет, насколько устарели пакеты в системе - нужна системная версия.
Если я пишу один проект здесь и сейчас - нужна версия как в проекте.
Если мне в одном месте нужны фичи старой версии, а в другой - новой, то я использую конкретную версию.
* Помню, когда я проектировал идеальный менеджер пакетов, я упоминал (или не упоминал) возможность алиасинга - когда в метаданных проекта или ещё где ты говоришь "пакет версий x..y импортирую как ololopaket1, а пакет версий z..t импортирую как ololopaket2". С такими алиасами можно действительно убрать import [email protected] для подавляющего большинства случаев.
Как будто что-то плохое. Вполне возможно, что в организации имеется код на всех этих языках, и его нужно читать и поддерживать. Может быть переписывать какие-то утилиты с одного на другой для повышения читаемости или пирфоманса.
Узкоспециализированный C++-программист или C#-программист или SQL-программист или HTML-программист - анскильные питушки, которые не смогли осилить чего-то кроме конкретной реализации. Такой заедушник сможет лишь получать деньги пару лет, пока не выйдет свежий стандарт, и его узкоспециализированность можно будет засунуть на флешку и сесть.
Нормальный программист знает несколько языков, хороший программист - несколько парадигм. А тут три языка со схожими принципами.
Однако, там в итоге пользователю не нужно пердолиться.
Программист всю нужную питушню собирает сам.
Иногда даже зависимости малость кэшируются, если они те же и установлены из одного CDN.
Мне как пользователю приятнее зайти на сайт, над которым один раз попердолились, и он потом у всех более-менее работает, чем устанавливать пакет, над дружбой с зависимостями которого тоже попердолились во время разработки, но мне с некоторой вероятностью придётся сделать ещё один виток по этому пердольному кругу.
Админ что ли?
В Haskell - функция unsafePerformIO.
В C/C++ - asm.
гоатсе → ujfnct → уйфнцт → eqaywn → еяаывн → tzfsdy → тзфсды → npacls → нпацлс → ygfwkc → ыгфвкц → suadrw → суадрв → ceflhd → цефлхд
Надо составить словарик английских и русских слов с таким «переводом», а потом выбрать из этих слов самые удачные.
Какая «ЙАЖА» )))
Отображение \u043d-питушни корректно, а протекание тегов - нет.