Perl vs PHP

[Hans R. Steiner]

Дизайны я придлагал... но на это кто-то забил

Движек... пишу сейчас для форума своей сети...

ЗЫ: я катигорически против PHP...

ЗЫ.ЗЫ: Perl or Perl + mason

[EL[michlen]]

Что не так в PHP?

[Legalizer]

Религиозные войны назревают Может за кружкой пива лучше?

[Hans R. Steiner]

1. не нравится он мне

2. имхо: не может быть лучше перла то, что изначально было написано на перле

3. пхп никак нельзя откомпилировать

4. имхо: кривой скрипт пхп опаснее кривого скрипта перл

и вообще, рассуждать можно много...

[Hans R. Steiner]

White_Mouse писал(а) Срд, 29 Марта 2006 10:47

Религиозные войны назревают Может за кружкой пива лучше?

согласен, но на следующей неделе... на этих выходных я в Питере

[EL[michlen]]

Цитата:

1. не нравится он мне

Мне тоже)))

Цитата:

2. имхо: не может быть лучше перла то, что изначально было написано на перле

Может и был изначально, сейчас на C.

Цитата:

3. пхп никак нельзя откомпилировать

Можно. Только зачем это в рамках данного вопроса?

Цитата:

4. имхо: кривой скрипт пхп опаснее кривого скрипта перл

Как раз наоборот. Прибавь к этому эффективность PHP как средства разработки (работа с БД и т.п.) - получается весьма интересный вариант. Но мы плавно уходим от темы. Можем продолжить во флейме, как считаешь?

[Hans R. Steiner]

EL[michlen

писал(а) Срд, 29 Марта 2006 21:03] Цитата: 1. не нравится он мне Мне тоже))) Цитата: 2. имхо: не может быть лучше перла то, что изначально было написано на перле Может и был изначально, сейчас на C. Цитата: 3. пхп никак нельзя откомпилировать Можно. Только зачем это в рамках данного вопроса? Цитата: 4. имхо: кривой скрипт пхп опаснее кривого скрипта перл Как раз наоборот. Прибавь к этому эффективность PHP как средства разработки (работа с БД и т.п.) - получается весьма интересный вариант. Но мы плавно уходим от темы. Можем продолжить во флейме, как считаешь?

3. Хм... возможно что-то упустил, но как откомпилировать PHP-скрипт?

-- откомпилированый вариант работает быстрее.

4. Как правило, кривой перловый скрипт, просто не будет работать.

-- В зависимости от настроек сервера, можно ограничить доступ

-- к скриптам.

-- Если на сервере траблы с пхп, он вполне может открыться как

-- обычный текст... а часто, это очень не желательно...

-- Согласен... лучше во флейм или в программазм...

[EL[michlen]]

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

[Hans R. Steiner]

Не совсем... вместо фантазии, вполне хватит забыть прикрутить

PHP или просто ошибиться в расширении файла (или в DocumentIndex)

ограничивать доступ к cgi-bin нужно в любом случае, а вот ограничение доступа к htdocs может привесити к неожиднным

проблемам

[Aceler]

Вообще-то PHP начиная с 5-й версии динамический компилятор и работает не медленнее Perl.

А если уж искать идеальный язык - RoR или Parser

[EL[michlen]]

Кстати, Ruby (Ruby on Rails) весьма интересен, только хостеров с ним мало, да еще глючный он иногда, говорят. Хотя удобный.

[Hans R. Steiner]

Хм... надо будет глянуть этот компилируемый PHP...

только вот не пойму... бинарники-то с него получить можно?

[Aceler]

Бинарники не выдает. А надо? Все равно при большой нагрузке копия скомпилированного кода будет висеть в ОЗУ.

[Hans R. Steiner]

Как зачем?

висеть в ОЗУ - это и mod_perl умеет... с него и началось (хотя,

могу и ошибаться... наверное, все же с какой-нибудь явы началось)

у бинарников есть, как минимум, одно преимущество - они бинарники

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

Что это дает?

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

-- не сможет его разобрать и получить какую-либо информацию.

-- (ну... может какую-нибудь все-таки и получит, но по своему

-- опыту могу сказать - дизасм и дебагинг - ужас и кЩмар)

2. если говорить о коммерческих проектах, которые планируются

-- продаваться и продаваться неоднократно т.е., много раз и за

-- деньги (движек для сайта, форума или еще чего-нибудь), можно

-- быть увереным, что никто не выдаст код как свой и не будет

-- получать за него деньги, кроме как его владелец.

3. при распространении программного продукта в бинарниках, а не

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

-- поклонниками ксакепа т.е., пока не вуйдут публикации на

-- конкретную тему, напакостить может только человек, хоть как-то

-- но подгатовленый...

[Aceler]

А...

Нет, PHP этого не умеет. Тем не менее большинство коммерческих CMS в мире написано на PHP.

[Fakir]

А вообще для снрверных технологий рулит J2EE

[EL[michlen]]

Если говорить о перечисленном Гансом, то решение для PHP есть и широко используется - http://www.zend.com/.

[Guard]

1. По поводу бинарников - у форума Invision power (написанном на PHP) есть trial версия, как писалось в аннотации - закодированная. Кстати, а OpenSource уже не в моде?

2. Хоть мой опыт программирования и скромен, но все же PHP мне кажется яснее и четче, чем Perl.

[Hans R. Steiner]

1. Опенсурс в моде, но не всегда

2. Перл яснее, на мой взгляд

[Ineu]

Maestro писал(а) Пнд, 17 Апреля 2006 08:01

ни перл ни пхп ни си по четкости и ясности текста программы в подметки паскалю(=Delphi) не годятся....

За шутку - 5 баллов

[EL[michlen]]

[Hans R. Steiner]

Нда... действительно хорошая шутка я бы даже сказал, стёб

[Byte]

Maestro писал(а) Втр, 18 Апреля 2006 07:47

понятно что для тех кто начинал писать сразу на си этот синтаксис самый родной и лучший

ну, это понятно...

Цитата:

(ибо китайцам проще писать используя 4000 иероглифов чем выучить латинские 26 букв)

а вот это непонятно...

[Ineu]

Maestro писал(а) Втр, 18 Апреля 2006 07:47

а оператор присвания $a=$a+1; с точки зрения математики вообще выглядит абсурдно паскалевское a:=a+1; выглядит логичнее

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

К тому же давайте сравнивать не Паскаль и ПХП, поскольку эти языки создавались в разное время и для разных целей. Давайте сравнивать Паскаль и Си, чтоб честно было

Цитата:

и в связи с этим в условии используется "==" вместо привычного "=" по началу это вызывает путаницу

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

Цитата:

как и существование разных обозначений для одних и тех же операций но с разными типами данных (я про "==" "eq")

Это Вы о Перле? Подобное есть и в том же Баше, например. Удобно сразу видеть, строки ли сравниваются или численные значения.

Цитата:

(а между тем в FOXPRO например и в условии и в присваивании используется "=" и компилятор в состоянии отличить эти две операции)

В Бейсике компилятор тоже на это способен. Переходим все на Бейсик?

Цитата:

а про || и && вместо понятных "or" и "and" я вообще молчу...

Зря молчите. В АСМе or и and означали вполне конкретные операции - побитовую логику. В Си для булевой логики есть операторы || и &&, а для побитовой - | и &. Поскольку это абсолютно разные операции, подобное разделение просто необходимо. Я знаю, что такое в Си a && b, а что такое a & b. А Вы можете мне без контекста сказать, что такое в Паскале a and b?

Цитата:

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

Насчет неудобного и, добавлю, нелогичного синтаксиса - ответьте мне на два вопроса.

Точка с запятой в Паскале означает конец оператора или блока.

1. Почему после имени функции и непосредственно перед ее описанием ставится точка с запятой, если функция по сути есть блок операторов. Почему по аналогии нет конструкций вида

if a = b then;

begin

....

end;

?

2. Почему в условном операторе точки с запятой перед else нет, хотя тут она как раз должна быть!

if a = b then

a := x;

else

...

Эта конструкция неверна! После a = x не должно быть точки с запятой. А почему? Это же нормальный завершенный оператор...

[EL[michlen]]

Кстати, об or, and и прочих. Во-первых, многие сишные компиляторы их и так понимают, а во-вторых, никто не мешает написать #define и использовать что угодно и как угодно.