Комментарии 206
Какая свежая новость. Третий годик проекту ужо.
Сравинть RoR c PHP это всё равно что сравнить Oracle c С++.
Сравинть RoR c PHP это всё равно что сравнить Oracle c С++.
А я бы стал сравнивать.
Сейчас даже тенденция такая есть, что некоторые пых-пых-кодеры(php тобишь) вообще шарахаются от RoR, ибо в интернете последнее время часто говорят, что Ror придет на смену PHP, а тотальное переобучение - не для всех малина.
Сейчас даже тенденция такая есть, что некоторые пых-пых-кодеры(php тобишь) вообще шарахаются от RoR, ибо в интернете последнее время часто говорят, что Ror придет на смену PHP, а тотальное переобучение - не для всех малина.
В интернете только и делают, что говорят. Причём впечатление, что о RoR говорят больше, чем делают. Этакая пирамида привлекают новый народ в Руби в основном для того, чтобы о нём ещё раз раcтрубить в статьях, показывающий очередной "Hello, world".
Кодеры на PHP шарахаются обосновано. Ruby является полностью объектно-ориентированной средой. Купированный мозг может сильно затруднить эффективное освоение.
Речь нужно вести не о переобучении, а о повышении (а возможно дис-)квалификации, поскольку средства типа PHP понижают планку программирования ниже допустимого плинтуса.
Речь нужно вести не о переобучении, а о повышении (а возможно дис-)квалификации, поскольку средства типа PHP понижают планку программирования ниже допустимого плинтуса.
так ведь один программист и на Java может весь код засунать в main(), а другой на PHP использовать design patterns в ООП
Может. Только все равно далеко на этом не уедет. Так ка волей не волей прийдется изучать что там и как работает. У Java высокий уровень вхождения. Как и у любого ООП языка собственно.
PHP это ООП-язык, в пятой версии ООП-модель приближается к Java по возможностям. То ли еще будет в шестой...Другой вопрос, что в ООП-парадигме там писать необязательно, как в С++
Давайте вы не будете меня смешить ООП в PHP 5 ? И тем что ООП модель в нем приближается к Java. Я писал и на том и на том и могу сказать что такого бредового ООП я больше нигде не видел. Одно то что нельзя перегрузить конструктор очень радует. Как перегружаются функции просто фантастика.
что вы понимаете под перегрузкой методов и главное - для каких целей не обойтись без перегрузки конструктора?
Без перегрузки конструктора не обойтись в случае создания объекта с использованием каких либо входных переменных. Конечно можно использовать один конструктор и внутри написать много кода, но это не очень удобно. Под перегрузкой методов она и подразумевается. Меня просто там порадовала конструкция которая требуется для указания перегрузки. Из-за этого там им пользоваться не сильно удобно. К тому же ООП в PHP не сильно быстрое.
>Под перегрузкой методов она и подразумевается.
Очень хорошее определение :)) Ну раз другого нет, то я буду понимать под перегрузкой возможность в зависимости от количества и типов переменных вызывать тот или иной метод (поскольку часто перегрузкой называют то, что происходит при полиморфизме).
В таком рассмотрении перегрузка:
- есть зло, поскольку нифига не упрощает работу по поддержке кода;
- не является одним из необходимых условий для того чтобы считать язык ОО.
>Без перегрузки конструктора не обойтись в случае создания объекта с использованием каких либо входных переменных.
1. РНР слаботипизованный язык, в этом есть свои плюсы и свои минусы. Но такая особенность дает больше гибкости в написании веб-приложений. Поэтому перегрузка методов в зависимости от принимаемых типов - вообще говоря противоречит идеалогии языка.
2. Много кода - это один вызов func_get_args()?
3. Что-то мне подсказывает, что если для конструктора потребовалось передавать переменное количество параметров, то это косяки в проектировании объектной структуры программы.
>К тому же ООП в PHP не сильно быстрое.
О как. Можно результаты тестов увидеть? По моим данным, возможные задержки при ОО подходе в РНР много меньше тех, что вносят кривые руки программистов. А если все же возникает необходимость в этой экономии на спичках, то значит помочь тут может только чистый С(++), но уж никак не Ruby и не Java.
Очень хорошее определение :)) Ну раз другого нет, то я буду понимать под перегрузкой возможность в зависимости от количества и типов переменных вызывать тот или иной метод (поскольку часто перегрузкой называют то, что происходит при полиморфизме).
В таком рассмотрении перегрузка:
- есть зло, поскольку нифига не упрощает работу по поддержке кода;
- не является одним из необходимых условий для того чтобы считать язык ОО.
>Без перегрузки конструктора не обойтись в случае создания объекта с использованием каких либо входных переменных.
1. РНР слаботипизованный язык, в этом есть свои плюсы и свои минусы. Но такая особенность дает больше гибкости в написании веб-приложений. Поэтому перегрузка методов в зависимости от принимаемых типов - вообще говоря противоречит идеалогии языка.
2. Много кода - это один вызов func_get_args()?
3. Что-то мне подсказывает, что если для конструктора потребовалось передавать переменное количество параметров, то это косяки в проектировании объектной структуры программы.
>К тому же ООП в PHP не сильно быстрое.
О как. Можно результаты тестов увидеть? По моим данным, возможные задержки при ОО подходе в РНР много меньше тех, что вносят кривые руки программистов. А если все же возникает необходимость в этой экономии на спичках, то значит помочь тут может только чистый С(++), но уж никак не Ruby и не Java.
Очень хорошее определение :)) Ну раз другого нет, то я буду понимать под перегрузкой возможность в зависимости от количества и типов переменных вызывать тот или иной метод (поскольку часто перегрузкой называют то, что происходит при полиморфизме).
В полиморфизме не перегрузка. Там есть специальный термин виртуальные функции. Хотя по мне то же термин корявый.
В таком рассмотрении перегрузка:
- есть зло, поскольку нифига не упрощает работу по поддержке кода;
Не зло. Дело в том что при отсутсвии перегрузки вам и необходимости передавать туда какие либо переменные, вам прийдется или отказаться от затеи передавать туда что либо, либо четко задать максимально большой список и уже в самом методе проверять переменные и производить с ними действия. В результате вы получите портянку кода. Есть конечно еще один вариант это плодить кучу методов с разными названиями. Но это не всегда удобно к тому же может привести к достаточно сильному перелопачиванию кода в случае если у нас изменяется имя или еще что-то. Перегрузка же позволяет написать набор функций имеющие одинаковое название и работоющие по разному с разными переменными. Конечно это палка о двух концах, но обычно пользы от не больше чем вреда.
- не является одним из необходимых условий для того чтобы считать язык ОО.
Это да. В C к примеру тоже есть возможность перегрузки функций.
1. РНР слаботипизованный язык, в этом есть свои плюсы и свои минусы. Но такая особенность дает больше гибкости в написании веб-приложений. Поэтому перегрузка методов в зависимости от принимаемых типов - вообще говоря противоречит идеалогии языка.
А от количества? У нас может быть не один входной параметр, а несколько.
2. Много кода - это один вызов func_get_args()?
А код верификации где? Откуда вы знаете что там напередавали? Основная идея перегрузки методов и конструкторов в избежании верификации входных параметров и функций проверки куда передать управление. Т.е. в случае если у нас передаются все входные параметры то нам надо проверить их число, потом какие из них чему равны.
3. Что-то мне подсказывает, что если для конструктора потребовалось передавать переменное количество параметров, то это косяки в проектировании объектной структуры программы.
А что-то мне подсказывает, что к примеру может потребоваться передать инициализационные данные в виде двух чисел или в виде к примеру массива. Я понимаю что это можно решить при помощи unc_get_args(). Но два конструктора будут обладать более простым и коротким кодом.
О как. Можно результаты тестов увидеть? По моим данным, возможные задержки при ОО подходе в РНР много меньше тех, что вносят кривые руки программистов.
Да много меньше, но сам код начинает работать медленнее. Хотя это еще возможно из-за того что там больше уровней абстракции.
А если все же возникает необходимость в этой экономии на спичках, то значит помочь тут может только чистый С(++), но уж никак не Ruby и не Java.
Вот про java не факт. Так как она довольно хорошо масштабируется. Надеюсь то что ее используют для своих порталов sun.com и ibm.com убедит в этом? ;)
>Не зло.
Давайте рассмаотрим не смешивая две задачи:
1. Передача произвольного количества параметров. Задача решается func_get_args.
2. Передаются разные типы данных. Напомню - РНР - слаботипизованный язык. Для большинства веб-орентированных задач это является большим плюсом. Если нам нужно в зависимости от типа передаваемого аргумента по разному их обрабатывать, то имеет место быть не правильно спроектированная система. Но даже в таком случае я не понимаю в чем преимущество разноса на несколько одинаковоназывающихся методов вместо сохранения логики в одном методе.
А поскольку это "палка о двух концах", то в самый не подходящий момент она может больно ударить по всяким разным местам. :) Разумеется в РНР это не снимает с программиста ответственности за верификацию данных. Тип данных придется проверять безусловно (хотя никто не мешает жестко задать пользовательский тип при аргументе). А проверять значения аргументов - надо в любом языке.
sun.com и ibm.com - сложно считать эти проекты высоконагруженными.
Давайте рассмаотрим не смешивая две задачи:
1. Передача произвольного количества параметров. Задача решается func_get_args.
2. Передаются разные типы данных. Напомню - РНР - слаботипизованный язык. Для большинства веб-орентированных задач это является большим плюсом. Если нам нужно в зависимости от типа передаваемого аргумента по разному их обрабатывать, то имеет место быть не правильно спроектированная система. Но даже в таком случае я не понимаю в чем преимущество разноса на несколько одинаковоназывающихся методов вместо сохранения логики в одном методе.
А поскольку это "палка о двух концах", то в самый не подходящий момент она может больно ударить по всяким разным местам. :) Разумеется в РНР это не снимает с программиста ответственности за верификацию данных. Тип данных придется проверять безусловно (хотя никто не мешает жестко задать пользовательский тип при аргументе). А проверять значения аргументов - надо в любом языке.
sun.com и ibm.com - сложно считать эти проекты высоконагруженными.
1. Передача произвольного количества параметров. Задача решается func_get_args.
Решается. Но надо еще написать дополнительную обвязку которая их обрабатывает. Если бы была возможность перегрузки этого кода не возникало.
2. Передаются разные типы данных. Напомню - РНР - слаботипизованный язык. Для большинства веб-орентированных задач это является большим плюсом.
Не требуется преобразование для вывода? В целом плюс, но иногда может давать неожиданные результаты. Хотя конечно это контролируемо.
Если нам нужно в зависимости от типа передаваемого аргумента по разному их обрабатывать, то имеет место быть не правильно спроектированная система.
Простой пример в качестве входных данных может фигурировать два числа, строка, массив и объект. Как вы можете их одинаково обработать? В случае с перегрузкой я создаю нужное мне количество конструкторов, в каждом пишу, как их обрабатывать и не заморачиваюсь.
Но даже в таком случае я не понимаю в чем преимущество разноса на несколько одинаковоназывающихся методов вместо сохранения логики в одном методе.
Хм в php это дает малую ценность так типизации фактически нет. Дает кстати в том случае если объекты передаваемые конструктору обрабатываются по разному. Там код процедуры сокращается и становится более понятным. Хотя я тут вот подумал... в целом ничего не мешает вызывать конструктор, а из него вызывать уже прегруженный метод. Хотя это конечно обход ограничения, но работать должно :)
Разумеется в РНР это не снимает с программиста ответственности за верификацию данных. Тип данных придется проверять безусловно (хотя никто не мешает жестко задать пользовательский тип при аргументе). А проверять значения аргументов - надо в любом языке.
Ну вот в слабой типизации мне и не нравится, что кроме верификации данных, еще надо проводить верификацию типа. Как-то ООП с жесткой типизацией в этом плане мне больше нравится. Если уж мне и надо будет передавать что-то без типизации, то проще уж абстрактный класс сделать от него наплодить потомков, а в методе же в качестве получаемого параметра указывать этого абстрактного предка.
sun.com и ibm.com - сложно считать эти проекты высоконагруженными.
Вы думаете что туда единомоментно мало народу заходит ? :)
>Но надо еще написать дополнительную обвязку которая их обрабатывает.
Да, и это единственная возможность правильно решать задачу. Потому что в случае использования перегрузки Вы не сможете описать все возможные варианты.
>Простой пример в качестве входных данных может фигурировать два числа, строка, массив и объект.
Это не пример. Это абстрактная задача :) Если в реальности возникает такая необходимость - 99% за то что система не правильно спроектирована. Если _вдруг_ такая необходимость возникает - передавайте только объект :)
>Если уж мне и надо будет передавать что-то без типизации, то проще уж абстрактный класс сделать от него наплодить потомков
Так в РНР предлагется именно такое же решение, но "повернутое" в обратную сторону - если нужна типизация - указывайте в качестве типа аргумента свой класс, от которого должен быть создан ваш объект. Таким образом и сохранятеся слабая типизация, и при необходимости можно задать ее жестко. Очень красивое решение. :)
>Вы думаете что туда единомоментно мало народу заходит?
Думаю меньше чем на - http://www.habrahabr.ru/blog/webdev/5054… + мамба для кучи. У яхи есть еще ряд сервисов, работающих под РНР. Кстати тот же ibm очень активно продвигает РНР в массы.
Да, и это единственная возможность правильно решать задачу. Потому что в случае использования перегрузки Вы не сможете описать все возможные варианты.
>Простой пример в качестве входных данных может фигурировать два числа, строка, массив и объект.
Это не пример. Это абстрактная задача :) Если в реальности возникает такая необходимость - 99% за то что система не правильно спроектирована. Если _вдруг_ такая необходимость возникает - передавайте только объект :)
>Если уж мне и надо будет передавать что-то без типизации, то проще уж абстрактный класс сделать от него наплодить потомков
Так в РНР предлагется именно такое же решение, но "повернутое" в обратную сторону - если нужна типизация - указывайте в качестве типа аргумента свой класс, от которого должен быть создан ваш объект. Таким образом и сохранятеся слабая типизация, и при необходимости можно задать ее жестко. Очень красивое решение. :)
>Вы думаете что туда единомоментно мало народу заходит?
Думаю меньше чем на - http://www.habrahabr.ru/blog/webdev/5054… + мамба для кучи. У яхи есть еще ряд сервисов, работающих под РНР. Кстати тот же ibm очень активно продвигает РНР в массы.
Да, и это единственная возможность правильно решать задачу. Потому что в случае использования перегрузки Вы не сможете описать все возможные варианты.
Обычно я делаю перегрузку именно на конечное число вариантов. Это удобнее чем городить лишний код и лучше читается.
Это не пример. Это абстрактная задача :) Если в реальности возникает такая необходимость - 99% за то что система не правильно спроектирована. Если _вдруг_ такая необходимость возникает - передавайте только объект :)
Этот пример вполне укладывается, в создание объекта прямоугольника или отрезка. Можно передавать два числа, можно уже существующий объект (для клонирования к примеру). Хотя конечно правильнее по возможности передавать объект.
Так в РНР предлагется именно такое же решение, но "повернутое" в обратную сторону - если нужна типизация - указывайте в качестве типа аргумента свой класс, от которого должен быть создан ваш объект. Таким образом и сохранятеся слабая типизация, и при необходимости можно задать ее жестко. Очень красивое решение. :)
По мне нет. Если уж у нас слабая типизация, то пусть это уж это будет полностью объектный язык. В процедурной же парадигме это несколько напрягает и иногда выходит боком. Поэтому я обычно в PHP использую ООП. Да кстати опять пока не забыл есть ли аналог перлового модуля strict для PHP?
Думаю меньше чем на - http://www.habrahabr.ru/blog/webdev/5054… + мамба для кучи. У яхи есть еще ряд сервисов, работающих под РНР. Кстати тот же ibm очень активно продвигает РНР в массы.
Хм. А мне кажется что порядки все же те же. IBM много чего в массы двигает. Sun вон вообще поддержку Groovy Ruby и Python добавила в свою JDK. Хотя там опять же трансляция в java производится, а затем компиляция и запуск на JVM :)
>Обычно я делаю перегрузку именно на конечное число вариантов.
А остальные варианты - приложение выпадает с ошибкой?
>пример вполне укладывается, в создание объекта прямоугольника или отрезка
Так это практически классический пример на применение полиморфизма ;)
>есть ли аналог перлового модуля strict для PHP
На сколько я знаю - нет.
>А мне кажется что порядки все же те же.
Мне кажется - массовые сервисы по определению должны иметь больше посетителей, чем специализированные сервера.
А остальные варианты - приложение выпадает с ошибкой?
>пример вполне укладывается, в создание объекта прямоугольника или отрезка
Так это практически классический пример на применение полиморфизма ;)
>есть ли аналог перлового модуля strict для PHP
На сколько я знаю - нет.
>А мне кажется что порядки все же те же.
Мне кажется - массовые сервисы по определению должны иметь больше посетителей, чем специализированные сервера.
От перегрузки методов я тоже не в восторге, именно поэтому я и написал в предыдущем посте
ООП-модель приближается к Java, а не
ООП-модель сравнима с Java
Вот вот. К тому же еще что мне не нравится в php это модель поведения CGI у динамических страниц, странный шаблонизатор, отсутсвие абстракций СУБД их коробки, единое пространство имен, безумная каша функций без какой либо на то системы, медленная работа самого ООП, не использование имеющегося в наличии механизма исключений стандартными функциями. Кроме этог еще неплохо бы увеличить скорость и ввести модуль аля strict для perl. Нет кстати такой шняги ? А то мне без таких вещей писать софт не комфортно.
>мне не нравится в php это модель поведения CGI у динамических страниц
Не очень понятно о чем речь. Можно поподробнее?
>странный шаблонизатор
Это Вы о чем? РНР - плохой шаблонизатор? ;)
>отсутсвие абстракций СУБД
PDO?
>единое пространство имен
Использование класссов с методами static - решает эту проблему.
>безумная каша функций без какой либо на то системы
это проблема не языка, а архитектора системы
>медленная работа самого ООП
об этом я уже спрашивал - результаты тестов?
>не использование имеющегося в наличии механизма исключений стандартными функциями
"стандартных" функций в РНР не так много, и (на сколько я помню) они все используют исключения. Что касается расширений (extension), то их не правильно рассматривать как часть РНР. Вот они еще не все переписаны с учетом механизма исключений.
>еще неплохо бы увеличить скорость
эээ... мы о какой скорости сейчас говорим?
Не очень понятно о чем речь. Можно поподробнее?
>странный шаблонизатор
Это Вы о чем? РНР - плохой шаблонизатор? ;)
>отсутсвие абстракций СУБД
PDO?
>единое пространство имен
Использование класссов с методами static - решает эту проблему.
>безумная каша функций без какой либо на то системы
это проблема не языка, а архитектора системы
>медленная работа самого ООП
об этом я уже спрашивал - результаты тестов?
>не использование имеющегося в наличии механизма исключений стандартными функциями
"стандартных" функций в РНР не так много, и (на сколько я помню) они все используют исключения. Что касается расширений (extension), то их не правильно рассматривать как часть РНР. Вот они еще не все переписаны с учетом механизма исключений.
>еще неплохо бы увеличить скорость
эээ... мы о какой скорости сейчас говорим?
Не очень понятно о чем речь. Можно поподробнее?
Поясняю. CGI работает следующим образом. Запрос прошел запустился процесс обработал запрос умер. PHP работает именно по такой схеме.
Это Вы о чем? РНР - плохой шаблонизатор? ;)
А где там отделение логики приложения от вывода? Под PHP есть неплохие сторонние шаблонизаторы к примеру smarty. Но имеющийся по умолчанию шаблонизатор довольно странный.
PDO?
Скорее ADO ? Есть не везде и не всегда.
Использование класссов с методами static - решает эту проблему.
В нутри приложения да. А модули как делать тоже все оборачивать таким образом?
это проблема не языка, а архитектора системы
Я про стандартные функции. В приложении то понятно.
об этом я уже спрашивал - результаты тестов?
Это можете воспринимать как мое субъективное мнение. Так как то ПО которое было написано на PHP и использовало ООП обычно работало медленнее чем аналоги не использующие ООП.
"стандартных" функций в РНР не так много, и (на сколько я помню) они все используют исключения.
Где-то список стандартных функций есть ? Которые умеют генерировать исключения?
Что касается расширений (extension), то их не правильно рассматривать как часть РНР. Вот они еще не все переписаны с учетом механизма исключений.
Если они не являются частью PHP почему они входят в его пакет? Хотя это вопрос не к вам, а к разработчикам PHP
эээ... мы о какой скорости сейчас говорим?
Общая скорость работы PHP интерпретатора. Или это нормально, что скорость работы реализации на java в два раза быстрее чем нативного интерпретатора ? Вот эта реализация:
http://caucho.com/resin-3.1/doc/quercus.…
А где там отделение логики приложения от вывода? Под PHP есть неплохие сторонние шаблонизаторы к примеру smarty. Но имеющийся по умолчанию шаблонизатор довольно странный.
То, что там по умолчанию, я бы вообще шаблонизатором не назвал. Впрочем, это не проблема языка, а программистов. Хочется разделение юзайте MVC плюс сторониий шаблонизатор.
Или это нормально, что скорость работы реализации на java в два раза быстрее чем нативного интерпретатора ?А они код зазендили? С этим сравнивать надо было, на мой взгляд.
То, что там по умолчанию, я бы вообще шаблонизатором не назвал.
Ну оно же там есть :)
Впрочем, это не проблема языка, а программистов. Хочется разделение — юзайте MVC плюс сторониий шаблонизатор.
В таком случае в чем сокральный смысл направленности на веб у PHP? :)
А они код зазендили? С этим сравнивать надо было, на мой взгляд.
Без zend'а там провал еще больше :) На самом деле там не совсем интерпертатор. Там транслятор в java
>PHP работает именно по такой схеме.
Для абсолютного большинства веб-приложений это не является проблемой.
>А где там отделение логики приложения от вывода?
Мы все время натыкаемся на одно и тоже - все зависит от того как программист напишет проект, т.е. на человеческий фактор. Что нам мешает шаблон вывода вынести в отдельный php файл и там написать:
Далле инклюдим шаблон. Все остальное - варианции. Это что касается разделения логики и вывода. Что же за шаблонизатор "по умолчанию" для меня так и осталось загадкой.
>Скорее ADO
Чем не устраивает PDO? Ко всему есть такое количество различных реализаций абстракных уровней БД, что у программиста есть постине огромный выбор вариантов.
>А модули как делать тоже все оборачивать таким образом
Мы сейчас говорим об слишком абстрактных вариантах использования. В каждом конкретном случае нужно искать свое решение. Для внешних модулей я бы предпочел использовать свой собственный враппер.
>Это можете воспринимать как мое субъективное мнение
Скорее что так оно и есть :)
>Где-то список стандартных функций есть? Которые умеют генерировать исключения
Отдельный список не встречал.
>Если они не являются частью PHP почему они входят в его пакет
А почему нет? если лицензия позволяет.
>Общая скорость работы PHP интерпретатора
Посмотрел по диагонали, но кроме постоянного "fast, safe, and easy" не встретил ничего о тестировании. Но из общих соображений - такого не может быть в принципе.
Для абсолютного большинства веб-приложений это не является проблемой.
>А где там отделение логики приложения от вывода?
Мы все время натыкаемся на одно и тоже - все зависит от того как программист напишет проект, т.е. на человеческий фактор. Что нам мешает шаблон вывода вынести в отдельный php файл и там написать:
Далле инклюдим шаблон. Все остальное - варианции. Это что касается разделения логики и вывода. Что же за шаблонизатор "по умолчанию" для меня так и осталось загадкой.
>Скорее ADO
Чем не устраивает PDO? Ко всему есть такое количество различных реализаций абстракных уровней БД, что у программиста есть постине огромный выбор вариантов.
>А модули как делать тоже все оборачивать таким образом
Мы сейчас говорим об слишком абстрактных вариантах использования. В каждом конкретном случае нужно искать свое решение. Для внешних модулей я бы предпочел использовать свой собственный враппер.
>Это можете воспринимать как мое субъективное мнение
Скорее что так оно и есть :)
>Где-то список стандартных функций есть? Которые умеют генерировать исключения
Отдельный список не встречал.
>Если они не являются частью PHP почему они входят в его пакет
А почему нет? если лицензия позволяет.
>Общая скорость работы PHP интерпретатора
Посмотрел по диагонали, но кроме постоянного "fast, safe, and easy" не встретил ничего о тестировании. Но из общих соображений - такого не может быть в принципе.
Для абсолютного большинства веб-приложений это не является проблемой.
Но есть некоторое количество веб-приложений которым это требуется. К тому же постоянные соединения к СУБД там конечно работают, но почему-то не всегда.
Мы все время натыкаемся на одно и тоже - все зависит от того как программист напишет проект, т.е. на человеческий фактор.
Понимаете если уж язык назвался языком для веба, то он должен уметь такие вещи из коробки. Иначе в чем его приемущество между языком общего прикладного характера?
Что нам мешает шаблон вывода вынести в отдельный php файл и там написать:
Далле инклюдим шаблон. Все остальное - варианции. Это что касается разделения логики и вывода. Что же за шаблонизатор "по умолчанию" для меня так и осталось загадкой.
В PHP есть не сторонний а встроенный шаблонизатор. Крайне убогий. Поэтому им мало кто пользуется.
Чем не устраивает PDO? Ко всему есть такое количество различных реализаций абстракных уровней БД, что у программиста есть постине огромный выбор вариантов.
ADO PDO хотелось бы единообразия. Зачем мне большой выбор? Мне достаточно было бы интерфейса аля JDBC в java или DBI в Perl. Зачем иметь много разных реализаций абстракции и при этом не иметь стандартной?
Мы сейчас говорим об слишком абстрактных вариантах использования. В каждом конкретном случае нужно искать свое решение. Для внешних модулей я бы предпочел использовать свой собственный враппер.
Свои слои абстракции это конечно хорошо... но все должно иметь свой предел :) В PHP же частенько приходится брать или чужой велосипед или придумывать свой. Вот это мне неочень в нем нравится.
Скорее что так оно и есть :)
Я тестировал на одной и той же машине. Хотя вполне возможно это издержки большей вложенности кода у проектов на ООП.
Отдельный список не встречал.
Тогда каким образом узнать генерит или нет? Просто если их генерит 10% всех функций PHP то механизм при работе с функциями PHP бесполезен.
А почему нет? если лицензия позволяет.
Хотя бы потому, что потом их доставить довольно сложно. В этом ксати с моей точки зрения большая неудача PHP. Если бы был только определенный минимум заложен в ядро, а все остальные промочки писались на PHP возможно было бы лучше.
Посмотрел по диагонали, но кроме постоянного "fast, safe, and easy" не встретил ничего о тестировании. Но из общих соображений - такого не может быть в принципе.
Это не они тестировали, а пользователи. Там кстати тоже были вопросы, а вы с акселератором сравнивали? Им сказали нет, но щас воткнем. Проверили с акселератором APC получили разницу в два раза в сторону Resin с Quercus, без акселератора было в пять раз лучше. А почему не может быть в принципе? Там PHP преобразовывается в сервлет точно так же как JSP. Т.е. работает по сути уже откомпилированный и висящий в памяти сервлет, запуск копии которого минимальны. К тому же там на все приложения использующие СУБД не взирая используют они постоянные соединения или нет пропускаются через пулл соединений к СУБД. Так что учитывая скорость этого java сервера, я вполне этому верю.
Вот это жесть, а не комментарий :)
>Но есть некоторое количество веб-приложений которым это требуется
Так и пишите их не на РНР :) Я разве где-то утверждал, что РНР является панацеей от всех бед? ;) Язык позволяет решать очень широкий спектр задач и это прекрасно. Естестественно что у языка есть области, в которых его использование не реально. Я просто уверен, что Java имеет свои ограничения (не являясь спецом по Java - не могу назвать конкретных ограничений).
>К тому же постоянные соединения к СУБД там конечно работают, но почему-то не всегда.
Все зависит от настройек persistent connection в ини-файле, и имеют кучу потенциальных проблем.
>Понимаете если уж язык назвался языком для веба, то он должен уметь такие вещи из коробки.
Язык никому ничего не должен :) Да и идеалогия такова - нужен такой модуль - подключаешь (или собираешь с ним) - он у тебя есть. Не нужен, не включаешь. Коробки, как таковой нет. И это - хорошо, это одно из преимуществ. Еще одно - язык позволяет реализовать так, удобно разработчику. Удобно следовать MVC - следуй, нет - нет. Удобно писать в функциональном стиле - пиши. Веб-приложения предъявляют очень разные требования, к языку и преимущество РНР в том, что он может удовлетворить большинству требований.
>В PHP есть не сторонний а встроенный шаблонизатор
Очень хочется увидеть ссылку на этот чудо-шаблонизатор. А то за 8 лет так ни разу с ним не столкнулся :)
>ADO PDO хотелось бы единообразия
Хотите однообразия - напишите один раз (или возьмите сторонний) клаас, реализующий паттерн "фабрика", напишите (или воспользуйтест сторонними) врапперами для различных баз - получите универсальный инструмент работы с БД. Не нравится такой подход - пользуйтесь стандартным PDO. Язык не навязывает программисту решение, он предлагает ему инструмент - это еще один плюс.
>В PHP же частенько приходится брать или чужой велосипед или придумывать свой.
А есть какой-то другой, третий способ? Имхо, либо свой, либо чужей - больше вариантов нет :)
>Хотя вполне возможно это издержки большей вложенности кода у проектов на ООП.
Возможно сравнение только между двумя равноценными версиями кода. Условно говоря, сравнивать скорость выполнения вывода "Hello, World". Чем более мы усложняем код, тем больше различий станет между подходами и тем менее правдивы результаты. Т.е. тесты заранее не корректны. Можно лишь полагаться на заявления ведущих разработчиков языка о том, что скорость практически не различается.
>Тогда каким образом узнать генерит или нет?
Думаю только чтением мана. Чесно - не задавался целью. Пока по старинке обрабатываю.
>Хотя бы потому, что потом их доставить довольно сложно.
Под виндой - раскомментировать dll, в *nix - http://www.php.net/manual/en/install.pec…
>все остальные промочки писались на PHP возможно было бы лучше
Может и лучше, но согласитесь откомпилированный С работать будет на порядки быстрее, чем РНР-код.
>Это не они тестировали, а пользователи
Без результатов и описания тестов - все слова. Надо смотреть тесты, надо смотреть на сколько они синтетические.
Так и пишите их не на РНР :) Я разве где-то утверждал, что РНР является панацеей от всех бед? ;) Язык позволяет решать очень широкий спектр задач и это прекрасно. Естестественно что у языка есть области, в которых его использование не реально. Я просто уверен, что Java имеет свои ограничения (не являясь спецом по Java - не могу назвать конкретных ограничений).
>К тому же постоянные соединения к СУБД там конечно работают, но почему-то не всегда.
Все зависит от настройек persistent connection в ини-файле, и имеют кучу потенциальных проблем.
>Понимаете если уж язык назвался языком для веба, то он должен уметь такие вещи из коробки.
Язык никому ничего не должен :) Да и идеалогия такова - нужен такой модуль - подключаешь (или собираешь с ним) - он у тебя есть. Не нужен, не включаешь. Коробки, как таковой нет. И это - хорошо, это одно из преимуществ. Еще одно - язык позволяет реализовать так, удобно разработчику. Удобно следовать MVC - следуй, нет - нет. Удобно писать в функциональном стиле - пиши. Веб-приложения предъявляют очень разные требования, к языку и преимущество РНР в том, что он может удовлетворить большинству требований.
>В PHP есть не сторонний а встроенный шаблонизатор
Очень хочется увидеть ссылку на этот чудо-шаблонизатор. А то за 8 лет так ни разу с ним не столкнулся :)
>ADO PDO хотелось бы единообразия
Хотите однообразия - напишите один раз (или возьмите сторонний) клаас, реализующий паттерн "фабрика", напишите (или воспользуйтест сторонними) врапперами для различных баз - получите универсальный инструмент работы с БД. Не нравится такой подход - пользуйтесь стандартным PDO. Язык не навязывает программисту решение, он предлагает ему инструмент - это еще один плюс.
>В PHP же частенько приходится брать или чужой велосипед или придумывать свой.
А есть какой-то другой, третий способ? Имхо, либо свой, либо чужей - больше вариантов нет :)
>Хотя вполне возможно это издержки большей вложенности кода у проектов на ООП.
Возможно сравнение только между двумя равноценными версиями кода. Условно говоря, сравнивать скорость выполнения вывода "Hello, World". Чем более мы усложняем код, тем больше различий станет между подходами и тем менее правдивы результаты. Т.е. тесты заранее не корректны. Можно лишь полагаться на заявления ведущих разработчиков языка о том, что скорость практически не различается.
>Тогда каким образом узнать генерит или нет?
Думаю только чтением мана. Чесно - не задавался целью. Пока по старинке обрабатываю.
>Хотя бы потому, что потом их доставить довольно сложно.
Под виндой - раскомментировать dll, в *nix - http://www.php.net/manual/en/install.pec…
>все остальные промочки писались на PHP возможно было бы лучше
Может и лучше, но согласитесь откомпилированный С работать будет на порядки быстрее, чем РНР-код.
>Это не они тестировали, а пользователи
Без результатов и описания тестов - все слова. Надо смотреть тесты, надо смотреть на сколько они синтетические.
Так и пишите их не на РНР :) Я разве где-то утверждал, что РНР является панацеей от всех бед? ;) Язык позволяет решать очень широкий спектр задач и это прекрасно. Естестественно что у языка есть области, в которых его использование не реально. Я просто уверен, что Java имеет свои ограничения (не являясь спецом по Java - не могу назвать конкретных ограничений).
Я пишу на нем, но только мелкие шутчки :) Если еще шаблонизатор smarty подцепить, то становится несколько удобнее. Жаль конечно, что вместо того стандартного шаблонизатора, по умолчанию нет именно smarty. У java да есть свои ограничения. Они касаются памяти. Java любит память поэтому мелкие финтифлюшки писать на ней не очень целесообразно.
Все зависит от настройек persistent connection в ини-файле, и имеют кучу потенциальных проблем.
Вот как-то хочется чтоб оно работало. Просто работало.
Язык никому ничего не должен :) Да и идеалогия такова - нужен такой модуль - подключаешь (или собираешь с ним) - он у тебя есть. Не нужен, не включаешь. Коробки, как таковой нет. И это - хорошо, это одно из преимуществ.
Это хорошо если не требует перекомпиляции. Хотя конечно можно использовать PEAR.
Еще одно - язык позволяет реализовать так, удобно разработчику. Удобно следовать MVC - следуй, нет - нет. Удобно писать в функциональном стиле - пиши. Веб-приложения предъявляют очень разные требования, к языку и преимущество РНР в том, что он может удовлетворить большинству требований.
Удволетворять то удволетворяет, только вот структруры у него стройной нет. А так все ничего. К примеру хотелось бы определения что является core функциями языка, а что дополнениями. А то как-то там все в куче и существует куча реализаций одного и того же.
Очень хочется увидеть ссылку на этот чудо-шаблонизатор. А то за 8 лет так ни разу с ним не столкнулся :)
http://www.codenet.ru/webmast/php/Templa…
Хотите однообразия - напишите один раз (или возьмите сторонний) клаас, реализующий паттерн "фабрика", напишите (или воспользуйтест сторонними) врапперами для различных баз - получите универсальный инструмент работы с БД. Не нравится такой подход - пользуйтесь стандартным PDO. Язык не навязывает программисту решение, он предлагает ему инструмент - это еще один плюс.
Мне хотелось бы одной хорошей библиотеки работы с СУБД. А то получается, что приходится делать дополнительные телодвижения. К тому же наличие такого количества библиотек на самым лучшим образом влиет на их качество.
А есть какой-то другой, третий способ? Имхо, либо свой, либо чужей - больше вариантов нет :)
Есть. :) Велосипед от разработчиков языка :) Хочу стандартный велосипед от производителей.
Можно лишь полагаться на заявления ведущих разработчиков языка о том, что скорость практически не различается.
Ну к тому же обычно кода на ООП несколько больше чем в поцедурном виде. Хотя это уже завистит от самого кодера и того как было спроектировано.
Думаю только чтением мана. Чесно - не задавался целью. Пока по старинке обрабатываю.
По этому собственно большая часть им если и пользуется, то только в своих приложениях. Нет у PHP стройности архитектуры.
Под виндой - раскомментировать dll, в *nix - http://www.php.net/manual/en/install.pec…
>все остальные промочки писались на PHP возможно было бы лучше
Может и лучше, но согласитесь откомпилированный С работать будет на порядки быстрее, чем РНР-код.
Во первых не везде есть возможность это сделать. К примеру на хостинге этого вам сделать никто не даст. к тому же хотя такой подход дает хорошие результаты по скорости он потенциально опаснее, чем код внутри интерпретатора. А у PHP и так не все шоколадно с безопасностью.
Без результатов и описания тестов - все слова. Надо смотреть тесты, надо смотреть на сколько они синтетические.
Были были там таблички. Только вот они видимо у себя Quercus меняют и из-за этого форум не доступен. 20 числа должон заработать. Тесты там проводили насколько помню запросом страницы у drupal. И меряли кто сколько отдает. Правда если уж быть честным, то сравнивать реализацию jsp/servlets с apache/mod_php не совсем корректно. Скорее надо сравнивать с FastCGI. Из-за этого как мне кажется и возникает выигрыш.
Ну и подведу итог что мне не нравится в PHP. Хотя язык по заявлениям авторов пишется специально для веба, но реально никаких существенных приемуществ по сравнению с каким либо прикладным языком + CGI нет. Если сравнивать прикладной язык + web-framework с PHP то... :) хотя конечно не совсем корректно это сравнивать. Не обладает стройной арихтектурой в результате мешанина функций больше всего напоминает мне тарелку с макаронами :) Из-за этого приходится брать чей нибудь велосипед, а хочется страндартный. Собственно если подумать к PHP у меня одна претензия отсутствие стройной модели. В результате чего при работе с ним приходится с этим бороться. И это раздражает.
>Вот как-то хочется чтоб оно работало
Тут скорее не к языку претензии, а к той же муське.
>http://www.codenet.ru/webmast
Ну это сложно назвать "встроеным" шаблонизатором :))) Сам по себе РНР, в таком случае, и является "встроенным" шаблонизатором.
>Мне хотелось бы одной хорошей библиотеки работы с СУБД
А она есть - та, что Вы сами для себя выберите. :) Одной из сильных сторон РНР является то, что он ни к чему не принуждает, позволяет делать так, как удобно разработчику. Один раз написав свое (если чужое не подошло), и пользуйтесь во всех проектах. Лично я так и сделал. Если хочется стандартов - используйте PDO от разработчиков.
>Нет у PHP стройности архитектуры
Разруха не в клозетах, а в головах :) То, что язык предъявляет не высокие требования к разработчику - в определенных моментах является минусом. Но если язык будет очень строг, не спасет от не понимания разработчиком зачем сделано именно так, а не иначе. Встречаются индивидуумы, которые 5 лет пишут на дельфях и ни разу за это время не видели реального кода. Программисты, пишущие мышкой, блин.
>Во первых не везде есть возможность это сделать.
Согласен. С другой стороны - на хостингах стоит достаточно большой пакет, для большинства приложений его хватает за глаза. Для специфичных приложений - все равно без собственного сервера (а то и не одного) делать нечего.
>Собственно если подумать к PHP у меня одна претензия отсутствие стройной модели.
Есть достаточное количество фреймворков под РНР, у большинства имеется достаточно стройная модель - используйте их :) Нужно просто принять тот факт, что разработчик является центральной фигурой, он определяет то, как ему удобно работать. Разработчики языка - не навязывают решения. И мне например, как раз нравится.
Тут скорее не к языку претензии, а к той же муське.
>http://www.codenet.ru/webmast
Ну это сложно назвать "встроеным" шаблонизатором :))) Сам по себе РНР, в таком случае, и является "встроенным" шаблонизатором.
>Мне хотелось бы одной хорошей библиотеки работы с СУБД
А она есть - та, что Вы сами для себя выберите. :) Одной из сильных сторон РНР является то, что он ни к чему не принуждает, позволяет делать так, как удобно разработчику. Один раз написав свое (если чужое не подошло), и пользуйтесь во всех проектах. Лично я так и сделал. Если хочется стандартов - используйте PDO от разработчиков.
>Нет у PHP стройности архитектуры
Разруха не в клозетах, а в головах :) То, что язык предъявляет не высокие требования к разработчику - в определенных моментах является минусом. Но если язык будет очень строг, не спасет от не понимания разработчиком зачем сделано именно так, а не иначе. Встречаются индивидуумы, которые 5 лет пишут на дельфях и ни разу за это время не видели реального кода. Программисты, пишущие мышкой, блин.
>Во первых не везде есть возможность это сделать.
Согласен. С другой стороны - на хостингах стоит достаточно большой пакет, для большинства приложений его хватает за глаза. Для специфичных приложений - все равно без собственного сервера (а то и не одного) делать нечего.
>Собственно если подумать к PHP у меня одна претензия отсутствие стройной модели.
Есть достаточное количество фреймворков под РНР, у большинства имеется достаточно стройная модель - используйте их :) Нужно просто принять тот факт, что разработчик является центральной фигурой, он определяет то, как ему удобно работать. Разработчики языка - не навязывают решения. И мне например, как раз нравится.
Тут скорее не к языку претензии, а к той же муське.
Проблемы реализации, что тут попишешь.
Ну это сложно назвать "встроеным" шаблонизатором :))) Сам по себе РНР, в таком случае, и является "встроенным" шаблонизатором.
Ну они его позиционируют именно так :) Для отделения вида от кода. Хотя конечно бред редкостный :)
А она есть - та, что Вы сами для себя выберите. :) Одной из сильных сторон РНР является то, что он ни к чему не принуждает, позволяет делать так, как удобно разработчику. Один раз написав свое (если чужое не подошло), и пользуйтесь во всех проектах. Лично я так и сделал. Если хочется стандартов - используйте PDO от разработчиков.
Если бы еще дистрибутив PHP при этом из себя представлял только ядро без всяких сторонних мулечек, а затем уже производилось навешивание этих мулечек было бы гараздо удобнее... хотя мячты мячты :)
Разруха не в клозетах, а в головах :) То, что язык предъявляет не высокие требования к разработчику - в определенных моментах является минусом.
Я хочу только большей стройности функций. А то там сильно каша. Чем это может быть полезно разработчику с невысоким уровнем я честно говоря ума не приложу.
Но если язык будет очень строг, не спасет от не понимания разработчиком зачем сделано именно так, а не иначе.
Ага в свое время именно по этому я в универе ушел с Pascal на C. И сам его изучал (у нашего курса почему-то этот предмет из программы вынули).
Встречаются индивидуумы, которые 5 лет пишут на дельфях и ни разу за это время не видели реального кода. Программисты, пишущие мышкой, блин.
Видел таких :) Со мной такие личности тоже учились :) Хотя конечно лабы на дельфе делать милое дело :) Мышкой навозюкал и показал :)
Есть достаточное количество фреймворков под РНР, у большинства имеется достаточно стройная модель - используйте их :) Нужно просто принять тот факт, что разработчик является центральной фигурой, он определяет то, как ему удобно работать. Разработчики языка - не навязывают решения. И мне например, как раз нравится.
Использования фреймворка из-за отсутствия стройности модели это тоже самое что вместо лечения перелома давать большому костыль :) А разработчики языка такое ощущение не имеют четкой позиции о том что должно быть в PHP и как должно быть в PHP. В результате получаем кашу вместо стройной модели.
кончай гнать. супер оопэшник. офигенные и супер удобные класссы в пятом php. dixi.
Если вам так кажется это ваши проблемы.
ваши, однозначно. )
Я мало пишу на PHP, а если и пишу то обычно использую ООП. Но от этого оно удобнее чем в Java или в C++ не становится. А ваши безосновательные выпады довольно странны. Вы не истина в последней инстанции.
ну а вы мля - истина!
Я высказвал свое мнение. Мир что уже делится на черное и белое? Я вообще не понимаю чем спровоцированна ваша агрессия.
агрессия у меня возникает когда я вижу заядлых Сишников пытающихся обосрать все другие модели классов по причине того что они не так наворочены.
а о том что большая часть тех возможностей что реализованы в языке, предназначенном для построения системных приложений, вообще не нужны в интерпретируемом языке для формирования гипертекста они думать не хотят.
а о том что большая часть тех возможностей что реализованы в языке, предназначенном для построения системных приложений, вообще не нужны в интерпретируемом языке для формирования гипертекста они думать не хотят.
агрессия у меня возникает когда я вижу заядлых Сишников пытающихся обосрать все другие модели классов по причине того что они не так наворочены.
Завязывайте нести бред в конце концов. Я приводил четкие примеры того что лично мне не нравится в PHP и как было бы лучше с моей точки зрения. И мне приводили четкие контрпримеры. Если у вас нет возможности говорить конструктивно лучше молчите.
а о том что большая часть тех возможностей что реализованы в языке, предназначенном для построения системных приложений, вообще не нужны в интерпретируемом языке для формирования гипертекста они думать не хотят.
Извинте меня, но каких таких возможностей которые предназначены для построения системных приложений? Факты в студию. К тому же PHP не только формирует гипертекст. Он еще отвечает за логику приложения. PHP не является шаблонизатором, он является языком программирования.
Я писал и на том и на том и могу сказать что такого бредового ООП я больше нигде не видел.
вот это меня злит. и злит реально. и человек который пишет такое в контексте PHP vs C++ (!!!) - реально просто дурак.
ООП там бредовое. Бредовое с моей точки зрения тем как там выполнена перегрузка методов (непонятно зачем было городить эту конструкцию) и тем что нельзя перегружать конструкторы. К тому же еще все переменные класса публично доступны. Для меня это менее удобно. К тому же вам стоило почитать дальнейшую дискуссию с long.
и я с облегчением воспринял удобные классы в php5, хотя долгое время тоже писал на c++....
просто не надо быть снобом. и отметать все что упрощает разработку и чтение кода.
просто не надо быть снобом. и отметать все что упрощает разработку и чтение кода.
и я с облегчением воспринял удобные классы в php5, хотя долгое время тоже писал на c++...
Можно конкретный пример чем классы в php5 удобнее чем в C++?
И еще. Можете процитировать, где я говорил я отметал использование ООП в PHP?
удобны тем что нет ничего лишнего (хотя может быть конечно коечего пока нехватает)... раз.
удобны обратной связью - возможностью прямо внутри кода отследить имена класса его предков, методов и методов его предка а так же полей... и т.д. и т.п.
удобны обратной связью - возможностью прямо внутри кода отследить имена класса его предков, методов и методов его предка а так же полей... и т.д. и т.п.
удобны тем что нет ничего лишнего (хотя может быть конечно коечего пока нехватает)... раз.
А что лишнего в реализации классов C++ к примеру?
удобны обратной связью - возможностью прямо внутри кода отследить имена класса его предков, методов и методов его предка а так же полей... и т.д. и т.п.
А зачем? Вот определение типа переданного объекта я еще могу понять, хотя там тоже не надо при использовании интерфейсного класса.
а затем, дорогой друг, что это иногда просто СМЕРТЬ как удобно.
sapienti sat.
sapienti sat.
Если для вас это смерть как удобно и вообще требуется, то это значит, что у вас что-то спроектировано не так :)
это же возможность а не необходимость... неужели не чувствуется разницы?
Чуствую. Может преведете пример где это полезно?
В PHP ООП это скорее костыль для проповедников ООП, а в Java это идеология, при том красивая. Я бы не стал ставить равенство между ООП Java и ООП PHP.
Я равенства не ставлю, я говорю, что разработчики PHP хотя-бы движутся в этом направлении, пытаются что-то улучшить, и это у них в пятой версии получается. Что не может не радовать, т.к. ООП PHP4 действительно страшный
У меня есть нездоровое ощущение что они никуда не движутся. PHP это как та телега в которую впряглись щука рак и лебедь. Особенно это заметно в плане безопасности. Извините но когда программист который занимается безопасностью PHP выходит из проекта из-за того что его патчи не вводятся в основное дерево это вызывает не сильно положительные эмоции.
вы имеете ввиду человека, который _кричал_ на каждом углу что он занимается безопастностью, и при этом не запостил ни одного патча? ;)
http://www.habrahabr.ru/blog/webdev/2547… после этого внимательно смотрим http://www.hardened-php.net/contact.10.h…
нет я имею в виду человека который этими патчами занимался.
а я имею ввиду, что да - в PHP есть проблемы с безопасностью, которые фиксят очень медленно или не фиксят вообще.
рекомендую к прочтению http://www.habrahabr.ru/blog/webdev/2547…
мы говорим об одном и том же человеке.
мы говорим об одном и том же человеке.
Я не буду спорить с тем насколько тот человек вменяем в общении, т.к. я его не знаю. Я говорю про то, что проблемы в принципе есть. Т.е. нашлось что заткнуть этим патчем (www.hardened-php.net который).
Например, стримы в PHP нельзя использовать много раз с разными контекстами, т.к. ОЗУ занимаемое пхп вырастет. Тот же самый tony2001@php.net фиксить это отказался, мотивируя тем что "так и должно быть". Ну я не знаю нормально ли, если скрипт работающий с 30кб данных за несколько часов жрет 1ГБ памяти и в самом PHP нет никакого механизма ее высвободить.
Так что давайте не будем рассуждать о «вменяемости» [бывших] программистов PHP.
Например, стримы в PHP нельзя использовать много раз с разными контекстами, т.к. ОЗУ занимаемое пхп вырастет. Тот же самый tony2001@php.net фиксить это отказался, мотивируя тем что "так и должно быть". Ну я не знаю нормально ли, если скрипт работающий с 30кб данных за несколько часов жрет 1ГБ памяти и в самом PHP нет никакого механизма ее высвободить.
Так что давайте не будем рассуждать о «вменяемости» [бывших] программистов PHP.
Давайте наконец научимся приводить факты. Для всего остального есть газеты типа "Жизнь".
не видел ни одного не кривого приложения написанного в рамках этой суперидеологии (когда вещественное к целому надо привести через дебри объектов!) - в основном это клиентбанки - и госсподи какие же они корявые!!! ))
вот вам пример http://npj.ru
Писать хорошо на Java сложнее, и требует больше опыта, чем писать хорошо на PHP... То что писали криво, не значит что платформа плохая... Меня всегда восхищала IntelliJ Idea написанная на Java... Использовал её ещё в 2001, когда при своем супер-функционале, она у меня не тормозила на P3-800 с 256М памяти...
PHP - это исключительно структурный язык. И это однозначно так. Тот факт что в пятой версии слепили хромой объектно-ориентированный механизм не говорит ни очем.
Да кстати хоть в С++ и необязательно пользоваться ООП-аппаратом, но он всеже более ООП чем PHP5, хотябы потому что есть набор основных объектов.
А вообще говоря PHP - это зло. Я сам сейчас на нем пишу..... так вот чтобы не потерять квалификацию приходится иногда усаживаться и делать что-то на С.
Да кстати хоть в С++ и необязательно пользоваться ООП-аппаратом, но он всеже более ООП чем PHP5, хотябы потому что есть набор основных объектов.
А вообще говоря PHP - это зло. Я сам сейчас на нем пишу..... так вот чтобы не потерять квалификацию приходится иногда усаживаться и делать что-то на С.
ООП само по себе не может упростить проект. Можно писать в функциональном стиле и проект будет стройный и понятный, а можно накрутить объеты так, что самая продвинутая документация не поможет разобраться. Т.е. мы в очередной раз приходим к тому, что не ООП, а мозги и руки программиста определяет степень кривости проекта. И уж точно не язык разработки.
ООП в первую очередь инструмент который облегчает и способствует написанию стройного кода. Поддерживать стройность и порядок в процедурной парадигме сложнее. К тому же она этому не способствует.
А не надо сравнивать ЯЗЫК с ФРЕЙМВОРКОМ.
Либо PHP vs Ruby, либо RoR vs Symfony (PRADO, CakePHP, CodeIgniter и так далее).
Либо PHP vs Ruby, либо RoR vs Symfony (PRADO, CakePHP, CodeIgniter и так далее).
естественно сравнений полно, но подобной -> по делу и конкретно - я раньше не видел
ИМХО:
Гибкость языка конечно сумасшедшая, воспроизводит должное впечатление, но потом приходит мысль о востребованости всех этих наворотов, да и интерпретатор работает медленнее, чем PHP.
Вот это как по мне вообще изврат:
Гибкость языка конечно сумасшедшая, воспроизводит должное впечатление, но потом приходит мысль о востребованости всех этих наворотов, да и интерпретатор работает медленнее, чем PHP.
Вот это как по мне вообще изврат:
Переменные указывают на объект
Фокус-покус:
nogpyra = "Даша"
k_HAM_B_rocTu_ugeT = nogpyra
puts nogpyra #-> "Даша", разумеется
k_HAM_B_rocTu_ugeT[0] = "М" # меняем первую (номер ноль) букву у переменной-строки
puts nogpyra #-> "Маша"
Синтаксис не из самых приятных, но возможно мне так только по началу показалось.
Кое-что навеяно из C#,
Мне он кажется каким-то слишком усложненным, вот даже не знаю, к добру ли оргомное кол-во разнообразных синтаксических конструкций.
А в противовес гибкости языка наверно можно поставить то, что при таких богатых возможностях синтаксиса не всегда интуитивно представляешь, как поведет себя та или иная языковая конструкция.
Очень хочется, чтобы кто-нибуть создал опрос на тему "Ruby & PHP".
Лично мне больше импонирует старикашка PHP, но я стараюсь быть обьективным.
Как говорил когда-то один очень хороший преподаватель: "Я абсолютно обьективный человек. Кому что захочу то и поставлю" :)
Ruby конкурент не PHP, а скорее перлу.
А главное, ему сто лет в обед, и сравнениям тоже.
А главное, ему сто лет в обед, и сравнениям тоже.
Давайте ещё, граждане, не забывать о Python, гораздо менее сумасшедшем. Из которого, собственно, Ruby и мутировал (не хочется говорить "родился").
А вообще тем, кто не имеет проблем с хостингом, посоветовал бы рассмотреть старые добрые JSP с каким-нибудь правильным фреймворком.
А вообще тем, кто не имеет проблем с хостингом, посоветовал бы рассмотреть старые добрые JSP с каким-нибудь правильным фреймворком.
С перлом родства значительно больше. А насчёт JSP... что ж вы так людей-то не любите :)
Servlet Faces? :)
Интересно, из каких источников вы узнали о том, что руби мутировал из питона ?
Они ровесники, сам Матз ничего не писал о питоне никогда - только о перл и , учитывая меньшую открытость японского коммьюнити, не вижу у этом ничего удивительного.
Почему-то как раз первая волна миграции на рельсы была именно из стана явщиков. Да и большую часть книжек по рельсам пишут бывшие явщики.
Они ровесники, сам Матз ничего не писал о питоне никогда - только о перл и , учитывая меньшую открытость японского коммьюнити, не вижу у этом ничего удивительного.
Почему-то как раз первая волна миграции на рельсы была именно из стана явщиков. Да и большую часть книжек по рельсам пишут бывшие явщики.
Ну, может быть, и не в первую очередь из Питона, согласен, но очень сильное влияние заметно.
Wikipedia:
Ruby is influenced by Python. Specifically, matz wished to have a language closer to the classical message passing object-oriented model than Python. [An Interview with the Creator of Ruby]
Wikipedia:
Ruby is influenced by Python. Specifically, matz wished to have a language closer to the classical message passing object-oriented model than Python. [An Interview with the Creator of Ruby]
Ага. Только о том, что связи с питоном пишут другие, а сам Матз обычно говорит что-то типа
Stewart: How about Python? What aspects of that language did you try to reuse in Ruby?
Matz: Far less than Perl. But I stole a few things, like exception names.
few things - не катит в качестве мутировал из питона.
Stewart: How about Python? What aspects of that language did you try to reuse in Ruby?
Matz: Far less than Perl. But I stole a few things, like exception names.
few things - не катит в качестве мутировал из питона.
Руби мутировал из Перла.
Об этом пишет википедиа.
Об этом пишет википедиа.
Улыбнуло http://phponrails.ru/
Я не буду ничего говорить о функциональности фреймворка, не углублялся в детали,
но выехать на имени Ror весьма неплохой маркетинговый ход :)
Я не буду ничего говорить о функциональности фреймворка, не углублялся в детали,
но выехать на имени Ror весьма неплохой маркетинговый ход :)
:) Рельсы на слуху вот выезжают :)
http://www.symfony-project.com/ - пхп-клон рейзлов.
Есть ещё Code gniter
http://www.codeigniter.com/
http://www.codeigniter.com/
Симфони рулит как минимум документацией, кодегнитер меня стошнил :)
+1 тебе, linker
Хотел написать статью про Symfony, когда релиз1 выйдет. Кто-нибуть читать будет?
Хотел написать статью про Symfony, когда релиз1 выйдет. Кто-нибуть читать будет?
«Пишите, мы оценим.»
Будет. Симфони - идеальный выбор для людей, которые хотят заняться более высокоуровневой и быстрой веб-разработкой, но не хотят переходить c PHP на другой язык (Ruby или Python).
Я вот пока не вижу в этом для себя смысла :) PHP5 стоит почти на любом хостинге, я его уже знаю, и, что немаловажно, код на PHP гораздо понятнее кода на Ruby. При этом Symfony, как мне кажется, мало чем не уступает RoR по возможностям. От добра добра не ищут.
P.S. Если уж переходить, то на Питон - имхо, он гораздо больше подходит для серьезного программирования в силу своей ясности и однозначности. Django и Zope есть, опять же.
Я вот пока не вижу в этом для себя смысла :) PHP5 стоит почти на любом хостинге, я его уже знаю, и, что немаловажно, код на PHP гораздо понятнее кода на Ruby. При этом Symfony, как мне кажется, мало чем не уступает RoR по возможностям. От добра добра не ищут.
P.S. Если уж переходить, то на Питон - имхо, он гораздо больше подходит для серьезного программирования в силу своей ясности и однозначности. Django и Zope есть, опять же.
Статьи про Симфони на русском уже давно надо писать)
Да ладно Вам, у CI очень хорошая документация, в смысле, на удивление понятная.
Сравнивать фреймворк с языком, конечно, не корректно... но всем так хочется:). Мои два цента:
Написаны на ПХП:
blo.gs (PHP)
Flickr (PHP)
del.icio.us (mod_perl)
Digg (PHP)
Technorati (PHP)
Wikipedia (PHP)
Почти ВСЕ более-менее достойные приложения на ROR написаны самими назработчиками ROR - 37signals.
Делайте выводы...
Написаны на ПХП:
blo.gs (PHP)
Flickr (PHP)
del.icio.us (mod_perl)
Digg (PHP)
Technorati (PHP)
Wikipedia (PHP)
Почти ВСЕ более-менее достойные приложения на ROR написаны самими назработчиками ROR - 37signals.
Делайте выводы...
И конечно же - ЖЖ, на перле.
В копилку: sourceforge.net (php)
О больших приложениях на Rails вы не услышите еще пару лет... Просто потому что ресурсы такого масштаба, как перечисленные вам, создаются по нескольку лет. Причина не в том, что невозможно написать движок мега-ресурс за несколько месяцев, а в том, что раскрутка требует времени.
Так что большие системы на Rails уже вовсю создаются и раскручиваются, просто их еще, по причине молодости, не заметно.
Так что большие системы на Rails уже вовсю создаются и раскручиваются, просто их еще, по причине молодости, не заметно.
А что мешала сделать большой проект на ROR год назад? Вы так говорите, как будто ROR недавно родился, а ведь ему уже 3 год пошёл
Возможно, его меньшая популярность в те годы…
Читаем http://www.php.net/manual/ru/history.php:
> Официально PHP/FI 2.0 вышел только в ноябре 1997 года, после проведения большей части своей жизни в бета-версиях. Вскоре после выхода его заменили альфа-версии PHP 3.0.
> PHP 3.0 был официально выпущен в июне 1998 года после 9 месяцев публичного тестирования.
Скажите, много ли было в 2000-м году (1997 + 3 года) крупных и известных ресурсов, написанных на PHP? Мне что-то все C++/CGI вспоминается...
> Официально PHP/FI 2.0 вышел только в ноябре 1997 года, после проведения большей части своей жизни в бета-версиях. Вскоре после выхода его заменили альфа-версии PHP 3.0.
> PHP 3.0 был официально выпущен в июне 1998 года после 9 месяцев публичного тестирования.
Скажите, много ли было в 2000-м году (1997 + 3 года) крупных и известных ресурсов, написанных на PHP? Мне что-то все C++/CGI вспоминается...
а на сколько увеличилось количество крупных проектов по сравнению с 2000 годом?
В России - значительно. В мире не так сильно как вы думаете.
Количество людей в отрасли почти не изменилось (падение после кризиса доткомов скомпенсировано последующим ростом), некоторое повышение продуктивность отдельного программиста съедено повышением сложности типичного "сложного" проекта. С чего бы в этих условиях увеличиваться числу крупных проектов?
Количество людей в отрасли почти не изменилось (падение после кризиса доткомов скомпенсировано последующим ростом), некоторое повышение продуктивность отдельного программиста съедено повышением сложности типичного "сложного" проекта. С чего бы в этих условиях увеличиваться числу крупных проектов?
Т.е. Вы считаете, что за 7 лет не накопилось критической массы проектов, которые могли бы быть переписаны на ROR?
А зачем их переписывать? Они и так работают :)
о! и это очень важно. потому что если бы ROR был бы на столько крут, что давал бы выигрышь по сравнению с уже существующими технологиями, проект был бы перевед на Ruby.
Вы понимаете разницу между "переписать успешный проект на платформе X" и "написать новый проект на платформе X"?
вполне. но если перенос на новую платформу даст возможность развивать сервис раз в 10 быстрее (где-то я видел фразу о том, что "я потратил на разработку 1 неделю, вместо 3х месяцев), то гораздо эффективнее в паралель пустить вторую группу разработчиков, которая перепишит проект (допустим проекту год - она перепишет его за полтора месяца).
Дабы ни у кого не возникло не понимания. выше, в этом сообщении был сарказм. имхо, очевидно, что выгоды, которые якобы сулит переход на ROR, далеко не так заметны.
Дабы ни у кого не возникло не понимания. выше, в этом сообщении был сарказм. имхо, очевидно, что выгоды, которые якобы сулит переход на ROR, далеко не так заметны.
да когда же он наконец сдохнет, этот PHP.. вместе с классическим CGI впридачу..
Производительность RoR настолько ниже того же PHP (да, не совсем корректно сравнивать фреймворк с языком, но из этого ведь и исходили), что боюсь ничего действительно серьёзного мы не увидим до появления нормального компилятора Ruby.
На больших приложениях Rails очень неудобен. Он годится для пртотипа, годится для работающего проекта без большой нагрузки. Но КПД, в смысле, процессорное время и память, требуемые на генерацию одной страницы, хуже в несколько раз чем тот же PHP, не говоря о питоне или джаве.
И чтобы не говорили любители сказать, что процессоры сейчас дешевы и лучше не скупиться на мощность, а экономить на времени разработки, для больших проектов это становится неверно.
И чтобы не говорили любители сказать, что процессоры сейчас дешевы и лучше не скупиться на мощность, а экономить на времени разработки, для больших проектов это становится неверно.
а народ-то ленив, причем весьма... :) вполне вероятно по-этому и нет особого движения по разработанным на Ruby проектам...
А между прочим спрос бешенно растет...
А между прочим спрос бешенно растет...
Очень правильно сравнивать php и ррельсы, потому как и на том и на другом пишут инет проекты..
по поводу скорости работы компилятора... ну ну.. сделайте php приложениы например на каке пхп и вот уже нет бывалой прыткости у пхп. а в рельсах есть уже столько всего.. сколько во многих других фреймворках ещё долго не будет.
по поводу о рельсах больше говорят.. в рунете это очень точно, потогму что у всех на работе сроки и не всё начальство хочет что то новое.. я вот сейчас перехожу на рельсы и скорее всё буду делать на рельсах, потому как любая вещь делается раза в два быстрее, я уже молчу у плагинах (тэги, комментрарии, аплод - ресайза -автоматмческое создание любого колва тумбнейлов) и все эти плагины не просто так а сразу привязываешь к нужным объектам. в итоге цмс котор я на пхп писал 3и мес на рельсах получилась за пару недель, это при том что основное время ищешь решение а не выдумываешь своё.
Что касается аякса и прочего.. это уже в фреймворки автокомплит всего 5 строчек... ни какого js писать не надо. продолжать можно до бесконечности.
но очень трудно после пыха начать думать на руби.. потому как очень многие вещи подсознательно начинаешь делать через...
а ещё рельсовое приложение не запускается каждый раз а всё время работает и всё время держит коннект с базой, это тож экономит время.
Ну и самая главная проблемма.. поищите хостинг в рунете.. bhost.ru и www.net.ru ... выбор поражает(
всем советую изучать рельсы, через пару лет потребуется много программеров и зп думаю будет не как у пхп кодеров а скорее ближе к явовским.
по поводу скорости работы компилятора... ну ну.. сделайте php приложениы например на каке пхп и вот уже нет бывалой прыткости у пхп. а в рельсах есть уже столько всего.. сколько во многих других фреймворках ещё долго не будет.
по поводу о рельсах больше говорят.. в рунете это очень точно, потогму что у всех на работе сроки и не всё начальство хочет что то новое.. я вот сейчас перехожу на рельсы и скорее всё буду делать на рельсах, потому как любая вещь делается раза в два быстрее, я уже молчу у плагинах (тэги, комментрарии, аплод - ресайза -автоматмческое создание любого колва тумбнейлов) и все эти плагины не просто так а сразу привязываешь к нужным объектам. в итоге цмс котор я на пхп писал 3и мес на рельсах получилась за пару недель, это при том что основное время ищешь решение а не выдумываешь своё.
Что касается аякса и прочего.. это уже в фреймворки автокомплит всего 5 строчек... ни какого js писать не надо. продолжать можно до бесконечности.
но очень трудно после пыха начать думать на руби.. потому как очень многие вещи подсознательно начинаешь делать через...
а ещё рельсовое приложение не запускается каждый раз а всё время работает и всё время держит коннект с базой, это тож экономит время.
Ну и самая главная проблемма.. поищите хостинг в рунете.. bhost.ru и www.net.ru ... выбор поражает(
всем советую изучать рельсы, через пару лет потребуется много программеров и зп думаю будет не как у пхп кодеров а скорее ближе к явовским.
самое интересно, что сейчас в Беларуси наблюдается тенденция перехода Java программистов (среднего уровня) на Ruby...
сорри не дописал в предыдущем посте - и думаю, что такая ситуация не только в Беларуси
На ROR можно писать только простые вещи, типа всяких там не нагруженных CMSок 90% работы которых - есть примитивный CRUD. Как только начинается работа посерьезней, ROR оказывается в тех местах где никто не хочет оказаться - проблемы с балансировкойи нагрузки, масштабируемостью, "продвинутым" использованием БД и т.д. и т.п.
Понятно, что для обльшинства проектов эти проблемы не актуальны:) Юзайте ROR! Никто не отговаривает.
Понятно, что для обльшинства проектов эти проблемы не актуальны:) Юзайте ROR! Никто не отговаривает.
Я так понимаю вы как раз из тех, кто писал на РОР, напоролся на вышеуказанные ограничения, глубоко разобрался и понял что в нем есть системные ошибки не позволяющие их обойти ? Или так просто пишете?
Мне кажется проекты 37 сигналов трудно назвать уж совсем ненагруженными CMSками
Мне кажется проекты 37 сигналов трудно назвать уж совсем ненагруженными CMSками
У нас РОР в продакшн не пошел, слава богу - напарываться на ограничения масштабируемости (например) слишком дорогое удовольствие.
Вы располагаете какими-то данными о размерах аудитории проектов 37 сигналов?
Вы располагаете какими-то данными о размерах аудитории проектов 37 сигналов?
ну инсайдерской информации у меня нет,конечно, но осенью они, насколько я помню, говорили, что у бейскампа база переросла 1 миллион пользователей.
Не знаю сколько там реально активных и т.п., но сдается мне, что у большей части народа, что так трогательно волнуется о немасштабируемости рельс количество пользователей поменьше.
Не знаю сколько там реально активных и т.п., но сдается мне, что у большей части народа, что так трогательно волнуется о немасштабируемости рельс количество пользователей поменьше.
Насчет скудного хостинга - VDS вам поможет
В Украине тоже.
Но это веяния запада, а не внутренние потребности.
Но это веяния запада, а не внутренние потребности.
О, вспомнил!
Посмотрите сюда:
http://37signals.com/?=PHPE9568F34-D428-…
Сайт самих разработчикой ROR написан на PHP :)))
Посмотрите сюда:
http://37signals.com/?=PHPE9568F34-D428-…
Сайт самих разработчикой ROR написан на PHP :)))
Можно еще так:
http://37signals.com/index.php?=PHPB8B5F…
http://37signals.com/index.php?=PHPB8B5F…
или вот так http://rubyonrails.org/?=PHPE9568F34-D42…
И что? :)
Вполне возможно, что им сейчас нет смысла тратить силы на переписывание сайта на рельсах. Сайт свои задачи выполняет? А время и силы можно потратить на развитие самих рельсов.
Вполне возможно, что им сейчас нет смысла тратить силы на переписывание сайта на рельсах. Сайт свои задачи выполняет? А время и силы можно потратить на развитие самих рельсов.
Так тут многие выкрикивают что на руби типа намного быстрее писать чем на PHP. То что писалось за 3 месяца чел написал за пару недель. Да самим заюзать этот язык это сильнее маркетинга :).
С другой стороны представим ситуацию.. Компания микрософт сидит на линуксе :).. весь интернет засмеял бы.
С другой стороны представим ситуацию.. Компания микрософт сидит на линуксе :).. весь интернет засмеял бы.
Надо использовать то, что целесообразно. И все прекрасно это понимают. Были разговоры что МС использовал для хотмейла не винду. И слава богу.
не совсем понял что ты хотел сказать.. но это реально.. просто основноые штуки которые на php писались долго... для релсь есть уже плагины которые это реализовывают.. просто прикрутить..
и писать тоже самое пришлось потому как от перехода на рельсы потребность в быстром редактировании структуры и документов нуда не отпала, а так как теперь я собираюсь работать только срельсами приходится переписывать готовые вещи( кстати эта причина долго меня тормозила, именно из-за неплохого своего движка с поддержкой многоязычности и модульно расширяемости я не хотел всё это заново делать.
сейчас не жалею.
и писать тоже самое пришлось потому как от перехода на рельсы потребность в быстром редактировании структуры и документов нуда не отпала, а так как теперь я собираюсь работать только срельсами приходится переписывать готовые вещи( кстати эта причина долго меня тормозила, именно из-за неплохого своего движка с поддержкой многоязычности и модульно расширяемости я не хотел всё это заново делать.
сейчас не жалею.
если бы ты был в курсе, то наверное уже прочитал бы давно, что в 37signals.com до того как сделать рельсы писали именно на пыхе, так что не удивительно, что их сайт на пыхе. или им надо сручно переделать все свои работы?
Ух ты, крутая фича для пробивки движка :]
можно в двух словах поподробнее - какие коды, когда выводятся, как запретить?
Может еще похожие фичи знаете?
можно в двух словах поподробнее - какие коды, когда выводятся, как запретить?
Может еще похожие фичи знаете?
Например, http://www.0php.com/php_easter_egg.php
Столько комментов понаписали, а забыли про главного конкурента RoRа - Django на питоне
Кстати тест на производительность для "легкого" проекта:
http://www.alrond.com/ru/2007/feb/04/dop…
И не надо мне говорить о предвзятости...не было ее! Сам думал сначала о RoR-е, а потом все же выбрал джангу
Кстати тест на производительность для "легкого" проекта:
http://www.alrond.com/ru/2007/feb/04/dop…
И не надо мне говорить о предвзятости...не было ее! Сам думал сначала о RoR-е, а потом все же выбрал джангу
+1 не забывайте про Django.. На днях прочитал http://djangobook.com, мозг порван :) планирую закатывать кое какие проекты новые на нем в продакшн
CodeIgniter (PHP) всех порвал по производительности, кроме django :). Очень хороший фреймворк хоть и не без недостатков.
Видите — „легкого“. Расти нужно, а не в модные фреймворки играццо.
У меня под боком нагрзочный проект, который парни построили на Django. Ничего хорошего не вышло и вряд ли выйдет. …И все потому, что универсальные решения всегда хуже специализированных.
Средней разработчик экономит на времени разработки. Время важная штука конечно, но и о качестве помнить нужно. Это как в анекдоте про „быстро, дешево и качественно“.
У меня под боком нагрзочный проект, который парни построили на Django. Ничего хорошего не вышло и вряд ли выйдет. …И все потому, что универсальные решения всегда хуже специализированных.
Средней разработчик экономит на времени разработки. Время важная штука конечно, но и о качестве помнить нужно. Это как в анекдоте про „быстро, дешево и качественно“.
У меня под боком нагрзочный проект, который парни построили на Django. Ничего хорошего не вышло и вряд ли выйдет. …И все потому, что универсальные решения всегда хуже специализированных.
Можно поинтересоваться какие специализированные решения имеются ввиду?
Средней разработчик экономит на времени разработки. Время важная штука конечно, но и о качестве помнить нужно.
Вам будет сложно сделать что-то некачественно придерживаясь идеологии фреймворка.
Можно поинтересоваться какие специализированные решения имеются ввиду?
Конечно, хотя странно слышать такой вопрос. Очень. Подумайте о том, почему существуют легковесные веб-серверы, как они обычно используются и кто стоит за ними.
Вам будет сложно сделать что-то некачественно придерживаясь идеологии фреймворка.
Спасибо, скрасили субботний вечер. В лучшем случае фреймворк диктует общую архитектуру приложений, но — сделать что-то некачественно только благодаря его использованию?! :-) Мне кажется, ваш опыт еще не перевесил ваше же убеждение в чудесности и общей божественности „данных нам фреймворков“.
Конечно, хотя странно слышать такой вопрос. Очень. Подумайте о том, почему существуют легковесные веб-серверы, как они обычно используются и кто стоит за ними.
Хорошо задам вопрос по-другому. Чем плохо использование легковесного веб-сервера с FastCGI и django в режиме FastCGI?
Спасибо, скрасили субботний вечер. В лучшем случае фреймворк диктует общую архитектуру приложений, но — сделать что-то некачественно только благодаря его использованию?! :-) Мне кажется, ваш опыт еще не перевесил ваше же убеждение в чудесности и общей божественности „данных нам фреймворков“.
Не правильно выразился. Использование хорошего фреймворка и его идеологии позволяет больше уделять коду логики приложения. Так как не происходит отвлечения на то как это вывести, как получить данные.
Хорошо задам вопрос по-другому. Чем плохо использование легковесного веб-сервера с FastCGI и django в режиме FastCGI?
Ничем. Обычное решение.
Разговор не о django, а о том, что привносит использование исключительно „универсальных“ решений.
Если интересно, прочитайте заметку Контролируемое скачивание 2 ведущего разработчика того самого нагрузочного проекта. По прочтении вам должно стать понятно, насколько помог мега-фреймфорк решить конкретную бизнес-задачу.
Я тут немного переставлю порядок цитат.
Первую часть я читал. Вот не думал что будет еще и вторая. Довольно любопытно.
Дело еще немного в том что автор хочет на типичном решении собственно для этого не предназначенного сделать довольно не типичную задачу. А именно хотел контролировать соединение сам причем через FastCGI. Если бы он таких хитрых вещей не хотел ему бы не потребовалось это все воротить. Т.е. к примеру если бы он бы вместо пропускания файла через FastCGI отдавал его бы самим http cервером то этого бы не происходило. Но так как хотелось несколько другого то пришлось зайти с другой стороны. Хотя опять же если мне не изменяет память sun.com отдает файлы аналогичным образом только servlet (судя по ссылке) и у них это работает.
PS Вообще случай довольно специфичный и по сути дела в результате вышел за рамки django или у вас такой же случай имеется?
Если интересно, прочитайте заметку Контролируемое скачивание 2 ведущего разработчика того самого нагрузочного проекта. По прочтении вам должно стать понятно, насколько помог мега-фреймфорк решить конкретную бизнес-задачу.
Первую часть я читал. Вот не думал что будет еще и вторая. Довольно любопытно.
Разговор не о django, а о том, что привносит использование исключительно „универсальных“ решений.
Дело еще немного в том что автор хочет на типичном решении собственно для этого не предназначенного сделать довольно не типичную задачу. А именно хотел контролировать соединение сам причем через FastCGI. Если бы он таких хитрых вещей не хотел ему бы не потребовалось это все воротить. Т.е. к примеру если бы он бы вместо пропускания файла через FastCGI отдавал его бы самим http cервером то этого бы не происходило. Но так как хотелось несколько другого то пришлось зайти с другой стороны. Хотя опять же если мне не изменяет память sun.com отдает файлы аналогичным образом только servlet (судя по ссылке) и у них это работает.
PS Вообще случай довольно специфичный и по сути дела в результате вышел за рамки django или у вас такой же случай имеется?
Да, у меня имеются, и для решения этих случаев я использую специально заточенный код, который либо вырабатывается самостоятельно, либо соскребается напильником с чужого. Это не швейцарский нож, и в этом нет ничего плохого.
Фреймворки уровня ror и django хороши для области обобщенных и сравнительно легких бизнес-задач: блоги, полупустые каталоги, etc.
Вот когда нужно что-то серьезное и более важное, чем удобство и удовольствие разработчика, вот тогда разработчик берет грабли, наклоняется, и начинает разгребать. Вы и сами об этом только что прочитали.
Фреймворки уровня ror и django хороши для области обобщенных и сравнительно легких бизнес-задач: блоги, полупустые каталоги, etc.
Вот когда нужно что-то серьезное и более важное, чем удобство и удовольствие разработчика, вот тогда разработчик берет грабли, наклоняется, и начинает разгребать. Вы и сами об этом только что прочитали.
Да, у меня имеются, и для решения этих случаев я использую специально заточенный код, который либо вырабатывается самостоятельно, либо соскребается напильником с чужого. Это не швейцарский нож, и в этом нет ничего плохого.
Это не плохо это хорошо :)
Фреймворки уровня ror и django хороши для области обобщенных и сравнительно легких бизнес-задач: блоги, полупустые каталоги, etc.
Тут больше вопрос в том как это масштабируется и как растут требования.
Вот когда нужно что-то серьезное и более важное, чем удобство и удовольствие разработчика, вот тогда разработчик берет грабли, наклоняется, и начинает разгребать.
Это было не укладывающееся в модель django и собственно в модель FastCGI. К тому же отдавать тяжелый контент именно самим django IMHO не стоит, автор статьи привел пример почему. Если же была возможность через FastCGI организовать отдачу контента куче клиентов одним потоком было бы заметно лучше. К сожалению там этого нет по этому приходится обходить ограничения.
ОФФТОП:
Полностью текст не читал, глянул про lighttpd.
Этот разработчик про send-file не слышал?:) FastCGI процессом нельзя отдавать тело файла.
Не поленился, зашел на один из наших серваков: пхп процесс (5.2.1RC5) весит 6,7MB (VSZ) / 3,3MB (RSS). Lighttpd занимает около 5MB памяти.
То, что вам нужно, делается связкой nginx+php или lighttpd+php и работать будет замечательно.
Полностью текст не читал, глянул про lighttpd.
Этот разработчик про send-file не слышал?:) FastCGI процессом нельзя отдавать тело файла.
Под lighttpd с FastCGI чуть меньше — 18 - 22 МБ.
Не поленился, зашел на один из наших серваков: пхп процесс (5.2.1RC5) весит 6,7MB (VSZ) / 3,3MB (RSS). Lighttpd занимает около 5MB памяти.
То, что вам нужно, делается связкой nginx+php или lighttpd+php и работать будет замечательно.
То, что вам нужно, делается связкой nginx+php или lighttpd+php и работать будет замечательно.
Это нужно не мне. Вы лучше напишите автору статьи, расскажите ему про x-send-file, ссылками поделитесь какими-нибудь. :-)
Как будете обеспечивать контроль скачивания и сессии ? Внимательно почитайте предпосылки. И чем предложенное вами решение будет отличаться от редиректа на статический файл ?
Что Вы понимаете под контролем скачивания и сессиями?:)
У нас исключительно на lighttpd+php сделан контроль доступа (можно прикрутить любую логику - авторизация, url expiration, лимитирование по IP адресам и странам), ограничение по каналу, ограничение по трафику (в ГБ), учет закачек на уровне 1) сколько байт какого файла какой юзер скачал 2) сколько попыток сделал юзер 3) какая скорость была у юзера.
При этом все это еще и частично зеркалируется (т.е. зеркала не идентичные, а повторяют части друг друга), и между зеркалами балансится нагрузка.
Я не знаю достаточно ли этих возможностей для проекта, о котором идет речь в статье, но нам достаточно:).
У нас исключительно на lighttpd+php сделан контроль доступа (можно прикрутить любую логику - авторизация, url expiration, лимитирование по IP адресам и странам), ограничение по каналу, ограничение по трафику (в ГБ), учет закачек на уровне 1) сколько байт какого файла какой юзер скачал 2) сколько попыток сделал юзер 3) какая скорость была у юзера.
При этом все это еще и частично зеркалируется (т.е. зеркала не идентичные, а повторяют части друг друга), и между зеркалами балансится нагрузка.
Я не знаю достаточно ли этих возможностей для проекта, о котором идет речь в статье, но нам достаточно:).
Что Вы понимаете под контролем скачивания и сессиями?:)
Вам процитировать из выше приведенной статьи, что там под этим понималось или как?
У нас исключительно на lighttpd+php сделан контроль доступа (можно прикрутить любую логику - авторизация, url expiration, лимитирование по IP адресам и странам), ограничение по каналу, ограничение по трафику (в ГБ), учет закачек на уровне 1) сколько байт какого файла какой юзер скачал 2) сколько попыток сделал юзер 3) какая скорость была у юзера.
И файлы отдает сам сервер. Но ни как не php так?
Вам процитировать из выше приведенной статьи, что там под этим понималось или как?
Да, пожалуйста.
И файлы отдает сам сервер. Но ни как не php так?
Сам сервер.
Лучше приведу механизм:
По этому у вас и нет этой проблемы. Так как у автора довольно специфичная задача.
Напомню вкратце, на какой схеме я остановился в прошлый раз.
* клиент обращается за скачиванием в Django-приложение, работающее под Apache’ем
* приложение возвращает в Apache умный итератор, из которого файл выдается пользователю
* умный итератор умеет ограничивать скорость, придерживая выдачу кусочков файла
* умный итератор учитывает количество отданных байт, записывая его в БД
Сам сервер.
По этому у вас и нет этой проблемы. Так как у автора довольно специфичная задача.
У него не задача специфичная, а решение этой задачи специфичное.
http://www.softwaremaniacs.org/blog/2006…, см "Задачка"
Я не вижу на кой черт здесь тело файла отдавать НЕ сервером.
http://www.softwaremaniacs.org/blog/2006…, см "Задачка"
Я не вижу на кой черт здесь тело файла отдавать НЕ сервером.
* для отдельных категорий пользователей скорость скачивания должна быть ограничена
* система должна быть в курсе, когда скачивание успешно завершено
Как ?
"ограничение скорости для категорий юзеров" - у нас нет такой фичи за ненадобностью, но делается без проблем все тем же лайти+пхп. Лайти позволяет лимитировать скорость соединения для определенной ссылки, а версия 1.5.0 (пока только бета, мы сами ее не используем) позволяет делать это через хеадеры.
"в курсе когда завершено скачивание" - это есть, правда не в реальном времени, а с задержкой ~5 минут.
как это сделано я не буду здесь описывать, во-первых потому что это уже наши internals, а во-вторых это займет много времени:)
"в курсе когда завершено скачивание" - это есть, правда не в реальном времени, а с задержкой ~5 минут.
как это сделано я не буду здесь описывать, во-первых потому что это уже наши internals, а во-вторых это займет много времени:)
Странно, что моя статья оставила такое впечатление. Я специально подчеркнул, что написание custom-сервера на Питоне позволило использовать в нем самом Django-модули и без проблем связываться с остальным приложением. В частности, были использованы авторизация, права, объекты HTTP-запросов и ответов, доступ к моделям.
Django фреймворк со слабой связностью модулей, а не монолит, он не навязывает никакой модели использования и может быть использован по частям.
Django фреймворк со слабой связностью модулей, а не монолит, он не навязывает никакой модели использования и может быть использован по частям.
В догонку: по поводу монолитов, использовании фреймворков и вообще о reuse есть хорошие комментарии к посту Reuse is vastly overrated.
про джанго ни кто не забывал просто пост про рельсы... для меня вообще закадка почему питон не прижился в рунете... если бы на хостах питон был всегда в наличии также как и пхп то возможно ситуация была бы иной
Да уж, мноого мнений написали... чуствуется мнения чистых програмеров... сам програмер но понимаю что цель любой работы - деньги. Это доказанная истина. Всё остальное это методы достижения цели. И всё что мы не делаем делается для достижения цели. Соответственно по моему паралельно на чём писать, главное чтобы приносило деньги :)..
С другой стороны - против статистики не попрёшь. PHP популярен и с этим сложно поспорить. Java я исключил, потому что не совсем равноценное сравнение. Если через несколько лет руби и станет популярным, то тогда и можно будет говорить что он лучше, а что то хуже.
От себя скажу что на данный момент для меня например больше возможностей заработать денег на PHP чем на руби.
С другой стороны - против статистики не попрёшь. PHP популярен и с этим сложно поспорить. Java я исключил, потому что не совсем равноценное сравнение. Если через несколько лет руби и станет популярным, то тогда и можно будет говорить что он лучше, а что то хуже.
От себя скажу что на данный момент для меня например больше возможностей заработать денег на PHP чем на руби.
+1
молоток! очень точно замечено, цель - заработать денег с максимальным удовольствием, за минимальное количество времени.
а с учетом текущего роста рейтинга (http://prog.labis.ru/blog/archives/22-Ru…) перспективы впечатляют...
молоток! очень точно замечено, цель - заработать денег с максимальным удовольствием, за минимальное количество времени.
а с учетом текущего роста рейтинга (http://prog.labis.ru/blog/archives/22-Ru…) перспективы впечатляют...
всё так ни кто не спорит, каждый сам для себя решает что для него лучше.. но есть одно но..
часто бывает так, что кто первый встал того и тапки)
вот я надеюсь что у меня будут клёвые тапки благодаря тому что я сейчас сделал ставку на рельсы. но часто бывает что всё идёт не так как надо)
мой длинный коммент лишь о том что рельсы действитильно эффективны, и что стоит обратить на них своё внимание. есть ещё много технологий скорее всего ещё лучше, но всё дело в маркейтинге.
у рельсов хор маркейтинг + они подружились с яблоками, а во всём мире наблюдается подъём интереса к яблокам, а это может помочь стать стандартом, как пхп стал стандартом 5 лет назад.
часто бывает так, что кто первый встал того и тапки)
вот я надеюсь что у меня будут клёвые тапки благодаря тому что я сейчас сделал ставку на рельсы. но часто бывает что всё идёт не так как надо)
мой длинный коммент лишь о том что рельсы действитильно эффективны, и что стоит обратить на них своё внимание. есть ещё много технологий скорее всего ещё лучше, но всё дело в маркейтинге.
у рельсов хор маркейтинг + они подружились с яблоками, а во всём мире наблюдается подъём интереса к яблокам, а это может помочь стать стандартом, как пхп стал стандартом 5 лет назад.
Вот, холивары сразу какие :))
Вот это махач, вот это понимаю… :-)
Есть много народу кто пробовал PHP после C, C++, Java, Perl :) В связи с этим не любят PHP. А есть люди которые на нем пишут и не любят когда на него ругаются :)
Ругань не любят два типа людей, пишущих на пыхе.
Первый тип — это те, кто не знаком с альтернативами.
Второй — те, кто знаком, но хорошо представляет, когда и зачем пыха нужна. :-)
Вот Ruby красивый язык. Учитывая, что я очень люблю JS и AS (третий хорош, да…), можно представить, что с Ruby я буду счастлив еще долго. В то же время, приходится писать демоны на С, пауков на Perl, и т.п. Ну и как в этом зоопарке ругаться на PHP?
Я думаю, что большинство воплей возникают по причине фрустрации или ламерства. …Потому что у людей думающих это называется конструктивной беседой по существу. :-)
Первый тип — это те, кто не знаком с альтернативами.
Второй — те, кто знаком, но хорошо представляет, когда и зачем пыха нужна. :-)
Вот Ruby красивый язык. Учитывая, что я очень люблю JS и AS (третий хорош, да…), можно представить, что с Ruby я буду счастлив еще долго. В то же время, приходится писать демоны на С, пауков на Perl, и т.п. Ну и как в этом зоопарке ругаться на PHP?
Я думаю, что большинство воплей возникают по причине фрустрации или ламерства. …Потому что у людей думающих это называется конструктивной беседой по существу. :-)
О кстати может вы объсните в чем прикол. Делаю такую вот вещь выделяю в одной функции malloc память под строку размещаю туда данные и предаю указатель на строку из функции. Далее если в другой функции вызвать первую функции и присвоить указатель локальной переменной и далее нигде эту локальную переменную не использовать, то в конце при попытке осовободить память (через операцию free) получаем segfault.
PS Компилятор gcc 3.3.6 и 4.1.1 опция используется -Wall и больше никаких.
PS Компилятор gcc 3.3.6 и 4.1.1 опция используется -Wall и больше никаких.
Я не совсем понял ваш вопрос. Зачем объявлять переменную, которую вы не собираетесь использовать?
Подошел напарник и выдал: после маллока сделать memset(0x0, ...), после записи проверить, что в конце данных есть-таки нулевой байт (то есть выделять нужно с учетом).
:-)
Подошел напарник и выдал: после маллока сделать memset(0x0, ...), после записи проверить, что в конце данных есть-таки нулевой байт (то есть выделять нужно с учетом).
:-)
Выделяю с учетом иначе бы падало бы при использовании :). Просто любытно почему кусок уже выделенной помяти при попытке в конце функции его освободить, но при этом он не использовался функцией, вызывает segfault. Код то я уже переписал, чтоб если не используется, не выделяло. Просто меня озадачила такая работа кода, хотя меня не покидает ощущение, что-то компилятор наоптимизировал.
и не говори :)
Нам до сих пор крутят пальцем у виска за наш переход в 2001 году с Perl на Ruby. Красивый ЯП. Из применяемых в *nix-based сайтах самый лучший.
Но всё течёт и меняется. Отсутствие многопоточности и нормального нетворка поставило крест на его дальнейшем использовании - все последующие проекты будут на другом красивом ЯП, C#.
В относительно скором времени для Ruby обещают и многопоточность и нормальный нетворк. Если бы мы сейчас только начинали, выбор был бы за Ruby, а не за Perl/PHP. Скорость интерпретатора не очень критична, большее значение имеет прямота рук. Поэтому если руки прямые и хочется красивый код, выбирайте Ruby =)
Но всё течёт и меняется. Отсутствие многопоточности и нормального нетворка поставило крест на его дальнейшем использовании - все последующие проекты будут на другом красивом ЯП, C#.
В относительно скором времени для Ruby обещают и многопоточность и нормальный нетворк. Если бы мы сейчас только начинали, выбор был бы за Ruby, а не за Perl/PHP. Скорость интерпретатора не очень критична, большее значение имеет прямота рук. Поэтому если руки прямые и хочется красивый код, выбирайте Ruby =)
После прочтения всего этого леса комментов есть несколько вопросов:
1) Чем ROR круче Симфони?
2) За PHP стоит мощная индустрия во главе с Zend (более-менее крупная коммерческая компания), а что стоит за Ruby?
3) Зачем хорошему PHP-программеру изучать Ruby или Pyton? Если это просто красиво - то почему не Java?
это скорее не к автору, а к наиболее радикальным комментаторам...
1) Чем ROR круче Симфони?
2) За PHP стоит мощная индустрия во главе с Zend (более-менее крупная коммерческая компания), а что стоит за Ruby?
3) Зачем хорошему PHP-программеру изучать Ruby или Pyton? Если это просто красиво - то почему не Java?
это скорее не к автору, а к наиболее радикальным комментаторам...
Зачем хорошему PHP-программеру изучать Ruby или Pyton?
чтобы понять, как кодинг может приносить удовольствие :) попробуйте, объяснить словами сложно
чтобы понять, как кодинг может приносить удовольствие :) попробуйте, объяснить словами сложно
PHP5 позволяет строить очень красивые модели и приносить удовольствие :)
Так почему все же не Java?
PHP, Ruby, Pyton - примерно одного поля ягоды. К тому же PHP быстрее, что позволяет при тех же ресурсах работать на более высоком уровне абстракции.
Возможно для новичка выбор Ruby или Pyton вместо PHP оправдан, но вот для хорошего PHP-разработчика - сомневаюсь... Шило на мыло IMHO
Так почему все же не Java?
PHP, Ruby, Pyton - примерно одного поля ягоды. К тому же PHP быстрее, что позволяет при тех же ресурсах работать на более высоком уровне абстракции.
Возможно для новичка выбор Ruby или Pyton вместо PHP оправдан, но вот для хорошего PHP-разработчика - сомневаюсь... Шило на мыло IMHO
попробуйте и всё тут :)
я пробовал программировать на PHP, пробовал на ActionScript (который очень близок к Java по стилю). потом попробовал Ruby и влюбился.
для хорошего разработчика смена языка - хороший сигнал, что он не стоит на месте, а развивается в ногу со временем.
я пробовал программировать на PHP, пробовал на ActionScript (который очень близок к Java по стилю). потом попробовал Ruby и влюбился.
для хорошего разработчика смена языка - хороший сигнал, что он не стоит на месте, а развивается в ногу со временем.
Не собираюсь если чесно, лучше Симфони покурю :)
По-моему вы недооцениваете сложность перехода - дело тут не только в языке, но и во всей инфраструктуре. Переход с PHP на Ruby потребует изменения ПО многих серверов, а это на практике так просто.
В думаю что в общем случае преимущество перехода опытного PHP5-разработчика на Ruby/Pyton весьма туманно
По-моему вы недооцениваете сложность перехода - дело тут не только в языке, но и во всей инфраструктуре. Переход с PHP на Ruby потребует изменения ПО многих серверов, а это на практике так просто.
В думаю что в общем случае преимущество перехода опытного PHP5-разработчика на Ruby/Pyton весьма туманно
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что такое Ruby on Rails