OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 16:00

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 95 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
СообщениеДобавлено: Вторник, 06 Сентябрь, 2011 05:33 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Alexey_Donskoy писал(а):
Ну, тут в теме априори утверждалось, что переделывать каркас, оформленный в виде АПИ, не в пример легче, чем в форме языка. Хотя вот я не улавливаю, в чём вообще между ними принципиальная разница? :D
А нет разницы... принципиальной... Удобство работы (эргономика) + документирование... вот и все требования. Поэтому каждый мажет то, что ему нравится...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Сентябрь, 2011 05:49 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Илья Ермаков писал(а):
Отличные цели, но такая постановка задачи невообразимо сложна для одного, интегрированного продукта.
IMHO, проблема не лежит в плоскости один-много продуктов. Продукт может быть и один, а поддержка многосторонней. Вот только организовать такую поддержку трудновато... нужен такой авторитет... или такой тупик... что дальше/больше некуда.
Илья Ермаков писал(а):
Даже в сфере автоматизации предприятий (где автоматизируется не умственный труд, а более приземлённые процессы) проекты монолитных систем проваливались, а успешные внедрения пошли только тогда, когда признали необходимость автоматизации посредством внедрения ряда слабосвязанных систем.
Любые элементы системы являются слабосвязанными... по определению. При этом сама система может быть вполне себе... монолитной. А внедряется на предприятиях по-прежнему всё подряд и монолитные системы и сервис-ориентированные системы. (Врагу бы не пожелал поддерживать целостность данных в SOA, там даже банальной транзакционности нет, а без доверия к данным... любая информационная система... вроде новогодней мишуры... глаз радует, а пользы никакой...).
Илья Ермаков писал(а):
Это не значит, что нет системообразующей модели и ядра (а то Alexus сейчас съест меня на второй завтрак :) ), но что каждая сторона автоматизируется с абстрагированием от других, со своей частной детальной моделью - и взаимодействует с другими только через обмен данными.
Так обмен данными тоже... проектируется (по-хорошему... до начала написания частей). И абстрагирование хорошо до известных пределов, которыми, в частности, является понимание того, что "часть должна встраиваться в целое", то есть должна обладать необходимыми интерфейсами, технологиями, поддержкой протоколов, структур и пр. (это, как минимум...)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Сентябрь, 2011 07:13 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко в viewtopic.php?p=65321#p65321 писал(а):
Илья Ермаков в viewtopic.php?p=65316#p65316 писал(а):
Сергей Прохоренко писал(а):
В будущем программирование без структурного редактора будет похоже на изучение в школе информатики без доступа к компьютеру.


Кстати, аналогия неверная.


Совершенно согласен. Поскольку нынешняя школьная информатика не имеет ни цели, ни ясного предмета изучения, и столь же бесполезна, как школьный курс ОБЖ. Но, во-первых, другой аналогии не нашлось. А во-вторых, несмотря на свою смысловую неправильность, она создает правильную эмоциональную окраску. Подсознательно же все понимают, что информатика нужна постольку, поскольку она применяется на компьютере, и чем дальше она будет от компьютера, тем сомнительнее ее польза.
...
Вывод можно, пожалуй, уточнить. Нынешняя в типичном ГОС-варианте - да, не имеет ни того, ни другого... :) Но в определении Белошапки - всё становится на места. И оказывается, что информатика - дисциплина формального анализа произвольной "предметки". И не привязана в своей основе "к компу". Потому что анализ проводится не только для того, чтобы "запрограммировать". Но и для тех целей, которые тут же очертил Алексей:
Alexey_Donskoy в viewtopic.php?f=57&t=3557&start=20#p65262 писал(а):
...
Драконограф писал(а):
А что имеется в виду? Информатизация обозначений по ЕСКД (и неимперативных по ЕСТД)?
Не настолько примитивно-утилитарно, конечно.
Имеются в виду не сами языки-стандарты, и даже не создание инструментов для работы с этими языками, а подходы к созданию этих языков.
Возникли они давно, и прямая их информатизация пока что приводит к не очень привлекательному результату.
Надо обновлять (а то и переписывать заново) подобные стандарты, с учётом нынешних и перспективных задач.
И работа эта по сути - работа с языком представления предметной области, то есть DSL...

