..........................ВЫБОР ЯЗЫКА ПРОГРАММИРОВАНИЯ ДЛЯ НАУЧНЫХ РАБОТНОКОВ

....................................................Вторая редакция (переработанная) 18.01.07 г.

Юдин С. Ю. .................................................................................................................................ser@t-k.ru

....................Идея написания этой статьи возникла после того, как на одном из сайтов по физике http://physics.nad.ru/aniboard/messages/291.html я обнаружил интересный алгоритм моделирования движения тела в поле постоянной напряженности по различным направляющим. Вернее, меня заинтересовал не весь алгоритм, т.к. основа их всех одна (принцип Даламбера, если не считать квазиалгоритма с применением уравнений Лагранжа 2-го рода) и различаются они только способом определения реакций в месте соприкосновения тел. Вот именно не известный мне способ определения реакций меня и заинтересовал, но код программы был выложен на языке программирования C++, с которым я тогда не был знаком, и по этому пришлось не только просить автора Kostya прокомментировать методику на нормальном языке, но и ознакомиться с языком C++, т.к. автор программы отказался дать более подробные разъяснения, заявив, что из кода программы и так все ясно. Но мне не было все ясно и тогда я спросил у автора "почему он выложил код программы на языке C++ , а не на самом понятном для широкого круга читателей языке, а именно на BASIC, т.к. для изложения именно самой методики моделирования, а сайт посвящен именно вопросам моделирования, а не программирования, необходимо писать программу на самом понятном и широко известном языке". А автор мне объяснил, что язык BASIC это не полноценный язык, т.к. у него даже нет компилятора, а по скорости работы программ он очень сильно уступает C++ и откомпилировать программу на C++ очень легко на любом простеньком компиляторе, и все, кого он знает, программируют на C++ и по этому никто не знает этого BASIC и т.д. и т.п. Я стал объснять автору программы, что он не прав, но он со мною категорически не согласился.

Вот тогда и возникла идея написать программу аналогичную программе автора, которая в принципе является типичной при проведение научных исследований, на различных языках программирования и, проведя сравнительные испытания, написать статью, чтобы читатели сами могли убедиться, кто из нас прав. А понимая, что я не научно-исследовательский институт, и программирование является побочным видом моей научной деятельности поэтому на всех известных на сегодняшний день языках программирования я написать такую программу не смогу, то я решил сосредоточиться только на двух из них - самом простом и считающимся самым медленным, т.е. языке Бэйсик и на самом запутанном и расплывчатом и считающимся самым быстрым, т.е. на С++, а также добавить для разнообразия еще несколько промежуточных по этим параметрам языков. Естественно, лучше быть богатым и здоровым, чем больным и бедным, но иного выхода у меня нет, т.к. на свете существует необъятное количество языков программирования, о многих из которых ни я ни Вы даже и не слышали http://www.rsdn.ru/article/philosophy/languages.xml?print . Например, существует такой чудненький язык как paranoid, который является пародией на созданный Минобороны США "максимально безопасный" язык Ada. Полюбуйтесь на фрагмент кода этого языка

х: сомнительное целое;

а: мало_похоже_на массив [x..y а_может_быть z] каких_нибудь символов;

L: безнадежно_поврежденный список слишком_маленьких целых;

x ТОЧНО 3;

x ЧЕСТНОЕ_СЛОВО 3;

x МАМОЙ_КЛЯНУСЬ 3;

ЕСЛИ y ЧТО_ТО_ОКОЛО 8 ...

ПРИ_МАЛЕЙШЕМ_ПОДОЗРЕНИИ_ЧТО x < 100...

СБЕГАЙ_КА_ПОИЩИ имяпроцедуры;

Конечно это шутка, но и серьезных языков программирования, пригодных для написания программ для научных исследований, существует все равно слишком меного, чтобы хотябы кратко упомянуть о них. По этому, чтобы исследование не затянулось на неограниченный срок, я ограничелся всего несколькими языками - Basic под DOS, Visual Basic 6.0, Visual Basic NET, C++ и Turbo Pascal. По мере написания программ на разных языках я выкладывал на своей домашней странице http://ser.t-k.ru (http://ser.tele-kom.ru) и на ее зеркале http://modsys.narod.ru как исходный код программ, так и уже откомпилированные файлы, а также снимки с экрана (скриншоты) внешнего вида программ, который очень отличался от внешнего вида программы code.cpp, написанной Kostya (см. рис.1), т.к. я добавил в эти программы возможность изменения начальных данных и режима работы программ и убрал вращение изображения вокруг вертикальной оси. А сейчас, когда все (запланированные мною) программы, выполняющие одну и ту же задачу, которые я назвал Spusk, и в которых за основу алгоритма взят алгоритм программы code.cpp, уже выложены на моей домашней странице, я подведу некоторые итоги по проделанной работе, а затем сделаю оценку примененным мною языкам программирования и некоторым другим для решения научных задач по нескольким критериям, а именно

1 - простота написания программ и понятность языка программирования для широкого круга пользователей

2 - возможности предоставляемые языком для решения разнообразных задач

3 - простота компиляции программ и установки их на различные компьютеры пользователей

4 - скорость работы программ

Рис.1. Внешний вид программы code.cpp

А начну я, пожалуй, с последнего критерия, который почему то обычно считается главным критерием при оценке различных языков программирования, хотя я считаю его самым незначимым при выборе языка программирования для научных работников, т.к. им надо не создавать программы для их коммерческого использования, а проводить на этих программах различные вычислительные эксперименты. И при этом им не только приходится самим писать эти программы, но и обсуждать со своими коллегами работу этих программ именно в плане конкретного научного исследования, а не программного кода как такового, т.к. владение конкретным языком программирования для научного работника является второстепенным требованием, в отличие от профессиональных программистов, а основным требованием к научному работнику является хорошее знание той области знаний, которой он занимается, используя возможности предоставляемые компьютерами. И, следовательно, изучение языка программирования и написание программ не должны занимать у него много времени. А отсюда главное требование к языку - простота, как изучения языка, так и написания программ на этом языке.

При этом возможности, предоставляемые языком программирования, должны обеспечить решение широкого круга задач и здесь специальные языки программирования, созданные специально для решения какого то узкого класса задач, хотя и могут решить какую то задачу более эффективно, чем универсальные языки, конечно же менее предпочтительны, т.к. при решение какой то научной проблемы приходиться решать порою множество очень разных задач, и изучать для каждой из них свой язык программирования это очень не рационально. Но, говоря о возможностях языка для решения широкого круга задач, я имею ввиду именно научные задачи, а не задачи защиты программ от взлома или создание программ-шпионов, которые отслеживают все действия пользователя компьютера, и которые конечно же лучше решать на С++ или Delphi, т.к. язык Visual Basic 6.0 не может выполнять низкоуровневые команды такие как, например, работа со стеками. Но ведь для решения научных задач совершенно не надо знать в какой последовательности данные помещаются в стек памяти и в какой последовательности потом извлекаются от туда. Да и вообще для этих целей, например, при защите программ от взлома лучше использовать не языки высокого уровня, а ассемблер. По этому язык, который нужен научному работнику, не должен быть перегружен различными специальными возможностями, которые совершенно не нужны при решение научных задач, т.е. для проведения математических расчетов. Например, возможности предоставляемые применением различных API функций не являются насущной необходимостью для научного работника. Ну зачем ему копаться во внутренностях своего компьютера, чтобы узнать какой у него заводской номер у винчестера или узнать имя пользователя компьютера на котором он сам и работает. И хотя язык Visual Basic 6.0 позволяет использовать API функций, но любую программу можно написать на нем и без использования этих функций и достаточно знаний только самого языка и по этому для научных работников более предпочтительным следует признать хоть и не такой быстрый, но зато очень простой язык, который не требует больших знаний по работе компьютера или операционной системы.

Да, действительно, иногда встречаются такие задачи, когда надо прогнать на компьютере их решение несколько сотен раз и при этом один прогон может составлять несколько часов машинного времени. В таких случаях имеет смысл говорить о скорости работы программ, написанных на разных языках программирования, но чаще всего приходиться иметь дело с задачами, решение которых на современных компьютерах занимает от нескольких секунд и до десятков минут. А при таком раскладе скорость работы программы не имеет практически никакого значения, т.к. только изменение начальных данных при проведение нового эксперимента и считывания полученных данных (все равно откуда: сразу с экрана, из файла или с распечатки) занимает у пользователя от нескольких десятков секунд до нескольких десятков минут, т.е. практически сопоставимо со временем работы самой программы. И даже в том случае, если Вы при работе программы за счет скорости языка программирования, сэкономите несколько дней или даже месяцев, это еще не критерий для выбора языка программирования по скорости работы программы, т.к. написание, отладка и тестирование программы средней сложности может тоже составить от нескольких дней до нескольких месяцев (не говоря уже о сложных программах). А так как научные работники не являются профессиональными программистами, то написание и отладка программы могут затянуться вообще на неограниченный срок. Таким образом, в 95% (если не 99%) случаев для научных работников основным критерием является простота языка программирования, а не его скорость.

А при работе над различными версиями программы Spusk мне попалась на глаза статья Виталия Крячко "О бедном Basic замолвите слово!" http://www.vbnet.ru/articles/Showarticle.aspx?id=220 , в которой приведены очень интересные данные по быстродействию различных языков программирования и много данных именно по различным вариантам языка BASIC, которые никак не вязались с общепринятым мнением, что язык BASIC очень медленный язык. И поэтому возникла также идея найти какие то методы, позволяющие повысить быстродействие программ, написанных на языке Visual Basic 6.0, который позволяет очень быстро написать программу с прекрасным визуальным интерфейсом, но работает частенько медленнее многих других языков (хотя из данных приведенных в таблице 1, взятой из вышеприведенной статьи при работе простейшего бенчмака с нижеприведенным кодом, этого не скажешь). А вот в исследование http://itc.ua/print.phtml?ID=15800 язык Visual Basic 6.0 после первого теста на быстродействие даже был снят с дальнейших испытаний из-за очень маленькой скорости работы. По этому пока просто ознакомьтесь с данными, приведенными в таблице 1.

