IBM заключила соглашение с разработчиками PHP

>что ты тут не по делу чё-то сказал... :)
я хоть и не он, однако думаю что саныч имел ввиду как раз наличие логина/пароля на доступ к базе иначе причем тут insert/update ? вот как в случае с этим phpAdmin'ом - прочитали php файл, узнали логин/пароль а дальше сделали delete или update уничтожив все данные. А если у этого логина/пароля нет прав на delete/update, а есть права только на вызов встроенных процедур данные не уничтожишь.

>Да, я пишу вебприложения на плюсах под FreeBSD.
Да месье знает толк в извращениях ! Бредятина полнейшая ибо что C++, что ASM, что PHP в данном случае упираются в базу. Вот только PHP (или perl кому-как) заточены под web гораздо лучше и хоть быстрее они конечно не будут, но скорость разработки на них будет быстрее на порядки не говоря уже о удобстве поддержки.

Чем то мне это prolog напоминает.

>Те же MySQL AG дошли наконец-то до этого и начали разработку >процедурного языка для пятой версии.
Очень интересно что за язык это будет !

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

>Приложение более чем серьезное.
>Вот это приложение: http://go.mail.ru/
Муа-ха-ха, http://validator.w3.org нашел на этой странице 139 ошибок :)

>где использовать PLSQL, а где проще использовать внешний язык

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

> Беда в том, что ПХП *заставляют* уметь все.

Ты про PHP5? Это маркетинг в чистом виде. Сначала одни воротят нос от PHP даже там, где его применение рационально, мотивируя это тем, что PHP - "недоязык". Тогда PHP'шники прикручивают туда всякий там ООП и прочее. Пеар в чистом виде =)

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

Это проблемы проектов, а точнее, тех, кто ими руководит.

> на котором по лицензионному соглашению недопустимо использовать кеширование результатов вывода.

Это как?? В смысле, законность кэшей и их перпендикулярность всяким там копирайтам, насколько я помню, установили даже в США... если не секрет - что за область хотя бы?

> Технологически .Net может быть и более приятна (в силу разных языков хотя бы)

Вот как раз технологически - далеко не факт. JDBC удобней ADO.NET, а аналога EJB в .NET просто нет...

> но вот работает она пока только на 1-й платформе (Mono не в счет пока) и поддержки со стороны сторонних вендоров, такой как Java не имеет.

А вот этого как раз и не надо. На _виндовом_ рынке, на который оно нацелено, и который сам по себе немаленький, поддержка одного Microsoft - выше крыши. Особенно когда они начинают проталкивать технологию как часть системы ("Windows Server 2003, теперь со ВСТРОЕННОЙ поддержкой платформы .NET и ASP.NET Веб-сервисов!").

>Вот как раз технологически - далеко не факт. JDBC удобней ADO.NET

Ты забыл добавить ИМХО :)

>Муа-ха-ха, http://validator.w3.org нашел на этой странице 139 ошибок :)

А плевать.Сайт показывается в Опере, Мозилле и Эксплорере. До валидатора дела нет ну никакого. Вам надо эстетствовать? Эстетствуйте ради бога. А нам нужна коммерческая выгода.

>Да месье знает толк в извращениях ! Бредятина полнейшая ибо что C++, что ASM, что PHP в данном случае упираются в базу.

Юноша, где я хоть словом обмолвился про базу? И тем более про SQL СУБД? И смею Вам уверить, узкое место - это отнюдь не то, что вы называете словом "база".

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

Они будут не просто медленнее, а *катастрофически* медленнее. И стоимость поддержки кластера машин и разработки кластерного ПО на таких языках будет много дороже, чем поддержка проекта на С++.

>Это как?? В смысле, законность кэшей и их перпендикулярность всяким там копирайтам, насколько я помню, установили даже в США... если не секрет - что за область хотя бы?

Низя кешировать результаты поиска. Да это и бесполезно, если учесть количество повторяющихся запросов.

вообще есть Ruby - замечательная замена PHP, как язык по сравнению с ним пыхпых находится в прошлом веке, ибо он в сути своей процедурно ориентированный, что влечет за собой сложности при разрастани проектов и повторном использовании кода .. руби, как молодому языку нужна более быстрая реализация, больше либсов на разные случаи жизни и хорошие mod_ruby для веб серверов, тогда imo php можно будет сдавать в утиль, а юные веб программеры не будут засорять себе мозги разным мусором :) ну а пока же PHP в своей нише безусловно доминирует, а IBM этим обстоятельством решила немного попользоваться ..

>А плевать.Сайт показывается в Опере, Мозилле и Эксплорере. До >валидатора дела нет ну никакого. Вам надо эстетствовать? Эстетствуйте >ради бога. А нам нужна коммерческая выгода.
А упущенная выгода вам нужна ? :))) Очень показывает ваше отношение к делу и профессионализм :)))

> Ты забыл добавить ИМХО :)

Не забыл. Покажи мне, например, backend-независимую работу с DataAdapter/DataSet на C#. Т.е. чтоб функция брала IDbConnection, а на выходе был DataSet с данными. Или вот такая простейшая вещь - получить значение поля с автоинкрементом после очередного INSERT'а, опять же, не завязываясь на специфику СУБД.

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

В Ruby сложнее въехать, с его итераторами и чистым ОО-подходом. В определенных кругах это является недостатком. Все равно, что людей с VB на Eiffel пытаться пересадить =)

>Юноша, где я хоть словом обмолвился про базу? И тем более про SQL СУБД? >И смею Вам уверить, узкое место - это отнюдь не то, что вы называете >словом "база".
>Они будут не просто медленнее, а *катастрофически* медленнее.
CGI, для работы не с базой, катастрофически медленннее... Объяснитесь !

>А упущенная выгода вам нужна ? :))) Очень показывает ваше отношение к делу и профессионализм :)))

Упущенная выгода от чего? Вы всерьез считаете: что пользователи постоянно ползуются валидатором и проверяют HTML ? :)))))))

>CGI, для работы не с базой, катастрофически медленннее... Объяснитесь !

Просите, вы о чем? Где есть хоть слово про CGI?

>Упущенная выгода от чего?
без комментариев :)))

>Вы всерьез считаете: что пользователи постоянно ползуются валидатором и >проверяют HTML ? :)))))))
Конечно не считаю. Я и w3.org считаем что тот кто им не пользуется не может называтся профессионалом только и всего :))))))))
То что у вас вместо языка разметки какой-то мусор это ваши личные половые проблемы, вот только бога ради не надо говорить что этот мусор HTML :)))

>Конечно не считаю. Я и w3.org считаем что тот кто им не пользуется не может называтся профессионалом только и всего :)))))))) >То что у вас вместо языка разметки какой-то мусор это ваши личные половые проблемы, вот только бога ради не надо говорить что этот мусор HTML :)))

Еще раз для тупых: 1) Сайт смотрится в Опере, Нетскейпе и ИЕ? Смотрится.

2) Без искажений? Без.

Чего еще надо-то?

>Просите, вы о чем? Где есть хоть слово про CGI?
Просто расскажите что это у вас там за CGI приложение (более чем серьезное) которое требует высокой сокрости работы и при этом не работает с базой ? Неземной красоты инопланетные узоры на основе rnd в виде картники ? :)))

>без комментариев :)))

И поподробнее, плиз. А то смотрися это как-будто вякнул в пустоту -- лишь бы пофлудить. Расскажите, какая выгода, когда и где будет упущена, если конечный пользователь видит все в нормальном виде?

>Еще раз для тупых: 1) Сайт смотрится в Опере, Нетскейпе и ИЕ?
Да успокойтесь вы :) Смотрится, смотрится !
Вот только что мы видим это не сайт, а просто куча мусора, все претензии к w3.org и к зеркалу :))))))))))))

>Просто расскажите что это у вас там за CGI приложение (более чем серьезное) которое требует высокой сокрости работы и при этом не работает с базой ? Неземной красоты инопланетные узоры на основе rnd в виде картники ? :)))

Вот это приложение: http://go.mail.ru/ С SQL базой не работает. Ну не нужна она там.

>Вот только что мы видим это не сайт, а просто куча мусора, все претензии к w3.org и к зеркалу :))))))))))))

Какая разница, как это интерпретирует валидатор? ;) Пользователям от этого ни тепло ни холодно. А раз нет разницы, зачем тогда платить? (c)

>Вот это приложение: http://go.mail.ru/ С SQL базой не работает. Ну не >нужна она там.
Семен Семеныч ! Вам же писали "что C++, что ASM, что PHP в данном случае упираются в базу" не обязательно в SQL :) Поиск у вас присутствует ? Присутствует. Скорость работы CGI все равно упирается в это. Что и требовалось доказать.

>Не забыл. Покажи мне, например, backend-независимую работу с DataAdapter/DataSet на C#. Т.е. чтоб функция брала IDbConnection, а на выходе был DataSet с данными. Или вот такая простейшая вещь - получить значение поля с автоинкрементом после очередного INSERT'а, опять же, не завязываясь на специфику СУБД.

Ну вот опять - насколько я понял у тебя удобно == кросплатформенно?

-- boshik

>Какая разница, как это интерпретирует валидатор? ;) Пользователям от >этого ни тепло ни холодно.
Да вообщем мне действительно без разницы что у вас там за мусор :)

>А раз нет разницы, зачем тогда платить? (c)
Ну я бы вам за мусор точно платить не стал :)))

> Еще раз для тупых: 1) Сайт смотрится в Опере, Нетскейпе и ИЕ? Смотрится. 2) Без искажений? Без. Чего еще надо-то?

Ну, например, можно было бы вспомнить про такую не самую малоизвестную desktop OS как Mac OS X, и, соответственно, Safari.

> Ну вот опять - насколько я понял у тебя удобно == кросплатформенно?

Нет, не кроссплатформенно. Но возможность (относительно) легко менять бэкенды должна иметь место. Я не хочу лазить по всему коду, делая Find&Replace OleDbCommand->SqlCommand.

>Из крупных китов в лагере

Старческий маразм. И оракл и ибм всеми руками и ногами тащят .нет в свои продукты, делают ГИГАНТСКИЕ усилия для обеспечения своевременной и наилучшей потдержки .нет. И ОЧЕВИДНО то, что они и в дальнейшем будут так делать. Наибольшее внимание на наиболее популярную и массовую технологию ибо там ДЕНЬГИ. Они к счастью не упертые ФАНАТЫ - они делают деньги. Количество *никсов по сравнению с количеством Уиндовс - стремится к нулю. На виндах лучше работает .нет и главное, что она будет работать еще лучше - в МС говорят - усремся, а сделаем так, что .нет на виндах будет рулить а жаба сосать и сделают, ибо это им выгодно.

>И они не собираются менять Java на .Net ;)

Блажен кто верует.

>Ruby - замечательная замена PHP, как язык по сравнению с ним пыхпых находится в прошлом веке, ибо он в сути своей процедурно ориентированный, что влечет за собой сложности при разрастани проектов и повторном использовании кода .. руби, как молодому языку нужна более быстрая реализация, больше либсов на разные случаи жизни и хорошие mod_ruby для веб серверов, тогда imo php можно будет сдавать в утиль, а юные веб программеры не будут засорять себе мозги разным мусором :) ну а пока же PHP в своей нише безусловно доминирует, а IBM этим обстоятельством решила немного попользоваться ..

>NiKel (*) (28.02.2005 1:24:39)

