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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

<<<... | 3606—3597 | 3596—3587 | 3586—3577 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 267


№ 3596   28-03-2007 04:38 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3595« (Сергей Перовский)
___________________________

Ответ на »сообщение 3592« (info21)
___________________________
>>>уметь жонглировать символами и производить формализмы -- не то же самое, что понимать науку-математику
Это слишком сильное утверждение.


Как могут быть слишком сильными утверждения того же порядка, что и "борщ это не бифштекс"?
Или мы собираемся скатиться на уровень "теста Тьюринга" и всерьез утверждать, что если компьютер можно научить преобразовывать формулы, то он "понимает" алгебру?

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


№ 3595   28-03-2007 04:26 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3592« (info21)
___________________________
>>>уметь жонглировать символами и производить формализмы -- не то же самое, что понимать науку-математику
Это слишком сильное утверждение.
Есть профессиональные математики, работа которых, в некотором смысле, как раз "жонглировать символами и производить формализмы". Без понимания тут никуда, но это понимание очень абстрактных вещей.
Инженерный взгляд на матиматику состоит в приведении к формализму конкретных практических задач. К сожалению термин "прикладная математика" стал пониматься очень узко, как вычислительная математика.
А не хватает именно прикладной математики и в подготовке математиков и в подготовке инженеров. Инженер с фундаментальным (в том числе математическим) образованием у нас редкость.


№ 3594   28-03-2007 03:58 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3593« (Как слышно? Приём!)
___________________________

Ответ на »сообщение 3592« (info21)
___________________________
Мама моя!
Что такое "понимать науку-математику"?
It is a question!


Тогда уж в корень: что такое вообще -- "понимать"?
А потом применить это к математике.
 AVC


№ 3593   28-03-2007 02:59 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3592« (info21)
___________________________
Мама моя!
Что такое "понимать науку-математику"?
It is a question!


№ 3592   28-03-2007 02:18 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3585« (К)
___________________________

Ответ на »сообщение 3584« (info21)
___________________________
Не к математике, а к представлениям о ней людей, ее не понимающих. Таких, разумеется, подавляющее большинство, всюду.
Например, к таковым, без сомненья, можно отнести Дейкстру и Бэкуса...


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

Примерно как делать детей -- не то же самое, что понимать науку генетику.


№ 3591   27-03-2007 17:17 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3589« (Руслан Богатырев)
___________________________

Вложите функцию (ее и только ее) в отдельный модуль. Назовем его для определенности модулем-функцией.

Думаю, это очевидно, но на всякий случай поясню. В такой модуль можно вкладывать не одну, а несколько функций. Аналогично тому, как это происходит с Оберон-классами. Т.е. в безоболочном виде (No Paranoia Rule) они могут общаться друг с другом внутри коробки-саркофага. Количество и состав компонуемых вместе функций в одном "функциональном" модуле диктуется задачей и выбором решения разработчиков.

Теперь видно, что ФП и ООП не конфликтуют с МП в лице Оберона именно в силу того, что мудрый Вирт предусмотрел возможность конфликта и отсек его еще на дальних подступах. ФП не может обойтись без ИП. Имитировать ИП на ФП да еще имея в виду "императивное" железо и императивный run-time много заковыристее, нежели наоборот. А имитировать приходится, ибо ФП со всех сторон окружают ИП-агрессоры. И в их мире надо выживать.  :)


№ 3590   27-03-2007 16:33 Ответить на это сообщение Ответить на это сообщение с цитированием
Небольшое замечание относительно термина "кластерно-модульное программирование". Почему я дал именно такое название.

1. Идея модулей появилась не у Дэвида Парнаса, а парой лет раньше -- у Петера Наура. И назвал он модули "кластерами действий" (Peter Naur "Programming by action clusters". BIT, 1969, #9). Ссылку на эту редкую работу, кстати, Вирт привел еще в своей знаменитой классической работе "Program Development by Stepwise Refinement" (1971) -- http://www.europrog.ru/paper/nw1971.pdf

2. Идея кластеризации (термин хорошо известен в области обработки данных и в сфере "железа") приглянулась Барбаре Лисков (MIT) и она застолбила этот термин для своего языка абстрактных типов данных -- CLU (1975). Собственно CLU есть "половинка" от CLUSTER. Кластер Барбары Лисков -- это своего рода модуль (АТД-модуль), в котором инкапсулированы (связаны друг с дружкой) абстрактный тип данных (АТД) и операции над ним. CLU относят к языкам модульного программирования.

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


№ 3589   27-03-2007 16:12 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3543« (Jack Of Shadows)
___________________________

>>>Во вторых, законный вопрос, почему это проблема в ООП, но не в ФЯ ?
Потому что ООП стоит на пути решения этой проблемы, мешается под ногами, ставит палки в колеса.
В то время как ФП доступ к решению этой проблемы совершенно прозрачен, между вами и решением нет никакой жесткой структуры вроде иерархии классов. Поскольку в ФП функции тоже являются данными, то их можно динамически передавать "сквозь" любую структуру данных, чего в ООП не сделаешь.

>>>В третьих, может есть альтернативное решение? Может в Оберон-системах, это решается по-другому?
А что уже есть какое то отдельное Оберон-программирование, которое в принципе отличается от ООП ?


Удивительное дело. Почти год назад в соседней ветке, посвященной ФП, я написал в сообщении #57, цитирую: Провокационный вопрос. Вообразим на минутку, что в Обероне мы пишем так, что модули имеют и экспортируют исключительно процедуры-функции, которые не хранят никаких состояний и которые на одни и те же аргументы возвращают один и тот же результат. Это и есть функциональное программирование в императивном языке?

А воз и ныне там. Хорошо, давайте разбираться.

Что есть Оберон? Это язык модульного программирования, в котором есть все необходимые основы императивного программирования, а также средства для построения ООП (конструктор из разряда "собери сам"). В КП этот конструктор вынесен на другой уровень, приближающий язык к мэйнстрим-пониманию ООП, но при этом нижний уровень (классического Оберона) сохранен. Этот уровень складывается из идеи построения классов через записи и ссылки (идея Тони Хоара, реализована в Algol W и классическом Паскале образца 1970 г.). Оберон расширил эту идею, добавив type extension -- "наследование" типов.

ООП в трактовке Алана Кея (Smalltalk) и нынешнее ООП, как уже говорилось, -- разные вещи. В Smalltalk уйма степеней свободы (каждый объект -- это маленький компьютер, "компьютеры" обмениваются сообщения, "коммутация" осуществляется по схеме "сообщение-->метод"), а в нынешнем -- тупой полиморфический вызов метода. В мэйнстрим-ООП у всех объектов данного класса методы одинаковые (методы-константы), у Оберона это ссылки, поэтому методы могут быть разными (методы-переменные).

Если более-менее понятно, что Оберон (классический) не помещен в "прокрустово ложе" мэйнстрим-ООП, можно идти дальше. Идем.

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

Подойдут ли они как аналог функций ФП? Давайте посмотрим. Для функций ФП необходимо выполнение определенных требований. Во-первых, надо отсечь побочные эффекты, которые возникают из-за прозрачности процедуры-функции (автоматически снаружи все импортируется, а "экспорт" идет через формальные параметры и имя функции-результата). Во-вторых, функции ФП оперируют в качестве параметров другими функциями (high-order functions). Про атомы, списки и кортежи мы тут рассуждать не будем -- это все легко представляется динамическими структурами данных и плодится в безбожных объемах через ту же динамическую память.

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

Теперь опишите процедурный тип, в котором прописывается интерфейс нашей функции (сигнатура). Его экспортируем (ставим звездочку). Теперь переходим ко второму требованию. Вирт для того и ввел процедурные переменные, чтобы решить эту задачу (язык Эйлер, Euler). Сделал это, анализируя в начале 1960-х годов ФП и пытаясь найти удобное обобщение Алгола-60. У него появились ссылки на процедуры (процедурные переменные). Они же решили и задачу ухода от передачи формальных параметров по имени (помимо передачи по значению и по ссылке). Ссылки на процедуры -- это процедурные типы (и соотв. им переменные). Собственно экспорт интерфейса функции нужен именно для оперирования ею как обычным типом данных (в смысле атомов, списков и кортежей ФП). Не будем забывать и про то, что в Обероне можно объявлять локальные процедуры (сколь угодно глубоко вкладывать новые функции внутрь "родительских"). Это тоже полезное дело в смысле ФП. Так что контекстом управляем полностью.

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

Так чего же тут бедному Оберону не хватает для полноты счастья ФП? Или очень все сложно?



№ 3588   27-03-2007 14:02 Ответить на это сообщение Ответить на это сообщение с цитированием
Похоже, народ устал после бурных дебатов. :)
Наверное, и правда требуется передышка.

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

Ответ на »сообщение 3582« (AVC)
___________________________
сомнительные места обобщенного программирования.
Не усёк, где оные сомнительные места?


Сомнительные места -- те, которые вызывают сомнения. :)
В данном случае, сомнения возникли у меня.
Сомнения -- это всего лишь сомнения, а не приговор. :)

О чем речь.
В приведенных Джеком примерах аспектного программирования, например pointcut before *.SSN SecureSSN, вызывает сомнение, что аспект применим к полю только на основании его текстового имени, никакого родства классов, помеченных звездочкой, не требуется.
Возникла ассоциация, что и в обобщенном программировании требуется только текстовое совпадение, чтобы текстовая строка была применима к конкретному типу переменной.
Вот это мне и кажется сомнительным, т.е. вызывает сомнение.
До тех пор, пока не увидел это в аспектном программировании (т.е. в чем-то для себя непривычном), просто не обращал на это внимания.
 AVC


№ 3587   27-03-2007 07:20 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3585« (К)
___________________________

Ответ на »сообщение 3584« (info21)
___________________________
Не к математике, а к представлениям о ней людей, ее не понимающих. Таких, разумеется, подавляющее большинство, всюду.
Например, к таковым, без сомненья, можно отнести Дейкстру и Бэкуса...

Любое программирование - это формальная система. Любая формальная система одинаково "близка к математике"...
Другой вопрос о близости используемой нотации/конструкциям к стандартно-математическим. Тут ФП, естественно, к ней ближе. Лично я считаю это только минусом - меньшая выразительность с точки зрения инженера...


<<<... | 3606—3597 | 3596—3587 | 3586—3577 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 267


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

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

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

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

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

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