OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 17:59

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




Начать новую тему Ответить на тему  [ Сообщений: 132 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7  След.
Автор Сообщение
СообщениеДобавлено: Суббота, 15 Январь, 2011 01:17 
Модератор
Аватара пользователя

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

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

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

Чтобы нормально "шаблонизировать", нужен аппарат типов и абстракций уровня того же Хаскелля. Я считаю такую цену неприемлемой. Слишком сложный аппарат.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Январь, 2011 01:17 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Alexey Veselovsky писал(а):
А поскольку основные циклы стандартны, а их множество вполне конечно, то.. То их и не надо писать каждый раз вручную! Они должны быть в стандартной либе в виде обобщенных функций. Вот и всё.

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

Хотя, в свете рассуждений об оптимизациях современных супер-скалярных пупер-процессоров становится непонятно, а как реально оценить стоимость такого ручного цикла? Не будет ли это оценкой плюс-минус лапоть?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Январь, 2011 01:26 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
Если Вы просто "обходитесь без брейков", то это, чаще всего, далеко не то, об чём речь. Булевские флаги понатыкать - те же яйцы :) Булевских флагов точно так же в нормально составленном цикле (кроме редких случаев) быть не должно. Хотя они чуть лучше брейков иногда, немного явнее семантика видна.

---
О чём речь, не раз уже показывалось на примерах, типа вот этого: http://oberoncore.ru/wiki/%D1%81%D1%82% ... 0%BB%D0%B0

Вот такое четырёхэтажное условие:
Код:
WHILE (b # NIL)
   & P(b) & P2(first, b)
   & P3(ta, tb, init_transformed)
   & (~P4() OR (f(b) = count))
DO
имхо приводят к труднопонимаемому коду и потенциально затруднит в дальнейшем модификацию/дополнение этого цикла.
Придётся действительно просто переписать цикл заново. Хотя необязательно это плохо. Переписанный вариант может оказаться лучше заточенным под изменённую постановку задачи, чем дополненный первоначальный...


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
В том споре с аффатаром исходного цика Info21 сразу заметил, что программа плохо структурирована уровнем выше, чем этот цикл.
Было исправлено то, что можно было сделать в рамках цикла.

РАЗУМЕЕТСЯ, если получается такая громотуха, значит, что-то организовано паршиво в программе. Надо перестраивать что-то в структурах данных и их обработке.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Январь, 2011 01:42 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Это старый такой "сладкий сон", что похожие, подобные вещи можно все упаковать в какие-то "либы".

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

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

Чтобы нормально "шаблонизировать", нужен аппарат типов и абстракций уровня того же Хаскелля. Я считаю такую цену неприемлемой. Слишком сложный аппарат.


Можно уровня окамла. Он совсем же простой. Можно ещё проще на самом деле. Аппарат типов в полную мощ у Хаскелля работает далеко не на этих однотипных циклах. Он там нужен для другого. Кроме того, хаскелл прост в применении, а типы никакой нагрузки на время исполнения программы не дают вообще. Непонятно, где там неприемлемая сложность то?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Январь, 2011 01:44 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Geniepro писал(а):
Тут противоречие с требованием Ильи -- стоимость этой обобщённой функции не видна в месте её использования, в отличии от вручную расписанного цикла.

У обобщенной функции есть только обобщенная сложность :-) Ведь она зависит от того к чему её применить. И как раз сложность, в месте применения, будет отлично видна.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Alexey Veselovsky писал(а):
Кроме того, хаскелл прост в применении, а типы никакой нагрузки на время исполнения программы не дают вообще. Непонятно, где там неприемлемая сложность то?


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


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

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Во-первых, мой ограниченный мозг не может вместить в себя его за приемлемое для меня время (например, за один-два вечера).

За один два вечера и оберон целиком в мозг не вместить, не говоря уже о компонентном паскале.

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

Мы пользуемся тучей вещей которые мы в одиночку/семьей/группой из человек 10, не сможем реализовать в полном объеме самостоятельно, значит ли это что от них стоит отказываться?

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


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Alexey Veselovsky писал(а):
Мы пользуемся тучей вещей которые мы в одиночку/семьей/группой из человек 10, не сможем реализовать в полном объеме самостоятельно, значит ли это что от них стоит отказываться?


Ну, какой-то уровень мы принимаем за "элементную базу", которая нам уже дана "как есть".

К тому же, приведёнными в примере вещами мы пользуемся в жизни, но не в своей проектной деятельности, не правда ли?

В программировании тоже какой-то уровень приходится принимать за "элементную базу". ОС, например. В ряде случаев - СУБД. Какие-то библиотеки, которые нужны по случаю и являются непрофильными для компании. И т.п.

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

На самом деле, это доступный и понятный критерий для решения "применять-не применять". Почему его приходится использовать? Потому что я знаю очень мало технологий в ИТ, которым я мог бы доверять, в том смысле, что разработчики достаточно подумали над проблемой и сделали реально самое простое и надёжное решение. Большинство существующего, если приходится использовать, то "скрипя зубами".
Есть разные критерии для доверия. Ну, например, если я смотрю на проект... ну, скажем, СУБД "Седна" и вижу его динамику на протяжении 3-4 лет - и не вижу ни роста объёма, ни новых фич, а только доведение до XML-стандартов и совершенствование внутренних механизмов, то я уже доверяю разработчикам. Я вижу, что они хорошо думают. (Хотя я не могу сказать, что я сильно доволен XML-XQuery-XMLSchema.... Объективно они решают ряд проблем, но спроектированы на 70% избыточно, "комитетски". Но разработчики "Седны" вынуждены брать его за "элементную базу", менять они стандарты эти не могут.)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Январь, 2011 02:30 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Alexey Veselovsky писал(а):
Мы пользуемся тучей вещей которые мы в одиночку/семьей/группой из человек 10, не сможем реализовать в полном объеме самостоятельно, значит ли это что от них стоит отказываться?


Ну, какой-то уровень мы принимаем за "элементную базу", которая нам уже дана "как есть".

К тому же, приведёнными в примере вещами мы пользуемся в жизни, но не в своей проектной деятельности, не правда ли?

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


Инструменты же программирования, на самом деле, настолько доступная для понимания и реализации штука, что "нет там ничего военного", чтобы не применять критерий "а можем ли воспроизвести сами".[/quote]
То же самое можно сказать и про ОС. Там тоже "нет ничего военного".

Илья Ермаков писал(а):
На самом деле, это доступный и понятный критерий для решения "применять-не применять".

На самом деле верен критерий иной -- при прочих равных, бери то, что проще в реализации. В данном же случае "прочих равных" не наблюдается.
Илья Ермаков писал(а):
Почему его приходится использовать? Потому что я знаю очень мало технологий в ИТ, которым я мог бы доверять, в том смысле, что разработчики достаточно подумали над проблемой и сделали реально самое простое и надёжное решение.
А я не знаю ни одной такой технологии, но это не повод всё бросить и начать ваять свои велосипеды, потому как к своим велосипедам доверия ещё меньше. Более того, я полагаю что не может существовать хоть скольконибудь универсальной технологии которая отвечала бы этим критериям. Ну нет там глобального необходимого и достаточного минимума сложности, для универсального инструментария. Для какой-то узкой (очень узкой!) задачи -- да, возможно оно и есть. Но как только задача чу-уть чуть поменяется, всё. Система в этом плане не устойчива.
Илья Ермаков писал(а):
Я вижу, что они хорошо думают. (Хотя я не могу сказать, что я сильно доволен XML. Объективно он решает ряд проблем, но спроектирован он на 70% избыточно,

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


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

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 710
Откуда: Псков
Geniepro писал(а):
Выглядит уже неплохо, но смущает пустое тело цикла... :о)

2 Geniepro
Ну это как бы редуцированный вариант циклов такого рода:
while (сказалА) {сказатьБ}
где сказалА - функция, которая и делает и возвращает успешность делания
Мне нравится наглядность таких циклов и их безбрейковость.
Это как бы расширение (цикличное)
if сказалА then сказатьБ
Достаточно много ситуаций попадают под такой цикл.
while (ЕстьПорцияДанных(данные)) { обработатьДанные(данные) }
и т.п.
Главное, что можно избежать необходимости выполнять один и тот же код до входа в while и в теле цикла и т.д.
Ну а без тела цикла тоже иногда весьма кошерно:
while (Дышу) {} где функция Дышу и делает один такт дыхания :)
while (НямНям) {} :)


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Alexey Veselovsky писал(а):
Избыточно для каких задач? Не допускаете ли вы возможности, что люди которые создавали и развивали стандарты на XML имели как минимум более разнообразный опыт проектов, видели более широкий круг задач, и именно под эти задачи XML и делался? Следует очень четко осознавать, что опыт отдельновзятого человека либо очень узок либо очень мелок. Отдельновзятой конторы (если это не гигант вроде IBM) -- тоже.


Пусть поступают "микроядерно". Простейшее ядро и возможность надстраивать слои. И слои на выбор.

Та же XML Schema, с которой мне приходится работать - можно было бы ограничить количество возможностей уровнем типа БНФ-грамматик. Слишком громоздко и много всего надо держать в голове.

Между прочим, почему не состоялась идея "рынка компонентов" и по сей день? Из-за того, что компонентные стандарты типа CORBA и COM были столь громоздкими, что работать в их рамках слишком накладно для обычных участников этого потенциального рынка...

Ведь у всех перед глазами пример достаточно удачных слоёных технологий, где слои довольно тупые - тот же Internet и Web. Каждый уровень занимается своим делом.


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

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Между прочим, почему не состоялась идея "рынка компонентов" и по сей день? Из-за того, что компонентные стандарты типа CORBA и COM были столь громоздкими, что работать в их рамках слишком накладно для обычных участников этого потенциального рынка...

Стоп. Почему не состоялась? Чем библиотека не компонента?


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

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

http://oberoncore.ru/wiki/component_soft


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

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Идеология компонентного ПО предполагает несколько другое. В частности, объектно-ориентированный стиль сборки из "кубиков". И т.п.

http://oberoncore.ru/wiki/component_soft

Всё это есть. Посмотрите например на многочисленные реализации различных jsr'ов. Где в спецификации зафиксирован стандартом интерфейс и свойства, а на гм. "рынке" есть множество компонент реализующих его. Правда они по большей части свободные :-)

Продавать компоненты не интересно и не выгодно. А покупать их -- тем более. Выгодно их совместно разрабатывать. Ну и продавать уже техподдержку/консультационные услуги.


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

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Интересно. И Вы можете взять один jsr от одного поставщика, второй jsr от другого и запустить это всё на jvm третьего хотя бы теоретически?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Январь, 2011 17:30 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 563
Откуда: Москва
Geniepro писал(а):
Alexey Veselovsky писал(а):
А зачем там на каждой итерации проверяется SrvIPStream != null ? В цикле ничто его не меняет. Разве что из другого потока кто-то что-то поменяет... С другой стороны, ничто не мешает ссылку у себя сохранить, гарантируя что ссылка всегда будет не ноль, (ведь объект этот из памяти его никто не вышвырнет пока на него есть ссылки) и проверять просто может оно писать или нет.

Нет гарантии, что SrvIPStream не будет уничтожен в других процессах...
А не слишком ли вольно идет обращение с SrvIPStream?
Код:
if (SrvIPStream != null) {
//здесь SrvIPStream уже может быть == null: другой поток позаботился
}


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Январь, 2011 17:51 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Comdiv писал(а):
Интересно. И Вы можете взять один jsr от одного поставщика, второй jsr от другого и запустить это всё на jvm третьего хотя бы теоретически?

jsr это спецификация. Она текстовая и на английском :-)
Да, я могу реализации смешивать как угодно и запускать на разных jvm (jvm может называться jvm только после того как прошла сертификация и тестирование на соответствие спек на jvm).


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

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Да, проблема рынка компонент (не важно платного или бесплатного), не в монструозности COM/Corba/Иного, а в спецификациях на эти компоненты.

Кто будет составлять и стандартизировать спецификации для компонент? Для всякой мелочи десктопной это особого смысла не имеет. Слишком долго дорого и некому. Нет спецификации, как понимаете нет и компонент (библиотек) которые им бы соответствовали => нет вожделенного "рынка компонент". В результате каждый реализует для данного направления свою библиотеку и публикует её. У библиотек функционал схожий, интерфейс иногда тоже схожий, но для переезда с одной либы на другую нужно обычно несколько поработать напильником.

Если же не брать десктопную мелочь, а брать сетевую инфраструктуру/телеком, то там всё давно хорошо (относительно конечно). Есть спецификации для компоненты. Ну, например rfc 3261 :-) Или XEP-0114. Или rfc 3525. И есть компоненты которые их реализуют. Они продаются, свободно распространяются и т.п. Из этих компонент строят инфраструктуру которая уже решает конкретную бизнес задачу.

Да, они обычно не работают в общем адресном пространстве, да и вообще на разных машинах могут работать. Ну и что? Компонентами они от того быть не перестают. :-)


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

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Alexey Veselovsky писал(а):
jsr это спецификация. Она текстовая и на английском :-)
Да, я могу реализации смешивать как угодно и запускать на разных jvm (jvm может называться jvm только после того как прошла сертификация и тестирование на соответствие спек на jvm).

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


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

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


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

Сейчас этот форум просматривают: Google [Bot] и гости: 9


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

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