Полностью согласен с автором. Где подписаться? :)

Я с 2000 года говорю, что Rexx это самая сильная сторона OS/2. К сожалению современные разработчики отодвинули его на задний план. И упорно не хотят ни чего о нем слышать.

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

Ещё одна особенность Rexx'а - он не навязывает стиль написания кода. Все иные языки требуют от программиста следования жестким догмам "шаг влево, в право - попытка бегства, прыжок на месте провокация" (с) От сюда появляются Си программисты и прочие. Я например перешел на Rexx с Паскаля, и поначалу строил конструкции к которым привык на нем. И только через пол года начал потихоньку от них отходить, открывая для себя все новые и новые грани Rexx. Мой же друг, до сих пор, пишет на Rexx как на Форте. Он жутко упрямый и очень тяжело расстается со старыми привычками. В обсуждении новости "Warpstock Europe: Изменения" Sergey Posokhov привел пример якобы кода Rexx. Смею утверждать что это код Basic'ка реализованный на Rexx. Образец кода Rexx я привел ниже в цепочке обсуждения. Вывод: Rexx не навязывает жесткого стиля написания программ, и может вынести почти любой. Одновременно он "мягко" подталкивает, можно сказать, даже "обучает" использовать свои конструкции - так как только в этом случае получается красивый и эффективный код Rexx. На практике это дает возможность быстрой адаптации программистов к условиям Rexx, снижает временные и как следствие материальные издержки.

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

Дело не в языке, а в программисте :)

SERG, соглашусь на 70%. На остальные 30% скажу, что "дело не в языке, а в информационном окружении".

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

С этой задачей Rexx справляется значительно части иных языков программирования.

Кто-нибудь из комментирующих использует NetRexx?

Я не использую. Но собираюсь. Часть моих планов связана с мобильными устройствами, вот для созданиях приложений для них собираюсь использовать NetRexx. Хотя признаю, что его применение возможно значительно шире.

Главным тормозом для меня является отсутствие документации на русском. А заниматься разбором перевода Промта, такого объема, я пока не готов. :)

1) Ява - говно. Скрытое состояние и ссылочный навес над ним. Rexx никогда не разовьётся в ООП, и это хорошо.

2) Он и над JavaScript вполне возможен. "Было бы желание".

3) "Parse" не оператор, это макра из Лиспа.

Sergey Posokhov: Rexx никогда не разовьётся в ООП, и это хорошо.

Мда... Позволю себе напомнить.

"Язык программирования Object REXX (объектный REXX) — объектно-ориентированный скриптовый язык, основанный на языке REXX, созданный корпорацией IBM первоначально для операционных систем серий OS/2 и OS/390." ([url])

"С середины 1990-х годов, два новых варианта Rexx появились:

* NetRexx : компилируется в Java байт-код с помощью исходного кода Java, это не имеет зарезервированных ключевых слов на всех, и использует модель Java объект, и, следовательно, как правило, не вверх-совместимый с «классическим» Rexx.

* Объект REXX : объектно-ориентированные в целом вверх-совместимой версией Rexx. "([url])

Второе: А оно нужно? Лично я всегда считал ООП - ошибкой и тупиком. А в последнее время все больше публикация с похожими точками зрения. Типизацию данных вообще считаю бредом, так как невозможно все подогнать под одну грибенку. Напеши тип (объект и т.п.) вселеной, с учетом ВСЕХ её свойств от "частицы бога", до черной дыры. Тип написать не возможно, а значит и "раборать" с ней тоже нельзя. А вот если типов данных нет, тогда за милую душу - все становятся на свои места. А главно расширяется до безгонечности, что согласись для вселеной не маловажно. :)

Да, здесь мы с тобой "на разных барикадах".

Sergey Posokhov: "Parse" не оператор

Согласен, Parse - это инструкция. "А хрен редьки не слаще?" (с) И он встречается в нескольких языках программирования, иногда называется по другому. Но Parse есть в Rexx, и он далеко не единственное достоинство Rexx.

Очень уважаю твой труд "OS/2 API Research", читал запоем. Хотел даже писать тебе, что ты так мало уделил внимание Rexx. Теперь понимаю что это безполезно. И в этом вопросе скажу "Иван, ты не прав!" (с).

>Напиши тип (объект и т.п.) вселеной, с учетом ВСЕХ её свойств от "частицы бога", до черной дыры.

На этот случай есть техника под названием "подмешивание", она применяется в языке Scala, вот так:

