OberonCore :: - Содержание деятельности и его формализация

Короче, опубликована предварительная редакция графит-метода здесь.

Владислав Жаринов писал(а):

Здесь будут размышления и предложения по подходу Мейера к формализации в целом, языку, реализации в ЭйффельСтудии и по технологии.

А не проще ли один раз (и надолго) разобраться с тем, что такое проектирование... где заканчивается проектирование и начинается разработка... какие инструменты нужны для проектирования, а какие для разработки... где стыковка моделирования и проектирования... То есть, подойти к вопросам создания нового (как части жизненного цикла) более... системно... Тогда и по Дракону примерно 80% недоразумений исчезнет само по себе.
Примечание: на Мейера опираться не следует, IMHO.

Исходя из сказанного выше и в этом посте, кое-что и об этом:

Владимир Паронджанов писал(а):

...
[править] План развития и частичной унификации языков программирования
Этот раздел еще не написан
...

...
План м.б. таким:

...

...
Важна и ещё одна мысль:

Щедровицкий Г.П. в download/file.php?id=2067 на с. 193 писал(а):

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

...

В чём различие всех этих специалистов?.. Очевидно, в точке зрения на предметную область

alexus писал(а):

В чём различие всех этих специалистов?.. Очевидно, в точке зрения на предметную область

Думаю следующий пример близкий программистам будет кстати. Одну и ту же предметную область - "программы для компьютера" - видят по разному:
1) интегрированная среда разработки;
2) JIT компилятор;
3) среда времени исполнения.
Едва ли стоит стремится к тому, чтобы у (1), (2) и (3) была одна общая библиотека с единственным описанием модели программных объектов. Пожалуй лучше написать три таких библиотеки - три описания одного и того же, но с разными акцентами на требуемые особые свойства рассматриваемых объектов.

alexus писал(а):

...

Владислав Жаринов писал(а):

Узлам графа (исполнителям) сопоставлены процедуры реакции. А в программируемой системе часть процедур (для машинных исполнителей) имеет вид программ. Так?

Реакции?.. Возмущения-реакции - это термины пограничного слоя система-внешняя среда. Внутри системы есть задания/вызовы методов, которые система выдаёт/активирует, в рамках предопределённых схем. Программ, в привычном виде, нет, есть инструменты.
...

Вот наверное по реализации "искусственной" основной вопрос - как реализуются инструменты и выдача им заданий, а также описания схем?

Вот да, здесь и хотелось бы в духе сказанного в этом посте потихоньку формировать систему языков. Отсюда вопросы:

Владислав Жаринов писал(а):

Или модель каждого уровня ведётся независимо

Так модель-то одна на всю систему.

Если рассуждать с позиции языка, то он должен использоваться как интерфейс, который верхний уровень использует для общения с нижним уровнем.

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

Valery Solovey писал(а):

Владислав Жаринов писал(а):

Или модель каждого уровня ведётся независимо

Так модель-то одна на всю систему.

Модель системы одна, но она включает модели уровней...

Valery Solovey писал(а):

Интерфейс - это протокол/декларация. Эту декларацию можно использовать из разных языков. Например, из программы написанной на Pascal или Oberon можно взаимодействовать с подпрограммами ОС, написанной на С++, если соблюдаются протоколы обращения к подпрограммам ОС.

Valery Solovey писал(а):

Любая предметная область (даже выдуманная) - часть мироздания, а мироздание - это система...

alexus писал(а):

Valery Solovey писал(а):

Так модель-то одна на всю систему.

Модель системы одна, но она включает модели уровней...

Оно-то да, но разрабатываться отдельно друг от друга могут уровни, их реализации, а не модели. Модели уровней ограничены моделью всей системы (хотя бы частично). Нет?

alexus писал(а):

Valery Solovey писал(а):

Я просто хотел обобщить как понятие языка программирования как он есть сейчас, так и интерфейсов. Разве интерфейс в виде подпрограмм на Pascal и C, на которых написан уровень, не представляют собой язык общения с данным уровнем? Как бы было удобнее, если бы общение с уровнем представляло собой не последовательности вызовов подпрограмм (порядок имеет значение!), а удобный синтаксис... Например, представим синтаксис SQL для конкретных целей конкретного уровня.

alexus писал(а):

Valery Solovey писал(а):

Любая предметная область (даже выдуманная) - часть мироздания, а мироздание - это система...

А здесь я что-то не могу связать сообщения. У меня что-то неправильно?

