Clarion 11-12

[Игорь Столяров]

У Clariona до сих пор есть хороший язык, развитая система шаблонов

Полностью согласен. Но это с нашей стороны, его пользователей.
А сколько программистов, которые могут этот хороший язык развивать или хотя бы поддерживать ?
Я так подозреваю, что это и есть основаная проблема со всеми планами развития в SV.
Нельзя вот так просто взять пресс денег и пойти купить себе интеграцию Unicode в Clarion 12.

А может и со здоровьем что

Не по наслышке знаю, что на пиво у программистов с братанами время всегда находится.
Поэтому если DevCon отменили - то это либо деньги, либо здоровье. Точнее уже их отсутствие.

[kreator]

Я не про сейчас. Понятно, что сейчас пациент в коме. А 20 лет назад ситуация была другой. Да и из комы можно вывести, было бы желание. Например, организовать что-то типа опенсорса, SV остался бы координатором.

[Игорь Столяров]

Например, организовать что-то типа опенсорса, SV остался бы координатором.

OpenSource - это маркетнговый миф. Крупнейшие хабы по развитию того же Linux
находятся в Microsoft и Oracle, которые заинтересованы в его существовании. И так во всём.

Я тут недавно пообщался с новыми авторами OpenSource проекта ZINT.
Это просто полный п..ец ! Профессиональная импотенция, раздувание щёк и рассуждения
об их дао во вселенной. И на этом всё. А ! Мне ещё рекомендовали перейти на разработку в UNIX.

При этом никто не смог объяснить почему их OpenSource код нормально собирается только в текущей
версии Microsoft Visual Studio ... А когда я сам разобрался - то просто удалил это всё и забыл как страшный сон.

[Губин Игорь]

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

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

Не удивлюсь, если конечной целью питерцев было именно такое.

[finsoftrz]

Я не про сейчас. Понятно, что сейчас пациент в коме. А 20 лет назад ситуация была другой. Да и из комы можно вывести, было бы желание. Например, организовать что-то типа опенсорса, SV остался бы координатором.

20 лет назад RZ решил полностью сменить правила игры и уйти на Clarion#, оторвавшись от наследия topspeed. Оттуда ноги растут и у текущей среды разработки, которая создавалась для Clarion# на С# по этой причине, а возможность работать с "легаси" win32 оставили на время для обратной совместимости. В результате большая часть разработчиков свалили с клариона совсем (на с#, windev, в веб), а от Clarion# осталась только среда, которую оставили для работы с win32, уже убрав к нему приставку "легаси".

[finsoftrz]

При этом никто не смог объяснить почему их OpenSource код нормально собирается только в текущей
версии Microsoft Visual Studio ... А когда я сам разобрался - то просто удалил это всё и забыл как страшный сон.

Не понял, совсем отказались от использования zint? Я как бы тоже через него двумерные шк вывожу.

[finsoftrz]

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

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

Не удивлюсь, если конечной целью питерцев было именно такое.

Имеет, но это очень странно, когда разработчик семейства неплохих компиляторов хочет отказаться от них и перейти на использование каких-то сторонних опенсорсных. Топспидовские компиляторы отличаются от других некоторыми внутренними механизмами, поэтому такой переход неминуемо выльется в необходимость тщательной отладки всплывающих проблем. У нас тут был небольшой диалог с Джонсоном. Когда я предположил, что RZ хочет сделать транслятор с клариона в си, по аналогии с Clarion# (что логично вытекает из сказанного RZ), Брюс что-то весь разволновался, сказал, что речь только про перекомпиляцию рантайма, а что будет с компилятором клариона, неизвестно, а рассуждения на эту тему спекуляция. То есть, мы говорим при уход с топспидовских компиляторов, но не знаем, что это предполагает, а должны оплачивать подписку за какие-то никому не видные изменения в рантайме. По мне это совсем не катит.

[kreator]

20 лет назад RZ решил полностью сменить правила игры и уйти на Clarion#, оторвавшись от наследия topspeed.

А он один это решил? Может другого варианта не было? Было, например, обсуждение как переделать старую версию для запуска в 64-битной среде?

[finsoftrz]

Насколько я читал, 32 разрядная среда была еще при топспиде, а отдельные компоненты всплывали в с55 (это уже SV). По какой-то причине не пошла в продакшен. Решения принимает RZ, он почти не контактирует с пользователями. Точнее пытался во временя c7, там такой негатив в ответ получил, что начал удалять посты и банить пользователей. Потом совсем закрылся.

[Губин Игорь]

По какой-то причине не пошла в продакшен

Насколько я помню, они не смогли довести оболочку до ума, постоянно всплывали какие-то глюки.

[finsoftrz]

По какой-то причине не пошла в продакшен

Насколько я помню, они не смогли довести оболочку до ума, постоянно всплывали какие-то глюки.

Отдельные утилиты в составе с55 были написаны на кларионе, скорее всего, та оболочка тоже (что вполне логично было бы). Вся эта тема пришлась на период распада топспида в 1999 году, когда Баррингтон продал бизнес группе инвесторов во главе с RZ. Могли тупо не договориться.

[kreator]

Скорей всего было банально. Майкрософт уведомил о том, что новая Винда (Виста) не будет запускать 16-битные проги. Поспрашивали сообщество. Никому не надо, у многих ещё ДОС. А когда петух клюнул, времени не оказалось, стали смотреть на сторонние разработки. Да и сами разрабы SV - нафиг надо напрягаться, всё же нормально было.

[finsoftrz]

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

[Губин Игорь]

Я подумал, а почему RZ решил (пусть на словах) отказаться от нового типа данных UString в пользу общей декларации String

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

Т.е., что там в этой строке, ASCII или Unicode, определяется лишь функцией её обработки. Если это БД, то, чуть утрируя, вообще ничего не надо делать, храним как храним, ищем как и искали. Получается, что надо переписать лишь куски связанные с работой со строками (поиск, замена и т.п.) и выводом на экран и печатью.

[finsoftrz]

А что там править, передавай как string.
Еще, я не видел, чтобы поддерживали в одном приложении строки и в ansi и в юникоде. Либо все ansi, либо все юникод.
Кстати, в группах один товарищ допытовался, нужен ли на самом деле кому юникод и зачем. Может мысли у него есть какие.
Интересно у Михаила поинтересоваться, покупают ли у него примочки с юникодом и насколько на самом деле это востребовано.