программист не разрабатывает систему - на то есть архитектор. но в целом - согласен, программистов - мало, архитекторов - по пальцам пересчитать.
но с другой стороны - если бы все дворники вдруг, неожиданно стали бы отличными программистами - кто бы подметал улицу? ;) правда, проблему адекватности зарплатных запросов это не отменяет.
Простите, но мне кажется что Вы слишком увлеклись идеей "2.0" ;) Т.е. чтобы социальная сеть сама отвечала на свои вопросы.
С одной стороны Вы согласны со мной, т.е. понимаете что разница есть, и в статье понятия смешаны. А с другой - просите меня сформулировать эту разницу. Вы же пишите, Вы понимаете, что есть ошибка, почему бы самому ее не исправить в одной из следующих статей?
>Вот как-то хочется чтоб оно работало
Тут скорее не к языку претензии, а к той же муське.
>http://www.codenet.ru/webmast
Ну это сложно назвать "встроеным" шаблонизатором :))) Сам по себе РНР, в таком случае, и является "встроенным" шаблонизатором.
>Мне хотелось бы одной хорошей библиотеки работы с СУБД
А она есть - та, что Вы сами для себя выберите. :) Одной из сильных сторон РНР является то, что он ни к чему не принуждает, позволяет делать так, как удобно разработчику. Один раз написав свое (если чужое не подошло), и пользуйтесь во всех проектах. Лично я так и сделал. Если хочется стандартов - используйте PDO от разработчиков.
>Нет у PHP стройности архитектуры
Разруха не в клозетах, а в головах :) То, что язык предъявляет не высокие требования к разработчику - в определенных моментах является минусом. Но если язык будет очень строг, не спасет от не понимания разработчиком зачем сделано именно так, а не иначе. Встречаются индивидуумы, которые 5 лет пишут на дельфях и ни разу за это время не видели реального кода. Программисты, пишущие мышкой, блин.
>Во первых не везде есть возможность это сделать.
Согласен. С другой стороны - на хостингах стоит достаточно большой пакет, для большинства приложений его хватает за глаза. Для специфичных приложений - все равно без собственного сервера (а то и не одного) делать нечего.
>Собственно если подумать к PHP у меня одна претензия отсутствие стройной модели.
Есть достаточное количество фреймворков под РНР, у большинства имеется достаточно стройная модель - используйте их :) Нужно просто принять тот факт, что разработчик является центральной фигурой, он определяет то, как ему удобно работать. Разработчики языка - не навязывают решения. И мне например, как раз нравится.
вполне. но если перенос на новую платформу даст возможность развивать сервис раз в 10 быстрее (где-то я видел фразу о том, что "я потратил на разработку 1 неделю, вместо 3х месяцев), то гораздо эффективнее в паралель пустить вторую группу разработчиков, которая перепишит проект (допустим проекту год - она перепишет его за полтора месяца).
Дабы ни у кого не возникло не понимания. выше, в этом сообщении был сарказм. имхо, очевидно, что выгоды, которые якобы сулит переход на ROR, далеко не так заметны.
>Обычно я делаю перегрузку именно на конечное число вариантов.
А остальные варианты - приложение выпадает с ошибкой?
>пример вполне укладывается, в создание объекта прямоугольника или отрезка
Так это практически классический пример на применение полиморфизма ;)
>есть ли аналог перлового модуля strict для 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 возможно было бы лучше
Может и лучше, но согласитесь откомпилированный С работать будет на порядки быстрее, чем РНР-код.
>Это не они тестировали, а пользователи
Без результатов и описания тестов - все слова. Надо смотреть тесты, надо смотреть на сколько они синтетические.
о! и это очень важно. потому что если бы ROR был бы на столько крут, что давал бы выигрышь по сравнению с уже существующими технологиями, проект был бы перевед на Ruby.
>Но надо еще написать дополнительную обвязку которая их обрабатывает.
Да, и это единственная возможность правильно решать задачу. Потому что в случае использования перегрузки Вы не сможете описать все возможные варианты.
>Простой пример в качестве входных данных может фигурировать два числа, строка, массив и объект.
Это не пример. Это абстрактная задача :) Если в реальности возникает такая необходимость - 99% за то что система не правильно спроектирована. Если _вдруг_ такая необходимость возникает - передавайте только объект :)
>Если уж мне и надо будет передавать что-то без типизации, то проще уж абстрактный класс сделать от него наплодить потомков
Так в РНР предлагется именно такое же решение, но "повернутое" в обратную сторону - если нужна типизация - указывайте в качестве типа аргумента свой класс, от которого должен быть создан ваш объект. Таким образом и сохранятеся слабая типизация, и при необходимости можно задать ее жестко. Очень красивое решение. :)
>Вы думаете что туда единомоментно мало народу заходит?
Думаю меньше чем на - http://www.habrahabr.ru/blog/webdev/5054… + мамба для кучи. У яхи есть еще ряд сервисов, работающих под РНР. Кстати тот же ibm очень активно продвигает РНР в массы.
>PHP работает именно по такой схеме.
Для абсолютного большинства веб-приложений это не является проблемой.
>А где там отделение логики приложения от вывода?
Мы все время натыкаемся на одно и тоже - все зависит от того как программист напишет проект, т.е. на человеческий фактор. Что нам мешает шаблон вывода вынести в отдельный php файл и там написать:
Далле инклюдим шаблон. Все остальное - варианции. Это что касается разделения логики и вывода. Что же за шаблонизатор "по умолчанию" для меня так и осталось загадкой.
>Скорее ADO
Чем не устраивает PDO? Ко всему есть такое количество различных реализаций абстракных уровней БД, что у программиста есть постине огромный выбор вариантов.
>А модули как делать тоже все оборачивать таким образом
Мы сейчас говорим об слишком абстрактных вариантах использования. В каждом конкретном случае нужно искать свое решение. Для внешних модулей я бы предпочел использовать свой собственный враппер.
>Это можете воспринимать как мое субъективное мнение
Скорее что так оно и есть :)
>Где-то список стандартных функций есть? Которые умеют генерировать исключения
Отдельный список не встречал.
>Если они не являются частью PHP почему они входят в его пакет
А почему нет? если лицензия позволяет.
>Общая скорость работы PHP интерпретатора
Посмотрел по диагонали, но кроме постоянного "fast, safe, and easy" не встретил ничего о тестировании. Но из общих соображений - такого не может быть в принципе.
>Не зло.
Давайте рассмаотрим не смешивая две задачи:
1. Передача произвольного количества параметров. Задача решается func_get_args.
2. Передаются разные типы данных. Напомню - РНР - слаботипизованный язык. Для большинства веб-орентированных задач это является большим плюсом. Если нам нужно в зависимости от типа передаваемого аргумента по разному их обрабатывать, то имеет место быть не правильно спроектированная система. Но даже в таком случае я не понимаю в чем преимущество разноса на несколько одинаковоназывающихся методов вместо сохранения логики в одном методе.
А поскольку это "палка о двух концах", то в самый не подходящий момент она может больно ударить по всяким разным местам. :) Разумеется в РНР это не снимает с программиста ответственности за верификацию данных. Тип данных придется проверять безусловно (хотя никто не мешает жестко задать пользовательский тип при аргументе). А проверять значения аргументов - надо в любом языке.
sun.com и ibm.com - сложно считать эти проекты высоконагруженными.
но с другой стороны - если бы все дворники вдруг, неожиданно стали бы отличными программистами - кто бы подметал улицу? ;) правда, проблему адекватности зарплатных запросов это не отменяет.
С одной стороны Вы согласны со мной, т.е. понимаете что разница есть, и в статье понятия смешаны. А с другой - просите меня сформулировать эту разницу. Вы же пишите, Вы понимаете, что есть ошибка, почему бы самому ее не исправить в одной из следующих статей?
Это весь опыт работы с фрилансерами?
Тут скорее не к языку претензии, а к той же муське.
>http://www.codenet.ru/webmast
Ну это сложно назвать "встроеным" шаблонизатором :))) Сам по себе РНР, в таком случае, и является "встроенным" шаблонизатором.
>Мне хотелось бы одной хорошей библиотеки работы с СУБД
А она есть - та, что Вы сами для себя выберите. :) Одной из сильных сторон РНР является то, что он ни к чему не принуждает, позволяет делать так, как удобно разработчику. Один раз написав свое (если чужое не подошло), и пользуйтесь во всех проектах. Лично я так и сделал. Если хочется стандартов - используйте PDO от разработчиков.
>Нет у PHP стройности архитектуры
Разруха не в клозетах, а в головах :) То, что язык предъявляет не высокие требования к разработчику - в определенных моментах является минусом. Но если язык будет очень строг, не спасет от не понимания разработчиком зачем сделано именно так, а не иначе. Встречаются индивидуумы, которые 5 лет пишут на дельфях и ни разу за это время не видели реального кода. Программисты, пишущие мышкой, блин.
>Во первых не везде есть возможность это сделать.
Согласен. С другой стороны - на хостингах стоит достаточно большой пакет, для большинства приложений его хватает за глаза. Для специфичных приложений - все равно без собственного сервера (а то и не одного) делать нечего.
>Собственно если подумать к PHP у меня одна претензия отсутствие стройной модели.
Есть достаточное количество фреймворков под РНР, у большинства имеется достаточно стройная модель - используйте их :) Нужно просто принять тот факт, что разработчик является центральной фигурой, он определяет то, как ему удобно работать. Разработчики языка - не навязывают решения. И мне например, как раз нравится.
Дабы ни у кого не возникло не понимания. выше, в этом сообщении был сарказм. имхо, очевидно, что выгоды, которые якобы сулит переход на ROR, далеко не так заметны.
А остальные варианты - приложение выпадает с ошибкой?
>пример вполне укладывается, в создание объекта прямоугольника или отрезка
Так это практически классический пример на применение полиморфизма ;)
>есть ли аналог перлового модуля strict для 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 возможно было бы лучше
Может и лучше, но согласитесь откомпилированный С работать будет на порядки быстрее, чем РНР-код.
>Это не они тестировали, а пользователи
Без результатов и описания тестов - все слова. Надо смотреть тесты, надо смотреть на сколько они синтетические.
Да, и это единственная возможность правильно решать задачу. Потому что в случае использования перегрузки Вы не сможете описать все возможные варианты.
>Простой пример в качестве входных данных может фигурировать два числа, строка, массив и объект.
Это не пример. Это абстрактная задача :) Если в реальности возникает такая необходимость - 99% за то что система не правильно спроектирована. Если _вдруг_ такая необходимость возникает - передавайте только объект :)
>Если уж мне и надо будет передавать что-то без типизации, то проще уж абстрактный класс сделать от него наплодить потомков
Так в РНР предлагется именно такое же решение, но "повернутое" в обратную сторону - если нужна типизация - указывайте в качестве типа аргумента свой класс, от которого должен быть создан ваш объект. Таким образом и сохранятеся слабая типизация, и при необходимости можно задать ее жестко. Очень красивое решение. :)
>Вы думаете что туда единомоментно мало народу заходит?
Думаю меньше чем на - http://www.habrahabr.ru/blog/webdev/5054… + мамба для кучи. У яхи есть еще ряд сервисов, работающих под РНР. Кстати тот же ibm очень активно продвигает РНР в массы.
Для абсолютного большинства веб-приложений это не является проблемой.
>А где там отделение логики приложения от вывода?
Мы все время натыкаемся на одно и тоже - все зависит от того как программист напишет проект, т.е. на человеческий фактор. Что нам мешает шаблон вывода вынести в отдельный php файл и там написать:
Далле инклюдим шаблон. Все остальное - варианции. Это что касается разделения логики и вывода. Что же за шаблонизатор "по умолчанию" для меня так и осталось загадкой.
>Скорее ADO
Чем не устраивает PDO? Ко всему есть такое количество различных реализаций абстракных уровней БД, что у программиста есть постине огромный выбор вариантов.
>А модули как делать тоже все оборачивать таким образом
Мы сейчас говорим об слишком абстрактных вариантах использования. В каждом конкретном случае нужно искать свое решение. Для внешних модулей я бы предпочел использовать свой собственный враппер.
>Это можете воспринимать как мое субъективное мнение
Скорее что так оно и есть :)
>Где-то список стандартных функций есть? Которые умеют генерировать исключения
Отдельный список не встречал.
>Если они не являются частью PHP почему они входят в его пакет
А почему нет? если лицензия позволяет.
>Общая скорость работы PHP интерпретатора
Посмотрел по диагонали, но кроме постоянного "fast, safe, and easy" не встретил ничего о тестировании. Но из общих соображений - такого не может быть в принципе.
Давайте рассмаотрим не смешивая две задачи:
1. Передача произвольного количества параметров. Задача решается func_get_args.
2. Передаются разные типы данных. Напомню - РНР - слаботипизованный язык. Для большинства веб-орентированных задач это является большим плюсом. Если нам нужно в зависимости от типа передаваемого аргумента по разному их обрабатывать, то имеет место быть не правильно спроектированная система. Но даже в таком случае я не понимаю в чем преимущество разноса на несколько одинаковоназывающихся методов вместо сохранения логики в одном методе.
А поскольку это "палка о двух концах", то в самый не подходящий момент она может больно ударить по всяким разным местам. :) Разумеется в РНР это не снимает с программиста ответственности за верификацию данных. Тип данных придется проверять безусловно (хотя никто не мешает жестко задать пользовательский тип при аргументе). А проверять значения аргументов - надо в любом языке.
sun.com и ibm.com - сложно считать эти проекты высоконагруженными.