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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

<<<... | 4386—4377 | 4376—4367 | 4366—4357 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 189


№ 4376   24-04-2007 08:18 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4346« (Руслан Богатырев)
___________________________

>>>Честно говоря, к метапрограммированию отношусь достаточно сдержанно.

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


№ 4375   24-04-2007 07:49 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4373« (Как слышно? Приём!)
___________________________

>>>Так что DAG и тем более иерархия дерева отдыхает.

Здесь, IMHO, какая-то путаница.
В Обероне даг модулей есть прямое отражение иерархии абстракций.
Параллелизм здесь не при чем.
 AVC


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

>>>Если руководитель команды (team leader проекта) не владеет (желательно очень хорошо) инструментами своих подчиненных, то в области программирования он быстро потеряет уважение и контроль.

Полностью согласен.
Но я хотел подчеркнуть значимость управления.
Если "управленец" и "разработчик" -- один и тот же человек, одна из этих функций может "пожрать" другую. :)
 AVC


№ 4373   24-04-2007 07:29 Ответить на это сообщение Ответить на это сообщение с цитированием
Кстати, прицепившись к термину "кластер".
Кластер компьютеров с иерархической структурой теперь - редкость.
Чаще это сетка на плоскости, многомерные гиперкубы и т.п. сети.
Дублирование связей, данных, кода, адаптивные механизмы
изменения активных соединений (т.е. структуры) - это реальность.
Так что DAG и тем более иерархия дерева отдыхает.
Почему? Та самая надёжность требует. Выход из строя любого
элемента и любой связи не должен остановить работу.

Как дела с распараллеливанием в Обероне?


№ 4372   24-04-2007 05:54 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4368« (Сергей Перовский)
___________________________

Так ли уж принципиально? Таблица регистрации СОМ-компонентов вполне работоспособный механизм.

Да принципиально. Аргументацию, думаю, повторять не стоит. Не убедила -- значит, не убедила.

Т.е. в Вашей конструкции язык более высокого уровня хорошо согласуется с Обероном? Очень хорошо и естественно, т.к. Вы разрабатывали кластерный подход изначально исходя из Оберона в качестве базы. Значит ли это, что такая пара языков лучше других?

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

Почему Вы думаете, что на операционном уровне регламентация невозможна?

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


№ 4371   24-04-2007 05:42 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4369« (AVC)
___________________________

Это -- менеджер.

Если руководитель команды (team leader проекта) не владеет (желательно очень хорошо) инструментами своих подчиненных, то в области программирования он быстро потеряет уважение и контроль. Тут как раз лапшу на уши повесить новоиспеченному менеджеру без квалификации (advanced programmer) -- можно в два счета. Такие кадры обычно скрупулезно растят. И ставят на эти позиции сильнейших программистов, умеющих работать в коллективе, пользующихся уважением и делом доказывающих свое лидерство.

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


№ 4370   24-04-2007 05:36 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4366« (Стэн)
___________________________

Я-то говорил, что не надо делить языки на те, с помощью которых разрабатываются модули и те, с помощью которых они объединяются в единое целое. Так как в объединяющий язык все равно придется внести большую часть понятийного аппарата.

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

Вообще, будет хорошо, если они начнут нормально общаться между собой хотя бы на русском.

Интересный момент. Основные проблемы недопонимания (линии разлома) происходят между:
* заказчиком и исполнителем ("замысел"),
* аналитиком и архитектором/проектировщиком ("проект"),
* проектировщиком и программистом ("строительство").

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

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

Проекты по заказному ПО по финансовым параметрам обычно разделяют на "fixed price" (фиксирована цена и сроки) и "time and material" (оплата по факту реально произведенных работ с учетом затрат на ресурсы). У нас все больше привыкли к fixed price -- поэтому сначала "стаканят" цену. А потом каждая сторона начинает выжимать из этого свою выгоду. Заказчик при такой схеме заинтересован выламывать руки исполнителю (цену-то уже не поменяешь, а за ту же цену получить побольше и получше -- кто ж не хочет). Исполнитель тоже не дурак -- начинает в ответ давить на заказчика смещением сроков, падением качества и т.д. и т.п. Другими словами, устанавливать fixed price на новые (еще не создававшиеся раньше исполнителем) вещи -- страшные риски (для обеих сторон). На Западе пришли к пониманию, что если важен результат, то требуется доверие (по принципу: "доверяй, но проверяй"). А это обеспечивает time and material. Поэтому нередко схема отношений выглядит так: дается на пробу мелкий проект ("покраска забора"). Справились хорошо? Тогда можно переходить к "time and material". Некоторые наши компании при работе на западных заказчиков идут дальше -- создают внутреннюю систему управления проектами, доступ к которой (дистанционно) получают представители заказчика. Вплоть до того, что они могут на те или иные работы запрашивать конкретных проверенных в деле исполнителей: Иванова, Петрова, а не Сидорова. И следить за исполнением заданий. Т.е. заказчик рулит ресурсами (в разумных, разумеется пределах) и даже спускается (если позволяет квалификация и уровень взаимоотношений с компанией-исполнителем) на уровень проектировщика. Отдача много выше. Доверие растет с каждым проектом. Клиент становится постоянником. Под него фактически формируется отдельное подразделение.

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

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

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

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



№ 4369   24-04-2007 05:09 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4355« (Руслан Богатырев)
___________________________

>>>5. Начальник участка (прораб, он же team leader)

Вот этого очень не хватает.
Хотя не уверен, что этим в софтверной области должен заниматься программист (тем самым исполняя в проекте две совершенно разные функции).
Здесь важно управление: цель, план, обратная связь и т.д.
Это -- менеджер.
 AVC


№ 4368   24-04-2007 05:02 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4350« (Руслан Богатырев)
___________________________
>>>Ни о каком языке конструирования он не говорил (а язык -- это принципиально).
Так ли уж принципиально? Таблица регистрации СОМ-компонентов вполне работоспособный механизм.
>>>И языку кластеров механизм импорта языка Оберон только помогает, поскольку в противном случае (в подходе ASU) импорт становится теневым и выносится на уровень операционный без регламентации (я уже приводил различия между языком и средой -- первый фиксирован, вторая -- с каждой версией принимает все новые более размытые очертания).
Тут по моему не очень четко сформулировано: смешиваются несколько утверждений.
>>>И языку кластеров механизм импорта языка Оберон только помогает
Т.е. в Вашей конструкции язык более высокого уровня хорошо согласуется с Обероном? Очень хорошо и естественно, т.к. Вы разрабатывали кластерный подход изначально исходя из Оберона в качестве базы. Значит ли это, что такая пара языков лучше других?
>>>поскольку в противном случае импорт становится теневым и выносится на уровень операционный без регламентации.
Очень спорное утверждение, что стандартизовать можно только язык.
Реализации языков тоже заметно отличаются друг от друга. А стандарты на физические интерфейсы соблюдаются тщательно и часто обеспечивают обратную совместимость.
Почему Вы думаете, что на операционном уровне регламентация невозможна? Потому, что сейчас этого нет? Очень сомнительный аргумент.





№ 4367   24-04-2007 04:45 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4365« (Как слышно? Приём!)
___________________________

Спасибо. Смешное сравнение :)

За этим у нас не заржавеет. Лишь бы польза была.

Раз уж затронул тему строительства применительно к программированию, хотел бы обратить внимание вот на какие аналогии:

1) строительство -- заказное и полузаказное ПО (промышленное производство);
2) автомобилестроение (машиностроение) -- тиражируемое ПО (промышленное производство);
3) народный промысел -- заказное ПО (индивидуальное производство), частный сектор условно-бесплатного ПО.

При этом программист по характеру деятельности (диктуется склонностями, это может быть как в индивидуальном производстве, так и в промышленном):
1. просто умелец (на все руки мастер)
2. монтажник
3. плиточник-облицовщик
4. сантехник
5. технолог
6. архитектор
7. инженер
8. врач
9. учитель
10. писатель


<<<... | 4386—4377 | 4376—4367 | 4366—4357 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 189


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

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

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

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

Перейти на конкретную страницу по номеру
  
Время на сайте: 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» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

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