Вы сильно заблуждаетесь вместе с MuToGeN  впрочем посмотрим ;)

У меня сейчас 2 заказа на промышленные приложения на PHP, из последнего над чем сейчас работаю это soap, distributed transactions etc. И надо сказать, что PHP интенсивно мигрирует в этом направлении.

Ну я в данном случае имел ввиду архитектуру работы, т.е. приложение - как JA или ActiveX или флеш. Я с ними не работал поэтому в каком они состоянии находятся плохо представляю. Но вы меня поняли.


Для бэкэнда ПХП уж слишком раздут... =) Хорош, не спорю, но раздут. 


Это какие? 
Загнется-то понятно не скоро, я про то, что куда тенденция пойдет крупных порталов, а частные странички аля я Вася Пупкин - да, будут делаться на ПХП, но, сам язык будет стоять на месте, ибо развиваться негде.


На то они и прошаренные. А вот вся 14-17 летняя милюзга, которая кое как написала 20 строчек кода и  считают себя мега программистами PHP? PHP дает возможностей много, а вот отличить профессионала очень тяжело...


Perl, который в свое время достиг максимум своего развития, между прочим - яркий пример. В область выше уровнем, он не вылез. Так и остался для своих shell-script целей... А писали на нем ой как много...
Это естественная эволюция.


Что вы называете промышленными приложениями? Что за контора их заказала? Что система должна делать?


Уровень выше - ГУЙ, а в ПХП это НИКАК не предусмотренно, а следовательно развивать некуда.

И



Тем не менее если глянуть на любое творение в виду сайта средних фирм...а таких огромное количество, то множество сайтов пишут на пхп, а огромных корпораций, которые всё хотят сделать "модняво" и накручено, что не факт, что хорошо, не так уж много. 

Я думаю что по своему смыслу как таковому, HTML, CSS, JavaScript, PHP, не только умрут не скоро, но и вообще фиг знает когда умрут, согласен, развитие рано или поздно прекращается, но использование этих технологий нисколько не сокращается...



Это сообщение отредактировал(а) ДобренькийПапаша - 22.7.2008, 16:30

Я называю промышленным приложением систему призванную обеспечить работу крупной компании.

Т.е. генерирующую и обрабатывающую от 100 до 10000 документов в день с сопутствующими им транзакциями. С соответствующими требованиями к надежности и устойчивости. Распределенную по времени и пространству. С возможностями интеграции с различными другими системами. С возможностью подключения произвольного набора переферийных устройств и т.д. и т.п. 


Какое-то однобокое представление о уровнях. PHP-GTK впрочем отвечает и на это странное предположение.
Я бы делил уровни по сложности и используемым технологиям... а не GUI vs Console.

Хотите вы того или нет, но сейчас очень много решений переносятся в веб. И в данном конкретном случае GUI предоставляют браузеры.
А это значит, что любое приложение пишется на нескольких языках. Как справедливо заметил nerezus на backend-роль отлично подходит PHP. На чем реализовывать frontend - это уже дело вкуса. Мне пока достаточно HTML+JavaScript.

Займут свои небольшую нишу, как Перл, например. А на ведущие позиции выйдут другие.


Вы меня извините, но работу крупной компании обеспечивают такие системы, как 1С, Axapta, Navision, SAP.
И вообще термина "промышленное программирование" не существует.
http://ru.wikipedia.org/wiki/Сравнение_язы...рограммирования


Транзакции к документам отношения не имеют, это раз. Два, даже 10000 - фигня...


Это общее требование.


Это как? Что такое распеределенное программирование я знаю. PHP на это не способен в принципе.
И эти задачи решают исключительно на других языках.


Это с какими простите? Мыши, Клавы принтеры, сканеры отменяются по любому, если брать девайсы, так сказать, не относящиеся к ПК, то как вы с ними работать собираетесь? Они все сидят на интерфейсах, с которыми ПХП работать в принципе не сможет. Ни RS-232, ни 422, ни 485, ни многие другие, а уровень поддержки TCP скорее всего будет недостаточен.


В данном случае для PHP это следующий вид эволюции. Тут "уровень" имелось ввиду концепций, гуй - консоль.


Если бы отвечало, на нем бы программы писали, а так, испоьзуют (т.к. я все-таки по большей части с С++ работал то и примеры к нему относящиеся) MFC, ATL, QT, boost и другие.
http://ru.wikipedia.org/wiki/Событийно-ори...рограммирование - в ПХП никакой событийности - нет.


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

Кхм,кхм. 
так и вертится вопрос про опыт в написании калькулятора - но не задам... "Как страшно далеки они от народа..."

Мне жаль, что приходится прописные истины объяснять тебе. Но слишком уж вызывающий тон у тебя при полной некомпетентности. 
Здесь Документ - это не веб-страничка. Это та правовая основа, которая разрешает и регулирует любой действие в крупных компаниях. 

Понятие транзакция относится не только к действиям в базе, но и вообще к любым завершенным действиям. И бизнес транзакция может включать в себя десяток транзакций в базе.

В бизнесе (в крупном) источник любых телодвижений с базой это документ/операция. Например Sales Order/продажа, Loan Order/заем/аренда etc. Каждый из этих документов/операций может порождать пачку производных от него равно как и транзакции в базе.

К примеру в Приватбанке ежедневный документооборот по платежным поручениям, в то время когда я там работал, был свыше 1млн штук в день. А в отдельных филиалах от 10т-100т.
А число транзакций в базе могло достигать полумиллиона только в одном небольшом филиале.


Не путаем distributed transaction и распределенное программирование. Это разные вещи...
Впрочем, ознакомся хотя бы с этим http://ru.wikipedia.org/wiki/%D0%A2%D1%80%...%86%D0%B8%D1%8F
и вот этим
http://en.wikipedia.org/wiki/Distributed_transaction



Различные barcode-scanners, принтеры, весы, кассовые аппараты и т.д. 
PHP поддерживает ПК - этого более чем достаточно. Все что не поддерживает TCP, легко оборачивается небольшими трансляторами написанными на чистом C.


Я возможно слишком умен, но зачем ему событийность?
Но что самое важное, кто сказал что ее нет в рамках веб, где он чаще всего и используется?

И вообще...
Поощряется использование MVC даже в декстоп приложениях, не говоря уже о PHP. Да я понимаю, что это зависит от уровня программиста.
Но поскольку сам я не совсем программист и тем не менее мне данная архитектура более чем удобна и прозрачна, то мне тем более удивительно слышать такое из уст специалиста.


Веб - позволяет это сделать с минимальным уровнем вхождения  И надо сказать что сейчас в мире доминирует принцип KISS, DRY и backward compatibility. Та же MS вышла в лидеры во многом благодаря сочетанию этих вещей.

Так что факты говорят за себя. 
На PHP можно писать экстремально нагруженные веб-приложения.
PHP имеет огромную базу в виде 20млн сайтов.

Так что достаточно лишь немного подождать и увидеть во что это все эволюционирует 

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

Опять не понимание.... Enterprise level application - такое существует?

Относительно тона я тоже самое могу сказать и по вашей фразе, что мы с мутогеном сильно ошибаемся ;)


Программная транзакция, которую надо спрограммировать - никакого реального отношения к документу не имеет, пока это не будет спрограммировано и сопоставлено, а тут уже документ некая программная сущность так или иначе представленная.


При наличии грамотно разнесенных для работы серверов пол миллиона транзакций для БД - не проблема. На сегодняшний день, конечно же.


Я несколько не правильно понял содержание вашего предыдущего поста.


1. поддержка ПК - далеко еще не все. Вы мне скажите, как в с COM портом в ПХП работать будете?
2. простая "обертка" тут не поможет, поскольску вам надо ей управлять, для винды это критично.



Для создания ГУИ приложений.


А где она есть? Покажите. __call и прочие - это не событийность...


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


Можно, не спорю, но именно веб-приложения, где нужно чтоб юзер обращался к информации по средствам HTTP, HTTPS протоколов.


И что? Сколько из этих сайтов сделано профессионально? Наиболее крупные корпорации, между прочим, ПХП не используют. По крайней мере 2 года назад, точно могу сказать, что ни Яндекс, ни Мэил на нем не работали (вроде как и рамблер).


Вопрос во что... В гуй? Нет... Этого не будет. Это 70% транслятора нынешнего надо писать...


По-моему, и как это озвучивали на Microsoft Bussines solutions называется это системы управления предприятием. О некоторых системах я говорил выше. Писать это на ПХП - самоубийство. По крайней мере на уровне NAvision & Axapta. Более простое еще может быть.

Никак.
Нет, это можно сделать на PHP - но глупо.

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


Это было 4 года назад. Впрочем, если сильно не вдаваться в подробности, там была система БД в филиалах с репликацией на основной сервер. И то и другое на Sybase, только разных версий.
Так что про объем транзакций в головном офисе я могу только гадать 



Model - база данных
View - html, javascript etc...
Controller - PHP.

со стороны клиента имеем обычый браузер для GUI. 
Вот пример, который я люблю показывать. http://extjs.com/deploy/dev/examples/desktop/desktop.html


С помощью их можно реализовать 90% типичных задач предприятий.


Представления не имею. Но полагаю счет идет на 10тки тысяч 


Да дался этот, прости господи, гуй... Это не вершина сложности в программировании 
Более того выше я уже давал схему.


С 5-7 недопрограммистами моего уровня - я бы взялся  где-то около года работы.

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

И да, для сотен документов в день я писал фактически в одиночку. Особенно мне понравилось работать с legacy DB. Я был просто в восторге от денормализованных таблиц на 100-150 полей.

Предыдущая попытка (до меня) делалась на java - они не прошли по производительности 
В текущем состоянии пока держимся 

оффтоп:ну вы тут нагородили...вы тему-то посмотрите, если всё так серьёзно, интересно было бы подискутировать в отдельной теме по поводу будущего вышеуказанных технологий, в частности пхп))))

Вот я как раз и про это. Управлять через COM порт на Винде вы не сможете 100%, вы просто визически не сможете закинуть в винду Device Control Block необходимый, для того, чтобы ОС разрешила работать с портом, как надо.


А как правило-то, работать тадо именно так.


Так клепать view на html - весьма затруднительно, по сравнению с визуальными средствами Delphi, MFC, Qt, etc...
А они уже содержат средства для организации контроллера.


По сути - обертка обертки... Не технологично.


что составляет 0.00N % =) Лично мое мнение, что счет идет на пару десятков тысяч даже...


Я к тому, что зачем использовать веб как промежуточный пункт, когда можно сразу наладить взаимодействие по TCP/IP. Когда задача еще в веб-интерфейсе (инет магазины), то тут да, другой вопрос.


Вы видели Navsion & Axapta в работе? Лично я видел только официальную демонстрация MS.Если не пить не есть, за год функционал написать может быть и можно, но при этомзабываем про отладку ;)


Я наверное несколько не так выразился в следствии чего моя мысль до вас не доходит как этого хотел бы я.
В данном контексте я имел ввиду развитие языка с точки зрения предоставления возможностей программисту. Для ПХП следующий этап - ГУЙ. Я согласен с вами, что ГУЙ это не верх сложности, да и сложность определяется задачей, а не технологиями или типом приложения, но куда ему развиваться дальше? Он и так превращается в большой фрэймворк %)

ДобренькийПапаша это модераторы при желании пусть тему расщипляют =)

Зато можно сделать абсолютно платформонезависимо  в отличии от...


Встречный вопрос, а меня видели в работе? 


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

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

пресловутая кроссплатформенность.

Моя последняя задача идет и на Linux и на Win2003 одинаково хорошо 

Ну почему... Да, Delphi, MFC - в этом плане тугие. А вот Qt- очень даже...
К тому же решается проблема стандартизации HTML кода, т.к. всем браузерам на эти стандарты по большому...


Нет, не видел, но не хочу вас обидеть ни в коем случае, но это нереально физически сделать за год систему аля Navision. полностью ее отладит... ИМХО, конечно.


Вот... Так вопрос-то изначально был в том, что эта ниша, имхо, будет подвинута, причем очень сильно ;)

И не пойдет он по пути ГУЯ... ну не будут разработчики 70% транслятора писать снова =)

А вот это очень интересный вопрос  кстати
Что проще, сделать кроссплатформенный html (на внешний вид плевать, пока говорим о функциональности)
или код на C/C++? 


Люблю невыполнимые задачи  Они интересны и за них очень хорошо платят.

Я бы поспорил, но 5х меня у меня нет 


Веб? Нонсенс 

С точки зрения времени однозначно кроссплатформенный гуй на С++ сделать легче, чем на html.
С точки зрения технологии... Ну тут зависит от программиста. Кое как наклепать html - дело не хитрое. Сделать качественно, подогнав под все браузеры - вопрос хороший.. В Сях это придется просто сделать...


Согласен, но есть реалии =)


gopher же подвинулся =)

Посмотрим 

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

Можно при желании провести эксперимент. Какой объем функциональности желателен?