А с чем сравнивать-то? на F# нет проектов, которые были бы кому то интересны за пределами F#.
Вынужден напомнитm вам ваш первоначальный тезис:
"количество звёздочек на гитхабе красноречиво намекает что проект никому не нужен"
А в F# надо постоянно классы в файле и сами файлы переставлять местами, чтобы соблюсти нужный порядок, при котором каждый класс видит то, что ему нужно.
В F# не нужно постоянно переставлять местами файлы и классе. В отличие от C# здесь нет рекомендации каждый класс выделять в отдельный файл.
Но мне постоянно врут в этом топике.
Вы заблуждаетесь. Скорее всего происходит банальное недопонимание. Просто уточните что имеет ввиду собеседник прежде чем делать скоропалительные выводы и уж тем более переходить к обвинениям.
А на предложение ответить за слова — молчат.
Возможно они не хотят повторять одно и то-же?
Что характерно, спикеры на конфах так же себя ведут.
Можно увидеть примеры?
Отвлекаясь на такие мелочи как сборка проекта модели, разработчик теряет концентрацию и мысль уходит безвозвратно.
Если разработчику понадобилось изменить модель при разработке UI части возможно то, что мысль ушла, даже хорошо ;)
Предлагаю оставим эту тему хотя бы до тех пор пока вы не предоставите ссылки подкрепляющие вашу точку зрения.
Мне наставили минусов, поэтому я не могу отвечать. Учитывая идиотскую систему минусования, введённую идиотами, владеющими хабром, пожалуй, это будет мой последний сюда визит.
Позвольте дать небольшой совет. Перечитайте свои комментарии к этой публикации (и вероятно к другим тоже). Они в большинстве своем чрезмерно эмоциональны. Я не берусь утверждать насколько они обоснованы, но, правда, сложно себе представить, что называя людей идиотами вы получите "+" в карму и за комментарий.
Вы тратите много времени здесь, комментария статьи. Вместо того чтобы раз за разом обрушивать на F# спорную критику можно было бы направить энергию в конструктивное русло.
Плохая документация? Внесите улучшение.
Не хватает какой-то фичи? Предложите ее добавить.
Видите проблему? Вынесите на обсуждение.
Для сравнения беру первый пришедший в голову проект на Го
Сравнение неуместно, при чем здесь любой другой язык?
А Suave существует давно, обсуждается в сообществе весьма активно, на волне некоторого хайпа мог бы и больше звёздочек собрать
У F# репозитория всего 1,406 звезд. Хотя тут наверное организация сыграла роль, так как F# Core находящийся в FSharp организации намного более популярен — 177.
А приходилось ли вам инспектировать чужой код на F#?
Приходилось. Кроме того, мой первый PR был сделан как раз в F# библиотеку.
Обычно иерархия модулей проекта определяется архитектурой и понятна из названий каталогов и файлов проекта
Да, но если речь идет об OpenSource проекте, то разбираться в чужом коде, чтобы исправить баг или даже просто локализовать проблему бывает проблематично (время-затратно)
И, наоборот, постоянно думать о порядке файлов в проекте страшно выбешивает.
Не нужно думать о порядке файлов, он автоматически линейный.
Что плохого в том, чтобы предостеречь начинающих от некачественного инструмента?
Вы меня превратно поняли. Я лишь попытался вас предостеречь от громких безосновательных утверждений. В вопросе полноты изложения — указывать не только на плюсы, но и на недостатки я вас полностью поддерживаю, но хотелось бы что-бы они были обоснованы.
Я действительно благодарен вам за ответы.
(в комьюнити именно так и принято, )
Насколько я могу судить, в F# сообществе принято говорить правду.
Модель, которая постоянно меняется в процессе разработки, и чтобы из основного проекта увидеть изменения эти изменения, нужно пересобрать вспомогательный.
Shrug. Все-таки не на C++ пишем, сборка занимает не так много времени.
Были определённые ожидания, связанyые с websharper и ui.next, но к сожалению они так и не вышли из маргинальной ниши.
Сам я далек от веб-разработки, но WebSharper с самого начала показался несколько странным.
Все остальные фреймворки (например hopack, suave, fable как самые изветсные), как показала практика, можно выкидывать, не дочитав readme.
Вы, наверное, вместо Hopack хотели написать Giraffe?
Можно уточнить что вы имеете ввиду под "как показала практика"?
В чём любой желающий может легко убедится: вместо документации — имитация оной, 1.2 контрибьютера, поддержка околонулевая, шизофреничные стрелочки в качестве кастомных операторов, в продакшене нет, количество звёздочек на гитхабе красноречиво намекает что проект никому не нужен
С документацией да, есть некоторые проблемы. Но сообщество достаточно активное чтобы быстро получить ответ на искомый вопрос.
В продакшене Suave используется, хотя сейчас, насколько мне известно, большую все популярность набирает SAFE.
Что касается звездочек и контрибуторов, то это все есть в открытом доступе:
Suave: 1015 Star / 86 contributors Fable: 1,437 Star / 90 contributors Giraffe: 939 Star / 46 contributors
Я уверен, что здесь достаточно больше количество звездочек чтобы считать заявление, цитирую "проект никому не нужен" безосновательными. Решительно не понимаю почему вы прибегаете к подобной риторике.
При этом читается хуже
Дело вкуса или привычки. Мне, например, читать F# код значительно проще чем C#. И тут дело не в самом синтаксисе, а в строгом порядке файлов. В F# все зависимости четко прослеживаются, тогда как в C# проекте крайне сложно ориентироваться в виде хаотичного расположения файлов.
При этом читается хуже, потому что нет жестких гайдлайнов, развитых линтеров и единого форматирования.
Возвращаться к своему коду тяжело, читать чужой невыносимо больно — вне зависимости от уровня квалификации того, кто этот код написал.
Не нужно распространять ваш негативный опыт на всех
Усложняется сборка.
Сложно представить проект в котором модель и UI смешаны в одном проектном файле по причине сложности их сборки. Можно увидеть ссылки или статьи подтверждающие ваши слова ?
А иногда модели вообще не нужны, достаточно старого доброго smart ui.
Мне такое сложно представить :-)
Если лучше и удобнее применить ООП, то лучше и удобнее применить C#, поскольку F# в планее ООП не даёт ничего сверх C#.
По моему опыту использования F# в нём ничего этого нет, потому и проектов на нём нет в количестве, достойном упоминания.
Можно узнать по-подробнее о вашем опыте с F#? Впервые встречаю человека с реальным опытом с F# и который бы утверждал что "F# не нормальный язык".
Отсутствие partial конечно осложняет, но не делает задачу невозможной. Если бы они очень захотели, то придумали бы врапер со ссылкой на реализацию (как вариант).
Возможно, конечно. Даже FsXAML предоставляет совсем базовую поддержку для code-behind.
Поэтому не проще ли честно признать, что вот этот вот вариант с десктопным UI на F# — маргинальщина и отстрел ног?
Проще, да, но не честнее. Код на F# пишется быстрее. Даже для демонстрации проблемы или наоборот решения какого-то вопроса использовать его намного удобнее. В тех случаях когда не требуется красивый и сложный UI с большим количеством code-behind возможностей F# точно хватит.
Не всегда приемлемо держать модели в отдельном проекте.
Разве? Вы не могли бы привести примеры?
Кроме того модели на практике вряд ли будут в ФП стиле, потому что должны быть совместимы с сугубо ООП-шными вещами на подобие IPropertyChanged.
В том то и дело что используется другой подход. F# в первую очередь функциональный язык программирования, а не чисто функциональный. Если лучше и удобнее применить другой подход, то его и стоит применять.
Если вы не в состоянии показать избыточность C# по сравнению с F# в нескольких словах на понятном языке, значит либо избыточности нет, либо вы не владеете вопросом.
Есть еще варианты кроме перечисленных вами.
В статье был приведен простейший пример, на всякий случай скопирую его снова:
C#:
public class Employee
{
public Guid Id { get; }
public string Name { get; }
public string Email { get; }
public string Phone { get; }
public bool HasAccessToSomething { get; }
public bool HasAccessToSomethinElse { get; }
public Employee(Guid id, string name, string email, string phone, bool hasAccessToSmth, bool hasAccessToSmthElse)
{
Id = id;
Name = name;
Email = email;
Phone = phone;
HasAccessToSomething = hasAccessToSmth;
HasAccessToSomethinElse = hasAccessToSmthElse;
}
}
Для определения одного и того-же объекта в F# варианте затрачивается меньше времени. В рамках одного типа разница не столь значительна, но все изменится когда вы увеличите их количество в разы.
И это только самый тривиальный случай. F# код намного лаконичнее чем аналогичный на C#.
Тем не менее в открытом доступе овердофига десктопных UI приложений на C# и почти ни одного на F#. Совпадение?
Нет, не совпадение. Не очень понимаю что именно вы хотите оспорить. C# намного, намного более популярный и востребованный язык чем F#. OpenSource разработчику десктопного UI приложения (да и не только десктопного) не выгодно писать на F#, просто по той причине, что проект не встретит той поддержки, которую мог бы получить аналогичный на C#. Все это должно быть достаточно очевидно. Но раз уж зашла речь об очевидных вещах, то если кто-то и задумается над написанием WPF приложения на F#, то он должен быть готов к тому, что хороших материалов не так уж и много.
WPF в F# ?? Вы в данном случае себя обманываете или окружающих?
Ни себя, ни окружающих я не обманываю. Вы просто говорите о другом. Поддержка F# в VS значительно уступает поддержке C# и проблема отсутствия шаблона для WPF далеко не в вверху списка того, что было бы здорово добавить.
Xaml редактор не умеет генерировать F# код и привязывать его к разметке.
Вы абсолютно правы в том, что поддержки для code-behind в F# проекте в том виде в котором она есть для C# нет, просто по той причине что в F# нет такого понятия как partial.
Если у вас вся исправность работы F# с WPF сводится к прикручиванию сборки, написанной на F#, так это смех.
Вы ошибаетесь. Хотя нет ничего смешного в том, чтобы определить View часть в C# проекте, тогда как все остальное переложить на F#.
и, скорее всего, научить JsonConvert парсить ее, потому что дефолтного конструктора нет
Мне тоже не совсем понятно что вы имели ввиду. Какой конструктор использовать можно указать с помощью [JsonConstructor]/[<JsonConstructor>]. К тому-же у структур есть конструктор по умолчанию.
Сложные приложения вряд-ли многие захотят выкладывать в открытый доступ.
WPF работает исправно. Полная F# поддержка для UWP скорее всего будет не скоро, но положительные сдвиги в этом направлении уже есть. Если по каким-то причинам вам нужен WinForms, то можно использовать, например, TrivialBehinds раз уж нет конструктора форм.
Xamarin.Forms поддерживает F#, для более удобной работы есть дополнительные библиотеки, такие как Fabulous, который здесь уже не раз упоминался.
Я бы посоветовал книгу "Программирование на F#". С тех пор F# изменился, но база — основные типы и сам функциональный подход все тот-же и описывается очень понятным и доступным языком.
Также есть восхитительный сайт F# for fun and profit. И, конечно, присоединяюсь к рекомендации worldbeater — "Domain Modelling Made Functional". Сам я эту книгу еще не читал, но это как раз тот случай когда можно советовать "не глядя"
Тут стоит уточнить, кого вы имеете ввиду под начинающими. Тех у кого есть опыт программирования на C#, тех кто знакомых с каким-то не функциональным языком, но не имеет представления о .NET или тех, кто только пробует делать свои первые шаги в программировании?
Использовать со старта вспомогательные библиотеки и/или фреймворки или нет сложный вопрос.
Лично я начинал с библиотеки FSharp.ViewModule и успешно ее использовал в своих небольших проектах, даже не подозревая о внутреннем устройстве команд и объектов уведомляющих о своем изменении. И еще долгое время подобные тонкости меня не беспокоили. Я считаю, что главное понимать что механизм делает, а осознание как именно придет с опытом, при условии что вообще возникнет необходимость разбираться во внутренней реализации.
Видимая сложность MVVM, возможно, одна из причин того, что многие продолжают смешивать все в одной куче. Библиотека, с другой стороны, может помочь развернуть процесс обучения — от общего представления о шаблоне к его полному (или хотя-бы достаточному) пониманию, делая его более плавным.
К тому-же, на мой взгляд, интереснее разбираться в том как приложение работает, а не в том как заставить его работать. И, конечно, самостоятельно написанная работающая программа, в отличие от взятой из папки "samples", пусть даже и построенная из готовых блоков (вызовов готовых методов), дает положительный эффект — "я могу, я умею" [хотя-бы что-то!], добавляя уверенности, а не отрицательный — "ничего не работает", "это не для меня".
Grid — позволяет организовать элементы по столбцам и строкам, ширина каждого столбца или строки настраивается индивидуально.
Кажется, вы пропустили "в виде сетки или таблицы" и не только ширина, но и высота тоже ;)
MVVM и интерфейс INotifyPropertyChanged. Копия текста.
Копия текста?
Привязка в терминологии WPF — это механизм, позволяющий связывать некоторые свойства контролов с некоторыми свойствами объекта C#-класса и выполнять взаимное обновление этих свойств при изменении одной из частей связки (это может работать в одну, в другую или в обе стороны сразу).
Не обязательно C# класса. WPF может прекрасно подружиться с F#, не говоря уже о VB.Net.
Ну, почти всё, финишная прямая! Осталось указать вьюхе, что оно должно слушать событие PropertyChanged:
TextBox Text="{Binding Path=SynchronizedText, UpdateSourceTrigger=PropertyChanged, Mode=OneWayToSource}"
TextBlock Text="{Binding Path=SynchronizedText, UpdateSourceTrigger=PropertyChanged, Mode=OneWay}"
Здесь, мне кажется, вы не совсем однозначно выражаетесь.
UpdateSourceTrigger лишь указывает на то, когда будет обновляться привязываемое свойство. PropertyChanged устанавливает режим обновления сразу после изменения свойства в "приемнике" (не самое удачное слово, но ничего лучше на ум так и не пришло). По умолчанию TextBox обновляет привязку после потери своего фокуса. Что касается TextBlock, то там установка UpdateSourceTrigger не требуется, как и явный Mode = OneWay.
В целом, несмотря на то, что хороших материалов по WPF хватает, еще один туториал точно не повредит.
Но в будущем мне бы хотелось, чтобы примеры были не настолько искусственные. В частности: здесь совсем не требуется реализация INotifyPropertyChanged. Если TextBlock должен дублировать текст из TextBox, то можно сразу там и привязываться к свойству Text, а дополнительная прослойка в виде свойства, оповещающего о своих изменениях, не нужна, обычного авто-свойства в данном конкретном случае будет достаточно.
Пойдемте.
— Куда? – удивилась Ксения.
— К чернокнижнице нашей, куда ж еще. – загадочно улыбнулся Сергей.
Лучше бы к Илене Сквоттер :-)
Хороший по смыслу рассказ и написан неплохо, но учитывая предыдущие истории могло быть и лучше. Все таки здесь перебор с "рукожопством", но продолжение или альтернативную ветку обязательно прочту
А Кинг на мой взгляд очень удачно (и жестоко) описал ситуацию, когда не серьёзное отношение к жизни в последствии приводит к необратимым результатам которых не избежать.
Не смотрел на "Долгую прогулку" с такой точки зрения ("не серьёзное отношение к жизни"). Слушал довольно давно, но ЕМНИП там не только добровольцы были. Мне казалось, что центральная идея — жестокость окружающего мира и да, согласен, последствия от необдуманно принятых решений.
Вынужден напомнитm вам ваш первоначальный тезис:
"количество звёздочек на гитхабе красноречиво намекает что проект никому не нужен"
В F# не нужно постоянно переставлять местами файлы и классе. В отличие от C# здесь нет рекомендации каждый класс выделять в отдельный файл.
Вы заблуждаетесь. Скорее всего происходит банальное недопонимание. Просто уточните что имеет ввиду собеседник прежде чем делать скоропалительные выводы и уж тем более переходить к обвинениям.
Возможно они не хотят повторять одно и то-же?
Можно увидеть примеры?
Если разработчику понадобилось изменить модель при разработке UI части возможно то, что мысль ушла, даже хорошо ;)
Предлагаю оставим эту тему хотя бы до тех пор пока вы не предоставите ссылки подкрепляющие вашу точку зрения.
Позвольте дать небольшой совет. Перечитайте свои комментарии к этой публикации (и вероятно к другим тоже). Они в большинстве своем чрезмерно эмоциональны. Я не берусь утверждать насколько они обоснованы, но, правда, сложно себе представить, что называя людей идиотами вы получите "+" в карму и за комментарий.
Вы тратите много времени здесь, комментария статьи. Вместо того чтобы раз за разом обрушивать на F# спорную критику можно было бы направить энергию в конструктивное русло.
Плохая документация? Внесите улучшение.
Не хватает какой-то фичи? Предложите ее добавить.
Видите проблему? Вынесите на обсуждение.
Сравнение неуместно, при чем здесь любой другой язык?
У F# репозитория всего 1,406 звезд. Хотя тут наверное организация сыграла роль, так как F# Core находящийся в FSharp организации намного более популярен — 177.
Приходилось. Кроме того, мой первый PR был сделан как раз в F# библиотеку.
Да, но если речь идет об OpenSource проекте, то разбираться в чужом коде, чтобы исправить баг или даже просто локализовать проблему бывает проблематично (время-затратно)
Не нужно думать о порядке файлов, он автоматически линейный.
Вы меня превратно поняли. Я лишь попытался вас предостеречь от громких безосновательных утверждений. В вопросе полноты изложения — указывать не только на плюсы, но и на недостатки я вас полностью поддерживаю, но хотелось бы что-бы они были обоснованы.
Я действительно благодарен вам за ответы.
Насколько я могу судить, в F# сообществе принято говорить правду.
Shrug. Все-таки не на C++ пишем, сборка занимает не так много времени.
Сам я далек от веб-разработки, но WebSharper с самого начала показался несколько странным.
Вы, наверное, вместо Hopack хотели написать Giraffe?
Можно уточнить что вы имеете ввиду под "как показала практика"?
С документацией да, есть некоторые проблемы. Но сообщество достаточно активное чтобы быстро получить ответ на искомый вопрос.
В продакшене Suave используется, хотя сейчас, насколько мне известно, большую все популярность набирает SAFE.
Что касается звездочек и контрибуторов, то это все есть в открытом доступе:
Suave: 1015 Star / 86 contributors
Fable: 1,437 Star / 90 contributors
Giraffe: 939 Star / 46 contributors
Я уверен, что здесь достаточно больше количество звездочек чтобы считать заявление, цитирую "проект никому не нужен" безосновательными. Решительно не понимаю почему вы прибегаете к подобной риторике.
Дело вкуса или привычки. Мне, например, читать F# код значительно проще чем C#. И тут дело не в самом синтаксисе, а в строгом порядке файлов. В F# все зависимости четко прослеживаются, тогда как в C# проекте крайне сложно ориентироваться в виде хаотичного расположения файлов.
Жестких нет, но есть рекомендации
The F# Component Design Guidelines
F# style guide
Не нужно распространять ваш негативный опыт на всех
Сложно представить проект в котором модель и UI смешаны в одном проектном файле по причине сложности их сборки. Можно увидеть ссылки или статьи подтверждающие ваши слова ?
Мне такое сложно представить :-)
Абсолютно
Вы имеете ввиду FAKE и Paket?
Можно узнать по-подробнее о вашем опыте с F#? Впервые встречаю человека с реальным опытом с F# и который бы утверждал что "F# не нормальный язык".
Возможно, конечно. Даже FsXAML предоставляет совсем базовую поддержку для code-behind.
Проще, да, но не честнее. Код на F# пишется быстрее. Даже для демонстрации проблемы или наоборот решения какого-то вопроса использовать его намного удобнее. В тех случаях когда не требуется красивый и сложный UI с большим количеством code-behind возможностей F# точно хватит.
Разве? Вы не могли бы привести примеры?
В том то и дело что используется другой подход. F# в первую очередь функциональный язык программирования, а не чисто функциональный. Если лучше и удобнее применить другой подход, то его и стоит применять.
Есть еще варианты кроме перечисленных вами.
В статье был приведен простейший пример, на всякий случай скопирую его снова:
C#:
Для определения одного и того-же объекта в F# варианте затрачивается меньше времени. В рамках одного типа разница не столь значительна, но все изменится когда вы увеличите их количество в разы.
И это только самый тривиальный случай. F# код намного лаконичнее чем аналогичный на C#.
Нет, не совпадение. Не очень понимаю что именно вы хотите оспорить. C# намного, намного более популярный и востребованный язык чем F#. OpenSource разработчику десктопного UI приложения (да и не только десктопного) не выгодно писать на F#, просто по той причине, что проект не встретит той поддержки, которую мог бы получить аналогичный на C#. Все это должно быть достаточно очевидно. Но раз уж зашла речь об очевидных вещах, то если кто-то и задумается над написанием WPF приложения на F#, то он должен быть готов к тому, что хороших материалов не так уж и много.
Ни себя, ни окружающих я не обманываю. Вы просто говорите о другом. Поддержка F# в VS значительно уступает поддержке C# и проблема отсутствия шаблона для WPF далеко не в вверху списка того, что было бы здорово добавить.
Вы абсолютно правы в том, что поддержки для code-behind в F# проекте в том виде в котором она есть для C# нет, просто по той причине что в F# нет такого понятия как
partial.Вы ошибаетесь. Хотя нет ничего смешного в том, чтобы определить View часть в C# проекте, тогда как все остальное переложить на F#.
Мне тоже не совсем понятно что вы имели ввиду. Какой конструктор использовать можно указать с помощью
[JsonConstructor]/[<JsonConstructor>]. К тому-же у структур есть конструктор по умолчанию.Сложные приложения вряд-ли многие захотят выкладывать в открытый доступ.
WPF работает исправно. Полная F# поддержка для UWP скорее всего будет не скоро, но положительные сдвиги в этом направлении уже есть. Если по каким-то причинам вам нужен WinForms, то можно использовать, например, TrivialBehinds раз уж нет конструктора форм.
Xamarin.Forms поддерживает F#, для более удобной работы есть дополнительные библиотеки, такие как Fabulous, который здесь уже не раз упоминался.
Я бы посоветовал книгу "Программирование на F#". С тех пор F# изменился, но база — основные типы и сам функциональный подход все тот-же и описывается очень понятным и доступным языком.
Также есть восхитительный сайт F# for fun and profit. И, конечно, присоединяюсь к рекомендации worldbeater — "Domain Modelling Made Functional". Сам я эту книгу еще не читал, но это как раз тот случай когда можно советовать "не глядя"
Работает прекрасно
Знакомство с Gjallarhorn.Bindable.WPF (F#) на примере выполнения тестового задания
С сокращениями названий для типов F# может помочь :-)
Использовать со старта вспомогательные библиотеки и/или фреймворки или нет сложный вопрос.
Лично я начинал с библиотеки FSharp.ViewModule и успешно ее использовал в своих небольших проектах, даже не подозревая о внутреннем устройстве команд и объектов уведомляющих о своем изменении. И еще долгое время подобные тонкости меня не беспокоили. Я считаю, что главное понимать что механизм делает, а осознание как именно придет с опытом, при условии что вообще возникнет необходимость разбираться во внутренней реализации.
Видимая сложность MVVM, возможно, одна из причин того, что многие продолжают смешивать все в одной куче. Библиотека, с другой стороны, может помочь развернуть процесс обучения — от общего представления о шаблоне к его полному (или хотя-бы достаточному) пониманию, делая его более плавным.
К тому-же, на мой взгляд, интереснее разбираться в том как приложение работает, а не в том как заставить его работать. И, конечно, самостоятельно написанная работающая программа, в отличие от взятой из папки "samples", пусть даже и построенная из готовых блоков (вызовов готовых методов), дает положительный эффект — "я могу, я умею" [хотя-бы что-то!], добавляя уверенности, а не отрицательный — "ничего не работает", "это не для меня".
Ах, вот оказывается в чем дело, как я сразу не догадался =)
Кажется, вы пропустили "в виде сетки или таблицы" и не только ширина, но и высота тоже ;)
Копия текста?
Не обязательно C# класса. WPF может прекрасно подружиться с F#, не говоря уже о VB.Net.
Здесь, мне кажется, вы не совсем однозначно выражаетесь.
UpdateSourceTriggerлишь указывает на то, когда будет обновляться привязываемое свойство.PropertyChangedустанавливает режим обновления сразу после изменения свойства в "приемнике" (не самое удачное слово, но ничего лучше на ум так и не пришло). По умолчаниюTextBoxобновляет привязку после потери своего фокуса. Что касаетсяTextBlock, то там установкаUpdateSourceTriggerне требуется, как и явныйMode = OneWay.В целом, несмотря на то, что хороших материалов по WPF хватает, еще один туториал точно не повредит.
Но в будущем мне бы хотелось, чтобы примеры были не настолько искусственные. В частности: здесь совсем не требуется реализация
INotifyPropertyChanged. ЕслиTextBlockдолжен дублировать текст изTextBox, то можно сразу там и привязываться к свойствуText, а дополнительная прослойка в виде свойства, оповещающего о своих изменениях, не нужна, обычного авто-свойства в данном конкретном случае будет достаточно.Лучше бы к Илене Сквоттер :-)
Хороший по смыслу рассказ и написан неплохо, но учитывая предыдущие истории могло быть и лучше. Все таки здесь перебор с "рукожопством", но продолжение или альтернативную ветку обязательно прочту
Не смотрел на "Долгую прогулку" с такой точки зрения ("не серьёзное отношение к жизни"). Слушал довольно давно, но ЕМНИП там не только добровольцы были. Мне казалось, что центральная идея — жестокость окружающего мира и да, согласен, последствия от необдуманно принятых решений.