Считаете ли Вы PHP текстовым интерпретатором, не предназначенным ни для чего более? Считаете ли целесообразным использовать эту кроссплатформенную технологию в других областях?

Legislative для чего тебе этот социологический опрос?

Чтобы понять, использует ли кто PHP в целях, отличных от работы с БД, разбором текста и применения ООП.

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

PHP используют в целях применения ООП? И где ж ты такое видел? 

Вы считаете, что это "текстовый интерпретатор"  
Я считаю, что PHP идеально подходит для web решений практически любого уровня сложности.

PHP: Hypertext Preprocessor — скриптовый язык программирования, созданный для генерации HTML-страниц на веб-сервере и работы с базами данных.

взять для примера мясорубку - она предназначена не только для того что бы молоть мясо, её можно и овощи и другое перерабатывать, так почему бы и РНР не использовать для чего то друго? Только следует задуматься, а надо-ли это?

Добавлено через 2 минуты и 32 секунды

а ICQ-бот в какое направление подходит?

Я как раз не считаю, что это "текстовый интерпретатор"

То Kangaroo : имелось ввиду, что для облегчения создания больших проектов можно применить ООП в том виде, в каком оно имеется в языке.

А я вот, в частности, использую php как встроенный скриптовый язык в приложении. Впрочем, как я его ни пристраивал, толком работать он начал только в составе web-броузера из того-же приложения, так что  получившийся монстр все равно очень напоминает Апач. (Как не собираю, все равно автомат получается ;-()

То MoLeX : работа с сетевым траффиком по сути есть разбор данных/текста.

тогда практически все что связано с вебом можно отнести к разбору данных\текста 

А как насчет работы с портами (я задавал такой вопрос, и оттуда решил поднять такой опрос) и соответственно насчет работы с подключенным оборудованием?
А как насчет создания процессов, которые бы в фоновом режиме отрабатывали, пока обрабатывается десяток запросов?

Ну, траффик бывает разный. Есть текстовые протоколы, такие, как FTP, SMTP, HTTP. И с ними проблем нет.
асечный же протокол, как мне кажется - бинарный. Хотя я и могу ошибаться.
С другой стороны, и с бинарным, в общем-то, работать не сильно сложнее, чем с текстовым. 

Другое дело, есть такое понятие, как "специализированный язык".
К примеру, в PHP есть туча специализированных функций для работы с HTTP - header, setcookie, apache_request_headers и прочая и прочая. Ни одной для работы с ком-портами я не видел.
В массиве $_SERVER - море переменных, относящихся к веб. И ни одной - к аппаратной части.

Добавлено @ 12:25
В этом смысле PHP - язык не столько для работы с текстом (в этом деле король - перл), а именно для работы с веб.
И именно в этой роли он вышвырнул перл с веб-серверов начисто. Хотя перл во многом мощнее пыха в работе с текстом.
То есть, специализация что-то, да значит.

А в плане работы с аппратным обеспечением пхп ничуть не лучше шелла или того же перла, или бейсика. 
И, насколько я могу судить по своему опыту, фразы типа "универсальный кроссплатформенный язык" обычно говорят люди, которые просто никаких других языков не знают. Обычно. Не всегда, но часто.

А ещё я хочу задать вопрос Legislative.
Скажи, все выскажутся против - ты откажешься от своей идеи писать работу с портами на РНР?

Это сообщение отредактировал(а) Feldmarschall - 24.3.2008, 12:36

Просто не стоит закрывать глаза на правду. Абривиатура PHP уже должна что-то говорить.
Да, пхп можно и кофе научить делать но ОСНОВНОЙ задачей пхп является работа с web-сервисами.


Legislative, тебя никто не будет останавливать, это было бы неправильно, но просто подумай, надо ли оно тебе?

делаю им всё, что лень делать руками

наверно, потому, что я его лучше знаю, чем другие языки

к примеру, вместо того чтобы разбираться с прогами по конвертированию изображений в нужные мне размеры и типы, легче было написать этот самый конвертор на пхп

bars80080, вот только этих самых форматов - кот наплакал =)

это так первое что вспомнилось

может быть, но задач неисчислимое море, а искать под каждую прогу, ни времени, ни желания, 

В Adobe Photoshop есть ф-ция batch, которая позволяет обрабатывать целые массивы файлов - это будет поудобнее, чем на php, да и возможностей заведомо больше, т.к. можно применять все фильтры и преобразования.

Legislative, отлаживать программу на языке, изначально не расчитанном на "низкоуровневые" задачи - спорная идея.
смотри, как бы тебе в обходах тех "подводных камней" при работе с портами, о которых ты спрашивал, не пришлось писать/искать монитор(исключительно для отладки). И, опять же, не PHP будешь искать, а уже CGI.

возможно, но там ведь не реализуешь простейшую комбинацию if...else

bars80080, где? на С++?

Возможно, но мне она как-то была не нужна ) К примеру тебе надо сделать всем картинкам определенный размер, то просто прописываешь увеличение до это размера и картинки меняются, при этом  те, которые были уже увеличены, соответственно, не меняются. Или ты хочешь генерировать случайное слово а затем наносить его как водяной знак? Для такого наверно не получится, да. Хотя я точно не могу сказать  относительно условий.

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

 в фотошопе. я ж говорю, что пхп знаю лучше чем остальное, а C то ++ вообще нет.

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

я такое на пхп тоже делал. хочу сказать что отлично все получается ) и нафиг фотопоп ненужен

И я такое делал... Потом, правда, переделывал в IfranView, качество оказалось посредственным... 

а вообще пункт "нет, PHP может все и не надо зацикливаться на этом", это правокационно просто ) я бы тоже хотел так ответить, иначе обидно становится )

Просто на фотошопе быстрее чем писать программу, вот для чего. Кликнул пару раз, поставил на обработку и ушел. А прогой то все ришишь, но по времени не всегда эффективно.   

ksnk, вот вот. Фельдмаршал уже обмолвился о том, что GDI достаточно дохленькая - к примеру нельзя задать качество сжатия jpeg - это же несерьезно. В принципе наверно нормально получилось c imagemagick.

Как это нельзя?

 

Но это не значит, что надо на PHP писать работу с компортами и прочим.

Fortop, спасибо, полезное замечание. Может быть GDI ещё может работать с анимированным GIF (это вторая проблема, с которой сталкивался)?

Насколько помню нет. Т.е. конвертирует оно их конечно - да. но только 1й кадр.

flashaa, нет, GD с анимированным гифом работать не умеет.
Но здесь важно не техническое умение, а на мой взгляд, принципиальная невозможность делать ресайз анимации. Слишком много тонкостей. рассинхронизация всего на один пиксель, что обычное дело при округлении, приведет к появлению белых пятен - и так далее. 
Размер, опять же, у анимашек обычно мелкий. Не говоря уже о размере отдельных фреймов. А что получается при уменьшении мелких картинок - лучше вообще не смотреть. Лучше уж тогда отключить антиалиасинг. А если его отключить, что получатся рваные края и те же белые пятна.

Я же говорил не о качестве джипега, а о мизерном количестве поддерживаемых форматов.



Это сообщение отредактировал(а) Feldmarschall - 24.3.2008, 16:16

ну, всё же подразумевается, что юзать пхп будет человек из вэба, а значит он побольшей части пользует три стандарта

кстати, "пхп может всё" - вылез вперёд

Гы!
 
Как бы логично было бы "разбирать" тот самый html, препроцессором которого PHP и является..., однако без DOM, который толком вставлен только в 5-й PHP, разбирать html неэффективно. Мелкие задачи грабинга текстов и патчинга шаблонов, которые вполне поддаются несложным регуляркам, вряд ли стоит назвать - "разбор текста". 

 Вместе с производительностью компьютеров? Ну, в принципе, 5-й PHP работает немного быстрее 4-го, однако и рессурсов ест побольше... Принципиального развития язык не получил, разве что деструкторы объектов - вешь, которую сложно адекватно имитировать на php-4, остальное переписывается на 4-ку практически без потери функциональных особенностей. Я чего-нибудь упустил? ну, понятно, библиотечных функций стало поболе...


Не всё , анимированные гифки - не умеет..., но любим мы его не за это   

Абсолютно согласен.

3 вариант ответа.

не совпадает по смыслу с 

To Feldmarschall:
1) php не первый мой язык, начиналось все с Паскаль, затем с/с++, ассемблером некоторое время занимался (и для ПК, и для микроконтроллеров), затем знакомился с php, Flash-технологиями и ActionScript 2, предпоследнее - perl, последнее C#.
2) все выскажутся против - не откажусь от своей идеи писать работу с портами на РНР, но стану относится к этому со скептицизмом.
Я получил дельный совет от awers (к сожалению не смогу ему добавить репутации). Но параллельно я все же напишу такой же код на php и сравню их работу.

То awers:
Нужно оно ли мне? Конечно.
Я смотрю на то, что возможная работа с портами на php и С++ мало чем отличается. Поэтому может есть смысл пробовать делать такие вещи и на php. Не хочется смешивать несколько языков в одном проекте. Здесь еще такой момент - подобные проекты могут делаться одним программистом php, а не двумя php и С++, значит это будет ПРОЩЕ с точки зрения организации проекта.

Legislative, маловероятно что в никсах будет открыт доступ к девайсам для wwwroot, а на винде и вовсе своя политика безопасности по отношению к портам.

Будет свой сервер. Мы его отконфигурируем так, как надо.

Добавлено через 3 минуты и 30 секунд
А вот с виндой действительно может выйти казус

А в винде так нужно будет делать в приложении на C++:
1)CreateFile("COM1")
2)DeviceIOControl
.....

Добавлено через 9 минут и 28 секунд
да еще с асинхронным вводом/выводом. Прелесть!

Добавлено через 10 минут и 35 секунд
Значит для виндовой реализации соответствующего модуля php проблем нет.