Rem BENCHMARK

Print "НАЧАЛО" : start = Timer : K = 0

Dim M(5)

50: K = K + L : A = K / 2 * 3 + 4 - 5 : GoSub 140

For L = 1 To 5 : M(L) = A : Next L

If K < 90000000 Then GoTo 50

finish = Timer - start : Print "КОНЕЦ - " + Str$(finish)

INPUT ; q : End

140: Return

Таблица 1. Результаты работы бенчмака

* Данные получены для PowerBASIC v2.10 в операционной системе DOS Windows XP sp2

** Данные получены для TurboPascal v7.0 в операционной системе DOS Windows XP sp2

Как следует из этих данных, по быстродействию для решения чисто технических задач (в режиме бенчмака), где требуется только ввести данные, произвести математические вычисления и считать с дисплея результат, явные фавориты C++ или Pascal (Delphi ) даже уступают некоторым версиям BASIC и стоят практически в одном ряду с самой распространенной версией BASIC, а именно Visual Basic 6.0. Но здесь не все так однозначно, т.к. многое зависит еще и от Вашего компьютера и от операционной системы, которая на нем установлена. И особенно это заметно на примере этого теста для различных вариантов языка BASIC, многие из которых создавались по компьютерным меркам уже давно и, следовательно, создавались совершенно для других компьютеров и других операционных систем. Например, я на своем Пентиуме с той же операционной системой и только с частотой 2 GHz (у Виталия Крячко было 1,8 GHz) прогнал такой же бенчмак для некоторых вариантов компиляторов BASIC и для компилятора Visual C++ v6.0, а также TurboPascal v7.0 (предшественник Delphi) и получил совершенно другие данные, которые добавил в таблицу в скобках, а в знаменателе указал еще и размер моего файла. И полученные мною данные подтверждают не однозначность результатов тестирования языков по простейшим бенчмакам на каком то конкретном комрьютере, т.к. у Крячко частота процессора была только немного меньше чем у меня, а время получилось значительно меньше, чем у меня для программ написанных под DOS, но значительно больше для программ написанных под Windows.

А вот несколько иной по структуре простейший бенчмак, который выложил Sharp на сайте по программированию VBNet http://www.vbnet.ru/forum/show.aspx?id=125800&page=1, показал совсем другие результаты. Время работы на FreeBasic было 4,2 сек, а на VisualC++ 2,1 сек. Откомпилированные фаилы и исходники программ, по этому тесту я поместил в тот же архив TestBench2.rar, что и файлы со всеми выше рассмотренными бенчмаками, но в отдельные папки Test2FB Test2VSi. Более того, если мы просто изменим немного структуру нашего бенчмака, то тоже можем получить заметную разницу во времени работы программы. Так во 2-м варианте приведенного выше текста бенчмака я заменил переход к метке 50 на обращение к подпрограмме на метке 100, а в 3-ем варианте выполнил все вычисления в цикле. При этом я сделал в подпрограмме на метке 140 подсчет обращений, чтобы компилятор не выбросил эту функцию как пустую. И эти три варианта для языка FreeBasic показали результаты 0,71 - 0,78 - 0,73 сек, а для Visual Basic 6.0 1,73 - 1,73 - 1,61 сек.

K = 0 : While K < 90000000 : GoSub 100 : Wend

100: K=K+L: A=K / 2 * 3 + 4 - 5 : GoSub 140 : For L=1 To 5: M(L)=A: Next L : Return

140: C = C + 1 : Return

K=0: While K< 90000000: K=K+L: A = K/2*3+4-5: GoSub 140: For L=1 To 5: M(L)=A: Next L: Wend

140: C = C + 1 : Return

Как видим, даже при незначительном изменение кода в этом простейшем бенчмаке, мы можем получить значительный разброс во времени работы программ. Таким образом, однозначно говорить о том, что программы, написанные на C++, работают всегда быстрее, сравнивая их с программами на Free Basic или даже на Visual Basic по результатам простейшего бенчмака не корректно. Да вдобавок ко всему и код этого бенчмака, мягко говоря, далек от совершенства. По этому сравнивать по быстродействию два языка для применения их в научных исследованиях надо не на абстрактном бенчмаке, а на программе для проведения типового научного исследования. При этом сам код, в программах написанных на разных языках, может существенно отличаться, т.к. нас интересует конечный результат, а не то с помощью каких конкретных операторов написана программа на том или ином языке, но сам математический алгоритм работы программ при их сравнение должен быть один и тот-же, т.к., как будет показано ниже при работе программы SpuskVB6 с разными алгоритмами решения дифференциальных уравнений (Эйлера и Рунге-Кутта), это может в разы повлиять на время работы программ. При этом большая часть таких программ будет иметь не только одинаковый синтаксис, но и одинаковую семантику, т.к. все математические вычисления в разных языках будут выглядеть примерно одинаково. Хотя в конкретной программной реализации алгоритма могут появиться существенные отличия. Например, язык С++ может работать со ссылками на функции, а Visual Basic 6.0 нет и по этому работа с функциями описывающими направляющие в этих программах может быть организована принципиально разными способами.

Проведем сравнительные испытания программ SpuskSi, написанной на C++, SpuskPB, написанной на PowerBASIC v2.10, SpuskTP, написанной на Turbo Pascal v7.0, SpuskVBnet, написанной на Visual Basic NET и SpuskVB6, написанной на Visual Basic 6.0 и результаты занесем в таблицу 2. Все эти программы, по мере их написания, я выкладывал на своей домашней странице, а сейчас я их все поместил в один архив Spusk.rar. В этих программах данные выводятся на экран после того как программа в режиме бенчмака выполнит NC0 шагов решения задачи, а компьютеры чаще всего для решения таких задач, где требуется многократное выполнение однотипных действий (групп действий) и применяются в научных исследованиях (решение дифференциальных уравнений численными методами, применение метода итераций, ежедневный обсчет технико-экономических показателей работы предприятия при моделировании и т.д.). При этом качество вывода изображения на экран при малых значениях NC0 не ухудшается, т.к., если задача с шагом решения 0,001 сек решается за смоделированное время 2 сек, то, следовательно, необходимо выполнить 2000 шагов решения и при размерах графического изображения в 200 пикселей изображение сдвинется на 1 пиксель только за 10 шага решения и по этому нет смысла выводить изображение на экран чаще чем через 10 шагов решения. Для программ SpuskSi, SpuskPB и SpuskTP вывод графики происходит не в объект PictureBox а потом на дисплей, как в программах SpuskVBnet и SpuskVB6, а сразу на дисплей и по этому выводятся не все точки, а только одно значение из NC0 и вследствие этого уже при NC0=256 выводится меньше 10 точек, что не позволяет получить всю информацию о процессе. А для программ SpuskVBnet и SpuskVB6 изображение выводится на экран полностью, но кусками и при больших значениях NC0, например, при NC0=50 скачки становятся заметными, но если время решения при этом сокращается до 1 сек, то не возможно заметить то ли оно выводится кусками, то ли непрерывно.

Таблица 2. Результаты тестирования программ Spusk при шаге решения tau=0.001 сек

Как видно из приведенных результатов, время работы всех программ за исключением SpuskSi при увеличение NC0 сокращается и очень значительно, но до определенного предела. При чем для программ SpuskVBnet и SpuskVB6 при малых значениях NC0 время работы уменьшается ровно в NC0 раз. А для программы SpuskSi это сокращение времени ничтожно при любых значениях NC0. Попробуем разобраться с чем это связано. Что касается такого аномального поведения программы SpuskSi, то я быстро нашел причину. Связано это было с тем, что при переделке кода исходной программы code.cpp я отключил вращение осей, но не обратил внисание на то, что для этого режима (при вращение) надо было постоянно на каждом шаге решения стирать старое изображение и рисовать полностью заново и оси и направляющие, а не только выводить новую точку, и по этому, т.к. эта операция в коде осталась, а занимала она много времени, значительного ускорения работы программы с увеличением NC0 не происходило. После того, как изображение стало полностью обновлятся только при начале работы программы, и программа SpuskSi стала с увеличением NC0 работать значительно быстрее. Что касается программ SpuskPB, SpuskTP, SpuskVBnet и SpuskVB6, то их значительное отставание от программы SpuskSi при малых значениях NC0, чего не было при работе бенчмака (таблица 1), т.е. при выполнение только математических преобразований, можно было бы объяснить большими затратами времени на вывод графики, но не понятно почему в программах SpuskVBnet и SpuskVB6 время работы при малых NC0 уменьшается ровно на значение NC0 как будто бы на математические вычисления время не затрачивается вовсе.

