Якби ви розробляли мову програмування, як би це зробити? Які функції ви б уклали? Що б ти не залишив? Статистично чи динамічно набрано? Сильно або слабо набрано? Складено чи інтерпретовано? Обґрунтуйте свої відповіді.

• Я, безумовно, думаю, що мови функціонального програмування захопляться, тому моя мова буде функціональною. Див. Ефекти приборкання за допомогою функціонального програмування

• Я думаю, що незабаром у процесорів з'являться нитки ядер, а нитками він буде пекло керувати. Тож Акторська модель - це обов’язково замість ниток. Див. Erlang - програмне забезпечення для одночасного світу

• Я також вважаю, що OOP провалився, зв'язок між об'єктами вважався асинхронним . Тому я думаю, що нам потрібно передавати повідомлення з незмінними повідомленнями. Надіслати та забути. Як і в моделі Актора. Див. Об'єктно-орієнтоване програмування: неправильний шлях?

• Я думаю, що було б добре мати статичну типізацію , тому помилки вловлюються раніше в циклі розробки. Але я б використовував висновок типу, як у Haskell, так що розробнику не потрібно записувати тип скрізь у коді, як у C, C # та Java. Див. Learn You A Haskell для великого добра

• Я також створив би чудову бібліотеку інтерфейсу користувача з декларативним макетом , як у WPF та Android. Але я хотів би мати це як у функціональному реактивному програмуванні .

Таким чином, моя мова буде схожа на паралельність в Erlang, але з набором тексту, як у Haskell та графічним інтерфейсом, як у WPF.NET.

Примітка. Я використовував C-подібний синтаксис для опису функцій у цій публікації, але я не прискіпливий до самого синтаксису, доки це не щось смішне, як усі ключові слова CAPS.

1. Система набору тексту

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

//variable declarations
int anInt = 42 //anInt is now irrevocably an integer and assigning another type to it is an error
vartype aVariable = 42 //aVariable is currently an integer, but any type can be assigned to it in the future

//function definitions
int countElements(Collection c)
{
  return c.count();
} 

//c HAS to be a collection, since countElements doesn't make sense otherwise

void addToCollection(Collection& c, vartype v) 
{
  c.append(v)
}

//c is passed by reference here

2. Складено проти тлумачення

Мені б хотілося, щоб мова була складена достроково, або складена JIT, але не чисто інтерпретована, тому швидкість є причиною. Це пов'язано з пунктом 1 , оскільки оптимізуючий компілятор / тремтіння буде набагато простішим часом оптимізувати статично набраний код, а динамічно набраний код просто може бути залишений як є.

3. Закриття

Мова повинна підтримувати функціональні конструкції програмування, а функції повинні бути об'єктами першого класу.

4. Об’єктно-орієнтовані

Мова повинна дозволяти писати об'єктно-орієнтований код, але також повинен бути дозволений простий імперативний код. тобто, слід створити привіт світову програму так:

int main(string<> args=null)
{
  printf("hello, world"); 
  return 0;
}

// this code also demonstrates two other features,
// default arguments for functions (not explained further)
// and immutable lists like string<> (see 6. Built-in datatypes)

5. Простори імен

Простори імен - це гарна річ. Дуже мало матеріалів повинно входити в глобальний простір імен. Але якщо ви повинні розмістити речі в глобальному просторі імен, ви можете (ala C ++).

6. Вбудовані типи даних

Мова, як вбудовані типи даних, повинна мати такі конструкції:

• Тип intданих або типи. Якщо існує лише один intтип, він повинен мати необмежений діапазон. Якщо більше, то повинні бути неявним в приведення до базового типу найменшого типу , здатний утримувати результат обчислень з типом необмеженого діапазону , будучи найбільшим.
• Єдиний вбудований двійковий floatтип, який еквівалентний IEEE 754double
• listТип, що змінюється , реалізований у вигляді подвійно пов'язаного списку або блоку суміжної пам'яті, що містить покажчики на кожен елемент
• Незмінний listтип, який діє як масив, але розмір якого не можна змінити після створення
• Змінні та незмінні stringтипи, за замовчуванням незмінні.
• mapАбо dictтипу , який є змінним, і має незмінні ключі і змінювані і / або незмінні значення.
• Типи вбудованої колекції повинні бути однорідними набраними за замовчуванням, але можуть бути vartyped, якщо потрібно
• booleanтипу
• А nullабо noneтип, який може бути призначений змінній будь-якого типу.
• Змінні та незмінні setтипи
• decimalТип , який реалізує десяткових чисел з плаваючою точкою змінні
• fixedТип, який реалізує фіксованою комою