Смишно. Ruby нужна качественная IDE на жабе, такая как Zend Studio от Zend. Вот тогда только на Ruby станут писать МНОГО кода и соответственно пойдет рост. Без IDE на жабе Ruby запускалка скриптов.

>а аналога EJB в .NET просто нет...

COM+ есть уже давно однако...

>>И они не собираются менять Java на .Net ;)

>Блажен кто верует.

надеюсь облажатся как sybase с ASE и ibm os/2 ораклу ума хватит.

>Семен Семеныч ! Вам же писали "что C++, что ASM, что PHP в данном случае упираются в базу" не обязательно в SQL :) Поиск у вас присутствует ? Присутствует. Скорость работы CGI все равно упирается в это. Что и требовалось доказать.

То есть, Вы считаете, что раз нечто упирается в базу, то оптимизация фронтэнда бесполезна? ЛОЛ.

>Ну, например, можно было бы вспомнить про такую не самую малоизвестную desktop OS как Mac OS X, и, соответственно, Safari.

Можно скриншот? Или опять будем обсуждать сферическихх коней в вакууме?

>COM+ есть уже давно однако...

Более того писать и деплоить EnterpriseServices намного проще чем EJB. Может ситуация и изменится но AFAIK EJB3 еще тока в спеках и еще не законченых.

>Блажен кто верует.

А что тут верить? Cobol до сих пор вроде крутится.

Я не думаю, что у IBM поднимется рука переписать линейку WebSphere/Rational (WebSphere Application Developer теперь называется Rational Application Developer, если кто не в курсе) на .NET, тем более выгода совсем не очевидна.

Тем более, Eclipse переписать/откомпилировать под .NET без изменений архитектуры, насколько я представляю, невозможно. Например, аналогов Java-вских classloader-ов в .NET нет (не с точки зрения загрузки классов, а с точки зрения возможности выстраивать их в иерархии, да еще и с каким-нибудь фильтрованием).

Так что менять (в смысле избавляться от Java) - точно (99.99%) не будут. Как дополнительная платформа - возможно.

Насчет пересобрать Eclipse под .NET - может и получИтся. У MS практически эквивалентная реализация Java для .NET. Тем более что он (Eclipse) пользует SWT (Насколько мне известно).

http://www.mono-project.com/about/applications.html#eclipse

Интересно посмотреть, чем они сэмулируют classloader-ы...

Читаем внимательно:

>Zoltan Varga made the Java VM for .NET IKVM run Eclipse, the IBM Open Source IDE

Насколько я понял, они просто написали реализацию JVM на .NET :) Смысла в этом я вижу мало.

http://en.wikipedia.org/wiki/Business_logic

Собственно, вот, о чем я говорю:

>To be able to statically compile Java libraries into .NET assemblies ("static mode"). Note that you can also statically compile Java applications, *but if the application depends on the exact Java class loading semantics, it might need to be adapted*. Dynamic mode supports the full Java class loader model, but in static mode there are necessarily some limitations. A mixed model is also possible, for example, statically compiled code can instantiate a class loader and use it to dynamically load classes.

>>Вот это приложение: http://go.mail.ru/ С SQL базой не работает. Ну не >>нужна она там.
>Семен Семеныч ! Вам же писали "что C++, что ASM, что PHP в данном случае упираются в базу" не обязательно в SQL :) Поиск у вас присутствует ? Присутствует. Скорость работы CGI все равно упирается в это. Что и требовалось доказать.


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


В случае с поиском именно скорость отображения результатов является ключевой. и эта скорость является СУММОЙ от всех проделанных операций по формированию результата. И именно эта скорость вкупе с результами и есть показатель экономической выгоды создания и поддержания данного сервиса. Но никак не хтмл вида ..,width=123... вместо width="123".


// Vad

>Скорость работы CGI все равно упирается в это. Что и требовалось доказать.

Она упирается только тогда, когда фронтэнд работает быстрее бэкэнда. Если использовать для фронтэнда нечто вроде PHP/Perl, фронтэнд будт тормозить. Особенно если учесть то, что фронтэнд занимается не только визуализацией результатов поиска, производимых на бэкэнде.

>Но никак не хтмл вида ..,width=123... вместо width="123".

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

(1) достаточно if и while (2) доказал Дейкстра, человек, которому мы много чем обязаны.

>Я не думаю, что у IBM поднимется рука переписать линейку

об этом речи нет. только дурак будет переписывать то, что уже работает.

>Например, аналогов Java-вских classloader-ов в .NET нет (не с точки зрения загрузки классов, а с точки зрения возможности выстраивать их в иерархии, да еще и с каким-нибудь фильтрованием

И слава Богу! А то некоторые особо одаренные модифицируют байт-код в процессе загрузки! Однако, что самое дерьмовое, присутствие "Java-вских classloader-ов" позволяет забыть про АОТ навсегда, а для десктопных приложений - это критично важно.

>И слава Богу!

А мне не нравится :(

>А то некоторые особо одаренные модифицируют байт-код в процессе загрузки!

Вполне разумная вещь, если с умом применять.

В случае с .NET просто генерится целая сборка. Например, при использовании XmlSerializer-а, генерится исходный код (сюрприз :) во временном каталоге, который потом компилируется C# компилятором. Полученная сборка грузится и используется. Лучше уж тогда байт-код для отдельного класса "на лету" генерить :)

>Однако, что самое дерьмовое, присутствие "Java-вских classloader-ов" позволяет забыть про АОТ навсегда, а для десктопных приложений - это критично важно.

Ну, какой-то AOT все же возможен. Фактически, это только на скорость запуска влияет.

Если взять реальный пример - Eclipse, состоящий из тьмы классов и жесткого использования classloader-ов, то даже на моей машине прошлого века (P-III, 667Mhz, 512Mb) стартует достаточно шустро.

Так что все опять упирается в кривизну рук :)

>В случае с .NET просто генерится целая сборка. Например, при использовании XmlSerializer-а, генерится исходный код (сюрприз :) во временном каталоге, который потом компилируется C# компилятором. Полученная сборка грузится и используется. Лучше уж тогда байт-код для отдельного класса "на лету" генерить :)

System.Reflection.Emit? И генерить на лету - это не МОДИФИЦИРОВАТЬ существующий класс на лету.

>Ну, какой-то AOT все же возможен. Фактически, это только на скорость запуска влияет.

Увы. Это влияет еще и на потребление памяти - jit жрет немало + бинарные имиджи имеют свойство шарится - код для N excel-ов займет столько же места как и для одного. Да и скорость запуска для десктопных прикладух - очень критична. Вспомните хотябы дебаты OO vs MS Qffice, Mozilla vs MS IE.

>System.Reflection.Emit? И генерить на лету - это не МОДИФИЦИРОВАТЬ существующий класс на лету.

Нет, именно исходники. Хреново отформатированные исходники C# :)

>Увы. Это влияет еще и на потребление памяти - jit жрет немало + бинарные имиджи имеют свойство шарится - код для N excel-ов займет столько же места как и для одного.

JDK 1.5 вроде умеет шарить память между процессами. Насколько это эффективно на данный момент - хз.

>Да и скорость запуска для десктопных прикладух - очень критична. Вспомните хотябы дебаты OO vs MS Qffice, Mozilla vs MS IE.

На это больше влияет грамотная архитектура. Взять тот же Eclipse - очень активно используется ленивая загрузка и кеширование.

P.S. Смотря на новый продукт от IBM, IBM Workplace Client Technology (он же Rich Client), такое ощущение, что они на скорость запуска забили совсем :). Интересно было бы посмотреть на аналогичную по функциональности штуку, но на .NET.

>JDK 1.5 вроде умеет шарить память между процессами. Насколько это эффективно на данный момент - хз.

Имеется ввиду статический код, код классов (наверное даже уже отJIT-теные).