Ещё раз, меня интересует вопрос, почему люди находят удовольствие в том, что в реальной жизни порицается
Вторым предложением вы прямым текстом отождествляете насилие в играх и насилие в жизни. Если вы этого не делаете, то и вопроса вашего нет - никто не поощряет то, что в реальной жизни порицается. Ведь в реальной жизни нет аналога вирутальному насилию.
Почему дети играют в "войнушку" и это ок, пускай детишки друг друга "убивают" с помощью палок и шишек, а точно такая же выдуманная игра но перед монитором - это внезапно что-то порицаемое? Ответ один - и то, и другое - это игра, блин!
Почему люди становятся актёрами? Потому что им интересно изображать других людей. Никто не н порицает актёров за то, что они выбирают роли убийц? За что тогда порицать геймеров, которые тоже решили примерить на себя эту РОЛЬ?
Я в VSCode мышкой если и пользуюсь, то ОЧЕНЬ иногда для каких-то жутко странных штук. С ходу могу вспомнить только один сценарий: мне нужно поставить несколько курсоров в случайных местах в тексте и что-то подредактировать такое странное (что, к слову, vim вообще не умеет, ибо multiline edit в vim реализован так плохо, что цензурных слов у меня нет для этого).
У меня студент работает во всяких VSCode, PyCharm и прочих продуктах идеостроя. Когда он показывает результаты, тыкая мышкой во все эти табы с кучей свистоперделок
Ну, а я когда смотрю, сколько лишних движений требует vim для тупейших действий, насколько это всё неудобно, насколько неинтерактивно, у меня слезы наворачиваются.
Я сам вимовод со стажем, и когда я смотрю на своих коллег вимоводов (с ещё большим стажем) - мне больно смотреть. Они делают все ТАК ДОЛГО. Я оперирую горячими клавишами и GUI элементами примерно процентов на 30 быстрее.
Но да, студентики у меня тоже очень ленивые, учить горячие клавиши не хотят и тоже всё тыкают мышкой. Они делают всё НЕВЕРОЯТНО ДОЛГО, иногда хочется им прописать курс vim-а только для того, чтобы появилась привычка делать всё через клавиатуру. Так что проблема не в VSCode. Проблема в студентах)
VSCode вполне себе портабельный и умеет в SSH. В 99% случаев, этого хватает для того, чтобы работать. При условии постоянной смены окружения, Vim просто ужасен, потому как без напильника и тонкой настройки - это удобный инструмент пару-тройку конфигов подправить, но не более.
В принципе, я использую vim для правки мелких вещей каждый день и ничего плохого сказать про него не могу в этом плане. Однако как основной инструмент для работы он требует куда больше настройки и костылей, чем VSCode.
Да, бывают совсем ограниченные среды, без доступа к внешнему интернету, через 5 проксей и RDP, но это прям очень специфические условия. Согласен, тут можно и поюзать vim.
Просто я не понимаю, почему люди продолжают есть этот кактус добровольно) Когда выбор был между vim или тяжеловесной IDE, я могу понять почему выбор падал в сторону vim, но теперь есть промежуточные варианты в виде VSCode или того же Sublime Text. Они имеют портабельные версии, они относительно лёгкие (для современного железа), в них куча плагинов, которые не надо настраивать по 4 дня (как это бывает с vim). Зачем тогда продолжать им пользоваться как основным инструментом?)
Выходить в нормальны режим делать hhhhh, cl... <Esc>A довольно утомительно, не считаете? Отпишитесь пожалуйста если знаете способ лучше, действительно очень интересно
Пускай заминусят, но я знаю офигенный способ решения чуть ли не 100% проблем с vim. Установите VSCode и не парьте мозг. Я много лет проработал с vim, даже научился-таки его варить нормально, но в итоге пришёл к выводу:
раз эти GUI есть, то я не вижу разумных причин ими не пользоваться
Я понимаю, что существует 10 тыщ плагинов, делающих из всего vim и все эти плагины, на мой взгляд, полная лажа) Я не нашел для ничего, чего не может VSCode или что в нём сделано хуже чем в vim.
Ну, если я правильно понял, то мы отказываемся от сортировки и просто линейно проходим по массиву, проверяя есть ли такой элемент в std::set. Соответственно и получаем N log MaxCount.
Однако, если повторяющихся элементов мало, мы будем просматривать первые MaxCount элементов и завершать цикл. Тут я конечно ошибся, ведь сложность будет O ( MacCount log MaxCount ).
Понятное дело, что в худшем случае мы всё равно просмотрим все N элементов, но я рассуждаю именно об амортизированном случае когда повторяющихся элементов "мало". Расчетами для конкретизации "мало" мне лень заниматься.
Много лет пишу на С++, но каждый раз грущу когда вижу всё вот это синтаксическое уродливое безумие, которое необходимо совершить, чтобы сделать простейшие вещи.
Что касаемо приведённых примеров, никакой существенной разницы между классическим подходом и ranges не увидел. Тут прям теорема Эскобара в действии.
Мне всегда было интересно, почему считается, что путешествие во времени возможно в обе стороны? Может быть если путешествия возможны - они возможны только в будущее? В таком случае никаких парадоксов и не будет)
Тут конечно неплохо бы определить что такое "реальность" или хотя бы что такое "свойство реальности" и чем оно отличается от умозрительной конструкции, потому что без этих определений то, что вы сказали не имеет смысла.
Вы только забываете, что эта польза не для сотрудников) Мне как линейному разрабу от всего этого пользы никакой и чем больше шпионского ПО использует работодатель, тем меньше мне с ним хочется работать.
Предлагаемая вами система - это типичный пример такого ПО :) Можно декларировать любые благородные цели, но правда в том, что использовать этот AI будет бесчеловечная корпоративная машина со всеми вытекающими)
Платформу не следуют воспринимать как человека, стоящего за спиной каждого сотрудника
А почему? Ведь в сущности ровно это она и делает. Если что-то можно использовать как инструмент давления на сотрудника - это рано или поздно будет сделано. Ни разу не видел исключений из этого правила.
Попил бабла. Ведь нужно сделать какой-нибудь цензурную коммисию. А этой комиссии нужен глава. А у депутата Госдумы как раз оболтус подрос.
И тут же выдаёте:
Вторым предложением вы прямым текстом отождествляете насилие в играх и насилие в жизни. Если вы этого не делаете, то и вопроса вашего нет - никто не поощряет то, что в реальной жизни порицается. Ведь в реальной жизни нет аналога вирутальному насилию.
Почему дети играют в "войнушку" и это ок, пускай детишки друг друга "убивают" с помощью палок и шишек, а точно такая же выдуманная игра но перед монитором - это внезапно что-то порицаемое? Ответ один - и то, и другое - это игра, блин!
Почему люди становятся актёрами? Потому что им интересно изображать других людей. Никто не н порицает актёров за то, что они выбирают роли убийц? За что тогда порицать геймеров, которые тоже решили примерить на себя эту РОЛЬ?
Я в VSCode мышкой если и пользуюсь, то ОЧЕНЬ иногда для каких-то жутко странных штук. С ходу могу вспомнить только один сценарий: мне нужно поставить несколько курсоров в случайных местах в тексте и что-то подредактировать такое странное (что, к слову, vim вообще не умеет, ибо multiline edit в vim реализован так плохо, что цензурных слов у меня нет для этого).
Ну, а я когда смотрю, сколько лишних движений требует vim для тупейших действий, насколько это всё неудобно, насколько неинтерактивно, у меня слезы наворачиваются.
Я сам вимовод со стажем, и когда я смотрю на своих коллег вимоводов (с ещё большим стажем) - мне больно смотреть. Они делают все ТАК ДОЛГО. Я оперирую горячими клавишами и GUI элементами примерно процентов на 30 быстрее.
Но да, студентики у меня тоже очень ленивые, учить горячие клавиши не хотят и тоже всё тыкают мышкой. Они делают всё НЕВЕРОЯТНО ДОЛГО, иногда хочется им прописать курс vim-а только для того, чтобы появилась привычка делать всё через клавиатуру. Так что проблема не в VSCode. Проблема в студентах)
del
VSCode вполне себе портабельный и умеет в SSH. В 99% случаев, этого хватает для того, чтобы работать. При условии постоянной смены окружения, Vim просто ужасен, потому как без напильника и тонкой настройки - это удобный инструмент пару-тройку конфигов подправить, но не более.
В принципе, я использую vim для правки мелких вещей каждый день и ничего плохого сказать про него не могу в этом плане. Однако как основной инструмент для работы он требует куда больше настройки и костылей, чем VSCode.
Да, бывают совсем ограниченные среды, без доступа к внешнему интернету, через 5 проксей и RDP, но это прям очень специфические условия. Согласен, тут можно и поюзать vim.
Просто я не понимаю, почему люди продолжают есть этот кактус добровольно) Когда выбор был между vim или тяжеловесной IDE, я могу понять почему выбор падал в сторону vim, но теперь есть промежуточные варианты в виде VSCode или того же Sublime Text. Они имеют портабельные версии, они относительно лёгкие (для современного железа), в них куча плагинов, которые не надо настраивать по 4 дня (как это бывает с vim). Зачем тогда продолжать им пользоваться как основным инструментом?)
Пускай заминусят, но я знаю офигенный способ решения чуть ли не 100% проблем с vim. Установите VSCode и не парьте мозг. Я много лет проработал с vim, даже научился-таки его варить нормально, но в итоге пришёл к выводу:
Я понимаю, что существует 10 тыщ плагинов, делающих из всего vim и все эти плагины, на мой взгляд, полная лажа) Я не нашел для ничего, чего не может VSCode или что в нём сделано хуже чем в vim.
С одной стороны да, хэш-таблицу можно, с другой - если MaxCount маленькое число, то есть вероятность, что константа будет несопоставимо большой.
Ну, если я правильно понял, то мы отказываемся от сортировки и просто линейно проходим по массиву, проверяя есть ли такой элемент в std::set. Соответственно и получаем N log MaxCount.
Однако, если повторяющихся элементов мало, мы будем просматривать первые MaxCount элементов и завершать цикл. Тут я конечно ошибся, ведь сложность будет O ( MacCount log MaxCount ).
Понятное дело, что в худшем случае мы всё равно просмотрим все N элементов, но я рассуждаю именно об амортизированном случае когда повторяющихся элементов "мало". Расчетами для конкретизации "мало" мне лень заниматься.
При условии, что повторяющихся элементов немного, то в среднем мы вообще скорее всего получим O(MaxCount)
Мамонов - наш президент)
В удобной семантике и консистентности с make_shared? Ну и просто более красиво как-то смотрится, чем
auto ptr = std::unique_ptr{ new Object };
Мне лично проще думать "make unique Object", чем "construct unique_ptr which holds Object".
Давайте будем честными - все мы видели очень мало оправданного использования
std::shared_ptr :)А как квантовый процессор учитывал сам себя?
Другие примеры с ranges выглядят еще более монструозно)
Много лет пишу на С++, но каждый раз грущу когда вижу всё вот это синтаксическое уродливое безумие, которое необходимо совершить, чтобы сделать простейшие вещи.
Что касаемо приведённых примеров, никакой существенной разницы между классическим подходом и ranges не увидел. Тут прям теорема Эскобара в действии.
Мне всегда было интересно, почему считается, что путешествие во времени возможно в обе стороны? Может быть если путешествия возможны - они возможны только в будущее? В таком случае никаких парадоксов и не будет)
Тут конечно неплохо бы определить что такое "реальность" или хотя бы что такое "свойство реальности" и чем оно отличается от умозрительной конструкции, потому что без этих определений то, что вы сказали не имеет смысла.
Статья супер. Вынес из неё для себя две вещи:
Не знаешь, что делать? Залей всё полимером!
Ваша кнопка - достойный соперник для Чака Норисса
Вы только забываете, что эта польза не для сотрудников) Мне как линейному разрабу от всего этого пользы никакой и чем больше шпионского ПО использует работодатель, тем меньше мне с ним хочется работать.
Предлагаемая вами система - это типичный пример такого ПО :) Можно декларировать любые благородные цели, но правда в том, что использовать этот AI будет бесчеловечная корпоративная машина со всеми вытекающими)
А почему? Ведь в сущности ровно это она и делает. Если что-то можно использовать как инструмент давления на сотрудника - это рано или поздно будет сделано. Ни разу не видел исключений из этого правила.