Принципиальным отличием этих двух программ от остальных является то, что после завершения каждого цикла вычислений равного NC0 шагов решения, новый цикл начинается при срабатывание таймера в то время как в программах SpuskPB и SpuskTP все решение задачи происходит в режиме бенчмака, т.к. остановка программы осуществляется по нажатию клавиши, а это событие обрабатывается самим циклически выполняемым кодом. В программе SpuskSi тоже можно после каждого цикла из NC0 шагов решения перехватить управление у программы, нажав клавишу или кликнув мышкой, т.к. после каждого цикла вычислений функция WinMain, если не будет никаких действий пользователя, автоматически начнет новый цикл расчетов, а если будут какие то действия, то сообщения от них поступят в очередь сообщений и после их обработки WndProc начнется новый цикл. А в программах SpuskVBnet и SpuskVB6 эта функция, которая бы циклически обрабатывала сообщения, отсутствует и поэтому, если мы запустим эти программы в режиме бенчмака, то чтобы программа реагировала на наши действия во время работы нам надо будет, как в программах SpuskPB и SpuskTP вставить в сам циклически выполняемый код программы операторы перехвата сообщений от различных клавиш и мышки. Но данное решение противоречит принципам работы программ с визуальным интерфейсом, где все действия выполняются по клику мышки по определенной кнопке на форме программе или по пункту меню. И хотя можно написать код, который бы как в программе SpuskSi циклически обрабатывал сообщения операционной системы, но это сильно усложнит код программы. Поэтому обычно после завершения каждого цикла вычислений работа таких программ с визуальным интерфейсом прекращается, чтобы операционная система могла обработать сообщения поступившие от пользователя, а затем новый цикл вычислений начается по срабатыванию таймера и обе программы SpuskVBnet и SpuskVB6 работают именно по этому принципу.

Интервал срабатывания таймера в обеих программах я установил на 1 мс и, следовательно, за 2000 шагов решения при NC0=1 время работы программ должно было увеличиться максимум на 2 секунды, но мы видим, что это не так. Тем более, что в этих программах графическая информация выводится полностью хотя и кусками и, следовательно, время работы программ не должно было значительно изменяться с изменением NC0, но именно в этих программах мы видим максимальное влияние величины NC0 на время работы программы. Попробуем изменить величину интервала срабатывания таймера и посмотрим, как это отразится на времени работы программы SpuskVB6 с использованием программы SpuskVB6MM. Данные по этому эксперименту представлены на рис.2, где по оси абсцисс отложен интервал срабатывания таймера в мс, а по оси ординат время работы программы в сек. Как мы видим, при разных значениях NC0, до величины интервала срабатывания таймера равного 15,5 мс время работы программы не изменяется, а затем резко увеличивается и опять не изменяется в течение длительного времени. Из этого можно сделать вывод, что таймеры срабатывают у нас не через 1 мс, как мы установили, а через 15,5 мс и это время является минимальным шагом для стандартных таймеров WindowsXP и при увеличение времени работы цикла из NC0 шагов до 15,5 мс таймер будет опять запускать программу при первом же срабатывание, но, если задать интервал срабатывания таймера от 16 мс до 31 мс, то он сработает только, когда пройдут два минимальных интервала и т.д. Если мы умножим теперь 15,5 мс на 2000 шагов решения, то мы и получим примерное время работы наших программ SpuskVBnet и SpuskVB6 при NC0=1, т.е. 31 сек. Таким образом, чтобы устранить этот явный недостаток программ SpuskVBnet и SpuskVB6 и можно было бы говорить о быстродействие языка программирования, а не о времени срабатывания таймеров, необходимо как то по другому в этих программах организовать выполнение циклов вычислений.

Рис.2 Изменение времени работы программы SpuskVB6MM в функции от установленного интервала срабатывания таймера при NC0=1, 2 и 4 шага решения и tau=0.001 сек.

Рассмотрим несколько возможных вариантов режимов организации циклов вычислений в программе SpuskVB6 и для сравнения организуем, на сколько это возможно, подобные режимы в программе SpuskSi, а чтобы поточнее определить разницу во времени работы разных вариантов программ, т.к. их время работы мы определяем опять таки с применением системного таймера Windows, который работает с точность 15,5 мс, мы уменьшим шаг решения и примем его tau=0.00001 сек, что увеличит общее число шагов решения и, следовательно, увеличит общее время решения. Конкретно в программе SpuskVB6MM реализуем три режима организации циклов вычислений. Во-первых, оставим режим по стандартному таймеру Visual Basic, во-вторых организуем цикл по мультимедийному таймеру timeSetEvent, который запускается в отдельном потоке и позволяет получить для моего компьютера интервал в 1 мс, а в третьих, чтобы не организовывать сложный цикл обработки сообщений, как в программах написанных на С++, просто используем оператор DoEvents, который, кроме того что возвращает значение открытых окон на компьютере, еще и отдает управление операционной системе, чтобы она могла сама обработать сообщения накопившиеся в ее очереди сообщений, а затем опять возвращает управление себе и работа программы продолжается. В программе SpuskSiMM также оставим, как и было, цикл обработки сообщений в WinMain и добавим два режима работы по таймеру. Обработку сообщений от стандартного таймера Windows, т.е. SetTimer разместим там же, где программа обрабатывает все сообщения, т.е. в WndProc, а мультимедийный таймер timeSetEvent также, как и в SpuskVB6MM, запустим в отдельном потоке.

Таблица 3. Результаты тестирования программ SpuskMM, т.е. при разных режимах организации циклов вычисления и шаге решения tau=0.00001 сек

Как видно из данных таблицы, для программы SpuskSiMM введение таймера SetTimer приводит к тем же последствиям, что у нас было в программе SpuskVB6, т.е. время работы при NC0=1 увеличивается до 32 сек, и, следовательно этот вариант программам написанным на С++ явно не подходит, т.к. они прекрасно работают и без этого таймера. А вот в программах, написанных на Visual Basic, этот метод организации циклов вычислений в принципе можно применять, но только в том случае, когда у нас время выполнения кода из NC0 шагов решения значительно больше 15,5 мс, т.е. в тех случаях, когда программы работают часами, а не секундами, как в нашем примере, и при общем количестве шагов решения в несколько тысяч в таких программах время решения задачи увеличится всего на несколько десятков секунд, что при 1 или 5 часах работы программы совершенно не существенно. Да и в наших программах при NC0=10000 мы видим, что при любом режиме организации циклов вычислений время работы программ получается практически одинаковым, т.к. при общем числе шагов решения 200000 увеличение времени работы программ даже от большого интервала срабатывания системного таймера составит всего 300 мс (15,5 * 20).

Применение мультимедийного таймера в программе SpuskSiMM опять таки ничего нам не дает, кроме головной боли, т.к. во-первых цикл обработки сообщений в WinMain, как работал, так и работает и запуск мультимедийного таймера (пусть даже и в отдельном потоке) ничего здесь не улучшает, а только немного ухудшает показатели. Связано это с тем, что хоть этот таймер и запущен в отдельном потоке, но работает то он на том же процессоре, что и наша основная программа, т.к. компьютеры то у нас в основном однопроцессорные, и по этому он только отнимает время у нашего процесса. Да и потом, хоть он и срабатывает через 1 мс, но это тоже время, а в цикле WinMain вообще нет никаких интервалов в процессе обработки сообщений. Вот если бы у нас был многопроцессорный компьютер, то мы могли бы для некоторых задач извлечь пользу из этого метода, когда нам надо было бы синхронизировать потоки решающие нашу задачу по частям на разных процессорах. Для программы SpuskVB6MM такой метод организации циклов вычислений дает существенный выигрыш для нашей программы при малых значениях NC0, но при больших значениях NC0 выигрыш от сокращения интервала срабатывания таймера перекрывается затратами времени на работу самого таймера и в результате общее время работы программы увеличивается. Вот если бы этот таймер был запущен на другом процессоре, чтобы не отнимать время у процессора, где решается наша задача, то тогда выигрыш во времени (правда не большой) был бы и при больших значениях NC0, но, как мы рассмотрели выше, в этом случае при времени работы программы в несколько часов нам бы это практически ничего не дало (кроме случая решения задачи по частям на разных процессорах).

Таким образом, для программы SpuskSiMM организация циклов вычислений в цикле обработки сообщений WinMain является наилучшим вариантом и улучшать ничего в программе SpuskSi мы не будем. А вот для программы SpuskVB6 у нас есть некоторая альтернатива, т.к. два метода организации циклов вычислений по мультимедийному таймеру и по оператору DoEvents показывают более менее сопоставимые результуты, хотя все таки режим по DoEvents показывает результат немного получше. Я бы лично, кроме каких то особых случаев, когда это Вам принципиально надо, не советовал организовывать работу циклов вычислений по мультимедийному таймеру запущенному в отдельном потоке. Да и многие авторы учебных пособий по программированию не советуют применять многопоточность в программах написанных на Visual Basic 6.0. А у меня, например, были проблемы при отладке программы, когда я ее запускал в IDE Visual Basic. Работала она нормально, но после того, как я закрывал программу, Windows выдавала сообщение об ошибке и вместе с закрытием самой программы закрывала и IDE. Таким образом, для дальнейшего тестирования программ я буду в программах SpuskVBnet и SpuskVB6 использовать организацию циклов вычислений с использованием оператора DoEvents, который хоть и позволяет получить результат чуть похуже, чем цикл обработки сообщений WinMain в программе SpuskSi, т.к. кроме передачи управления операционной системе, которая обрабатывает все сообщения находящиеся в очереди сообщений, а не те, которые мы сами выбрали для обработки в WndProc, у нас оператор DoEvents еще и пересчитывает все открытые окна, но зато такой метод значительно упрощает сам код программы и к тому же не надо вникать в тонкости работы Windows с ее приоритетами потоков, когда Windows может даже если Вы не включили в WndProc обработку какого-то события все равно его обработать если у него будет выше приоритет и т.д. и т.п. Т.е. данный метод позволяет не задумываться о том, как работает операционная система, что очень важно для научных работников, которым эти тонкости знать не обязательно.

Теперь переделаем наши программы SpuskSi, SpuskVBnet и SpuskVB6 с учетом выявленных у них недостатков и назовем их SpuskSiM, SpuskVBnetM и SpuskVB6M и для более детального анализа выполним их так, чтобы можно было выводить через NC0 шагов решения отдельно графическую информацию и текстовую. При этом в программах SpuskVBnet и SpuskVB6 уберем вывод всей графической информации кусками, а сделаем также как и во всех остальных программах, чтобы на графики выводилась только каждая NC0-я точка. И теперь вид, например, программ SpuskSiM и SpuskVBnetM, при их работе будет такой, как изображено на рис.3 и рис.4.

