Оператор if — это наверное самый зловещий оператор, которым мне приходилось пользоваться. Он является основной причиной возникновения спагетти-кода и как следствие причиной сильной головной боли, когда проект развивается много лет. Только вот пока не додумал, как от него избавиться совсем. Какие варианты? или мне пора в ФП?
Re: If-statement умер. Да здравствует if-expression!
Здравствуйте, michael_isu, Вы писали:
_>Оператор if — это наверное самый зловещий оператор, которым мне приходилось пользоваться. Он является основной причиной возникновения спагетти-кода и как следствие причиной сильной головной боли, когда проект развивается много лет. Только вот пока не додумал, как от него избавиться совсем. Какие варианты? или мне пора в ФП?
Пока не додумаешь, используй условное выражение вместо условного оператора.
Здравствуйте, michael_isu, Вы писали:
_>Оператор if — это наверное самый зловещий оператор, которым мне приходилось пользоваться. Он является основной причиной возникновения спагетти-кода и как следствие причиной сильной головной боли, когда проект развивается много лет. Только вот пока не додумал, как от него избавиться совсем. Какие варианты? или мне пора в ФП?
Стратегия. Мапить условие на функцию, которая выполняется при этом условии. Но это в том случае, когда действительно все сложно. Если грамотно декомпозировать, то ничего страшного в if нет.
Здравствуйте, michael_isu, Вы писали:
_>Оператор if — это наверное самый зловещий оператор, которым мне приходилось пользоваться. Он является основной причиной возникновения спагетти-кода и как следствие причиной сильной головной боли, когда проект развивается много лет. Только вот пока не додумал, как от него избавиться совсем. Какие варианты? или мне пора в ФП?
Надо поменять парадигму программировния — надо задавать цели неким операторам, а не описывать условия.
Вот например цель — любое число из данного набора больше "А". Вот и нет ифа. Но это сейчас не возможно поменять парадигму так как всегда есть молодеж которая прется от программирования считая его искуством.
Это примерно так же как пытаться доказать что существующие ОС это ПРОСТО кошмар и прошлый век. И надо писать свою. Но где взять деньги? Кто их даст, если все считают себя самыми умными, и считают что ОСы и так самое то. А оно я про ядро, оно уже не нужно такое сложное.
Но вот ведь в чем парадокс, опять же если люди которые могут дотянуться до денег но не умеют сделать революционное решение, а другие кто может его сделать, не могут дотянуться до денег. А новую ОС как и новую парадигму программирования давно уже пора делать. Но где деньги. Я вот знаю как сделать Но деньги есть только на то что кормит.
Здравствуйте, michael_isu, Вы писали:
_>Какие варианты? или мне пора в ФП?
pattern matching? вообще есть некоторое недовольство к ифу. ну а к чему его нет? пущай живет пока, не будем его беспокоить...
Здравствуйте, michael_isu, Вы писали:
_>Оператор if — это наверное самый зловещий оператор, которым мне приходилось пользоваться. Он является основной причиной возникновения спагетти-кода и как следствие причиной сильной головной боли, когда проект развивается много лет. Только вот пока не додумал, как от него избавиться совсем. Какие варианты? или мне пора в ФП?
В моем языке события не только подписываются на на другие события (группа событий, которая у меня называется комплектом), но и имеют логическое выражение которое проверяется при срабатывании комплекта. При истиности этого выражения считается что событие произошло и запускается процедура обработки событий. Получается то, что должно происходить под If-ом просто выносится из текста программы в удобное место.. Событие имеет имя.. Ну, и все значительно упрощается. Есть еще один плюс такого решения. Если надо, например, отследить индекс на конец текста и по концу чего-то выполнить, то применяя такой метод можно не беспокоится за анализ на конец файла при его разборе и избавиться от if после каждого чтения из файла.. Событие произойдет и выполниться то, что должно.
Применяя такие события спагетти код распрямляется.. Такие проблемы называл логической сложностью.. Но не нашел здесь понимания..
Re[2]: If-statement умер. Да здравствует if-expression!
JM>Но вот ведь в чем парадокс, опять же если люди которые могут дотянуться до денег но не умеют сделать революционное решение, а другие кто может его сделать, не могут дотянуться до денег. А новую ОС как и новую парадигму программирования давно уже пора делать. Но где деньги. Я вот знаю как сделать Но деньги есть только на то что кормит.
Кто мешает написать что именно предлагаешь сделать
Здравствуйте, Just Men, Вы писали:
JM>Здравствуйте, michael_isu, Вы писали:
_>>Оператор if — это наверное самый зловещий оператор, которым мне приходилось пользоваться. Он является основной причиной возникновения спагетти-кода и как следствие причиной сильной головной боли, когда проект развивается много лет. Только вот пока не додумал, как от него избавиться совсем. Какие варианты? или мне пора в ФП?
JM>Надо поменять парадигму программировния — надо задавать цели неким операторам, а не описывать условия.
JM>Вот например цель — любое число из данного набора больше "А". Вот и нет ифа. Но это сейчас не возможно поменять парадигму так как всегда есть молодеж которая прется от программирования считая его искуством.
Забавно. Ну убрали if поглубже. Но он же никуда не делся. На уровне машинного кода условный переход все равно остался.
Чего добиваемся?
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Забавно. Ну убрали if поглубже. Но он же никуда не делся. На уровне машинного кода условный переход все равно остался. SVZ>Чего добиваемся?
Машинные коды это еще один дуругой вопрос. Давно уже пора сделать не одно АЛУ ( пусть 6 ядер ), а 20000 просто сложателей и 20000 вычитателей ну и так далее. И сделать маш команды типа как были в DEC'е
Здравствуйте, Just Men, Вы писали:
JM>Машинные коды это еще один дуругой вопрос. Давно уже пора сделать не одно АЛУ ( пусть 6 ядер ), а 20000 просто сложателей и 20000 вычитателей ну и так далее. И сделать маш команды типа как были в DEC'е
JM>MOV @r0,@r3++
JM>И отдать упавление всем кешом ( 1 2 3 ... ) ОСу.
Гм, "все уже украдено до нас" (с)
Есть CUDA — 100500 примитивных ядер, которые можно использовать как сложаторы и вычитаторы.
Много есть задач, которые решаются на CUDA? Думаю, пальцев обеих рук хватит, чтобы сосчитать.
И пока нет нормального матаппарата для распараллеливания вычислений вряд ли их станет больше.
ИМХО.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Забавно. Ну убрали if поглубже. Но он же никуда не делся. На уровне машинного кода условный переход все равно остался. SVZ>Чего добиваемся?
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Гм, "все уже украдено до нас" (с) SVZ>Есть CUDA — 100500 примитивных ядер, которые можно использовать как сложаторы и вычитаторы. SVZ>Много есть задач, которые решаются на CUDA? Думаю, пальцев обеих рук хватит, чтобы сосчитать. SVZ>И пока нет нормального матаппарата для распараллеливания вычислений вряд ли их станет больше. SVZ>ИМХО.
Знаю CUDА не плохо. Ну что сказать — это спец процессор. На нем ничего толком не сделаешь. Да и там есть свои тараканы например надо все строго (и сложно ) выравнивать. А иначе будет еще медленней чем на CPU.
Здравствуйте, michael_isu, Вы писали:
_>А можно пример?
Пример 1.2. Определение события EndText.
Dim Integer Len ' Длина текста
Dim Integer Ind] ' Индекс проверяемого символа
New Event EndText ' Создание события EndText
{ Condition= (Len=Ind)
Connection (Ind.Change,Len.Change) ' Подписка на события Ind.Change и Len.Change
}
При изменении длины или индекса возникают события Ind.Change или Len.Change. Запускается проверка события EndText подписанного на них. Если выражение (Len=Ind) истинно, то тогда возникает событие EndText. В каком месте напишешь процедуру обработки этого события не важно. Факт в том, что больше отслеживать его в самой программе не надо.
Здравствуйте, michael_isu, Вы писали:
_>Оператор if — это наверное самый зловещий оператор, которым мне приходилось пользоваться. Он является основной причиной возникновения спагетти-кода и как следствие причиной сильной головной боли, когда проект развивается много лет. Только вот пока не додумал, как от него избавиться совсем. Какие варианты? или мне пора в ФП?
Элементарно
Вместо спегетти-кода
if (expression)
{
...
}
else
{
...
}
Пишем нормальный удобочитаемый код, используя паттерн-матчинг:
switch(expression)
{
case true:
...
break;
case false:
...
break;
}
Здравствуйте, michael_isu, Вы писали:
_>Оператор if — это наверное самый зловещий оператор, которым мне приходилось пользоваться. Он является основной причиной возникновения спагетти-кода и как следствие причиной сильной головной боли, когда проект развивается много лет. Только вот пока не додумал, как от него избавиться совсем. Какие варианты? или мне пора в ФП?
И правда! Давно пора вернуться к старым добрым cmp, je, jb, .....
А ещё лучше перфокартам — уж там то никакого спагетти.
Здравствуйте, michael_isu, Вы писали:
_>Оператор if — это наверное самый зловещий оператор, которым мне приходилось пользоваться. Он является основной причиной возникновения спагетти-кода и как следствие причиной сильной головной боли, когда проект развивается много лет. Только вот пока не додумал, как от него избавиться совсем. Какие варианты? или мне пора в ФП?
Как не прогер-задрот официально заявляю, чо if — это один из лучших операторов (после присвоения, конечно ). Потому что это самый понятный и простой оператор. Даже в этом долбанном for постоянно забываешь в какой последовательности чо там идёт: сначала условие или приращение.
Здравствуйте, Real 3L0, Вы писали:
R3>Даже в этом долбанном for постоянно забываешь в какой последовательности чо там идёт: сначала условие или приращение.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, michael_isu, Вы писали:
_>Оператор if — это наверное самый зловещий оператор, которым мне приходилось пользоваться. Он является основной причиной возникновения спагетти-кода и как следствие причиной сильной головной боли, когда проект развивается много лет. Только вот пока не додумал, как от него избавиться совсем. Какие варианты? или мне пора в ФП?
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, michael_isu, Вы писали:
_>>Оператор if — это наверное самый зловещий оператор...
R3>Как не прогер-задрот официально заявляю, чо if — это один из лучших операторов (после присвоения, конечно ).
Как начинающий тролль, официально заявляю:
самый лучший оператор — goto.
Это самый понятный оператор из существующих, притом куда понятнее чем оператор присваивания, т.к. совершенно не известно, что именно будет выполнятся за ширмой
a = b;
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, michael_isu, Вы писали:
_> Какие варианты? или мне пора в ФП?
C++ к вашим услугам :
class NoOp
{
public:
virtual int GetResult() = 0;
virtual ~NoOp() = 0;
};
//virtual
NoOp::~NoOp()
{
}
class NoOp_Yes : public NoOp
{
public:
virtual int GetResult() { return 1; }
virtual ~NoOp_Yes(){}
};
class NoOp_ReallyNo : public NoOp
{
public:
virtual int GetResult() { return 6; }
virtual ~NoOp_ReallyNo(){}
};
NoOp* NewNoOp_ReallyNo()
{
return new NoOp_ReallyNo;
}
NoOp* NewNoOp_Yes()
{
return new NoOp_Yes;
}
NoOp* WithoutOp(bool b)
{
NoOp* (*arr[2])();
arr[0] = NewNoOp_ReallyNo;
arr[1] = NewNoOp_Yes;
NoOp* p = arr[b]();
return p;
}
int main()
{
int n = 2;
// int a;
//
// if ( n > 2 )
// a = 1;
// else
// a = 6;
//
// No 'if' ! Just call:
NoOp* pResultGenerator = WithoutOp(n > 2);
int a = pResultGenerator->GetResult();
delete pResultGenerator;
std::cout << "Result:" << a << std::endl;
std::cout << "end" << std::endl;
//getch();return 0;
}
Программа выводит на печать 1 при условии, что n больше 2, и 6 — в противном случае.
Хоть и без tempate'ности, зато с виртуальным деструктором и массивом указателей на функции!
Нарекаю данный паттерн No-if-pattern. Говоря по-русски: Паттерн Несли.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Real 3L0, Вы писали:
R3>>Даже в этом долбанном for постоянно забываешь в какой последовательности чо там идёт: сначала условие или приращение.
Помню как-то раз полдня провел в веселой отладке из-за перепутанных условий в for
Здравствуйте, michael_isu, Вы писали:
_>Оператор if — это наверное самый зловещий оператор, которым мне приходилось пользоваться. Он является основной причиной возникновения спагетти-кода и как следствие причиной сильной головной боли, когда проект развивается много лет. Только вот пока не додумал, как от него избавиться совсем. Какие варианты? или мне пора в ФП?
Лучше сразу в пролог, там от оператора if одна стрелка осталась
Здравствуйте, Философ, Вы писали:
Ф>Как начинающий тролль, официально заявляю: Ф>самый лучший оператор — goto.
Ф>Это самый понятный оператор из существующих, притом куда понятнее чем оператор присваивания, т.к. совершенно не известно, что именно будет выполнятся за ширмой Ф>a = b;
В некоторых диалектах бейсика был возможен такой вариант:
goto a
где a — переменная. Ну и куда перейдёт управление? Как это узнать просто глядя на код? Только прогоняя код пошагово...
Здравствуйте, Qbit86, Вы писали:
N>>В Erlang условное выражение и оператор if — одно и то же.
Q>Ну какбе во всех порядочных языках if — это не то что в Си-подобных языках «if», а то, что в Си-подобных языках «тернарный оператор».
А почему только тернарный? Что за дискриминация? В Erlang у if сколько угодно веток.
ты что считаешь что можешь загаживать темы про программирование своими любимым нытьем про политику? С чего ты это взял. Тебя банить надо, во первых на "обсуждение" личности а второе за офтопик, а в третьих за глупость. А ну кышь в СВ-помойту.
Здравствуйте, Just Men, Вы писали:
JM>ты что считаешь что можешь загаживать темы про программирование своими любимым нытьем про политику? С чего ты это взял. Тебя банить надо, во первых на "обсуждение" личности а второе за офтопик, а в третьих за глупость. А ну кышь в СВ-помойту.
Не надо пальцы гнуть, я бана не боюсь. Он повышает продуктивность.
Здравствуйте, michael_isu, Вы писали: _>Оператор if — это наверное самый зловещий оператор, которым мне приходилось пользоваться. Он является основной причиной возникновения спагетти-кода и как следствие причиной сильной головной боли, когда проект развивается много лет. Только вот пока не додумал, как от него избавиться совсем. Какие варианты? или мне пора в ФП?
мне кажется что проблема спагетти кода и прочего надуманная.
то есть нет большой проблемы писать так, чтобы было просто и понятно.
чаще применяется "осознанный вандализм" — код специально усложняется, чтобы его было сложно поддерживать
Здравствуйте, koodeer, Вы писали:
K>В некоторых диалектах бейсика был возможен такой вариант: K>goto a K>где a — переменная. Ну и куда перейдёт управление? Как это узнать просто глядя на код? Только прогоняя код пошагово...
Между прочим это прародитель ФВП. По крайней мере я это как-то раз использовал в школе как указатель на функцию (хотя и не знал этого) и был ужасно горд красотой решения.
Давайте делиться "изобретенными" костылями, которые легко и удобно делаются на других языках (особенно если знаешь теорию).
Я лично "изобретал":
Односвязные списки на массивах в том же бейсике. Полиморфизм в С через union и указатель на функцию. Аналог продолжений на C# через yield return.
Все это уже можно было найти в литературе в то время, но я не знал как это называется и изобретал сам. Рассказывайте, уверен, например, что большинство старожилов "изобрели" почти все паттерны GoF до прочтения книги.
Здравствуйте, Ziaw, Вы писали:
Z>Все это уже можно было найти в литературе в то время, но я не знал как это называется и изобретал сам. Рассказывайте, уверен, например, что большинство старожилов "изобрели" почти все паттерны GoF до прочтения книги.
Так GoF только с терминологией и помогает разобраться, у них так и написано. Эти "паттерны" сами возникают при решении задач, читал ты книжку, или нет.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Z>>Все это уже можно было найти в литературе в то время, но я не знал как это называется и изобретал сам. Рассказывайте, уверен, например, что большинство старожилов "изобрели" почти все паттерны GoF до прочтения книги.
Ops>Так GoF только с терминологией и помогает разобраться, у них так и написано. Эти "паттерны" сами возникают при решении задач, читал ты книжку, или нет.
В целом верно. Но тот же визитор, при решении задач сам не возникает. Его "изобрести" надо.
Здравствуйте, Ziaw, Вы писали:
Z>В целом верно. Но тот же визитор, при решении задач сам не возникает. Его "изобрести" надо.
Я лично «изобретал» двойную диспетчеризацию на базе двумерной таблички функций (точнее, ассоциативный контейнер с ключом из пары типов), лишь бы Визитор не «изобретать» :)
Здравствуйте, Qbit86, Вы писали:
Q>Я лично «изобретал» двойную диспетчеризацию на базе двумерной таблички функций (точнее, ассоциативный контейнер с ключом из пары типов), лишь бы Визитор не «изобретать»
И я подобное делал, правда по одному типу. Визитор тот еще монстр. Но само решение достаточно интересное.
Здравствуйте, michael_isu, Вы писали:
MI>Оператор if — это наверное самый зловещий оператор, которым мне приходилось пользоваться. Он является основной причиной возникновения спагетти... Только вот пока не додумал, как от него избавиться совсем. Какие варианты?
Здравствуйте, netch80, Вы писали:
N>Этот термин уже занят для поклонников Dragon Book.
Уважаемый Валентин Нечаев!
Вы хорошо знакомы с одномерным (текстовым) структурным программированием.
Похоже, что Вы считаете его единственно возможным.
Но это не так.
Сегодня точкой роста научного знания является не одномерное, а двумерное структурное программирование, реализованное в языке ДРАКОН.
Ниже даны пояснения:
1. Императивная (процедурная) часть языка ДРАКОН опирается на
новый метод – двумерное структурное программирование. Или, что
одно и то же, шампур-метод.
2. Правила двумерного структурного программирования существен-
но отличаются от традиционного одномерного (текстового) струк-
турного программирования.
3. Идеи структурного программирования разрабатывались, когда
компьютерная графика фактически еще не существовала и основ-
ным инструментом алгоритмиста и программиста был одномерный
(линейный или ступенчатый) текст.
4. До появления компьютерной графики методология текстового
структурного программирования была наилучшим решением.
5. С появлением компьютерной графики ситуация изменилась.
Появилась возможность заменить текстовые управляющие струк-
туры на управляющую графику, то есть использовать двумерное
структурное программирование.
6. Слабое место традиционного структурного программирования и
текстового представления алгоритмов и программ заключается в
недостатке выразительных средств. Следствием являются ограни-
чения и запреты. Эти ограничения и запреты вытекают из природы
текста, из природы текстового представления управляющих струк-
тур.
7. Недостаток выразительных средств, проявляющийся через ограни-
чения и запреты, тормозит повышение производительности труда
алгоритмистов и программистов.
8. В рамках текстового представления управляющих структур уст-
ранить эти ограничения и запреты невозможно. Чтобы добиться
улучшения, надо перейти от одномерного текстового структурного
программирования к двумерному визуальному структурному прог-
раммированию.
9. Многие ограничения и запреты, неизбежные при текстовом струк-
турном программировании, во многих случаях противоречат здра-
вому смыслу, затрудняют понимание алгоритмов и программ, иска-
жают нормальный ход человеческой мысли.
10. Недопустимо запрещать правильный процесс мышления. Его надо
разрешить. Шампур-метод и язык ДРАКОН устраняют этот недос-
таток.
11. При использовании шампур-метода набор управляющих ключевых
слов текстового структурного программирования становится не-
нужным.
12. При визуальном структурном подходе программист работает толь-
ко с чертежом программы (дракон-схемой), не обращаясь к ее тек-
стовому представлению. Точно так же программист, работающий,
скажем, на Дельфи, не обращается к ассемблеру и машинному
коду – они для него просто не существуют.
13. Во многих случаях (список которых еще предстоит уточнить) жела-
тельно отказаться от текстовых управляющих структур, заменив их
управляющей графикой.
14. ДРАКОН – это не просто новый язык (новое семейство языков).
Это новый взгляд на процедурное программирование. Если угод-
но – новое мировоззрение.
15. Наибольшую трудность в течение длительного времени представ-
ляли математика и эргономика блок-схем. Нужно было создать
математически строгий метод формализации блок-схем, позволяю-
щий превратить блок-схемы в программу, пригодную для ввода в
компьютер и трансляции в объектный модуль программы.
16. Язык ДРАКОН позволил эффективно решить эту задачу.
17. Одно временно была решена задача эргономизации блок-схем, то
есть задача приспособления блок-схем для наиболее удобного
человеческого восприятия и понимания.
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Здравствуйте, netch80, Вы писали:
N>>Этот термин уже занят для поклонников Dragon Book.
ВП>Уважаемый Валентин Нечаев!
ВП>Вы хорошо знакомы с одномерным (текстовым) структурным программированием. ВП>Похоже, что Вы считаете его единственно возможным. ВП>Но это не так.
Вы про UML в курсе? Ваш дракон просто пустое место в смысле содержания. И вообще. Прислушивайтесь хоть чуток к в общем то не глупым людям
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Здравствуйте, netch80, Вы писали:
N>>Этот термин уже занят для поклонников Dragon Book.
ВП>Уважаемый Валентин Нечаев!
ВП>Вы хорошо знакомы с одномерным (текстовым) структурным программированием. ВП>Похоже, что Вы считаете его единственно возможным. ВП>Но это не так.
Похоже что вы считаете единственно возможным структурное программирование. Но это не так.
ВП>Сегодня точкой роста научного знания является не одномерное, а двумерное структурное программирование, реализованное в языке ДРАКОН.
Вы ошибаетесь. Что бы это понять, нужно лишь выглянуть за пределы уютного "научного" круга, использующего ДРАКОН, ознакомитсья с другими парадигмами программирования, кроме структурного.
Здравствуйте, samius, Вы писали:
S>Похоже что вы считаете единственно возможным структурное программирование. Но это не так.
Уважаемый Алексей Шинкарев!
Я вовсе не считаю структурное программирование единственно возможным.
ВП>>Сегодня точкой роста научного знания является не одномерное, а двумерное структурное программирование, реализованное в языке ДРАКОН.
S>Вы ошибаетесь. Что бы это понять, нужно лишь выглянуть за пределы уютного "научного" круга, использующего ДРАКОН, ознакомитсья с другими парадигмами программирования, кроме структурного.
Не понимаю, где здесь ошибка. Да, я противопоставил одномерное и двумерное структурное программирование.
Первое всем известно.
А второе (как показывает обсуждение на форумах RSDN) воспринимается с большим трудом.
Я согласен с Вами, что, говоря о ДРАКОНе, надо обязательно сказать про следующие парадигмы:
Возникает вопрос: позволяет ли этот список парадигм программирования выявить сущность языка ДРАКОН?
Если у Вас есть замечания, буду благодарен за критику.
Здравствуйте, Don Reba, Вы писали:
DR>Боюсь, что вы немного отстали от жизни. В отечественной практике, в текстовом виде уже семь лет как пишутся далеко не только одномерные программы:
Уважаемый Алексей Бадалов!
Не согласен. В самом деле, я писал:
3. Идеи структурного программирования разрабатывались, когда
компьютерная графика фактически еще не существовала и основ-
ным инструментом алгоритмиста и программиста был одномерный
(линейный или ступенчатый) текст.
Вы не заметили слово "ступенчатый".
Вам не нравится слово "ступенчатый"?
Ладно, пусть будет по-вашему.
Скажем, интендация.
Не нравится "интендация"?
Ладно, я заранее с Вами соглашусь.
Выбирайте любой термин, какой считаете нужным.
Это что-нибудь меняет?
В литературе текст обычно называют линейным или одномерным.
Вам это не по душе?
Ради бога, я с Вами спорить не буду.
Но! Двумерное структурное программирование (используемое в языке ДРАКОН) — это 2D.
Two-dimentional.
Разве не так?
ВП>4) параллельное программирование; ВП>7) End-user development; ВП>8) real-time programming ВП>10) Concurrent computing; ВП>И др.
ВП>Возникает вопрос: позволяет ли этот список парадигм программирования выявить сущность языка ДРАКОН? ВП>Если у Вас есть замечания, буду благодарен за критику.
Для пунктов 4,7,8,10 Дракон не подходит совершенно.
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Здравствуйте, samius, Вы писали:
S>>Похоже что вы считаете единственно возможным структурное программирование. Но это не так.
ВП>Уважаемый Алексей Шинкарев!
ВП>Я вовсе не считаю структурное программирование единственно возможным.
Уже хорошо. А что вам дало повод считать так в отношении netch80?
ВП>>>Сегодня точкой роста научного знания является не одномерное, а двумерное структурное программирование, реализованное в языке ДРАКОН.
S>>Вы ошибаетесь. Что бы это понять, нужно лишь выглянуть за пределы уютного "научного" круга, использующего ДРАКОН, ознакомитсья с другими парадигмами программирования, кроме структурного.
ВП>Не понимаю, где здесь ошибка. Да, я противопоставил одномерное и двумерное структурное программирование. ВП>Первое всем известно. ВП>А второе (как показывает обсуждение на форумах RSDN) воспринимается с большим трудом.
С трудом понимаю вашу терминологию. Согласно определению, в основе структурного программирования лежит представление программы в виде иерархической структуры блоков. И я не вижу повода размышлять о мерности такого представления. Почему вы традиционное структурное программирование назвали одномерным? Структура блоков может быть достаточно сложна, что бы граф мог не быть планарным. И обычное текстовое представление кода неплохо с этим справляется при наличии развитой IDE. Кстати, текст не менее двумерен, чем картинка-схема.
То что второе (двумерное структурное программирование) воспринимается с трудом — в этом я согласен. Но восприятие — это вопрос многих переменных, в коих значатся автор кода, читатель кода, знакомство того и другого с технологиями и описываемыми процессами, опыт и т.п. Т.е. согласен считать что мои трудности с восприятием ДРАКОНа субъективны.
ВП>Я согласен с Вами, что, говоря о ДРАКОНе, надо обязательно сказать про следующие парадигмы:
Я ничего подобного не утверждал. Я считаю что рост научного знания в области структурного программирования отсутствует. Методология есть, а науки там нет. Во всяком случае с момента публикации теоремы Бёма — Якопини (1966).
ВП>1) императивное программирование; ВП>2) процедурное программирование; ВП>3) структурное программирование; ВП>4) параллельное программирование; ВП>5) Automata-based programming; ВП>6) Automatic programming; ВП>7) End-user development; ВП>8) real-time programming ВП>9) Time-driven programming; ВП>10) Concurrent computing; ВП>И др.
ВП>Возникает вопрос: позволяет ли этот список парадигм программирования выявить сущность языка ДРАКОН?
Не могу ответить на этот вопрос, т.к. сущность языка ДРАКОН я не постиг. По мне так это еще один способ записи алгоритмов, причем не самый удобный и наглядный, судя по схемам в википедии. Врачу может и удобно будет водить пальцем по квадратикам. А что касается квиксорта и чисел фибоначчи — то дракон-схемы мне кажутся избыточными относительно текстовой записи.
ВП>Если у Вас есть замечания, буду благодарен за критику.
Возможно я вас неправильно понял. Может быть вы говорили о росте научного знания конкретно в области структурного программирования, а не программирования вообще, которое давно уже вышло за рамки структурного.
ВП>>8) real-time programming M>Для пунктов 4,7,8,10 Дракон не подходит совершенно.
А вот 8 вопрос интересный.
Вроде как объявлено использование, причем реальное использование, именно в real-time системах.
У меня возникло смутное подозрение, что в обсуждаемой отрасли в БЦВМ не используется система прерываний в принципе. Все от чего могли бы они исходить просто опрашивается в цикле.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[9]: Мерность как самостоятельная характеристика
Здравствуйте, samius, Вы писали:
S>С трудом понимаю вашу терминологию. Согласно определению, в основе структурного программирования лежит представление программы в виде иерархической структуры блоков. И я не вижу повода размышлять о мерности такого представления. Почему вы традиционное структурное программирование назвали одномерным? Структура блоков может быть достаточно сложна, что бы граф мог не быть планарным. И обычное текстовое представление кода неплохо с этим справляется при наличии развитой IDE. Кстати, текст не менее двумерен, чем картинка-схема.
Вы имели в виду что-то типа сказанного здесь?..
Чтобы снять все вопросы, могу рекомендовать Вам прочитать мою книгу (всего 520 страниц).
Почти триста илллюстраций. У Вас будет полная ясность по языку ДРАКОН.
Книга продается на каждом углу.
Паронджанов В. Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. – М.: ДМК Пресс, 2012. – 520 с. — Иллюстаций 272.
Здравствуйте, Владимир Паронджанов, Вы писали:
N>>Этот термин уже занят для поклонников Dragon Book. ВП>Уважаемый Валентин Нечаев! ВП>Вы хорошо знакомы с одномерным (текстовым) структурным программированием. ВП>Похоже, что Вы считаете его единственно возможным. ВП>Но это не так.
Уважаемый Владимир Паронджанов!
Я очень хочу понять, почему Вы выдвигаете такие предположения в мой адрес. Я не вижу ни одной причины, по которой это можно было бы сделать.
Если Вы внимательно прочитаете мои сообщения, то заметите, что я не сделал пока что ни единого отрицательного комментария в сторону Вашего творения в виде языка "Дракон". Поэтому мне вообще непонятна причина этого Вашего ответа на моё сообщение.
Поэтому я могу пока что квалифицировать Ваш комментарий в мою сторону только одним из двух следующих вариантов: 1) Вы чрезмерно обидчивы и видите какой-то "наезд" на своё детище даже там, где такого не предполагалось и не высказывалось, 2) Вы используете любой повод для высказывания своей позиции, даже там, где его нет.
ВП>Сегодня точкой роста научного знания является не одномерное, а двумерное структурное программирование, реализованное в языке ДРАКОН.
В Вашем высказывании содержится утверждение про точку роста научного знания, но также по его конструкции имплицитно подразумевается, что это является какой-то особо выдающейся или даже единственной точкой роста научного знания. Нисколько не возражая против первого — с моим академическим "бэкграундом" я хорошо представляю себе, что наука может развиваться в тысячах разных направлений одновременно, я тем не менее не вижу никаких аргументов в пользу второго, поэтому соответствующий эмоциональный слой высказывания отношу исключительно на счёт Вашей заинтересованности в данной работе.
Как я уже говорил, меня до сих пор тема языка Дракон и связанных с ним технологий не интересовала никак. Я просто отметил в памяти, что есть такое и что его как-то продвигают. Но раз уж Вы зацепили персонально меня, я пошёл смотреть по ссылкам, что же собственно видно. Текущее впечатление пока что сводится к обычному "многабукав — ниасилил", извините за прямолинейность. Простой вопрос навстречу: Вы можете привести какой-то понятный большинству пример, где использование ваших средств даёт принципиальное облегчение рассмотрения сути задачи и соответственно построения решения?
Вы сами, насколько я понимаю, придумываете графические средства для того, чтобы воспользоваться тем, что визуализация позволяет значительно быстрее понять суть (разумеется, если правильно сделана). Поэтому я не стал глубоко вчитываться в теоретические основы, а начал с рассмотрения картинок. Вопрос: Вы представляете что-то кроме блок-схем алгоритма? Если да, то где оно? Если нет, то чем оно поможет большинству программистов, задачи которых далеко выходят за пределы одиночного алгоритма?
Я чуть больше поясню свой интерес здесь. Моя основная работа сейчас связана с VoIP. Средства управления в VoIP, такие, как SIP — это сложные программные комплексы с нетривиальной логикой, которая собрана в логические уровни. Например, в случае SIP есть уровень приложения, уровень сессии, уровень диалога, уровень транзакций, уровень транспорта. Каждый из них на простом уровне понимания может быть представлен как машина состояний (конечный автомат) с логикой, определяемой внешними и внутренними событиями. Конечно, если я попытаюсь представить логику одного элементарного звена в виде блок-схемы, что-то получится; но это представление будет неэффективно — в том смысле, что неадекватно задаче и из блок-схемы не получится получить ни одного специфического для автомата результата (начиная с тривиальщины вроде нахождения неиспользуемых состояний). Попытка же представить функционал полной программы в виде блок-схемы 1) обречена на получение конструкции, которая влезет разве что на экран в две комнатные стены, 2) ничего не даст для понимания собственно логики. Логичный риторический вопрос — зачем мне тут рисовать блок-схему?
Другой пример — организация структуры данных в памяти. Представим себе больничную базу данных. Обнаружено, что каждая запись о посещении врача содержит ФИО пациента вместо ссылки на общую карточку пациента, то есть присутствует бессмысленное и потенциально диверсионное (в случае опечаток, например) дублирование данных. Чтобы хорошо представить себе структуру данных и найти в ней подобные проблемы, нужно нарисовать именно структуру данных. Блок-схема этому никак не поможет, в ней родственные пункты будут разнесены по чрезвычайно далёким местам.
А что именно Вы собираетесь представлять в виде блок-схемы, если вся логика сосредоточена в простейших (до 10 строчек) виртуальных методах, зато принципиально то, в каком классе какой из них перекрыт?
Если всё это у вас есть, то я его не нашёл — видимо, слишком хорошо спрятано.
ВП>1. Императивная (процедурная) часть языка ДРАКОН опирается на ВП>новый метод – двумерное структурное программирование. Или, что ВП>одно и то же, шампур-метод.
Что скрывается за этим красивым названием и почему шампур?
ВП>3. Идеи структурного программирования разрабатывались, когда ВП>компьютерная графика фактически еще не существовала и основ- ВП>ным инструментом алгоритмиста и программиста был одномерный ВП>(линейный или ступенчатый) текст.
Простите, а разве ничего не значит, что в то же самое время рисовали блок-схемы вручную для разработки и контроля алгоритма? И что советские правила приёма программ просто требовали наличия этих блок-схем даже там, где они были бессмысленны?
Тогда что именно вы привнесли? Графическое средство для автоматизации того, что делалось вручную, пока имело смысл, но дальше потеряло этот смысл?
ВП>4. До появления компьютерной графики методология текстового ВП>структурного программирования была наилучшим решением.
Не была она наилучшим решением. Она была одна из и далеко не исходной.
ВП>14. ДРАКОН – это не просто новый язык (новое семейство языков). ВП>Это новый взгляд на процедурное программирование. Если угод- ВП>но – новое мировоззрение.
Которому лет 50, мне кажется.
ВП>17. Одно временно была решена задача эргономизации блок-схем, то ВП>есть задача приспособления блок-схем для наиболее удобного ВП>человеческого восприятия и понимания.
Мне кажется, во всей разработке это единственно ценная часть, как для прикладного программиста. Остальное — а именно, ориентация на блок-схемы — пригодна только для обучения студентов, и то как вспомогательное средство.
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Именно так и сделано в языке ДРАКОН.
Здесь на рисунке 88 ошибка. На светофоре жёлтый после красного включается до того, как выключится красный. Т.е. у светофора по ПДД четыре сигнала (кроме ночного режима): зелёный, жёлтый, красный, красно-жёлтый.
Здравствуйте, Qbit86, Вы писали:
Q>Здесь на рисунке 88 ошибка. На светофоре жёлтый после красного включается до того, как выключится красный. Т.е. у светофора по ПДД четыре сигнала (кроме ночного режима): зелёный, жёлтый, красный, красно-жёлтый.
Это совершенно непринципиально, jIMHO, для объяснения метода. Нужно будет — дорисуют.
Тем более что в разных странах разные традиции. Например, у нас принят мигающий зелёный, а в ГДР я видел в той же роли жёлто-зелёный. Или, в Барселоне, похоже, "ночной режим" с мигающим жёлтым не включается принципиально (в 4 утра точно так же переключается, как обычно), но совершенно обычно, что на перекрёстке на выезде с какой-то улицы в одной фазе горит красный, а в другой — мигающий жёлтый (мол, езжайте, но осторожно и всех пропускайте). А над пешеходным светофором там тоже мигающий жёлтый (ну любят они его) для машин, которые подъезжают и должны пропускать пешеходов.
А в Броварах (под Киевом) были светофоры, где ввели мигающий зелёный так, что зелёный по одному направлению и красный по другому это один и тот же сигнал на выходе с блока управления, так что там не было красно-жёлтого, но красный мигал перед переключением.
Здравствуйте, Qbit86, Вы писали:
N>>Тем более что в разных странах разные традиции. Q>Но логика одна: читая «промежуточный» сигнал светофора, водитель должен понимать, что за ним последует — разрешающий или запрещающий сигнал.
Ты уводишь в оффтопик.
Давай уже тогда вспоминать светофоры с индикацией времени, сколько осталось до переключения сигнала (половина Киева уже имеет такое на пешеходных светофорах). Зачем какие-то промежуточные сигналы, если ты видишь, что до переключения осталось 5...4...3...2...1... секунд? "It's the final countdown!"
В рамках темы, ты наталкиваешь на другую мысль. Что будет, если потребовать таких индикаторов в данной схеме? Останется она "двумерной" в терминах авторов Дракона или станет трёхмерной, потому что цикл смены показаний времени в пределах одного сигнала это отдельная "вложенная" сущность?
Здравствуйте, netch80, Вы писали:
N>Я очень хочу понять, почему Вы выдвигаете такие предположения в мой адрес. Я не вижу ни одной причины, по которой это можно было бы сделать.
Уважаемый Валентин Нечаев!
Это произошло в результате ошибки. Приношу свои извинения.
N>В Вашем высказывании содержится утверждение про точку роста научного знания… N>…………………………………………………………………………….. N>поэтому соответствующий эмоциональный слой высказывания отношу исключительно на счёт Вашей заинтересованности в данной работе.
Вы правы.
N>...меня до сих пор тема языка Дракон и связанных с ним технологий не интересовала никак. N>………………………………………………… N>Простой вопрос навстречу: Вы можете привести какой-то понятный большинству пример, где использование ваших средств даёт принципиальное облегчение рассмотрения сути задачи и соответственно построения решения?
Боюсь, один пример ничего не даст. Могу дать ссылку на 124 страницы. http://drakon-practic.ru/drakon.pdf
N>Вы сами, насколько я понимаю, придумываете графические средства для того, чтобы воспользоваться тем, что визуализация N>позволяет значительно быстрее понять суть (разумеется, если правильно сделана).
Нельзя говорить, что я сам. Это совместный труд ФГУП «НПЦАП» им. Пилюгина
и Института прикладной математики им. Келдыша РАН .
Все началось с Бурана.
N>Поэтому я не стал глубоко вчитываться в теоретические основы, а начал с рассмотрения картинок. N>Вопрос: Вы представляете что-то кроме блок-схем алгоритма?
Я написал десяток книг по блок-схемам (дракон-схемам), в том числе три для детей.
Но в них ни слова (почти) про структуры данных.
N>Если нет, то чем оно поможет большинству программистов, N>задачи которых далеко выходят за пределы одиночного алгоритма?
В Вашем вопросе содержится неточность.
Вы (не только Вы, но и весь мир) мыслите одиночными алгоритмами.
Когда задачи ДАЛЕКО ВЫХОДЯТ за пределы одиночного алгоритма, возникают проблемы.
Вы (и вместе с Вами весь мир) научились с помощью РАЗЛИЧНЫХ СПОСОБОВ преодолевать эти проблемы.
Вы (и вместе с Вами весь мир) считаете, что это хорошие способы.
Предположим, что сегодня существует N способов преодолевать эти проблемы.
Я предлагаю еще один, N+1-й способ.
Не вместо существующих, а в дополнение к ним. Этот способ называется ДРАКОН.
Что такое ДРАКОН?
Это принципиально новая нотация для записи алгоритмов ЛЮБОЙ сложности.
Не только одиночных алгоритмов, а огромной совокупности огромных алгоритмов.
Чем сложнее алгоритм, тем больше выгода от использования ДРАКОНа.
ДРАКОН превращает сложные и непонятные (точнее, трудные для понимания) алгоритмы
в простые и понятные (точнее, более легкие для понимания).
Не только одиночные алгоритмы, но и огромные совокупности огромных алгоритмов.
Я отчетливо сознаю, что не ответил на Ваши вопросы.
Попытаюсь (если будет возможность) продолжить ответ через несколько дней.
Здравствуйте, Владимир Паронджанов, Вы писали:
N>>Я очень хочу понять, почему Вы выдвигаете такие предположения в мой адрес. Я не вижу ни одной причины, по которой это можно было бы сделать. ВП>Уважаемый Валентин Нечаев! ВП>Это произошло в результате ошибки. Приношу свои извинения.
Протестую! Эта ветка про светофор!
ВП>Что такое ДРАКОН? ВП>Это принципиально новая нотация для записи алгоритмов ЛЮБОЙ сложности.
To all: Кто-нибудь кроме меня вспомнил Шахиджаняна?
Глаза у меня добрые, но рубашка — смирительная!
Re[10]: Мерность как самостоятельная характеристика
Здравствуйте, VladZharinov, Вы писали:
VZ>Здравствуйте, samius, Вы писали:
S>>С трудом понимаю вашу терминологию. Согласно определению, в основе структурного программирования лежит представление программы в виде иерархической структуры блоков. И я не вижу повода размышлять о мерности такого представления. Почему вы традиционное структурное программирование назвали одномерным? Структура блоков может быть достаточно сложна, что бы граф мог не быть планарным. И обычное текстовое представление кода неплохо с этим справляется при наличии развитой IDE. Кстати, текст не менее двумерен, чем картинка-схема. VZ>Вы имели в виду что-то типа сказанного здесь?..
Да, что-то типа того. С поправкой на то, что я обычный текст (и даже один символ) считаю двумерным объектом.
Одномерный — это что-то вроде азбуки Морзе, или представления текста в виде строки в памяти компьютера. Текст, который мы видим глазами, безусловно двумерен (как минимум).
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Книга продается на каждом углу.
Владимир, вы уже вплотную подошли к бану. Если вы хотите рекламировать коммерческую литературу — оплатите, пожалуйста, размещение баннера или текстовой рекламы по официальным расценкам.
Форумы здесь посвящены обсуждению проблем программирования, и на вопросы принято отвечать бесплатно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Владимир Паронджанов, Вы писали:
N>>>Я очень хочу понять, почему Вы выдвигаете такие предположения в мой адрес. Я не вижу ни одной причины, по которой это можно было бы сделать. ВП>>Уважаемый Валентин Нечаев! ВП>>Это произошло в результате ошибки. Приношу свои извинения.
Q>Протестую! Эта ветка про светофор!
В связи с программами и спецификациями? Скажем, как у Карпова?..
ВП>>Что такое ДРАКОН? ВП>>Это принципиально новая нотация для записи алгоритмов ЛЮБОЙ сложности.
Q>To all: Кто-нибудь кроме меня вспомнил Шахиджаняна?
Можно и другое вспомнить. Правда, не совсем понятно, что Вы имели в виду. Скажем, такие вещи: N>>Если нет, то чем оно поможет большинству программистов, N>>задачи которых далеко выходят за пределы одиночного алгоритма?
ВП>В Вашем вопросе содержится неточность. ВП>Вы (не только Вы, но и весь мир) мыслите одиночными алгоритмами.
ВП>Когда задачи ДАЛЕКО ВЫХОДЯТ за пределы одиночного алгоритма, возникают проблемы.
ВП>Вы (и вместе с Вами весь мир) научились с помощью РАЗЛИЧНЫХ СПОСОБОВ преодолевать эти проблемы.
ВП>Вы (и вместе с Вами весь мир) считаете, что это хорошие способы.
— возможно, просто несинхронизация со смыслом высказывания корреспондента (имею в виду употребление выделенного у участников жирным шрифтом)...
Здравствуйте, Sinclair, Вы писали:
S>Форумы здесь посвящены обсуждению проблем программирования, и на вопросы принято отвечать бесплатно.
Попробую дать бесплатный ответ. В ветке про ГРАФИТ-ФЛОКС указывалось, какие структуры данных поддерживает эта технология. Скажем, здесь. Т.е. это ячейки памяти. Надо абстрактные типы вводить — потребуется создать и соответствующий графовый синтаксис. Можно так, как здесь описано. Пример применения... ну хотя бы здесь.
Тут недавно говорили и про рекурсию на схемах — так в Примере 95 как раз видно, что именно на схемах типов можно решить задачу её указания. Другой путь — вписывать данные о рекурсивных вызовах в вершины конца схем алгоритмов.
А ВП создал такой способ описания структур данных, какой нужен был для ГРАФИТ-ФЛОКС-исполнителя (БЦВМ).
Здравствуйте, VladZharinov, Вы писали:
Q>>Протестую! Эта ветка про светофор! VZ>В связи с программами и спецификациями? Скажем, как у Карпова?..
Q>>To all: Кто-нибудь кроме меня вспомнил Шахиджаняна? VZ>Можно и другое вспомнить. :) Правда, не совсем понятно, что Вы имели в виду.
Ваш комментарий содержит ссылки на сообщения форума OberonCore (без малейшего намёка на то, как это связано с моим сообщением). Последние в свою очередь содержат ссылки на какие-то мутные источники. Причём среди них в качестве автора фигурирует, прошу прощения, Шалыто. Вы явно переоцениваете моё желание читать труды подобной публики. Хватит с меня того, что я, даже видя forum.oberoncore.ru в адресе ссылки, всё равно туда перешёл. О чём незамедлительно пожалел, так как обычно стараюсь блюсти гигиену мозга.
Какой-то Карпов, какой-то разбор Резуна, одна ссылка удивительней другой просто.
Глаза у меня добрые, но рубашка — смирительная!
Re[11]: Мерность как самостоятельная характеристика
Здравствуйте, samius, Вы писали:
S>Да, что-то типа того. С поправкой на то, что я обычный текст (и даже один символ) считаю двумерным объектом. S>Одномерный — это что-то вроде азбуки Морзе, или представления текста в виде строки в памяти компьютера. Текст, который мы видим глазами, безусловно двумерен (как минимум).
Ага... всё собираюсь развить как раз в том же ключе — что есть физически одномерные представления типа той же азбуки Морзе. Тогда как обычные буквы надо читать в двух измерениях.
И в то же время текст логически может представлять одномерную структуру — без каких-то нелинейных связей содержания.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, VladZharinov, Вы писали:
Q>>>Протестую! Эта ветка про светофор! VZ>>В связи с программами и спецификациями? Скажем, как у Карпова?..
Q>>>To all: Кто-нибудь кроме меня вспомнил Шахиджаняна? VZ>>Можно и другое вспомнить. Правда, не совсем понятно, что Вы имели в виду.
Q>Ваш комментарий содержит ссылки на сообщения форума OberonCore (без малейшего намёка на то, как это связано с моим сообщением). Последние в свою очередь содержат ссылки на какие-то мутные источники. Причём среди них в качестве автора фигурирует, прошу прощения, Шалыто.
Не, там конкретно не Шалыто. Карпов просто как раз разбирал, как проверять программы, в частности, на примере светофора...
Q>Какой-то Карпов, какой-то разбор Резуна, одна ссылка удивительней другой просто.
Я так понял, что упоминанием Шахиджаняна Вы намекаете на "методы внедрения идей"... Хотя, возможно, имелось в виду что-то другое?..
Тут есть, мне кажется, один аспект — человек вроде как придумал, как можно исчислять схемы. И то, что его посты могут заставлять вспомнить Шахиджаняна (и не только), не значит, что в этом нет чего-то полезного...
Здравствуйте, VladZharinov, Вы писали:
VZ>Здравствуйте, samius, Вы писали:
S>>Да, что-то типа того. С поправкой на то, что я обычный текст (и даже один символ) считаю двумерным объектом. S>>Одномерный — это что-то вроде азбуки Морзе, или представления текста в виде строки в памяти компьютера. Текст, который мы видим глазами, безусловно двумерен (как минимум). VZ>Ага... всё собираюсь развить как раз в том же ключе — что есть физически одномерные представления типа той же азбуки Морзе. Тогда как обычные буквы надо читать в двух измерениях.
Даже если мы будем считать один символ точечным объектом, двумерность текста все равно будет иметь значение.
VZ>И в то же время текст логически может представлять одномерную структуру — без каких-то нелинейных связей содержания.
Конечно же содержание и связи — это вопрос контекста. Когда мы смотрим на текст как на последовательность codepoint-ов, то нет в нем никакого содержания и связей, кроме самой последовательности. Но если мы скормим эту последовательность браузеру — можем увидеть нечто интересное. Скормим другую компилятору — можем получить программу, решающую какую-то задачу. А если посмотрим на текстовое представление сами, то увидим что-то другое.
Потому сопоставлять исходные тексты программы с одномерной последовательностью символов совершенно нелепо.
Re[13]: Мерность как самостоятельная характеристика
... VZ>>И в то же время текст логически может представлять одномерную структуру — без каких-то нелинейных связей содержания. S>Конечно же содержание и связи — это вопрос контекста. Когда мы смотрим на текст как на последовательность codepoint-ов, то нет в нем никакого содержания и связей, кроме самой последовательности. Но если мы скормим эту последовательность браузеру — можем увидеть нечто интересное. Скормим другую компилятору — можем получить программу, решающую какую-то задачу. А если посмотрим на текстовое представление сами, то увидим что-то другое. S>Потому сопоставлять исходные тексты программы с одномерной последовательностью символов совершенно нелепо.
Во-во... И если мы хотим представить для текста программы маршруты его исполнения — то можем просто расположить участки этих маршрутов по порядку выбора, переводя строку после каждого оператора. Без всякой замены маршрутных ключевых слов на графику вершин и линий... И физическое расположение фраз на плоскости станет представлять двумерную логику в смысле сказанного у Ермакова и Жигуненко в п.3:
Последовательность действий выстраивается по вертикали сверху вниз, переключение семантических состояний системы (переходы между маршрутами) выполняются по горизонтали слева направо (расщепление) и справа налево (объединение).
Здравствуйте, michael_isu, Вы писали:
_>Оператор if — это наверное самый зловещий оператор, которым мне приходилось пользоваться. Он является основной причиной возникновения спагетти-кода и как следствие причиной сильной головной боли, когда проект развивается много лет. Только вот пока не додумал, как от него избавиться совсем. Какие варианты? или мне пора в ФП?
Очень простое решение заменить оператор if с помощью pattern matching
Так что бы вместо if и switch
int fib(int n) {
if (n==0) return 1;
if (n==1) return 1;
return fib(n-1)+fib(n-2);
}
можно было писать так
int fib(int n) { return fib(n-1)+fib(n-2); }
int fib(int n==0) { return 1; }
int fib(int n==1) { return 1; }
это способно убрать длинные портянки if-ов и статические switch-и заменит расширяемыми.
ps: оператор if и goto бессмертны. не возможно убить то чего нет.
Re[13]: Мерность как самостоятельная характеристика
S>Даже если мы будем считать один символ точечным объектом, двумерность текста все равно будет иметь значение.
Откуда взялась двухмерность?
Текст или одномерный — как последовательность считываемых символов,
или многомерный (где кол-во измерений переваливает за не один десяток) — если речь идет о формируемых текстом смысловых пространств.
Re[14]: Мерность как самостоятельная характеристика
Здравствуйте, DarkGray, Вы писали:
S>>Даже если мы будем считать один символ точечным объектом, двумерность текста все равно будет иметь значение.
DG>Откуда взялась двухмерность?
Возможно от тэртерийцев, если верить википедии. Но на самом деле несложно проследить двумерность от наскальной живописи.
DG>Текст или одномерный — как последовательность считываемых символов,
кроме последовательности символов текст обладает так же и форматированием (отступы, табуляция и т.п.). Да, сейчас их засунули в последовательность символов, но это не всегда было так.
DG>или многомерный (где кол-во измерений переваливает за не один десяток) — если речь идет о формируемых текстом смысловых пространств.
Нет, я не об этом. Я о том, что таблицу (например) можно представить текстом. Но если смотреть на этот текст как на последовательность символов, то можно не увидить того, что видно в таблице.
Re[15]: Мерность как самостоятельная характеристика
DG>>Откуда взялась двухмерность? S> Но на самом деле несложно проследить двумерность от наскальной живописи.
Если занудничать, то наскальная живопись — это 6-ти мерное пространство:
— 3-оси поверхности скалы (которая не тождественна двухмерному пространству)
— цвет
— фактура
— шершавость
Может добавляться еще время, если прыгающий свет факела или двигающийся луч солнца подчеркивал какие-то участки рисунка в зависимости от изменения времени.
DG>>или многомерный (где кол-во измерений переваливает за не один десяток) — если речь идет о формируемых текстом смысловых пространств. S>Нет, я не об этом. Я о том, что таблицу (например) можно представить текстом. Но если смотреть на этот текст как на последовательность символов, то можно не увидить того, что видно в таблице.
Если в виде таблицы представлен многомерный куб, то если на таблицу смотреть как на двухмерное пространство, то можно вообще ничего не увидеть.
Поэтому я еще раз повторю свой вопрос: почему акцент делается именно на двухмерности? а не допустим хотя бы на 4-х мерности (размерность окружающего пространства + время)?
Re[16]: Мерность как самостоятельная характеристика
Здравствуйте, DarkGray, Вы писали:
DG>>>Откуда взялась двухмерность? S>> Но на самом деле несложно проследить двумерность от наскальной живописи.
DG>Если занудничать, то наскальная живопись — это 6-ти мерное пространство:
Нет желания отвечать на занудство
S>>Нет, я не об этом. Я о том, что таблицу (например) можно представить текстом. Но если смотреть на этот текст как на последовательность символов, то можно не увидить того, что видно в таблице.
DG>Если в виде таблицы представлен многомерный куб, то если на таблицу смотреть как на двухмерное пространство, то можно вообще ничего не увидеть.
верно
DG>Поэтому я еще раз повторю свой вопрос: почему акцент делается именно на двухмерности? а не допустим хотя бы на 4-х мерности (размерность окружающего пространства + время)?
Потому что 5-7 тысяч лет текст читается с двумерной проекции того, на чем он написан, на плоскость. И лишь в последнее время его стали записывать в виде последовательности символов для машинного представления. Для чтения его человеком нужна как минимум двумерная картинка.
Re[17]: Мерность как самостоятельная характеристика
S>Потому что 5-7 тысяч лет текст читается с двумерной проекции того, на чем он написан, на плоскость.
Мозг человека за последние 5-7 тысяч лет не менялся. Он как был многомерным, так и остался. От того что в истории был период, когда накопленная информация преимущественно передавалась в двухмерном виде — на человека никак не повлияло.
Re[18]: Мерность как самостоятельная характеристика
Здравствуйте, DarkGray, Вы писали:
S>>Потому что 5-7 тысяч лет текст читается с двумерной проекции того, на чем он написан, на плоскость.
DG>Мозг человека за последние 5-7 тысяч лет не менялся. Он как был многомерным, так и остался. От того что в истории был период, когда накопленная информация преимущественно передавалась в двухмерном виде — на человека никак не повлияло.
И, собственно, что из этого следует? Разве текст перестает представляться в двумерном виде? Или в письменности начинают преобладать драконовские схемы?
Пришел студент экзамен по биологии сдавать, а знает только один билет — про блох. Ну зашел он в аудиторию, взял билет, читает — “блохи” (YES!). Он начинает:
— Блохи — насекомые, которые живут в шерсти животных, имеют длинный, острый хоботок, которым протыкают кожу и пьют кровь. Блохи имеют длинные ноги, за счет которых хорошо прыгают…
Ему зачли билет, сказали взять другой. Берет — “собаки”. Он начинает:
— Собаки — животные разряда млекопитающих, они имеют 4 лапы и хвост, которые покрыты шерстью. А в шерсти наверняка живут блохи, а блохи — это…
Экзаменаторы подумали, заставляют еще один билет брать… Он берет — “кошки”. Студент пять:
— Кошки — это животные, которые имеют 4 ноги, длинные усы и хвост. Также имеется волосяной покров, в котором наверняка есть блохи, а блохи — это…
Экзаменаторы в дауне… Самый главный не растерялся и говорит:
— Юноша, а что вы можете сказать нам про рыб?
Студент:
— Рыбы — это животные, тело которых покрыто чешуей. Ну а если бы они имели шерсть, то там точно водились бы блохи. А блохи — это…
Что такое двумерное программирование? ЧТО ЭТО ТАКОЕ? Что такое одномерное? будущее вообще за фазовым пространством
.
Re[19]: Мерность как самостоятельная характеристика
то, что когда человек утверждает, что текст одномерен или двумерен, то это лишь расхожее клише, которое никакого отношения к реальному состоянию дел не имеет.
Для реального текста, символы — это точки в 5-ти мерном пространстве: две координаты на плоскости, вид гарнитуры шрифта, код символа, цвет (цвет фона уже используется редко и относится он больше к цвету блоков содержащих текст, а не к самому тексту)
S> Разве текст перестает представляться в двумерном виде?
Как ты в данном случае задал термин "представляться", чтобы это было не тавтологическим утверждением? При условии, что произвольное k-мерное счетное множество может быть представлено, как n-мерное счетное множество (при этом k, n произвольные натуральные числа)
Re[20]: Мерность как самостоятельная характеристика
Здравствуйте, DarkGray, Вы писали:
S>>И, собственно, что из этого следует?
DG>то, что когда человек утверждает, что текст одномерен или двумерен, то это лишь расхожее клише, которое никакого отношения к реальному состоянию дел не имеет.
DG>Для реального текста, символы — это точки в 5-ти мерном пространстве: две координаты на плоскости, вид гарнитуры шрифта, код символа, цвет (цвет фона уже используется редко и относится он больше к цвету блоков содержащих текст, а не к самому тексту)
Ты не забыл что каждый символ может быть неаффинно искажен, а то и разрезан на куски? Просто интересует, почему ты ограничился 5-и мерным пространством.
S>> Разве текст перестает представляться в двумерном виде?
DG>Как ты в данном случае задал термин "представляться", чтобы это было не тавтологическим утверждением? При условии, что произвольное k-мерное счетное множество может быть представлено, как n-мерное счетное множество (при этом k, n произвольные натуральные числа)
Просто посмотри на книжку/газету и успокойся. Вне зависимости от гарнитуры, кода символа и т.п., от х.з. д.н.э. до сегодняшнего дня двух измерений для текста хватает. Точнее,
T: R^2->{0, 1}
ну или можешь считать что
T: R^2->R^4
если тебе нужен цвет, прозрачность и т.п.
