О том, что break и continue — это частные случаи goto знают не только избранные, и ругают точно также как и goto. Те же, кто считает break и continue оправданными, и к goto относятся более тепло. И проблема неструктурного программирования не исчерпывается заходом внутрь конструкций. Поэтому, к примеру, в MISRA C — рекомендациях для критичных к ошибкам ПО, неструктурное программирование запрещено практически полностью, включая и преждевременный выход из функции.
При структурном программировании совсем не обязательно просовывать кучу флагов, если этого не требует сама задача. Речь об этом и неудобстве подтверждает то, что я сказал ранее — большинству людей не хочется вникать в суть.
С исключениями тоже интересно, учитывая тенденции новых языков. В Go избыточное использование исключений сделали неудобным, поэтому даже не все знают, что там они есть, а в Rust исключений нет вовсе. Со Swift ещё не разобрался, но, похоже, его разработчики тоже пытаются найти что-то своё. Всё быстро меняется и Ваше понятие о современном программисте могло и устареть, не говоря о том, сколько современных программистов используют С. Думаете, они поголовно мучаются без исключений?
Всё несколько не так. Проблема вообще не в goto, а в неструктурном программировании. Если соблюдать принципы структурного программирования, то goto оказывается ненужным. При этом само по себе использование goto не приводит автоматически к неструктурному коду, и наоборот — без goto тоже можно программировать неструктурно. Поскольку большинству людей не хочется вникать в суть, то и мусолят они то, что лежит на поверхности — goto.
Это стандартная особенность скриптовых языков — то, что хорошо для экономии строчек, плохо в отношении ошибкоустойчивости. Та же статическая типизация не только способствует скорости, но и позволяет вылавливать ошибки раньше. Чем больше программа — тем сложней её связи и тем больше в ней ошибок и вероятность их проявления и последствия от них. Тем критичней возможность отлавливать ошибки как можно раньше.
Меня не радует то, что так много кода в мире, от которого всё больше зависит наша жизнь, создаётся программистами, у которых плохо с логикой. Автор этой статьи не исключение, поскольку начав с того, что одной из причин, по которой люди отказываются от Python — это его медленная скорость, продолжает доказывать, что нет причин этого делать потому что: 1) скорость не важна 2) Python быстрый.
И как-то выпадает из этого доказательства то, что скорость Python — это далеко не единственный и, возможно, не главный недостаток. Главным недостатком, на мой взгляд, является слабая ошибкоустойчивость Python, которая всё с возврастающей нелинейной силой начинает проявляться по мере роста размера и сложности проекта. Для чего-то простого Python вполне приемлем, для чего-то сложного или ответственного — нет.
Ах да, скорость языка тоже важна для целей корректности программы, так как позволяет использовать более простые, а потому и более надёжные решения там, где для медленных языков придётся изгаляться.
Возможно, мы читали разные статьи, но я не нигде не видел утверждений о том, что «нельзя допустить ошибку». Допускаю, что Вы не поняли основной посыл — некоторые ошибки, сделанные в программах на Си, действительно крайне сложно совершить, например, как эпичную Appleвскую: if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
В целом же, язык не запрещает делать ошибки и статический анализатор и система автоматического доказательства корректности тоже нужны.
Некоторые трансляторы Оберона генерируют код на Си, так что применить к ним те же инструмента анализа вполне возможно. Только кому это действительно интересно?
Мне статья понравилась, хотя я тоже не избежал разочарования.
Но главное в том, что в вашем ответе нарушена логика. От того, что другие напишут хорошие статьи, на что Вы намекаете, плохая статья с затраченным на неё временем не исчезнет, а поэтому и не исчезнет объект для критики. Более того, из-за большого количества плохих статей становиться и более трудозатратным поиск хороших. Поэтому для того, чтобы сделать что-то лучше, нужно не только что-то делать, но и чего-то не делать.
Было бы совсем неплохо советоваться со своим внутренним худ.советом, а то и организовать внешний.
В любом случае, для скриптования — решение так себе. Одно дело — набор маленьких скриптов, другое дело — набор многомегабайтных болванок. На время запуска размер тоже влияет, так как увеличивается количество данных для считывания и загрузки.
Я не уверен, что оно так уж подходит для быстрого запуска маленьких программ. Так как минимальный размер исполнимого файла, который он создаёт, довольно велик.
джава не способна решить проблемы скриптования никак
С точки зрения потенциальных возможностей, нет никаких ограничений, чтобы эффективно использовать Java для маленьких быстрозапускающихся программ. Для этого всего лишь нужна виртуальная машина, нацеленная на быстрый запуск, а не на продолжительное оптимизированное исполнение. Большой нужды в этом нет, потому что Java — это не скриптовый язык. Тем не менее, список виртуальных машин Java так велик, что, вполне возможно, есть реализации, соответствующие этому требованию.
Понятно, вначале я был невнимателен и не заметил, что оценивается размер одного ответа в зависимости от количества запрашиваемых параметров, а не все необходимые данные, включая запрос.
В своё время мне довелось создавать систему обработки батареек и я задумал сделать их самоописываемыми, чтобы легко поддерживать разные типы и их версии. Особенность была в том, что требовался протокол с минимальными накладными расходами, чтобы влезть в узкий канал данных. Не найдя быстро ничего подходящего, я решил создать своё решение, и теперь вижу, что оно получилось действительно экономным.
Если для чтения одного параметра в DLMS требуется out(12 + 11) + in(12 + 2 + 4) = 41 байт, то в моём решении в минимальном варианте требовалось out(1) + in(1 + 4) = 6 байт. Ответ для пакета данных из 30 параметров мог составлять (1 + 30 * 4 = 121) байт, если все параметры лежали в одной структуре или (15 + 15 * 2 + 30 * 4 = 165) байт, если — в разрозненных.
Понятно. Осталось понять, как получается около 200 байт на 30 значений. Если данные считываются через запрос-ответ, то согласно формулам для DLMS на 30 значений уйдёт (12 + 11 * 1) * 30 + (12 + 6 * 1) * 30 = 1230 байт. Если же предположить, что запросом мы подписываемся на получение новых значений, то тогда понадобится (12 + 11 * 1) * 1 + (12 + 6 * 1) * 30 = 563 байт. И только если мы каким-то одним хитрым запросом запросили сразу 30 значений, которые придут пачкой, то выйдет (12 + 11 * 1) * 1 + (12 + 6 * 30) * 1 = 215 байт. Последний вариант выглядит странно, если нужно получить серию измерений от одного датчика, поэтому у меня возник вопрос о схеме получения данных.
Что-то никак не могу сообразить схему получения данных, которая использовалась для расчётов таблиц. Объясните, пожалуйста, как для DLMS при размере запроса — 12 + 11*n и размере ответа — 12+ 6*n получается около 200 байт на 30 полученных значений, то есть, чуть больше 6 байт на значение? Значения идут пачкой? И почему размер запроса согласно формуле больше, чем ответ?
К сожалению, мои наблюдения говорят об обратном. Легко можно получить тонну ненависти.
А в каком виде он это рассказывал -«оно есть, но неудобно»?
То есть, они все перешли на C++? Вроде бы нет же, не переходят. Зачем они «мучаются»?
При структурном программировании совсем не обязательно просовывать кучу флагов, если этого не требует сама задача. Речь об этом и неудобстве подтверждает то, что я сказал ранее — большинству людей не хочется вникать в суть.
С исключениями тоже интересно, учитывая тенденции новых языков. В Go избыточное использование исключений сделали неудобным, поэтому даже не все знают, что там они есть, а в Rust исключений нет вовсе. Со Swift ещё не разобрался, но, похоже, его разработчики тоже пытаются найти что-то своё. Всё быстро меняется и Ваше понятие о современном программисте могло и устареть, не говоря о том, сколько современных программистов используют С. Думаете, они поголовно мучаются без исключений?
И как-то выпадает из этого доказательства то, что скорость Python — это далеко не единственный и, возможно, не главный недостаток. Главным недостатком, на мой взгляд, является слабая ошибкоустойчивость Python, которая всё с возврастающей нелинейной силой начинает проявляться по мере роста размера и сложности проекта. Для чего-то простого Python вполне приемлем, для чего-то сложного или ответственного — нет.
Ах да, скорость языка тоже важна для целей корректности программы, так как позволяет использовать более простые, а потому и более надёжные решения там, где для медленных языков придётся изгаляться.
Возможно, мы читали разные статьи, но я не нигде не видел утверждений о том, что «нельзя допустить ошибку». Допускаю, что Вы не поняли основной посыл — некоторые ошибки, сделанные в программах на Си, действительно крайне сложно совершить, например, как эпичную Appleвскую:
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
В целом же, язык не запрещает делать ошибки и статический анализатор и система автоматического доказательства корректности тоже нужны.
Некоторые трансляторы Оберона генерируют код на Си, так что применить к ним те же инструмента анализа вполне возможно. Только кому это действительно интересно?
Но главное в том, что в вашем ответе нарушена логика. От того, что другие напишут хорошие статьи, на что Вы намекаете, плохая статья с затраченным на неё временем не исчезнет, а поэтому и не исчезнет объект для критики. Более того, из-за большого количества плохих статей становиться и более трудозатратным поиск хороших. Поэтому для того, чтобы сделать что-то лучше, нужно не только что-то делать, но и чего-то не делать.
Было бы совсем неплохо советоваться со своим внутренним худ.советом, а то и организовать внешний.
В своё время мне довелось создавать систему обработки батареек и я задумал сделать их самоописываемыми, чтобы легко поддерживать разные типы и их версии. Особенность была в том, что требовался протокол с минимальными накладными расходами, чтобы влезть в узкий канал данных. Не найдя быстро ничего подходящего, я решил создать своё решение, и теперь вижу, что оно получилось действительно экономным.
Если для чтения одного параметра в DLMS требуется out(12 + 11) + in(12 + 2 + 4) = 41 байт, то в моём решении в минимальном варианте требовалось out(1) + in(1 + 4) = 6 байт. Ответ для пакета данных из 30 параметров мог составлять (1 + 30 * 4 = 121) байт, если все параметры лежали в одной структуре или (15 + 15 * 2 + 30 * 4 = 165) байт, если — в разрозненных.