НовостиСобытияКонференцииФорумыIT@Work
Идеи и практики автоматизации:

Блог

По поводу совместимости версий языков программирования

Андрей Колесов
12.10.2011 11:23:56

Небольшое упоминание о Фортране вызвало не только ностальгические воспоминания о "старых добрых временах", но позволило вспомнить о некоторых проблемах сегодняшнего дня. А именно о совместимости версий языков программирования и возможности унаследованного исходного года.

По этому поводу я получил письмо от приятеля:

Цитата
Я провозился с попытками перевода кода Visual Basic 6 в Visual Basic 2008 и понял, что это большая проблема, по крайней мере для меня. Явное декларирование переменных - это только цветочки. Изменений довольно много! Там и массивы теперь с только нуля начинаются, и тип переменной (например A$ неявно не A$ а STRA), нет теперь PUT и GET и др. А те средства, что в Студио есть для конвертации VB6 в VB2008 годятся только для самых простых и очевидных текстов. написанных на VB6. В связи с этим у меня два вопроса:

1. Риторический - почему тексты, написанные, например, на Фортране в 1977 году (а то и в 68) идут на современных компиляторах, а в BASIC они берут и запросто меняют синтаксис, не поддерживая более ранние версии. Что за идея? Я понимаю интерактивная среда, графика, интепретатор, но ведь в Студио есть для VB2008 console application. Так почему для нее не поддерживается стандарт (например VB6) и его расширения типа VB2008, 2010 и др. Есть этому разумное объяснение?
2. Практический. А у тебя дистрибутив VB6 есть?


То, что переход от VB6 к VB.NET – это проблема, было известно еще 10 лет назад, как только Microsoft объявила про намерение выпустить VB.NET (могу привести большой список статей, опубликованных тогда же).
Именно поэтому VB6 у меня сохранился…

Комментариев: 16

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии

Андрей
12.10.2011 17:19:31

Ответ по моему прост. Изначально фортран работал на разных платформах и использовался в научной среде. А в научной среде было не зазорно поделиться библиотеками и исходными текстами расчетных программ. Поэтому и старались делать совместимыми со стандартом.

12.10.2011 20:46:39

Почему так происходит - это можно понять. Причин можно.
Вопрос сейчас не о том.
Создает ли это реальные проблемы для разработчиков?
Как они решаются?

Roman
13.10.2011 09:06:26

Конечно, создают. Решаются эти проблемы просто - переписываем код вручную. Конвертеры обычно не справляются со сложными алгоритмами, преобразуют лишь самые простые куски кода. Вопрос в другом - а зачем переходить с VB6 на VB2008?

13.10.2011 09:38:52

Мне бы не хотелось отвечать за приятеля Сергей, цитата которого приведена в посте. Надеюсь, он ответит сам.
Я сам могу ответить сегодня лишь "гипотетически" поскольку уже 10 лет не пишу код.

В обшем: примерно потому же, почему приходится переходить с вполне, вроде бы устраивающей XP на Windows 7. НАпример, при переходе на новый ПК вы обнаруживаете, что VB6 просто перестает работать, или в какие-то моменты перестает (есть такая проблема: старые программы не работают на быстродействующих компах).

Вы не можете купить и поставить у себя VB6.
В нем нет чего-то полезного, что есть в VB2008...

Konstantin
12.10.2011 23:55:44

Можно с некоторым приближением использовать VBA, который есть уже почти во всех крупных приложениях(MS Office, Adobe Photoshop etc). VBA оставил себе синтаксис VB6 с некоторыми специфическими допиливаниями - хоть какое-то решение проблемы...

13.10.2011 00:13:59

Нет, это не решение вопроса. VBA может заменить VB только на уровне небольших программок, не более того...
Да, и для небольших не годится... smile:)

Legio
15.10.2011 12:27:32

А в чём, собственно, разница? Да, для работы придётся запускать не exe'шник, а открывать какой-нибудь xls-файл -- но дальше-то будет всё примерно то же самое. Я как минимум одно не очень маленькое приложение, нарисованное в VBA и запускающееся из Excel'я знаю. И не знаю никаких причин, которые бы помешали существовать другим приложениям такой же или даже большей сложности.

15.10.2011 12:33:28

Мы говорим с вами о разных вещах. Никто не сомневается, что на VBA можно написать достаточно серьезное приложение. Это даются в конца 1990, началось с выпуска Office 97 (по этому поводу - полно публикаций, книг, разработок).

Но перенести в VBA приложение из VB - это проблема. Часто почти нерешаемая (и ненужная для решения).
VB и VBA - похожие, но в целом - разные вещи.

Legio
15.10.2011 12:44:56

Приложение запускается, по мановению волшебной палочки скрывается окошко офисного приложения и, вуаля, на экране остаётся только форма. Оконечному пользователю так даже, может, и удобнее будет -- он этот эксель-вёрд-юнеймит по десять раз на дню запускает и +1 кнопочка на панели инструментов его не смутит.

Насчёт целесообразности -- это вопрос, да. Но чтобы по каким-то чисто техническим причинам нельзя было перенести что-то исполняемое из VB6 в VBA...

15.10.2011 12:48:12

Можно вас спросить: сколько времени вы занимаетесь разработкой на VB и VBA?
Я спрашиваю не в плане, попытки вас как-то уязвить, а просто, чтобы понять...

Legio
15.10.2011 13:01:01

"Промышленной" -- с 2006-го года. "Углубляю и допиливаю" одну монструозную софтину, у которой вся документация и все примеры кода только на VB6 (софтина сторонняя, а её разработчик очень неторопливо переходит на .NET). И что VB6, что VBA рядом со мной в избытке smile:D

15.10.2011 13:19:34

Тогда у нас нет предмета для спора, поскольку я давно не работал...
Вы хотите сказать, чт можете просто загрузить VB-приложение в среду VBA и он заработает?

Не отдельные подпрограммы, а весь исходный код.

Возможно, я что-то забыл, но я уверен (и много писал по этому поводу), что это невозможно. Отличий очень много, начиная с того, что формы в VBA и VB - разные.

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

Ладно, останемся каждый при своем мнении.
Я просто не уверен, что проблема поддержки VB6 настолько актуальна, чтобы спорить по этому поводу.

Legio
15.10.2011 13:28:20

Просто загрузить -- конечно нет. Перенести исполняемое приложение с гораздо меньшими, чем при переносе на .NET, затратами по части времени и нервов -- скорее всего, да.

15.10.2011 13:47:52

С такой постановкой вопроса могут только согласиться. Разумеется, все зависит от сложности (размеров) приложения и самое главное - для чего выполняется перенос.

А зачем вообще, нужно переносить приложение из VB6 в VBA?
Работает себе в VB6 и пусть работает?

Вы получили приложение в исходных кодах VB6, а самой системы VB6 нет?
Это уже задача. Но опять же, ее решение зависит от того - что вы собираетесь делать с этим приложением в исходный кодах. Как-то его запустить, чтобы что-то посчитать, а потом через месяц забыть?
И ли вы собираете его серьезно эксплуатировать и развивать?

Ответ зависит от постановки целевой задачи.

15.10.2011 12:56:27

Что касается моего опыта.
Я плотно занимался проблемой VB и VBA во второй половине 1990-х (до 2002).
http://www.visual.2000.ru/develop/vb/index.htm

Основные публикации по VB приведены тут: http://www.visual.2000.ru/develop/ms-
vb/index.htm
К сожалению, сборник публикаций по VBA не сохранился (он был на сайте MS).
http://www.visual.2000.ru/develop/ms-vb/vba.htm

Roman
13.10.2011 09:01:34

Ну, VB6 И VBA - совсем разные вещи... VBA (Visual Basic for Application) используется лишь как средство для расширения возможностей других каких-либо продуктов (MS Office и пр.), но он никак не может использоваться в качестве полноценного языка программирования для написания самостоятельных программ (VBA не умеет компилировать (из объектных файлов) исполняемые файлы Windows).

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии