Так сравнивать нельзя: big-O же ничего не говорит про константы и про «менее быстро» растущие части функции.
0.0001*exp(x)-10000 — это всё равно O(exp(x))
100000*x+10000000*sqrt(x)+100000000000 — всё равно O(x)
Конечно используются. В JDK и .NET Core используется умножение Карацубы (в JDK 11 по умолчанию умножение переходит на Карацубу, если множители больше 2560 бит ). В JDK с множителей длины 7680 бит используется умножение Тоома-Кука.
Оп! А в бухгалтерии-то 1С, а в этой платформе нет настоящих плавающих запятых. Ну точнее есть, но только на границе с внешним миром (и то не всегда) и в кишках математических функций, которые внутри с float/double работают (но параметры и результат — всё равно свои числа).
Тип «Число» в переменных это примерно как BigDecimal в Java (но, если ничего не изменилось за 5 лет, существенно менее эффективный). В БД в полях, доступных программисту конфигурации — Numeric из SQL (с ограничением длины и точности), который отображается в такой же ограниченный тип в памяти с достаточно необычным подходом к переполнению. Так что в бухгалтерии всё сойдётся :) Ну или не сойдётся по другой причине.
Классических Int, замечу, тоже почти-почти нет. И это имеет свою цену с точки зрения производительности — другой настолько тормозной системы в задаче «посчитай в цикле до миллиарда» даже среди интерпретаторов не найти.
Посидеть половину дня без дополнений — не смертельно.
У меня 988 открытых вкладок. Кстати, я об этом знаю от дополнения (Tab Counter). Вкладки распиханы по страницам и по дереву вкладок (Tree Tabs — отображается слева, глючный, но терплю). Конечно, включены и uOrigin, и uMatrix. А пароли я не помню потому что Kee Pass. Ах, да, еще меня достали utm в url, поэтому Neat Url. А чтобы ссылку на телефоне открывать без перенабирания и посылания самому себе — Tab2QR. С FF на хром c таким количеством вкладок и без древовидного представления не перейти в принципе. FF без дерева — тоже не особо нужен. Полдня с полоской из примерно 1000 вкладок? Really??? А пользователям TorBrowser хватит 10 секунд словить неанонимность. Так что фейл реально фейловый.
То, что люди ошибки совершают — это норм и понятно. GitLab'у простили же как чуть не протеряли свою PostgreSQL. Но FF за последние несколько лет и "естественно" теряет пользователей (просто потому что альтернативы нормальные), и дополнительно выстрелами из дробовика отстреливает (принуждение к подписи аддонов — один из выстрелов). Лично я с FF пока не готов спрыгивать, но не удивлюсь, если аудитория за неделю на 30% уменьшится. А чем меньше пользователей, тем меньше способов монетизации. Чем меньше способов монетизации, тем меньше разработки. При падении ниже определённого порога — войдёт (или вошёл — уже близко) в самозатягивающуюся петлю. И останется один webkit, как IE6 на несколько лет.
Иван, ну на самом деле всё вот это писькомерство: «вы не настоящие, вон из профессии» с одной стороны и «забирай свои монадки и уваливай» с другой — оно если и имеет место то в первые года три работы или до настоящего столкновения с задачей «на два фронта». Банковских джавистов в учётных системах сильно отрезвляет знакомство с задачами на 1С: Специалиста («За 5 часоооов??? С нуля???»), 1Cники начинают сильно грустить от любой задачи, которая выходит за рамки платформы (например, обмен данными в Protocol Buffers или вообще разбор бинарных файлов).
А вот реальные общие задачи, когда с обеих сторон работают нормальные профессионалы, особенно, если они кратко познакомились с технической стороной другой стороны, просто понимают что каждый инструмент своей задаче нужен.
А что насчет строк? String — формально неограниченный тип и теоретически обладает бесконечным числом значений (на практике, естественно, мы не обладаем бесконечной памятью, поэтому конкретное число будет зависеть от конфигурации компьютера).
String в текущих реалиях совсем не бесконечный. В JVM он точно не будет длиннее Integer.MAX_VALUE байт (так как содержит byte[] адресуемый целым числом). Причем не удивлюсь, если из-за деталей реализации окажется еще более ограниченным. Это не так много — 2 ГиБ памяти, а это уже не ограничение даже для современных телефонов. Да, конечно, кардинальное число exp(2,(8*(exp(2,31)-1)) изрядно большое (и даже в BigInteger в Java не влезет), но всё-таки эти пределы уже вполне можно "пощупать".
Егор Бугаенко, конечно, знатный тролль. И в данном контексте это не оскорбление, а, скорее, комплимент: это важное умение — красиво набросить "интересную тему" на вентилятор.
Но что касается сути статьи, тут из-за однобокости и максималистичности подачи потерялся простой факт. Каналы коммуникации обладают сильно разными свойствами. Вот давайте посмотрим на такую табличку:
(Сделал я. Только что. Оценки субъективные из головы — кому не нравится, может, предложить свои варианты цифр, если из-за этого будут другие выводы — обсудим. Картинкой, потому что в предпросмотре таблица не отображается)
Тут:
Latency, с – сколько проходит времени от создания информации (проговаривания или печати) до её восприятия. Важно, что эта latency в письменном тексте не может быть меньше, чем время, на то, чтобы дописать сообщение/текст и отправить его.
Скорость создания (знаков/мин) – по моим наблюдениям, говорим мы обычно (если не диктор новостей) со скоростью 300-600 знаков (кроме пробелов и знаков препинания, если стенографировать), печатаем 100-300 знаков/мин, если хоть немного задумываемся, скорость падает (см "письмо, комментарий"). Реальные текстовые документы, если есть готовое в голове пишутся не быстрее 1500-3000 знаков в час (25-50 знаков в минуту), требется время на вычитку. Важный документ перед публикацией перечитывается столько раз, что скорость набора неважна. Скорость мессенджера, конечно, взята "компьютерная": на мобиле и набор, и восприятие медленнее.
Скорость приема (знаков/мин) – а) скорость восприятия на слух обычно выше, чем комфортно говорить, поэтому лекции/доклады часто удобнее в ютубе просматривать на повышенной скорости; б) скорость чтения среднего ИТ-специалиста 1500-3000 знаков/мин, если умеет скорочтение, то 3000-6000, в) скорость чтения документов выше, потому что мы их редко читаем "до буквы" — в таблице вариант именно "с пропусками"
КПД отдачи вербализируемой информации – в обычной речи обычно очень невысокий КПД реальной информации, хорошо если половина. Если мы пишем, то этот коэффициент возрастает (в зависимости от внимательности к тексту).
КПД приёма вербализируемой информации – но информация теряется не только при её создании, но и при чтении/слушании. По опыту техник быстрого чтения знаю, что среднее восприятие среднего текста у среднего человека примерно 60%, у попыток воспринять информацию на слух — реально и 40% завышено, а если не видеть собеседника, то еще ниже.
КПД приёма невербализируемой информации – эмоции, жесты, мимика — всё это (как и в статье замечено) теряется в письменном общении. Причем если в сообщении в телеге язык менее формален и есть смайлики, то из условного RFC это обычно вычищено.
Кроме этого есть еще несколько особенностей модели.
Во всех кейсах мы полудуплексные. Либо отдаём информацию, либо принимаем. Се ля ви.
Схемы/визуализации. Голосом они почти никак не передаются, для этого обычно используются презентации. Схемы существенно снижают (в знаках в минуту) скорость создания контента, но часто оно того стоит. Я их не рассматриваю для упрощения.
Асинхронность. В личном общении её почти нет. В мессенджере и письмах — ограниченная.
Возможность почти мгновенно прервать незаконченное сообщение/работу (перебить) — уберфича личного общения. Мы можем прервать собеседника на полуслове ("Слушай, ну это же не имеет отношения к теме собрания"). Да, у приёма есть большая цена (в том числе из-за полудуплексности), если все начнут всех перебивать, то обмен информацией ломается. Но именно из-за его эффективности мы все умеем его использовать :) Положительный эффект в том, что говорящему не нужно заканчивать речь. Попробуйте перебить того, кто пишет вам сейчас письмо (ой, мы же об этом и не знаем даже :) )
Каждый канал идеален для своих задач. То, о чем написал Егор — для писем и простых документов. Общение один на один если требуется многократно обмениваться репликами. Мессенджер для асинхронной координации (например, при устранении инцидента.)
Конечно, эти каналы часто используются совместно, чтобы оптимизировать передачу под конкретную задачу:
Парное программирование вносит скорость личного общения в код ревью (строки 4 и 5)
Доклад на конференции — это одновременно и мультиплексирование общения, и обогащение презентацией и быстрое получение обратной связи ("а теперь вопросы")
Протокол совещания позволяет не протерять информацию
Посмотрев на эту модель становится очевидно, что есть много кейсов в разработке ПО, когда общение будет эффективнее переписки. Да, общение не идеально для передачи информации по КПД, но обладает свернизким latency и возможностью прервать недоделанное сообщение. А что касается объёмов — так ведь суть беседы руководителя один на один с сотрудником по кадровым вопросам часто может быть выражена в трёх строках. Но зачастую требует десятки реплик с каждой стороны.
Ну и еще: часто стоимость часа работы (пусть даже 10 высокооплачиваемых сотрудников) ничто по сравнению с возможностью вывести продукт раньше. Если совещание приблизит time to market, то это может окупить несколько недель "экономной" переписки.
Просто любопытно стало, что именно имеется в виду под «программа похожая на Hex-Rays IDA»? Это конкретная программа, которую вы почему-то не хотите называть или IDA, которой у вас «как бы нет»? :)
Ещё один лайфхак. В gitlab есть встроенная web-IDE. Она умеет работать с md. Там же можно делать ревью, там же просматривать, там же редактировать, там же история правки в понятном любому разработчику виде. При этом ещё и редактировать можно в любимом редакторе. Там же можно временно хранить картинки. Ветки git, наверное, никому в такой задаче не приводятся, но они есть.
Про парное программирование всё понятно (и про необходимость взаимодоверия, и про мгновенную конструктивную обратную связь, и про эффективность в удачной паре).
Но меня вот смутили моменты "Код надо было писать на C#, с которым он никогда не работал, поэтому в голове промелькнуло — потрачу кучу времени бестолку." и "Из меня js-ник, как из гофера дженерик, но я действительно ему помог.". На senior-уровне удивительно видеть удивление, что один опытный разработчик может давать разумные советы разработчику на другом языке. Ладно, если бы хотя бы один из них писал на чем-то «радикальном-маргинальном», но почти все коммерческие ЯП (C#, Java, JS, Go, C и даже С++ иногда, Python, Ruby, PHP, Object Pascal, VB и даже 1С) на этом уровне очень-очень похожи. Да, «ревьюер» должен принять, что оформление кода и многие моменты реализации другие, не должен через слово повторять «а вот у нас в [моя платформа] всё было бы лучше», но это к этому моменту (senior же!) уже должно быть гигиеническим навыком. Иначе как такой «senior» будет адаптироваться к деталям code style и к коду «соседних» команд?
Ну да, конечно есть куча «непохожих»: функциональные, как Haskell, Lisp, F# и прочие OCamlы (а знаете как увольняют хаскель-программиста? «собирай свои монадки и уматывай!» (с) Башорг :) ), с непривычной системой типов, как в Scala, или, наоборот, низкоуровневые — ассемблер, с непривычной семантикой памяти (Rust), логические (Prolog), очень специфичные по предметной области (Verilog) и т.п. В этом случае барьер не столько языковой, сколько понятийный. Но и даже здесь есть ислючение — декларативный SQL, который так или иначе на базовом уровне знает не меньше половины программистов «традиционных» языков.
Так что для опытного разработчика не нужно удивляться, что другой опытный разработчик может прочитать код на другом языке и оценить решение.
Даже если 1% из 300 тысяч сотрудников в этом году захочет увеличить озу в два раза, то это будет значительная сумма.
Не будет. Чисто в стоимости самих модулей, если 3000 человек по модулю 8 ГБ, то это примерно 10 млн рублей. Модуль стоит как час (один) работы этого сотрудника. Это дешевле многих закупаемых сбером серверов (которые закупаются стойками). Любые расчеты эффективности будут стоить дороже, чем достигаемая экономия. Вся система типовых конфигураций нужна из-за негибкости и неэффективности сбербанка.
А где там длинные числа? Все эти быстрые умножения (Карацуба и последующие) они про числа в тысячи бит.
0.0001*exp(x)-10000 — это всё равно O(exp(x))
100000*x+10000000*sqrt(x)+100000000000 — всё равно O(x)
Тип «Число» в переменных это примерно как BigDecimal в Java (но, если ничего не изменилось за 5 лет, существенно менее эффективный). В БД в полях, доступных программисту конфигурации — Numeric из SQL (с ограничением длины и точности), который отображается в такой же ограниченный тип в памяти с достаточно необычным подходом к переполнению. Так что в бухгалтерии всё сойдётся :) Ну или не сойдётся по другой причине.
Классических Int, замечу, тоже почти-почти нет. И это имеет свою цену с точки зрения производительности — другой настолько тормозной системы в задаче «посчитай в цикле до миллиарда» даже среди интерпретаторов не найти.
У меня 988 открытых вкладок. Кстати, я об этом знаю от дополнения (Tab Counter). Вкладки распиханы по страницам и по дереву вкладок (Tree Tabs — отображается слева, глючный, но терплю). Конечно, включены и uOrigin, и uMatrix. А пароли я не помню потому что Kee Pass. Ах, да, еще меня достали utm в url, поэтому Neat Url. А чтобы ссылку на телефоне открывать без перенабирания и посылания самому себе — Tab2QR. С FF на хром c таким количеством вкладок и без древовидного представления не перейти в принципе. FF без дерева — тоже не особо нужен. Полдня с полоской из примерно 1000 вкладок? Really??? А пользователям TorBrowser хватит 10 секунд словить неанонимность. Так что фейл реально фейловый.
То, что люди ошибки совершают — это норм и понятно. GitLab'у простили же как чуть не протеряли свою PostgreSQL. Но FF за последние несколько лет и "естественно" теряет пользователей (просто потому что альтернативы нормальные), и дополнительно выстрелами из дробовика отстреливает (принуждение к подписи аддонов — один из выстрелов). Лично я с FF пока не готов спрыгивать, но не удивлюсь, если аудитория за неделю на 30% уменьшится. А чем меньше пользователей, тем меньше способов монетизации. Чем меньше способов монетизации, тем меньше разработки. При падении ниже определённого порога — войдёт (или вошёл — уже близко) в самозатягивающуюся петлю. И останется один webkit, как IE6 на несколько лет.
А вот реальные общие задачи, когда с обеих сторон работают нормальные профессионалы, особенно, если они кратко познакомились с технической стороной другой стороны, просто понимают что каждый инструмент своей задаче нужен.
Еще мне из дополнения 2 момента непонятны
Первое:
А что будет для
Option[Option[Option[A]]]? Насколько я понимаю, новых значений там не появится — всё также будетCardinality.of[A] + 1.Второе — про
Cardinality.of[A => B].Я правильно понимаю, что это всё только про чистые детерминированные функции (иначе
Unit=>Unitне счесть).String в текущих реалиях совсем не бесконечный. В JVM он точно не будет длиннее
Integer.MAX_VALUEбайт (так как содержитbyte[]адресуемый целым числом). Причем не удивлюсь, если из-за деталей реализации окажется еще более ограниченным. Это не так много — 2 ГиБ памяти, а это уже не ограничение даже для современных телефонов. Да, конечно, кардинальное числоexp(2,(8*(exp(2,31)-1))изрядно большое (и даже в BigInteger в Java не влезет), но всё-таки эти пределы уже вполне можно "пощупать".Егор Бугаенко, конечно, знатный тролль. И в данном контексте это не оскорбление, а, скорее, комплимент: это важное умение — красиво набросить "интересную тему" на вентилятор.
Но что касается сути статьи, тут из-за однобокости и максималистичности подачи потерялся простой факт. Каналы коммуникации обладают сильно разными свойствами. Вот давайте посмотрим на такую табличку:
(Сделал я. Только что. Оценки субъективные из головы — кому не нравится, может, предложить свои варианты цифр, если из-за этого будут другие выводы — обсудим. Картинкой, потому что в предпросмотре таблица не отображается)
Тут:
Кроме этого есть еще несколько особенностей модели.
Каждый канал идеален для своих задач. То, о чем написал Егор — для писем и простых документов. Общение один на один если требуется многократно обмениваться репликами. Мессенджер для асинхронной координации (например, при устранении инцидента.)
Конечно, эти каналы часто используются совместно, чтобы оптимизировать передачу под конкретную задачу:
Посмотрев на эту модель становится очевидно, что есть много кейсов в разработке ПО, когда общение будет эффективнее переписки. Да, общение не идеально для передачи информации по КПД, но обладает свернизким latency и возможностью прервать недоделанное сообщение. А что касается объёмов — так ведь суть беседы руководителя один на один с сотрудником по кадровым вопросам часто может быть выражена в трёх строках. Но зачастую требует десятки реплик с каждой стороны.
Ну и еще: часто стоимость часа работы (пусть даже 10 высокооплачиваемых сотрудников) ничто по сравнению с возможностью вывести продукт раньше. Если совещание приблизит time to market, то это может окупить несколько недель "экономной" переписки.
Ещё один лайфхак. В gitlab есть встроенная web-IDE. Она умеет работать с md. Там же можно делать ревью, там же просматривать, там же редактировать, там же история правки в понятном любому разработчику виде. При этом ещё и редактировать можно в любимом редакторе. Там же можно временно хранить картинки. Ветки git, наверное, никому в такой задаче не приводятся, но они есть.
каждая нотка на каждом ладу долбанной скрипки
Это тонкий стёб, как и "Metallika" или "так получилось"?
Прямо к песне: В какое же светлое завтра готов ты ещё рвануться?
(На самом деле статья хорошая)
Но меня вот смутили моменты "Код надо было писать на C#, с которым он никогда не работал, поэтому в голове промелькнуло — потрачу кучу времени бестолку." и "Из меня js-ник, как из гофера дженерик, но я действительно ему помог.". На senior-уровне удивительно видеть удивление, что один опытный разработчик может давать разумные советы разработчику на другом языке. Ладно, если бы хотя бы один из них писал на чем-то «радикальном-маргинальном», но почти все коммерческие ЯП (C#, Java, JS, Go, C и даже С++ иногда, Python, Ruby, PHP, Object Pascal, VB и даже 1С) на этом уровне очень-очень похожи. Да, «ревьюер» должен принять, что оформление кода и многие моменты реализации другие, не должен через слово повторять «а вот у нас в [моя платформа] всё было бы лучше», но это к этому моменту (senior же!) уже должно быть гигиеническим навыком. Иначе как такой «senior» будет адаптироваться к деталям code style и к коду «соседних» команд?
Ну да, конечно есть куча «непохожих»: функциональные, как Haskell, Lisp, F# и прочие OCamlы (а знаете как увольняют хаскель-программиста? «собирай свои монадки и уматывай!» (с) Башорг :) ), с непривычной системой типов, как в Scala, или, наоборот, низкоуровневые — ассемблер, с непривычной семантикой памяти (Rust), логические (Prolog), очень специфичные по предметной области (Verilog) и т.п. В этом случае барьер не столько языковой, сколько понятийный. Но и даже здесь есть ислючение — декларативный SQL, который так или иначе на базовом уровне знает не меньше половины программистов «традиционных» языков.
Так что для опытного разработчика не нужно удивляться, что другой опытный разработчик может прочитать код на другом языке и оценить решение.
Не будет. Чисто в стоимости самих модулей, если 3000 человек по модулю 8 ГБ, то это примерно 10 млн рублей. Модуль стоит как час (один) работы этого сотрудника. Это дешевле многих закупаемых сбером серверов (которые закупаются стойками). Любые расчеты эффективности будут стоить дороже, чем достигаемая экономия. Вся система типовых конфигураций нужна из-за негибкости и неэффективности сбербанка.