>> Решение, предложенное в статье — нет :)

Хм. Это, видимо, из-за несоответствия локальных путей удаленным. Но обычно во всех средах, где удаленная отладка предусмотрена из коробки (в PyCharm это через pydevd), есть какой-то способ задать соответствие путей. Либо явно, как в PyDev, либо отладчик хитрым способом пытается отмапить пути, как у PTVS (мы ходим по удаленной файловой системе и ищем __init__.py, чтобы реконструировать часть пути, которая относится к имени модуля, а потом сравниваем только эту часть с локальным именем файла). В PyCharm, судя по докам, есть явный path mapping — почему нельзя использовать его?

А кто-то не поддерживает точки останова при удаленной отладке?

Кстати, с запуском у нас такие же заморочки. В смысле, что нужно городить огород с костылями вроде этого. Единственное что, бинарь не обязан называться python.exe. В идеале, конечно, надо бы прикрутить удаленный запуск напрямую через SSH — это есть в списке фич.

Впрочем, что касается конкретно Raspberry Pi, Win10 и PTVS — подождите Build через неделю, там будет кое-что :)

>> без лишних извратов можно передать non-null значение в функцию, принимающую nullable параметры.

То, что String — это подтип String?, это как раз хорошо и правильно, никакого камуфлирования. В C# аналогично int — это подтип Nullable, во всяком случае, с подстановочной т.з. (но не наоборот!)

>> Основной плюс в том, что nullable types — это исключительно фишка компилятора, также как и generics. Не существует реального типа String?.. Напр. нельзя написать String?::class, нельзя унаследовать nullable type, etc.

А вот это уже косяк. И непонятно, почему вы его приводите в качестве фичи. Понятно, что это ограничение рантайма, так же, как и type erasure у generics, но что в этом хорошего?

Ну и в любом случае это не значит, что такого типа нет. В TypeScript вот вообще все типы исключительно этапа компиляции, а в рантайме понятия «тип» нет вообще, но это же не значит, что типы там не настоящие.

>> итоге все транслируется в обычные ссылочные типы, которые по определению уже null. С Optional это не так — это реальный тип данных, который для каждого ссылочного значения, которое уже и так nullable, создает дополнительный объект в памяти.

Это уже косяк конкретной реализации Optional в Java. Хотя я могу их понять — из-за того, что внятной семантики у null не было, иногда им приходится различать «значение есть, но оно null» от «значения нет».

Но это, опять же, не проблема самой идеи с optional-типами, а данной конкретной её инкарнации. Те самые nullable-типы в Kotlin — это и есть optional, просто с более удобным сахаром и более внятной семантикой.

На практике, 90% кода на шарпе, с которым я имею дело, не использует сахар. Т.е. в данном случае имелся в виду именно набор функциональных примитивов.

Ну так по сути это все равно разные несовместимые типы, просто в Kotlin проверка на null меняет тип s со String? на String внутри соответствующей ветви. Т.е. претензия здесь не по адресу — виноват не Optional, виновато отсутствие удобного способа проверить и сузить тип.

>> Алгоритм обработки коллекции, записанный в функциональном виде, чаще всего проигрывает в читабельности, выразительности, расширяемости в сравнении с императивным видом.

Это все, мягко говоря, субъективно. Когда в C# появились лямбды семь лет назад, многие комментировали это слово в слово как вы. А сейчас уже очень тяжело найти код без LINQ по объектам, и всем все понятно. Это вопрос привычки.

Сразу вопрос — вот такое вот он съест?

template<bool> struct a_t;

template<> struct a_t<true> {
    template<int> struct b {};
};

template<> struct a_t<false> {
    enum { b };
};

typedef a_t<sizeof(void*)==sizeof(int)> a;

enum { c, d };
int main() {
    a::b<c>d; // declaration or expression?
}

И что именно будет в результате (и, в частности, будет ли оно зависеть от настроек текущей конфигурации проекта)?

