Здравствуйте, DarkGray, Вы писали: DG>зачем ты хочешь разделить менеджмент и программирование? DG>получить упрощение задачи? а ты уверен, что при таком упрощении не потеряешь кучу всего важного?
Уверен. Менеджмент как дисциплина практически не зависит от области деятельности. Программирование как таковое тоже не зависит от того, каким именно способом выполняется менеджмент. DG>я утверждаю, что такое жесткое разделение на менеджмент и программирование выплескивает с водой ребенка, и если интересно могу показать это на многих примерах
Покажи.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали: DG>как тогда понимать твою фразу? DG>
DG> На всякий случай напомню, что контролировать нужно не всё, а выполнение того, что оговорено в контракте.
Так и понимать. Если в контракте оговорено "поставка исходных кодов, оформленных в соответствии со стандартами качества" — тогда можно и нужно контролировать исходники.
А если оговорено "поставка исполняемых файлов, инструкций и т.п. необходимых для выполнения пользовательских задач в соответствии с п.п. 2.1-2.187", то нужно контролировать выполнение пользовательских задач. При этом совершенно неважно, насколько детально там всё оговорено в пунктах 2.1 — 2.187. Детали соответствия решения задаче можно оговаривать дополнительно и даже устно. Но задним числом начинать докапываться до вещей типа "о-о, мы думали вы сделаете это на ведге, а вы сделали на ASP.NET", или "В этой задаче можно было применить MVC фреймворк, а вы не применили" — нельзя. Вам было всё равно, на чём мы напишем, когда подписывали контракт? Вот и хорошо — пусть будет всё равно и дальше.
Было не всё равно? Ну так надо было как-то сформулировать свои пожелания. А если вам хотелось на ходу вмешиваться в наш процесс — то надо было подписывать не fixed price, а time & material basis контракт. Потому что ваши капризы за наш счёт — это нечестно.
Подчеркну: речь не идёт о исчерпывающем описании деталей реализации в контракте. Речь идёт о том, что контракт описывает взаимные обязанности. Если в контракте не прописан дресс-код для исполнителей, то они имеют право одеваться как хотят. Точка.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
DG>есть еще два направления: DG>1. уменьшению кол-ва потенциальных ошибок (уменьшение мест где потенциально могут быть ошибки)
Каждая строка кода — это место, где потенциально может быть ошибка. Каждая лишняя декларация — это место, где потенциально может быть ошибка. Все эти DRY, YAGNI, KISS — именно об этом: меньше строк — меньше мест для ошибок. DG>2. увеличение скорости разработки
Каждая строка кода — это текст, который надо написать. Меньше строк — меньше работы.
Менеджмент контактирует с программированием исключительно по этим двум направлениям. DG>и уменьшение сложности часто идет рука об руку с этим направлениями, т.к. уменьшение сложности часто уменьшает кол-во потенциальных ошибок, и увеличивает скорость разработки.
Правильно. В итоге выясняется, что всё, что есть в программировании от менеджмента — это уменьшение сложности. И другие правила второго порядка малости — типа оформления кода так, чтобы его было удобнее читать.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
DG>явно, что на основание базовых знаний менеджмента (например, что важное, срочное и рисковое — должно идти в первую очередь) DG>программирование на этот вопрос вообще не отвечает.
Молодец какой. Сначало понамешал к программированию всяких левых активностей, а теперь наоборот сузил программирование до крайности.
Разберись уже к чему ты хочешь применять "огни" (учитывая, что это не огни менеджмента )
Здравствуйте, Sinclair, Вы писали:
S>Так и понимать. Если в контракте оговорено "поставка исходных кодов, оформленных в соответствии со стандартами качества" — тогда можно и нужно контролировать исходники.
Если заказчику все же захотелось контролировать исходники, то ему нужны критерии качества по которым будет оцениваться код. Вот о этих критериях качества и идет речь в данном топике. В принципе заказчика можно заменить и на начальника отдела разработки, он надеюсь должен контролировать качество кода своих подчиненных или это ему тоже совершенно не нужно? Суть задачи, т.е. необходимость выработки формализованных критериев оценки качества кода, от этого не изменится.
ps
Сразу оговорюсь, что предлагаемый DarkGray'ем способ оценки сложности кода как числа вариантов меня не устраивает, т.к. этот способ слишком сложен и схоластичен для реального применения.
S>Грубо говоря — да. А что, есть какая-то альтернатива?
есть, например, такой огонь: не вызывать из под lock-ов чужие методы
и совсем не вызывать из под lock-ов колбаки
вот такое правило — очень легко проверяется, в отличие от правила — что по любой трассе выполнения локи должны накладываться в одном и том же порядке.
S>Пойми, даже если конкретно этот код нарушает какие-то из огней, то не составит проблемы написать другой код — идеально соответствующий огням — и всё еще вызывающий дедлоки
можно, конечно.
можно и иголкой убить себя, вот только вероятность этого сильно падает, да, и больше шансов, что тот кто так сделал — сказочный долб..б...
можно опять же провести аналогию с ТБ.
ТБ старается уменьшить кол-во несчастных случаев (кол-во фатальных ошибок), для этого ставятся всякие защитные кожухи, делаются двойные проверки (например, между двумя поездами должно быть как минимум два светофора) и т.д.
соответственно, правило — не вызывать чужих методов из под локов — это такой же защитный кожух, да — это не серебрянная пуля, но оно сильно уменьшает кол-во ошибок связанных с lock-ами
S>Так и понимать. Если в контракте оговорено "поставка исходных кодов, оформленных в соответствии со стандартами качества" — тогда можно и нужно контролировать исходники. S>А если оговорено "поставка исполняемых файлов, инструкций и т.п. необходимых для выполнения пользовательских задач в соответствии с п.п. 2.1-2.187", то нужно контролировать выполнение пользовательских задач.
Повторю вопрос третий раз: откуда взялся данный контракт? был дарован господом богом?
т.е. почему тобой априори считается, что это правильный контракт и в нем написано должно быть именно это?
т.е. заказчик и разработчик когда подписывали этот контракт они думали что они хотят? или не думали?
если думали, то о чем?
я утверждаю, что заказчик и разработчик обязаны был думати именно о тех вещах, которые были зафиксированы в модели
ответственность Заказчика:
1. выбрать Разработчика
2. поставить задачу
3. оплатить работу
4. проконтролировать выполнение
5. воспользоваться результатом
ответственность Разработчика
1. разработать продукт
S> При этом совершенно неважно, насколько детально там всё оговорено в пунктах 2.1 — 2.187. Детали соответствия решения задаче можно оговаривать дополнительно и даже устно. Но задним числом начинать докапываться до вещей типа "о-о, мы думали вы сделаете это на ведге, а вы сделали на ASP.NET", или "В этой задаче можно было применить MVC фреймворк, а вы не применили" — нельзя. Вам было всё равно, на чём мы напишем, когда подписывали контракт? Вот и хорошо — пусть будет всё равно и дальше.
если контракт выполняется, то я с тобой согласен.
но если контракт не выполняется (опять же, например, кол-во ошибок не уменьшается) то стоит требовать подписание доп. соглашение, по которому большие возможности контроля переходят к заказчику.
VGn>Есть гипотеза, что Хомо Сапиенс сожрал неандертальцев (а не наоборот) именно потому, что имел преимущество в разделении труда.
говоря мантру "разделение труда — рулит, и что поэтому я не буду делать то, что мне не нравиться" — надо понимать, когда она действительно рулит, а когда — нет.
и соответственно понимать, когда можно привлечь другого, а когда стоит изучить и делать самому хотя бы в минимальном объеме.
для понимание того, что можно отдать другим, а что нельзя (Т.е. что при отдаче на сторону — принесет снижение издержок или наоборот увеличение издержек) можно проводить минимальный анализ по следующим пунктам:
1. задача профильная/непрофильная
2. задача стандартная/нестандартная
профильная — именно в этом заключается та работа за которую платят
стандартная — есть много участников которые хотят тоже самое, либо она одна и та же из-за дня в день
на сторону оптимально лишь отдавать непрофильные стандартные.
плохо отдаются на сторону нестандартные профильные/непрофильные
опасно отдавать профильные стандартные.
профильные стандартные нельзя отдавать потому что в итоге ты становишься лишним звеном, и заказчику удобнее напрямую обращаться к тому, кому отдавалась работа.
нестандартные задачи плохо отдаются на сторону — потому что много времени уходит на передачу информации/понимания и т.д. другой стороне
соответственно, например, оценка сроков, рисков, требуемых ресурсов, составление плана работ по тому модулю, который непосредственно делает программист, оптимальнее делается самим программистом (если он, конечно, программист, а не кодер).
т.к. задача отчасти профильная (программисту платят именно за то, чтобы он разработал код при заданных ограничениях), нестандартная (код очень разный от задачи к задаче — если это именно программист), требует большого передачи информации (программист должен полностью рассказать, что и как он собирается делать, все подводные камни которые он видит и т.д.)
из этого получается, что программиста оптимальнее обучить минимальным основам менеджмента, чем пытаться на каждого программиста поставить по менеджеру, который за программиста будет оценивать бюджет, риски и т.д.
Здравствуйте, DarkGray, Вы писали: DG>Повторю вопрос третий раз: откуда взялся данный контракт? был дарован господом богом?
Этот вопрос выходит за рамки дисциплины "программирование". Я в очередной раз намекаю, что есть такая дисциплина, "менеджмент". Там про всё это и многое другое и
DG>т.е. почему тобой априори считается, что это правильный контракт и в нем написано должно быть именно это?
Потому, что обе стороны подписали контракт.
DG>т.е. заказчик и разработчик когда подписывали этот контракт они думали что они хотят? или не думали? DG>если думали, то о чем?
Какая разница, о чём они думали? Ты теперь еще и в психологию бизнеса собрался полезть что ли? DG>если контракт выполняется, то я с тобой согласен. DG>но если контракт не выполняется (опять же, например, кол-во ошибок не уменьшается) то стоит требовать подписание доп. соглашение, по которому большие возможности контроля переходят к заказчику.
Опять двадцать пять. Если контракт не выполняется, то программистские мантры ничему не помогут. Есть отдельная наука про выполнение контрактов и контроль выполнения контрактов. Её постулаты никак не зависят от того, что это за контракт — на поставку окорочков или на разработку веб-поисковика.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
VGn>Молодец какой. Сначало понамешал к программированию всяких левых активностей, а теперь наоборот сузил программирование до крайности. VGn>Разберись уже к чему ты хочешь применять "огни" (учитывая, что это не огни менеджмента )
когда меня учили системного подходу то там говорилось анализа не бывает без синтеза, синтеза не бывает без анализа.
задача анализа — выделить минимальные независимые кубики
задачи синтеза — собрать эти кубики обратно, чтобы получить решение.
в первом посте, уже было синтезированное программирование — программирование с вкраплениями менеджмента, маркетинга, когнитивной психологии и т.д.
сейчас же мы проводим анализ из каких минимальных кубиков состоит то, что мы назвали программированием в самом начале.
или другими словами:
программирование (из первого поста) — это программирование, как деятельность программиста
программирование (из определения про перевод на язык машины) — это чистая деятельность без вкрапления других деятельностей
Здравствуйте, eao197, Вы писали:
K>>Это неверно. Современники оценивали "Выступление стрелковой роты и т.д" (так называемый "Ночной дозор") низко. Позже ее стали оценивать высоко. Теперь ее оценивают скорее низко. E>Так ведь оценивают же. В отличие о многих современников того же Рембрандта, которые просто канули в лету.
Ну да. Вы, конечно, скипнули мое замечание про канувшего в лету Баха, которого повторно открыли специалисты через 80 лет после смерти.
E>>>Он до сих пор считается выдающимся представителем голландской школы живописи. Его творчество до сих пор изучают, его картины используются при обучении современных художников. K>>Не до сих пор, а в настоящий момент. E>Который длится, как минимум, лет пятьдесят.
Не важно, сколько длится. Важно, что в творчестве Рембрандта Ван-Рейна нет ничего определяющего когда кто и как будет оценивать его творчество. Нет никаких гарантий, что через n лет оценка будет пересмотрена. Как она уже пересматривалась множество раз.
Произведение искусства вне контекста культуры не имеет никакой ценности и не производит никакого объективного эффекта. Эстетический эффект существует только в головах и, по большому счету, каждой конкретной головой и определяется. Ценность искусства исключительно субъективна. Программное обеспечение же может производить объективный, наблюдаемый эффект и по этой причине может обладать объективной ценностью.
E>>>Будет ли тоже самое происходить с "дерьмом художника" через 450-500 лет? Если да, значит вы правы. Если нет, значит неправильные направления в искусстве все же есть. K>>Почему вас так волнует дерьмо художника? E>Потому что это, на мой взгляд, опровержение вашего тезиса о том, что в искусстве нет неправильных путей.
Можете вы объяснить почему это именно так?
K>>И откуда взялись числа 450-500? E>Это приблизительный масштаб времени, на котором становится видно, является ли творчество Рембрандта искусством или нет.
Я не спрашивал что это. Я спрашивал откуда взялись эти числа.
K>>Я указываю на принципиальную разницу — суд времени над этим "произведением искусства" свершился в момент аварийного подрыва ракеты. Откладывать его на +бесконечность не пришлось. Пересмотр оценки не предвидится. E>Здесь нет принципиальной разницы. Различие только во временных масштабах.
Различие между детерминированным свойствами объекта интервалом и интервалом случайным и свойствами объекта не определяющимся принципиальны.
Суда времени для произведения искусства не существует. Есть только перекладывание ответсвенности за ответ на вопрос. Когда кто-то говорит, что время покажет в данном случае, он говорит фактически только то, что сам он оценивать не будет, а оценит какой-то еще не родившийся Вася. Вася, однако, не будь дураком, перекинет отвественность на еще не родившегося Петю.
Описание другого принципиального различия заключающегося в том, что переоценка картины возможна, а переоценка успешности запуска ракеты — нет, вы, естественно, также скипнули.
E>Когда выполнялась приемка ПО Ариан, это ПО объективно доказывало свою состоятельность на имеющихся приемных испытаниях. Прошло какое-то время и бах! Не прокатило.
Это не верно. Это ПО не создается для того, чтобы проходить тесты. Оно создается для запуска ракет. И объективно доказать свою способность управлять ракетой оно может только управляя ракетой.
E>С ошибкой 2000-го года похожая история, только время между приемкой и бабахом чуть побольше было.
Вам, видимо так нравится со мной дискутировать, что вы приводите доводы в ответ на сообщение, в котором уже содержатся контраргументы. Видимо для того, чтобы я их повторил.
E>В живописи временные отрезки еще больше. Но сама выбраковка, тем не менее, существует.
Почему больше? И что представляет из себя выбраковка в случае с живописью?
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, eao197, Вы писали:
K>>1) Техники передачи эмоций — это знание того, что человек определенным образом интерпретирует линии определенной кривизны — и такому можно каждого научить, даже аутиста, который интуитивно эмоции не воспринимает. E>Интересно. Как можно передать эмоцию, которую не воспринимаешь?
Я написал "интуитивно не воспринимает", а не "не воспринимает". Очевидно, что воспринимать можно не интуитивно.
K>>2) Некоторых индивитуальных способностей художника, которым, вообще говоря, никто не учит. E>В том-то и дело. Что выполнив одну и ту же композицию (нарисовав один и тот же портрет с одной и той же точки) два разных художника используют разные техники рисунка (или разные их сочетания). И получат два разных изображения с разным ритмом и настроением. Почему они поступили так, как поступили?
Потому, что художника учат своеобразному языку и культуре речи на этом языке. Чтобы он мог на этом языке выразить свой внутренний мир и свое субъективное восприятие внешнего мира.
Выпускник художественной школы в такой же степени художник, в какой выпускник общеобразовательной — писатель.
E>Два программиста, обладающих одинаковыми познаниями произведут декомпозицию и решение одной и той же задачи по разному, сделав акценты на разных аспектах системы. Почему они поступили так, как поступили?
Программисты не выражают свой внутренний мир в первую очередь — они отвечают на вызовы мира внешнего. И если акценты в случае искусства — это основное содержание и основной его эффект, то в случае программирования это эффект побочный. Программирование не равно искусству — они пересекаются, и пересечение, может, в принципе быть пустым, а может и не быть. Можно даже допустить, что программирование может включать в себя искусство, но искусство программирование включать не может — поэтому заявления о том, что программирование — это искусство я считаю неверными и даже вредными с практической точки зрения. То, для чего программирование собственно и существует находится за пределами пересечения с искусством.
E>На мой взгляд, дело здесь именно в умении, т.е. сочетании опыта, вкуса, знаний и каких-то других факторов (в том чисте и иррациональных).
Ну а какое отношение умение имеет к творчеству?
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
во-первых, я забыл еще третью важную вещь — это маркетинг
программирование — в чистом виде — это перекладывание того, что умеет человека на формализованный язык(на язык машины)
менеджмент — в чистом виде — решить проблемы в жестких рамках текущей реальности (сроки, ресурсы, ограничения среды и т.д.)
маркетинг — в чистом виде — выяснение того что действительно хочет заказчик(потенциальный заказчик) и за что он хочет заплатить деньги
соответственно при полном разделении труда получается три человека: маркетолог, менеджер и программист. деятельность соседей они не понимают, и не хотят понимать.
а дальше происходит стандартный сценарий:
заказчик -> маркетологу: хочу чтобы было пиу-пиу, вжжж, а потом как ба-бах
маркетолог -> заказчику: а вы хотите трехмерную космическую стрелялку на своем телефоне?
заказчик -> маркетологу: да
маркетолог -> менеджеру: тут заказчик хочет стрелялку
менеджер -> программисту: стрелялку сделаем?
программист -> менеджеру: конечно, одной левой
менеджер -> заказчику: ок, давайте подпишем контракт
в контракте фиксируется какая-то фигня типа: при взрыве должно быть сначала обязательно ба, а только потом бах.
программист матерясь 3 месяца пытается из имеющегося ба-ба-бах сделать ба-бах, в итоге что-то получается но как-то корявенько
заказчик смотря на результат — какой-то у вас хреновенький ба-бах получился, вот в соседской игрушке ба-ба-бах, как ба-ба-бах.
to Sinclair: ты согласен с тем, что вот так оно все и происходит, если программист и слышат не хочет о менеджменте и маркетинге?
или будет как-то по другому? если по другому, то как?
Здравствуйте, Klapaucius, Вы писали:
K>Не важно, сколько длится. Важно, что в творчестве Рембрандта Ван-Рейна нет ничего определяющего когда кто и как будет оценивать его творчество. Нет никаких гарантий, что через n лет оценка будет пересмотрена. Как она уже пересматривалась множество раз.
С долгоживущими программами происходит тоже самое. Поэтому я и упоминаю проблему 2000-го года в данном контексте.
E>>Потому что это, на мой взгляд, опровержение вашего тезиса о том, что в искусстве нет неправильных путей.
K>Можете вы объяснить почему это именно так?
Потому что, на мой взгляд, в произведении искусства должны сочетаться как выдающаяся идея, так и исполнительское мастерство автора. В данном случае присутствует только идея, актуальная только на текущем временном этапе. Поэтому данное произведение, опять же по-моему, не должно считаться произведением искусства. А то, что сейчас оно таковым считаеться -- это неправильно.
K>>>И откуда взялись числа 450-500? E>>Это приблизительный масштаб времени, на котором становится видно, является ли творчество Рембрандта искусством или нет.
K>Я не спрашивал что это. Я спрашивал откуда взялись эти числа.
Это я пытался на память угадать, на сколько от нас отстоит эпоха Возрождения.
K>Суда времени для произведения искусства не существует.
У меня прямо противоположное мнение на этот счет. Поскольку есть "произведение искусства" и есть то, что на данный момент считается таковым.
E>>В живописи временные отрезки еще больше. Но сама выбраковка, тем не менее, существует.
K>Почему больше? И что представляет из себя выбраковка в случае с живописью?
Например, картины в духе соцреализма и изображающие, скажем, пахарей или даже трактор на пашне, считались произведением советского искусства только на протяжении существования СССР. После исчезновения соответствующей идеологии и средств ее продвижения такие "творения" получают свою нормальную оценку -- ширпотреб. Ни идеи, ни воплощения.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, frogkiller, Вы писали:
K>>Лично я не против многих путей. Просто, когда вдруг при этом ни с того ни с сего поминают про искусство, у меня возникают опасения, что сторонник какого-то пути не может объяснить чем этот путь лучше других. F>Засада в том, что ты хочешь только логического объяснения.
Где я такое написал? Когда мы говорим о выборе пути для реализации чего-то объективно ценного, мне нужно проверяемое обоснование. Логика куда угодно завести может — меня это не увтраивает.
F>Ну не получится полностью разложить по полочкам то, что содержит в себе иррациональное.
Любая наука — инструмент отделения той иррациональности, которую подмешивает к опыту человек. С последующим разложением по полочкам. По вашему научный подход не работает, так? Каким образом в таком случае вы, например, публикуете здесь свои посты? С помощью магии?
F>Однако, ты же не станешь отрицать существование красоты только потому, что она не вписыватся в построенную тобой логическую модель мира?
Это вариация вопроса о том, перестал ли уже оппонент пить коньяк по утрам, да? "Логическую модель мира", которую я якобы построил, вы сами выдумали. И красоту с иррациональностью также вы отождествляете, в отличие от меня.
F>Я не знаю, как это объяснить, кроме как показать и сказать: смотри! Неужели у тебя никогда не возникали моменты, когда ты смотрел в код и видеел, что он просто красив?! — не важно, что он делал и для чего предназначался...
Я уже пытался донести до вас свою мысль примером с красотой сверхзвукового самолета, в котором нет вообще ничего иррационального. Разумеется, я видел красивый код, красивые уравнения и красивые диаграммы Фейнмана. Но все это просто концентрированная рациональность. Что иррационального в их красоте? Рациональной красоты больше, чем кажется. Иррациональная крастота — это "Цветы зла" Бодлера, например. В программировании ситуация весьма нетипичная.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>>>1) Техники передачи эмоций — это знание того, что человек определенным образом интерпретирует линии определенной кривизны — и такому можно каждого научить, даже аутиста, который интуитивно эмоции не воспринимает. E>>Интересно. Как можно передать эмоцию, которую не воспринимаешь?
K>Я написал "интуитивно не воспринимает", а не "не воспринимает". Очевидно, что воспринимать можно не интуитивно.
А это как? Сидит аутист перед натурщиком, а преподаватель ему объясняет -- вот это на самом деле у человека не оскал, а улыбка?
E>>Два программиста, обладающих одинаковыми познаниями произведут декомпозицию и решение одной и той же задачи по разному, сделав акценты на разных аспектах системы. Почему они поступили так, как поступили?
K>Можно даже допустить, что программирование может включать в себя искусство, но искусство программирование включать не может — поэтому заявления о том, что программирование — это искусство я считаю неверными и даже вредными с практической точки зрения.
Искусство, которое включает в себя программирование, -- это за гранью моего понимания. Простите.
"Искусство программирования" в ряду с такими понятиями, как "Военное искусство", "Искусство управления", "Кузнечное искусство", "Искусство штыкового боя" -- это я еще могу себе представить.
E>>На мой взгляд, дело здесь именно в умении, т.е. сочетании опыта, вкуса, знаний и каких-то других факторов (в том чисте и иррациональных).
K>Ну а какое отношение умение имеет к творчеству?
Здравствуйте, eao197, Вы писали:
E>С долгоживущими программами происходит тоже самое. Поэтому я и упоминаю проблему 2000-го года в данном контексте.
Ну вот, теперь первый ответ на это возражение уже двумя моими постами выше.
E>Потому что, на мой взгляд, в произведении искусства должны сочетаться как выдающаяся идея,
Согласен. Но оценка идеи зависит от конкретного человека больше, чем от самой идеи.
E>так и исполнительское мастерство автора.
Время съест это мастерство. Многие произведения искусства с нынешней точки зрения мастерством не отличаются.
E>В данном случае присутствует только идея, актуальная только на текущем временном этапе.
О. В какое время эта идея не была актуальна? Проблема этой идеи как раз в том, что она слишком уж актуальна и чертовски стара. Никакого свежего взгляда на мир в ней нет.
E>Поэтому данное произведение, опять же по-моему, не должно считаться произведением искусства. А то, что сейчас оно таковым считаеться -- это неправильно.
Я понял, что это ваше мнение. Но мнение это одно, а способ выбраковки — другое. Вы же понимаете, что использовать вас как эталон при выбраковке произведений искусства не очень хорошая идея?
K>>Я не спрашивал что это. Я спрашивал откуда взялись эти числа. E>Это я пытался на память угадать, на сколько от нас отстоит эпоха Возрождения.
Поэтому я и написал, что вы путаете суд истории с оценкой в настоящий момент. Живи вы в начале XIX века, сказали бы что нужно 250-300 лет, так?
K>>Суда времени для произведения искусства не существует. E>У меня прямо противоположное мнение на этот счет. Поскольку есть "произведение искусства" и есть то, что на данный момент считается таковым.
Это и называется мода, которую время от искусства якобы отделяет.
E>>>В живописи временные отрезки еще больше. Но сама выбраковка, тем не менее, существует.
K>>Почему больше? И что представляет из себя выбраковка в случае с живописью?
E>Например, картины в духе соцреализма и изображающие, скажем, пахарей или даже трактор на пашне, считались произведением советского искусства только на протяжении существования СССР. После исчезновения соответствующей идеологии и средств ее продвижения такие "творения" получают свою нормальную оценку --
Именно это я и написал. Ценность искусство имеет только в рамках культурного контекста. Вне нашего культурного контекста картины Рембрандта — это слои масляной краски и только. Просто контекст в котором работы Рембрандта имеют ценность шире и долговечнее. Но откуда следует вывод, что опираться на широкий и долговечный контекст лучше, чем на узкий и эфемерный — это просто разные области выражения.
E>ширпотреб.
И не какой это не ШИРпотреб. НЕт широкого потребления теперь. УЗпотреб в чистом виде.
E>Ни идеи, ни воплощения.
Ни то ни другое никуда не делось. Просто идея переоценена — так со всеми идеями происходит. А воплощение если было хорошим — оно им останется, пока не появятся лучшие техники воплощения. А если было плохим, то плохим и осталось.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, DarkGray, Вы писали: DG>to Sinclair: ты согласен с тем, что вот так оно все и происходит, если программист и слышат не хочет о менеджменте и маркетинге? DG>или будет как-то по другому? если по другому, то как?
Не согласен. Нет времени детально описывать, почему и как.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.