Вы привели интересное сравнение в конце — а можете привести примеры не императивных языков в которых нужно следить за памятью а-ля rust?
Все программирование построено на том, что мы строим абстракции в терминах в которых легче рассуждать. Иногда при этом что-то теряется. В сравнении с C++, rust, конечно, намного лучше — проблема управления памяти есть в обоих языках, но rust ее намного лучше решает.
Но в сравнении с альтернативным решением проблемы управления памятью — gc, подход rust-а, будь он хоть прекрасно контролируемым, создает значительно большую нагрузку на мозг. Так что "традиционных императивных языках особенностях" стоит заменить на "языки с gc", к которым, например, относятся многие функциональные языки.
Я вообще не понял зачем они нужны, ведь если они не меняются, то и rerender-а не будет? Зато передавать нескольких аргументов мапой/вектором приходится. Странно.
Ну и как оказалось (написали в комментах к коммиту) это была проблема вида RTFM: все аргументы кроме первого не учитываются quiescent-ом для re-render-а, они там называются static arguments. Как мне кажется странное решение, и не то чтобы это было нужно.
Еще из немного неприятного: по +- понятным причинам слетала поддержка резолва аргументов в IDE. Можно было наверное вручную раскрывать макросы, но не сделали.
А вообще как чисто решение для state->view над реактом — quiescent приятен.
Изменяемые состояния объединяют время и состояние в одну сущность, порождая кучу ошибок. И это фатальный недостаток изменяемых состояний — с ними сложней работать, они создают ошибки и дают меньше гарантий.
А не то что они плохо описываются математической теорией.
Как выше написали, работа с сетью в js не cpu intensive, специально выделять ее в воркеры не нужно. А поддержку xhr из webworkers сделали потому что это может кому-нибудь понадобиться. Например вы качаете много данных, а потом делаете много cpu intensive действий с ними. Проще будет написать всю эту логику в воркере, а не качать данные отдельно в основном потоке, чтобы потом отправить их в воркер.
Так что делать как указано в статье не стоит. Сложно и незачем.
Мне показывали возможность показа клиенту картинки с ключем, и соответственно можно сравнить эти картинки с собеседником и таким образом убедиться что родной сервер не делает man in the middle.
Посмотрите на функциональные языки, поймете откуда Maybe берет свои истоки.
В новых языках (например котлине) из коробки есть nullability check — все типы могут Nullable или нет (определяется знаком вопроса в декларации типа).
На практике null это исключение, а не наоборот. Поэтому выделять nullable значение в отдельную сущность — удобно.
Одно из решений — ввести аттрибуты: Nullable/NotNull (говорю про яву), но есть и решение средствами языка — как раз описанная возможность с помощью Maybe.
И мне кажется это хорошо повышает как безопасность кода по поводу NullRefExc, так и его читаемость. Конечно же если весь код написан в таком стиле.
>> Maybe добавляет сложности, но не добавляет решений.
Решение NullRefExc оно точно добавляет.
Казалось бы в последнем примере все логично: метод не виртуальный и поэтому реализация выбирается в момент компиляции. Мы же не просим от такого кода:
class A {}
class B: A {}
void method(A a) { System.Console.WriteLine(«A»); }
void method(B b) { System.Console.WriteLine(«B»); }
A b = new B();
method(b);
вывода на экран «B». Тут абсолютно все также и логично.
Посмотрите как можно сделать асинхронность:
https://twitter.github.io/finagle/guide/Futures.html
Все программирование построено на том, что мы строим абстракции в терминах в которых легче рассуждать. Иногда при этом что-то теряется. В сравнении с C++, rust, конечно, намного лучше — проблема управления памяти есть в обоих языках, но rust ее намного лучше решает.
Но в сравнении с альтернативным решением проблемы управления памятью — gc, подход rust-а, будь он хоть прекрасно контролируемым, создает значительно большую нагрузку на мозг. Так что "традиционных императивных языках особенностях" стоит заменить на "языки с gc", к которым, например, относятся многие функциональные языки.
android.stackexchange.com/questions/32442/jurisdictions-where-camera-shutter-sound-is-mandated-by-law
И чилды нужны, так что реально форкать надо =)
Ну и как оказалось (написали в комментах к коммиту) это была проблема вида RTFM: все аргументы кроме первого не учитываются quiescent-ом для re-render-а, они там называются static arguments. Как мне кажется странное решение, и не то чтобы это было нужно.
Еще из немного неприятного: по +- понятным причинам слетала поддержка резолва аргументов в IDE. Можно было наверное вручную раскрывать макросы, но не сделали.
А вообще как чисто решение для state->view над реактом — quiescent приятен.
Но вот представление всего состояния программы в одном немутабельном состоянии общую логику сильно упростило на мой взгляд.
В контексте статьи выше — они покрывают те примеры что у автора.
А не то что они плохо описываются математической теорией.
Так что делать как указано в статье не стоит. Сложно и незачем.
habrahabr.ru/post/206476/#comment_7113122
Там понятно что почему получается и сходится, но как по мне эта часть статьи эээ странная.
А как работает формула про (a+b)^n при отсутствии коммутативности?
В новых языках (например котлине) из коробки есть nullability check — все типы могут Nullable или нет (определяется знаком вопроса в декларации типа).
На практике null это исключение, а не наоборот. Поэтому выделять nullable значение в отдельную сущность — удобно.
Одно из решений — ввести аттрибуты: Nullable/NotNull (говорю про яву), но есть и решение средствами языка — как раз описанная возможность с помощью Maybe.
И мне кажется это хорошо повышает как безопасность кода по поводу NullRefExc, так и его читаемость. Конечно же если весь код написан в таком стиле.
>> Maybe добавляет сложности, но не добавляет решений.
Решение NullRefExc оно точно добавляет.
class A {}
class B: A {}
void method(A a) { System.Console.WriteLine(«A»); }
void method(B b) { System.Console.WriteLine(«B»); }
A b = new B();
method(b);
вывода на экран «B». Тут абсолютно все также и логично.
javascript:document.cookie="VISITOR_INFO1_LIVE=ST1Ti53r4fU";