?

Log in

No account? Create an account

Предыдущий пост Поделиться Следующий пост
О том, почему всё так хреново
lex_kravetski
Пока ещё выложены только два видео по теме «компьютер против бумаги». Но из комментариев к ним уже можно узнать много всего интересного.

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


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


  3. Если у нового инструмента нет какой-то фичи, то он менее удобен, чем старый, и непригоден к использованию, даже если у старого инструмента тоже нет и этой фичи, и ещё пары сотен фич, которые есть у нового. Несмотря даже на то, что новый инструмент содержит все фичи старого, а также новые, которыми пользоваться объективно проще. Так, например, швейцарский нож хуже каменного скребка, поскольку в швейцарском ноже нет зубочистки. Впрочем, см. пункты 1 и 2.


  4. Пункт 3 остаётся верным, даже если у нового инструмента есть эта фича, просто ты не в курсе. Если тебе о ней скажут, то надо просто проигнорировать эти сведения (ведь иначе их придётся запоминать, а это противоречит пунктам 1 и 2) и остаться уверенным, что фичи просто нет.


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


  6. Любые эксперименты и наблюдения меньше говорят о реальности, нежели твои умозрительные о ней представления. Если результаты экспериментов противоречат твоим умозрительным представлениям, то из этого следует только то, что эксперименты был проведены неправильно, в недостаточном количестве и т.п. И в любом случае они ничего не докажут. Так, например, если ты уверен, что лошади скачут быстрее, чем летают самолёты, поскольку лошади ведь такие клёвые, то эксперимент, который покажет, что это не так, будет просто означать, что «это ведь — всего лишь один эксперимент». Даже если лошадь обгоняла летящий самолёт в нуле экспериментов.


  7. Самое интересное. Если какие-то нюансы использования инструмента даны в разных источниках (в нескольких статьях, в нескольких видеороликах), то из этого следует, что их либо невозможно, либо очень тяжело использовать одновременно. На одной лекции вам рассказали про Второй Закон Ньютона, а на другой — про Закон Всемирного Тяготения. Очевидно, что эти два закона невозможно одновременно использовать при решении одной задачи. Шах и мат, физики!


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

Хотелось бы всё свалить на проблемы с финансированием, но проблема уже не только с ним, а ещё и с кадрами. И с образованием в целом. Это всё тоже следствие негодной системы общественных отношений, но оно уже не сводится к банальному «не дают денег». Теперь, даже если вдруг дать денег, всё равно всё будет хреново. И разгребать это говнище придётся десятилетиями.



doc-файл


  • 1
0.3.11. Зачем мне язык, у которого только с числами хорошо, а со строками все плохо?

Я пишу пост про научную инфраструктуру Python, там упомянуто под 100 пакетов. Наука это не столько числодробилки, сколько возможность выразить и решить задачу в терминах предметной области. Можно ручками написать SVD над матрицами, но написать sklearn.preprocessing.PCA(2).fit_transform(X) быстрее и понятнее.

Библиотека числодробилок должна быть написана производителем железа на языке без оверхеда, C/C++ или Fortran, как, например, Intel MKL или cuDNN от NVIDIA, а не писаться странными людьми с сомнительными ресурсами и знаниями для каждого динамического языка.

"+" обычно используется у математиков для коммутативных операций
Довод так себе, в машинной арифметике даже == нерефлексивное, почему же для него не придумали что-нибудь необычного?

Джулия - всё-таки не мат.пакет
Место "не матпакета", где принимаются неудобные решения с целю производительности, уже занято C++.

все эти [[]] визуально загромождали код
Нет, речь не об этом. Во всех нормальных языках принято считать рейнджем (1:3, {vec.begin(), vec.end()}) полуинтервал, включающий начало и исключающий конец, это упрощает большинство алгоритмов. В матлабе, а с ним и в Julia, это не так. По той же причине во всех языках программирования, кроме паскалеподобных, используется нумерация от 0. В Python срезы имеют вид a[2:] (с второго элемента до конца), a[:-1] (все, кроме последнего).

Нет распаковки таплов в for
Прошу прощения, не там прочитал в логах, это была не к Julia претензия.

Кернель для C++, публичная версия будет, если взлетит.

>> 0.3.11

Уже, кстати, есть 4.5 типа-стабильная и пятёрка-девелоперская.

>> Зачем мне язык, у которого только с числами хорошо, а со строками все плохо?

