Comments 429
Сразу вспомнилось:
чуть глаза не сломал от вашего комментария… пора отдыхать)))
Похоже, у нас с вами одинаковые браузеры и операционки.
У меня, похоже, другая ось. Какая у вас и почему сглаживание даёт такое размытие?
Дело не в оси. Если реже глаз, значит, один LCD монитор RGB, а другой BRG. Отсюда и цветной вырвиглаз.
Как влияет монитор на файл скриншота?
Субпиксельное сглаживание зависит от последовательности пикселей.
От монитора зависит система, которая и сглаживает.
Если увеличить скриншот, то видно, что буквы не чёрные, а красно — синие.
Вот тут ru.wikipedia.org/wiki/ClearType сказано, почему ClearType не работает на ЭЛТ.
От монитора зависит система, которая и сглаживает.
Если увеличить скриншот, то видно, что буквы не чёрные, а красно — синие.
Вот тут ru.wikipedia.org/wiki/ClearType сказано, почему ClearType не работает на ЭЛТ.
я звизда!
Опасно вешать такой коммент в конце дня пятницы!
Почти дежавю: habrahabr.ru/post/147247/#comment_4963128
Я знаю, как Deffe может исправить ситуацию.
Ничего лучше «пыхи» здесь быть не может? :-)
Капитан ПХП идет на помощь!
itmages.ru/image/view/585443/11cf38f0
(Сорри, не могу вставить картинку прямо в комментарий.)
itmages.ru/image/view/585443/11cf38f0
(Сорри, не могу вставить картинку прямо в комментарий.)
Я тоже сначала пост по вашей ссылке прочитал, а потом здесь
Зачет!
> Да, у PHP сейчас лучший менеджер зависимостей из всех языков.
говорить так и менеджере зависимостей, который был inspired by npm — это по крайней мере смешно
> PHP все еще является наипростейшим языком для изучения не-техническими людьми
и именно это же является одной из его слабых сторон
> Давайте я вам рассскажу маленький секрет успеха PHP
нет, спасибо
говорить так и менеджере зависимостей, который был inspired by npm — это по крайней мере смешно
> PHP все еще является наипростейшим языком для изучения не-техническими людьми
и именно это же является одной из его слабых сторон
> Давайте я вам рассскажу маленький секрет успеха PHP
нет, спасибо
именно это же является одной из его слабых сторон
Это преимущество, а не недостаток. То, что таким образом появляются «непрофессионалы» — проблема их самих, а не языка.
нет, спасибо
Аргументируете? Сами-то на чем пишете? Чем оно лучше? Оно успешнее РНР?
На последний вопрос сам и отвечу: как видно из предоставленной в статье статистики — нет.
> PHP все еще является наипростейшим языком для изучения не-техническими людьми
> и именно это же является одной из его слабых сторон
когда простота была «плохой»?
> и именно это же является одной из его слабых сторон
когда простота была «плохой»?
Простота плоха тем, что привлекает в область много профанов, которые считают, что научились программировать после того как сделали свой первый сайт. Этим же плохи современные доступные по цене зеркалки.
А вам то что до них? Ну профаны и профаны, конкуренцию специалистам они не сощдают, заполняя те ниши, которые те самые специалисты считают для себя недостойными.
Я же не писал, что переживаю из-за них. Просто таков сам факт и это в свою очередь формирует представление о языке и навыках, необходимых для разработки того или иного продукта.
(написано по просьбе 1999)
(написано по просьбе 1999)
Если вы говорите, что PHP быстро развивается, то точно не видели Ruby и Python. Эти языки чуть ли не на прорядок быстрее развиваются.
Гиперболы в разговорах о PHP, как я вижу, не редкость, а норма.
Я ещё меньше года назад программировал на PHP… не успел я ещё гиперболизироваться.
Чтобы не быть голословным…
> Загляните на Packagist — основной репозиторий для Composer: в нем уже находится более 1900 пакетов и они были установлены более миллиона раз меньше чем за 3 месяца.
rubygems.org/
725,855,681 downloads
of 41,114 gems cut since July 2009
Ещё стоит учитывать, что Ruby разработчиков меньше, чем PHP…
> Загляните на Packagist — основной репозиторий для Composer: в нем уже находится более 1900 пакетов и они были установлены более миллиона раз меньше чем за 3 месяца.
rubygems.org/
725,855,681 downloads
of 41,114 gems cut since July 2009
Ещё стоит учитывать, что Ruby разработчиков меньше, чем PHP…
маленькая особенность: since July 2009
3 месяца vs 3 года
3 месяца vs 3 года
Я не совсем понял, вы сравнили количество скачанных ruby пакетов с количеством добавленных php пакетов?
725 млн. вс 1 млн
41114 вс 1900
3 года вс 3 месяца
41114 вс 1900
3 года вс 3 месяца
Так и не понял, что вы хотели сказать этими цифрами. Что за 3 года ruby пакетов добавили больше, чем php за 3 месяца?
Судя по твитам Фабьена, следующая его статья будет о том, чем, собственно, composer лучше bundler'a ;)
Судя по твитам Фабьена, следующая его статья будет о том, чем, собственно, composer лучше bundler'a ;)
Одна тонкость — для руби это официальный и едва ли не единственный источник?
Для PHP же — это одна из множества альтернатив, о которой ещё далеко не все знают, поскольку неофициальная.
Сравнение некорректно.
Для PHP же — это одна из множества альтернатив, о которой ещё далеко не все знают, поскольку неофициальная.
Сравнение некорректно.
Это не тонкость, а сила языка. Нормальные программисы просто так делятся нормальным кодом.
А в PHP-мире каждый второй сидит со своей CMS или велосипедом, боится показывать… иногда правда показывает и просит не малую цену.
А в PHP-мире каждый второй сидит со своей CMS или велосипедом, боится показывать… иногда правда показывает и просит не малую цену.
С другой стороны как-то нет на слуху CMS на языках отличных от PHP. Фреймворки есть, CMS нет.
Те, кому нужны были CMS на Ruby, знают хотя бы парочку. Причем больная часть CMS — это надстройка над ROR.
Обычно людям нужна (если формализировать их требования) просто CMS, может несколько кастомных модулей к ней. Почему-то выбирают CMS на PHP и заказчики, и исполнители. Сам не знаю почему выбираю :) Может мало документации?
В 2000-2005 году рынок был переполнен дешевыми китайскими велосипедами с кучей перделок и все их покупали. Сейчас не один нормальный человек за такую кучу стали не сядет.
Надеюсь и web-программисты образумятся.
Надеюсь и web-программисты образумятся.
Лучше плохо ехать, чем хорошо идти. Дарёному (почти) коню в зубы не смотрят. И т. п. Нормальных людей больше интересует соотношение цена/качество, а не качество само по себе.
> Лучше плохо ехать, чем хорошо идти. Дарёному (почти) коню в зубы не смотрят.
Вообще не понял, о чем вы…
> Нормальных людей больше интересует соотношение цена/качество
У нас множество людей интересует только халява =)
Вообще не понял, о чем вы…
> Нормальных людей больше интересует соотношение цена/качество
У нас множество людей интересует только халява =)
Что-то мне подсказывает, что китайские велосипеды дешевле своих «оригиналов» были. Причём в цену оригиналов была и заложен т. н. интеллектуальная собственность и прочий НИОКР, на который китайцы не тратились.
Я это заметил и потому больше «финансовую подушку» не создаю, иначе встречу интересную задачу и буду приплачивать за возможность её решить :)
Я это заметил и потому больше «финансовую подушку» не создаю, иначе встречу интересную задачу и буду приплачивать за возможность её решить :)
UFO just landed and posted this here
Люди выставляют «ТЗ», я уточняю неясные моменты и предлагаю ценник и сроки. За интересные задачи — скидка. Что они считают за качество мне не интересно, вся инфа (плюс-минус лапоть) у них есть.
UFO just landed and posted this here
Я предлагаю на выбор сайт на симфони и на рельсах, на рельсах в 1,5 раза дольше и в 1,5 раза дешевле. Никто не выбрал на рельсах!
UFO just landed and posted this here
На рельсах в 2-3 раза быстрее получается, если сравнивать ROR и Symfony.
UFO just landed and posted this here
У вас быстрее, у меня медленнее. На рельсах у меня быстро прототипы получаются, решения в лоб и т. п. Когда начинаются нестандартные сценарии, то предпочитаю переходить на симфони.
UFO just landed and posted this here
> Когда начинаются нестандартные сценарии, то предпочитаю переходить на симфони.
Пример, пример пишите. Никогда у меня такого не было, все гладко списывается.
Пример, пример пишите. Никогда у меня такого не было, все гладко списывается.
Может у вас более глубокие знания Ruby и/или RoR чем у меня. А может у меня более глубокие symfony2. И уж точно production окружение для php на голом debian/ubuntu я быстрее разверну раз в 100 чем рельсовое, лезть в ману или гуглить не потребуется.
Есть такие решения как capistrano и подобные. На голом сервере все само разворачивается одной командой.
Руками приложение я разворачивают 5-10 минут… и то большая часть времени качаются пакеты и гемы.
Руками приложение я разворачивают 5-10 минут… и то большая часть времени качаются пакеты и гемы.
Смотрите, ставите…
— nginx
— postgres
— rvm
Дальше создать пользователя в базе, подправить конфиг. Качаете гемы и запускаешь unicorn… все…
— nginx
— postgres
— rvm
Дальше создать пользователя в базе, подправить конфиг. Качаете гемы и запускаешь unicorn… все…
Это я умею (только мускул предпочитаю, вроде же в рельсах есть DBAL), правда не нравится что при установке rvm приходится осуществлять лишние разумные действия — не заскриптуешь.
А кроме единорога есть ещё 100500 способов запустить рельсы. Мне почему-то пассажир ближе, а там тоже заморочки… Причём вроде есть deb пакет, но он совместим только с дебиан, а под убунтой не разрезолвить. И вообще само «качаете гемы» предполагает большее взаимодействие с сервером чем закачка файлов по scp.
А кроме единорога есть ещё 100500 способов запустить рельсы. Мне почему-то пассажир ближе, а там тоже заморочки… Причём вроде есть deb пакет, но он совместим только с дебиан, а под убунтой не разрезолвить. И вообще само «качаете гемы» предполагает большее взаимодействие с сервером чем закачка файлов по scp.
Я предпочитаю ровно наоборот. Максимум нагрузки на бэкенд. И да, через RESTful. :)
UFO just landed and posted this here
PUT /hubs/123/posts/15678/comments/56689['carma' => '+1']
Вообще лучше сделать просто…
PUT /comments/56689['carma' => '+1']
Иначе Rails сделает 3 запроса вместо одного.
PUT /comments/56689['carma' => '+1']
Иначе Rails сделает 3 запроса вместо одного.
Путь обеспечивает выбор нужного представления для редиректа.
Обычно такие запросы посылаются асинхронно… тут это не нужно, надуманно.
Так они и посылаются асинхронно. Просто в разных ситуациях разное представление.
Не понимаю о каком вы представлении. Ответ должен быть в виде JSON с кодом выполнения (успешно или нет) и вспомогательной информацией типа нового значения кармы.
Простите, а что такого нестандартного на RoR равно экзекуции, а на Symfony/Yii/etc — нормально?
Скорее самого языка касается, а не фреймворков. Проблемы составляет реализация бизнес-логики сложнее чем CRUD. Мне (почти) очевидна её реализация на PHP или C, а на Ruby я постоянно удивляюсь, если получается нагуглить решение.
Возможно вы плохо знакомы с языком? Метапрограммирование довольно хитрая вещь.
Я этого не отрицаю. Книги по метапрограммированию читал, но счёл, что большей частью оно схоже использованию отражений в PHP, то есть годится для библиотек или фреймворков с тщательно и подробно документируемым поведением. Я избегаю «магии» в коде.
В Ruby магия сплош и рядом. И при длительном изучении все получается очень просто. Такое поведение заложено в философии…
Язык следует принципу «наименьшей неожиданности»: программа должна вести себя так, как ожидает программист. Однако в контексте Ruby это означает наименьшее удивление не при знакомстве с языком, а при его основательном изучении.
Вы скорее всего гораздо лучше знаете PHP, только и всего. Github на рельсах написан, а логика там явно за рамками CRUD. Да и Ruby позволяет такое, чего я на PHP даже не представляю (это уже со своей колокольни) :-)
UFO just landed and posted this here
Большая часть метапрограммирования, блоки, все, благодаря чему можно писать лаконичный и красивый код. попробуйте на php написать гем (ну ладно, PEAR модуль или что там сейчас в моде), который будет предоставлять такой синтаксис:
every 3.hours { awesome 'task', option: 'value' }
Задача «предоставлять такой синтаксис» заведомо не корректна. Сформулируйте какую функциональность этот синтаксис предоставляет и как часто она встречается в проектах, написанных с нуля.
Функциональность? Писать лаконичный и понятный код, это для многих уже достаточный аргумент. Встречается во всех хороших проектах :-) Если знакомы с рельсами, должны были увидеть что различные DSL распространены довольно широко. Да, все это можно написать и на php, но будет гораздо уродливее (даже Yii сравнить с RoR, видно что ребята старались соответствовать, но сам язык подвел).
Я так подозреваю, что гитхаб всё же основан на какой-то СУБД и/или плоском хранилище. Какие операции доступа к внешнему сервису позволяет руби и не позволяет пэхэпэ?
UFO just landed and posted this here
Я предпочитаю решать задачу заказчика наиболее эффективным из известных мне способов. Я считаю деньги заказчика, чтоб за как можно меньшее число часов ему мне пришлось платить. Если задача интересная, то ещё и скидку делаю.
UFO just landed and posted this here
Даже немного раньше :) Мне интересней разрабатывать под фреймворками или даже с нуля.
UFO just landed and posted this here
По личному опыту CMS (вкупе с популярными модулями/плагинами/...) решают задачи процентов на 90.
UFO just landed and posted this here
Значит вы (сайт я как понял ваш?) не смогли сформулировать свои требования. Я, как исполнитель, в случаях когда «ТЗ» заказчика допускает двоякое трактование всегда уточняю все нюансы. В частности интересует заказчика ли заказчика стоимость поддержки. Верите — нет, но мне зачастую проще и экономически выгоднее накидать костылей на CMS, я уточняю у заказчика и если его это устраивает делаю ему скидку.
Ребят, неужели вас так легко затроллить? :)
Понятно что Fabien в некоторых моментах приукрасил, просто чтобы привлечь внимание (что, кстати, явно удалось :D). А внимание он (ну и я, как переводчик) хотел привлечь к тому что PHP — уже давно не то, что вы пробовали в школе в 2005 году.
Теперь это полноценный язык, который очень быстро развивается и с очень активным коммюнити. И прежде чем писать очередной пост ненависти в сторону PHP — посмотрите что нового произошло. Вполне может быть что вам даже понравится.
Понятно что Fabien в некоторых моментах приукрасил, просто чтобы привлечь внимание (что, кстати, явно удалось :D). А внимание он (ну и я, как переводчик) хотел привлечь к тому что PHP — уже давно не то, что вы пробовали в школе в 2005 году.
Теперь это полноценный язык, который очень быстро развивается и с очень активным коммюнити. И прежде чем писать очередной пост ненависти в сторону PHP — посмотрите что нового произошло. Вполне может быть что вам даже понравится.
Я знаю, сам пишу движок под PHP 5.4, и будьте уверенны, в курсе, как он развивается.
Просто это мой субъективный взгляд со стороны на статьи об PHP. Одни хотят унизить PHP посильнее, а вторые вознести к небесам. Мне нравится язык, но объективность точки зрения в статьях часто страдает.
Просто это мой субъективный взгляд со стороны на статьи об PHP. Одни хотят унизить PHP посильнее, а вторые вознести к небесам. Мне нравится язык, но объективность точки зрения в статьях часто страдает.
Действие рождает противодействие. Если не возносить к небесам, то унизят и общая картина объективна не будет. А так минус на плюс даёт ноль и общую картину можно считать объективной. :)
Какой смысл в движке конкретно под PHP 5.4. Поясните, пожалуйста.
Движок пишется не под PHP 5.4, а с его использованием. То есть с использованием тех особенностей, которых не было в предыдущих версиях. Не совсем корректно выразился изначально.
Например, поведение $this в замыканиях, вызовы типа
И тому подобное.
Просто такие конструкции в определённых ситуациях сильно пригождаются, позволяют писать более компактный и быстрый код. А ещё чаще это просто удобно.
Например, поведение $this в замыканиях, вызовы типа
echo (new Class())->{'some crazy function with spaces'}($value)[0][1];
И тому подобное.
Просто такие конструкции в определённых ситуациях сильно пригождаются, позволяют писать более компактный и быстрый код. А ещё чаще это просто удобно.
За одну возможность писать [...] вместто array(...) я был готов продать душу дьяволу, но обошлось без этого. Жду предложения по типизации выражений и…
Я чуть меньше года назад ушел с PHP, но слежу за всеми новостями из этого, копаюсь в новых фреймворкам. Иногда просят что-то подправить на PHP-сайтах.
Вы не правы. О быстром развитии — это вовсе не гипербола. Гиперболы в разговорах о PHP чаще всего только в разговорах о недостатках этого языка. Мало кто знает о его реальных возможностях. Чаще всего люди под влиянием всех этих «критиков» уходят из PHP раньше, чем успевают изучить его, а потом рассказывают о преимуществах других языков и недостатках PHP.
Ага, развиваются: python3wos.appspot.com/ :)
Изменения в PHP пока что по большому счёту были обратно-совместимыми. Разве что выпиливание отдельных элементов типа register_globals.
Но думается мне, что если в PHP что-то поменяют так, что большинство существующих проектов перестанут работать на новой версии, боюсь, и для PHP появится такая стена позора.
Возможно, разработчики PHP просто поступают осторожнее, внося изменения аккуратно.
Но думается мне, что если в PHP что-то поменяют так, что большинство существующих проектов перестанут работать на новой версии, боюсь, и для PHP появится такая стена позора.
Возможно, разработчики PHP просто поступают осторожнее, внося изменения аккуратно.
UFO just landed and posted this here
Ну я как бы и не утверждал обратного.
Это просто ответ на комментарии «PHP недостаточно быстро развивается» и «другие языки развиваются быстрее».
Есть разница между развитием и переделыванием. Python как раз переделали — получили 2 активно используемые, но практически несовместимые версии и сообщество, которое вот уже 4 года не могут заставить перейти на новую ветку.
Это просто ответ на комментарии «PHP недостаточно быстро развивается» и «другие языки развиваются быстрее».
Есть разница между развитием и переделыванием. Python как раз переделали — получили 2 активно используемые, но практически несовместимые версии и сообщество, которое вот уже 4 года не могут заставить перейти на новую ветку.
У меня огромный проект перешел с 5.2 на 5.3 вообще без никаких проблем.
Да, с переходом с 4 на 5 версию были бы проблемы, но время 4 ветки ушло еще в 2005 году, сегодня навернякапрощелучше переписать приложение, будет и быстрее и более поддерживаемее.
Да, с переходом с 4 на 5 версию были бы проблемы, но время 4 ветки ушло еще в 2005 году, сегодня наверняка
UFO just landed and posted this here
Я бы сюда ещё C# приплел, угнаться за ним многим сложно.
Главная задача на близкое будущее — чтобы поддержка 5.4 появилась в услугах виртуального хостинга, а не только при ручной настройке сервера. Многие рядовые пользователи пользуются именно такой услугой, а там только 5.3, да и то не так давно появился.
А Руби-то с Питоном на виртуальных хостингах завались, конечно.
Есть не мало решений типа heroku.com, есть дешевле.
Про Руби не знаю, но Питона, вообще-то, завались.
Шо ви говорите?
Вот я прям щас попытался найти хостинг с поддержкой Python 3.2 и не нашел ничего на первой странице выдачи + рекламе. (Если точнее, ни на одном хостинге «с поддержкой Python» я не нашел указания версии совсем.)
Вот я прям щас попытался найти хостинг с поддержкой Python 3.2 и не нашел ничего на первой странице выдачи + рекламе. (Если точнее, ни на одном хостинге «с поддержкой Python» я не нашел указания версии совсем.)
обычно у заказчика требующего python/ruby найдётся 10-20уе/мес на нормальный VPS…
хотя если вы намекаете, что ниша РНР — малонагруженны сайты на 1 долларовых недохостингах, тогда вопросов не имею)
ну и про «хостинг» (хостинги в том виде, в котором они есть в РНР, малопопулярны в других языка) с py3.2 — docs.webfaction.com/software/python.html
хотя если вы намекаете, что ниша РНР — малонагруженны сайты на 1 долларовых недохостингах, тогда вопросов не имею)
ну и про «хостинг» (хостинги в том виде, в котором они есть в РНР, малопопулярны в других языка) с py3.2 — docs.webfaction.com/software/python.html
А что, много проектов есть на Python 3.2?
Думаю, примерно как на PHP 5.4
С питоном немного другая история. Насколько я знаю, сообщество до сих пор саботирует переход на python 3.x, т.к. обратной совместимости нет, а пользы от него мало. Полезные нововведения дублируются в ветке 2.x. Главный фреймворк — Django — только еще анонсирует экспериментальную поддержку Python 3.3. Какой смысл держать на хостинге Python 3? Для крутых программистов, которые хотят экспериментировать? Так вирутальный хостинг им не подходит по многим другим причинам.
Я как бы в курсе :)
Ветка началась с жалобы на то, что развитие PHP задерживает отсутствие 5.4 на виртуальных хостингах.
Ну так вот, с актуальными версиями Питона и Руби (да и вообще с хостингом Питона и Руби) всё куда как печальнее. А про node.js я вообще молчу.
Ветка началась с жалобы на то, что развитие PHP задерживает отсутствие 5.4 на виртуальных хостингах.
Ну так вот, с актуальными версиями Питона и Руби (да и вообще с хостингом Питона и Руби) всё куда как печальнее. А про node.js я вообще молчу.
Всё так, но актуальная версия Python — 2.7.3.
А PHP — 5.0 ;)
Я понимаю, что вы шутите, но нас читают дети.
Для них я на всякий случай напишу это:
PHP 5 was released in July 2004.
Python 2.7.3 — 11 April 2012.
Для них я на всякий случай напишу это:
PHP 5 was released in July 2004.
Python 2.7.3 — 11 April 2012.
Я не понял смысла вашего ответа.
«Актуальная» версия PHP — это 5.2.17, выпущенная 6.01.2011
Именно оно и стоит на большинстве хостингов, потому что ветки 5.0-5.2 практически не отлисаются в плане обратной совместимости.
5.3 и 5.4 — совсем другая песня. Не того, конечно, масштаба, что Python 3.x или Ruby 1.9, но что-то рядом. Его пока ставят неохотно — оно и понятно.
Так что ситуация, в общем-то, очень похожая у PHP и у Python/Ruby
«Актуальная» версия PHP — это 5.2.17, выпущенная 6.01.2011
Именно оно и стоит на большинстве хостингов, потому что ветки 5.0-5.2 практически не отлисаются в плане обратной совместимости.
5.3 и 5.4 — совсем другая песня. Не того, конечно, масштаба, что Python 3.x или Ruby 1.9, но что-то рядом. Его пока ставят неохотно — оно и понятно.
Так что ситуация, в общем-то, очень похожая у PHP и у Python/Ruby
Ну вот у меня 3.1 есть (и в тарифах написано). Нужен 3.2? Не проблема — никто не спрашивал. Может на следующей неделе и сделаю. diphost.ru
Вообще странно про «ни на одном». В РФ практически три хостинга когда-либо позиционировавшие себя как хостинги с Python — netangels, мы и каким-то боком jino.
Вообще странно про «ни на одном». В РФ практически три хостинга когда-либо позиционировавшие себя как хостинги с Python — netangels, мы и каким-то боком jino.
www.google.com/search?q=python+хостинг
Вижу только Джино с Питоном 2.7
Вижу только Джино с Питоном 2.7
Было бы круто там еще RoR… Через passenger ( видимо 3.2 ) или Unicorn…
Эх, а то в рунете пока кроме locum толком не податься.
Эх, а то в рунете пока кроме locum толком не податься.
Неясна ситуация со стабильностью руби 1.9.3. Судя по списку рассылки freebsd что-то там провалилось с портированием. Самим кишка тонка. Также не ясно кто будет и как поддерживать пользователей. RoR — это как и Java совершенно отдельная религия. Мы сами программисты, мы можем и Python посмотреть, и php, и Си. Но RoR это идеология и там уже начинается. Вопрос — сможем ли мы обеспечить поддержку пользователей на хотя бы удовлетворительном уровне?
Ну если FreeBSD и проблемы с портами то действительно сложно.
Ну и без Rails девелопера да, может быть сложновато учитывать нюансы.
Но ниша открыта, реализуется это либо через mod_rails(passenger) к Apache/Nginx, либо через reverse proxy к unicorn.
Ну и без Rails девелопера да, может быть сложновато учитывать нюансы.
Но ниша открыта, реализуется это либо через mod_rails(passenger) к Apache/Nginx, либо через reverse proxy к unicorn.
1. freebsd хрен с ним. там была проблема что не все порты зависимые пересобрались с 1.9.3. это в контексте обсуждения не существенно
2. а вот девелопер — это да. представьте его ФЗП и какая наценка должны быть только чтобы его существование окупить.
3. мы уже проходили с wsgi это. ниша открыта, мы в неё первыми удачно вломились вплоть до хостинга clck.ru и прочих бобуковских проектов и это… 5% наших клиентов. такой расклад делает неокупаемым (2)
4. ну я не первый день замужем :) естественно я отлично знаю как это делается. на хостинге даже сделано для ruby 1.8.6, но введено в тарифы и возможности хостинга, используется только для внутренних проектов.
2. а вот девелопер — это да. представьте его ФЗП и какая наценка должны быть только чтобы его существование окупить.
3. мы уже проходили с wsgi это. ниша открыта, мы в неё первыми удачно вломились вплоть до хостинга clck.ru и прочих бобуковских проектов и это… 5% наших клиентов. такой расклад делает неокупаемым (2)
4. ну я не первый день замужем :) естественно я отлично знаю как это делается. на хостинге даже сделано для ruby 1.8.6, но введено в тарифы и возможности хостинга, используется только для внутренних проектов.
По поводу второго пункта — вполне может быть, раз вы сами знаете что такое passenger и unicorn, то вам понадобятся просто консультации, а не человек в штате.
Или, например, просто открытость к тикетам в поддержку со стороны Rails проектов.
По поводу «ниши» — это какая-то история с положительной/отрицательной обратной связью. Нету shared Rails хостинга — никто не берется делать сайты в этой нише на Rails, никто не берется — нету хостинга. Это скорее стратегический проект, который бы помог бы выделится на фоне конкурентов. Ну и совершенно не обязательно делать Rails в дешевых тарифах.
Но вообщем конечно да, не моя компетенция считать что Вам выгодно, а что — нет.
Или, например, просто открытость к тикетам в поддержку со стороны Rails проектов.
По поводу «ниши» — это какая-то история с положительной/отрицательной обратной связью. Нету shared Rails хостинга — никто не берется делать сайты в этой нише на Rails, никто не берется — нету хостинга. Это скорее стратегический проект, который бы помог бы выделится на фоне конкурентов. Ну и совершенно не обязательно делать Rails в дешевых тарифах.
Но вообщем конечно да, не моя компетенция считать что Вам выгодно, а что — нет.
на хостинге даже сделано для ruby 1.8.6
Ruby 1.8.6 уже сильно не актуален. Уже состоялся последний релиз Ruby 1.8.7, осталось 11 месяцев, в которые при необходимости будут выпускать security-патчи и на этом всё.
Так что если будете делать хостинг для Ruby, делайте поддержку только 1.9.3+
Кстати, а почему jino каким то боком? Полноценно вроде поддерживает да и саппорт может нужную тебе версию поставить.
Завались то завались, но в основном через cgi работает питон, а какой нибудь wsgi это большая редкость или за такие деньги, что проще vds дешевый взять. Но к минусам я это не отношу )
Просто распространенность PHP на виртуальном хостинге одно из ключевых преимуществ. Легко найти хостера, легко найти CMS, легко установить и пользоваться — для многих это существенный плюс.
И легко найти того, кто сам всё это сделает за смешные деньги. Иногда кажется, что админы-фрилансеры ценник заряжают не по трудоемкости, а по ключевым словам в ТЗ. Увидели Django — +N%, увидели RoR — +2N%, увидели Node.js — +5N%.
Не скажу за всю Одессу © Но среди ведущих хостингов Украины php5.4 уже поддерживается вовсю. У мелких меинстрим тем более никогда не был проблемой.
Друг вообще откатился пол года назад на 5.2 на своём сервере из-за того, что одно проприетарное решение не работало на 5.3. Вот и не торопятся на хостингах. А то вроде бы и не виноваты, а клиент материт.
Не понимаю тех, для кого проблема взять под проект дешевый vds с поддержкой от хостера, если чего-то нет на шареде. Это ж какой бюджет должен быть у сайта, чтобы такое не понятнуть.
Не в бюджете дело, а в администрировании. На шареде почти все настройки ОС, nginx/Apache, MySQL, самого PHP вне зоны ответственности разработчика сайта. Максимум рекомендует тот или иной хостинг. А рекомендуя VDS заказчику сразу встаёт вопрос, а кто его будет настраивать и поддерживать. А поддержка от хостера уже не дешевое удовольствие.
Не знаю, сейчас хостеры так налегают на облака, что готовы предоставлять саппорт типовых конфигураций за весьма небольшие деньги, иногда даже бесплатно. Если в типовой конфигруации поменять версию php, сильно ситуация не поменяется.
hostpro.ua/ru/cloud — обещают помогать чуть ли не бесплатно. Ну это первое что подвернулось под руку.
hostpro.ua/ru/cloud — обещают помогать чуть ли не бесплатно. Ну это первое что подвернулось под руку.
UFO just landed and posted this here
У нас уже недели как три есть. Особо никому не нужно.
Здесь есть существенная ложка мёда (и отдушина для Ruby с Python'ом) — VPS это уже не редкость и все более менее солидные хостинги его предлагают по цене не дороже привычного виртуального. А там уже можно настроить многое, чего не будет на виртуальном и даже более того, выше уровень обеспечения безопасности, если она имеет хоть какое-то значение (для меня это уже давно насущный вопрос) — она уже не зависит от соседей по хостингу.
Просто, быстро, удобно. Надо будет, перейду на что-нибудь другое.
Быстрая эволюция языка — как раз свидетельство серьезных проблем, заложенных изначально. И куча головной боли, для разработчиков, заодно.
Соглашусь. Хотя, с другой стороны, в случае php эта эволюция обеспечена сменой назначения языка.
С простого инструмента для создания динамических страничек,
до простого средства разработки несложных сайтов,
до средства разработки проектов средней сложности с большим порогом входа,
потом еще несколько этапов и наконец до универсального языка разработки веб-проектов любой сложности.
Естественно, для того чтобы шагнуть на новую ступень, нужно многое изменить. Радует, что дальше вряд ли будут сильно менять уже. Разве что, захотят идти в энтерпрайз, но думаю, не захотят.
С простого инструмента для создания динамических страничек,
до простого средства разработки несложных сайтов,
до средства разработки проектов средней сложности с большим порогом входа,
потом еще несколько этапов и наконец до универсального языка разработки веб-проектов любой сложности.
Естественно, для того чтобы шагнуть на новую ступень, нужно многое изменить. Радует, что дальше вряд ли будут сильно менять уже. Разве что, захотят идти в энтерпрайз, но думаю, не захотят.
Linux тоже оч шустро развивается. Что, конечно же, свидетельствует о серьезных проблемах, заложенных изначально.
А вот выше сказали что питон и руби развиваются быстрее :)
Я уже перешёл на похапэ, вот уже как 7 лет.
Меня в php радует поддержка большими компаниями и появление таких замечательных утилит, как hiphop, которые позволяют получить отличную скорость и работы кода и разработки, одновременно.
cython, сто лет как.
Берем обычный код на питоне, обрабатываем этой штукой и получаем с++ код, который компилится и работает практически как нативный на с++? Я не думаю.
Ну, зря, думать полезно.
UFO just landed and posted this here
Читая википедию: Cython — язык программирования, упрощающий написание модулей С/С++ кода для Python.. Я не в курсе деталей, возможно там не сильно корректно написано, но судя по этому, язык все-же не совсем такой и код таки придется переделывать.
Родной питоновский код будет компилироваться cython'ом, за некоторыми ограничениями (которые так же есть у hiphop'a), просто, если использовать специальный диалект (тот же питон + объявления типов данных, которые будут использоваться в c'шном коде (если не указывать, то практически везде будет использоваться тип PyObject)), выгода от компиляции в нативный код будет выше.
У hiphop основное ограничение — не использовать eval и другой динамический код. Остальное связано, в основном, с расширениями. Потому, многие существующие движки, типа вордпресса (с дурным количеством кода) им нормально компилируются. Точнее, движки, часто, надо немного подпилить (избавиться от динамического кода), но объем работ там сравнительно небольшой.
Кстати, почему вообще пишут на питоне, если есть cpython? Ну я не про небольшие скрипты, а про веб-проекты на джанге, например.
Кстати, почему вообще пишут на питоне, если есть cpython? Ну я не про небольшие скрипты, а про веб-проекты на джанге, например.
Нет.
Берете код на питоне, профайлите его, находите узкие тяжелые вычислительные места, например, перемножения матриц.
С помощью этой штуки переписываете конкретные тяжелые функции на С и легко интегрируете с остальным кодом на питоне.
Профит.
Берете код на питоне, профайлите его, находите узкие тяжелые вычислительные места, например, перемножения матриц.
С помощью этой штуки переписываете конкретные тяжелые функции на С и легко интегрируете с остальным кодом на питоне.
Профит.
Хм. Ну можно экстеншн написать и под php, в чем профит? Надо Сишного кодера искать, как минимум. Как максимум, на высоконагруженном сайте может не быть узкого места, а он будет тормозить потому, что будет стандартный код в интерпретаторе крутиться (контроллер, там, проверки разные, подключения библиотек и т.д.).
Я описывал ниже пример, взял обычный сайт, где код выполняется достаточно ровно и узких мест, как таковых, нет. Просто перекомпилировал через hiphop + g++ и получил скорость отклика в 30 раз быстрее. Не думаю, что у меня получится, если я перепишу узкие места на Си. Ну разве что весь сайт в виже extension делать, но, думаю, даже в этом случае, на инициализацию уйдет много времени.
Я описывал ниже пример, взял обычный сайт, где код выполняется достаточно ровно и узких мест, как таковых, нет. Просто перекомпилировал через hiphop + g++ и получил скорость отклика в 30 раз быстрее. Не думаю, что у меня получится, если я перепишу узкие места на Си. Ну разве что весь сайт в виже extension делать, но, думаю, даже в этом случае, на инициализацию уйдет много времени.
Лично у меня все претензии не к PHP, а к пехепешникам. Качество кода, количество мозга и так далее…
особенно это видно по govnokod.ru
Не думаю, что качество моего кода или, тем более, количество мозга у меня сильно меняется в зависимости от того на каком языке пишу, будь то PHP, Ruby, Python, Erlang или JS (языки на которых писал что-то посложнее helloworld за последние года 3). Более того, есть подозрение, что код на PHP у меня более качественный. Чисто потому что в куда большем количестве чужого кода разбирался.
ИМХО, в каждом языке есть и гуру, но есть и быдлокодеры, просто порог вхождения последних разный. PHP простой и даёт множество функций из коробки (сравните, например, с С++), поэтому многие новички, которые даже не знают, что есть так называемое качество кода, начинают именно с него. Глупо предъявлять претензии ко всем пхпшникам, есть множество грамотных, сам общаюсь с ними лично.
Есть такой момент. Но:
1) Когда количество кодеров и сайтов на рельсах и джанго догонят пехепе, тогда вы удивитесь, как же много говнокода на любимом руби или питоне :)
2) Так исторически сложилось, что пхп во многих случаях используется в чистом виде: когда-то фреймворков толком и не было, а сейчас пойди подбери что-то среди этого разнообразия. Зоопарк разных подходов, идей и концепций. Зато наклепать «сайтик» на PHP можно моментально, даже не зная слова «фреймворк». Отсюда обилие велосипедов и говнокода: каждый пишет в меру своей распущенности и язык этому никак не препятствует.
Рельсы или же джанго загоняют пограммиста в относительно жёсткие рамки: простора для говнокода остаётся гораздо меньше. А без фреймворка, на чистом питоне или руби сайты писать как-то не принято.
1) Когда количество кодеров и сайтов на рельсах и джанго догонят пехепе, тогда вы удивитесь, как же много говнокода на любимом руби или питоне :)
2) Так исторически сложилось, что пхп во многих случаях используется в чистом виде: когда-то фреймворков толком и не было, а сейчас пойди подбери что-то среди этого разнообразия. Зоопарк разных подходов, идей и концепций. Зато наклепать «сайтик» на PHP можно моментально, даже не зная слова «фреймворк». Отсюда обилие велосипедов и говнокода: каждый пишет в меру своей распущенности и язык этому никак не препятствует.
Рельсы или же джанго загоняют пограммиста в относительно жёсткие рамки: простора для говнокода остаётся гораздо меньше. А без фреймворка, на чистом питоне или руби сайты писать как-то не принято.
Не то что не принято, а очень трудозатратно, если не CGI писать — написать страничку с «hello world» означает сначала написать сервер, обрабатывающий запросы — сокеты и т. п. А PHP в стандартном конфиге сочетает удобство простоту CGI для разработки и куда большую скорость.
Что такое «стандартный кофиг»? mod_php? php-fpm?
PHP в чем-то знаетели и есть фрэймворк, если разобрать на части, то условном можно сказать, что это Perl (mod_perl) + CGI.pm + TemplateToolkit (или Mason).
Для Ruby чтобы работать в веб-окружении есть Rack подключается одной строкой, второй строкой подключается любимый сервер thin, третьей берите в руки Erb-шашку и RUBYте всех от плеча! Проблемы нет.
PHP в чем-то знаетели и есть фрэймворк, если разобрать на части, то условном можно сказать, что это Perl (mod_perl) + CGI.pm + TemplateToolkit (или Mason).
Для Ruby чтобы работать в веб-окружении есть Rack подключается одной строкой, второй строкой подключается любимый сервер thin, третьей берите в руки Erb-шашку и RUBYте всех от плеча! Проблемы нет.
Поэтому я и против бездумной популяризации Питона и Руби. В мире есть PHP. В него сливается большинство начинающих кодеров. А если человеку важна эстетическая составляющая, красота кода, качество библиотек — он задумается и найдет себе подходящее решение. Если нет, то останется с PHP и не будет портить жизнь другим.
PHP используется как основной язык на 77,9% среди всех сайтов
windows используется на ещё большем проценте комп«ютеров, так что теперь, на basic-е программировать?
PHP все еще является наипростейшим языком для изучения не-техническими людьми
Спорный момент, хотя в части именно веб-программирования пожалуй соглашусь. Результат — мы имеем кучу технически не сильно образованных людей, которые считают себя веб-программистами, и клепают „сайты“.
Экосистема — ну, каждый кулик свое болото хвалит, я вот слыхал что на C можно написать вообще все-все, что можно написать на другом языке, куча либ на все случаи жизни, IDE такие что сами код могут писать… Мечта, а не язык.
Ну и главное замечание к статье — чем же так PHP гораздо лучше, чем мы думаем, автор так и не обьяснил…
windows используется на ещё большем проценте комп«ютеров, так что теперь, на basic-е программировать?
PHP все еще является наипростейшим языком для изучения не-техническими людьми
Спорный момент, хотя в части именно веб-программирования пожалуй соглашусь. Результат — мы имеем кучу технически не сильно образованных людей, которые считают себя веб-программистами, и клепают „сайты“.
Экосистема — ну, каждый кулик свое болото хвалит, я вот слыхал что на C можно написать вообще все-все, что можно написать на другом языке, куча либ на все случаи жизни, IDE такие что сами код могут писать… Мечта, а не язык.
Ну и главное замечание к статье — чем же так PHP гораздо лучше, чем мы думаем, автор так и не обьяснил…
Тогда уж на C#, а не на basic. C# клёвый. Рекомендую.
Тем, что у многих о нём устаревшее представление, о PHP5.4 думают как о PHP3, да ещё считают, что пишут на нём только в «спагетти»-стиле. У вас лично может быть объективное и вы прекрасно знаете достоинства и недостатки как самого языка, так и экосистемы. Но многие этим похвастаться не могут, «не читал, н осуждаю» или «не знал, да забыл».
Что ж, не могу не согласиться, что PHP5.4 действительно сильно отличается от PHP3.
Делает ли это его таким же заслуживающим внимания как PHP3 — сомнительно.
Изначальная фишка php в том что он был действительно прост до опупения, и это позволило ему завоевать популярность. Но обвешивание языка шаблонизации (это отдельный разговор), поддержкой всего и вся, увы, не делает его самым крутым языком ;(
У php своя ниша, он идеально хорош для добавления несложной динамики в статический html, тут не поспоришь.
Но современные реалии таковы, что сайты уже не состоят из набора html-ек, это сложные движки, которые должны работать эффективно и надежно, а также удобно сопровождаться. У php проблемы и с первым, и с другим, и с третьим.
По пунктам:
Производительности perl-а php достиг с третьей версии, и фактически остановился (как и перл, но это другой разговор). Интерпретируемый язык не догонит C никогда, как кукурузник не догонит боинг, сколько реактивных двигателей на него не вешай. pecl-APC (или другие opcode кешеры) ещё помогает не сдохнуть php проектам под нагрузкой, hiphop сильно капризный и специфичный…
Надежность php обсуждать даже не смешно. Каждый релиз сопровождается тоннами исправленных багов, читаешь relnotes и радуешься «хорошо что меня это не касается и касаться не будет». Несовместимость самых версий, проблемы компиляции модулей на новых версиях… Не будем о плохом.
Ну и вернемся к самому языку как таковому. Честно признаюсь, не рассматривал подробно новшества php 5.4, не в курсе насколько елегантно они введены. Но учитывая, какой бардак происходит в именовании функций, в передаче параметров эти функциям, как реализованы RE и прочее… Что-то сомнительно что с версией 5.4 php заблистал утонченностью и элегантностью
В общем, IMHO и ещё раз IMHO, PHP — это как максимум начальный этап карьеры программиста, и чем быстрее его проскочить, тем лучше. Есть куча других языков и технологий, заслуживающих внимания.
Делает ли это его таким же заслуживающим внимания как PHP3 — сомнительно.
Изначальная фишка php в том что он был действительно прост до опупения, и это позволило ему завоевать популярность. Но обвешивание языка шаблонизации (это отдельный разговор), поддержкой всего и вся, увы, не делает его самым крутым языком ;(
У php своя ниша, он идеально хорош для добавления несложной динамики в статический html, тут не поспоришь.
Но современные реалии таковы, что сайты уже не состоят из набора html-ек, это сложные движки, которые должны работать эффективно и надежно, а также удобно сопровождаться. У php проблемы и с первым, и с другим, и с третьим.
По пунктам:
Производительности perl-а php достиг с третьей версии, и фактически остановился (как и перл, но это другой разговор). Интерпретируемый язык не догонит C никогда, как кукурузник не догонит боинг, сколько реактивных двигателей на него не вешай. pecl-APC (или другие opcode кешеры) ещё помогает не сдохнуть php проектам под нагрузкой, hiphop сильно капризный и специфичный…
Надежность php обсуждать даже не смешно. Каждый релиз сопровождается тоннами исправленных багов, читаешь relnotes и радуешься «хорошо что меня это не касается и касаться не будет». Несовместимость самых версий, проблемы компиляции модулей на новых версиях… Не будем о плохом.
Ну и вернемся к самому языку как таковому. Честно признаюсь, не рассматривал подробно новшества php 5.4, не в курсе насколько елегантно они введены. Но учитывая, какой бардак происходит в именовании функций, в передаче параметров эти функциям, как реализованы RE и прочее… Что-то сомнительно что с версией 5.4 php заблистал утонченностью и элегантностью
В общем, IMHO и ещё раз IMHO, PHP — это как максимум начальный этап карьеры программиста, и чем быстрее его проскочить, тем лучше. Есть куча других языков и технологий, заслуживающих внимания.
Скорость для php не проблема с тех пор, как появился странслятор в с++ код, который после компиляции работает на сравнимом с нативным кодом, уровне. Работает при этом эффективно и надежно (давно не слышал о каких-либо проблем с безопасностью на ФБ и ВК).
> Скорость для php не проблема с тех пор, как появился странслятор в с++ код
ага. от Facebook'а. Заточенный на Facebook. Неспособный скомпилировать >>90% кода на РНР.
ага. от Facebook'а. Заточенный на Facebook. Неспособный скомпилировать >>90% кода на РНР.
У меня проекты завелись достаточно легко на нем. Пока, правда, служебные, но с ними проблем небыло. Чуть подправить код пришлось, но почти тридцатикратное ускорение того стоит, как по мне. проблемы с основном с расширениями, но, учитывая скорость работы, большую часть из них можно заменить на php классы с аналогичной функциональностью.
UFO just landed and posted this here
К-во запросов в секунду. Полагаю, процессор (я в тонкосятх настройки по памяти не разбирался, там встроенный веб-сервер и как там настроить количество воркеров или что-то еще, я пока не в курсе).
UFO just landed and posted this here
Да, был код на php, работал через php-fpm+apc и nginx, я его через hiphop собрал в виде демона и ab показал 3200 запросов против 110 (тот-же сервер, загрузка процессора в обоих случаях 100%). База не использовалась, но работала шаблонизация (шаблоны скомпилены в php код), ну и стандартный контроллер, фильтрация данных и прочее. Код реальный, брал работающий самописный проект.
UFO just landed and posted this here
С реализацией да, у PHP постоянные проблемы. Как-то рассматривают частные случаи в строго определенном контексте. Скажем сделали валидными выражения func()[0] и (new Class())->method(), но надо проверять будет ли работать (new Class())[0]->method(); и с большой вероятностью не будет, чисто по опыту — не любят разработчики PHP общих решений. Операторы типа [] -> () применяются не к выражения какого-то типа, а к строго определенным конструкциям. Собственно это скорее не операторы с операндами, а трехэлементные конструкции имеющие смысл в строго определенных контекстах, причём в разных контекстах разный смысл.
Для меня он стал скорее заключительным этапом, полкарьеры метаний с чуть ли не с ассемблера до лиспа, а потом появилась задача сделать сайт, на Си оказалось неудобно, выбирал между Perl и PHP. Подкупила прежде всего схожесть синтаксиса, что программу на PHP я читать мог без подготовки, а на PERL нет. Для себя я могу писать на python или ruby, могу если приспичит написать на c/c++, ковырялся относительно недавно с Erlang и Scala. Но это для себя, хобби. Работа же — PHP: устойчивый спрос на рынке труда без требований типа «активный аккаунт на github». Были попытки перейти на Ruby(Rails) и Python(Django), но не смог решить организационные вопросы (проще говоря косячил) по причинами с ЯП не связанным — брался за новую работы не подчистив концы.
Для меня он стал скорее заключительным этапом, полкарьеры метаний с чуть ли не с ассемблера до лиспа, а потом появилась задача сделать сайт, на Си оказалось неудобно, выбирал между Perl и PHP. Подкупила прежде всего схожесть синтаксиса, что программу на PHP я читать мог без подготовки, а на PERL нет. Для себя я могу писать на python или ruby, могу если приспичит написать на c/c++, ковырялся относительно недавно с Erlang и Scala. Но это для себя, хобби. Работа же — PHP: устойчивый спрос на рынке труда без требований типа «активный аккаунт на github». Были попытки перейти на Ruby(Rails) и Python(Django), но не смог решить организационные вопросы (проще говоря косячил) по причинами с ЯП не связанным — брался за новую работы не подчистив концы.
> чисто по опыту — не любят разработчики PHP общих решений.
Они вообще боятся трогать парсер и лексер. Видно в многочисленных обсуждениях разных фич, затрагивающих эти два компонента.
Они вообще боятся трогать парсер и лексер. Видно в многочисленных обсуждениях разных фич, затрагивающих эти два компонента.
Что-то подобное подозревал. Судя по отсутствию формального описания синтаксиса, внутри творится чёрти что.
Сейчас не найду сслыку на обсуждение namespace'ов, но там был ад. Один из ключевых аргументов против :: был именно «лексер (или парсер) не сможет разобраться»
Они вообще хотят поменять лексер на более современный, ибо тот что сейчас не способен справится с новыми веяниями, у него нету контекста — отсюда и проблемы с тем, что некоторые вещи очень проблемно реализовать.
Если мне память не изменяет, то хотят на lemon parser пересесть и какая-то работа за кулисами там шла, но инфы почти нету.
Если мне память не изменяет, то хотят на lemon parser пересесть и какая-то работа за кулисами там шла, но инфы почти нету.
UFO just landed and posted this here
Не игнорируешь а ждешь массового распространения на шаредах версии поддерживающей нововведения. Нэймспэйсы и анонимные функции я сейчас использую активно. Через год-два наверное нчну использовать фишки 5.4.
UFO just landed and posted this here
Грубо говоря не знаю когда появился php, но когда мне поставили задачу создать сайт я выбирал из трех языков: C, PHP и Perl/ У PHP было только одно значимое для работодателя преимущество — прототип (как сейчас модно говорить) на нём я создал за день, На сишный мне трое суток понадилось, от перла после суток разбирательства я отказался в принципе.
UFO just landed and posted this here
99% не динамические? Вы уверены?
Конечно. Жду статические гугл с яндексом и прочие дропбоксы с фейсбуками.
Я думаю имелось ввиду, что сайты вполне могут обойтись без динамики… ну про 99% конечно утрированно, но нереально огромное кол-во сайтов можно было бы сделать статикой + минимум JS скриптов…
Ну. Сейчас обыкновенные заказчики (сайты визитки, сайты портфолио) все хотят либо галерею, либо новости или еще что-то подобное. Крайне неудобно делать такое статикой.
И что в таком случае делать сайтам, которые начинают развиваться?
В случае с CMS — просто ставится/включается соответствующий компонент, в случае со сгенерированным сайтом — создавать сайт с нуля?
При этом учтите, в современных CMS хорошо развито кеширование, которое приближает сайты на этих CMS по производительности к сайту на статике.
Но лично по поводу широкораспространённых бесплатных CMS спорить не готов — большинство из них мне сильно не нравятся (теоретически можно было бы сделать лучше).
В случае с CMS — просто ставится/включается соответствующий компонент, в случае со сгенерированным сайтом — создавать сайт с нуля?
При этом учтите, в современных CMS хорошо развито кеширование, которое приближает сайты на этих CMS по производительности к сайту на статике.
Но лично по поводу широкораспространённых бесплатных CMS спорить не готов — большинство из них мне сильно не нравятся (теоретически можно было бы сделать лучше).
Они тащат груз BC, по-моему. Поставь их разработчикам задачу написать такой же по функциональности движок и уверен качество кода будет куда выше. Вот только будет ли кто пользоваться этим движком с оригиналом общее имеющее только название, если заказчики сайтов уже вложили немалые деньги в создание модулей, тем и прочую кастомизацию. Скорее просто кто-нибудь форкнет текущую версию, как это было с, например OpenOffice.org, пускай и причины были другие.
Ставим модуль, генерируем статику по новой, в чем проблема?
Какую статику, если речь идёт про новые функции?
Считаем что статика — это одна функция: контент.
Форум на статике или рейтинг постов в блоге — уже не прокатит.
А ведь это достаточно распространённые функции в современном вебе и список таких функций можно набросать приличный.
Кроме того, мои заказчики хотят сами управлять контентом — генератор тоже нужно куда-то поставить и настроить. Так CMS же и выполняет эту функцию — это онлайн редактор сайта, с этим самым сайтом и связанный.
Дело в том, что сама генерация статики, как таковая, имеет смысл для высоконагруженных проектов или кластера проектов — там это экономит деньги. А низконагруженному, где несколько тысяч посетителей в день — вообще без разницы на чём он, по цене он заказчику находится в минимуме. Зато удобство работы с ним — это важный для заказчика вопрос.
Считаем что статика — это одна функция: контент.
Форум на статике или рейтинг постов в блоге — уже не прокатит.
А ведь это достаточно распространённые функции в современном вебе и список таких функций можно набросать приличный.
Кроме того, мои заказчики хотят сами управлять контентом — генератор тоже нужно куда-то поставить и настроить. Так CMS же и выполняет эту функцию — это онлайн редактор сайта, с этим самым сайтом и связанный.
Дело в том, что сама генерация статики, как таковая, имеет смысл для высоконагруженных проектов или кластера проектов — там это экономит деньги. А низконагруженному, где несколько тысяч посетителей в день — вообще без разницы на чём он, по цене он заказчику находится в минимуме. Зато удобство работы с ним — это важный для заказчика вопрос.
Ну я к тому, что если сайт в принципе можно сгенерировать статически, но его можно перегенерировать, если надо в него что-то добавить. То, что любой сайт можно сделать статикой, я не утверждаю. Хотя форум или блог, как раз, сделать не так сложно (пусть и некоторые вещи будут несколько ограничены).
Важно понимать, что статическим должен быть не весь сайт. Админка в любом случае, будет динамическая. Разумнее и сайт делать хоть немного динамическим (на уровне include, как минимум). Но если брать полностью статически вариант блога, то схема может быть следующей:
страница списка содержит записи на один календарный месяц. Главная страница, соотвественно, это текущий месяц. При добавлении/редактировании поста, обновляется 2 страницы: страница записей за текущий месяц и страница конкретной записи. Комментарии динамические, но внешние, например disqus или от какой-то социалки. Аналогично и виджеты с последними комментариями. Раз в месяц, придется перегенерировать все страницы, чтобы добавить новый месяц в навигацию.
Конечно, в обычном случае, так делать нет смысла. Но если сделать, то вполне можно давать ссылку на такой блог с Хабра или откуда-то еще и блог легко вытянет хабраэффект даже на не сильно мощном хостинге. Как правило, проблемы с производительностью у блогов возникают именно в таком случае.
Важно понимать, что статическим должен быть не весь сайт. Админка в любом случае, будет динамическая. Разумнее и сайт делать хоть немного динамическим (на уровне include, как минимум). Но если брать полностью статически вариант блога, то схема может быть следующей:
страница списка содержит записи на один календарный месяц. Главная страница, соотвественно, это текущий месяц. При добавлении/редактировании поста, обновляется 2 страницы: страница записей за текущий месяц и страница конкретной записи. Комментарии динамические, но внешние, например disqus или от какой-то социалки. Аналогично и виджеты с последними комментариями. Раз в месяц, придется перегенерировать все страницы, чтобы добавить новый месяц в навигацию.
Конечно, в обычном случае, так делать нет смысла. Но если сделать, то вполне можно давать ссылку на такой блог с Хабра или откуда-то еще и блог легко вытянет хабраэффект даже на не сильно мощном хостинге. Как правило, проблемы с производительностью у блогов возникают именно в таком случае.
Я думаю, что различные профили пользователей и личные кабинеты есть на большем числе сайтов чем 1% — куда не ткнись всюду требуют регистрации, чтоб даже ознакомиться с контентом. В принципе не очень сложно должно быть сделать блоговый движок на статике, но к нему всё равно нужен динамический бэкенд («админка»), да и СУБД больше как-то подходит для задач типа «найти все посты с таким-то тэгом», чем рыться в HTML файлах. В итоге приходим к системе, которая, по сути, по POST запросам генерирует сначала модель в БД, а потом её представление в файле — в динамических системах это называется файловое кэширование представлений.
Сравнивать языки нужно только в зависимости от контекста их употребления. Для одних задач один язык больше подходит, для других другой. Сказать однозначно и без поворотно, что один язык лучше другого в любом контексте его употребления, по крайней мере глупо. У каждого языка есть изъяны, но в разных случаях эти изъяны либо влияют на корректность работы приложения и на его перформанс либо нет, но так же у каждого есть свои преимущества в той или иной задаче. И как правило на практике в сложных веб-приложения используются несколько разных языков — каждый для своей задачи. И это есть правильно.
Лучше спорить, что в такой-то данной задаче, в таких-то условиях такой-то язык лучше. А то получается, что камаз лучше, чем порш кайен, а как на порше привезти 5 тонн кирпичей никого не волнует.
Лучше спорить, что в такой-то данной задаче, в таких-то условиях такой-то язык лучше. А то получается, что камаз лучше, чем порш кайен, а как на порше привезти 5 тонн кирпичей никого не волнует.
Я просто оставлю это здесь — php.net/manual/en/types.comparisons.php
«php» == TRUE
«php» == 0
0 != TRUE
Крутая система типов, да.
«php» == 0
0 != TRUE
Крутая система типов, да.
Читая документацию, вы, видимо, пропустили следующее:
«Обратите внимание, что переменная, в зависимости от ее типа в данный момент, в определённых ситуациях может иметь разные значения. Более подробную информацию смотрите в разделе Манипуляции с типами.»
«Обратите внимание, что переменная, в зависимости от ее типа в данный момент, в определённых ситуациях может иметь разные значения. Более подробную информацию смотрите в разделе Манипуляции с типами.»
Я намекаю на то, что само по себе такое поведение говорит о изначальных ошибках в проектировании системы типов и нагроможденных вокруг нее костылях для совместимости.
А неочевидное поведение — это куча трудноотлаживаемых ошибок, говнокод и головная боль разработчиков.
А неочевидное поведение — это куча трудноотлаживаемых ошибок, говнокод и головная боль разработчиков.
Неочевидно оно для людей привыкших к строгим языкам. А вот если взглянуть на конструкции типа
то всё встаёт на свои места. Непустые строки считаются истинными, кроме строки '0'. При численных операциях строки кастуются к числу. Нужно учитывать, что практически все значения в скрипт поступают в текстовом виде: переменные окружения, запросы, файлы, БД — везде строки. Вывод тоже строковый.
$var = $_GET['var'];
if ($var) echo 'TRUE';
echo $var * 2;
то всё встаёт на свои места. Непустые строки считаются истинными, кроме строки '0'. При численных операциях строки кастуются к числу. Нужно учитывать, что практически все значения в скрипт поступают в текстовом виде: переменные окружения, запросы, файлы, БД — везде строки. Вывод тоже строковый.
Я привык считать, что такие конструкции — говнокод. Именно из-за неявного приведения.
В питоне или в руби сравнение строки с число всегда вернет false. Ну просто потому что число и строка — разные классы объектов. И это гораздо более логично.
А не пустая ссылка всегда истинна. Пустая — ложна.
В питоне или в руби сравнение строки с число всегда вернет false. Ну просто потому что число и строка — разные классы объектов. И это гораздо более логично.
А не пустая ссылка всегда истинна. Пустая — ложна.
Приводите типы, сравнивайте строго. Кто мешает?
Никто ;) Я не пишу на ПХП, там слишком маленькие зарплаты ;)
Я бы не стал писать на ПХП даже если бы платили нормально :)
А если бы платили только за пхп?
Если бы платили только за пхп — я бы ушел в аналитики. Ну или тестировщики.
Все равно. Вы бы пошли писать на КОБОЛе, если бы «только за него платили»? :) Есть пара технологий, с которым я имел несчастье иметь дело, и которыми я больше не притронусь не при каких обстоятельствах. Например MFC. От PHP у меня, правда, нету такой травмы, но язык мне очень сильно не нравится и плохо себе представляю, что может заставить меня с ним иметь дело…
Хорошим специалистам хорошо платят.
Всегда ли? А если операцию сравнения переопределить?
А насчёт логично: спросите у непрограммиста: '123' равно 123 или не равно. PHP кроме всего прочего позиционируется как первый язык, на котором можно начинать писать не зная что такое тип, класс, объект, как они хранятся в памяти и т. п.
А насчёт логично: спросите у непрограммиста: '123' равно 123 или не равно. PHP кроме всего прочего позиционируется как первый язык, на котором можно начинать писать не зная что такое тип, класс, объект, как они хранятся в памяти и т. п.
И слегка неожиданно:
defined('null'); // true
defined('NULL'); // true
define('null', true); // notice нельзя переопределить константу
define('NULL', true); // true
NULL===true // false
('NULL')===true // false
('NULL')==true // true
Loose comparisons with ==
Strict comparisons with ===
От вашего коммента складывается впечатление что вы ниасилили перевод этих 2 строк в вашей ссылке.
Strict comparisons with ===
От вашего коммента складывается впечатление что вы ниасилили перевод этих 2 строк в вашей ссылке.
См. мой коммент выше.
И осильте любой другой язык с динамической типизацией кроме php и javascript.
Наличие костылей ДАЖЕ В СИСТЕМЕ ТИПОВ — это один из признаков того, в чем автор поста пытается нас разубедить.
И осильте любой другой язык с динамической типизацией кроме php и javascript.
Наличие костылей ДАЖЕ В СИСТЕМЕ ТИПОВ — это один из признаков того, в чем автор поста пытается нас разубедить.
Это не костыли, это осознанно подобранные под конкретную область применения допущения. Если не понимаете ее, привыкли к другому и боитесь трудноотлаживаемых ошибок используйте жесткое сравнение, а не пытайтесь выставить это недостатком языка.
Это не баг, это фича, да ;)))
Поверьте, я достаточно хорошо себе представляю как развиваются языки, как мешает обратная совместимость и технический долг и откуда в итоге взялись разные виды сравнения, хоть и не пхпшник ;)
Неявное преобразование типов с отчетливо разными интерфейсами и поведениями — это нарушение LSP и явная архитектурная ошибка. От которой теперь очень сложно избавиться не порушив совместимость.
Почему ни в одном другом языке, кроме джаваскрипта, мне не нужно задумываться о том, какое сравнение выбирать? Оно везде тупо одно ;) И если я сравню строку (не указатель на массив как в C, конечно) с числом без явного преобразования, мне рантайм скажет, что я мудак и будет полностью прав.
Ок, я не буду выставлять это недостатком языка. Я просто скажу, что большинство других языков имеет явное достоинство по сравнению с пхп.
Поверьте, я достаточно хорошо себе представляю как развиваются языки, как мешает обратная совместимость и технический долг и откуда в итоге взялись разные виды сравнения, хоть и не пхпшник ;)
Неявное преобразование типов с отчетливо разными интерфейсами и поведениями — это нарушение LSP и явная архитектурная ошибка. От которой теперь очень сложно избавиться не порушив совместимость.
Почему ни в одном другом языке, кроме джаваскрипта, мне не нужно задумываться о том, какое сравнение выбирать? Оно везде тупо одно ;) И если я сравню строку (не указатель на массив как в C, конечно) с числом без явного преобразования, мне рантайм скажет, что я мудак и будет полностью прав.
Ок, я не буду выставлять это недостатком языка. Я просто скажу, что большинство других языков имеет явное достоинство по сравнению с пхп.
Это просто разные типизация. Транслятор с сильной обзовётся, со слабой выберет наиболее вероятное (по мнению разработчиков) кастование. Хотите сравнить число со строкой — в любом случае правила приведения типов нужно знать.
Слабая типизация — это когда типизация идет по совпадению контрактов (оно же «утиная» — если квакает как утка… и так далее). Сильная — по совпадению типов и их отношениям в иерархии.
И у строки и у числа отчетливо РАЗНЫЕ иерархии и РАЗНЫЕ контракты.
И у строки и у числа отчетливо РАЗНЫЕ иерархии и РАЗНЫЕ контракты.
В языках со слабой типизацией обычно используется подход под названием «утиная типизация»
утиная типизация — это «выглядит, как утка, плавает, как утка, крякает, как утка — значит утка». Строки и числа в PHP — это не утиная типизация, а слабая динамическая типизация.
Утиная типизация один из видов слабой типизации.
Не понял, с чего вы с PHP на JavaScript перескочили, в остальном могу лишь еще раз повторить, что причина в конкретной области применения. Если следовать вашей логике получиться шаг назад во времена Perl-a, когда у каждого программера была собственная самописная функция для распарсивания значений из POST&GET и т.п. Если вам кажется непонятным или неправильным существующее неявное преобразование или еще какие-то моменты, просто используйте явное приведение типов и т.п., не надо доказывать, что все остальные не правы. Именно эти «архитектурные ошибки» сделали PHP на порядок эффективнее и как следствие популярнее других языков в веб-разработке.
Ну про эффективнее — это откровенная неправда ;)
А во-вторых, знаете чем кодер отличается от разработчика?
Кодер пишет используя один инструмент. И ассоциирует себя с ним.
Разработчик решает задачи. Выбирая инструмент под задачу.
Вы кажется так и не поняли, что я критикую не пхпшников, а сам инструмент. И обиделись, как и насравшие мне в карму.
Что в общем уже отчетливо характеризует пхп-комьюнити, уж простите.
P.S. Если следовать моей логике надо не возвращаться к перлу, а идти вперед от пхп — к рельсам или дотнету.
А во-вторых, знаете чем кодер отличается от разработчика?
Кодер пишет используя один инструмент. И ассоциирует себя с ним.
Разработчик решает задачи. Выбирая инструмент под задачу.
Вы кажется так и не поняли, что я критикую не пхпшников, а сам инструмент. И обиделись, как и насравшие мне в карму.
Что в общем уже отчетливо характеризует пхп-комьюнити, уж простите.
P.S. Если следовать моей логике надо не возвращаться к перлу, а идти вперед от пхп — к рельсам или дотнету.
Я вам в карму не срал, но уверен, что если бы вы пришли в топик про Винду и начали рассказывать какая она плохая и Линукс рулит, то получили тоже самое. Аналогично с темами в хабах Python, Ruby и т.д.
Так работает хабр, к сожалению.
Так работает хабр, к сожалению.
Что значит откровенная неправда? В чём вы меряете эффективность?
Хорошо, перечислите свои инструменты, которые вы используете для решения задач.
> Это не костыли, это осознанно подобранные под конкретную область применения допущения.
Нет, это именно костыли. === появился в РНР далеко не сразу и является именно костылем поверх убогой системы типов.
Нет, это именно костыли. === появился в РНР далеко не сразу и является именно костылем поверх убогой системы типов.
Изначально система типов подобрана под весьма узкую задачу, со временем язык стал популярнее и спектр задач расширился, в связи с чем были добавлены возможности явного приведения, сравнения с учетом типа и т.п. Автор статьи называет это развитием языка, вы называете костылями, от выбора терминологии язык хуже не становится.
> Изначально система типов подобрана под весьма узкую задачу
Никто никакую систему типов не подбирал. Она получилась такой, какой получиласб по двум причинам:
— основным вдохновителем был Perl
— автор не умел писать компиляторы и вообще не думал о дизайне языка (по его же признаниям)
В итоге получилось то, что получилось. === является банальным костылем, который в грамотно спроектированном языке (в котором действительно что-то выбирают прежде, чем реализовать) просто не появился бы.
Никто никакую систему типов не подбирал. Она получилась такой, какой получиласб по двум причинам:
— основным вдохновителем был Perl
— автор не умел писать компиляторы и вообще не думал о дизайне языка (по его же признаниям)
В итоге получилось то, что получилось. === является банальным костылем, который в грамотно спроектированном языке (в котором действительно что-то выбирают прежде, чем реализовать) просто не появился бы.
Не понятно почему PHP постоянно пытаются записать в недостатки какие-то факты из лохматых 90х. Давайте проведем аналогию, в 2006 Джек Дорси хотел создать некую платформу, которая позволяла бы ему постоянно обмениваться с друзьями короткими сообщениями, проект планировался исключительно для внутреннего использования. Значит ли это, что Twitter говно? Я так не думаю, потому что на сегодняшний день все проблемы связанные с ограничениями изначальной идеи успешно решены. В свою очередь 100500 заранее продуманных проектов провалились не выдержав столкновения с реальностью.
> Не понятно почему PHP постоянно пытаются записать в недостатки какие-то факты из лохматых 90х.
Потому что эти факты остаются в силе и сегодня. === является именно что костылем. Не фичей, не продуманным решением, не следствием «расширения сферы языка», а простым банальным костылем.
Все остальные фантазии и непонятно к чему приплетенные аналогии — кому угодно, только не техническому ресурсу.
Потому что эти факты остаются в силе и сегодня. === является именно что костылем. Не фичей, не продуманным решением, не следствием «расширения сферы языка», а простым банальным костылем.
Все остальные фантазии и непонятно к чему приплетенные аналогии — кому угодно, только не техническому ресурсу.
Костылем на технических ресурсах называют нагромождение избыточного кода, при отсутствии нормального решения. === просто еще один оператор, для тех случаев, когда стандартное решение не достаточно строго, никаких избыточных проблем он не создает.
Так же костылем называется ничем не оправданное техническое решение, принятое для якобы решения существующих проблем, но эти проблемы не решающее.
Это уже фейл какой-то, а не костыль, костыль это все же какое никакое, но решение, а не его отсутствие :)
Какие проблемы по вашему не решены? Если вы считаете, что PHP надо переделать по образу и подобию Perl-а или C, то это исключительно ваша проблема. Проблема заключалась в том, что возникла необходимость писать фрагменты кода со строгой типизацией, не утратив изначальной гибкости и простоты, оператор ===, вместе с прочими методами явного приведения полностью решает это проблему.
Какие проблемы по вашему не решены? Если вы считаете, что PHP надо переделать по образу и подобию Perl-а или C, то это исключительно ваша проблема. Проблема заключалась в том, что возникла необходимость писать фрагменты кода со строгой типизацией, не утратив изначальной гибкости и простоты, оператор ===, вместе с прочими методами явного приведения полностью решает это проблему.
> Это уже фейл какой-то, а не костыль, костыль это все же какое никакое, но решение, а не его отсутствие
Именно. Костыль — это «какое-то решение».
> Проблема заключалась в том, что возникла необходимость писать фрагменты кода со строгой типизацией, не утратив изначальной гибкости и простоты
Нет. Проблема заключалась именно в том, что оператор == давал *видимость* простоты, и *видимость* правильной работы, при том, что он:
— создавал больше проблем, чем решал
— обладал (и обладает) совершенно идиотскими правилами приведения типов.
Причем эти проблемы и правила были и остаются настолько серьезными, что за его использование в нормальных конторах бьют по рукам.
Что делают в РНР? Вместо того, чтобы решить проблему оператора ==, они вводят новый оператор ===, который работает так, как изначально должен был бы работать ==, который не заменяет ==, но который настоятельно рекомендуют использовать вместо ==.
Если это не костыль, я не знаю, что называть костылем.
Сказки про «гибкость и удобство» оставьте школоте и кодерам, которые уверены, что код типа «$var = «1»; echo $var + 1;» — это хороший качественный безопасный код.
Именно. Костыль — это «какое-то решение».
> Проблема заключалась в том, что возникла необходимость писать фрагменты кода со строгой типизацией, не утратив изначальной гибкости и простоты
Нет. Проблема заключалась именно в том, что оператор == давал *видимость* простоты, и *видимость* правильной работы, при том, что он:
— создавал больше проблем, чем решал
— обладал (и обладает) совершенно идиотскими правилами приведения типов.
Причем эти проблемы и правила были и остаются настолько серьезными, что за его использование в нормальных конторах бьют по рукам.
Что делают в РНР? Вместо того, чтобы решить проблему оператора ==, они вводят новый оператор ===, который работает так, как изначально должен был бы работать ==, который не заменяет ==, но который настоятельно рекомендуют использовать вместо ==.
Если это не костыль, я не знаю, что называть костылем.
Сказки про «гибкость и удобство» оставьте школоте и кодерам, которые уверены, что код типа «$var = «1»; echo $var + 1;» — это хороший качественный безопасный код.
UFO just landed and posted this here
У меня остался только один вопрос, почему вы продолжаете дискутировать о PHP, вместо того, чтобы писать скажем на Java?
Я могу понять смысл споров, как сделать PHP лучше, но ваши высказывания говорят о том, что вы не согласны с базовыми концепциями языка.
Возможность написать:
одна из фич, обуславливающая популярность языка, а не его проблема. Если это проблема для вас — смените язык, он никогда не будет соответствовать вашим понятиям о прекрасном.
Как это часто бывает в спорах о PHP — определяйтесь, «вам шашечки или ехать».
Я могу понять смысл споров, как сделать PHP лучше, но ваши высказывания говорят о том, что вы не согласны с базовыми концепциями языка.
Возможность написать:
$str = '1';
return ++$str;
одна из фич, обуславливающая популярность языка, а не его проблема. Если это проблема для вас — смените язык, он никогда не будет соответствовать вашим понятиям о прекрасном.
Как это часто бывает в спорах о PHP — определяйтесь, «вам шашечки или ехать».
UFO just landed and posted this here
> У меня остался только один вопрос, почему вы продолжаете дискутировать о PHP, вместо того
Я же не могу высказать свое мнение по поводу языка, с которым работал почти 10 лет? Нуну
> Я могу понять смысл споров, как сделать PHP лучше, но ваши высказывания говорят о том, что вы не согласны с базовыми концепциями языка.
Да, не согласен. И мое мнение достаточно объективно.
> Возможность написать:
> $str = '1';
> return ++$str;
> одна из фич, обуславливающая популярность языка, а не его проблема.
Вообще-то, это — его проблема, а не фича. Вы постоянно приводите код, который обхективно является ужасным страхом и пытаетесь выставить его, как хороший белый пушистый код, за который РНР стоит любить.
Так вот, именно такой код ведет к горе ошибок, SQL-injections, ошибкам валидации вводимых данных и т.п. Если вы не способны этого понять и считаете, что так оно и должно быть, что вы делаете в этой профессии?
> смените язык, он никогда не будет соответствовать вашим понятиям о прекрасном.
При чем тут мое чувство прекрасного? Есть некоторые объективные вещи, которые нужно называть своими именами.
Слабая динамическая типизация — гуано (не путать со строгой динамической, как например в Питоне/Эрланге), так как она позволяет огромный класс ошибок, которые невероятно сложно отследить.
=== — это костыль, который не должен существовать, потому что таким поведением обязан обладать ==.
Таблиц типа Loose comparisons with == вообще не должно существовать, потому что они бессмысленны, нелогичны и ведут к целому классу ошибок.
Язык должен помогать написанию качественного безопасного кода, а не поощрять адъ и израиль и разработчиков, которые считают, что такой адъ — это хороший код.
Я же не могу высказать свое мнение по поводу языка, с которым работал почти 10 лет? Нуну
> Я могу понять смысл споров, как сделать PHP лучше, но ваши высказывания говорят о том, что вы не согласны с базовыми концепциями языка.
Да, не согласен. И мое мнение достаточно объективно.
> Возможность написать:
> $str = '1';
> return ++$str;
> одна из фич, обуславливающая популярность языка, а не его проблема.
Вообще-то, это — его проблема, а не фича. Вы постоянно приводите код, который обхективно является ужасным страхом и пытаетесь выставить его, как хороший белый пушистый код, за который РНР стоит любить.
Так вот, именно такой код ведет к горе ошибок, SQL-injections, ошибкам валидации вводимых данных и т.п. Если вы не способны этого понять и считаете, что так оно и должно быть, что вы делаете в этой профессии?
> смените язык, он никогда не будет соответствовать вашим понятиям о прекрасном.
При чем тут мое чувство прекрасного? Есть некоторые объективные вещи, которые нужно называть своими именами.
Слабая динамическая типизация — гуано (не путать со строгой динамической, как например в Питоне/Эрланге), так как она позволяет огромный класс ошибок, которые невероятно сложно отследить.
=== — это костыль, который не должен существовать, потому что таким поведением обязан обладать ==.
Таблиц типа Loose comparisons with == вообще не должно существовать, потому что они бессмысленны, нелогичны и ведут к целому классу ошибок.
Язык должен помогать написанию качественного безопасного кода, а не поощрять адъ и израиль и разработчиков, которые считают, что такой адъ — это хороший код.
По вашей логике прежде чем браться за PHP стоит выпилить си и все подобные языки, вы не представляете какие там возможности, скажем при работе с указателями, для проблем с адресацией, утечками памяти и т.п.
Если вы считаете, что язык вместо вас должен заботиться об инъекциях, валидации входных данных и т.п., то вопрос «что вы делаете в этой профессии?» задайте лучше себе. Никакая типизация не защитит вас от ошибок, если у вас не хватает профессионализма, ровно как широкие возможности выстрелить себе в ногу не заставят профессионала это сделать.
Если вы считаете, что язык вместо вас должен заботиться об инъекциях, валидации входных данных и т.п., то вопрос «что вы делаете в этой профессии?» задайте лучше себе. Никакая типизация не защитит вас от ошибок, если у вас не хватает профессионализма, ровно как широкие возможности выстрелить себе в ногу не заставят профессионала это сделать.
> По вашей логике прежде чем браться за PHP стоит выпилить си и все подобные языки,
Нет, это не по моей логике, а по вашей буйной фантазии
> вы не представляете какие там возможности, скажем при работе с указателями, для проблем с адресацией, утечками памяти и т.п.
Я прекрасно представляю, какие там возможности. И люди не называют это фичами. Люди называют это проблемами и предупреждают всех об опасностях, связанных с этими проблемами и делают все возможное, чтобы этих проблем избегать — включая костыли типа auto_ptr, smart_ptr и т.п.[*]
И только в РНР школота рассказывает о том, насколько РНР крут, что позволят писать адский код типа «$str = '1'; return ++$str;»
В C/C++ за такой код в нормальной конторе уволят на следующий же день. За такой же код на РНР тоже.
«Но ведь эта так крута и гибка!!! одинодинодин». Тьфу
[*] Да, *_ptr — это костыли, чтобы скрыть многие из встроенных в язык проблем, несмотря на их — во многом — хорошую или даже отличную реализацию.
Нет, это не по моей логике, а по вашей буйной фантазии
> вы не представляете какие там возможности, скажем при работе с указателями, для проблем с адресацией, утечками памяти и т.п.
Я прекрасно представляю, какие там возможности. И люди не называют это фичами. Люди называют это проблемами и предупреждают всех об опасностях, связанных с этими проблемами и делают все возможное, чтобы этих проблем избегать — включая костыли типа auto_ptr, smart_ptr и т.п.[*]
И только в РНР школота рассказывает о том, насколько РНР крут, что позволят писать адский код типа «$str = '1'; return ++$str;»
В C/C++ за такой код в нормальной конторе уволят на следующий же день. За такой же код на РНР тоже.
«Но ведь эта так крута и гибка!!! одинодинодин». Тьфу
[*] Да, *_ptr — это костыли, чтобы скрыть многие из встроенных в язык проблем, несмотря на их — во многом — хорошую или даже отличную реализацию.
Возможность написать свой личный smart pointer не означает, что указатели это проблема Си, а наличие === не говорит о том, что == больше не нужен. Вы что-то слишком часто стали называть меня школотой, которую надо уволить, я приму это как признание, что аргументов у вас больше нет и дискуссия окончена.
Ну да, ну да. Вместо аргументов посчитать, что тебя называют школотой — это явный признак высочайшего профессионализма, да
Ах, и да.
Сравнить этот код:
> $str = '1';
> return ++$str;
с указателями на С и назвать это гибкой фичей языка способен только исключительно некомпетентный школяр. Гнать таких из профессии ссаными тряпками.
Сравнить этот код:
> $str = '1';
> return ++$str;
с указателями на С и назвать это гибкой фичей языка способен только исключительно некомпетентный школяр. Гнать таких из профессии ссаными тряпками.
за все 7 лет программирования на этом языке я лишь один или два раза попадался на баги, связанные с неправильным приведением/сравнением типов.
Стоит ли овчинка выделки? Имхо, это не та вещь, которая мешает писать приложения. Меня лично больше бесит и раздражает порядок аргументов в разных функциях и вообще зоопарк этих самых функций, особенно для работ со строками и массивами с названиями а-ля str_replace или substr.
Я бы на этом больше концентрировался, а вы про лохматую типизацию, которая вообще никому не мешает и не создает проблем, либо создает, но редко.
Стоит ли овчинка выделки? Имхо, это не та вещь, которая мешает писать приложения. Меня лично больше бесит и раздражает порядок аргументов в разных функциях и вообще зоопарк этих самых функций, особенно для работ со строками и массивами с названиями а-ля str_replace или substr.
Я бы на этом больше концентрировался, а вы про лохматую типизацию, которая вообще никому не мешает и не создает проблем, либо создает, но редко.
> Стоит ли овчинка выделки? Имхо, это не та вещь, которая мешает писать приложения.
Стоит и мешает. Через семь лет приучаешься везде писать === «потому что».
> Я бы на этом больше концентрировался, а вы про лохматую типизацию,
Какая подветка, о том и говорю. Про остальные проблемы РНР я прекрасно знаю, и какой ад там творится, тоже
Стоит и мешает. Через семь лет приучаешься везде писать === «потому что».
> Я бы на этом больше концентрировался, а вы про лохматую типизацию,
Какая подветка, о том и говорю. Про остальные проблемы РНР я прекрасно знаю, и какой ад там творится, тоже
В итоге получилось то, что получилось. === является банальным костылем
Ну почему же, представьте теперь ситуацию что нужно получить какое-то значение (допустим из get-параметров) и прибавить к нему n-e число:
$var = "1";
echo $var + 1; //2
Потому что «1» == 1, а если бы в языке отстутсвовало понятие неявного привдения типов, то пришлось бы вам всегда делать что-то вроде этого:
(int)$var + 1;
Не смотря на то что, в таком привидении нет ничего плохого, большинство разработчиков стараются обходится без этого, если есть такая возможность.
Или как в Python:
var = "1"
int(var) + 1
PS: На всякий случай хочу обратить внимание, что во времена когда только обсуждался стандарт С++11 предлагалось введение нового оператора идентичности <=>
concept EqualityComparable<typename T>
{
axiom Consistency(T a, T b) {
(a == b) <=> !(a != b);
}
}
Однако концепты и аксиомы не вошли в стандарт (решили что слишком рано еще такое вводить), тем не менее, даже в таком статическом языке как С++ рассматривалась возможность введения оператора идентичности, хотя и не много для других целей.
В конце концов, вы можете не пользоваться этим оператором :)
> Ну почему же, представьте теперь ситуацию что нужно получить какое-то значение (допустим из get-параметров) и прибавить к нему n-e число:
Ну, представил? Показали вы:
1. страшный страх и ужасный ужас с точки зрения качества кода, безопасности — да чего угодно
2. код, не имеющий отношения к тому факту, что === — это костыль
> если бы в языке отстутсвовало понятие неявного привдения типов, то пришлось бы вам всегда делать что-то вроде этого:
И правильно пришлось бы делать. Только опять же, этот пример не имеет никакого отношения к тому, что === — это костыль. Причем == настолько плох, что
> тем не менее, даже в таком статическом языке как С++ рассматривалась возможность введения оператора идентичности, хотя и не много для других целей.
1. У С++ во многом такая же проблема, как и у РНР — слабая типизация.
2. Цели были другими
Ну, представил? Показали вы:
1. страшный страх и ужасный ужас с точки зрения качества кода, безопасности — да чего угодно
2. код, не имеющий отношения к тому факту, что === — это костыль
> если бы в языке отстутсвовало понятие неявного привдения типов, то пришлось бы вам всегда делать что-то вроде этого:
И правильно пришлось бы делать. Только опять же, этот пример не имеет никакого отношения к тому, что === — это костыль. Причем == настолько плох, что
> тем не менее, даже в таком статическом языке как С++ рассматривалась возможность введения оператора идентичности, хотя и не много для других целей.
1. У С++ во многом такая же проблема, как и у РНР — слабая типизация.
2. Цели были другими
>(int)$var + 1;
лучше тогда уже intval($var) + 1;
лучше тогда уже intval($var) + 1;
0 != TRUE в таких языках, как C, C++, Python и JavaScript.
UFO just landed and posted this here
phpDaemon — asynchronous server-side framework of network applications implemented in PHP using famous libevent which makes possible to handle hundreds and thousands of simultaneous connections.
UFO just landed and posted this here
Вот только не надо на PHP демонов писать.
Не предназначен он для этого — там все заточено под другую задачу.
Написал нам тут один аутсорсер демона на пхп — за 1 день утекает 4ГБ памяти!!!
Не предназначен он для этого — там все заточено под другую задачу.
Написал нам тут один аутсорсер демона на пхп — за 1 день утекает 4ГБ памяти!!!
А у нас куча демонов на php, и ничего нигде не течет. Хотя, я знаю много способов сделать так, чтобы потекло=)
Зачем винить инструмент, если нафейлил тот, кто не умеет им пользоваться.
Зачем винить инструмент, если нафейлил тот, кто не умеет им пользоваться.
ну зачем, если он не предназначен для этого? На brainfuck люди тоже много чего пишут, но это же не значит, что так правильно. PHP даже расшифровывается как «гипертекстовый препроцессор»
Ну что значит не предназначен? У нас не используется многопоточность — только очереди, а по остальным параметрам все там нормально предназначено. Мне постоянно говорят о таких вещах. То для парсеров php не предназначен. То демонов на нем писать нельзя. То для больших сайто вон плохой.
Мне кажется, что эти все люди живут в каком-то царстве слухов. Да, у языка есть ограничения. Основные — отсуствие многопоточности и оверхед при работе с большими массивами. Если об этих ограничениях знать, то нормальный получается результат.
Или вы предлагаете специально брать отдельных людей для написания внутренних демонов потому, что на php писать не гламурно (или заставять кого-то учить гламурные языки)? Извините, но я считаю, что это чушь.
При этом, ряд задач у нас делается на Си потому, что к ним специфические требоавния как по скорости, так и по расходу памяти. Другие языки, приемлимого результата не дадут. Такие задачи на php никто и не пытается решать (даже не смотря на наличие таких инструментов, как hiphop)
Мне кажется, что эти все люди живут в каком-то царстве слухов. Да, у языка есть ограничения. Основные — отсуствие многопоточности и оверхед при работе с большими массивами. Если об этих ограничениях знать, то нормальный получается результат.
Или вы предлагаете специально брать отдельных людей для написания внутренних демонов потому, что на php писать не гламурно (или заставять кого-то учить гламурные языки)? Извините, но я считаю, что это чушь.
При этом, ряд задач у нас делается на Си потому, что к ним специфические требоавния как по скорости, так и по расходу памяти. Другие языки, приемлимого результата не дадут. Такие задачи на php никто и не пытается решать (даже не смотря на наличие таких инструментов, как hiphop)
Ну и нода тоже течет, и еще быстрее.
PHP все еще является наипростейшим языком для изучения не-техническими людьми
Имхо, у Фабьена когнитивный диссонанс. С одной стороны он утверждает, что PHP очень простой язык, а с другой — для работы с самым популярным PHP-фреймворком необходимы знания об интерфейсах, итераторах, DIC, аннотациях и прочем-прочем-прочем.
Очень просто. Для начала работы с языком не нужно практических никаких знаний, для разработки промышленных приложений нужны специальные знания. Как велосипеды — есть детские трехколесные, а есть профессиональные.
Градация между junior и senior в PHP огромна как нигде.
Junior PHP должен уметь поковырять форум или друпал и поменять пару функций и переменных.
Senior PHP должен знать Symfony2, Zend, MVC, ORM, Doctrine2, DIC, annotations, Yaml, Json, XML, Git…
Думаю стоит или придерживаться принципа KISS в разработке или не упоминать о простоте PHP.
Junior PHP должен уметь поковырять форум или друпал и поменять пару функций и переменных.
Senior PHP должен знать Symfony2, Zend, MVC, ORM, Doctrine2, DIC, annotations, Yaml, Json, XML, Git…
Думаю стоит или придерживаться принципа KISS в разработке или не упоминать о простоте PHP.
PHP используется как основной язык на 77,9% среди всех сайтов99.(9)% которых являются говносайтами
… и если переписать их на другом ЯП, то они станут вареньесайтами, да? :)
99.(9)% сайтов — говносайты. Независимо от языка.
>> Давайте я вам рассскажу маленький секрет успеха PHP: не смотря на все изменения за последние годы, PHP все еще является >> наипростейшим языком для изучения не-техническими людьми; PHP позволяет создавать динамичные вебсайты быстрее, чем >> любая другая технология, позволяет поднимать сайты дешево и без заморочек. Вполне возможно, что PHP не самый лучший >> язык в мире с точки зрения проектирования, но он позволяет быстро достигать целей, и с этим не поспоришь.
Полная херня. Я 3 года писал на PHP. 2 года пишу на Java. Так вот я на Java умудряюсь разрабатывать код не медленнее, чем на PHP. Если говорить о веб-сайтах, а не о скриптах из 2-ух страничек.
Полная херня. Я 3 года писал на PHP. 2 года пишу на Java. Так вот я на Java умудряюсь разрабатывать код не медленнее, чем на PHP. Если говорить о веб-сайтах, а не о скриптах из 2-ух страничек.
>> PHP, возможно, не лучший язык в мире, и я далеко не первый, кто пытается говорить о его плюсах, но PHP — это лучшая веб платформа… и точка.
С какого это перепугу она лучшая веб-платформа? Вы чего обкурились, уважаемый? Не слишком ли громкое утверждение? Я же не делаю тут сбросы говномасс, что Java это круто, а PHP это не круто.
Если тебе доступен лишь один инструмент, это не значит, что он самый лучший.
С какого это перепугу она лучшая веб-платформа? Вы чего обкурились, уважаемый? Не слишком ли громкое утверждение? Я же не делаю тут сбросы говномасс, что Java это круто, а PHP это не круто.
Если тебе доступен лишь один инструмент, это не значит, что он самый лучший.
>> Я просмотрел все: от Perl до Ruby
Как-то узко посмотрел. Столько буков между A и P, S и Z.
Особенно с учетом, что можно было бы перенять опыт того, что уже сделано для такой платформы, как JVM. Maven, Ant + Ivy только чего стоят.
Как-то узко посмотрел. Столько буков между A и P, S и Z.
Особенно с учетом, что можно было бы перенять опыт того, что уже сделано для такой платформы, как JVM. Maven, Ant + Ivy только чего стоят.
PHing Is Not GNU make; it's a PHP project build system or build tool based on Apache Ant. You can do anything with it that you could do with a traditional build system like GNU make, and its use of simple XML build files and extensible PHP «task» classes make it an easy-to-use and highly flexible build framework.
Похоже на ответ к другому комментарию))
Почему то читая статьи о ненависти к PHP у меня возникает ощущение что проводится чёрный пиар.
Допустим Вы преуспевающий разработчик на PHP, ну не хватает вам плюшек в языке, уходите с него, и пользуйтесь на здоровье чем то другим… тихо мирно и не подливайте масла в огонь.
Допустим Вы преуспевающий разработчик на PHP, ну не хватает вам плюшек в языке, уходите с него, и пользуйтесь на здоровье чем то другим… тихо мирно и не подливайте масла в огонь.
Заказчики не хотят идти следом. Нужно им помочь :)
А заказчику не всё ли равно какой язык? :) Судя по моей практике — заказчику важен только результат причём он ему нужен ещё вчера :)
Заказчику всё равно какие буквы. Но заказчику не всё равно каковы:
— стоимость и распространенность хостингов
— стоимость и распространенность специалистов
— уровень входа в язык/технологию
При всём своем давнем скептическом отношению к PHP как к ЯП и экосистеме сложившейся вокруг него, нельзя не признать, что для очень многих классов задач PHP будет экономически оправданным выбором, особенно если не рассматривать потенциальную проблему взрывного роста.
— стоимость и распространенность хостингов
— стоимость и распространенность специалистов
— уровень входа в язык/технологию
При всём своем давнем скептическом отношению к PHP как к ЯП и экосистеме сложившейся вокруг него, нельзя не признать, что для очень многих классов задач PHP будет экономически оправданным выбором, особенно если не рассматривать потенциальную проблему взрывного роста.
Сериал «PHP. Холивар. Часть 2».
Список серий (для тех кто пропустил):
The PHP Singularity
PHP solves problems. Oh, and you can program with it too!
Where is your Vision Jeff?
PHP is much better than you think
The True Problem With PHP
Список серий (для тех кто пропустил):
The PHP Singularity
PHP solves problems. Oh, and you can program with it too!
Where is your Vision Jeff?
PHP is much better than you think
The True Problem With PHP
Последнее время PHP гнобят все, кому не лень, даже довольно-таки разумные люди.
Отличное начало. Захотелось занять свое место и достать попкорн.
Языком PHP назвать трудно (по той же причине, почему это нельзя сделать по отношению к тому же башу). Это средство создания наколеночных решений, который мутировал в нечто, напоминающее полноценный язык.
Но в маркетинге миллионы мух никогда не ошибаются (потому что они платят). PHP как язык — ужасен, но это не мешает ему быть легким в изучении и в решении ряда задач. К тому же привычка и популярность (легко найти хостинг, студента, который в состоянии поддержать чей-тогокод и т.п.)
Это отнюдь не хороший язык. Но это ничего не значит.
Отличное начало. Захотелось занять свое место и достать попкорн.
Языком PHP назвать трудно (по той же причине, почему это нельзя сделать по отношению к тому же башу). Это средство создания наколеночных решений, который мутировал в нечто, напоминающее полноценный язык.
Но в маркетинге миллионы мух никогда не ошибаются (потому что они платят). PHP как язык — ужасен, но это не мешает ему быть легким в изучении и в решении ряда задач. К тому же привычка и популярность (легко найти хостинг, студента, который в состоянии поддержать чей-то
Это отнюдь не хороший язык. Но это ничего не значит.
Да, у PHP сейчас лучший менеджер зависимостей из всех языков.
O RLY?
Ок ребят, давайте поставим наш извечный вопрос таким ребром:
Я решил, что мне необходимо изучить PHP. С чего начать учить(желательны русскоязычные источники и литература)? И стоит ли учить его, может есть язык способный «выбить» PHP?
Я решил, что мне необходимо изучить PHP. С чего начать учить(желательны русскоязычные источники и литература)? И стоит ли учить его, может есть язык способный «выбить» PHP?
Вы бы хоть точку отсчета указали, человеку мыслящему в плоском С литература нужна будет сильно отличная от того, кто пришел с Java. Если нужен только синтаксис www.php.ru/manual/ и гугла более чем достаточно.
Надо поставить себе цель: зачем учить?
Чтобы выучить язык программирования? Лучше взять Python/Ruby/Scala/Erlang или даже всех их вместе.
Чтобы выучить язык программирования, который даст работу? Лучше взять все вышеперечисленное + C#/Java
Чтобы получить работу бедному студенту? Ну да, PHP подойдет. Но лучше студенту выучить выщеперечисленное и найти болеее высокооплачиваемую работу.
Чтобы выучить язык программирования? Лучше взять Python/Ruby/Scala/Erlang или даже всех их вместе.
Чтобы выучить язык программирования, который даст работу? Лучше взять все вышеперечисленное + C#/Java
Чтобы получить работу бедному студенту? Ну да, PHP подойдет. Но лучше студенту выучить выщеперечисленное и найти болеее высокооплачиваемую работу.
UFO just landed and posted this here
Цель — удобно чувствовать себя богом в вебе.
P.S. Абстрагируемся от меня =) Считаем, что вроде как на какой-то средненький уровень программирования я претендовать могу, главное синтаксис ^_^
P.S. Абстрагируемся от меня =) Считаем, что вроде как на какой-то средненький уровень программирования я претендовать могу, главное синтаксис ^_^
> Цель — удобно чувствовать себя богом в вебе.
:)
Тогда Руби/Питон :)
И параллельно — что-то из функциональщины (Erlang/Haskell) — для общего развития
:)
Тогда Руби/Питон :)
И параллельно — что-то из функциональщины (Erlang/Haskell) — для общего развития
Чтобы чувствовать себя богом не достаточно знать один язык, но достаточно шизофрении.
PHP это на сегодня явный лидер в веб-разработке, большой спрос, очень высокая оплата для топ-разработчиков, огромная конкуренция и тотальный демпинг среди новичков. Если вы готовы к конкуренции и считаете, что вы сможете доказать, что вы на порядок лучше 100500 индусов — оно того стоит. Если же вы не слишком уверены в своей потенциальной звездности, тогда конечно лучше Руби/Питон, там вас простят и поймут, просто за то, что вы пишите на языке, на котором замену вам найти очень сложно.
Имея средненький уровень и зная только синтаксис вы навряд ли сможете уйти в отрыв от индусов и школьников, для этого варианта скорее действительно подходит более узкий кусок рынка и менее популярный язык.
PHP это на сегодня явный лидер в веб-разработке, большой спрос, очень высокая оплата для топ-разработчиков, огромная конкуренция и тотальный демпинг среди новичков. Если вы готовы к конкуренции и считаете, что вы сможете доказать, что вы на порядок лучше 100500 индусов — оно того стоит. Если же вы не слишком уверены в своей потенциальной звездности, тогда конечно лучше Руби/Питон, там вас простят и поймут, просто за то, что вы пишите на языке, на котором замену вам найти очень сложно.
Имея средненький уровень и зная только синтаксис вы навряд ли сможете уйти в отрыв от индусов и школьников, для этого варианта скорее действительно подходит более узкий кусок рынка и менее популярный язык.
Вы даже в этом комментарии, где я пытаюсь выяснить, что же все-таки в данный момент представляет наибольший интерес и концентрацию полезности, умудряетесь рассматривать все с бока личности и своих симпатий
Сейчас очень заметный дефицит дотнетчиков и рубистов, работа ищется очень легко, зарплаты больше сильно.
Не надо идти в язык где вас будут демпинговать школьники готовые работать за еду.
Не надо идти в язык где вас будут демпинговать школьники готовые работать за еду.
UFO just landed and posted this here
А когда меня начинают донимать что PHP плох, я просто говорю:
— «На чем написан второй по посещаемости сайт во мире Facebook, и наш ВКонтакте», после чего как правило всякие претензии уходят )
— «На чем написан второй по посещаемости сайт во мире Facebook, и наш ВКонтакте», после чего как правило всякие претензии уходят )
Ок, Facebook написан на PHP, но ведь PHP написан на С, а С написан на ассемблере… а значит хорош будет только тот, кто написан на Facebook!
UFO just landed and posted this here
Во-первых, Facebook и ВКонтакте написаны на PHP, а не на С и ассемблере.
Во-вторых, кто-то говорит что С и ассемблер это плохие языки?
Непонятно к чему этот сарказм, дело действительно не в языке, а в программистах.
Во-вторых, кто-то говорит что С и ассемблер это плохие языки?
Непонятно к чему этот сарказм, дело действительно не в языке, а в программистах.
Если из крутости FB следует крутость PHP, то по этой же логике если PHP плох, то плохи С и ассемблер, ведь он на них написан.
К тому и сарказм, что по качеству продукта нельзя однозначно судить о качестве языка (особенно в случае с FB, который по сути написан не на PHP, а не собственном компиляторе, использующим PHP синтаксис).
К тому и сарказм, что по качеству продукта нельзя однозначно судить о качестве языка (особенно в случае с FB, который по сути написан не на PHP, а не собственном компиляторе, использующим PHP синтаксис).
Пошел учить пэхапэ…
>> PHP гнобят все, кому не лень
Кто против пхп — палец вверх.
Кто за — палец вниз.
Комментарии внизу.
Кто против пхп — палец вверх.
Кто за — палец вниз.
Комментарии внизу.
PHP — язык, для разворачивания решений на котором не нужен отдельный сервер в виде приложения, либо рельс, ноды, либо чего-то подобного. Это уменьшает стоимость разворачивания. Этим мне он нравится.
PHP — язык с огромным коммьюнити и богатой документацией, с кучей примеров кода и библиотек на любой вкус. Этим мне он нравится.
PHP — язык, изначально, исторически созданный для Web-приложений (в отличии от питона и руби, к примеру). Поэтому для написания веб-приложения на нём в первую очередь пишутся веб-приложения (а на иных языках — сначала пишется web-сервер). Этим мне он нравится.
PHP — язык, решения на котором дёшево поддерживать. PHP-программистов просто найти и легко обучить. Проще гарантировать заказчику, что его проект не умрёт. Этом мне он нравится.
PHP — язык, который легко собирается под различные платформы. По мне — проще питона, по крайней мере при кросскомпиляции с отсутствующими библиотеками. Имею в виду не голый питон, а например pygame. Тоже самое с Java. Этим мне он нравится.
PHP — язык, богатый на стандартные изкоробочные функции. Например, существуют проекты, которые копируют PHP-шные функции в Javascript, потому что аналогов в яваскрипте нет. Работа со строками в PHP проста и удобна (в отличии от яваскрипта, явы или си). Этим мне он нравится.
PHP прекрасно, просто и удобно из коробки работает с базами данных, в отличие от той же node.js. Этим мне он нравится.
Так что я за PHP.
PHP — язык с огромным коммьюнити и богатой документацией, с кучей примеров кода и библиотек на любой вкус. Этим мне он нравится.
PHP — язык, изначально, исторически созданный для Web-приложений (в отличии от питона и руби, к примеру). Поэтому для написания веб-приложения на нём в первую очередь пишутся веб-приложения (а на иных языках — сначала пишется web-сервер). Этим мне он нравится.
PHP — язык, решения на котором дёшево поддерживать. PHP-программистов просто найти и легко обучить. Проще гарантировать заказчику, что его проект не умрёт. Этом мне он нравится.
PHP — язык, который легко собирается под различные платформы. По мне — проще питона, по крайней мере при кросскомпиляции с отсутствующими библиотеками. Имею в виду не голый питон, а например pygame. Тоже самое с Java. Этим мне он нравится.
PHP — язык, богатый на стандартные изкоробочные функции. Например, существуют проекты, которые копируют PHP-шные функции в Javascript, потому что аналогов в яваскрипте нет. Работа со строками в PHP проста и удобна (в отличии от яваскрипта, явы или си). Этим мне он нравится.
PHP прекрасно, просто и удобно из коробки работает с базами данных, в отличие от той же node.js. Этим мне он нравится.
Так что я за PHP.
Афигеть. Ёпт. Как не скажу что пхп — в жопе. Ну как тут не сказать, что хабр за один лишь пхп не люблю, хоть он и на рельсах работает. Волшебно. Как это??? Гы.
Структурируем:
Документация:
Сам язык документирован в том же объеме, как и остальные популярные языки. Камметы?
>> язык, изначально, исторически созданный для Web-приложений…
Ох, ёпт. удалите меня. Да — это так. Что же в этом хорошего? Веб уже другой.
>> язык, решения на котором дёшево поддерживать…
Факт. Ну там 1с исключение. А так «знатоков» — докуя.
>> язык, который легко собирается под различные платформы.
собирается. это не достоинство языка. Они все собираются.
>> язык, богатый на стандартные изкоробочные функции.
10xМинусов мне в карму. За то что сказать хочу.
>> прекрасно, просто и удобно из коробки работает с базами данных, в отличие от той же node.js. Этим мне он нравится.
Да мне вообще руби нравится с гламурными рельсами и клал я на ноду (даже не пробовал, извиняюсь перед пользователями ноды, я тут холивар развожу). И на пхп я 10 лет писал. Как же за*бали холиварщики.
Да нормальный php, просто ты волнуешься.
Структурируем:
Документация:
Сам язык документирован в том же объеме, как и остальные популярные языки. Камметы?
>> язык, изначально, исторически созданный для Web-приложений…
Ох, ёпт. удалите меня. Да — это так. Что же в этом хорошего? Веб уже другой.
>> язык, решения на котором дёшево поддерживать…
Факт. Ну там 1с исключение. А так «знатоков» — докуя.
>> язык, который легко собирается под различные платформы.
собирается. это не достоинство языка. Они все собираются.
>> язык, богатый на стандартные изкоробочные функции.
10xМинусов мне в карму. За то что сказать хочу.
>> прекрасно, просто и удобно из коробки работает с базами данных, в отличие от той же node.js. Этим мне он нравится.
Да мне вообще руби нравится с гламурными рельсами и клал я на ноду (даже не пробовал, извиняюсь перед пользователями ноды, я тут холивар развожу). И на пхп я 10 лет писал. Как же за*бали холиварщики.
Да нормальный php, просто ты волнуешься.
В хвалебном топике про пхп? Смело.
Насчет обучения PHP… Во многих школах на информатике учат текстовым и графическим редакторам, максимум алгоритмам, но не касаются языков программирования. И это правильно с одной стороны, Но, с другой стороны возникает немалое желание школьников обучаться программированию, поэтому, решил на базе компьютерного класса, открыть бесплатные курсы юных программистов для школьников.
Скорей даже не курсы а кружок, в котором мы будем разбирать современные тенденции развития языков программирования, и, конечно же, пробовать свои силы в них. Цель занятий – познакомить детей с наиболее популярными языками программирования и дать им возможность самим сориентироваться в этом многообразии, и, в дальнейшем, сделать правильный выбор в своей профессиональной ориентации.
Все языки объять невозможно, поэтому, в качестве основы, будет взят один язык, разобраны основные конструкции, из других языков будут приводиться примеры реализации аналогичных конструкций для сравнения, стоит ли брать за основу PHP, как достаточно простой для начального освоения и дружелюбный к ошибкам?
Скорей даже не курсы а кружок, в котором мы будем разбирать современные тенденции развития языков программирования, и, конечно же, пробовать свои силы в них. Цель занятий – познакомить детей с наиболее популярными языками программирования и дать им возможность самим сориентироваться в этом многообразии, и, в дальнейшем, сделать правильный выбор в своей профессиональной ориентации.
Все языки объять невозможно, поэтому, в качестве основы, будет взят один язык, разобраны основные конструкции, из других языков будут приводиться примеры реализации аналогичных конструкций для сравнения, стоит ли брать за основу PHP, как достаточно простой для начального освоения и дружелюбный к ошибкам?
> PHP позволяет создавать динамичные вебсайты быстрее, чем любая другая технология
прямо-таки любая?
уже несколько проектов переписали с PHP на python, в обоих случаях сократилось серваков в N раз и скорость разработки повысилась раза в 2-3 :)
PHP умер, признайте это :)
с каждым годом все больше проектов (серьезных) будут переписывать с PHP на python/ruby/etc.
прямо-таки любая?
уже несколько проектов переписали с PHP на python, в обоих случаях сократилось серваков в N раз и скорость разработки повысилась раза в 2-3 :)
PHP умер, признайте это :)
с каждым годом все больше проектов (серьезных) будут переписывать с PHP на python/ruby/etc.
Ну если эти проекты переписать с говнокода php, на нормальный php, это тоже приведет к ускорению разработки и снижению количества необходимых серверов. А если потом еще hiphop применить, то серверов будет нужно еще на порядок меньше.
Глобальный рефактонинг вообще штука хорошая, есть на нее есть ресурсы. ХЗ, при чем тут язык.
Глобальный рефактонинг вообще штука хорошая, есть на нее есть ресурсы. ХЗ, при чем тут язык.
ох, скорость разработки на питоне выше :)
если взять тот же проект и написать паралельно на php и на питоне — на питоне выйдет быстрее и по времени и по скорости работы :) соответственно и разработчиков меньше нужно и железных ресурсов, не говоря про удобство и кайф, который получают разработчики работая с этим языком :)
если взять тот же проект и написать паралельно на php и на питоне — на питоне выйдет быстрее и по времени и по скорости работы :) соответственно и разработчиков меньше нужно и железных ресурсов, не говоря про удобство и кайф, который получают разработчики работая с этим языком :)
если взять тот же проект и написать паралельно на питоне и на basic — на basic'е выйдет быстрее и по времени и по скорости работы :) соответственно и разработчиков меньше нужно и железных ресурсов, не говоря про удобство и кайф, который получают разработчики работая с этим языком :)
Очень объективно и аргументированно, конечно. Если все так, зачем крупные проекты вообще на php пишут?
Почему тот-же Youporn с очень солидной нагрузкой недавно переписал сайт на php, а не питоне, руби или просто заново не сделал на perl'е? Не смогли найти разработчиков или забыли провести экспертизу перед принятием решения?
Очень объективно и аргументированно, конечно. Если все так, зачем крупные проекты вообще на php пишут?
Почему тот-же Youporn с очень солидной нагрузкой недавно переписал сайт на php, а не питоне, руби или просто заново не сделал на perl'е? Не смогли найти разработчиков или забыли провести экспертизу перед принятием решения?
я уже говорил что это получено на своем опыте, еще аргументация нужна? )
круто ) один youporn, и все?
p.s. популярнее не значит лучше, это везде так
круто ) один youporn, и все?
p.s. популярнее не значит лучше, это везде так
Ваш опыт, штука субъективная, у других людей все может быть совершенно иначе. Многие люди не бросаются на все подряд, а изучают тот инструмент, с которым случилось поработать. Если уйти на пределы «сайты на php на 21 день» и говносайтов, то на php отлично строится качественная, красивая и масштабирумая архитектура. Собственно, язык тут вообще, наверно не при чем.
youporn это просто один из свежих примеров, вы не хуже меня понимаете, что большая часть сайтов в мире на php и написаны, включая много очень крупных и посещаемых проектов. Тот факт, что этот язык вообще выбирают для подобных проектов, говорит о том, что для них он прекрасно подходит. В противном случае, с ростом проекта, от php пришлось бы избавиться.
То, что много людей пишут на php черти-как, не означает, что мало тех, кто делает это грамотно.
youporn это просто один из свежих примеров, вы не хуже меня понимаете, что большая часть сайтов в мире на php и написаны, включая много очень крупных и посещаемых проектов. Тот факт, что этот язык вообще выбирают для подобных проектов, говорит о том, что для них он прекрасно подходит. В противном случае, с ростом проекта, от php пришлось бы избавиться.
То, что много людей пишут на php черти-как, не означает, что мало тех, кто делает это грамотно.
хотелось бы увидеть подтверждение ваших слов в цифрах на реальных проектах
Ерунда какая-то несустветная.
Именно из-за таких слухов и появляются статьи в стиле «ПХП гавно, питон рулит». Рулит не язык, а программист, если написан говнокод, то его можно на любом языке написать.
Уверен, вы не сможете привести пример, где разработчиков и железа понадобилось бы меньше, чем если бы написали на питоне.
Именно из-за таких слухов и появляются статьи в стиле «ПХП гавно, питон рулит». Рулит не язык, а программист, если написан говнокод, то его можно на любом языке написать.
Уверен, вы не сможете привести пример, где разработчиков и железа понадобилось бы меньше, чем если бы написали на питоне.
У вас hiphop какая-то серебряная пуля?
Ну он позволяет убрать ограничения скорости, связанные с языком. Когда запросы к базе оптимизированы и хорошо работает кэш, упирается все, обычно, в производительность php. Если небольшими усилиями можно ускорить такой код в десятки раз, то это очень хорошо сказывается на производительности проекта.
Если переписывали говнокод на PHP, тогда все ясно, да. А так не знаю что вы там переписали так, что нельзя нормально написать на PHP и при этом время разработки и количества железа было бы соизмеримым.
Хватит уже травить эти басни и слухи.
Хватит уже травить эти басни и слухи.
Недопереведено… register_globals and magic_quotes…
Ох уж эти холивары…
- У каждого языка своя ниша, для веба лучше PHP сейчас нет — это отличный клей между веб-сервером, БД, мемкешами, веб-службами, почтовым агентом и т.п. Именно так его и надо воспринимать, писать на PHP синтаксический анализатор многомегабайтных текстов — глупо (но можно, pcre работает довольно шустро), так же глупо писать веб-интерфейс сайта на Си или Си++ (получится тот же php, только хуже). Для тяжелых бэкендов (расчеты графов, рендеры, обработка видео) — пожалуйста никто не мешает использовать другой, более специализированный для конкретной задачи инструмент.
- Nginx + PHP-FPM + APC = высокая производительность.
- Тем кто спрашивал «учить PHP или не учить», отвечаю: «Учить. Платформу для нового проекта выбираютне программисты, а инвесторы (заказчики), а эти парни деньги считать умеют, и понимают, что держать штат PHP программистов, гораздо дешевле и менее рисковано, чем C-, Java-, Python- или Ruby- программистов; и что купить один раз лишний сервер и балансер — тоже дешевле».
>> что держать штат PHP программистов, гораздо дешевле и менее рисковано, чем C-, Java-, Python- или Ruby- программистов
Тобто PHP программисты малооплачиваемы?
Замените с своём посте PHP на C#, на Ruby, на Java. Мало что поменяется. Уж очень субъективный комментарий.
Все заказчики с которыми я работал, свято верили что им нужен ТОЛЬКО .Net. Это ж не значит, что .Net зохавает весь мир.
Тобто PHP программисты малооплачиваемы?
Замените с своём посте PHP на C#, на Ruby, на Java. Мало что поменяется. Уж очень субъективный комментарий.
Все заказчики с которыми я работал, свято верили что им нужен ТОЛЬКО .Net. Это ж не значит, что .Net зохавает весь мир.
Хорошие PHP шники сейчас ниразу не дешевле аналогичный рубистов, питонеров и дотнетчиков. Java только немного обгоняет. По крайней мере, в Киеве.
UFO just landed and posted this here
однако от чего же мы так думаем про него?)
Как-то так.
> HP используется как основной язык на 77,9% среди всех сайтов, где язык платформы известен. Wordpress используется в 16,6%
Люблю статистику, она такая шлюха :). Одностраничный г-сайтик hello world, склепанный в качестве первого творения считается? сетки сателлитов, дорвеев и прочих сеошных чмошностей считаются?
Честнее было бы сравнить по трафику. Подозреваю что на эти 77.9% сайтов приходится не так много веб трафика.
PS php тоже люблю
Люблю статистику, она такая шлюха :). Одностраничный г-сайтик hello world, склепанный в качестве первого творения считается? сетки сателлитов, дорвеев и прочих сеошных чмошностей считаются?
Честнее было бы сравнить по трафику. Подозреваю что на эти 77.9% сайтов приходится не так много веб трафика.
PS php тоже люблю
у вас неточность:
>все еще является наипростейшим
>языком для изучения не-техническими людьми
имелось в виду:
подходит для школьников
>все еще является наипростейшим
>языком для изучения не-техническими людьми
имелось в виду:
подходит для школьников
PHP гораздо лучше, чем вы думаете