Схожі на голосовий помічник та україномовні — айтівці фантазують про власні мови програмування

Якби ви створювали власну мову програмування з будь-якими характеристиками в межах нашої реальності, то якою б вона була? Ми поставили це питання читачам та отримали кілька десятків відповідей. Нам запропонували український синтаксис, суб’єктноорієнтовану парадигму та мову, схожу на голосовий помічник.

Тож якби айтівці могли створити будь-яку мову програмування...

«Це була б мультипарадигмальна мова (обʼєктноорієнтована і функційна); мала б garbage collector та можливість для ручного memory management і low-level операцій. Також вона мала б повноцінну багатопотоковість із green/lightweight threads, continuations/coroutines тощо. Мова і платформа — набір специфікацій, які дозволяють сторонні імплементації» (Java Team Lead).

«Це була б мова із вбудованим ML у компілятор на основі есперанто. Ти передаєш текст, він компілює його в базову версію коду. Якщо треба підкоригувати, то розробник коригує і передає це компілятору» (Data Engineer).

«Головними фішками моєї інтерпретованої мови програмування були б синтаксис українською та стандартна бібліотека. Так, кодити нею було б трохи незручно, але весело :)

Структурні елементи залишив би такими ж, як у більшості мов. Інтерпретатор мав би функціонал зберігання стека викликів, як у Python, щоб у разі помилки, яку ніде не обробили, дізнатись, де саме вона виникла, і розуміти порядок викликів функцій.

Також тут були б два режими виконання: запуск файла-пакета та інтерактивний режим.

Деякі з ідей я вже реалізував, а код дуже примітивного інтерпретатора виклав у відкритий доступ на GitHub.

1. Пакети — файли, які можна підключати, очевидно, в інші пакети. Виконуваний код можна писати в будь-якому місці пакета.

2. Галуженні алгоритми — оператор «„якщо“».

Приклад:

 
якщо (істина)

 // код

 інакше якщо (1 == ""текст"")

 // код

 інакше

 // код

 кінець;

3. Функції — можна визначати в скоупі пакета, класу, а також в інших функціях.

Приклад:

  функція факторіал(число: ціле): ціле

 якщо (число == 0)

 повернути 1;

 кінець;

 повернути число * факторіал(число - 1);

 кінець;

6. Лямбда-функції — змінні, що містять функцію та мають свій спосіб визначення.

Приклад:

 ф = лямбда ()

 друкр(""це лямбда"");

 кінець;

4. Класи — обʼєкти, які можуть наслідувати інші обʼєкти, де базовим є клас «об_єкт»; клас може містити статичні члени та члени обʼєкта класу. До статичних належать змінні та лямбда-функції, визначені прямо в скоупі класу, а до членів обʼєкта — змінні, але визначені в конструкторі, та функції й оператори, визначені в скоупі класу. Наслідуючи клас, можна перевизначати оператори, змінні, а також функції, включно зі статичними членами.

Приклад:

 клас Кіт : Тварина

оператор __констуктор__(я: Кіт, ім_я: рядок)

я._ім_я = ім_я;

кінець;

 функція ім_я(я: Кіт): рядок

 повернути я.ім_я;

 кінець;

 кінець;

5. Псевдоніми та розширення. Псевдоніми — переназивання типів, як у Go чи С++ (typedef). Розширення потрібні для переназваних типів, щоб додати до них нові методи, оператори, змінні та статичні члени.

Приклад:

 псевдонім Стан для ціле;

 розширення Стан

 оператор __рядок__(я: Стан): рядок

 якщо (я == 1)

 повернути ""Стан 1"";

 інкаше якщо (я == 2)

 повернути ""Стан 2"";

 кінець;

 повернути ""Стан 3"";

 кінець;

 оператор &(я: Стан, інший: Стан)

 повернути я & інший;

 кінець;

 кінець;

5. Обробка помилок. Базовим був би клас «„Помилка“», від якого наслідувати інші види помилок.

У прикладі генерується помилка ділення на нуль та перехоплюється за допомогою відповідної конструкції:

 блок

 1 / 0.0;

 піймати (п: ДіленняНаНуль)

 друкр(п);

 піймати (п: Помилка)

 друкр(п);

 кінець;

«Python Developer.

«Ця мова була б компільованою, максимально швидкою. А ще містила б надійний код прямо з коробки — компілятор не давав би вам написати поганий або небезпечний код» (JavaScript, TypeScript та React Developer).

«Це була б компільована, багатопотокова, суворо типізована та імперативна мова програмування» (Senior PHP Developer).

«NormalJS — та сама JavaScript, але суворо типізована й об’єктноорієнтована» (Junior Front-end Developer).

«Суб’єктноорієнтована парадигма, коли патерни людської психіки стають частиною структури та алгоритмів програми. Технічні характеристики: Alpha-Omega, Aequilibrium, Engine V8, просторово-фононна форма логіки інтерфейсу, преонний генератор випадкових властивостей» (Senior Socionics Developer).

«Я б поєднав Java із простотою та оригінальністю Go, тільки без каналів, або ж Rust. Крім того, додав би деякі конструкції Python, але боюся отримати нову Scala :)» (CTO).

«Як на мене, зараз не вистачає простої та легкої мови загального призначення, яка б підходила для навчання і входження в програмування. Нинішні мови переобтяжені деталями, важкими для розуміння початківцями.

Якщо людина починає свій шлях у програмуванні з JavaScript, їй доведеться розібратись з HTML, порядком завантаження сторінки та іншими „проблемами“ вебу ще до написання першого коду. А потім вивчати неочевидне: приведення типів, захоплення контексту та інші важкі для розуміння речі.

З іншими мовами схожа ситуація. Наприклад, Java вимагає писати класи й методи для того, щоб зробити найпростішу програму; далі доведеться вивчати наслідування та інші речі, без яких можна писати більшість алгоритмів, але знання мови без них буде неповним.

Для дітей є Scratch, але для старших класів школи та непрофільних вишів він не підходить, оскільки важливо вивчити алгоритми та деякі початкові концепції.

Хороша мова для початківців повинна інтерпретуватись у браузері, щоб її можна було запускати звідусіль. Бажано, щоб для написання першої програми не потрібно було вивчати додаткових концепцій, а запускатися вона могла однією командою.

У цій мові має бути змога створювати функції та об’єкти, мати певні вбудовані колекції. Але без важких для розуміння концепцій, бінарних операторів, класів, рефлексій, захоплення контексту, необов’язкових операторів на кшталт "switch" чи "try".

Важливою частиною концепції такої мови є повідомлення про помилки. Частина сучасних мов мають незрозумілі сповіщення, які не вказують, що саме пішло не так. Натомість деякі розробники змогли скласти повідомлення, що описують абсолютно всі аспекти тієї чи іншої проблеми. Також важливими є вбудовані засоби форматування і лінтери, щоб писати погано форматований код було неможливо» (Senior Software Developer).

«Моя мова програмування була б дуже простою і „голою“, але з можливістю розширення та ускладнення через плагіни. В результаті ми мали б в одному флаконі PHP, Golang і Rust» (Priest of Voodoo Tribe).

«Моя мова базувалася б на принципах структурно-подійного програмування. Мала б слабку типізацію, була б модульною та універсальною для FE та BE, fail safe та fault tolerant» (Senior ФОП).

«Це була б мова, схожа на голосовий помічник, щоби голосом або текстом давати команди машині, яка б їх виконувала. Для програмування озвучувався або писався б певний алгоритм, який би потім виконувався. Також у цієї мови був би набір необхідних інструментів для кожної сфери її застосування, наприклад, вебфреймворк, взаємодія з базами даних, обчислення, навчання тощо. Тобто програміст будує архітектуру і систему алгоритмів, передає це машині, і вона вже реалізовує. Звісно, до алгоритмів будуть застосовуватися певні вимоги та стандарти» (Junior Python Developer).

"Кілька років тому я захопився іграми студії Zachtronics та захотів зробити свою в такому ж стилі. Zachtronics знаменита головоломками, часто на тему програмування. Тому мова, яку я тоді вигадав, не має стосунку до нормального програмування, її ціль — бути складною та цікавою у використанні, а геймплей гри полягав би у розв’язанні різних задач цією мовою. Іншими словами, це — есоланг.

При створенні цієї мови мене понад усе цікавила ідея самомодифікації. Тому синтаксис має бути надзвичайно простий, тоді як поведінка — комплексна.

Найпростіша складова мови — це команда, така як FIND чи REPLACE. Команди мають один аргумент у форматі тексту та відділені від інших команд та аргументів символом |.

Тож найпростіший рядок програми може мати такий вигляд:

""|FIND|XXX|REPLACE|YYY|""

Але програми не відокремлені від тексту, який вони модифікують — натомість написані усередині. Аргументи можуть бути будь-яким текстом, тому команди можуть вставляти, редагувати та видаляти інші команди.

Всередині кожного рівня гравцю дають текст, задачу, що потрібно зробити з цим текстом, та окреме місце для написання коду. Коли гравець написав код та хоче дебажити чи виконати його, він натискає кнопку play. І написаний ним текст — команди та аргументи — прикріплюються до початку тексту, який треба редагувати. Для цих команд не важливо, чи це звичайний текст, чи в ньому записані інші команди — весь відредагований документ є потенційним кодом.

То як же це все працює? При натисканні play гра ітерує від початку до кінця документа багато разів. Коли гра знаходить команду, вона її виконує. Це модифікує текст, розташований після команди, і так далі — до кінця документа. Потім починає з початку документа, доки на одній з ітерацій жодна з команд не спрацює. Наприклад, візьмемо таку програму:

|FIND|XXX|REPLACE|YYY|

|FIND|ZZZ|REPLACE|XXX| 

Документ містить субстрінг ZZZ. На початку текст програми вставляється перед документом, і починаються ітерації. Перша команда не знаходить XXX, тому не виконується. Далі друга команда знаходить ZZZ та замінює на XXX.

Більше команд у документі не залишилось, тому ця ітерація закінчується та починається наступна. Тут уже перша команда знаходить XXX та замінює на YYY. Друга команда не знаходить нічого, і ітерація закінчилась. На наступній ітерації жодна команда не знайшла нічого, нічого не змінила, тому програма вважається виконаною.

При створенні цієї мови в мене була надія, що я зможу придумати багато задач, які було б цікаво розвʼязати. На жаль, або фантазії забракло, або сама мова недостатньо експресивна.

До того ж кожний рівень мав би мати вигляд: перетвори текст X на текст Y. І на мою думку, в таку гру мало хто б грав — у тій самій Zachtronics усі ігри мали красиві пояснення — мовляв, ось ти ремонтуєш таємничий комп’ютер, і що більше рівнів пройдеш, то більше сюжету дізнаєшся.

Для кожного рівня мені треба було б згенерувати багато тексту, щоб ці задачки не були тривіальними. Втім, певно, всі ці труднощі можливо розвʼязати.

Текст можна згенерувати за допомогою GPT, щодо літературної теми гри в мене з’явилися ідеї, а для експресивності саму мову можна допрацювати — наприклад, в мене є ідея для conditional команди.

Але до цього всього в мене не доходять руки. Я сподіваюсь, що когось тут ці ідеї надихнуть на свою самомодифіковану мову для редагування тексту" (Hobbyist GameDev).

«Мова програмування = людська мова. В ідеалі, це була б найвідоміша у світі мова програмування, і синтаксис там був би українською. Бо англійська вже всім набридла :)

Щоб компілятор був зі штучним інтелектом, але з відмінним захистом і безпекою від самопрограмування, та можливістю переписати програму під себе. Щоб компілятор розумів звичайні слова, без тупих алгоритмів на кшталт ""if-else-for"" і складних рекурсивних функцій й наслідувань з параметрами тощо.

Щоб брак коми чи дужки не зносив всю програму. Щоб в інтегрованому середовищі було максимально зрозуміло, що та куди писати, що натискати, замість купи іконок з непотрібними інструментами, які ніхто не знає.

Винайти ПЗ, розпланувати до деталей систему, створити концепцію та ідею програми і так складно. Так ще й потрібно враховувати мову програмування, її можливості, бо як же з user story або use case перевести в ""(function=print&name>coutPublic};"" (це гіперболічне перебільшення). Хто взагалі додумався до такого?

Замість того, щоб придумати одразу „людську“ мову, яку б розумів комп’ютер, ми повинні вчити та розуміти мову комп’ютера. То хто ж кого створив і хто кому служить?

Досить вже мучити програмістів цими складними незрозумілими мовами! Треба спрощувати собі життя, а не навпаки» (Middle Business Analyst).

«Ідеальна мова, яку ніколи не створять, — така, що покриє не лише бізнес-логіку, а й усе, що стосується результивної системи, декларативного опису модулів чи сервісів з інтеграціями, логіки всередині них, їхнього деплою і стану роботи, і все це — однією мовою на деві/стейджі/продах. Також вона повинна мати можливість транскрипції на будь-яку іншу мову під капотом. І ще IDE одразу під цю мову, щоб під час розробки можна було не виходити за межі цієї IDE взагалі» (Lead Back-end Engineer).

«Ця мова має повністю замінити та витіснити «1С» з української землі. Назвемо її, наприклад, «9Ж» (Senior Software .NET Engineer).

«Ідеальна мова програмування — максимально автоматизована. Команди даються живою, розмовною мовою, а AI інтерпретує його у цілісний код потрібного рівня та пропонує варіанти написання тих чи інших шматочків коду залежно від задач програміста. При цьому для Front-end можна розробити автоматизовану систему інтерпретації макета дизайнера у код, що сильно скоротить час на розробку вебзастосунків та сайтів» (Junior Front-end Developer).

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU