Re: Совместное совещание по Рефалу 17 июня
On Wed, 21 Jun 2023 at 14:44, Arkady Klimov arkady.klimov_AT_gmail.com wrote: > Сайт refal.net я попробовал, он переадресуется на сайт Харькова. Возможно, он > у нас заблокирован: я входил при включенном впн. Самого рефал-сайта там я не > нашел. Возможно, сервер у Леонида Б. отключен. Хотелось бы узнать, что там. Здравствуйте, Хотел только сказать: отсюда (г. София) сайт refal.net виден. Внешний вид тот же, что у refal.ru, но дальше похоже что не всё одинаково. Если нужно поискать на этом сайте что-то конкретное, я буду рад попробовать и поделиться результатом. Бойко
Re: Re[2]: рефал всё же скорее умер :(
On Mon, 20 Feb 2023 at 13:20, Александр Гусев gusev_aleksandr_AT_mail.ru wrote: > > Аркадий, это аббревиатура «read-eval-print» - основной интерфейс исходного > basic. Набрал выражение, нажал ввод - увидел ответ, как было на Консуле, если > не забыл. То есть без команд компиляции, сборки и т.п., доставшихся от эпохи > перфокарт и os360, малопонятных для рядового пользователя вещей. > > Отправлено из мобильной Почты Mail.ru > > понедельник, 20 февраля 2023 г. в 13:46 +0300 от refal : > > Спасибо, Бойко, это очень дельно. > Хочу только уточняюще спросить: что такое REPL? Да, как сказал Александр, REPL – read-eval-print loop. Изобрели для Лиспа когда-то. Чуть подробнее можно найти об этом в вики: https://ru.wikipedia.org/wiki/REPL и ещё подробнее в статье на английском https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop Это то же, что GHCi для Haskell или irb для Ruby. Вообще, примеров много. Что интересно, видел таких вещей даже для C и C++.
Re: рефал всё же скорее умер :(
На теме живучести Рефала позволю себе вставить свои 2 копейки (или 2 стотинки). Живучесть языка зависит от привлечения к его использованию новых людей. А какие факторы, помимо самого языка, могут этому способствовать? 1) По-моему, необходимым условием для того, чтобы язык производил благоприятное впечатление, является наличие документации в удобном и современном виде. Под словом «документация» имею ввиду классическую троицу: • исчерпывающий справочник по языку; • руководство по программированию на языке (вместе с кратким справочником по языку); • справочник пользователя (компилятора и пр. составляющих конкретной системы программирования на данном языке). Удобный для пользования и современный вид документации очень важен. Его нетрудно постичь, но основные реализации Рефала такой документацией не располагают. Файлы *.txt или архаичный HTML внимания не привлекут, они скорее отталкивают пользователей. Нужен LaTeX или хорошо стилизованный HTML, а лучше всего иметь и то, и другое. Тем более, что их можно получать из одного исходника, записанного в простом формате разметки. Из моего опыта, asciidoc (https://docs.asciidoctor.org/asciidoc/latest) без соперников с точки зрения богатства возможностей оформления текста при простоте разметки. 2) Привлекает пользователей также наличие классического REPL. Тому примеров много, причём для языков самого разного вида. 3) Возможность выполнения программ онлайн – например, как на сайтах https://tio.run https://ideone.com или в виде онлайн консоли (опять-таки REPL, но в браузере, как здесь для JavaScript): https://jsconsole.com Студентам, например, такие возможности очень нравятся. Заметил, что они их однозначно предпочтут даже когда установить на компе компилятор или интерпретатор и пользоваться им совсем нетрудно. Точки 1)-3), по-моему, нетрудно обеспечить. Следующие две требуют более существенную работу, но если речь идёт о выживании языка, то следует думать и о развитии сферы его применения, поэтому, как мне кажется, их тоже хорошо иметь ввиду. 4) Продвижению языка очень помогает существование написанных на нём прикладных библиотек. Есть немало примеров языков программирования, успех которых обусловлен именно наличием таких библиотек. Язык Python, например – яркий пример весьма заурядного по существу языка, получившего огромное распространение благодаря оснащённости прикладными библиотеками в самых разных областях. Причём создание библиотек шло лавинообразно: наличие одних библиотек способствовало применению языка и созданию новых библиотек. Да и Fortran не умер как раз благодаря написанным на нём библиотекам. 5) Если язык транслируется в JavaScript или WebAssembly – это сразу открывает возможности его применения в веб среде, и не только. Не говоря уже, что таким образом и сам язык обогащается за счёт использования уже развитой инфраструктуры.
Re: Музейная ссылочка
On Wed, 11 Aug 2021 at 15:38, Arkady Klimov arkady.klimov_AT_gmail.com wrote: > > Да, написано с уважением, но без понимания (типа слышал звон ...). Написал бы > я коммент, да не нашел как. > А автор там указан - Антон Семин (справа вверху). > Аркадий У данной фирмы есть страничка для контактов https://skillbox.ru/contacts с формуляром для отправки сообщений. Может, оттуда перенаправят автору, а он добавит ваш комментарий к статье. Всего лишь предположения, конечно.
Re: Re[2]: Рефал "мертв"? Да здравствует Рефал.
Здравствуйте все! Несколько человек высказалось в поддержку существования специфического для Рефала мышления в решении задач. Однако при этом никто не указывает, в чём эта специфика состоит. А вопрос интересен даже только ввиду того, что, по-видимому, и среди рефальщиков не все разделяют данную точку зрения. Тем более важно уточнить, в чём состоит связанная с Рефалом специфика, если говорить об (согласно Александру Гусеву) «обучении Рефалу не как языку, а как методу мышления». Имеется ли, например, порождённая Рефалом методология программирования, которую можно излагать и которой можно следовать, необязательно прибегая к собственно программированию на Рефале, и которая вместе с тем достаточно чётко отличается от других существующих методологий?
Re: В защиту ссылок в Рефале – Was: Рефал-семинар 17 мая 2021 в 10:30 в Zoom'e
On Tue, 18 May 2021 at 23:00, Andrei Klimov andrei_AT_klimov.net wrote: > > После семинара между двумя Александрами (Гусевым и Коноваловым) возникла > переписка с ограничеснной рассылкой только тем, кто был на семинаре. Я > захотел встрять и посылаю письмо в refal@botik c надеждой, что это обсуждение > будет интересно всем. Также я указал в BCC тех, кто был на семинаре, но на > нашу рассылку не подписан, и еще некоторых коллег. > . То, что написано ниже, к Рефалу не относится, по крайней мере непосредственно, а было вызвано разговором о ссылках, и, более конкретно, указанием на первичность понятия ссылки и на то, что ссылка — вовсе не машинный адрес. Руки зачесались и не смог устоять :) Итак, вспомнилось несколько вещей. Во-первых то, что в (функциональном) языке Erlang имеется как раз тип абстрактных ссылок — reference: https://erlang.org/doc/reference_manual/data_types.html#reference. Эти значения порождаются особой функцией и каждое из них отличается от остальных. Что характерно, вопреки их имени, они не могут ссылаться ни на что, а существуют сами по себе. Или же можно считать, что любое такое значение только на себя и ссылается. Насколько я понял, развиваемое Andrew Pitt понятие ссылки, про которое рассказал Андрей Климов, ближе всего к этому reference в языке Erlang. Фундаментальность ссылок осознавалась и хорошо видна в определении языка Algol 68, в котором, однако, ссылки строго типизированные. Определение переменной, например int i, закрепляет за именем i тип ref int, т.е. ссылка на целое (а не просто целое). В действительности, int i является сокращённой формой более подробного определения ref int i = loc int, где loc — генератор (локальных в данном блоке) ссылок, порождающий в данном случае ссылку на целое. Имя же i после этого привязывается неотделимым образом к ссылке. Если нужно в одной команде определить переменную и задать значение, на которое она ссылается, то пишут int i := <целочисленное выражение>, что в более подробном виде есть ref int i = loc int := <целочисленное выражение>. И вообще, любое отдельное присваивание i := ... заменяет то, на что ссылается i (или задаёт его, если до того i ни на что не ссылалось). С другой стороны, написав int j = <целочисленное выражение>, за именем j закрепляется тип int (а не ref int) и j становится обозначением соответствующего значения. Заметим, что и здесь, и выше = является не присваиванием, а отождествлением имени со значением. Поскольку тип j не ссылочный, то j не есть переменная, не может ссылаться ни на что, и в частности применение присваивания := к j невозможно. К тому же, на обозначаемое j значение нельзя ссылаться каким-нибудь косвенным образом: его можно только цитировать через имя j. А что собой представляют ссылки (указатели) в «самом ссылочном» языке C? На мой взгляд, словом «указатель» или «ссылка» в C обозначается несколько очень разных понятий: а) ссылка на значение переменной; б) ссылка на начальный или другой элемент массива; в) ссылка на динамически отведённый кусок памяти; г) ссылка на функцию. Свойства этих четырёх видов указателей разные. К а) не имеет смысла применять никакие операции кроме разыменования (хотя язык этого не запрещает). К б), помимо разыменования, применима так называемая адрессная арифметика. Ссылки вида в) имеют тип void* (стрелка в пустоту). Такие ссылки, тем не менее, магически превращаются в ссылки на любой конкретный тип значения. Ввиду всего этого, в) можно считать чуть замаскированным машинным адресом, тогда как а) и б) являются вполне абстрактными ссылками — ничто не требует видеть за ними машинные адреса. Что касается случая г), от него вообще мало пользы. Чем практически (а не формально) отличается тип ссылки на функцию от типа этой же функции? Как мне кажется, смешивание разных понятий под общим именем «ссылка»/«указатель» в C способствует в немалой степени путанице в понимании природы ссылок вообще. Вспомним и о BCPL, где указатели примерно такие как в C, но бестиповые. Этот язык вообще бестиповый, так что указатель — это значение переменной лишь с точки зрения некоторых операций. То же значение для других операций — целое число или что-то ещё. Наконец, кроме ссылок в более-менее прямом смысле, в разных языках программирования имеются другие формы косвенного обращения. В C++, например, такими являются так называемые итераторы. По применяемым над ними действиям они похожи на указатели, но вместе с тем снабжены специфическими для них, и при этом весьма существенными свойствами. Имеется ещё и понятие reference, которое не указатель (и, конечно, не итератор) — как, например, в int & i. Кажется, переводится как «синоним». Примечательно, что сложно даже навести терминологический порядок в таком языке. Скажем, можно постулировать, что имеются разные виды ссылок: указатели (и на самом деле, как уже писал выше, одних их уже несколько видов!), итераторы и синонимы. И не дай бог после этого сказать,
Re: Справочник по Рефалу-5λ
Поздравляю Вас, Александр! Появление документации – важная веха в развитии любой программы, тем более такой непростой как в Вашем случае. Вероятно, стоит снабдить текст содержанием (оглавлением), и тем лучше, если с гиперссылками. Бойко On Mon, 20 Apr 2020 at 17:36, Александр Коновалов a.v.konovalov87_AT_mail.ru wrote: > Добрый день всем! > > В рассылке я часто упоминал Рефал-5λ, иногда публиковал ссылку > на репозиторий с исходниками. Но вот нормальной документации к нему пока > не было. > > И вот она появилась: > > https://bmstu-iu9.github.io/refal-5-lambda/B-reference.html > > В справочнике есть почти полное описание языка (не раскрыты только $DRIVE > и $SPEC), инструкция по использованию компилятора и описание отладочных > средств. Библиотека встроенных функций там не описана, поскольку она та же > самая, что и у классического Рефала-5. > > Ну, в общем, теперь на Рефале-5λ может программировать не только автор . > > > > С уважением, > Александр Коновалов > > >
Re: Как мне назвать компилятор?
Имя музыкального тона «ля» созвучно со словом «лямбда», а обозначается он через букву A. Тогда вместо префикса «r5l» можно «r5a». К тому же, «a» — одна из обычных добавок к имени (подобно «плюс» и «прим»), чтобы оно и было подобно, и отличалось от существующего. И, наконец, A не сильно отличается от греческого Λ :) Конечно, всё это очень натянуто, но вряд ли в большей степени, чем графическая имитация буквы Λ знаком \ (Haskell) или λ — знаком -> (Ruby). Просто моите две стотинки :) On Tue, 31 Mar 2020 at 14:26, Александр Коновалов a.v.konovalov87_AT_mail.ru wrote: > > Добрый день всем! > > У компилятора название есть, такое же как у языка — Рефал-5λ. Но вот чего нет > — нет нормального названия для утилиты командной строки. > > > > Исторический контекст (можно не читать). > > Когда-то я разрабатывал так называемый Простой Рефал — диалект, синтаксически > похожий на Рефал-5 (но не совместимый с ним), семантически — на Рефал-2 > (пустые функции вместо слов), поддерживающий только базисное подмножество. > Позже я в него добавил безымянные вложенные функции (замыкания, «лямбды»). > Исполнимый файл естественным образом назывался srefc (Simple Refal Compiler). > Для компилятора была также утилита srmake, которая принимала на входе имя > одного исходника, находила остальные по зависимостям и вызывала для них > srefc. Зависимости вычислялись по комментариям вида > > //FROM имя-файла > > которые по соглашеню предваряли списки $EXTERN для функций из соответствующих > файлов. > > Потом я понял, что несовместимый диалект не нужен даже мне и переделал > компилятор в совместимый с Рефалом-5. Так появился язык Рефал-5λ, который > является надмножеством Рефала-5 и включает в себя вложенные функции (что > символизирует буква «λ» в названии). Но имя программы так и осталось srefc, а > имя утилиты поиска зависимостей — srmake (которая теперь ищет комментарии > *$FROM имя-файла). > > Исходники компилятора уже давно переписаны с Простого Рефала на Рефал-5λ > (кроме фронт-энда Простого Рефала, который остался самоприменим), фронт-энд > Простого Рефала я уже подумываю удалить, поэтому имена srefc и srmake > становятся анахронизмом. > > > > Поэтому я прошу помощи у подписчиков: как мне назвать программу компилятора > (вместо srefc) и программу поиска зависимостей (вместо srmake)? > > Можно сократить название refal-5-lambda до r5l и использовать его как > префикс: r5lc, r5lmake. Но префикс r5l похож на r51 и r5I и этим неудачен — > легко перепутать. Использовать имена r5c и r5make не хочу, т.к. это не > Рефал-5, а Рефал-5λ. Имя вроде refal-5-lambda-compiler слишком длинное. > > По умолчанию компилятор создаёт исполнимые файлы, состоящие из > интерпретатора, к которому «приклеен» байткод. Но можно создавать файлы и из > голого байткода. Для запуска последних как программ я планирую написать > интерпретатор вроде refgo из классического Рефала-5. Возникает вопрос: а > какое ему дать имя? > > > > С уважением, > Александр Коновалов
Re: OT: название упорядочивающей последовательности
Добрый день всем! Спасибо за ответы. Кажется, из предложенного лучше всего подходит «упорядочивающая перестановка». Дополню (или напомню тем, кому знакомо), что нахождение по данному вектору упорядочивающей его перестановки, не изменяя сам вектор — отнюдь не экзотика и не новость в программировании. Соответствующая операция имеется ещё в языке APL, созданном в начале 1960-х. Сила APL как раз в работе с последовательностями и массивами высшего чем 1 порядка, а также в присутствии элементов чисто аппликативного (комбина́торного) функционального стиля. Имеется эта операция также и в языках, созданных под влиянием APL: J, K, Nial. Кстати, в переводах старых книг по APL можно встретить название «индексация по возрастанию»» В языке APL данная операция обозначается через ⍋ (http://fileformat.info/info/unicode/char/00234B), так что, например, ⍋ 7 2 13 9 18 16 даст 2 1 4 3 6 5. Кому интересно, можно поиграть APL-ом, и в частности выражениями как выше, вот здесь: https://tryapl.org У упорядочивающей перестановки следующее важное свойство: если А — перестановка чисел 1,...,n, а Б — упорядочивающая А перестановка, то А и Б — взаимно обратные перестановки, а поэтому и А является упорядочивающей Б перестановкой. On Wed, 11 Mar 2020 at 22:11, Yuri Klimov yuri_AT_klimov.net wrote: > > Добрый вечер! > > Я бы назвал "упорядочивающая перестановка", если я правильно понял о чем речь. > Б - перестановка (отображение i в Б[i]), после применение которой к A > получаем упорядоченную последовательность. > > С уважением, > Юрий Климов > > On Wed, 11 Mar 2020 at 12:46, Boyko Bantchev boykobb_AT_gmail.com > wrote: >> >> У меня вопрос, имеющий отношение не к Рефалу, а к терминологии >> программирования в целом. >> >> Бывает, что некоторую последовательность А нужно упорядочить, >> не изменяя её. Для этого мы вводим последовательность Б индексов >> 1, 2, ..., указывающих на элементы первой последовательности, и >> сортируем Б так, чтобы А[Б[1]], А[Б[2]], ... было упорядоченной >> версией А. Как назвать упорядоченную таким образом последовательность >> Б? По-английски она обычно называется grade (of А), а по-русски я >> бы назвал косвенным упорядочением, или ранжировкой А, но похоже, >> что нет устоявшегося слова. >> >> А как бы вы назвали?
Re: OT: название упорядочивающей последовательности
Здравствуйте, Александр, спасибо за ответ! Но индекс в СУБД — это, по-моему, любая структура данных косвенного доступа, увеличивающая временную эффективность действий с данными (https://ru.wikipedia.org/wiki/Индекс_(базы_данных)). Я имею ввиду нечто проще и совсем конкретное. Например, если последовательность А состоит из чисел 7 2 13 9 18 16, тогда то, о чём я говорю — это вектор Б = 2 1 4 3 6 5, поскольку А[Б[1]] = А[2] = 2 А[Б[2]] = А[1] = 7 А[Б[3]] = А[4] = 9 А[Б[4]] = А[3] = 13 А[Б[5]] = А[6] = 16 А[Б[6]] = А[5] = 18, или, записав короче, А[Б], есть упорядоченный вариант А. Слово «индекс» не очень подходит для применения в общем контексте программирования и потому, что в нём у него имеется другой смысл. On Wed, 11 Mar 2020 at 17:41, Александр Гусев gusev_aleksandr_AT_mail.ru wrote: > > Добрый день, Бойко! > В практике баз данных последовательность Б называют индексом. А её > составление индексированием. > Или я не понял вопроса. > > > > Отправлено из мобильной Почты Mail.ru > > > среда, 11 марта 2020 г., 12:47 +0300 от refal : > > У меня вопрос, имеющий отношение не к Рефалу, а к терминологии > программирования в целом. > > Бывает, что некоторую последовательность А нужно упорядочить, > не изменяя её. Для этого мы вводим последовательность Б индексов > 1, 2, ..., указывающих на элементы первой последовательности, и > сортируем Б так, чтобы А[Б[1]], А[Б[2]], ... было упорядоченной > версией А. Как назвать упорядоченную таким образом последовательность > Б? По-английски она обычно называется grade (of А), а по-русски я > бы назвал косвенным упорядочением, или ранжировкой А, но похоже, > что нет устоявшегося слова. > > А как бы вы назвали?
OT: название упорядочивающей последовательности
У меня вопрос, имеющий отношение не к Рефалу, а к терминологии программирования в целом. Бывает, что некоторую последовательность А нужно упорядочить, не изменяя её. Для этого мы вводим последовательность Б индексов 1, 2, ..., указывающих на элементы первой последовательности, и сортируем Б так, чтобы А[Б[1]], А[Б[2]], ... было упорядоченной версией А. Как назвать упорядоченную таким образом последовательность Б? По-английски она обычно называется grade (of А), а по-русски я бы назвал косвенным упорядочением, или ранжировкой А, но похоже, что нет устоявшегося слова. А как бы вы назвали?
Re: Эпистемиология по Турчину
On Sun, 1 Mar 2020 at 15:33, Andrei Klimov klimov_AT_keldysh.ru wrote: > > Бойко, большое спасибо! > > Действительно, я лопухнулся, а был уверен, что настроил гугл-группу > metacomputation-ru так, чтобы все могли в нее писать. Мне даже казалось, что > уже были письма от неподписчиков. Теперь поправил на "Post: Anyone on the > web". > > Бойко, вы подняли шикарные вопросы, и я с удовольствием продолжу по ним > дискуссию, но смогу спокойно сформулировать свои мысли не раньше вторника. > > Всего наилучшего, > Андрей Спасибо большое за поясняющую информацию! Жду с интересом продолжения дискуссии. С уважением, Бойко
Re: Эпистемиология по Турчину
Предыдущий пост я прислал через «Reply to all», имея ввиду сказанное в этой группе раньше: «Гугл-группа Metacomputation-Ru ... открыта и для неподписанных». В результате получил ответ от некоего товарища, назвавшего себя Google Groups. Ответ гласил следующее: > Возможно, группа (metacomputation-ru), с которой вы пытаетесь соединиться, не > существует или у вас нет разрешения на добавление в нее сообщений. Причины, > по которым невозможно добавить сообщения в группу: > > * имя группы написано или отформатировано неправильно; > * владелец удалил эту группу; > * необходимо сначала присоединиться к группе; > * группа закрыта для сообщений. Мне самому это неважно, но решил сообщить в качестве обратной связи.
Re: Эпистемиология по Турчину
> Мы привыкли читать определения в одном направлении – справа налево: > справа известное, слева определяемое, до этого не известное. А при > "круговом определении" надо читать в обе стороны – и слева направо, > и переворачивая фразу. Давайте сделаем это, чтобы проиллюстрировать, > что я имею в виду, дав "определение" понятия предсказания через > понятие знания (слово "определение" пишу в кавычках, чтобы еще раз > подчеркнуть, что речь не о том, что в математике). Насколько понимаю, Ваше предложение состоит в том, чтобы считать две понятия — «имеющее смысл знание» и «предсказание» — взаимно определяющимися, а именно, сказав ⯁ знание имеет смысл, если его можно использовать для предсказаний под словом «предсказание» понимать не что иное, как: ⯀ предсказание есть деятельность, придающая смысл знанию. По-моему, это «определение» пустое, оно не проясняет содержания ни первого понятия, ни второго, ни связи между ними. И причина не просто в том, что каждое из двух понятий мы пытаемся определить через другое в рамках одного и того же отношения. Согласен, что от философии нельзя ожидать строго последовательного изложения определений каждое через предыдущие. Но ведь математике также не чужды взаимные определения: именно так работают системы аксиом. Например, понятия точки, прямой и плоскости взаимно определяются через некоторый набор аксиом евклидовой геометрии. Вся информация об этих объектах дана через аксиомы, а они ни в коем случае не являются последовательными определениями. Так почему отсутствие последовательности или иерархии в определениях работает даже для математики, а здесь нет? В аксиоматической системе аксиомы не есть определения, а выявляют суть абстрактных понятий косвенно, через отношения между ними. Говоря «Через любые две точки проходит ровно одна прямая» или «Среди любых трёх точек, лежащих на одной прямой, ровно одна лежит между двумя другими», мы уточняем смысл абстрактных понятий точка и прямая через отношения «проходит» и «лежит между», причём эти отношения — такие же абстракции. Тем не менее, каждая аксиома уточняет смысл и объектов, и отношений между ними, неся конкретную, чётко выделяемую информацию — количественную и прочую. И так как аксиомы составляют совокупность (у Гильберта их двадцать, групированные по видам отношений), вместе взятые их можно считать определением и первичных геометрических объектов, и отношений между ними. Так ли в случае с вышеприведённым философским определением? Две определяемые в нём сущности — знание со смыслом и предсказание, а связывает их отношение «придавать смысл». Но само «определение», в отличие от любой геометрической аксиомы, лишено информативности. Из него нельзя ничего извлечь о том, что такое знание со смыслом, что есть предсказание или что значит придавать смысл. Тем более что, также в отличие от аксиом, оно стоит само по себе, а не является элементом совокупности. Поэтому и остаётся непонятным и практически неприменимым.
Re: Re[2]: День Валентина Турчина
Александр, спасибо за комментарий в ответ на мой вопрос! Подумав над написанным Вами, у меня возникли сомнения насчёт следующего. > В основе мета-подхода лежит предпочтение влияния на корни процесса, > на то, что лежит в его основании. В кибернетике, по моему мнению, > предпочтение отдаётся выделению «чёрного ящика» со своим входом и > выходом. Трудно согласиться, что «нетурчиновская» кибернетика предпочитает не интересоваться корнями и основаниями процессов, и тем более, что её методология как-то сосредоточена на применение «чёрного ящика». Сам Турчин, насколько мне известно, такого разделения не делал. «Чёрный ящик» — всего-навсего способ изучения незнакомой системы и сосредоточением на нём нельзя объяснить развитие таких сложных и богатых содержанием тем, как в следующей цитате из Википедии: «Concepts studied by cyberneticists include, but are not limited to: learning, cognition, adaptation, social control, emergence, convergence, communication, efficiency, efficacy, and connectivity.» Нет никакой большой важности концепции «чёрного ящика» и с самого возникновения кибернетики. В книге «Кибернетика» Н. Винера это понятие упоминается ровно раз (не считая введения). А в более популярно написанной и не менее знаменитой книге «Кибернетика и общество» того же Винера никаких ящиков вообще нет. Ввиду всего этого, вопросу о принципиальной необходимости выделения МСП как особое понятие, как я его задал в предыдущем посте, пока не нахожу ответа. Хорошего дня!
Re: День Валентина Турчина
Спасибо Александру за резюме статьи. Я со своей стороны воспользуюсь случаем задать вопрос о смысле понятия «метасистемный переход», так как его я так и не постиг, хотя несколько раз пытался читать соответствующие тексты В. Ф. Турчина. Чем понятие «метасистемный переход» отличается от просто понимания, при этом всеми разделяемого, что сложные системы строятся из более простых, и что это естественно имеет место на более чем одном уровне? Какое значение имеет, будем ли мы называть это «метасистемным переходом», если и так нам понятно, что, например, биологическая ткань — система, состоящая из систем-клеток, органы — системы из тканей, а организмы — из органов. И что организмы, в свою очередь, формируют системы-общества. И что все системы эволюируют, переходя во что-то новое. Чем введение термина «метасистемный переход» способствует лучшему, более совершенному пониманию мира? Какой вообще области нужно считать принадлежащим данный термин? Похоже, что кибернетике. Но статьи под названием «Кибернетика» в Википедии, по крайней мере на русском и на английском, не ссылаются на такой термин ни раз. Выходит, что сама кибернетика мало нуждается в наличии этого термина. Да и сам так называемый «Кибернетический манифест», являясь философским и вообще мировоззренческим кредо своих авторов, имеет, как мне кажется, с кибернетикой мало общего. Кто хочет, пожалуйста поделитесь мнениями в связи с этим. On Mon, 24 Feb 2020 at 13:31, Александр Коновалов a.v.konovalov87_AT_mail.ru wrote: > > Добрый день всем! > > Напишу краткое содержание трёх частей этой статьи. Статья построена в форме > диалога с воображаемым собеседником — на первый взгляд может показаться, что > это интервью. Но это не интервью. > > В первой части статьи http://7i.7iskusstv.com/y2019/nomer9/turchin/ Турчин > объясняет основы философии, беря в качестве отправной точки эпистемологию. > Осилить мне её не удалось, поскольку такие философствования сложны для меня. > > Вторая часть http://7i.7iskusstv.com/y2019/nomer10/turchin/ представляет > просто конспект книги Феномен науки. > > Третья часть http://7i.7iskusstv.com/y2019/nomer11/turchin/ содержит > раскрытие идей «Кибернетического манифеста». Если в манифесте идеи скорее > перечислены, то здесь они подробно разбираются. > > > > С уважением, > Александр Коновалов > > > > From: Andrei Klimov [mailto:and...@klimov.net] > Sent: Friday, February 14, 2020 10:51 PM > To: metacomputation-ru ; refal@botik.ru > Subject: День Валентина Турчина > > > > Добрый день всем! > > > > Сегодня 14 февраля день не только Святого Валентина, но и нами более любимого > и ценимого Валентина Федоровича Турчина – его день рождения (1931). > > > > Мы поминаем его и поздравляем друга с тем, что мы его знали или заочно > впитывали его идеи. > > > > Образ Валентина Федоровича и его цельное эволюционное мировоззрение живет в > нас и помогает нам не растеряться в нынешнем бурном потоке событий и новых > явлений – от научных и социальных до философских вопросов – смысла жизни, > этики, добра, отношения к смерти и бессмертию, нашего места в мире и принятия > решений о наших личных поступках. > > > > В качестве подарка нашему сообществу рад сообщить, что в прошлом году была > опубликована на популярном сайте – в двух выпусках интернет-журнала "Семь > искусств" – одна из последних статей Валентина Турчина в переводе на русский: > > Диалог о метасистемном переходе > > http://7i.7iskusstv.com/y2019/nomer9/turchin/ > http://7i.7iskusstv.com/y2019/nomer11/turchin/ > > Прекрасный перевод с английского сделал Владимир Балтер. Вот ссылки на > оригинал: > > A dialogue on Metasystem transition, World Futures, 45:1-4, 5-57, 1995. DOI: > 10.1080/02604027.1995.9972553 > > https://www.tandfonline.com/doi/abs/10.1080/02604027.1995.9972553 – > официальная страница статьи, куда ведет и указанный DOI. Официально PDF-файл > бесплатно не дают, но... сами знаете. > http://pespmc1.vub.ac.be/Papers/Turchin/dialog.pdf – файл "препринта" на > сайте ""Principia Cybernetica". > https://pat.keldysh.ru/~roman/doc/Turchin/1999-Turchin--A_Dialogue_on_Metasystem_Transition.pdf > – этот же файл, но с обрезанными краями (для удобства чтения на экране и > печати буклетом) на сайте Сергея Романенко, куда он поместил часть работ > Турчина. > > Всего наилучшего, > > Андрей Климов > > > > PS. Это письмо послано в Гугл-группу Metacomputation-Ru и в рассылку > refal@botik.ru, где сосредоточены большинство ценителей научного наследия > Турчина по computer science. Кроме того, в "скрытую копию" поставлены адреса > коллег и друзей, которые отсутствуют в этих рассылках. > > > > Публикация "Диалога" на русском – хороший повод обменяться впечатлениями и об > этой статье, и о всех вопросах связанных с концепцией метасистемного перехода > Турчина. > > > > Гугл-группа Metacomputation-Ru, на мой взгляд, вполне подходящее место для > обсуждения как этой, так и других работ Турчина. Пишите в нее на адрес > metacomputation...@googlegroups.com, даже если вы в
Re: Нужна ли "Ленинская простота" в Рефале?
Добавлю к уже сказанному другими о множественных значениях. Множественные результаты имеются в Scheme и с ними работается сравнительно удобно. Например, одна и та же функция может возвращать разное количество результатов в разных случаях. Функция ниже находит корни квадратного уравнения, реальные или комплексные, и возвращает их как два значения. Но если они совпадают, возвращается единственное значение.O`` (define [roots a b c] (let ([d (sqrt (- (* b b) (* 4 a c)))] [a2 (* 2 a)]) (if (= 0 d) (- (/ b a2)) (values (/ (- (+ b d)) a2) (/ (- d b) a2) (roots 1 -3 2) ; получаем два значения: 1 и 2 (roots 1 6 9); получаем значение –3 Множественное присваивание и множественные результаты имеются в языке CLU (середины 70-х) — он более-менее забыт, но дал начало многим конструкциям в современных ЯП. В CLU, например, имеется цикл вида for x,y,z in итератор(аргументы) do тело-цикла где итератор — ограниченного вида сопрограмма, возвращающая некоторое количество значений, которыми питается цикл. Язык Lua также отлично поддерживает множественное присваивание, множественные результаты и циклы как выше у CLU, только с бо́льшими возможностями. (Вообще, в этом языке — удивительно богатый набор возможностей в микроскопическом объёме реализации. Настоящая жемчужина!) On Mon, 2 Dec 2019 at 18:29, Sergei M. Abramov abram_AT_botik.ru wrote: > > > Так что Рефал Плюс — не единственный язык с коарность, или слово > > «коарность» я понял не так. > > Понял так, как надо. > > > В языке Go функции тоже могут возвращать несколько значений: > > https://ru.wikipedia.org/wiki/Go#Функции_могут_возвращать_несколько_значений > > Не знал, Да, сделано "как надо". > > > В Common Lisp’е функции могут возвращать несколько значений (и это не > > возврат списка): > > http://lisper.ru/pcl/the-special-operators#Множественные значения > > Да, тоже не знал. Но, конечно, наворочено... > > > Языки, которые поддерживают кортежи, не считаются. Ну можно вернуть > > кортеж из нескольких значений, но это всё равно будет возврат одного > > значения — кортежа, а не нескольких. > > В точку. Можно эмулировть коарность (коместность) через картежи, > списки, записи и другие подобные механизмы. Например, Haskell: > splitAt, divMod и т.д... > > А разница между эмуляцией и истинной коарностью в одном: при эмуляции > два результата (несколько) конструктором упаковываются в одну > стриктуру чтобы через мгновение разламывать эту структуру в точке > приема на составные части (селекторы). > > Истинная коарность экономит на конструкторе и селекторах. > > Всего доброго, > > Сергей Абрамов >
Re: Re[2]: Нужна ли "Ленинская простота" в Рефале?
On Mon, 2 Dec 2019 at 10:54, Александр Гусев gusev_aleksandr_AT_mail.ru wrote: > > Что касается С-расширения, то это из области "упёртых" практиков. Один мой > знакомый не смог откомпилировать дистрибутив Рефала, который первый ему > попался в сети, под Линукс, плюнул и отступился. Не всегда всё так гладко как > видит разработчик такого продукта в привычном ему окружении. «Трюк» как раз в том, чтобы в реализации на C и через C руководствоваться не «своим окружением», а следовать стандарту ANSI C. Этот подход очень хорошо работает, не раз успешно применён и даёт реализации, которые трудно обогнать по компактности и быстродействию.
Re: Про параллелизм в Рефале
On Sun, 1 Dec 2019 at 23:24, Andrei Klimov andrei_AT_klimov.net wrote: > > вс, 1 дек. 2019 г., 15:31 Александр Коновалов a.v.konovalov87_AT_mail.ru > : >> >> Кстати, вопрос к знатокам терминологии параллельного и/или функционального >> программирования. Вот есть понятие чистая функция — это детерминированная >> функция без побочного эффекта. У этого понятия есть антоним в русском языке, >> кроме словосочетания «грязная» функция? Я пишу «грязная» в кавычках, >> поскольку в литературе его не встречал. > > > Александр, устно мы всегда говорили и говорим "грязная функция". > > В русском письменном языке более скованные традиции, чем в английском. Там > они легко тащат разговорный жаргон в профессиональную терминологию. А мы > что-то из себя изображаем. > > Я бы приветствовал использование "грязный" в текстах, но не знаю, сложилась > ли уже такая традиция. Я бы предложил чистая/нечистая. Мне кажется, это и лучше соответствует английским словам pure/impure. По-английски не dirty function же, всё-таки :)
Re: Нужна ли "Ленинская простота" в Рефале?
> Распространённая терминологическая ошибка Александр, Представьте себе, мне хорошо известна разница между понятиями статическая/динамическая и строгая/нестрогая в отношении типизации в языках программирования. Однако я говорю не о нестрогой типизации, а о слабой. Слабо типизированным я называю язык, в котором, грубо говоря, типы данных имеют небольшую роль. Например, их мало и нельзя определять новые. Такой язык не обязательно нестрого типизированный. > Ликбез по типизациям: https://habr.com/ru/post/161205/ Спасибо за заботу. Адекватных источников, например книжек, хватит, я их читал и по мере сил стараюсь продолжать. > А с тем, что Рефал — динамически типизированный, я не спорю. Я и не утверждал то, с чем вы не спорите. Кстати, оно и неоднозначно, динамический Рефал или нет. Например, если считать типами s., t. и e., то Рефал окажется статически типизированным: тип каждой переменной определён в тексте программы, т.е. статически.
Re: Нужна ли "Ленинская простота" в Рефале?
> ... Если ещё немного усложнить язык - получится Хаскелл, зачем тогда Рефал? Получить Haskell или вообще язык с системой типов Hindley–Milner из Рефала не то что с небольшими усложнениями, а вообще нереально ожидать. Рефал ведь слабо типизированнъй язык, тогда как с Hindley–Milner-овскими языками как раз наоборот. И механизмы сопоставления у Рефала и у Hindley–Milner-а совсем разные. У каждого свои преимущества. А избежание необходимости усложнений Рефала, на мой взгляд, можно постичь, если реализовать небольшое его подмножество в виде библиотеки на ANSI C. Это даст, с одной стороны, компилятор, интерпретатор и REPL этого минимального и совсем простого Рефала для непосредственных применений, в том числе для изучения, обучения и всяких хобби занятий. С другой стороны, через интерфейс к ANSI C будет обеспечена возможность сочетать программирование на Рефале с программированием на почти любом другом языке. На этих других языках, а не в самом Рефале, и будут реализоваться все желательные языковые расширения. И то, и другое увеличило бы, помимо прочего, практическую доступность Рефала. Зависимости от операционной системы, например, вообще не будет — одна реализация языка на все системы, где есть C. Ещё одна возможность — реализовать тот самый небольшой Рефал в виде библиотеки на JavaScript, что обеспечило бы применимость и в вебприложениях, и (через Node) во многих других. Может, я что-то упускаю из вида, но именно такой путь развития Рефала мне кажется очень перспективным.
Re: Нужны ли вещественные числа в Рефале?
> Это было давно, во времена MS-DOS’а. Да, но я о ведь о сейчас говорю – как возможный способ реанимировать рисование в Рефале-6 (или ввести в любой Рефал). > Слишком оптимистичное мнение о SVG. Если график содержит миллиард точек, > то SVG (равно как и PostScript) получится необычайно толстым, в браузере > будет открываться годами... А вот растровая графика (например, PNG) -- > ей все равно, миллиард точек на графике или сто миллиардов (я имею в > виду размер файла и время загрузки его; создание PNG со ста миллиардами > точек, конечно же, в сто раз дольше, чем с миллиардом точек). Вы говорите о растровой графике, а я – о рисовании линий и фигур, о котором написал Аркадий Климов. Рисование линий и фигур я связываю с векторной графикой и никак не с «миллиардом точек». Впрочем, глубокие проблемы с обработкой миллиарда точек, как мне кажется, возникли бы и без всякой графики, будь то и растровой.
Re: Нужны ли вещественные числа в Рефале?
> У меня (Рефал-5λ) их нет, поскольку (а) мне они не требовались, (б) их нет в > Рефале-5, с которым должен быть совместим Рефал-5λ. Добавлять или не > добавлять — я думаю. Поэтому и спросил. А какого рода несовместимость появилась бы, если бы у Рефала-5λ были вещественные числа? Т.е., какие программы на Рефале-5 имели бы ошибочное (с точки зрения Рефала-5) истолкование в Рефале-5λ?
Re: Список всех простых чисел
> что хуже ("всего" в 1.55 раз) Эратосфена вычеркивания с объединением
Р.Хюи, соавтор (вместе с К.Айверсоном) и главный разработчик языка J,
наследника APL, считает, что разницу в скорости меньше чем в два раза
не следует считать разностью. И действительно, она вполне может быть
вызвана не самими алгоритмами, а другими обстоятельствами.
Re: Плохой суперкомпилятор Рефала как неплохой оптимизатор
> С: — Ну а шесть орехов? > М: — Не ку… а… ты меня совсем запутал. Я знаю только что куча это > когда много, а если мало — то это не куча. А больше я ничего не знаю. Изучал бы нечеткую логику, тогда знал бы: куча — с мерой μ, и не куча — с мерой 1-μ. Обе вещи вместе, а не «или, или» :)