Мне всё-таки интересно бенчмарки посмотреть хоть в каком-то виде, чтоб посмотреть, где там просадка со строками.
И всё-таки интересно, что у вас за науч. задачи, где нужна производительность на строках из коробки. При чём на столько нужна, что если нету, то "тормозное убожество" и "закопать". Обычно для тексто-месилки всё-таки используют специальные инструменты и пакеты.

>> Библиотека числодробилок должна быть написана производителем железа на языке без оверхеда, C/C++ или Fortran, как, например, Intel MKL или cuDNN от NVIDIA, а не писаться странными людьми с сомнительными ресурсами и знаниями для каждого динамического языка.

Вам самому никогда не приходилось писать библиотеку под свои задачи? Это ж наука, там постоянно нужно что-то выдумывать и дорабатывать и пользоваться наработками других "странных людей"! Я вот таким занимаюсь постоянно (и мои друзья и знакомые в науке тем же занимаются). Вы всегда ждёте супер-оптимизированную библиотеку полностью без оверхеда и именно от производителя железа? Или это "как оно должно быть в идеальном мире"?

>> Довод так себе, в машинной арифметике даже == нерефлексивное, почему же для него не придумали что-нибудь необычного?

Я пишу про коммутативность, а не рефлексивность, поэтому не понял Вашего вопроса. Решение с "+", возможно, спорное (у "нормальных" людей суммирование строк ассоциируется именно с конкатенацией), но, имхо, не лишено логики (в ряде других языков конкатенацию делают при помощи "~", "++", "||" и пр.) из-за коммутативности плюса. Имхо, уж точно не яркий пример "ужаса синтаксиса". Как максимум - решение, с которым можно поспорить.

>> Место "не матпакета", где принимаются неудобные решения с целю производительности, уже занято C++.

Думаете, все эти D и прочие Rust'ы появляются от нечего делать и нереализованных амбиций?
C++ не очень удобен для программирования "нормальными" людьми (без сишности головного мозга - грубо, но всё же). Плюс не динамическая типизация. И он сложен для изучения. А нужен язык, которым достаточно просто пользоваться, нет многих сишных загонов, который более читаем (вот где можно в пример ужасы синтаксиса привести, так это для С++ - говорю это, хоть я и сам плюсовик), при этом достаточно производителен для нужд научн-софта, расширяем при необходимости (не всем нравится почти полное отсутствие синтаксиса у того же Лиспа) и т.д. И в плане прогресса как языка С++ подавал надежды, после того как комитет вышел из анабиоза и начал клепать стандарты, но с 17ым стандартом он опять, судя по всему, собирается уйти в анабиоз.

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

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

Для полноценного выражения в терминах предметной области в языке должна быть, имхо, предусмотрена возможность создания DSL'ей (хоть в каком-нибудь виде), как в том же шестом Перле. Одно из решений для реализации DSL - макросы. И в Джулии они есть.

>> Во всех нормальных языках принято считать рейнджем (1:3, {vec.begin(), vec.end()}) полуинтервал, включающий начало и исключающий конец, это упрощает большинство алгоритмов.
>> По той же причине во всех языках программирования, кроме паскалеподобных, используется нумерация от 0

Вот в том-то и дело, что в языках, заражённых вирусом сишности, принято нумеровать от нуля и прочие "странности". "Нормальные" люди считают от единицы и до последнего элемента: 1, 2, 3, - а не 0, 1, 2. "Усложнение" тут будет в том, что единицу в индексах нужно будет отнимать (как делают математики в своих работах - нумеруют "нормально" и вычитают единицу, где нужно в индексах). А в функциональном программировании, где не нужно явно итерировать диапазон, такой проблемы вообще не возникает (в Mathematica, например, где большой набор функций для перелохмачивания списков без использования циклов и прочего, - там даже foreach не сразу ввели, т.к. редко нужен был).

Токма, вроде, это всё не проблема синтаксиса.


Да никакой магии не нужно, простые строковые операции над короткими строками, сплиты, джойны, массивы таплов, слайсы, сравнения, изменения регистра. Я надеялся на скорость C++ x1-x2, а получил x350. И, разумеется, остался на "специальном" Python.

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

Рефлексивность == это куда более "математичное" требование, чем коммутативность +. Бинарных операторов много, а на эквивалентности держится вся математика. И что за языки такие?

D и Rust появились именно из-за чьих-то неумных амбиций, а вовсе не из желания создать что-то полезное. Собственно, ваша претензия к C++, что у него не динамическая типизация, показывает, что вы C++ не понимаете. Чтение Как я роDesign & Evolution должно вам помочь. Кстати, примеры ужасов синтаксиса C++ в студию.

