Ответ на »сообщение 2617« (Geniepro)
___________________________

Ответ на »сообщение 2613« (Илья Ермаков)
___________________________

Известно также, что качество кода, генерируемого компилятором Оберона, находится на уровне С, а в некоторых реализациях навроде XDS в то время, когда они развивались, превосходило все известные реализации С (да и сейчас обходит VC 7.0)...
Отсюда делайте сами вывод...

Извините, но с этим тоже можно поспорить.
...но превзойти программы на том же C# (компилятор которого не так уж и хорош) они так и не смогли... Думаю, компилятор VC 8.0 получше будет, чем С#, так что тут XDS скорее сего пролетел бы...

С чем поспорить? Что за привычка вообще спорить совсем не с тем, что утверждалось :-)
При чем тут C# и VC 8.0 - о том, что они превосходят XDS, много лет не развивающийся, я и сам знаю. Речь шла о современннике XDS. Даже не современнике - т.к. современник VC 6.0.

Ответ на »сообщение 2612« (Руслан Богатырев)
___________________________
Понимаю, что можно заниматься дизассемблированием и анализировать схему работы транслятора, но сомневаюсь, что этим озадачиваются даже грамотные ФП-программисты.
Грамотные программисты вообще себе голову этим забивать не будут.
Миллионы программистов используют Python, Ruby, ASP, PHP, Perl, JavaScript, VBScript. Каждый из этих языков НА ПОРЯДОК медленнее хаскеля, не говоря уже об Ocaml. И никому из этих программистов не приходит в голову заниматься дизассемблированием и анализировать схему работы транслятора.

Ваш вопрос из серии "жеского РВ" и бразильской АЭС. То есть вы выносите на сайт прикладников весьма узкоспецифичные проблемы, и требуете чтобы мы этими проблемами озадачились.
Да нам плевать на эти проблемы.
Лисп и Python достаточно быстры и вполне умещаются в рамки оперативки, чтобы я использовал их в решении своих повседневных задач. Так буду ли я мучаться вопросами эффективности хаскеля ?

Ответ на »сообщение 2605« (Geniepro)
___________________________

Ответ на »сообщение 2588« (RBV)
___________________________
Большое спасибо за интересную идею. Только ответьте, пожалуйста, на один вопрос.

Не за что. :) Хотите попробовать? :):):)


Вот Руслан Богатырёв уже несколько лет предлагает российскому сообществу блэкбоксёров...

Стратегический смысл?

Так вот, вопрос: Почему Вы думаете, что создание транслятора Оберона или хотя бы загрузчика его модулей может заинтересовать необеронщиков, если это неинтересно даже оберонщикам?
Евгений... Причем тут заинтересовать?! Была предложена чисто системная задача. Динамическая загрузка модулей. Всё.

Ответ на »сообщение 2604« (Руслан Богатырев)
___________________________
В отношении части B: на примере Хаскеля хорошо видно, что импорт IO не показывает точки использования импортируемых сущностей внутри исходного текста (типичная ситуация в случае т.н. неквалифицирующего импорта).


Как раз таки в отношении IO там все в порядке. IO четко показан ТИПОМ нечистых функций, да оператором do.

Далее, оберонисты почему то все время предполагают что программисты работают в notepad. Хотя последние 10 лет (может больше) я не помню ни одного случая написания мною хоть одной строчки кода в редакторе, для программирования не предназначенном.

Для выделения служебных слов не нужно заставлять программиста писать их большими буквами. С этим прекрасно справляется любой программистский редактор.
Для выяснения какая функция из какого модуля совсем необязательно перед каждым из них везде писать имя модуля. Достаточно навести на него мышку, и редактор вам покажет полное имя. Более того достаточно нажать Ctrl-Мышка и пожалуйста, редактор прыгнет прямо в тело описания этой функции.

Позиция оберонистов в данном случае - это зарывание головы в песок и игнорирование изменений в окружающей среде. Пожмем плечами и пойдем дальше.


Если говорить не о языке, а о сопоставлении подходов в рамках конкретных языков реализации, то следует обратить внимание, что в Хаскеле использовались императивные вещи (do и монады).


Тут уже не знаешь смеяться или плакать. :)) Мама, смотри - присваивание !!!
Руслан, ну уже сколько раз говорилось. Есть в ФЯ изменение состояния (императивные вещи), не делось оно никуда.


По словам Р.В.Душкина, "монада является наиболее сложным концептом для понимания, который только есть в языке Haskell". Они в ФП служат окном в императивный мир.


