- Оригинальное название: Bob Zaunere on the new IDE and Clarion.NET
- Дата публикации: 24.07.2005
- Дата перевода: 09.08.2005
- Источник: http://www.clarionmag.com
Translated and published with the permission of CoveComm Inc, publisher of Clarion Magazine.
Переведено и опубликовано с разрешения компании CoveComm, издателя Clarion Magazine.
AG: Andrew Guidroz (Эндрю Гайдроз)
DH: Dave Harms (Дэйв Хармс)
BZ: Bob Zaunere (Боб Заунер)
Предисловие: это интервью между AG, DH — редакторами Clarion Magazine и BZ. Интервью происходило по телефону. Интервью было записано и потом воспроизведено без особых изменений в печатном виде. Для меня оказалось достаточно сложным переводить разговорную речь, поэтому перевод не особо точен 🙂
AG: В эфире Планета Кларион, сегодня З0 июня 2005 года. Произошло много интересных вещей с момента нашего последнего выхода в эфир.
DH: Мы очень долго ждали новостей от SoftVelocity и наконец дождались.
AG: Ага, точно. Вышел релиз 6.2 и хотфикс к нему 🙂
… пропущено (не имеющий особого значения треп) …
DH: … вообщем, у нас на связи Боб Заунер и у нас есть к нему миллион вопросов. Во-первых, спасибо за то, что уделили нам время. Презентация Clarion.NET на Бразильской конференции породила множество ужасных дискуссий…
BZ: Я расскажу об этом, чтобы вы поняли направление. Эта презентация, … мне кажется это достаточно смешным. Я получал удовольствие от чтения диких предположений, когда у меня выдавалось свободное время. На самом деле не предполагалось показывать эту презентацию, потому что она не имеет под собой контекста. Перед презентацией было длинное объяснение о том, что мы показываем, зачем и для чего. И очень интересно видеть, как люди не имеющие никакого представления приходят к своей интерпретации о том, что они видели и что это значит.
AG: Подходящая фраза для этого в сообществе — мы называем это каким мы это видим, а если мы этого не видим, мы выдумываем это.
DH: Не могли бы вы рассказать кратко о целях этой презентации?
BZ: Контекст на самом деле такой. Выполнена некоторая работа над IDE, в частности объединения некоторой новой функциональности, которая нам нужна для .NET стороны линейки продукта. И мы выбрали для показа это, потому что это качественно новое и интересное. Что мы не показали и что не имеет никакого смысла … потому что для меня не было никаких инструкций для того, чтобы объяснять это, в действительности была показана часть реализации для .NET. Это позволило людям верить в то, что .NET выйдет ранее, чем Clarion 7. Clarion 7 не готов к выходу. Мы только начали с IDE. Еще одна сумашедшая вещь. На самом деле все просто — мы просто решили показать это потому, что это качественно ново и интересно. Мы решили что будет смешным показывать как много мы сделали на этой стороне продукта.
DH: Т.е. на самом деле это не является главным в том, чем занимается SoftVelocity в данный момент?
BZ: Нет, на очень длительное время. Все что вы можете сказать касательно этого, что это только маленький кусочек того, чем мы занимаемся в данный момент, и как мы далеко еще от .NET части проекта.
AG: Так не будет такого же IDE для C7?
BZ: Показанное IDE, часть IDE, которое будет использоваться. Т.е. будет общее IDE. Пока оставим без вопросов эту часть. Но несомненно, есть две вещи, в которых вы правы. У нас есть два внутренних IDE. Одно из них 100%-е Win32 IDE, и второе не 100% Win32. Одно из IDE мы вам показали. Оно является смешением обоих IDE. Что мы реально сделали, так это объединили функциональности обоих IDE, для того чтобы получить одно IDE, которое будет поддерживать все, что необходимо для обоих продуктов.
DH: IDE, которое вы показали основано на IDE SharpDeveloper и мы говорили об этом немного в последний раз. Не могли бы вы рассказать каким образом вы пришли к решению получить лицензию на SharpDeveloper, для использования его как базиса для конечного продукта?
BZ: Мы присматривались к IDE SharpDeveloper-а долгое время. Это IDE имеет большую функциональность, которую мы хотели реализовать. Нам необходимо было обеспечить поддержку Clarion.NET как языка. Например, возможность, простейший пример, дизайнер форм, который работает с .NET-контролами. У нас был свой собственный дизайнер форм. Но он не такой полный, какой в SD IDE. Так или иначе, пока вы пишите IDE, может так получиться что IDE это костяк, с группой вещей встроенных в него. И это не просто. IDE достаточно сложный зверь, спрятанный под колпаком. Потому что существует множество взаимодействий, которые нужно обработать между апплетами или компонентами, это водопровод, если можно так сказать, это критическая часть IDE. UI (user interface) нет. Это водопровод. Теперь у нас есть большая история по расширению IDE. И это IDE имеет собственный водопровод. Что мы нашли, когда смотрели код SD это архитектура которая очень похожа на то, что мы имели. И если бы это было бы не так, то мы возможно бы не стали использовать SD, так как это было бы лишней тратой времени. Но так как это очень похоже и философски близко с тем как мы думаем о том, каким должно быть IDE, мы нашли полное соответствие.
DH: это интересная точка зрения, так как я думал, что вы обратили внимание на это IDE, потому что существует возможность скачать код IDE, потому что это IDE с открытым исходным кодом и вы можете рассматривать его не покупая, обсуждать, вступать в некоторые переговоры…
BZ: Ну да … это правда.
AG: Мне кажется, что не все до конца понятно, я просто хочу сделать все прозрачным. Дэйв думает так, я по другому, я уверен, что существует миллион различных мнений в новостных конференциях. Вы решили, несмотря на то что это open source продукт, и некоторые люди используют его путем написания своих плагинов, у вас другой подход, вы решили взять копию продукта, лицензировать ее, а далее изменять существующий код, т.е. получиться ответвление от существующего продукта.
BZ: с самого начала мы знали, что исходный код претерпит значительные изменения. У нас никогда не было мысли выбросить наше собственное IDE со всеми его сложностями и просто переписать наше IDE под SD IDE. SD IDE, те парни очень талантливы. Отличная архитектура, по моему мнению. Но это IDE разрабатывалось для того, что им необходимо, для достижения их целей. И их IDE разработано специально для ручного кодирования. Наше же IDE явно основывается на различных точках зрения. Множество людей пишут «руками» на Кларионе и находят, что этот язык достаточно хорош, но на самом деле наше IDE это генератор приложений, словарь и шаблоны.
AG: вы видите к чему я клоню. Мне любопытно вот что, сейчас уже версия 1.1, а завтра они выпустят 1.2. Ничто не мешает мне зайти на сайт и скачать последнюю версию IDE. Но я дословно должен пройти через вас для установки, потому что вы изменили исходный код и вы в дальнейшем являетесь хранителем исходного кода.
BZ: это точно, так и есть
DH: как теперь я думаю, просто чтобы все было прозрачно, как я понял SD, версия которую можно скачать с сайта бесплатна и выпущена под GPL, и GPL ограничивает. Я думаю. Если вы сделаете плагин для SD я подозреваю, что плагин не попадет под GPL. Это так?
BZ: да я верю, что это так. Я думаю в контексте SD, что у них есть опция допускающая плагины, которые не попадают под GPL. Но я не уверен насчет этого.
DH: Да. Ребята из SD могут распространять одну версию под GPL, и другую версию как коммерческий исходный код … для SoftVelocity.
AG: Как делают MySQL.
BZ: Да абсолютно точно.
AG: хорошо, люди увидели IDE на конференции разработчиков …
BZ: Ага. В действительности наше объяснение никто не услышал, мы показали вам некоторую функциональность, которая будет присутствовать в новом IDE. Таким вот образом будет выглядеть UI. Не были показаны app-генератор и словарь, они остались за кадром. UI измениться. Но некоторая функциональность уже присутствует. И мы хотели показать прогресс в .NET компиляторе и рассказать о некоторых изменениях и языке и т.д. Это была часовая презентация. Мы не могли рассказать обо всем. Я планировал показать что сделано для компиляции Win32 кода для различных версий Клариона: 7, 6, 5 и т.д.
DH: текущая версия Клариона — 7. Теперь новое IDE. Вы можете компилировать под Win32? А вы можете скомпилировать Clarion.NET и Win32 и VB.NET и C#?
BZ: Да, точно так. Этот момент не был включен в поспешно сделанный AVI-файл, но я планировал это показать, но у меня не было визы, у меня были установленные копии 5.5, 6 и 7-ки, и я собирался сказать «Посмотрите. Перенесем это и скомпилируем на 7-ке, теперь на 6-ке», и я собирался показать еще несколько небольших трюков. Но у меня не было шанса сделать это. Я был в «заключении».
AG: Этот запуск нескольких версий, вы смогли это сделать в новом IDE, потому что это не Кларион. Это не использует общие ресурсы для разных запусков, я про DLL и тому подобные вещи?
BZ: Вообще то нет. На самом деле, архитектура которую мы делаем и которая будет встроена в следующий релиз уже существует в старом IDE. Что произошло и над чем мы бились долгое время: это проектная система, которая знает версию. У вас есть зарегистрированная версия IDE. И она находит правильные версии для линковки. Т.е. она знает, что нужно для приложения, если вы сказали «Я хочу работать под 6-кой» и вы сказали «Добавить TOPSPEED драйвер в проект», она знает «А, это 6-ка, добавим тогда C60tpsx.dll», а не C7 dll или какие либо другие. Т.е. эта часть не изменилась. Этот код у нас уже есть.
AG: Т.е. ваше собственное IDE, которое вы начали делать с нуля, … вы не будете его использовать, но будете использовать функциональность которую вы напишете для него.
BZ: Что то вроде того. IDE, внутреннее IDE — оно будет отдельно от SharpDeveloper-а. Мы будет продолжать его разрабатывать. То что мы не сделали в старых IDE …
DV: Остановитесь здесь. Зачем нужно продолжать разрабатывать старое IDE, когда теперь есть SD как основа?
BZ: ОК, «разработка IDE» — раз это не понятно, давайте вернемся. Мы говорим о двух различных вещах. Мы говорим о Win32 и .NET. Давайте не будем забывать об этом. И я не говорю, что будет один большой генератор приложений. Многие из людей вообще не знают о слое ASL (Apllet Support Layer). Посмотрите на дистрибутив C4, или других Cxx, вы можете найти там СxxASL.DLL и многие другие DLL. Вы скажите «Я не использую эти DLL», конечно не используете, потому что это часть IDE. И если вы внимательно посмотрите на новое IDE, показанное в этом маленьком AVI, вы найдете C70ASL.DLL и ассоциированные с ним компоненты как часть IDE, которое я показал. И что дальше, мы продолжим встраивать части в IDE и расширять его. Потому что, когда они будут готовы, они будут встроены в то, что станет конечным IDE.
DH: это интересно. Если подвести итоги, то SD это как бы слой наверху и внизу, а на самом деле есть две большие подсистемы. У вас есть Clarion.NET подсистемы … о нет, я опять сбит с толку.
BZ: потому что это достаточно сложно.
DH: да уж. Вы многое рассказали сегодня. У вас есть то, что мы называем старым IDE, а SD будет как бы наружным слоем, так?
BZ: что то вроде того. Но UI изменится. Давайте на этом закончим с вопросами по этому поводу.
DH: ОК, вы купили лицензию на SD чтобы он помог вам в разработке Clarion.NET и затем, чтобы он помог вам в визуальном оформлении IDE сам по себе?
BZ: Да, я думаю это правда. Некоторые люди думаю, что IDE выглядит достаточно простым. Я вижу, что многие говорят «Я могу написать существующее IDE за две недели». Это пустяк. Поставьте галку и перекомпилируйте. Издевательство. Если вы посмотрите, что происходит «внутри» IDE, вы найдете, что IDE это сложный кусок кода. Вспомните Visual Studio 2005, она была beta пару лет. Может больше. Тестировалось каждая часть и работа все еще продолжается. И там не так много изменений по сравнению с Visual Studio 2003. Так что происходит? Я расскажу вам. IDE — это очень сложная часть кода. Люди имеют ошибочное представление об этом. Часть кода SD отлично поддерживает слой для работы под .NET. Это они сделали. И они могут работать с Win32 кодом тоже. Я не намекаю что они не хотят. А мы имеем разработанную систему для работы с Clarion-ом и Win32 с App-генератором и редактором словаря, и это то что мы представляем из себя сейчас. Весь существующий код нуждается в улучшении или он должен быть переписан, что конечно же мы не будем делать. Залицензировав SD мы сэкономили тысячи тысяч часов. Это не вызывает вопросов. Это не сделать за выходные.
DH: Т.е. ваши слова означают, что существуют две главные арены работы по отношению к IDE. Как мне кажется, одна часть по интеграции существующего кода IDE в базу SD. И вторая, что то вроде женитьбы текущего app-генератора, редактора словаря и редактора кода с .NET стороной вещей. Это точное утверждение?
BZ: Да, типо того. Вы знаете, это не сколько интеграция, потому что это звучит как плагин, я использую термин имплантация, потому что это несколько не совсем тоже, что и интеграция. В IDE существует множество внутренних взаимодействий между различными компонентами. И они могут быть на поверхности, возьмем наше IDE для C6. На поверхности кажется что IDE состоит только из нескольких компонент. Редактор словаря и app-генератор. Но внутри каждого из них содержатся намного значительные подсистемы. Некоторые из них разработаны только для коммуникации между аплетами, некоторые для других целей. Тоже самое касается и IDE SD.
DH: Есть еще одно мнение, люди говорят, «А почему бы вам не сделать плагин под Visual Studio?» То что вы описываете, звучит более сложным чем плагин … и плагин не обеспечит удовлетворительной функциональностью, это так?
BZ: В основном да. Может наступит тот день, когда мы скажем «ОК, давайте сделаем плагин для Visual Studio». Но это не будет сегодня, потому что я не думаю, что наши пользователи хотят этого. Написание плагина под VS определенно может быть выполнено. Мы можем сделать это, но это большая разница по сравнению с теми плагинами, что пишут другие люди. Они изначально говорят «Я возможно буду поддерживать компилятор», если он у них есть — «с поддержкой работы в редакторе и системе проектов VS». А это уже совсем другое.
DH: … которые намного проще, чем окружение app-генератора …
BZ: App-генератор, редактор словаря, шаблоны и т.п. Это монстры. Потому что VS IDE для ручного кодирования. И мы смотрим на них. Они хотят выглядеть как наш продукт, мы знаем что это факт. И нам нравится смотреть на них тоже сейчас. Есть несколько хороших вещей в VS 2005 …
DH: Извини, Боб. Давай немного остановимся. Ты сказал, что они хотят выглядеть как наш продукт, что это означает?
BZ: Есть люди, работающие в команде над VS, бывшие пользователи Клариона. Я не буду называть их имена. Они находятся под большим влиянием Клариона.
AG: Те из парней, которые напрямую вовлечены в часть по разработке C#, да?
BZ: Если более точно, то они в команде разработки VS. Но все таки … это конечно отклонение в сторону …
DH: это очень интересное отклонение. Я помню эту историю мне рассказывал Брюс Баррингтон, очень давно, о том как Бил Гейтс вызвал какого-то своего вице президента и капал ему на мозги, показываю на полдюжины копий Clarion Professional Developer, лежащих на столе, и говорил ему «Скажи мне почему эти парни могут то, что мы не можем».
BZ: Ептить. Я тоже очень хорошо помню эту историю. Я хочу вернуться к той точке, насчет AVI, который мы показали без всякого контекста, это не было маркетинговым ходом. Это была просто короткая техническая демонстрация и перед показом было длинное вступление о том, что мы собираемся делать и что уже сделано. Я понимаю все эти точки зрения людей, которые появились после. И некоторые даже были в восторге. Я не читал каждое сообщение. Их было слишком много. Но в основном, я видел достаточно позитивные отклики и только несколько ни черта не поняли, литературно выражаясь «APP-генератора больше не будет, что эти пацаны делают с этим продуктом?»
DH: Можем мы спросить пару особых вопросов о конкретных возможностях? Касательно отладчика, насколько я понял в SD версии 1.1 нет отладчика. В версии 2.0 встроенный отладчик. Вероятно отладчик для Клариона останется отладчиком от SoftVelocity. А как насчет Clarion.NET, будет ваш отладчик или отладчик SD?
BZ: Существует отличный способ для отладки .NET программ, потому что у нас есть весь IL-код. Внутри мы имеем и имели все это время зачатки .NET отладчика. Он конечно будет сильно отличаться от Win32 отладчика. Сделаем ли мы что нибудь с реализацией SD-отладчика, об этом пока еще слишком рано говорить.
AG: теперь о COM-контролах. Мы увидим эти штуки активными и работающими во время разработки в IDE?
BZ: Существует два момента, если смотреть на этот вопрос, и одно решение не может быть принято. Поэтому я не знаю какой ответ вам дать от лица фирмы. Существует два пути дальнейшей работы. У нас есть существующий редактор экранов (screen formatter). Он работает как Win32 с Кларион-реализацией Win32-контролов. И теперь у нас есть выбор использовать существующий Win32-форматтер или продолжить дальнейшую работу над form-дизайнером, который должным образом должен представить Win32-контролы. Это сильно отличается от того, что люди могут себе представить, готов спорить.
DH: Отличается дизайнер или процесс?
BZ: Процесс полностью отличен. Обработка контролов, работающих под .NET на 1000 % отличается от того как вы работаете с ними под Win32. Если посмотреть на почти любой компонент, любой Windows-контрол, например на кнопку, и посмотреть на ее реализацию в .NET и реализацию в текущем Кларионе, вы найдете множество совпадений и множество различий. Некоторые вещи, которые из года в год просят наши пользователи добавить в свойства нашей кнопки уже представлены, некоторые нет. Вообщем, один из путей — использовать form-дизайнер и реализовывать полностью отличный от сегодняшнего способ работы с контролами, а второй — использовать существующий Win32 редактор.
DH: и это поднимает другой вопрос, вопрос миграции. Я имею ввиду миграцию C7 или Win32-приложений на .NET, так как APP-генератор и form-дизайнер имеют различные возможности и контролы, что необходимо для миграции приложений?
BZ: Мы счастливчики в этом отношении. Когда я говорю «мы», я подразумеваю Кларион-разработчиков, потому что, как вы знаете в приложении контролы сохранены App-генератором. Т.е. мы имеем описательное представление контрола и его свойств. Это значит, что это представление может быть трансформировано, например, в окно. Но также, это представление можем быть трансформировано в то, что мы показали в AVI, т.е. в стандартный способ, который Win Forms использует для описания контрола.
DH: Точно, это преимущество Клариона перед многими языками, потому что он изначально весь представлен метаданными.
BZ: здесь есть один спорный момент, я и упоминал о нем в AVI. Сейчас в Clarion.NET не реализована Window-структура. И есть две причины для этого. Первая, в том, что Window-структура конечно же использует цикл ACCEPT. Вторая идет рядом …
DH: Как мне показалось цикла ACCEPT не будет в Clarion.NET, так?
BZ: В этой точке не будет. Наша изначальная задача в том, что мы искали и мы должны быть уверенными в том, что мы поддерживаем работу с .NET, также как это делает весь остальной мир. И есть противоположное мнение «Вы знаете, у нас есть лучший способ и мы сделаем .NET слой попозже». Мы рассматривали противоположное мнений. Поэтому мы должны сказать «ОК, вот так Windows работает с .NET, а так это будет работать в Clarion». А теперь, что мы увидели в AVI, если уйти от app-файла, то различия практически незаметны …
DH: Извини… Точки вставки в цикле ACCEPT не значительно отличается от точек вставки в методе обработчике событий, мы часто используем TakeEvent-метод, так ведь?
BZ: В точности так. Если вы посмотрите на представление окна для .NET, это конечно не Window-структура, но она достаточно хорошо читаема. Однако, как часто многие из нас редактируют сложный текст Window-структуры. Я думаю, что не многие и не часто. Обычно все происходит в дизайнере форм. Мы не работаем с описанием окна напрямую, особенно со сложными и большими описаниями. Это намного больше займет времени, чем открыть окно в дизайнере. И поэтому Window-структура на данный момент не реализована. О первой причине я сказал выше. Потому что мы планировали реализовать Clarion.NET следуя способу, которым пошли все другие .NET-совместимые языки, которые должны на 100% поддерживать интеграцию с базовыми библиотеками классов. Но есть еще одна причина, и она возможно более интересна. Одна из причин в том что в действительности текущая Window-структура и ее связь с Кларион RTL и компилятором и всеми Кларион подсистемами наиболее удобны. Это прекрасно, но есть ограничения которые связывают нас. Для добавления нового контрола или изменения существующего требуется очень много изменений. Это требует изменений в парсере Window-структуры. Требуются изменения в самом редакторе форм. Требует изменения в компиляторе и RTL. Поэтому, по моему мнению, это слишком сложно и требуется много кода, чтобы когда вам было угодно добавить новый контрол.
DH: я должен сказать, в противопоставлении к .NET, потому что там все основано на библиотеке классов. Там этот вопрос решается установкой вашего класса и возможностью использовать отображение для определения возможностей класса и т.д.
BZ: Да, точно. Изначально, дизайнер форм может подгрузить любой контрол. Это может быть контрол, созданный пользователем или какой-либо сторонний контрол, или новый контрол добавленный в базовую библиотеку классов. Существует возможность загрузить контрол и отобразить его свойства, это отличается от Клариона и намного более гибко.
DH: а будет портирован текущий дизайнер, для того чтобы использовать его вместо существущего .NET редактора форм?
BZ: нет. Я никогда не говорил об этом. Если мы портируем дизайнер, то он будет использоваться для Win32.
DH: ОК, это в смысле вопрос о том будет ли Windows forms дизайнер адаптирован для C7 или в C7 будет использован текущий дизайнер?
BZ: да, так точнее, а то это не одно и тоже. Пока я выбрал не реализовывать это сейчас под .NET. Мы исследуем это.
DH: не реализовывать что?
BZ: Window структуру. Вернее это частично так. Мы исследовали этот момент и пришли к выводу, что это можно сделать. И мы даже нашли способ, как сделать возможным существование Window-структуры. Но это будет не в динамике, как вы можете сделать сейчас в редакторе форм, это способ типо расширения. Но я не уверен, что мы выполним это.
DH: Я полагаю что должно быть преимущество в обратной совместимости. Должна быть возможность легко портировать приложение под .NET. А это звучит как будто возможен достаточно простой перенос, вы должны принять во внимание, что люди будут жаловаться почему нет этой возможности здесь и другой возможности там.
BZ: … и почему я не могу использовать компонент от сторонних разработчиков и как мне это сделать? Я не думал, что мы будем говорить о миграции. Даже если принять во внимание людей, у которых есть приложения хранящиеся не в app, полностью написанные «руками», все равно существует простой путь для переноса Window-структур в представление WinForms. На данные момент у нас нет такого кода, но мы думаем об этом. И я уверен, что мы сделаем это. Мы можем написать парсер и распарсить эту структуру.
DH: Довольно четкое направление.
BZ: Я не думал сегодня говорить о миграции. Я думаю это больше психологический момент. Люди могут предположить что-то ужасное: «Где WINDOW структура?» Не так актуальна миграция по сравнению с плюсами функциональности. Проблема звучит не так как «Оу, мое приложение не работает, потому что что-то произошло с Window-структурой». Как я говорил, к app-файлам это в основном не относится. А для «ручных» проектов существует понятный путь для того чтобы все получилось.
… на этом интервью прекращается, вернее при записи получилось много шумов, также поскипан дальнейший небольшой треп между DH и AG, что то вроде подведения итогов и саморекламы …