Comments 64
а ruby всё равно лучше :)
Согласен, отчасти, но всё равно минус поставлю, потому что всё зависит от информационного ареола: пользователи, контент, контекст.
Если по русски, то от поставленной задачи. В общем, — братья рубисты, давайте прекратим джихад против php, у дзен языка много отображений на этот мир, и каждое это отображение прекрасно по своему.
Если по русски, то от поставленной задачи. В общем, — братья рубисты, давайте прекратим джихад против php, у дзен языка много отображений на этот мир, и каждое это отображение прекрасно по своему.
хотел я плюсиков подзаработать, чтобы наконец контент в блоге начать публиковать, а получилось наоборот. немного странное вы сообщество. помоему проще было одного модератора посадить, чтобы он спам отсекал, чем терять СТОЛЬКО потенциального контента, сколько вы с такой закрытой моделью теряете.
Странное у вас видение возможностей заработать плюсиков. Примерно как прийти в гарлем и закричать "Черножопые отстой" в надежде заручиться уважением и укрепить здоровье...
Что же касается "теряемого" контента, так тут большой-пребольшой вопрос в качестве этого "потенциального" контента...
Что же касается "теряемого" контента, так тут большой-пребольшой вопрос в качестве этого "потенциального" контента...
UFO just landed and posted this here
Спасибо!)
Мне вот очень нужны PHP программисты на PHP-5. А у нас большая часть людей на PHP-4 продолжают писать.
UFO just landed and posted this here
Мы пишем весь проект на ООП + ZEND переделанный.
Блин, как част о понимаю что мог бы сгодиться, если б не 16 лет.
Возраст роли не играет.
Как показывает практика, человек в 15-16 лет может быть отличным программистом, но при этом достаточно безответственным — такой уж возраст.
По крайней мере сначала такого человека лучше проверить на каком-нибудь проекте без жмущих сроков.
По крайней мере сначала такого человека лучше проверить на каком-нибудь проекте без жмущих сроков.
UFO just landed and posted this here
у меня на серваке собран 4-ый пхп с 3-мя модулями. pcre, mbstring и mysql. нет ни сессий, ни xml ничего подобного. можно, конечно, собрать последнюю версию со всеми модулями и ходить по улице, нарезать понты, какой ты кутой php5 программист.
Вот когда они переведут php на UTF8, вот это будет реальной причиной перехода. А наличии ООП... как-то не впечатляет. c++ в этом плане куда более крут.
Вот когда они переведут php на UTF8, вот это будет реальной причиной перехода. А наличии ООП... как-то не впечатляет. c++ в этом плане куда более крут.
Сравнивать C++ и PHP, даже на уровне ООП... я даже не знаю как это назвать. Во всяком случае, область применения этих двух птичек сильно различается и те возможности, которые могут понадобиться в прикладном (системном) программировании, не всегда могут пригодиться в разработке Web-сайтов. Я так считаю.
т.е. c++ с ваших слов не применим в вебе? расскажите это создателям li.ru
Я сказал, что область применения этих двух языков различна и сделал упор на то, для чего, собственно, создавались эти языки.
Не сравнивайте слишком разные вещи. Стоит отличать вывод списка комментариев от обработки большого массива информации.
Я пишу и на с++, и на php, и на java - только все же различаю вещи. У каждого языка свои вещи. Если бы на маленький проект я бы стал писать движок на java или тем более c++, то было бы проще застрелиться. Да, я бы его написал - но ушло бы куда больше времени. А оправдало бы повышение быстродействия затраченное время? Сильно сомневаюсь.
У всех, кто противопостовляет с++, python, java и пр. более "продвинутые" языки простым вроде php, имхо, комплекс неполноценности. Нужно выбирать адекватный инструмент, а не гордиться знанием одного из них.
Я пишу и на с++, и на php, и на java - только все же различаю вещи. У каждого языка свои вещи. Если бы на маленький проект я бы стал писать движок на java или тем более c++, то было бы проще застрелиться. Да, я бы его написал - но ушло бы куда больше времени. А оправдало бы повышение быстродействия затраченное время? Сильно сомневаюсь.
У всех, кто противопостовляет с++, python, java и пр. более "продвинутые" языки простым вроде php, имхо, комплекс неполноценности. Нужно выбирать адекватный инструмент, а не гордиться знанием одного из них.
Если бы я мог ставить плюсы сообщениям, я бы поставил Вам.
Аргументирую: для каждого проекта нужно выбирать такой ЯП, который наиболее полно удовлетворит потребности программиста.
И, согласитесь, разработка проекта на PHP займёт меньше времени, чем на C++, так как PHP намного легче использовать в боевых условиях.
С другой стороны, производительность. Если, допустим, необходима очень плотная работа с БД, то лучше будет использовать C++ (хотя тут можно поспорить: "оптимизируйте, товарищи, ваши запросы к БД ;)" ).
И, согласитесь, разработка проекта на PHP займёт меньше времени, чем на C++, так как PHP намного легче использовать в боевых условиях.
С другой стороны, производительность. Если, допустим, необходима очень плотная работа с БД, то лучше будет использовать C++ (хотя тут можно поспорить: "оптимизируйте, товарищи, ваши запросы к БД ;)" ).
>> Если... я бы стал писать движок на java..., то было бы проще застрелиться
Как хотите, но странно мне это.
Потому что как минимум:
- объектная модель php5 со временем всё больше становится похожа на java (с огромным отставанием, конечно)
- шаблонных движков и mvc-фреймворков (в том числе поддерживающих ajax) на java написано на порядок больше, чем на php, и они явно качественней
Так почему же проще изобретать свой велосипед на php? ;)
Как хотите, но странно мне это.
Потому что как минимум:
- объектная модель php5 со временем всё больше становится похожа на java (с огромным отставанием, конечно)
- шаблонных движков и mvc-фреймворков (в том числе поддерживающих ajax) на java написано на порядок больше, чем на php, и они явно качественней
Так почему же проще изобретать свой велосипед на php? ;)
Сравните spring и, к примеру, cakephp. На чем выйдет быстрее?
И изобретать велосипед не к чему - есть много готовых фреймворков/cms и под php.
И изобретать велосипед не к чему - есть много готовых фреймворков/cms и под php.
>>c++ в этом плане куда более крут.
В плане ООП c++ как-то уж очень далек от идеала.
В плане ООП c++ как-то уж очень далек от идеала.
1. PHP давным давно работает без проблем с UTF8.
2. В PHP5 совершенно нормальная объектная модель, ничем не хуже других языков. Вы вообще знакомы с PHP5?
3. Какой смысл собирать PHP с тремя модулями??? Причем тут понты? Сессии, GD, iconv и прочие вещи просто жизненно необходимы при серьезной работе.
2. В PHP5 совершенно нормальная объектная модель, ничем не хуже других языков. Вы вообще знакомы с PHP5?
3. Какой смысл собирать PHP с тремя модулями??? Причем тут понты? Сессии, GD, iconv и прочие вещи просто жизненно необходимы при серьезной работе.
при серьезной работе можно заметить что сессии мешают делать масштаб. Что если у вас в локалке несколько php тачек и сверху над ними какой-либо лоадбалансер? Ничего не остается как писать свою версию сессий через базу.
Можно, конечно, поднять nfs и заставить все абстрими класть сессию на виртуальный раздел и читать с него, но это будет большим тормозом.
Так же при серьезной работе можно заметить что возможности GD очень сильно ограничены. Что GD жрет много памяти, а т.к. установлена как модуль, жрет памяти много php. И что ImageMagic не просто быстрее удобнее и функциональнее, он еще и практичнее.
iconv отлично заменяет mbstring.
Php несомненно без проблем работае с utf8, при наличии нужный модулей. Но движит им не utf8 =) иначе ни все эти модули для работы с кодировками стали бы ненужными. Они ими и станут, как тока php начнет работу на utf
Можно, конечно, поднять nfs и заставить все абстрими класть сессию на виртуальный раздел и читать с него, но это будет большим тормозом.
Так же при серьезной работе можно заметить что возможности GD очень сильно ограничены. Что GD жрет много памяти, а т.к. установлена как модуль, жрет памяти много php. И что ImageMagic не просто быстрее удобнее и функциональнее, он еще и практичнее.
iconv отлично заменяет mbstring.
Php несомненно без проблем работае с utf8, при наличии нужный модулей. Но движит им не utf8 =) иначе ни все эти модули для работы с кодировками стали бы ненужными. Они ими и станут, как тока php начнет работу на utf
Ну, высоконагруженные проекты - разговор отдельный совершенно :)
По поводу UTF8. Вы, видимо, имеете ввиду внутреннюю работу с юникодом? Будет в 6-й версии. Хотя обычно без этого спокойно можно обойтись, pcre понимает UTF8, ну и есть iconv и mbstring, и я не вижу ничего плохого в том, что это модули. Хотя, естественно, было бы удобнее работать с юникодом, не задумываясь :)
По поводу UTF8. Вы, видимо, имеете ввиду внутреннюю работу с юникодом? Будет в 6-й версии. Хотя обычно без этого спокойно можно обойтись, pcre понимает UTF8, ну и есть iconv и mbstring, и я не вижу ничего плохого в том, что это модули. Хотя, естественно, было бы удобнее работать с юникодом, не задумываясь :)
"при серьезной работе можно заметить что сессии мешают делать масштаб. Что если у вас в локалке несколько php тачек и сверху над ними какой-либо лоадбалансер? Ничего не остается как писать свою версию сессий через базу. "
Естественно, если не знать возможностей платформы, которую используешь, то "прийдется самому писать". Знающие используют session.save_handler.
Естественно, если не знать возможностей платформы, которую используешь, то "прийдется самому писать". Знающие используют session.save_handler.
>В PHP5 совершенно нормальная объектная модель, ничем не хуже других языков. Вы вообще знакомы с PHP5?
:) Объектная модель это не просто слово class, это подход к организации всего приложения. Попишите на том же руби и вы поймете о чем я)
:) Объектная модель это не просто слово class, это подход к организации всего приложения. Попишите на том же руби и вы поймете о чем я)
Я знаком с руби, хотя и не имел опыта работы. Каких-то существенных преимуществ в его объектной модели по сравнению с таковой в PHP5 не заметил. Ну да, там всё - объекты, и что с того? Главное - грамотная структуризация приложения, а PHP это позволяет делать.
Ну в php, например, нет перегрузки (overload) методов и классов =) А это на самом деле неотьемлемая часть ООП.
На самом деле можно конечно сделать перегрузку если, просто проверять тип входных параметров и пускать код по разным веткам. Но это ведь, согласитесь "не красиво". Смысл тогда вообще в ООП?..
А все потому что php интепритируемый язык и нетипизированный.
Еще не забывайте что библиотека функций у php процедурная. Какой бы чистый ООП ты не использовал в конце концов ты придешь к вызову процедур.
Поэтому ООП в PHP какой-то "нечетный" (то есть odd)
Я убежден, что во многом причиной ввода в пхп ООП было дань моде, особенно тот ООП, который был в четвертой версии. Там разработчики дали нам вожделенное слово class вместо настоящего ООП. =)
На самом деле можно конечно сделать перегрузку если, просто проверять тип входных параметров и пускать код по разным веткам. Но это ведь, согласитесь "не красиво". Смысл тогда вообще в ООП?..
А все потому что php интепритируемый язык и нетипизированный.
Еще не забывайте что библиотека функций у php процедурная. Какой бы чистый ООП ты не использовал в конце концов ты придешь к вызову процедур.
Поэтому ООП в PHP какой-то "нечетный" (то есть odd)
Я убежден, что во многом причиной ввода в пхп ООП было дань моде, особенно тот ООП, который был в четвертой версии. Там разработчики дали нам вожделенное слово class вместо настоящего ООП. =)
то, о чем вы говорите (перегрузка на основе типов аргументов, отсутствие функций), никакого отношения к ООП не имеет
Как это не имеет? Перегрузка - один из китов ООП.
Представим, хрестоматийный клас Shape.
Окружность можно построить по центру и радиусу, либо по трем точкам лежащим на этой окружности. Для этого перегружаем конструктор.
class Circle {
public Circle(point, radius){
// Реализация медода построения окружности по Радиусу и центру
}
public Circle(point1, point2, point3){
// Реализация медода построения окружности по трем точкам на окружности
}
}
На php нет такого механизма, а он мог бы пригодиться. Для реализации подобного этого нужно будет делать финты ушами.
Если перегрузка не имеет отношения к ООП, то что тогда имеет?
Может, вы один из тех, для кого ООП это слово Class? ;)
Представим, хрестоматийный клас Shape.
Окружность можно построить по центру и радиусу, либо по трем точкам лежащим на этой окружности. Для этого перегружаем конструктор.
class Circle {
public Circle(point, radius){
// Реализация медода построения окружности по Радиусу и центру
}
public Circle(point1, point2, point3){
// Реализация медода построения окружности по трем точкам на окружности
}
}
На php нет такого механизма, а он мог бы пригодиться. Для реализации подобного этого нужно будет делать финты ушами.
Если перегрузка не имеет отношения к ООП, то что тогда имеет?
Может, вы один из тех, для кого ООП это слово Class? ;)
UFO just landed and posted this here
В Воскресенье займусь этим. Тем более что удалил старые .make файлы. И Apache давно надо пере собрать.
тоже пересоберу php, так как стоит еще 4.*
UFO just landed and posted this here
То есть, вы предлагаете не писать об этом в блоге под названием "PHP"? ;)
UFO just landed and posted this here
UFO just landed and posted this here
Порассуждайте шире. Иначе с phpclub, например, надо выбросить 70 процентов обсуждений вообще. :)
Sign up to leave a comment.
PHP 5.2.4