Рис.3. Внешний вид программы SpuskSiM во время работы.

Рис.4. Внешний вид программы SpuskVBnetM во время работы.

В программе SpuskTP после переделки практически ничего не изменится, кроме раздельного вывода данных, а вот программу SpuskPB, т.е. откомпилированную PowerBASIC v2.10 заменим программой SpuskFBM, т.е. откомпилируем ее компилятором Free Basic v 0.16, который показал отличный результат на бенчмаке, но, когда я писал программы Spusk и выкладывал их на своей домашней странице, я не был знаком с этим компилятором и по этому в предыдущих тестах использовалась программа SpuskPB. В принципе сам текст кода этих программ SpuskPB, SpuskFB а также SpuskQB практически один и тот же и по этому сам язык программирования не изменился, но теперь мы будем использовать более современный компилятор, который позволяет получить 32 битный код, т.е. под DOS эта программа работать не будет. Для сравнения текста кода программ SpuskQB и SpuskFB можете посмотреть файл SpuskQB_FB.bas в архиве TestSpusk.zip, где я специально отметил пару строчек, где внес изменения в текст кода программы SpuskQB. В таблице 4 теперь будут приведены результаты тестирования программ, что использовались при тестировании в таблице 2, но которые к своему названию добавили теперь по одной букве M. А для программ SpuskTPM и SpuskFBM я предусмотрел также и чисто текстовый режим работы в консоле (см. рис.5), который восновном и использовался раньше при проведение научных расчетов и который может быть полезен, когда нам надо получить только конечный результат, но при отладке программ и при проведение поисковых экспериментов желательно все же для лучшего осмысления наблюдать данные не только в текстовом виде, но и в виде графиков.

Рис.5 Работа программы SpuskFBM в текстовом режиме.

Таблица 4. Результаты тестирования программ SpuskM при разных режимах вывода информации и шаге решения tau=0.00001 сек

Как видно из приведенных данных, программа SpuskSiM стабильно показывает хорошие результаты. Правда теперь у нее появился конкурент, т.к. при малых значениях NC0 гораздо лучше результат у программы SpuskFBM, а наилучший результат при малых значениях NC0 показывает программа SpuskTPM, но только в текстовом режиме и по этому воспользоваться этим преимуществом можно будет только при очень большом времени работы программы. Объясняется это тем, что, например, для нашей программы данные будут выводиться на экран так быстро, что мы их просто не успеем разглядеть. Не плохие результаты показывает SpuskTPM и в графическом режиме, но только если при этом не надо выводить на экран и текстовую информацию. К тому же SpuskFBM в любом случае в графическом режиме показывает результаты лучше чем SpuskTPM и по этому в дальнейшем программу на TurboPascal мы рассматривать не будем. Хотя возможно, что программа на Delphi, т.е. на Pascal под Windows, и исправит этот недостаток программы SpuskTPM и если кто то напишет такую программу SpuskDelM, то я ее обязательно протестирую и в следующих редакциях статьи вернусь к этому вопросу. А пока я оставлю в следующей таблице 5, где будут данные по еще более усовершенствованным версиям этих программам, для нее свободную колоночку, также как и для программы SpuskVSiM, если кто-то надумает написать программу на VisualC++ .

А возможно кто то возьмется и за доработку программы SpuskSiM, т.к. я не являясь специалистом по языку С++ внес в исходный код программы code.cpp, написанной Kostya, только минимальные изменения, чтобы ее можно было функционально сравнивать с другими программами и убрал код, который сильно увеличивал время вычислений, а например, функцию Transform, которая после отключения вращения осей стала лишней, я не стал удалять, чтобы не запутываться с параметрами по ссылкам. Но эта небольшая функция не может сильно повлиять на результаты теста и поэтому программу SpuskSiM вполне можно сравнивать с программами SpuskVBnetM и SpuskVB6M, т.к. в них в свою очередь есть много других функций, которых нет в программе SpuskSiM. И если, например, из программы SpuskVB6M удалить все функции, которых нет в SpuskSiM, то мы получим, особенно при малых NC0, значительный выигрыш по времени в программе SpuskVB6Mminus. Буду также очень признателен, если кто-то сможет устранить очень медленный вывод графики в программе SpuskVBnetM. Как видно из данных таблицы, сам код в этой программе выполняется гораздо быстрее, чем в однотипной программе SpuskVB6M, а время вывода изображения на дисплей в окнах TextBox, примерно такое же, как и у программы SpuskVB6M, но вывод изображения в окно PictureBox занимает времени в несколько раз больше.

Первоначально я думал, что это связано именно с процессом записи изображения на картинку, а не вывода его на дисплей и попробовал несколько других методов вывода изображения в PictureBox, которые предложил EROS на сайте по программированию VBNet. Замена метода вывода точек gg.FillRectangle на картинку bmp с последующим помещением картинки в PictureBox на метод bmp.SetPixel, что является вполне логичным, т.к. нарисовать один пиксель вместо квадрата со стороной в один пиксель гораздо проще, ни к чему не привела (при самом чувствительном к такой замене режиме работы NC0=10, kodG=1, kodT=0). При этом время работы программы SpuskVBnetMpixel (см. в архиве TestSpuskM2.rar) не только не уменьшилось, а наоборот даже увеличилось на 16 (шестнадцать) процентов, но вызвано это увеличение было тем, что мне пришлось немного увеличить размер изображения bmp, т.к. при работе этого метода программа давала ошибку, если координаы точек выходили за пределы изображения. А вот время затраченное на вывод самого изображения в PictureBox с выводом его на дисплей после окончания работы программы в режиме бенчмака, когда во время работы управление операционной системе для этого не передавалось, оказалось меньше, а конкретно 2,3 сек против 2,6 сек и сопоставимым со временем работы других программ. Некоторые сомнения относительно некорректной работы оператора DoEvents развеяла работа программ SpuskVBnetM и SpuskVBnetMpixel в режиме бенчмака с принудительным выводом изображения на дисплей методом Picture1.Refresh, т.к. время работы оказалось 70 и 82 сек, что только немного меньше времени при работе с циклами по DoEvents (соответственно было 77 и 87 сек).

Если нам не надо выводить на экран весь график изменения какого-то параметра с разверткой по координате или по времени (осциллограмму), а достаточно только одной движущейся на картинке точки, то можно применить и метод вывода изображения Paint. Однако, как показал эксперимент при работе программы SpuskVBnetMpaint, и такаой вывод изображения в PictureBox не дал положительного эффекта (время работы программы стало 75 сек). Но я думаю, что здесь должно быть какое-то решение, потому, что не должны все языки технологии NET, использующие, примененные мною методы, работать так медленно с графикой, т.к. эта технология является самой современной, но сам я это решение найти не могу. Поэтому, если у кого-то есть претензии почему вот здесь программа написана не идеально или почему Вы не сравниваете еще и программу вот на этом языке программирования, то милости просим - исправте код или напишите программу на своем любимом языке и пришлите, а я ее протестирую и изложу результаты в следующей редакции, а пока будем довольствоваться при выборе оптимального языка для научных работников теми данными, что у меня есть.

А остались у нас три Бэйсика, два из которых заметно уступают в быстродействие и чистый С++, который сильно уступает остальным по критерию простоты и удобства работы. Причем программу на FreeBasic из дальнейшего конкурса программ на самую оптимальную для научных работников все же прийдется исключить, не смотря на блестящие результаты по быстродействию, т.к. быстродействие, как я уже писал выше, не является основным критерием для выбора языка программирования для научных работников. А главными критериями здесь являются простота самого языка и удобство работы с программой. Что касается простоты, то к Free Basic нет никаких претензий и здесь он пожалуй самый идеальный кандидат, т.к. полностью поддерживает синтаксис самого простого языка QuickBasic и в то же время при желание написать более сложную программу может запросто работать с функциями API и даже работает со ссылками на функции, чего кстати не может Visual Basic 6.0. Но у него есть один недостаток, если Вы пишите обычное консольное приложение, а с оконным будут такие же сложности как у С++, чего, т.е. сложностей, категорически нельзя допускать, то очень не удобно изменять начальные данные перед каждым новым экспериментом. Идеально в этом плане подходят визульные языки, которые позволяют очень быстро нарисовать форму программы с множеством различных переключателей, чекбоксов, текстовых окошек и т.д. для быстрого изменения начальных данных и при этом все данные на протяжение всего эксперимента остаются перед глазами. Но как язык для обучения программированию и для демонстрации работы каких то простейших методик в виде программ, конечно же язык BASIC, как самый простой и в том числе FreeBasic, не заменим. Впрочем, и Visual Basic 6.0, если не использовать все его возможности, тоже подойдет для этих целей, т.к. в этом случае его код практически ничем не будет отличаеться от кода бэйсиков созданных для работы под DOS также как и от кода FreeBasic.

Но, чтобы окончательно закончить тему о быстродействие различных языков программирования, давайте немного остановимся на некоторых уловках, которые могут повлиять на этот показатель работы программ, кроме уже рассмотренного мною метода NC0, который я успешно применяю уже лет 20-ть. Например, всем известно, что язык Visual Basic 6.0 требует при работе программ библиотеку msvbvm60.dll, которая выполняет роль виртуальной машины, которая взаимодействует с другими элементами операционной системы, и как я заметил, когда в коде встречаются упоминания о визуальных элементах, то это значительно тормозит работу программы из за неэффективной работы этой виртуальной машины. Давайте по возможности уберем из критичного кода программы SpuskVB6M, т.е. кода выполняемомого многократно, эти упоминания и заменим их аналогами, которые бы выполняли ту же функцию, что и визуальные элементы. Например, в критичном коде программы SpuskVB6M в самом начале функции Param есть такой код