Наверное, не надо уточнять, что такая информатизация "в широком смысле" относится не только к случаю, когда эти языки реализованы в АИС - но и когда на них говорят "в карандаше на бумаге" (ну и устно). ;)
И работа с инвариантами (опять же не только в целях программирования) - базовый метод этой дисциплины.
А у Перегудова чётко показано, "для чего" - чтобы создать базис формально проанализированного в интересах любых иных дисциплин (и их автоматизации - опять же как частный случай). Ну, ессно, объект анализа - не только представления, но и процессы, не только сущности, но и отношения.
    Не будет умения анализа - нет возможности для того же "реинжиниринга" - опять же необязательно предусматривающего внедрение новых компов/софта. Помнится, у Хаммера классический пример - как раз на сокращение бизнес-процесса (работы со счетами) - и ряда рабочих мест и категорий документов... ;)
А в основе, как верно опять же напомнил Алексей - процесс моделирования, которому предшествует (и сопутствует) структуризация.
И пример попытки интегрировать сходные представления - как раз курс Симоновича. Некоторые соображения, как это развить - в этом посте, если интересно. ;)

Короче, как говорил Фёдор Васильевич - "не зря веточка". :D Говорил уже в этом посте о "великих информатиках", которые проводили формальный анализ и "работу над языком и методом предметки" задолго до появления информашины (а иногда - и представления о ней - которым надо считать "аналитическую машину" Чарльза Бэббиджа с условным переходом Августы Ады Лавлейс) - а иной раз в областях где автоматизации нет и сегодня. ;) Но здесь ограничусь более "научно-техническим" примером.
    Когда Лука Пачоли в 1494 году выпустил свой "Трактат о счетах и записях" - он на доступном в то время математическом уровне (не забываем о стадийности процесса!) провёл информатизацию "предметки" учёта движения ценностей. В результате установил единый метод отражения движения - и адекватную ему структуру данных. Ничего, что это всё предназначалось для бумажной и ручной переработки данных?.. :wink:
    Пришло время - и в рамках вновь появившегося аппарата матричной алгебры (который ввёл, говоря словами alexus, "новые буквы" - как сущности и операции над ними) этот метод стало возможным сформулировать как матричную задачу взаимных расчётов.

Это всё к тому, что главная задача курса информатики - научить этому самому "общему формальному анализу". В более узком смысле - тому, о чём говорил Алексей применительно к языкам. А "выход на комп" - как одно из приложений анализа, доведённого до конечного уровня - наряду с "ручным" командным представлением (для "человека-как-машины"). Лишь владея этим, можно нормально подходить и к формулировке языков для того же структурного редактора.


Последний раз редактировалось Владислав Жаринов Вторник, 06 Сентябрь, 2011 07:49, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Сентябрь, 2011 07:40 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко в viewtopic.php?p=65323#p65323 писал(а):
...
Он будет гораздо проще систем управления предприятием или банком, где сотни менеджеров и десятки крупных акционеров с противоположными интересами, сотни технологических процессов и внешних связей, хаотичное управление и десятки информационных систем различных поколений. Структурный редактор - это техническая система, то есть он заведомо проще, прозрачнее и обозримее любой социальной системы (предприятие, банк).
...
"Просто редактор" - да, можно рассматривать в аспекте целевого назначения сам по себе, без "операторской триады" (пользователь-сервисник-администратор). В аспекте эргономики, ессно, любую сколь-нибудь сложную ТС не следует отрывать от человека-участника её полного ЖЦ - для чего и инжпсихология - но это уже часть функционального назначения, и мы сейчас, конечно, не об этом.
Такую же систему, которая "работает с семантикой и прагматикой" - т.е. интеллекто-имитирующую - уже нужно брать во взаимосвязи с человеком - как социотехническую (кстати, таковы же и банк, и <промышленное> предприятие типичные). Там тоже будут "противоположные интересы" - в виде неопределённости человеческого опыта в "предметке". Которая при отчуждении и передаче в семредактор выразится, допустим, в конфликтующих правилах базы знаний (и/или определениях одной предметной сущности).
Определённая концепция построения такого редактора ("вводящая в человеческие рамки" по Мичи и Джонстону) - да, при грамотном воплощении сделает его как подсистему прозрачней и обозримей для человека-оператора. Но говорить о "гораздой простоте" такого редактора самого по себе - как изделия программной инженерии - я бы не стал... Кстати, то же относится и к простоте его как продукта - не так-то просто реализовать удобные и гарантоспособные механизмы, скажем, для поддержки разрешения тех же конфликтов "отчуждённой неопределённости"...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Сентябрь, 2011 07:47 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Alexey_Donskoy в писал(а):
Драконограф писал(а):
Попробую изложить, как понял суть. Вы называете моделью на предметном языке опять же "внешнюю схему" задачи. Но информатизованную - т.е. однозначно преобразуемую в структуру данных, с которой может работать алгоритм "решения различных задач".
Вообще-то, понятие модели шире. Это всего лишь частный случай, который возможен при использовании такого средств механизации творческого труда, как комп ;)
Я согласен с Усовым, когда он говорит про внутренние образы... Но это ведь тоже максима; а в реальной жизни так или иначе всё равно приходится решать задачи, и хотеть механизировать сей труд ;)
Поэтому как отправная точка - имхо, годится.
Может, все методики и от лукавого, но они помогают... когда помогает "комбинаторный подход"...
...
В каком-то смысле ответил в этом посте - в духе в основном согласия насчёт частного случая. :) Широта возникает именно в силу того, что модель м.б. предназначена не только "абстрактной машине" - а человек может не только исполнять алгоритм, но и выстраивать его - т.е. реализовывать "эвроритм". ;)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Сентябрь, 2011 08:42 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Alexey_Donskoy в viewtopic.php?p=65315#p65315 писал(а):
...
Драконограф писал(а):
Как итог - императив и декларатив никуда не деваются. Нам по-прежнему, чтобы поручить решение этой задачи не естественному интеллекту, а машине (информатической, сиречь для переработки данных, сиречь формально-языковой), надо сделать "нейтральную схему". В её системе команд - или на "нейтральном" языке более высокого уровня. Прогязыке - допустим, на том же Обероне (расширенном теми или иными библиотечными средствами)...
Мне кажется, здесь Вы торопитесь (также, как и Info21, говоря о "приматическом реагировании" на слово "программа") ;)
Необходимо учитывать, что всё сказанное Вами, относится к очень узкоё задаче - разработке инструмента. То, что большинство здесь присутствующих являются программистами и так или иначе причастны к этой узкой задаче, мало что меняет.
Ну да... сам ведь говорил в том же смысле в этом посте хотя бы... да и Рыжикова в этом посте приводил именно как пример предложения базиса "предметных языков" для информатизации... а поди ж ты, сбился на более узкое понимание... ;)
Alexey_Donskoy в viewtopic.php?p=65315#p65315 писал(а):
...
Я-то говорил в более общем смысле. Есть предметная область, есть специалист и есть инструмент для механизации его труда (например, комп с соответствующим софтом).
Аналогично плотнику, использующему топор, специалист использует комп. При этом в целом ряде случаев специалист строит свою формальную модель на DSL, предлагаемом инструментальным средством. Поэтому в том случае, когда инструментом является комп с софтом, процесс работы специалиста с инструментом можно назвать программированием.

В этом смысле, кстати, процесс работы программиста абсолютно ничем не отличается от процесса работы вышеописанного специалиста. Это просто частный случай.

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

И как следствие - чтобы редактор был, нужен всё-таки импер-инфор-язык (скажем, Оберон - или язык структурного редактора) - и его реализация (скажем, ББ - или прототип того же редактора). Другое дело - что если этот язык понимать в реализации как один из возможных "предметных" - можно редактор сделать постепенно "мультипредметным". И одновременно использовать его "предметные" возможности на пользу программирования - причём и самого редактора (о чём и говорилось в этом посте). :)
    Но для этого в документах редактора нужно отражать разные виды знания - структурированные, напр. согласно этой классификации. Как - нужно продумывать.
    Ясно лишь, что такая структуризация первична по отношению к делению содержания документа по "предметкам". Почему - уже говорил и alexus, и Потопахин - ещё см. в этом посте.
    Тем более, что в одном массиве (проектном документе или встроенной БД) м.б. данные, отчуждающие знание по разным "предметкам" - и сам массив может служить источником по разным "предметкам" (и, соответственно, работать с разными языками редактора).

Пока что мы видим в группе Валерия - см. в этом посте - продумывание концепции деления "по языкам". Это равно необходимо - и взаимосвязано с делением по общности/формам знаний, формализуемых в редакторе. Для графит-метода у меня представление вырисовывается - отсюда и сказанное в этом посте. Но здесь многое будет по-другому - и из-за предполагаемой текстобазированности документов, и из-за "замаха" на имитацию интеллекта в предметных областях (и работу со всеми проектными языками внутри самого редактора - фактически подмену редактирующих функций любых СА[ПР] в соответствующей "предметке")... И тут надо уже учитывать и сказанное в этом посте (по п.2 - п.1 уже, как я вижу, предполагается).
    Кстати, отсюда вопрос - а обмен данными с этими СА предполагается? Не будет же редактор, например, будучи "домайно-специализированным" на конструировании материальных изделий машиностроения, заниматься за Автокад геометрическим моделированием или расчётом конструкций?.. ;)
Alexey_Donskoy в viewtopic.php?p=65315#p65315 писал(а):
...
Драконограф писал(а):
Однако теперь понятнее, что Вы говорили об унификации предметных языков. Если я верно понял, Вы хотели бы видеть структурный редактор именно способным вести "внешнюю схему" задачи (как частный случай, с которого можно начинать - из "предметки" программирования) и воспринимать и отрабатывать разные её постановки (насколько это допускает текущее состояние модели "предметки"). Тогда да, нужны лексика и правила "внешней схематизации предметки" в самом редакторе. Так?
Ну наконец-то! Ура! :)

Я всё время вспоминаю, как Седов 20 лет назад про это говорил... А воз и ныне там...
А чё там говорить-то... читая тех же Лената и Мичи с Джонстоном в момент их публикации, и я думал о подобном... да и любой знакомившийся с такой качественной популярной литературой, мог, поразмыслив, прийти к тому же... :) Да задачка не так проста... очевидно, в силу того же "текущего состояния отрасли"... ;)


Последний раз редактировалось Владислав Жаринов Вторник, 06 Сентябрь, 2011 09:40, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Сентябрь, 2011 08:55 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus в viewtopic.php?p=65328#p65328 писал(а):
...
Илья Ермаков писал(а):
Это не значит, что нет системообразующей модели и ядра (а то Alexus сейчас съест меня на второй завтрак :) ), но что каждая сторона автоматизируется с абстрагированием от других, со своей частной детальной моделью - и взаимодействует с другими только через обмен данными.
Так обмен данными тоже... проектируется (по-хорошему... до начала написания частей). И абстрагирование хорошо до известных пределов, которыми, в частности, является понимание того, что "часть должна встраиваться в целое", то есть должна обладать необходимыми интерфейсами, технологиями, поддержкой протоколов, структур и пр. (это, как минимум...)
Проектируется... правда, иногда как раз и получается, что часть нужно встроить в уже существующее... отсюда и мой вопрос по обмену данными в предыдущем посте... Вы такие вещи имели в виду?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Сентябрь, 2011 09:08 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Валерий Лаптев писал(а):
Илья Ермаков писал(а):
Отличные цели, но такая постановка задачи невообразимо сложна для одного, интегрированного продукта.
Это не значит, что нет системообразующей модели и ядра (а то Alexus сейчас съест меня на второй завтрак :) ), но что каждая сторона автоматизируется с абстрагированием от других, со своей частной детальной моделью - и взаимодействует с другими только через обмен данными.

Вот этого мне пока от пацанов добиться в полной мере не удалось.
Я вижу модель программы - для интерпретатора, и модель программы - для структурного редактора. Да, у них есть нечто общее.
А пацаны пока совсем разделить не могут. Из-за того, что представляют программу и там и там в виде одного и того же семантического дерева. Я тут уже писал о проблемах с архитектурой в редакторе - макароны на вьюхе.
Если удастся мне додавить разделение моделей, то открываются весьма радужные перспективы, например, в реализации разных DSL. Просто пишется подсистема над обеими моделями - и все работает на счет раз... :)


А в чем по-вашему разница между моделью программы для интерпретатора и моделью программы для структурного редактора? Мне кажется, что первое есть просто основная часть второго. См. рисунок:
Вложение:
Архитектура PureBuilder.png
Архитектура PureBuilder.png [ 12.33 КБ | Просмотров: 15515 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Сентябрь, 2011 09:54 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
alexus в viewtopic.php?p=65328#p65328 писал(а):
...
Так обмен данными тоже... проектируется (по-хорошему... до начала написания частей). И абстрагирование хорошо до известных пределов, которыми, в частности, является понимание того, что "часть должна встраиваться в целое", то есть должна обладать необходимыми интерфейсами, технологиями, поддержкой протоколов, структур и пр. (это, как минимум...)
Проектируется... правда, иногда как раз и получается, что часть нужно встроить в уже существующее... отсюда и мой вопрос по обмену данными в предыдущем посте... Вы такие вещи имели в виду?
Нет, не совсем... Встраивание, о котором Вы говорите, весьма болезненный вопрос. Если разработчики не позаботились и не документировали процесс встраивания, то... лучше не браться. Последствия могут быть плачевными. И даже при наличии хорошей документации... не всё гладко проходит, как правило... Наиболее оптимальный путь - это продумывание системы... как единого целого. В этом случае вопросы "случайных" стыковок/соединений с другими частями/системами исключён.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Сентябрь, 2011 10:09 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Интеграция - это да... Но я-то говорил именно о наведении связей по данным.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Сентябрь, 2011 14:15 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
Интеграция - это да... Но я-то говорил именно о наведении связей по данным.
А это не интеграция?..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Сентябрь, 2011 19:38 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus писал(а):
Драконограф писал(а):
Интеграция - это да... Но я-то говорил именно о наведении связей по данным.
А это не интеграция?..
Когда с готовыми системами (и, возможно, сторонней разработки) - то в моём понимании скорее стык (иногда говорят о наложении - когда "что-то поверх чего-то").


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 07 Сентябрь, 2011 07:37 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
alexus писал(а):
Драконограф писал(а):
Интеграция - это да... Но я-то говорил именно о наведении связей по данным.
А это не интеграция?..
Когда с готовыми системами (и, возможно, сторонней разработки) - то в моём понимании скорее стык (иногда говорят о наложении - когда "что-то поверх чего-то").
Поверьте... на слово... :) обмен данными (связи по данным) - это один из вариантов интеграции.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 07 Сентябрь, 2011 10:55 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1053
Откуда: Россия, Чебоксары
Драконограф писал(а):
оказалось, что их учат без учебников. Только задачник - а на уроках объясняют через визуализацию. Так, числа представляются в виде отрезков (в масштабе, конечно). А арифметические операции - как схемы расположения этих отрезков (сложение, скажем - их конкатенацией). При этом нет обычных определений как операндов и результатов - там, слагаемое, уменьшаемое и пр. Можно говорить только "часть" и "целое" - и исходить из принципа "часть всегда меньше целого"
Ну, если специально не упираться, как в последних фразах, то вполне полезно.

Однако ж есть разные ипостаси чисел: счётность и протяжённость... а ещё и векторность в перспективе ;)

На мой взгляд, отличный пример визуализации в мультфильме "38 попугаев" - как раз всё, что нужно, легко и в игровой форме даётся! Если бы ТАК в школе учили!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 07 Сентябрь, 2011 15:44 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
Вник немного - оказалось, что их учат без учебников. Только задачник - а на уроках объясняют через визуализацию. Так, числа представляются в виде отрезков (в масштабе, конечно). А арифметические операции - как схемы расположения этих отрезков (сложение, скажем - их конкатенацией). При этом нет обычных определений как операндов и результатов - там, слагаемое, уменьшаемое и пр. Можно говорить только "часть" и "целое" - и исходить из принципа "часть всегда меньше целого".
Смена метода не должна превращаться в самоцель (иначе это просто самолюбование... очередной "Нарцисс")... Цель должна находиться "этажом выше". Из описания непонятно, какая цель преследуется "педагогами". Но точно могу сказать, что принцип "часть всегда меньше целого" является принципиально ошибочным.
В советское время (вторая половина 70-х - 80-е г.г.) много споров вызывала методика педагогов Никитиных Б.П. и Л.А., а также их последователей. В конце-концов их обвинили в сектантстве(?).. и на этом всё успокоилось, хотя опыт был весьма ценный и просто интересный. Но то что не укладывается в рамки догматов должно искореняться... в обществе... стремящемуся к застою (то есть, в современном обществе, в том числе). Вот например, что писал Борис Павлович Никитин:
Никитин Б.П. писал(а):
То, что у нас сложилось, назвать системой, видимо, еще нельзя. Но основные принципы, которыми мы руководствуемся, выделить можно. Во-первых, это легкая одежда и спортивная обстановка в доме: спортснаряды вошли в повседневную жизнь с самого раннего детства, стали для них как бы средой обитания наравне с мебелью и другими домашними вещами.
Во-вторых, это свобода творчества детей в занятиях. Никаких специальных тренировок, зарядок, уроков. Ребята занимаются сколько хотят, сочетая спортивные занятия со всеми другими видами деятельности.
В-третьих, это наше родительское неравнодушие к тому, что и как у малышей получается, наше участие в их играх, соревнованиях, самой жизни.
Все эти принципы были выработаны в практике жизни, в общении с детьми. Мы пользовались ими интуитивно, неосознанно, преследуя лишь одну цель: не мешать развитию, а помогать ему, причем не давить на ребенка в соответствии со своими какими-то замыслами, а наблюдать, сопоставлять и, ориентируясь на самочувствие и желание ребенка, создавать условия для дальнейшего его развития.

Драконограф писал(а):
Вот так. Будут у кого какие мнения? :D
Если нетрудно, то дайте ссылку на описанную Вами методику... или её адептов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 07 Сентябрь, 2011 21:25 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Драконограф в viewtopic.php?f=57&t=3557&start=60#p65334 писал(а):
...
Такую же систему, которая "работает с семантикой и прагматикой" - т.е. интеллекто-имитирующую - уже нужно брать во взаимосвязи с человеком - как социотехническую (кстати, таковы же и банк, и <промышленное> предприятие типичные). Там тоже будут "противоположные интересы" - в виде неопределённости человеческого опыта в "предметке". Которая при отчуждении и передаче в семредактор выразится, допустим, в конфликтующих правилах базы знаний (и/или определениях одной предметной сущности).
...
Кстати, когда для создания приложения нужно на столь "передовые рубежи информатики" выдвигаться - IMHO, надо основываться на адекватно развитой теории интеллекта (и языка). Фёдор Васильевич здесь дал оценку одной из возможных теорий в сопоставлении с его собственной. Я же попробую более общую вещь сформулировать. Теория интенсификации рассматривает интеллект как "чёрный ящик", который из неких соображений, установленных методами "нормальной науки", можно "грамотно проектировать" подбором формы внешних воздействий данными. Главное соображение, как уже говорил где-то - гипотеза Уорфа. Лучше всего изложено в этой лекции Тер-Минасовой - она там практически с этого начинает (только не называя её так).
А теория, адекватная вызову "отчуждения над-синтаксического", должна, полагаю, иметь в основе "белый ящик" - т.е. модель механизмов мышления. И теория умотипов - попытка такую модель дать.
И можно видеть два "но" к существующему (и оформленному фактически теорией интенсификации в опубликованной версии) положению дел. Во-первых, в той же лекции опять же говорится о справедливости утверждения, обратного уорфову - т.е. что и мышление формирует язык. В некотором смысле весь Оберонкоре - утверждение необходимости нестихийности этого формирования в информатике. :) Во-вторых, есть ещё гипотеза "двойного кодирования" (Р. Солсо, кажется) - что мозг пользуется и вербальным, и невербальным представлением. В силу такого же понимания, наверное, и замечания автора теории о "драконолюбах". ;)
И теория умотипов свои "но" добавляет - своё понимание высказывал здесь.
Отсюда не только то, что говорил в этом посте - но и необходимость так строить редактор, чтобы развивать способы определения предметных языков. И со многими вещами вообще подождать - пока вид "белого ящика" не определится вполне...


Последний раз редактировалось Владислав Жаринов Четверг, 08 Сентябрь, 2011 05:51, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 07 Сентябрь, 2011 21:30 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Драконограф в viewtopic.php?f=57&t=3557&start=60#p65359 писал(а):
...
Поверьте... на слово... :) обмен данными (связи по данным) - это один из вариантов интеграции.
В принципе вопрос терминологический... так что почему бы не поверить?.. :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 08 Сентябрь, 2011 05:13 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
alexus писал(а):
Но точно могу сказать, что принцип "часть всегда меньше целого" является принципиально ошибочным.
...
Можно пояснить, почему (применительно к измеримым)?
Пожалуйста... Возьмите яйцо... Его частями являются: желток, белок и скорлупа. Правильно?.. Скорлупа по размерам меньше, чем яйцо?.. Нет?.. Размер является измеримой характеристикой?.. Да?.. Получается, что часть равна целому по измеримой характеристике.
Представление о том, что часть меньше/легче/проще целого лежит в основе редукционизма, который, являясь доминантным направлением, завёл современную науку в тупик.
Каждый Человек - Вселенная. Человек равен Вселенной. Мы мыслим себя частями Вселенной... а может быть всё наоборот... а может и нет...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 08 Сентябрь, 2011 07:20 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
alexus писал(а):
...
Скорлупа по размерам меньше, чем яйцо?.. Нет?.. Размер является измеримой характеристикой?.. Да?.. Получается, что часть равна целому по измеримой характеристике.
...
Да... я должен был сказать, наверное, "применительно к числам", поскольку обсуждается арифметика... :) Но очевидно, что такой принцип не м.б. распространён за пределы числовых операций.
Всё зависит от того... что мы понимаем под числами? Если простой аналог количественной меры, то, возможно, Ваше утверждение справедливо. И то надо как-то доказать, что число 4 является частью числа 7... (отрицательные числа какой частью являются, например)...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 08 Сентябрь, 2011 07:28 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1053
Откуда: Россия, Чебоксары
alexus писал(а):
Размер является измеримой характеристикой?.. Да?.. Получается, что часть равна целому по измеримой характеристике.
При всём почтении... и поддержке... но это есть передёргивание.
От редукционизма тоже есть практическая польза, если его правильно применять.

В данном случае масса и объём (пока не вышли за пределы применимости Ньютоновской механики) - адекватны (потому как составляют в данном примере системообразующие критерии).
А линейный размер - взятая с потолка характеристика, не имеющая отношения к системообразующим критериям.

Более интересно то, что эти самые системообразующие критерии не всегда возможно выделить.
То есть не всегда возможно сказать, что вот это есть часть, и часть чего именно...

alexus писал(а):
надо как-то доказать, что число 4 является частью числа 7
А, ну вот, и Вы про то же :)

Всё опять-таки сводится к моделированию: система координат, проекция...
Так, имеем простую координатную ось (числовую).
И проециуем на неё количественную характеристику "размер". Или, скажем, "объём". Или "масса". Ну и т.п., со всеми соответствующими выводами и следствиями.
А сами числа мерить отрезками, конечно, неверно...


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 95 ]  На страницу Пред.  1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB