Слушайте, CheshireCat, назовите своё имя, пожалуйста! Просто, доброй традицией данного славного форума стало подписываться своими настоящими именами и фамилиями. А по-кличке как-то даже и не приятно обращаться к собеседнику – не располагает...
CheshireCat писал(а):
у нас просто разное представление о том что таки необходимо в языке а без чего можно обойтись. разный опыт, и нельзя сказать чей опыт "лучше". главное что желание все урезать - совпадает)) и это хорошо)) а между тем, начиная с Оберона-1, в язык постоянно что-то добавляют)) Добавление это не зло если оно четко оправдано))
Не помню, но, по-моему, Чёрчил как-то сказал в парламенте что-то, навроде того, что «надо всячески опасаться полезных и взвешенных нововведений, особенно тех, которые подкреплены доводами здравого смысла»... :о)
Цитата:
Вам просто _кажется_ что КА - не оправдано. Что те добавления которые делались – более оправданы чем _одно_ добавление - КА, которое их большую часть заменит... ладно, поживем - увидим... или - не увидим))
Нет. Я категорически против введения КА В ЯЗЫК! Я – за введение в язык СРЕДСТВ, которые помогают строить новый язык на базе имеющегося для поддержки той или иной парадигмы или идеологии (вплоть до смены синтаксиса). Вполне естественным выводом будет заключение о том, что я склоняюсь в сторону Форта и Лиспа. Но, опять-таки, это – чисто эмпирические мозговые упражнения. В области оберонов – библиотеки и - только!
Цитата:
по двунаправленности, таблицам и указателям - конкретизирую.
я нигде не говорил про навороченные субд, лишь про таблицы.
(кстати двунаправленность в СУБД называют "реляционность")) ) А таблица конечно не выполняет очистку сама, она лишь _дает возможность_ это сделать. Например согласовать вызов предварительно реализованных процедур разрушения связи в компонентах на обоих ее концах. И нормально, чисто, в реальном времени, отработать факт завершения связи.
Указатель-же этого сделать не позволяет в принципе, потому что он однонаправлен и его "цель" не имеет никакой информации о "источнике", он просто не имеет нужной информации (хотя безусловно именно поэтому он занимает меньше памяти). Поэтому для поддержки целостности системы приходится привлекать сторонние ее компоненты которые знают то что требуется, знают _обоих_ или могут это вычислить. А это усложняет архитектуру всей системы. Именно поэтому я называю указатель полуэлементом. Он - несамодостаточная вещь, он зависит от наличия в системе чего-то еще. А зависимости усложняют модификацию.
Таблица – носитель реляционности в СУБД.
Без механизмов СУБД – она – НИЧТО.
Эти механизмы и есть ДОПОЛНИТЕЛЬНЫЕ средства НАД таблицами.
Эти механизмы (просто по своей природе) НЕ МОГУТ работать «в реальном времени» (но, так как само определение понятие «реального времени» сейчас порождает споры, то я оговариваюсь – смотря в КАКОМ РЕАЛЬНОМ ВРЕМЕНИ).
СУБД потому и является «реляционными», что таблицы (части таблиц) носят (отображают) понятия «отношения». Для полноценной реализации такого же рода отношений без наименования получающейся системы «реляционная БД», просто не будем выходить дальше ОЗУ в своих операциях над «хранилищами». Могу вас заверить, что получившаяся система будет ничуть не хуже.
«Указатель в системе» ни от чего не «зависит». Семантика его настолько низкоуровнева, да к тому же ещё и «нагружена с двух сторон» (понятие элементарной ячейки в массиве памяти + простейшее понятие идентификатора), что он ни чём не нуждается, а сам является строительным блоком для построения более сложных решений (систем).
Цитата:
Я согласен что иногда очистка источника связи не требуется, именно потому возникает искушение экономно обойтись указателем.
Но это как с goto. Проблемы остаются чисто потому что иногда их ведь не бывает и потому неохота их решать вообще)). с гото тоже проблем нет _иногда_. но _в общем случае_ указатель все-же не может полноценно заменить таблицу. И когда этот факт медленно доползет до мозга, как и то что указатели таки иногда полезны как низкоуровневое системное средство для работы с написанной на Си системой, разработчику остается только добавить сборщик мусора. Просто больше выхода у него нет. Поэтому все _универсальные_ процедурные системы с указателями - _требуют_ сборщика мусора.
Все эти рассуждения верны до тех пор, пока у вас в задаче не удаётся получить решения, где нет динамики в работе со структурами данных.
Простой пример: «обыкновенный» бортовой самописец. Нужна ли там СУБД? В принципе – есть соблазн «встроить». Но вот беда – НИ ОДНА ИЗ СУЩЕСТВУЮЩИХ СУБД не может обеспечить нормальную работоспособность при записи параметров полёта, при ЗАДАННЫХ ПАРАМЕТРАХ «реального времени». А те (нормальные, привычные, «простые», «безреляционные») алгоритмы, что разработаны – совершенно не нуждаются в динамическом выделении/освобождении памяти... Да там у меня и понятие «указатель» существует «опосредованно», через переменные статически объявленных массивов и записей...
Городить там «реляционность»... - зачем?
Да, на уровне проекта, модели, что-то такое я рисовал с кубиками и стрелочками между ними. Но, продвигаясь по решению задачи, я нашёл простой и адекватный способ выражения сущностей моей предметной области, отношений между ними и операций над(между) ними, помогающими успешно «втиснуть» проект в жёсткие временные и пространственные рамки к моей системе.
Использование «полного» отображения «реляционной» модели на какой-либо тулз аля СУБД – стало бы НЕ оптимальным решением, с огромным перерасходом вычислительных и «памятийных» ресурсов...
Понимаете, CheshireCat, программирование (до сих пор, как это не удивительно, представьте!) иногда требует подсчёта отдельных тактов и байтов. В том числе и для того, что бы вы смогли спокойно поспать по пути из Москвы во Владивосток на высоте 10 000 м или что бы всякая сволочь сто раз подумала, прежде чем заявлять права на что-то в России. :о)
Цитата:
ЗЫ... Да, если есть возможность, следует использовать статические данные. Никто и не спорит. Сам всегда так делаю в мелких утилитах. Но мы то говорим про общий случай когда система обязана быть модифицируемой, динамичной.
Удивительно то, что по размерам оте самые системы, в которых требуется подсчитывать такты и байты могут быть меньше в разы некоторых утилит «обычного» программиста. Но! Зачастую мозговой энергии и изобретательности, при их создании, затрачивается НА ПОРЯДКИ больше; и «внесено» в эти системы «мощности решений» не в пример больше.
Про «общий случай» можно и поговорить. Обеспечение «модифицируемости» и «динамичности» - рассматриваются на фазе принятия проектных решений, при учёте ограничений предметной области и средств реализации.
Если используется Оберон – одни подходы, если Си – другие.
Буд-то бы те, кто работает на Си не имею своих, сложившихся во время десятилетий работы, практик?!
Просто (как в моей области) ТРАДИЦИОННО в понятие «модифицируемости» и «динамичности» вкладывается свой смысл. Этот «смысл» может и не быть похожим 1-в-1 на обероновский, но, поверьте мне никто и нигде не стремится «осложнить себе жизнь» и делать «лишние движения».
Си не поддерживает модульности синтаксически, но есть приёмы и подходы, позволяющие разбить систему на относительно «ярковыраженные» обособленные части.
Пока, «на лету» код менять в бортовых системах не пытался. Но вот появился загрузчик ELF-модулей (exe или dll) в Контики – будем и его пользовать – посмотрим, что такого нового мы можем «выкатить», что бы не возить приборы и оборудование на аэродромы и на полигоны, или их «железо» – через пол-мира – к нам... :о)
Цитата:
Непонял почему это у меня гото самодостаточен? Ерунда какая.
Он же тоже однонаправлен и черезчур низкоуровнев, он _не может ничего выразить в одиночку сам по себе_ и потому не подходит на роль элемента языка. Вот дейкстровские - могут выразить сами кое-что. Самодостаточны. Видимо Вы играете словами, зачем-то подсовываете математическую и философскую самодостаточность вместо инженерной.
Я не играю словами.
Для «работы» goto ничего кроме метки (адреса, ссылки, «якоря») НЕ НУЖНО. НИКАКОЙ ДОПОЛНИТЕЛЬНОЙ СИНТАКСИЧЕСКОЙ ИЛИ СЕМАНТИЧЕСКОЙ «ОБВЕСКИ».
Для работы дейкстровских примитивов, вам нужно обеспечить выполнение «предусловий» и «инвариантов». Кроме того (в зависимости от ЯП), вам нужно обеспечить больше мест «правильности оформления» этих синтаксических конструкций. Собственно (что не очевидно для многих, даже после десятилетий программирования :о) ) и само разбиение на несколько похожих, но «разных» итеративных конструкций как раз и служит для более чёткого, «явного» закрепления разности смыслов участков вашего кода разной семантики.
Goto более «прост», более «общ», более «опасен». Но это (как и в случае с командами risc-машин, по сравнению с cisc-машинами) позволяет КОМБИНИРОВАТЬ из них более подходящие для данной задачи (оптимальные) последовательности операций. Большая свобода выбора. Меньшая «смысловая нагрузка» - большая «допустимая комбинаторность». Но здесь же – и опасность «более высокой семантической» перенагрузки (как в путанице иных производительных, но совершенно запутанных ФОРТРАН-программ) :о)
В конце концов, именно на комбинации goto строятся дейкстровские примитивы... :о) Для выражения более «высокоуровневой», но ограниченной семантики.
Кстати, мне не понятно противопоставление математики и философии инженерии!
Программист без математики – просто кодер, даже – не инженер!
Программист, который не интересуется, хотя бы изредка, философскими вопросами, – не просто кодер, а – просто непонятно что... «кодеротёс», что ли? :о)
Ведь надо ж относиться к своему труду не просто как к «тасканию камней», надо ж, хоть и иногда, и «Храм строить»... :о)