For i = 1 To 4

If i = 1 And Check1.Value = 0 Then GoTo 32

If i = 2 And Check2.Value = 0 Then GoTo 32

If i = 3 And Check3.Value = 0 Then GoTo 32

If i = 4 And Check4.Value = 0 Then GoTo 32

При этом визуальный элемент Check1.Value принимает только два значения 0 или 1. Давайте заменим эти визуальные элементы кода просто переменными, которые тоже будут у нас принимать значение 0 или 1. Более того, т.к. эта сложная конструкция If...And...Then нужна, чтобы связать свой чекбокс с номером направляющей, нам выгодно будет задать массив переменных kodCheck(5) и теперь мы можем записать не только код без упоминания визуальных элементов, но в нашем случае и заменить 4-е строчки кода одной

For i = 1 To 4

If kodCheck(i) = 0 Then GoTo 32

Как видно из данных в таблице 5, быстродействие программы SpuskVB6MV при больших значениях NC0 увеличилось более чем в 3 раза и заметно увеличилось при малых значениях NC0 (правда частично за счет замены 4-х строк кода одной). Но вот аналогичная замена еще в двух местах менее критичного кода (см. исходник), не приводит к положительному результату, а в некоторых случаях время работы программы наоборот увеличивается, что лично для меня вообще не понятно. Поэтому применяйте такую замену осторожно и внимательно следите, как это отразилось на времени работы программы. А вот для программы SpuskVBnetMV такая замена привела к очень незначительному уменьшению времени работы программы. И вызвано это не заменой визуальных элементов их аналогами, а только заменой 4-х строчек кода одной, т.к. теперь все языки NET технологии работают в принципиально другой виртульной машине с одной большой библиотекой Common Language Runtime (CRL) что практически равнозначно работе с другой операционной системой. Теперь CRL при первом запуске программы переводит промежуточный IL код программ в native- код и дальше уже этот код работает самостоятельно, т.е. не обращается к виртуальной машине.

Есть и еще одна принципиальная возможность повысить быстродействие программ написанных на Visual Basic 6.0. Это вынос всего критичного кода, т.е. математической модели, в библиотеку DLL, которую надо написать на Free Basic, т.к. компилятор этого языка, согласно данным таблицы 1, показал очень хороший результат при работе в режиме бенчмака с чисто математическими преобразованиями. Причем сам код программы, описывающий математическую модель, остается при этом неизменным и только надо будет в начале функции, расположенной в DLL, добавить немного кода для принятия исходных данных для начала расчета и в конце функции для отправки полученных данных в основную программу. И, как мы видим из данных приведенных в таблице 5, для этого варианта программы SpuskVB6MVdllFB скорость работы программы на некоторых режимах стала даже выше, чем у программы SpuskSiM и особенно это заметно на самом нужном при проведение вычислительных экспериментов режиме (после отладки модели), т.е. когда kodG=1 и kodT=0.

Таблица 5. Результаты тестирования программ SpuskM оптимизированных на скорость работы

Есть конечно же и множество других методов повышения быстродействия программ начиная от элементарной замены кода b=a^2 на b=a*a до более сложных вплоть до изменения самой методики расчета. Я, например, после того как Kostya в упомянутой в начале статьи теме написал, что "Предложения по усовершенствованию алгоритма приветствуются", высказал желание постараться усовершенствовать программу Kostya (code.cpp) так, чтобы она работала с той же точностью раза в 2, а с учетом метода Рунге-Кутта по 4-м коэффициентам, раз в 100 быстрее. Что касается увеличения быстродействия без метода Рунге-Кутта, то мне это быстро удалось сделать даже с перевыполнением взятых на себя соцобязательств и в основном только за счет графики, например, я заменил очень медленное перо path на более быстрое. Так исходная программа code моделировала спуск тела по прямой (при одновременном моделировании движения другого тела по дуге окружности) за 10,359 сек, а моя программа SpuskSi за 2,237 сек, т.е. получается в 4,63 раза быстрее.

Усовершенствование алгоритма за счет сокращения двух расчетных точек и за счет применения метода Рунге-Кутта позволяют увеличить скорость работы программы при той же точности решения еще где то в 4,7 раза. Этот результат я получил на программе SpuskVB6 на режимах с параметром NC0 от 10 до 100, т.е. тогда, когда на время работы программы влияют в основном математические вычисления, сравнивая время с одинаковым значением NC0 для разных методик. При этом я рассматривал движение по параболе, т.к. только она отвечает всем требованиям теста с учетом процента ошибки (прямая вообще не дает ошибки, циклоида является аппроксимацией, а у дуги окружности в самом начале вылетает огромная ошибка из-за не совершенства алгоритма). Так при движение по параболе и при одновременном движение другого тела по прямой алгоритм Kostya с применением метода Эйлера при шаге решения 0,001 сек давал ошибку в конечной точке 0,14317%, а модернизированный алгоритм с применением метода Рунге-Кутта давал такую же ошибку решения 0,14286% при шаге решения 0,0047 сек. Итого получается, что мне удалось увеличить быстродействие программы только за счет этих двух приемов в 21,76 раза (4,7*4,7=21,76). С учетом применения метода NC0 получается еще чуть-чуть побольше, т.к. этот метод для программы SpuskSi с обновлением всего изображения не дает большого выигрыша. А вот если рассматривать программу SpuskSiM, то там при NC0=10 получаем выигрыш в 5,74 раза. Итого получается 21,76*5,74=129,4 раза. Есть, конечно же, и еще кое-какие резервы по увеличению быстродействия этого алгоритма, например, по использованию в качестве расчетных точек уже вычисленные ранее. Правда при этом возникает множество сложностей с переменным шагом по координате для различных точек, но я думаю, что и приведенных примеров достаточно, чтобы показать, что путей повышения быстродействия работы программ может быть множество. Но если Вы можете предложить какой-то эффективный метод, который позволяет повысить быстродействие работы рассмотренных программ, где то на 10-20 процентов, то я обязательно изложу его в следующей редакции статьи.

Только не следует предлагать, хоть и эффективные методы, но сложные по своему исполнению для научных работников со средним уровнем навыков по программированию, например, использования в критичном коде ассемблерных вставок, т.к. за то время пока они будут изучать ассемблер и переводить на него уже отлаженный код, они бы не только написали свою программу, но и закончили проведение всех необходимых им экспериментов. А самим научным работникам я бы не советовал увлекаться мелкими усовершенствованиями кода, которые хоть и позволят увеличить быстродействие конкретной их программы, но при этом ухудшат восприятие математических формул, описывающих их процесс. Например, в критичном коде всех программ у меня 6-ть раз повторяется выражение /2/h, которое можно было бы заменить на /h2, где h2=2*h и при этом скорость работы программы теоретически должна возрасти, но на напримере программы SpuskVB6M время работы программы не только не уменьшилось, но мне не удалось вообще зафиксировать статистически значимое изменение времени работы. Более того, у Вас при таких многочисленных заменах возникли бы проблемы при отладке математической модели (а в основном этим Вам и прийдется заниматься при отладке кода программ), т.к. разобраться в математических преобразованиях тем сложнее, чем больше у Вас различных переменных. Но если у Вас часто повторяются большие куски кода, то в этом случае такая замена будет полезна, как с точки зрения быстродействия программы, так и с точки зрения осмысления математических преобразований. Только данное замечание относится к конкретной Вашей программе, и совершенно не имеют никакого отношения к выбору языка программирования, т.к., использование такой замены во всех тестируемых мною программах, приведет только к абсолютному уменьшению времени работы всех программ, но никак не отразиться на относительных показателях, которые нас и интересуют.

Таким образом, как следует из данных таблицы 5, получается, что медлительность всех программ, написанных на языке BASIC, несколько преувеличена и, следовательно, по такому параметру, как быстродействие вполне можно выбирать для написания программ для научных исследований и язык Visual Basic 6.0. При этом программа SpuskVB6MV показала приличный результат даже по сравнению с программой SpuskSiM написанной на чистом C++. А если написать программу на Visual C++, т.е. с использованием библиотек MFC (Microsoft Foundations Classes) или VCL (Visual Component Library) от Borland (используется для программирования как на Delphi так и на C++ Builder), которые упрощают написание программ с визуальным интерфейсом, то такая программа быстрее всего будет работать чуть медленнее, чем использованная мною программа на чистом C++. Таким образом, научным работникам вообще нет смысла связываться с языком C++ из за его сложности при практически той же скорости работы программы. А использование еще более сложного языка Visual C++ NET должно быстрее всего тоже увеличить время работы программы SpuskSiM, т.к. теперь все языки NET работают примерно одинаково, ввиду того, что работают теперь с одной и той же виртуальной машиной, а, как мы видим, программа SpuskVBnetMV на многих режимах работает медленнее, чем SpuskVB6MV, и, следовательно, и программа SpuskVSinetMV должна работать на большей части режимов медленнее даже чем SpuskVB6MV, не говоря уже о SpuskVB6MVdllFB, но окончательный вывод по их быстродействию все же надо будет сделать после тестирования этих программ. А мой вывод по выбору языка программирования именно по быстродействию таков. Если вы решаете задачу, где много математических вычислений, то в принципе можете выбирать по критерию быстродействия любой из визуальных языков. И если даже окажется, что программа SpuskVSiM будет работать в 2 раза быстрее, чем использованная мною программа SpuskSiM, то это ни коим образом не может повлиять на сделанный мною выше вывод.

