OberonCore https://forum.oberoncore.ru/ |
|
Свежий язык программирования :) https://forum.oberoncore.ru/viewtopic.php?f=21&t=459 |
Страница 2 из 4 |
Автор: | Wlad [ Понедельник, 17 Сентябрь, 2007 20:17 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
CheshireCat писал(а): ((ужас чего наворочали. и снова грамматики как в зонноне... Совершенно не наблюдаю этого "кАка"... И, собсна, а чего так фдрук очередная попытка поспособствовать прогрессу в отрасли с "ужасом" ассоциируется? Вода холодная? Мир привычный покусился кто-то поломать? CheshireCat писал(а): подумаю лучше на тему конечных автоматов и ммх... Да, пожалуй, это будет для всех лучше... :о) |
Автор: | CheshireCat [ Вторник, 18 Сентябрь, 2007 12:21 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
не подскакивайте, у меня было просто брюзжание вслух)) я ни в коей мере не навязываюсь и никаким авторитетом тут не обладаю)) просто заметил что система (как и зоннон) пытается своим особым способом структурировать уж очень большую и не вполне изученную область. Архитектура это сложная штука, подобно искусственному интеллекту. Мне просто на уровне интуиции не нравится их подход. Не нравятся обмены и протоколы как элемент описания архитектуры. Потому что логика работы системы становится неявной и труднее предсказуемой по описанию. Обмены это подобно указателям, слишком низкоуровневая, "однонаправленная" ("неполная", "нецельная", "незамкнутая" - не знаю адекватного термина)) ) абстракция. Система из таких полу-элементов часто имеет артефакты. Может тот кто знает синергетику, и обьяснил бы в чем дело)) У меня всего-лишь сработал нюх на софт)) 9 лет администрирования разных программ выработали... Композита - слишком необычная и экспериментальная штука. К то как а я буду ждать пока другие шишек набьют с ней как с указателями)) так что наверное лучшеб КА в язык встроили, Глушков поди не зря на них налегал... и еще полезно наверно сейчас в языке иметь прямую поддержку автоматически распараллеливаемых ммх-подобных операций с маленькими массивчиками из нескольких элементов, pack. фиксированной длины... заменить byte например на bytepack... оффтоп... ...так никому тут подпиленная mocka не пригодится? 400 кило архив тгз с компилятором, 700 с исходниками, все линковано статически с уцЛибс, генерирует статические бинарники от 20 кб (можно и 3.5 кб хелло ворд сделать если надо). бутстраппится из ассемблерных исходников под Слакварью и НетБСД за 3 секунды и требует для работы только шелл и бинутилсы (гсс уже не нужен для линковки). я там для себя внес модификацию - теперь компилятор понимает ключевые слова и базовые типы в низком регистре. получается очень похоже на Паскаль)) Пришлось лазить по исходникам и переименовывать кучу переменных с именами наподобие from to by mod ))... Имена русские увы не берет но сообщения вполне нормально русские в кои8 пишет в консоль. Может пригодиться например учителям для лаб или олимпиад как запасной вариант)). оцениваю компилятор на 4 балла. писан местами по студенчески и кое-где залатан но вроде живой. |
Автор: | Wlad [ Вторник, 18 Сентябрь, 2007 21:19 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
CheshireCat писал(а): не подскакивайте, у меня было просто брюзжание вслух)) Я, как раз, – и не подсКАКивал... На счёт икания очень хорошо доктор Борменталь говорил... CheshireCat писал(а): я ни в коей мере не навязываюсь и никаким авторитетом тут не обладаю)) Авторитет – вещь капризная, приходящая и призрачная... Вот уж на что я лично смотрю после всего остального... :о) Как по мне, если уж на то пошлО – так главнее, что бы ногти не обгрызаны были и под ними черноты не наблюдалось!... :о))) CheshireCat писал(а): просто заметил что система (как и зоннон) пытается своим особым способом структурировать уж очень большую и не вполне изученную область. Архитектура это сложная штука, подобно искусственному интеллекту. Мне просто на уровне интуиции не нравится их подход. Не нравятся обмены и протоколы как элемент описания архитектуры. Потому что логика работы системы становится неявной и труднее предсказуемой по описанию. «Этапачемужето?» (с) Матроскин Здесь я с вами никак согласиться не могу! Наоборот! Здесь открывается ещё одно измерение в описании интерфейсов! Может я до сих пор неправильно делал, что не повторял, того, что уже когда-то сказал – ведь не все могли это читать – просто в силу срока рождения или приобщения к Сети. :о) А тяжкий труд различного рода «популяризаторов», в не малой степени, заключается именно в готовности повторить! Так вот: вводя формализацию (в удобоваримом представлении, заметьте!) обмена, Зоннон и Композита позволяют раскрыть «семантическую ожидаемость» интерфейсов. Теперь оные интерфейсы – не просто описания кучи функций (методов) и массой «сопроводиловки»-текстовых док (описанное в которых может поддерживаться, а может н нет!). Теперь у вас есть СПОСОБ ОПИСАНИЯ И ВЕРИФИКАЦИИ З_А_Я_В_Л_Е_Н_Н_О_Й ЛОГИКИ (и – последовательности) взаимодействия между компонентами! Из описания интерфейсов в традиционном варианте вы никак этого ни получить, ни проверить, ни получить поддержки НЕ МОГЛИ! Средств, правил и инструментов для этого у вас не было! Более того и для появления самого такого инструментария никаких возможностей не существовало! - только через поддержку определённого «соглашения» в среде. К языкам программирования и описаниям проектных решений это ни в малейшей степени не относилось. Потому, что это можно было поддерживать и соглашаться, а, можно и - нет. CheshireCat писал(а): Обмены это подобно указателям, слишком низкоуровневая, "однонаправленная" ("неполная", "нецельная", "незамкнутая" - не знаю адекватного термина)) ) абстракция. Здрасьте! Как раз я бы мог согласиться, если бы имели в виду не Зоннон и Композиту, а – обмены в QNX и MINIX! Там – да – абстракции ограничены низкоуровневым машинным представлением информации. Но в Хонноне и Композите – уж извините – описания уровня абстракций (и реальное наполнение их) ограничены только вашей фантазией, наложенной на предметку!!! (А вы доки-то читали, ваще-то?) CheshireCat писал(а): Система из таких полу-элементов часто имеет артефакты. Каких ПОЛУ-ЭЛЕМЕНТОВ? CheshireCat писал(а): так что наверное лучшеб КА в язык встроили, А вот здесь, как раз, в полной мере «приложимо» ваше возмущение на счёт «низкоуровневости»!!! Вы когда-нибудь пытались «расшифровать» описание какого-нибудь протокола на реализации с помощью «чисто автоматного подхода» (продираясь через лес веток switch-case) и, например, в подходе Активного Оберона или PROTOTHREADS? :о))) CheshireCat писал(а): Глушков поди не зря на них налегал... и еще полезно наверно сейчас в языке иметь прямую поддержку автоматически распараллеливаемых ммх-подобных операций с маленькими массивчиками из нескольких элементов, pack. фиксированной длины... заменить byte например на bytepack... 1.Я заканчивал кафедру, где чуть ли не 80% личного состава считали себя, тем или иным «макаром», принадлежащими к «школе Глушкова». Для меня само упоминание фамилии Глушкова хоть в малой степени в положительном ключе – уже является сигналом «напрячься на счёт» говорящего... Жизненный опыт, уж извините!... С одной стороны, подкреплённый отзывами новосибирцев (и – не только, а и тех, кто успел с Лебедевым поработать), с другой – последующее непосредственное общение (уже – по другую сторону Урала :о) ), с теми, кто считает себя «верным продолжателем дела»... 2.Глушков решал ограниченный круг задач, актуальных по его тематике в то время. Не он бы – так кто-то другой пришёл к примерно похожим подходам и решениям! Сама структура и способы обуславливались проблемой. И решались довольно «низкоуровневые» задачи. Меня умиляет желание расширить уровень применимости абстракций! Математика-то с человеческим мышлением – вещи гибкие – но лучше (для всех!) что бы набор абстракции соответствовал уровню задач! Или обладал свойством (или средством) «немозголомного» расширения и «поднятия» уровня. Желательно - максимально обобщенным средством! Вы хотите реальной иллюстрации применения теории КА на деле (к чему это может привести?) – попытайтесь найти в Сети распечатки реализации протоколов с помощью КА! :о))) А потом – найдите через гугл всё, что относится, к применению protothreads в, например, реализации стека TCP/IP... :о) Кроме того, в вашем последнем предложении сквозит (аж – с ног сдувает! :о) ) желание получить поддержку в максимально обобщённом средстве (язык программирования), довольно узкой и частной задачи... И – на что это опять похоже? «За что боролись?» |
Автор: | CheshireCat [ Среда, 19 Сентябрь, 2007 04:59 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
ну насчет черноты... я таки четко вижу себя мусорным котом ведь, хоть жена и злится когда я так говорю)) потому что все время роюсь в программном мусоре в поисках вкусно пахнущих кусочков)) за картинкой меня, Чешира - отсылаю всех в игру с отпадным оформлением - Америкэн МакГи Алиса)) насчет интерфейсов. обмен это с точки зрения _пользователя_ всегда низкоуровневая деталь. описание интерфейса для меня подобно силуэту предмета, контурному рисунку. имхо схема внутренней логики предмета более абстрактна и информативна для инженера чем рисунок его внешнего вида)) хотя конечно форма разьемов на панели достаточна бывает, и хорошо когда так. но не в данном случае, когда требуется мичуринство компонент и нужно их содержимое контролируемо перемешивать. нам ведь нужна не стыковка компонент как таковая! а получение агрегатов с заранее заданными свойствами, в том числе _выбор_ требуемых компонент и _выбор_ схем их взаимодействия. автоматизация проверки стыкуемости компонент вещь конечно полезная но это даже не половина дороги. хотя конечно обероновцев я понимаю. их подталкивает к такому видению современная многопроцессорность и кластеризация. набор кусков мусора, перебрасывающихся всяким другим мусором - постоянно у меня перед глазами)) шютка грамматики для меня это слишком децентрализованное описание, неиерархическое, нецельное, неструктурное - относительно описываемого предмета конечно. взаимодействие то конечно нормально описано а вот сам предмет с которым нам работать - получается только косвенно. В стиле ООП. Вы просто смотрите с точки зрения программиста который постоянно стыкует готовые компоненты. Тогда да, возможность проверять протокол полезна. А я - с точки зрения администратора ("суперпользователя") который потом результат ваших стыковок использует и пытается понять что все-таки делается "внутре" и как заставить его делать то что надо)) Сейчас крайне мало думают о пользователях. даже GPL думает только о благе программистов на самом деле потому что без них сейчас никто в их программах все равно не разберется)) полу-элементом для меня является компонент который не самодостаточен и требует строгих правил комбинирования с другими полуэлементами чтоб получить что-то самодостаточное и надежное. пример. указатели - полуэлементы. а реляционная таблица с записью вида (источник,приемник) - полный элемент. goto - полуэлемент. while, if - элементы... и так далее... думаю все поняли что я имею ввиду и могут расклассифицировать по аналогии все прочие программистские термины. ...про разные применения КА - switch-технологию, protothreads, я конечно слышал... просто не раз _озвучивалось_ что КА как раз _требует_ автоматизированной поддержки, тулзами а лучше самим языком программирования... и уж само собой копаться в потрохах switch-ей _ни в коем случае не надо_, как и дизассемблировать обычные программы вместо чтения высокоуровневых if-while)) ...а ведь были таки у Глушкова новаторские и при том очень полезные разработки типа МИР)) хотя конечно вам виднее... Впрочем у меня тоже создалось впечатление что там все держалось на нем самом а ученикам он мало что сумел обьяснить. тоже видимо скорее интуитив был в значительной мере а не логик. или потому что трудно читается как все математическое и сухое. в-общем, согласен, та школа уже давно того... но порыться в той старой помойке мне было приятно)) по абстракциям. уровень абстракции это понятие связанное не с самой абстракцией, не ее свойство. это свойство _текущего положения_ абстракции среди набора тех с которыми мы оперируем. свойство _системы_ абстракций. место кубика в пирамиде может меняться. пример - списки в лиспе это ведь тоже лишь простая абстракция. еще продолжать примеры чтоб у Вас совсем разрушилось неверное представление о принципиальной низкоуровневости и малой применимости КА))? ЗЫ. я собственно подумываю над тем, можно ли расширить описание инициализатора модуля до полноценного конечного автомата с более чем двумя состояниями. с целью превратить каждый модуль в табличный автомат. И соответственно модифицировать логику Oberon.Loop введя больше полезных операций алгебры конечных автоматов чем две имеющиеся. например, нечто типа вычитания для автоматического получения частных оптимизированных программ... И к каким осложнениям это приведет. А то еще будет как с композитой - при борьбе со сложностью и ее артефактами введены новая сложность и думаю скоро будут новые артефакты)) Первое осложнение которое приходит в голову - может потребоваться модифицировать механизм вызова команд модуля (экспортируемых процедур без параметров), сделав его отложенным и выполняющимся через Oberon.Loop... в-общем тут еще мне ничего не ясно еще много думать... но сделать из модулей Оберона-1 конечные автоматы охота. мне кажется они могут просто перекрыть функциональность и параллельного ActiveOberon и Composit-ы. может я и не прав... |
Автор: | Wlad [ Среда, 19 Сентябрь, 2007 21:35 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
>>>насчет интерфейсов. обмен это с точки зрения _пользователя_ всегда низкоуровневая деталь. Это если такой «обмен» удалось сделать «атомарным» и не имеющим «памяти» по вызванным другим элементам интерфейса! Но – так бывает очень редко! Конечно, талант разработчика как раз и состоит в том, что бы в интерфейсе на старт каждого действия была отдельная «кнопка». Но, в большинстве случаев, пользователю ПРИХОДИТСЯ учитывать модальность. А тут, уж пардоньте, часто выходит, как в истории про один прибор в конце 1960-х, который у потребителей горел при первом же включении! Причём, прибор этот прошёл самые жёсткие испытания и проверки (по-настоящему! с военприёмкой! «без фуфла»!). А дело оказалось в том, что первое же предложение, про включение одного из режимов этого прибора, было разбито так: на нечётной странице, внизу, на одной стороне листа, было написано: «Нажмите кнопку А, ...» переворачиваем страницу, и на другой стороне листа вверху читаем: «... предварительно нажав кнопку Б.» ... И техники и младший инженерный состав, дружными рядами, сожгли тысячи приборов в первые же две недели начала эксплуатации! Просто «идя прямо по написанному»! Соблюдая интерфейсы! :о) Являлось ли обеспечение выполнения требования о предварительном нажатии Б перед А «более низкоуровневой деталью»? Нет! Кнопка Б и всё, что с нею связано – находились на одном уровне иерархии понятий и абстракций для пользователя. Здесь вопрос – были ли правы конструкторы, внося «зависимости» от «последовательности вызова элементов интерфейса»? Конечно, в идеале, было бы лучше иметь «отдельную» кнопку на каждое желание пользователя! Но, такого часто не удаётся получить. (О причинах – отдельный подробный и долгий разговор, но, вкратце это «играют» ограничения реализации, а не предметки.) И вот, как раз для таких случаев, и подходит описание правильности последовательности субъекта (клиента), пытающегося получить некую функциональность (или – её часть) от «сервера»... Такое описание и не даст «нажать А без нажатой Б»! >>>описание интерфейса для меня подобно силуэту предмета, контурному рисунку. имхо схема внутренней логики предмета более абстрактна и информативна для инженера чем рисунок его внешнего вида)) хотя конечно форма разьемов на панели достаточна бывает, и хорошо когда так. «Абстрактность» и «информативность» – это красное и тёплое! Союз «и» туда не влазит! Не может быть «схема внутренней логики предмета» БОЛЕЕ АБСТРАКТНОЙ, чем рисунок внешнего вида предмета!!! Вы уже начали дробить предмет и вычленять элементы и связи, которые привели к тому, что вы воспринимаете что-то, как именно «такой предмет». >>>но не в данном случае, когда требуется мичуринство компонент и нужно их содержимое контролируемо перемешивать. Так ведь никто и не собирался «перемешивать»! Как раз и добиваемся БОЛЕЕ ЧЁТКОГО И ПОЛНОГО (по-возможности – более всестороннего и подробного) описания ГРАНИЦ компонент! Это в ТММ интерфейсы обуславливаются самими физическими свойствами и «работой» физических и химических законов между «сочленяемыми» деталями. А в мире программирования таких ограничений нет. Но мы их ищем! Нам НЕОБХОДИМО находить такое «сочетание камешков», что бы вода ИМЕННО ТАК по руслу, сложенному нами из этих «камешков» потекла и начала «вращать колёсики нашей мельницы»! :о) А без описания правил взаимодействия у вас только метафизика (да и то – иногда!) получается! Всё – только на везении, а не на законах! >>>нам ведь нужна не стыковка компонент как таковая! а получение агрегатов с заранее заданными свойствами, в том числе _выбор_ требуемых компонент и _выбор_ схем их взаимодействия. Правильно, но схемы эти – НЕ СТАТИЧНЫ! А чем вы правила динамики собираетесь описывать? Декларативность – хорошо! Но чем она реализуется, поддерживается и отслеживается? >>>автоматизация проверки стыкуемости компонент вещь конечно полезная но это даже не половина дороги. На самом деле, мы (отрасль вцелом) ещё даже со ступенек дома не сошли, а не то, что к калитке на улицу не подходим! :о) >>>хотя конечно обероновцев я понимаю. их подталкивает к такому видению современная многопроцессорность и кластеризация. набор кусков мусора, перебрасывающихся всяким другим мусором - постоянно у меня перед глазами)) шютка Так ведь и оберон-мир к тому и стремиться, что бы такое «копошение в мусоре» было как можно меньшим! Вы ж отследите всё развитие оберон-систем! И посмотрите – там и правда «мусора» меньше на единицу обеспечиваемой аналогичной функциональности. >>>грамматики для меня это слишком децентрализованное описание, неиерархическое, нецельное, неструктурное - относительно описываемого предмета конечно. Вы – не читали доку! Грамматики как раз и создавались для иерархического, цельного и именно структурного описания сущностей при взаимодействиях. Конечно, то, что может (неподготовленному читателю) показаться скопищем никак не связанной зауми, для человека подписавшего некоторую бумагу и о неразглашении и знакомому с некоторыми планами, относительно применения предлагаемых механизмов, видится единственно верным, полным и удобным решением. Вкратце: описания взаимодействия компонентов (по Зоннону или Композите), в конечном итоге должны привести к абсолютно гибкой архитектуре взаимодействия между компонентами на основе средства с полным самоописанием, с минимальным базисом для «учреждения договорённости о форматах и способах взаимодействия». Это то, что сейчас заказывается на проработку грандами отрасли телекоммуникаций и то, чем планируется заменить мобильники, телевидение и интернет. Намёк на ПОРЯДОК цены вопроса улавливаете?... :о) >>>взаимодействие то конечно нормально описано а вот сам предмет с которым нам работать - получается только косвенно. В стиле ООП. Пардон, а вы можете предложить что-то иное, отличное от представлений «часть-целое», «пользователь-поставщик», «принадлежность-к-множеству»? >>>полу-элементом для меня является компонент который не самодостаточен и требует строгих правил комбинирования с другими полуэлементами чтоб получить что-то самодостаточное и надежное. Само понятие «компонент» предусматривает СПОСОБ ВЗАИМОДЕЙСТВИЯ с чем-то другим! Хотя бы - со средой, для функционирования в которой компонент изготовлялся... И тут вы опять неминуемо придёте - .... к правилам взаимодействия! Причём – обязательно! - к необходимости описания динамики, а не просто перечисления набора функций в привычных «интерфейсах»... Вернулись к тому, с чего начали!... :о) >>>пример. указатели - полуэлементы. а реляционная таблица с записью вида (источник,приемник) - полный элемент. goto - полуэлемент. while, if - элементы... и так далее... думаю все поняли что я имею ввиду и могут расклассифицировать по аналогии все прочие программистские термины. Не понял. Указатель – всего лишь удачный (и самодостаточны, в определённом смысле и на определённом уровне) способ представления «метки (имени,дескриптора) объекта». Обоснуйте полноту вашей таблицы вида (источник, приёмник) для случая сурогатных ключей и потери основной таблицы в вашей БД... :о) goto – как раз – ПОЛНЫЙ элемент, а вот while, for – в полном согласии с вашей интуитивной классификацией - «полуэлементы»! У goto «мощность применения» выше, а вот структурные примитивы, как раз и были введены по причине требования наложения ограничений... :о) >>>...про разные применения КА - switch-технологию, protothreads, я конечно слышал... просто не раз _озвучивалось_ что КА как раз _требует_ автоматизированной поддержки, тулзами а лучше самим языком программирования... А вот подходы Активного Оберона и protothreads – НЕТ, НЕ ТРЕБУЮТ! Они - «самоописываемы» и наглядны! :о) И алгоритмы, записанные с помощью и в духе этих подходов, более интуитивно понятны и обозримы! >>>...а ведь были таки у Глушкова новаторские и при том очень полезные разработки типа МИР)) хотя конечно вам виднее... Нам виднее!... :о) >>>по абстракциям. уровень абстракции это понятие связанное не с самой абстракцией, не ее свойство. это свойство _текущего положения_ абстракции среди набора тех с которыми мы оперируем. свойство _системы_ абстракций. место кубика в пирамиде может меняться. Абстракция для того и вводится, что бы «описывать место»! Абстракция – есть само «место с описанием»! То, что вы описали очень смахивает на описание взаимодействия и системы конкретных носителей абстракций (экземпляров классов)... :о) >>>пример - списки в лиспе это ведь тоже лишь простая абстракция. еще продолжать примеры чтоб у Вас совсем разрушилось неверное представление о принципиальной низкоуровневости и малой применимости КА))? Список в Лисп – абстракция понятия упорядоченного набора элементов. Как это сокровенное знание поможет вам разрушить у меня «неверное представление о принципиальной низкоуровневости» КА – не знаю! :о) Кстати, не пытались на Лиспе описывать структуру переходов КА? :о) >>>ЗЫ. я собственно подумываю над тем, можно ли расширить описание инициализатора модуля до полноценного конечного автомата с более чем двумя состояниями. с целью превратить каждый модуль в табличный автомат. Для какой задачи? У меня великое подозрение, что это опять из той же оперы, что и про введение поддержки ММХ... :о) >>>А то еще будет как с композитой - при борьбе со сложностью и ее артефактами введены новая сложность и думаю скоро будут новые артефакты)) Я лично сложности не вижу! Ещё одно измерение – вижу! Но оно - «ортогонально» к уже имющимся «пространствам описаний», а, потому – не имеет на них «проекций усложнения»... |
Автор: | Geniepro [ Среда, 19 Сентябрь, 2007 22:49 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
Владимир Лось писал(а): Вкратце: описания взаимодействия компонентов (по Зоннону или Композите), в конечном итоге должны привести к абсолютно гибкой архитектуре взаимодействия между компонентами на основе средства с полным самоописанием, с минимальным базисом для «учреждения договорённости о форматах и способах взаимодействия». А эти протоколы Зоннона/Композиты можно менять во время работы программы? Или только путём перекомпиляции?Если только перекомпиляцией то какая ж тут гибкость-то? |
Автор: | Wlad [ Четверг, 20 Сентябрь, 2007 08:22 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
Geniepro писал(а): А эти протоколы Зоннона/Композиты можно менять во время работы программы? Или только путём перекомпиляции? Если только перекомпиляцией то какая ж тут гибкость-то? Описание протокола взаимодействия – часть описания интерфейса. Постулированные и опубликованные интерфейсы – меняются? Конечно, с другой стороны, я могу написать компонент, действующий на принципах того же КА, и работающий «проверяльщиком» входной информации от клиентов сервера, куда этот компонент будет встраиваться (своеобразный «синтаксический(лексический) анализатор»). И, при определённых усилиях и организации кода, я могу просто на лету менять его автомат переходов (описание синтаксиса)... Но сам СПОСОБ ВЗАИМОДЕЙСТВИЯ с самим этим компонентом, всё равно, остаётся неизменным – он часть интерфейса этого компонента. |
Автор: | Valery Solovey [ Четверг, 20 Сентябрь, 2007 10:26 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
Владимир Лось писал(а): «Абстрактность» и «информативность» – это красное и тёплое! Союз «и» туда не влазит! А может, «Абстрактность» и «информативность» – это холодное и тёплое? Ведь, при увеличении информативности - больше конкретики => меньше абстрагирования. Значит соединительный союз тут точно не к месту.
Не может быть «схема внутренней логики предмета» БОЛЕЕ АБСТРАКТНОЙ, чем рисунок внешнего вида предмета!!! Вы уже начали дробить предмет и вычленять элементы и связи, которые привели к тому, что вы воспринимаете что-то, как именно «такой предмет». |
Автор: | Info21 [ Четверг, 20 Сентябрь, 2007 11:16 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
Владимир Лось писал(а): ... «Абстрактность» и «информативность» – это красное и тёплое! Союз «и» туда не влазит! Это плюс не влазит. А союз и влазит. И сама фраза у CheshireCat'а насчет "более абстрактный и информативный" изячна. |
Автор: | Geniepro [ Четверг, 20 Сентябрь, 2007 19:17 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
Владимир Лось писал(а): Geniepro писал(а): А эти протоколы Зоннона/Композиты можно менять во время работы программы? Или только путём перекомпиляции? Если только перекомпиляцией то какая ж тут гибкость-то? Описание протокола взаимодействия – часть описания интерфейса. Постулированные и опубликованные интерфейсы – меняются? |
Автор: | CheshireCat [ Пятница, 21 Сентябрь, 2007 04:41 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
Чето я все больше теряю тему разговора)) такое ощущение что мы с Владимиром говорим на разных языках)) Так все-таки что он пытается и кому доказать такого что противоречит моим словам, кто-нибудь обьяснит?)) Или он таки подтверждает мои слова?)) Еще раз повторю что у нас просто разные требования. Я -пользователь. Он - программист. А программисты часто не вполне понимают чего на самом деле надо пользователям)) Особенно - государственные)) Впаривание больших проектов это не моя область)) Мне бы то что надо конкретно мне)) по указателям. таблица отличается тем что позволяет реализовать поддержку целостности структур данных. она двунаправленна. а указатель - нет. и для того чтоб все не поломалось он требует наличия сборщика мусора который реализует по сути функцию поиска этих обратных связей и выполнение нужных чисток. По-моему я вполне четко сформулировал критерий по которому элемент полон. Это - самодостаточность. А про гото я вообще ниче у Владимира не понял. А кто-нибудь понял?)) он называет черное белым по-моему... ....по МИР. мой отец на нем считал. по сравнению с тем что в то время было МИР был супер. я ему верю. ...при чем тут структура КА на Лиспе? спор ради спора - не для меня. КА и Оберон мне были бы полезны для конкретной задачи. Веб-сервисы. ЛЕГКО МОДИФИЦИРУЕМЫЕ, расширяемые и УРЕЗАЕМЫЕ медицинские информационные системы. Прежде всего - ПОНЯТНЫЕ ВСЕМУ ПЕРСОНАЛУ системы. Вместо теперешнего зоопарка порожденного халявой для программистов (кучи денег как в госзаказах, отсутствие обратной связи и ответственности после сдачи). Мои интересы вполне конкретны. И ММХ работа со строками была бы очень вебу полезна. И избегание уникода тоже. По-моему я вполне конкретно формулирую чего мне бы хотелось)) |
Автор: | Wlad [ Пятница, 21 Сентябрь, 2007 12:35 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
info21 писал(а): Владимир Лось писал(а): ... «Абстрактность» и «информативность» – это красное и тёплое! Союз «и» туда не влазит! Это плюс не влазит. А союз и влазит. И сама фраза у CheshireCat'а насчет "более абстрактный и информативный" изячна. Там где есть место оговоркам – не до изячества! Абстрактность может быть «более информативной», если для всех собеседников, выводящих новую абстрактность понятен базис «конкретики», на которой эта «абстрактность» построена. Мы не вопросами Веры занимаемся, что бы просто постулировать «вводимые с потолка абстрактности». Даже имея просто «абрис» прибора («картинки разъёмов и штекеров»), ЧеширскийКот обязан был быть мотивирован некоей задачей, для решения которой его выбор пал именно на ЭТОТ прибор. И критерии выбора ЧеширскогоКота наверняка не на цвете корпуса прибора основывались... |
Автор: | Wlad [ Пятница, 21 Сентябрь, 2007 12:36 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
CheshireCat писал(а): Чето я все больше теряю тему разговора)) такое ощущение что мы с Владимиром говорим на разных языках)) Так все-таки что он пытается и кому доказать такого что противоречит моим словам, кто-нибудь обьяснит?)) Или он таки подтверждает мои слова?)) Дело в том, что вами сейчас движет желание иметь в, используемом вами, средстве реализации неких частных свойств для наиболее быстрого решения вставших здесь и сейчас перед вами частных задач. Я же пытаюсь рассуждать с точки зрения опыта, обобщения, построения СИСТЕМ; пытаюсь втолковать, что даже если вы получите, то, что вам «вкрай необхидно прямо зараз!», то, всё равно, ваше «щасте будит мималйотным». Потому, что следующий набор задач возбудит в вас совершенно аналогичные желания добавить в язык «ещё чё-нить самое палезное» («Мне бы то что надо конкретно мне))», «КА и Оберон мне были бы полезны для конкретной задачи», «Мои интересы вполне конкретны.»). И так – до бесконечности («И ММХ работа со строками была бы очень вебу полезна.», «И избегание уникода тоже»(???!!!-моё)). И – не зарекайтесь, что ваш случай - «особенный»! :о) Наркоманы и алкоголики – ВСЕ АБСОЛЮТНО УВЕРЕНЫ НА СЧЁТ СОБСТВЕННОЙ СПОСОБНОСТИ «вовремя остановиться»... :о) (Вот на счёт курильщиков – допускаю! :о) Сам курил больше десяти лет, «дошёл» до двух пачек «Ватры» в день, 3 мая 1997 года бросил и вот уже 10 лет, как не выкурил ни одной сигареты! :о) ) CheshireCat писал(а): Еще раз повторю что у нас просто разные требования. Я -пользователь. Он - программист. А программисты часто не вполне понимают чего на самом деле надо пользователям)) А вы что думали, что программирование – это «написание кода, исполняющегося компьютером»? Нет. Программирование – это, прежде всего, описание задачи и способов её решения. В ходе построения этих описаний производится масса (мыслительной) работы, в том числе. и по оценке получаемых решений. Вот я и оценивал ваши рассуждения о «полукомпонентах» с точки зрения моего опыта. CheshireCat писал(а): Особенно - государственные)) Впаривание больших проектов это не моя область)) Если это намёк, то – не по адресу! CheshireCat писал(а): по указателям. таблица отличается тем что позволяет реализовать поддержку целостности структур данных. она двунаправленна.... Таблица НЕ ПОЗВОЛЯЕТ «реализовать поддержку целостности структур данных». Ни в одной из СУБД не встречал в описании их свойств понятия «двунаправленность», присущего создаваемым в этих СУБД таблицам... :о) CheshireCat писал(а): ...а указатель - нет. и для того чтоб все не поломалось он требует наличия сборщика мусора который реализует по сути функцию поиска этих обратных связей и выполнение нужных чисток. Если я примерно «усёк» понятие «двунаправленности», то не допускаете ли вы мысли, что могут существовать задачи (отличные от тех, с которыми приходилось сталкиваться до сих пор вам в вашей практике), для которых может просто не существовать потребности наличия «обратных связей»? А, если у меня в системе управления РВ всё так критично по временным рамкам, что я просто не пользуюсь подпрограммами выделения/возвращения памяти, а всё делаю статически определяемыми переменными? И у меня просто не будет «висячих» указателей? Здесь скорее на вероятность появления ошибок не природа указателей будет влиять, а – отслеживание правильности перемещения по составным структурам данных (проверки индексов)... CheshireCat писал(а): По-моему я вполне четко сформулировал критерий по которому элемент полон. Это - самодостаточность. А про гото я вообще ниче у Владимира не понял. Ну так по введённому, вами же, критерию, goto - «более самодостаточен» в базисе понятий представления вычислительного процесса (программы, алгоритма, последовательности действий), чем дейкстровские структуры управления! :о) CheshireCat писал(а): А кто-нибудь понял?)) он называет черное белым по-моему... Ну, и на что вы надеетесь, обращаясь к третьим лицам? :о) А вдруг третьи лица вас в библиотеку пошлют? В лучшем случае?... :о) CheshireCat писал(а): ....по МИР. мой отец на нем считал. по сравнению с тем что в то время было МИР был супер. я ему верю. И я вашему папе верю! Но, - зная историю вопроса, - причём здесь непосредственно Глушков? Наш директор тоже под всеми нашими документами о приёмке/сдаче бортового оборудования свою подпись ставит, но это ДАЛЕКО не значит, что он схемы разводит и проги пишет и на полигонах мёрзнет... CheshireCat писал(а): ...при чем тут структура КА на Лиспе? При том, что, не смотря на все язвительные замечания на счёт наличия множества скобок в Лиспе, я помню, как меня, в своё время, поразила наглядность описания и реализации таблицы переходов КА, когда я её первый раз увидел в Лисп-программе... CheshireCat писал(а): спор ради спора - не для меня. без комментариев... :о) |
Автор: | CheshireCat [ Понедельник, 24 Сентябрь, 2007 08:43 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
у нас просто разное представление о том что таки необходимо в языке а без чего можно обойтись. разный опыт, и нельзя сказать чей опыт "лучше". главное что желание все урезать - совпадает)) и это хорошо)) а между тем, начиная с Оберона-1, в язык постоянно что-то добавляют)) Добавление это не зло если оно четко оправдано)) Вам просто _кажется_ что КА - не оправдано. Что те добавления которые делались - более оправданы чем _одно_ добавление - КА, которое их большую часть заменит... ладно, поживем - увидим... или - не увидим)) по двунаправленности, таблицам и указателям - конкретизирую. я нигде не говорил про навороченные субд, лишь про таблицы. (кстати двунаправленность в СУБД называют "реляционность")) ) А таблица конечно не выполняет очистку сама, она лишь _дает возможность_ это сделать. Например согласовать вызов предварительно реализованных процедур разрушения связи в компонентах на обоих ее концах. И нормально, чисто, в реальном времени, отработать факт завершения связи. Указатель-же этого сделать не позволяет в принципе, потому что он однонаправлен и его "цель" не имеет никакой информации о "источнике", он просто не имеет нужной информации (хотя безусловно именно поэтому он занимает меньше памяти). Поэтому для поддержки целостности системы приходится привлекать сторонние ее компоненты которые знают то что требуется, знают _обоих_ или могут это вычислить. А это усложняет архитектуру всей системы. Именно поэтому я называю указатель полуэлементом. Он - несамодостаточная вещь, он зависит от наличия в системе чего-то еще. А зависимости усложняют модификацию. Теперь менее очевидное. Я согласен что иногда очистка источника связи не требуется, именно потому возникает искушение экономно обойтись указателем. Но это как с goto. Проблемы остаются чисто потому что иногда их ведь не бывает и потому неохота их решать вообще)). с гото тоже проблем нет _иногда_. но _в общем случае_ указатель все-же не может полноценно заменить таблицу. И когда этот факт медленно доползет до мозга, как и то что указатели таки иногда полезны как низкоуровневое системное средство для работы с написанной на Си системой, разработчику остается только добавить сборщик мусора. Просто больше выхода у него нет. Поэтому все _универсальные_ процедурные системы с указателями - _требуют_ сборщика мусора. А ведь могут иметь вместо указателей таблицы и не иметь выделенного сборщика мусора. Кстати большую полезность таблиц показывают все современные скриптовые языки. В них указатели непопулярны. И про то что есть какой-то сборщик мусора, вспоминают редко. И их реализация вообще может не иметь выделенного сборщика (мне так кажется... конкретные примеры привести не могу но могу попробовать поискать). Эти языки просто широко пользуются тем что _могут себе позволить не быть низкоуровневыми_, могут не иметь указателей. Получается что с таблицами ситуация та-же что и с Сетунью и с Обероном. Небольшое усложнение на низком уровне резко упрощает верхние уровни. По-моему подробнее разжевать мне уже не по силам)) ЗЫ... Да, если есть возможность, следует использовать статические данные. Никто и не спорит. Сам всегда так делаю в мелких утилитах. Но мы то говорим про общий случай когда система обязана быть модифицируемой, динамичной. Непонял почему это у меня гото самодостаточен? Ерунда какая. Он же тоже однонаправлен и черезчур низкоуровнев, он _не может ничего выразить в одиночку сам по себе_ и потому не подходит на роль элемента языка. Вот дейкстровские - могут выразить сами кое-что. Самодостаточны. Видимо Вы играете словами, зачем-то подсовываете математическую и философскую самодостаточность вместо инженерной. Мы говорим про инженерную поскольку говорим про реальную архитектуру реальной системы. Хорошо. конкретизирую. Для меня самодостаточность требует непустой семантики. Самодостаточность единицы а не самодостаточность пустоты. |
Автор: | Илья Ермаков [ Понедельник, 24 Сентябрь, 2007 12:54 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
Мне понравилась мысль про таблицы. А Вы не привели бы красивый и наглядный пример - может, в каких-то языках такой метод активно применяется? |
Автор: | Wlad [ Понедельник, 24 Сентябрь, 2007 21:36 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
Слушайте, CheshireCat, назовите своё имя, пожалуйста! Просто, доброй традицией данного славного форума стало подписываться своими настоящими именами и фамилиями. А по-кличке как-то даже и не приятно обращаться к собеседнику – не располагает... CheshireCat писал(а): у нас просто разное представление о том что таки необходимо в языке а без чего можно обойтись. разный опыт, и нельзя сказать чей опыт "лучше". главное что желание все урезать - совпадает)) и это хорошо)) а между тем, начиная с Оберона-1, в язык постоянно что-то добавляют)) Добавление это не зло если оно четко оправдано)) Не помню, но, по-моему, Чёрчил как-то сказал в парламенте что-то, навроде того, что «надо всячески опасаться полезных и взвешенных нововведений, особенно тех, которые подкреплены доводами здравого смысла»... :о) Цитата: Вам просто _кажется_ что КА - не оправдано. Что те добавления которые делались – более оправданы чем _одно_ добавление - КА, которое их большую часть заменит... ладно, поживем - увидим... или - не увидим)) Нет. Я категорически против введения КА В ЯЗЫК! Я – за введение в язык СРЕДСТВ, которые помогают строить новый язык на базе имеющегося для поддержки той или иной парадигмы или идеологии (вплоть до смены синтаксиса). Вполне естественным выводом будет заключение о том, что я склоняюсь в сторону Форта и Лиспа. Но, опять-таки, это – чисто эмпирические мозговые упражнения. В области оберонов – библиотеки и - только! Цитата: по двунаправленности, таблицам и указателям - конкретизирую. я нигде не говорил про навороченные субд, лишь про таблицы. (кстати двунаправленность в СУБД называют "реляционность")) ) А таблица конечно не выполняет очистку сама, она лишь _дает возможность_ это сделать. Например согласовать вызов предварительно реализованных процедур разрушения связи в компонентах на обоих ее концах. И нормально, чисто, в реальном времени, отработать факт завершения связи. Указатель-же этого сделать не позволяет в принципе, потому что он однонаправлен и его "цель" не имеет никакой информации о "источнике", он просто не имеет нужной информации (хотя безусловно именно поэтому он занимает меньше памяти). Поэтому для поддержки целостности системы приходится привлекать сторонние ее компоненты которые знают то что требуется, знают _обоих_ или могут это вычислить. А это усложняет архитектуру всей системы. Именно поэтому я называю указатель полуэлементом. Он - несамодостаточная вещь, он зависит от наличия в системе чего-то еще. А зависимости усложняют модификацию. Таблица – носитель реляционности в СУБД. Без механизмов СУБД – она – НИЧТО. Эти механизмы и есть ДОПОЛНИТЕЛЬНЫЕ средства НАД таблицами. Эти механизмы (просто по своей природе) НЕ МОГУТ работать «в реальном времени» (но, так как само определение понятие «реального времени» сейчас порождает споры, то я оговариваюсь – смотря в КАКОМ РЕАЛЬНОМ ВРЕМЕНИ). СУБД потому и является «реляционными», что таблицы (части таблиц) носят (отображают) понятия «отношения». Для полноценной реализации такого же рода отношений без наименования получающейся системы «реляционная БД», просто не будем выходить дальше ОЗУ в своих операциях над «хранилищами». Могу вас заверить, что получившаяся система будет ничуть не хуже. «Указатель в системе» ни от чего не «зависит». Семантика его настолько низкоуровнева, да к тому же ещё и «нагружена с двух сторон» (понятие элементарной ячейки в массиве памяти + простейшее понятие идентификатора), что он ни чём не нуждается, а сам является строительным блоком для построения более сложных решений (систем). Цитата: Я согласен что иногда очистка источника связи не требуется, именно потому возникает искушение экономно обойтись указателем. Но это как с goto. Проблемы остаются чисто потому что иногда их ведь не бывает и потому неохота их решать вообще)). с гото тоже проблем нет _иногда_. но _в общем случае_ указатель все-же не может полноценно заменить таблицу. И когда этот факт медленно доползет до мозга, как и то что указатели таки иногда полезны как низкоуровневое системное средство для работы с написанной на Си системой, разработчику остается только добавить сборщик мусора. Просто больше выхода у него нет. Поэтому все _универсальные_ процедурные системы с указателями - _требуют_ сборщика мусора. Все эти рассуждения верны до тех пор, пока у вас в задаче не удаётся получить решения, где нет динамики в работе со структурами данных. Простой пример: «обыкновенный» бортовой самописец. Нужна ли там СУБД? В принципе – есть соблазн «встроить». Но вот беда – НИ ОДНА ИЗ СУЩЕСТВУЮЩИХ СУБД не может обеспечить нормальную работоспособность при записи параметров полёта, при ЗАДАННЫХ ПАРАМЕТРАХ «реального времени». А те (нормальные, привычные, «простые», «безреляционные») алгоритмы, что разработаны – совершенно не нуждаются в динамическом выделении/освобождении памяти... Да там у меня и понятие «указатель» существует «опосредованно», через переменные статически объявленных массивов и записей... Городить там «реляционность»... - зачем? Да, на уровне проекта, модели, что-то такое я рисовал с кубиками и стрелочками между ними. Но, продвигаясь по решению задачи, я нашёл простой и адекватный способ выражения сущностей моей предметной области, отношений между ними и операций над(между) ними, помогающими успешно «втиснуть» проект в жёсткие временные и пространственные рамки к моей системе. Использование «полного» отображения «реляционной» модели на какой-либо тулз аля СУБД – стало бы НЕ оптимальным решением, с огромным перерасходом вычислительных и «памятийных» ресурсов... Понимаете, CheshireCat, программирование (до сих пор, как это не удивительно, представьте!) иногда требует подсчёта отдельных тактов и байтов. В том числе и для того, что бы вы смогли спокойно поспать по пути из Москвы во Владивосток на высоте 10 000 м или что бы всякая сволочь сто раз подумала, прежде чем заявлять права на что-то в России. :о) Цитата: ЗЫ... Да, если есть возможность, следует использовать статические данные. Никто и не спорит. Сам всегда так делаю в мелких утилитах. Но мы то говорим про общий случай когда система обязана быть модифицируемой, динамичной. Удивительно то, что по размерам оте самые системы, в которых требуется подсчитывать такты и байты могут быть меньше в разы некоторых утилит «обычного» программиста. Но! Зачастую мозговой энергии и изобретательности, при их создании, затрачивается НА ПОРЯДКИ больше; и «внесено» в эти системы «мощности решений» не в пример больше. Про «общий случай» можно и поговорить. Обеспечение «модифицируемости» и «динамичности» - рассматриваются на фазе принятия проектных решений, при учёте ограничений предметной области и средств реализации. Если используется Оберон – одни подходы, если Си – другие. Буд-то бы те, кто работает на Си не имею своих, сложившихся во время десятилетий работы, практик?! Просто (как в моей области) ТРАДИЦИОННО в понятие «модифицируемости» и «динамичности» вкладывается свой смысл. Этот «смысл» может и не быть похожим 1-в-1 на обероновский, но, поверьте мне никто и нигде не стремится «осложнить себе жизнь» и делать «лишние движения». Си не поддерживает модульности синтаксически, но есть приёмы и подходы, позволяющие разбить систему на относительно «ярковыраженные» обособленные части. Пока, «на лету» код менять в бортовых системах не пытался. Но вот появился загрузчик ELF-модулей (exe или dll) в Контики – будем и его пользовать – посмотрим, что такого нового мы можем «выкатить», что бы не возить приборы и оборудование на аэродромы и на полигоны, или их «железо» – через пол-мира – к нам... :о) Цитата: Непонял почему это у меня гото самодостаточен? Ерунда какая. Он же тоже однонаправлен и черезчур низкоуровнев, он _не может ничего выразить в одиночку сам по себе_ и потому не подходит на роль элемента языка. Вот дейкстровские - могут выразить сами кое-что. Самодостаточны. Видимо Вы играете словами, зачем-то подсовываете математическую и философскую самодостаточность вместо инженерной. Я не играю словами. Для «работы» goto ничего кроме метки (адреса, ссылки, «якоря») НЕ НУЖНО. НИКАКОЙ ДОПОЛНИТЕЛЬНОЙ СИНТАКСИЧЕСКОЙ ИЛИ СЕМАНТИЧЕСКОЙ «ОБВЕСКИ». Для работы дейкстровских примитивов, вам нужно обеспечить выполнение «предусловий» и «инвариантов». Кроме того (в зависимости от ЯП), вам нужно обеспечить больше мест «правильности оформления» этих синтаксических конструкций. Собственно (что не очевидно для многих, даже после десятилетий программирования :о) ) и само разбиение на несколько похожих, но «разных» итеративных конструкций как раз и служит для более чёткого, «явного» закрепления разности смыслов участков вашего кода разной семантики. Goto более «прост», более «общ», более «опасен». Но это (как и в случае с командами risc-машин, по сравнению с cisc-машинами) позволяет КОМБИНИРОВАТЬ из них более подходящие для данной задачи (оптимальные) последовательности операций. Большая свобода выбора. Меньшая «смысловая нагрузка» - большая «допустимая комбинаторность». Но здесь же – и опасность «более высокой семантической» перенагрузки (как в путанице иных производительных, но совершенно запутанных ФОРТРАН-программ) :о) В конце концов, именно на комбинации goto строятся дейкстровские примитивы... :о) Для выражения более «высокоуровневой», но ограниченной семантики. Кстати, мне не понятно противопоставление математики и философии инженерии! Программист без математики – просто кодер, даже – не инженер! Программист, который не интересуется, хотя бы изредка, философскими вопросами, – не просто кодер, а – просто непонятно что... «кодеротёс», что ли? :о) Ведь надо ж относиться к своему труду не просто как к «тасканию камней», надо ж, хоть и иногда, и «Храм строить»... :о) |
Автор: | Geniepro [ Понедельник, 24 Сентябрь, 2007 23:19 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
Цитата: Цитата: Вам просто _кажется_ что КА - не оправдано. Что те добавления которые делались – более оправданы чем _одно_ добавление - КА, которое их большую часть заменит... ладно, поживем - увидим... или - не увидим)) Нет. Я категорически против введения КА В ЯЗЫК! Я – за введение в язык СРЕДСТВ, которые помогают строить новый язык на базе имеющегося для поддержки той или иной парадигмы или идеологии (вплоть до смены синтаксиса) |
Автор: | Wlad [ Вторник, 25 Сентябрь, 2007 21:17 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
Geniepro писал(а): Насколько я понимаю, цикл WHILE, обобщённый в Обероне-07 Виртом до цикла Дейкстры, как раз можно удобно использовать для реализации конечных автоматов? Или я ошибаюсь? Описания ещё не видел... У вас есть? - дайте ссылку... |
Автор: | Geniepro [ Вторник, 25 Сентябрь, 2007 23:47 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
Описания Оберона-07 у меня тоже нет, но цикл Дейкстры описан во многих книгах... |
Автор: | Борис Рюмшин [ Среда, 26 Сентябрь, 2007 00:54 ] |
Заголовок сообщения: | Re: Свежий язык программирования :) |
Владимир Лось писал(а): Geniepro писал(а): Насколько я понимаю, цикл WHILE, обобщённый в Обероне-07 Виртом до цикла Дейкстры, как раз можно удобно использовать для реализации конечных автоматов? Или я ошибаюсь? Описания ещё не видел... У вас есть? - дайте ссылку... Вся доступная информация пока только здесь: viewtopic.php?f=30&t=615 |
Страница 2 из 4 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |