я думаю, что на нашем уровне познания у нас сейчас в науке точно "эпициклы" или спор о том "какая система отсчёта правильная" и Ньютон с первым законом ещё не пришёл.
Например пытаясь ответить на вопрос: сколько информации "появляется" во вселенной при коллапсе волновой ф-ии одной частицы я прихожу в ужас.
ПС И к стати где прочитать определение понятия присваивания в python? Я беглым поиском по их документации не нашёл. Нашёл 3.1.1.number (equal sign) и такие же обрывочные определения для других типов.
ваше утверждение про "сверху вниз" слабо осмысленно, пока вы забываете про разные концепции вычислений. Я догадываюсь что вы хотите сказать, но чтобы не играть в загадки - давайте в явном виде огласим наши позиции.
Моя позиция:
В статье есть неверное утверждение как работает equals sign, вот оно: "Когда мы утверждаем, что нечто равно чему-то, нужно ставить “=” (equals sign)"
Я привожу пример с mutable data, когда видно, что утверждение плохое и неверное. Если читать определение буквально и дотошно, что в момент присваивания - в sum должно лежать AST: (|, a b), на самом деле в sum лежит результат вычислений.
Эту разницу между call-by-name \ call-by-value новички ещё не знают и узнают не скоро, но корректные определения надо давать с самого начала.
Правильно определение equals sign "Когда мы вычисляем значение и 'присваиваем его в переменную(*)' " *) правильно наверное передаём его в lvalue - или что там у python в этом месте не нашёл.
Теперь ваша позиция в явном виде и возражения к моей пожалуйста.
Тут коллега хороший вопрос задал, обсуждение может быть долгим, но по факту вот этот пример лучше (лучше пример на изменяемых типах данных), чтобы прям видно было, что после "a |= {10}" равенство перестало выполняться.
sum = a | b
print(a, b, sum)
print(id(a), id(b), id(sum))
#вот вывод:
#$ {1, 2} {3, 4} {1, 2, 3, 4}
#$ 1005001 1005002 1005003
#########################
a |= {10}
print(a, b, sum)
print(id(a), id(b), id(sum))
#вот новый вывод, заметьте, a изменилось, sum нет, т.е. "раверство" перестало выполняться
#$ {1, 2, 10} {3, 4} {1, 2, 3, 4}
#$ 1005001 1005002 1005003
вы про "мутабельность" "иммутабельность" или про суть определения?
ПС Если про первое - согласен, наверное лучше было бы привести пример со словарями (но тут не уверен понятен ли он). Если про второе - то что значит "утверждаем что равно"? Какой квантор ставить?
# разницы в определениях нет
(subverse1, subverse2) = "однажды в студёную", "зимнюю пору"
# тут разница в определении видна, verse по-вашему должен кажды раз вычисляться
# в реальности он вычисляется однажды и хранится в памяти
verse = subverse1 + " " + subverse2
Да заметьте вот минимальный пример.
Я думаю, что python очень плохой для обучения программированию язык (для обучения "написанию скрпитов" хороший) - именно потому, что можно что-то писать не понимаю что ты делаешь и заложить мины под дальнейшее обучение.
Другие языки гораздо более явно заставляют задумываться - а понимаю ли я что вот в этом месте происходит, а python заметает эти вопросы под ковёр.
Я думаю, что python сложный язык, маскирующийся под простой, особенно при обучении.
То есть чтобы на нём осознанно писать ПО (не скриптики или автоматизацию) - нужно понимать все те же концепции, современного ПО что и для других языков.
Только при этом python создаёт иллюзию "ты же можешь использовать концепцию ХХХ не зная что это - потом разберёшься". Проблема с этой иллюзией в том, что очень сложно потом заставить себя выучить концепцию ХХХ, когда ты худо-бедно (но с ошибками и подводными камнями) умеешь её применять.
Риски ретроспективы и постмортемов, т.к. команду может устраивать исправление, но не проработка причин.
Мне кажется, что это вообще самый главный из минусов (если вы внедрили KPI - будьте готовы, что люди начнут оптимизировать KPI, а не делать содержательную работу) который вы почему-то утащили на предпоследнее место.
Извините где и как такого добиться? Единственное что приходит в голову - черепичные диски (ну или на нормальных дисках прям какая-то жуткая ошибка программиста)? https://habr.com/ru/post/529860/
Потому, как с точки зрения общего случая - нормальная кэшируемая "достаточно поточная" запись в ФС то, что вы написали противоречит и опыту, замерам и разумным объяснениям.
В ближайшие 100 лет всё как раз можно с ног на голову перевернуться языках программирования. Уже сейчас ChatGPT умеет эффективно конвертировать код между разными ЯП. Это в итоге приведёт к тому, что количество используемых ЯП будет сокращаться. При этом будут приходить новые ЯП, и старая кодовая база будет транслироваться на новые ЯП. А те же умные ИИ алгоритмы начнут не просо транслировать - а ещё и очень эффективно оптимизировать и выявлять баги.
Вы собственно описали два мешающих друг-другу процесса: - трансляцию на другой язык - оптимизацию после трансляции
Суть в том, что для хорошей оптимизации надо оставить как можно больше исходной семантики и внести как можно меньше паразитной (той, которая не нужна в исходной задаче, но появилась в технической реализации из-за особенностей инструментария, например ЯП, или SQL или ещё чего).
То есть с тем, что подход к написанию ПО будет меняться - я не спорю, но вот переписывание старого ПО будет происходить как-то кардинально по-другому.
хм.. кажется, что вся статья - это борьба с языком, чтобы получить нормальный доступ к аппаратуре.
Как-то во время чтения созрела мысль, что высокопроизводительный код на C# \ Java выглядит настолько уродливо потому, что "пробиваться сквозь абстракции к аппаратуре" сложнее, чем "навернуть ещё один слой абстракций".
ПС. Мне кажется, что rust был бы оптимален для этой задаче - совмещает в себе библиотеку с UCA алгоритмом с низкоуровневыми возможностями.
На самом деле может случиться так (и чем больше отношение "размер файла" \ "доступная память" - тем вероятнее, что случиться), что несколько последовательных сортировок слиянием (так конечно проблема со сравнением UTF8-строк) будут работать быстрее, чем: 1. отсортировать всё в памяти 2. заполнить конечный файл ориентируясь на индексы в памяти.
Не скажу как конкретно у такой задачи, но "в целом" можно ориентироваться на - 200-400 МБ/сек поточного чтения - 300-450 МБ/сек поточной записи (разница от того, что часто чтение "не совсем" поточное, а асинхронка файлового кэша делает запись совсем поточной) - 150 IO*opers / sec
Но в целом всё зависит от данных. На вашем решении вы уложились, если бы было "околонулевой" шанс совпадения строк - сортировать поточно наверное (с мапингом файлов в память) наверное было бы оптимально.
Заблуждение-0: - строки можно сравнить - ну или хотя бы "в мире хоть кто-то знает как можно сравнить две строки на равенство".
Ответ: нет и нет.
Unicode предполагает 4 формы нормализации строк (для сравнение на равенство), все 4 нужны в разных случаях именно потому, что не существует "технического", способа сравнить строки на равенство. И без вникания в "бизнес логику" непонятно какой способ вам подходит.
А, к стати если уж речь зашла об этом - вы какие из этих книг читали и можете посоветовать? Судя по отзывам - у них у всех есть один большой недостаток - их писали люди из университетов, а не индустрии. И поэтому они сосредоточены на том, как делать "правильно в сферическом вакууме", а не как делать так, чтобы потом на этом было удобно программировать.
А вот почитать захотелось на эту тему что-то: 1. боле-менее фундаментальное 2. боле-менее с практической стороны а нету. Лекция что я привёл, соответствует только критерию (2)
я думаю, что на нашем уровне познания у нас сейчас в науке точно "эпициклы" или спор о том "какая система отсчёта правильная" и Ньютон с первым законом ещё не пришёл.
Например пытаясь ответить на вопрос: сколько информации "появляется" во вселенной при коллапсе волновой ф-ии одной частицы я прихожу в ужас.
э... о чём мы вообще тогда спорим?
ПС
И к стати где прочитать определение понятия присваивания в python? Я беглым поиском по их документации не нашёл.
Нашёл 3.1.1.number (equal sign) и такие же обрывочные определения для других типов.
ваше утверждение про "сверху вниз" слабо осмысленно, пока вы забываете про разные концепции вычислений.
Я догадываюсь что вы хотите сказать, но чтобы не играть в загадки - давайте в явном виде огласим наши позиции.
Моя позиция:
В статье есть неверное утверждение как работает equals sign, вот оно: "Когда мы утверждаем, что нечто равно чему-то, нужно ставить “=” (equals sign)"
Я привожу пример с mutable data, когда видно, что утверждение плохое и неверное. Если читать определение буквально и дотошно, что в момент присваивания - в sum должно лежать AST: (|, a b), на самом деле в sum лежит результат вычислений.
Эту разницу между call-by-name \ call-by-value новички ещё не знают и узнают не скоро, но корректные определения надо давать с самого начала.
Правильно определение equals sign "Когда мы вычисляем значение и 'присваиваем его в переменную(*)' " *) правильно наверное передаём его в lvalue - или что там у python в этом месте не нашёл.
Теперь ваша позиция в явном виде и возражения к моей пожалуйста.
К чему вы эти не относящиеся к делу слова написали.
Вопрос: верно ли определение автора.
Утверждение: не верно (более хороший пример c set внизу).
Если всё ещё считаете, что верно - докажите.
Тут коллега хороший вопрос задал, обсуждение может быть долгим, но по факту вот этот пример лучше (лучше пример на изменяемых типах данных), чтобы прям видно было, что после "a |= {10}" равенство перестало выполняться.
вы про "мутабельность" "иммутабельность" или про суть определения?
ПС
Если про первое - согласен, наверное лучше было бы привести пример со словарями (но тут не уверен понятен ли он).
Если про второе - то что значит "утверждаем что равно"? Какой квантор ставить?
Это если вы хотите избежать false negative на 100% и максимально ограничить число false positive (но теоретически они возможны).
А если вы хотите поставить быстрый, но изредка ошибающийся фильтр возможны разные компромиссы.
Да заметьте вот минимальный пример.
Я думаю, что python очень плохой для обучения программированию язык (для обучения "написанию скрпитов" хороший) - именно потому, что можно что-то писать не понимаю что ты делаешь и заложить мины под дальнейшее обучение.
Другие языки гораздо более явно заставляют задумываться - а понимаю ли я что вот в этом месте происходит, а python заметает эти вопросы под ковёр.
Я думаю, что python сложный язык, маскирующийся под простой, особенно при обучении.
То есть чтобы на нём осознанно писать ПО (не скриптики или автоматизацию) - нужно понимать все те же концепции, современного ПО что и для других языков.
Только при этом python создаёт иллюзию "ты же можешь использовать концепцию ХХХ не зная что это - потом разберёшься".
Проблема с этой иллюзией в том, что очень сложно потом заставить себя выучить концепцию ХХХ, когда ты худо-бедно (но с ошибками и подводными камнями) умеешь её применять.
С "=" мы не утверждаем, что нечто чему-то равно. Мы присваиваем объекту значение (создаём новый объект или присваиваем значение старому).
"=" как утверждение это в Haskell (там оно так и называется equation - уравнение).
Мне кажется, что это вообще самый главный из минусов (если вы внедрили KPI - будьте готовы, что люди начнут оптимизировать KPI, а не делать содержательную работу) который вы почему-то утащили на предпоследнее место.
Это для черепичных дисков (никогда с ними дела не имел)? Потому, что для обычных HDD всё ровно наоборот.
Ну это же первое, что должно смутить, вас не смутило?
Извините где и как такого добиться?
Единственное что приходит в голову - черепичные диски (ну или на нормальных дисках прям какая-то жуткая ошибка программиста)? https://habr.com/ru/post/529860/
Потому, как с точки зрения общего случая - нормальная кэшируемая "достаточно поточная" запись в ФС то, что вы написали противоречит и опыту, замерам и разумным объяснениям.
Вы собственно описали два мешающих друг-другу процесса:
- трансляцию на другой язык
- оптимизацию после трансляции
Суть в том, что для хорошей оптимизации надо оставить как можно больше исходной семантики и внести как можно меньше паразитной (той, которая не нужна в исходной задаче, но появилась в технической реализации из-за особенностей инструментария, например ЯП, или SQL или ещё чего).
То есть с тем, что подход к написанию ПО будет меняться - я не спорю, но вот переписывание старого ПО будет происходить как-то кардинально по-другому.
хм.. кажется, что вся статья - это борьба с языком, чтобы получить нормальный доступ к аппаратуре.
Как-то во время чтения созрела мысль, что высокопроизводительный код на C# \ Java выглядит настолько уродливо потому, что "пробиваться сквозь абстракции к аппаратуре" сложнее, чем "навернуть ещё один слой абстракций".
ПС.
Мне кажется, что rust был бы оптимален для этой задаче - совмещает в себе библиотеку с UCA алгоритмом с низкоуровневыми возможностями.
На самом деле может случиться так (и чем больше отношение "размер файла" \ "доступная память" - тем вероятнее, что случиться), что несколько последовательных сортировок слиянием (так конечно проблема со сравнением UTF8-строк) будут работать быстрее, чем:
1. отсортировать всё в памяти
2. заполнить конечный файл ориентируясь на индексы в памяти.
Не скажу как конкретно у такой задачи, но "в целом" можно ориентироваться на
- 200-400 МБ/сек поточного чтения
- 300-450 МБ/сек поточной записи (разница от того, что часто чтение "не совсем" поточное, а асинхронка файлового кэша делает запись совсем поточной)
- 150 IO*opers / sec
Но в целом всё зависит от данных.
На вашем решении вы уложились, если бы было "околонулевой" шанс совпадения строк - сортировать поточно наверное (с мапингом файлов в память) наверное было бы оптимально.
Заблуждение-0:
- строки можно сравнить
- ну или хотя бы "в мире хоть кто-то знает как можно сравнить две строки на равенство".
Ответ: нет и нет.
Unicode предполагает 4 формы нормализации строк (для сравнение на равенство), все 4 нужны в разных случаях именно потому, что не существует "технического", способа сравнить строки на равенство.
И без вникания в "бизнес логику" непонятно какой способ вам подходит.
Ещё интересные картинки тут:
https://www.unicode.org/reports/tr15/#Canon_Compat_Equivalence
А, к стати если уж речь зашла об этом - вы какие из этих книг читали и можете посоветовать?
Судя по отзывам - у них у всех есть один большой недостаток - их писали люди из университетов, а не индустрии. И поэтому они сосредоточены на том, как делать "правильно в сферическом вакууме", а не как делать так, чтобы потом на этом было удобно программировать.
А вот почитать захотелось на эту тему что-то:
1. боле-менее фундаментальное
2. боле-менее с практической стороны
а нету. Лекция что я привёл, соответствует только критерию (2)
Да.
Сейчас средняя температура тела здорового человека "в развитом мире" ниже, чем 36.6