Zend Studio for Eclipse

Хоть и бета - по-моему интересно.

будьте добры, подскажите - по какой оно лицензии?

Хоть и интересно, - по-моему, ПХП - говно.

> будьте добры, подскажите - по какой оно лицензии?

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

Kate рулит.

Ну и причем тут линукс?

Чего только не придумают, что бы не использовать JSP/Servlets в составе какого-нибудь продвинутого фреймворка, к примеру, JSF или Tapestry. :o

А ещё PHP можно пускать через Resin -- работает раз в шесть быстрее, опять же, прямая трансляция PHP в java-байткод с последующим JIT'ом в нэйтив-код и кэшированием.

Так нет же вместо покупки планки памяти за две тысячи рублей, буим изобретать лесапеды и трястись над дырами в интерпретаторе, использовать RAID0+1 для быстрой подгрузки скриптов, что б не тормозило. Apache+modPHP+MySQL+Linux нашэфсйо. :))

А еще будем думать как вставить элемент в начало массива :-) ппц

>А еще будем думать как вставить элемент в начало массива :-) ппц

Конечно. PHP-кодеры ведь не знают, что лет семь существует такая вещь как Java Collection Framework. :)))

Стантартизация -> Стандартизация (через Д)

> А ещё PHP можно пускать через Resin -- работает раз в шесть быстрее, опять же, прямая трансляция PHP в java-байткод с последующим JIT'ом в нэйтив-код и кэшированием.

Quercus roughly matches PHP performance with accelerators like APC

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

+1

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

Это - дело алгоритма(программиста), а не ЯП. В STL поэтому и присутствуют разные виды коллекций. С указанием порядка скорости для разного вида операций. Если php декларируется как прикладной язык высокого уровня - он должен давать такую возможность. А то доходит до смешного. Вместо бинда к функции внутри интерпретатора похапешники юзают библиотеки для работы с массивами, написанные на самом php. Ни о какой скорости тут говорить не приходится тем более.

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

На основании чего сделан такой вывод? На основе того, что массив это "массив как в VB, Pascal, FORTRAN, PHP"? А если его представить списком перечислимых элементов?

В Java использование LinkedList не имеет накладных расходов на вставку и удаление элементов в любое и из любго места "массива". Для частых перечислений и редких вставок со сдвигом элементов хорош ArrayList (или обычный массив). Они имеют унифицированный интерфейс List.

Коллекции Java так же описывают различные ассоциативные массивы с интерфейсом Map и множества с интерфейсом Set, не говоря уж о контейнерах и очередях (дэки и стэки).

Да и ещё, коллекции обеспечивают сортировку элементов по заданной страгии.

В PHP, наверное, всего этого нет или реализовано самопально/внешними библиотеками, о чём многие PHP-кодеры мало наслышаны, судя по специфическим комментариям.

>удаление элементов в любое и из s/любго/любого места "массива".

>коллекции обеспечивают сортировку элементов по заданной s/страгии/стратегии.

> А то доходит до смешного. Вместо бинда к функции внутри интерпретатора похапешники юзают библиотеки для работы с массивами, написанные на самом php.

$x = array(1,'lor'=>'anonymous', 2,3);
print_r($x);
array_splice($x, 0, 0, array(0));
print_r($x);

>А ещё PHP можно пускать через Resin -- работает раз в шесть быстрее, опять же, прямая трансляция PHP в java-байткод с последующим JIT'ом в нэйтив-код и кэшированием.

Извините, п%здец. На что только люди не идут, лишь бы Django/Python не использовать.

Это ж накуя одно глюкалово поверх второго пускать?

Хотите сказать, что это одно и то же, что и несуществующий array_push_front?

>Извините, п%здец. На что только люди не идут, лишь бы Django/Python не использовать.

Скажите, исходники для Python 2.4 можно транслировать в Python 2.5 и в новейшем Python3k без существенной модификации?

Ещё одна провокация флейма?

>Скажите, исходники для Python 2.4 можно транслировать в Python 2.5 и в новейшем Python3k без существенной модификации?

А что, исходники java 1.2 можно автоматически транслировать в исходники java 1.6? С применением ее всех новых фич (генерики и прочее). Что касается питона. Да, исходники 2.4 работают на 2.5. В 3k порушена совместимость потому как это - фактически новый язык. В этой версии не просто добавили фич и изменили библиотеки, но и переработали некоторые концепции.

>А ещё PHP можно пускать через Resin -- работает раз в шесть быстрее, опять же, прямая трансляция PHP в java-байткод с последующим JIT'ом в нэйтив-код и кэшированием.

использование акселераторов ускорят php в разы

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

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

> Скажите, исходники для Python 2.4 можно транслировать в Python 2.5 и в новейшем Python3k без существенной модификации?

Python 2.5 обратно совместим с 2.4, естественно. Версию 3 для того и назвали версией 3, что в ней ломается обратная совместимость с версией 2. Собственно, Python 3 для того и понадобился, чтоб наконец отбросить все костыли, связанные с обратной совместимостью. Тулза для автоматизации перевода из 2 в 3 есть.

>для профессиональных PHP разработчиков

это оксюморон ;)

> Собственно, Python 3 для того и понадобился, чтоб наконец отбросить все костыли, связанные с обратной совместимостью. Тулза для автоматизации перевода из 2 в 3 есть.

А костыли при автоматическом переводе куда деваются? Заменяются аппаратами Елизарова?

>В Java использование LinkedList не имеет накладных расходов на вставку и удаление элементов в любое и из любго места "массива". Для частых перечислений и редких вставок со сдвигом элементов хорош ArrayList (или обычный массив). Они имеют унифицированный интерфейс List.

Вообще-то это слишком навороченно. Константность добавления в любое место становится заметной при размере коллекции > ~4000 элементов, в других случаях ArrayList быстрее. Поскольку данные в настоящее время хранятся в основном в базах данных (возможно Embedded) лично мне редко попадаются коллекции крупнее 100 элементов и, следавательно, в любом проекте можно использовать *только* ArrayList/HashSet/HashMap. Изредка можно использовать LinkedHashSet/LinkedHashMap чтобы сохранить порядок добавления элементов в хеш; мне не приходилось это делать, хотя про фичу я знаю. Зачем добавлять в начало - тоже непонятно. Какое-то FIFO чтоли?

>>для профессиональных PHP разработчиков

>это оксюморон ;)

Возхохотамше под лавкою.

> array_splice($x, 0, 0, array(0));

Глядя на это следует плакать или смеятся?

http://php.net/array_unshift

Ну наконец-то в сырой, сомнительный и хрупкий java-мир придет глобальная и надежная технологи PHP.

> А что, исходники java 1.2 можно автоматически транслировать в исходники java 1.6?

Исходники для Java 1.2 нормально компилируются в Java 1.6. И вообще, с обратной совместимостью в Java дела обстоят хорошо, как ни где.

>> array_splice($x, 0, 0, array(0)); > Глядя на это следует плакать или смеятся?

Застрелиться с горя о недостижимости мечты о "САМОМ УДОБНОМ ЯЗЫКЕ ПРОГРАММИРОВАНИЯ СО ВСЕМИ ВОЗМОЖНЫМИ FEATURES".

> http://php.net/array_unshift

хех, пропустил :)

> Константность добавления в любое место становится заметной при размере коллекции > ~4000 элементов

лень проверять, но я сомневаюсь, что это так. Список: 2-3 присваивания, и одно выделение памяти (которое в джаве супербыстрое). Массив, как ни крути, придётся сдвигать (что в случае 1000 элементов равносильно убийству кэша и вообще достаточно долго), а ещё может не повезти, и придётся новый кусок памяти выделять, а значит памяти съели в два раза больше, пока сборщик не придёт. Чисто интуитивно иассив может сравниваться, и даже выигрывать у списка при размере в десяток элементов, не больше. Хотя конечно надо проверять.

>> Константность добавления в любое место становится заметной при размере коллекции > ~4000 элементов

>лень проверять, но я сомневаюсь, что это так. Список: 2-3 присваивания, и одно выделение памяти (которое в джаве супербыстрое). Массив, как ни крути, придётся сдвигать (что в случае 1000 элементов равносильно убийству кэша и вообще достаточно долго)

Вообще-то добавлять всегда нужно в конец, я не знаю зачем может понадобиться добавлять в середину. 4 кб (4 байта указателя на java.lang.Object X 1000) сдвинуть при помощи memove я думаю не проблема.

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

А при использовании связанных списков мы имеем минимум по 12 байт накладных расходов на каждый элемент + выравнивание. Не считая MCB или как он там называется. На 64-битовой архитектуре указатели в 2 раза шире, так что там накладных расходов будет еще больше.

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

Скотт Мейерс в "Effective STL" советует использовать вообще всегда std::vector, кроме очень редких исключений. А в С++ из-за статических инстанциаций шаблонов потребности в указателях меньше - там элементы связанного списка std::list хранятся прямо в узлах.

>А что, исходники java 1.2 можно автоматически транслировать в исходники java 1.6? С применением ее всех новых фич (генерики и прочее).

Да.
А ещё бинарники (.class) Java 1.1 1996 года нормально работают в JRE 1.6 без перекомпиляции.

(Эх, на ностальгию потянуло что-то, а не запустить ли мне Borland JBuilder 2.0 Professional на современной машине и поработать в нём(?) Ж))

> В Java использование LinkedList не имеет накладных расходов на вставку и удаление элементов в любое и из любго места "массива".

В цепочных списках доступ к элементу за O(n) плюс оверхед памяти на указатели. В силу этого их практическая ценность невелика, и большинство ЯВУ ограничиваются только линейным массивом с предсказанием роста.

Если у вас частые вставки/удаления - имеет смысл подумать об использовании списков списков.

> исходники для Python 2.4 можно транслировать в Python 2.5

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

> и в новейшем Python3k без существенной модификации?

Пока рано говорить - Py3k только в альфе и миграционная тулза только дорабатывается. Там поглядим.

> Застрелиться с горя о недостижимости мечты о "САМОМ УДОБНОМ ЯЗЫКЕ ПРОГРАММИРОВАНИЯ СО ВСЕМИ ВОЗМОЖНЫМИ FEATURES".

[припадая ухом к земле] чу! Слышу топот копыт набегающих лисперов...

> Чего только не придумают, что бы не использовать JSP/Servlets в составе какого-нибудь продвинутого фреймворка, к примеру, JSF или Tapestry. :o

Нэ смэшно.

> А ещё PHP можно пускать через Resin -- работает раз в шесть быстрее

Лучше сразу принять позу стоя в гамаке с ластами. Ровно во столько же раз быстрее он работает с любым акселератором. Surprise, surprise...

> Так нет же вместо покупки планки памяти за две тысячи рублей

Дык кончились места, куда их втыкать мона...

>>Скажите, исходники для Python 2.4 можно транслировать в Python 2.5 и в новейшем Python3k без существенной модификации?

>А что, исходники java 1.2 можно автоматически транслировать в исходники java 1.6?

Ну, я вижу, господа, вы наконец пришли к согласию! Только php! Надёжно и глобально.

>> Застрелиться с горя о недостижимости мечты о "САМОМ УДОБНОМ ЯЗЫКЕ ПРОГРАММИРОВАНИЯ СО ВСЕМИ ВОЗМОЖНЫМИ FEATURES".

>[припадая ухом к земле] чу! Слышу топот копыт набегающих лисперов...

Я недавно начал читать "Структура и интерпретация компьютерных программ", автор Харольд Абельсон и Дж. Сассман. Пока 50 страниц прочёл. Дальше не тянет. Весьма доходчиво описывается Лисп, но, как всегда, простые примеры легки для понимания, но в жизни, как правило, задачи сложны. То есть получается, что функциональное программирование не встречает широкой поддержки только из-за того, что его трудно использовать там, где оно сильно, в силу сложности понимания программистом предметной области. Безусловно, порог вхождения в Лисп обусловлен не самим языком (синтаксис и семантика у него просты), а сложностью понимания тех задач, для решения которых этот язык предназначен (подходит). Ведь задачу можно решить, если её понять. Язык вторичен.

Полсотни каментов, ни одного по теме. LOR-Style

> Безусловно, порог вхождения в Лисп обусловлен не самим языком (синтаксис и семантика у него просты), а сложностью понимания тех задач, для решения которых этот язык предназначен (подходит). Ведь задачу можно решить, если её понять. Язык вторичен.

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

> Полсотни каментов, ни одного по теме.

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

мне

>>для профессиональных PHP разработчиков

>это оксюморон ;)

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

Zend razZendить можна за 3 доллара на кетайском сайте! %) Гыы! %)

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


Bottom-up programming.
http://www.paulgraham.com/progbot.html