Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 5396 07-10-2007 04:21 | |
Ответ на »сообщение 5395« (Как слышно? Приём!)
___________________________
>>> А какой еще есть способ?
Если не разжёвывать - создание высокоуровневнего языка.
По Руслану, "архитектурного".
Язык для эффективной манипуляции модулями.
Да. Но ведь это другой (отдельный) язык?
№ 5395 07-10-2007 03:21 | |
>>> Расчленить –- это здорово. Но как? Вот в чём загвоздка.
>>> И Лейбниц обоснованно возразил Декарту: "Это правило Декарта малоэффективно,
>>> поскольку искусство разделения... остаётся неподдающимся истолкованию".
... и изобрел дифференциальное исчисление ! :)
Что по сути и есть идея расчленения в пределе!
>>> А какой еще есть способ?
Если не разжёвывать - создание высокоуровневнего языка.
По Руслану, "архитектурного".
Язык для эффективной манипуляции модулями.
>>> Когда и как все это будет реализовано?
А вот с этим проблемы.
Не технические и не программистские.
Не нужны пока программы для сложных систем.
Как паровоз во времена фараонов.
Поэтому всё сводится к трёпу и любованию своей мудростью.
Буквально к "фило""софии".
№ 5394 06-10-2007 15:16 | |
Ответ на »сообщение 5392« (qwerty)
___________________________
То есть, все Ваши ранние наработки (тот же ЛОТОС) настолько сырые, что Вы их сделаете общественно доступными только после серьезной переработки в составе Росы?
Не вижу смысла Вас в этом разубеждать.
№ 5393 06-10-2007 15:15 | |
Ответ на »сообщение 5390« (AVC)
___________________________
Руслан, такое впечатление (вполне возможно, ошибочное), что свалены в кучу разнородные сущности.
(Это не критика, а просьба немного "разжевать". :) )
А почему должны быть однородные? Насчет разжевать -- должен извиниться. Это потребует немало времени и концентрации на этом направлении. К сожалению, у меня сейчас работы выше крыши.
Что касается контроля инвариантов, то в Обероне именно модульность этому способствует.
А не в Обероне? :) Или другим языкам мы отказываем в праве на жизнь? Вы можете по контролю сложности сопоставить, например, Eiffel и Oberon. Сравнение, полагаю, будет далеко не в пользу Оберона.
В Обероне есть модули и ASSERT. Остальное ручками и головой. Или я не прав?
Вообще говоря, надо для начала разобраться в тех сложностях, с которыми требуется бороться. Понять, с каким из них стоит бороться. И какой ценой. А только потом уже разбираться с конкретными сущностями вроде модулей. Для начала выдвину такую гипотезу: с сложностями надо бороться раньше, ДО языка реализации. А на уровне языка это делать не ручками, а возлагать на соответствующие механизмы. Впрочем, мы забегаем далеко вперед. Обсуждать столь серьезный вопрос как бы между прочим не стоит.
Если бы Вы составили, например, список сложностей, которые программисту надо взять под контроль, это могло бы стать началом плодотворного обсуждения.
№ 5392 06-10-2007 07:36 | |
Ответ на »сообщение 5377« (Руслан Богатырев)
___________________________
Ответ на »сообщение 5375« (Jack Of Shadows)
___________________________
>Ну, до реализации Росы еще года два минимум ждать
Вы чрезвычайно оптимистичны :))
Смотря что понимать под реализацией. Макетирование начнется достаточно скоро. И хотя обещанного, как известно, три года ждут, результаты начнут проявляться, мягко говоря, несколько раньше. При этом показывать на публике из сырого имеет смысл в том случае, когда есть желание получить полезную обратную связь. Она нужна для принятия решений, для уточнения выбора, для поиска новых участников и помощников.
То есть, все Ваши ранние наработки (тот же ЛОТОС) настолько сырые, что Вы их сделаете общественно доступными только после серьезной переработки в составе Росы?
№ 5391 06-10-2007 06:01 | |
Ответ на »сообщение 5390« (AVC)
___________________________
Границы -- суть модульности. Все остальное может строиться только поверх этого основания (генераторы кода по спецификациям -- вроде поддержки xUML -- это отдельный вопрос, мало связанный с конкретным языком).
Вот смотрите: реально, во время выполнения программы, существуют только процедуры, модули и дескрипторы типов.
№ 5390 06-10-2007 05:44 | |
Ответ на »сообщение 5387« (Руслан Богатырев)
___________________________
Ответ на »сообщение 5386« (AVC)
___________________________
>Это один из возможных способов. Но не единственный.
А какой еще есть способ?
-- Первичность асинхрона (декларатива) и вторичность синхрона (императива).
-- Использование формальных методов (скорее "до", нежели "после").
-- Первичность спецификаций, вторичность реализаций. Контроль синхронизации спецификаций и их вариативных проекций на языки реализации.
-- Архитектурный язык.
-- Формирование и контроль инвариантов.
-- Высокоуровневый контроль памяти (языково- и сущностно-ориентированной).
-- Переключение ментальных контекстов. В смысле -- работа в рамках одного контекста -- одной парадигмы, которую наиболее оптимальным образом поддерживает соответствующий язык (сбалансированные синтаксис-семантика-прагматика) из ортогональной связки языков (спроектированных по принципу концептуальной экономии).
-- Методология программирования, обеспечивающая поддержку перечисленных выше (и других) механизмов контроля сложности.
Руслан, такое впечатление (вполне возможно, ошибочное), что свалены в кучу разнородные сущности.
(Это не критика, а просьба немного "разжевать". :) )
Что касается контроля инвариантов, то в Обероне именно модульность этому способствует.
Принцип прост: инварианты памяти (безопасность типов) контролируются языком, все остальные инварианты вводятся программистом и защищаются границами модулей.
Границы -- суть модульности. Все остальное может строиться только поверх этого основания (генераторы кода по спецификациям -- вроде поддержки xUML -- это отдельный вопрос, мало связанный с конкретным языком).
№ 5389 06-10-2007 03:27 | |
Ответ на »сообщение 5388« (Jack Of Shadows)
___________________________
Когда и как все это будет реализовано ? Не то чтобы я считал это возможным. Просто хочется знать когда вы на практике наступите на те же грабли, на которые наступали многие до вас. :))
Это не окончательный набросок и даже не особо предварительный. Пока еще изучаем, сопоставляем и размышляем. И будет это длиться еще несколько месяцев. Как минимум. Только потом будем расставлять приоритеты и исходя из них подходить к проектированию.
№ 5388 05-10-2007 16:37 | |
Ответ на »сообщение 5387« (Руслан Богатырев)
___________________________
Когда и как все это будет реализовано ? Не то чтобы я считал это возможным. Просто хочется знать когда вы на практике наступите на те же грабли, на которые наступали многие до вас. :))
№ 5387 05-10-2007 15:33 | |
Ответ на »сообщение 5386« (AVC)
___________________________
>Это один из возможных способов. Но не единственный.
А какой еще есть способ?
-- Первичность асинхрона (декларатива) и вторичность синхрона (императива).
-- Использование формальных методов (скорее "до", нежели "после").
-- Первичность спецификаций, вторичность реализаций. Контроль синхронизации спецификаций и их вариативных проекций на языки реализации.
-- Архитектурный язык.
-- Формирование и контроль инвариантов.
-- Высокоуровневый контроль памяти (языково- и сущностно-ориентированной).
-- Переключение ментальных контекстов. В смысле -- работа в рамках одного контекста -- одной парадигмы, которую наиболее оптимальным образом поддерживает соответствующий язык (сбалансированные синтаксис-семантика-прагматика) из ортогональной связки языков (спроектированных по принципу концептуальной экономии).
-- Методология программирования, обеспечивающая поддержку перечисленных выше (и других) механизмов контроля сложности.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|