В decimal, floatі fixedтипи повинні ділитися точної такий же публічний інтерфейс (або через успадкування або качиної типізації), що дозволяє їм бути прозоро передається і повертається з функції. Батьківський тип можна назвати real.

7. Дзвінок за значенням та посиланням

Ви повинні мати можливість викликати функції як за значенням, так і за посиланням, при цьому за замовчуванням є значення (тобто, копія аргументу робиться та функціонує в цій функції).

8. Покажчики

Мова повинна мати покажчики та допускати арифметику вказівника. Покажчики можуть бути набрані лише статично (щоб уникнути кошмару, який є void*). vartypeпокажчики явно заборонені. Наявність покажчиків та арифметики покажчиків дозволяє серйозно використовувати мову як мову програмування систем.

9. Вбудована лінія

У зв'язку з 8. Мова повинна містити доступний код мови вбудованої вбудованої мови для тих ситуацій, коли це необхідно.

10. Безпека

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

11. Невизначена поведінка

Мовний стандарт повинен визначати, як програма повинна вести себе за будь-яких обставин, за винятком коду, явно позначеного небезпечним, тобто не повинно бути невизначеної поведінки поза небезпечними блоками. Це дозволяє використовувати мову як життєздатну мову розробки додатків, одночасно дозволяючи сказати, вписати в неї ОС.

Це все, що я можу придумати на даний момент, але я редагую / оновлюю публікацію, як думаю про інші речі.

Ось як виглядала мова мого програмування мрії:

• Потужна система статичного типу з деякою підтримкою залежного набору тексту.
• Необов’язковий динамічний набір тексту.
• Числова вежа a la Lisp, але статично набрана.
• Макрос а ля Лісп.
• Передусім функціональна мова програмування з базовою підтримкою імперативного програмування (як, наприклад, сім'я ML).
• Збір сміття.
• Введіть умовивід.
• Продовження.
• Необов’язкова лінива семантика.
• Усі конструкти керування надавалися б у вигляді бібліотечних функцій. (Це можливо зробити за допомогою двох останніх функцій.)
• Мінімальний синтаксис (не такий як Ліпс, але щось на зразок Іоке / Сеф.)

Я б спроектував це майже як C #, але Microsoft мене обіграв. :)

^{_{(За винятком звичайно, що мій був би менш продуманим і більш любительським.)}}

Я не дуже заперечую, чи він складений чи інтерпретований, тому мені не потрібно виправдовувати цей біт.

Щодо сильного статичного набору тексту, мені важко зрозуміти, чому це навіть вимагає виправдання. Статична типізація - це функція, яка виловлює помилки під час компіляції. Динамічне введення тексту - це відсутність цієї функції і відкладає помилки до часу виконання. В моєму особистому досвіді у мене було небагато випадків використання, коли динамічна відправка мала сенс і була корисною, тому згортання, які мені довелося пройти в C # до 4.0, щоб отримати це, тоді були легко виправдані. З C # 4.0 мені навіть не потрібно цього виправдовувати, тому що зараз ми динамічно відправляємо.

Однак я, мабуть, створив би новий синтаксис, а не дотримуватися такої релігійності, як старий синтаксис C, як C #. Оператор перемикання особливо жахливий, і мені також не подобається синтаксис литого (це неправильний шлях). Я не сильно суєтую з приводу деталей синтаксису, тому мені не потрібно це детально обґрунтовувати, за винятком того, що я б не хотів, щоб це було багатослівним, як Visual Basic.

Що ще ви хотіли б, щоб я виправдовувався?

Ну ось список функцій, які я вклав би:

Слухати як синтаксис

Стиль Лісп

Плюси :

• Синтаксис, що легко розширюється Ви коли-небудь намагалися реалізувати цикл foreach в C? Це не зовсім просто. (Зверніть увагу, я це зробив ).
• Гомоїконічність. Можна просто(eval "your data files")

Мінуси :

• Вкладені польські позначення часто важко читати

Функціональне програмування

Хаскелл стиль

Плюси :

• Легка паралельність, весь код безпечний для потоків.

Мінуси :

• Складно реалізувати побічні ефекти в чистому функціональному коді, хоча монади, здається, добре справляються.

Сильний динамічний набір тексту

Стиль Python

Плюси :

• Динамічне введення тексту дозволяє зробити читним код, сильне введення тексту може усунути помилки типу

Впровадження :

Дозволити перевантаження функцій на основі типів, подібних до CL defgeneric:

(define (+ (a <int>) (b <int>))
  (ints-add a b))

(define (+ (a <string>) (b <string>))
  (string-concat a b))

(define (+ a b)
  (add-generic a b))

Складається та інтерпретується

Плюси :

• Підвищення продуктивності при компіляції (як правило, правда, не завжди)

Мінуси :

• Можна обмежити функції в мові, хоча llvm було б добре підкріплено.

Системи програмування

C стиль

Плюси :

• Звертається до дуже незначного кола користувачів.
• Легше взаємодія програм, драйверів ядра та пристроїв, якщо всі вони написані однією мовою

Мінуси :

• Обмежує абстракції в мові, динамічне введення тексту часто не підходить.

Гігієнічні макроси (стиль стилю CL та схема)

Плюси :

• Легко розширити мову, особливо з синтаксисом Lispy ™
• Я говорив це раніше, чи не так?

Мінуси :

• Не багато, якщо це робиться з синтаксисом Lispy ™

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

Є кілька мов там, які я вважаю досить проклятим хорошим (C # є моїм поточним улюбленим). Оскільки це моя мова фантазії, ось що я дуже хочу, щоб вона мала:

• Офіційна документація api. Java API такий хороший, як і C # /. NET. Ruby / Rails тут дуже жахлива.
• Офіційна загальна документація Kick-Ass (практичні вказівки, загальні можливості використання, багато прикладу коду). C # /. Net для цього добре.
• Велика спільнота документологів на основі блогу та вирішення проблем StackOverflow допомагає мені вийти з важких місць
• Широкий спектр добре підтримуваних, добре задокументованих та потужних плагінів / бібліотек / розширень (у Ruby / Rails є "потужний", але жоден з двох інших).
• Є досить стабільним - не змінює все, щоб зламати більшість існуючих код щорічно (дивлячись на вас, Ruby / Rails).
• Не надто стабільна - здатна адаптуватися до прогресу в мовному дизайні (дивлячись на вас, c ++)

Підказки компілятора

Я розмовляю зі мною, бо я не знаю так багато про дизайн мови, але я думаю, що особливість, про яку я говорю, називається підказками іншими мовами. Може, компілятор підказує ?

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

E: Я вдячний коментарям, що пояснюють, про що я прошу, або наводячи приклади, коли це вже існує.

Спробуйте нові ідеї:

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

// a view pattern (or Active Pattern in F#)
default = \def val: !!val.Type val def

// usage of the pattern
greet = \name<(default "world") `and` hasType Str>:
  p "Hello, \{name}!"

(p "Enter your name", .input).greet // (, ) is a sequence expression, returning the last value

Ось пояснення:

default =встановлює сховище, \def valпочинає функцію curries з двома аргументами, те val.Typeсаме Type[val], що !!перетворює на булеву, і може застосовуватися булева, так valіdef are after it.

f x= f[x]= x.f .f=f[]

і в greet, він використовується, name<(default "world")і hasType Str>це означає, що візерунок default "world"буде використаний і прив'язаний до name. Шаблон за замовчуванням визначає значення за замовчуванням. andце ще один візерунок, який поєднує два візерунки разом. defaultшаблон не може потерпіти невдачу , а hasTypeможе потерпіти невдачу. У цьому випадку це кидає виняток.

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

Хеші та подібні будуть як у Lua та JavaScript.

Якщо я збираюся скласти мову компіляції, я зроблю F # для Java з функціями, схожими на Haskell. Це чиста функціональна мова, за винятком того, що є функція, яка поєднує цитати та Comp Exprs разом для досягнення імперативного програмування шляхом написання блоків, подібних до псевдокоду.

Маючи на увазі, що єдиними мовами, які я знаю, є PHP та javascript, і що я дійсно повинен вивчити ще кілька, перш ніж розробляти мову:

Синтаксис: Ретельно продумайте назви функцій та порядок аргументів (тобто бути менш брудним, ніж PHP).

Особливості: Майте набір stringфункцій, які працюють на змінних у вигляді ряду байтів, але не розуміють текст, і набір textфункцій, які розуміють безліч кодувань і можуть працювати на UTF-8 та інших багатобайтових рядках. (І вбудуйте в мову перевірки правильності кодування, з такою функцією, text.isValidEncoding(text, encoding)яка підкаже вам, чи є послідовність байтів неправильно сформована і небезпечна для того, щоб вважати її текстом.

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

Перш ніж розробляти мову програмування, я знайшов би гарну відповідь на питання: навіщо нам потрібна ще одна мова програмування? Код Розетти на момент написання цього переліку перераховує 344 мови. Якщо жоден із них не відповідав моїм потребам, то особливості того, чому вони не зробили б, визначили початкову точку (мови, що наближаються до найближчих) і що було б додано до неї.

Якби я виграв в лотерею і чомусь не мав нічого кращого зробити, я би почав з Ліскелла і зробив би його повноцінною мовою на відміну від фронтального GHC, а потім зробити FFI простішим (і автоматизованим), щоб я міг використовувати будь-яку C / C ++ бібліотека.

Гарною мовою є мова, яка є:

• легко міркувати про (відсутність незрозумілого синтаксису)
• дозволяють висловлювати свої ідеї з мінімальними спотвореннями
• приховати від вас деталі з ситкою зернистістю (оптимізація / управління ресурсами)
• легко паралелізувати (кілька ядер, розподілені обчислення)

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

• C-взаємозв’язок : C - мова мов програмування, і кількість розроблених в C бібліотек дивовижна. Маючи простий інтерфейс (наприклад, Python) до C, мова автоматично отримує перевагу від усіх цих бібліотек, а також дозволяє надсилати важкі завдання, які не могли бути достатньо оптимізовані до близької до металевої мови.
• Поширений : Мені подобається взяти Go на багатопотокових, з легкими процедурами, які тривалість виконання посилається на потоки залежно від їх активності. Така мова спонукає програміста розмірковувати про завдання та ізолювати їх одне від одного.
• Збір сміття : само собою зрозуміло;)
• Незмінне : набагато простіше міркувати про щось, що ніколи не може мутувати, набагато простіше реалізувати багатопотокові / розподілені обчислення теж (для синхронізації потрібна лише робота з життям, що є завданням компілятора)
• Лямбда : йдеться про функції першого класу, я думаю
• Передача повідомлення : незмінність означає відсутність мютексу, тому ми дотримуємося пропозиції Тоні Хоареса
• Модулі : дещо схожі з просторами імен, але з кращою інкапсуляцією
• Рефлексія : розподілене обчислення вимагає серіалізації, яку слід залишити компілятору, а десеріалізація легше досягається за допомогою певної форми рефлексії.
• Статичний сильний набір тексту : чим раніше виявлена ​​помилка, тим менше коштує

Наразі мова, наближена до цього списку, мабуть, є Haskell, хоча:

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

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

По-перше, я б спробував придумати підхід OOP, який дозволяє створювати справді пов’язані моделі. Що я маю на увазі під тим, що моделі є однією з найважливіших речей майже в будь-якому проекті програмування - це завжди багато бурхливої ​​роботи та безперервного рефакторингу, щоб виправити це правильно, і я звинувачую це у відсутності реального підключення в Мови ОО.

Дозвольте мені продемонструвати. Скажімо, клас класу має власність Двері.

var door = house.Door;

Тепер у вас є локальна змінна із посиланням на екземпляр Door.

Але врахуйте, що щойно сталося: Ви просто зірвали Двері з будинку, і тепер ви цілком задоволені тим, що пропускаєте Двері навколо, а решта вашого коду не знає про те, що ця Двері насправді прикріплена до Будинку.

Для мене це принципово неправильно.

І так, я знаю, це "легко" фіксується в кожному конкретному випадку - у цьому випадку, підтримуючи зворотний посилання від кожної Двері до будинку, до якого вона зараз приєднана. Це, звичайно, відкриває вашу модель помилкам, оскільки тепер ваш обов'язок точно підтримувати дві зворотні посилання, тому ви робите приватні властивості House.Doors та Door.House, і ви додаєте такі методи, як House.AddDoor (), House.RemoveDoor ( ), Door.SetHouse () та ін.

Хіба це не здається великою роботою для моделювання таких прямолінійних відносин? Багато коду для підтримки? Чимало коду на рефактор, коли модель розвивається?

Проблема - покажчики. Кожна мова, яку я бачив, по суті, страждає від того, що посилання на об'єкт - це дійсно вказівник, адже саме цим користуються комп'ютери.

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

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

Я поняття не маю, як виглядатиме синтаксис для такої мови, чи можна це навіть виразити за допомогою тексту. (Мені було цікаво, чи така мова повинна якось бути графічною ...)

Я також хотів би, щоб усі форми випадкового стану були ліквідовані.

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

Це починає звучати зайвим? У який момент за все це безумство ми справді зробили щось корисне? І під корисним я маю на увазі щось відчутне - те, що кінцевий користувач може зрозуміти і хвилювати. Зрештою, години, які ви витратили насправді, будуючи щось, що користувачі навіть можуть зрозуміти, - це справді єдино витрачені години. Все інше - це побічні ефекти.

Я хотів би дуже динамічної мови. Цикл запису / компілювання / запуску - втомлива трата часу. В ідеалі мова повинна просто з'ясувати, що змінилося, і компілювати / завантажувати прозоро, на задньому плані, за потребою.

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

Знову ж таки, я навіть не знаю, чи можна це зробити за допомогою традиційного IDE або якщо для цього потрібен абсолютно новий вид інтерфейсу.

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

Держава в цілому має бути чимось, яким ви повністю керуєте мовою. Чому потрібно наполегливо покладатися на базу даних? В ідеалі я хотів би мати можливість просто вказати термін життя будь-якої змінної в моделі: один веб-запит, один сеанс, 24 години, постійно.

Чому нам доводиться вибирати цілий масив рішень для зберігання даних для різних медіа та термінів життя? - не кажучи вже про перетворення та формування даних для відповідності кожному медіа; кеш браузера, база даних, пам’ять, диск, хто піклується! Дані - це дані. Там, де ви зберігаєте свої дані (і на який термін), має бути простий вибір, а не битва проти богів!

Ну, удачі в цьому.

Це, мабуть, буде багатомовна парадигма, яка підтримує наступне:

• Структурне / процедурне програмування
• Об'єктно-орієнтоване програмування
• Функціональне програмування

Чому саме ці? Об'єктно-орієнтована, тому що це чудовий спосіб організації великих програм, особливо для організації даних. Структурована тому, що ви не завжди хочете / потребуєте цього (ООП), люди повинні мати вибір. Функціональна, тому що програмістам легко налагоджувати, і це робить програми більш зрозумілими.

Я б використав модель Python з відступними блоками для позначення кодових блоків. Це дуже чітко і приємно читати.

Я б вкрав дуже багато ідей у ​​Python насправді, тому що Python - це дуже приємна мова. Я б взяв це за твердження і скопіював би його карти, список і кортежі.

Зараз, я б, мабуть, не брав би динамічні концепції від Python: для одного, це, мабуть, було б експліцитно та статично набрано. Я думаю, що програми стають більш зрозумілими з цим. Змінні, ймовірно, були б об'єктами з методами, тоді ви могли б зробити щось на кшталт str.length()отримання довжини рядка. У визначеннях функцій вам доведеться вказати тип повернення та типи аргументів (підтримуючи також якісь загальні типи).

Повернемося до копіювання з Python ;-). Мені подобається, що це необов'язкові аргументи процедури, тому я, мабуть, мав би це. Однак Python не підтримує процедуру перевантаження, я б хотів цього.

Давайте подивимось на класи, я б відкинув багаторазове успадкування; легко зловживати. Я би реалізував приватні та подібні сфери, і, мабуть, реалізував би так, як це робиться в C ++. У мене також були б абстрактні класи та інтерфейси; Я не вірю, що Python має це.

Це підтримувало б внутрішні класи, насправді я хотів би дуже потужної об'єктно-орієнтованої мови.

Це, мабуть, було б інтерпретовано. Це можливо отримати дуже швидко, використовуючи хорошу компіляцію JIT (я хотів би швидкої мови, хоча продуктивність програміста вийшла б на перше місце), а компіляція просто погана на продуктивність у багато разів. Інтерпретовані мови також сприяють незалежності платформи - щось важливе для кожного дня.

Він би вбудував підтримку Unicode; в наші дні інтернаціоналізація має велике значення.

Це точно було б зібране сміття. Чорт я ненавиджу займатися управлінням пам’яттю сам; також не добре для продуктивності.

Нарешті, це мала б хорошу стандартну бібліотеку.

Вау, щойно зрозумів, наскільки я справді люблю Python.

Перш за все, я придбав би кілька книг про компілятори, кілька стандартів, і взяв би курс чи дві мови та компілятори. Я б вніс свій внесок у PEP та відвідав засідання комітетів зі стандартів C ++. Я б додав патчі до компіляторів, які використовую, сподіваюся, як для функцій, так і помилок.

Тоді я б повернувся назад і з жахом подивився на цей список, який я придумав зараз, який із напрямків я б пішов з мовою, якби я почав зараз:

• Функціональна , тому що в даний час я не добре розбираюся в жодних функціональних мовах, і зробити це було б чудовим способом її вивчення. Якщо це не випливає безпосередньо: все постійно .
• Я наповнив би її стільки ж виводу типу, скільки можу вмістити в неї, але з можливістю чітко вказати інтерфейси. Не впевнений у інших типах. Це збільшується вдвічі, оскільки всі функції за замовчуванням є загальними .
• Як ви вже здогадалися, з інтерфейсами ; тобто з типами, які дають лише обіцянки щодо доступних операцій.
• Наскільки я можу сказати, сильно чи слабко введена мова, в цьому випадку не має великого значення. Я б назвав це сильно набраним, оскільки речі ніколи не змінюють інтерфейси, які вони реалізують .
• Було б багато дизайн за контрактом . Знову-таки, наскільки я вміщу: передумови та пост-умови є обов'язковими; Я не знаю, наскільки важливі інваріанти, коли мова йде про функціональне програмування.
• Поки я перебуваю на цьому, я погляну на мови, на яких можна офіційно довести правильність, і побачити, чи я можу взяти звідти щось.
• Я б вийшов і написати дивовижну бібліотеку для тестування . Навіть у випадку, якщо я не зможу зробити це приголомшливим, я, принаймні, витрачу на нього значну кількість часу, працюючи над цим, оскільки я думаю, що це має бути кожна мова.
• Що стосується синтаксису, то мова буде або мати значні прогалини і дуже схожий на Python , або він буде заснований на ложбане і обмін багато граматики та лексики. У першому випадку я би зробив все можливе, щоб зробити граматику максимально близькою до CFG.
• Мені було б байдуже, чи зможуть люди, які реалізовували цю мову, заздалегідь її склали, JIT, інтерпретувати її, скандувати її на багаттях чи платити дітям коледжу за їх виконання. Моя власна реалізація, ймовірно, почалася б як перекладач або компілятор С, і врешті рухалася до JITter.

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

Якби у мене був час, я створив би локалізовану мову програмування, засновану на Scala, тому вона мала б більшість її можливостей, за винятком, напевно, XML. Моя мета - зробити мову, яка майже природно читається мовами з іншою структурою, ніж англійська, наприклад, арабська (моя рідна мова). Я маю на увазі такі особливості:

• #langДиректива перед процесором , яка використовується для інформування попереднього процесора про людську мову, що використовується для програмування. Наприклад: #lang arдозволив би використовувати слово فئةзамість class, عرفзамість defтощо. Ключові слова, характерні для людської мови, визначалися б у стандартних файлах препроцесора.
• Попередній процесор видалить кілька необов'язкових ключових слів, єдиною метою яких є додавання ясності коду. Наприклад, він видалить "складається з" в, class MyClass is composed of {щоб стати class MyClass {, і видалив "як" в, def MyMethod(x: Int) as {щоб стати def MyMethod(x: Int) {. У деяких (людських) мовах це полегшить розуміння коду, особливо для студентів.
• Компілятор дозволив би використовувати позначення префікса для доступу до властивостей. Це може не мати сенсу для більшості носіїв мови на основі латинської мови, але для деяких інших мов це має ідеальний сенс. Наприклад, доступ до властивостей арабською мовою зазвичай є префіксом, як у اعرض طول اسم محمد, що еквівалентно print(length(name(Mohammad)))англійській мові програмування. (Дужки є для ясності.)

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