colorForth вам у руки.

В найдавніших високорівневих мовах програмування (FORTRAN, COBOL) рівень відступу мав синтаксичне значення, наприклад:

С=10
      C=10

(перший рядок — коментар, другий — присвоєння змінній C значення 10)
Пізніші діалекти цих мов від цього відмовились. Просто це інколи незручно, веде до неочевидних помилок. Деякі з сучасних мов, (перш за все, python) теж використовують цей засіб (хай навіть і в інший спосіб — для передачі вкладеності алгоритмічних структур) — в загальному випадку це зручно (зрештою, маркувати вкладеність відступами прийнято і в мовах, де це не має синтаксичного значення), але інколи залежність від відступів стає перешкодою для реалізації певних можливостей (в випадку python'а — повноцінних анонімних функцій, аналогічних JS'івським). Тобто, виникає потреба якось цю екзотику обійти, щоб можна було писати повноцінний структурований код, не використовуючи відступів.

Інший приклад. Мій улюблений APL, для якого використовується специфічний набір символів. Що одразу створює труднощі вводу, ставить додаткові вимоги до робочого середовища мови. Це не щось нездоланне, але закономірний наслідок цього — поява мов, що надають такі ж можливості, але з використанням чистого ASCII. В принципі, було б зручно, якби той же APL мав вбудовану можливість використовувати ASCII-транслітерацію як альтернативний варіант паралельно з традиційними «кракозябликами» (але тоді він перестане бути APL'ом).

Тепер, кольорова розмітка. Існують різні формати передачі кольорового тексту (ANSI-послідовності в консольному виводі, HTML, RTF та інші мови розміток, двійкові формати...) — якщо кольоровий код представлено не мовою розмітки поверх звичайного тексту, а чимось іншим, це вимагає спеціального редактора (тоді як мова розмітки дозволяє вибирати між простим текстовим редактором та WYSIWYG). З точки зору читаності — програміст не може бути дальтоніком, текст програми не можна роздрукувати на чорно-білому принтері — це все обмеження, які неминуче доведеться обходити, якщо кольорова мова раптом стане не езотерикою, а мейнстрімом. Що, фактично, штовхає нас до мови розмітки назразок HTML поверх мови, яка передає код програми. По суті, ми отримаємо звичайну текстову мову, де будуть ключові слова назразок <red>, <blue> чи ще якось, яку можна альтернативно відобразити в вигляді кольорового тексту з прихованими ключовими словами.

Зазвичай програмний код не має вигляд текстового документа. Він має вигляд файлової системи з текстових документів. Причому файлова система має ієрархічну структуру - як зазвичай програмні елементи глобального рівня (модулі, класи, функції і т.д.) У мене була ідея, що це варто було б використати - по функції на файл, наприклад... доки на третьому курсі ми не вивчали Java. З того часу традиційна модель мене повністю влаштовує.
Ще одна дурна ідея з 4-го курсу - ОС, де замість файлової системи реляційна БД. Тобто замість ls треба виконувати SELECT.

Можна обмежитись  файловою утилітою, яка використовуватиме для роботи з файловою системою синтаксис SQL. Директорію (чи, точніше, всю систему директорій) можна представити як таблицю з рекурсивними посиланнями, плюс деякі допоміжні віртуальні таблиці (напр., для швидкого доступу до файлів та директорій за заданим повним шляхом). Структура таблиць при цьому лишається незмінною.
Далі, варто подумати про інтеграцію цієї SQL-підсистеми в повноцінну СУБД, де можна створювати різні додаткові таблиці, індекси тощо, зв'язані з таблицею-директорією...

bash десь там. Тільки весь вивід летить у повернений результат

#  s1

s1() {
    echo --$1--$2--
}

s1_result=`s1 A1 A2`
s2_result=`s2 B1 B2`

echo s1_result = $s1_result
echo s2_result = $s2_result

# s2
echo --$1--$2--

~/temp $ s1
s1_result = --A1--A2--
s2_result = --B1--B2--
~/temp $ s2 Q1 Q2
--Q1--Q2--

https://replace.org.ua/post/156421/#p156421
    Зовсім непоміченою пройшла доволі оригінальна ідея (одного славного анонімного чоловіка) про бездротові методи передачі інформації на короткі дистанції, засобами мобільних легких станцій швидкого розгортання. Правду кажучи досі захоплює ту частину мого розуму що відповідає за генерування всіляких зображень.
    Тільки уявіть, - станція подібна до синхротрону в одному місці передає (по повітрю або по дузі-трубі під технічним вакуумом) потік твердотільних носіїв інформації до іншої станції, (з невеликою відстанню від одного високощільного носію інформації до іншого на дузі-траєкторії) на середній швидкості в ~2400m/s чорт забирай, до кожного навіть можна пригвинтити конденсатор(для утримання інформації на носію типу DRAM) для швидшого зчитування/запису "при циркуляції на льоту" в іншій станції, і поверненню на потік передачі.

Редаг.
Звісно можна передавати різне добро між містами. Грім-Пошта - "Доставка з майбутнього".

Hardware захист ПЗ. Для ігор принаймні, вважаєте уже опція? -Ідея не покидає мене, бачиться якийсь флешко-подібній пристрій з простими функціями для гри(на MCU) - ніяких інших даних. Ціль тільки сповільнити взлом (на максим. можливий час), - прошу, уявіть тільки скільки можна наштовхати дрібних важливих функцій для гри(особливо з відкритим кінцем і множинними напрямами розвитку) які буде необхідно розгадати (умовному зломнику)  для того аби гра для всіх ймовірних напрямів функціонувала як слід, корректно, збалансовано, як задумано розробниками.

Думаю мою ідею (Грім-Пошта - "Доставка з майбутнього".) треба відправити одному з тих ментально неврівноважених мільйонерів-шарлатанів.
Тільки представлю її в листі як "Гіпер-Доставка"...or "HyperDelivery-GigaExpress"(читається акронім як ЕйчДі-Джі)...Залишилось тільки добути контакти і зробити CG відео презентацію (дякувати богу якісь широкі, чи будь які взагалі, розрахунки їм не потрібні, аби виглядало круто - от саме як моя штука (що є вигаданою системою транспортування матеріалів, для однієї гри(майбутнє, хайтек, гігаполіси, андроїди і тд.) яку я колись задумував)).