Каждое доказательство у меня было в отдельном PDF файле. К примеру "Выступления на конференциях". В каждом таком файле скриншот выступления, ссылка на выступление или сайт конференции, и немного пояснений. Стоит всегда пояснять что изображено на скриншоте.
У меня все статьи были на английском. Если скриншот на русском, я бы добавил так же перевод от себя с пояснениями.
Могу поделиться шаблоном для рекомендательного письма и примером доказательств. Отправь пожалуйста свой email в ЛС, перешлю PDF'ы.
Знаком не только с вышеприведенной статьей, но так же с оригинальным выступлением: https://www.youtube.com/watch?v=J31o0ZMQEnI
Как можно видеть, графики и объяснение как работает развертывание стека были взяты как раз оттуда.
И так же вскользь упоминает об этом в State of Loom:
For this reason, none of the schedulers in the JDK currently employs time-slice-based preemption of virtual threads, but that is not to say it won’t in the future — see Forced Preemption.
Ведь это по факту копирует работу планировщика системы — не перечеркивает ли это все плюсы корутин?
Не перечеркивает. Из достоинств корутин стоит отметить динамический размер стека и более быстрый context switch. Так что иметь forced preemtion — полезная вещь, вот только Go в этом плане всегда ударяется в крайности. Либо preemtion для всех, либо ни для кого.
Всегда было приятно почитать твои комментарии, они обычно очень обстоятельные. А статья получилась тем более обстоятельной.
Работаю с Go года четыре, и в целом полностью согласен с выводами, сделанными за четыре часа знакомства. Go Community крайне токсичный, берет плохой пример с Rob'а Pike'а, и не берет хороший пример с Russ'а Cox'а.
go statement — часть языка, а не стандартной библиотеки. Будь это частью библиотеки, как в том же Kotlin, проблем было бы меньше. Но по факту, приходится городить всякие g.Go(func()), которые не равны go func()
Во первых по содержанию курса, раз уж они на него пришли :)
Во-вторых — по задаваемым вопросам.
И почему вы уверены, что они поняли?
Уверен? Нет. Но в целом, у преподавателя есть два средства. Во-первых, это реакция учеников на объяснения. Во-вторых, результат практических заданий.
Ниже в другой ветке уже написал, но повторюсь.
На мой взгляд, подход автора правилен в том, что нужно объяснить студенту, что моноиды, монады и прочие функторы, это то, с чем он скорее всего и так уже работает. А формальные объяснения из category theory этому мало помогут.
Вопрос не в том, как кому-то нравится изучать материал. А как его эффективней преподавать.
Преподавать от простого к сложному эффективней, чем вываливать на студента ворох терминов в надежде, что он в них не захлебнется.
"Множество" — вообще неочевидно. Студент видел string'и, видел int'ы, видел class'ы. "Множества" студент не видел.
Что такое "ассоциативная операция" — тоже стоит пояснить.
Интуитивно можно понять только "бинарная операция", да и то не уверен, все ли студенты поймут это правильно.
В итоге вместо того, чтобы дать студенту чувство уверенности, такой формализм его только запутает.
Рад слышать, что статья оказалась полезна.
Каждое доказательство у меня было в отдельном PDF файле. К примеру "Выступления на конференциях". В каждом таком файле скриншот выступления, ссылка на выступление или сайт конференции, и немного пояснений. Стоит всегда пояснять что изображено на скриншоте.
У меня все статьи были на английском. Если скриншот на русском, я бы добавил так же перевод от себя с пояснениями.
Могу поделиться шаблоном для рекомендательного письма и примером доказательств. Отправь пожалуйста свой email в ЛС, перешлю PDF'ы.
Рад, что статья заинтересовала!
Мне трудно представить, что подписи трех C-Level можно собрать за месяц, если только это не три близких друга.
По поводу давности доказательств - у меня, к примеру, были указаны патенты 2012го года.
Статей на Medium, если они на английском, не только достаточно, но я бы сказал, что они даже лучше.
В Израиле любая посылка шла месяц, если не больше. Даже заказ внутри страны может идти неделю-другую.
Какие, например?
Насколько мне известно, по O-1 партнер не имеет права на работу.
Доказательства рассматриваются комитетом. Важнее качество, а не количество представленных доказательств.
Booking.com все еще считают, что Perl — самое то.
Хорошо, что хотя бы от Fiber терминологии избавились. А был же еще Strand.
Опрашивать каналы в цикле — тоже не самая очевидная вещь, когда всего лишь хотелось бы прочесть файл.
Знаком не только с вышеприведенной статьей, но так же с оригинальным выступлением:
https://www.youtube.com/watch?v=J31o0ZMQEnI
Как можно видеть, графики и объяснение как работает развертывание стека были взяты как раз оттуда.
У том, что с Project Loom возможен и forced preemtion Ron Pressler писал мне тут:
https://twitter.com/pressron/status/1262350580820869120
И так же вскользь упоминает об этом в State of Loom:
Не перечеркивает. Из достоинств корутин стоит отметить динамический размер стека и более быстрый context switch. Так что иметь forced preemtion — полезная вещь, вот только Go в этом плане всегда ударяется в крайности. Либо preemtion для всех, либо ни для кого.
Начать стоит с того, что вышеприведенный код запустится в одном потоке.
Всегда было приятно почитать твои комментарии, они обычно очень обстоятельные. А статья получилась тем более обстоятельной.
Работаю с Go года четыре, и в целом полностью согласен с выводами, сделанными за четыре часа знакомства. Go Community крайне токсичный, берет плохой пример с Rob'а Pike'а, и не берет хороший пример с Russ'а Cox'а.
go statement— часть языка, а не стандартной библиотеки. Будь это частью библиотеки, как в том же Kotlin, проблем было бы меньше. Но по факту, приходится городить всякиеg.Go(func()), которые не равныgo func()Основная проблема с решениями вроде
errgroupи прочими заключается в том, что в Go все эти библиотеки — second class citizens.Понятно почему. В мире Go полиморфизм — от лукавого.
Зато простыни кода с
wg.Add(1)иwg.Done()считаются чем-то само собой разумеющимся.Не только :)
В моем случае (Тель Авив), такие педагоги были в основном профессорами, которых заставляли давать лекции, "отвлекая" их от "важных исследований".
Во первых по содержанию курса, раз уж они на него пришли :)
Во-вторых — по задаваемым вопросам.
Ниже в другой ветке уже написал, но повторюсь.
На мой взгляд, подход автора правилен в том, что нужно объяснить студенту, что моноиды, монады и прочие функторы, это то, с чем он скорее всего и так уже работает. А формальные объяснения из category theory этому мало помогут.
Собственно о чем я и писал — формальное определние давать не стоит, оно нужно не всем.
Моя цель как преподавателя — объяснить тему так, чтобы студент ее понял.
Стараюсь не решать за своих студентов, что им нужно, а что нет.
Вопрос не в том, как кому-то нравится изучать материал. А как его эффективней преподавать.
Преподавать от простого к сложному эффективней, чем вываливать на студента ворох терминов в надежде, что он в них не захлебнется.
"Множество" — вообще неочевидно. Студент видел string'и, видел int'ы, видел class'ы. "Множества" студент не видел.
Что такое "ассоциативная операция" — тоже стоит пояснить.
Интуитивно можно понять только "бинарная операция", да и то не уверен, все ли студенты поймут это правильно.
В итоге вместо того, чтобы дать студенту чувство уверенности, такой формализм его только запутает.