1

Тема: Різні випадкові ідеї.

Що як мати вихідний код не у форматі простого текстового документу. -Скільки цікавих речей і корисних можна було б приладнати до такого файлу (якогось нового стандарту X). Хтось мав уже таку думку?

2

Re: Різні випадкові ідеї.

colorForth вам у руки.

Подякували: tchort1

3 Востаннє редагувалося tchort (17.04.2021 15:55:46)

Re: Різні випадкові ідеї.

Треба ж таке. Я до речі Forth вчив (по книзі десь 1980-х). (Мова до слова варта вивчення. Мав інтересу в ній.)

4

Re: Різні випадкові ідеї.

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

С=10
      C=10

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

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

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

Подякували: tchort1

5 Востаннє редагувалося P.Y. (17.04.2021 19:12:29)

Re: Різні випадкові ідеї.

Але, якщо думати в цьому напрямку (тобто, текстовий формат програми та спеціалізований редактор, що цей текст візуалізує), виникають деякі суто практичні ідеї. Наприклад, як задати у програмі якісь графічні дані? Нехай у тексті буде посилання на файл з зображенням, або самий вміст цього файлу (перекодований у base64 для аѕсіі-сумісності), або блок svg. Тоді в візуалізуючому редакторі цей вміст буде відображатись як безпосередньо зображення (яке тут же можна й відредагувати у вбудованому графічному редакторі; процес розміщення файла на диску можна від користувача приховати). Таке зображення можна включити, наприклад, у вивід програми (зрозуміло, що йдеться про вивід не в звичайну текстову консоль, а у щось більш багатофункціональне), розмістивши його всередині текстового рядка, або передати на обробку якійсь функції для роботи з зображеннями, і т.п.
Виникає шкідлива ідея дозволити використовувати такі вбудовані зображення й за межами літералів-рядків — наприклад, в іменах змінних. Чому вона шкідлива? Як мінімум, через те, що можна зробити зображення схожими між собою (наприклад, з різницею в відтінку окремого пікселю). Або й ідентичними графічно, але розміщеними в  різних файлах. Тобто, редактор має якимось чином відстежувати, щоб таких ситуацій не виникало — і якщо в другому випадку це ще можна формально відстежити, то розбиратися, де закінчується межа схожості — задача нетривіальна. В текстовому представленні, проте, відрізнити схожі зображення можна просто за іменами файлів — таким чином, користувачі текстових редакторів отримають перевагу перед користувачами візуалізуючого редактора.

Подякували: tchort1

6

Re: Різні випадкові ідеї.

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

Подякували: tchort, P.Y.2

7

Re: Різні випадкові ідеї.

Підкину і свою ідею. Нехай у нас є простенька мова програмування назразок класичного BASIC'а. Типовим недоліком більшості старих класичних діалектів є відсутність у них підпрограм-функцій. З іншого боку, будь-яка програма є аналогом такої функції: ввід даних відповідає отриманню вхідних параметрів, друк — поверненню результату. Що, як це використати: дозволити програмі викликати інші програми як функції, при цьому обробляючи перший IPUT та останній PRINT усередині викликаної програми-функції як, відповідно, її заголовок з параметрами та присвоєння результату. Наприклад:
fact.bas:

INPUT a
b=1
FOR i=2 TO a
b=b*i
NEXT
PRINT b

main.bas:

FOR i=1 TO 10
PRINT i, "! = ", fact(i)
NEXT

При цьому, fact.bas можна запустити як самостійну програму (яка прочитає число й виведе його факторіал), а можна викликати як функцію з іншої програми.

Подякували: tchort1

8

Re: Різні випадкові ідеї.

ОС, де замість файлової системи реляційна БД. Тобто замість ls треба виконувати SELECT.

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

9

Re: Різні випадкові ідеї.

koala написав:

Ще одна дурна ідея з 4-го курсу - ОС, де замість файлової системи реляційна БД. Тобто замість ls треба виконувати SELECT.

