OberonCore
https://forum.oberoncore.ru/

Категорический императив Калашникова: KISYBI
https://forum.oberoncore.ru/viewtopic.php?f=57&t=2988
Страница 5 из 5

Автор:  Борис Рюмшин [ Пятница, 14 Февраль, 2014 10:37 ]
Заголовок сообщения:  Re: Категорический императив Калашникова: KISYBI

У меня, как у модератора, явное ощущение, что все поток сознания начатый с сообщения Madzi (viewtopic.php?p=85455#p85455) вообще тут не по теме.

Автор:  Jordan [ Пятница, 14 Февраль, 2014 15:32 ]
Заголовок сообщения:  Re: Категорический императив Калашникова: KISYBI

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

Почти весь форум об обероне, что ещё обсуждать? :wink:

Автор:  Иван Кузьмицкий [ Пятница, 14 Февраль, 2014 16:27 ]
Заголовок сообщения:  Re: Категорический императив Калашникова: KISYBI

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

Автор:  Jordan [ Пятница, 14 Февраль, 2014 16:48 ]
Заголовок сообщения:  Re: Категорический императив Калашникова: KISYBI

Можно конечно, обвинять автора в наркотической зависимости, под какими веществами он создавал С++. Но говорить, что автор не в теме, максимализм.

К*M*N вас не зацепило?

Тут имелось ввиду простая мысль. Что, данные наборы контейнеров используются часто. Хранение, чтение и запись информации. Прочитали, обработали, сохранили. Как минимум, в большинстве случаев STL предлагает оптимальные контейнеры для хранения и простой обработки.

Никто не мешает обрабатывать данные своими алгоритмами.

Экономия 90% как раз в написании этих контейнеров.

Автор:  Иван Кузьмицкий [ Суббота, 15 Февраль, 2014 02:48 ]
Заголовок сообщения:  Re: Категорический императив Калашникова: KISYBI

Jordan писал(а):
Экономия 90% как раз в написании этих контейнеров.
Это понятно. Я про другое - разве вы 90% своего рабочего времени занимаетесь написанием контейнеров? Сильно вряд ли. Если потребность новом в контейнере возникает редко, то относительно неважно, буст вы используете или что-то другое. Всё равно процент времени, ушедшего на контейнер, будет маленьким. А выигрыш и совсем неразличимым. Конечно, всё меняется, если вы только и делаете, что шаблонизируете алгоритмы - но тогда, может, проще что-то "в консерватории подправить"?

Автор:  Jordan [ Суббота, 15 Февраль, 2014 10:30 ]
Заголовок сообщения:  Re: Категорический императив Калашникова: KISYBI

Это был пример, против постулата KISYBI. Да никто не мешает копипастить, и если других способов нет, будет лучше чем извращаться с приведением типов.

Пример GLIb, библиотека контейнеров и алгоритмов на си. Свою функцию выполняет, но делает настолько всё небезопасно и костыльно. Так как в языке нету средств, для нормальной реализации. Особенно коробит, работа с массивами. Сама идея непрерывной памяти выброшена, есть массив указателей. На каждый указатель выделяется память. Отсюда и обход массива, ещё более не эффективен, постоянные кэш промахи.(обращение идёт через [i]->поле)

Всё эти void* обычно локализуют в функциональности конкретной реализации. На паскале, такая реализация будет не лучше.

У каждого программиста, есть свой файлик с реализациями, своих структур из которой он копирует реализацию. Но сам способ реализации STL интересен.

1. Встроить в язык шаблонизатор. Получается STL
2. Обойтись средствами языка. Повальный void*
3. Внешние тулзы для генерации обобщённого кода.
4. Копипаст.

Все эти способы работают, лучше хуже другой вопрос.

Иван Кузьмицкий писал(а):
проще что-то "в консерватории подправить"?


Не уловил, вы о чём?

Автор:  Jordan [ Суббота, 15 Февраль, 2014 10:34 ]
Заголовок сообщения:  Re: Категорический императив Калашникова: KISYBI

Все эти фичи в языке для человека, суть получение коечного результата.

Автор:  Иван Кузьмицкий [ Суббота, 15 Февраль, 2014 11:01 ]
Заголовок сообщения:  Re: Категорический императив Калашникова: KISYBI

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

Автор:  Jordan [ Суббота, 15 Февраль, 2014 11:02 ]
Заголовок сообщения:  Re: Категорический императив Калашникова: KISYBI

Сборщик мусора полезная и удобная фича. Создаёт некий постулат, забудьте об утечке памяти, я всё сделаю. Хотя при интенсивном выделении GC прийдётся проходить по всем объектам, что бы понять, что освобождать, что нет. Есть многопоточные GC с делением на поколения и ещё всякие уловки, для ускорения.

Если от этого отойти, ну копипастишь ты алгоритм, ну и скопипать освобождение ресурсов и освободи где надо. Элементарно же. Нет, получаем серьёзные удобства. Так же и с обобщённым программированием, получаем плюшки.

Автор:  Иван Кузьмицкий [ Суббота, 15 Февраль, 2014 11:06 ]
Заголовок сообщения:  Re: Категорический императив Калашникова: KISYBI

Сборка мусора более важная вещь, чем автокопипаст с помощью шаблонов. Потому что утечка памяти опасна, а копипаст алгоритма - нет.

Автор:  Jordan [ Суббота, 15 Февраль, 2014 11:07 ]
Заголовок сообщения:  Re: Категорический императив Калашникова: KISYBI

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


Подождите, но каждое наращивание языка, поддаётся правилам и описанию. Контроль есть.

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


Угу, бывает тоскливо когда смотрю исходники других проектов на С++. Но я не унываю.
Какие есть книги, которые можно почитать по архитектуре? Но более применимые в современном программировании. Не книги 70-80ых годов. Обычно как ни скачаешь, везде С++ в с паттернами, фабрики и т.д Слишком высокий уровень.

Автор:  Иван Кузьмицкий [ Суббота, 15 Февраль, 2014 11:09 ]
Заголовок сообщения:  Re: Категорический императив Калашникова: KISYBI

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


Подождите, но каждое наращивание языка, поддаётся правилам и описанию. Контроль есть.
На оберспейсе пилят сразу два компилятора оберона. Почему не сразу С++? Правила есть, контроль есть, возьми и запили что нужно. Но нет, что-то в консерватории не то :)

Автор:  Илья Ермаков [ Суббота, 15 Февраль, 2014 12:37 ]
Заголовок сообщения:  Re: Категорический императив Калашникова: KISYBI

Jordan писал(а):
Сборщик мусора полезная и удобная фича. Создаёт некий постулат, забудьте об утечке памяти, я всё сделаю.


Угу, вот именно со сборкой мусора начинаются интересные вещи.
В применениях, где объём памяти под динамические объекты начинает превышать 16Гб (по сообщениям "Одноклассников", допустим), она жрёт более 50% времени (если на Java).
Ведь те, кто делал ту же Java, должны были предполагать, что за ростом производительности (что сгладило расходы на сборку мусора) пойдёт рост ОЗУ до такого предела, когда затраты на любой алгоритм сборки будут расти нелинейно. Но нет - оставили в языке только динамические строки\массивы\объекты, которые добавляют безумное количество мусора.
И самое главное - что из-за таковых особенностей языка очень сложно (если возможно) написать какое-то библиотечное управление памятью, которое позволяет работать с выключенным сборщиком (на пулах повторно используемых объектов, допустим; или хранить деревья данных типа DOM в объектах с итерируемым доступом вместо прямого доступа) - всё равно любая локальная переменная породит мусор (ну да, потом изобрели безумно сложные HotSpot-ы, которые умеют догадываться, что можно разместить на стеке. А потом латают дырки в этих безумно сложных оптимизациях).

Автор:  Илья Ермаков [ Суббота, 15 Февраль, 2014 12:39 ]
Заголовок сообщения:  Re: Категорический императив Калашникова: KISYBI

Jordan писал(а):
Какие есть книги, которые можно почитать по архитектуре? Но более применимые в современном программировании. Не книги 70-80ых годов. Обычно как ни скачаешь, везде С++ в с паттернами, фабрики и т.д Слишком высокий уровень.


Рекомендую в обязательном порядке Эрика Эванса "Предметно-ориентированное проектирование. Структуризация сложных программных систем".

Автор:  PSV100 [ Пятница, 21 Февраль, 2014 19:01 ]
Заголовок сообщения:  Re: Категорический императив Калашникова: KISYBI

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

Мэйнстрим-прыжки к а-ля Haskell-абстракциям пока больше вредны, чем полезны. К примеру, запись какого-нибудь linq-выражения или выкрутаса в стиле:
" xs.iter().chain(ys.iter()).fold(0, (a, b) => a + b) "

может иметь непредполагаемые (программёром) эффекты, например, куча скрыто создаваемых временных коллекций объектов. Да и в самих исходных абстракциях далеко не всё гладко (особенно в Скале). Насчёт тех же коллекций, как основной фундамент, только вот сейчас потихоньку начинают, наконец-то, к ним подходить со здравым смыслом, как в Reducers Кложуры.

Илья Ермаков писал(а):
Угу, вот именно со сборкой мусора начинаются интересные вещи...

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

В общем, на сегодня отрасль в попытках простоты далека от мудрости, всего лишь чушь выше "хуже воровства".

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