Мова, заснована на обмеженні кількості аргументів, переданих функціям

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

а) чи призвела б така мова до легшого розуміння коду?

б) чи чіткіше буде потік коду? (змушений робити більше кроків, потенційно менше взаємодій "приховано"

в) чи зробили б обмеження мову незмінно об'ємною для складніших програм.

г) (бонус) будь-які інші коментарі щодо плюсів та мінусів

Примітка:

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

Роберт К. Мартін у своїй книзі "Чистий код" рекомендує наполегливо використовувати функції з максимум 0, 1 або 2 параметрами, тому принаймні є один досвідчений автор книги, який вважає, що код стає чистішим за допомогою цього стилю (проте він напевно, тут не найвищий авторитет, і його думки є дискусійними).

Там, де Боб Мартін правильний IMHO, це: функції з 3 і більше параметрами часто є індикаторами кодового запаху. У багатьох випадках параметри можуть бути згруповані разом для формування комбінованого типу даних, в інших випадках це може бути індикатором для функції, яка робить занадто багато.

Однак я не думаю, що було б гарною ідеєю вигадувати нову мову для цього:

• якщо ви дійсно хочете застосувати таке правило протягом усього коду, вам просто потрібен інструмент аналізу коду для існуючої мови, не потрібно для цього вигадувати абсолютно нову мову (наприклад, для C # щось, на зразок 'fxcop', можливо, може бути використане ).

• інколи поєднання параметрів з новим типом просто не здається клопоту, інакше це стане чисто штучним поєднанням. Дивіться, наприклад, цей File.Openметод із .Net Framework. Це потребує чотирьох параметрів, і я впевнений, що дизайнери цього API зробили це навмисно, тому що вони думали, що це буде найбільш практичним способом надання різних параметрів функції.

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

Є багато мов, які вже працюють таким чином, наприклад Haskell. У Haskell кожна функція бере рівно один аргумент і повертає рівно одне значення.

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

Це називається Frege-Schönfinkeling, Schönfinkeling, Schönfinkel-Currying, або Currying, після Хаскелла Керрі, який широко його досліджував у 50-х роках, Мойсея Шенфінкеля, який описав це в 1924 році, і Готлоба Фреге, який передбачив це в 1893 році.

Іншими словами, обмеження кількості аргументів має саме нульовий вплив.

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

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

Мова, заснована на тому, як вона стримує розробника, залежить від припущення, що розробник мови розуміє потреби кожного програміста краще, ніж програміст розуміє ці потреби. Бувають випадки, коли це фактично справедливо. Наприклад, обмеження в багатопотоковому програмуванні, що вимагає синхронізації за допомогою мютексів і семафорів, вважаються багатьма "хорошими", оскільки більшість програмістів абсолютно не знають про основні складні для машини складності, які ці обмеження приховують від них. Крім того, мало хто хоче повністю зрозуміти нюанси багатопотокового алгоритму збору сміття; мова, яка просто не дозволяє зламати алгоритм GC, є кращою перед тією, яка змушує програміста усвідомлювати занадто багато нюансів.

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

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

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

Вам знадобляться дві речі:

• Закриття
• Складений тип даних

Я додам математичний приклад, щоб пояснити відповідь, написану Йоргом У Міттагом .

Розглянемо функцію Гаусса .

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

На першому кроці ми створимо функцію Гаусса, яка приймає всі три параметри, а саме середню, дисперсію та вільну змінну.

На другому кроці ми створюємо складений тип даних, який поєднує середнє значення та дисперсію в одне.

На третьому кроці ми створюємо параметризацію функції Гаусса, створюючи закриття функції Гаусса, прив'язаної до складеного типу даних, який ми створили на другому кроці.

Нарешті, ми оцінюємо закриття, створене на третьому кроці, передаючи йому значення вільної змінної x.

Отже, структура:

• Оцінити (обчислення)
  • Параметризований гаусський (закриття: формула, плюс деякі зв'язані змінні)
    • GaussianParameters (складений тип даних)
      • Середнє значення)
      • Варіантність (значення)
  • X (значення вільної змінної)

1. Практично на будь-якій мові програмування ви можете передавати певний тип списку, масиву, коррекції, запису чи об’єкта як єдиний аргумент. Єдина мета - утримувати інші предмети, а не передавати їх функції окремо. Деякі Java IDE навіть мають функцію " Extract Parameter Object ", щоб зробити саме це. Внутрішньо Java реалізує змінну кількість аргументів, створюючи та передаючи масив.

2. Якщо ви дійсно хочете робити те, про що ви говорите, в найчистішому вигляді, вам потрібно розглянути читання лямбда. Це саме те, що ви описуєте. Ви можете шукати в Інтернеті, але опис, який мав сенс для мене, був у видах "Мови програмування" .

3. Подивіться на мови програмування Haskell та ML (ML простіше). Вони обидва базуються на лямбдальному обчисленні і концептуально мають лише один параметр на функцію (якщо трохи примружити).

4. Пункт 2 Джоша Блоха: "Подумайте про будівельника, стикаючись з багатьма параметрами конструктора." Ви можете бачити, наскільки це багатослівне , але радіти працювати з API, написаним таким чином.

5. Деякі мови назвали параметри, що є ще одним підходом до того, щоб зробити підписи величезних методів набагато простішими в навігації. Наприклад, Котлін назвав аргументи .