I>Т.к. "серебряной пули" нет, также нет и "супер-пупер" языка)) И владение несколькими языками позволяет избавиться от привязанности к языку как таковому, а плясать уже от задачи и выбирать инструмент наиболее подходящий для нее.
Умение убеждать клиента (не) использовать платформу/ЯП приобретается отдельно
Здравствуйте, Wolverrum, Вы писали:
I>>Т.к. "серебряной пули" нет, также нет и "супер-пупер" языка)) И владение несколькими языками позволяет избавиться от привязанности к языку как таковому, а плясать уже от задачи и выбирать инструмент наиболее подходящий для нее. W>Умение убеждать клиента (не) использовать платформу/ЯП приобретается отдельно
Здравствуйте, Wolverrum, Вы писали:
I>>Т.к. "серебряной пули" нет, также нет и "супер-пупер" языка)) И владение несколькими языками позволяет избавиться от привязанности к языку как таковому, а плясать уже от задачи и выбирать инструмент наиболее подходящий для нее. W>Умение убеждать клиента (не) использовать платформу/ЯП приобретается отдельно
Здравствуйте, jazzer, Вы писали:
J>Ну что, у нас пятница сегодня...
J>Вы все знаете парадокс Блаба, он тут популярен
Мне кажется что отличия языков принципиальные только в парадигмах. Императивные, функциональные, логические и т.п.
Внутри парадигмы можно говорить только о синтаксических особенностях. Недостаток фич в рамках единой парадигмы можно всегда обойти. Потому страдающие блаба программизмом и верхоглядство говорит только об умственных способностях.
А вот заняться объединением парадигм и созданием универсального синтаксического стандарта можно и нужно заниматься. Тогда эти болезни роста пройдут как страшный сон.
Здравствуйте, batu, Вы писали:
B>Мне кажется что отличия языков принципиальные только в парадигмах. Императивные, функциональные, логические и т.п.
Парадигма слишком размытое понятие, Smalltalk и скажем Java в одной парадигме, но разница между ними не меньше чем если
взять языки из других парадигм.
B>Внутри парадигмы можно говорить только о синтаксических особенностях.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, batu, Вы писали:
B>>Мне кажется что отличия языков принципиальные только в парадигмах. Императивные, функциональные, логические и т.п.
FR>Парадигма слишком размытое понятие, Smalltalk и скажем Java в одной парадигме, но разница между ними не меньше чем если FR>взять языки из других парадигм.
B>>Внутри парадигмы можно говорить только о синтаксических особенностях.
FR>Тот же пример выше показывает что нет.
Можно еще С добавить. Не принципиальная разница. Задачи одного класса решаются практически одинаково. И по технике программирования и по эффективности. Внешне выглядит по разному. Так это и есть синтаксис, а не только какой значек что обозначает.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>а насчёт испытания душевных мук — свинья тоже не страдает оттого что живёт в грязи. просто иное состояние ей неведомо
О, так оказывается все программисты на c++ свиньи с плюсами!
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, jazzer, Вы писали:
J>И заключается в том, что программист, смотрящий на языки, в которых используется какая-то концепция, которой нет в его языке X, не понимает ценности этой концепции, пока не изучит язык Y, в котором эта фича реализована. После чего он без этой фичи уже жить не может и смотрит на свой прежний язык X в лучшем случае с недоумением, но чаще — с практически физическим отвращением.
Как сказать...
До поры до времени я не знал
нормально организованных циклов — их не было в Фортране-4. Писал их через GOTO.
структур и указателей — их там тоже не было. Обходился как мог.
ООП — за полным отсутствием вообще.
Фортран, конечно, с тех пор изменился, так что если бы мне пришлось к нему вернуться — это был бы уже Фортран-77 или Фортран-9x. Там все это (кроме ООП) есть.
Но сказать, что доведись мне вернуться к Фортрану-4, это вызывало бы физическое отвращение — да ничего подобного. Для расчетных задач он и сейчас неплох, и не надо мне там ООП и указателей не надо, и даже GOTO меня не так уж возмущает.
А потом были Паскаль и С. В них уже все это было, кроме ООП. И спустя 10 лет после того, как я освоился с классами и ООП, оказалось, что писать придется опять на чистом С. Поморщился, конечно, да, но и только. И писал на чистом С 4 года. Ну если быть честным, в некоем собственном "псевдоклассовом" стиле.
Так что от человека зависит.
J>Так вот обратный парадокс Блаба заключается в том, что, казалось бы, программист должен приобрести более широкий кругозор и начать смотреть на вещи шире и сбалансированнее, но вместо этого он становится нетерпимее и почему-то приобретает практически религиозную уверенность, что все, кто пишет не на Y (а особенно программисты на Х) испытывают невыносимые страдания, программируя на своих языках. По определению. Что во всех этих языках ничего хорошего нет и быть не может, а если и есть, то оно не стоит отсутствия в них Главной Фичи языка Y. Да, и все программисты не на Y записываются в Блаб-программисты.
Все очень просто.
/////////////////////
Подарили Вове
Новый барабан.
До чего ж красивый
Новый барабан!
«Ах, какой барабан!» — говорили.
Вот какой барабан подарили!
Знать не хочет Вова
Ни о чём другом:
Целый день в квартире
Не смолкает гром.
Ходит гром, ходит гром по квартире,
И гремит он подряд дня четыре.
Здравствуйте, batu, Вы писали:
FR>>Тот же пример выше показывает что нет. B>Можно еще С добавить. Не принципиальная разница. Задачи одного класса решаются практически одинаково. И по технике программирования и по эффективности. Внешне выглядит по разному. Так это и есть синтаксис, а не только какой значек что обозначает.
Можно и хаскель добавить, можно еще и синтаксис с семантикой путать.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, batu, Вы писали:
FR>>>Тот же пример выше показывает что нет. B>>Можно еще С добавить. Не принципиальная разница. Задачи одного класса решаются практически одинаково. И по технике программирования и по эффективности. Внешне выглядит по разному. Так это и есть синтаксис, а не только какой значек что обозначает.
FR>Можно и хаскель добавить, можно еще и синтаксис с семантикой путать.
Хаскель функциональный. Там другая техника программирования.
Здравствуйте, batu, Вы писали:
FR>>Можно и хаскель добавить, можно еще и синтаксис с семантикой путать. B>Хаскель функциональный. Там другая техника программирования.
Здравствуйте, Nuzhny, Вы писали:
N>Критика может вестись с целью... N>Разумеется, что такая классификация может быть проведена зачастую только постфактум, после наблюдения за развитием объекта после получения своей дозы критики.
Определить цель невозможно, можно только определить результат. Да и цель некого волновать не должна, потому как значение имеет результат, а не цель.
Т.е. "деструктиной" критиком можно все что угодно называть и требовать "конструктивной". Что, в общем-то и требовалось, потому как "конструктивная критика" придумана для того, чтобы затыкать другим рты, а себе — уши, под благовидным предлогом. Больше ни на что концепция "конструктивной критики" не годится.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
'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
Здравствуйте, Ikemefula, Вы писали:
I>Конструктивная критика — это пополнение информации об объекте критики.
Т.е. любая, кроме той, что пополняющий информацию уже слышал.
I>Т.е. написал ты, к примеру, функционал какой то и услышал отзывы коллег, например "удобно/неудобно"+"вот так лучше, хуже, можно, нельзя", "медленно/быстро"+"ускорить,замедлить можно вот так" и тд.
Вот это критика: >"удобно/неудобно", "медленно/быстро"
А вот это деятельность, которая к критике никакого отношения не имеет: >"вот так лучше, хуже, можно, нельзя", "ускорить,замедлить можно вот так"
Люди, которые хорошо находят проблемы и люди, которые хорошо находят решения — это люди, думающие, зачастую, по-разному. Первые сразу видят где сломается, а вторые придумают, как починить, если им кто-то подскажет, что проблема существует и укажут где она. Бывает, что люди умеют хорошо и то и другое, но бывает это крайне редко.
I>Неконструктивная, деструктивная критика этой особенностью не обладает. ... без указания/предложения путей решения.
Попробуйте такой подход, поощряющий "конструктиную" критику: принимайте багрепорты только вместе с исправляющим баг патчем, все прочие — игнорируйте, как неконструктивные. Оцените полезность такого подхода для проекта.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
'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>Здравствуйте, Ikemefula, Вы писали:
I>>Конструктивная критика — это пополнение информации об объекте критики.
K>Т.е. любая, кроме той, что пополняющий информацию уже слышал.
K>А вот это деятельность, которая к критике никакого отношения не имеет: >>"вот так лучше, хуже, можно, нельзя", "ускорить,замедлить можно вот так"
У тебя какая то уникальная трактовка слова критика.
K>Люди, которые хорошо находят проблемы и люди, которые хорошо находят решения — это люди, думающие, зачастую, по-разному. Первые сразу видят где сломается, а вторые придумают, как починить, если им кто-то подскажет, что проблема существует и укажут где она. Бывает, что люди умеют хорошо и то и другое, но бывает это крайне редко.
Если дворник предложит тебе вой вариант как баг пофиксить, то это вряд ли критика.
Я же контекст обозначил вполне конкретно, а ты это пропустил судя по всему.
I>>Неконструктивная, деструктивная критика этой особенностью не обладает. ... без указания/предложения путей решения.
K>Попробуйте такой подход, поощряющий "конструктиную" критику: принимайте багрепорты только вместе с исправляющим баг патчем, все прочие — игнорируйте, как неконструктивные. Оцените полезность такого подхода для проекта.
При чем здесь патч ?
Багрепорт обычно это указание проблемы + указание как должно быть.
Здравствуйте, Klapaucius, Вы писали:
K>Определить цель невозможно, можно только определить результат. Да и цель некого волновать не должна, потому как значение имеет результат, а не цель. K>Т.е. "деструктиной" критиком можно все что угодно называть и требовать "конструктивной". Что, в общем-то и требовалось, потому как "конструктивная критика" придумана для того, чтобы затыкать другим рты, а себе — уши, под благовидным предлогом. Больше ни на что концепция "конструктивной критики" не годится.
Ой, да ладно! Всё знают и используют понятие "конструктивная критика" по делу. Конечно, можно и для отмазок от работы его применять. Но отрицать его полезность — глупо.
Здравствуйте, Nuzhny, Вы писали:
N>Всё знают и используют понятие "конструктивная критика" по делу.
Т.е. для того, для чего оно и предназначено — для игнорирования критики. Потому что вся критика "недостаточно конструктивна".
N>Конечно, можно и для отмазок от работы его применять.
Будто бы можно применить для чего-то другого.
N>Но отрицать его полезность — глупо.
Переоценить его вред — невозможно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
'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