OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 20 Август, 2019 17:53

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




Начать новую тему Ответить на тему  [ Сообщений: 169 ]  На страницу Пред.  1 ... 5, 6, 7, 8, 9  След.
Автор Сообщение
СообщениеДобавлено: Среда, 14 Декабрь, 2011 10:40 
Аватара пользователя

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


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Вообще, какое-то мусоленье проблем несуществующих.

По моему личному опыту, нет каких-либо серьёзных проблем в современном императивном ЯП класса КП (или наоборот, резервов - узких мест), устранив которые, можно добиться значимого прироста производительности на широком спектре задач.
Всякие фишки среды разработки (в том числе изменение способа ввода) могут изменить ситуацию незначительно - потому, что ввод программы в компьютер и так происходит значительно быстрее, чем думание.

Повышение производительности относительно "монстров" типа Явы/.NET возможно путём снижения многообразия средств, ограничения "технарской фантазии", удаления мест потенциальных граблей и мест, которые требуют много времени на "борьбу" с ними. Что и имеется в Оберонах.

Увеличивать производительность труда относительно хороших императивных языков можно дальше только для конкретных задач. Например, для сборки-интеграции распределённых систем, ИС.
Для построения алгоритмов управления (технологии типа SWITCH, Графит-Флокс).
Ещё есть задача облегчения понимания структуры объектно-ориентированных систем - каким образом строить спецификации или "карты" по уже существующим системам.

Ещё есть задачи с другого конца, где есть проблемы у "обычных языков". Задействование специального оборудования - спец. вычислителей, сигнальных процессоров и т.п. Решить на уровне компилятора задачу эффективной трансляции обычных платформенно-независимых конструкций ЯВУ получается плохо. Там нужны, опять же, какие-то генерирующие технологии, из описаний вычислительных алгоритмов на разные вычислители.

Всё это интересно и актуально, но совершенно не "теснит" обычные языке на широком спектре задач.


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

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Сергей Прохоренко писал(а):
Слова "я так вижу" я принимаю только от художников
Вот я Вам и говорю "как художник художнику" :)


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

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Илья Ермаков писал(а):
По моему личному опыту, ...
Ответил в личку.


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

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


Вы просто на них закрываете глаза. Предотвращение побочных эффектов позволяет не допустить ошибки времени исполнения, которые могут проскочить и анализ кода, и тестирование. Я не считаю, что история языков программирования закончилась с появлением КП.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Просто исследования переходят на более высокий уровень... Сколько можно копать одно и то же :)
Ваше исследование очень интересно, но только если Вы будете правильно прицеливаться. "Вынести" обычные ЯП не получится.

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


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

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Я не "функциональщик". Я – за присваивания, полноценные переменные, состояния – внутри функций. Без этого невозможно реализовать эффективный код и естественным образом моделировать многие предметные области. Но на более высоком уровне – на уровне функций – я поддерживаю те идеи функционального программирования, которые обеспечивают надежность программирования. В частности – отсутствие побочных эффектов.
Илья Ермаков писал(а):
Если плохо проектировать, будут проблемы.

Конечно. Но язык программирования и структурный редактор должны заставлять проектировать правильно. Если нет возможности спроектировать неправильно, то никто ею и не воспользуется.
Илья Ермаков писал(а):
"Вынести" обычные ЯП не получится.

Получится. Аргументов можно привести много:
1. Если честно посмотреть на вещи, то сейчас нет по-настоящему универсальных языков программирования. Все они фактически специализированные. Хочешь сделать веб-сервер – используй Erlang. Хочешь веб-интерфейс – не обойтись без JavaScript. Хочешь делать корпоративные приложения – без Java никуда. А если нужна "числодробилка" или драйверы – C/C++. А потребность в универсальном языке есть, что подтверждается появлением новых гибридных языков. Очевидно, что прорыв в этом направлении уже невозможно осуществить на традиционной текстовой основе программного кода – достигнут «потолок» в развитии этой технологии.
2. Ракеты и самолеты продолжают падать по вине управляющих программ. И существование КП по факту никак этому не воспрепятствовало - в этих ракетах и самолетах его просто не применяли.
3. В программировании еще слишком много шаманства и искусства в противовес науке и инженерии. Кодификация стиля программирования мало помогает, поскольку средства программирования позволяют программировать абы как. Минимизация языка программирования – тоже не панацея. Для программирования высокоуровневых конструкций на минимальном языке придется использовать изощренные приемы и писать много кода.
4. Затраты на отладку, внедрение и сопровождение программ просто немыслимые, и во многом вина за это лежит на архитектуре программ, которую диктуют средства программирования.
5. Вытеснение одних языков программирования другими приводит к огромным издержкам по поддержанию или замене унаследованного кода и обучению новым языкам, хотя в своей основе все языки программирования имеют много общего. Зачем изучать новый синтаксис, если графически всё можно изобразить одним способом?

