Мне доводилось слышать мнение, что джавский байткод изначально затачивался под эффективный его интерпретатор, а вот в дотнете такой задачи не ставилось, поэтому там его дизайн не шибко этому способствует.
Не берусь сказать, в чем именно это проявляется, но слышал я это от человека, занимающегося VM в .NET.
На самом деле не так уж и сложно. Там слой графики хорошо изолирован от собственно XAML и всего такого, и портировать надо в основном его (ну и работу с WM).
Интересно, можно ли как-то автоматизировать этот процесс. Если шрифт юникодный, то в нем ведь все эти стрелочки уже есть, нужно просто перенести их в лигатуры, добавив нужное количество пространства по бокам для выравнивания, так?
Q: How does Visual Studio Community 2013 compare to other Visual Studio editions?
A: Visual Studio Community 2013 includes all the great functionality of Visual Studio Professional 2013
Там добавилась, например, отладка плюсового кода на андроиде (т.е. по факту VS научилась удаленно отлаживать через gdb из коробки — я надеюсь, они рано или поздно вытащат эту фичу в UI как вещь в себе).
Разница с монадой в том, что в последней у вас результатом вычисления последовательности выражений будет тоже Result — у которого можно проверить Error. Т.е. это эквивалент плюсового:
А чем типизированный Result принципиально отличается от checked-исключений в Java, которые вы просили «не предлагать»?
Собственно, строго типизированные исключения не являются чем-то таким особенным, если понять, что это просто монада, и в любом языке, где есть средства для работы с монадами, автоматический проброс и гарантированная обработка с полной строгой типизацией реализуются, по сути, автоматически.
Исключения в Java тоже можно рассматривать в качестве такой монады, которая насильно засунута в каждый закоулок языка (т.е. условно говоря — каждое выражение в Java на самом деле имеет не тип T, а Result<T, ExceptionList>). Проблема с ними там в том, что в Java убогие дженерики, которые вообще никак не покрывают throws, что не позволяет объявлять higher-order functions с корректной сигнатурой («я бросаю все, что бросает переданная мне функция, плюс X, минус Y»). Это, кстати, пытались прикрутить в Project Lambda на ранних этапах, но после радикального упрощения оно пошло под нож.
>> В статье рассказывается про две стратегии обработки исключений, из коей можно сделать выводы, что вне зависимости от выбранного механизма, есть некоторый (малый или умеренный) оверхед.
При использовании таблиц исключений, оверхед при их (исключений) отсутствии нулевой.
Непонятно, за что минусуют комментарий. Что, человек неправду сказал, что анонимность биткоин-транзакций во многом и позволяет проворачивать такие схемы? У меня у самого есть биткоины, и я хочу, чтобы эта валюта взлетела, но надо понимать, что побочным эффектом будут и вот такие вещи (а также Silk Road, с его «рынком наемных убийц» и прочими прелестями). И, да — этим должны заниматься соответствующие органы. Не биткоином, а теми, кто им пользуется в преступных целях.
Судя по дате, это какой-то древний дев билд. Последний баг с брейкпоинтами в TS был относительно недавно (сообщение от пользователя в октябре), и пофикшен в Beta 3, который вышел вчера.
Не берусь сказать, в чем именно это проявляется, но слышал я это от человека, занимающегося VM в .NET.
Кстати, шрифт ваш мне напомнил Fortress.
A: Visual Studio Community 2013 includes all the great functionality of Visual Studio Professional 2013
Где вы не проверяете отдельно каждый вызов foo, bar и baz на Error, а ловите его один раз при выходе из блока.
Собственно, строго типизированные исключения не являются чем-то таким особенным, если понять, что это просто монада, и в любом языке, где есть средства для работы с монадами, автоматический проброс и гарантированная обработка с полной строгой типизацией реализуются, по сути, автоматически.
Исключения в Java тоже можно рассматривать в качестве такой монады, которая насильно засунута в каждый закоулок языка (т.е. условно говоря — каждое выражение в Java на самом деле имеет не тип T, а Result<T, ExceptionList>). Проблема с ними там в том, что в Java убогие дженерики, которые вообще никак не покрывают throws, что не позволяет объявлять higher-order functions с корректной сигнатурой («я бросаю все, что бросает переданная мне функция, плюс X, минус Y»). Это, кстати, пытались прикрутить в Project Lambda на ранних этапах, но после радикального упрощения оно пошло под нож.
При использовании таблиц исключений, оверхед при их (исключений) отсутствии нулевой.