А вот это недопонимание. Монады и IO это не одно и тоже. List например тоже монада, хотя к IO не имеет никакого отношения.
Для того чтобы пользоваться List не нужно знать ни того факта что это монада, ни вообще того что такое монады.
То же самое и с IO. Монада конечно вешь сложная. Но IO такое же легкое как и в императивных языках.

Ответ на »сообщение 2612« (Руслан Богатырев)
___________________________

Вопрос: какие подходы мировое ФП-сообщество выработало в отношении оценки потребности ресурсов/"просадки" с перспективой возможностей последующего масштабирования (быстро) полученного решения? Это не укол, а желание разобраться. Плюсы ФП (сокрытие деталей) здесь превращаются в минусы. Их, видимо, можно нивелировать. Осталось выяснить как.

Боюсь, такие вопросы нужно задавать в других форумах, там, где тусуется действительно мировое ФП-сообщество, а не несколько человек... :о))

Насколько мне известно, в случае с энергичными ФЯ всё довольно прозрачно, что позволяет, например, утверждать, что программы на том же Эрланге можно использовать в мягком РВ.
Хотя оценить время работы параллельных программ можно разве что на глазок...

В случае же с ленивыми языками всё гораздо сложнее и менее предсказуемо. Если транслятор не использует анализ строгости, то поведение программы по оси времени вообще малопредсказуемо. С анализатором строгости тоже непросто - мало ли что он соптимизируе, а что - нет?
Хвостовая рекурсия иногда может дать выгоду, а иногда (с ленивыми, да ещё и бесконечными, списками) - наоборот, всё испортить...
Иногда явное указание строгого исполнения тех или иных функций может дать ускорение на порядки...

Пока остаётся лишь традиционное средство - профилирование программ.

Ответ на »сообщение 2613« (Илья Ермаков)
___________________________

Известно также, что качество кода, генерируемого компилятором Оберона, находится на уровне С, а в некоторых реализациях навроде XDS в то время, когда они развивались, превосходило все известные реализации С (да и сейчас обходит VC 7.0)...
Отсюда делайте сами вывод...

Извините, но с этим тоже можно поспорить.
Я как-то баловался с простенькими тестами - не нашёл подтверждений этому.
Те мои программки на XDS работали действительно чуть быстрее, чем на Дельфях и C++Builder'е и заметно (в несколько раз) быстрее, чем на BlackBox Component Pascal, но превзойти программы на том же C# (компилятор которого не так уж и хорош) они так и не смогли... Думаю, компилятор VC 8.0 получше будет, чем С#, так что тут XDS скорее сего пролетел бы...

Да вообще, как тут часто замечалось, все эти тесты - такая фикция... :о)

Ответ на »сообщение 2611« (Руслан Богатырев)
___________________________

И Вы, разумеется, выбрали худший, поскольку руководствовались "Бейсик-критерием" вместо надежности и сопровождаемости. Экономия на использовании лишних "буковок" -- IMHO, Бейсик-мания.

Вообще, интересное противостояние взглядов у оберонщиков и большинства остальных программистов на средства разработки.

Оберонщикам подсветка синтаксиса не важна - её роль играет языковое соглашение по прописным идентификаторам.

Явная квалификация модуля, из которого импортируется тот или иной объект, вместо возложения этого на редактор, подсказывающий место описания этого объекта с документирующим комментарием.

Явное специфицирование типов объектов вместо автовывода типов и опять же подсказки редактора кода.

Всё это - всё-таки, на мой взгляд, дело вкуса и привычки... Не так уж и часто люди соглашаются на добровольный аскетизм в средствах разработки...

Ответ на »сообщение 2611« (Руслан Богатырев)
___________________________

Без qualified-импорта нельзя локализовать точки импорта сущностей (надо знать, что было в импортируемом модуле -- иметь к нему доступ или документацию, которая имеет тенденцию рассинхронизироваться с действительностью).

Для хаскелла есть вполне стандартный и общепринятый инструмент генерации документации Haddock (вроде Javadoc) и некоторые принятые соглашения по коментариям, документирующим код на Хаскелле, которые используются Haddock'ом.


Хочу обратить Ваше внимание, что неквалифицирующий импорт в Хаскеле сделан не как в Модуле-2 -- в Модуле-2 явно прямо в списке импорта (т.е. у нас перед глазами) перечисляются импортируемые идентификаторы, а в Хаскеле -- только имя импортируемого модуля. Это худший вариант.

Вообще-то можно и так тоже (очень часто встречается):

module ACM_2007_A where

import IO (openFile, hClose, ReadMode, hGetContents)
import List (nub)

или даже так (с последующей квалификацией импортированных объектов):

module ACM_2007_A where

import qualified IO (openFile, hClose, IOMode(ReadMode), hGetContents)
import qualified List (nub)

то, что средством qualified не воспользовался Geniepro, лишний раз говорит о недооценке такой возможности (ложный стереотип относительно того, что это всего лишь косметическое средство борьбы с конфликтом имен). Уроки и опыт Оберона стоит извлекать.

Ну, вряд ли стоит обобщать мой случай на всех хаскеллеров. Иногда квалифицированный экспорт всё-таки используется, вот только я видел не так много больших хаскеллевских программ, а в маленьких это не очень оправдано...

Сейчас вот полистал исходники компилятора GHC (а это, по-моему, до сих пор ещё самый большой проект на Хаскелле), обратил внимание, что квалифицированный импорт встречается крайне редко...

Уж если сами разработчики Хаскелла и его основной реализации так редко используют эту возможность - что уж ожидать от рядовых и тем более начинающих хаскеллеров?

А может быть, для чистых ФЯ это не так уж и важно?
Хаскелл не является языком компонентного программирования, так что не все обероновские взгляды на код программ актуальны и беспорны для Хаскелла...


Не уверен, что строгость программирования -- дело вкуса. Это больше напоминает принцип "и так сойдет".

В серьёзных проектах руководители проектов выставляют свои требования к кодированию с административным воздействием - так стоит ли перекладывать это ещё и на язык программирования, делая его использование неудобным? Оберон не имеет гибкости в этом вопросе - так ли уж это хорошо?


Это худший вариант. То, что он в этом языке сосуществует с лучшим вариантом -- квалифицирующим импортом -- дает возможность выбора (чего давать нельзя).  И Вы, разумеется, выбрали худший, поскольку руководствовались "Бейсик-критерием" вместо надежности и сопровождаемости. Экономия на использовании лишних "буковок" -- IMHO, Бейсик-мания. Об уроках Оберона я не зря говорил. Делайте выводы, учитесь на чужом опыте тех, кто на этом не одну собаку съел, а не отмахивайтесь, как от назойливой мухи. Уж слава Богу, в сфере нюансов модульного программирования Вирт и его коллеги дадут 100 очков вперед Хаскель-сообществу.

Вы меня извините, но всё это довольно спорно.

С другой стороны, Хаскелл до сих пор ещё не используется в промышленных масштабах, а в основном только для экспериментальных работ и быстрого макетирования программ. Может быть, если Хаскелл войдёт в промышленность, то хаскеллеры и выработают стандарт кодирования и инструменты поддержки этого стандарта...
А пока же. как говорят отцы-основатели Хаскелла, Хаскелл - язык для экспериментальных разработок...

Ответ на »сообщение 2608« (Руслан Богатырев)
___________________________

P.S. На мой взгляд, задача достаточно хорошо ложится на конечные автоматы (со всеми вытекающими последствиями по компактности, в ущерб определенной наглядности). Но это детали.

Мне как-то пришло в голову, что эта программа на Хаскелле не сильно отличается от конечного автомата...


Простите за нескромный вопрос, а Вы в этом плане себя причисляете к большинству или к меньшинству?

Ну, будь я фанатом машшиного кода, вряд ли бы я интересовался Хаскеллом...


Вынужден трактовать это либо как Вашу невнимательность к словам оппонента, либо как работу на публику

Извиняюсь, что не дочитал тот абзац до конца (уж больно большой он), а сразу начал отвечать на него. Потом отвлёкся, и только сейчас таки дочитал...

Ответ на »сообщение 2606« (Geniepro)
___________________________
ЗЫ. А если сделать Оберон-систему целиком в машинных кодах, то она будет гораздо эффективнее, чем на Обероне. И почему большинству людей такая идея кажется бредом?
Не будет. Известно, что для программ начиная от среднего размера компилятор с языка С дает в среднем по коду лучшее качество, чем ассемблерист руками...
Известно также, что качество кода, генерируемого компилятором Оберона, находится на уровне С, а в некоторых реализациях навроде XDS в то время, когда они развивались, превосходило все известные реализации С (да и сейчас обходит VC 7.0)...
Отсюда делайте сами вывод...

А вообще, одним из важных критериев надежности среды для системного программирования и бы считал "раскрученность" на самой себе... При наличии слоев на разных язык, инородного рантайма и т.п. гарантия надежности платформы и развиваемости платформы на порядок падает...
Это не касается, естественно, прикладного программирования - есть рантайм на Си - и пусть себе, зато вся прикладная инфраструктура "сверху" раскручена на самой себе - и отлично...