Вы старательно выводите в своих ответах какого-то настоящего шотландца, которого корежит от использования + для некоммутативной конкатенации, а написание end там, где его можно просто опустить, ничуть не смущает; который радуется тому, что на Julia можно написать библиотеку численных вычислений, не переходя на богомерзкий C с его нумерацией с 0, но который без малейших сложностей переходит на Perl (с нумерацией с 0) или еще куда-нибудь, когда ему нужно что-нибудь сделать со строками. Я таких шотландцев не встречал, только фанбоев. В Julia я вижу тот же самый Python, только хуже по всем показателям: по производительности, синтаксису, сообществу/инфраструктуре/инструментарию, перспективам; и при этом не вижу ни одного преимущества.

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

Ну, задач всяких много. Базы данных распределённые, например. Под каждую специфичную задачу свой инструмент есть. Джулия, вроде, под задачи Перла по обработке текстов не заявлялась. Никто, думаю, не будет чмырить C#, потому что у него сортировка массивов отстойно работает. Кому надо вдруг за*батая сортировка, возьмёт специальную библиотеку.

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

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

>> D и Rust появились именно из-за чьих-то неумных амбиций

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

>> вы C++ не понимаете.

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

>> которого корежит от использования + для некоммутативной конкатенации

Я упомянул, что не всем джулистам это нравится (мне, например, не нравится). Но это точно не ужас синтаксиса, а как максимум спорное решение со своей логикой. Всё-таки мы по кругу ходим.

>> а написание end там, где его можно просто опустить, ничуть не смущает

Я написал, что опускание end'а - это удобный сахар (взамен потери наглядности, когда по коду с кучей таких конструкций будешь глазами бегать). Но это точно не ужас синтаксиса. Ходим по кругу.

>> который радуется тому, что на Julia можно написать библиотеку численных вычислений, не переходя на богомерзкий C с его нумерацией с 0

Мне вот лично пофиг, с нуля или нет. Но для людей, которые чисто юзеры языка и не страдают сишными загонами - им вот будет на одну ступеньку удобнее "нормальная" нумерация. Имхо.

>> но который без малейших сложностей переходит на Perl (с нумерацией с 0) или еще куда-нибудь, когда ему нужно что-нибудь сделать со строками.

Покажите код бенчмарка!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
:)

Судя по тому, что Вы уже который раз мою просьбу игнорируете и под ужасами синтаксиса понимаете спорные мелочи, типа неопускание end'а (надо, кстати, погуглить, делал ли кто-то реквест на этот сахар с опусканием), у меня закрадывается впечатление, что никакого кода я так и не получу, на котором я типа должен офигеть от этого "тормознутого убожества".

Если там поправимая просадка, то мы сделаем запрос разрабам. Если там by design проблема, то это будет плохо, т.к. хотелось бы всё-таки не терять производительность на строках. А то на самом деле придётся в случае чего тем же перлом пользоваться или пакеты подключать оптимизированные. А это не гуд.

>> и при этом не вижу ни одного преимущества.

Само собой. На главной странице языка ни одного и не перечислено, а те, которые перечислены, никому не нужны. А если и нужны, то полутора калекам.

Ну, задач всяких много.
Тем не менее, Python и C++ более-менее все задачи исчерпывают. А для Julia никакой ниши нет и не будет.

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

От того, что вы видите в синтаксисе Julia только "свою небесспорную логику", а я вонючие миазмы 80-х, мои взгляды как-то должны измениться? Потом вы старательно всюду пишете про "нормальных людей", которым все ок, видимо, пытаясь выставить меня ненормальным. Однако githut и redmonk, например, с вами не согласны, показывая, что все нормальные люди предпочитают Python, а Julia, несмотря на лютый хайп, заняла место рядом с канувшими в Лету Haxe и Vala.

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

Всё ясно. Закончим беседу. Думаю, что читающие извлекут из неё какую-то пользу.

>> В Python срезы имеют вид a[2:] (с второго элемента до конца), a[:-1] (все, кроме последнего).

Имхо, записи, типа a[1:end-1] очевиднее. А a[:-1] можно рассматривать как сахар (удобный, кстати). Но имхо, отсутствие такого сахара - явно не ужас синтаксиса. В Nim, например, есть фишки, типа такой:
for i in 0 .. <n
, - чтоб наглядно и, как говорите, "удобно для алгоритмов". Но это сахар.

>> Кернель для C++, публичная версия будет, если взлетит.

https://github.com/minrk/clingkernel
Я не пользовался.
Пробовали, или там недостатки есть?

Edited at 2016-04-22 14:47 (UTC)

С cling все и началось. Он неюзабелен.

  • 1