Managed C++ уже много лет как deprecated. Но, скорее всего, имелся в виду C++/CLI.

Он вполне себе поддерживался, но его выпилили в VS 2010 (по причине полного переписывания C++ Intellisense). Потом запилили обратно в следующих версиях.

На самом деле это очень старая идея — в CLOS используется похожая схема для инкапсуляции.

Кристально чистая гомосексуальность — это вообще редкая штука, что у животных, что у людей. Так что не беспокойтесь, гены передадутся куда надо :) а о поддержании «правильного» процента в долгосрочной перспективе позаботится эволюция. Половой отбор никто не отменял, и у хомосапиенсов он работает вовсю.

Там потом были дальнейшие исследования (других уже людей) с целью уточнить факторы воздействия, и вроде как были некоторые основания полагать, что дело даже не в физической плотности как таковой, а в «плотности социального взаимодействия» (попросту говоря — количеству сторонних особей, с которыми вы пересеклись за некий фиксированный срок времени, и которым по результатам взаимодействия вам хочется взять и уе… ть). Т.е. теоретически плотность физическую можно повышать, если при этом есть какие-то каналы разрядки социального напряжения.

Да, интересующимся источником — погуглите «Population density and social pathology», John B. Calhoun.

Это крысы. На людях мы пока такие опыты не ставили. Но есть предположение, что из-за этого процент должен быть выше в городах вообще, что вроде как соответствует действительности.

В любом случае, это может быть только один фактор из множества других. Просто в этом эксперименте был изолирован именно он.

Эволюция — это всегда рандом на индивидуальном уровне. А вот на уровне вида в целом уже есть вполне определенные закономерности. Например, у крыс процент гомосексуальных индивидов в следующем поколении возрастает, если их держать в более тесных клетках — такой вот самоконтоль популяции…

У баз с полноценной поддержкой XML (не знаю, как с этим в Postgres, но думаю, что это там есть) индексы по XML как раз замечательно строятся, и XPath-запросы потом их используют. Собственно, он именно затем и нужен как отдельный от обычных блобов тип данных.

То есть это из-за вашей любви к копипасте во все поля тривиальный баг в одном экземпляре приводит к распределенной атаке на всю сеть?

На самом деле, это просто грубый, но простой хак, позволяющий с минимальными усилиями вырубить функциональность размножения у определенного подмножества объектов, без рефакторинга в отдельный класс.

>> Более того, в развитых странах сумма наличными больше ста долларов вызовет опасения.

Вы так говорите, как будто это что-то хорошее.

Потому что если все будут на Blink, то де факто стандартом HTML/CSS/JS будет не то, что написано на w3.org, а то, что Гугл реализовал в Blink. К чему это приводит, вы могли видеть на примере IE6 в 2001-2004.

Да, это, разумеется, WPF. Его «наследники» намного более убоги.

Насчет нативной поддержки редактирования (это все-таки не то же самое, что type safe) — ну так её нет и у обычных биндингов. Хотя это в принципе можно сделать, возможности редактора VS такое позволяют — аналогично тому, как в ASP.NET редактор поддерживает смешанный HTML и C# код.

На производительность генерация кода не влияет, так как происходит целиком на этапе компиляции — обратите внимание, это MSBuild-таск. По сути он вклеивается в обычный пайплайн для генерации кода для WPF, и вшивает тело лямбд в partial class. Потому и все ошибки в лямбде, будь то неверные типы или переменные, вылезут на этапе компиляции (ну, если вы не используете dynamic — а по умолчанию, если не указать тип параметра у лямбды, то он там будет именно dynamic).

Производительность в рантайме — один словарный поиск по строке для каждой лямбды один раз при загрузке XAML, плюс два косвенных вызова на каждый вызов лямбды (там несколько оберток). По сравнению с накладными расходами на сам биндинг, вы это вообще не заметите.