OberonCore https://forum.oberoncore.ru/ |
|
Стандартная библиотека контейнеров и алгоритмов https://forum.oberoncore.ru/viewtopic.php?f=47&t=4246 |
Страница 1 из 3 |
Автор: | Маздайщик [ Вторник, 05 Февраль, 2013 18:14 ] |
Заголовок сообщения: | Стандартная библиотека контейнеров и алгоритмов |
Раньше программисты сортировали так: Код: … for i := 0 to len(items) - 2 do for j := i + 1 to len(items) - 1 do if items[j] < items[i] then swap(items[i], items[j]); … Сейчас сортируют вот так: Код: items.sort(); В большинстве мейнстримовых языков есть стандартные средства для организации контейнеров: вектора-массивы, списки, отображения (хеш-таблицы либо деревья), а также некоторые алгоритмы, применимые для работы с ними: сортировка, удаление дубликатов, двоичный поиск и т.д. Где-то эти механизмы встроены в язык (Python), где-то поставляются с библиотекой. Обобщённые контейнеры могут быть реализованными либо как контейнеры объектов корневого типа Object (ранняя Java), либо как generic’и (C++, поздняя Java, C#). В отличии от Ады (и от поздних извращений стандартной Модулы), в Обероне/КП дженериков нет, значит, по идее, должна быть какая-нибудь библиотека контейнеров, основанная на корневом типе (ANYREC). Я некоторое время изучал встроенную документацию BlackBox, таковую не нашёл. Не нашёл даже библиотечной функции сортировки (хотя таковая есть даже в C89). Я плохо искал или таковая библиотека, по замыслу создателей, действительно не нужна? |
Автор: | Пётр Кушнир [ Вторник, 05 Февраль, 2013 18:30 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
Надо у разработчиков спрашивать |
Автор: | Пётр Кушнир [ Вторник, 05 Февраль, 2013 18:51 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
Вообще, если принять за данность, что разработчики не дали нам списков, есть два варианта. Сказать, что Blackbox не нужен. Создать библиотеки списков, и использовать их везде, в своих проектах, а так же предоставить их сообществу. Сказать, что такие библиотеки не нужны, а списки правильно будет располагать в каждой подсистеме свои (пусть даже и копии модулей, но исчезает зависимость). У каждого варианта есть свои преимущества, но я, например, сторонник второго пути, поэтому появилась библиотека Lists. |
Автор: | Info21 [ Вторник, 05 Февраль, 2013 20:09 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
Надо доказывать, и доказательство должно быть очень весомым, почему в язык и компилятор встраивается то, что может быть вынесено в библиотеки. |
Автор: | Евгений Темиргалеев [ Вторник, 05 Февраль, 2013 20:10 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
Любой программист должен знать "Алгоритмы и структуры данных" (например, http://oberoncore.ru/library/algorithms ... structures). Чтобы: а) уметь адекватно применять готовые средства. б) уметь сочетать стандартные приёмы, реализуя ориентированные на задачу решения (которые могут в разы повышать эффективность в сравнении комбинированием отдельно взятых стандартных решений). Готовые компоненты по означенной тематике есть. См. http://oberoncore.ru/bbcc/ и http://oberoncore.ru/projects/cpc |
Автор: | Маздайщик [ Среда, 06 Февраль, 2013 15:49 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
Info21 писал(а): Надо доказывать, и доказательство должно быть очень весомым, почему в язык и компилятор встраивается то, что может быть вынесено в библиотеки. Я говорил про скриптовые языки вроде Python’а, JavaScript. Встраивание тех средств, которые могут быть вынесены в библиотеки, я нахожу допустимым только для скриптовых языков или языков предметной области. Для компилируемых языков общего назначения подобные средства должны быть по максимуму вынесены в отдельные библиотеки. Когда-то, когда я ещё только делал первые шаги в программировании, мне именно этим и понравился язык Си (Си++) — ввод-вывод был независим от языка, в отличие от Паскаля или Бейсика, где для ввода-вывода используются особые синтаксические конструкции: Write(x:10:5), PRINT A$ и т.д.То, что сам язык и компилятор должен иметь минимум особых средств, никак не противоречит тому, что вместе с языком должна распространяться достаточно удобная и обширная библиотека, одинаковая для всех реализаций. Пётр Кушнир писал(а): У каждого варианта есть свои преимущества, но я, например, сторонник второго пути, поэтому появилась библиотека Lists. Евгений Темиргалеев писал(а): Готовые компоненты по означенной тематике есть. См. http://oberoncore.ru/bbcc/ и http://oberoncore.ru/projects/cpc Спасибо за ссылки. В общем, стандартной библиотеки с такими средствами в Компонентном Паскале нет, есть несколько библиотек от сторонних разработчиков. Можно использовать либо их (тогда нужно тащить соответствующую стороннюю подсистему), либо самому изобретать велосипед. |
Автор: | Info21 [ Среда, 06 Февраль, 2013 19:02 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
Маздайщик писал(а): либо самому изобретать велосипед. Да ладно.У меня много динамических данных в самых разных задачах, но списки почему-то создаются добавлением в голову, а используются -- снятием с головы Тут любая библиотека сложнее будет. А если что-то более сложное, то там столько вариантом, что легче учесть конкретную специфику напрямую, чем бороться с библиотекой на все случаи жизни. Это много раз обсуждалось. |
Автор: | Валерий Лаптев [ Четверг, 07 Февраль, 2013 09:59 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
Маздайщик писал(а): В общем, стандартной библиотеки с такими средствами в Компонентном Паскале нет, есть несколько библиотек от сторонних разработчиков. Можно использовать либо их (тогда нужно тащить соответствующую стороннюю подсистему), либо самому изобретать велосипед. Дело в том, что и стандарта нет. Поэтому и стандартной библиотеки не наблюдается... |
Автор: | Александр Ильин [ Четверг, 07 Февраль, 2013 12:40 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
Есть In, Out и т.п. См. Oakwood Guidelines. Это и есть стандарт. |
Автор: | Info21 [ Четверг, 07 Февраль, 2013 18:19 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
Александр Ильин писал(а): Есть In, Out и т.п. См. Oakwood Guidelines. Это и есть стандарт. Oakwood Guidelines это не стандарт.Реальный стандарт -- библиотеки ББ. |
Автор: | Ярослав Романченко [ Пятница, 08 Февраль, 2013 13:52 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
Кстати, Клеменс Шиперский предлагал (в книге "Component Software: Beyond Object-Oriented Programming") добавить дженерики (параметрическим полиморфизмом кажется называлось) в КП, но идея почему-то не получила развития. |
Автор: | Info21 [ Пятница, 08 Февраль, 2013 20:49 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
Ярослав Романченко писал(а): но идея почему-то не получила развития. "Почему-то"?Потому что избыточная сложность. |
Автор: | Пётр Кушнир [ Пятница, 08 Февраль, 2013 21:26 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
А в каждый значимый модуль совать новый самодельный итератор/стек не сложно? |
Автор: | Ярослав Романченко [ Пятница, 08 Февраль, 2013 22:40 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
"Избыточная сложность" говорите? А сколько кода придётся налабать на КП/Обероне, что-бы описать подобную структуру данных? Код: TElement = class; И ведь есть языки в которых это можно, и работает весьма эффективно, тот-же ObjectPascal/Delphi...TDictionaryKey = TPair<string, string>; TDictionaryEntry = TPair<TDictionaryKey, TElement> TElementsDictionary = TDictionary<TDictionaryEntry>; TItemsList = TList<TElementsDictionary>; ЗЫ. И что-бы структура заработала как надо, нужно переопределить всего две простейших функции в TElementsDictionary. Подсчитаем количество кода? |
Автор: | Иван Денисов [ Пятница, 08 Февраль, 2013 23:31 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
Душевные мучения по поводу отсутствия списков и хеш-таблиц закончились после чтения "Алгоритмов и структур данных" и написания маленького примера для сравнения производительности дефолтной хеш-функции в python и, выбранной мной для конкретной задачи на КП. Универсальной хеш-функции не может быть, и манипуляции со списками также иногда лучше делать нетривиально. ИМХО, использование "дорогих" по производительности алгоритмов должно обходится "дороже" по времени для программиста, чтобы не забивать микроскопом гвозди, разрабатывать сбалансированные приложения. |
Автор: | Ярослав Романченко [ Пятница, 08 Февраль, 2013 23:37 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
Никто Вам не мешает подставить свои хеш-функции в стандартные контейнеры. Фактически, в этом случае, только хеш-функцию Вам и нужно будет написать, всё остальное сделает скрытый от глаз библиотечный код. |
Автор: | Info21 [ Пятница, 08 Февраль, 2013 23:55 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
Лучше последовать примеру И.Д. и научиться программировать по хорошей книжке. Окупится мультикратно. |
Автор: | Пётр Кушнир [ Суббота, 09 Февраль, 2013 00:11 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
Ну, в современном мире принято дорого платить за время кодера, и соответственно, кодеру выгоднее меньше делать движений за это время, а собственнику выгоднее это учитывать и повышать норму выработки, а кодеру в ответ на это приходится повышать уровень абстракции, но в итоге, всё это выливается в потогонную систему, которая никакого отношения не имеет к значимости объема исходного кода. Ну, написали там тридцать строк, а тут сто, всё равно написание строк не занимает столько мозговых ресурсов, параметр строки/время важен в основном заказчику. Ну, динамичный мир, быстрые бизнесы и прочее. Ведь подумайте, не важно, на самом деле, когда русские запустили бы человека в космос, в 1961-м или 2001-м, для истории это смешные сроки, это было важно сделать быстро только в условиях конкуренции внутри популяции Хомо. Так же не имеет значения, когда вы допишете модуль управления очередным генератором данных в БД из ввода пользователя, сегодня или завтра. Короче, я к тому, что внешние причины приводят нас к обсуждению каких-то внутренних симтомов. С этой точки зрения, критериев простоты чистого Компутер Сайнс так и не выработано, есть либо аргумент "Слышь, код быстрей пиши" либо "При наличии времени мы вполне очевидным образом берём готовую идею, переосмысляем и пишем заново под задачу". |
Автор: | Ярослав Романченко [ Суббота, 09 Февраль, 2013 00:25 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
Info21 писал(а): Лучше последовать примеру И.Д. и научиться программировать по хорошей книжке. Конечно можно, и нужно. Никто не отрицает.Окупится мультикратно. Только вот, отрицание параметрического задания класса сродни отрицанию третьего измерения Можно так и пыхтеть в двух измерениях, а можно признать существование третьего и получить дополнительную степень свободы. Ведь параметрический полиморфизм по-сути просто устраняет рутинные операции. Допустим, нам нужны три списка: список целых, список строк и список вещественных элементов. В традиционном подходе, описываем+кодируем три разных структуры, реализующих списки - TIntegerList, TStringList и TFloatList. А параметрический полиморфизм избавляет от этой рутины. Написали: TIntegerList = TList<Integer>, TStringList = TList<String> и TFloatList = TList<Float>. И... компилятор генерирует готовые классы со всем необходимым функционалом. И строгим статическим контролем типов! |
Автор: | Пётр Кушнир [ Суббота, 09 Февраль, 2013 00:30 ] |
Заголовок сообщения: | Re: Стандартная библиотека контейнеров и алгоритмов |
А возможна ли реализация подобного механизма на каком-то приближённом к идеалу уровне, но в виде компонента? Ведь можно допустить, что раз не включено в язык, пусть будет включено в компонент, как составляющая. |
Страница 1 из 3 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |