OberonCore
https://forum.oberoncore.ru/

Про общеупотребимые компоненты.
https://forum.oberoncore.ru/viewtopic.php?f=47&t=4403
Страница 2 из 5

Автор:  Илья Ермаков [ Пятница, 19 Июль, 2013 22:58 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

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

Автор:  Иван Кузьмицкий [ Пятница, 19 Июль, 2013 23:04 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

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

Автор:  Илья Ермаков [ Пятница, 19 Июль, 2013 23:05 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

Иван Кузьмицкий писал(а):
Разрешите подписаться. Чем писать собственные, к примеру, сортировки, лучше взять подходящую готовую из библиотеки и получить работающий прототип системы. Если в дальнейшем прижмёт с оптимизацией, можно потратиться на переписывание. К тому же, стандартные решения (подходящие для 80-90 процентов случаев), как правило, и более безопасны - потому что комьюнити уже успело наступить на все возможные грабли.


На самом деле, речь-то не о том, что плохо иметь что-то подходящее готовое. Речь о том, что пригодная для общего пользования стандартизация подобных алгоритмов требует добавления в язык целого пласта средств (не одного какого-нибудь средства, а именно пласта - всего, что тянет с собой обобщённое программирование в стиле STL-ей и прочих). Поэтому и идут дискуссии, в которых на чашу весов "против", к вот этой необходимости засорить язык средствами, которые нигде особо, кроме таких сверхобобщённых библиотек, не полезны, докладываются и другие доводы, в духе "а так ли оно и хочется, иметь такие библиотеки".
То же было ведь когда-то и с Delphi, да и Java... Библиотеки на уровне "список из anyptr".

Автор:  Jordan [ Пятница, 19 Июль, 2013 23:09 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

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

Автор:  Jordan [ Пятница, 19 Июль, 2013 23:11 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

Еще нужно заметить, без шаблонов, программисту нужно.

1. Или писать в сотый раз, реализацию контейнера.
2. Использовать обобщенный на поинтерах, но с приведением типа.

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

Автор:  Иван Кузьмицкий [ Пятница, 19 Июль, 2013 23:16 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

Илья, и всё же. Вот есть компонент для создания Md5-хэшей. Писать самому такое довольно накладно, а использовать готовый компонент просто. Или генератор ODF. Или ещё что-то подобное. Сверхобобщённых формализмов не надо, пусть сортировка на Обероне требует реализации абстрактной RECORD, я легко пойду на это - потому что это в десятки раз дешевле написания и отладки собственной необобщённой сортировки.

Автор:  Пётр Кушнир [ Пятница, 19 Июль, 2013 23:32 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

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

Автор:  Alexey Veselovsky [ Пятница, 19 Июль, 2013 23:52 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

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


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

Автор:  Пётр Кушнир [ Суббота, 20 Июль, 2013 00:27 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

Вопрос-манипуляция. Веселовский, тебе разве не очевидно, что если бы первый вариант был реализуем в ББ, его бы давно реализовали?
Ах да, ты же с оберспейса.

Автор:  Comdiv [ Воскресенье, 21 Июль, 2013 20:58 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

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

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

Но и в таком виде целесообразность для меня, как программиста-любителя не очевидна. Недавно мне понадобился расстановочный(хэш) массив. После рукописной реализации на Си, которая заработала сразу после компиляции, я призадумался, и решил сравнить это решение с STL-ным в С++. Разбор документации, в том числе неочевидных нюансов, занял у меня больше времени, чем наивное решение. Код вместе с обвязкой, абстрагирующей предметную область от реализации, оказался лишь в 2-а раза меньше. С учетом редкости использования подобной структуры, набитые шишки мне не пригодятся в будущем - успею забыть.

Увы, ценность библиотеки падает в связи с тем, что ею пользоваться тоже надо уметь, и определяется зависимостью от соотношения частоты, сложности использования и простоты лежащего внутри механизма. Одно дело MD5, другое дело простая сортировка. Еще это, конечно же, зависит от человека. Одним проще выучить таблицу синусов-косинусов для стандартных углов, другим проще вывести нужное значение на бумажке. Кому требуется угодить?

Автор:  Comdiv [ Понедельник, 22 Июль, 2013 00:14 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

Свидетельство от разработчика RSS - читалки для еще не вышедшего Ubuntu Phone в подтверждение моим сомнением из предыдущего сообщения.
http://habrahabr.ru/post/187284/
Цитата:
Оба моих тиммейта достаточно опытные в разработке с использованием Qt (в среднем 4 года) и QML (2 года). Но и с таким опытом они порой удивляли меня своими велосипедами.

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

Автор:  Иван Денисов [ Понедельник, 22 Июль, 2013 13:05 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

Нет желания заводить отдельную папку под списки, сильно жирно для них.

Возникла идея, сделать Lists для Omc (One Module Component), HashTable и т.п.
OmcLists
OmcHashTable
OmcMd5
...
Туда же перенести разные плюшки i21sys, которые укладываются в один модуль Вроде Desktop, Calls
OmcDesktop
OmcCalls

Ну и пополнять...

Я, правда, не понимаю логики почему omc с маленькой буквы сделали... какое-то уродство, все папки с большой, а эта видите-ли с маленькой, как и i21sys.

Автор:  Пётр Кушнир [ Понедельник, 22 Июль, 2013 13:37 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

Тогда должно было быть OMC (если создавать аббревиатуру One Module Component).
Но модули из omc не предполагается использовать напрямую, насколько я понял. Их надо копировать себе в подсистему.

Автор:  Пётр Кушнир [ Понедельник, 22 Июль, 2013 13:54 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

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

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

Автор:  Пётр Кушнир [ Понедельник, 22 Июль, 2013 14:12 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

В целом, понятно, что люди смогут использовать компоненты почти сразу, без особых сомнений, только если за этим компонентом будет стоять авторитетный источник доверия этому компоненту. Что-то типа института стандартизации. Или корпорации Гугл. Все это понимают, но справиться с собой не могут. Ну, расточительно это, изучать что-то незнакомое.

Автор:  Иван Кузьмицкий [ Понедельник, 22 Июль, 2013 14:47 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

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

Автор:  Пётр Кушнир [ Понедельник, 22 Июль, 2013 14:58 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

Иван Кузьмицкий писал(а):
Компоненты должны быть проверенными и надёжными. Кто даст гарантию работоспособности? Никто в здравом уме не будет хвататься за первый попавшийся компонент, который может тут же взглючить - по одной простой причине, ведь доводка сырого компонента может выйти дороже.
Я уже указал эту причину, как одну из причин ненужности компонентов от оберонкоры, и вообще от кого либо, кроме субъекта уровня Гугла, чтобы глобально надёжно. В ветке про патчи к ББ довольно много комментариев с патчами, но мгновенно слил ББ разве что веселовский. Аналогично можно поступить с неудачными детьми, как там, в анекдоте "Этих отмоем или новых нарожаем?".

Гарантии надёжности может дать совместная работа по багфиксу, в общем. Но об этом речи быть не может.

Автор:  Иван Кузьмицкий [ Понедельник, 22 Июль, 2013 15:05 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

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

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

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

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

Автор:  Пётр Кушнир [ Понедельник, 22 Июль, 2013 15:14 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

Я уже перечислил все причины, нет нужды их повторять.
Да, эта точка зрения имеет право на существование.

Автор:  Пётр Кушнир [ Понедельник, 22 Июль, 2013 15:20 ]
Заголовок сообщения:  Re: Про общеупотребимые компоненты.

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

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