-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
проблемы объектного сознания
- Автор темы fisher
- Дата начала
- Статус
svetasmirnova
маленький монстрик
StUV
нет, про твой последний неотредактированный
нет, про твой последний неотредактированный
StUV
Rotaredom
++
недавно в открытых работах одной из "сильносвязанных с ИТ" кафедр бауманки в описании платформы для запуска вычислений, основанных на решении "задачи о рюкзаке", нашел схемы кластерных решений на oss, активно использующиеся в данный момент в системах статистики некоторых крупных web-сервисов
дату публикации/линк на источник уже не вспомню, но тогда поразился, что это было точно за пару лет до первого потока открытых публикаций именно по теме веба
соответственно, примеры реализации подавляющего числа задач можно найти в соответствующей литературе, вопрос в желании и особенно во времени на все это (проблема одних ресурсов порождает проблемы других)
недавно в открытых работах одной из "сильносвязанных с ИТ" кафедр бауманки в описании платформы для запуска вычислений, основанных на решении "задачи о рюкзаке", нашел схемы кластерных решений на oss, активно использующиеся в данный момент в системах статистики некоторых крупных web-сервисов
дату публикации/линк на источник уже не вспомню, но тогда поразился, что это было точно за пару лет до первого потока открытых публикаций именно по теме веба
соответственно, примеры реализации подавляющего числа задач можно найти в соответствующей литературе, вопрос в желании и особенно во времени на все это (проблема одних ресурсов порождает проблемы других)
svetasmirnova
маленький монстрик
fisher
> наконец, ниже пояса. инкапсуляция как одобрение интеллектуальной слепоты
А отделение HTML от "кода" не является ли по сути той же инкапсуляцией?
> наконец, ниже пояса. инкапсуляция как одобрение интеллектуальной слепоты
А отделение HTML от "кода" не является ли по сути той же инкапсуляцией?
StUV
Rotaredom
возвращаясь к тредстарту
>> объекты - промежуточные построения, умозрительные
>> программа либо полезна либо бесполезна. то есть суть работы - результат, не процесс
imho, оо-организация кода проще в re-use
т.е. если рассматривать результат одного проекта как старт нового, в большей степени изменяющего, чем расширяющего первый - хорошо организованный оо-код проще взять as-is (с поддержкой одной ветки в обоих продуктах + отдельно код модификаций)
-~{}~ 17.03.09 01:07:
>> высокая стоимость владения (стоимость владения большого веб-проекта в разы превышает фонд зп)
здесь бы уточнить... - ооп каким боком?
>> инкапсуляция как одобрение интеллектуальной слепоты (мне неважно что там - унаследую и понеслась
в условиях долгоживущего проекта - "нормальная" практика
уже внедренный "когда-то" протокол определяет общие интерфейсы
недоверие к интерфейсам порождает замену протокола, а это уже "революция" подсистем (не эволюция) - что достаточно затратно (соответственно, закладываясь на обратное - противоречим пунктам первого абзаца тезисов тредстарта)
-~{}~ 17.03.09 01:18:
>> интеллектуальная слепота как метод заработка
относительно сильно ограниченного
в случае особого успеха - только во времени (если не вкладываться в развитие)
>> тотальная не-математичность
базовые алгоритмы инкапсулированы в средство, оптимизаций хватает в других местах
в случае необходимости - можно заменить имплементацию ("не боги пхп/... ..." =))
>> не-реляционность
малый %% низкоуровневых операций над данными - т.е. усложненная реализация доступа/обработки в итоге упрощает интерфейсы и сокращает клиентский код - уменьшает сроки, затраты - следовательно, работает на результат
>> и сплошной ОРМ
при отсутствии дорогостоящего "правильного" софта - хорошее средство для построения многостраничных запросов к сложным реляционным моделям (ессно, последующая оптимизация и нарезка типовых шаблонов необходима)
не более...
>> объекты - промежуточные построения, умозрительные
>> программа либо полезна либо бесполезна. то есть суть работы - результат, не процесс
imho, оо-организация кода проще в re-use
т.е. если рассматривать результат одного проекта как старт нового, в большей степени изменяющего, чем расширяющего первый - хорошо организованный оо-код проще взять as-is (с поддержкой одной ветки в обоих продуктах + отдельно код модификаций)
-~{}~ 17.03.09 01:07:
>> высокая стоимость владения (стоимость владения большого веб-проекта в разы превышает фонд зп)
здесь бы уточнить... - ооп каким боком?
>> инкапсуляция как одобрение интеллектуальной слепоты (мне неважно что там - унаследую и понеслась
в условиях долгоживущего проекта - "нормальная" практика
уже внедренный "когда-то" протокол определяет общие интерфейсы
недоверие к интерфейсам порождает замену протокола, а это уже "революция" подсистем (не эволюция) - что достаточно затратно (соответственно, закладываясь на обратное - противоречим пунктам первого абзаца тезисов тредстарта)
-~{}~ 17.03.09 01:18:
>> интеллектуальная слепота как метод заработка
относительно сильно ограниченного
в случае особого успеха - только во времени (если не вкладываться в развитие)
>> тотальная не-математичность
базовые алгоритмы инкапсулированы в средство, оптимизаций хватает в других местах
в случае необходимости - можно заменить имплементацию ("не боги пхп/... ..." =))
>> не-реляционность
малый %% низкоуровневых операций над данными - т.е. усложненная реализация доступа/обработки в итоге упрощает интерфейсы и сокращает клиентский код - уменьшает сроки, затраты - следовательно, работает на результат
>> и сплошной ОРМ
при отсутствии дорогостоящего "правильного" софта - хорошее средство для построения многостраничных запросов к сложным реляционным моделям (ессно, последующая оптимизация и нарезка типовых шаблонов необходима)
не более...
жалко, я надеялся что топик пойдёт в сторону функционального программирования и распределённых систем.
а получается что 99% утверждают, что программировать в объектно-ориентированном стиле удобнее на классах, нежели делать тоже на процедурах и функциях. удивился бы если бы это было не так.
а получается что 99% утверждают, что программировать в объектно-ориентированном стиле удобнее на классах, нежели делать тоже на процедурах и функциях. удивился бы если бы это было не так.
StUV
ну, мне как бы самому хотелось бы послушать, опыт программирования у мну маленький и скудный. но могу попробовать.
функциональный подход,
ооп подход. мы при каждой итерации проверяем размер массива, так как его состояние могло измениться.
самая важная проблема - это состояния, собственно ради состояний мы и используем объекты. если состояний нет, а важны только результаты работы, то стоит использовать функциональный стиль. во время кеширования мы как раз обращаемся к функциональному стилю, используя не состояния, а результаты работы.
в распределённых системах мы получаем преимущество за счёт распараллеливания процесов. допустим на новый отчёт мы _одновременно_ отправляем несколько обработчиков, каждый там _у себя_ делает необходимые расчёты и пишет результаты.
ну, мне как бы самому хотелось бы послушать, опыт программирования у мну маленький и скудный. но могу попробовать.
функциональный подход,
PHP:
$array = array(0,1,0);
$arrayCount = count($array);
for($i=0;$i<$arrayCount;$i++) doAnything($array);
PHP:
$array = array(0,1,0);
for($i=0;$i<count($array);$i++) doAnything($array);в распределённых системах мы получаем преимущество за счёт распараллеливания процесов. допустим на новый отчёт мы _одновременно_ отправляем несколько обработчиков, каждый там _у себя_ делает необходимые расчёты и пишет результаты.
fisher
накатила суть
>>А отделение HTML от "кода" не является ли
>>по сути той же инкапсуляцией?
не совсем, это модульность. собственно именно про модульность (компонентность) и было выше в цитате - что, мол, похоже только модульность значение и имеет.
-~{}~ 17.03.09 09:19:
>>по сути той же инкапсуляцией?
не совсем, это модульность. собственно именно про модульность (компонентность) и было выше в цитате - что, мол, похоже только модульность значение и имеет.
-~{}~ 17.03.09 09:19:
согласен
CPU
ну я же говорю об обратной стороне медали! у человека всегда есть какая-то часть которая какбе говорит ему - чел ну давай уже заебошим поскорее вот тут понатыкаем вроде делает чё надо и пойдем пиво пить / к любимой семье и детям. это не тупость. это психология. психология не разбираться воткнуть кубиком лего. это и плюс, и минус.
относительно не относительно - проблема есть. с промышленной точки зрения компонентность позволяет получить дешевый труд сборщика на конвеере. программист - рабочий вообще-то, если кто-то это ещё не понял и витает в розовых облаках.
всё это потом страшно бьет по голове если проект вырос
ну чем оно хорошее-то? единственное удобство - автогенерация типовых интерфейсов по схеме, когда ты делаешь типовые проекты десятки штук в год. так эту проблему можно в любой парадигме хорошо решить.
Alexandre
PHPПенсионер
fisher
полностью тебя поддерживаю. Мое мнение - просто у одних одни проекты, направленные на производительность, а у других - другие, направленные на "быстрое написание". Вот и изобретают велосипеды, аля ASP.NET под РНР
как говорил мой ведущий специалист "делай как можно проще, сложно - получится само", очень ценные мысли здесь как впрочем и вдругих главах этой книги.
полностью тебя поддерживаю. Мое мнение - просто у одних одни проекты, направленные на производительность, а у других - другие, направленные на "быстрое написание". Вот и изобретают велосипеды, аля ASP.NET под РНР
как говорил мой ведущий специалист "делай как можно проще, сложно - получится само", очень ценные мысли здесь как впрочем и вдругих главах этой книги.
StUV
Rotaredom
эээ.... не совсем
недавно столкнулся с проблемой - "утрированно" суть:
проектная команда ~ 10-15 чел.
с учетом задействованых технологий - в среднем 1-3 чел. в направлении
нач. одного из направлений на мой запрос на новую фичу отвечает "сделаем так-то" - я удивленно "почему так, а не вот так?" - "надо, нам виднее"
ОК, поехали...
спустя пол-года более опытный спец удивленно - "а нафига вы в этом месте яйца через ж на уши натянули?"... в итоге переделаем по модели моего первоначального предположения
к чему это все - если я в команде все-таки квалифицированных в своей области спецов буду сомневаться в предлагаемых ими интерфейсах + и не только я, а и все участники проекта - это все очччень медленно, но правильно и красиво развиваясь загнется и прикроется в зачатке...
понятно, что при проектировании системы на уровне узловых подсистем (продуктов, средств, библиотек, ...) + на первых итерациях разработки - нельзя останавливаться на уровне интерфейсов - необходимо знать/понимать работу изнутри, но в завершающей стадии (после 70% ~rup-развития) мы уже _должны_ использовать готовые интерфейсы
да
программер - в конечном итоге ремесленник
в чем суть проблемы? (тезисно)
развитие технологий порождает новые "горизонты" в развитии специальности
за последние ~70 лет рост области мат. направлений в ИТ постоянно увеличивается, направлений для реальной научной работы в сфере кибернетика=физ.+мат. - просто дофига, отраслей для практических применений своего "творчества" хватает, особо "талантливые" каждые 5-10 лет порождают новые области/направления
т.е. металл как плавили/ковали 500 лет назад - технология так и осталась на примерно том же уровне - рост только в масштабах и околопроизводственной инфраструктуре, но наочно-прикладных технологичных процессов родилось просто дофига и никогда оно не остановится
а если кто-то сидит у себя в сарае на даче и кует в мини-кузнице жестяные феньки в собственное удовольствие/для продажи - ну и хсним
как блочный конструктор - по принципу приводимого кажется выше c++билдера - можно не вдаваясь в подробности зафигачить приличный интерфейс, а потом оттюнить его на нативном уровне - главное не забывать как оно работает внутри
но. спорить по теме орм не буду - на личной практике так нае..лся с орм - на всю жизнь впечатлений. плюсы вижу больше в теории и возможных будущих применениях, чем в возможной ближайшей практике.
Alexandre
PHPПенсионер
с удовольствием прочитал весь топик
многот противоричивый мений - и это по моему - хорошо...
я не буду дискутировать, ограничусь используемой практикой
использую ООП в той мере - в какой оно необходимо. Перекопал кучу лит-ры по этому вопросу, но не скажу что съел сабаку,
многое зависит от цели приложения,например, если мы на 100% знаем что не перейдем на другую БД, то в этом случае некий класс AbstractDBLayer - является лишней прослойкой. Несомненно - если у нас коробочный вариант - то такую возможность предусмотреть необходимо.
Итак - зная ососбенности конкретного приложения - часть абстрактных классов просто является лишней...
ORM - это отдельная песня...
многот противоричивый мений - и это по моему - хорошо...
я не буду дискутировать, ограничусь используемой практикой
использую ООП в той мере - в какой оно необходимо. Перекопал кучу лит-ры по этому вопросу, но не скажу что съел сабаку,
многое зависит от цели приложения,например, если мы на 100% знаем что не перейдем на другую БД, то в этом случае некий класс AbstractDBLayer - является лишней прослойкой. Несомненно - если у нас коробочный вариант - то такую возможность предусмотреть необходимо.
Итак - зная ососбенности конкретного приложения - часть абстрактных классов просто является лишней...
ORM - это отдельная песня...
StUV
Rotaredom
+к теме спора о выборе подхода
задолбало "на пальцах" объяснять критерии выбора того или иного подхода - хочется один раз "отрезать и все"
(сорри, если где какие лаги - поток сознания и все вытекающее)...
тут AmdY высказался за определение критериев выбора на основе
>> самая важная проблема - это состояния, собственно ради состояний мы и используем объекты. если состояний нет, а важны только результаты работы, то стоит использовать функциональный стиль.
не спора для, а обсуждения ради...
состояние системы (объекта, процесса, ...) определяется как совокупность состояний его степеней свободы в заданный момент времени
X = F(t), X определено на множестве {X} = {x_1, ..., x_N}, F(t) принадлежит множетсву {X}
это в "простых случаях" - поясняю: в наших обсуждениях часто встречается аргументация вида - "в простом проекте это так, а вот у нааас, система слооожная, распределенная.... - там все сложно, математика сложная, хрен разберешься"
так вот, в простых случаях мы можем определить динамику состояний так
X=F(t) => {x_i=f(t)}
так вот, в общем случае сложных не(квази)детерменированных систем (сложные распределенные программные комплексы)
описание меняется математически меняется не значительно:
X=F(t,G(X)) => {x_i=f(t, g(x_1, ..., x_(i-1), x_(i+1, ..., x_N)))}
(в недетерминиролванных системах для некоторых степеней свободы - неисключается и x_i, так, к слову)
т.е. состояние суть функция аргументов время и некоторая функция состояния (определенная на некотором своем множестве)
Далее, в нашем мире так сложилось, что информация на аппаратном уровне представлена линейно - 0/1.
Для постороения более сложных (более информативных - тафтологически) систем и операций над ними - используются некоторые соглашения.
Часто эти соглашения называют контрактами.
Любой контракт, повышающий уровень абстракции, приводит к затратам дополнительных ресурсов - притивно - увеличению единиц используемой машинной памяти и тактов процессора.
Есть контракты аппаратные - 8бит=1байт, и тд... + аппаратные реализации двоичной арифметики + более сложные абстракции аппаратных матричных операций над сущностями более высокой разрядности, но в конечном итоге конечные операции - суть операции над линейными структурами - т.е. _контракты_затратны_
Далее, контракты семантики и базового функционала средств разработки - машинные коды, асм, ...
Тут уже отмечались, те кто помнят первые домашние "игровые" ПК - чтобы сделать на них дейтвительно что-то интересное, контрактов и абстраций встроенных средств разработки (бэйсик, паскаль) было недостаточно - приходилось часть подпрограмм кодировать напрямую или ассемблировать.
Далее,... средства и их контракты эволюционируют, оптимизируются и снова эволюционируют и тд.. тп - появляются структурные языки, объектные, объектно-ориентированные - и каждый новый контракт - это затраты, затраты, затраты, затраты, затраты,......
За этими всеми контрактами забываются начальные 0/1, потеря производительности, рост "стоимости владения", ... - хорошо, если продукт или разрабатываемая его часть не требует оптимизаций на уровне понижения абстракций за счет отказа от дополнительных контрактов.
А если требует?
Вот здесь, только на этой грани и возникает вопрос выбора конкретного средства, парадигмы, подхода, алгоритма, ... - И это _чистый_критерий_ _идеализированного_процесса_ разработки программного продукта.
А ведь есть еще бизнес затраты - ниокр, стоимость средств разработки, стоимость кадров, железо, ...
--------
так что... "самая важная проблема" _для_меня_ где-то в этом, а не "ооп это просто круто и правильно" или "функциональный подход ускоряет разработку"
------------------------
я перейду полностью на ооп на объектно-ориентированном железе - напр., на квантовых компах, оперирующих на самом низком уровне переходами в пространстве с количеством степеней свободы, достаточным для хранения информации о состояниях объектов реального мира, но не ранее...
-~{}~ 17.03.09 11:46:
x-yuri
http://phpclub.ru/talk/showthread.php?s=&threadid=69253
(действующие лица - те же
)
а вообще - это было очень давно, "в другой жизни"...
задолбало "на пальцах" объяснять критерии выбора того или иного подхода - хочется один раз "отрезать и все"
(сорри, если где какие лаги - поток сознания и все вытекающее)...
тут AmdY высказался за определение критериев выбора на основе
>> самая важная проблема - это состояния, собственно ради состояний мы и используем объекты. если состояний нет, а важны только результаты работы, то стоит использовать функциональный стиль.
не спора для, а обсуждения ради...
состояние системы (объекта, процесса, ...) определяется как совокупность состояний его степеней свободы в заданный момент времени
X = F(t), X определено на множестве {X} = {x_1, ..., x_N}, F(t) принадлежит множетсву {X}
это в "простых случаях" - поясняю: в наших обсуждениях часто встречается аргументация вида - "в простом проекте это так, а вот у нааас, система слооожная, распределенная.... - там все сложно, математика сложная, хрен разберешься"
так вот, в простых случаях мы можем определить динамику состояний так
X=F(t) => {x_i=f(t)}
так вот, в общем случае сложных не(квази)детерменированных систем (сложные распределенные программные комплексы)
описание меняется математически меняется не значительно:
X=F(t,G(X)) => {x_i=f(t, g(x_1, ..., x_(i-1), x_(i+1, ..., x_N)))}
(в недетерминиролванных системах для некоторых степеней свободы - неисключается и x_i, так, к слову)
т.е. состояние суть функция аргументов время и некоторая функция состояния (определенная на некотором своем множестве)
Далее, в нашем мире так сложилось, что информация на аппаратном уровне представлена линейно - 0/1.
Для постороения более сложных (более информативных - тафтологически) систем и операций над ними - используются некоторые соглашения.
Часто эти соглашения называют контрактами.
Любой контракт, повышающий уровень абстракции, приводит к затратам дополнительных ресурсов - притивно - увеличению единиц используемой машинной памяти и тактов процессора.
Есть контракты аппаратные - 8бит=1байт, и тд... + аппаратные реализации двоичной арифметики + более сложные абстракции аппаратных матричных операций над сущностями более высокой разрядности, но в конечном итоге конечные операции - суть операции над линейными структурами - т.е. _контракты_затратны_
Далее, контракты семантики и базового функционала средств разработки - машинные коды, асм, ...
Тут уже отмечались, те кто помнят первые домашние "игровые" ПК - чтобы сделать на них дейтвительно что-то интересное, контрактов и абстраций встроенных средств разработки (бэйсик, паскаль) было недостаточно - приходилось часть подпрограмм кодировать напрямую или ассемблировать.
Далее,... средства и их контракты эволюционируют, оптимизируются и снова эволюционируют и тд.. тп - появляются структурные языки, объектные, объектно-ориентированные - и каждый новый контракт - это затраты, затраты, затраты, затраты, затраты,......
За этими всеми контрактами забываются начальные 0/1, потеря производительности, рост "стоимости владения", ... - хорошо, если продукт или разрабатываемая его часть не требует оптимизаций на уровне понижения абстракций за счет отказа от дополнительных контрактов.
А если требует?
Вот здесь, только на этой грани и возникает вопрос выбора конкретного средства, парадигмы, подхода, алгоритма, ... - И это _чистый_критерий_ _идеализированного_процесса_ разработки программного продукта.
А ведь есть еще бизнес затраты - ниокр, стоимость средств разработки, стоимость кадров, железо, ...
--------
так что... "самая важная проблема" _для_меня_ где-то в этом, а не "ооп это просто круто и правильно" или "функциональный подход ускоряет разработку"
------------------------
я перейду полностью на ооп на объектно-ориентированном железе - напр., на квантовых компах, оперирующих на самом низком уровне переходами в пространстве с количеством степеней свободы, достаточным для хранения информации о состояниях объектов реального мира, но не ранее...
-~{}~ 17.03.09 11:46:
x-yuri
http://phpclub.ru/talk/showthread.php?s=&threadid=69253
(действующие лица - те же
)а вообще - это было очень давно, "в другой жизни"...
Это не ООП, это фееричный писдец. С какого фига обьект будет в ООП менятся а в процедурном нет? И самое главное - что все молчат, никто этого не видет. Это что предвзятое отношение к ООП?
fisher
Вот ты сам себе противоречишь, человек всегда скотски ленив, а еще скотски ТУП. В большом проекте чаще всего есть программисты вот такие что ты пишешь, лишь бы сделать, так вот еще один плюс ООП это ограничить его тупую фантазию жестким интерфейсом, чтоб максиматьно что он принес в систему негативного это типа того что написал AmdY c коунтом. И отрефакторить придется только за ним внутрнений код класса, а не архитектуру, как элементарно может случится в процедурном. У меня брат работает в крупной гамедевной немецкой фирме ведущим программистом над MMOG игрой, не думаю что надо говорить что все наши творения нервно курят в сторонке по сравнению с такой системой, так вот - дураков и там хватает, и именно заданный интерфейс и жсткое описание его позволяет хоть как-то писать и развиватся, а потом уже он садится и перелапачивает код написанный ими.
Пиши на ассемблере, что ты уводишь разговор в заведомо тупикое и даже не кем не рассматривуемую область?
john.brown
просто кулибин
HraKK
Разговор заведомо тупиковый с самого начала. Хоть топикстартер и прикидывался, что он якобы хочет чего то (правда, непонятно, что) выяснить "до начала флейма", по сути он как раз флейм и начал.
Спор, блин, тупоконечников с остроконечниками...
Разговор заведомо тупиковый с самого начала. Хоть топикстартер и прикидывался, что он якобы хочет чего то (правда, непонятно, что) выяснить "до начала флейма", по сути он как раз флейм и начал.
Спор, блин, тупоконечников с остроконечниками...
- Статус