Здравствуйте, grosborn, Вы писали:
G>Вообще-то на уровне школы это было бы нормально преподавать. Так сказать для базового уровня понимания. Однозначно лучше чем блок-схемы, даст понимание декомпозиции, раз уж это в драконе идея фикс. Ну и псевдоакадемические бездари в школе как бэ пусть себе будут, не страшно
Нет-нет-нет.
Как раз это прекрасный способ привить отвращение к программированию. Нас на первом курсе как-то заставляли рисовать диаграммы кода по ГОСТу, когда несколько строк кода превращаются в несколько страниц A4 с диаграммами. От этого плевались буквально все.
Sapienti sat!
Re[12]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, vdimas, Вы писали:
C>>А так вижу, что этот ДРАКОН используется очередными псевдоакадемическими бездарями чтобы мучать студентов. V>Почему мучать? Свою первую более-менее сложную программу я расписал на 3-х листах в блок-схемах когда-то. И она сразу заработала. П\росто у меня не было достаточно машинного времени на тот момент, чтобы позволить себе ее отладку часами...
Сочуствую. Тяжело жилось в каменном веке, с деревянными компьютерами прибитыми к полу.
Но сейчас ситуация немного другая.
V>Да и сейчас, если чувствую нутром во время ревью чужого кода, что "здесь что-то не то", беру блокнот и рисую квадратики и стрелочки и сразу вижу это "не то" или
что напрасно сомневался.
Прекрасно. А теперь то же самое попробуй на формальном ДРАКОНе.
Sapienti sat!
Re[11]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, vdimas, Вы писали:
V>Это ты себя, любимого, выгородить решил. Те, кто не в состоянии понимать блок-схемы, вообще на технические специальности не годятся по складу ума. Как тебе юз-кейз дадут читать, если ты его прочесть не сумеешь? Получается, над тобой нужен старший смотрящий, который разжует и в рот положит.
Замечательно. Итого делаем вывод, что программирование — это чисто женская профессия. Ибо у мужчин просто нет необходимого склада ума для этого дело — они хуже понимают блок-схемы. Увольняем всех мужчин нахрен, оставляем 1% женщин — и вперед, наконец поднимем ИТ до нужного уровня.
Юз кейсы всю жизнь пишутся и писались текстом! Из графического — только дизайн. Конечные автоматы, если они есть, задаются просто табличками. По крайней мере сколько не видел буржуйские спеки, никаких диаграмм там не было. Графические юз кейсы я первый и последний раз видел в институте, когда надо мной UMLом измывались и заставляли из этих диаграмок код генерить. В православных конторах, где все по ГОСТу, работать к счастью не доводилось. Рисование юзкейсов диаграмками — это напрасная трата времени и денег. Я конечно понимаю, что в Севастополе процесс разработки на порядок выше поставлен, чем в Москве, да и ИТ там гораздо сильнее развито, и зарплаты там наверно тысяч под 500 у джуниоров, но как то пока севастопольские работодатели не оказывали мне чести у них поработать.
Re[21]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, vdimas, Вы писали:
V>Блин, ну ты даааал...
Это ты в очередной раз дал.
1)В каком месте это дракон?
2)Засунуть слова в прямоугольники и заменить операторы на стрелочки много ума не надо.
И эта махинация ухудшила восприятие.
Например, чтобы понять, что else-if может повторяться 0 или более раз нужно распутывать клубок стрелок.
V>Как это SQL не ложится, если есть мильон существующих тулзов графического редактирования SQL?
На основе дракона?
V>Например, IBM, вроде бы известная тебе контора, НЕ использует BNF/EBNF в своей документации, а использует графический аналог EBNF:
Да плевать мне на IBM.
V>http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.gsg.doc/gsg15.htm
Феерический ужОс.
V>Ну и я уже давным давно предлагал тебе скачать хотя бы два-три десятка тулзов для разработки компиляторов... просто посмотреть, где сейчас народ находится, а то вы малость застряли на сравнении с бизоном из 80-х... Во многих тулзах идет такое же или похожее редактирование синтаксических диаграмм.
Ты даже не понял, какие у меня претензии к бизонам.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, elmal, Вы писали:
V>>Почему бы тебе не скачать среду и не построить эту блок-схему самому, в кач-ве небольшой разминки? E>Даже нашел реализацию сам: E>http://upload.wikimedia.org/wikipedia/commons/f/fd/Quicksort_in_DRAKON-Python.png E>Куча состояний, внимание расфокусировано, рекурсию хрен заметишь. E>Лично я никакого ускорения понимания не заметил. По сравнению с нормальной реализацией:
Вы совершенно правы, на простых алгоритмах дракон не дает выигрыша.
Но в сложных случаях дело обстоит иначе.
Давайте рассмотрим сложный случай, например, проектирование атомного реактора (на драконе).
Сейчас я дам ссылку. Но перед этим пояснения:
1. Прочитайте раздел ВИЗУАЛИЗАЦИЯ МЕТОДОЛОГИЙ (стр. 201-212).
2. Это старая книга (2001 год). Я давно отказался от термина "методология",
который я использовал под дурным влиянием Джеймса Мартина.
3. Таким образом, название следует читать ВИЗУАЛИЗАЦИЯ АЛГОРИТМОВ.
4. Я отказался также от термина "алгоритм-концепция". Следует читать "алгоритм".
5. Но это мелочи. Главное в том, что в данном примере (атомный реактор) не следует употреблять термин "состояние".
Никаких состояний там нет. Это не конечный автомат. То, что на первый взгляд, кажется состоянием, это СТРУКТУРНЫЙ ЭЛЕМЕНТ алгоритма. http://www.e-reading.org.ua/bookreader.php/135509/Kak_uluchshit'_rabotu_uma.pdf
С уважением В. Паронджанов
Re[11]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Вы совершенно правы, на простых алгоритмах дракон не дает выигрыша. ВП>Но в сложных случаях дело обстоит иначе.
Так, уже достало враньё слушать.
Пример сложного алгоритма в студию, хотя бы аналог 10000 строк кода. Иначе всё про ДРАКОН считаем банальным враньём и фрикачеством.
У ваших оппонентов (WolfHound, к примеру) есть действительно интересные разработки, которые подкреплены заметным объёмом кода. Я несогласен с их идеями, но воспринимаю их вполне серьёзно. Возможно, что это я ошибаюсь, а не они.
А ваши поделки не тянут даже на это. В общем, "Code talks bullshit walks" (c) Linus Torvalds.
Sapienti sat!
Re[21]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, vdimas, Вы писали:
V>Например, IBM, вроде бы известная тебе контора, НЕ использует BNF/EBNF в своей документации, а использует графический аналог EBNF: V>http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.gsg.doc/gsg15.htm V>Похоже, ты ни разу в жизни не читал их документаций...
Замечательно, что сам привел пример IBM. Прочитай отзывы об их продуктах. Например по поводу Lotus Notes. Прочитай отзывы программистов, которые там работают. Могу сам даже написать про их мегабиблиотеку связи, которая плодит по потоку на каждое обращение, а в интерфейсах не предусмотрено даже метода закрыть соединение. Или про приколы, когда дергаешь метод получения данных, в результате удаленный сервер, на котором работает куча пользователей, перезагружается. Слишком часто будешь забирать данные — тоже часто перезагружается. Замечательная система, как так можно писать, я не представляю. Эта IBM такими темпами скоро загнется. Ибо работать на них, это настоящий ад. Там такая бюрократия, что любой НИИ советских времен сказкой покажется. Я один раз к ним чуть не попал на проект. А потом со мной работал коллега, который имел счастье к ним попасть. Ему потом очень страшный адский проект сказкой казался, он такое рассказывал, что волосы дыбом вставали.
Так вот, IBM — это пример того, как не надо делать продукты.
Re[12]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, elmal, Вы писали:
V>>Это ты себя, любимого, выгородить решил. Те, кто не в состоянии понимать блок-схемы, вообще на технические специальности не годятся по складу ума. Как тебе юз-кейз дадут читать, если ты его прочесть не сумеешь? Получается, над тобой нужен старший смотрящий, который разжует и в рот положит. E>Замечательно. Итого делаем вывод, что программирование — это чисто женская профессия. Ибо у мужчин просто нет необходимого склада ума для этого дело — они хуже понимают блок-схемы.
Ты опять сел в лужу. Всё ровно наоборот: мужчины понимают карты и схемы многократно лучше женщин, но женщинам лучше даются длинные последовательности рассуждений. И естественные языки, поэтому. И перестань, наконец, бесконечно тараторить. ))
E>Юз кейсы всю жизнь пишутся и писались текстом! Из графического — только дизайн. Конечные автоматы, если они есть, задаются просто табличками. По крайней мере сколько не видел буржуйские спеки, никаких диаграмм там не было.
Значит, ты не видел ещё ничего или тебе просто не показывали, зная бесполезность для тебя лично.
Re[11]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>5. Но это мелочи. Главное в том, что в данном примере (атомный реактор) не следует употреблять термин "состояние". ВП>Никаких состояний там нет. Это не конечный автомат. То, что на первый взгляд, кажется состоянием, это СТРУКТУРНЫЙ ЭЛЕМЕНТ алгоритма. ВП>http://www.e-reading.org.ua/bookreader.php/135509/Kak_uluchshit'_rabotu_uma.pdf
Итого, для реактора ок, предположим что язык подходит лучше, чем конкуренты. Если мне нужно будет делать документацию — ок, возможно когда нибудь попробую. Но на том примере перечислена не полная программа, там только верхушка айсберга, служащая для иллюстрации. Я в курсе, что можно продолжать спускаться и постепенно увеличивать детализацию. Я даже готов признать, что для управления реактором оптимально сначала нарисовать высокоуровневый алгоритм, тщательно его проверить, а далее на его основе сгенерить текст.
А теперь перечисляю но:
1) Реакторы, космические корабли, сложное медицинское оборудование вроде томографов — это весьма узкая область. В этой области до сих пор царит царство waterfall methodology, сначала полная и подробная документация, затем реализация, требования не меняются. И скорее всего так и будет водопад царствовать в этой области, так как для своих задач он вполне подходит;
2) В современном мире в 99% случаев правят AGILE методологии, требования меняются постоянно, сделать нужно быстро, на документирование нет времени, ибо неизвестно, нужна новая фича или нет. Ты делаешь фичу, тебе говорят молодец, но мы передумали;
3) Итого, я готов допустить, что для waterfall методологии дракон довольно хорошо подходит (правда там пилить еще и пилить его нужно). У вас большой опыт в этом — я даже спорить не буду, ибо именно в waterfall некомпетентен. Но я могу сказать точно, что подход — сначала рисуем, а потом генерим, в современных Agile методологиях полностью не применим. Ибо тут уже у меня хороший опыт, и здесь я вполне компетентен.
4) На этом форуме найдется крайне мало людей, использующих водопад, и работающих в областях, где он применим. Соответственно именно в этом форуме вряд ли у вас будет большая поддержка. А вот критики будет очень и очень много, ибо все будут рассматривать язык применительно к своим задачам и своему весьма немалому опыту работы по другим методологиям.
Re[22]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, WolfHound, Вы писали:
V>>Блин, ну ты даааал... WH>Это ты в очередной раз дал. WH>1)В каком месте это дракон?
В таком, что здесь походя утверждают о неприменимости графического представления как такового. Дык, остыньте малость на фактах.
WH>2)Засунуть слова в прямоугольники и заменить операторы на стрелочки много ума не надо.
Это спор с самим собой?
WH>И эта махинация ухудшила восприятие.
Эта "махинация" позволяет составлять запросы даже тем, кто плохо владеет языком SQL или только начинает его изучать. Я наблюдал как девочки оперативно накидывали в MS Access полезные запросы в графике буквально на 2-3-й день его изучения, не зная языка SQL. И видел, как они постепенно изучали тем самым этот SQL до приемлимого уровня, видя во что именно преобразуется графическое представление.
WH>Например, чтобы понять, что else-if может повторяться 0 или более раз нужно распутывать клубок стрелок.
Это в любом случае надо понять, даже в виде БНФ или любой другой нотации.
V>>Как это SQL не ложится, если есть мильон существующих тулзов графического редактирования SQL? WH>На основе дракона?
Ну и ок. Т.е. мы согласны обсуждать только Немерле, а на остальное плевать. На том и порешим.
V>>Ну и я уже давным давно предлагал тебе скачать хотя бы два-три десятка тулзов для разработки компиляторов... просто посмотреть, где сейчас народ находится, а то вы малость застряли на сравнении с бизоном из 80-х... Во многих тулзах идет такое же или похожее редактирование синтаксических диаграмм. WH> Ты даже не понял, какие у меня претензии к бизонам.
Да пообщался я с вами в той фейерической ветке про БНФ. Поржал, спасибо. Редкостная каша в голове.
Re[22]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, elmal, Вы писали:
E>Я один раз к ним чуть не попал на проект. А потом со мной работал коллега, который имел счастье к ним попасть. Ему потом очень страшный адский проект сказкой казался, он такое рассказывал, что волосы дыбом вставали. E>Так вот, IBM — это пример того, как не надо делать продукты.
Здравствуйте, elmal, Вы писали:
E>4) На этом форуме найдется крайне мало людей, использующих водопад, и работающих в областях, где он применим.
Боже, сколько нубства... Водопад ВСЕГДА применим, когда идет реализация заведомо известных требований (спецификаций, протокола, и т.д. и т.п.). В этих условиях ему нет равных. И опять же — водопад не отменяет RUP, то бишь итеративный характер разработки. Это просто движение вектора декомпозиции сложности и ничего более.
Re[13]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, vdimas, Вы писали:
V>Ты опять сел в лужу. Всё ровно наоборот: мужчины понимают карты и схемы многократно лучше женщин, но женщинам лучше даются длинные последовательности рассуждений. И естественные языки, поэтому. И перестань, наконец, бесконечно тараторить. ))
Я опираюсь вот на это
.
V>Значит, ты не видел ещё ничего или тебе просто не показывали, зная бесполезность для тебя лично.
Я говорю еще раз — в православных конторах я не работал! И куда мне до великих специалистов исключительно по императивному программированию. Не сомневаюсь, что в конторах, где царит ГОСТ, исключительно императивный подход, а также многое другое тяжелое наследие прежних времен, мне не заплатят даже 5000 рублей в месяц.
Re[12]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Cyberax, Вы писали:
C>Дело в том, что ДРАКОН — это не язык разработки use-case'ов и для описания формальных требований он тоже не очень подходит.
Use-case тоже описывают лишь крохи формальных требований. Но на драконе можно описать юз-кейзы. Я сильно его не смотрел, но даже на что посмотрел: "силуэт" — это полный аналог диаграмм use-case по своим выразительным возможностям. Не зря алгоритмы верхнего уровня имеют "силуэт".
В драконе есть любопытный момент, что делается серьезная попытка устаканить некую экологию графической нотации... Бо тот же UML никак эти вещи не определяет, и я видел действительно достаточно ужаса лишь потому, что у авторов юз-кейзов был плохой вкус, а хорошему научиться было банально негде.
C>Получается непонятная шизофрения — с одной стороны инжинеры должны описывать алгоритм на некотором почти-формальном языке,
Описание ПРИКЛАДНОГО алгоритма — это и есть ТЗ. И это очень хорошее ТЗ в отличие от уже ставших привычным "да ты не выё, ты рукой покажи..." и прочих монологов брата Нибэнимэда.
И язык будет или формальным или нет, "почти" — это как немножко беременный, так не бывает. В том-то и заключается второй цимус, что формальность описания означает его заведомую однозначность, в отличие от описания "своими словами" на естественном языке.
C>а с другой стороны программисты должны по этому намалёванному непотребию потом делать что-то работающее. Я прямо отсюда слышу их матюки.
Ну вон из профессии, марш на вебку, делов-то...
Кто-то же пишет реализации протоколов TCP? (Упрощенную реализацию ваш покорный слуга тоже когда-то сделал для контроллера). А там спецификаций в сумме — мама не горюй. И никто не умер...
ИМХО, формальные описания делают две полезные вещи:
— краткость самого описания; (можно пользоваться преопределенными примитивами, составляющими язык описания и его семантику)
— полнота и однозначность.
Все-таки в RFC много отcебятины, воды и что самое досадное — недоговоренностей. Надо "проникаться" и делать прочие эзотерическо-загадочные вещи. Без спецификаций оставлен целый класс ситуаций в TCP, пришлось по другим местам по крохам собирать информацию о "правилах хорошего тона" в поведении ендпоинтов, т.ч. числе через реакцию ответной части из работающей операционки. Прямо оттуда ты мог слышать мои матюги. Я бы предпочел однозначные и полные спецификации вместо этого бредового этапа разработки.
C>Т.е. я совсем не против методологии, где инжинеры описывают формальные требования, по которым потом создаётся код. Но для этого надо иметь соответствующие инструменты. И самый главный из них — старый добрый текст. Диаграммы имеют смысл, но только для: C>1) Иллюстрации общей структуры (т.е. иерархические диаграммы). C>2) Диаграммы для КА (в различных формах).
Блок схемы — это считай разновидность автомата. Просто автомат магазинный. ИМХО, для огромного класса алгоритмов магазинный удобнее конечного. Ну и магазинные включают в себя все остальные классы автоматов.
Я не хочу акцентировать конкретно на Драконе. Речь о парадигме как таковой. Тем более, что была дана ссылка где-то тут на документ с еще двумя языками — императивным и функциональном. И ес-но я считаю, что графический язык должен иметь одно или несколько отображений на какой-нить текстовый язык, т.к. самое удобное — это конечно-же двусторонее редактирование (по своему опыту). Т.е. многие операции в тексте гораздо удобнее. Но смотреть затем удобнее в графику. Отпадает надобность в блокнотиках, карандашиках и прочих мятых салфетках.
Re[14]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, vdimas, Вы писали:
V>>Ты опять сел в лужу. Всё ровно наоборот: мужчины понимают карты и схемы многократно лучше женщин, но женщинам лучше даются длинные последовательности рассуждений. И естественные языки, поэтому. И перестань, наконец, бесконечно тараторить. )) E>Я опираюсь вот на это
Ну а я опираюсь на многолетний опыт работы с женщинами и мужчинами в области разработки электроники. Различия в подходе к работе увидел довольно быстро, заинтересовался и одно время читал много материала об этих различиях, подтверждающего мои наблюдения. Например: http://www.medinfo.ru/sovety/psi/33.phtml
В восприятии мужчины главное место занимает то, что он видит. У женщины большая часть впечатлений связана с восприятием речи.
У мужчин У женщин
логика интуиция
обобщение анализ
восприятие в целом внимание к деталям
склонность к абстракциям конкретика
Тут в первй строчке немного не согласен: мужчины не понимают, что есть "интуиция". На самом деле это очень далеко зашедшая в подробностях логика. ИМХО, мужская логика проще гораздо. Еще от себя добавлю, что мужчина легко рассуждает о параллельном взаимодействии сразу нескольких алгоритмов, зато женщине проще уследить за всеми деталями одного, даже очень сложного и глубокого, что мужчинам бывает сложно, и наверно от этого — всегда скучно.
И таки способность мужчин многократно лучше воспринимать карты/схемы — это известный факт. Географический кретинизм — это вообще чисто женская фишка. (Дамы, не сочтите за шовинизм, у мужчин своих недостатков хватает).
E>Я говорю еще раз — в православных конторах я не работал! И куда мне до великих специалистов исключительно по императивному программированию. Не сомневаюсь, что в конторах, где царит ГОСТ, исключительно императивный подход, а также многое другое тяжелое наследие прежних времен, мне не заплатят даже 5000 рублей в месяц.
Самое время спросить о возрасте, но че-то нелюбопытно. Итак понятно.. ))
Re[13]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Cyberax, Вы писали:
C>Сочуствую. Тяжело жилось в каменном веке, с деревянными компьютерами прибитыми к полу.
C>Но сейчас ситуация немного другая.
Дык, сейчас всё хуже, насколько я вижу. Посади даже 15-тилетнего ребенка за комп и попроси написать аналогичную программу и засеки время. Ответ я знаю заранее.
V>>Да и сейчас, если чувствую нутром во время ревью чужого кода, что "здесь что-то не то", беру блокнот и рисую квадратики и стрелочки и сразу вижу это "не то" или C>что напрасно сомневался. C>Прекрасно. А теперь то же самое попробуй на формальном ДРАКОНе.
Дык, дело навыков. Я его потыкал — не хватает возможностей настройки горячих клавиш. А вообще с графическими тулзами я работал очень много по электронике. Повторю — дело навыков и удобства конкретной реализации редактора. Какие-то удобней, какие-то нет. Например, несмотря на убогость системы ORCAD в свое время, набивать схемы на нем было многократно удобнее, чем на PCAD, их потом из ORCAD в PCAD импортировали и дальше на нем уже доводили схему до производства.
Т.е. даже берем один графический язык — схем электрических принципиальных, и видим кучи редакторов разной степени удобства.
Re[14]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, vdimas, Вы писали:
C>>Сочуствую. Тяжело жилось в каменном веке, с деревянными компьютерами прибитыми к полу. C>>Но сейчас ситуация немного другая. V>Дык, сейчас всё хуже, насколько я вижу. Посади даже 15-тилетнего ребенка за комп и попроси написать аналогичную программу и засеки время. Ответ я знаю заранее.
В 15 лет я уже писал программы в тысячи строк кода (на С++). Первую программу я написал в 9 лет (на Бэйсике).
V>Т.е. даже берем один графический язык — схем электрических принципиальных, и видим кучи редакторов разной степени удобства.
Электрические схемы — это по своей сути графическая вещь. Но вот сложные схемы всё как-то сейчас в виде текста описывают.
Sapienti sat!
Re[14]: Язык ДРАКОН — новая идея в программировании
> Я говорю еще раз — в православных конторах я не работал! И куда мне до великих специалистов исключительно по императивному программированию. Не сомневаюсь, что в конторах, где царит ГОСТ, исключительно императивный подход, ...
Не нужно унижать императивный подход. Видишь ли, есть такая проблема, на космическую станцию нельзя послать специалиста в командировку для отладки, сбора требований, исправления бага и смены прошивки в микроконтроллере.
Posted via RSDN NNTP Server 2.1 beta
Забанен на рсдн за применение слова "Маргинал"
Re[15]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, grosborn, Вы писали:
G>Не нужно унижать императивный подход. Видишь ли, есть такая проблема, на космическую станцию нельзя послать специалиста в командировку для отладки, сбора требований, исправления бага и смены прошивки в микроконтроллере.
Так я что — спорю? Я ни грамма не унижаю. Более того, наряду с прочими подходами, я вполне использую и императивный, и ни грамма этого не стыжусь. Вот только во первых, кроме императивного, есть еще куча других подходов. Которые вполне применимы и на космической станции. Космическая индустрия уникальна тем, что там несоизмеримо выше цена ошибки. В результате там несоизмеримо выше затраты на документирование и тестирование.
Кстати про космос — занятная статья: http://c2.com/cgi/wiki?MarsSpiritSoftwareProblem
Re[23]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, vdimas, Вы писали:
WH>>1)В каком месте это дракон? V>В таком, что здесь походя утверждают о неприменимости графического представления как такового. Дык, остыньте малость на фактах.
Ты посмотри, на что ты отвечаешь.
V>Эта "махинация" позволяет составлять запросы даже тем, кто плохо владеет языком SQL
И где тут SQL?
Может хватить прыгать по темам.
Или сказать совсем нечего?
V>или только начинает его изучать. Я наблюдал как девочки оперативно накидывали в MS Access полезные запросы в графике буквально на 2-3-й день его изучения, не зная языка SQL.
А я видел девочек которые на С++ пишут лучше многих тут присутствующих.
V>И видел, как они постепенно изучали тем самым этот SQL до приемлимого уровня, видя во что именно преобразуется графическое представление.
А с чего ты взял, что за те же 2-3 дня они бы SQL не осилили?
WH>>Например, чтобы понять, что else-if может повторяться 0 или более раз нужно распутывать клубок стрелок. V>Это в любом случае надо понять, даже в виде БНФ или любой другой нотации.
Сравнил блин.
В нормальной нотации нужно запомнить всего один оператор.
Кстати как в твоей графике будет выглядеть запись того что правило нужно повторить от 5 до 10 раз?
V>Ну и ок. Т.е. мы согласны обсуждать только Немерле, а на остальное плевать. На том и порешим.
Причем тут немерле? Совсем аргументов нет?
V>Да пообщался я с вами в той фейерической ветке про БНФ. Поржал, спасибо. Редкостная каша в голове.
Сказал адепт секты, которая, не смотря на свою многочисленность, за 50 лет не смогла создать ни одного алгоритма годного для промышленного применения.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн