Pull to refresh
60
0
Pavel Minaev @int19h

User

Send message

У качественных литиевых батареек AA - напр. Energizer Ultimate Lithium - срок хранения 25 лет "по паспорту".

G-Shock у людей и по 20 лет живут без смены аккумулятора.

У меня есть один экземпляр, которому уже почти 10 лет. Тоже заряжается "на подоконнике".

Это разумная гипотеза, но не более того. Без экспериментальной проверки полагаться на «здравый смысл» нельзя.
Мы избегаем прямых сравнений с основным конкурентом в таком формате (когда инициатива идет от нас), т.к. оно по определению не могло бы быть беспристрастным ввиду очевидного конфликта интересов, и будет воспринято как самореклама. :)

В идеале, хорошо бы, если бы детальное сравнение по фичам сделал кто-то из пользователей обоих продуктов (а еще лучше добавить в сравнение и PyDev, Wing, Spyder...). Думаю, это была бы интересная статья для Хабра. И я с удовольствием бы ответил на все вопросы, которые появились бы после такого сравнения.

Впрочем, я могу ответить на такие вопросы и здесь, лишь бы они были конкретными — т.е. не общее сравнение продуктов, а по конкретным фичам и сценариям.
"Hey, ..." в данном контексте скорее переводится как "слышь, ..." :)
В PTVS нет своего интерпретатора Питона — он использует то, что у вас уже есть. Поэтому все, что работает в обычном Питоне (или IronPython, который тоже поддерживается), будет работать и здесь. С другой стороны, никакой особой интеграции с WinForms и прочим на уровне кода нет — хотя, разумеется, вы можете использовать существующие библиотеки вроде Tk и pythonnet. В IDE есть поддержка визуального редактора форм WPF при использовании IronPython.

Что касается кроссплатформенности — сама VS не кроссплатформена, к сожалению. Поддержки кроссплатформенной VS Code у нас пока нет, но работа над этим уже началась. При этом сам код, который ви пишете, разумеется, может быть кроссплаформенным, и PTVS поддерживает удаленную отладку кода на любых платформах.
В отличие от гитхаба, который все-таки сайт «для работы», скажем так, Реддит — это, по сути, гигантский форум. И у его сообщества есть вполне определенное и очень ярко выраженное мнение по вопросам вроде свободы слова. Так что shitstorm будет гарантированный, и я думаю, что блокировку на стороне сервера скоро уберут.
Это намного более низкоуровневая вещь, чем Java. В нее можно компилить C — попробуйте сделать это с JVM…
Вы почитайте описание на GitHub. К JS это все не имеет никакого отношения, основная цель — задать кроссплатформенный, портабельный IR, в который можно будет компилить (для начала) C и C++.
>> Точно так же никакой проблемы нет в том, чтобы сразу использовать интерфейс. Это нулевые затраты.

В плане написания — возможно. В плане чтения, особенно когда активно используются дженерики, и там еще что-то вложенное — var проще.

>> Всё становится сложнее, когда программист автоматом добавляет return из метода, IDE выводит возвращаемый тип из типа переменной

А вот тут я уже замечу, что нехорошим в данном случае является именно автовывод типа возврата. Границы метода — они неспроста.
А в чем проблема поменять тип, если это вдруг понадобится? Ну будет дифф не на две строки, а на три.

(Как показывает практика, в 99% случаев — не понадобится, и по умолчанию имхо стоит исходить из этого.)
Для локальной переменной нет никакого смысла ограничивать её тип интерфейсом — она не более чем деталь реализации метода. Интерфейсы имеет смысл использовать на границе API, но как раз там var в C# недоступен.
>> в развитии C# выбрали модель «добавить как можно больше фич и сахара как можно быстрее»,

Это в равной степени миф. Я вам советую почитать записи в блоге Эрика Липперта про дизайн языковых фич, и design meeting notes из страницы Roslyn на GitHub. Там можно увидеть, насколько нещадно на самом деле режутся списки предлагаемых фич.
В C++ можно было и раньше, интерпретатор на шаблонах пишется на коленке. Правда, отжирает по паре гигабайт памяти на мало-мальски сложных программах, но, право же, это такая мелочь по сравнению с улучшенной читабельностью.

А теперь, когда у нас есть еще и user-defined literals…
Если сразу писать код с ConfigureAwait, то ваш воркараунд не нужен. Причем профит этим не ограничивается — не будет ненужных переходов на главный поток, вне зависимости от контекста вызова, и не будет разницы в поведении из-за неизвестного начального шедулера.
Отлично, т.е. у вас вызывающий код должен быть в курсе деталей реализации DoSomeWorkAsync, чтобы знать, нужно его оборачивать в Task.Run или нет.

Или вы всерьез предлагаете вообще все таски так оборачивать «на всякий случай»?

Не лучше ли делать так, как рекомендуют авторы всего этого дела, и по возможности писать контексто-независимый асинхронный код (т.е. — с ConfigureAwait), особенно в библиотеках, где его планируется повторно использовать?
>> Например, вы можете его вызвать в отдельном потоке, а затем дождаться его.

И что, вы думаете, это как-то поможет с описанным в статье дедлоком?
Обратите внимание — тот же офис (с которого компания традиционно рубит больше всего денег) уже несколько лет как продается в т.ч. как сервис, с годовой подпиской.
Кстати, очень похожим образом работал класс XPathDocument. Там после парсинга все XDM-дерево хранится именно вот так, отображением на большие массивы байт индексацией. И обход дерева через XPathIterator ходит по этим байтам (в которых хранятся и относительные сдвиги на соседние узлы по разным осям).

Information

Rating
Does not participate
Location
North Bend, Washington, США
Date of birth
Registered
Activity