>Но в сторону DOS я никогда не плюну...
Злые языки поговаривают, что DOS писали на самом деле школьники, у
которых Билли всё украл. Мне это кажется правдой, потому что я (и не
только я, и Нортон, например) вижу в ней чисто детские ляпы.
А в бедных школьников и я никогда не плюну... Так, что солидарен.
>>Реализация метода Хартри-Фока на Бейсике действительно
>>выглядит смешно, и не из-за убогости Бейсика, и не из-за
>>непрофессионализма программиста, а потому, что такая его реализация не
>>научит ничему бедного студента (или почти ничему -- алгоритм-то хотя бы
>>изложен). И Досовская графика несерьёзна по той же причине, а не из-за
>>её неудобств.
>
>Так и не понятно -- почему смешно и несерьезно.
"Смешно и несерьёзно" -- излишне резко, конечно, но зато откровенно о
наболевшем...
>Но метод Хартри-Фока, простите меня,
>не метод Гаусса-Жордана, здесь надо уметь много чего... И проще
>показать идею на псевдокоде, к коему и близок бейсик, нежели
>демонстрировать свое умение работать с классами и указателями,
>забыв, для чего все это делается. А уж поняв идею, реализуй
>потом потом на чем хочется.
И да и нет. Нетривиальный алгоритм трудно проиллюстрировать/пояснить --
это очевидно. Как это лучше сделать, не знает сейчас никто. Есть разные
подходы, один хуже другого (по объективным оценкам усвоения материала
студентами). Классический условно можно назвать "нарисуем блок схему".
Наиболее распространён сейчас в школе (и у нас и за границей), в случае
нетривиальных алгоритмов почти совсем не применяется, потому что практика
показала, что сложная (в которой больше 4-х узлов) блок схема только
запутывает, а не поясняет. Отсюда имеются попытки использовать что-то
другое, более ясное. Псевдокод (или, я с Вами согласен, тот же Бейсик) --
шаг не в правильном направлении; он, по сути своей, есть почти только
словестное описание блок схемы с ограмным количеством ужастных для
сердца программиста-профессионала уловных/безусловных/потусторонних
команд переходов. Вот именно такой код смешён, потому что довольно давно
стало очевидно, что понять его студенту (и не только студенту, но и
профессионалу, которого заставили читать документацию на программный код,
написанную "по госту на блоксхемы") не стоит и пытаться. Вот только
альтернативы-то убоги. Конечно, нужно бы выписать алгоритмы вроде
алгоритма Якоби и всё тот же метод Хартри-Фока на языке объектного
подхода -- вобщем-то все понимают, что только так и правильно, да ни кто
не знает, как это сделать. Эта ситуация, в каком-то смысле, наследие
Фотранства (как явления). Те, кто должны излагать реализации этих
алгоритмов, просто не достаточно знакомы с технологиями программирования
и, что более важно, проектирования ПО. Программисты-профессионалы давно
сломали в себе подобный психологический барьер (у них небыло Фортранства,
но было Сиштство). Они давно склонились к мысли, что лучшая
иллюстрация нетривиального алгоритма -- работающая программа, которую
можно совершенствовать и с которой можно поэкспериментировать, и которая
должна как можно более походить на программы "из реальной жизни". А
объяснять детали алгоритма нужно на человеческом языке (внятно и точно,
и подробно, и с забавными картинками-каррикатурами). Но книг, в которых
авторы бы доконца смогли реализовать эти замечательные идеи, ну так мало,
что нельзя, конечно, говорить, что такой подход чем-то выигрывает по
сравнению с блок схемой, например... Но по крайней мере
программисты-практики (в отличие от научных работников) давно перестали
пояснять свои нетривиальные творения на псевдокоде -- всё UML и подобным
увлекаются. Авось и до численных методов эти веяния доберутся лет через
двести.
>Так что мне хотелось бы защитить "тупых преподов". Речь, скорее,
>должна идти о разделении труда: одни учат рассчитывать, используя
>компьютер (ведь все, в конце концов, сводится к простым арифметическим
>операциям, делай это хоть в DOS, либо в чем-то более "благородном"),
>другие учат современным технологиям программирования. А перемешать
>все это в одной бочке... Немало студентов выходят из вузов, научившись
>бойко топтать клавиши, но не отличающих синус от косинуса.
Такое разделение труда -- вещь очень заманчивая... Например, материал
курса численных методов ясно распадается на две части: теория (условия
сходимости, детали реализации, выбор метода для данной задачи) и практика
(вот задача из реальной жизни -- расчитай). Сейчас почти поголовно вторая
часть полностью отсутствует -- на лабораторных студентов в лучшем случае
заставят реализовать метод простой итерации на Паскаль (если не на
Бейсик). Так делают не по простоте душевной, конечно. Это способ объяснить
детали алгоритмов, но способ малоэффективный: например, совершенно
теряется понимание особенностей применения того или иного метода к данной
задаче. Ну, а с технической точки зрения мы имеем ситуацию, когда мы
имеем только "одних", а "другие", если они действительно могут это, то
уже нашли себе более лакомое приложение своих талантов, чем наша, прости
господи, высшая школа. Так, что, опять же, куда не денься, а читать
"вторую половину" должен тот же тупой доцент, а это не реально...
>Знаете, бывают конфеты никудышные, а завернул в красивый фантик...
>Вот и программу можно облачить в окошки, менюшки, кнопки --
>сиди и любуйся!
>А бывает, что надо просто посмотреть ход кривой, где у нее
>особенности, где она обращается в нуль, где пики...
>Промежуточный результат счета программы. Неужели OpenGL использовать,
>может, просто libplot?
Теперь понял, что "фантики" -- это "окошки, менюшки, кнопки".
Вы описали здесь обычный рабочий день вычислителя. Конечно, я согласен.
Именно graph, gnuplot, наконец, а не программа на Паскаль.
Но вот OpenGL здесь надо бы заменить другим словом. Она имеет хождение
в научной среде (по крайней мере -- в виде Open Inventor) на равне с
libplot. Это в основном благодаря физикам-эксперементаторам: им там очень
важно нарисовать ускоритель в 3D и как пучки полетели. Более менее
стандартные средства здесь есть, но достаточно универсальное им пока
слабо написать, вот и кооперируются с индустрией 3D моделирования и
комп игр.