x = new Dog with Wings

x.fly()

Создали летающую собаку и запустили. Пока ты читал эту строку, она уже улетела.

В других языках (Сишка, Лисп, Эрланг, Питон) так сделать не получится. Но это не значит, что строгая типизация - что-то плохое.

Sergey Posokhov: есть техника под названием "подмешивание"

Как вариант. Но все таки по упрямлюсь, подобные механизмы я называю "костылями". Подобные "дополнительные подсистемы" лишь за уши натягивают идею до желаемого результат, при этом перегружают самую идую, программу, понижают стабильность систему в целом и прочее и прочее. Вообщем от них больше проблем, чем пользы.

Для проверки своих бредовых идей я использую инструмент называется "доведения до абсурда". Берем идею и по шагово "расширяем" её сначала в "одну", затем в "другую" сторону, до полного абсурда. Большинство идей не выдерживают и трех "шагов в строну". Идея считается жизнеспособной если она способна существовать в "полном абсурде" с обоих "сторон". В крайнем случае она должна позволять максимально приблизиться к "абсурду".

Sergey Posokhov: Но это не значит, что строгая типизация - что-то плохое.

Ни в коем случае. Типизация - это один самых древних костылей в программировании. Изначально это облегчало написание самого языка и понижало ресурсоемкость техники. А потом она слишком прижилось, так что теперь придеться избавляться от неё лет 50. Я точно не доживу. В бытность фаната Паскаля, я "молился" на типизацию. Но за последний годы Rexx "показал" мне что есть другой путь. И он появился как минимум одновременно с типизацией. Только на "перекрестке сверунли" не туда.

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

В таком случае, авторы языка Erlang свернули как раз в нужную тебе сторону. В этом языке нет типов данных, но есть механизм сопоставления с образцом.

Создаём три структуры данных:

X = {rectangle, 10, 10}

Y = {circle, 10}

Z = {apple, 10}

Пишем функцию для расчёта площади:

area({rectangle, Width, Ht}) -> Width * Ht;

area({circle, R}) -> 3.14159 * R * R.

Вызываем её:

area(X) %% площадь прямоугольника равна 100

area(Y) %% площадь окружности равна 314.159

area(Z) %% ошибка...

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

Так что третьего пути нет: либо как в Erlang, либо доступ по указателям - но тогда уже и строгая типизация и проверки всего вся.

Такие дела.

Sergey Posokhov: Если же ты хочешь полностью динамический язык, где доступ к данным происходит по их именам

Если честно не совсем понял о чем ты. Выдлею несолько базовых идей Rexx которые мне симпатизируют:

1. Составные имена пременных.

2. Отсутствие классических массивов (следствие первого).

3. Отсутствие разницы между процедурами и функциями.

4. Отсутствие типа данных. Вернее не так, наличие одно типа данных - текстового.

5. Инструкция Parse.

6. Инструкция Interpret.

7. Перегруженность do. Хотя это многим не нравиться.

8. и так далее. Здесь нет смысла писать все.

Вот пример массива из одной моей программы (он малась устарел, но для примера пойдет):

Base.Counter=0 /* Счетчик уникальных номеров */

Base.Pump.Base='УнКод' /* Основа для создания уникальных номеров */

Base.Buch.ListCode='УнКод1 УнКод2' /* Список уникальных номеров существующих насосов */

Base.ListTelefon='Телефон1 Телефон2' /* Список телефонных номеров */

Base.Telefon.Code='УнКод' /* Уникальный код связанного насоса */

Base.Code.Name='Имя насоса' /* Имя насоса. Отображется в списке */

Base.Code.Description='Описание' /* Описание насоса */

Base.Code.Production=0 /* Производительность, куб/ч */

Base.Code.EngineSize=0 /* Мощность двигателя, кВт/ч. Расход энергии. */

Base.Code.ComStart='' /* Команда запуска насоса. */

Base.Code.ComStop='' /* Команда остановки насоса. */

Где Code - уникальный номер насоса.

А вот пример работы с ним:

pumpName = value(Base.PumpCode.Name)

/* Ищем номер телефона по коду насоса */

do n=1 to words(Base.ListTelefon)

if value('Base.'word(Base.ListTelefon,n))=pumpCode then do

pumpTelefon=word(Base.ListTelefon,n)

leave

end /* if */

end /* do n */

