Потому что мне в моей практике массивы из нескольких элементов встречались не раз и не два.
А сколько? Сколько строчек кода Вы сэкономите в своём текущем проекте, если в нём будет задействован generic линейный поиск?
Но если у Вас в задаче есть место, где точно нужен линейный поиск, то это хорошо, что Вы и задействовали линейный поиск. Моё сообщение как раз о том, что многообразие задач не позволяет эффективно долбить одними и теми же подходами.
Если Вы имеете ввиду [1, 2, 3, 4, 5], что встречается в сообщении, которое автор претензии к Go выложил в ответе собеседнику, так принадлежность к такому множеству вообще решается через битовые маски в Си-подобных языках
0 != ((1 << n) & 62)
и этот вариант будет работать быстрей «дружественного к шине памяти и к предсказателю переходов» линейного поиска.
А о чём это говорит? Что как раз нет большого смысла в однообразном способе решения, за которое так радеет автор претензии к Go, желая работать одинаково и со строками, и с числами, и с бог знает с чем ещё. Когда вместо сферических примеров в вакууме появляется настоящая задача, то всё видится несколько не так.
Лично мне уже изрядно надоели программы, которые еле ворочаются на сверхпроизводительных современных компьютерах.
Беда с такими программистами, которые используют линейный поиск по массиву O(n) там, где следует использовать ассоциативный массив O(1). Потому всё и тормозит.
переключение задач происходит по таймеру, который работает с фиксированной частотой.…. Допустим, задача А исполняется за 700 мкс, после чего передаёт управление функцией Yield(). Планировщик поставит на исполнение задачу Б. Но через 300 мкс придёт прерывание от таймера, и планировщик передаст управление дальше.
Почему бы не давать задаче Б 1000 + 300 мкс? Тогда задача Б не ущемляется, а, наоборот, поощрается. Остальным задачам от этого, как минимум, не хуже, а если и задача Б завершится раньше, то и следующей задаче перепадёт больше машинного времени.
На первый взгляд, такой подход выглядит адекватнее и воплощаться должен просто.
Под особым отношением я не имел ввиду, что он должен быть основным языком в компании, а то, что его отдалённым производным уделяется куда больше внимания, чем заслуживает сам язык.
О том, что 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 так велик, что, вполне возможно, есть реализации, соответствующие этому требованию.
А сколько? Сколько строчек кода Вы сэкономите в своём текущем проекте, если в нём будет задействован generic линейный поиск?
Но если у Вас в задаче есть место, где точно нужен линейный поиск, то это хорошо, что Вы и задействовали линейный поиск. Моё сообщение как раз о том, что многообразие задач не позволяет эффективно долбить одними и теми же подходами.
и этот вариант будет работать быстрей «дружественного к шине памяти и к предсказателю переходов» линейного поиска.
А о чём это говорит? Что как раз нет большого смысла в однообразном способе решения, за которое так радеет автор претензии к Go, желая работать одинаково и со строками, и с числами, и с бог знает с чем ещё. Когда вместо сферических примеров в вакууме появляется настоящая задача, то всё видится несколько не так.
Лично мне уже изрядно надоели программы, которые еле ворочаются на сверхпроизводительных современных компьютерах.
Почему бы не давать задаче Б 1000 + 300 мкс? Тогда задача Б не ущемляется, а, наоборот, поощрается. Остальным задачам от этого, как минимум, не хуже, а если и задача Б завершится раньше, то и следующей задаче перепадёт больше машинного времени.
На первый взгляд, такой подход выглядит адекватнее и воплощаться должен просто.
К сожалению, мои наблюдения говорят об обратном. Легко можно получить тонну ненависти.
А в каком виде он это рассказывал -«оно есть, но неудобно»?
То есть, они все перешли на C++? Вроде бы нет же, не переходят. Зачем они «мучаются»?
При структурном программировании совсем не обязательно просовывать кучу флагов, если этого не требует сама задача. Речь об этом и неудобстве подтверждает то, что я сказал ранее — большинству людей не хочется вникать в суть.
С исключениями тоже интересно, учитывая тенденции новых языков. В Go избыточное использование исключений сделали неудобным, поэтому даже не все знают, что там они есть, а в Rust исключений нет вовсе. Со Swift ещё не разобрался, но, похоже, его разработчики тоже пытаются найти что-то своё. Всё быстро меняется и Ваше понятие о современном программисте могло и устареть, не говоря о том, сколько современных программистов используют С. Думаете, они поголовно мучаются без исключений?
И как-то выпадает из этого доказательства то, что скорость Python — это далеко не единственный и, возможно, не главный недостаток. Главным недостатком, на мой взгляд, является слабая ошибкоустойчивость Python, которая всё с возврастающей нелинейной силой начинает проявляться по мере роста размера и сложности проекта. Для чего-то простого Python вполне приемлем, для чего-то сложного или ответственного — нет.
Ах да, скорость языка тоже важна для целей корректности программы, так как позволяет использовать более простые, а потому и более надёжные решения там, где для медленных языков придётся изгаляться.
Возможно, мы читали разные статьи, но я не нигде не видел утверждений о том, что «нельзя допустить ошибку». Допускаю, что Вы не поняли основной посыл — некоторые ошибки, сделанные в программах на Си, действительно крайне сложно совершить, например, как эпичную Appleвскую:
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
В целом же, язык не запрещает делать ошибки и статический анализатор и система автоматического доказательства корректности тоже нужны.
Некоторые трансляторы Оберона генерируют код на Си, так что применить к ним те же инструмента анализа вполне возможно. Только кому это действительно интересно?
Но главное в том, что в вашем ответе нарушена логика. От того, что другие напишут хорошие статьи, на что Вы намекаете, плохая статья с затраченным на неё временем не исчезнет, а поэтому и не исчезнет объект для критики. Более того, из-за большого количества плохих статей становиться и более трудозатратным поиск хороших. Поэтому для того, чтобы сделать что-то лучше, нужно не только что-то делать, но и чего-то не делать.
Было бы совсем неплохо советоваться со своим внутренним худ.советом, а то и организовать внешний.