недопустимые формы ведения дискуссии, оскорбляющие (явно и неявно) участников форума, придерживающихся взглядов, отличных от Ваших.
Все мои "оскорбления" семантически сводятся к одному-единственному утверждению: для профессионального программиста инструмент сугубо вторичен, поскольку он руководствуется фундаментальными теоретическими знаниями, а не тупым ремесленым опытом в рамках одного узгкоограниченного взгляда на проблему. Профессионал от быдлокодера тем и отличается, что может менять языки как перчатки, выбирая наиболее адекватный задаче язык, и использовать его по назначению, т.к. его мышление не зажато в рамках возможностей некоторой единственной технологии. С этим утверждением будет спорить только полнейший недоумок, так что поимённый список недоумков из данной беседы выделить несложно.
Соответственно, "оскорбительно" мои слова могут звучать только для тех, к кому они применимы - а в этом случае, как следует из первого утверждения, человек не имеет права обижаться и сопротивляться - он обязан слушать и внимать, и быть благодарным за то, что ему открыли простор для развития. Если же он будет вслух возражать, то он таким образом будет препятствовать глобальному научному прогрессу - а именно за это и надо в первую очередь модерить.
Хотя по прежнему пишу по фортрановски (фортран давно забыл). ФП - оно в голове. Помогает правильней организовать код. Фактическое отсутствие образования - катострофа.
Ага, я несколько лет выбивал из головы последствия виндово-дельфёво/билдерового программирования (и сейчас ещё не уверен, что до конца от этой плесени избавился).
Основной тезис Postrelyonysh'а не "функциональное программирование полезно" (против этого никто никогда и не возражал) а "ТОЛЬКО функциональное программирование полезно".
Вы не поняли вообще ни хрена. Читайте топик сначала.
Остаётся только немого подождать, чтобы увидеть, как эта молодая шпана сметёт нас с лица земли
Именно этот процесс я и пытаюсь ускорить, только модераторы всегда мешают. А пользователи вынуждены мучаться, сопеть и молчать в тряпочку.
Любой анализ проектировщиком предметной области начинается вовсе не с действий, а с составления словаря и онтологии, т. е. как раз таки с описания объектов и их взаимосвязей. А действия -- это уже вторично.
У Васи была цель перейти из трезвого состояния в нетрезвое, а уж сгонял он для этого в магазин сам или послал жену -- это низкоуровневые детали реализации.
Вот-вот, как я и сказал - горбатого могила исправит - в голове алгольщика глаголам уже нет места.
Только если в новой версии будет решено вручить Васе мобильник, чтобы жена могла в любой момент позвонить ему и попросить заскочить по пути в продуктовый за молоком (и оказывается, что Вася вовсе и не алкоголик, а бежит за хорошим пивом для гостей) - то вся ваша любовно вылизанная ООПная архитектура дружно встанет раком и исходник во много десятков тысяч строк окажется просто ненужным набором символов. И естественной реакцией заказчика будет вас уволить и нанять других программистов, заплатив повторно за реализацию того же самого функционала другим способом. Я такого наелся уже, и знаю, о чём говорю.
Object-Oriented Design приводит к адекватным проектным решениям тогда и только тогда, когда предметная область хорошо проработана и редко меняется, и программисту просто негде ошибиться - на то эта методология и убога. Проблема же стереотипов состоит в том, что такие как вы изо всех сил формируют массовые заблуждения на счёт того, что вот эта хрень является следствием объективной сложности программирования - за это и ненавидим Algol style programming.
Ни методологически корректного анализа, ни логических выкладок не обнаружил.
Основой методологически корректного сравнения эффективности разных подходов, на мой взгляд, является анализ статистически значимой разницы в производительности, качестве, сопровождаемости и других характеристиках разработанного программного обеспечения. Вы где-то приводили такие данные?
Анализ я провёл до этого топика, а здесь просто излагал его результаты. Я указал на его полное отсутствие у других. Некоторые данные, так и быть:
1.
Производительность была важна до первой половины 90-х, а на 4-х ядрах всем на неё плевать. Но, раз уж так просите:
http://shootout.alioth.debian.org/debian/benchmark.phphttp://dada.perl.it/shootout/craps.htmlЗамечу, что это сравнение на мелких кодах, но языки разной степени высокоуровневости имеют разный порядок роста эффективности компиляции, т.к. абстракции более высокого уровня несут больше информации для оптимизации. Для большинства ФЯ трудно избежать оверхеда на рантайм, но такого, как у Java, всё равно ни у одной реализации нет.
2. Анализ разницы в
качестве полностью инкапсулирован в упоминании системологии и её приложений, таких как ТРИЗ. Но объяснять это на словах человеку, не умеющему мыслить системно, просто бесполезно. В то же время человек, которого с детства приучили мыслить системно, даже если ему первым языком подсунули какую-нибудь дрянь вроде Delphi,- и сам ещё на этапе изучения интуитивно почувствует, что что-то не так, и будет испытывать выраженную нехватку возможности осуществить метасистемный переход (что в терминах программирования означает переход к более высокому уровню абстракции, к другой семантике). И в последствии, расширив кругозор, такой человек легко поймёт, в чём (и насколько важна) разница между языками со встроенным в компилятор foreach (как С#) и языками, на которых можно легко реализовать foreach, используя только конструкции самого языка ("нормальными" языками).
3.
Сопровождаемость (она же модифицируемость) сравнена на примерах Yahoo! Stores и Opera. И не надо мерять качество количеством - это абсурд. С инженерной т.з. решающее значение имеет именно
потенциальная эффективность методологии проектирования - см.абзац выше про Васю. А вам, пока миллионы леммингов не признают эффективность, хоть кол на голове теши.
Моё определение успешности -- чисто утилитарное: успешный проект -- это проект, в котором удалось решить поставленную задачу в согласованные сроки в рамках согласованного бюджета при взаимной удовлетворённости сторон.
Ну, я и говорю - абы скомпилировать и продать.
Подход "день потерять, потом за пять минут долететь" на более-менее крупных задачах приводит к результату за ничуть не меньшее время, только уровень качества оказывается несопоставимо выше. А если включить сюда ещё и зависимость стоимости поддержки программ от качества их написания - то он ещё и экономически выгоднее.
Есть какая-нибудь статистика, подтверждающая подобные заявления? (Отдельные примеры успешного/провального использования того или иного подхода доказательством статистически значимой разницы не являются).
...
отказ от традиционного и привычного ООП в пользу ФП или другого альтернативного подхода, не поддерживаемого, к тому же, производителями использующихся базовых программных средств, в некотором роде граничит с авантюрой
хочу заметить, что программирование -- деятельность глубоко практическая, и для того чтобы утверждать о безусловном преимуществе (или о безусловной пагубности) какого-то одного подхода, нужны достоверные статистические данные, а не голословные заявления об "ограниченности знаний".
Если бы всё было безоблачно, то за это время ООП умерло бы, не успев родиться (просто не выдержало бы конкуренции).
...
У Вас лично есть опыт успешной разработки чего-нибудь большого?
Ну прямо классика: "
не фиг думать, надо трясти", "
миллионы леммингов не могут ошибаться" и, конечно же, "
лучше сделать говно, чем не сделать никак". Ограниченность - она если есть, то проявляется сразу во всём. Здесь же и самонадеянное "
я знаю Lisp, но проектировать лучше в ООП"; и фамильярное "
я не возражаю против других подходов" вскоре после яростных воплей "
ООП рулит, и кто этого не понимает, тот лох". Любой ценой защитить своё право на самолюбие, и не важно, заслуженно это право, или нет.
Это у Лиспа-то "научная новизна"? Ему ж 50 лет уже.
Вы всерьёз или прикидываетесь? Я говорил о новизне не какого-либо языка, а детального исследования влияния языка на образ мышления. Более древние языки (английский и русский) имеют такое же фундаментальное влияние, и неформально это давно было известно. Этим, например, исторически активно пользовались политики и религиозные деятели, модифицируя лексикон для управления общественным сознанием и стирания исторического наследия.
Попробую привести другую аллегорию. Представьте на полу мир двухмерных существ. Это пятна, для которых линии - это стены. Вы сверху можете смотреть на их мир и забавляться над тем, как они, чтобы сходить друг к другу в гости, вынуждены огибать линии, через которые вы просто перешагиваете. От вас они видят лишь след ботинок - такое же пятно, как сами. Представить и понять, какие новые степени свободы открывает третье измерение, для них столь же тяжело, как для вас представить и понять возможности, открываемые четвёртым. Примерно так же отличаются возможности ментальных операций для людей с разными "родными" языками. Чем совершеннее семантика языка, тем больше качественно новых степеней свободы ("мерности") имеет разум того, кто на нём мыслит (собственно, именно поэтому МакКарти не стал пытаться вести исследования в сфере ИИ на Фортране, а применил language-oriented design и создал Лисп). Так вот, для человека, которому проще и доступнее программирование на VB/C++/Delphi/Java/C#, а более мощные и умные языки являются "надстройкой" над этим,- пытаться понять, что такое "семантика более высокого уровня, чем ООП" и чем отличается "Lisp-программа" от "Delphi-программы" (не важно, на каком языке эта программа написана) - это примерно то же самое, что для двумерного существа пытаться понять, что такое "объём тела" и чем отличается "поверхность" от "плоскости". Разница же становится видна невооружённым глазом при изменениях в ТЗ - но только не тех изменениях, которые могут придумать себе сами программисты, а при изменениях, которые могут внести специалисты предметной области, имеющие слабое представление о сущности программирования.
