Чи є там мови надвисокого рівня? [зачинено]

Історично HLL - це щось на зразок C, Fortran або Pascal, а VHLL - це щось на кшталт Ruby або Python. Мені добре знайомі терміни 4GL, 5GL, DSL та LOP, а ті, хто ні, не повинні читати Вікіпедію для визначення. Я шукаю УГЛЛ.

Моє запитання: чи є якісь комп'ютерні мови там, які ще на порядок більш продуктивні, і хтось працює над ними?

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

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

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

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

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

• Креслення форми GUI IS програма для форми GUI
• Таблиця, що містить рядки, стовпці та заголовки, є програмою для таблиці в базі даних
• Декларативна логіка говорить про те, що слід робити і коли, без тверджень про ІФ
• Операції з наборами даних, без циклів FOR
• Непослідовне виконання, наприклад, керовані даними, узгодження шаблонів, ходьба по дереву

Мотивація запитання полягає в тому, що я все більше втомився від великої наполегливої ​​роботи над переведенням відносно простих бізнес-вимог у великі кількості коду, щоб задовольнити те, що комп'ютер хоче чи потребує. Питання справді в тому, щоб знайти інших людей, які поділяють мій біль і працюють над тим, щоб підвищити рівень мов і змусити комп’ютер зробити більше важкої роботи. Це було головним напрямком у 1970–80-х роках, але чи все ще відбувається?

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

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

• Лісп, макроси та здатність до самовиправлення
• Haskell, із залежністю даних та узгодженням шаблону
• SQL, який займається рядками та таблицями
• Rebol, який здається розумним, але я не дуже розумію
• APL (і J) з його багатовимірними масивами та над компактними операторами
• C # з LINQ
• AWK / Perl / Python / Ruby з чудовими колекціями та вбудованими регулярними виразками

Ці мови мають занадто багато функцій низького рівня, щоб бути UHLL. Програмісту ще належить написати багато конструкцій низького рівня для будь-якої корисної програми.

Є пакети RAD / 4GL. Я використовував деякі:

• dBase / Foxpro
• Dataflex / Powerflex (мій продукт)
• Доступ
• PowerBuilder

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

Є необроблені рамки / бібліотеки. Я використав декілька:

• Рейки
• Java awt і гойдалки
• .NET Windows Forms, WPF і ASP.NET.

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

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

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

Пізно редагування: Я думаю, що у мене є відповідь: Wolfram Language. http://www.wolfram.com/wolfram-language/

Майже всі перелічені вами критерії - це речі, які вже були випробувані в інструментах 4GL / RAD, таких як MS Access, Sybase Power Builder, Oracle Forms, Ruby-on-Rails (як більш сучасний зразок для веб-додатків) та багатьох інших (див. Вікіпедію для дуже довгий список постачальників). І справді, переведення відносно простих бізнес-вимог у якусь програму можна дуже швидко досягти за допомогою цих інструментів. Ось чому більшість постачальників інструментів RAD рекламують свою продукцію таким чином, що всі повинні думати, що вони вже винайшли UHLL у вашому розумінні.

Улов полягає в тому, що як тільки ви залишите основу вимог " відносно простими ", і як тільки вам доведеться підтримувати та розвивати програми, написані в цих середовищах, ви помітите, що ви легко досягаєте меж і помічаєте їх недоліки або що реалізовувати вимоги до них нічим не простіше, ніж з будь-яким іншим "VHLL", який ви маєте на увазі. ІМХО є хороший шанс, що вони вб'ють будь-яке підвищення ефективності, яке ви мали у версії 1.0, переходячи до версій 1.1, 1.2 та 1.3 вашої програми.

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

Мова програмування найвищого рівня, яку я знаю - APL . Для цього потрібна спеціальна клавіатура для представлення всіх необхідних символів. Перегляньте це відео , в якому автор пише про повну реалізацію гри Життя Конвея приблизно за сім хвилин.

Справжнє питання, звичайно, "чи це практично?" Чи можу я знайти достатньо програмістів APL у світі, щоб підтримувати бізнес таким чином? Чи буде APL працювати на телефонах і планшетах? Чи мені справді потрібно купувати всім моїм розробникам програмного забезпечення нові клавіатури?

Якщо ви дійсно хочете підвищити продуктивність, найкраща ставка - це, мабуть, якийсь варіант Lisp. Clojure працює на JVM і має порт .NET. Я говорю це тому, що люди це вже зробили; пошукова система Orbitz працює на Lisp, і Пол Грехем керував цілим бізнесом, використовуючи Lisp, стверджуючи, що це дало йому значну перевагу перед конкурентами (які всі використовували Java).

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

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

Зауважте, що основні мови все ще розвиваються. Linq був створений для конкретної мети зробити програмування, кероване даними, більш декларативним. До мови C # було додано кілька нових функцій, щоб змусити роботу Linq; всі вони мають відношення до підвищення продуктивності розробника.

Подальше читання
Збивання середніх

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

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

Я особисто буду говорити про архітектуру раціонального програмного забезпечення IBM , яка є спробою реально дозволити розробку Ultra High Level. Мета полягає в тому, щоб ви могли створити філософську концепцію бізнесу як об'єкт, наприклад, Актор чи Клас, надати атрибутам сутності, визначити з'єднання, визначити, як інформація може протікати через систему під час роботи над цим, і зробити це все з графічним інтерфейсом.

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

Дійсно, що було зроблено, це формування складного графічного інтерфейсу, дуже ретельна реалізація / інтерпретація UML, а потім він компілює в код Java / C # / VB з повними документами XML, що містять графічну інформацію про UML, і вони також реалізують / включають Інженерія в зворотному напрямку, щоб ви могли переходити вперед і назад між моделлю та кодом, щоб ви могли керувати речами як на дуже високому філософському рівні з носовим кровотечею, так і на дуже низькому рівні, що стосується платформи.

Це все, що ви хочете, і більше, і ви нічого не відмовляєте в обміні! Правильно?

Чому його не використовують усі?!?!

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

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

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

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

З людей у ​​галузі, з якими я спілкувався, вони сумно сказали те саме. Їх почуття полягало в тому, що вони робили багато роботи над створенням документації, незліченною кількістю діаграм, моделей, зустрічей, аналізу протягом місяців і місяців, а потім вони все це викинули, а команда розробників просто написала код і часто просто ставилася до нього як до цього Ще одне палітурне завдання (що ніхто більше не читає). Тож тепер вони просто використовують Java та деякі програми для діагностування / візуалізації спеціального призначення та Agile, і ось кінець цієї історії.

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

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

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

Можливо, це працювало б лише на підприємстві з тисячами команд + чоловік, а може бути, ми просто ще не там.

Я не знаю.

Однак дослідження того, що правильно, а що неправильно, при такому підході до мов ультрависокого рівня - і я думаю, що такий тип UML повинен бути включений у такий розгляд - дійсно повинен враховувати такі речі, як Rational Software Architect, щоб уникнути потенційні дурні доручення.

А може, ми просто мусимо дати йому ще 20-50 років наполегливої ​​праці. Я вже не оптиміст, що мова програмування - це обмеження.

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

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

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

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

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

Я б очікував, що Lua, використовуваний грою для скриптування своїх квестів та інтерфейсів, відповідатиме цим критеріям. Існують також схожі мови домену (і утиліти для створення карт), які дозволяють дизайнерам рівнів швидко і легко сказати: «Коли гравець розмовляє з Боб, запускайте Епічний квест Боба».

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

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

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