Здравствуйте, BulatZiganshin, Вы писали:
BZ>интересная мысль. что если ясность можно измерить кол-вом концепций, которые человек должен помнить одномоментно?
Интересный вопрос. К сожалению, чем сожнее задача, тем более выскоуровневыми концепциями нужно оперировать чтьбы описать или понять задачу. Но всему есть предел и иногда количество концепция растет просто в силу сложности задач. Хотя возможно это есть недостаток инструмента и/или проектировщика.
Но однозначно, что чем меньшим объемом надо владеть, тем лучше. Но как говорил, Энштеин — ... но не меньше.
BZ>тогда получится, что функциональный подход выигрывает потому, что вместо нескольких переменных, описывающих обработку, можно ввести одну функцию, которая её осуществляет, к примеру вместо x*a+b ввести функцию f = (+b).(*a) и дальше думать только об "f x"
Это заблуждение. ФП иногда дает хорошие результаты, а иногда не очень. Иногда ООП позволяет описать концепции на очень высоком уровне и тем самым уменьшить количество сущностей которыми надо оперировать.
Мое мнение заключается в том, что ФП, ООП, МП (метапрограммирование), и ЛП (логическое программирование) — это сопособы решения задач которые лучше или хуже подходят в тех или иных случаях. А раз так, то хорошо бы иметь возможность применять их все в рамках одного языка. Да это резко увеличивает набор базовых концепций которыми надо владеть программисту, но это же одновременно позволяет ему выбрать лучшую абстракцию в конкретном случае и уменьшимть то самое количество сущностей в конретной задаче.
BZ>ООП подход выигрывает потому, что вместо набора отдельных процедур, которые осуществоляют обработку данных независимо друг от друга, мы имеем дело с более общей единицей — объектом, и думаём о его поведении в целом
+1
BZ>"обработка волной" в стиле unix и функциональных языков выигрывает потому, что мы каждый раз думаем только об одном промежуточном результате обработки, а не пытаемся рассматривать её глобально целиком. скажем, идиому "sort|uniq|sort" понять куда проще, чем императивную программу, выполняющую все эти действия за раз. юникс ведь потому и стал популярен, что позволил решать задачи обработки текста без создания сложных программ на С
Когда как. Опять же sort|uniq|sort можно записать как sort.()uniq.()sort.() и это будет просто применением процедурного подхода в ООП.
В общем, главное абстракция, а не то где или какими способами она достигается.
Кстати, мой опыт подсказывает мне, что ФП лучше подходит для реализации алгоритмов, а ООП для декомпозиции на уровне прилоежений. Причем объекты могут использоваться в функциональных вычислениях, и наоборот функциональные вычисления могут использоваться для реализации методов объектов. В общем, они взаимодополняют друг-друга, а никак не противоречат друг другу. Просто проблема С++ (C#, Java и т.п.) в том, что эти языки (и их поклонники) обделены фукнциональными средствами (кстати в C# ситуация меняется к лучшему). И проблема Хаскеля (МЛ, Миринды...) в том что эти языки обделены полноценным императивноым программированием и ООП-ом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Короче, прекратим этот спор, т.к. я сомневаюсь что это прокатит в указанных мной случаях. Ты же не имея опыта работы с движками тоже не можешь утверждать. Но все таки я склоняюсь к мнению Cyberaxe здесь
Я имею опыт написания быстрых программ на разных языках. В отличии от вас с Cyberax-ом.
Спор же действительно бессысленнен, так с верой спорить нельзя. А ваша вера в С++ носит чисто реалигиозный характер.
DC>Я не намерен дальше продолжать этот спор. В итоге хочу сказать, что не смотря на все преимущества (более мощную поддержку метапрограммирования) С++ все равно остается неплохим инструментом и не фиг его хаять.
Здравствуйте, BulatZiganshin, Вы писали:
VD>>А зачем интерпретирвемый?
BZ>а зачем мне компилировать шелловские скрипты? скажем, у меня тестирование архиваторов таким скриптом управляется
Вообще-то речь шла о "скриптах" для игр. Они точно ничего похожего со скриптами исполняющимися один раз в сто лет не имеют.
VD>>У ОКамла проблемы с черезмерной строгостью и статиченостью
BZ>в хаскеле это становится проблемой только при динамичсеколй передаче управлени (exceptions) и наверно ещё при динамичсекой подгрузке кода.
Это и есть главная их проблема. Но у ОКамла они еще более явные. Там просто приведение типов или передача ссылок уже проблема.
BZ> в остальном строгость означает только что компилятор сам выведет все типы или скажет, что это совершенно невозможно. у меня было такое, когда я параметром функции ухитрился задать саму эту функцию, и компилятор сказал, что тип входит бесконечным
Ага. Но современный софт не мыслим без динамики. Лично я не буду использовать язык не позволяющий мне создать плагин или исползовать дизайнер форм.
VD>>Компонентность он поддерживает хуже чем С++.
BZ>почему это? в нём даже функторы есть, говорят мощнейшая штука
Фанкторы из другой оперы. Из оперы компонентности CreaeceInstance(строковоеИмяТипа) и приведение типов, скажем к интерфейсам.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, cl-user, Вы писали:
CU>Хм, а на этом "убийце скриптов" можно не перезапускать основную программу после изменения отдельного маленького компонента, а просто указать, что если "скриптик" Х изменился после последней его загрузки — загрузить его заново?
Можно.
CU> И что для этого понадобится включить в эту программу — весь framework языка или маленькую dll-ку интерпретатора?
Можно маленький фрэймвор языка, а не большую длл-ку интерпретатора.
В общем, не надо демагогии. Игры занимают целые ДВД. Многие из них ставят дотент просто ради мелких утилит (вспоминаем хафлайф). Никаких проблем включить в его состав 20 метров рантайма (да хоть сто) нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eugene0, Вы писали:
E>Самообразование — это правильно. Вот только дочитаю вон тот томик по теории алгоритмов, и непременно возьмусь за Немерле. Или за Хаскель. Или еще за что-нибудь
Ясно. С этого надо было и начинать. А то я то его дочитал еще 7 лет назад. И вот пристаю к занятым людям.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>>У ОКамла проблемы с черезмерной строгостью и статиченостью
BZ>>в хаскеле это становится проблемой только при динамичсеколй передаче управлени (exceptions) и наверно ещё при динамичсекой подгрузке кода.
VD>Это и есть главная их проблема. Но у ОКамла они еще более явные. Там просто приведение типов или передача ссылок уже проблема.
ну если динамическая типизация в обработчиках прерываний — главная проблема языка, то он вообще идеален
VD>Ага. Но современный софт не мыслим без динамики. Лично я не буду использовать язык не позволяющий мне создать плагин или исползовать дизайнер форм.
hsplugin есть, есть даже ghc-as-a-library. как это устроено — я не в курсе
при этом они ленивы, но поблочно — каждый блок в 4к символов вычисляется отдельно. так что получается дёшево и сердито плюс они обещают loop fusion, т.е. развёртывание операций типа тех, что я написал, в эффективный императивный код, но я не уверен, что это уже реально работает
BZ>>интересная мысль. что если ясность можно измерить кол-вом концепций, которые человек должен помнить одномоментно?
VD>Интересный вопрос. К сожалению, чем сожнее задача, тем более выскоуровневыми концепциями нужно оперировать чтьбы описать или понять задачу. Но всему есть предел и иногда количество концепция растет просто в силу сложности задач. Хотя возможно это есть недостаток инструмента и/или проектировщика.
ключевое слово здесмь — одномоментно. к примеру, почему советуют разьбивать функции на меньшие? общее кол-во концепций от этого не умеьшится, но в каждой подфункции их остаётся меньше. я специально брал функции с многими обрабатываемыми данными, разюбивал их на части, которым приходилось передавать много аргументов, и программа от этого становилась понятней
ну а дальше в дело вступает системный подход — т.е. ты аккуратно дробишь на каждом уровне концепцию на 7+-2 подконцепций
VD>Это заблуждение. ФП иногда дает хорошие результаты, а иногда не очень. Иногда ООП позволяет описать концепции на очень высоком уровне и тем самым уменьшить количество сущностей которыми надо оперировать.
VD>Кстати, мой опыт подсказывает мне, что ФП лучше подходит для реализации алгоритмов, а ООП для декомпозиции на уровне прилоежений.
ну тогда получается ООД+ФП, верно? надо срочно писать книгу о паттернах ООД+ФП, пока другие место не застолюбили
BZ>>я например вполне поддерживаю Влада в том, что Немерле быстрее хаскела, и в свою очередь языки с нативной компиляцией вероятно быстрее байткодовых
VD>Вобще-то Хаскель как раз компилируется в нэйтив-код. Я ошибаюсь? VD>Байтод же дотнета никогда не исполняется в режиме интерпретации. Он всегда компилируется. VD>Так что если разница есть, то она определяется не байткодом, а другими вещами.
ghc компилируется в натив, однако ленивые вычисления и ужаснейший кодогенератор не дают ему сколь-либо развернуться. а вот если взять ocaml (и даже clean с императивным кодом), то они близки к gcc. что касается байт-кода, то во-первых трудно противостоять таким монстрам, как gcc/icl, а уж тем более трудно это сделать, когда компиляция идёт через промежуточный этап, на котором теряется большая часть семантической информации. далее — языки типа c#/немерле/явы имеют более высокоуровневую модель, которая закономерно выливается в более медленный код. ну к примеру, данные всегда boxed. если же использовать unmanaged расширения этих языков, то никакого выигрыша в лёгкости программирования ты не получаешь
BZ>>вопрос "если наш язык так крут, почему же его никто не использует?" в сообществах small языков возникают куда чаще, чем здесь есть даже статья об этом профессора Вадлера, одного из авторов Haskell и generic Java. если кратко, то дело (помимо объективных свойств самого языка) в *инфораструктуре*: библиотеках, средствах разработки, книгах, обучении и в конечном счёте подготовленных специалистах
VD>Все это действительно влияет на популярность языка. Но разные Вадлеры, на мой взгляд, очень глубого заблуждаютя если считают эти факторы определяющими. Намного важнее интуитивность, привычность и применимость на практике. Так вот языки типа Хаскеля неинтуитивны, непривычны и очень плохохо применимы на практике. А перечисленное тобой — это всего лишь объяснение того почему они не применимы на парктике. Но неинтуитивность и непонятность куда важнее. Но тут уже Валдеры становятся Блаб-ами. Они смотрят на других со своей точки зрения и не хотят принять в рассчет точку зрения других.
VD>С обучением вообще "труба". Все что я пробовал читать по ФП никода не годится. Это писанина сумашедших ученых погрязщих в теоритическом булшите. Их труды скорее способны отбить желание изучать предмет.
VD>Тут нужна литература столь же доступная как труд Кхернигана. Уверен, что успех С во многом определяется его книгой.
мне нечего добавить, кроме того, что "Вадлеров" (это вообще-то самый известный человек в FP) ты обидел незаслуженно я (и не один я, конечно) пишу потихоньку статьи, объясняющие тонкости хаскела, которые я сам успел понять и вообще, весь сайт haskell.org (а он сплощь wikified) — это набор таких статей. сейчас многие мечтают о двух книгах — "advanced haskell" и "haskell in real world" (да, и ещё haskell cookbook), но пока что реальных подвижек в эту сторону не видно. ну а для начинающих литературы достаточно, им не обязательно читать научные статьи. загляни на http://www.haskell.org/haskellwiki/Learning_Haskell
BZ>>людей, способных изучить и эффективно применять какой-нибудь язык, для которого нет хорошо накатанных паттернов, тем более для которого нет отладчиков, библиотек и т.д. -
VD>Вопрос отладчиков, библиотек и IDE очень важен. И его надо решать. Это один из фаторо останавливающих программистов в изучении и применении новых языков. После Дельфи, ИДЕИ и VS 2005 мало кто захочет писать код в нотпэдах или даже в Вимах и Емаксах.
кстати, хорошо что напомнил. Visual Haskell (надстройка над VS) есть. она использует для компиляции ghc, т.е. интеграции во фреймворк нет. но по крайней мере intellisense работает. интерактивный отладчик в ghci уже появился, может через год-два он будет и в VH представлен
кстати, если здесь есть студенты — в google SoC на хаскеле можно заработать также, как и на других языках/проектах
BZ>>меня как-то на C# приглашали только потому, что я хаскел знаю. в history of haskell самая понравившшаяся мне фраза — представителя одной из коммереских фирм: "мы обнаружили, что поиск специалистов по хаскелу — это просто способ найти наиболее грамотных и талантливых программистов".
VD>Не потому ли это, что читая введение в Хаскель ближе к середине уши заворачиваются в трубочку, а голова становится деревянной?
VD>Другими словами не кажется ли тебе, что такой способ выявления "широколобых" является отличной демонстрацией отрицательных черт языка?
разумеется вообще, я бы с удовольствием сам написал введение в хаскел, но не потяну по времени но и в тех книгах, которые есть, за исключением попыток мимоходом объяснить сложные концепции, типа cps и монад, ничего сложного нету. почитай yaht или gentle
Удивительное дело — написал кучу текста, в котором 0 слов относится к предмету разговора. Знаешь как это называется? Врочем, этого и следовало ожидать.
... << RSDN@Home 1.2.0 alpha rev. 673 on Windows Vista 6.0.6000.0>>
Здравствуйте, eao197, Вы писали:
E> Даже переход от процедурного к объектно-ориентированному стилю не требует такого сдвига в способе мышления.
Следует отменить, что переход ООП -> ФП у некоторых индивидов способен
спровоцировать легкий (обратимый) сдвиг по фазе.
а). Отмечаются навязчивые состояния с хаотичными всплесками агрессии.
б). Существенно возрастает мания величия. Индивиду кажется, что он наконец
"прозрел" и очень близко подобрался к "истине".
Раньше такой эффект можно было наблюдать столкнувшись
с индивидом находящимся в процессе изучении LISP, Forth ...
Теперь это сплошь и рядом, особенно после появления Nemerle
(как ни крути, ФП его корневая парадигма).
Здравствуйте, Alexmoon, Вы писали:
A>1. Если он мне нужен для перемещения по памяти занимаемой объектом с более глобальной областью видимости, то о каком освобождении идет речь. Ежели я выделяю под него память и при этом я не имею 100% уверенности что после выделения, до достижения точки присвоения не возникнет исключения, я ставлю перехватчик обязательно в области видимости указателя и как минимум ставлю фильтр на выброс всех описанных спецификацией исключений, алгоритмами выделения. И в зависимости от того где было перехвачено исключение я делаю соответствующие выводы. Все остальное — ошибка программиста, may be. Мог конечно что то и упустить при беглом описании. Не статья, чтобы над ней работать, но суть реализации такова. Я думаю всегда, даже когда знаю что делаю. Это помогает мне не напрягаться отсутствием элементарного внимания в некоторых случаях.
А я в таких случаях использую умные указатели с разрушающим копированием. Типа std::auto_ptr.
Те я просто выделяю память и передаю ее на сохранение такому смартпоинтеру. При помещение в контейнер или возврате из функции владение просто передается. А если будет исключение или что-то другое то память будет освобождена.
ИМХО это гораздо лучше чем постоянно следить за исключениями которые могут появится при будущих рефакторингах.
Обработчики исключений я ставлю только там где могу эти исключения обработать, а не там где выделяю ресурсы. Ибо с ресурсами и смартпоинтеры прекрасно справятся.
Спецификации исключений не использую вобще. Ибо толку никакого, а под ногами путуются.
И вобще если что-то может сделать компилятор то это должен делать компилятор.
Ибо мне нужно задачу решать, а не обработчики исключений для освобождения памяти прописывать.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
D>Следует отменить, что переход ООП -> ФП у некоторых индивидов способен D>спровоцировать легкий (обратимый) сдвиг по фазе. D>а). Отмечаются навязчивые состояния с хаотичными всплесками агрессии. D>б). Существенно возрастает мания величия. Индивиду кажется, что он наконец D>"прозрел" и очень близко подобрался к "истине".
... и тут он кричит "эврика!" и голым выбегает на улицу. способностью делать открытия человек и отличается от животных, isn't?
Здравствуйте, BulatZiganshin, Вы писали:
D>>Следует отменить, что переход ООП -> ФП у некоторых индивидов способен D>>спровоцировать легкий (обратимый) сдвиг по фазе. D>>а). Отмечаются навязчивые состояния с хаотичными всплесками агрессии. D>>б). Существенно возрастает мания величия. Индивиду кажется, что он наконец D>>"прозрел" и очень близко подобрался к "истине".
BZ>... и тут он кричит "эврика!" и голым выбегает на улицу. способностью делать открытия человек и отличается от животных, isn't?
Здравствуйте, Denis2005, Вы писали:
D>Здравствуйте, BulatZiganshin, Вы писали:
D>>>Следует отменить, что переход ООП -> ФП у некоторых индивидов способен D>>>спровоцировать легкий (обратимый) сдвиг по фазе. D>>>а). Отмечаются навязчивые состояния с хаотичными всплесками агрессии. D>>>б). Существенно возрастает мания величия. Индивиду кажется, что он наконец D>>>"прозрел" и очень близко подобрался к "истине".
BZ>>... и тут он кричит "эврика!" и голым выбегает на улицу. способностью делать открытия человек и отличается от животных, isn't?
D>Вы заметили в моем сообщении выделенное слово?
а вы не задумывались, что всё что вы знаете, когда-то было открыто такими "некоторыми" индивидами?
Здравствуйте, BulatZiganshin, Вы писали:
D>>Вы заметили в моем сообщении выделенное слово?
BZ>а вы не задумывались, что всё что вы знаете, когда-то было открыто такими "некоторыми" индивидами?
Это не столь частый случай (оставим историю в покое).
У многих людей процесс познавания чего-то нового протекает спокойно и естественно.
Например, когда я изучал (открывал для себя) ФП посредством языка LISP
(хотя через этот язык я еще много чего познал помимо ФП), то не занимался
его агитацией на каждом углу и регулярными постингами на форумах формата A4,
которые по своей сути содержат смысловую нагрузку не более чем “ФП — это реально круто!”.
BZ>>а вы не задумывались, что всё что вы знаете, когда-то было открыто такими "некоторыми" индивидами?
D>Это не столь частый случай (оставим историю в покое). D>У многих людей процесс познавания чего-то нового протекает спокойно и естественно.
я это привёл для того, чтобы вы *поняли* состояние Влада. ведь понять — значит простить
Здравствуйте, VladD2, Вы писали:
VD>Такие языки как C# или Nemerle с такой задачей справятся великолпно.
Если в своп глубокий не уйдут
VD>Да что там они. Вот погляди: VD>http://www.haskell.org/haskellwiki/Frag VD>это Ку3 написанный на Хаскеле!
VD>А Хаскель — это очень медленно. Кто тебе это сказал?
То есть конечно помедленее чем C++ раза в 2-3, но в целом нормально (лучше чем любой скрипт).
DC>>MC там представлен я не сомневаюсь, только MC не производитель движков.
VD>Да? А кто по твоему MS Flight Simulator делает? VD>А Эдж Оф Эмпаир под чьим крылом? К тому же они делают главную штуковину DirectX, XNA и драверы для видео. Так что они точно знают что нужно разработчикам игр.
Они точно знают что нужно им для того чтобы побольше заработать на разработчиках игр .
P.S. Меня уже давно раздражает что MS пытается быть всем для всех (и ОС, и игры, и офис, и ERP, и КПК, и средства разработки). Куда антимонопольный комитет США смотрит ?
VD>>А Хаскель — это очень медленно. АХ> Кто тебе это сказал?
АХ>Haskell vs C++ АХ>Haskell vs Java
АХ>То есть конечно помедленее чем C++ раза в 2-3, но в целом нормально (лучше чем любой скрипт).
бывает ложь маленькая, ложь большая и бенчмарки
первое — большая часть этих тестов порверяет скорость библиотек, а не генерируемого кода. и при этом стоит ограничение — использовать можно только бибилиотеки, идущие в комплекте с компилятором. BOOST например с gcc не идёт, так что сравниваем мы ежа с ужом
второе — среди этих тестов есть всё же 2-3, проверяющих кодогенерацию. но если посмотреть на реализацию этих задач на хаскеле, то можно увидеть, что они используют императивный никзоуровневый подход, а не ленивые вычисления. или ещё лучше — в библиотеку ghc внесены функции, которые необходимы только для этих тестов. вот более реальные данные:
правда, из них тоже не надо делать вывод, что всё ровно в 700 раз медленней. по моему опыту, на прикладнине можно рассчитывать на падение скорости в 3-10 раз, за счёт того, что используются сишные бибилиотеки, сишные OS calls, и при желании критичную часть кода можно переписать в императивном стиле или на С
ps: и даже тесты, проверяюбщие кодогенерацию, сделаны дубово, поскольку многие из них ограничены скоростью работы памяти! что за бардак...
АХ>P.S. Меня уже давно раздражает что MS пытается быть всем для всех (и ОС, и игры, и офис, и ERP, и КПК, и средства разработки). Куда антимонопольный комитет США смотрит ?
меня лчино это не раздражает, но экономику жалко. монополизм MS имхо тормозит развитие отрасли. например, главная причина выпуска NET, на мой взгляд — стремление привязать разработчиков к одной платформе и отучить их писать переносимый софт, что уже было начало получаться с явой. если бы существовала реальная конкуренция, то уже давно появились бы две-три фирмы с нормальными IDE под яву. а в нынешней ситуации их делать смысла нет
но и в тех книгах, которые есть, за исключением попыток мимоходом объяснить сложные концепции, типа cps и монад, ничего сложного нету. почитай yaht или gentle
Кто тебе это сказал?
?