Заметьте, что я нигде не употребляю в качестве аргумента скорость ввода (набора) программ, хотя Вы упорно считаете это моим аргументом.


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3061
Откуда: Астрахань
Поддержу Сергея.
Инструментарий просто не должен допускать неправильного проектирования-программирования.
Я тут уже привлодил пример, что мой студент, привыкнув писать в нашем редакторе исключительно структурно (постановка "руки"), потом и в шарпе стал так уже на автомате делать. И это - только один маленький пример. Причем это уже на 4 курсе, когда вроде все "плохие" привычки сформировались. И то их удалось скомпенсировать А если сразу начинающих в среду, которая просто не даст писать неправильно, то это как-раз то самое, о чем говорил ВИРТ: профессиональные привычки и качества.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Илья Ермаков писал(а):
"Вынести" обычные ЯП не получится.

Получится. Аргументов можно привести много:


Сергей, не буду с Вами спорить, потому что в сказанном Вы правы.
Я не спорю с Вами, просто поправляю акценты, что ли.
То, что Вы делаете сейчас (моё мнение) - не сможет "вынести"... и надо быть к этому готовым. Но это, конечно, поможет поэкспериментировать и многое нам всем лучше понять. А вот что будет потом... поживём-увидим :)

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

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

Схематично, я вижу ситуацию именно так.


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

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Илья Ермаков писал(а):
То, что Вы делаете сейчас (моё мнение) - не сможет "вынести"... и надо быть к этому готовым.


Почему? Есть ли какие-то конкретные причины?

Мне кажется, что Валерий Лаптев очень правильно задумал проект с коммерческой точки зрения. Структурный редактор выдает не машинные коды и не только байт-код, но и полноценный код на популярном ЯВУ! Более того, он мимикрирует под IDE этого ЯВУ. Работодателю программист может предъявить код на том языке (C#), который традиционно используется в разработке, и этот код может в дальнейшем поддерживаться другими программистами. А у самого программиста порог вхождения тоже низкий, так как не надо переучиваться на другой язык. То есть, структурный редактор может бесшовно вписаться в мейнстрим и постепенно вытеснить сначала IDE, а затем и ЯВУ. Это не жесткая конкуренция, в которой нет шансов победить мейнстрим.

Правда, я бы выбрал более популярный язык, чем C#, - Java. Но, насколько я понимаю, переход от C# к Java в будущем будет нетрудным, так как языки похожи.

Конечно, будет трудно впихнуть семантику внутреннего языка структурного редактора в синтаксис и виртуальные машины C# и Java. Видимо, какие-то возможности останутся недоступными для перевода в C# и Java. Например, легковесные процессы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Декабрь, 2011 16:04 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3061
Откуда: Астрахань
Сергей Прохоренко писал(а):
Правда, я бы выбрал более популярный язык, чем C#, - Java. Но, насколько я понимаю, переход от C# к Java в будущем будет нетрудным, так как языки похожи.

Да, они практически идентичные с шарпом. Просто пацан реально владеет шарпом. Но потом и про Яву подумаем.


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Александр Шостак писал(а):
Нам предлагается отказ от глобального пространства и передача контекста вручную:
M1.P1(M);
M2.P2(M);
Вы не поняли. Ничего подобного не предлагается. Если м1 и м2 - объекты, а Р1 и Р2 связанные с ними процедуры, то внутри объектов м1 и м2 уже есть указатель на М0. Поэтому вызовы связанных процедур текстуально выглядят так как будто м1 и м2 модули:

м1.P1; (* Процедура Р1 знает указатель на М0 так как он хранится в объекте м1 *)
м2.P2; (* Процедура Р2 знает указатель на М0 так как он хранится в объекте м2 *)

То есть вместо

----------------------------------------------------------------------------
MODULE M0;
PROCEDURE P0;
END M0.
----------------------------------------------------------------------------


----------------------------------------------------------------------------
MODULE M1;
IMPORT M0;
PROCEDURE P1;
END M1.
----------------------------------------------------------------------------


----------------------------------------------------------------------------
MODULE M2;
IMPORT M0;
PROCEDURE P2;
END M2.
----------------------------------------------------------------------------

Делаем так:

----------------------------------------------------------------------------
TYPE M0 = POINTER TO RECORD (System.Module) END;

PROCEDURE (m0: M0) P0;
BEGIN (* ... *)
END P0;
----------------------------------------------------------------------------


----------------------------------------------------------------------------
TYPE M1 = POINTER TO RECORD (System.Module)
m0: M0; (* помним указатель на объект-модуль М0 *)
END;

PROCEDURE (m1: M1) P1;
BEGIN
m1.m0.P0();
END P1;
----------------------------------------------------------------------------


----------------------------------------------------------------------------
TYPE M2 = POINTER TO RECORD (System.Module)
m0: M0; (* помним указатель на объект-модуль М0 *)
END;

PROCEDURE (m2: M2) P2;
BEGIN
m2.m0.P0();
END P2;
----------------------------------------------------------------------------


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Декабрь, 2011 18:37 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
Теперь понял, спасибо. Не понятно другое. Какие проблемы при этом решаются. Ведь согласитесь, если M0 представляет собой графический движок, или реализует определённую игровую часть, или управляет таблицей данных в стиле excel, то все другие модули будут иметь у себя ссылку на него. Проблемы состояния подобный шаг ни в коем случае не решит. Просто каждому желающему (читать, как всегда, практически всем) эту ссылку в начале работы придётся передать (и обращение всегда будет не по прямым адресам, а через разыменование).

Или я в чём-то ошибаюсь?


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Александр Шостак писал(а):
Какие проблемы при этом решаются
Это надо ещё обдумать. На первый взгляд облегчается выгрузка модулей (делается автоматически сборщиком мусора).

Сами модули уходят из языка на уровень библиотек - язык становится проще.

Александр Шостак писал(а):
и обращение всегда будет не по прямым адресам, а через разыменование
Если модули динамически загружаются, то доступ к их переменным осуществляется тоже через разыменование чего-то там скрытого от программиста.


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

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
Цитата:
Если модули динамически загружаются, то доступ к их переменным осуществляется тоже через разыменование чего-то там скрытого от программиста.

Не обязательно. Имея таблицу смещений, можно при загрузке править код модулей-импортёров для прямого доступа. Образ PE в Windows тоже может загружаться не по желаемому адресу. При наличии Table Of Relocations все ссылки будут поправлены.

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


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4489
Откуда: Россия, Орёл
Сергей Губанов писал(а):
На первый взгляд облегчается выгрузка модулей (делается автоматически сборщиком мусора).
Мне кажется, что приравнивать модули к данным нельзя. Если модуль в данный момент не используется, это ещё не означает, что его надо убирать. Оптимальный режим использования компонент (какие должны быть загружены всё время, какие нет и т.п.) может определить только человек.

И ещё:
Борис Рюмшин писал(а):
особо явного смысла в выгрузке модулей нет... частая выгрузка нужна только в процессе разработки, а не при эксплуатации

тем более может возникнуть ситуация достаточно тупая (сродни пробуксовке страниц в ОС) - вот модуль понадобился, загрузился, что-то выполнил... стал не нужен, был собран и тут же снова понадобился... и так в цикле
О том же:
Project Oberon писал(а):
2.2.2 Commands
...any command click may cause the loading of one or several modules, if M is not already present in main store. The next invocation of M.P occurs instataneously, since M is already loaded. A further consequence is that modules are never (automatically) removed, because a next command may well refer to the same module.


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

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Сергей Прохоренко писал(а):
... язык программирования и структурный редактор должны заставлять проектировать правильно. Если нет возможности спроектировать неправильно, то никто ею и не воспользуется.
Средства разработки могут помочь в выполнении формальных правил, но заставить проектировать правильно не в их силах. Если бы они [средства] знали, как правильно, то... проектировщики, очевидно, были бы не нужны...
Сергей Прохоренко писал(а):
Илья Ермаков писал(а):
"Вынести" обычные ЯП не получится.

Получится. Аргументов можно привести много:
Хорошо... посмотрим.
Сергей Прохоренко писал(а):
1. Если честно посмотреть на вещи, то сейчас нет по-настоящему универсальных языков программирования. Все они фактически специализированные. Хочешь сделать веб-сервер – используй Erlang. Хочешь веб-интерфейс – не обойтись без JavaScript. Хочешь делать корпоративные приложения – без Java никуда. А если нужна "числодробилка" или драйверы – C/C++. А потребность в универсальном языке есть, что подтверждается появлением новых гибридных языков. Очевидно, что прорыв в этом направлении уже невозможно осуществить на традиционной текстовой основе программного кода – достигнут «потолок» в развитии этой технологии.
Гибридизация языков никак не способствует их же универсальности... и популярности... Кроме того, частота появления новых языков не снижается, что также не способствует появлению "универсальных" языков.
Наконец, текстовая основа просуществует ещё достаточно долго, в силу своих качеств: 1. доступности; 2. распространённости; 3. понятности. Формирование иных не-текстовых образов - процесс достаточно долгий и противоречивый (столкновение множества субъективных точек зрения не порождает объективную (универсальную) точку зрения... и даже не способствует этому... как правило (это можно легко проследить по обсуждениям острых вопросов на форумах, например)).
Сергей Прохоренко писал(а):
2. Ракеты и самолеты продолжают падать по вине управляющих программ. И существование КП по факту никак этому не воспрепятствовало - в этих ракетах и самолетах его просто не применяли.
Это не аргумент...
Сергей Прохоренко писал(а):
3. В программировании еще слишком много шаманства и искусства в противовес науке и инженерии.
Почему одно [наука и инженерия] должно подменять другое [шаманство и искусство]?.. Шаманство и искусство неизбежны при осознании и создании нового. Наука нужна для формализации (осознанного или созданного) нового, инженерия необходима при использовании формализмов, полученных наукой. Если мы формализуем "всё и вся"... то развитие полностью прекратится. С другой стороны, конечно, глупо не пытаться осмыслить новое, то есть глупо отказываться от формализации. То есть, нужен поиск оптимума, а не система противовесов.
Сергей Прохоренко писал(а):
Минимизация языка программирования – тоже не панацея. Для программирования высокоуровневых конструкций на минимальном языке придется использовать изощренные приемы и писать много кода.
Попробую поделится наблюдениями... Если взять всего две базовых конструкции: присваивание и сравнение (как частный случай арифметики), то этого вполне достаточно для написания программ... но трудоёмко. Чтобы снизить трудозатраты, дадим возможность создавать и поименовывать комплексы/агрегаты из этих двух конструкций - макроопределения. Трудозатраты снизятся примерно в 1000 раз при росте многообразия примерно в 100 раз. Введём правила создания макросов, например, правила структурного программирования (описание и построение минимального количества оптимальных/универсальных комплексов)... трудозатраты на разработку программ снизятся ещё в 10...100 раз, а многообразие уменьшится примерно в те же 10...100 раз.
Вообще, вопрос минимизации количества типов элементов является очень интересным с точки зрения семантики систем. И любая(!) большая система (более 4-х уровней), образует ромб, где повышение многообразия сменяется его уменьшением... и всё это происходит не случайно, а вполне закономерно...
Сергей Прохоренко писал(а):
4. Затраты на отладку, внедрение и сопровождение программ просто немыслимые, и во многом вина за это лежит на архитектуре программ, которую диктуют средства программирования.
Средства (любые, а не только разработки программ) могут накладывать ограничения, но диктовать архитектуру... это из области утопий (в том смысле, что архитектор придумал такую архитектуру, которую выстроить с помощью доступных средств/технологий нереально... а-ля, крыша без опоры). Поэтому перекладывание проблем архитектуры на средства разработки - некорректно.
Сергей Прохоренко писал(а):
5. Вытеснение одних языков программирования другими приводит к огромным издержкам по поддержанию или замене унаследованного кода и обучению новым языкам, хотя в своей основе все языки программирования имеют много общего. Зачем изучать новый синтаксис, если графически всё можно изобразить одним способом?
В таком случае, и текстом можно описать одним способом (если графика формализована... а она в данном случае должна быть формальной). С другой стороны, если появится одно графическое средство, то... их тут же станет много... поскольку появится множество желающих продвинуть свой вариант графической нотации. Это всё уже многократно повторялось и в новых языках, и в новых ОС, и в новых СУБД и пр. и пр.
Другими словами, этот аргумент вызывает большие сомнения.


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Евгений Темиргалеев писал(а):
Мне кажется, что приравнивать модули к данным нельзя
Объект это не только данные, но и связанные с ними процедуры. Разница с модулем в способе создания. Модуль в каком-то смысле является статическим объектом. То есть в каком-то смысле разница не очень большая.
Евгений Темиргалеев писал(а):
Если модуль в данный момент не используется, это ещё не означает, что его надо убирать. Оптимальный режим использования компонент (какие должны быть загружены всё время, какие нет и т.п.) может определить только человек.
Это решаемо. Например, так: объект-модуль-загрузчик Kernel создаётся в процедуре main() и заякорен в ней в главном цикле программы. Другие объекты-модули загружаются объектом Kernel. Если загруженный модуль нужен "надолго", то указатель на него якорится в Kernel. Если не "надолго", то в Kernel кладётся его слабая ссылка. Когда долгоживущий модуль понадобиться выгрузить, то в Kernel указатель на него заменяется слабым указателем и запускается GC.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Сергей Губанов писал(а):
Евгений Темиргалеев писал(а):
Мне кажется, что приравнивать модули к данным нельзя
Объект это не только данные, но и связанные с ними процедуры. Разница с модулем в способе создания. Модуль в каком-то смысле является статическим объектом. То есть в каком-то смысле разница не очень большая.


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

На первое можно сказать, что на языках решаются разного уровня-рода задачи, начиная от простых и учебных. Выход на мета-уровень должен "включаться" только в нужный момент, при необходимости, а до этого язык должен предоставлять простые и прямые средства, непосредственно выражающие мысль. Человек должен иметь чёткую опору, скелет - какой набор определений известен в единичном экземпляре и глобально доступен через импорт, и уже "цепляясь" за этот скелет, где нужно, вводить мета-средства (объекты-как-модули и проч.) Вообще, "всё можно на Лиспе", "всё можно на Форте", "всё можно на Смоллтоке"... Но - наиболее сбалансированными и естественными являются те языки, в которых разные вещи выглядят по-разному, а выход на уровень мета-абстракций происходит только при необходимости. В отличие от тех языков, где самые обыденные вещи приходится выражать с помощью специализации супер-абстракций.

По поводу второго - ну да, целесообразно стараться разделять модули по назначению: здесь мы определили абстрактные типы, а в этом - реализацию и состояние, а вот здесь чисто алгоритмы... Но это уже на усмотрение разработчика. Потому что небольшая примесь всегда бывает. Сделали модуль с абстракциями, иногда самые базовые и инвариантные алгоритмы - процедуры для работы с этими абстракциями через их интерфейс вполне уместно положить рядом (поскольку они всегда практически будут использоваться). Например, для модуля Files - алгоритм CopyBytes(rd, wr, count) (его там сейчас нет).
Ну а минимальное состояние в виде динамических разъёмов тоже там будет.
Ну да, можно засовывать в язык средство динамического подключения реализаций, чтобы не делать это через состояние модулей. Но что мы выиграем - и сколько это будет стоить, и всего многообразия случаев это не покроет....


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4489
Откуда: Россия, Орёл
Сергей Губанов писал(а):
Евгений Темиргалеев писал(а):
Если модуль в данный момент не используется, это ещё не означает, что его надо убирать. Оптимальный режим использования компонент (какие должны быть загружены всё время, какие нет и т.п.) может определить только человек.
Это решаемо. Например, так: объект-модуль-загрузчик Kernel создаётся в процедуре main() и заякорен в ней в главном цикле программы. Другие объекты-модули загружаются объектом Kernel. Если загруженный модуль нужен "надолго", то указатель на него якорится в Kernel. Если не "надолго", то в Kernel кладётся его слабая ссылка. Когда долгоживущий модуль понадобиться выгрузить, то в Kernel указатель на него заменяется слабым указателем и запускается GC.
А если рассмотреть компонентную систему, в которой нету невыгружаемой сущности "программа", т.е. нету процедуры main с главным циклом и якорями? Невыгружаемый --- компонент. И если говорить точно, то в ББ выгружаются не модули, а компоненты. Просто технически сделано так, что модуль является минимальным компонентом; более крупные состоят из нескольких взаимодействующих компонентов-модулей, навроде многоклеточного организма.

Для примеру: нашёл я три компонента, которые комбинируются в нужный мне "сервис", скачал, настроил, "запустил". Компилятора нету, это слово для меня матерное, про якори майны и главный цикл вообще не слыхал. А с конфигурирующе-якорящей программой как быть? Программистов нанимать?

СохранялкаПочтовыхВложений.УстПараметрыАккаунта(....)
СохранялкаПочтовыхВложений.УстПапку("Вложения")
СохранялкаПочтовыхВложений.Старт

ПеремещалкаФайловПоТипу.УстПапкуА("Вложения")
ПеремещалкаФайловПоТипу.УстПапкуБ("Картинка")
ПеремещалкаФайловПоТипу.УстМаску("bmp")
ПеремещалкаФайловПоТипу.Старт

ВыгружалкаНаФТП.УстПараметрыАккаунта(....)
ВыгружалкаНаФТП.УстПапку("Картинки")
ВыгружалкаНаФТП.УстURL(...)
ВыгружалкаНаФТП.Старт


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

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


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

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


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

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