Ну и теперь вопрос деловой к alexus - в русле темы. Уровни языков соответствуют уровням систем? Или выделяются иначе - как?

...
Тот язык хорош и удобен, на котором можно легко (ясно и формально) выразить смысл (уровня системы, в том числе). Благодаря этой тенденции появляются термины языка, то есть слова, в которых умещается целое понятие, представление, набор свойств/качеств и т.п. Но удобство использование терминов зависит от их "интуитивной" понятности. А это уводит в сторону словообразования... правил использования алфавита, то есть, к смыслу букв. Но кому это сегодня интересно...

alexus в viewtopic.php?p=69527#p69527 писал(а):

Вот попробовать бы и определить облик класса языков для каждого уровня... хотя бы в виде "лексика-правила"...

А Вы видите какие-то инвариантные к "предметке" и зависящие только от уровня требования к определению языка/семейства этого уровня?

Автор:	igor [ Вторник, 08 Ноябрь, 2011 17:38 ]
Заголовок сообщения:	Re: О методе и средствах визуализации
Владислав Жаринов писал(а): Короче, опубликована предварительная редакция графит-метода здесь. Судя по документу, одинарных слов уже явно не хватает

Автор:	Владислав Жаринов [ Четверг, 10 Ноябрь, 2011 08:32 ]
Заголовок сообщения:	Re: Содержание деятельности и его визуализация
Ну, не у меня одного (подозреваю, что Вы имеете в виду слова через дефис). Более интересно, правильно ли определены такие вещи, как доминатор и рецессор здесь. Ибо надо уже, чтобы визуализация и для детей не всегда "накладывала на математику гриф "до 16-ти"", а наоборот... Как для текстовой записи в практике Виталия Валерьевича... или Фёдора Васильевича... В т.ч. чтобы "они программировали", а не "их программировали"...

Автор:	Владислав Жаринов [ Среда, 04 Январь, 2012 09:52 ]
Заголовок сообщения:	Подход к структуризации деятельности
alexus в viewtopic.php?p=69120#p69120 писал(а): Владислав Жаринов писал(а): Здесь будут размышления и предложения по подходу Мейера к формализации в целом, языку, реализации в ЭйффельСтудии и по технологии. А не проще ли один раз (и надолго) разобраться с тем, что такое проектирование... где заканчивается проектирование и начинается разработка... какие инструменты нужны для проектирования, а какие для разработки... где стыковка моделирования и проектирования... То есть, подойти к вопросам создания нового (как части жизненного цикла) более... системно... Тогда и по Дракону примерно 80% недоразумений исчезнет само по себе. Примечание: на Мейера опираться не следует, IMHO. IMHO, соглашусь - по части методологии формализации. Так, у него всё так же непонятно отношение "программ" к "системам" - уже говорил. И сам по себе подход к отражению реальности как информоделей (исполнимый прогтекст + контрактные спецификации) м.б. и неплох - но объектный взгляд вызывает вопросы... В то же время есть и вроде удачные вещи - как изложение основ логики. Да и то, что говорится об инвариантах исполнения - разве не имеет смысл?.. Насчёт один раз разобраться - конечно, проще. Собственно, для этого эта ветка и задумывалась. Давайте вернёмся к вопросу... Ибо, хотя я и предложил некое конкретное наполнение "унификации языков" в таком виде: Владислав Жаринов в viewtopic.php?f=62&t=3303&start=20#p68767 писал(а): Исходя из сказанного выше и в этом посте, кое-что и об этом: Владимир Паронджанов писал(а): ... [править] План развития и частичной унификации языков программирования Этот раздел еще не написан ... ... План м.б. таким: 1) Определять полный, "графитный" синтаксис языков - графы как исчисление, их текстовую разметку, скажем, через РБНФ (в пределе - информатизованный определением условий применения РБНФ-продукций). Так я делаю для графит-инфор-языков, так начал и Э. Ильченко для "промежуточного формата". 2) Выделять "общее семантическое ядро" ряда инфор-языков, как делает группа В. Лаптева. И формировать для неё изоморфную граф-базированную форму представления. 3) Идти к предметно-инвариантной семантике, как предлагает alexus. И для неё делать стандартное определение. ... - но прекрасно понимаю справедливость и для данного случая этого замечания: Владислав Жаринов в viewtopic.php?f=75&t=3126&start=20#p68088 писал(а): ... Важна и ещё одна мысль: Щедровицкий Г.П. в download/file.php?id=2067 на с. 193 писал(а): Как известно, в основании нашей современной педагогики лежит принцип обобщения передового опыта. Он был выдвинут в 30-е годы и в тех условиях был правильным и помог поднять педагогику. Но сейчас перед нами стоят принципиально новые задачи, и в этих условиях принцип обобщения опыта уже вреден, он стал тормозом дальнейшего развития педагогики. И это понятно, ибо когда подобный принцип начинает определять научно-исследовательскую работу, то это приводит к уничтожению самой науки. Обобщая опыт использования керосиновой лампы, нельзя прийти к электричеству. И наоборот, чтобы получить электрическую лампочку, нужно предварительно научно исследовать природу и законы электрических и электромагнитных явлений. ... Т.е. обобщением синтаксиса существующих языков мы отнюдь не выходим на новый. Посему никакого естественного перехода от 2) к 3) не предполагается - более того, первый совершенно не обязан быть необходимым условием (и частью последовательности)... В т.ч. касается и позднее написанного В.Д. содержания плана.

Автор:	Сергей Губанов [ Пятница, 06 Январь, 2012 00:16 ]
Заголовок сообщения:	Re: Подход к структуризации деятельности
alexus писал(а): В чём различие всех этих специалистов?.. Очевидно, в точке зрения на предметную область Думаю следующий пример близкий программистам будет кстати. Одну и ту же предметную область - "программы для компьютера" - видят по разному: 1) интегрированная среда разработки; 2) JIT компилятор; 3) среда времени исполнения. Едва ли стоит стремится к тому, чтобы у (1), (2) и (3) была одна общая библиотека с единственным описанием модели программных объектов. Пожалуй лучше написать три таких библиотеки - три описания одного и того же, но с разными акцентами на требуемые особые свойства рассматриваемых объектов.

Автор:	alexus [ Пятница, 06 Январь, 2012 11:14 ]
Заголовок сообщения:	Re: Подход к структуризации деятельности
Сергей Губанов писал(а): alexus писал(а): В чём различие всех этих специалистов?.. Очевидно, в точке зрения на предметную область Думаю следующий пример близкий программистам будет кстати. Одну и ту же предметную область - "программы для компьютера" - видят по разному: 1) интегрированная среда разработки; 2) JIT компилятор; 3) среда времени исполнения. Едва ли стоит стремится к тому, чтобы у (1), (2) и (3) была одна общая библиотека с единственным описанием модели программных объектов. Пожалуй лучше написать три таких библиотеки - три описания одного и того же, но с разными акцентами на требуемые особые свойства рассматриваемых объектов. Вполне возможно. Только важно, чтобы все библиотеки имели один источник/получались из одного источника. Под источником понимается целостное концептуальное представление.

OberonCore https://forum.oberoncore.ru/

Содержание деятельности и его формализация https://forum.oberoncore.ru/viewtopic.php?f=86&t=3853	Страница 2 из 2

Автор:	alexus [ Суббота, 07 Январь, 2012 23:41 ]
Заголовок сообщения:	Re: Содержание деятельности и его визуализация
Владислав Жаринов писал(а): alexus писал(а): ... Владислав Жаринов писал(а): Узлам графа (исполнителям) сопоставлены процедуры реакции. А в программируемой системе часть процедур (для машинных исполнителей) имеет вид программ. Так? Реакции?.. Возмущения-реакции - это термины пограничного слоя система-внешняя среда. Внутри системы есть задания/вызовы методов, которые система выдаёт/активирует, в рамках предопределённых схем. Программ, в привычном виде, нет, есть инструменты. ... Вот наверное по реализации "искусственной" основной вопрос - как реализуются инструменты и выдача им заданий, а также описания схем? Схемы обсуждались здесь: Заголовок: Оберон и проектирование систем Инструменты обсуждали здесь: Заголовок: Рефакторинг: есть ли ему место в разработке систем? О системах говорилось здесь: Заголовок: Языки системы и система языков

Автор:	Владислав Жаринов [ Воскресенье, 08 Январь, 2012 10:13 ]
Заголовок сообщения:	Re: Содержание деятельности и его визуализация
Вот да, здесь и хотелось бы в духе сказанного в этом посте потихоньку формировать систему языков. Отсюда вопросы: * Можно ли понимать так, что эта система должна включать три класса языков - по одному для нижнего, промежуточного и верхнего уровня? условно говоря - ПРОЛОГ, ЛИСП, Оберон/КП ? * Следует ли понимать, что реализация системы выглядит как определение хотя бы по одному языку в каждом классе и правил трансляции описания вышележащего уровня в следующий? Т.е. в итоге имеем императивную форму для всей модели (в частности, это м.б. программная реализация)? Или модель каждого уровня ведётся независимо, и высокоуровневые представления имеют отдельные "нижние" реализации, "спускающие управление" при работе реализованной системы по иерархии (ПРОЛОГ-единицы - ЛИСПовским, а те - Обероновским), причём все, ессно, могут иметь вид готовых машинных программ? * Как должна обобщаться эта архитектура на число уровней, большее 3-х? увеличением числа промежуточных уровней?

Автор:	alexus [ Воскресенье, 08 Январь, 2012 19:51 ]
Заголовок сообщения:	Re: Содержание деятельности и его визуализация
Владислав Жаринов писал(а): Вот да, здесь и хотелось бы в духе сказанного в этом посте потихоньку формировать систему языков. Отсюда вопросы: * Можно ли понимать так, что эта система должна включать три класса языков - по одному для нижнего, промежуточного и верхнего уровня? условно говоря - ПРОЛОГ, ЛИСП, Оберон/КП ? * Следует ли понимать, что реализация системы выглядит как определение хотя бы по одному языку в каждом классе и правил трансляции описания вышележащего уровня в следующий? Т.е. в итоге имеем императивную форму для всей модели (в частности, это м.б. программная реализация)? Или модель каждого уровня ведётся независимо, и высокоуровневые представления имеют отдельные "нижние" реализации, "спускающие управление" при работе реализованной системы по иерархии (ПРОЛОГ-единицы - ЛИСПовским, а те - Обероновским), причём все, ессно, могут иметь вид готовых машинных программ? * Как должна обобщаться эта архитектура на число уровней, большее 3-х? увеличением числа промежуточных уровней? Языков может быть больше трёх. Например, специализированные языки, типа SQL или языки/протоколы сетевого взаимодействия/общения... Но если говорить предметно, то есть три базовых класса языков: язык действия (императивные и функциональные языки), язык мысли (логика и...) и язык чувства (искусство). По мере роста систем, программных в том числе, мы постепенно переходим ко второй группе языков. Большие системы (3+) стоят дорого и способствуют решению жизненно важных задач, поэтому содержат не только действующие элементы, но и элементы самоконтроля (контроль собственного состояния) и контроля состояния внешней/окружающей среды. Здесь без логики не обойтись. Если на начальном этапе развития достаточно просто знать своё состояние и состояние внешней среды, то потом потребуется контролировать динамику изменения состояний, соответствие (внутреннего и внешнего), частоту смены состояний (внутри и вовне), скорость переходных процессов, установление причин и следствий изменений и т.д. и т.п. Другими словами, системы должны будут научиться чувствовать, а затем и пред-чувствовать. И для передачи чувственных образов потребуются развитые языки, точно также, как языки нужны для передачи мыслей и действий. Если кто-то думает, что разные сферы искусства появились "сами собой"... "случайно", то отнюдь... И науки появились совершенно закономерно, как и полезная (индивидуальная и совместная) деятельность людей. Но это так... повод к размышлению. Для современных систем (3+) достаточно двух базовых языковых классов (деятельность + зачатки логики). Каждый уровень системы независим от других уровней в плане своего создания и развития. Можно провести аналогию... Есть чипмейкеры (создатели элементной базы), а есть те, кто пишет операционные системы (ОС) для работы с "железом". Но очередная версия операционной системы следует за пожеланиями пользователей, а не за новыми чипами. Совместимость чипов с новой ОС определяется протоколами/интерфейсами, на основе которых создаются драйвера. Пока уровень развития недостаточно высок, что приводит к различным коллизиям при взаимодействии устройств и ОС. Но по мере развития, вопросами согласования будут заниматься отдельные органы стандартизации, которые принимают и утверждают протоколы взаимодействия, и контролируют их исполнение. Чипмейкеры успешно продвигают эту модель, в отличие от производителей ОС. Но подвижки есть. Независимость уровней систем, открытость/доступность описаний интерфейсов - это залог успешного (быстрого, экономичного - эффективного) развития систем. И, наоборот, закрытость интерфейсов, связность уровней - это залог их краха. В свою очередь, независимость уровней + открытость интерфейсов открывает перед разработчиками перспективу в свободе выбора средств реализации любого уровня (эффективность разработки и реализации при установленных/заданных параметрах качества). Моноязычные системы - это нонсенс... в перспективе. Промежуточные уровни не должны появляться, это ломает архитектуру системы (возможно, речь идёт о подуровнях). Подуровни не имеют своего интерфейса, они должны соответствовать интерфейсу своего уровня. Введение подуровней - это нормальный процесс внутреннего развития уровня. А рост самой системы может быть только вверх (и иногда в процессе проектирования - вниз, за счёт дополнительной декомпозиции). В свою очередь, рост вверх, означает появление новых целей и задач, т.е. вычленения из внешней среды новых функций и... ресурсов.

Автор:	Valery Solovey [ Среда, 11 Январь, 2012 18:56 ]
Заголовок сообщения:	Re: Содержание деятельности и его визуализация
alexus писал(а): Valery Solovey писал(а): Владислав Жаринов писал(а): Или модель каждого уровня ведётся независимо Так модель-то одна на всю систему. Модель системы одна, но она включает модели уровней... Оно-то да, но разрабатываться отдельно друг от друга могут уровни, их реализации, а не модели. Модели уровней ограничены моделью всей системы (хотя бы частично). Нет? alexus писал(а): Valery Solovey писал(а): Если рассуждать с позиции языка, то он должен использоваться как интерфейс, который верхний уровень использует для общения с нижним уровнем. Интерфейс - это протокол/декларация. Эту декларацию можно использовать из разных языков. Например, из программы написанной на Pascal или Oberon можно взаимодействовать с подпрограммами ОС, написанной на С++, если соблюдаются протоколы обращения к подпрограммам ОС. Я просто хотел обобщить как понятие языка программирования как он есть сейчас, так и интерфейсов. Разве интерфейс в виде подпрограмм на Pascal и C, на которых написан уровень, не представляют собой язык общения с данным уровнем? Как бы было удобнее, если бы общение с уровнем представляло собой не последовательности вызовов подпрограмм (порядок имеет значение!), а удобный синтаксис... Например, представим синтаксис SQL для конкретных целей конкретного уровня. alexus писал(а): Valery Solovey писал(а): И чем выше уровень - тем (желательно) больше степень декларативности языка. О каких-то конкретных существующих языках тут говорить нет смысла, потому что в конечном итоге, на самом верху это должен быть язык предметной области (максимально приближенный к предметной области). А все те слои, на которые была разделена система, должны были подвести к верхнему языку. Любая предметная область (даже выдуманная) - часть мироздания, а мироздание - это система... А здесь я что-то не могу связать сообщения. У меня что-то неправильно?

