Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  12:59[Войти] | [Зарегистрироваться]
Обсуждение темы:
Оберон-технология: особенности и перспективы


Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение. 

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 6256 сообщений

Добавить свое сообщение

Отслеживать это обсуждение

Обсуждение из раздела
Школа ОБЕРОНА

<<<... | 5416—5407 | 5406—5397 | 5396—5387 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 86


№ 5406   07-10-2007 10:41 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 5404« (Как слышно? Приём!)
___________________________

Как может асинхронное программирование при сети связей выиграть борьбу со сложностью?

Кто сказал, что в этой борьбе можно выиграть? :)

Тезис довольно простой: мы в значительной мере создаем себе сложности сами. Почему? Потому что так проще. :) И выгоднее.

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

Сложные вещи делать проще. Простые -- сложнее. Написать статью по нетривиальной проблеме на половину журнальной полосы много сложнее, нежели статью на несколько полос.

Асинхронное программирование -- лишь одно из звеньев цепи. Правда, очень важное. Это несколько иной подход к мышлению, к решению задач, к реализации проектов. Подход, в котором вместо "раньше - позже" преимущественно фигурируют причинно-следственные связи.  Он не отвергает синхрон, просто становится над ним, становится первичным.

Асинхронное программирование лежит в русле идей В.Е.Котова, в русле работ по проекту МАРС середины 1980-х. Увы, в том проекте большей частью вынуждены были ограничиваться демонстрацией, "военным парадом" тех заделов, которые были созданы в предшествующие годы.

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


№ 5405   07-10-2007 10:01 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 5403« (Руслан Богатырев)
___________________________

Ответ на »сообщение 5402« (AVC)
___________________________

>>>Ну а если говорить о моём видении стратегии борьбы со сложностью, то, думаю, её вполне можно озвучивать уже сейчас. Это асинхронное программирование.

Асинхронное -- в каком смысле? (Вопрос задан в свете »сообщение 5387«.)
 AVC


№ 5404   07-10-2007 09:59 Ответить на это сообщение Ответить на это сообщение с цитированием
>>> Борьба со сложностью в рамках индивидуального программирования (и небольших проектов)
>>> вполне может решаться подходом языков-ядер (Оберона, Лиспа, Пролога и др.).
>>> Минимализм и концептуальная экономия.

>>> Но как только речь идет о других масштабах и другом процессе разработки
>>> (коллективном, индустриальном), требуется предпринимать дополнительные шаги

А не путается ли тут сложность проекта (объективная) и сложность пастьбы котов (субъективная)?
Очень опасная путаница. Задумывался UML как средство создания сложных моделей.
Затем превратился в средство контроля за разработкой. Именно это и погубило UML.

С одной стороны (со стороны разработчиков и Ко) - увлечение конечными автоматами и изобретением
очередного языка и компилятора было супротив интереса к нотации больших систем.
"Минимализм и концептуальная экономия", "сложные проблемы имеют простые решения".

С другой стороны - удобство и наглядность графического представления (по аналогии с презантациями)
были мгновенно впитаны менеджерами проектов. И UML стал игрушкой офисного планктона, а жаль.

Нужен надязык, но уже не UML. Там всё обросло ракушками администрирования.
Смотреть надо в сторону сетей Петри и чего-то более неформального и нечёткого.

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

Как может асинхронное программирование при сети связей выиграть борьбу со сложностью?


№ 5403   07-10-2007 07:30 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 5402« (AVC)
___________________________

Конечно, правы.
Остается удивляться, почему все-таки это достаточно удобно. :)


Всё в мире относительно. Как Вы думаете, если бы, например, простановка ASSERT производилась автоматически (на основе более высокоуровневых сущностей) и при этом еще контроль и обработка ASSERT не сводились бы к примитивной интерпретации ран-таймом, было бы ещё удобнее? :)

Ну а если говорить о моём видении стратегии борьбы со сложностью, то, думаю, её вполне можно озвучивать уже сейчас. Это асинхронное программирование.


№ 5402   07-10-2007 07:14 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 5393« (Руслан Богатырев)
___________________________

>>>В Обероне есть модули и ASSERT. Остальное ручками и головой. Или я не прав?

Конечно, правы.
Остается удивляться, почему все-таки это достаточно удобно. :)

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

Если бы Вы составили, например, список сложностей, которые программисту надо взять под контроль, это могло бы стать началом плодотворного обсуждения.


Согласен.
Попробую сформировать такой список.
А то прямо сейчас голову занимают скорее организационные вопросы: как наладить (на работе) учет ошибок и т.п.
 AVC


№ 5401   07-10-2007 05:37 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 5396« (AVC)
___________________________

Да. Но ведь это другой (отдельный) язык?

Безусловно. И не один. Борьба со сложностью в рамках индивидуального программирования (и небольших проектов) вполне может решаться подходом языков-ядер (Оберона, Лиспа, Пролога и др.). Минимализм и концептуальная экономия.

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


№ 5400   07-10-2007 05:32 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 5399« (AVC)
___________________________

А к чему этот вопрос? Переход на личности?

Полагаю, простое любопытство. Никакого криминала :)


№ 5399   07-10-2007 05:30 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 5397« (qwerty)
___________________________

Ответ на »сообщение 5394« (Руслан Богатырев)
___________________________

Поставлю вопрос по-другому. Есть ли в Сети вообще какие-либо исходники на модуле или обероне, написанные Вами?


А к чему этот вопрос? Переход на личности?
 AVC


№ 5398   07-10-2007 05:21 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 5397« (qwerty)
___________________________

Поставлю вопрос по-другому. Есть ли в Сети вообще какие-либо исходники на модуле или обероне, написанные Вами?

А... так Вас интересую я, а не системы. С этого и стоило начинать. Насчет моих исходников в Интернете -- возможно, где-то и есть. В свое время (где-то в середине 1990-х) распространял свои библиотеки на Модуле-2, включая поддержку драйверов БД (Clarion) и мультиязыковое программирование для TopSpeed-компиляторов.

Впрочем, если интересует подход к написанию исходного текста и документированию, в качестве иллюстрации можете взглянуть на эту работу: "Золотой треугольник Паскаля" (2001) -- http://www.oberon2005.ru/paper/triangle.pdf


№ 5397   07-10-2007 04:54 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 5394« (Руслан Богатырев)
___________________________


Не вижу смысла Вас в этом разубеждать.

Поставлю вопрос по-другому. Есть ли в Сети вообще какие-либо исходники на модуле или обероне, написанные Вами?


<<<... | 5416—5407 | 5406—5397 | 5396—5387 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 86


Добавить свое сообщение

Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
Функция может не работать в некоторых версиях броузеров.

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования