Мощная среда ZXDev для разработки НА ПЯТИ ЯЗЫКАХ для ZX готова к тестированию

[Oleg N. Cher]

psb, в основном я под этим понимаю расширяемый формат составных документов каркаса BlackBox Component Builder и всю массу управляющих элементов, которые можно на нём разработать плюс инструменты по визуализации и редактированию (кнопки, строки ввода команд, визуальные мини-редакторы свойств и форм), которые легко встроить в компонентную среду на базе этого каркаса, гораздо легче, чем вцепиться намертво в текстовое представление и городить текст, а потом поверх него различные xml-файлы форм, свойств проекта, мейк-файлы и прочея.

Конечно можно иметь исходник в тексте и рядом с ним текстовый же xml, который будет расписывать где в каком месте этого исходника какой цвет и где вставлена картинка, но — упс — подредактировали чуток текст и всё рассыпалось. Зачем же так изголяться? Не для редактирования ли мы с этим xml мирились? Только для какого редактирования? А почему нельзя редактировать двоичный файл? Религиозная привязанность к любимому Notepad'у? Не лучше ли адаптировать системы контроля версий в контексте наших задач и использовать более компактный и универсальнее, чем xml, двоичный формат?

В BlackBox есть конвертеры из и в текстовое представление (html, rtf, txt и т.д.), так что совместимость по исходникам (и для контроля версий) остаётся, никуда мы от неё не убежим.

Vitamin, теги — не для чтения. Это компромисс между человеческим и машинным, подход, который имеет ограниченную применимость. Также для меня уродливо выглядит попытка насадить весь мир на xml для чего надо и в особенности для чего не надо.

Посмотрите, господа, вы в одних случаях "за" текстовый вид (например, в xml, где оно в ряде случаев чревато ошибками, громоздко, времяёмко по распарсиванию, да и требует больших объёмов памяти), а вот промежуточное представление для трансляции Оберон-программ в виде текста на языке Си — смущает. Что не так? Хотите чтобы вся музыка и графика тоже хранилась в xml, а не в mp3, jpg и png? Ну может со временем так и будет, если адекватные дяди из майкрософт постараются. Когда-то майкрософт удивлялся плоским html и считал их неэффективными, использовал двоичные .doc и .xls форматы. А теперь сажает на xml весь мир. Не надоело хавать всё, что суют под нос?

Господа, понятно, что расширенные возможности форматирования текстов программ могут понадобиться не всем из вас, и я, разумеется, собираюсь поддержать простой plain текст в виде UTF-8, например, и с раскраской синтаксиса, когда-нибудь. Я не ставлю цель угодить всем. А то некоторым здесь больше нравится придираться к моим формулировкам и затеять священную войну за "а мне так больше ндравица", чем аргументированно доказывать свою точку зрения, или, не дай бог, увидеть преимущества чего-то выходящего за рамки привычного и поучаствовать в его развитии.

[Advertiser]

[Vitamin]

Vitamin, теги — не для чтения. Это компромисс между человеческим и машинным, подход, который имеет ограниченную применимость. Также для меня уродливо выглядит попытка насадить весь мир на xml для чего надо и в особенности для чего не надо.

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

Когда-то майкрософт удивлялся плоским html и считал их неэффективными, использовал двоичные .doc и .xls форматы. А теперь сажает на xml весь мир. Не надоело хавать всё, что суют под нос?

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

[psb]

psb, в основном я под этим понимаю расширяемый формат составных документов каркаса BlackBox Component Builder и всю массу управляющих элементов, которые можно на нём разработать плюс инструменты по визуализации и редактированию

поискал скриншоты, ничего нового не увидел, что бы отличалось от, скажем, vb или делфей 2004 года выпуска (они описания форм хранят в тексте). куда смотреть, где примеры того, о чем вы говорите?

[Oleg N. Cher]

psb, пример — сама среда BlackBox Component Builder. Она в одном своём внутреннем формате сочетает то, на что в других случаях используется много форматов. Вы открываете Word и сохраняете документ в docx, открываете Си-редактор и сохраняете в текст, открываете в браузере HTML, но чтобы сохранить сразу всю страницу, Вам нужен уже веб-архив chm или mht. BB предлагает для всего этого один расширяемый формат .odc (Oberon DoCument). И для гиперпереходов, и для исходников, и для форматированных документов с динамическими картинками. Это универсализация подхода к документам вообще. А поглядеть можно... ну, например, посмотрите как изящно в тексты встраиваются коммандеры (аналог кнопки-командной строки), можно разработать подобные же, но другие по функционалу элементы управления.

