Ну зачем же обижать. Уже 22 года программирую, со школы. Вот в школе и научили, что алгоритмы + структуры данных = программы. Но вот нужность объединения алгоритмов и структур данных в одно целое для меня под вопросом.
ООП - прекрасная штука, если иерархия объектов и их функциональность - очевидны. Да и то.
Вот представим себе объекты, которые идеально подходят под парадигму ООП - линейная алгебра, скаляры, векторы и матрицы. Вектор - это набор скаляров, матрица - вектор векторов, правильно ? Все операции тоже прекрасно определены, можем писать D = A*B + C*scalar, правильно ?
И такие штуки были очень модными лет 15 назад, когда появился C++. А потом мода сошла и все вернулись к основам: CALL DGEMM(....)
А знаете почему ? Потому что если вы все инкапсулируете и элемент результата будете представлять как скалярное произведение двух векторов, то работать все будет. И код будет понимаемым. Только вот скорость будет на пару порядков меньше, чем при использовании знаний об реальной внутренней организации данных , архитектуре процессора, его кэшах и все такое прочее.
А это абсолютно тривиальный пример, прекрасно ложащийся на ООП.
Я вот отвечу только на несколько, там где можно кратко, нет сил растекаться мыслею
не подходит в силу убогой реализации ООП.
ООП - вообще не догма. Нету никакой необходимости в ООП.
Использование UML и паттернов при проектировании и ООП на стадии реализации спасет отца русской демократии
Наивная вера в UML и паттерны выдает теоретика. Есть еще много страшных слов: CORBA, RMI, EJB. К реальной жизни крупного веб-проекта они относятся очень слабо.
200 запросов в секунду при какой загрузке?
Вопрос теоретика. Значение имеет размер данных, я действительно забыл указать. 200 запросов по HTTP из базы данных, индексы которой не влезают в RAM.
Зато совершенно не пофигу как осуществляется взаимодействие с СУБД и какие средства предоставляет язык для упрощения этих операций.
Вот это, как раз, абсолютно пофигу. Не нравятся средства языка - ну напишите один раз нашлепку сверху. Какую хотите, хоть объектную, хоть еще какую. Будете миллион-первым.
Понимаете, все вот эти пляски вокруг выбора языка - они происходят в предположении, что собственно кодирование занимает какое-то значимое время. А это совсем не так, основное время уходит на пере-проектирование и тестирование (даже не на отладку). В вебе же всегда moving target. А сколько у вас уйдет на кодирование - 10% времени или 20 - нет никакой разницы.
А вот рисование стрелочек в начале проекта и наложение на них визиторов, синглетонов и прочих функторов приведет затем к крайне интересному эффекту, когда выяснится, что иерархия объектов на самом деле совсем другая.
Угу только вот в Java и в вроде .NET это уже реализовано на уровне сервера по умолчанию.
Что это ? Снабжение разработчика умом ?
Сейчас Java(EJB)/Net в той же позиции, что и несколько лет VB - быстрое написание каких-то вебовских приложений.
А когда вам нужно не "какое-то", а единственное уникальное и посидеть недельку подумать - это экономия пары десятков серверов или $100k - язык уже имеет минимальное значение. Чем вам ORM не ку? Так же кешит.
"Автоматически" ? Или на чтении ? Кэширование на чтении на крупных проектах не подходит. А автоматическое proactive-кэширование требует телепатии от средств разработки, пока нету.
FastCGI естественно реализует лучшую модель чем mod_php. Но по умолчанию пользователю предлагается именно mod_php
А для странички на виртуальном хостинге этого достаточно. А если мы все еще про большие проекты, то у них есть разработчики снабженные умом.
Почитайте про ORM
Ну почитал. А толку то ? Вот простая задача: 5 заголовков новостей на морде Яндекса. Есть разумное решение: пушить эти 5 заголовков в кэши в памяти на фронтендах. Пушить будет, естественно, модуль который эти top5 рассчитывает. Проактивное, так сказать, кэширование.
Все остальные решения - неразумные.
похоже, имелось ввиду, что php не обладает достаточной масштабируемостью, для больших проектов и, черт возьми, я с этим абсолютно согласен
А я - не согласен. Т.е. я на PHP ничего никогда не делал, но вижу "на нем" большие проекты (Бегун, Мамба - как примеры).
PHP - это такой язык программирования + небольшой фреймворк. Немного странный, кривой и косой, ну а что прямое ?
Большие же проекты бывают двух видов
а) дофига кода т.к. сложная функциональность
б) дофига обращений и при этом дофига данных
(может быть оба сразу)
И это все - не проблема выбора языка программирования. Программировать вообще пофигу на чем (я вот обратно полюбил фортран после 20-летнего перерыва) и если кода много, то проблемы его организации примерно одинаковы во всех процедурных языках позволяющих использовать локальные переменные.
А при большой нагрузке/больших данных - это все проблема аккуратного проектирования БД, создания множества серверов БД (например, популярное сейчас single writer/multiple readers), кэширования нужных данных в памяти и т.п. Ну вот вы никак не отдадите 200 запросов в секунду из БД, какая бы она не была. И совершенно пофигу на каком языке их отдавать из памяти.
У PHP есть одно огромное достоинство и один небольшой недостаток и на них и следует ориентироваться
а) "специалистов" по PHP много. Они, конечно, преимущественно в кавычках, но есть из кого выбрать, чтобы затем учить
б) в проекте кроме вебовской функциональности обычно есть и другая обвязка (command-line). Делать ее на PHP глупо, что автоматически заводит в проекте еще один язык.
Ага уберите два костыля в виде FastCGI и memcached
Вы что, какие костыли ? FastCGI реализует более разумную модель
приложения, чем mod_php. Без лишних копий. В-принципе, если (бы) иметь на входе другой разумный сериализатор, то можно было (бы) иметь и mod_php backend.
А, извините, memcached реализует то, что в любом случае придется реализовывать руками - кэширование в памяти тех данных, которые там нужны.
PHP же для нагруженных проектов достаточно большой гемморой.
Нагруженные проекты сами по себе большой геморой
Вот берем цифровой фотоаппарат. У него сенсор вообще линейный, "средства адаптации" - тоже линейные (чувствительность, выдержка и светосила).
Что совершенно не мешает делать фотографии при освещенности,
отличающейся на 7 десятичных порядков. Не "отдельные фотоны", а именно фотографии, где есть, например, видимая линия горизонта
На самом деле, разница в освещенности не такая фатальная.
Пусть даже мы видим отдельные фотоны. Целый один. Он попал в
клетку и произвел сигнал.
А сколько фотонов попадает в клетку при нормальной освещенности,
скажем за 1/25 секунды (условная постоянная времени глаза)?
А не так и много, как выясняется.
Один люкс - это 10^16 фотонов в секунду на квадратный метр. Через зрачок
пройдет на ~4 порядка меньше. Размажется это по 120 млн светочувствительных
клеток (основное количество из них - палочки). Т.е. еще минус 8 порядков.
Т.е. 10^4 фотонов в секунду на клетку или ~400 в 1/25 секунды.
На ярком свету (10^4 люкс) зрачок спилит еще пару порядков и будет ~40000
фотонов на клетку за "постоянную времени". Оценка от фонаря, просто
порядок величины.
Вот и получается, что у нас два вида рецепторов, обеспечивающих динамический диапазон 4-5 порядков. А вовсе не 12.
Естественно, ученые по цвету и глазу про адаптацию знают и эксперименты
с цветным зрением проводятся после адаптации (есть/были и обратные эксперименты,
когда нечто показывается глазу, адаптированному под другое освещение; есть/были
эксперименты на додумывание сцены, когда показывают нечто знакомое без одной из компонент)
Сумеречное зрение и цветное - имеют разные чувствительные элементы, механизмы
там тоже могут быть разными, запросто.
А вот про 100-200 часов и улавливание отдельных фотонов - это больше похоже на апокриф.
Если просидеть неделю (168) часов в темноте, то крыша может уехать довольно далеко
и что и как будет уловлено - вопрос. Даже когда просыпаешься под землей - ощущения
самые различные, пробовал.
На самом деле, причина может быть и другой. Современная шкала зведных
величин разработана в середине 19-го века. Исследования Вебера уже были,
астрономы могли их просто имплементировать в шкале звездных величин не
задумываясь.
Для сумеречного (scotopic) зрения все может быть иначе.
Оно мне с практической (фотографической) точки зрения неинтересно
и подробностями я не интересовался
Я на 99% уверен, что там не так все просто. А усложняется все тем,
что слух довольно быстро тренируется (быстрее зрения) и в процессе
изучения будет меняться изучаемый объект.
1) Есть минимальные приращения, которые видны глазом (как разница между яркостями/цветами
двух соседних объектов). Для этого (вроде бы) работает логарифм т.е. минимальная видимая ступенька
пропорциональна яркости одного из сравниваемых объектов (они близки по яркости).
При цветном зрении видна разница примерно в 1%. Это закон Фехнера (или Фехнера-Вебера)
2) А вот для больших приращений это не так. Скажем, если мы хотим построить шкалу из 20
шагов с диапазоном яркостей 1:127 и будем строить ее по экспоненциальному закону, то
получится шкала, которая не выглядит равномерной. Разница в яркости в 30% в темной
области выглядит меньше, чем такая же разница в светлой.
А равномерной (perceptual uniform) выглядит шкала, которая линейна в темной области
(в самом начале шкалы) и кубична в остатке. Т.е. линейная по L в пространстве L*a*b.
Собственно, Lab и был придуман как перцептуально-линейное (с евклидовой метрикой
разницы).
3) Суть ошибки в том, что дифференциальное исчисление впрямую применяют к ощущениям
(интегрированием закона Фехнера), интегрируя малые приращения. А это неверно даже
для яркостей.
4) Кроме этого, естественно, есть одновременные контрасты и прочие зависимости
восприятия от окружения, есть (довольно примитивные) модели вроде CIECAM02, но это
уже исправление недостатков Lab (как первое приближение Lab вполне неплохо)
Если в организации 1000 сотрудников, то по мегабиту на каждого не нужно.
И для почты-видео-whatever - не нужно.
На, блин, сотни тысяч подписчиков стрима у МТУ внешних каналов - гигабит 10.
И на Россию - ну пусть вдвое больше (считая что забугра - треть).
Хватает на все.
ООП - прекрасная штука, если иерархия объектов и их функциональность - очевидны. Да и то.
Вот представим себе объекты, которые идеально подходят под парадигму ООП - линейная алгебра, скаляры, векторы и матрицы. Вектор - это набор скаляров, матрица - вектор векторов, правильно ? Все операции тоже прекрасно определены, можем писать D = A*B + C*scalar, правильно ?
И такие штуки были очень модными лет 15 назад, когда появился C++. А потом мода сошла и все вернулись к основам: CALL DGEMM(....)
А знаете почему ? Потому что если вы все инкапсулируете и элемент результата будете представлять как скалярное произведение двух векторов, то работать все будет. И код будет понимаемым. Только вот скорость будет на пару порядков меньше, чем при использовании знаний об реальной внутренней организации данных , архитектуре процессора, его кэшах и все такое прочее.
А это абсолютно тривиальный пример, прекрасно ложащийся на ООП.
не подходит в силу убогой реализации ООП.
ООП - вообще не догма. Нету никакой необходимости в ООП.
Использование UML и паттернов при проектировании и ООП на стадии реализации спасет отца русской демократии
Наивная вера в UML и паттерны выдает теоретика. Есть еще много страшных слов: CORBA, RMI, EJB. К реальной жизни крупного веб-проекта они относятся очень слабо.
200 запросов в секунду при какой загрузке?
Вопрос теоретика. Значение имеет размер данных, я действительно забыл указать. 200 запросов по HTTP из базы данных, индексы которой не влезают в RAM.
Зато совершенно не пофигу как осуществляется взаимодействие с СУБД и какие средства предоставляет язык для упрощения этих операций.
Вот это, как раз, абсолютно пофигу. Не нравятся средства языка - ну напишите один раз нашлепку сверху. Какую хотите, хоть объектную, хоть еще какую. Будете миллион-первым.
Понимаете, все вот эти пляски вокруг выбора языка - они происходят в предположении, что собственно кодирование занимает какое-то значимое время. А это совсем не так, основное время уходит на пере-проектирование и тестирование (даже не на отладку). В вебе же всегда moving target. А сколько у вас уйдет на кодирование - 10% времени или 20 - нет никакой разницы.
А вот рисование стрелочек в начале проекта и наложение на них визиторов, синглетонов и прочих функторов приведет затем к крайне интересному эффекту, когда выяснится, что иерархия объектов на самом деле совсем другая.
Что это ? Снабжение разработчика умом ?
Сейчас Java(EJB)/Net в той же позиции, что и несколько лет VB - быстрое написание каких-то вебовских приложений.
А когда вам нужно не "какое-то", а единственное уникальное и посидеть недельку подумать - это экономия пары десятков серверов или $100k - язык уже имеет минимальное значение.
Чем вам ORM не ку? Так же кешит.
"Автоматически" ? Или на чтении ? Кэширование на чтении на крупных проектах не подходит. А автоматическое proactive-кэширование требует телепатии от средств разработки, пока нету.
А для странички на виртуальном хостинге этого достаточно. А если мы все еще про большие проекты, то у них есть разработчики снабженные умом.
Почитайте про ORM
Ну почитал. А толку то ? Вот простая задача: 5 заголовков новостей на морде Яндекса. Есть разумное решение: пушить эти 5 заголовков в кэши в памяти на фронтендах. Пушить будет, естественно, модуль который эти top5 рассчитывает. Проактивное, так сказать, кэширование.
Все остальные решения - неразумные.
А я - не согласен. Т.е. я на PHP ничего никогда не делал, но вижу "на нем" большие проекты (Бегун, Мамба - как примеры).
PHP - это такой язык программирования + небольшой фреймворк. Немного странный, кривой и косой, ну а что прямое ?
Большие же проекты бывают двух видов
а) дофига кода т.к. сложная функциональность
б) дофига обращений и при этом дофига данных
(может быть оба сразу)
И это все - не проблема выбора языка программирования. Программировать вообще пофигу на чем (я вот обратно полюбил фортран после 20-летнего перерыва) и если кода много, то проблемы его организации примерно одинаковы во всех процедурных языках позволяющих использовать локальные переменные.
А при большой нагрузке/больших данных - это все проблема аккуратного проектирования БД, создания множества серверов БД (например, популярное сейчас single writer/multiple readers), кэширования нужных данных в памяти и т.п. Ну вот вы никак не отдадите 200 запросов в секунду из БД, какая бы она не была. И совершенно пофигу на каком языке их отдавать из памяти.
У PHP есть одно огромное достоинство и один небольшой недостаток и на них и следует ориентироваться
а) "специалистов" по PHP много. Они, конечно, преимущественно в кавычках, но есть из кого выбрать, чтобы затем учить
б) в проекте кроме вебовской функциональности обычно есть и другая обвязка (command-line). Делать ее на PHP глупо, что автоматически заводит в проекте еще один язык.
Вы что, какие костыли ? FastCGI реализует более разумную модель
приложения, чем mod_php. Без лишних копий. В-принципе, если (бы) иметь на входе другой разумный сериализатор, то можно было (бы) иметь и mod_php backend.
А, извините, memcached реализует то, что в любом случае придется реализовывать руками - кэширование в памяти тех данных, которые там нужны.
PHP же для нагруженных проектов достаточно большой гемморой.
Нагруженные проекты сами по себе большой геморой
Поэтому я думаю, что с IPTV тоже ничего не выйдет
На самом деле Naspers - это нигерийская компания. И суть сделки -
в отмене фильтрации нигерийского спама.
Что совершенно не мешает делать фотографии при освещенности,
отличающейся на 7 десятичных порядков. Не "отдельные фотоны", а именно фотографии, где есть, например, видимая линия горизонта
На самом деле, разница в освещенности не такая фатальная.
Пусть даже мы видим отдельные фотоны. Целый один. Он попал в
клетку и произвел сигнал.
А сколько фотонов попадает в клетку при нормальной освещенности,
скажем за 1/25 секунды (условная постоянная времени глаза)?
А не так и много, как выясняется.
Один люкс - это 10^16 фотонов в секунду на квадратный метр. Через зрачок
пройдет на ~4 порядка меньше. Размажется это по 120 млн светочувствительных
клеток (основное количество из них - палочки). Т.е. еще минус 8 порядков.
Т.е. 10^4 фотонов в секунду на клетку или ~400 в 1/25 секунды.
На ярком свету (10^4 люкс) зрачок спилит еще пару порядков и будет ~40000
фотонов на клетку за "постоянную времени". Оценка от фонаря, просто
порядок величины.
Вот и получается, что у нас два вида рецепторов, обеспечивающих динамический диапазон 4-5 порядков. А вовсе не 12.
черенковское излучение от того, что ему в глаз попадало.
с цветным зрением проводятся после адаптации (есть/были и обратные эксперименты,
когда нечто показывается глазу, адаптированному под другое освещение; есть/были
эксперименты на додумывание сцены, когда показывают нечто знакомое без одной из компонент)
Сумеречное зрение и цветное - имеют разные чувствительные элементы, механизмы
там тоже могут быть разными, запросто.
А вот про 100-200 часов и улавливание отдельных фотонов - это больше похоже на апокриф.
Если просидеть неделю (168) часов в темноте, то крыша может уехать довольно далеко
и что и как будет уловлено - вопрос. Даже когда просыпаешься под землей - ощущения
самые различные, пробовал.
величин разработана в середине 19-го века. Исследования Вебера уже были,
астрономы могли их просто имплементировать в шкале звездных величин не
задумываясь.
Оно мне с практической (фотографической) точки зрения неинтересно
и подробностями я не интересовался
что слух довольно быстро тренируется (быстрее зрения) и в процессе
изучения будет меняться изучаемый объект.
1) Есть минимальные приращения, которые видны глазом (как разница между яркостями/цветами
двух соседних объектов). Для этого (вроде бы) работает логарифм т.е. минимальная видимая ступенька
пропорциональна яркости одного из сравниваемых объектов (они близки по яркости).
При цветном зрении видна разница примерно в 1%. Это закон Фехнера (или Фехнера-Вебера)
2) А вот для больших приращений это не так. Скажем, если мы хотим построить шкалу из 20
шагов с диапазоном яркостей 1:127 и будем строить ее по экспоненциальному закону, то
получится шкала, которая не выглядит равномерной. Разница в яркости в 30% в темной
области выглядит меньше, чем такая же разница в светлой.
А равномерной (perceptual uniform) выглядит шкала, которая линейна в темной области
(в самом начале шкалы) и кубична в остатке. Т.е. линейная по L в пространстве L*a*b.
Собственно, Lab и был придуман как перцептуально-линейное (с евклидовой метрикой
разницы).
3) Суть ошибки в том, что дифференциальное исчисление впрямую применяют к ощущениям
(интегрированием закона Фехнера), интегрируя малые приращения. А это неверно даже
для яркостей.
4) Кроме этого, естественно, есть одновременные контрасты и прочие зависимости
восприятия от окружения, есть (довольно примитивные) модели вроде CIECAM02, но это
уже исправление недостатков Lab (как первое приближение Lab вполне неплохо)
А 1000 человек в едином трудовом порыве делающих что ? Видеочат ?
в домохозяйстве занять даже мегабит нечем
И для почты-видео-whatever - не нужно.
На, блин, сотни тысяч подписчиков стрима у МТУ внешних каналов - гигабит 10.
И на Россию - ну пусть вдвое больше (считая что забугра - треть).
Хватает на все.
Для организаций там другой прайсинг.
Зачем, кстати, организации гигабит ?