Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 210
Ого!
В марте 2010 года в палате интенсивной терапии доктор Джани Таскинен отключил пациента PHP6 от аппарата искусственного жизнеобеспечения. Ветка PHP6 была перенесена из trunk в branch, trunk заняла ветка PHP 5.4. Часть органов пациента PHP6, не связанных с Юникодом, была передана PHP 5.4.
+42
Довольно забавно читать такие комменты оглядываясь назад, когда в итоге через некоторое вышел PHP 7, по скорости который сравним с чистым С. Не холивара ради, а просто забавно :) Я и сам был в шоке, не буду скрывать, в каком еще языке такое возможно, хотя я сам на Java пишу.
Сравним с чистым Си? Он даже Джаве проигрывает: benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/php-java.html
Возможно, я на нем последний раз лет десять назад писал (в прямом смысле), в любом случае, это язвк для создания веб-страничек, а не для того, что там тестируется, но увеличение скорости загрузки сайтов видна невооруженным взглядом. В любом случае, удивляет то, что вроде бы уже давно должно быть мертво, вдруг поднимается из пепла. В новых обновлениях явы только копирайты меняют, и это при том что она Ораклу принадлежит. В других языках тоже только уж совсем критические баги и утечки закрывают насколько мне известно.
Это печально
уже скоро 2 года пройдет, а для вас это новость?
Насколько я понимаю, в список «что пошло не так» включается ещё и убитая скорость. PHP в силу своей архитектуры весь завязан на строках (кто не использует «магические» __get?), и добавление юникода в каждую строковую операцию ой как отрицательно сказывалось на производительности. Кто ж обновляться на PHP 6 будет, если мощностей нужно в два раза больше. (Слышал, схожая история приключилась с юникодом в Delphi.)
Ну дык надо было utf8 пилить, там для латиницы 1 байт используется.
С другой стороны utf-16 действительно практически стандарт де-факто для исходных кодов, к примеру в ECMA-262 прописано то, что исходник нужно явно в utf-16 переводить, и ничё, js жив пока :)
С другой стороны utf-16 действительно практически стандарт де-факто для исходных кодов, к примеру в ECMA-262 прописано то, что исходник нужно явно в utf-16 переводить, и ничё, js жив пока :)
Расскажите поподробнее про историю с Delphi. Что в итоге, внедрили, стало тормозить, но прогресс не остановить и все стали пользоваться?
В Delphi просто взяли и «тихой сапой» заменили «на уровне ядра» однобайтовый строковый тип ansistring на двух-четырехбайтный. Теперь все строки состоят из двухбайтных «символов», причем синтаксис не изменился. Но если раньше функция длины строки фактически возвращала размер памяти, выделенный под строку в байтах, то теперь — как придется.
Представляете, сколько кода нужно переписывать, при переносе из «устаревших» версий!!!
А еще для обеспечения обратной совместимости сделали строковый тип динамически перекодируемым — с автоопределением кодировки при загрузки из «однобайтового» источника, например, файла.
Вообщем, не слова, а одни эмоции!!!
Представляете, сколько кода нужно переписывать, при переносе из «устаревших» версий!!!
А еще для обеспечения обратной совместимости сделали строковый тип динамически перекодируемым — с автоопределением кодировки при загрузки из «однобайтового» источника, например, файла.
Вообщем, не слова, а одни эмоции!!!
А с какой версии такое счастье привалило?
а месье фантаст… про существование разных строковых типов слышать приходилось? ;)
короче, переписывать явно нужно только там, где со строками побайтово работали, а не посимвольно… что никогда не было хорошим стилем…
короче, переписывать явно нужно только там, где со строками побайтово работали, а не посимвольно… что никогда не было хорошим стилем…
Не все так страшно. Ранее уже были типы AnsiString и WideString, состоящие соответственно из Char (1-byte) и WideChar (2-byte).
Просто было изменено соответствие string с AnsiString на WideString.
Если нужно быстро и нераздумывая портировать код, просто замените везде string -> AnsiString
Хотя, как показала практика такую замену стоит делать только там, где мы работаем со строками, как с буферами.
Просто было изменено соответствие string с AnsiString на WideString.
Если нужно быстро и нераздумывая портировать код, просто замените везде string -> AnsiString
Хотя, как показала практика такую замену стоит делать только там, где мы работаем со строками, как с буферами.
Не вводите читателей в заблуждение.
Синонимом для типа String в последних версиях Delphi является UnicodeString, а вовсе не WideString.
И то, и то — строка WideChar-ов, но не одно и то же.
Ну и Char теперь синоним для WideChar.
Если портировать «быстро и не раздумывая», то можно напороться на многократные неявные преобразования AnsiString <=> UnicodeString.
Молчу уже о том, что использовать строки в качестве буферов — плохая идея.
Синонимом для типа String в последних версиях Delphi является UnicodeString, а вовсе не WideString.
И то, и то — строка WideChar-ов, но не одно и то же.
Ну и Char теперь синоним для WideChar.
Если портировать «быстро и не раздумывая», то можно напороться на многократные неявные преобразования AnsiString <=> UnicodeString.
Молчу уже о том, что использовать строки в качестве буферов — плохая идея.
Как всегда бывает, если фичу впиливают люди, ею не пользующиеся.
А как же в Java работает все на юникоде? Неужто там не подумали про скорость?
Там, наверное, не нужно всё это постоянно делать в рантайме.
Насколько я понял их печальную историю — у них проблема была в том, что они попробовали пойти простым путем и вначале привести к юникоду только строки. Соответственно все операции с ними приводили к перекодировкам, что негативно сказалось на скорости. А когда они, оценив это, начали переписывать весь код библиотек чтобы не было преобразований — то получилось то, что получилось — не потянули, много там библиотек оказалось.
Ни UTF-16, ни UCS-4 («UTF-32») не поддерживают прямую адресацию символов. google:«combining characters». Поэтому поддержка прямой адресации в «UTF-32» по сути ничем от такой же поддержки прямой адресации в UTF-8 не отличается.
Можно сделать как в питоне — при получении строки извне она преобразуется во внутренний формат с возможностью нормализации. Нормализованные UCS-4 строки вполне себе поддерживают прямую адресацию, если я ничего не путаю?
UCS-4 строки не поддерживают прямую адресацию при наличии combining characters.
Например, буква «д́» непредставима в UCS-4 одним код-поинтом.
Например, буква «д́» непредставима в UCS-4 одним код-поинтом.
Да, вы правы :(. Про комбинирование произвольного мимвола с произвольными диакритическими знаками я не учел. А это на практике вообще используется? Можно во время нормализации на такие конструкции обижаться как на несуществующие в природе ^_^". Или ударения так нужны?
Конечно нужны. Вот пример практического использования диакритики:
stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags#1732454
stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags#1732454
Мать вашу! На те же грабли, что и Embarcadero наступили! Что они все на этот UTF16 молятся?!
И то же «на уровне ядра»!
У кого есть картинка с FUUUUU!
И то же «на уровне ядра»!
У кого есть картинка с FUUUUU!
У них, насколько я понимаю, не совсем UTF-16, а скорее UCS-2. Оригинальный UTF-16 может при большой нужде представлять один символ не двумя, а четырьмя байтами. Насколько я помню, ни Embarcaчтототамнепроизносимое, ни то что делали в PHP 6 такой возможностю не обладали. А ранние майкрософтовские реализации (вроде до XP, хотя могу ошибаться) вообще при виде композитных символов, акцентов и клинописи из расширенных планов падали от удивления :)
Таки в Delphi XE так и есть — при выводе «на экран» один видимый символ может состоять из двух двухбайтовых «точек», например, символ с умляутом.
Фиг с ним с экраном, это и в Windows 95 было, «multibyte» называлось. Пляски с бубном начинаются, когда мы вызываем API вида «а отреж-ка, родимый, пять последний символов» — а он и разрезает символ аккурат на две половинки O_O.
Ну все-таки в UTF-16 (UCS-2) в Delphi XE мы при данном сценарии получим «читаемый» символ (тот же умляут). А вот в UTF-8 Лазаря и с «полудоделанной поддержкой» в PHP 6 — что угодно…
И потому «печалька больше».
И потому «печалька больше».
UTF-8 не на много сложнее. По старшим битам всегда можно определить какой это байт по-счёту и откорректировать индекс.
В UTF-8 все хорошо кроме архитектурной проблемы «что делать с invalid byte sequence». Потому как для UTF-8 все комбинации 2-х байт обозначают какой-нибудь символ. А вот в UTF-8 ряд комбинаций с точки зрения кодировки являются «некорректными».
почему бы не бросать экспешн?
Половина больших приложений перестанит работать «с этими новыми непонятными эксепшнами — а-а-а-а-а, они все поломали!»
Простите, а при каких условиях в большие приложения может прийти invalid byte sequence? Мне казалось это действительно исключительная ситуация
Они обычно берутся при ошибке программиста, который работает со строкой не посимвольно, а как с массивом байт. И если с UTF-16 еще как-то с этими ошибками жить можно, то при использовании для внутреннего представления UTF-8 «все резко прекращает работать».
Тоесть понятно что в идеальном сферическом мире, где пони, бабочки и все прочее, программисты не совершают ошибок и языкам/фреймворкам нет необходимости с этим работать. Но в реальном мире, увы, больший приоритет имеет желание клиента «У нас сейчас все работает, ничего не знаем ни о каких ошибках и вообще програмисты которые это писали давно уволились. Зачем вы в новой версии все поломали?!?».
Тоесть понятно что в идеальном сферическом мире, где пони, бабочки и все прочее, программисты не совершают ошибок и языкам/фреймворкам нет необходимости с этим работать. Но в реальном мире, увы, больший приоритет имеет желание клиента «У нас сейчас все работает, ничего не знаем ни о каких ошибках и вообще програмисты которые это писали давно уволились. Зачем вы в новой версии все поломали?!?».
В реальном мире legacy приложения должны выполняться на той версии софта, под которую написаны. И уж тем более никто не будет менять мажорную версию.
Есть нюансы. Тот кто контролирует среду исполнения не всегда знает, что за приложения у него крутятся. А кто контролирует приложение о таких тонкостях как версии даже не догадывается. В результате имеем хостинги с хорошо если PHP5.2 по умолчанию, а то и 4.х ставят, а 5.3 только по запросу, причём ручками переносят похоже, надо тикет создавать, а после переноса айпишник меняется.
Вот это классный сервис! )
был анонс на хабре же.
Надеюсь с PHP не начнётся вереница «как обозвать новую версию». Помоему, файрфокс и ядро линукса уже исчерпали лимит статей на подобную тематику.
«Так а в чём проблема» — спрашиваем мы. «Есть mbstring, используем и радуемся.»
mbstring входит в набор волшебных костылей, из-за которого многие недолюбливают PHP.
Идеалисты есть только потому, что есть идеальные вещи. Если бы идеальные вещи были созданы, они бы превратились в обыденные. И идеалисты бы вымерли.
Другими словами, этот котстыль работает. Он удовлетворяет большинство потребностей тех web-разработок, для которых подходит PHP.
Оффтоп: лично мне вообще не понятны холивары по поводу языков програмирования. Это как «Угадай мелодию»:
«Я сделаю этот проект за месяц на джаве за 100 баксов»
«А я сделаю этот проект за месяц на пэхапэ за 77 баксов»
«Ну и делай, сука, на своем бадлопэхапэ этот неинтересный быдлопроект»
и наоборот
«Я сделаю этот проект за месяц на джаве за 100 баксов»
«Чорт, на пэхапэ не получится, да и заказчик чота больно привередлив. Да нахер мне это надо, пуст делает. У меня еще 5 на подходе»
Другими словами, этот котстыль работает. Он удовлетворяет большинство потребностей тех web-разработок, для которых подходит PHP.
Оффтоп: лично мне вообще не понятны холивары по поводу языков програмирования. Это как «Угадай мелодию»:
«Я сделаю этот проект за месяц на джаве за 100 баксов»
«А я сделаю этот проект за месяц на пэхапэ за 77 баксов»
«Ну и делай, сука, на своем бадлопэхапэ этот неинтересный быдлопроект»
и наоборот
«Я сделаю этот проект за месяц на джаве за 100 баксов»
«Чорт, на пэхапэ не получится, да и заказчик чота больно привередлив. Да нахер мне это надо, пуст делает. У меня еще 5 на подходе»
Мне больше не понятно, почему проект на джаве/рельсах/джанге/шарпе/… сделают за 100$ минимум, а на пыхе за 77, если кругом кричат, что на пыхе всё плохо, писать на нём сложно и т. п., а, например, на джаве/шарпе компилятор половину ошибок найдёт до первого запуска, а на рельсах/джанге и писать толком ничего не нужно, «всё уже написано до нас».
Забавно, что в Ruby 1.8 было практически то же самое — «Языки кроме английского? А что, такие есть? O_O Сколько-сколько байт на символ?!?». А в версии 1.9 все переделали, теперь в комплекте со строчками идет ее кодировка и все даже более-менее работает.
Особенно забавно то, что создатель языка — японец.
Там до 1.9 та-а-а-акие танцы с бубнами были для поддержки японской кодировки — специальный ключ интерпретатору (!!!) который переводил его в «специальный режим», в котором UTF-16 и Shift_JS частично поддерживалось регекспами. Вот тут подробно описано:
goo.gl/poKsm
goo.gl/poKsm
А японский там был сбоку прикручен, отдельными захардкоженными кодировками Shift-JIS и EUC. Юникод тоже был, но таким омерзительным костылем, что им иначе как в регулярках пользоваться было нельзя.
К счастью, в 1.9 о проблемах с кодировками по большому счету можно забыть. 1.8.7, последний стабильный релиз ветки 1.8, вышел больше трех лет назад и окончательно умрет этим летом.
К счастью, в 1.9 о проблемах с кодировками по большому счету можно забыть. 1.8.7, последний стабильный релиз ветки 1.8, вышел больше трех лет назад и окончательно умрет этим летом.
Ради небольшого оффтопика, можно поподробнее про его смерть этим летом? Вроде как 2.0 на 2013 запланировали?
А вот из источника: 1.8.7 EOL. Багфиксы кончатся в июне 2012, а секурити-фиксы — в июне 2013.
окончательно умрет этим летом
Не уверен. Перевод проектов с 1.8.7 до 1.9 явно не у всех будет проходить безболезненно. Думаю, пока REE базируется на 1.8.7, многие будут на нем сидеть до последнего.
Copy-on-write-совместимая куча из REE уже годы назад как перенесена в 1.9, а крутилочки для GC можно получить, скормив
А так… ну да, старые и плохо написанные (потому что про 1.9 известно уже оч-чень давно) приложения, конечно, сломаются. Туда им и дорога. 1.8 должен умереть. В JRuby, кстати, через одну минорную версию 1.8-режим тоже выкинут.
rvm installпатч из полтысячи строк. Фичи REE вовсе не проблема.
А так… ну да, старые и плохо написанные (потому что про 1.9 известно уже оч-чень давно) приложения, конечно, сломаются. Туда им и дорога. 1.8 должен умереть. В JRuby, кстати, через одну минорную версию 1.8-режим тоже выкинут.
Я, собственно, не возражаю. Сам уже давно на 1.9.
Пару недель назад видел на #ruby-talk живого человека с 1.8.5. Я повторю: 1.8.5, в 2012.
Я вот прямо сейчас установил 1.8.7, чтобы создать новый проект. Не страшно?
Я бы сказал, что не страшно, а толсто ;)
Я серьезно. Зашёл на ruby-lang.org чтоб посмотреть какая версия стабильная, установил rvm, установил 1.9.3, начал устанавливать libapache2_mod_passenger, а он по зависимостям начал тянуть 1.8.7 (Ubuntu 11.10). А мне не только прототип надо создать на рельсах, но и задеплоить его на вдс, где php в продакшене, потому сборка passenger из исходников мягко говоря не желательна.
Ну так надо было не
а
Это как бы в инструкции по использованию написано, если я ничего не путаю.
sudo apt-get install libapache2-mod-passengerа
sudo gem install passengerЭто как бы в инструкции по использованию написано, если я ничего не путаю.
Это написано в easiest way, я сделал как в others. Easiest выдал по зависимостям кучу apache*-dev пакетов, страшно такое на production ставить, вдруг он apache собирается перекомпилировать.
Э… При все моем уважении — как установка gem могла выдать в зависимостях кучу deb пакетов?
Не самого passenger, а выполнение команды passenger-install-apache2-module. Она очень подробные инструкции даёт и, видимо, зависящие от ОС, раз писала команды sudo apt-get install…
Выполнял — апач они не пересобирают. В любом случае можно локально склонировать production сервер и проверить что все пройдет нормально. У меня пока никаких проблемм не было.
Всё равно страшно. Работает — не трогай. Я не администратор, с консолью на «вы» (кроме нескольких зазубренных команд и то, большую часть знал ещё со времён CP/M и MS-DOS) и как «локально склонировать production сервер» толком не представляю. Если встанет такая задача, то разберусь, наверное, чтобы создать образ для VirtualBox, но как-то когда возникает мысль «хорошо бы такой иметь», то времени на то, чтобы гуглить и читать маны нет.
Но по ходу беседы, нашёл вроде способ запустить mod_passenger под 1.9.3 (наверное наоборот правильно). Одна строчка в конфиге апача :(
Но по ходу беседы, нашёл вроде способ запустить mod_passenger под 1.9.3 (наверное наоборот правильно). Одна строчка в конфиге апача :(
Зачем passenger?
Первый результат в гугле по apache rails :) А если серьезно, то из тех вариантов, что нашёл, самый простой для разворачивания рельс параллельно с php-приложениями на одном порту для человека, который еле-еле отличает TCP-сокеты от файловых, то есть меня. :( Привлекло также, что есть модули и для apache, и для nginx, и standalone, если вдруг проект из прототипа превратится в продакшен и мне придётся его поддерживать.
Считается самым модным способом запуска ruby кода под apache?
Я, к примеру, с пессенджера перешел на thin и ни капли не жалею.
Это да, но сколько было геморроя с Rails на 1.9 из-за «invalid multibyte char»… Иегуде даже ликбез проводить пришлось.
java-программисты смотрят на эти проблемы и языки как на…
больше баттхерта, товарищи неосиляторы)
По моему фраза "[Язык программирования] — программист", это диагноз.
Настоящий программист, называет себя программистом, а уже только потом, как бы между прочим говорит о языках и технологиях которыми он владеет, что предполагает легкую возможность использовать более подходящий инструмент для текущей задачи, и возможности освоить что-то новое при необходимости. Одно из правил программирования звучит приблизительно так: «Избегайте венчания на технологии и языке программирования» (Программист прагматик).
Настоящий программист, называет себя программистом, а уже только потом, как бы между прочим говорит о языках и технологиях которыми он владеет, что предполагает легкую возможность использовать более подходящий инструмент для текущей задачи, и возможности освоить что-то новое при необходимости. Одно из правил программирования звучит приблизительно так: «Избегайте венчания на технологии и языке программирования» (Программист прагматик).
Я не понимаю как Java можно не осилить, простой же язык. Правда писать надо очень много, не у всех есть время на это.
Тем более после PHP :) Но это сам язык, а для создания веб-приложений на Javа нужно освоить побольше чем ввести строчку apt-get запустить инсталлер денвера, а потом копировать на хостинг по ftp.
Для простейших домашних страничек не сильно-то и больше. Используйте JSP и все примерно сравнимо по сложности будет. Архитектурно Java может намного больше чем PHP, тут даже сравнивать бесполезно, а вот сколько времени уйдет от «впервые вижу» до способности не писать говнокод — вопрос. Пожалуй, в случае с Java больше, но только, имхо, из-за монструозных библиотек и близость к enterprise миру.
А как же JSR-204, крики «А-а-а-а-а, клинопись!!!» и пляски с бубнов вокруг surrogate pairs?
Вот здесь на хабре было написано, что в php 5.4 будет нативная поддержка Юникода:
Из вашего поста следует, что с Юникодом ничего не получилось и ничего не получится.
Кому верить?
Да-да. Больше не придется использовать расширения, вроде multibyte и ему подобных. Все строковые функции отлично понимают юникод.
Из вашего поста следует, что с Юникодом ничего не получилось и ничего не получится.
Кому верить?
Верить этому комментарию к тому топику. Автор того топика для написания своей статьи использовал слишком устаревшие данные. (Например смотрите на upd внизу статьи)
Чтобы эта хрень ($str[0] = 'японский иероглиф') работала, надо серьезно усложнять код. Так как при работе с байтовой строкой надо заменить байт, а при работе с юникодом найти стартовую позицию, число байт, заменить их и возможно, сдвинуть оставшийся кусок строки. Как минимум, это будет работать неэффективно и провоцирует появление медленного кода (так как 99% PHP-программистов вряд ли осознают что скрывается за инструкцией вставки юникод символа в начале строки и будут делать подобные вставки в цикле).
При том, кому это нужно? Да никому нафиг не нужно. Уже сегодня в PHP можно работать с любыми юникодными строками (кроме некоторых проблем в preg_* с конструкциями вроде [бБ] — увы). А уж возможность называть функции и классы русскими (японскими, испанскими и пр.) буквами, это вообще верх маразма.
Я лично за то, чтобы ядро работало с массивами байт (плюсы: скорость работы, использование существующих библиотек), а разработчики использовали свою голову и mbstring, когда им надо посчитать длину строки или порезать ее с учетом многобайтных символов.
Так что, зачем огорчаться, давайте радоваться лучше.
При том, кому это нужно? Да никому нафиг не нужно. Уже сегодня в PHP можно работать с любыми юникодными строками (кроме некоторых проблем в preg_* с конструкциями вроде [бБ] — увы). А уж возможность называть функции и классы русскими (японскими, испанскими и пр.) буквами, это вообще верх маразма.
Я лично за то, чтобы ядро работало с массивами байт (плюсы: скорость работы, использование существующих библиотек), а разработчики использовали свою голову и mbstring, когда им надо посчитать длину строки или порезать ее с учетом многобайтных символов.
Так что, зачем огорчаться, давайте радоваться лучше.
Если в ПХП вставили новый PCRE, то проблем с русским в preg нет уже.
Большая проблема, имхо, в англоговорящих разработчиках, которые может что-то где-то и слышали про не ASCII не Windows-1251 многобайтовые кодировки, но даже представить не могут, что в их программах их будут использовать и потому считают символ синонимом байта и делают замену символа типа
По хорошему да, ядро должно работать с массивами байтов, чтобы операции типа конкатенации и сравнения (и то, тут уже могут быть проблемы с упорядочиванием) проходили без проблем. Но вот функции должны, имхо, оперировать строками на уровне символов. Все функции, которые принимают строки как последовательности символов, а не как ключи/хэши или последовательности байтов, а не только mb_*.
$str[0] = upper($strtoupper[0]); (ничего больше в голову не пришло :) )По хорошему да, ядро должно работать с массивами байтов, чтобы операции типа конкатенации и сравнения (и то, тут уже могут быть проблемы с упорядочиванием) проходили без проблем. Но вот функции должны, имхо, оперировать строками на уровне символов. Все функции, которые принимают строки как последовательности символов, а не как ключи/хэши или последовательности байтов, а не только mb_*.
Что касается сравнения, то тут все совсем плохо, так как в юникоде одинково выглядящие буквы можно записать разными последовательностями байт (например, буквы с крючками и точечками сверху). По крайней мере, без нормализации, сравнение будет работать неверно.
И если все строки будут по дефолту перкодироваться/нормализовываться, то в PHP все будет работать еще медленнее (а он и так не шустр). Плюс с кодировками типа utf-8/utf-16 даже операция поиска N-ого символа в строке будет занимать O(N) (при O(1) для однобайтовой кодировки). Ну нафиг.
Ну или пусть, если уж никак без юникода, хотя бы сделают бинарные strtr(), strlen(), substr() и прочее.
И если все строки будут по дефолту перкодироваться/нормализовываться, то в PHP все будет работать еще медленнее (а он и так не шустр). Плюс с кодировками типа utf-8/utf-16 даже операция поиска N-ого символа в строке будет занимать O(N) (при O(1) для однобайтовой кодировки). Ну нафиг.
Ну или пусть, если уж никак без юникода, хотя бы сделают бинарные strtr(), strlen(), substr() и прочее.
В-третьих: люди просто устали вставлять поддержку юникода и в без того прекрасно работающий код.
Улыбнули.
Заголовок напомнил: «зима не будет» :)
и в без того прекрасно работающий код
Вспомнилось:
«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
Это круто. У меня давно создавалось ощущение, что php5.4 уже съел все вкусности php 6
True Enterprise PHP, а юникод сделать не могут…
Забавно, что православная ява получила полную поддержку Unicode, включая поддержку ввода на японском, китайском и корейском языках в далеком 1998 году.
А мне больше всего понравился пример про котэ
слышали, слышали… жаль.
Вообще-то абсолюно все, что можно сказать сказано ровно в двух слайдах:
То есть базар не смог сделать чуда.
! 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
То есть базар не смог сделать чуда.
Забавно, но не нашёл на хабре упоминания об этом даже в комментариях. Пора устранить этот недостаток, ведь многие используют только хабр, как источник информации.
Где-то в комментах была ссылка на этот пост: www.amiro.ru/blog/tech/how-was-php6-died
Зато будет Perl 6. Когда-нибудь.
Простите, но это — ппц. Современный язык для веб разработки, нативно не поддерживающий юникод (да и вообще, в случае с PHP, нормальную работу с кодировками) — нонсенс.
И, кстати, у расширения mbstring *есть* проблемы. Основная — невозможность сменить настройку mbstring.internal_encoding через .htaccess. Но даже и без лично я сталкивался с багами, пусть и очень-очень редко.
И, кстати, у расширения mbstring *есть* проблемы. Основная — невозможность сменить настройку mbstring.internal_encoding через .htaccess. Но даже и без лично я сталкивался с багами, пусть и очень-очень редко.
Простите, не холивара ради, но нишу современного в веб разработке занял руби )
Смеялся долго.
Всего 2 секунды )
Ну не могу удержаться :).
First they ignore you, then they laugh at you, then they fight you, then you win. ©
Биться без юникода будет сложно, так что можем переходить сразу к последней стадии :trollface:.
First they ignore you, then they laugh at you, then they fight you, then you win. ©
Биться без юникода будет сложно, так что можем переходить сразу к последней стадии :trollface:.
Технологии надо не просто придумать. Нужно бабло, чтоб их поддержать. Я был бы рад, если бы руби убило джаву, например. Или пых в конце концов.
А я, как рубист, не был бы. Лучший интерпретатор Ruby на данный момент работает поверх JVM. Rubinius, кхм, слегка нестабилен, а MRI тормозной, как полтора барана. JRuby же — drop-in replacement в большей части случаев и невероятно быстр с invokedynamic.
О_О 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) Самый быстрый интерпретатор Ruby это MacRuby, который мало чего общего с вэбом имеет. А главное, сюрприз, сюрприз — имеет нормальный, работающий GC и настоящие треды.
2) jRuby работает через раз, работает медленнее чем 1.9.2, треды тяжелые (jvm же). Часть кода не работает («drop-in replacement» your ass). Редкий случай когда продукт с каждым минорным апдейтом становиться все медлее и медленнее.
3) Рубиниус, кхм, вообще сложно назвать интерпретатором ruby. Вроде есть, вроде работает, вроде должен быть быстрым. А на делее проигрываем всем всем (хотя на некоторой синтетике может обогнать jRuby).
И того самым адекватным решением сегодня будет — RubyEE и MRI 1.9.3, ну если извращенец, то еще можно macruby.
Коллеги, вы определитесь, как бы.
1) Если верить brixen-у (автору rbx), то MacRuby проигрывает даже MRI. Сам не пробовал, макоси у меня нет и не намечается, но попробуйте все же проверить.
2) У меня на вполне реальном GC-интенсивном workload-е (обработка ~десятков тысяч графов с ~тысячами нод, правда не всех одновременно), jruby рвал MRI в два и чуть-чуть больше раз. Пруфы будут, если желаете, я оптимизацией там аж обзанимался. Даже баг нашел в мастере jruby.
«Работает через раз» не замечал, как и «часть кода», но у меня могут быть нетипичные задачи. Для моих портирование сводилось к замене Cext-специфичных гемов и все.
3) Рубиниус, пусть он и по скорости аналогичен или слегка проигрывает MRI, имеет важное преимущество: его авторы не курили что-то очень вставляющее, когда его писали. По хорошему, MRI бы выкинуть нафиг и заменить (допиленным, чтоб не падал) рубиниусом. Совместимость там уже огого какая (буквально на днях, в т.ч. настоящий момент, допиливаются последние кусочки рубиспека 1.9), а код просто на порядки чище и понятнее. Собственно, в Рубиниусе как бы еще нет практически никаких оптимизаций, в отличие от MRI, где новые уже втыкать-то некуда. (Замену ядра аки MRI→KRI я за оптимизацию не считаю.)
Нет, спасибо, REE с учетом перспектив 1.8 адекватным решением не является. Это костыль для поддержки старого кода и не более того.
2) У меня на вполне реальном GC-интенсивном workload-е (обработка ~десятков тысяч графов с ~тысячами нод, правда не всех одновременно), jruby рвал MRI в два и чуть-чуть больше раз. Пруфы будут, если желаете, я оптимизацией там аж обзанимался. Даже баг нашел в мастере jruby.
«Работает через раз» не замечал, как и «часть кода», но у меня могут быть нетипичные задачи. Для моих портирование сводилось к замене Cext-специфичных гемов и все.
3) Рубиниус, пусть он и по скорости аналогичен или слегка проигрывает MRI, имеет важное преимущество: его авторы не курили что-то очень вставляющее, когда его писали. По хорошему, MRI бы выкинуть нафиг и заменить (допиленным, чтоб не падал) рубиниусом. Совместимость там уже огого какая (буквально на днях, в т.ч. настоящий момент, допиливаются последние кусочки рубиспека 1.9), а код просто на порядки чище и понятнее. Собственно, в Рубиниусе как бы еще нет практически никаких оптимизаций, в отличие от MRI, где новые уже втыкать-то некуда. (Замену ядра аки MRI→KRI я за оптимизацию не считаю.)
Нет, спасибо, REE с учетом перспектив 1.8 адекватным решением не является. Это костыль для поддержки старого кода и не более того.
> 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 адекватным решением не является. Это костыль для поддержки старого кода и не более того.
Так оно и есть. Не более.
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 адекватным решением не является. Это костыль для поддержки старого кода и не более того.
Так оно и есть. Не более.
это надо сначала написать все на Ruby. Потом заоптимизировать, потом упереться в VM, переписать на C. И получается, что за всеми этими строчками на руби прячутся сотни строк на сях.А в каких-то интерпретируемых языках, в том же PHP, это не так?
1) Давайте я дам вам свой код, а вы проверите? На MRI, JRuby и MacRuby. Живой проект с вполне реальной, не синтетической, нагрузкой.
2) Вообще ничего не делал с JVM, только -Xmx увеличил слегка.
мнээ. Фиберы — не гем, а часть языка, по крайней мере начиная с 1.9. Про производительность их в jruby ничего сказать не могу, но я что-то не слышал про нативную поддержку continuations в JVM. Опять же, врать не хочу.
3) В рубиниусе immix GC, который является на настоящий момент самым продвинутым с теоретической точки зрения. Верить на слово не предлагаю — почитайте статью. Реализация, возможно, пострадала, но из моего опыта в rbx тормозил в основном ввод-вывод. Еще раз говорю: rbx нужно допиливать, но в нем проблемы именно что в мелочах.
Не такой уж и клёвый? Руби рулит не потому, что гемов много, и, конечно, не тем, что быстрый, а тем, что его метапрограммирование по возможностям ближе всего (из известных мне языков) к лисповым макросам. Возможность писать в шесть-восемь раз меньше кода не означает возможности в то же количество раз меньше думать или отсутствия необходимости оптимизировать. Тормозят, за редкими исключениями, крохотные куски кода. Их и правда лучше переписать на сях, если уж все настолько критично, причем на рубевом API это существенно проще, чем на просто голых сях. В большей части случаев проблема решается просто применением головного мозга.
Надо написать все на Руби? Отлично, большая часть библиотек на руби пишется на порядок быстрее, чем на сях. Я даже не говорю о том, что есть FFI и все такое.
2) Вообще ничего не делал с JVM, только -Xmx увеличил слегка.
мнээ. Фиберы — не гем, а часть языка, по крайней мере начиная с 1.9. Про производительность их в jruby ничего сказать не могу, но я что-то не слышал про нативную поддержку continuations в JVM. Опять же, врать не хочу.
3) В рубиниусе immix GC, который является на настоящий момент самым продвинутым с теоретической точки зрения. Верить на слово не предлагаю — почитайте статью. Реализация, возможно, пострадала, но из моего опыта в rbx тормозил в основном ввод-вывод. Еще раз говорю: rbx нужно допиливать, но в нем проблемы именно что в мелочах.
Не такой уж и клёвый? Руби рулит не потому, что гемов много, и, конечно, не тем, что быстрый, а тем, что его метапрограммирование по возможностям ближе всего (из известных мне языков) к лисповым макросам. Возможность писать в шесть-восемь раз меньше кода не означает возможности в то же количество раз меньше думать или отсутствия необходимости оптимизировать. Тормозят, за редкими исключениями, крохотные куски кода. Их и правда лучше переписать на сях, если уж все настолько критично, причем на рубевом API это существенно проще, чем на просто голых сях. В большей части случаев проблема решается просто применением головного мозга.
Надо написать все на Руби? Отлично, большая часть библиотек на руби пишется на порядок быстрее, чем на сях. Я даже не говорю о том, что есть FFI и все такое.
Выяснил. Фиберы нативные в JVM есть, фиберы JRuby работают с половиной их скорости по утверждению %random_username% с #jruby.
1) Вы мне дадите проект маленько другого типа. Я не думаю, что у вас GUI приложение или какой-то демон.
2) Ну тут если небольшая проблема. GC в MRI без патчей это маленький ад. В то время как в JVM вполне нормальный, да еще и с возможностью настраивать.
Фиберы) Ну это понятно. Просто их отсутствие печалит.
Что касается Ruby — если бы там не было СТОЛЬКО гемов, то разговора и не было.
> Их и правда лучше переписать на сях, если уж все настолько критично, причем на рубевом API это существенно проще, чем на просто голых сях. В большей части случаев проблема решается просто применением головного мозга.
++
> Надо написать все на Руби? Отлично, большая часть библиотек на руби пишется на порядок быстрее, чем на сях. Я даже не говорю о том, что есть FFI и все такое.
Я если честно рассчитывал, что rbx позволит полностью отказаться от Cext.
2) Ну тут если небольшая проблема. GC в MRI без патчей это маленький ад. В то время как в JVM вполне нормальный, да еще и с возможностью настраивать.
Фиберы) Ну это понятно. Просто их отсутствие печалит.
Что касается Ruby — если бы там не было СТОЛЬКО гемов, то разговора и не было.
> Их и правда лучше переписать на сях, если уж все настолько критично, причем на рубевом API это существенно проще, чем на просто голых сях. В большей части случаев проблема решается просто применением головного мозга.
++
> Надо написать все на Руби? Отлично, большая часть библиотек на руби пишется на порядок быстрее, чем на сях. Я даже не говорю о том, что есть FFI и все такое.
Я если честно рассчитывал, что rbx позволит полностью отказаться от Cext.
1) Я описал свой опыт, вы свой. Ок.
2) Давайте уж определимся, что мы сравниваем. 99% юзеров используют непатченный MRI (или REE, но в основном из-за COW), и у меня вот нет ни малейшего желания тюнить ГЦ. И без того работы хватает.
Фиберы см. выше. Они там есть и вроде как не тормозят. Вполне возможно, что неправильно что-то делаете вы. Я бы в первую очередь заподозрил себя.
Как хорошо, что сейчас не 2006, а вы — не dhh.
rbx _с оптимизациями LLVM_ вполне возможно и позволит, но до этого еще долго идти. Ту же арифметику без статического анализа (я, кстати, над этим какбе работаю) сделать сложно, а нормальный статический анализ в рантайме а-ля JVM или V8 там появится еще ой как нескоро. В jRuby, во всяком случае, это произойдет явно раньше.
rbx очень сильно популяризовал (ну, в своей песочнице, конечно, которая не такая уж и маленькая) использование ffi, что решает большую часть проблем с Cext. Нормальный ffi искореняет необходимость тупых оберток, а умные с нормальным API библиотеки и не нужны (скажем, всякие еполлы и прочие kqueue отлично делаются через ffi, и собирать ничего не нужно). Остаются штуки вроде narray, но они опять же в меньшинстве.
2) Давайте уж определимся, что мы сравниваем. 99% юзеров используют непатченный MRI (или REE, но в основном из-за COW), и у меня вот нет ни малейшего желания тюнить ГЦ. И без того работы хватает.
Фиберы см. выше. Они там есть и вроде как не тормозят. Вполне возможно, что неправильно что-то делаете вы. Я бы в первую очередь заподозрил себя.
Как хорошо, что сейчас не 2006, а вы — не dhh.
rbx _с оптимизациями LLVM_ вполне возможно и позволит, но до этого еще долго идти. Ту же арифметику без статического анализа (я, кстати, над этим какбе работаю) сделать сложно, а нормальный статический анализ в рантайме а-ля JVM или V8 там появится еще ой как нескоро. В jRuby, во всяком случае, это произойдет явно раньше.
rbx очень сильно популяризовал (ну, в своей песочнице, конечно, которая не такая уж и маленькая) использование ffi, что решает большую часть проблем с Cext. Нормальный ffi искореняет необходимость тупых оберток, а умные с нормальным API библиотеки и не нужны (скажем, всякие еполлы и прочие kqueue отлично делаются через ffi, и собирать ничего не нужно). Остаются штуки вроде narray, но они опять же в меньшинстве.
> 2) Давайте уж определимся, что мы сравниваем. 99% юзеров используют непатченный MRI (или REE, но в основном из-за COW), и у меня вот нет ни малейшего желания тюнить ГЦ. И без того работы хватает.
Не пропатчил MRI, не настроил GC и запустил проект в продакшен — ССЗБ
> Фиберы см. выше. Они там есть и вроде как не тормозят. Вполне возможно, что неправильно что-то делаете вы. Я бы в первую очередь заподозрил себя.
Когда я тестил фиберы мапились на нативные треды. Сейчас, действительно фиберы почти как настоящие и имеют свой пул.
Я сейчас сравню яблоко с бананом, но clang вон генерит хороший код под llvm. Доходит до того, что бывает быстрее чем нативный от gcc. Так, что оптимизировать надо rbx, прочитал вашу статью — годнота! Успехов!
Не пропатчил MRI, не настроил GC и запустил проект в продакшен — ССЗБ
> Фиберы см. выше. Они там есть и вроде как не тормозят. Вполне возможно, что неправильно что-то делаете вы. Я бы в первую очередь заподозрил себя.
Когда я тестил фиберы мапились на нативные треды. Сейчас, действительно фиберы почти как настоящие и имеют свой пул.
Я сейчас сравню яблоко с бананом, но clang вон генерит хороший код под llvm. Доходит до того, что бывает быстрее чем нативный от gcc. Так, что оптимизировать надо rbx, прочитал вашу статью — годнота! Успехов!
OH SHI~~~ GCC! clang не просто иногда быстрее gcc, он практически всегда быстрее гцц. Доходит до того, что LLVM-ом шейдеры компилируют для CPU, и они вполне себе конкурируют (google://gallium3d) по производительности с low-end GPU вроде последни Интелей. Да, интели не сильно-то и GPU, но они все-таки параллельные и вполне себе domain-specific.
Я о коде сгенерированом clang. То, что clang быстрее gcc это и так ясно.
Понимаете PHP как бы интерпретируемый, динамический язык с не строгой типизацией. Это даёт лёгкий порого вхождения, но это и накладывает очень большие ограничения на реализацию разной хрени.
Дело не в языке. Дело в прямых руках. Я слышал рассказы коммитера в код самого PHP о том, какой там ппц.
Есть немало языков, динамических, без строгой типизации, где с юникодом все в порядке.
ЗЫ: Почитайте комментарии в баг-трекере PHP почему настройка mbstring.func_overload стала PHP_INI_SYSTEM. Это просто феерично. Точнее, феерично, что внятного объяснения этому решению так и не было дано.
Есть немало языков, динамических, без строгой типизации, где с юникодом все в порядке.
ЗЫ: Почитайте комментарии в баг-трекере PHP почему настройка mbstring.func_overload стала PHP_INI_SYSTEM. Это просто феерично. Точнее, феерично, что внятного объяснения этому решению так и не было дано.
>> Есть немало языков, динамических, без строгой типизации, где с юникодом все в порядке.
Давайте, давайте. Желательно с примерами.
Давайте, давайте. Желательно с примерами.
JavaScript?
Маловато будет!
4 независимых реализации JavaScript, две из которых — открытых.
Я вообще никогда не испытывал никаких проблем с текстом в JS
Я вообще никогда не испытывал никаких проблем с текстом в JS
Perl? Но тут не уверен, что он слаботипизированный. А из более-менее популярных с динамической типизацией остались только Python и Ruby, но у них типизация сильная.
Perl — не. Люди утверждают что поддержка юникода костыльная.
Python 3 и Ruby 1.9 с очень хорошей поддежкой юникода появились относительно недавно.
Но тут правда ваша, у PHP был шанс быть одним из первых в своём классе, но они его упустили.
Python 3 и Ruby 1.9 с очень хорошей поддежкой юникода появились относительно недавно.
Но тут правда ваша, у PHP был шанс быть одним из первых в своём классе, но они его упустили.
Если разбираться, то в параллели популярных динамических языков есть два класса: сильно типизированные python и ruby, и слабо — php и js (вроде perl тут же). По поддержке юникода если смотреть, то получаются python, ruby, js нормально (уже) поддерживают, а perl и php с костылями. Так же они делятся по тому признаку, что в первых трёх всё объект (допустимы конструкции типа «string».length, а в последних есть примитивные типы, не являющиеся объектами. Может в этом сложность?
У Python 2.6 и 2.7 с unicode тоже все нормально. В третьей версии просто его сделали по умолчанию — до этого были отдельные юникодные литералы и если не указано иначе, использовался latin-1.
JavaScript при всей его сложности, достаточно компактен, исполняется на стороне клиента и не содержит 100500 расширений для работы со сторонними компонентами.
Давайте ещё примеров.
Давайте ещё примеров.
Tcl.
Хех, прямо мой путь описан :) На goto правда не повёлся, а вот на неймспейсы — да :)
Можете пояснить пару моментов про приведённой статье?
> Подавляющее большинство из них знает, что включенный register_globals — это плохо, но при этом не могут привести реальный (а не вымученный) пример связанной с ним дыры в безопасности! А можете ли привести такой пример вы? (Подсказка: проблемы связаны с массивами и использованием []-синтаксиса в формах.)
О чём тут речь?
> А уж когда ты хозяин рынка, можно потихоньку подтягивать к себе высокопрофессиональную аудиторию: достаточно создать всего пару высоконагруженных проектов на PHP или даже частично на PHP (я намекаю на Facebook), и дело в шляпе.
Насколько были связаны разработчики Facebook и PHP, чтобы говорить, что Facebook был разработан для пиара PHP?
> Подавляющее большинство из них знает, что включенный register_globals — это плохо, но при этом не могут привести реальный (а не вымученный) пример связанной с ним дыры в безопасности! А можете ли привести такой пример вы? (Подсказка: проблемы связаны с массивами и использованием []-синтаксиса в формах.)
О чём тут речь?
> А уж когда ты хозяин рынка, можно потихоньку подтягивать к себе высокопрофессиональную аудиторию: достаточно создать всего пару высоконагруженных проектов на PHP или даже частично на PHP (я намекаю на Facebook), и дело в шляпе.
Насколько были связаны разработчики Facebook и PHP, чтобы говорить, что Facebook был разработан для пиара PHP?
Китайцам надо меньше в код гадить, а то его и так временами не разобрать xD
> как юникод поддерживается сейчас
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. Ну это же позорище — хрен знает сколько уже языку лет, мировая популярность, а работа с текстом — костыль на костыле.
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. Ну это же позорище — хрен знает сколько уже языку лет, мировая популярность, а работа с текстом — костыль на костыле.
>>если кратко, то PHP поддерживает Unicode в том смысле, что не пытается угадывать кодировку текста и просто считает строку последовательностью байт
Не всегда все так просто. Например при работе с DOMDocument приходиться делать такие хаки
$doc->loadHTML('<?xml encoding=«UTF-8»>'. $html);
чтобы PHP угадывал как правильно обрабатывать текст
Не всегда все так просто. Например при работе с DOMDocument приходиться делать такие хаки
$doc->loadHTML('<?xml encoding=«UTF-8»>'. $html);
чтобы PHP угадывал как правильно обрабатывать текст
Зима ни будит.
> function привет(){}
Зачем нам это?
Зачем нам это?
>function привет(){}
Ждем новую версию битрикса с русскими исходниками =)
Ждем новую версию битрикса с русскими исходниками =)
По моему мнению, зная некоторые особенности, проблем c UTF и сейчас особых не возникает.
А на счет PHP 6, так может оно и к лучшему. До сих пор еще даже PHP 4 не везде до конца умер :(
А на счет PHP 6, так может оно и к лучшему. До сих пор еще даже PHP 4 не везде до конца умер :(
У меня никакого акцента нет, я просто попытался перевести презентацию разработчика PHP, сохранив смысл.
Что касается моего личного мнения, то оно тут. И соответственно я считаю, что нужно придумать, как в рамках таких ограничений реализовать юникод. Для начала нужно собрать вместе стандартные проблемы по юникоду и потом подумать.
Что касается моего личного мнения, то оно тут. И соответственно я считаю, что нужно придумать, как в рамках таких ограничений реализовать юникод. Для начала нужно собрать вместе стандартные проблемы по юникоду и потом подумать.
Ну я бы сказал, что он и так довольно шустро развивается, но развивается таки довольно странно. :)
Вот мне на практике приходится сталкиваться с php4 php 5.2 php 5.3, вроде бы и совместимость, есть почти… Однако и довольно серьезные различия, которые в фреймворках и cms иногда выливаются в очень-очень серьезные различия и несовместимости, а это в свою очередь в желание начать забывать PHP :)))
Вот мне на практике приходится сталкиваться с php4 php 5.2 php 5.3, вроде бы и совместимость, есть почти… Однако и довольно серьезные различия, которые в фреймворках и cms иногда выливаются в очень-очень серьезные различия и несовместимости, а это в свою очередь в желание начать забывать PHP :)))
Возможно, хорошим выходом было бы допилить только SPL, добавив в него ООП-обёртки для строк, чисел и прочих базовых структур языка, при этом полностью поддерживая UTF-8.
Мой преподаватель сказал, что PHP умирает, я ему не поверил, но такие «новости» заставляют задуматься…
Как только появится интерпретируемый язык с нестрогой динамической типизацией и с таким же низким порогом вхождения, обеспечивающий принципиально иную степень удобства, хорошо расширяемый, компактный и поддерживающий из коробки: юникод, фреймворки тестирования. То тогда стоит беспокоится.
Лично я вижу пока одного кандидата — JavaScript, но инфраструктуры пока не достаточно вокруг, а проблем в самом языке уже хватает.
Лично я вижу пока одного кандидата — JavaScript, но инфраструктуры пока не достаточно вокруг, а проблем в самом языке уже хватает.
Python?
Python появился гораздо раньше PHP, но всегда отставал по популярности в 2 раза. Я связываю это с синтаксисом. В мире очень популярен Си-подобный синтаксис. А вот Питон к сожалению более далёк к нему по сравнению с PHP и JavaScript. То есть порог вхождения не столь низкий.
Хотя, конечно по всему остальному, Питон проходит помоим критериям.
Хотя, конечно по всему остальному, Питон проходит помоим критериям.
Имхо, проблема прежде всего в инфраструктуре у таких конкурентов php как python, ruby и js. Хостингов мало (под js вообще не видел), разворачивание и администрирование на (V)DS сложнее (субъективно, на личном опыте), разработчиков, готовых работать «за еду», тоже мало (иногда кажется, что я единственный :) ). Продуктов типа CMS для массового конечного пользователя тоже толком нет. При прочих равных заказчик выбирает PHP из-за того, что его риски в этом случае меньше.
P.S. python считается языком со строгой типизацией, как и ruby.
P.S. python считается языком со строгой типизацией, как и ruby.
Разработчики «за еду» обычно пишут очень плохой код на PHP и вообще не способны написать сколь-нибудь сложное приложение на Rails. И это хорошо.
Что же до развертки… да, это незначительно сложнее, чем для PHP. Вместо туториала за 10 минут придется прочитать туториал и потратить 30 минут. Для всего, кроме поднятия хоста с двумя сотнями дорвеев, это не является каким-нибудь препятствием. Кроме того, мне что-то подсказывает, что PHP с дефолтными настройками для серьезных задач абсолютно не подходит.
Что же до развертки… да, это незначительно сложнее, чем для PHP. Вместо туториала за 10 минут придется прочитать туториал и потратить 30 минут. Для всего, кроме поднятия хоста с двумя сотнями дорвеев, это не является каким-нибудь препятствием. Кроме того, мне что-то подсказывает, что PHP с дефолтными настройками для серьезных задач абсолютно не подходит.
Ну вот, оценили мой код не видя его :( Притом, что мне почти всё равно писать ли на PHP+Symfony, на Ruby+Rails или на Python+Django, если не пользоваться всякими coffee-script, haml и less и прочими «трендами», а реализовывать требуемую функциональность возможностями предоставляемыми фреймворком «из коробки». Может мой код не *-way, велосипедный и профи найдёт в нём недостатки, но работает и, есть основания думать, легко поддерживается. Тот же профи воспользуется генератором вместо цикла, сменит вызов моего метода на неизвестную мне библиотечную функцию, заменит мой модуль авторизации на другой из публичных бандлов, гемов или пакаджей, но бояться что где-то что-то упадёт он вряд ли будет, а если упадёт, то тесты ему это покажут.
Может я люблю делать всё через задницу, может очень тупой, но 30 минут мне вчера не хватило, чтобы развернуть рельсы локально, но в обстановке приближенной к «боевой» (тренировка к завтрешнему развёртыванию в боевой). Как-то все туториалы, которые смог нагуглить нарушают debian-way и предполагают компиляцию к чему я отношусь с опаской на продакшене. Худо бедно смог настроить так, что компилируются только гемы (и то, хорошо подсказали в этом топике, что *-dev пакеты это лишь заголовки). Про мелочи вроде изучения init-скриптов (и, как следствие, баша) вообще молчу, как и нагугленные туториалы, они как-то заканчиваются на победном "* start".
Может я люблю делать всё через задницу, может очень тупой, но 30 минут мне вчера не хватило, чтобы развернуть рельсы локально, но в обстановке приближенной к «боевой» (тренировка к завтрешнему развёртыванию в боевой). Как-то все туториалы, которые смог нагуглить нарушают debian-way и предполагают компиляцию к чему я отношусь с опаской на продакшене. Худо бедно смог настроить так, что компилируются только гемы (и то, хорошо подсказали в этом топике, что *-dev пакеты это лишь заголовки). Про мелочи вроде изучения init-скриптов (и, как следствие, баша) вообще молчу, как и нагугленные туториалы, они как-то заканчиваются на победном "* start".
А при чем тут вы? Я говорил о тех разработчиках «за еду», чей код я видел. Он ужасен.
Лично я пользуюсь rvm на продакшне и не парюсь по этому поводу, хотя кое-кто, конечно, скажет, что это жутко неправильно. Избежать сборки гемов вряд ли можно, потому что в Дебиане пакетированные гемы древние, как кости мамонта, и для мало-мальски новых рельс они просто не подойдут по версии.
В принципе, как мне кажется (я не пробовал), если ваша версия/проект на Rails работает через Bundler, то все должно работать и с обычным общесистемным Ruby.
Если Ruby и гемы уже установлены, то вебсервер поднимается за пятнадцать минут по первой ссылке в гугле.
Лично я пользуюсь rvm на продакшне и не парюсь по этому поводу, хотя кое-кто, конечно, скажет, что это жутко неправильно. Избежать сборки гемов вряд ли можно, потому что в Дебиане пакетированные гемы древние, как кости мамонта, и для мало-мальски новых рельс они просто не подойдут по версии.
В принципе, как мне кажется (я не пробовал), если ваша версия/проект на Rails работает через Bundler, то все должно работать и с обычным общесистемным Ruby.
Если Ruby и гемы уже установлены, то вебсервер поднимается за пятнадцать минут по первой ссылке в гугле.
Ну я выше написал, что отношу себя к их числу, хотя да, слово «обычно» как-то пропустил, буду считать себя необычным. :) Извините.
Я тоже в итоге через rvm всё настроил, причём чёрти как — сначала ruby1.8, rybygems, через gem rvm, а потом через rvm ruby 1.9.3.
На том сервере ещё крутится apache+mod_php, поэтому ставил mod_passenger из какого-то репозитория. В общем от ламповского apt-get install apache2 php5 mysql-server далеко. И это только установка, ещё и за обновления следить теперь в трёх местах вместо одного.
Я тоже в итоге через rvm всё настроил, причём чёрти как — сначала ruby1.8, rybygems, через gem rvm, а потом через rvm ruby 1.9.3.
На том сервере ещё крутится apache+mod_php, поэтому ставил mod_passenger из какого-то репозитория. В общем от ламповского apt-get install apache2 php5 mysql-server далеко. И это только установка, ещё и за обновления следить теперь в трёх местах вместо одного.
RVM ставится не так, это раз.
Следить за обновлениями гемов на продакшне не нужно, так как приложение жестко зависит от определенных версий гемов в Gemfile.lock и с другими просто не запустится; тут «случайно» пропустить обновление нельзя, это два.
Обновления самого Ruby выходят раз в полгода, ну и да, ничто все-таки не мешает использовать системный Ruby, чтобы обновления вам доставляло APT, это три.
Следить за обновлениями гемов на продакшне не нужно, так как приложение жестко зависит от определенных версий гемов в Gemfile.lock и с другими просто не запустится; тут «случайно» пропустить обновление нельзя, это два.
Обновления самого Ruby выходят раз в полгода, ну и да, ничто все-таки не мешает использовать системный Ruby, чтобы обновления вам доставляло APT, это три.
Ну не сказать прямо так, что php умирает. Скорее у него карма все более и более портится (например, в Долине уже почти невозможно без стыда объяснять, почему твой тот или иной проект написан на PHP, это вызывает смех), и он стареет и мумифицируется. Но для массовой аудитории язык как был торт, так и остается.
Андруша, ты молодец!
Я прочитала статью и все комменты.
мне понравилось.
ня! :*
Я прочитала статью и все комменты.
мне понравилось.
ня! :*
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP 6 не будет, не осилили