PalmOS -- якщо правильно пам'ятаю, все всередині було в базі, з ключами, які, зокрема, вказували, від якої аплікухи записи. Файли .pdb на компі (з аплікухаи та їхніми даними) були експортованими записами plam os data base.
Розмір запису не міг перевищувати 4К, через це простий блокнот не міг створювати більші «файли»

10

Re: Різні випадкові ідеї.

P.Y. написав:

дозволити програмі викликати інші програми як функції, при цьому обробляючи перший IPUT та останній PRINT усередині викликаної програми-функції як, відповідно, її заголовок з параметрами та присвоєння результату.

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--
P.Y. написав:

При цьому, fact.bas можна запустити як самостійну програму (яка прочитає число й виведе його факторіал), а можна викликати як функцію з іншої програми.


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

Подякували: P.Y., leofun012

11

Re: Різні випадкові ідеї.

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

І на вході не стандартний ввід, а вже зразу параметри. BASH узагалі початково ближчий до структурованого процедурного стилю. В принципі, bash і надихнув мене на цю ідею. А ще — блок-схеми алгоритмів, де, за відсутності загальноприйнятого способу опису функцій, їх інколи малюють аналогічно програмам з «вводом» і «виводом».
Порівняно з bash'ем, ідея також у тому, щоб узагалі уникнути перетворення дані=>текст=>дані при передачі параметрів та результату: якщо програма викликається як функція, то компілятор має спеціальним чином обробити INPUT та PRINT, розпізнавши їх у певних позиціях і перетворивши на заголовок та присвоєння результату (тоді як bash просто перехоплює текстовий вивід і підставляє його в рядок). Таким чином, отриманий машинний код може бути таким же оптимальним, як код функції на Сі.

Подякували: ReAl1

12 Востаннє редагувалося tchort (03.05.2021 12:46:02)

Re: Різні випадкові ідеї.

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

Прихований текст

https://upload.wikimedia.org/wikipedia/commons/f/fa/HD.6B.438_%2811969997484%29.jpg
https://upload.wikimedia.org/wikipedia/commons/thumb/f/fd/Arial_view_of_PS_at_CERN_in_1965.jpg/1025px-Arial_view_of_PS_at_CERN_in_1965.jpg

Ігноруйте надписи, уявіть що відстань між кільцями - десяток км

https://upload.wikimedia.org/wikipedia/commons/f/ff/Intersecting_Storage_Rings_01.png

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

13 Востаннє редагувалося tchort (03.05.2021 16:50:42)

Re: Різні випадкові ідеї.

P.Y. написав:

Але, якщо думати в цьому напрямку (тобто, текстовий формат програми та спеціалізований редактор, що цей текст візуалізує), виникають деякі суто практичні ідеї. Наприклад, як задати у програмі якісь графічні дані?

Три речі що мені спали на думку тоді першими, чи то підштовхнули до такої думки взагалі, незгадати, це:
1. Графічні схеми відношень, для якогось блоку коду, - швидка міні документація, авто генерування стрілочок що вказуватимуть на ці схеми відношень-взаємодій та можливість коментувати роботу якоїсь частини по відношенню до якоїсь іншої частини, інтегрувавши текст пояснень прямо в те генероване зображення з коду.
2. Коментарі/документація різними мовами прямо з файла, на місці.
3. Без макро та "закоментувань" вимикати-ховати і замінювати одні блоки коду іншими тільки кліком. Або навіть трансформувати його в щось інше.(що вміють деякі IDE зараз.)

Додано:
    Насправді, давно кружляє ця думка - якось розлучити опис механізму(програмний код) з описом для людей(коментарями, поясненнями) - аби останні було важко додати такі що не відповідали б механізму, підсвічували ці структури пояснення виконані згідно якимось правилам якщо вони вірогідно не правильні, або інакше якось обмежували змушуючи думати про те що відбувається насправді (відносно того що бажано, чекається, уявляється).