OberonCore
https://forum.oberoncore.ru/

"Стоимость", уровень языка и абстракций
https://forum.oberoncore.ru/viewtopic.php?f=27&t=3157
Страница 4 из 7

Автор:  Илья Ермаков [ Суббота, 15 Январь, 2011 01:17 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

Это старый такой "сладкий сон", что похожие, подобные вещи можно все упаковать в какие-то "либы".

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

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

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

Автор:  Geniepro [ Суббота, 15 Январь, 2011 01:17 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

Alexey Veselovsky писал(а):
А поскольку основные циклы стандартны, а их множество вполне конечно, то.. То их и не надо писать каждый раз вручную! Они должны быть в стандартной либе в виде обобщенных функций. Вот и всё.

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

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

Автор:  Geniepro [ Суббота, 15 Январь, 2011 01:26 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

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

---
О чём речь, не раз уже показывалось на примерах, типа вот этого: 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 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

В том споре с аффатаром исходного цика Info21 сразу заметил, что программа плохо структурирована уровнем выше, чем этот цикл.
Было исправлено то, что можно было сделать в рамках цикла.

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

Автор:  Alexey Veselovsky [ Суббота, 15 Январь, 2011 01:42 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

Илья Ермаков писал(а):
Это старый такой "сладкий сон", что похожие, подобные вещи можно все упаковать в какие-то "либы".

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

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

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


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

Автор:  Alexey Veselovsky [ Суббота, 15 Январь, 2011 01:44 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

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

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

Автор:  Илья Ермаков [ Суббота, 15 Январь, 2011 01:48 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

Alexey Veselovsky писал(а):
Кроме того, хаскелл прост в применении, а типы никакой нагрузки на время исполнения программы не дают вообще. Непонятно, где там неприемлемая сложность то?


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

Автор:  Alexey Veselovsky [ Суббота, 15 Январь, 2011 02:04 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

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

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

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

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

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

Автор:  Илья Ермаков [ Суббота, 15 Январь, 2011 02:16 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

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


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

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

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

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

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

Автор:  Alexey Veselovsky [ Суббота, 15 Январь, 2011 02:30 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

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


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

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

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


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

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

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

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

Автор:  albobin [ Суббота, 15 Январь, 2011 14:27 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

Geniepro писал(а):
Выглядит уже неплохо, но смущает пустое тело цикла... :о)

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

Автор:  Илья Ермаков [ Суббота, 15 Январь, 2011 16:03 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

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


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

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

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

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

Автор:  Alexey Veselovsky [ Суббота, 15 Январь, 2011 16:10 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

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

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

Автор:  Илья Ермаков [ Суббота, 15 Январь, 2011 17:13 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

Идеология компонентного ПО предполагает несколько другое. В частности, объектно-ориентированный стиль сборки из "кубиков". И т.п.

http://oberoncore.ru/wiki/component_soft

Автор:  Alexey Veselovsky [ Суббота, 15 Январь, 2011 17:17 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

Илья Ермаков писал(а):
Идеология компонентного ПО предполагает несколько другое. В частности, объектно-ориентированный стиль сборки из "кубиков". И т.п.

http://oberoncore.ru/wiki/component_soft

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

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

Автор:  Comdiv [ Суббота, 15 Январь, 2011 17:22 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

Интересно. И Вы можете взять один jsr от одного поставщика, второй jsr от другого и запустить это всё на jvm третьего хотя бы теоретически?

Автор:  Peter Almazov [ Суббота, 15 Январь, 2011 17:30 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

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

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

Автор:  Alexey Veselovsky [ Суббота, 15 Январь, 2011 17:51 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

Comdiv писал(а):
Интересно. И Вы можете взять один jsr от одного поставщика, второй jsr от другого и запустить это всё на jvm третьего хотя бы теоретически?

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

Автор:  Alexey Veselovsky [ Суббота, 15 Январь, 2011 18:06 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

Да, проблема рынка компонент (не важно платного или бесплатного), не в монструозности COM/Corba/Иного, а в спецификациях на эти компоненты.

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

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

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

Автор:  Comdiv [ Суббота, 15 Январь, 2011 18:07 ]
Заголовок сообщения:  Re: "Стоимость", уровень языка и абстракций

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

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

Страница 4 из 7 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/