LINUX.ORG.RU

"Тихо и незаметно" -- любимое вступление! Заблаели!!!

anonymous
()

Кто-нибудь может прокомментировать почему у нас в университете продается книга с названиемPHP4/5 -что пятый уже есть? Или как понимать название?

wieker ★★
()
Ответ на: комментарий от anonymous

В алфа-бета тестировании еще с прошлого года...

anonymous
()
Ответ на: комментарий от Deleted

Опасно, а вдрух пхп-кодеры найдут трубу и как ударят ночью по бышке из-за угла, и очень убедительно попросят убрять его с сервака... ;))

BSDun
()
Ответ на: комментарий от anonymous

Ошибаешся, полезных тут нет вообще. Я просто сообщил об этом.

anonymous
()

Люди, может кто сталкивался...

Поставил phpAdsNew(ногами не пиннать! - начальство захотело - типа, красиво, блин) На 4.3.4 работала, на 4.3.5 и 4.3.6 - половина функций не работает. В логах - ничего вообще нет, хотя выставил по максимуму. Приходится сидеть на 4.3.4, а меня это немного напрягает, т.к. многое поправили в 4.3.6 Выкачал из cvs current версию phpadsnew - та же самая картина :( Региться на ихнем форуме - желания нет, да и не отвечают они почти.

Deleted
()
Ответ на: комментарий от Deleted

> Dimez -- без обид - не стоит на этом форуме такие вопросы задавать, лучше официальной рассылкой пользоваться.

anonymous
()
Ответ на: комментарий от anonymous

Когда руки кривые, тады да, тормозит и глючит..

PHP, конечно, летает, но вот для чего-то большого, ну совсем непригодное. К сожалению, находятся пионеры пытающиеся на нём Content Managment System писать.

eRazor ★★★
()
Ответ на: комментарий от eRazor

К вопросу о "непригодности для чего-то большого":

> PHP scales. There, I said it. The word on the street is that "Java scales and PHP doesn't." The word on the street is wrong, and PHP needs someone to stand up and tell the truth: that it does scale.

http://www.onjava.com/pub/a/onjava/2003/10/15/php_scalability.html

int19h ★★★★
()
Ответ на: комментарий от eRazor

Content Managment System == что-то большое? А маленькое запрещено?
А примеры большого, но непригодного можно? ;)
Ламерьё! Только губами шлёпать горазды.

anonymous
()
Ответ на: комментарий от anonymous

CMS Может быть достаточно большим, что б его большим называть. Ты готов аргументировать аль так просто погубошлёпствовал?

eRazor ★★★
()
Ответ на: комментарий от int19h

> PHP scales. There, I said it. The word on the street is that "Java scales and PHP doesn't." The word on the street is wrong, and PHP needs someone to stand up and tell the truth: that it does scale.

Любопытная статья, комментарии к ней ещё интереснее :-)

Я не хочу вдаваться в споры о производительности PHP и производительности оппонента PHP приведённого в статье -- Java. В быстродействие Java мои проекты никогда не упирались, а вот с черезмерно превышенными сроками при написании больших проектов на PHP я не раз сталкивался.

Лично мне мешают в больших проектах: процедурная ориентированность PHP, отсутствие строгой типизации, маленькое количество "гуру" пишущих на PHP пришедших с "больших" языков в следствии чего отсутствуют стндарты кодирования как таковые и плодятся в большом количестве отвратительно структурированные поделки, авторы которых о проектировании вообще ничего не слышали.

Ну, в общем, вот.

p.s. Желающие обсудить ламеризм могут считать заранее посланными себя куда им фантазия подскажет ихняя..

eRazor ★★★
()
Ответ на: комментарий от int19h

> PHP scales. There, I said it. The word on the street is that "Java scales and PHP doesn't." The word on the street is wrong, and PHP needs someone to stand up and tell the truth: that it does scale.

Больше всего мне вот этот ответ понравился:

I have programmed in both langauages for some time and have my opinions about both. While PHP is great for some things I feel it is completely not for others. One reason behind this is because PHP is basically a procedure based programming language and thus is harder to manage in larger projects with multiple people working on them. And mixing biz logic in the view can lead to all sorts of problems down the road. I know that PHP has objects you can use but have you ever actually tried to create a MVC based application with php objects? Can get pretty messy. On the other hand java is horrible for smaller projects because of the amount of planning and coding it takes to do smaller things. While easier to maintain and in my opinion much cleaner it is very easy to create enterprise applications seperating the biz logic from the presentation. But as I said I think both languages are great in their own grown. But they are totally different beast. Just my two cents.

eRazor ★★★
()
Ответ на: комментарий от eRazor

> CMS Может быть достаточно большим, что б его большим называть.

Не понял, что ты хотел сказать. Я просил прокомментировать вот эту твою фразу:

"но вот для чего-то большого, ну совсем непригодное. К сожалению, находятся пионеры пытающиеся на нём Content Managment System писать."

Что тако "большое" и какие проблемы с написанием CMS для PHP?

anonymous
()
Ответ на: комментарий от eRazor

> Лично мне мешают в больших проектах: процедурная ориентированность PHP

Дык так бы сразу честно и признался: Процедурно програмить не можешь.
Только при чём тут язык (какой бы он ни был)?

anonymous
()
Ответ на: комментарий от eRazor

> и плодятся в большом количестве отвратительно структурированные поделки, авторы которых о проектировании вообще ничего не слышали.

О каких авторах идёт базар? Спросили конкретно тебя, то есть ты и есть
автор, и отвечаешь от своего имени ;)

anonymous
()
Ответ на: комментарий от eRazor

> One reason behind this is because PHP is basically a procedure based programming language and thus is harder to manage in larger projects with multiple people working on them.

По-моему это бред. Можно подумать, что до появления ООП писались только
очень маленькие проекты, и было это трудно-трудно. А с приходом ООП
скорость и легкость написания взлетела как ракета.

> And mixing biz logic in the view

И это бред. Какая связь между стилем программирования и смешиванием
вьюшек с бизнеслогикой?

> I know that PHP has objects you can use but have you ever actually tried to create a MVC based application with php objects?

Постоянно. Можно узнать, в чём заключается Великая Проблема
использования MVC в php?

anonymous
()

Моё заключение такое: люди, типа eRazor совершенно не задумываясь
повторяют чужие рекламные слоганы.

anonymous
()
Ответ на: комментарий от anonymous

>Не понял, что ты хотел сказать. Я просил прокомментировать вот эту твою фразу:

Я это к тому сказал, что к нам 3 проекта на ПХП написанные пришли один за другим на переделку. В двух из них в основе лежит postNuke. Проекты имеют весьма немаленькие размеры и представляют из себя полнейшую кашу.

Проблемы с написанием CMS на PHP в том, что сам язык не располагает писать на нём что-то стройное. Покажи мне одну CMS хорошо написанную на нём, мне весьма любопытно посмотреть будет.

eRazor ★★★
()
Ответ на: комментарий от anonymous

>О каких авторах идёт базар? Спросили конкретно тебя, то есть ты и есть автор, и отвечаешь от своего имени ;)

Я в конторе работаю которая занимается доработкой/переносом софта. Мне много чего приходит. Абсолютно не знаю что тебе ответить, т.к. те авторы про которые я говорю для тебя так и останутся гипотетическими. Я излишне категоричен т.к. ни разу ничего хорошего мне на переработку не попадалось, что на PHP было написано.

eRazor ★★★
()
Ответ на: комментарий от eRazor

> Я это к тому сказал, что к нам 3 проекта на ПХП

Очень репрезентативная выборка. Других аргументов нет?

> сам язык не располагает писать на нём что-то стройное.

Ну опять частное мнение без фактов. Нет, так не интересно разговаривать.
Показать можно, например, http://phpwebsite.appstate.edu/

anonymous
()
Ответ на: комментарий от anonymous

>Дык так бы сразу честно и признался: Процедурно програмить не можешь. Только при чём тут язык (какой бы он ни был)?

Процедурный подход, конечно, долгое время использовался и на нём не одну тонну кода написали и пишут и как здесь заметили и большие проекты на нём также писали/пишут, но такая вещь как инкапсуляция весьма удобна и полезна и не от балды появилось объектно-ориентированное программирование. Я думаю, оно всё-таки поудобнее будет для больших проектов. А процедурно я писать умею, просто лично мне и ещё громадному количеству людей во всём мире удобнее использовать классы и объекты.

eRazor ★★★
()
Ответ на: комментарий от anonymous

>Моё заключение такое: люди, типа eRazor совершенно не задумываясь повторяют чужие рекламные слоганы.

Зря ты так :-(, я сказал то что думаю исходя из опыта своей работы, a не из опыта чтения бестселлеров A vs B.

eRazor ★★★
()
Ответ на: комментарий от anonymous

>Показать можно, например, http://phpwebsite.appstate.edu/

Ок, thanx.

Я его поковыряю пару недель, потом в Develop всплыву с топиком, тогда поговорим предметно об конкретно phpWebSite.

eRazor ★★★
()
Ответ на: комментарий от eRazor

Что-то плохо улавливаешь мысль. Ты написал "и плодятся в большом
количестве отвратительно структурированные поделки, авторы которых".
А я хотел сказать, при чём тут какие-то авторы, говори от своего имени
что конкретно плохо, если действительно имеешь опыт разработки на php.
Что, на жабе все пишут идеально? Плохих авторов найти можно в любом
языке. С другой стороны, если что-то приносят для переработки, то
вполне резонно предположить, что ЭТО написано плохо. То есть ты
сталкиваешься практически с одним лишь плохим софтом. Отсюда вывод -
высказывания твои предвзяты и не объективны.

anonymous
()
Ответ на: комментарий от eRazor

> Лично мне мешают в больших проектах: процедурная ориентированность PHP

В четверке с этим дела обстоят не так уж и плохо. Да, сам API на девяносто процентов процедурный. Но свой код вполне можно оформлять в объекты.

Ну и, разумеется, ждем стабильную пятерку. =) Вот выйдет - посмотрим, как оно с JSP сравнится.

> отсутствие строгой типизации

Оччень спорный момент. Типизация - она еще неизвестно, Right Thing или нет (если отбросить производительность, что в данном случае некритично).

> маленькое количество "гуру" пишущих на PHP пришедших с "больших" языков в следствии чего отсутствуют стндарты кодирования как таковые и плодятся в большом количестве отвратительно структурированные поделки,

Это беда любого простого в освоении языка. Но лечится со временем =) А стандарты, они есть, если сильно захотеть. Проблема в том, чтобы заставить людей им следовать. Только для этого надо в каждой книжке/мануалу по PHP вдалбливать что "правильно делать так" - ну, как в случае с явой. Кому надо, сами разберутся, что можно еще вот так и вот так (и получается не хуже), а кому не надо, те хотя бы перевариваемый код писать будут. Ну в общем это не проблема собственно языка.

int19h ★★★★
()
Ответ на: комментарий от eRazor

> в конторе работаю которая занимается доработкой/переносом софта.

Нну... согласись, что доработка, и разработка с нуля - это все-таки слегка разные вещи =) Да, PHP нынче популярна в стране Пионерии, и следствие этого - вот такие "проекты", про которые ты рассказываешь. Но язык в этом не виноват, и его вполне можно использовать _правильно_, не хуже, чем яву.

int19h ★★★★
()
Ответ на: комментарий от anonymous

>А я хотел сказать, при чём тут какие-то авторы, говори от своего имени что конкретно плохо, если действительно имеешь опыт разработки на php.

Ок, я в принципе, сказал уже. Самая большая вещь, что мешает мне это его "процедурность". Спорить не будем, что классы в 4 PHP это только название? Я говорил, что умею писать процедурно, но я не умею писать процедурно и гибко. Софт написанный не является чем-то монолитно неизменяемым типа памятника. Он потом часто возвращается на переделку и улучшение. Думаю с этим спорить никто не будет, так вот, я человек ленивый и предпочитаю заранее заботится об возможных изменениях. Используя процедурный стиль этого крайне трудно добиться, т.к. в общем случае в процедурных языках это сводится к постоению конструкций манипулирующих указателями на функции (ну или тем, что заменяет их). Во-первых, оно имеет ограниченность применения, а во-вторых это имеет довольно неуклюжий синтаксис. Используя ОО парадигму мне удаётся добиваться достаточно элегантных и гибких решений, благо есть где поучиться -- "Design Patterns" GoF и иже с ними труды -- вышло достаточно много всего посвящённого проектированию приложений. Например, можно сделать такую классную вещь как развязать алгоритм и его реализацию. С процедурным стилем элегантно сделать это невозможно, придётся эмулировать vmt.. И кроме общих рекомендаций по стилю в мире литературы касающейся процедурной парадигмы я ничего не встречал. (Если кто знает чего стоящего -- подскажите). Так вот исходя из вышенаписанного я считаю PHP не очень подходящим языком для написания больших проектов.

То, что я написал является лично моим мнением построенным на лично моём опыте работы.

eRazor ★★★
()
Ответ на: комментарий от int19h

>> отсутствие строгой типизации >Оччень спорный момент. Типизация - она еще неизвестно, Right Thing или нет (если отбросить производительность, что в данном случае некритично).

Ну, скажи, ты ошибки/описки делаешь? Я делаю. Очень раздражает не выплёвывание ошибки, а запуск программы и дальнейшее её загадочное поведение. Когда код по объёму небольшой -- отсутствие строгой типизации удобно, а вот когда полно всего, это мешать начинает. В принципе, я эти ошибки быстро нахожу, но лично мне было бы удобнее в момент компиляции/интерпретации сообщение об ошибке с указанием номера строки получать.

eRazor ★★★
()
Ответ на: комментарий от int19h

>Нну... согласись, что доработка, и разработка с нуля - это все-таки слегка разные вещи =) Да, PHP нынче популярна в стране Пионерии, и следствие этого - вот такие "проекты", про которые ты рассказываешь. Но язык в этом не виноват, и его вполне можно использовать _правильно_, не хуже, чем яву.

Я согласен с тобой, но одновременно я согласен и с Луговским, который после N- ного исправленного проекта на C++ стал плеваться на него, при всём при том что C++ я просто обожаю. (Он об этом бурные дискуссии разводил в фидо несколько лет назад)

eRazor ★★★
()
Ответ на: комментарий от eRazor

> но я не умею писать процедурно и гибко.

Вот эти слова надо было написать сразу. Было бы коротко и понятно.
И не нужно было бы выписывать километры особых мнений. ООП - такая же
вредная привычка, как процедурное программирование. Противно становится
тогда, когда начинают спорить на тему "а моя вредная привычка лучше
чужой вредной привычки".

anonymous
()
Ответ на: комментарий от int19h

>Но язык в этом не виноват, и его вполне можно использовать _правильно_, не хуже, чем яву.

Кроме самого языка существуюет еще комьюнити, существующий наработки, фреймворки, стандарты и т.д. Например опытный разработчик может писать правильно и там и там, но он скорее выберет Java потому что например для CMS он может взять качественный MVC фреймворк типа струтса или tapersity, может взять slide и сразу получит WebDAV-репозитарий, пользователей с правами доступа, транзакционную работу с данными, легко заменяя-дополняя нужное. Если смотреть с точки зрения дизайнера или начинающего разработчика, то php обеспечивает более быстрый старт, для многих случаев готовые решения. Иногда эта легкость обманчива и оборачивается неподдерживаемой системой, не готовой к изменениям требований, иногда окупается низкими затратами. Однозначного выбора нет.

anonymous
()
Ответ на: комментарий от anonymous

>> но я не умею писать процедурно и гибко. >Вот эти слова надо было написать сразу. Было бы коротко и понятно. ООП - такая же вредная привычка, как процедурное программирование. Противно становится тогда, когда начинают спорить на тему "а моя вредная привычка лучше чужой вредной привычки".

Стало быть парадигма стала теперь вредной привычкой?

Обычный высокомерный ответ не несущий в себе кроме негатива вообще ничего. Что ты хотел сказать: что ты умеешь большие объёмы кода процедурно писать так, что потом его леко перерабатывать, что в принципе существуют методики позволяющие процедурно писать так, что код потом легко переработке поддаётся? Ы??? Или слова "Было бы коротко и понятно" означают недостижимую крутость и нежелание общаться с плебеями? Если да, то твой тезис "Ламерьё.." я уже послушал..

eRazor ★★★
()
Ответ на: комментарий от eRazor

> Ну, скажи, ты ошибки/описки делаешь? Я делаю. Очень раздражает не выплёвывание ошибки, а запуск программы и дальнейшее её загадочное поведение.

