The name LLVM was originally an initialism for Low Level Virtual Machine. This initialism has officially been removed to avoid confusion, as the LLVM has evolved into an umbrella project that has little relationship to what most current developers think of as virtual machines
На самом деле правильный подход — оставить текстовые файлы, но предусмотреть синтаксис настолько простой и эффективный, чтобы анализ и построение синтаксического дерева выполнялись буквально «на лету» в любой IDE начиная от профессиональных систем и заканчивая сверхлегкими
Flash память ужасно ненадёжна. Её ненадёжность компенсируется сложной прошивкой. Причём чем тоньше техпроцесс или чем больше бит пихают в одну ячейку (MLC, TLC, QLC...), тем менее надёжен NAND и тем сложнее требуется прошивка. А их пишут обычные люди, как могут так и пишут — где-то хорошо, где-то так себе.
В общем, когда немножко представляешь изнутри эту кухню, тот факт, что SSD внезапно смертен, не удивляет совершенно.
Штрафное время начисляется за каждую правильно решенную задачу и равняется времени, прошедшему с начала соревнования до момента прохождения кодом всех тестов. Более того, за каждую неудачную попытку сдать задачу к штрафу прибавляется 20 минут (только в том случае, если в итоге задачу удается решить). Штраф не начисляется, если команда так и не предложила правильное решение задачи.
Никаких противоречий, просто не сказано ничего про compilation error и про неудачные отправки для уже сданной успешно задачи (для правил это важно, а для статьи — лишние подробности).
В общем, я тоже не понимаю плюсов динамической типизации, и, как можно увидеть на практике, индустрия старается от неё уйти в сторону строгой статической типизации.
Системы типов в мейнстрим языках становятся всё более развитыми и позволяют всё большую гибкость (= меньше напрягают, больше помогают), поэтому остаётся всё меньше поводов выбирать динамическую типизацию.
Но дизайн — это же единственное, чем можно конкурировать.
И кстати, чем дизайн Котлина по вашему мнению хуже, чем у существующих решений? Какие там страшные косяки?
У F# на редкость дружелюбное сообщество. В соответствующем Телеграм чате новичкам всегда рады и на вопросы постоянно отвечают. И здесь вам тоже ответили, нужные ссылки привели, уточнить если что всегда можно. По-моему, здесь не в сообществе проблема, а вам очень хочется придраться.
Не только в кастах дело: в C например можно всё сломать, обратившись к обычному числу как к указателю. Или указатель на одну структуру скастить к указателю на другую, совсем несовместимую, и система типов это не проверяет. И в рантайме тоже никто это не проверяет — получайте UB.
Какова семантика? Условие проверяется до выполнения тела цикла или после? Тело цикла выполняется в случае, если условие истинно или ложно?
И получается Lisp!
Когда видишь в описании языка слово «функциональный», ожидаешь увидеть нечто другое.
В общем, когда немножко представляешь изнутри эту кухню, тот факт, что SSD внезапно смертен, не удивляет совершенно.
Никаких противоречий, просто не сказано ничего про compilation error и про неудачные отправки для уже сданной успешно задачи (для правил это важно, а для статьи — лишние подробности).
Системы типов в мейнстрим языках становятся всё более развитыми и позволяют всё большую гибкость (= меньше напрягают, больше помогают), поэтому остаётся всё меньше поводов выбирать динамическую типизацию.
А чем, например, Ruby не ООПшный?
И кстати, чем дизайн Котлина по вашему мнению хуже, чем у существующих решений? Какие там страшные косяки?
Простите, а какой язык из уже взлетевших может похвастаться идеальным дизайном без косяков?
Это я к тому, что качество дизайна может быть и влияет на успех языка, но точно не является определяющим фактором.
Простите, но минусы на Хабре анонимны и поставить его мог кто угодно, даже по ошибке.
Здесь выведется последний объявленный тип. Неоднозначность можно явно разрешить при необходимости.
Для конкретно вашего случая (чтобы не путать единицы измерения) очень удобно использовать single case discriminated union:
(Пример взяла отсюда)