• Спросите Итана: могут ли потери на излучение звёзд объяснить тёмную энергию?
    0

    Обьясните почему вселенных много, а сверхпространство одно? Почему рекурсвное правило "множественность лучше" останавливается у вас всего на уровень выше, а не уходит в бесконечность?

  • Спросите Итана: могут ли потери на излучение звёзд объяснить тёмную энергию?
    0

    Вы говорите, что количество вселенных действительно бесконечно. Ни пруфов, ни полезных следствий.


    Если я ошибся с пониманием количества вселенных у вас, то попрошу назвать критерий остановки

  • Спросите Итана: могут ли потери на излучение звёзд объяснить тёмную энергию?
    0

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

  • Спросите Итана: могут ли потери на излучение звёзд объяснить тёмную энергию?
    0

    Хотел бы напомнить, что избегаем мы совокупной сложности, а не только видимой.


    Для того, чтобы предсказывать мир в рамках мультивселенной нам нужно иметь описание всей мультивсленной (правил её порождающих) +
    описание способа идентификации текущей вселенной. Чем больше вселенных, тем сложнее второе.


    Зачем вообще это нужно: чтобы избежать overfitting

  • Спросите Итана: могут ли потери на излучение звёзд объяснить тёмную энергию?
    0

    Бритва Оккама нынче не в мейнстриме

  • Рефакторинг программы на Go: ускорение в 23 раза
    +1

    Потому что супероптимизаторы никто в 21 веке ещё не написал. Немного трудная задача

  • Цена рефакторинга
    0

    Теперь ясен пример с Нотчем. Если было действительно так, как вы описывали, это действительно вопрос этики. Хотя странно, что не было договоренностей на этот счёт.


    Касательно плохого кода. Дело не в том, какое качество кода. А в том, были ли нарушены чьи-то ожидания. Если покупатель перед покупкой знает, что там говнокодище и многие программисты не будут продолжать над ним работу, то нет этической проблемы.

  • Цена рефакторинга
    0

    У вас содержится неявная предпосылка "если Нотч свалил, то значит Нотч говнокодил специально". Иначе пример Нотча бессмысленнен в контексте разговора.


    А то, о чем вы говорите похоже на киберсквоттинг. "Вот видишь сколько посещений у домена, прикупить не хочешь?". Но это передергивание. Реальный косяк примера со стартапом заключается в том, что у вас появилось хоть какое-то обоснование кроме "пох, что будет завтра и не у меня"

  • На переднем крае науки: анализ статей arxiv.org
    +1
    Такое впечатление, будто вы пытаетесь оправдаться :-)
  • Цена рефакторинга
    0

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


    Ну, что ж. Наверное в список проблем стоит добавить "босс — гондон". Честно, я совсем не имею понятия, что советовать гондонам. Я абсолютно некомптентен в вашем вопросе

  • Выборы вообще не работают; во всём нужно винить математику
    0
    Спасибо за поправку, я не очень хорошо изначально сформулировал.
  • Выборы вообще не работают; во всём нужно винить математику
    +2

    Мне очень странно читать статьи со спекулятивными выводами


    Парадокс Эрроу, за который он получил нобелевскую премию в 1971, говорит, что за пределами выбора большинством голосов из двух кандидатов, не существует метода для точного определения выбора большинства

    Этот отрывок ссылается на википедию. Заходим в вики и видим:


    В рамках кардиналистского подхода, предполагающего количественную измеримость предпочтений, теорема Эрроу в общем случае не работает

    Внезапно, да? Теорема применима, только если мы четко решили, что можно голосовать только одним конкретным определенным образом. Другими словами: теорема Эрроу утверждает, что некоторые системы голосования — хрень, и их применять не стоит.


    Но давайте посмотрим, что именно утверждает теорема Эрроу.


    Смысл этой теоремы состоит в том, что в рамках ординалистского подхода не существует метода объединения индивидуальных предпочтений для трёх и более альтернатив, который удовлетворял бы некоторым вполне справедливым условиям и всегда давал бы логически непротиворечивый результат.

    Буквально это значит: в рамках определенного подхода существует ряд ситуаций, когда получается ерунда. Ничего о том, насколько часто это происходит.


    Что вообще значат все эти парадоксы выборов: иногда волю избирателей нельзя определить математическими методами. Искать решение в таких ситуациях стоит вне математики.


    Дальше, странная вещь. Я не нашёл примера парадокса, при котором побеждает откровенно трешовый кандидат. Возможно, что система выбора просто отображает тот факт, что в ряде случаев кандидаты идут в притирку. И манипуляциями можно вывести любого кандидата в победители.


    А вот чего стоит знать о парадоксах. На самом деле реальность страшнее. Математические теоремы парадоксов выбора основываются на том, что отдельный выборщик может четко выбрать между двумя альтернативами. Но это не так. Люди постоянно сомневаются. Люди чего-то не знают. А это усиливает парадоксы. Вероятно, инженеры понимают, что в ситуациях минимального перевеса люди изменят свое мнение после понимания реальных дел.


    Так стоит ли так волноваться о парадоксах? Или может лучше думать о том, как дать людям возможность сделать выбор, о котором они не пожалеют?

  • Цена рефакторинга
    +6

    Эта проблема называется "недостаток коммуникации" и "микроменджмент".


    Вместо того, чтобы объяснить суть поставленных задач босс пытается выполнять работу программиста.


    Естественно, что:
    1) босс будет принимать технические решения хуже, чем программист
    2) програмист будет считать босса некомпетным самоуверенным дебилом, потому что не знает обстоятельств
    3) даже если программист будет выполнять требования, то это будут не те требования, которые изначально нужны

  • Разбираем популярный миф: «Вещество на 99% состоит из пустоты»
    +2

    В 2018 году писать заумнообразные простыни, надеясь что их никто не прочтет? Серьезно?


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

  • IDisposable — что ваша мама не говорила об освобождении ресурсов. Часть 1
    –2

    В дополнение к статье. В отличии от конструкции using тип shared_ptr меньше подвержен проблемам протечки абстракции.


    Если у вас есть достаточно сложный код, то весьма вероятно, что Dispose вызовется позже, чем мог бы быть вызван при оптимальном использовании.


    А shared_ptr убивает объект моментально при отсутствии ссылок.

  • IDisposable — что ваша мама не говорила об освобождении ресурсов. Часть 1
    0

    Сборщики мусора и автоматическое управление памятью действительно таки усложняют жизнь в ряде случаев. Просто в области применения C# таких случаев действительно очень мало

  • О значении доброжелательности в команде
    0
    Пункт 3 не объясняет, как мы приходим к выбору «или Линус ругается как чёрт, или линукс не является нужным». Можно ревьюить код незнакомых людей, не ругаясь при этом как чёрт.

    Нет, ваше «можно» можно рассыпать дополнительными условиями, чтобы тактика «материться как строитель» была самой рациональной.

    Я попытаюсь проиллюстрировать примерами:

    1) Если вы ревьювите одного-трех человек, то вы можете подстраиваться под каждого и даже лизать им. Если вы ревьювите код сотни человек, то у вас тупо не хватит времени в сутках подстраиваться под каждого. Даже в чистом ревью есть пределы того, насколько вы можете быть хорошим и замечательным.

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

    3) Представьте, что вам приходится ревьювить людей, которые случайно попали в профессию, не понимают банальных вещей и работают спустя рукава. Какие эмоции у вас это будет вызывать? Как долго вы продержитесь, если не будете выпускать пар?

    Теперь вернемся к Линусу и линуксу. Очень похоже, что:
    1) Линус занимается линуксом не для того, чтобы обучать программистов;
    2) В линукс пытается зайти дохрена кода;
    3) У Линуса есть строгие требования качества к продукту, которые он ставит выше чувств говнопрограммистов. Был бы популярен линукс, если бы он был бы гавном?
    4) Трудно предсказать, каким был бы линукс если бы не вклад других хороших программистов. Очень возможно, что продукт был бы недоразвитым. И кому он был бы нужен?

    Линусу нужно привлекать хороших программистов (код которых не вызывает эмоции «блять, ты что дебил?») и отсекать плохих программистов. Его подход вполне работает.

    Заметьте, я не говорю, что такой подход работает всегда и должен использоваться как пример для подражания в любой команде. Линукс определенно уникальный продукт и большинство компаний не имеет схожих условий разработки.
  • О значении доброжелательности в команде
    0
    Простите, но ваше «сменить работу несложно» — это огромное заблуждение.

    1) Начнем с того, сколько технических скиллов может понадобиться человеку. Возьмем какого-нибудь программиста js/php с зп 500-800$ и попытаемся его устроить в компанию занимающейся разработкой на Java/whatever. Это потребует от полугода до года обучения. А еще долгих муторных попыток трудоустройства.

    2) Дальше полутехнические скиллы. Есть компании, в которых не налажена даже система контроля версий. Есть компании, в которых есть code review, continious integration, tdd и т.д. Разрыв между культурой разработки может быть адски большой. И это все тоже требует обучения.

    3) Я уже не говорю о софт-скиллах. Хотя бы о банальном разговорном английском.

    4) Может случиться такая ситуация, что для того, чтобы перейти из ядовитой компании в хорошую нужно затратить очень дофига времени. Просто потому что они работают по другому и имеют более высокие требования к кадрам.

    5) У вас (возможно) есть неявное предположение, что разработчик понимает, что есть нетоксичные компании. После пары смен токсичных компаний попытка рассказать о хороших компаниях будет восприниматься человеком как сказки о единорогах

    6) У вас (возможно) есть неявное предположение, что невозможность смены работы не может происходить из сложной финансовой ситуации или какой-нибудь такой объективной хуйни.

    7) У вас (возможно) есть неявное предположение, что невозможность дообучения не может происходить из проблемы с физическим здоровьем (физическая усталость), с психическим здоровьем (апатия, депрессия, стрессы, выгорание), с недостатком времени (человеку нужно ухаживать за ребенком).
  • О значении доброжелательности в команде
    0

    Послушайте, вы нанимаете дебила и требуете, чтобы с ним обращались лучше, чем с белым человеком.


    То, что вы описали — не доброжелательность, а социальные игры.

  • О значении доброжелательности в команде
    0

    1) Мир разработки шире, чем вы думаете. Не всякий программист крут и высокоплачиваем.


    2) Человеку вне разработки трудно понять кто прав.


    3) Линусу приходится смотреть на код абсолютно левых ему людей. Один из залогов популярности линукса — open source

  • Мысленные эксперименты над сознанием: Что это? Где оно находится? Оно вообще существует?
    0

    Вопросы затрагивающиеся в статье находятся в стадии "мы нихрена на понимаем даже куда копать" (прим; ИИ нет, доказательства невозможности ИИ нет = никто ничего не понимает). А со стороны автор не отличается от других пиздаболов.


    На ошибки, кстати, указывают. Но не "rtfm", а на конкретные косяки. Что куда лучше, чем просто обосрать автора. В ко'сентвриях к техническим статьям такое тоже встречается, если они не совсем говно

  • О значении доброжелательности в команде
    0

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


    К слову. Если развивать вашу позицию, то мы придем к выбору: или Линус ругается как черт, или линукс не является нужным.

  • О значении доброжелательности в команде
    +2

    Для того, чтобы разрушить команду CircleCi достаточно запустить в команду двоих: начальника склонного к кумовству или жополизству; и одного дауна с подвешенным языком или родственными связями. Т.е просто дауна, которого уволить нельзя.

  • Антипаттерны тестирования ПО
    0
    Интеграционными он называет компонентные тесты, что является довольно распространённой ошибкой. Интеграционный тест проверяет взаимодействие модулей
    В защиту автора хочу сказать, что есть разница между академическим определением и тем как термины понимают в жизни. То, что описывает автор ближе к людям. Хотя такие ремарки конечно стоит делать.

    Ну а пресловутая «бизнес-логика» — это вообще не понятно что. Что это за мифическое приложение такое без «бизнесс-логики»?
    Есть довольно широкий класс малопродуманных полуполезных говноприложений.
  • Не пишите лишнего
    0
    Примерно это, да. За разными языками закреплены разные стереотипы, не обязательно обоснованные. Я просто объясняю соль шутки.
  • Не пишите лишнего
    0
    :-). Да причем тут php и процедурно.

    Систему можно разбивать более чем одним способом. А еще разный способ подходит под разные задачи.

    Но. Когда систему бьют, чтобы бить; когда абстракции выделяют бездумно и в огромном количестве; когда количество смысла на строку текста приближается к нулю. Вот тогда мы получаем ООП головного мозга.
  • Не пишите лишнего
    0
    У разных языков и их фанатов разные интерпретации понимания термина ООП. Реализации реально очень разные. И как правило программисты в рамках одного языка пересекаются чаще, чем в рамках разных. И это формирует общий стиль мышления и кодирования.
  • Почему SQLite не использует Git
    +2
    ACID может обеспечиваться и без СУБД, но нужно обеспечивать. В ACID системах есть механизмы восстановления после креша. Git этим не заморачивается вообще. Буквально — если убить процесс СУБД, то после перезапуска она будет работать, а не прикидываться ветошью. Если убить процесс git, то следующая операция может тупо не пройти, потому что он не может восстановиться от промежуточного состояния. Никаких повреждений данных не нужно — нужно только прервать процесс в нужный момент.
  • Прогулка по быстрому, безопасному и почти законченному веб-сервису на Rust
    +1
    Насколько я понимаю в Rust есть union-тайпы и pattern matching, которые открывают возможности для type driven development. Я не могу пока что сказать что-то конкретное по поводу жизнеспособности этого подхода, но по первым ощущениям — он приносит выгоду.

    Для примера можно почитатьType Driven Development with F#
  • Прогулка по быстрому, безопасному и почти законченному веб-сервису на Rust
    +1
    А еще вы можете передать null

    Забавно, но вы как раз пытаетесь проиллюстрировать проблемы статической типизации наиболее встречающимся динамическим элементом, от которого не защитились.

    К слову, у Java одна из наиболее убогих систем типизации по сравнению со многими другими языками.

    Я не совсем понимаю, почему остальные проблемы рантайма игнорируются
    Разные языки решают разные проблемы по-разному. Кроме того, существует огромный пласт языков немейнстримных или вообще игрушечных, в которых многие проблемы пытаются решить.

    А какая из проблем вам больше всего доставляет?
  • Почему SQLite не использует Git
    +2

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

  • Что будет если объединить ArrayList и LinkedList?
    0
    Пробежкой галопом по связному списку с учетом разного количества элементов в каждом узле. За O(N) и малой константой, как у вас.
  • Что будет если объединить ArrayList и LinkedList?
    +5

    Вы переизобрели Unrolled Linked List?

  • REST API Best Practices
    0

    Итоговая производительность у graphql-клиента будет выше за счёт объединения запросов

  • Алгоритм Пинг-Понг или критика Обратной Польской Нотации
    0
    Если сложность ваших алгоритмов отличается, нет вообще никакого смысла подсчитывать, сколько у вас там операций сравнения на одном шаге и предполагать сколько раз предсказатель ветвлений промахнётся.

    Нууу нет. Другое дело, что человек не бенчи гоняет, а слова туда-сюда.

    В целом я бы сказал, что в этой задачи есть естественный предел на входящее выражение. Сомнительно, что будут гонять выражения с миллионами операндов. А значит влияние константы становится очень важным.
    Этот как использование bubble sort для малых отрезков внутри quick sort — асимптотика хуже, но константа меньше сильно.
  • Массивы, указатели и другие квантовые явления вокруг нас
    0

    Простите, я не разбираюсь в си.


    У меня есть предположение, что концепция ub была введена, чтобы компилятор работал быстрее и не тратил ресурсы на поиск неадекватного кода. Насколько адекватно моё предположение?


    И связанный вопрос: замедляется ли (или замедлялась ли в прошлом) сборка проекта при этих флагах?

  • Вам действительно нужен Redux?
    0
    Если гарантировать что в reducer попадет честный getState, а к компонентам завернутый getState, то может сработать.
    Но все еще нужен механизм по комбинированию такого стейта. Я не уверен, что селекторов хватит, хотя и может хватить.
  • Вам действительно нужен Redux?
    0
    Нууу, очень странный вопрос. Вы приписываете эту проблему redux, а эта проблема проявляется при многих видах интеграции.

    Либо вы волевым решением навязываете end-user ваше видение того как хранится стейт, либо отдаете это на откуп ему.

    Навязывание как правило превращает вашу либу в говно, поэтому вы обречены копаться в говне. Чтобы не копаться в говне — не пишите говна.

    И как его написать? В этом же и вопрос. Просто отвечать на вопрос «как написать» — «примитивно напишите» очень странно.
    Под «примитивным redux» я подразумевал решение, которое просто работает и которое написано как вам нравится. А если кому-то не нравится как конкретно оно работает, то он может взять и написать под себя используя универсальный компонент.

    Впрочем вы можете попытаться экспортировать не просто reducer, а high-order-reducer который можно параметризовать маппингом get/set state. Это в теории должно дать возможность приаттачивать состояние к другой части дерева.

    Но тут будет много проблем:
    — можно хранить стейт как raw objects, ImmutableJS, seamless immutable, mori — в общем так, как не хочет end-user;
    — приаттачивать состояние к другой части стейта может акнуться, потому что другой код может затирать нахер стейт аккордиона.

    У меня вопрос: почему вы не любите нормализованный стейт?
  • Вам действительно нужен Redux?
    –2
    Краткая инструкция:

    1. Не используйте redux как API внутри универсальных компонентов;
    2. Не используйте setState как API внутри универсальных компонентов;
    3. В Props ожидайте методы, которые читают состояние и которые пишут состояние;
    4. Напишите пару говноврапперов над универсальным компонентом для хипстеров: один с setState, другой с примитивным redux. Второй можно не писать.


    Теперь объясню почему у вас вылезла проблема. Redux-way — это сохранять стейт, чтобы он не потерялся. Но у end-developer уже есть свое видение того как должен храниться стейт. Эти видения не могут быть всегда совместимыми.

    Проблема интеграции чужих говен модулей/систем вечна. И пока что никто не знает как её решить оптимальным образом.

    И вообще, end-developerу может быть пофиг на то, что этот конкретный стейт может потеряться. Или он может считать, что в его системе этот стейт не может потеряться.

    P.S: Мою краткую инструкцию можно распечатать и использовать в качестве туалетной бумаги. Ибо я не пишу универсальные компоненты.
  • Вам действительно нужен Redux?
    0
    Бизнес-логика не только меняет данные, а еще и читает их. Одних action generatorов вам не хватит