Можно вообще написать такой генератор псевдослучайных чисел, который тест на выпадение шестёрок будет проходить идеально.
Например такй: seed ГПСЧ будет от 0 до 100 * 3 (100 раз по 3 рола), а само число выбираться case-ом. После броска: seed++.
Но генерировать пароли таким генератором явным образом не стоит) Всего 300 разных паролей.
Вопрос качества ГСПЧ — это вопрос энтропии источника, а не то, насколько он адекватно аппроксимирует равномерное распределение.
Первые две метрики точно не годятся для поставленной задачи, ведь самый простой язык по ним — Brainfuck!
6 операторов, да 2 условных оператора — истинно самый простой язык.
А третья метрика, вообще непонятно от чего зависит.
От библиотек, от компиляторов, сред программирования, ленивости программистов, репозиториев с либами, и их удобства.
Ну и от языка, конечно, тоже. В общем совсем не понятно что означает то или иное число.
Вообще, я думаю, из-за того, что сложность бывает разных типов, хорошую метрику построить будет проблематично.
Какой бы простой Go или Lua не был, в решении математических задач WolframAlpha или Matlab надерут ему задницу по простоте.
Ставлю на Эмпирику. Так что продолжаем холиварить!
Тут отлично подойдёт самый простой алгоритм «k-средних» (а у нас тут k=2), да и пишется он на коленке за пол часа.
И для каждого конкретного случая писать его снова не нужно. В том и прелесть, если сравнению с Threshold=200.
Продать «k-средних» как отдельный сервис, это к маркетологам. -)
Если сделать достаточное количество запросов, то можно даже попытаться применить кластерный анализ, вместо непонятно что означающего «среднего значения между минимальным и максимальным временем загрузки».
А ещё, можно делать два запроса: на favicon.ico и на favicon.ico?randomhashhere.
Тогда можно знать за сколько скачивается та же фавиконка, но без кеша.
Если сделать SmsRecipient интерфейсом, то его можно имплементировать пользователям, компаниям, администраторам системы, и красиво передавать сами модели в шлюз.
Я вопрос прочитал полностью. Это не отменяет моего вопроса.
Более того, я действительно считаю что ответы на вопросы «Зачем использовать ООП?», «Зачем нам ООП?», «Почему используют ООП?» должны быть похожими и заключается в описании сильных сторон ООП.
В вашем же ответе, только ваше субъективное «Мы на ООП пишем лучше чем при процедурном подходе». Это как ответ на вопрос «В чём сильные стороны сюрреализма?» отвечать «Я плохой художник-импрессионист».
Ядро GNU/Linux содержит более тринадцати миллионов строк процедурного кода (взято тут). Если бы они не смогли управлять сложностью этого кода, он не был бы так популярен сейчас.
Обычно это происходит, если разработчик ИТ продукта, разбираеться только в ИТ на должном уровне и не хочет слышать тех, кто разбирается в автоматизации производства стройматериалов.
Можно вообще написать такой генератор псевдослучайных чисел, который тест на выпадение шестёрок будет проходить идеально.
Например такй: seed ГПСЧ будет от 0 до 100 * 3 (100 раз по 3 рола), а само число выбираться case-ом. После броска: seed++.
Но генерировать пароли таким генератором явным образом не стоит) Всего 300 разных паролей.
Вопрос качества ГСПЧ — это вопрос энтропии источника, а не то, насколько он адекватно аппроксимирует равномерное распределение.
Первые две метрики точно не годятся для поставленной задачи, ведь самый простой язык по ним — Brainfuck!
6 операторов, да 2 условных оператора — истинно самый простой язык.
А третья метрика, вообще непонятно от чего зависит.
От библиотек, от компиляторов, сред программирования, ленивости программистов, репозиториев с либами, и их удобства.
Ну и от языка, конечно, тоже. В общем совсем не понятно что означает то или иное число.
Вообще, я думаю, из-за того, что сложность бывает разных типов, хорошую метрику построить будет проблематично.
Какой бы простой Go или Lua не был, в решении математических задач WolframAlpha или Matlab надерут ему задницу по простоте.
Ставлю на Эмпирику. Так что продолжаем холиварить!
И для каждого конкретного случая писать его снова не нужно. В том и прелесть, если сравнению с Threshold=200.
Продать «k-средних» как отдельный сервис, это к маркетологам. -)
А ещё, можно делать два запроса: на favicon.ico и на favicon.ico?randomhashhere.
Тогда можно знать за сколько скачивается та же фавиконка, но без кеша.
Думаю, с интерфейсом будет совсем красиво.
Спросите лучше тут: discrete.gr/complexity/
Или у вас позиция «ИМХО» в русской интерпретации, и говорить на эту тему вы не видите смысла?
Более того, я действительно считаю что ответы на вопросы «Зачем использовать ООП?», «Зачем нам ООП?», «Почему используют ООП?» должны быть похожими и заключается в описании сильных сторон ООП.
В вашем же ответе, только ваше субъективное «Мы на ООП пишем лучше чем при процедурном подходе». Это как ответ на вопрос «В чём сильные стороны сюрреализма?» отвечать «Я плохой художник-импрессионист».
Ядро GNU/Linux содержит более тринадцати миллионов строк процедурного кода (взято тут). Если бы они не смогли управлять сложностью этого кода, он не был бы так популярен сейчас.
PoP 1
Пинговал из разных стран — потери 60-80%… Хабраэффект?