Автор:	alexus [ Четверг, 12 Январь, 2012 21:16 ]
Заголовок сообщения:	Re: Содержание деятельности и его визуализация
Valery Solovey писал(а): alexus писал(а): Valery Solovey писал(а): Так модель-то одна на всю систему. Модель системы одна, но она включает модели уровней... Оно-то да, но разрабатываться отдельно друг от друга могут уровни, их реализации, а не модели. Модели уровней ограничены моделью всей системы (хотя бы частично). Нет? Нет - это слишком категорично. Один и тот же уровень может работать с разными системами/принадлежать разным системам/разделяться между системами. Это отчасти объясняет самостоятельность уровней, в том числе и их самостоятельное/независимое моделирование. Мы привыкли к тому, что система создаётся в одном месте и централизовано, но так будет не всегда. Чем дальше будет развиваться проектное производство (производство ПО, в том числе), тем чётче будет специализация/разделение труда. Это приведёт к тому, что каждый уровень (и даже подуровень) системы будет создаваться отдельными коллективами. Valery Solovey писал(а): alexus писал(а): Valery Solovey писал(а): Если рассуждать с позиции языка, то он должен использоваться как интерфейс, который верхний уровень использует для общения с нижним уровнем. Интерфейс - это протокол/декларация. Эту декларацию можно использовать из разных языков. Например, из программы написанной на Pascal или Oberon можно взаимодействовать с подпрограммами ОС, написанной на С++, если соблюдаются протоколы обращения к подпрограммам ОС. Я просто хотел обобщить как понятие языка программирования как он есть сейчас, так и интерфейсов. Разве интерфейс в виде подпрограмм на Pascal и C, на которых написан уровень, не представляют собой язык общения с данным уровнем? Как бы было удобнее, если бы общение с уровнем представляло собой не последовательности вызовов подпрограмм (порядок имеет значение!), а удобный синтаксис... Например, представим синтаксис SQL для конкретных целей конкретного уровня. SQL - это хороший пример декларативного языка, языка описания сущностей и связей между ними. Но он не пригоден для описания действий. Для этого вводят специальные конструкции на некотором диалекте, для написания триггеров, хранимых процедур, исполнительских блоков и пр. Но речь не об этом... Мне бы хотелось отметить, что архитектура системы, структура уровней и интерфейсов - это самостоятельная задача для проектировщиков, она не должна быть связана с выбором языков разработки. Наоборот, язык разработки должен соответствовать своему месту (уровню, задаче). При этом нельзя сбрасывать со счетов плеяду языков, предназначенных для решения узкого круга специализированных задач. Для проектировщиков и разработчиков язык - это инструмент. И попытки унификации "всеобщего языка" порой очень напоминают попытки скрестить лопату с хирургическим скальпелем... Valery Solovey писал(а): alexus писал(а): Valery Solovey писал(а): И чем выше уровень - тем (желательно) больше степень декларативности языка. О каких-то конкретных существующих языках тут говорить нет смысла, потому что в конечном итоге, на самом верху это должен быть язык предметной области (максимально приближенный к предметной области). А все те слои, на которые была разделена система, должны были подвести к верхнему языку. Любая предметная область (даже выдуманная) - часть мироздания, а мироздание - это система... А здесь я что-то не могу связать сообщения. У меня что-то неправильно? Специалистам, которые работают с системой, нужны и декларативные языки, и императивные языки, и языки исчисления предикатов... просто в силу разности задач... решаемых в рамках системы. Означает ли сказанное, что нет и не может быть "общего языка"?.. Нет, не означает. Понятие языковой общности не основано на каких-то общих конструкциях полезных на любом уровне, при решении любых задач... Этого нет и быть не может. Общность возможна только на основе семантики... на основе понимания того, что "малое в большом, а большое в малом". Хорошим примером мог бы служить древнерусский язык, где смыслом (ключевым/основополагающим/отражающим мироздание) наделялась каждая буква алфавита! Из осмысленных букв складывались частные осмысленные слова, из слов - предложения. Древние понимали, что утрата смысла хотя бы в одном месте, на одном из этапов, делает бессмысленными любые построения. Для нас буквы - это просто звук... увы...

Автор:	Владислав Жаринов [ Воскресенье, 15 Январь, 2012 08:09 ]
Заголовок сообщения:	Уровни систем и уровни языков
Ну и теперь вопрос деловой к alexus - в русле темы. Уровни языков соответствуют уровням систем? Или выделяются иначе - как?

Автор:	alexus [ Воскресенье, 15 Январь, 2012 11:13 ]
Заголовок сообщения:	Re: Уровни систем и уровни языков
Владислав Жаринов писал(а): Ну и теперь вопрос деловой к alexus - в русле темы. Уровни языков соответствуют уровням систем? Или выделяются иначе - как? Правильнее сказать - должны соответствовать, в нашей (программёрской) жизни чаще (почти всегда!) бывает так, что не соответствуют. Вы правильно ставите многие вопросы (об информации и смысле, в частности). Тот язык хорош и удобен, на котором можно легко (ясно и формально) выразить смысл (уровня системы, в том числе). Благодаря этой тенденции появляются термины языка, то есть слова, в которых умещается целое понятие, представление, набор свойств/качеств и т.п. Но удобство использование терминов зависит от их "интуитивной" понятности. А это уводит в сторону словообразования... правил использования алфавита, то есть, к смыслу букв. Но кому это сегодня интересно...

Автор:	Владислав Жаринов [ Понедельник, 16 Январь, 2012 07:51 ]
Заголовок сообщения:	О системе языков
А Вы видите какие-то инвариантные к "предметке" и зависящие только от уровня требования к определению языка/семейства этого уровня?

Автор:	alexus [ Среда, 18 Январь, 2012 07:07 ]
Заголовок сообщения:	Re: О системе языков
Владислав Жаринов писал(а): А Вы видите какие-то инвариантные к "предметке" и зависящие только от уровня требования к определению языка/семейства этого уровня? Владислав, я пока занят... но вопрос интересный, чуть позже я на него постараюсь ответить.

Страница 2 из 2	Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/

Автор:	Владислав Жаринов [ Среда, 18 Январь, 2012 10:37 ]
Заголовок сообщения:	Re: Содержание деятельности и его визуализация
Вероятно, я тоже пока буду занят (а то много активности было в сети ), но позже обязательно постараюсь ознакомиться с Вашими ответами. Удачи!