Далеко не всегда экономичность - главный параметр. Есть масса параметров. Грубо говоря, нужно вывести космический аппарат в определенную точку. Экономичность тут будет ну где-то в самом хвосте списка(да и то, только из-за ограничений наложенных аппаратными ресурсами, а не финансами), а во главе угла надежность. Расширяемость, поддержка и тд и тп, это все вообще даже рассматриваться не будет, не имеет смысла(обновлять софт на железке, которая находится вне пределов доступа человека - такое себе занятие). Или например информационная система, которая прогнозирует рост акций и делает ставки на бирже. Экономичность по ресурсам тут идет лесом, там ребята готовы на любые условия, хоть суперкомпьютер, лишь бы производительность этой системы была максимально возможной, бабки - тоже не проблема, они в любом случае отобьются. Но тут как раз такие параметры как расширяемость, поддержка и тд имеют довольно-таки большое значение, зачастую именно эти параметры рассматриваются как конкурентное преимущество(насколько быстро возможно допилить систему под меняющийся рынок). И вот тут всплывают миллиарды точек зрения на миллиарды задач.
Понимаю, какое множество факторов, а в зависимости от этого какое множество решений. Но если два программиста ставят во главу угла один и тот же фактор, то тоже задачу по-разному решат?
Вполне вероятно, что по-разному. Далеко ходить не буду. У меня есть проекты с математикой. Так вот я, как сторонник "монолитных" решений решу ее скорее всего на своем языке(Java\C#), а например кто-то другой найдет специалиста по питухону и вынесет всю математику в питухон и будет дергать оттуда. Это так сказать из реальной практики пример. Да блин, одну и ту же задачу в рамках одного языка, одной архитектуры и одного стиля, можно решать миллионом способов. Есть определенные шаблоны, но реальная задача всегда сводится к их комбинации. На примере математики: есть, например, свойства сложения коммутативность a + b = b + a, ассоциативность a + (b + c) = (a + b) + c, дистрибутивность a * (b + c) = a*b + a*c, а есть их сочетания: z*d + a*x + b*y + c*y = (y*(b+c) + a*x) + z*d. Так вот и с задачами в программировании, реальная задача - всегда сочетание. Результат одинаков, решение разное.
питухон - это язык питон? Ну если еще и на другом языке задачу решать, ясно, что будут разночтения - с другой стороны, и спорить не о чем. "реальная задача - всегда сочетание. Результат одинаков, решение разное". Я правильно понимаю, что если программа работает, то опять спорить не о чем, и все споры, пока она не поддается? Нет, неправильно. Вы же говорили, это смотря, с точки зрения каких факторов оценивать
Или например информационная система, которая прогнозирует рост акций и делает ставки на бирже. Экономичность по ресурсам тут идет лесом, там ребята готовы на любые условия, хоть суперкомпьютер, лишь бы производительность этой системы была максимально возможной, бабки - тоже не проблема, они в любом случае отобьются. Но тут как раз такие параметры как расширяемость, поддержка и тд имеют довольно-таки большое значение, зачастую именно эти параметры рассматриваются как конкурентное преимущество(насколько быстро возможно допилить систему под меняющийся рынок).
И вот тут всплывают миллиарды точек зрения на миллиарды задач.
Reply
Reply
Да блин, одну и ту же задачу в рамках одного языка, одной архитектуры и одного стиля, можно решать миллионом способов. Есть определенные шаблоны, но реальная задача всегда сводится к их комбинации.
На примере математики: есть, например, свойства сложения коммутативность a + b = b + a, ассоциативность a + (b + c) = (a + b) + c, дистрибутивность a * (b + c) = a*b + a*c, а есть их сочетания: z*d + a*x + b*y + c*y = (y*(b+c) + a*x) + z*d. Так вот и с задачами в программировании, реальная задача - всегда сочетание. Результат одинаков, решение разное.
Reply
"реальная задача - всегда сочетание. Результат одинаков, решение разное".
Я правильно понимаю, что если программа работает, то опять спорить не о чем, и все споры, пока она не поддается? Нет, неправильно. Вы же говорили, это смотря, с точки зрения каких факторов оценивать
Reply
Reply
Leave a comment