Здесь использую "новый" тип массивов который я активно у себя внедряю. Он состоит из переменой структуры, обычно так её и называю Structure, и элементов массива любой сложности, доступ которым осуществлется по именам хранящимся в Structure. Плюсы:

* Простое определение количества элементов массива words(structure)

* Доступ к элементу по номеру word(structure,n)

* Доступ к элементу по имени (имя может нести значение, например дата) - напрямую

* Простое добление нового элемента.

* Простое удаление элемента.

* Простая проверка наличие элеменат в массиве. wordpos >0.

* Простая сортировка массива.

* И прочее. Думаю идея понятна.

Он подходит для данных объемов от десятков до нескольких тысяч (в rexx строка безконечная). Кроме того если данных очень много, их всегда можно переорганизовать, что бы уменьшить количество корневых элементов.

Да, знаем такую структуру данных, именованный массив, он же HashMap и он же хеш. Есть ещё LinkedList и ArrayList, им надо памяти поменьше и добавление в них быстрее (но не поиск).

Здесь полезно знать не как это делается в Rexx, а каким будет снижение быстродействия: логарифмическим или линейным. И тогда мы узнаем, что будет, если программа встретит несколько миллионов (а не тысяч) элементов, названия которых она вывалит в массив "Structure".

Линейные там задержки скорее всего.

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

Про задержки ни чего сказать не могу (я же не программист :), скорость работы с моими объемами данных (~20 000 записей за год на 10 насосов, в настоящий момент имеем 3 года), меня устраивает и резерв очень большой. Скорость загрузки программы зависит от машины и составляет 3-10 сек, при этом происходит полная настройка программы, а не только загрузка данных. Вывод запрашиваемых данных на любой машине - задержка меньше секунды.

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

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

Sergey Posokhov мне кажется вы не правильно поняли

оппонента. Rexx есть по умолчанию в системе и позволяет пользователям не программистам решать задачи в их профессиональной области.

P. s.: за OS/2 API Research спасибо.

tux, ты не когда не думал, что на классическом rexx'се можно без особых проблем почти полностью (по прикидкам до 70%) повторить ООП?

tux,все забываю спросить, вопрос про NetRexx, был из чистого интереса или есть проекты? Сам пишешь на нём?

На NetRexx можно сказать не пишу хотя был случай написал как-то расчетную программу для работы. Непонятна дальнейшая судьба NetRexx и открытие исходников ничего похоже не изменило. Насчет возможностей повторить ООП на классическом Rexx это не ко мне (хлеб свой не программированием зарабатываю). Я считаю язык программирования должен помогать решать мои задачи, что Rexx (хорошо что он есть в базовой поставке системы) с успехом и делает ну а все остальное от лукавого.

tux, NetRexx изучал по английской справке?

Ну вот свершилось. Закончился Chaos Constructions 2013. По его результатам можно сказать следующее:

1. Он прошел успешно.

2. Я впервые побывал на нем, хотя хотел попасть аж с 1998 года.

3. Была собрана меж городская осевка, проверено на практике возможность такого. Правда там было всего три осевика. Ну что для начала то же не плохо.

4. Я все таки сделал майку с эмблемами eCS и OS/2.

5. Было принято решение сделать осевку на базе Chaos Constructions ежегодной. В перспективе открыть отдельную секция.

6. Мною прочитан доклад по Rexx на тему «Язык программирования REXX в современном мире. Создание кроссплатформенных программ». Адаптированный доклад можно прочитать здесь ([url]). На сколько я могу судить, все прошло хорошо. Да же задали ряд вопросов. Как только узнаю адрес видео, добавлю ссылку в статью.

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

8. Первые объявлено об открытии электронной библиотеке по Rexx (librexx.ru) Материала пока мала, но это только начало. Так что прошу заходить, пользоваться. Если есть иной материал шлите на меня для публикации. tae(очень злая собака)aport.ru

9. Мои суммарные затраты составили 10т.р. Если не считать кражи телефона (то же мне культурная столица). Но его, кстати, украли из-за Всех Вас. Так как не приехали, и не создали толпу. Вот теперь пусть вас совесть мучает. :)

Вполне подъемная сумма за год. Все начинаем копить. Каждый день нужно откладывать по 30 рублей, и через год у вас будет нужная сумма. У нас чашка кофе стоит дороже.

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

Чуть позже объявим ответственных за координацию общих усилий. На их имя высылать заявки с примерными темами докладов и иными хотелками или вопросами.

Хватит спать! Выходим из сумрака!