Видимо, большинству пользователей, которые приносят эту самую выгоду стандарты не интересны. Вот из-за табов (а не из-за стандартов) некоторый процент перешел на другие браузеры, вот MS их и добавила.
Что мне не ясно? Всё ясно. Устраивать бредовый холивар на ровном месте не намерен. Если было бы хоть сколько-нибудь констуктивности, еще можно было бы. А пытаться опровергнуть очередную ахинею смысла не вижу.
Эту проблему я пытался обозначить фразой "нормальный сайт, а не Nuke" :)
Единственный вывод, который из всего этого можно сделать — нельзя удобство языка выразить в числах :)
Про то что считать "ООП" долгие споры ведутся. Лучше сказать "от класс-ориентированных языков". Тем более что сам факт возможности изменений не зависит от этой модели.
Для решения круга задач. И одного/двух тестов здесь не придумать.
Вот взять сайт среднего уровня написанный на PHP (нормальный сайт, а не Nuke какой-нибудь) и примерно такой же на Ruby, тогда можно сравнивать скорость работы и скорость разработки.
Я не слишком хорошо знаком с руби, но дополнять и изменять функциональность существующих типов можно JS (хотя там не совсем типы) и, насколько знаю, в Питоне.
В JS, кстати, сами нативные функции изначально сишные, но можно дополнять своими, написанными, на JS.
С учетом того, что скорость доступа к БД определяется в большинстве случаев особенностями самой БД и драйверов к ней.
Да, поэтому разница в скоростях м/у подобными языками уже не несет той остроты, которая была, например, м/у C и паскалем. Гораздо важнее удобство и т.п.
Так что же это за предметная область такая - уже который раз пытаюсь выяснить - где скорость работы циклов/массивов/рекурсий не имеет значение?
Имеет, но не главенствующее. Повторяю, опреации с массивами в PHP в большинстве случаев делаются с помощью встроенных функций работы с массивами. Если в интерпретируемом языке нужна сложная обработка структур, для которой нет набора встроенных средств и её нужно делать вручную на уровне базовых конструкций языка, то такой язык вряд ли подойдет для данной задачи. Так что в данных языках важен набор этих самых встроенных средств и его соответствие задачам решаемым в области данного языка.
Для разметок веб-страничек использут HTML.
Может быть вам ознакомиться для начала с предметной областью, прежде чем высказывать свое компетентное мнение?
Подходят, подходят )
Они подходят для того, чтобы оценить скорость доступа к элементам массива в цикле for. Ну или рекурсивного вызова. Но не подходят для оценки общей производительности языка в его предметной области.
Для того же перебора цифр, можно даже не просто копирование заменить, а использовать встроенные функции работы с массивами.
Это главный недостаток подобных языков - они не могут сколько-нибудь далеко уйти от набора встроенных функций, без значительной потери эффективности.
И эффективность языка во многом определяется именно набором этих самых функций и то, на сколько правильно он ложится на предметную область. Спорить об абстрактном удобстве синтаксиса и абстрактном быстродействии базовых конструкций в отрыве от набора предопределенных средств здесь не совсем корректно.
Вообще в большинстве случаев большинство времени едят запросы к базам и увеличение скорости цикла for, здесь вряд ли поможет.
Это не хитрые хаки. Это элементарные основы языка. Вывод вашей статьи:
Вывод – по производительности PHP и Ruby Core 1.9.0 примерно равны
Какой к чорту производительности? Если решать на PHP задачи методами Си, никакой производительности не будет.
"Скорость работы массивов/циклов" в предметной области PHP имеет не главенствующее значение.
Еще раз. Если бы тест был "перебрать все возможные варианты заданного набора цифр", то это одно. Сама задача не сказать, что хорошая, но да ладно. Вот её в качестве тестов можно было порешать. Решать для каждого языка своим алгоритмом, подходящим для данного языка. Чтобы алгоритм (не тест) корректировался для PHP и для всех остальных.
Здесь же взяли C-решение и воспроизвели его алгоритм на других языках только с изменением синтаксиса.
Типа, включаешь её, уходишь, а потом приходишь и смотришь скриншоты — кто в твоё отсутствие на компе лазил и что делал.
Единственный вывод, который из всего этого можно сделать — нельзя удобство языка выразить в числах :)
Но, давайте не будем в этой теме )
Вот взять сайт среднего уровня написанный на PHP (нормальный сайт, а не Nuke какой-нибудь) и примерно такой же на Ruby, тогда можно сравнивать скорость работы и скорость разработки.
В JS, кстати, сами нативные функции изначально сишные, но можно дополнять своими, написанными, на JS.
И как это сказывается на производительности?
Да, эта фишка достаточно распространена в последнее время во многих языках. К сожалению, нужно признать, в PHP в полной мере её нет.
Да, поэтому разница в скоростях м/у подобными языками уже не несет той остроты, которая была, например, м/у C и паскалем. Гораздо важнее удобство и т.п.
Имеет, но не главенствующее. Повторяю, опреации с массивами в PHP в большинстве случаев делаются с помощью встроенных функций работы с массивами. Если в интерпретируемом языке нужна сложная обработка структур, для которой нет набора встроенных средств и её нужно делать вручную на уровне базовых конструкций языка, то такой язык вряд ли подойдет для данной задачи. Так что в данных языках важен набор этих самых встроенных средств и его соответствие задачам решаемым в области данного языка.
Может быть вам ознакомиться для начала с предметной областью, прежде чем высказывать свое компетентное мнение?
Они подходят для того, чтобы оценить скорость доступа к элементам массива в цикле for. Ну или рекурсивного вызова. Но не подходят для оценки общей производительности языка в его предметной области.
Для того же перебора цифр, можно даже не просто копирование заменить, а использовать встроенные функции работы с массивами.
Это главный недостаток подобных языков - они не могут сколько-нибудь далеко уйти от набора встроенных функций, без значительной потери эффективности.
И эффективность языка во многом определяется именно набором этих самых функций и то, на сколько правильно он ложится на предметную область. Спорить об абстрактном удобстве синтаксиса и абстрактном быстродействии базовых конструкций в отрыве от набора предопределенных средств здесь не совсем корректно.
Вообще в большинстве случаев большинство времени едят запросы к базам и увеличение скорости цикла for, здесь вряд ли поможет.
Если хотите продолжить дискуссию, предлагаю переместиться в конец комментариев, а то тут место мало )
Какой к чорту производительности? Если решать на PHP задачи методами Си, никакой производительности не будет.
"Скорость работы массивов/циклов" в предметной области PHP имеет не главенствующее значение.
Здесь же взяли C-решение и воспроизвели его алгоритм на других языках только с изменением синтаксиса.