Давайте теперь, после рассмотрения вопроса по быстродействию программ, рассмотрим и остальные критерии оценки языков программирования для применения их в научных исследованиях. Что касается первого критерия, т.е. простоты написания программ и понятности языка программирования для широкого круга пользователей, то здесь конечно же любому BASIC нет никаких альтернатив, а для работы под Windows с визуальным интерфейсом конкретно языку Visual Basic 6.0. И наверное все, кто занимается программированием, знакомы с языком BASIC и тем, кто только учится программированию, лучше всего начинать именно с него. А так как по синтаксису почти все разновидности языка BASIC совпадают, то Вы всегда очень легко можете перейти с BASIC под DOS, например, QuickBasic или PowerBASIC на Visual Basic 6.0 (не путать с Visual Basic 7.0, т.к. это просто другое название Visual Basic NET и просто так перейти на него не получиться). А можно сразу начать изучение с FreeBASIC или Visual Basic 6.0, т.к. если Вы не будете ипользовать их все возможности, то можете начать писать программы самостоятельно уже на второй день.

Например, программа SpuskQB_FB, написана мною практически с использованием 7 слов, которые Вам надо выучить - это ввод и вывод данных INPUT и PRINT и операторов безусловного перехода GOTO, перехода на подпрограмму GOSUB с возвращением RETURN, организации цикла вычислений FOR...TO...NEXT, выполнения действий при выполнение условия IF....THEN и плюс к этому надо в самом начале объявить массивы DIM (если они у Вас есть). Здесь я не упомянул о прибамбасах, которые Вам могут пригодиться, таких как подача звукового сигнала BEEP, взятие системного времени TIMER и принудительная остановка программы при нажатие клавиши INKEY$. Итого получается уже 10 слов, которые надо выучить, чтобы написать не учебную программу типа "HELLO BASIC", а вполне работоспособную серьезную программу, каковой является программа Spusk, т.е. очень типичную программу для научных исследований. Правда если Вы хотите вместе с текстом еще и графику выводить на экран, то надо будет выучить еще 5 слов - выбор типа экрана SCREEN, его очистка от изображения CLS, задание размеров окна WINDOW куда будите выводить изображение, т.е. рисовать там линию LINE или точку PSET.

Таким образом, если Вы за сегодня выучили эти 15 слов, то завтра можете начинать писать свою программу. Причем интегрированная среда разработки (IDE) Free Basic написана полностью в стиле Windows и при этом она гораздо проще, чем IDE Microsoft Visual Studio и имеет приличный Help и большую коллекцию примеров, а во время написания программ делает простейшие посказки, выделяя ключевые слова разным цветом. А при запуске программы, если компилятор обнаружит ошибки, то он сообщит в какой строчке и какая у Вас ошибка и по номерам строк, которые появятся у вас слева от кода, Вы легко найдете свою ошибку. А если все пройдет нормально, то получите уже откомпилированный файл своей первой программы. А к уже имеющимся примерам я поместил в архиве TestSpusk еще несколько примеров по работе с функциями и двумя разными режимами работы с DLL библиотеками на примере программы Spusk.

Многие наверное будут разочарованы, что так быстро можно научиться программированию и писать практически любой математической сложности программы. Ведь у нас в России нормальные герои всегда идут в обход, создавая себе не нужные сложности, а потом их героически преодолевая. А я считаю, какая разница на каком языке написана программа, если она позволяет получить тот же результат, что и программа, написанная на самом навороченном языке программирования из семейства NET. К тому же, как видно из таблицы 4, программа, написанная на Free Basic, работает даже быстрее, чем программа, написанная на языке Visual Basic NET. А если Вы захотите написать программу с красивым визуальным интерфейсом и многочисленными режимами управления работой программы, то в Вашем распоряжение Visual Basic 6.0, куда Вы можете почти один к одному перенести свой код из Free Basic и, поупражнявшись денек в рисование кнопок, переключателей, текстбоксов и прочей визуальной прелести изобразить все это на форме своей программы. Правда скорость работы программы при этом немного упадет, но, если Вам очень надо будет, то, использовав некоторые из предложенных мною выше методов, Вы всегда ее можете увеличить.

Теперь давайте немного остановимся на так называемом стиле программирования, который считается в среде программистов показателем качества написания программ. Хорошим стилем у них чаще всего считается применение методологии (технологии) программирования, называемой структурное программирование, когда в каждой строке пишется по одному оператору и при этом делается сдвиг (табуляция) операторов, выполняющихся в теле другого оператора. Таким образом, мы получаем код, который записан как бы лесенкой. Особенно это важно для языка С++ и ему подобных языков, где в начале и в конце выполнения кода после каждого оператора надо ставить фигурные скобки, и такая запись позволяет контролировать количество открытых и закрытых скобок (хотя частенько в сложном коде не спасает и это). В результате мы получаем очень растянутый по вертикали код и, чтобы просмотреть какой-то логически законченный кусок кода, приходиться прокручивать на дисплее несколько экранов, т.е. не возможно одним взором сразу охватить весь логически завершенный блок кода. По этому научному работнику больше подойдет процедурно-ориентированная методология программирования, т.к. при отладке своей программы приходится в основном разбираться с тем насколько верно им составлены математические формулы, а не насколько грамотно они записаны с точки зрения концепции конкретного языка программирования. А т.к. для него очень важно видеть на экране сразу весь блок кода с формулами (весь алгоритм или его законченную часть), чтобы анализировать, где может быть ошибка в самих формулах, а не в коде, то в таком случае прийдется несколько однотипных операций или даже весь цикл FOR...NEXT записывать в одной строке программы, чтобы сделать запись кода более компактной. Для сторонников методологии структурного программирования это будет все равно, что красная тряпка для быка, но не надо придавать большого значения тому, какой стиль кем-то считается хорошим. Пишите так, как Вам будет легче анализировать этот код.

При этом существуют и другие правила хорошего стиля написания программ, которых должны придерживаться все программисты независимо от того какой методологии программирования они придерживаются. Во-первых все переменные, которые Вы будите использовать в программе, должны быть объявлены и инициализированы, т.е. необходимо принудительно задать их начальные значения. Это убережет Вас от неприятных неожиданностей при работе программы. Во-вторых, старайтесь всем переменным, процедурам и функциям присвоить имена несущие смысловую нагрузку, а в коде оставлять побольше комментариев, чтобы хотя бы Вы сами смогли разобраться с кодом этой программой через год. А я, например, даже пишу описание по работе с программой, которое вызывается нажатием кнопки About, т.к. убедился на личном примере, что частенько уже через год не могу вспомнить зачем нужна та или иная кнопка на форме какой-то написанной мною же программы. И в-третьих, постарайтесь использовать во всех, написанных Вами программах, для обозначения каких-то переменных, которые у Вас часто повторяются, одни и те же обозначения. Я, например, всегда скорости по осям X,Y,Z обозначаю VX, VY, VZ, а силы FX, FY, FZ и т.д. Очень желательно также отделять отдельные функционально законченные блоки кода друг от друга пустыми строками. В общем-то, можно сказать, что ваш стиль программирования, который Вы сформируете со временем, это уже будет ваш стиль мышления. Я вот, например, как привык при работе на первых ЭВМ, где ноль всегда перечеркивался косой чертой, чтобы отличить его от буквы О, так до сих пор и пишу даже в обычных формулах перечеркнутый нолик, хотя сейчас при выводе данных на дисплей и на принтер нолик уже не перечеркивают.

В связи со всем вышесказанным, я просто не понимаю упертых сторонников языка C++, да еще и слепо использующих обязательную запись кода лесенкой, если им приходится заниматься не разработкой программ в большом коллективе программистов, где все привыкли именно к такой записи, а написанием личных программ и тем более для проведения обычных математических расчетов. Ведь, кроме того, что язык C++ требует хорошего знания теории компьютера и тонкостей работы операционной системы, сама семантика языка C++ с точки зрения русского языка очень "корявая", не говоря уже о такой мелочи как то, что писать или хотя бы объявлять функции в C++ надо с конца программы, что конечно же не принципиально, но опять таки не очень логично с точки зрения человека, который первый раз встречается с языком программирования. Kostya очень обиделся, когда я ему написал, что язык C++ очень "корявый", т.к. он этого не замечает и все требовал с меня объяснений почему я так считаю. Видите ли, это трудно объяснить, также как трудно объяснить, например, почему дегустатору нравиться один сорт пива, или вина, а не другой в то время когда Вам лично нравиться именно другой. Но все же попробую, тем более, что недавно я наткнулся в Интернете на статью "Редкая профессия" Евгения Зуева http://beda.stup.ac.ru/psf/ziss/wmaster/books/magazine/pcmag/9705s/05S979.htm , в которой он описывает, как занимался созданием компилятора для языка C++ в начале 90-х годов и тоже считает этот язык "корявым". Вот что он пишет.

"Тогда язык Си++, судя по учебным пособиям, казался нам... да, непростым для компиляции, с корявым и неоднозначным синтаксисом, сильно усложненной семантикой традиционных конструкций, но вполне сравнимым, например, с объектной версией Паскаля фирмы Borland." Но, когда он вник во все тонкости этого языка, то он восклицает "И такой язык любят миллионы программистов?! Мир сошел с ума. Яду мне, яду!.." А вот как он пытается объяснить свой вывод "Я оказался в меньшей степени отравлен магнетическим воздействием системы UNIX и традициями программирования на Си, или, если угодно, находился под влиянием иной системы традиций ("правильно" построенные языки типа Алгола-68, Паскаля и Ады, большие компьютеры с "настоящими" операционными системами и т.д.), и с большим трудом привыкал к диктуемому "птичьим" языком Си стилю программирования, идущему, как мне кажется, непосредственно от личных пристрастий и привычек создателей языка." Таким образом, мы оба с ним впервые практически столкнулись с языком C++ не в школе или институте, а в зрелом возрасте, когда у нас уже сформировались свои понятия о языках программирования, и по этому мы оба высказали не только свежий, но квалифицированный взгляд на этот язык, назвав его птичьим и корявым. А те, кто со студенческой скамьи изучал C++, просто этого не замечают, т.к. привыкли именно к этому языку. А ведь, как гласит народная мудрость "Если Вас ударить в глаз, Вы конечно вскрикните. Закричите раз другой, а потом привыкните". Вот все, кто привык к языку C++ и не замечают, что он "корявый". Я извиняюсь за не совсем эстетичный довод, но он, как мне кажется, очень коротко и точно отражает суть проблемы.

Но, чтобы окончательно раскрыть глаза на истинное положение дел некоторым любителям языка С++ (правда я не уверен, что им поможет и это), стоит наверное привести еще несколько цитат из статьи еще одного человека не по наслышке знакомого с языком С++ http://article.zombiehack.com/viewart.php?artnum=1160748142&part=b . Вот три цитаты

"процесс программирования на С++ нередко сравнивают с хождением по минному полю. Виновата чрезмерная сложность языка, который с возрастом становится все сложнее и сложнее. Поговаривают даже о скорой кончине С++. Симптомы загнивания и деградации налицо, пусть даже слухи о его смерти сильно преувеличены. С++ не решил тех проблем, ликвидации которых ожидали. Программирование не стало ни проще, ни эффективнее, количество ошибок ничуть не уменьшилось, удачные примеры повторного использования кода (о котором трубят все поклонники С++) можно пересчитать по пальцам одной руки..."

"Программисты, одинакового хорошо владеющие двумя языками (С и С++), неоднократно замечали, что для 99% проектов 99% возможностей С++ просто не нужны!"

"Вполне логично ожидать, что на смену С придет язык с предельно простым синтаксисом, который можно будет выучить буквально за ночь! Не спеши тратить время на углубленное изучение тонкостей С++, возможно, они исчезнут прежде, чем успеют пригодиться..."

Мне могут возразить, что если язык BASIC такой хороший, а язык С++ такой плохой, то почему так много моих знакомых пишут именно на С++. Этому есть много объяснений и популярность того или иного языка среди ваших знакомых также, как и популярность артистов эстрады, это не показатель того насколько этот язык или артист хорош, хотя сбрасывать со счетов и этот показатель конечно же не стоит. Поэтому давайте обратимся к рейтингу популярности языков программирования. Самым известным сайтом, где ежемесячно публикуются рейтинги популярности языков является http://www.tiobe.com/tpci.htm и по данным этого сайта получается, что самым популярным, согласно нижеприведенной таблицы, с большим отрывом является язык Java, а язык С++ находиться рядом с Visual Basic. И объяснение здесь очень простое. Во-первых, этот рейтинг не имеет никакого отношения не только к популярности языков для научным работникам, но даже популярности среди профессиональных программистов, т.к. определяется регулярным опросом Google, MSN и Yahoo! по частоте употребления в контексте веб-страниц названия того или иного языка. Это объясняется тем, что, во-первых, разговаривают о языках программирования в Интернете в основном профессиональные программисты, а не научные работники, которые обсуждают совсем другие вопросы. А во-вторых разговоры в Интернете сейчас идут в основном о Web проектах и о базах данных и по этому Java на которой много программируют для Web и оказалась на первом месте, а вместе с ней в первой десятке оказались и другие языки применяющиеся для этого PHP, Perl, Python, JavaScript и даже мало кому известный Ruby. А вот широко известный и общепризнанный раньше Фортран оказался только на 21 месте. Правда здесь не совсем уместно говорить и о том, что популярный раньше Фортран очень любили, хотя Интернета тогда не было и популярность определялась не так, как на этом сайте. Просто раньше не было особого выбора среди языков и на всех больших машинах, таких как CM1600 или EC1865 куда не прийдеш был установлен в основном он, и я, например, проработав 10 лет на Фортране не могу сказать, что я в свое время его именно выбирал для своих научных исследований.

Таблица 6. Рейтинги популярности языков программирования по частоте упоминания о них в Интернете

Более интересен рейтинг http://www.dedasys.com/articles/language_popularity.html выполненный David N. Welton (правда он за октябрь 2005 г.), где присутствует не только вышеупомянутый рейтинг по количеству упоминаний языка в Интернете, но есть еще и рейтинги по стоимости размещения рекламы по этому языку и сколько стоит один клик мышкой по такой рекламе, по количеству open source проектов, в которых этот язык используется и по количеству предложений работы для программистов, использующих этот язык. И здесь самыми дорогими по рекламе оказались с большим отрывом три языка С, т.е. C, C++ и C#, по количеству реализованных проектов лидирует с большим отрывом С, а затем идут плотной группой Java, C++, Perl и PHP, а вот по предложению работы с большим отрывом лидирует язык структурированных запросов SQL, используемый при работе с базами данных, например, для программ складского или бухгалтерского учета. А ведь в приведенной выше таблице популярности он был только на 13 месте. По этому надо очень осторожно относиться к различным рейтингам популярности или к частоте упоминания языка в различных рекламных проектах при его выборе для своих научных исследований. Но выбор Вашего первого языка программирования очень ограничен, т.к. частенько преподаватели дают студентам не тот язык, который бы был для них оптимален при первом знакомстве с языками программирования, а тот язык, на котором они работали и который они лучше всего знают. А у аспирантов возникает другая проблема при выборе языка, когда их научный руководитель предлагает воспользоваться им программами (чаще всего на Фортране или на С++), которые для этой тематики писал он. И здесь у аспиранта возникает дилемма выбора невесты (языка) или по ее достоинствам или по приданному, которое за нее дают. Но не все так печально и к счастью язык программирования можно поменять, даже если Вы, как, например, я, 10 лет проработали на другом языке.

Таким образом, если мы посмотрим на первую десятку самых популярных языков, то и здесь мы увидим, что выбор то и по этому показателю сводиться в основном к двум языкам C++ или Visual Basic, т.к. С отпадает ввиду того, что это язык структурного программирования и он нам для создания красивого визуального интерфейса не очень подходит, а все остальные нам тоже не очень подходят, т.к. являются сценарными языками, т.е. скриптовыми и в основном используются в Web программировании. Можно конечно использовать и язык Java, но он все таки больше подходит для Web проектов или сетевых сервисов на предприятиях и к тому же является также как и языки технологии NET больше интерпретируемым, чем компилируемым. Правда из первой десятки остается еще C#, но его с успехом могут заменить или C++ NET или Visual Basic NET и по этому в принципе выбор опять сведется или к C++ или Visual Basic. А в пользу выбора Visual Basic можно еще добавить то, что Вы с него можете легко перейти на скриптовый язык VBA (Visual Basic for Applications), который можете использовать в своих документах созданных Exel и World, а, используя скриптовый язык VBScript, Вы можете разрабатывать Web проекты. Кроме этого Visual Basic 6.0 работает и с SQL запросами и по этому Вы можете писать на нем программы для работы с базами данных. Я надеюсь, что я не очень перехвалил Visual Basic и Вы все же взвесите все за и против, а не кинетесь немедленно изучать Visual Basic, который оказывается не только самый простой, но еще и популярен, а к тому же имеет множество родственников, позволяющих решать самые разнообразные задачи.

Но, говоря о простоте языка для написания программ, нельзя забывать и о простоте и удобстве отладки программ, т.к. времени на отладку только самого кода программ, а не математических уравнений, частенько затрачивается гораздо больше, чем на их написание. И здесь, как ни странно, языку BASIC тоже практически нет никаких альтернатив, т.к. отладку программ можно вести не при их компиляции, а при работе в режиме интерпретатора языка BASIC, что очень удобно, т.к. уже при написание кода, если Вы допустили какую то ошибку интерпретатор Visual Basic 6.0 сразу же выдаст вам не только сообщение о том, что Вы ее допустили, но и подскажет какую Вы ошибку конкретно допустили. А если Вы в обычном Блокноте пишите код на C++, то, естественно эта программа Вам ничего не подскажет по ошибкам. И хотя сейчас Вы на языке C++ от Микрософт можете писать программы уже непосредственно в оболочке Microsoft Visual Studio 6.0, которая тоже делает некоторые подсказки, но их качество не идет ни в какое сравнение с возможностями подсказок в оболочке Visual Basic 6.0. Например, если ошибка возникла уже в процессе выполнения программы, то интерпретатор Visual Basic 6.0 не только подскажет какая произошла ошибка, покажет Вам строчку, где произошла ошибка, но и покажет значения переменных, которые привели к такой ошибке. Например, это позволяет очень легко исправлять ошибку деления на ноль, когда Вы видите какая переменная из множества в этой строке равна нулю.

Что касается написания программ с использованией технологии NET, на которую, после того как были переведены Basic и C++, а также язык C# (си шарп), который специально для этой технологии и создан, сейчас переведятся практически все остальные известные языки программирования, то возможности у языков NET гораздо шире, чем у существующих сейчас, но не в плане написания программ для решения конкретных научных задач, а в плане использования различных компонентов для сборок даже на разных языках программирования и даже при их присоединение к проекту через Интернет, но я не думаю, что все это нужно научным работникам. Тем более, что за такие широкие коммуникационные свойства приходиться расплачиваться значительным усложнением языков, а научным работникам надо заниматься не изучением тонкостей языка программирования, а изучением тонкостей той научной проблемы, которой они занимаются. При этом им приходиться частенько проводить одновременно совершенно разные расчеты, например, моделирование поведения различных систем, проведение статистической обработки полученных данных, экономические расчеты эффективности предлагаемых решений и т.д. и по этому язык для научных работников должен обладать широкими возможностями именно в этом плане.

В общем то можно сказать, что все процедурные языки программирования Basic, C++, Pascal, Fortran и т.д. являются универсальными и позволяют решать самые разнообразные научные задачи. Хотя иногда бывает проще решить конкретную задачу с использованием специальных языков программирования. Например, для решения экономических задач использовать Кобол, а для решения задач связанных конкретно с системами массового обслуживания (лифты, бензозаправки, аэропорты, операционная система Windows и т.д.) создан язык GPSS, который сразу оперирует очередями, заявками, узлами обслуживания и т.д., т.е. теми терминами, которые используются для описания систем массового обслуживания. Но здесь имеются и большие минусы. Во-первых, для каждой специальной задачи не будешь изучать новый язык, а во-вторых, если Ваша задача немного не вписывается в стандартный алгоритм работы этого языка, то Вам придется упрощать свою задачу, подгоняя ее под этот стандарт и, следовательно, Вы будете решать уже другую задачу. По этому, я лично категорически против всех этих специальных языков программирования, но если кому то очень хочется блеснуть оригиральностью, то могут конечно выучить и какой то специальный язык для решения конкретной задачи. Правда здесь несколько особняком стоят языки программирования различных математических пакетов таких как Maple или Matlab и я сам иногда пользуюсь Maple, но только для символьных вычислений, хотя можно конечно же использовать их и для каких-то простейших расчетов. А в тех случаях, когда можно и какую то сложную задачу решить с использованием этих пакетов, я считаю, что лучше все таки написать для этого свою программу на выбранном Вами универсальном языке программирования, чтобы быть уверенным, что задача решена верно, т.к. эти пакеты просто выдают ответ, а как он был получен остается тайной, а к тому же надо изучать еще и язык этих пакетов, а при решение сложной задачи Вы поверхностными знаниями работы с этими пакетами не отделаетесь.

Теперь, что касается последнего критерия оценки, а именно простоты компиляции и установки программ на различные компьютеры пользователей. Что касается компиляции программ в native-код, то здесь у всех языков это делается более-менее одинаково и все различия заключаются в выборе различных настроек компиляции, которые предоставляет тот или иной компилятор, который обычно входит в среду разработки языка (хотя может поставляться и отдельно). Правда следует добавить, что компилятры языка С++ выпускают очень много фирм и практически ни один из них не поддерживает стандарт языка на 100% (в различных вариациях), и, следовательно, реально можно использовать только базовые языковые средства, составляющие ядро С++, а все остальное только на ваш страх и риск (если конечно же Вы хорошо себе представляете, где они эти базовые средства заканчиваются). И поэтому нет никакой уверенности, что ваш код будет успешно откомпилирован двумя разными компиляторами одного и того же языка, если вы не сообщите тому кто захочет воспользоваться Вашим кодом, под какой компилятор этого языка Вы его писали. И здесь с одной стороны плохо, что Микрософт является монополистом компиляторов для Visual Basic 6.0, а с другой стороны есть 100% уверенность, что ваш код правильно будет откомпилирован любым пользователем, который будет его использовать.

А вот при установке программ на компьютеры пользователей явным фаворитом являеться C++, т.к. все, что нужно для работы программ, написанных на C++ всегда есть на любом компьютере, где установлена операционная система Windows, т.к. она сама написана на C и, следовательно, все библиотеки необходимые для работы программ написанных на C++ всегда будут на таком компьютере, а операционная система Windows является самой распространенной. А вот другим языкам при работе на компьютерах, где стоит операционная система Windows нужно как-то заботиться о своей работоспособности и частенько они в откомпилированный файл включают все необходимое. А мне для работы программы SpuskTP пришлось вместе с откомпилированным файлом положить в архив и видиодрайвер EGAVGA.BGI необходимый для работы программы. Visual Basic 6.0 в этом плане повезло больше, чем другим языкам, т.к. он разрабатывался фирмой Микрософт, которая старается поддерживать свои продукты и по этому необходимую для его работы библиотеку msvbvm60.dll включает в комплект поставки Windows. Тем более, что установить эту библиотеку на свой компьютер, если она там отсутствует (установлена более ранняя версия) не такая уж и большая проблема. А для тех, для кого и это проблема, я написал Setup, который в автоматическом режиме сам установит и зарегистрирует эту библиотеку на вашем компьютере. Так, что и здесь у C++ нет никаких явных преимуществ перед Visual Basic 6.0. И если мы вспомним о технологии NET, то здесь Вы уже хилой библиотекой msvbvm60.dll в 1,25 Mb не отделаетесь и здесь пока есть проблемы. Хотя конечно же Микрософт будет поддерживать и этот свой продукт и в новых версиях появится все необходимое для работы программ, созданных с помощью технологии NET.

Правда, говоря о технологии NET нельзя все сводить только к наличию на компьютере дополнительных файлов библиотеки CLR, т.к. компиляция сборки NET в DLL-библиотеку или EXE-файл не доводится до конца. Большая часть информации, обычно используемой компилятором, хранится в так называемом манифесте. Вместо машинного кода компилятор генерирует так называемый IL-код, а при первой загрузке приложения NET запускается JIT-компилятор, который и генерирует машинный код для работы приложения. Нечто подобное было и у Visual Basic 6.0, который мог компилировать программу в промежуточный P-код, который потом интерпретировался исполнительной средой, но здесь IL-код компилируется в машинный код, который потом сохраняется. Но больше всего это похоже на виртуальную машину языка Java, которая позволяет всем системам взаимодействовать друг с другом начиная со смарт-карт и заканчивая суперкомпьютерами независимо от аппаратной платформы и системного программного обеспечения. И технология NET тоже теоретически предпологает, что приложения NET будут работать на всех платформах или операционных системах с поддержкой CLR, что очень важно при массовом распространение программ, т.к. частенько уже откомпилированный файл программы отказывается работать на разных компьютерах даже с одной и той-же операционной системой. Вот только наврядли эта многоплатформенность нужна конкретному научному работнику, который пишет программу не для массового ее тиражирования, а для личной работы с этой программой и на конкретном своем компьютере.

Здесь же следует сказать, что до недавнего времени был еще один критерий оценки программ по размеру откомпилированного файла, но с появлением винчестеров с гигабайтным объем, а вместо кучи дискет для установки больших программ достаточно стало одного CD диска, он ушел в небытие, и сейчас размер программ мало кого интересует. Хотя еще лет 15 назад, когда у меня появился персональный 286 компьютер с винчестером на 20 Mb, мне казалось что не хватит и всей жизни, чтобы забить этот винт программами написанными под DOS. Но я надеюсь, что сегодняшние мои представления о размерах винчестеров и размерах программ не изменятся, т.к. практически современные программы достигли своего совершенства и навряд-ли будут стремительно расти. Хотя компании, производящие программное обеспечение постоянно пытаются втиснуть в свои программные продукты какую нибудь новую функцию, чтобы раструбить всем как она полезна и что всем надо обязательно покупать новую версию их продукта не смотря даже на то, что уже существующие функции редко используются хотя бы на половину. Но это чисто эволюционный путь, который не может заметно повлиять на размеры программ, а новые языки с принципиально новыми концепциями навряд-ли появятся в обозримом будущем.

В этой статье, как Вы заметили, основное внимание было уделено рассмотрению двух языков программирования, а именно С++ и Visual Basic 6.0, которые на мой взгляд являются просто антиподами, и по этому позволяют наиболее отчетливо увидеть все аспекты проблемы выбора языка программирования. Да, я мало уделил времени другим языкам программирования и в частности Fortran, который раньше считался самым быстрым и популярным языком именно для проведения различных математических расчетов. Он конечно же и сейчас быстрый язык, но он слабо продвигается в отличие, например, от Visual Basic 6.0, который является детищем Микрософт, и по этому я даже не нашел в Интернете сайта посвященного программированию на Фортране, а Visual Basic 6.0 стараниями Микрософт доведен просто до совершенства и я ни сколько не жалею, что перешел с Фортрана на Visual Basic 6.0. Только не путайте его с Visual Basic 7.0, т.к. это просто другое название Visual Basic NET, который, как Вы уже поняли, я не рекомендую для изучения научным работникам. Есть конечно же и другие языки, которые по своим параметрами больше соответствуют или C++ или Visual Basic 6.0, по этому я не говорю категорически, что надо выбирать именно Visual Basic 6.0, но при этом выбранный вами язык должен больше соответствовать возможностям Visual Basic 6.0. А в пользу выбора именно 6-й версии Visual Basic можно привести и такой довод, как то, что теперь эта версия является окончательной и дальнейшим изменениям этот язык подвергаться не будет. Я, например, этому очень рад, т.к. за 27 лет, что я занимаюсь программированием, надоела эта чехарда с новыми версиями языков или вообще новыми языками. Правда для профессиональных программистов, пишущих программы на заказ, это конечно же катастрофа, но для научных работников, пишущих программы для себя, это не имеет никакого значения. Кстати теперь в программах на Visual Basic 6.0 можно использовать и недокументированные возможности, например, VarPtr, т.к. теперь это точно никуда не денется. А у языка Free Basic есть свой плюс - он распространяется свободно и за лицензию ничего платить не надо. Есть конечно же и у других языков свои плюсы и Вы вправе выбрать любой из них для своих научных исследований, но я считаю, что на ближайшие лет 10 Visual Basic 6.0 в сочетание с Free Basic (или без него) это наилучший выбор для научных работников.

Список использованных программ:

1. http://modsys.narod.ru/Prog/Prog_Prog/TestBench2.rar - архив программ простейших бенчмаков на разных языках программирования.

2. http://modsys.narod.ru/Prog/Prog_Prog/TestSpusk.rar - архив программ Spusk на разных языках программирования

3. http://modsys.narod.ru/Prog/Prog_Prog/TestSpuskM2.rar - архив программ SpuskM на разных языках программирования, оптимизированных по скорости выполнения программ.