Пользователь
0,0
рейтинг
15 февраля 2012 в 20:22

Разработка → PHP 6 не будет, не осилили

PHP*
Забавно, но не нашёл на хабре упоминания об этом даже в комментариях. Пора устранить этот недостаток, ведь многие используют только хабр, как источник информации.

Так вот PHP 6 не будет, вообще. 11 марта 2010 команда разработчиков приняла решение об отмене выпуска PHP 6 в текущем его виде. В результате транк с PHP 6 был перенесён в бранч, а в транке образовалась новая версия — 5.4, в которую разработчики перенесли все наработки из PHP 6, кроме юникода.

Ниже приведен краткий пересказ презентации (pdf), сделанной Andrei Zmievski на PHP Community Conference в 2011 году.


Но для начала рассмотрим как юникод поддерживается сейчас


  • В исходном коде:
    • Можно использовать в названии функций и переменных нелатинские символы, попадающие под регулярку [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*. Следующий код абсолютно валиден: function привет(){}
    • Нормально обрабатываются документы с UTF-8 BOM, но только если нет пустых строк, иначе произойдёт отправка заголовков. Чтобы избежать этого рекомендуется держать HTML-код в шаблонах, а в самих PHP-файлах не использовать закрытие PHP-тега ?>
  • При обработке строк:
    • Стандартные строковые функции, нормально переваривают как минимум UTF-8, но с символами работать не умеют, поэтому такие вещи как определение позиции символа или размера строки будут работать не правильно.
    • Стандартное расширение xml умеет перегонять текст из UTF-8 в ISO-8859-1 и обратно, но по сути это бесполезный функционал.
    • Расширение mbstring (Multibyte String), которое поддерживает большинство кодировок, включая юникодовые. Правда обычно оно не включено по умолчанию.


Общий смысл презентации



Что хотелось иметь

Так а в чём проблема спросите вы? Есть mbstring, используй и радуйся.
А дело в том, что разработчики решили поддержать юникод не на уровне библиотеки, а на уровне ядра. Это означает, что любая php-функция, а также строковые операторы, в потенциале, могут принимать в себя юникод и более менее гарантировать, что юникод символы не будут исковерканы, удалены и не произойдёт ошибки. Кроме того, сам mbstring реализует далеко не все стандартные строковые функции.

Взгляните на следующий примеры:

и

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

Выбор кодировки

  • UTF-8 — Достоинства: обратная совместимость в ASCII, преобладающая кодировка в вебе, есть много библиотек, поддерживающих её.
  • UTF-16 — Достоинства: внутренняя кодировка библиотеки ICU, которая была выбрана для юникода и используется крупными игроками в вебе.
  • UTF-32 — Достоинства: прямая индексация.

В результате выбор пал, на UTF-16 из-за библиотеки ICU. Надо отметить, что оглядываясь назад, разработчики заявили, что если бы им дали сделать выбор ещё раз, то они выбрали бы UTF-8, так как режим обратной совместимости снизил бы объём работы.

Что пошло не так

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

Результат

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

Будущее

Расширение mbstring неполноценно. Можно написать отдельный класс для работы с юникодом, но это также будет не полноценно. Поэтому как именно нужно поддерживать юникод в PHP сейчас всё ещё открытый вопрос.

Выученные уроки
  • Переписывать очень много работающего кода — трудно.
  • Заставлять людей делать утомительные вещи — трудно.
  • Ожидать результаты от вышеописанной деятельности, длящейся долгое время — трудно.
  • Будьте преданны (stay committed).
Андрей Нехайчик @gnomeby
карма
43,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (207)

  • +6
    Ого!
  • +45
    В марте 2010 года в палате интенсивной терапии доктор Джани Таскинен отключил пациента PHP6 от аппарата искусственного жизнеобеспечения. Ветка PHP6 была перенесена из trunk в branch, trunk заняла ветка PHP 5.4. Часть органов пациента PHP6, не связанных с Юникодом, была передана PHP 5.4.
    • +1
      +42
  • +3
    Это печально
  • +20
    уже скоро 2 года пройдет, а для вас это новость?
    • НЛО прилетело и опубликовало эту надпись здесь
    • +14
      image
    • +1
      Это не новость, но попытка заполнить дырку на хабре.
      • –2
        Это Спарта!
  • 0
    Насколько я понимаю, в список «что пошло не так» включается ещё и убитая скорость. PHP в силу своей архитектуры весь завязан на строках (кто не использует «магические» __get?), и добавление юникода в каждую строковую операцию ой как отрицательно сказывалось на производительности. Кто ж обновляться на PHP 6 будет, если мощностей нужно в два раза больше. (Слышал, схожая история приключилась с юникодом в Delphi.)
    • +1
      Ну дык надо было utf8 пилить, там для латиницы 1 байт используется.
      С другой стороны utf-16 действительно практически стандарт де-факто для исходных кодов, к примеру в ECMA-262 прописано то, что исходник нужно явно в utf-16 переводить, и ничё, js жив пока :)
      • 0
        utf16 используется для внутреннего представления. Исходные коды в любой кодировке, для определения используется BOM.
    • +1
      Расскажите поподробнее про историю с Delphi. Что в итоге, внедрили, стало тормозить, но прогресс не остановить и все стали пользоваться?
      • +1
        В Delphi просто взяли и «тихой сапой» заменили «на уровне ядра» однобайтовый строковый тип ansistring на двух-четырехбайтный. Теперь все строки состоят из двухбайтных «символов», причем синтаксис не изменился. Но если раньше функция длины строки фактически возвращала размер памяти, выделенный под строку в байтах, то теперь — как придется.
        Представляете, сколько кода нужно переписывать, при переносе из «устаревших» версий!!!
        А еще для обеспечения обратной совместимости сделали строковый тип динамически перекодируемым — с автоопределением кодировки при загрузки из «однобайтового» источника, например, файла.

        Вообщем, не слова, а одни эмоции!!!
        • 0
          А с какой версии такое счастье привалило?
          • 0
            С 2009 началось, в XE — полная поддержка, в XE2 — исправление багов.
            Теперь все string и char — двух-четырехбайтные * N
            • +2
              Ужас. Я уже не застал.
        • +1
          а месье фантаст… про существование разных строковых типов слышать приходилось? ;)
          короче, переписывать явно нужно только там, где со строками побайтово работали, а не посимвольно… что никогда не было хорошим стилем…
        • +2
          Не все так страшно. Ранее уже были типы AnsiString и WideString, состоящие соответственно из Char (1-byte) и WideChar (2-byte).
          Просто было изменено соответствие string с AnsiString на WideString.
          Если нужно быстро и нераздумывая портировать код, просто замените везде string -> AnsiString
          Хотя, как показала практика такую замену стоит делать только там, где мы работаем со строками, как с буферами.
          • +2
            Не вводите читателей в заблуждение.
            Синонимом для типа String в последних версиях Delphi является UnicodeString, а вовсе не WideString.
            И то, и то — строка WideChar-ов, но не одно и то же.
            Ну и Char теперь синоним для WideChar.

            Если портировать «быстро и не раздумывая», то можно напороться на многократные неявные преобразования AnsiString <=> UnicodeString.

            Молчу уже о том, что использовать строки в качестве буферов — плохая идея.
        • 0
          Как всегда бывает, если фичу впиливают люди, ею не пользующиеся.
    • +1
      А как же в Java работает все на юникоде? Неужто там не подумали про скорость?
      • 0
        Там, наверное, не нужно всё это постоянно делать в рантайме.
      • +1
        Насколько я понял их печальную историю — у них проблема была в том, что они попробовали пойти простым путем и вначале привести к юникоду только строки. Соответственно все операции с ними приводили к перекодировкам, что негативно сказалось на скорости. А когда они, оценив это, начали переписывать весь код библиотек чтобы не было преобразований — то получилось то, что получилось — не потянули, много там библиотек оказалось.
  • +5
    Ни UTF-16, ни UCS-4 («UTF-32») не поддерживают прямую адресацию символов. google:«combining characters». Поэтому поддержка прямой адресации в «UTF-32» по сути ничем от такой же поддержки прямой адресации в UTF-8 не отличается.
    • 0
      Можно сделать как в питоне — при получении строки извне она преобразуется во внутренний формат с возможностью нормализации. Нормализованные UCS-4 строки вполне себе поддерживают прямую адресацию, если я ничего не путаю?
      • +5
        UCS-4 строки не поддерживают прямую адресацию при наличии combining characters.

        Например, буква «д́» непредставима в UCS-4 одним код-поинтом.
        • 0
          Да, вы правы :(. Про комбинирование произвольного мимвола с произвольными диакритическими знаками я не учел. А это на практике вообще используется? Можно во время нормализации на такие конструкции обижаться как на несуществующие в природе ^_^". Или ударения так нужны?
          • +9
            Конечно нужны. Вот пример практического использования диакритики:

            stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags#1732454
            • 0
              4435 upvotes O_O. Нифигажсебеответ…
          • +1
            Модифицирующие символы используются в европейских языках. (пример, en.wikipedia.org/wiki/Swedish_alphabet) Правда, для особо популярных символов (grapheme) используется один code paint. ё тоже можно представить в виде двух символов, при нормализации в NFC они заменятся одним, но не всем языкам так везёт. :)
    • +2
      Прямая адресация code points. То, что с combining chars, то называется grapheme clusters. Каждый combining chars — это code point. Нормализация позволяет упорядочить combining chars по их классу.

      И сразу допишу, почему в ICU используют UTF-16 (а не UTF-8).
      Это позволяет избежать проверку запрещённых байтов (illegal bytes). Ещё это проще чем utf-8, но не теряется место, как с utf-32.
  • +4
    Мать вашу! На те же грабли, что и Embarcadero наступили! Что они все на этот UTF16 молятся?!
    И то же «на уровне ядра»!

    У кого есть картинка с FUUUUU!
    • +1
      У них, насколько я понимаю, не совсем UTF-16, а скорее UCS-2. Оригинальный UTF-16 может при большой нужде представлять один символ не двумя, а четырьмя байтами. Насколько я помню, ни Embarcaчтототамнепроизносимое, ни то что делали в PHP 6 такой возможностю не обладали. А ранние майкрософтовские реализации (вроде до XP, хотя могу ошибаться) вообще при виде композитных символов, акцентов и клинописи из расширенных планов падали от удивления :)
      • 0
        Таки в Delphi XE так и есть — при выводе «на экран» один видимый символ может состоять из двух двухбайтовых «точек», например, символ с умляутом.
        • +1
          Фиг с ним с экраном, это и в Windows 95 было, «multibyte» называлось. Пляски с бубном начинаются, когда мы вызываем API вида «а отреж-ка, родимый, пять последний символов» — а он и разрезает символ аккурат на две половинки O_O.
          • 0
            Ну все-таки в UTF-16 (UCS-2) в Delphi XE мы при данном сценарии получим «читаемый» символ (тот же умляут). А вот в UTF-8 Лазаря и с «полудоделанной поддержкой» в PHP 6 — что угодно…
            И потому «печалька больше».
            • 0
              UTF-8 не на много сложнее. По старшим битам всегда можно определить какой это байт по-счёту и откорректировать индекс.
              • 0
                В UTF-8 все хорошо кроме архитектурной проблемы «что делать с invalid byte sequence». Потому как для UTF-8 все комбинации 2-х байт обозначают какой-нибудь символ. А вот в UTF-8 ряд комбинаций с точки зрения кодировки являются «некорректными».
                • 0
                  почему бы не бросать экспешн?
                  • +1
                    Половина больших приложений перестанит работать «с этими новыми непонятными эксепшнами — а-а-а-а-а, они все поломали!»
                    • 0
                      Простите, а при каких условиях в большие приложения может прийти invalid byte sequence? Мне казалось это действительно исключительная ситуация
                      • +2
                        Они обычно берутся при ошибке программиста, который работает со строкой не посимвольно, а как с массивом байт. И если с UTF-16 еще как-то с этими ошибками жить можно, то при использовании для внутреннего представления UTF-8 «все резко прекращает работать».

                        Тоесть понятно что в идеальном сферическом мире, где пони, бабочки и все прочее, программисты не совершают ошибок и языкам/фреймворкам нет необходимости с этим работать. Но в реальном мире, увы, больший приоритет имеет желание клиента «У нас сейчас все работает, ничего не знаем ни о каких ошибках и вообще програмисты которые это писали давно уволились. Зачем вы в новой версии все поломали?!?».
                        • –1
                          В реальном мире legacy приложения должны выполняться на той версии софта, под которую написаны. И уж тем более никто не будет менять мажорную версию.
                          • +1
                            Есть нюансы. Тот кто контролирует среду исполнения не всегда знает, что за приложения у него крутятся. А кто контролирует приложение о таких тонкостях как версии даже не догадывается. В результате имеем хостинги с хорошо если PHP5.2 по умолчанию, а то и 4.х ставят, а 5.3 только по запросу, причём ручками переносят похоже, надо тикет создавать, а после переноса айпишник меняется.
    • 0
      • +1
        Вот это классный сервис! )
        • +2
          был анонс на хабре же.
      • –4
  • 0
    Надеюсь с PHP не начнётся вереница «как обозвать новую версию». Помоему, файрфокс и ядро линукса уже исчерпали лимит статей на подобную тематику.
  • +5
    «Так а в чём проблема» — спрашиваем мы. «Есть mbstring, используем и радуемся.»
    • +1
      mbstring входит в набор волшебных костылей, из-за которого многие недолюбливают PHP.
      • –2
        Идеалисты есть только потому, что есть идеальные вещи. Если бы идеальные вещи были созданы, они бы превратились в обыденные. И идеалисты бы вымерли.
        Другими словами, этот котстыль работает. Он удовлетворяет большинство потребностей тех web-разработок, для которых подходит PHP.

        Оффтоп: лично мне вообще не понятны холивары по поводу языков програмирования. Это как «Угадай мелодию»:
        «Я сделаю этот проект за месяц на джаве за 100 баксов»
        «А я сделаю этот проект за месяц на пэхапэ за 77 баксов»
        «Ну и делай, сука, на своем бадлопэхапэ этот неинтересный быдлопроект»

        и наоборот

        «Я сделаю этот проект за месяц на джаве за 100 баксов»
        «Чорт, на пэхапэ не получится, да и заказчик чота больно привередлив. Да нахер мне это надо, пуст делает. У меня еще 5 на подходе»
        • 0
          Мне больше не понятно, почему проект на джаве/рельсах/джанге/шарпе/… сделают за 100$ минимум, а на пыхе за 77, если кругом кричат, что на пыхе всё плохо, писать на нём сложно и т. п., а, например, на джаве/шарпе компилятор половину ошибок найдёт до первого запуска, а на рельсах/джанге и писать толком ничего не нужно, «всё уже написано до нас».
          • +1
            У PHP репутация такая, однако: репутация языка для чайников, ламеров и домашних страничек. И никакие фейсбуки этого не изменят. Хотя в нашей фирме у PHP-разработчиков зарплаты высокие
  • +7
    Забавно, что в Ruby 1.8 было практически то же самое — «Языки кроме английского? А что, такие есть? O_O Сколько-сколько байт на символ?!?». А в версии 1.9 все переделали, теперь в комплекте со строчками идет ее кодировка и все даже более-менее работает.
    • +20
      Особенно забавно то, что создатель языка — японец.
      • 0
        Там до 1.9 та-а-а-акие танцы с бубнами были для поддержки японской кодировки — специальный ключ интерпретатору (!!!) который переводил его в «специальный режим», в котором UTF-16 и Shift_JS частично поддерживалось регекспами. Вот тут подробно описано:

        goo.gl/poKsm
      • 0
        А японский там был сбоку прикручен, отдельными захардкоженными кодировками Shift-JIS и EUC. Юникод тоже был, но таким омерзительным костылем, что им иначе как в регулярках пользоваться было нельзя.

        К счастью, в 1.9 о проблемах с кодировками по большому счету можно забыть. 1.8.7, последний стабильный релиз ветки 1.8, вышел больше трех лет назад и окончательно умрет этим летом.
        • 0
          Ради небольшого оффтопика, можно поподробнее про его смерть этим летом? Вроде как 2.0 на 2013 запланировали?
          • +2
            А вот из источника: 1.8.7 EOL. Багфиксы кончатся в июне 2012, а секурити-фиксы — в июне 2013.
        • 0
          окончательно умрет этим летом

          Не уверен. Перевод проектов с 1.8.7 до 1.9 явно не у всех будет проходить безболезненно. Думаю, пока REE базируется на 1.8.7, многие будут на нем сидеть до последнего.
          • 0
            Copy-on-write-совместимая куча из REE уже годы назад как перенесена в 1.9, а крутилочки для GC можно получить, скормив
            rvm install
            патч из полтысячи строк. Фичи REE вовсе не проблема.

            А так… ну да, старые и плохо написанные (потому что про 1.9 известно уже оч-чень давно) приложения, конечно, сломаются. Туда им и дорога. 1.8 должен умереть. В JRuby, кстати, через одну минорную версию 1.8-режим тоже выкинут.
            • +2
              Я, собственно, не возражаю. Сам уже давно на 1.9.
              • 0
                Пару недель назад видел на #ruby-talk живого человека с 1.8.5. Я повторю: 1.8.5, в 2012.
                • 0
                  Я вот прямо сейчас установил 1.8.7, чтобы создать новый проект. Не страшно?
                  • +4
                    Я бы сказал, что не страшно, а толсто ;)
                    • 0
                      Я серьезно. Зашёл на ruby-lang.org чтоб посмотреть какая версия стабильная, установил rvm, установил 1.9.3, начал устанавливать libapache2_mod_passenger, а он по зависимостям начал тянуть 1.8.7 (Ubuntu 11.10). А мне не только прототип надо создать на рельсах, но и задеплоить его на вдс, где php в продакшене, потому сборка passenger из исходников мягко говоря не желательна.
                      • +1
                        Ну так надо было не
                        sudo apt-get install libapache2-mod-passenger
                        а
                        sudo gem install passenger

                        Это как бы в инструкции по использованию написано, если я ничего не путаю.
                        • 0
                          Это написано в easiest way, я сделал как в others. Easiest выдал по зависимостям кучу apache*-dev пакетов, страшно такое на production ставить, вдруг он apache собирается перекомпилировать.
                          • 0
                            Э… При все моем уважении — как установка gem могла выдать в зависимостях кучу deb пакетов?
                            • 0
                              Не самого passenger, а выполнение команды passenger-install-apache2-module. Она очень подробные инструкции даёт и, видимо, зависящие от ОС, раз писала команды sudo apt-get install…
                              • 0
                                Выполнял — апач они не пересобирают. В любом случае можно локально склонировать production сервер и проверить что все пройдет нормально. У меня пока никаких проблемм не было.
                                • 0
                                  Всё равно страшно. Работает — не трогай. Я не администратор, с консолью на «вы» (кроме нескольких зазубренных команд и то, большую часть знал ещё со времён CP/M и MS-DOS) и как «локально склонировать production сервер» толком не представляю. Если встанет такая задача, то разберусь, наверное, чтобы создать образ для VirtualBox, но как-то когда возникает мысль «хорошо бы такой иметь», то времени на то, чтобы гуглить и читать маны нет.

                                  Но по ходу беседы, нашёл вроде способ запустить mod_passenger под 1.9.3 (наверное наоборот правильно). Одна строчка в конфиге апача :(
                                  • 0
                                    *-dev-пакеты это заголовочные файлы, passenger, даже при желании, пересобрать апач не сможет. Он скомпилирует только себя.
                                  • 0
                                    ну так привёл бы её тут, до кучи… раз уж нашёл и похвастался.
                                    • 0
                                      PassengerRuby /home/rvm/.rvm/rubies/ruby-1.9.3-p0/bin/ruby

                                      (знаю, что вышла p125 вчера, но обновляться пока погожу)
                      • +1
                        Зачем passenger?
                        • 0
                          Первый результат в гугле по apache rails :) А если серьезно, то из тех вариантов, что нашёл, самый простой для разворачивания рельс параллельно с php-приложениями на одном порту для человека, который еле-еле отличает TCP-сокеты от файловых, то есть меня. :( Привлекло также, что есть модули и для apache, и для nginx, и standalone, если вдруг проект из прототипа превратится в продакшен и мне придётся его поддерживать.
                        • 0
                          Считается самым модным способом запуска ruby кода под apache?
                          • +1
                            Вероятно, да. В сравнении с настройкой апача как прокси для юникорна.
                      • +1
                        Я, к примеру, с пессенджера перешел на thin и ни капли не жалею.
                        • 0
                          Тонко.
                          • 0
                            Стараюсь.
          • 0
            У нас наконец-то решили перенести проекты на 1.9.3. Сейчас конкретно в процессе переноса. Это очень страшно:) Не больше, чем можно себе представить:) А проект этот был начат год назад. Какого черта выбрали 1.8.7 — не известно.
    • +1
      Это да, но сколько было геморроя с Rails на 1.9 из-за «invalid multibyte char»… Иегуде даже ликбез проводить пришлось.
      • 0
        А он так и остался местами…
        Я, например, пытался перевести проект на 1.9.3 один, но обломался, причем прописав уже UTF-8 везде где можно…

        Сижу на 1.8.7 пока
  • –27
    java-программисты смотрят на эти проблемы и языки как на…
    • –30
      больше баттхерта, товарищи неосиляторы)
      • +23
        По моему фраза "[Язык программирования] — программист", это диагноз.
        Настоящий программист, называет себя программистом, а уже только потом, как бы между прочим говорит о языках и технологиях которыми он владеет, что предполагает легкую возможность использовать более подходящий инструмент для текущей задачи, и возможности освоить что-то новое при необходимости. Одно из правил программирования звучит приблизительно так: «Избегайте венчания на технологии и языке программирования» (Программист прагматик).
      • +2
        Я не понимаю как Java можно не осилить, простой же язык. Правда писать надо очень много, не у всех есть время на это.
        • +1
          Тем более после PHP :) Но это сам язык, а для создания веб-приложений на Javа нужно освоить побольше чем ввести строчку apt-get запустить инсталлер денвера, а потом копировать на хостинг по ftp.
          • +1
            Для простейших домашних страничек не сильно-то и больше. Используйте JSP и все примерно сравнимо по сложности будет. Архитектурно Java может намного больше чем PHP, тут даже сравнивать бесполезно, а вот сколько времени уйдет от «впервые вижу» до способности не писать говнокод — вопрос. Пожалуй, в случае с Java больше, но только, имхо, из-за монструозных библиотек и близость к enterprise миру.
    • +3
      А как же JSR-204, крики «А-а-а-а-а, клинопись!!!» и пляски с бубнов вокруг surrogate pairs?
  • +1
    Вот здесь на хабре было написано, что в php 5.4 будет нативная поддержка Юникода:
    Да-да. Больше не придется использовать расширения, вроде multibyte и ему подобных. Все строковые функции отлично понимают юникод.

    Из вашего поста следует, что с Юникодом ничего не получилось и ничего не получится.

    Кому верить?
    • 0
      Верить этому комментарию к тому топику. Автор того топика для написания своей статьи использовал слишком устаревшие данные. (Например смотрите на upd внизу статьи)
  • +3
    Чтобы эта хрень ($str[0] = 'японский иероглиф') работала, надо серьезно усложнять код. Так как при работе с байтовой строкой надо заменить байт, а при работе с юникодом найти стартовую позицию, число байт, заменить их и возможно, сдвинуть оставшийся кусок строки. Как минимум, это будет работать неэффективно и провоцирует появление медленного кода (так как 99% PHP-программистов вряд ли осознают что скрывается за инструкцией вставки юникод символа в начале строки и будут делать подобные вставки в цикле).

    При том, кому это нужно? Да никому нафиг не нужно. Уже сегодня в PHP можно работать с любыми юникодными строками (кроме некоторых проблем в preg_* с конструкциями вроде [бБ] — увы). А уж возможность называть функции и классы русскими (японскими, испанскими и пр.) буквами, это вообще верх маразма.

    Я лично за то, чтобы ядро работало с массивами байт (плюсы: скорость работы, использование существующих библиотек), а разработчики использовали свою голову и mbstring, когда им надо посчитать длину строки или порезать ее с учетом многобайтных символов.

    Так что, зачем огорчаться, давайте радоваться лучше.
    • 0
       Если в ПХП вставили новый PCRE, то проблем с русским в preg нет уже.
      • 0
        8.12 в августе (5.3.7) поставили.
        • 0
          Проблем нет уже с 8.10, достаточно применить опцию UCP.
    • +2
      Большая проблема, имхо, в англоговорящих разработчиках, которые может что-то где-то и слышали про не ASCII не Windows-1251 многобайтовые кодировки, но даже представить не могут, что в их программах их будут использовать и потому считают символ синонимом байта и делают замену символа типа $str[0] = upper($strtoupper[0]); (ничего больше в голову не пришло :) )

      По хорошему да, ядро должно работать с массивами байтов, чтобы операции типа конкатенации и сравнения (и то, тут уже могут быть проблемы с упорядочиванием) проходили без проблем. Но вот функции должны, имхо, оперировать строками на уровне символов. Все функции, которые принимают строки как последовательности символов, а не как ключи/хэши или последовательности байтов, а не только mb_*.
      • 0
        Что касается сравнения, то тут все совсем плохо, так как в юникоде одинково выглядящие буквы можно записать разными последовательностями байт (например, буквы с крючками и точечками сверху). По крайней мере, без нормализации, сравнение будет работать неверно.

        И если все строки будут по дефолту перкодироваться/нормализовываться, то в PHP все будет работать еще медленнее (а он и так не шустр). Плюс с кодировками типа utf-8/utf-16 даже операция поиска N-ого символа в строке будет занимать O(N) (при O(1) для однобайтовой кодировки). Ну нафиг.

        Ну или пусть, если уж никак без юникода, хотя бы сделают бинарные strtr(), strlen(), substr() и прочее.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Меня всегда веселили книжки по PHP6 в магазинах(которым уже много лет, между прочим). Отмена PHP6 была очевидной.
    • +2
      Меня на собеседовании как-то спрашивали знаю ли я php6.
  • +1
    В-третьих: люди просто устали вставлять поддержку юникода и в без того прекрасно работающий код.

    Улыбнули.
  • +6
    Заголовок напомнил: «зима не будет» :)
  • +13
    и в без того прекрасно работающий код

    Вспомнилось:
    «I really don't like programming. I built this tool to program less so that I could just reuse code.
    PHP is about as exciting as your toothbrush. You use it every day, it does the job, it is a simple tool, so what? Who would want to read about toothbrushes?
    I was really, really bad at writing parsers. I still am really bad at writing parsers. We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all.
    There are people who actually like programming. I don't understand why they like programming.
    I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say «yeah it works but you're leaking memory everywhere. Perhaps we should fix that.» I'll just restart apache every 10 requests.»

    — Rasmus Lerdorf
  • 0
    Это круто. У меня давно создавалось ощущение, что php5.4 уже съел все вкусности php 6
  • +3
    imageimageimage True Enterprise PHP,

    а юникод сделать не могут…

    Забавно, что православная ява получила полную поддержку Unicode, включая поддержку ввода на японском, китайском и корейском языках в далеком 1998 году.
    • –5
      зря кошку в лужу мордой тыкаете — будет только громче шипеть и яростней царапаться)
      • –2
        Кошка > пхп-программист
    • +2
      При всем момем уважении к кофе, вам я тоже про JSR-204 напомню. Там все не так гладко было.
      • +2
        Самое главное, что они этот процесс прошли
  • +1
    А мне больше всего понравился пример про котэ
  • 0
    слышали, слышали… жаль.
  • +5
    Вообще-то абсолюно все, что можно сказать сказано ровно в двух слайдах:
    ! In the end, implementation deemed too technically difficult
    ! People were bored converting large chunks of already working code
    ! The project ran out of steam

    ‣ PHP development culture means that people work on what they’re interested in
    ‣ Clearly, the Unicode/i18n implementation wasn’t interesting enough to be viable


    То есть базар не смог сделать чуда.
  • 0
    Забавно, но не нашёл на хабре упоминания об этом даже в комментариях. Пора устранить этот недостаток, ведь многие используют только хабр, как источник информации.

    Где-то в комментах была ссылка на этот пост: www.amiro.ru/blog/tech/how-was-php6-died
    • 0
      Ну лучше так, ведь есть что пообсужать.
  • –1
    image
  • +3
    Зато будет Perl 6. Когда-нибудь.
    • 0
      фактически он есть, недавно даже релиз вышел
      но правда иначе как бетой эту версию комплиятора не назовешь =)
      • 0
        Я, как бэээ, в курсе, спасибо :)
    • –2
      Как бе про тьюринг неполные языки лучше молчать.
  • +3
    Простите, но это — ппц. Современный язык для веб разработки, нативно не поддерживающий юникод (да и вообще, в случае с PHP, нормальную работу с кодировками) — нонсенс.

    И, кстати, у расширения mbstring *есть* проблемы. Основная — невозможность сменить настройку mbstring.internal_encoding через .htaccess. Но даже и без лично я сталкивался с багами, пусть и очень-очень редко.
    • –16
      Простите, не холивара ради, но нишу современного в веб разработке занял руби )
      • +13
        Смеялся долго.
        • –1
          Всего 2 секунды )
          • +5
            Упс. Это минуты ) FUUUUUU )
            • 0
              Зашел на страничку ответить на комментарий выше по дереву. Так бы вообще не смеялся.
        • +1
          Ну не могу удержаться :).

          First they ignore you, then they laugh at you, then they fight you, then you win. ©

          Биться без юникода будет сложно, так что можем переходить сразу к последней стадии :trollface:.
          • –5
            Технологии надо не просто придумать. Нужно бабло, чтоб их поддержать. Я был бы рад, если бы руби убило джаву, например. Или пых в конце концов.
            • 0
              А я, как рубист, не был бы. Лучший интерпретатор Ruby на данный момент работает поверх JVM. Rubinius, кхм, слегка нестабилен, а MRI тормозной, как полтора барана. JRuby же — drop-in replacement в большей части случаев и невероятно быстр с invokedynamic.
              • +1
                О_О jRuby лучший? Ну давайте по-порядку:
                1) Самый быстрый интерпретатор Ruby это MacRuby, который мало чего общего с вэбом имеет. А главное, сюрприз, сюрприз — имеет нормальный, работающий GC и настоящие треды.
                2) jRuby работает через раз, работает медленнее чем 1.9.2, треды тяжелые (jvm же). Часть кода не работает («drop-in replacement» your ass). Редкий случай когда продукт с каждым минорным апдейтом становиться все медлее и медленнее.
                3) Рубиниус, кхм, вообще сложно назвать интерпретатором ruby. Вроде есть, вроде работает, вроде должен быть быстрым. А на делее проигрываем всем всем (хотя на некоторой синтетике может обогнать jRuby).
                И того самым адекватным решением сегодня будет — RubyEE и MRI 1.9.3, ну если извращенец, то еще можно macruby.
                • –1
                  Коллеги, вы определитесь, как бы.
                  • –1
                    А что определятся?
                    1.9.3 + патчи если новый проект.
                    RubyEE если старый и без проблем не заводится на 1.9.3.
                • +1
                  1) Если верить brixen-у (автору rbx), то MacRuby проигрывает даже MRI. Сам не пробовал, макоси у меня нет и не намечается, но попробуйте все же проверить.

                  2) У меня на вполне реальном GC-интенсивном workload-е (обработка ~десятков тысяч графов с ~тысячами нод, правда не всех одновременно), jruby рвал MRI в два и чуть-чуть больше раз. Пруфы будут, если желаете, я оптимизацией там аж обзанимался. Даже баг нашел в мастере jruby.
                  «Работает через раз» не замечал, как и «часть кода», но у меня могут быть нетипичные задачи. Для моих портирование сводилось к замене Cext-специфичных гемов и все.

                  3) Рубиниус, пусть он и по скорости аналогичен или слегка проигрывает MRI, имеет важное преимущество: его авторы не курили что-то очень вставляющее, когда его писали. По хорошему, MRI бы выкинуть нафиг и заменить (допиленным, чтоб не падал) рубиниусом. Совместимость там уже огого какая (буквально на днях, в т.ч. настоящий момент, допиливаются последние кусочки рубиспека 1.9), а код просто на порядки чище и понятнее. Собственно, в Рубиниусе как бы еще нет практически никаких оптимизаций, в отличие от MRI, где новые уже втыкать-то некуда. (Замену ядра аки MRI→KRI я за оптимизацию не считаю.)

                  Нет, спасибо, REE с учетом перспектив 1.8 адекватным решением не является. Это костыль для поддержки старого кода и не более того.
                  • 0
                    > 1) Если верить brixen-у (автору rbx), то MacRuby проигрывает даже MRI. Сам не пробовал, макоси у меня нет и не намечается, но попробуйте все же проверить.

                    MacRuby работает чуть ли не на той же скорости, что и Objective-C если сравнивать, нормальный проект, а не «давайте посчитаем факториалы»

                    > 2) У меня на вполне реальном GC-интенсивном workload-е (обработка ~десятков тысяч графов с ~тысячами нод, правда не всех одновременно), jruby рвал MRI в два и чуть-чуть больше раз. Пруфы будут, если желаете, я оптимизацией там аж обзанимался. Даже баг нашел в мастере jruby.

                    Ну вероятно у вас GC не настроенный в MRI, и оттюненый в JVM?

                    > «Работает через раз» не замечал, как и «часть кода», но у меня могут быть нетипичные задачи. Для моих портирование сводилось к замене Cext-специфичных гемов и все.

                    У меня вот проект использовал Fibers и в 1.9.2 (а теперь и в 1.9.3) летает на любых стресс тестах, стоит зависти под jRuby (заменив Cext на PureRuby) так все, еле шевелится и памяти жрет в разы больше.

                    3) А GC там появился нормальный? Я конечно сам более за рубиниус, но бывали случаее, что он просто умирал на простых файлах (даже не проектах). Просто висел 20 минут поего KILL не отправлю. А так руби не такой уж и клевый язык. Если есть готовый gem (97.4% hit-rate) то все замечательно, а если нет то это надо сначала написать все на Ruby. Потом заоптимизировать, потом упереться в VM, переписать на C. И получается, что за всеми этими строчками на руби прячутся сотни строк на сях.

                    > Нет, спасибо, REE с учетом перспектив 1.8 адекватным решением не является. Это костыль для поддержки старого кода и не более того.

                    Так оно и есть. Не более.
                    • 0
                      это надо сначала написать все на Ruby. Потом заоптимизировать, потом упереться в VM, переписать на C. И получается, что за всеми этими строчками на руби прячутся сотни строк на сях.
                      А в каких-то интерпретируемых языках, в том же PHP, это не так?
                      • –1
                        На php не так. На PHP надо написал, потом пожаловаться хостеру, потом купить тариф по-дороже. Я о том, что можно сразу после первой версии начать писать на более быстром языке.
                        • –1
                          Ну я сейчас прототипы пишу на рельсах, а потом на php переписываю )

                    • +2
                      1) Давайте я дам вам свой код, а вы проверите? На MRI, JRuby и MacRuby. Живой проект с вполне реальной, не синтетической, нагрузкой.

                      2) Вообще ничего не делал с JVM, только -Xmx увеличил слегка.

                      мнээ. Фиберы — не гем, а часть языка, по крайней мере начиная с 1.9. Про производительность их в jruby ничего сказать не могу, но я что-то не слышал про нативную поддержку continuations в JVM. Опять же, врать не хочу.

                      3) В рубиниусе immix GC, который является на настоящий момент самым продвинутым с теоретической точки зрения. Верить на слово не предлагаю — почитайте статью. Реализация, возможно, пострадала, но из моего опыта в rbx тормозил в основном ввод-вывод. Еще раз говорю: rbx нужно допиливать, но в нем проблемы именно что в мелочах.

                      Не такой уж и клёвый? Руби рулит не потому, что гемов много, и, конечно, не тем, что быстрый, а тем, что его метапрограммирование по возможностям ближе всего (из известных мне языков) к лисповым макросам. Возможность писать в шесть-восемь раз меньше кода не означает возможности в то же количество раз меньше думать или отсутствия необходимости оптимизировать. Тормозят, за редкими исключениями, крохотные куски кода. Их и правда лучше переписать на сях, если уж все настолько критично, причем на рубевом API это существенно проще, чем на просто голых сях. В большей части случаев проблема решается просто применением головного мозга.

                      Надо написать все на Руби? Отлично, большая часть библиотек на руби пишется на порядок быстрее, чем на сях. Я даже не говорю о том, что есть FFI и все такое.
                      • 0
                        Выяснил. Фиберы нативные в JVM есть, фиберы JRuby работают с половиной их скорости по утверждению %random_username% с #jruby.
                      • 0
                        1) Вы мне дадите проект маленько другого типа. Я не думаю, что у вас GUI приложение или какой-то демон.
                        2) Ну тут если небольшая проблема. GC в MRI без патчей это маленький ад. В то время как в JVM вполне нормальный, да еще и с возможностью настраивать.

                        Фиберы) Ну это понятно. Просто их отсутствие печалит.

                        Что касается Ruby — если бы там не было СТОЛЬКО гемов, то разговора и не было.

                        > Их и правда лучше переписать на сях, если уж все настолько критично, причем на рубевом API это существенно проще, чем на просто голых сях. В большей части случаев проблема решается просто применением головного мозга.
                        ++

                        > Надо написать все на Руби? Отлично, большая часть библиотек на руби пишется на порядок быстрее, чем на сях. Я даже не говорю о том, что есть FFI и все такое.

                        Я если честно рассчитывал, что rbx позволит полностью отказаться от Cext.
                        • 0
                          1) Я описал свой опыт, вы свой. Ок.

                          2) Давайте уж определимся, что мы сравниваем. 99% юзеров используют непатченный MRI (или REE, но в основном из-за COW), и у меня вот нет ни малейшего желания тюнить ГЦ. И без того работы хватает.

                          Фиберы см. выше. Они там есть и вроде как не тормозят. Вполне возможно, что неправильно что-то делаете вы. Я бы в первую очередь заподозрил себя.

                          Как хорошо, что сейчас не 2006, а вы — не dhh.

                          rbx _с оптимизациями LLVM_ вполне возможно и позволит, но до этого еще долго идти. Ту же арифметику без статического анализа (я, кстати, над этим какбе работаю) сделать сложно, а нормальный статический анализ в рантайме а-ля JVM или V8 там появится еще ой как нескоро. В jRuby, во всяком случае, это произойдет явно раньше.

                          rbx очень сильно популяризовал (ну, в своей песочнице, конечно, которая не такая уж и маленькая) использование ffi, что решает большую часть проблем с Cext. Нормальный ffi искореняет необходимость тупых оберток, а умные с нормальным API библиотеки и не нужны (скажем, всякие еполлы и прочие kqueue отлично делаются через ffi, и собирать ничего не нужно). Остаются штуки вроде narray, но они опять же в меньшинстве.
                          • 0
                            > 2) Давайте уж определимся, что мы сравниваем. 99% юзеров используют непатченный MRI (или REE, но в основном из-за COW), и у меня вот нет ни малейшего желания тюнить ГЦ. И без того работы хватает.

                            Не пропатчил MRI, не настроил GC и запустил проект в продакшен — ССЗБ

                            > Фиберы см. выше. Они там есть и вроде как не тормозят. Вполне возможно, что неправильно что-то делаете вы. Я бы в первую очередь заподозрил себя.

                            Когда я тестил фиберы мапились на нативные треды. Сейчас, действительно фиберы почти как настоящие и имеют свой пул.

                            Я сейчас сравню яблоко с бананом, но clang вон генерит хороший код под llvm. Доходит до того, что бывает быстрее чем нативный от gcc. Так, что оптимизировать надо rbx, прочитал вашу статью — годнота! Успехов!
                            • 0
                              OH SHI~~~ GCC! clang не просто иногда быстрее gcc, он практически всегда быстрее гцц. Доходит до того, что LLVM-ом шейдеры компилируют для CPU, и они вполне себе конкурируют (google://gallium3d) по производительности с low-end GPU вроде последни Интелей. Да, интели не сильно-то и GPU, но они все-таки параллельные и вполне себе domain-specific.
                              • 0
                                Я о коде сгенерированом clang. То, что clang быстрее gcc это и так ясно.
                                • 0
                                  И я о коде. Clang все еще хуже коммерческих компиляторов (icc, keil), но рвет gcc без особого труда.

                                  А разгадка одна: безблагодатностьфанатики из GNU, закопавшие модульный дизайн, благодаря которому LLVM столь гибок, а в кишках gcc разбираются 2.5 монаха.
                                  • 0
                                    Не знал. Будем считать, что ситуации когда clang + llvm медленнее gcc только в том случае если проект не собирается под clang + llvm.
    • 0
      Понимаете PHP как бы интерпретируемый, динамический язык с не строгой типизацией. Это даёт лёгкий порого вхождения, но это и накладывает очень большие ограничения на реализацию разной хрени.
      • 0
        Дело не в языке. Дело в прямых руках. Я слышал рассказы коммитера в код самого PHP о том, какой там ппц.

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

        ЗЫ: Почитайте комментарии в баг-трекере PHP почему настройка mbstring.func_overload стала PHP_INI_SYSTEM. Это просто феерично. Точнее, феерично, что внятного объяснения этому решению так и не было дано.
        • +1
          >> Есть немало языков, динамических, без строгой типизации, где с юникодом все в порядке.

          Давайте, давайте. Желательно с примерами.
          • +1
            JavaScript?
            • 0
              Маловато будет!
              • +1
                4 независимых реализации JavaScript, две из которых — открытых.
                Я вообще никогда не испытывал никаких проблем с текстом в JS
              • 0
                Perl? Но тут не уверен, что он слаботипизированный. А из более-менее популярных с динамической типизацией остались только Python и Ruby, но у них типизация сильная.
                • 0
                  Perl — не. Люди утверждают что поддержка юникода костыльная.
                  Python 3 и Ruby 1.9 с очень хорошей поддежкой юникода появились относительно недавно.

                  Но тут правда ваша, у PHP был шанс быть одним из первых в своём классе, но они его упустили.
                  • 0
                    Если разбираться, то в параллели популярных динамических языков есть два класса: сильно типизированные python и ruby, и слабо — php и js (вроде perl тут же). По поддержке юникода если смотреть, то получаются python, ruby, js нормально (уже) поддерживают, а perl и php с костылями. Так же они делятся по тому признаку, что в первых трёх всё объект (допустимы конструкции типа «string».length, а в последних есть примитивные типы, не являющиеся объектами. Может в этом сложность?
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • 0
                        Поверил на слово комменту выше. С perl последний раз сталкивался в 99-м или 2000-м, когда на C++ для веба писать утомило.
                  • 0
                    У Python 2.6 и 2.7 с unicode тоже все нормально. В третьей версии просто его сделали по умолчанию — до этого были отдельные юникодные литералы и если не указано иначе, использовался latin-1.
            • 0
              JavaScript при всей его сложности, достаточно компактен, исполняется на стороне клиента и не содержит 100500 расширений для работы со сторонними компонентами.

              Давайте ещё примеров.
              • 0
                Какая разница где исполняется? Тем более что и на сервере исполняется тоже.

                Зачем мне их вам давать? :)
          • 0
            Tcl.
  • +1
    Хотелось бы напомнить, что Зенд всегда славился своими пиар-компаниями. Почитайте классиков.

    PS
    Кстати, а белки-истерички уже слышали об этой новости?
    • 0
      Хех, прямо мой путь описан :) На goto правда не повёлся, а вот на неймспейсы — да :)
      • 0
        Эм… в смысле нейспейсы? Что с ними не так?
        • 0
          Обратил на них внимание на ранних альфах из-за холиваров :)
        • 0
          С ними абсолютно все так — просто в PHP они внедрены с некоторым подвывертом. Это вызвало тонны ненависти среди одних и нескончаемые лучи любви в адрес Зенда у других. В результате появились миллиарды холиварных текстов. Та же самая ситуация и с goto.

          По всей сети миллиарды холиварных текстов «О вреде goto», «О вреде статей о вреде goto» и так далее. В результате Зенд делает так, чтобы о PHP говорили, писали, спорили. Пиар — дело тонкое.
    • 0
      Можете пояснить пару моментов про приведённой статье?

      > Подавляющее большинство из них знает, что включенный register_globals — это плохо, но при этом не могут привести реальный (а не вымученный) пример связанной с ним дыры в безопасности! А можете ли привести такой пример вы? (Подсказка: проблемы связаны с массивами и использованием []-синтаксиса в формах.)

      О чём тут речь?

      > А уж когда ты хозяин рынка, можно потихоньку подтягивать к себе высокопрофессиональную аудиторию: достаточно создать всего пару высоконагруженных проектов на PHP или даже частично на PHP (я намекаю на Facebook), и дело в шляпе.

      Насколько были связаны разработчики Facebook и PHP, чтобы говорить, что Facebook был разработан для пиара PHP?
      • 0
        По поводу register_globals — я тоже признаюсь, сколько ни искал готовых примеров описанной в статье уязвимости — не нашел. Может статься, это было шаманство с суперглобальными массивами или эту уязвимость уже давно пофиксили.

        По поводу второго — вероятно, имеется в виду, что Зенд дождался появления серьезных проектов на PHP и стал сильно пиарить этот факт. Как-то так.
        • 0
          Про register_globals самоое элементарное:

          if ($pass == "secret") $valid_user = true;
          if (isset($valid_user)) {
          echo "hello";
          |}
          • 0
            Вымученные примеры вроде просили не писать.
            • 0
              может, можно переопределить какой-либо глобальный массив? типа GLOBALS или ENV
              • 0
                Вот тоже мысль мелькнула такая, что CGI-заголовки можно подделать.
                • 0
                  Глобальный массив так не переопределить. Речь шла о том, что очень часто забывают инициализировать переменную пустым массивом перед тем, как в нее добавлять элементы. Это не генерирует нотисы.

                  <?php
                  $а['fruit'] = 'apple';
                  $a[...] = ...;

                  foreach ($a as $k => $v) ...;
  • 0
    Китайцам надо меньше в код гадить, а то его и так временами не разобрать xD
  • +2
    > как юникод поддерживается сейчас
    kunststube.net/encoding/ — если кратко, то PHP поддерживает Unicode в том смысле, что не пытается угадывать кодировку текста и просто считает строку последовательностью байт. Хорошая статья, многое подробно разжевано.

    > UTF-16 — Достоинства
    www.unicode.org/notes/tn12/ — еще в 2004-м году написали, почему UTF-16 предпочтительнее во многих аспектах.

    > достаточно мало специалистов, которые понимают тонкости юникода
    www.joelonsoftware.com/articles/Unicode.html — вообще классика, всем must read.

    Не хочу никого обидеть, но знание ситуации с кодировками в общем и понимание Unicode в частности, имхо, отличает квалифицированного разработчика от code monkey. Ну это же позорище — хрен знает сколько уже языку лет, мировая популярность, а работа с текстом — костыль на костыле.
    • +3
      >>если кратко, то PHP поддерживает Unicode в том смысле, что не пытается угадывать кодировку текста и просто считает строку последовательностью байт
      Не всегда все так просто. Например при работе с DOMDocument приходиться делать такие хаки
      $doc->loadHTML('<?xml encoding=«UTF-8»>'. $html);
      чтобы PHP угадывал как правильно обрабатывать текст
  • +2
    Зима ни будит.
  • 0
    > function привет(){}
    Зачем нам это?
  • +9
    >function привет(){}

    Ждем новую версию битрикса с русскими исходниками =)
  • +1
    По моему мнению, зная некоторые особенности, проблем c UTF и сейчас особых не возникает.
    А на счет PHP 6, так может оно и к лучшему. До сих пор еще даже PHP 4 не везде до конца умер :(
    • 0
      Вы не совсем поняли акцент автора статьи и проблематику. Проблема не в том, что цифру отменили, а в том, что разработка PHP как такового отстает от мировых трендов и потребностей.

      Да, PHP развивается — но хотелось бы, чтобы это происходило как-то пошустрее и, соответственно, как-то побольше соответствовало стандартам.
      • 0
        У меня никакого акцента нет, я просто попытался перевести презентацию разработчика PHP, сохранив смысл.

        Что касается моего личного мнения, то оно тут. И соответственно я считаю, что нужно придумать, как в рамках таких ограничений реализовать юникод. Для начала нужно собрать вместе стандартные проблемы по юникоду и потом подумать.
        • 0
          Для подавляющего большинства разработчиков PHP любая проблема по юникоду представляет собой, видимо, чисто академическую проблему. Им это не интересно.
      • 0
        Ну я бы сказал, что он и так довольно шустро развивается, но развивается таки довольно странно. :)
        Вот мне на практике приходится сталкиваться с php4 php 5.2 php 5.3, вроде бы и совместимость, есть почти… Однако и довольно серьезные различия, которые в фреймворках и cms иногда выливаются в очень-очень серьезные различия и несовместимости, а это в свою очередь в желание начать забывать PHP :)))
        • 0
          По-моему, любому развивающемуся языку с ~20 лет историей сложновато поддерживать совместимость и гарантировать, что код работавший 20 лет назад будет работать и под современными версиями трансляторов.
  • +2
    Возможно, хорошим выходом было бы допилить только SPL, добавив в него ООП-обёртки для строк, чисел и прочих базовых структур языка, при этом полностью поддерживая UTF-8.
  • +2
    Мой преподаватель сказал, что PHP умирает, я ему не поверил, но такие «новости» заставляют задуматься…
    • 0
      Как только появится интерпретируемый язык с нестрогой динамической типизацией и с таким же низким порогом вхождения, обеспечивающий принципиально иную степень удобства, хорошо расширяемый, компактный и поддерживающий из коробки: юникод, фреймворки тестирования. То тогда стоит беспокоится.

      Лично я вижу пока одного кандидата — JavaScript, но инфраструктуры пока не достаточно вокруг, а проблем в самом языке уже хватает.
      • 0
        Python?
        • 0
          Python появился гораздо раньше PHP, но всегда отставал по популярности в 2 раза. Я связываю это с синтаксисом. В мире очень популярен Си-подобный синтаксис. А вот Питон к сожалению более далёк к нему по сравнению с PHP и JavaScript. То есть порог вхождения не столь низкий.

          Хотя, конечно по всему остальному, Питон проходит помоим критериям.
          • 0
            Имхо, проблема прежде всего в инфраструктуре у таких конкурентов php как python, ruby и js. Хостингов мало (под js вообще не видел), разворачивание и администрирование на (V)DS сложнее (субъективно, на личном опыте), разработчиков, готовых работать «за еду», тоже мало (иногда кажется, что я единственный :) ). Продуктов типа CMS для массового конечного пользователя тоже толком нет. При прочих равных заказчик выбирает PHP из-за того, что его риски в этом случае меньше.

            P.S. python считается языком со строгой типизацией, как и ruby.
            • 0
              Разработчики «за еду» обычно пишут очень плохой код на PHP и вообще не способны написать сколь-нибудь сложное приложение на Rails. И это хорошо.

              Что же до развертки… да, это незначительно сложнее, чем для PHP. Вместо туториала за 10 минут придется прочитать туториал и потратить 30 минут. Для всего, кроме поднятия хоста с двумя сотнями дорвеев, это не является каким-нибудь препятствием. Кроме того, мне что-то подсказывает, что PHP с дефолтными настройками для серьезных задач абсолютно не подходит.
              • 0
                Ну вот, оценили мой код не видя его :( Притом, что мне почти всё равно писать ли на PHP+Symfony, на Ruby+Rails или на Python+Django, если не пользоваться всякими coffee-script, haml и less и прочими «трендами», а реализовывать требуемую функциональность возможностями предоставляемыми фреймворком «из коробки». Может мой код не *-way, велосипедный и профи найдёт в нём недостатки, но работает и, есть основания думать, легко поддерживается. Тот же профи воспользуется генератором вместо цикла, сменит вызов моего метода на неизвестную мне библиотечную функцию, заменит мой модуль авторизации на другой из публичных бандлов, гемов или пакаджей, но бояться что где-то что-то упадёт он вряд ли будет, а если упадёт, то тесты ему это покажут.

                Может я люблю делать всё через задницу, может очень тупой, но 30 минут мне вчера не хватило, чтобы развернуть рельсы локально, но в обстановке приближенной к «боевой» (тренировка к завтрешнему развёртыванию в боевой). Как-то все туториалы, которые смог нагуглить нарушают debian-way и предполагают компиляцию к чему я отношусь с опаской на продакшене. Худо бедно смог настроить так, что компилируются только гемы (и то, хорошо подсказали в этом топике, что *-dev пакеты это лишь заголовки). Про мелочи вроде изучения init-скриптов (и, как следствие, баша) вообще молчу, как и нагугленные туториалы, они как-то заканчиваются на победном "* start".
                • 0
                  А при чем тут вы? Я говорил о тех разработчиках «за еду», чей код я видел. Он ужасен.

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

                  В принципе, как мне кажется (я не пробовал), если ваша версия/проект на Rails работает через Bundler, то все должно работать и с обычным общесистемным Ruby.

                  Если Ruby и гемы уже установлены, то вебсервер поднимается за пятнадцать минут по первой ссылке в гугле.
                  • 0
                    Ну я выше написал, что отношу себя к их числу, хотя да, слово «обычно» как-то пропустил, буду считать себя необычным. :) Извините.

                    Я тоже в итоге через rvm всё настроил, причём чёрти как — сначала ruby1.8, rybygems, через gem rvm, а потом через rvm ruby 1.9.3.

                    На том сервере ещё крутится apache+mod_php, поэтому ставил mod_passenger из какого-то репозитория. В общем от ламповского apt-get install apache2 php5 mysql-server далеко. И это только установка, ещё и за обновления следить теперь в трёх местах вместо одного.

                    • 0
                      RVM ставится не так, это раз.

                      Следить за обновлениями гемов на продакшне не нужно, так как приложение жестко зависит от определенных версий гемов в Gemfile.lock и с другими просто не запустится; тут «случайно» пропустить обновление нельзя, это два.

                      Обновления самого Ruby выходят раз в полгода, ну и да, ничто все-таки не мешает использовать системный Ruby, чтобы обновления вам доставляло APT, это три.
                      • 0
                        Вот видите сколько тонкостей :) И на всё это вы 30 минут выделили? )
    • 0
      Ну не сказать прямо так, что php умирает. Скорее у него карма все более и более портится (например, в Долине уже почти невозможно без стыда объяснять, почему твой тот или иной проект написан на PHP, это вызывает смех), и он стареет и мумифицируется. Но для массовой аудитории язык как был торт, так и остается.
  • 0
    Андруша, ты молодец!
    Я прочитала статью и все комменты.
    мне понравилось.
    ня! :*
    • 0
      Сорри, это не gnomeby, а поклонница. не портите ему карму только! лучше меня убейте.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.