Стиль, правда, отличается от описанного выше. Я обычно просто жду, когда кто-то разово оскорбит меня или другого игрока («noob» и прочая классика) и начинаю подначивать оскорбляющего игрока, но не в стиле «я твою маму в кино водил», а в стиле «почему ты снова умер?» или «ого, как-то не очень у тебя счёт» и прочие относительно безобидные, но раздражающие фразы. Жертва не приспособлена к такому нудному стилю и сразу съезжает на поток оскорблений (в этом месте важно замолчать, чтобы не раздражать остальных игроков, а оставить их фокус внимания на жертве). В конце игры идет репорт (и почти наверняка взаимный репорт от жертвы). Далее жертва попадает под критерии наказания (на эту тему приходят нотификации, что «игрок по вашему репорту понес наказание», а я — нет.
Речь идет о LoL, где можно не бояться репортов от неадекватов за то, что «не так/не тем играл» или «да мы тебя вдвоем/вчетвером/ввосьмером зарепортим» из-за природы системы верификации репортов.
Раньше там был трибунал (где живые люди читали лог по результатам репорта и выносили решение), сейчас там вроде автоматизированная оценка чата. Т.е. репорт сам по себе не оказывает действия, а лишь привлекает внимание системы верификации.
Ну и по поводу моей мотивации. Она состоит в следующем: если человек использовал слово типа «noob», то это наверняка не единичный случай, а его стиль. Однако многие уже привыкли к некоторой фоновой интенсивности оскорблений и не репортят за это. Поэтому надо «поджечь» такого игрока, чтобы он изошелся по полной и его зарепортило больше людей + система верификации задетектила его с большей вероятностью. Таким образом, его поведение ведет к неудобствам (временный или постоянный бан, бан в чате, заведение и прокачивание альтернативного аккаунта).
Иными словами, я реализую «мстительную» стратегию, т.к. считаю ее ближе к эволюционно стабильной, чем оскорбляющую или терпящую. Месть здесь начинается после самого первого оскорбления.
Если автоматика в LoL научится распознавать такое реактивно-провоцирующее поведение как негативное, перейду к более тонкому стилю.
Даже не знаю, что и сказать. Сам подход называть какой-то язык игрушечным достаточно распространен. Больше всего достается JavaScript.
Думаю, даже по комментариям здесь очевидно, что WL используют не от незнания Lisp.
Каждому инструменту своя ниша, с этим сложно спорить. Но один частный случай еще не опровергает все остальные. Эта игрушка экономит куче людей и компаний много времени и денег. У нее есть своя ниша, которая несколько шире, чем помощь студентам с домашкой. Сейчас эту нишу пытаются расширить и появляется куча проблем. Будут ли они решены — я не знаю. Тут каждый решает для себя, на что ставить.
Т.к. большинство языков тьюринг-полные, то, в принципе, задачу можно решить в любом из них. Различия языков — это, по сути, различия самого процесса разработки. И вот здесь у WL есть несколько уникальных вещей.
Самое главное — это сама парадигма языка «все является символом” и работа с паттернами. На самом деле вы не объявляете функции, а задаете преобразования одних символов в другие. Можно писать программу с любого места, используя еще не реализованые функции (а по сути — используя символы, для которых нет дальнейших правил преобразования).
Когда вы объявляете функцию, скажем, f[x_,y_]:=x+y, эти нижние прочерки там неспроста. Они означают паттерны, которые мы преобразовываем (это нечто большее, чем концепция аргументов функции). Можно задавать дополнительные условия для этих самых входных паттернов. Рассмотрим пример:
MyPlus[x_, y_] := x + y /; x > y
MyPlus[2, 3] := "4, lol"
MyPlus[6, 5]
> 11
MyPlus[5, 6]
> MyPlus[5, 6]
MyPlus[2, 3]
> "4, lol"
Здесь у нас функция, которая складывает числа, но почему-то только если первое больше второго. В противном случае вся конструкция (»вызов функции") остается неизменной и в таком виде используется дальше. А в случае сложения 2 и 3 она вообще говорит неправду. Иными словами, я задал несколько правил преобразования символа MyPlus[_,_] а Математика по мере выполнения выбирает, какое из этих правил использовать, с приоритетом у самого специфичного правила (это не зависит от порядка объявления).
И еще одно — при разработке программы в т.н. блокнотах происходит что-то, что отличается от обычного “изменил код — запустил — проверил”. Код и результаты его работы смешаны вместе в одном интерфейсе (таким образом, который вы зададите). Например, вам нужно модифицировать какую-то функцию — вы можете изменить и выполнить только ее, без перезапуска всей программы, видя результат ее работы прямо там же. При этом будет использован текущий “контекст” (заданные переменные и т.д.). Таким образом, граница между разработкой, исполнением и отладкой стирается, обратная связь мгновенна. Традиционный способ разработки кажется при этом уже не таким удобным.
Есть много интересных вещей, которые из этого следуют, но сложно уместить ответ в рамках комментария.
Строго говоря, да. Я не нашел какого-либо прямого способа работы с сокетами в Wolfram Language. Вообще, при написании этой статьи была робкая надежда, что где-то в комментариях объявится кто-то, кто скажет «Да как так можно-то? Вот как эту задачу нужно было решить на самом деле».
Очень интересно наблюдать за процессом становления WL как языка и системы общего назначения, но судя по всему, не только я блуждаю в потемках, пытаясь найти способы более приземленного применения. При этом прочувствовав силу WL очень сложно потом заставить себя переписывать решение на другом языке только потому, что там гораздо больше вариантов развертывания.
«Не стучать» — потенциально более масштабируемое решение. Проблема действительно должна быть решена на как можно более низком (но достаточном) уровне иерархии системы. Это же основы проектирования и обработки исключений. Если каждую проблему перекидывать на верхний уровень, теряется суть иерархии.
В пределе оба варианта плохи и лучше выработать какой-то промежуточный критерий перекидывания проблемы на верхний уровень. К примеру, при вероятности невозможности решения проблемы на данном уровне, равной 60%. Конкретное число должно подбираться с учетом многих факторов (например, загруженность руководства).
Если я считаю, что Вася, скорее всего, вентилятор не выключит и это подтверждают предыдущие случаи взаимодействия с ним, то настало время привлекать третью сторону. Если же я при этом уверен, что третья сторона слишком занята, чтобы решать эту проблему, то придеться уже прикидывать, выйдет ли начистить Васе репу самостоятельно.
> к Вам подошел ген директор и спрашивает — как думаешь какова будет реакция комьюнити на подобные ограничения?
Вы ему честно говорите, что реакция будет плохая и лучше так не делать (если вы в данный момент не занимаетесь, скажем так, «форсированным строительством карьеры»), а он вам «Я директор, я так вижу. Будем делать защиту.»
Что мешает задать разные варианты векторной иконки для разных диапазонов размеров, по аналогии с растром? При этом так больше гибкости, т.к. нет необходимости задавать все варианты для всех иконок. Если иконка хорошо масштабируется, то можно оставить один вариант для всех размеров.
Ого, векторные иконки, инновация. Привет от S60.
А так дизайн нравится. Непонятно, почему некоторые считают, что теперь кто попало сможет рисовать иконки и это стало легче. Имхо простота дается тяжелее — нужно передать ту же мысль меньшим количеством деталей.
Я не alizar, но у меня ни одной https страницы за последние несколько часов не открылось. Всякие клиенты, вроде дропбокса, тоже не работают, само собой. Меня, столичную илиту с моноклем в глазу, вы уж послушаете, я надеюсь?
Стиль, правда, отличается от описанного выше. Я обычно просто жду, когда кто-то разово оскорбит меня или другого игрока («noob» и прочая классика) и начинаю подначивать оскорбляющего игрока, но не в стиле «я твою маму в кино водил», а в стиле «почему ты снова умер?» или «ого, как-то не очень у тебя счёт» и прочие относительно безобидные, но раздражающие фразы. Жертва не приспособлена к такому нудному стилю и сразу съезжает на поток оскорблений (в этом месте важно замолчать, чтобы не раздражать остальных игроков, а оставить их фокус внимания на жертве). В конце игры идет репорт (и почти наверняка взаимный репорт от жертвы). Далее жертва попадает под критерии наказания (на эту тему приходят нотификации, что «игрок по вашему репорту понес наказание», а я — нет.
Речь идет о LoL, где можно не бояться репортов от неадекватов за то, что «не так/не тем играл» или «да мы тебя вдвоем/вчетвером/ввосьмером зарепортим» из-за природы системы верификации репортов.
Раньше там был трибунал (где живые люди читали лог по результатам репорта и выносили решение), сейчас там вроде автоматизированная оценка чата. Т.е. репорт сам по себе не оказывает действия, а лишь привлекает внимание системы верификации.
Ну и по поводу моей мотивации. Она состоит в следующем: если человек использовал слово типа «noob», то это наверняка не единичный случай, а его стиль. Однако многие уже привыкли к некоторой фоновой интенсивности оскорблений и не репортят за это. Поэтому надо «поджечь» такого игрока, чтобы он изошелся по полной и его зарепортило больше людей + система верификации задетектила его с большей вероятностью. Таким образом, его поведение ведет к неудобствам (временный или постоянный бан, бан в чате, заведение и прокачивание альтернативного аккаунта).
Иными словами, я реализую «мстительную» стратегию, т.к. считаю ее ближе к эволюционно стабильной, чем оскорбляющую или терпящую. Месть здесь начинается после самого первого оскорбления.
Если автоматика в LoL научится распознавать такое реактивно-провоцирующее поведение как негативное, перейду к более тонкому стилю.
Только тут принцип наоборот — видео из поезда
исправлено
Думаю, даже по комментариям здесь очевидно, что WL используют не от незнания Lisp.
Каждому инструменту своя ниша, с этим сложно спорить. Но один частный случай еще не опровергает все остальные. Эта игрушка экономит куче людей и компаний много времени и денег. У нее есть своя ниша, которая несколько шире, чем помощь студентам с домашкой. Сейчас эту нишу пытаются расширить и появляется куча проблем. Будут ли они решены — я не знаю. Тут каждый решает для себя, на что ставить.
WOLFRAM_EXECUTABLE = "/Applications/Mathematica.app/Contents/MacOS/MathKernel"
Самое главное — это сама парадигма языка «все является символом” и работа с паттернами. На самом деле вы не объявляете функции, а задаете преобразования одних символов в другие. Можно писать программу с любого места, используя еще не реализованые функции (а по сути — используя символы, для которых нет дальнейших правил преобразования).
Когда вы объявляете функцию, скажем, f[x_,y_]:=x+y, эти нижние прочерки там неспроста. Они означают паттерны, которые мы преобразовываем (это нечто большее, чем концепция аргументов функции). Можно задавать дополнительные условия для этих самых входных паттернов. Рассмотрим пример:
Здесь у нас функция, которая складывает числа, но почему-то только если первое больше второго. В противном случае вся конструкция (»вызов функции") остается неизменной и в таком виде используется дальше. А в случае сложения 2 и 3 она вообще говорит неправду. Иными словами, я задал несколько правил преобразования символа MyPlus[_,_] а Математика по мере выполнения выбирает, какое из этих правил использовать, с приоритетом у самого специфичного правила (это не зависит от порядка объявления).
И еще одно — при разработке программы в т.н. блокнотах происходит что-то, что отличается от обычного “изменил код — запустил — проверил”. Код и результаты его работы смешаны вместе в одном интерфейсе (таким образом, который вы зададите). Например, вам нужно модифицировать какую-то функцию — вы можете изменить и выполнить только ее, без перезапуска всей программы, видя результат ее работы прямо там же. При этом будет использован текущий “контекст” (заданные переменные и т.д.). Таким образом, граница между разработкой, исполнением и отладкой стирается, обратная связь мгновенна. Традиционный способ разработки кажется при этом уже не таким удобным.
Есть много интересных вещей, которые из этого следуют, но сложно уместить ответ в рамках комментария.
Очень интересно наблюдать за процессом становления WL как языка и системы общего назначения, но судя по всему, не только я блуждаю в потемках, пытаясь найти способы более приземленного применения. При этом прочувствовав силу WL очень сложно потом заставить себя переписывать решение на другом языке только потому, что там гораздо больше вариантов развертывания.
MacBook Pro Retina Mid 2014:
op=Now 0.290 s
op=TestGraph 1.5 s
Raspberry Pi Model 2:
op=Now 3.4 s
op=TestGraph 7.6 s
Иными словами, что бы вы сделали, вернувшись на 8 лет назад?
В пределе оба варианта плохи и лучше выработать какой-то промежуточный критерий перекидывания проблемы на верхний уровень. К примеру, при вероятности невозможности решения проблемы на данном уровне, равной 60%. Конкретное число должно подбираться с учетом многих факторов (например, загруженность руководства).
Если я считаю, что Вася, скорее всего, вентилятор не выключит и это подтверждают предыдущие случаи взаимодействия с ним, то настало время привлекать третью сторону. Если же я при этом уверен, что третья сторона слишком занята, чтобы решать эту проблему, то придеться уже прикидывать, выйдет ли начистить Васе репу самостоятельно.
Вы ему честно говорите, что реакция будет плохая и лучше так не делать (если вы в данный момент не занимаетесь, скажем так, «форсированным строительством карьеры»), а он вам «Я директор, я так вижу. Будем делать защиту.»
А так дизайн нравится. Непонятно, почему некоторые считают, что теперь кто попало сможет рисовать иконки и это стало легче. Имхо простота дается тяжелее — нужно передать ту же мысль меньшим количеством деталей.
Двоемыслие какое-то.