Такие, от которых спасает строгая типизация - не делал уже давненько. Видимо, успешное освоение PHP и питона дает о себе знать =)

int19h ★★★★
()
Ответ на: комментарий от eRazor

> Спорить не будем, что классы в 4 PHP это только название?

Будем. Чего тебе в них не так? С точки зрения синтаксиса - да, не хватает некоторых вещей, например, цепочного вызова методов: $foo->bar()->baz(). Но соответствующая функциональность все равно есть, просто реализуется обходными путями. А так вроде всяческие инкапсуляции с полиморфизмами наличествуют, ну и чем вам это не OO?

int19h ★★★★
()
Ответ на: комментарий от eRazor

> что в принципе существуют методики позволяющие процедурно писать так, что код потом легко переработке поддаётся?

Да. Просто тебя этому никогда не учили. Сызмальства тебе сказали:
ООП - гуд, процедуры - бэд. Ты скушал, и никогда не ставил данный тезис
под сомнение.

anonymous
()
Ответ на: комментарий от int19h

>Такие, от которых спасает строгая типизация - не делал уже давненько. Видимо, успешное освоение PHP и питона дает о себе знать =)

Прошу извинить, я подменил понятия. Я говорил о механизме вывода типов, который определяет тип переменной исходя из контекста.

eRazor ★★★
()
Ответ на: комментарий от anonymous

>> что в принципе существуют методики позволяющие процедурно писать так, что код потом легко переработке поддаётся?

>Да. Просто тебя этому никогда не учили. Сызмальства тебе сказали: ООП - гуд, процедуры - бэд. Ты скушал, и никогда не ставил данный тезис под сомнение.

Нет, я начал программировать когда об этом вообще не говорили. Во времена Радио86РК публикаций об программировании доступных мне, не было. Скажем так -- я прошёл естественным путём через процедурное программирование к ООП.

Хорошо. Скажи где почитать об этом, я очень не против пробел в знаниях убрать.

eRazor ★★★
()
Ответ на: комментарий от int19h

Всё торчит наружу как public методы, отсутствие static методов и классов, отсутствие константных объектов внутри классов, и какой полиморфизм, когда и так любой объект является как бы полиморфным? Это херит существующие ООП методики делая их применение бессмысленным. Так же отсутствие множественного наследования хотя бы интерфейсов.

В чём инкапсуляция заключается, когда методы закрыть нельзя?

eRazor ★★★
()
Ответ на: комментарий от int19h

Сами авторы говорят что до PHP5 OO в PHP больше походило на работу с ассоциативными массивами с дополнительными возможностями........

Например: работа ведется напрямую с объектом а не с указателем на него с вытекающими отсюда последствиями... А отсутствие private,protected - полей , методов... перевод по адресу http://detail.phpclub.net/article/2004-01-07

Вот в 5-ой версии действительно в объектную модели внесены серьезные изменения и объекты наконец то становятся объектами :)

про ОО в PHP5 смотри статью http://detail.phpclub.net/article/crossing_php5

anonymous
()
Ответ на: комментарий от anonymous

Да знаю я, что в пятёрке будет. Я говорил про здесь и сейчас, что мы имеем. И Int19H говорил насколько я понял про текущее положение вещей.

eRazor ★★★
()
Ответ на: комментарий от eRazor

>Будем. Чего тебе в них не так? С точки зрения синтаксиса - да, не хватает некоторых вещей, например, цепочного вызова методов: $foo->bar()->baz(). Но соответствующая функциональность все равно есть, просто реализуется обходными путями. А так вроде всяческие инкапсуляции с полиморфизмами наличествуют, ну и чем вам это не OO?

>int19h (*) (19.04.2004 14:02:32)

Так вот я как раз и говорю что то что есть сейчас в 4-ой версии не ОО а жалкое подобие... И писать большие проекты с использованием такого ОО чревато, увеличением сроков разработки и/либо несметным количеством багов

anonymous
()

Ладно, вопрос к eRazor на засыпку: почему абсолютное большинство
реально работающих интернет-магазинов не пишется на java, а пишется на
php. Среди них есть довольно большие и дорогие проекты, в которые
вложено немало денег. Почему так происходит? Ведь судя по твоим словам -
это вотчина джавы.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.