Если программист в девять утра уже на работе...



Всю ночь сидела и мучала Блокнот - мою программу на Visual Basic for DOS. И весело, и печально. Весело то, что это вроде как VB, но игрушечный. А печально то, что нет сервиса. За время программирования под Windows я так привыкла к сервису системы, что теперь приходится очень сложно. Например, в Windows есть реестр и куча функций для работы с ним. И хотя иногда начинается морока со всем этим, но всёже оно есть. А тут - голый файлик, из которого читаем некие числа (чтобы была возможность ручками подправить). И всё сама!



Пока научила Блокнот сохранять и читать настройки (правда пока не знаю, как узнать каталог программы), а также сохранять файлы, определять изменения. Остальное пока задерживается.



А! Что-то я тут вспомнила про Win32 API. Рискую опять показаться "крутым программером", но всёже... Для меня всё это очень естественно. Тоесть я знаю что любая программа работает в Windows через Win32 API (я всегда пишу Win32, потому как API - это просто некий интерфейс, а не что-то конкретное, как думают некоторые) и вызов функций для меня - вполне естественное дело. А потом читаешь в Инете статьи от всяких "очень продвинутых программеров", слушаешь знакомых... "Я тут использую кое-какие апишки," - говорил мне один знакомый дельфиец. Меня аж передёргивает. Словно он говорит: "Я тут использую песок с Марса." Ну и во всяких статьях удивлённое: "Чего только не найдёшь в этих Win32 API!" Интересно, а когда он в холодильник заглядывает, он тоже так удивляется? Начинаешь думать, что такие вот программеры считают, что Windows и, скажем, Delphi - далеко друг от друга, что Delphi совершенно иначе реализует, скажем, чтение файла...



В книге про драйверы ещё прочитала фразу о том, что многие программисты избегают реестра. Я помню гордые заявления, что "программа ничего не пишет в реестр". Молодец! Мой Блокнот для Windows был написан на достаточно (для него) быстрой машине, поэтому все обращения к реестру у него идут очень тупо: открыл ключ, прочитал/записал, закрыл. Ни какого "кэширования", ничего. На ноутбуке такое решение ОЧЕНЬ тормозит. Программа грузится и выгружается очень долго - это я отслеживала с помощью RegMon. Исходников как-то не очень, но решение есть: просто открывать общий ключ и скопом все значения читать - скорость возрастает. Проверяла на другой программе, которую я такой оптимизацией заставила работать раз в десять быстрее. Я это к чему? Когда я пожаловалась на скорость тому дельфийцу (уточнив, где происходит падение производительности), знаете что он мне ответил? А зачем я использую вообще реестр? Честно говоря, я была обескуражена такой постановкой вопроса.

Тоесть как зачем? И он мне посоветовал: вот есть INI файлы... Я ответила что-то невнятное про пользователей и хранение настроек в HKEY_CURRENT_USER, но... Короче, сошлись на том, что я за передовые технологии (при том, что реестр появился ещё в Windows 3.XX)... Но... Я до сих пор не могу понять логику этого человека. Может быть он просто не посчитал нужным вникать в суть вопроса? Почему программа тормозит? Ясно от чего - мастдаевский реестр! А ещё говорят о женской логике...



Хм... Кстати. В той книжке про ошибки на C++... Я когда это читала, у меня неволно возникала мысль, что на Visual Basic половина этих ошибок вообще не возникает. И дело вроде бы не в компиляторе/синтаксическом анализаторе... Даже не знаю почему... Хотя, общее всёже есть. Но всё равно слишком много чисто сишных ошибок.



У нас, кстати, был такой предмет "Программирование и алгоритмизация". Там преподаватель (сильно смахивающий на одного героя из Бумера, ну того, который смылся в конце первой части и долго ещё рыдал) пытался объяснить программирование абстрагируясь от языков. Впрочем, всё равно всё скатилось на C++, что понимали только два человека (я среди них ^_^). Меня немного напрягла витавшая в кругах студентов, толком не знающих ни одного языка программирования (или Паскаль со школы... Бррр!), мысль о том, что языки на самом деле отличаются операторами. Достаточно изучить операторы, а там уже можно и программу писать... Вот интересно, как скоро жизнь за такое убеждение настучит по голове? Я, конечно, могу ошибаться, но мне всё видится иначе. Есть похожие языки, но на самом деле какждый язык - это отдельная философия. Язык - это не просто набор операторов. Почему-то часто упускается из виду наличие стандартных библиотек и исполнительных сред. Более того, часто языки отличаются по области применения и по

реализации. Например Java. Похоже на C, но, собственно, и всё. Для того чтобы эффективно использовать Java, не достаточно просто узнать, как там что пишется. Необходимо изучить стандартную библиотеку, как и где применяется язык, по каким правилаам.



Неудачный пример. Я сама не знаю Java. Хорошо. Javasсriрt. Этот язык похож на C, но достаточно ли изучить его синтаксис? На C создаются программы, которые работают отдельно, используют стандартную библиотеку C, ну или какую-нибудь подобную. Программа работает с самой системой (DOS, Windows, UNIX - не важно), работает по определённым правилам. Хорошо. А что JS? У JS своя библиотека объектов и функций, такие мелочи как строки там реализованы иначе (пожалуй, строки - самое заметное отличие между языками). Но это не всё. JS работает как скриптовый язык. Он может работать под WSH или в DHTML Тоесть для его применения не достаточно знать, что переменная объявляется с помощью var. Нужно знать объектную модель WSH или DHTML, потому как без них язык как-то теряет смысл.



Или вот. Менее экстримальный пример. VB и C++. Какзалось бы, близкие языки. ООП, высокий уровень, Win32, ну и так далее. Написал программу на C++, а потом прочитал про операторы VB и перенёс на VB. Но. Когда начинаешь рассматривать всё это ближе, оказывается что и у этих двух языков разная философия. Не думаю, что философия VB в том, что нажал кнопку и мастер сделал полпрограммы (такая мысль читается между строк во многих книгах по VB). Однако многие задачи в этих двух языках решаются по-разному. Взять хотябы строки. Чтобы работать с ними в обоих языках приходится переключать мышление с VB на C++ и наоборот. Разные исполнительные среды, разные стандартные библиотеки - это очень сильно отличает языки. Visual Basic со своими Dim, For и Select Case был бы ничем без VBRUN с её Mid(), CreateObject() и прочими функциями, которых как-то нет в C++. А такой аспект как указатели? Допустим мы начинаем строить какую-то структуру данных на C++, набираем базовые

классы, наследуем, строим иерархию, потом плодим тучи указателей и всё это приводим к какой-то системе. А теперь зная операторы VB переносим всё на этот язык. Первое неприятное открытие: VB не поддерживает указатели (хотя, можно ухитриться, но толку с этого мало). Второе неприятное открытие: классы в VB работают не совсем так, как в C++. И вся структура летит под откос, приходит осознание того, что структуру надо проектировать заново. С нуля.



Я тут так много понаговорила, хотя хотела сказать одну вещь: не надо слушать тех, кто говорит, что языки можно учить пачками, ведь отличия в них только в наборе ключевых слов. Я видела таких любителей среди которых было немало таких, которые бросили это занятие.



Я сама вроде как учила Паскаль, но я не доконца понимаю его философию и реализацию. Я сейчас пишу на трёх языках: VB, C++ и JS (раньше писала на VBS, но как-то не прижилось). При этом, стыдно признаться, в C++ я почти не знаю стандартную библиотеку. Да, я знаю синтаксис. Но могу ли я использовать язык в полную силу? Конечно нет.



Кстати, я сейчас всю ночь писала на VB для DOS. Как же сильно оно отличается от VB6! Это просто похожие языки. Но они не одно и тоже. Просто Quick Basic вдруг научился работать с формами...



За всеми этими рассуждениями забыла о самом главном. Когда я однажды одному программисту (одному из моих учителей) показала компилятор Quick Basic, он был очень удивлён. Сегодня мне снова пришлось столкнуться с этой штукой... В IDE не компилируется проект. Говорит, что "too many files". Я даже строчку FILES в Config.SYS меняла, смотрела, где это include файлы могут циклиться - нету! И всё равно не компилируется... С горя решила поковырять компилятор. В VB6 от нас отбили эту радость, зато в VB for DOS всё есть, с краткой справкой по ключам... BC.EXE (BASIC Compiler) принимает модули вроде FRM и BAS. BI (BASIC Include ^_^) подставляются препроцессором сами. С первого раза не получилось, оказалось, что нужно отдельно указывать поддержку обработчиков ошибок - всё подробно указывается в дампе. Ага. Получила я три OBJ файла. Теперь нужен линковщик, который так и называется: Link.EXE. Только там параметры передаются немного странно, сразу не разобрать... Кроме того, моя

программа не работала сразу. Я думала, что это из-за сжатия EXE (было такое когда-то!), но оказалось, что дело в порядке OBJ файлов...



Так я и упранялась, всё компилировалось, EXE получался килобайт тридцать. Но потом я заметила ключ генерации отдельного кода и иструкций 80386. С первым дело туманное. Программа в таком случае весит меньше, но требует какой-то общий модуль для работы. И оказалось, что у меня всё компилировалось именно в таком виде! Я откомпилировала без этой бяки и оказалось, что программа весит почти девести килобайт! Сначала думала, что это из-за инструкций 386'ого... Короче, поковырявшись, я пришла к выводу, что отдельный модуль можно потерпеть - всё равно его код клеится к самой программе...



Самое что интересное, я сделала BAT файл, в котором всё прописано. Даже конфигурация без модуля, а также отладочная сборка. Всё выглядит очень серьёзно, что ни кто и не скажет так противно: "Бейсик..."