Спасибо Интересная статья, симптомы скорее типичны. Мы тоже по сути не лечим, если никто не жалуется. Регулярно бывает, что после очередного апдейта накинули еще что-то тяжелое и игра стала еще тормознутее, но пользователям норм ((
Ох. Любят у нас находить изобретателей, вы бы хоть почитали, о чем были его работы. Он предложил оригинальные приборы для обработки данных и скорее работал в области статистики. Программированием это называть некорректно, потому что речь не шла о создании "программы". Собственно именно в этом и отличие от Бэббиджа, который занимался, по сути, механическими калькуляторами, но придумал концепцию команд, позволяющих выполнять последовательности вычислений автоматически.
Ну и не стоит забывать, что ответила академия наук - это тоже важно.
Гипотетические дроны, использующие внутренние сим карты и связь. Как водится, не совсем понятно, как это защитит от гиганского рынка серых внутренних симок.
Я знаю. На самом деле открытый паскаль - один из самых переносимых ЯП. В свежих Делфи большие наборы компонентов для мобилок. Тем не менее инфраструктура живет, но так себе. Я люблю делфи, но рекомендовать бы его не стал.
Собственно так же фундаментально. У питона как бы есть типы, в этом можно убедиться, забыв распарсить строковую "1" в 1 и попытавшись их сложить. Просто типов нет у переменных, переменные тут просто идентификаторы. Типы прикрутили довольно поздно, они не обязательны и тонны кода написаны без них. Но да, для того и прикрутили.
В сухом остатке динамическая типизация дает маленькую простоту и удобство в замен повышенного шанса потенциальных рантайм ошибок.
Но речь тут не про это, а про важность понимания типов для обучения. Python тут не страшное зло, страшное зло тут JS с феерическими и неочевидными правилами преобразований, стимулирующими магическое мышление в такой строгой дисциплине, как программирование.
Ну нет, скорее аргумент был что обучение типам важно, потому что это важная концепция, которую нужно понять при обучении. А то, что и в промышленных ЯП это часто используется - другой вопрос.
Так же как и против статической. Они слегка ортогональны.
Основное отличие - ты указываешь тип и потом живешь с этим ограничением. Или не указываешь тип, а получаешь его рантайм и живешь без ограничений. Второе проще примерно на 1 ключевое слово в начале для каждой переменной и поля, но сложнее в неопределенном количестве мест, где ты не можешь определить необходимые данные по сигнатуре функции или понять что происходит лишь по идентификатору
Ну как не имеет, а JS? Ну то есть при присвоении безусловно нечему приводиться, но при использовании значения JS выдает самый безумный список неявных преобразований, которые нужно знать. Собственно самые страшные вещи в js, это неявные преобразования строк в числа и обратно, потому что они нетранзитивны (не все строки это корректные числа) из-за чего их нужно постоянно валидировать при пользовательском вводе. Да и python сложение float и int вполне себе проводит с результатом в виде float
C это отдельная вселенная, это безусловно не лучший учебный язык, в том числе из-за UB, а вот в других статических языках обычно неявные преобразования работают только для неразрушающих преобразований, что работает довольно прозрачно.
Безусловно типы имеют данные, а переменные - лишь их абстракции. И только вам (пользователям языков в смысле) решать, какую абстракцию вы считаете менее протекающей - когда коробочка имеет форму или когда вместо коробочки наклеечка. Как по мне статическая валидация - штука удобная и для пользователя и для компилятора. Она позволяет выразительно описывать API (какие данные требуются функции), предотвращает множество тупейших ошибок с переиспользованием идентификаторов для разных (в контексте программы) сущностей и исключает целые классы ошибок валидации инвариантов, поскольку оные производятся на этапе компиляции и их никак нельзя проигнорировать. Динамические ЯП используют целую гору костылей типа стат анализа и автотестов для того, что работает почти бесплатно. Лишь ради возможности использовать другую, более простую, как им кажется, абстракцию идентификаторов.
Спасибо
Интересная статья, симптомы скорее типичны.
Мы тоже по сути не лечим, если никто не жалуется. Регулярно бывает, что после очередного апдейта накинули еще что-то тяжелое и игра стала еще тормознутее, но пользователям норм ((
Это крайне иронично)
Я ведь не говорю, что они решают эту проблему хорошо, лишь то, что по замыслу авторов они "призваны" решить.
Я так то лично считаю, что у нас другие проблемы и они должны решаться другими способами.
Ох.
Любят у нас находить изобретателей, вы бы хоть почитали, о чем были его работы.
Он предложил оригинальные приборы для обработки данных и скорее работал в области статистики.
Программированием это называть некорректно, потому что речь не шла о создании "программы".
Собственно именно в этом и отличие от Бэббиджа, который занимался, по сути, механическими калькуляторами, но придумал концепцию команд, позволяющих выполнять последовательности вычислений автоматически.
Ну и не стоит забывать, что ответила академия наук - это тоже важно.
Гипотетические дроны, использующие внутренние сим карты и связь.
Как водится, не совсем понятно, как это защитит от гиганского рынка серых внутренних симок.
Нормально они гульнули, на всю котлету.
Ну удачки, нужно посмотреть.
Потому что он отлично работает только на специализированных устройствах и для игр.
Там вполне себе используем, дек отличный.
В остальном в нем те же проблемы, что и с другими десктопными линусками.
Ах, туплю)
Ну такой налог и так все платят. Просто по традиции он не назван по прямой цели
Второй тип есть, всякие экологические сборы - распространенная практика и не только в России.
Я знаю. На самом деле открытый паскаль - один из самых переносимых ЯП. В свежих Делфи большие наборы компонентов для мобилок.
Тем не менее инфраструктура живет, но так себе.
Я люблю делфи, но рекомендовать бы его не стал.
Это не иллюзия, код так то по прежнему пишется для машины.
Просто не в первую очередь.
Собственно так же фундаментально.
У питона как бы есть типы, в этом можно убедиться, забыв распарсить строковую "1" в 1 и попытавшись их сложить.
Просто типов нет у переменных, переменные тут просто идентификаторы.
Типы прикрутили довольно поздно, они не обязательны и тонны кода написаны без них.
Но да, для того и прикрутили.
В сухом остатке динамическая типизация дает маленькую простоту и удобство в замен повышенного шанса потенциальных рантайм ошибок.
Но речь тут не про это, а про важность понимания типов для обучения.
Python тут не страшное зло, страшное зло тут JS с феерическими и неочевидными правилами преобразований, стимулирующими магическое мышление в такой строгой дисциплине, как программирование.
На дженерик задается ограничение ведь.
Интерфейс/класс. Можно и без, но тогда и использовать их можно только как произвольный тип.
Ну нет, скорее аргумент был что обучение типам важно, потому что это важная концепция, которую нужно понять при обучении.
А то, что и в промышленных ЯП это часто используется - другой вопрос.
Так то python и JS очень популярные ЯП
Ваша правда, я про это слышал, но не использовал делфи сто лет.
Если время будет ограничено, то чтобы делать роботов-солдат будут использованы люди добытчики и люди - сборщики.
Это фича PaskalABC
В старых паскалях и реализациях делфи нужно объявлять переменные в блоке перед функцией.
Я все же надеюсь, что в данном случае это больше шутка.
И так печалей хватает с попилом
Так же как и против статической. Они слегка ортогональны.
Основное отличие - ты указываешь тип и потом живешь с этим ограничением. Или не указываешь тип, а получаешь его рантайм и живешь без ограничений.
Второе проще примерно на 1 ключевое слово в начале для каждой переменной и поля, но сложнее в неопределенном количестве мест, где ты не можешь определить необходимые данные по сигнатуре функции или понять что происходит лишь по идентификатору
Ну как не имеет, а JS?
Ну то есть при присвоении безусловно нечему приводиться, но при использовании значения JS выдает самый безумный список неявных преобразований, которые нужно знать. Собственно самые страшные вещи в js, это неявные преобразования строк в числа и обратно, потому что они нетранзитивны (не все строки это корректные числа) из-за чего их нужно постоянно валидировать при пользовательском вводе.
Да и python сложение float и int вполне себе проводит с результатом в виде float
C это отдельная вселенная, это безусловно не лучший учебный язык, в том числе из-за UB, а вот в других статических языках обычно неявные преобразования работают только для неразрушающих преобразований, что работает довольно прозрачно.
Безусловно типы имеют данные, а переменные - лишь их абстракции.
И только вам (пользователям языков в смысле) решать, какую абстракцию вы считаете менее протекающей - когда коробочка имеет форму или когда вместо коробочки наклеечка.
Как по мне статическая валидация - штука удобная и для пользователя и для компилятора.
Она позволяет выразительно описывать API (какие данные требуются функции), предотвращает множество тупейших ошибок с переиспользованием идентификаторов для разных (в контексте программы) сущностей и исключает целые классы ошибок валидации инвариантов, поскольку оные производятся на этапе компиляции и их никак нельзя проигнорировать.
Динамические ЯП используют целую гору костылей типа стат анализа и автотестов для того, что работает почти бесплатно. Лишь ради возможности использовать другую, более простую, как им кажется, абстракцию идентификаторов.