Почему я (не) перешел на .NET с Visual Basic 6.0
Я оставил название статьи именно таким, каким оно указано в условиях конкурса потому, что после практического знакомства с VB.NET пришел к выводу, что оптимальным для эффективного продолжения моей трудовой деятельности на сегодняшний день является использование обеих версий - Vb6 и VB.NET.
Я не считаю себя "чистым" профессиональным программистом. Просто в течение ряда лет мне приходилось решать различные прикладные задачи с применением ЭВМ. При этом построение программы расчета, сопровождаемой контрольным примером, представлялось весьма проблематичным, поскольку многие важные стороны конечного результата заранее почти никогда не были известны. Практика показала, что даже в то время, когда решение прикладных задач обеспечивалось далеко не "персональными" ЭВМ, разделение функций между программистом и специалистом, формулирующим ему задачу и анализирующим результаты расчета, к ожидаемому успеху не приводило.
Оптимальным оказалось сочетание в одном лице программиста и специалиста в области знаний, соответствующей решаемой задаче. И даже, когда ее решение одному специалисту было не под силу завершить в реальные сроки, наиболее рациональным оказывалось разбиение исходной задачи на отдельные составляющие, но так, чтобы условие упомянутого сочетания сохранялся.
В этих условиях был необходим язык, не требовавший при программировании обращения за каждой мелочью к соответствующим библиотекам, как, например Си или Паскаль. Пока возможности средств графического отображения информации были весьма бедны (ЭВМ серии СМ, ДВК, ЕС), роль такого языка успешно выполнял старый добрый Фортран. С приходом эры подлинно персональных ЭВМ, позволивших наряду с другими новшествами существенно обогатить возможности экранной графики, наиболее подходящим стал Бейсик, сочетавший в составе встроенных операторов все необходимые пользователю графические примитивы.
Из всех версий Бейсика эры начала ПЭВМ пальму первенства за возможность объединения в одной программе модулей, написанных на разных языках, следует отдать версии QB4.5 фирмы Майкрософт. Это обеспечило наилучшее использование накопленной временем библиотеки модулей, написанных на Фортране, в новых задачах, имевших тесную преемственную связь с ранее решенными.
В более поздних, Vb-версиях, эта возможность была утрачена, однако к этому времени уже практически все используемые модули многократного применения уже были написаны на Бейсике и утрата оказалась не существенной. Ну, а возможности визуального программирования, особенно обретенные в версиях Vb5 и Vb6, были выше всех похвал. Переход на Vb произошел у меня как бы сам собой, не вызвав ни малейших затруднений. Характер выполняемой мною работы, в основном, сохранялся. К таким новшествам Vb-версий, как разработка собственных ОСХ или классов прибегал весьма и весьма редко, а вот возможность эффективного управления из Vb6 работой Excel и Word, а также динамического открытия новых окон оценил сразу и там, где это считаю рациональным, широко использую.
Чтобы объяснить, почему я по-прежнему сохраняю "разумную" (мне кажется) привязанность к обеим версиям, уместно перейти к краткому изложению опыта решения прикладных задач на Visual Basic 6.0 и VB.NET.
Опыт работы на Visual Basic 6.0.
Мой опыт программирования на Visual Basic 6.0 связан с необходимостью решения круга задач, которые для конкретности уместно сопроводить таким перечнем:
- динамика колебаний сложных механических структур - стержней переменного сечения, слоистых конструкций, пластин и т. п.;
- регистрация сложных электрических сигналов с помощью звуковых карт и иных АЦП;
- спектральный, корреляционный анализ этих сигналов, а также родственные этим методам и связанные с ними методы обработки цифровых массивов данных;
- прогнозирование событий по опытным табличным данным (например, прогноз ветрового волнения моря);
- выявление преимущественного направления и средней скорости движения большого числа объектов, совершающих случайные колебания (например, скорости всплытия паро-газовых пузырей в потоке кипящей жидкости или облаков по результатам анализа серии последовательных изображений процесса).
Совершенно очевидно, что для решения каждой из таких задач следует основное внимание сосредоточить на физике исследуемого процесса, в максимальной мере сопровождая результаты вычисления графическими характеристиками процесса. Это позволяет оперативно сопоставлять результаты расчета со здравым смыслом и вовремя выявлять огрехи в вычислениях и выбранных алгоритмах. Visual Basic 6.0 при решении таких задач в идеальной мере освобождает программиста от обращения к специальным графическим библиотекам.
Единожды объявленные операторами DefDbl, DefSng и т. п. диапазоны переменных делают удачную преемственность с Фортраном и освобождают программиста от принудительного утомляющего объявления типа переменных.
Синтаксис языка позволяет свести к минимуму число выражений, начинающихся с новой строки. Это чрезвычайно удобно, так как в пределах одного экрана представляется возможным охватить одним взглядом достаточно сложный процесс вычислений, выполнить анализ кода и легко уловить огрехи программирования.
По поводу двух последних абзацев предвижу неистовство "программистов-классиков", которые "жить не могут" без Option Explicit и программирования "лесенкой", а всех, кто этим пренебрегает считают "немытыми чайниками". Пусть так. Но, пока, мне ни разу не удалось убедиться, что пренебрежение этими двумя правилами снижает производительность решения задачи. В целом - совсем наоборот. Упрощения эти делают возможным написание кода без предварительного выписывания формул на бумажке и переписывание их оттуда в текст программы с неизбежными ошибками.
Все неплохо, когда формула состоит из трех букв z = x + y. Попробуйте записать программу аналитического решения системы четырех линейных алгебраических уравнений и сразу увидите, как начнете спотыкаться на этих лесенках. Использование известного инструмента Derive Texas Instruments Incorporated позволяет решить эту задачу в несколько минут без бумажки. Вот только для "лесенки" места не остается и с Option Explicit запаришься.
В заключение - еще об одной полезности Vb6.
Иногда приходится иметь дело с такими извращениями Бейсика, о которых и говорить бы не стоило, но куда денешься. Есть такой старинный пакет Surfer (Golden Software.Inc). Предназначен он для построения объемных изображений и приближен к картографии, но не настолько, чтобы строить карты по действующим в гидрографических службах наставлениям. Имеет встроенный интерпретатор собственного Бейсика.
Поскольку те, кто должны рисовать карты, программировать не умеют, выпало недавно и на мою долю написать несколько программ на таком Бейсике. Кто этого пакета не знает, пусть представит себе интерпретатор, не имеющий текущего контроля кода и не поддерживающий принципиально Кириллицу. Операторы кое-какие - не "наши". Рисует прямоугольники, дуги, круги, эллипсы но не рисует (!) отрезки прямых линий. Последние рисуются программно в такой последовательности:
- сначала рисуется прямоугольник нулевой ширины или высоты;
- а затем этот прямоугольник поворачивается вокруг центра тяжести на заданный угол.
Представьте себе эту кучу операторов для построения отрезка прямой. А их нужно строить сотни. Да для каждого задавать, а то и вычислять координаты концов отрезков по разным условиям. Несмотря на возможность написания подпрограмм, все переменные - глобальные. Не знаю, как я справился бы с задачей, не владея Vb6. А тут - в миг написал все сначала на Vb6. Потом буфером перетащил в интерпретатор Surfer, подправил пару операторов и был таков.
Опыт работы на VB.NET
И зачем, казалось бы мне, от этих дифирамбов в отношении Vb6 переходить к VB.NET?
А вот зачем:
- Vb6 медленно работает с файлами, известные приемы чтения бинарных файлов для ускорения ввода данных не всегда дают желаемого результата;
- Vb6 медленно считает - это не всегда важно, но при спектральном анализе в темпе ввода данных, расчетах колебаний сложных механических структур и в ряде других задач скорость счета нуждается в существенном увеличении;
- не утверждаю это однозначно, но создается впечатление, что некоторые структуры Framework удобнее их API аналогов;
- очень хорошее впечатление оставляют алгоритмы сортировки данных и ряд других процедур над массивами;
- в Бета 2005 версии заложено переопределение операторов - появляется возможность возврата к комплексным числам в той мере, в какой это было возможно в старом добром Фортране, а потом было так надолго утрачено, что уже все, кого это серьезно касается (не тех, кому нужно просто выполнить одно арифметическое действие над двумя комплексными числами), уже привыкли отдельно вычислять в сложных выражениях мнимую и действительную части и прошлого не помнят…;
- и, наконец, работа с большой оперативной памятью, когда система сама (!!) преподносит тебе подарок, оперативно переформируя ее "до упора".
Опыт работы с VB.NET пока невелик.
Из практически законченных программ для "внутреннего употребления" хотелось бы отметить такие.
1. Расчет траекторий лучей в двухслойной среде с рефракцией. Сложность задачи в том, что при каждом отражении от границы раздела сред луч двоится и количество траекторий лавинообразно нарастает. Удалось решить задачу, включающую свыше 33 миллионов участков таких траекторий с расчетом энергии, распространяющейся вдоль каждой из них.
2. Вторая программа предназначена для дальнейшей обработки данных, полученных предыдущей программой применительно к частным условиям конкретной задаче.
3.
Программа узкополосного спектрального анализа акустических сигналов (рис. 1), записанных с помощью звуковой карты. По сервисным возможностям оформления результатов программа имеет преимущества перед ее аппаратным аналогом - анализатором 2033 фирмы Брюль и Къер (Дания), который раз в 10 дороже ПЭВМ с частотой процессора 1 ГГц. По скорости обработки на высоких частотах программа, естественно, уступает упомянутому анализатору, но вполне приемлема для решения большинства прикладных задач.
На остальных написанных программах вряд ли стоит останавливаться, поскольку на них автор учился программировать, набивал шишки и приобретал соответствующий опыт.
К стати об этом опыте. Упомянутые выше программы первоначально были написаны мною с помощью 2003 версии. Потом они были переработаны в варианте 2005 Бета. А недавно эта Бета прекратила свое существование. Вместо нее появилась для свободного тестирования Бета 2. Но инсталлируется, как я понял, она только прямо с сайта Майкрософт. То ли я ее не так поставил, то ли где-то в процессе передачи данных произошла ошибка, но она у меня не работает. Бог бы с ней. Немного жалко денег. Но программы-то я писал не для удовольствия, а для решения насущных задач. И после перевода их в 2005 версию заметно усовершенствовал. И надо было бы еще улучшить коды, а вот остался у разбитого корыта.
И решил я загрузить компоненты - формы и модули последних моих 2005-тых версий обратно в 2003-тью студию. Она поплевалась, поворчала, но Рашен все может. Я там подергал кое за что немного, убрал, строки, которые 2003-тью не устраивали и все заработало! В общем, если с вами такое же случится - не отчаивайтесь.
Что тормозит мое вхождение в VB.NET
Как поется в песенке "А мне всегда, чего-то не хватает: зимою - лета…". Так вот и с VB.NET.
Ну конечно же VB.NET - это новое слово в программировании. Она будет успешно совершенствоваться и без моих советов. Поэтому хотелось бы высказать те пожелания, которые специфичны для моей профессии, как я ее называю - "решателя прикладных задач методами математического моделирования и расчетных оценок на ПЭВМ".
Мне, видимо, не скоро (а, возможно, и никогда не) доведется окончательно расстаться с Vb6. Поэтому хотелось бы пожелать совершенствования системы в части автоматизации перевода программ Vb6 на VB.NET. Пока возможности, предоставляемые Майкрософтом - достаточно скромные. В кодах программ остаются "хвосты", которые почему-то иногда проявляются не сразу, а при дальнейшем совершенствовании кода уже в VB.NET. Не уверен, что Майкрософт уделит этому должное внимание - мелковато для нее. Но здесь открывается широкое поле деятельности для русскоязычных программистов, которые вполне могут и склонны писать подобные автономные модули.
Пока VB.NET существенно уступает Vb6 и по количеству мультимедийных контролов. Совсем плохо обстоит дело с записью звука. Здесь также широкое поле для творчества программистов-любителей, которые, зачастую не уступают профессионалам, а то и превосходят их.
Вообще-то мультимедийные программы можно эффективно организовывать и без специальных контролов, а пользоваться API функциями. Хорошим примером является широко известный программистам модуль Audiomonitor, фрагменты которого мне не раз доводилось модифицировать и встраивать в свои программы. Но однажды я задался целью переложить коды этого модуля на VB.NET. Тут началась такая чехарда с функциями обратного вызова и "аналогов" VarPtr, что мне расхотелось доводить эту задачу до конца и остался я с ней в Vb6.
Этот пример наводит на мысль, что необходим модуль глубоко автоматизированного перевода программ, написанных на Vb6 и использующих API функции, на VB.NET.
Наличие единого для Си и Бейсика компилятора имеет предпосылку для объединения в одном ехе-шнике разноязычных модулей. Иногда такое решение было бы оптимальным. Возможно так можно поступать и сейчас. Встречаются на сей счет кое-какие намеки. Но механизм такого объединения нужно реализовать простым и понятным для пользователя способом, чтобы ему не приходилось ломать голову над представлением переменных в разных языках, а больше думать над решаемой физической задачей,
И, наконец, последнее, что уж давно у меня наболело, но самому времени на это не хватает. В VB.NET есть прекрасные быстродействующие средства вывода графиков, сформированных по данным массивов. Но конкретное программное решение всегда требует написания значительного объема надежно застрахованного от ошибок кода. Тут бы иметь подходящий ОСХ или DLL-льку. Но, как у Булата - "Надо б лампочку повесить - денег все не соберем". Вот и таскаю модуль из одного места в другое. И каждый раз корежу до неузнаваемости исходный код.
Заключение
Надеюсь, что мне удалось подвести итог моей поступи под флагами QB4.5 - Vb6 - VB.NET и обосновать необходимость дальнейшего использования в работе каждой из этих версий.
Приятно осознавать, что с Биллом Гейтсом всех нас объединяет наша общая преданность Бейсику.
Ну, а в какой версии чаще работать - подскажет Жизнь.
|