Если неохота вникать в среду BlackBox, читать доки, пробовать (давно штудировали VisualStudio с многотонным талмудом в руках?). Если пипл не понимает и не хочет понимать преимуществ форматируемых элементов в исходниках (например, подчеркнуть важный фрагмент кода, а сверхважный выделить красным жирным; не до конца отлаженное пометить курсивом, а временный код бледным серым),

тут я пас.

[ZEK]

psb, он о маразме BB, там можно к примеру гифку анимированую или кнопку вставить в исходник, и что там как в RTF можно текст раскрашивать

[Vitamin]

- Итак, у нас есть 50 разных контейнеров для хранения текстовой информации, каждый со своими плюсами и минусами.
- Какой ужас! Надо что-то с этим делать! Надо придумать контейнер, заменяющий всю эту свору!
...
- Итак, у нас есть 51 разный контейнер для хранения текстовой информации...

[psb]

я кстати согласен, что иметь возможность делать пометки "на полях" у кода (т.е. то, что не войдет в сам исходник, но будет с ним связано), вести какие-то обсуждения, и возможно даже выделять код цветом (такое было, кстати, в шторме) - иногда было бы интересно. как и расшаривание редактирования кода в ide между участниками. это все хорошо.

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

п.с. кто-то пытался сравнивать разные ревизии опенофисовских документов (текстовые xml, ага)? успешно (в смысле, все ли понятно)?

[Vitamin]

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

Это называется Code Review. И инструментов для этого- куча. И таки все эти пометки на полях и прочие обсуждения в конечный исходник не попадают.

[Alex Rider]

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

1. Можно смотреть и/или править код программы на компьютера без IDE.
2. Можно сравнивать версии кода при помощи текстовых компарилок типа WinMerge.
3. Возможность использовать для компиляции программы любые сторонныие компиляторы, поддерживающие синтаксис языка.
4. Распространенные системы контроля версий поддерживают слияние кода только в текстовом формате.

Хватит?

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

[Oleg N. Cher]

Как сопоставить высказывание Vitamin'а об ужасности парсенья бинарных файлов и существовании вполне себе бинарного формата BXML? Я не против этого формата. Но не соотношу его с текстовым XML. Токенизированный двоичный BXML в моих глазах приобретает перед текстовым xml важное преимущество — работать с ним должна только машинная программа, а не человеческое восприятие. Я против ручного редактирования больших массивов текста в перемешку с тегами. Это больше приличествует маньяку, чем похоже на комфортную работу в визуальном средстве разработки. А то, знаете, есть такая штука ant (кто юзает яву, тот в курсе), большим недостатком которого на мой вгзляд является xml-представление командного файла. Приходится много ручками редактировать. Не, ну может кому-то и нравится. А мне это настолько давит на мозг, что уж лучше бы там были плоские текстовые команды с параметрами, но без всяких тегов.

Чем же так принципиально трудно парсить бинарные форматы? Может парсилка кривая? Я исхожу из того, что любое текстовое представление ASCII (или UTF) — это подмножество бинарного представления, но не наоборот; соответственно, потенциал бинарей выше. Нет, Vitamin прав в том, что если сломается корявый софт и придётся отскребать мозги от асфальта, то тут да, сломанные бинарные форматы отдыхают, а xml безусловно вне конкуренции.

1. Можно смотреть и/или править код программы на компьютера без IDE.

ЗАЧЕМ?

Можно программить на компе без Visual Studio, в debug.exe. Или на ZX без асма, прям в хекс дампе.

2. Можно сравнивать версии кода при помощи текстовых компарилок типа WinMerge.

Как-нить откройте в BlackBox два документа и нажмите F9.

3. Возможность использовать для компиляции программы любые сторонныие компиляторы, поддерживающие синтаксис языка.

А почему Вы решили, что сейчас в XDev это нельзя? По-моему, я так и вызываю SDCC.

4. Распространенные системы контроля версий поддерживают слияние кода только в текстовом формате.

Решаемо. Было бы желание решать. Как сказал умный человек: кто хочет сделать, тот ищет возможности, а кто не хочет — ищет отмазки.

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

Так Вы бы попробовали. Нету там никаких воспомогательных файликов, только одни .odc

---------- Post added at 15:00 ---------- Previous post was at 14:55 ----------

Это называется Code Review.

Это называется костыль. Придуманный, чтобы заткнуть недостатки принятого решения в виде текстового хранения исходников.

Но, впрочем, пусть будут оба подхода, раз они востребованы.