В основном да. Но бывает лень или хочется быстрей получить результат, тогда пишу их постфактум. Хотя это не очень хороший подход, так как более вероятней что-то пропустить.
Я специально подчеркнул про современные подходы к ракетостроению, ничего из перечисленного вами на практике не использовалось и сложно что-то утверждать про их возможности.
Надо считать по формуле Циолковского сколько топлива понадобится ракете, чтобы преодолеть такую гравитацию. Там получается, что чем выше гравитация, тем сложней запуск, может даже на определенном уровне гравитации запуск в космос и вовсе невозможен. Это если исходить из современных представлений о ракетных технологиях и ограничениях.
Интересно, не думал, что именно эта фича из релиза станет заголовком новости. Мы решили поддержать @SuperBuilder потому что было довольно много запросов о его поддержке, несмотря на то, что это до сих пор экспериментальная аннотация: https://youtrack.jetbrains.com/issue/KT-53563/Kotlin-Lombok-Support-SuperBuilder Она нужна тем, кто итеративно портирует код Java на Kotlin, и, видимо, таких пользователей довольно много.
Главное не все время, а когда нужно. Вот например я работаю над компилятором языка Kotlin - и там чем круче проц, тем быстрей проходят все тесты (они распараллелены), т.е. потолка практически нет. Ну и чем больше ядер используется, тем больше памяти требуется.
Кстати, в силу специфики задачи, мощная видеокарта вообще не нужна.
Получается, что мир для жителей бублика замкнутый, потому что можно достигнуть изначальной точки, если двигаться в определенных направлениях.
Однако по современным представлениям, реальная вселенная плоская, кривизны обнаружено не было. Из этого следует, что она все же конечная, но замыкается на очень больших расстояниях, которые мы это пока не можем обнаружить (либо вообще никогда не сможем), либо вселенная бесконечная. В первом случае у вселенной может быть центр, но в другом измерении, как вы и написали. Во втором - у вселенной центра нет.
Согласен - как будто бы написана глупость, которая портит все остальное впечатление от статьи. Но не знаю, может в C++ есть какие-то нюансы при выведении типов для auto.
Если член команды Jetbrains ReSharper пишет что нашел дичь (ну ок - нестандартное или необычное поведение), наверное он чего-то в этом понимает.
Так-то я тоже в JetBrains работаю, правда над компилятором Котлина (в котором тоже можно написать много подобного и похуже). Но наверное из-за этого я понимаю причины подобного поведения в большинстве приведенных примерах. Над запрещением некоторых можно подумать, но все это сложно с учетом того, что нужно сохранять обратную совместимость.
Обратная совместимость. Словаasync, await могут быть как ключевыми, так и идентификаторами в зависимости от контекста. Они были введены не с первой версии дотнета, поэтому если бы их сделали жестко ключевыми, то какой-то старый код мог бы перестать компилировать, о чем разработчики языка конечно же подумали, в отличие от автора статьи (если весь этот пост не шутка).
Дичь пятая: вызов без инициализации
Даже из названия используемых классов становится понятно, для чего нужна такая функциональность: для оптимизации десериализации, чтобы не инициализировать поля, значения которых сразу же будет переписано. Использовать можно, если точно знать зачем это нужно.
Дичь шестая: угар по гречески
Здесь вообще претензия непонятна и подобное почти везде написать можно. Если хочется запретить нелатинские буквы, то можно настроить какой-нибудь линтер. Тем более с unsafe.
Дичь восьмая: строка, которая хотела стать числом
Такой код, конечно, писать не надо - это абьюз возможности перегрузки операторов. Но с точки зрения разработчиков языка сложно формализовать и реализовать такие запреты.
Дичь седьмая: рефлексия без рефлексии
Возможность творить такое без использования спецального API для рефлексии — неожиданный сюрприз для анализаторов кода и антивирусов.
Объединения - это фича языка, которая используется при написании быстрого кода. Например, когда нужно получить побитовое представление float и изменить единичные биты. И обнаружить такое несложно, учитывая вот это:
[StructLayout(LayoutKind.Explicit, Pack = 1)]
public struct Union
{
[FieldOffset(0)] public Alpha AsAlpha;
[FieldOffset(0)] public Bravo AsBravo;
}
Как говорится комментарии излишни, отмечу лишь что работа с типами double и float чаще всего происходит в геймдеве и каждая подобная ошибка может стоить неделю отладки «в мыле и с красными глазами».
Думаю, что даже малоопытные разработчики из геймдева знают, в каких случаях нужно использовать оператор == для чисел с плавающей точкой (в очень редких).
А если серьезно, просто не надо использовать такой код в реальных проектах, благо что каждый пример — повод к немедленному увольнению.
Именно такой не надо, но хорошо бы понимать почему так можно или хотя бы сценарии использования определенных редких вещей.
Синтаксис дело привычки, мне на первых порах тоже было неудобно, а потом наступил момент, когда я на инфиксную запись уже смотрел с неодобрением)
Я тут имею в виду скорей ситуацию в общем. Например, математики издавна пользуются инфиксной формой, так и не перешли на lisp-подобный формат. Хотя у них в формулах вообще намного больше визуала, но это все равно ближе к инфиксной записи.
В случае работы со строками мне сначала пришлось бы составлять строку, потом парсить строку вывода в какой-нибудь внутренний формат, который бы подозрительно напоминал лисповый список с префиксной формой внутри.
Эти формы еще и на результат могут влиять. Но, с учетом того, что у автора в приоритете скорость, а не точность, то особо так важно.
Кажется, здесь нужно использовать веса для различных функций. Например, логарифм намного сложней умножения или деления, так что вес у него больше и записи справа проще в данном контексте. Хотя если умножений много, а логарифм - один, то логарифм оптимальней. Все это неточно и может работать неправильно на каких-то краевых случаях.
В целом я согласен - задача упрощения выражений довольно расплывчатая и сложная. Скорей всего у идеального алгоритма такая сложность, что она делает его непрактичным для реального использования и без эвристик не обойтись.
Один разбор этого выражения (а ведь в нем тоже могут быть скобки! И некоторые из них, но не все, ограничивают параметры функций!) может стать темой дипломной работы, чего уж тут говорить об удобстве.
Это к теме формальных грамматик и парсинга. Там могут быть какие-то сложности, неоднозначности, но в целом не должно быть особо сложно.
В лисп же первый член списка это всегда обозначение функции, а все остальные - ее параметры. В общем, если вам нужно работать с символьными выражениями, выбирайте лисп, не пожалеете.
Это удобно с точки зрения синтаксического разбора, но с точки зрения восприятия инфиксная запись формул все-таки удобней для восприятия человеком.
Кстати, а вы солверы не смотрели? Например, Z3. Для описания моделей в нем тоже используется lisp подобный язык, есть функции упрощения, а для кастомных правил есть такая фича, как тактики.
В основном да. Но бывает лень или хочется быстрей получить результат, тогда пишу их постфактум. Хотя это не очень хороший подход, так как более вероятней что-то пропустить.
Кажется, что такая запись дробей редко используется, т.к. с ней работать неудобно. Разве что для лучшей наглядности.
Best way to denote some trigonometric functions ("tg" vs "tan", "ctg" vs "cot")
А atan2 не так работает?
Я специально подчеркнул про современные подходы к ракетостроению, ничего из перечисленного вами на практике не использовалось и сложно что-то утверждать про их возможности.
Надо считать по формуле Циолковского сколько топлива понадобится ракете, чтобы преодолеть такую гравитацию. Там получается, что чем выше гравитация, тем сложней запуск, может даже на определенном уровне гравитации запуск в космос и вовсе невозможен. Это если исходить из современных представлений о ракетных технологиях и ограничениях.
Интересно, не думал, что именно эта фича из релиза станет заголовком новости. Мы решили поддержать
@SuperBuilderпотому что было довольно много запросов о его поддержке, несмотря на то, что это до сих пор экспериментальная аннотация: https://youtrack.jetbrains.com/issue/KT-53563/Kotlin-Lombok-Support-SuperBuilder Она нужна тем, кто итеративно портирует код Java на Kotlin, и, видимо, таких пользователей довольно много.Главное не все время, а когда нужно. Вот например я работаю над компилятором языка Kotlin - и там чем круче проц, тем быстрей проходят все тесты (они распараллелены), т.е. потолка практически нет. Ну и чем больше ядер используется, тем больше памяти требуется.
Кстати, в силу специфики задачи, мощная видеокарта вообще не нужна.
Еще для определения рациональных чисел: Q = Z / N, где Z - целые, N - натуральные. С нулем не получится такой лаконичной записи.
Вроде получается так.
Получается, что мир для жителей бублика замкнутый, потому что можно достигнуть изначальной точки, если двигаться в определенных направлениях.
Однако по современным представлениям, реальная вселенная плоская, кривизны обнаружено не было. Из этого следует, что она все же конечная, но замыкается на очень больших расстояниях, которые мы это пока не можем обнаружить (либо вообще никогда не сможем), либо вселенная бесконечная. В первом случае у вселенной может быть центр, но в другом измерении, как вы и написали. Во втором - у вселенной центра нет.
Согласен - как будто бы написана глупость, которая портит все остальное впечатление от статьи. Но не знаю, может в C++ есть какие-то нюансы при выведении типов для auto.
Тонкости языка, отладка и IDE - не особо связанные вещи. Этим даже разные команды занимаются.
Так-то я тоже в JetBrains работаю, правда над компилятором Котлина (в котором тоже можно написать много подобного и похуже). Но наверное из-за этого я понимаю причины подобного поведения в большинстве приведенных примерах. Над запрещением некоторых можно подумать, но все это сложно с учетом того, что нужно сохранять обратную совместимость.
Обратная совместимость. Слова
async,awaitмогут быть как ключевыми, так и идентификаторами в зависимости от контекста. Они были введены не с первой версии дотнета, поэтому если бы их сделали жестко ключевыми, то какой-то старый код мог бы перестать компилировать, о чем разработчики языка конечно же подумали, в отличие от автора статьи (если весь этот пост не шутка).Даже из названия используемых классов становится понятно, для чего нужна такая функциональность: для оптимизации десериализации, чтобы не инициализировать поля, значения которых сразу же будет переписано. Использовать можно, если точно знать зачем это нужно.
Здесь вообще претензия непонятна и подобное почти везде написать можно. Если хочется запретить нелатинские буквы, то можно настроить какой-нибудь линтер. Тем более с unsafe.
Такой код, конечно, писать не надо - это абьюз возможности перегрузки операторов. Но с точки зрения разработчиков языка сложно формализовать и реализовать такие запреты.
Объединения - это фича языка, которая используется при написании быстрого кода. Например, когда нужно получить побитовое представление float и изменить единичные биты. И обнаружить такое несложно, учитывая вот это:
Думаю, что даже малоопытные разработчики из геймдева знают, в каких случаях нужно использовать оператор
==для чисел с плавающей точкой (в очень редких).Именно такой не надо, но хорошо бы понимать почему так можно или хотя бы сценарии использования определенных редких вещей.
А после мойки ее еще разгружать надо.
Я тут имею в виду скорей ситуацию в общем. Например, математики издавна пользуются инфиксной формой, так и не перешли на lisp-подобный формат. Хотя у них в формулах вообще намного больше визуала, но это все равно ближе к инфиксной записи.
Да - это называется деревом разбора.
Да, это валидный аргумент.
Эти формы еще и на результат могут влиять. Но, с учетом того, что у автора в приоритете скорость, а не точность, то особо так важно.
Кажется, здесь нужно использовать веса для различных функций. Например, логарифм намного сложней умножения или деления, так что вес у него больше и записи справа проще в данном контексте. Хотя если умножений много, а логарифм - один, то логарифм оптимальней. Все это неточно и может работать неправильно на каких-то краевых случаях.
В целом я согласен - задача упрощения выражений довольно расплывчатая и сложная. Скорей всего у идеального алгоритма такая сложность, что она делает его непрактичным для реального использования и без эвристик не обойтись.
Это к теме формальных грамматик и парсинга. Там могут быть какие-то сложности, неоднозначности, но в целом не должно быть особо сложно.
Это удобно с точки зрения синтаксического разбора, но с точки зрения восприятия инфиксная запись формул все-таки удобней для восприятия человеком.
Кстати, а вы солверы не смотрели? Например, Z3. Для описания моделей в нем тоже используется lisp подобный язык, есть функции упрощения, а для кастомных правил есть такая фича, как тактики.
Это функция IntelliJ, которая позволяет быстро сохранить и откатить изменения (еще неправильно написал, правильно shelve). Использую ее внутри IntelliJ: https://www.jetbrains.com/help/idea/shelving-and-unshelving-changes.html