Честно говоря не совсем понял, к чему относится ваш комментарий, так как я и говорил о том, что не нужно просто запоминать, а аналогия с пультом, пакетиком и телевизором немного странная :)
Не, я такого не говорил. Я имел ввиду, что важно запоминать и анализировать новую информацию в связке с уже имеющейся и встраивать ее в свою "картину мира".
Банальный пример с датами - часто можно слышать фразы - "Даты событий не нужно запоминать, так как их всегда можно нагуглить/посмотреть". Если ты запоминаешь даты событий просто как циферки, то да, тогда они мало полезны, но запоминание дат как "временной картины" событий, дает тебе возможность выстраивать и анализировать их ход в уме и связывать с уже известной тебе ранее последовательностью событий.
Вот я с этим абсолютно согласен. Все рассказы о том, что теперь можно ничего не запоминать, а просто нагуглить - полная чушь.
Информация != знания. Если ты ничего не помнишь, а полагаешься на гугл, то ты не можешь нормально мыслить. В итоге мы получаем, что вроде информации у нас все больше и больше, а ее понимания все меньше и меньше.
Вы пытаетесь доводить аргумент до абсурда, типа в оптимизированном коде вообще невозможно разобраться и что-то изменить, поэтому не старайтесь. Получается тезис вроде: "Выбираете - читаемый и поддерживаемый код как предлагаю я или нечитаемый и неподдерживаемый код как предлагаете вы".
Насчёт кешей в борьбе между o(1) и o(n) вы меня реально рассмешили. Я хотел написать живой пример, но, боже, оптимизация обращений памяти как замена перевода алгоритма с o(n) на o(1)
Может в данном случае, это не лучший пример, но ничего прям смешного я тут не вижу. Может быть вообще такое, что подобной оптимизацией вы только сделаете хуже. Например, вы решили поменять обычный массив o(n) на хеш таблицу o(1). Но обращение к данным у вас в программе идет последовательно с множеством попаданий в кеш. Теперь получается, что большинство обращений будут cache miss, так как обращение к данным в хеш таблице уже не последовательно. В итоге производительность может упасть в 10-100 раз и это не покроет разницу в асимптотическом выигрыше. Это просто пример того, что не все так однозначно.
Я писал, что нужно искать баланс между понятностью и производительностью, а вы говорите, что понятность должна стоять на первом плане, а к тому же код даже может быть неправильным, но главное понятным. Вас самого это не смущает?
Взгляните на это со стороны заказчика или пользователя - если программа тормозит и некорректно работает, то оправдание - "зато код понятно написан" вы считаете адекватным?
Алгоритмические оптимизации обычно оказываются важнее языковых (сравните o(1) на бейсике с o(n) на ассемблере)
Оптимизации с учетом использования кешей процессора и правильного обращения к памяти на практике обычно оказываются еще важнее, так как эти O(x) оценки лишь асимптотические.
Но опять же, все зависит от ситуации и как я уже говорил, здесь нужно искать баланс и компромис.
Код пишется для читателя. Себя, спустя пол-года, или другого программиста. Все, кто всего лишь "решает задачу" с помощью кода обречены на страдания при его чтении.
Звучит очень странно. Код для читателя пишется в первую очередь в учебниках и статьях, но в основном код пишется, чтобы исполняться и решать задачу.
В утверждении о том, что код чаще читается, чем пишется, забывается о том, что намногочаще он исполняется на процессоре. Во всем конечно нужен баланс, но ваше утверждение о приоритете понятности уж слишком категорично, а уж о том, что неправильный понятный код лучше правильного непонятного вообще смешно. Понятный/непонятный, это слишком субъективные понятия в сравнении с правильный/неправильный.
Откройте панчиновскую статью по ссылке, наведите на оценку — 133 голоса за, 9 против. Не знаю, правда, как эти факты повлияют на вашу веру.
Какие факты? Если вы приводите данного персонажа в пример, то должны знать, что его аудитория действует по принципу "Вижу Панчина, сначала лайк потом просмотр". Так что рассуждать о серьезности восприятия на основании таких плюсиков мне кажется не стоит.
Из приведенной вами статьи Панчина можно сделать вывод, что Панчин и Логика, это как П и Л - издали вроде похожи, но если хорошо присмотреться, то оказывается, что это совсем разные вещи и даже рядом не стоят.
где он убедительно доказывает природное происхождение
Таким способом невозможно доказать природное происхождение.
Ну а в конце статьи, как обычно нужно добавить всякую чушь про 5G, чипирование и тп. Что еще раз показывает, что клоунады у него больше чем науки.
Хочу заметить, что я не являюсь сторонником lab-leak теории, я просто говорю о том, что эти типа доказательства совсем не доказательства. И как раз антинаучно до проведения тщательного расследования явно отвергать одну из гипотез лишь на основании изначального отсутствия прямых доказательств, что как известно не является доказательством отсутствия.
Наверное, как всегда у конспирологов — никак.
Вы должно быть хорошо разбираетесь, как мыслят конспирологи.
А где я говорил про pnpm? Мой комментарий только относительно переиспользования кода, переиспользования хелперов, без которых код часто ломается (i.e. isObject/isArray) и использование одиночных пакетов vs lodash.
Вы не говорили, но статья изначально про то как с помощью pnpm сэкономить место и ускорить работу.
Тут есть нюанс. Ну мы с вами напишем корректный isObject в три строчки сходу, и всё будет ок. Но я предпочту чтоб джуны в моей команде использовали lodash вместо того, чтоб писать свои сравнения, которые потом что-то сломают.
Да, это решается code-review (но зачем?). Да, можно открыть исходники lodash и скопировать имплементацию. Но чем это отличается от запекания текущей версии lodash в package-lock и использовании его как пакета?
Я соглашусь, что если рассматривать ситуацию в общем, то все не так однозначно, но тут скорее вопрос к контрибьютерам webpack и его зависимостей - почему нельзя заменить этот и подобные пакеты несколькими строчками кода? Или они тоже боятся, что джуны все сломают?
Защита что кто-то сломает npm репозиторий и поменяет текущие версии в нём? Всё может быть, но это уже паранойя.
Есть вариант, что кто-то может взломать одного из авторов и залить туда malware, что совсем не есть параноя и происходит достаточно часто.
Тут же стоял вопрос не размера конечного бандла, так как все современные сборщики умеют делать tree shaking и использование pnpm в этом плане ничего не решает. Речь идет о том, что вместо того, чтобы написать 3 строчки кода, люди непонятно зачем тянут в проект зависимость в 277 строк, которую они никак не контролируют. То есть webpack и множество других утилит, которыми пользуются тысячи людей, стоит на вот таком вот фундаменте.
Вот меня тоже несколько пугает, что 300-500MB для пакетов, это считается норм.
Разработчики совсем оторвались от реальности. Никого не удивляет, что для того, чтобы собрать какую-то страничку с формочкой, тебе нужно качать такие объемы с десятками непонятных пакетов.
Я некоторое время назад разбирался с поломкой в webpack (после очередного обновления) и решил посмотреть, что там за модули он с собой тянет. Как оказалось со времен left-pad ничего особо не поменялось. Теперь у нас есть не менее важный пакет https://github.com/tarruda/has:
Object.prototype.hasOwnProperty.call shortcut
Вот его код:
'use strict';
var bind = require('function-bind');
module.exports = bind.call(Function.call, Object.prototype.hasOwnProperty);
Заметьте, что он даже имеет зависимость 'function-bind'.
/*!
* isobject <https://github.com/jonschlinkert/isobject>
*
* Copyright (c) 2014-2017, Jon Schlinkert.
* Released under the MIT License.
*/
'use strict';
module.exports = function isObject(val) {
return val != null && typeof val === 'object' && Array.isArray(val) === false;
};
Вообщем, изначально здравая идея переиспользования кода в js экосистеме доведена до абсурда, и как мне кажется, делая очередной пакетный менеджер вы решаете не ту проблему.
Ну, почему? Ферматист был уверен, что теорема верна.
Ну это понятно, что они были уверены. Да и вообще можно было бы не напрягаться и использовать "универсальное доказательство" - "Очевидно, что ..." и дальше идет формулировка :)
А "наоборот" это как?;) Понимание без доказательства?
Ага, я думаю, что понимания без доказательства быть не может. Хотя это все конечно относительно, в том смысле, что считать доказательством, а что нет. Вот например Начала Евклида до 19-го века считались своего рода эталоном в математике, а потом решили, что нет, они недостаточно строгие и большая часть его доказательств уже не воспринимаются как доказательства в современном понимании.
Естественно, с этим никто не спорит. Точно так же, как доказательство корректности алгоритма для целых чисел ничего не говорит о корректности на числах с плавающей точкой. Доказывать надо про ту реализацию, которая написана в коде. И использование одного и того же языка для описания алгоритма и доказательства его свойств здесь помогает, а не мешает.
Ок, возможно с моей стороны было просто недопонимание вашей позиции.
Я имел ввиду понимание не формулировки теоремы, а того, "почему" теорема верна, а этого ферматисты уж точно не понимали. Доказательство без понимания может быть, а вот наоборот нет :) Например Гаусс дал около пяти или шести доказательств "Квадратичного закона взаимности", так как первоначальные его видимо не устраивали.
Если при неформальном доказательстве я вывожу в тетрадке слова «доказывается по индукции» (или, тем более, «вот два интересных случая, остальное доказывается по индукции»), то делегирование проверки этой самой индукции оракулу никак не ухудшит моё понимание.
Я имел ввиду не просто стандартный метод доказательства по индукции, а случаи, когда вывод доказательства очень длинный и сложный. Ну например, в математике есть понятие "Элементарное доказательство", но такие доказательства не являются простыми, а наоборот существенно сложнее для понимания.
Возьмите джаву, там всё с представлением и с поведением хорошо.
Ну начали мы с UB в C\C++, а там как раз ассоциативность нарушена, так как в одном случае ты получишь корректный результат, а в другом может быть ошибка переполнения.
Так вы и не положительные целые числа рассматриваете, а другой объект.
Да, получается, что в любом случае, когда на языке более высокого уровня, ты работаешь с типом int, то на низком уровне, в большинстве случаев, ты работаешь с кольцом вычетов по модулю, элементы которого интерпретируются как целые числа, но с разным поведением, которое зависит от имплементации.
Что тут сломается — это не ассоциативность, а ∀ x. x + 1 > x. Ничего страшного, можно продуктивно жить и без этого факта.
Я согласен, что это не ассоциативность, но это не "ничего страшного", так как ты так же не можешь полагаться на проверки диапазонов.
Скажу честно, что я не разбираюсь в языках для формальных доказательств и вообще в теме формальных доказательств корректности программ, поэтому не могу спорить о чем-то по существу. Я просто имел ввиду, что математические абстракции в виде целых чисел и их имплементации в программах не равнозначны, и математическое доказательство корректности алгоритма для целых чисел не дает никакой гарантии.
Кроме гипотезы Римана есть куча других фактов, но доказательство которых не представляет интереса. Я бы с радостью делегировал их доказательство оракулу.
Да, но тогда вы жертвуете пониманием.
Представьте себе обычный int и забудьте, что signed integer overflow — UB. Для каких a, b и c это будет нарушено?
Если я не ошибаюсь, то здесь нам приходится полагаться на представление чисел (2's complement). Но все равно остается такая проблема, что в чистой математике сумма двух положительных целых чисел никогда не может быть отрицательной, а в реальной программе может.
Честно говоря не совсем понял, к чему относится ваш комментарий, так как я и говорил о том, что не нужно просто запоминать, а аналогия с пультом, пакетиком и телевизором немного странная :)
Не, я такого не говорил. Я имел ввиду, что важно запоминать и анализировать новую информацию в связке с уже имеющейся и встраивать ее в свою "картину мира".
Банальный пример с датами - часто можно слышать фразы - "Даты событий не нужно запоминать, так как их всегда можно нагуглить/посмотреть". Если ты запоминаешь даты событий просто как циферки, то да, тогда они мало полезны, но запоминание дат как "временной картины" событий, дает тебе возможность выстраивать и анализировать их ход в уме и связывать с уже известной тебе ранее последовательностью событий.
Вот я с этим абсолютно согласен. Все рассказы о том, что теперь можно ничего не запоминать, а просто нагуглить - полная чушь.
Информация != знания. Если ты ничего не помнишь, а полагаешься на гугл, то ты не можешь нормально мыслить. В итоге мы получаем, что вроде информации у нас все больше и больше, а ее понимания все меньше и меньше.
Да, для жанра антиутопии слишком мрачно, а вот как исторический роман будет самое то.
Что это вы такое говорите, а как же Метавселенная Цукерберга?
This is the future we want, and I'm going to keep pushing and giving everything I've got to make this happen. (c) Mark Zuckerberg
После этих слов лично я спокоен за наше будущее.
Вы пытаетесь доводить аргумент до абсурда, типа в оптимизированном коде вообще невозможно разобраться и что-то изменить, поэтому не старайтесь. Получается тезис вроде: "Выбираете - читаемый и поддерживаемый код как предлагаю я или нечитаемый и неподдерживаемый код как предлагаете вы".
Может в данном случае, это не лучший пример, но ничего прям смешного я тут не вижу. Может быть вообще такое, что подобной оптимизацией вы только сделаете хуже. Например, вы решили поменять обычный массив o(n) на хеш таблицу o(1). Но обращение к данным у вас в программе идет последовательно с множеством попаданий в кеш. Теперь получается, что большинство обращений будут cache miss, так как обращение к данным в хеш таблице уже не последовательно. В итоге производительность может упасть в 10-100 раз и это не покроет разницу в асимптотическом выигрыше. Это просто пример того, что не все так однозначно.
Я писал, что нужно искать баланс между понятностью и производительностью, а вы говорите, что понятность должна стоять на первом плане, а к тому же код даже может быть неправильным, но главное понятным. Вас самого это не смущает?
Взгляните на это со стороны заказчика или пользователя - если программа тормозит и некорректно работает, то оправдание - "зато код понятно написан" вы считаете адекватным?
Оптимизации с учетом использования кешей процессора и правильного обращения к памяти на практике обычно оказываются еще важнее, так как эти O(x) оценки лишь асимптотические.
Но опять же, все зависит от ситуации и как я уже говорил, здесь нужно искать баланс и компромис.
Звучит очень странно. Код для читателя пишется в первую очередь в учебниках и статьях, но в основном код пишется, чтобы исполняться и решать задачу.
В утверждении о том, что код чаще читается, чем пишется, забывается о том, что намного чаще он исполняется на процессоре. Во всем конечно нужен баланс, но ваше утверждение о приоритете понятности уж слишком категорично, а уж о том, что неправильный понятный код лучше правильного непонятного вообще смешно. Понятный/непонятный, это слишком субъективные понятия в сравнении с правильный/неправильный.
Либо я не ошибся и вы практикуете ролевые игры на хабре :)
Какие факты? Если вы приводите данного персонажа в пример, то должны знать, что его аудитория действует по принципу "Вижу Панчина, сначала лайк потом просмотр". Так что рассуждать о серьезности восприятия на основании таких плюсиков мне кажется не стоит.
Из приведенной вами статьи Панчина можно сделать вывод, что Панчин и Логика, это как П и Л - издали вроде похожи, но если хорошо присмотреться, то оказывается, что это совсем разные вещи и даже рядом не стоят.
Таким способом невозможно доказать природное происхождение.
Ну а в конце статьи, как обычно нужно добавить всякую чушь про 5G, чипирование и тп. Что еще раз показывает, что клоунады у него больше чем науки.
Хочу заметить, что я не являюсь сторонником lab-leak теории, я просто говорю о том, что эти типа доказательства совсем не доказательства. И как раз антинаучно до проведения тщательного расследования явно отвергать одну из гипотез лишь на основании изначального отсутствия прямых доказательств, что как известно не является доказательством отсутствия.
Вы должно быть хорошо разбираетесь, как мыслят конспирологи.
Похоже на толстый троллинг. Я не верю, что можно всерьез воспринимать статьи Панчина.
Вы не говорили, но статья изначально про то как с помощью pnpm сэкономить место и ускорить работу.
Я соглашусь, что если рассматривать ситуацию в общем, то все не так однозначно, но тут скорее вопрос к контрибьютерам webpack и его зависимостей - почему нельзя заменить этот и подобные пакеты несколькими строчками кода? Или они тоже боятся, что джуны все сломают?
Есть вариант, что кто-то может взломать одного из авторов и залить туда malware, что совсем не есть параноя и происходит достаточно часто.
Тут же стоял вопрос не размера конечного бандла, так как все современные сборщики умеют делать tree shaking и использование pnpm в этом плане ничего не решает. Речь идет о том, что вместо того, чтобы написать 3 строчки кода, люди непонятно зачем тянут в проект зависимость в 277 строк, которую они никак не контролируют. То есть webpack и множество других утилит, которыми пользуются тысячи людей, стоит на вот таком вот фундаменте.
Вы шутите?
Каждый раз качать 5 файлов и 277 строк, ради функции в 3 строчки?
Вот меня тоже несколько пугает, что 300-500MB для пакетов, это считается норм.
Разработчики совсем оторвались от реальности. Никого не удивляет, что для того, чтобы собрать какую-то страничку с формочкой, тебе нужно качать такие объемы с десятками непонятных пакетов.
Я некоторое время назад разбирался с поломкой в webpack (после очередного обновления) и решил посмотреть, что там за модули он с собой тянет. Как оказалось со времен left-pad ничего особо не поменялось. Теперь у нас есть не менее важный пакет https://github.com/tarruda/has:
Вот его код:
Заметьте, что он даже имеет зависимость 'function-bind'.
Также есть пакет https://github.com/jonschlinkert/isobject с чуть более замысловатой имплементацией, но хоть без зависимостей:
Вообщем, изначально здравая идея переиспользования кода в js экосистеме доведена до абсурда, и как мне кажется, делая очередной пакетный менеджер вы решаете не ту проблему.
Ну это понятно, что они были уверены. Да и вообще можно было бы не напрягаться и использовать "универсальное доказательство" - "Очевидно, что ..." и дальше идет формулировка :)
Ага, я думаю, что понимания без доказательства быть не может. Хотя это все конечно относительно, в том смысле, что считать доказательством, а что нет. Вот например Начала Евклида до 19-го века считались своего рода эталоном в математике, а потом решили, что нет, они недостаточно строгие и большая часть его доказательств уже не воспринимаются как доказательства в современном понимании.
https://en.wikipedia.org/wiki/Elementary_proof
Ок, возможно с моей стороны было просто недопонимание вашей позиции.
Я имел ввиду понимание не формулировки теоремы, а того, "почему" теорема верна, а этого ферматисты уж точно не понимали. Доказательство без понимания может быть, а вот наоборот нет :) Например Гаусс дал около пяти или шести доказательств "Квадратичного закона взаимности", так как первоначальные его видимо не устраивали.
Я имел ввиду не просто стандартный метод доказательства по индукции, а случаи, когда вывод доказательства очень длинный и сложный. Ну например, в математике есть понятие "Элементарное доказательство", но такие доказательства не являются простыми, а наоборот существенно сложнее для понимания.
Ну начали мы с UB в C\C++, а там как раз ассоциативность нарушена, так как в одном случае ты получишь корректный результат, а в другом может быть ошибка переполнения.
Да, получается, что в любом случае, когда на языке более высокого уровня, ты работаешь с типом int, то на низком уровне, в большинстве случаев, ты работаешь с кольцом вычетов по модулю, элементы которого интерпретируются как целые числа, но с разным поведением, которое зависит от имплементации.
Я согласен, что это не ассоциативность, но это не "ничего страшного", так как ты так же не можешь полагаться на проверки диапазонов.
Скажу честно, что я не разбираюсь в языках для формальных доказательств и вообще в теме формальных доказательств корректности программ, поэтому не могу спорить о чем-то по существу. Я просто имел ввиду, что математические абстракции в виде целых чисел и их имплементации в программах не равнозначны, и математическое доказательство корректности алгоритма для целых чисел не дает никакой гарантии.
Да, но тогда вы жертвуете пониманием.
Если я не ошибаюсь, то здесь нам приходится полагаться на представление чисел (2's complement). Но все равно остается такая проблема, что в чистой математике сумма двух положительных целых чисел никогда не может быть отрицательной, а в реальной программе может.