OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 14:37

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 76 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Понедельник, 17 Сентябрь, 2007 20:17 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
CheshireCat писал(а):
((ужас чего наворочали. и снова грамматики как в зонноне...

Совершенно не наблюдаю этого "кАка"...
И, собсна, а чего так фдрук очередная попытка поспособствовать прогрессу в отрасли с "ужасом" ассоциируется? Вода холодная? Мир привычный покусился кто-то поломать?
CheshireCat писал(а):
подумаю лучше на тему конечных автоматов и ммх...

Да, пожалуй, это будет для всех лучше... :о)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Вторник, 18 Сентябрь, 2007 12:21 

Зарегистрирован: Вторник, 04 Июль, 2006 13:04
Сообщения: 88
Откуда: Novosibirsk
не подскакивайте, у меня было просто брюзжание вслух))
я ни в коей мере не навязываюсь и никаким авторитетом тут не обладаю))
просто заметил что система (как и зоннон) пытается своим особым способом
структурировать уж очень большую и не вполне изученную область.
Архитектура это сложная штука, подобно искусственному интеллекту.
Мне просто на уровне интуиции не нравится их подход.
Не нравятся обмены и протоколы как элемент описания архитектуры.
Потому что логика работы системы становится неявной и труднее
предсказуемой по описанию. Обмены это подобно указателям,
слишком низкоуровневая, "однонаправленная" ("неполная", "нецельная",
"незамкнутая" - не знаю адекватного термина)) ) абстракция.
Система из таких полу-элементов часто имеет артефакты. Может тот кто
знает синергетику, и обьяснил бы в чем дело)) У меня всего-лишь сработал
нюх на софт)) 9 лет администрирования разных программ выработали...
Композита - слишком необычная и экспериментальная штука.
К то как а я буду ждать пока другие шишек набьют с ней как с указателями))

так что наверное лучшеб КА в язык встроили, Глушков поди не зря на них
налегал... и еще полезно наверно сейчас в языке иметь прямую поддержку
автоматически распараллеливаемых ммх-подобных операций
с маленькими массивчиками из нескольких элементов, pack.
фиксированной длины... заменить byte например на bytepack...

оффтоп...
...так никому тут подпиленная mocka не пригодится? 400 кило архив тгз с
компилятором, 700 с исходниками, все линковано статически с уцЛибс,
генерирует статические бинарники от 20 кб (можно и 3.5 кб хелло ворд
сделать если надо). бутстраппится из ассемблерных исходников под
Слакварью и НетБСД за 3 секунды и требует для работы только шелл
и бинутилсы (гсс уже не нужен для линковки).
я там для себя внес модификацию - теперь компилятор понимает ключевые
слова и базовые типы в низком регистре. получается очень похоже на
Паскаль)) Пришлось лазить по исходникам и переименовывать кучу
переменных с именами наподобие from to by mod ))...
Имена русские увы не берет но сообщения вполне нормально русские
в кои8 пишет в консоль. Может пригодиться например учителям
для лаб или олимпиад как запасной вариант)).
оцениваю компилятор на 4 балла. писан местами по студенчески и кое-где
залатан но вроде живой.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Вторник, 18 Сентябрь, 2007 21:19 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
CheshireCat писал(а):
не подскакивайте, у меня было просто брюзжание вслух))

Я, как раз, – и не подсКАКивал...
На счёт икания очень хорошо доктор Борменталь говорил...
CheshireCat писал(а):
я ни в коей мере не навязываюсь и никаким авторитетом тут не обладаю))

Авторитет – вещь капризная, приходящая и призрачная... Вот уж на что я лично смотрю после всего остального... :о) Как по мне, если уж на то пошлО – так главнее, что бы ногти не обгрызаны были и под ними черноты не наблюдалось!... :о)))
CheshireCat писал(а):
просто заметил что система (как и зоннон) пытается своим особым способом структурировать уж очень большую и не вполне изученную область.
Архитектура это сложная штука, подобно искусственному интеллекту.
Мне просто на уровне интуиции не нравится их подход.
Не нравятся обмены и протоколы как элемент описания архитектуры.
Потому что логика работы системы становится неявной и труднее
предсказуемой по описанию.

«Этапачемужето?» (с) Матроскин

Здесь я с вами никак согласиться не могу!
Наоборот!
Здесь открывается ещё одно измерение в описании интерфейсов! Может я до сих пор неправильно делал, что не повторял, того, что уже когда-то сказал – ведь не все могли это читать – просто в силу срока рождения или приобщения к Сети. :о) А тяжкий труд различного рода «популяризаторов», в не малой степени, заключается именно в готовности повторить!
Так вот: вводя формализацию (в удобоваримом представлении, заметьте!) обмена, Зоннон и Композита позволяют раскрыть «семантическую ожидаемость» интерфейсов. Теперь оные интерфейсы – не просто описания кучи функций (методов) и массой «сопроводиловки»-текстовых док (описанное в которых может поддерживаться, а может н нет!). Теперь у вас есть СПОСОБ ОПИСАНИЯ И ВЕРИФИКАЦИИ З_А_Я_В_Л_Е_Н_Н_О_Й ЛОГИКИ (и – последовательности) взаимодействия между компонентами! Из описания интерфейсов в традиционном варианте вы никак этого ни получить, ни проверить, ни получить поддержки НЕ МОГЛИ! Средств, правил и инструментов для этого у вас не было! Более того и для появления самого такого инструментария никаких возможностей не существовало! - только через поддержку определённого «соглашения» в среде. К языкам программирования и описаниям проектных решений это ни в малейшей степени не относилось. Потому, что это можно было поддерживать и соглашаться, а, можно и - нет.

CheshireCat писал(а):
Обмены это подобно указателям,
слишком низкоуровневая, "однонаправленная" ("неполная", "нецельная",
"незамкнутая" - не знаю адекватного термина)) ) абстракция.

