Здравствуйте, AVC, Вы писали:
AVK>>Отсутсвие фактов не может быть доказательством чего бы то ни было.
AVC>Повторю мысль, что отсутствие фактов — тоже факт.
Можешь сколь угодно ее повторять, правдой от этого она не станет.
AVC>>>У Конан Дойла Шерлок Холмс раскрывает преступление, опираясь как раз на тот факт, что собака не лаяла. AVC>>>
AVK>>А Иван-дурак на печи ездил.
AVC>Вот ты все шутишь.
По иному на подобное реагировать невозможно. Когда за доказательства выдаются художественные произведения или поговорки, это говорит о полном отсутствии нормальных аргументов.
AVC>>>А безопасные и небезопасные языки — просто близнецы-братья, да? AVK>>В какой то мере да.
AVC>Вот мы с тобой и расходимся в том, в какой именно мере.
И что? От этого ты сразу становишься прав?
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, AVC, Вы писали:
AVC>Много чего от Оберона. AVC>В Обероне еще в начале 1990-х был встроенный веб-браузер с поддержкой апплетов (насколько я слышал, он днмонстрировался на JMLC тех лет).
И код этого браузера был утырен в Java?
AVC>Разработанная Францем в рамках технологии OMI (Oberon Module Interchange) "кодогенерация на лету" (ставшая темой его диссертации; на эту же тему он читал лекции в Sun;
Тебе уже сказали — аргументация в стиле после этого, значит вследствие этого есть чистейшей воды демагогия.
AVC> а в качестве спасибо — полное отсутствие прямых ссылок на Оберон со стороны создателей Явы) стала теоретической основой JIT-, AOC- и DAC-компиляторов Явы.
Доказательства в студию.
AVC>Известно,
Кому известно?
AVC> что виртовские компиляторы Модулы-2 и Оберона тщательно изучались в Sun (об этом и Вирт говорил;
Вирт в Sun работал? Ссылки на точные цитаты Вирта в студию.
AVC> возможно, он и консультации давал, старый добрый дедушка-профессор) и повлияли на компиляторы Явы:
А возможно и нет.
AVC>Так что насчет "потырили код" ты, наверное, где-то прав.
Я этого не утверждал.
AVC>Но дело не в том, что что-то заимствовали, а в том, что скрыли источник заимствований.
Для начала надо доказать, что код был заимствован.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, Дарней, Вы писали:
AVK>>Тебе сказать, где yacc найти?
Д>ты хочешь сказать, что yacc — чистый КА безо всяких надстроек?
Не просто КА, ДКА. Другое дело что реальные парсеры конечно почти никогда вчистую в LR(1) не укладываются.
Если же говорить о просто КА, то в его рамки укладывается абсолютно любой детерминированный алгоритм. Доказать просто — машина Тьюринга реализуется без проблем ввиде КА.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
AndrewVK wrote: > Доказать просто — машина Тьюринга реализуется без проблем ввиде КА.
Какой конечный автомат будет соответствовать вот такой программе:
for(int f=0;;++f)
printf("%d\n",f);
?
(для чистой МТ печать заменяем добавлением строки на ленту)
Здравствуйте, AndrewVK, Вы писали:
AVC>>Известно,
AVK>Кому известно?
AVC>> что виртовские компиляторы Модулы-2 и Оберона тщательно изучались в Sun (об этом и Вирт говорил;
AVK>Вирт в Sun работал? Ссылки на точные цитаты Вирта в студию.
Вот что пишут по указанной мной сылке:
in Prof. Wirth's festschrift "The School of Niklaus Wirth — The Art of
Simplicity" there is an essay by Robert Griesemer and Srdjan Mirovic of Sun Microsystems called "A Compiler for the Java HotSpot Virtual
Machine". The abstract includes the following "Its code generator was
strongly influenced by the design of Niklaus Wirth's Modula-2 and
Oberon compilers" and goes on to mention that the compiler is part of
the standard Java 2 RTE. There is more along the same lines in the
paper.
Ясно сказано, что статья написана сотрудниками Sun Microsystems.
AFAIK, один из них (Robert Griesemer) бывший аспирант Вирта, защитивший в ETH диссертацию на тему "A Programming Language for Vector Computers".
Прошлой осенью Вирт приезжал в Россию (довольно надолго — был здесь больше месяца).
Во время этого пребывания он читал в разных местах лекции (в принципе, одну и ту же лекцию, с вариациями, некий прообраз "Хороших идей"
Компания Sun, как и другие, купила исходные коды. За очень недорого, кстати. Они очень серьезно исследовали этот код, я знаю это. Через семь лет после выхода ОБЕРОНА они выпустили Java. В Java заимствовано несколько идей из ОБЕРОНА, но они коррумпировали его синтаксисом языка "С". С точки зрения продавцов это был достаточно умный ход.
Один молодой человек задал вопрос о том, что Вирт думает о Java и C#, акцентируя особое внимание на то, что в них есть сборщик мусора и всё такое, и что вообще писать программы на них гораздо лучше. Он говорил на очень хорошем английском языке, так что переводчик не потребовался. Интонация вопроса была таковой, что, как я понял, задававший вопрос молодой человек был абсолютно не в курсе относительно Оберонов и Оберон-систем (видимо знал только Паскаль 1970 года) и поэтому сделал такой сильный акцент на том, что вот мол, хе-хе, в Java и C# есть сборщики мусора, прогрессивные языки-то, не то, что там какой-то допотопный Паскаль!!! Вирт попросил разрешения сначала ответить на второй вопрос — про сборщики мусора. Он сказал, что сборщики мусора — это, конечно, хорошо, и программисты о них, конечно, должны знать. Но не стоит их так вот сильно выпячивать. Дескать, что тут такого-то? Ну, обычный сборщик мусора, кого этим можно удивить? Далее ответил про Java. Вирт очень спокойно так рассказал, что создатели Java за семь лет до ее создания очень подробно изучили исходные коды Оберона и, в частности, исходные коды оберонистых сборщиков мусора они тоже очень хорошо изучили. Далее испортили (corrupted) Оберон сишным синтаксисом и обозвали получившееся словом Java. Кстати, заметил Вирт, то, что они испортили его сишным синтаксисом, был хороший маркетинговый ход с их стороны. Что касается .Net, то она появилась в результате конкуренции, и в принципе они (Java и .Net) более-менее одинаковые.
Хотя информация попала из разных мест и от разных людей, совпадение достаточно полное, чтобы сомневаться в том, что именно Вирт сказал о Java.
Обращаю внимание на то, что в обоих случаях это был ответ на вопрос из зала.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Left2, Вы писали:
АХ>>С другой стороны, если вы работаете с Windows постоянно приходится обновлять дорогое ПО и Железо (вон чтобы Висту установить нехилая система будет нужна!), АХ>>для Linux это не обязательно, поскольку основные стандарты не меняются и многое ПО там бесплатно.
L>Извините, а что в виндоус сделано такого что она постоянно требует обновления железа? То есть, Win 98 поставленная на Celeron 333 через какое-то время потребует апгрейта до P4?
Согласен. Это натуральные инсунуации. Это новые версии ОС рассчитаны на новое железо. И потребляют они больше именно из-за этого. Так же Виста в режиме без Аэро и другой хрени мало чем отличается от W2k. И линукс образца 1997-го года потреблял ресурсов куда меньше чем образца 2006-го. Вот только Линукс 1997-го года выпуска вообще на современном железе будет вести себя весма странно. Помнится у них таогда даже такие простые вещи как объем раздела отводимый для виртуалной памяти был огрничен где-то 128 метрами. На сегодня это просто смешно.
Виста на современной машине летает как трофейный мессер. Это я говорю по собственному опыту. А на машины класса Pentium 90 она банально не рассчитана. Windows 95 же будет прекрасно работать на этом самом Pentium 90 до тех пор пока железо не загнется от времени. А на современную машину ставить Windows 95 — это маразм.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Вертер, Вы писали:
В>по своему личному наблюдению, с 1998 года доля линукса в конторах, в которых я работал не вырастала, а наоборот, немного падала...
Линукс рулит в области дешевого хостинга. Там он сильно поимел Виндовс. Ну, на десктопе он дальше пиар-акции не пошел.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Если ты хочешь, например, создать новую железку (какой-нибудь наладонник или еще чего), то ты можешь в качестве ОС взять Линукс и модифицировать ядро под специфику железа. АХ>Значительно проще чем изобретать велосипед, разрабатывая свою ОС.
Но вот практика показывает, что те же телефоны и КПК в основном работают не под Линукс. А ведь по твоей логике должно быть наоборот.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не просто КА, ДКА. Другое дело что реальные парсеры конечно почти никогда вчистую в LR(1) не укладываются.
состояние КА описывается одним-единственным числом — номером состояния. В отличие от него, парсер LR(1) должен иметь стек, без него он невозможен.
AVK>Если же говорить о просто КА, то в его рамки укладывается абсолютно любой детерминированный алгоритм. Доказать просто — машина Тьюринга реализуется без проблем ввиде КА.
Одно из очень важных свойств машины Тьюринга — это возможность не только читать, но и записывать в клетки ленты. В отличие от этого, у конечного автомата может меняться только его текущее состояние.
В общем, по основам computer science — незачет.
VladD2 wrote: > Согласен. Это натуральные инсунуации. Это новые версии ОС рассчитаны на > новое железо. И потребляют они больше именно из-за этого. Так же Виста в > режиме без Аэро и другой хрени мало чем отличается от W2k. И линукс > образца 1997-го года потреблял ресурсов куда меньше чем образца 2006-го.
Неправда. Линукс образца 2006 года можно сконфигурировать для работы на
машинах 1997 года — энтузиасты его на чистый 386 спортировали.
> Вот только Линукс 1997-го года выпуска вообще на современном железе > будет вести себя весма странно. Помнится у них таогда даже такие простые > вещи как объем раздела отводимый для виртуалной памяти был огрничен > где-то 128 метрами. На сегодня это просто смешно.
В 97 году этого уже не было.
Здравствуйте, AVC, Вы писали:
AVC>Я здесь немного не понял.
Да ты ту вобще ничего не понял. AVC>Любой регулярный язык может быть выражен с помощью EBNF.
А кто спорит? Я говорю о том что EBNF тут нафиг не упал. AVC>Если же в языке есть рекурсия (он не регулярный), то как обойтись без стека?
А зачем тебе нужна рекурсия? Что-то я не знаю ни одного рекурсивного протокола общения. А в подавляющем большинстве случаев все банально сводится к запрос/ответ. AVC>Вообще, почему ты так раскритиковал EBNF?
По тому что контроль EBNF в общем случае реализовать очень накладно. Я некоторое время назад возился с Адаптированный алгоритм Эрли — описание
посмотри во что вылевается EBNF в общем случае...
Те на практике будет реализованно некое подмножество типа LL(1). AVC>Ведь EBNF — это расширенная BNF, т.е. EBNF = BNF + циклы + опции. AVC>Т.е. EBNF, по идее, как минимум не уступает по мощности BNF. AVC>Приверженность Вирта к языкам программирования с LL(1)-грамматикамми (чтобы код был читабельным) никак не связана с мощностью EBNF.
LL(1) к читабельности не имеет ну никакого отношения.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>ИМХО ты путаешь описание и реализацию. LR(1) грамматики, к примеру, вполне себе реализуются при помощи ДКА, но описываются все же тем же EBNF. AVK>Андрей Михалыч, как мне кажется, имел ввиду немножко иное — инструментарий для преобразования EBNF в что либо конечное не такой уж и простой, на него придется потратить усилия. При том что в его конкретном случае задача всей мощи EBNF не требует, и можно обойтись простым декларативным язычком, который можно обработать либо каким нибудь несложным тулзом типа CoCo/R или даже XSLT.
Нет Андрей Владимирович я считаю что для описания протоколов вобще EBNF нафиг не упал. А EBNF в общем случае это ахренительная задачка... Алгоритм Эрли жрет просто невообразимое колличество ресурсов.
А что касается преобразованием некоторого декларативного язычка то я использую другую мегатулзу nemerle называется. Получается намного проще чем всякие коки и тем болие XSLT.
Скажем в случае с nemerle нет проблем с заглядыванием на несколько токенов вперед ибо pattern-matching с сахаром для списков рулит.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, eao197, Вы писали:
WH>>Если я правильно понял то что написано в твоей статье сообщения отсылаются не в канал, а агенту? E>Это внутри одного процесса. E>Если же организуется распределенное приложение из нескольких процессов, то все они должны быть соеденены коммуникационными каналами.
Дело в том что я вобще не хочу знать насколько далеко расположен процесс с которым идет общение.
Те в коде общение с процессом в соседнем фибере и с процессом расположенным на другом конце света должно быть одинаковым.
E>Если процесс завершается корректно и корректно закрывает свои каналы, то удаленная сторона это сразу же обнаруживает и считает канал закрытым, о чем SObjectizer информирует прикладной код посредством сообщения msg_client_disconnected.
У тебя завершается процесс ОС так? А мне процессы ОС по крайней мере таких как винда и линух создавать и убивать ооооооочень накладно.
Вот по этому я делаю "зеление процессы" (по аналогии с green thread) таких чтобы можно было плодить и убивать тысячами.
Еще у меня есть задача максимально упростить прикладной код. Те когда процесс понимает что дальше работать не имеет смысла он должени иметь возможность просто застрелися например выбросив исключение из глубины в несколько вызовов и все. Его партнеры висящие на канале который неожиданно закрывается получают что-то типа ChannelClosedException и тоже застреливаются возможно выполнив некую дополнительную работу типа отката транзакции.
Таким образом получается каскадное завершение процессов. Если они конечно не расчитывают на то что канал будет закрыт.
E>Однако, при использовании SOP требуется, чтобы поток дробился на одельные сообщения на прикладном уровне, поскольку SObjectizer сначала закачивает все сообщение в память и только потом доставляет его обрабатывающему агенту. Поэтому, если весь поток будет представлен одим сообщением, то сам понимаешь. А вот если поток разбивается на серию сообщений, то каждое сообщение может обрабатываться по мере поступления.
А мне очень часто нужно потоки передавать... я не хочу заморачиватся этим в прикладном коде.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Неумелый переход на личности поскипан.
AVC>Что касается других тезисов WolfHound-а (а они сводятся к тому, что активные объекты — это плохо), то, ИМХО, они того же типа, что и мысль про EBNF. AVC>Возможность в Активном Обероне и Зонноне работать с активными объектами — это дополнительная (и очень хорошая) возможность, как и циклы в EBNF.
Хоть бы попытался понять о чем я говорю...
Еще раз активные объекты плохоя идея не по тому что они есть в Виртовских языках, а просто по тому что это плохая идея.
Ну нельзя вешать протокол общения на объект. Ну не работет это если объекту нужно общатся с несколькими клиентами. Не работает просто по тому что работать не может ибо состояние одно на всех. Особенно весело это становится если разным клиентам нужны разные протоколы.
Также это плохая идея по тому что все плавает в одном объектном пространстве. И эффективно оно может работать только на одном процессоре (хотя множество изолированных объектных пространств всеравно будут работать лучше ибо ГЦ можно запускать по очереди для каждого из них и сканировать ему нужно меньше). Если появляется второй то мы получаем огромные штрафы при вызове мусорщика ибо встают сразу ВСЕ потоки и ВСЕ процессоры в то время как можно тормознуть только один (а то и тормознуть частично вытясная ГЦ убирающий один процесс болие приоритетным процессом). А в случае кластера (про болие распределенную систему я вобще молчу) один ГЦ на всех просто не работает.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
AVC>>Если же в языке есть рекурсия (он не регулярный), то как обойтись без стека? WH>А зачем тебе нужна рекурсия? Что-то я не знаю ни одного рекурсивного протокола общения. А в подавляющем большинстве случаев все банально сводится к запрос/ответ.
Вопрос: в большинстве случаев или всегда?
AVC>>Вообще, почему ты так раскритиковал EBNF? WH>По тому что контроль EBNF в общем случае реализовать очень накладно. Я некоторое время назад возился с Адаптированный алгоритм Эрли — описание
посмотри во что вылевается EBNF в общем случае... WH>Те на практике будет реализованно некое подмножество типа LL(1).
А какая альтернатива у EBNF в данном случае?
AVC>>Приверженность Вирта к языкам программирования с LL(1)-грамматикамми (чтобы код был читабельным) никак не связана с мощностью EBNF. WH>LL(1) к читабельности не имеет ну никакого отношения.
Мне показалось, что буквально несколькими строчками ранее ты обосновывал, что с помощью EBNF только LL(1) можно разобрать эффективно.
Это не читабельность?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, WolfHound, Вы писали:
E>>Если же организуется распределенное приложение из нескольких процессов, то все они должны быть соеденены коммуникационными каналами. WH>Дело в том что я вобще не хочу знать насколько далеко расположен процесс с которым идет общение. WH>Те в коде общение с процессом в соседнем фибере и с процессом расположенным на другом конце света должно быть одинаковым.
Оно совершенно спокойно делается одинаковым, поскольку для каждого сообщения в системе сохраняется информация о канале, из которого оно получено (имя этого канала доступно через event_data_t::channel()). Если же сообщение было сгенерированно в том же процессе, то event_data_t::channel() будет возвращать специальное значение -- localhost. Если затем это значение передается как идентификатор канала в send_msg, то send_msg понимает, что сообщение не должно уходить за рамки процесса. Поэтому, если обработка сообщения выглядит как-то так:
void
some_agent::evt_request(
const so_4::rt::event_data_t & event_data,
const msg_request & cmd )
{
// Обработка...
// Отсылка ответа.
so_4::api::send_msg(
// Отправляем ответ в точности тому, кто прислал запрос.
event_data.channel(),
global_agent_name,
"msg_response", ... );
}
Совершенно прозрачная схема работы.
E>>Если процесс завершается корректно и корректно закрывает свои каналы, то удаленная сторона это сразу же обнаруживает и считает канал закрытым, о чем SObjectizer информирует прикладной код посредством сообщения msg_client_disconnected. WH>У тебя завершается процесс ОС так? А мне процессы ОС по крайней мере таких как винда и линух создавать и убивать ооооооочень накладно.
Ну ты же сам сначала сказал про мелкие процессы. Процессы -- это вполне конкретное понятие (если только речь идет не об Erlang-е). Тоже о чем ты говоришь ниже -- это потоки внутри одного процесса.
Кстати, у тебя есть конкретые замеры накладных расходов на создание процессов в Linux-е?
WH>Вот по этому я делаю "зеление процессы" (по аналогии с green thread) таких чтобы можно было плодить и убивать тысячами.
В этом случае в SObjectizer вообще не нужно процессы плодить -- достаточно насоздавать столько агентов, сколько нужно. Хоть сотни тысяч.
E>>Однако, при использовании SOP требуется, чтобы поток дробился на одельные сообщения на прикладном уровне, поскольку SObjectizer сначала закачивает все сообщение в память и только потом доставляет его обрабатывающему агенту. Поэтому, если весь поток будет представлен одим сообщением, то сам понимаешь. А вот если поток разбивается на серию сообщений, то каждое сообщение может обрабатываться по мере поступления. WH>А мне очень часто нужно потоки передавать... я не хочу заморачиватся этим в прикладном коде.
Интересно, а какие готовые прикладные протоколы такое ввобще из коробки позволяют поддерживать?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AVC, Вы писали:
WH>>А зачем тебе нужна рекурсия? Что-то я не знаю ни одного рекурсивного протокола общения. А в подавляющем большинстве случаев все банально сводится к запрос/ответ. AVC>Вопрос: в большинстве случаев или всегда?
Приведи хоть один реальный протокол в котором есть рекурсия.
AVC>А какая альтернатива у EBNF в данном случае?
В данном случае он не нужен.
Кстати на твой EBNF я могу сказать что контекстно свободных грамматик мне не хватает и мне нужны контекстно зависимые... А это совсем тушите свет.
AVC>Мне показалось, что буквально несколькими строчками ранее ты обосновывал, что с помощью EBNF только LL(1) можно разобрать эффективно. AVC>Это не читабельность?
Чего обосновывал? Ты не путай эффективную реализацию для машины и читабельность для человека. Это совершенно разные вещи. И одно от другого никак не зависит.
Взять теже регулярные выриажения... ну совершенно не читаемая штука но компом парсится на раз, а C# человеком читается легко но компу его разобрать не просто. А языки с выводом типов типа немерле для компа вобще задачка на гране возможного но вот человеком они читаются очень легко.
Так что не нужно из раза в раз повторять эту Виртувскую глупость что читабельность LL(1) грамматик лучше чем у грамматик которые в LL(1) не укладываются.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Дарней, Вы писали:
Д>состояние КА описывается одним-единственным числом — номером состояния. В отличие от него, парсер LR(1) должен иметь стек, без него он невозможен.
Конечный автомат (в теории алгоритмов) — математическая абстракция, позволяющая описывать пути изменения состояния объекта в зависимости от его текущего состояния и входных данных, при условии что общее возможное количество состояний конечно.
Вот, собственно и все ограничение — количество состояний конечно. А уж что из себя это состояние представляет — не суть важно. Поскольку стек на любой реальной машине конечен, то и его использование совсем не означает, что это не КА.