Здрасьте! Как раз я бы мог согласиться, если бы имели в виду не Зоннон и Композиту, а – обмены в QNX и MINIX! Там – да – абстракции ограничены низкоуровневым машинным представлением информации. Но в Хонноне и Композите – уж извините – описания уровня абстракций (и реальное наполнение их) ограничены только вашей фантазией, наложенной на предметку!!! (А вы доки-то читали, ваще-то?)

CheshireCat писал(а):
Система из таких полу-элементов часто имеет артефакты.

Каких ПОЛУ-ЭЛЕМЕНТОВ?

CheshireCat писал(а):
так что наверное лучшеб КА в язык встроили,

А вот здесь, как раз, в полной мере «приложимо» ваше возмущение на счёт «низкоуровневости»!!!
Вы когда-нибудь пытались «расшифровать» описание какого-нибудь протокола на реализации с помощью «чисто автоматного подхода» (продираясь через лес веток switch-case) и, например, в подходе Активного Оберона или PROTOTHREADS? :о)))

CheshireCat писал(а):
Глушков поди не зря на них налегал... и еще полезно наверно сейчас в языке иметь прямую поддержку автоматически распараллеливаемых ммх-подобных операций
с маленькими массивчиками из нескольких элементов, pack. фиксированной длины... заменить byte например на bytepack...

1.Я заканчивал кафедру, где чуть ли не 80% личного состава считали себя, тем или иным «макаром», принадлежащими к «школе Глушкова». Для меня само упоминание фамилии Глушкова хоть в малой степени в положительном ключе – уже является сигналом «напрячься на счёт» говорящего... Жизненный опыт, уж извините!... С одной стороны, подкреплённый отзывами новосибирцев (и – не только, а и тех, кто успел с Лебедевым поработать), с другой – последующее непосредственное общение (уже – по другую сторону Урала :о) ), с теми, кто считает себя «верным продолжателем дела»...
2.Глушков решал ограниченный круг задач, актуальных по его тематике в то время. Не он бы – так кто-то другой пришёл к примерно похожим подходам и решениям! Сама структура и способы обуславливались проблемой. И решались довольно «низкоуровневые» задачи. Меня умиляет желание расширить уровень применимости абстракций! Математика-то с человеческим мышлением – вещи гибкие – но лучше (для всех!) что бы набор абстракции соответствовал уровню задач! Или обладал свойством (или средством) «немозголомного» расширения и «поднятия» уровня. Желательно - максимально обобщенным средством!
Вы хотите реальной иллюстрации применения теории КА на деле (к чему это может привести?) – попытайтесь найти в Сети распечатки реализации протоколов с помощью КА! :о))) А потом – найдите через гугл всё, что относится, к применению protothreads в, например, реализации стека TCP/IP... :о)
Кроме того, в вашем последнем предложении сквозит (аж – с ног сдувает! :о) ) желание получить поддержку в максимально обобщённом средстве (язык программирования), довольно узкой и частной задачи... И – на что это опять похоже? «За что боролись?»


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Среда, 19 Сентябрь, 2007 04:59 

Зарегистрирован: Вторник, 04 Июль, 2006 13:04
Сообщения: 88
Откуда: Novosibirsk
ну насчет черноты... :oops: я таки четко вижу себя мусорным котом ведь,
хоть жена и злится когда я так говорю)) потому что все время роюсь
в программном мусоре в поисках вкусно пахнущих кусочков)) за
картинкой меня, Чешира - отсылаю всех в игру с отпадным оформлением -
Америкэн МакГи Алиса))

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

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

...про разные применения КА - switch-технологию, protothreads,
я конечно слышал... просто не раз _озвучивалось_ что КА как
раз _требует_ автоматизированной поддержки, тулзами а лучше
самим языком программирования... и уж само собой копаться
в потрохах switch-ей _ни в коем случае не надо_, как и
дизассемблировать обычные программы вместо чтения
высокоуровневых if-while))

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

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

ЗЫ. я собственно подумываю над тем, можно ли расширить описание
инициализатора модуля до полноценного конечного автомата с
более чем двумя состояниями. с целью превратить каждый модуль
в табличный автомат. И соответственно модифицировать логику
Oberon.Loop введя больше полезных операций алгебры конечных
автоматов чем две имеющиеся. например, нечто типа вычитания для
автоматического получения частных оптимизированных программ...
И к каким осложнениям это приведет.
А то еще будет как с композитой - при борьбе со сложностью и ее
артефактами введены новая сложность и думаю скоро будут
новые артефакты))
Первое осложнение которое приходит в голову - может потребоваться модифицировать механизм вызова команд модуля (экспортируемых
процедур без параметров), сделав его отложенным и выполняющимся
через Oberon.Loop... в-общем тут еще мне ничего не ясно еще много
думать... но сделать из модулей Оберона-1 конечные автоматы охота.
мне кажется они могут просто перекрыть функциональность
и параллельного ActiveOberon и Composit-ы. может я и не прав...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Среда, 19 Сентябрь, 2007 21:35 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
>>>насчет интерфейсов. обмен это с точки зрения _пользователя_
всегда низкоуровневая деталь.

Это если такой «обмен» удалось сделать «атомарным» и не имеющим «памяти» по вызванным другим элементам интерфейса!
Но – так бывает очень редко! Конечно, талант разработчика как раз и состоит в том, что бы в интерфейсе на старт каждого действия была отдельная «кнопка». Но, в большинстве случаев, пользователю ПРИХОДИТСЯ учитывать модальность. А тут, уж пардоньте, часто выходит, как в истории про один прибор в конце 1960-х, который у потребителей горел при первом же включении! Причём, прибор этот прошёл самые жёсткие испытания и проверки (по-настоящему! с военприёмкой! «без фуфла»!). А дело оказалось в том, что первое же предложение, про включение одного из режимов этого прибора, было разбито так:
на нечётной странице, внизу, на одной стороне листа, было написано:
«Нажмите кнопку А, ...»
переворачиваем страницу, и на другой стороне листа вверху читаем:
«... предварительно нажав кнопку Б.»
... И техники и младший инженерный состав, дружными рядами, сожгли тысячи приборов в первые же две недели начала эксплуатации! Просто «идя прямо по написанному»! Соблюдая интерфейсы! :о)

Являлось ли обеспечение выполнения требования о предварительном нажатии Б перед А «более низкоуровневой деталью»? Нет! Кнопка Б и всё, что с нею связано – находились на одном уровне иерархии понятий и абстракций для пользователя. Здесь вопрос – были ли правы конструкторы, внося «зависимости» от «последовательности вызова элементов интерфейса»?
Конечно, в идеале, было бы лучше иметь «отдельную» кнопку на каждое желание пользователя! Но, такого часто не удаётся получить. (О причинах – отдельный подробный и долгий разговор, но, вкратце это «играют» ограничения реализации, а не предметки.)
И вот, как раз для таких случаев, и подходит описание правильности последовательности субъекта (клиента), пытающегося получить некую функциональность (или – её часть) от «сервера»... Такое описание и не даст «нажать А без нажатой Б»!

>>>описание интерфейса для меня подобно силуэту предмета, контурному рисунку. имхо схема внутренней логики предмета более абстрактна и информативна для инженера чем рисунок его внешнего вида)) хотя конечно форма разьемов на панели достаточна бывает, и хорошо когда так.
«Абстрактность» и «информативность» – это красное и тёплое! Союз «и» туда не влазит!
Не может быть «схема внутренней логики предмета» БОЛЕЕ АБСТРАКТНОЙ, чем рисунок внешнего вида предмета!!! Вы уже начали дробить предмет и вычленять элементы и связи, которые привели к тому, что вы воспринимаете что-то, как именно «такой предмет».

>>>но не в данном случае, когда требуется мичуринство компонент и нужно их содержимое контролируемо перемешивать.
Так ведь никто и не собирался «перемешивать»!
Как раз и добиваемся БОЛЕЕ ЧЁТКОГО И ПОЛНОГО (по-возможности – более всестороннего и подробного) описания ГРАНИЦ компонент!
Это в ТММ интерфейсы обуславливаются самими физическими свойствами и «работой» физических и химических законов между «сочленяемыми» деталями. А в мире программирования таких ограничений нет. Но мы их ищем! Нам НЕОБХОДИМО находить такое «сочетание камешков», что бы вода ИМЕННО ТАК по руслу, сложенному нами из этих «камешков» потекла и начала «вращать колёсики нашей мельницы»! :о)
А без описания правил взаимодействия у вас только метафизика (да и то – иногда!) получается! Всё – только на везении, а не на законах!

>>>нам ведь нужна не стыковка компонент как таковая! а получение агрегатов с заранее заданными свойствами, в том числе _выбор_ требуемых компонент и _выбор_ схем их взаимодействия.
Правильно, но схемы эти – НЕ СТАТИЧНЫ! А чем вы правила динамики собираетесь описывать? Декларативность – хорошо! Но чем она реализуется, поддерживается и отслеживается?

>>>автоматизация проверки стыкуемости компонент вещь конечно полезная но это даже не половина дороги.
На самом деле, мы (отрасль вцелом) ещё даже со ступенек дома не сошли, а не то, что к калитке на улицу не подходим! :о)

>>>хотя конечно обероновцев я понимаю. их подталкивает к такому видению современная многопроцессорность и кластеризация. набор кусков мусора, перебрасывающихся всяким другим мусором - постоянно у меня перед глазами)) шютка
Так ведь и оберон-мир к тому и стремиться, что бы такое «копошение в мусоре» было как можно меньшим! Вы ж отследите всё развитие оберон-систем! И посмотрите – там и правда «мусора» меньше на единицу обеспечиваемой аналогичной функциональности.

>>>грамматики для меня это слишком децентрализованное описание, неиерархическое, нецельное, неструктурное - относительно описываемого предмета конечно.
Вы – не читали доку! Грамматики как раз и создавались для иерархического, цельного и именно структурного описания сущностей при взаимодействиях. Конечно, то, что может (неподготовленному читателю) показаться скопищем никак не связанной зауми, для человека подписавшего некоторую бумагу и о неразглашении и знакомому с некоторыми планами, относительно применения предлагаемых механизмов, видится единственно верным, полным и удобным решением.
Вкратце: описания взаимодействия компонентов (по Зоннону или Композите), в конечном итоге должны привести к абсолютно гибкой архитектуре взаимодействия между компонентами на основе средства с полным самоописанием, с минимальным базисом для «учреждения договорённости о форматах и способах взаимодействия».
Это то, что сейчас заказывается на проработку грандами отрасли телекоммуникаций и то, чем планируется заменить мобильники, телевидение и интернет.

Намёк на ПОРЯДОК цены вопроса улавливаете?... :о)

>>>взаимодействие то конечно нормально описано а вот сам предмет с которым нам работать - получается только косвенно. В стиле ООП.
Пардон, а вы можете предложить что-то иное, отличное от представлений «часть-целое», «пользователь-поставщик», «принадлежность-к-множеству»?

>>>полу-элементом для меня является компонент который не самодостаточен и требует строгих правил комбинирования с другими полуэлементами чтоб получить что-то самодостаточное и надежное.
Само понятие «компонент» предусматривает СПОСОБ ВЗАИМОДЕЙСТВИЯ с чем-то другим! Хотя бы - со средой, для функционирования в которой компонент изготовлялся...
И тут вы опять неминуемо придёте - .... к правилам взаимодействия! Причём – обязательно! - к необходимости описания динамики, а не просто перечисления набора функций в привычных «интерфейсах»...
Вернулись к тому, с чего начали!... :о)

>>>пример. указатели - полуэлементы. а реляционная таблица с записью вида (источник,приемник) - полный элемент. goto - полуэлемент. while, if - элементы... и так далее... думаю все поняли что я имею ввиду и могут расклассифицировать по аналогии все прочие программистские термины.
Не понял.
Указатель – всего лишь удачный (и самодостаточны, в определённом смысле и на определённом уровне) способ представления «метки (имени,дескриптора) объекта».
Обоснуйте полноту вашей таблицы вида (источник, приёмник) для случая сурогатных ключей и потери основной таблицы в вашей БД... :о)
goto – как раз – ПОЛНЫЙ элемент, а вот while, for – в полном согласии с вашей интуитивной классификацией - «полуэлементы»! У goto «мощность применения» выше, а вот структурные примитивы, как раз и были введены по причине требования наложения ограничений... :о)

>>>...про разные применения КА - switch-технологию, protothreads, я конечно слышал... просто не раз _озвучивалось_ что КА как раз _требует_ автоматизированной поддержки, тулзами а лучше самим языком программирования...
А вот подходы Активного Оберона и protothreads – НЕТ, НЕ ТРЕБУЮТ!
Они - «самоописываемы» и наглядны! :о)
И алгоритмы, записанные с помощью и в духе этих подходов, более интуитивно понятны и обозримы!

>>>...а ведь были таки у Глушкова новаторские и при том очень полезные разработки типа МИР)) хотя конечно вам виднее...
Нам виднее!... :о)

>>>по абстракциям. уровень абстракции это понятие связанное не с самой абстракцией, не ее свойство. это свойство _текущего положения_ абстракции среди набора тех с которыми мы оперируем. свойство _системы_ абстракций. место кубика в пирамиде может меняться.
Абстракция для того и вводится, что бы «описывать место»! Абстракция – есть само «место с описанием»!
То, что вы описали очень смахивает на описание взаимодействия и системы конкретных носителей абстракций (экземпляров классов)... :о)

>>>пример - списки в лиспе это ведь тоже лишь простая абстракция. еще продолжать примеры чтоб у Вас совсем разрушилось неверное представление о принципиальной низкоуровневости и малой применимости КА))?
Список в Лисп – абстракция понятия упорядоченного набора элементов.
Как это сокровенное знание поможет вам разрушить у меня «неверное представление о принципиальной низкоуровневости» КА – не знаю! :о)
Кстати, не пытались на Лиспе описывать структуру переходов КА? :о)

>>>ЗЫ. я собственно подумываю над тем, можно ли расширить описание инициализатора модуля до полноценного конечного автомата с более чем двумя состояниями. с целью превратить каждый модуль в табличный автомат.
Для какой задачи? У меня великое подозрение, что это опять из той же оперы, что и про введение поддержки ММХ... :о)

>>>А то еще будет как с композитой - при борьбе со сложностью и ее артефактами введены новая сложность и думаю скоро будут новые артефакты))
Я лично сложности не вижу!
Ещё одно измерение – вижу! Но оно - «ортогонально» к уже имющимся «пространствам описаний», а, потому – не имеет на них «проекций усложнения»...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Среда, 19 Сентябрь, 2007 22:49 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Владимир Лось писал(а):
Вкратце: описания взаимодействия компонентов (по Зоннону или Композите), в конечном итоге должны привести к абсолютно гибкой архитектуре взаимодействия между компонентами на основе средства с полным самоописанием, с минимальным базисом для «учреждения договорённости о форматах и способах взаимодействия».
А эти протоколы Зоннона/Композиты можно менять во время работы программы? Или только путём перекомпиляции?
Если только перекомпиляцией то какая ж тут гибкость-то?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Четверг, 20 Сентябрь, 2007 08:22 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Geniepro писал(а):
А эти протоколы Зоннона/Композиты можно менять во время работы программы? Или только путём перекомпиляции? Если только перекомпиляцией то какая ж тут гибкость-то?

Описание протокола взаимодействия – часть описания интерфейса.
Постулированные и опубликованные интерфейсы – меняются?

Конечно, с другой стороны, я могу написать компонент, действующий на принципах того же КА, и работающий «проверяльщиком» входной информации от клиентов сервера, куда этот компонент будет встраиваться (своеобразный «синтаксический(лексический) анализатор»). И, при определённых усилиях и организации кода, я могу просто на лету менять его автомат переходов (описание синтаксиса)... Но сам СПОСОБ ВЗАИМОДЕЙСТВИЯ с самим этим компонентом, всё равно, остаётся неизменным – он часть интерфейса этого компонента.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Четверг, 20 Сентябрь, 2007 10:26 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Владимир Лось писал(а):
«Абстрактность» и «информативность» – это красное и тёплое! Союз «и» туда не влазит!
Не может быть «схема внутренней логики предмета» БОЛЕЕ АБСТРАКТНОЙ, чем рисунок внешнего вида предмета!!! Вы уже начали дробить предмет и вычленять элементы и связи, которые привели к тому, что вы воспринимаете что-то, как именно «такой предмет».
А может, «Абстрактность» и «информативность» – это холодное и тёплое? Ведь, при увеличении информативности - больше конкретики => меньше абстрагирования. Значит соединительный союз тут точно не к месту.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Четверг, 20 Сентябрь, 2007 11:16 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Владимир Лось писал(а):
... «Абстрактность» и «информативность» – это красное и тёплое! Союз «и» туда не влазит!


Это плюс не влазит. А союз и влазит.

И сама фраза у CheshireCat'а насчет "более абстрактный и информативный" изячна.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Четверг, 20 Сентябрь, 2007 19:17 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Владимир Лось писал(а):
Geniepro писал(а):
А эти протоколы Зоннона/Композиты можно менять во время работы программы? Или только путём перекомпиляции? Если только перекомпиляцией то какая ж тут гибкость-то?

Описание протокола взаимодействия – часть описания интерфейса.
Постулированные и опубликованные интерфейсы – меняются?
Да постоянно! ;о)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Пятница, 21 Сентябрь, 2007 04:41 

Зарегистрирован: Вторник, 04 Июль, 2006 13:04
Сообщения: 88
Откуда: Novosibirsk
Чето я все больше теряю тему разговора))
такое ощущение что мы с Владимиром говорим на разных языках))
Так все-таки что он пытается и кому доказать такого что противоречит
моим словам, кто-нибудь обьяснит?)) Или он таки подтверждает мои слова?))

Еще раз повторю что у нас просто разные требования.
Я -пользователь. Он - программист. А программисты часто не вполне
понимают чего на самом деле надо пользователям)) Особенно -
государственные)) Впаривание больших проектов это не моя область))
Мне бы то что надо конкретно мне))

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

....по МИР.
мой отец на нем считал. по сравнению с тем что в то время было МИР был супер.
я ему верю.

...при чем тут структура КА на Лиспе? :evil: спор ради спора - не для меня.
КА и Оберон мне были бы полезны для конкретной задачи. Веб-сервисы.
ЛЕГКО МОДИФИЦИРУЕМЫЕ, расширяемые и УРЕЗАЕМЫЕ медицинские
информационные системы. Прежде всего - ПОНЯТНЫЕ ВСЕМУ ПЕРСОНАЛУ
системы. Вместо теперешнего зоопарка порожденного халявой для
программистов (кучи денег как в госзаказах, отсутствие обратной
связи и ответственности после сдачи).
Мои интересы вполне конкретны.
И ММХ работа со строками была бы очень вебу полезна.
И избегание уникода тоже. По-моему я вполне конкретно
формулирую чего мне бы хотелось))


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Пятница, 21 Сентябрь, 2007 12:35 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
info21 писал(а):
Владимир Лось писал(а):
... «Абстрактность» и «информативность» – это красное и тёплое! Союз «и» туда не влазит!

Это плюс не влазит. А союз и влазит.
И сама фраза у CheshireCat'а насчет "более абстрактный и информативный" изячна.

Там где есть место оговоркам – не до изячества!
Абстрактность может быть «более информативной», если для всех собеседников, выводящих новую абстрактность понятен базис «конкретики», на которой эта «абстрактность» построена.
Мы не вопросами Веры занимаемся, что бы просто постулировать «вводимые с потолка абстрактности». Даже имея просто «абрис» прибора («картинки разъёмов и штекеров»), ЧеширскийКот обязан был быть мотивирован некоей задачей, для решения которой его выбор пал именно на ЭТОТ прибор. И критерии выбора ЧеширскогоКота наверняка не на цвете корпуса прибора основывались...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Пятница, 21 Сентябрь, 2007 12:36 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
CheshireCat писал(а):
Чето я все больше теряю тему разговора))
такое ощущение что мы с Владимиром говорим на разных языках))
Так все-таки что он пытается и кому доказать такого что противоречит
моим словам, кто-нибудь обьяснит?)) Или он таки подтверждает мои слова?))

Дело в том, что вами сейчас движет желание иметь в, используемом вами, средстве реализации неких частных свойств для наиболее быстрого решения вставших здесь и сейчас перед вами частных задач. Я же пытаюсь рассуждать с точки зрения опыта, обобщения, построения СИСТЕМ; пытаюсь втолковать, что даже если вы получите, то, что вам «вкрай необхидно прямо зараз!», то, всё равно, ваше «щасте будит мималйотным». Потому, что следующий набор задач возбудит в вас совершенно аналогичные желания добавить в язык «ещё чё-нить самое палезное» («Мне бы то что надо конкретно мне))», «КА и Оберон мне были бы полезны для конкретной задачи», «Мои интересы вполне конкретны.»). И так – до бесконечности («И ММХ работа со строками была бы очень вебу полезна.», «И избегание уникода тоже»(???!!!-моё)). И – не зарекайтесь, что ваш случай - «особенный»! :о) Наркоманы и алкоголики – ВСЕ АБСОЛЮТНО УВЕРЕНЫ НА СЧЁТ СОБСТВЕННОЙ СПОСОБНОСТИ «вовремя остановиться»... :о) (Вот на счёт курильщиков – допускаю! :о) Сам курил больше десяти лет, «дошёл» до двух пачек «Ватры» в день, 3 мая 1997 года бросил и вот уже 10 лет, как не выкурил ни одной сигареты! :о) )
CheshireCat писал(а):
Еще раз повторю что у нас просто разные требования.
Я -пользователь. Он - программист. А программисты часто не вполне
понимают чего на самом деле надо пользователям))

А вы что думали, что программирование – это «написание кода, исполняющегося компьютером»? Нет. Программирование – это, прежде всего, описание задачи и способов её решения. В ходе построения этих описаний производится масса (мыслительной) работы, в том числе. и по оценке получаемых решений. Вот я и оценивал ваши рассуждения о «полукомпонентах» с точки зрения моего опыта.
CheshireCat писал(а):
Особенно - государственные)) Впаривание больших проектов это не моя область))

Если это намёк, то – не по адресу!
CheshireCat писал(а):
по указателям.
таблица отличается тем что позволяет реализовать поддержку целостности структур данных. она двунаправленна....

Таблица НЕ ПОЗВОЛЯЕТ «реализовать поддержку целостности структур данных».
Ни в одной из СУБД не встречал в описании их свойств понятия «двунаправленность», присущего создаваемым в этих СУБД таблицам... :о)
CheshireCat писал(а):
...а указатель - нет.
и для того чтоб все не поломалось он требует наличия сборщика мусора
который реализует по сути функцию поиска этих обратных связей и
выполнение нужных чисток.

Если я примерно «усёк» понятие «двунаправленности», то не допускаете ли вы мысли, что могут существовать задачи (отличные от тех, с которыми приходилось сталкиваться до сих пор вам в вашей практике), для которых может просто не существовать потребности наличия «обратных связей»?
А, если у меня в системе управления РВ всё так критично по временным рамкам, что я просто не пользуюсь подпрограммами выделения/возвращения памяти, а всё делаю статически определяемыми переменными? И у меня просто не будет «висячих» указателей? Здесь скорее на вероятность появления ошибок не природа указателей будет влиять, а – отслеживание правильности перемещения по составным структурам данных (проверки индексов)...
CheshireCat писал(а):
По-моему я вполне четко сформулировал критерий по которому элемент полон. Это - самодостаточность.
А про гото я вообще ниче у Владимира не понял.

Ну так по введённому, вами же, критерию, goto - «более самодостаточен» в базисе понятий представления вычислительного процесса (программы, алгоритма, последовательности действий), чем дейкстровские структуры управления! :о)
CheshireCat писал(а):
А кто-нибудь понял?))
он называет черное белым по-моему...

Ну, и на что вы надеетесь, обращаясь к третьим лицам? :о)
А вдруг третьи лица вас в библиотеку пошлют? В лучшем случае?... :о)
CheshireCat писал(а):
....по МИР.
мой отец на нем считал. по сравнению с тем что в то время было МИР был супер.
я ему верю.

И я вашему папе верю! Но, - зная историю вопроса, - причём здесь непосредственно Глушков? Наш директор тоже под всеми нашими документами о приёмке/сдаче бортового оборудования свою подпись ставит, но это ДАЛЕКО не значит, что он схемы разводит и проги пишет и на полигонах мёрзнет...
CheshireCat писал(а):
...при чем тут структура КА на Лиспе?

При том, что, не смотря на все язвительные замечания на счёт наличия множества скобок в Лиспе, я помню, как меня, в своё время, поразила наглядность описания и реализации таблицы переходов КА, когда я её первый раз увидел в Лисп-программе...
CheshireCat писал(а):
спор ради спора - не для меня.

без комментариев... :о)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Понедельник, 24 Сентябрь, 2007 08:43 

Зарегистрирован: Вторник, 04 Июль, 2006 13:04
Сообщения: 88
Откуда: Novosibirsk
у нас просто разное представление о том что таки необходимо в языке а
без чего можно обойтись. разный опыт, и нельзя сказать чей опыт "лучше".
главное что желание все урезать - совпадает)) и это хорошо))
а между тем, начиная с Оберона-1, в язык постоянно что-то добавляют))
Добавление это не зло если оно четко оправдано)) Вам просто _кажется_
что КА - не оправдано. Что те добавления которые делались - более
оправданы чем _одно_ добавление - КА, которое их большую часть заменит...
ладно, поживем - увидим... или - не увидим))

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

Теперь менее очевидное.
Я согласен что иногда очистка источника связи не требуется,
именно потому возникает искушение экономно обойтись указателем.
Но это как с goto. Проблемы остаются чисто потому что иногда их ведь
не бывает и потому неохота их решать вообще)).
с гото тоже проблем нет _иногда_.
но _в общем случае_ указатель все-же не может полноценно заменить
таблицу. И когда этот факт медленно доползет до мозга, как и то
что указатели таки иногда полезны как низкоуровневое системное
средство для работы с написанной на Си системой,
разработчику остается только добавить сборщик мусора.
Просто больше выхода у него нет. Поэтому все _универсальные_
процедурные системы с указателями - _требуют_ сборщика мусора.
А ведь могут иметь вместо указателей таблицы и не иметь
выделенного сборщика мусора.
Кстати большую полезность таблиц показывают все современные
скриптовые языки. В них указатели непопулярны. И про то что есть
какой-то сборщик мусора, вспоминают редко. И их реализация вообще
может не иметь выделенного сборщика (мне так кажется... конкретные
примеры привести не могу но могу попробовать поискать).
Эти языки просто широко пользуются тем что _могут себе позволить
не быть низкоуровневыми_, могут не иметь указателей.
Получается что с таблицами ситуация та-же что и с Сетунью
и с Обероном. Небольшое усложнение на низком уровне резко
упрощает верхние уровни.
По-моему подробнее разжевать мне уже не по силам))

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

Непонял почему это у меня гото самодостаточен? Ерунда какая.
Он же тоже однонаправлен и черезчур низкоуровнев, он _не может
ничего выразить в одиночку сам по себе_ и потому не подходит
на роль элемента языка. Вот дейкстровские - могут выразить сами
кое-что. Самодостаточны. Видимо Вы играете словами, зачем-то подсовываете
математическую и философскую самодостаточность вместо инженерной.
Мы говорим про инженерную поскольку говорим про реальную архитектуру
реальной системы. Хорошо. конкретизирую.
Для меня самодостаточность требует непустой семантики.
Самодостаточность единицы а не самодостаточность пустоты.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Понедельник, 24 Сентябрь, 2007 12:54 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Мне понравилась мысль про таблицы. А Вы не привели бы красивый и наглядный пример - может, в каких-то языках такой метод активно применяется?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Понедельник, 24 Сентябрь, 2007 21:36 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Слушайте, CheshireCat, назовите своё имя, пожалуйста! Просто, доброй традицией данного славного форума стало подписываться своими настоящими именами и фамилиями. А по-кличке как-то даже и не приятно обращаться к собеседнику – не располагает...

CheshireCat писал(а):
у нас просто разное представление о том что таки необходимо в языке а без чего можно обойтись. разный опыт, и нельзя сказать чей опыт "лучше". главное что желание все урезать - совпадает)) и это хорошо)) а между тем, начиная с Оберона-1, в язык постоянно что-то добавляют)) Добавление это не зло если оно четко оправдано))

Не помню, но, по-моему, Чёрчил как-то сказал в парламенте что-то, навроде того, что «надо всячески опасаться полезных и взвешенных нововведений, особенно тех, которые подкреплены доводами здравого смысла»... :о)
Цитата:
Вам просто _кажется_ что КА - не оправдано. Что те добавления которые делались – более оправданы чем _одно_ добавление - КА, которое их большую часть заменит... ладно, поживем - увидим... или - не увидим))

Нет. Я категорически против введения КА В ЯЗЫК! Я – за введение в язык СРЕДСТВ, которые помогают строить новый язык на базе имеющегося для поддержки той или иной парадигмы или идеологии (вплоть до смены синтаксиса). Вполне естественным выводом будет заключение о том, что я склоняюсь в сторону Форта и Лиспа. Но, опять-таки, это – чисто эмпирические мозговые упражнения. В области оберонов – библиотеки и - только!
Цитата:
по двунаправленности, таблицам и указателям - конкретизирую.
я нигде не говорил про навороченные субд, лишь про таблицы.
(кстати двунаправленность в СУБД называют "реляционность")) ) А таблица конечно не выполняет очистку сама, она лишь _дает возможность_ это сделать. Например согласовать вызов предварительно реализованных процедур разрушения связи в компонентах на обоих ее концах. И нормально, чисто, в реальном времени, отработать факт завершения связи.
Указатель-же этого сделать не позволяет в принципе, потому что он однонаправлен и его "цель" не имеет никакой информации о "источнике", он просто не имеет нужной информации (хотя безусловно именно поэтому он занимает меньше памяти). Поэтому для поддержки целостности системы приходится привлекать сторонние ее компоненты которые знают то что требуется, знают _обоих_ или могут это вычислить. А это усложняет архитектуру всей системы. Именно поэтому я называю указатель полуэлементом. Он - несамодостаточная вещь, он зависит от наличия в системе чего-то еще. А зависимости усложняют модификацию.

Таблица – носитель реляционности в СУБД.
Без механизмов СУБД – она – НИЧТО.
Эти механизмы и есть ДОПОЛНИТЕЛЬНЫЕ средства НАД таблицами.
Эти механизмы (просто по своей природе) НЕ МОГУТ работать «в реальном времени» (но, так как само определение понятие «реального времени» сейчас порождает споры, то я оговариваюсь – смотря в КАКОМ РЕАЛЬНОМ ВРЕМЕНИ).
СУБД потому и является «реляционными», что таблицы (части таблиц) носят (отображают) понятия «отношения». Для полноценной реализации такого же рода отношений без наименования получающейся системы «реляционная БД», просто не будем выходить дальше ОЗУ в своих операциях над «хранилищами». Могу вас заверить, что получившаяся система будет ничуть не хуже.
«Указатель в системе» ни от чего не «зависит». Семантика его настолько низкоуровнева, да к тому же ещё и «нагружена с двух сторон» (понятие элементарной ячейки в массиве памяти + простейшее понятие идентификатора), что он ни чём не нуждается, а сам является строительным блоком для построения более сложных решений (систем).
Цитата:
Я согласен что иногда очистка источника связи не требуется, именно потому возникает искушение экономно обойтись указателем.
Но это как с goto. Проблемы остаются чисто потому что иногда их ведь не бывает и потому неохота их решать вообще)). с гото тоже проблем нет _иногда_. но _в общем случае_ указатель все-же не может полноценно заменить таблицу. И когда этот факт медленно доползет до мозга, как и то что указатели таки иногда полезны как низкоуровневое системное средство для работы с написанной на Си системой, разработчику остается только добавить сборщик мусора. Просто больше выхода у него нет. Поэтому все _универсальные_ процедурные системы с указателями - _требуют_ сборщика мусора.

Все эти рассуждения верны до тех пор, пока у вас в задаче не удаётся получить решения, где нет динамики в работе со структурами данных.
Простой пример: «обыкновенный» бортовой самописец. Нужна ли там СУБД? В принципе – есть соблазн «встроить». Но вот беда – НИ ОДНА ИЗ СУЩЕСТВУЮЩИХ СУБД не может обеспечить нормальную работоспособность при записи параметров полёта, при ЗАДАННЫХ ПАРАМЕТРАХ «реального времени». А те (нормальные, привычные, «простые», «безреляционные») алгоритмы, что разработаны – совершенно не нуждаются в динамическом выделении/освобождении памяти... Да там у меня и понятие «указатель» существует «опосредованно», через переменные статически объявленных массивов и записей...
Городить там «реляционность»... - зачем?
Да, на уровне проекта, модели, что-то такое я рисовал с кубиками и стрелочками между ними. Но, продвигаясь по решению задачи, я нашёл простой и адекватный способ выражения сущностей моей предметной области, отношений между ними и операций над(между) ними, помогающими успешно «втиснуть» проект в жёсткие временные и пространственные рамки к моей системе.
Использование «полного» отображения «реляционной» модели на какой-либо тулз аля СУБД – стало бы НЕ оптимальным решением, с огромным перерасходом вычислительных и «памятийных» ресурсов...

Понимаете, CheshireCat, программирование (до сих пор, как это не удивительно, представьте!) иногда требует подсчёта отдельных тактов и байтов. В том числе и для того, что бы вы смогли спокойно поспать по пути из Москвы во Владивосток на высоте 10 000 м или что бы всякая сволочь сто раз подумала, прежде чем заявлять права на что-то в России. :о)
Цитата:
ЗЫ... Да, если есть возможность, следует использовать статические данные. Никто и не спорит. Сам всегда так делаю в мелких утилитах. Но мы то говорим про общий случай когда система обязана быть модифицируемой, динамичной.

Удивительно то, что по размерам оте самые системы, в которых требуется подсчитывать такты и байты могут быть меньше в разы некоторых утилит «обычного» программиста. Но! Зачастую мозговой энергии и изобретательности, при их создании, затрачивается НА ПОРЯДКИ больше; и «внесено» в эти системы «мощности решений» не в пример больше.
Про «общий случай» можно и поговорить. Обеспечение «модифицируемости» и «динамичности» - рассматриваются на фазе принятия проектных решений, при учёте ограничений предметной области и средств реализации.
Если используется Оберон – одни подходы, если Си – другие.
Буд-то бы те, кто работает на Си не имею своих, сложившихся во время десятилетий работы, практик?!
Просто (как в моей области) ТРАДИЦИОННО в понятие «модифицируемости» и «динамичности» вкладывается свой смысл. Этот «смысл» может и не быть похожим 1-в-1 на обероновский, но, поверьте мне никто и нигде не стремится «осложнить себе жизнь» и делать «лишние движения».

Си не поддерживает модульности синтаксически, но есть приёмы и подходы, позволяющие разбить систему на относительно «ярковыраженные» обособленные части.
Пока, «на лету» код менять в бортовых системах не пытался. Но вот появился загрузчик ELF-модулей (exe или dll) в Контики – будем и его пользовать – посмотрим, что такого нового мы можем «выкатить», что бы не возить приборы и оборудование на аэродромы и на полигоны, или их «железо» – через пол-мира – к нам... :о)

Цитата:
Непонял почему это у меня гото самодостаточен? Ерунда какая.
Он же тоже однонаправлен и черезчур низкоуровнев, он _не может ничего выразить в одиночку сам по себе_ и потому не подходит на роль элемента языка. Вот дейкстровские - могут выразить сами кое-что. Самодостаточны. Видимо Вы играете словами, зачем-то подсовываете математическую и философскую самодостаточность вместо инженерной.

Я не играю словами.
Для «работы» goto ничего кроме метки (адреса, ссылки, «якоря») НЕ НУЖНО. НИКАКОЙ ДОПОЛНИТЕЛЬНОЙ СИНТАКСИЧЕСКОЙ ИЛИ СЕМАНТИЧЕСКОЙ «ОБВЕСКИ».
Для работы дейкстровских примитивов, вам нужно обеспечить выполнение «предусловий» и «инвариантов». Кроме того (в зависимости от ЯП), вам нужно обеспечить больше мест «правильности оформления» этих синтаксических конструкций. Собственно (что не очевидно для многих, даже после десятилетий программирования :о) ) и само разбиение на несколько похожих, но «разных» итеративных конструкций как раз и служит для более чёткого, «явного» закрепления разности смыслов участков вашего кода разной семантики.
Goto более «прост», более «общ», более «опасен». Но это (как и в случае с командами risc-машин, по сравнению с cisc-машинами) позволяет КОМБИНИРОВАТЬ из них более подходящие для данной задачи (оптимальные) последовательности операций. Большая свобода выбора. Меньшая «смысловая нагрузка» - большая «допустимая комбинаторность». Но здесь же – и опасность «более высокой семантической» перенагрузки (как в путанице иных производительных, но совершенно запутанных ФОРТРАН-программ) :о)
В конце концов, именно на комбинации goto строятся дейкстровские примитивы... :о) Для выражения более «высокоуровневой», но ограниченной семантики.

Кстати, мне не понятно противопоставление математики и философии инженерии!
Программист без математики – просто кодер, даже – не инженер!
Программист, который не интересуется, хотя бы изредка, философскими вопросами, – не просто кодер, а – просто непонятно что... «кодеротёс», что ли? :о)
Ведь надо ж относиться к своему труду не просто как к «тасканию камней», надо ж, хоть и иногда, и «Храм строить»... :о)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Понедельник, 24 Сентябрь, 2007 23:19 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Цитата:
Цитата:
Вам просто _кажется_ что КА - не оправдано. Что те добавления которые делались – более оправданы чем _одно_ добавление - КА, которое их большую часть заменит... ладно, поживем - увидим... или - не увидим))
Нет. Я категорически против введения КА В ЯЗЫК! Я – за введение в язык СРЕДСТВ, которые помогают строить новый язык на базе имеющегося для поддержки той или иной парадигмы или идеологии (вплоть до смены синтаксиса)
Насколько я понимаю, цикл WHILE, обобщённый в Обероне-07 Виртом до цикла Дейкстры, как раз можно удобно использовать для реализации конечных автоматов? Или я ошибаюсь?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Вторник, 25 Сентябрь, 2007 21:17 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Geniepro писал(а):
Насколько я понимаю, цикл WHILE, обобщённый в Обероне-07 Виртом до цикла Дейкстры, как раз можно удобно использовать для реализации конечных автоматов? Или я ошибаюсь?

Описания ещё не видел... У вас есть? - дайте ссылку...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Вторник, 25 Сентябрь, 2007 23:47 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Описания Оберона-07 у меня тоже нет, но цикл Дейкстры описан во многих книгах...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Свежий язык программирования :)
СообщениеДобавлено: Среда, 26 Сентябрь, 2007 00:54 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Владимир Лось писал(а):
Geniepro писал(а):
Насколько я понимаю, цикл WHILE, обобщённый в Обероне-07 Виртом до цикла Дейкстры, как раз можно удобно использовать для реализации конечных автоматов? Или я ошибаюсь?

Описания ещё не видел... У вас есть? - дайте ссылку...

Вся доступная информация пока только здесь: viewtopic.php?f=30&t=615


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 76 ]  На страницу Пред.  1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB