Существуют ли языки сверхвысокого уровня? [закрыто]

Исторически HLL - это что-то вроде C, Fortran или Pascal, а VHLL - это как Ruby или Python. Я знаком с терминами 4GL, 5GL, DSL и LOP, и те, кто не должен, должны прочитать Википедию для определений. Я ищу UHLL.

У меня вопрос: есть ли какие-нибудь компьютерные языки, которые на порядок более продуктивны, и кто-нибудь над ними работает?

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

Основной областью, которая меня интересует, являются бизнес-приложения общего назначения и потребительские приложения с интерфейсом GUI или браузера, сохранением данных и подключениями к другим системам, таким как печать и электронная почта. Другие люди вполне могут сосредоточиться в другом месте.

Я признаю, что некоторые из этих языков могут быть специфичными для домена, и что они могут быть немного больше, чем возможности конфигурации большого и функционального приложения. Электронные таблицы Excel попадают в эту категорию.

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

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

• Рисунок формы GUI - это программа для формы GUI
• Таблица, содержащая строки, столбцы и заголовки, является программой для таблицы в базе данных.
• Декларативная логика говорит, что и когда должно быть сделано, без утверждений IF
• Операции над наборами данных без циклов FOR
• Непоследовательное выполнение, например, управление данными, сопоставление с образцом, обход дерева

Мотивация этого вопроса заключается в том, что мне все больше надоела огромная тяжелая работа по переводу относительно простых бизнес-требований в большие объемы кода для удовлетворения потребностей компьютера. Вопрос в том, чтобы найти других людей, которые разделяют мою боль и работают над повышением уровня языков и заставляют компьютер выполнять большую часть тяжелой работы. Это было основным направлением в 1970-х-80-х годах, но все еще происходит?

Вот некоторые предлагаемые ответы на мой вопрос, приведенные здесь для краткого изложения или перечисления языков, о которых я знаю, и которые, на мой взгляд, не соответствуют.

Есть много языков, которые являются HLL или VHLL и содержат отдельные функции, которые относятся к более высокому уровню. Я использовал большинство из них (часто плохо). Они включают

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

Эти языки имеют слишком много низкоуровневых функций, чтобы быть UHLL. Программист все еще должен написать много конструкций низкого уровня для любой полезной программы.

Есть пакеты RAD / 4GL. Я использовал некоторые:

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

И многое другое я не использовал. В большинстве случаев язык - это HLL, но пакет содержит структуру и привилегированные соединения между языком и пакетом, что позволяет быстро создавать приложения. Я не уверен, почему такой подход выдохся, но в любом случае это не так.

Есть сырые фреймворки / библиотеки. Я использовал несколько:

• Рельсы
• Ява трепетно
• .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 работает на Лиспе, и Пол Грэм управлял целым бизнесом, используя Лисп, утверждая, что это дало ему значительное преимущество перед его конкурентами (которые все использовали Java).

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

И все еще остается вопрос о том, чтобы критическая масса разработчиков разбиралась в этом языке. Несмотря на все свои недостатки, у вас никогда не будет проблем с поиском Java-программиста.

Обратите внимание, что основные языки все еще развиваются. Linq был создан с конкретной целью сделать программирование на основе данных более декларативным. Несколько новых функций были добавлены в язык C #, чтобы заставить Linq работать; все они связаны с повышением производительности труда разработчиков.

Дальнейшее чтение,
опережающее средние

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

Лучший пример этого специфического явления, о котором я знаю, и который, возможно, представляет здесь большой потенциальный интерес, - это Unified Modeling Language . Действительно, существуют специальные стеки приложений, разработанные специально для того, чтобы делать то, что вы просите. Он отвечает многим вашим требованиям, но не обязательно так, как вы думаете. Тем не менее, это чрезвычайно познавательно для этой ситуации, поскольку я чувствовал то же самое, и мой опыт (который следует) изменил способ, которым я думаю об этой проблеме.

Я лично здесь буду говорить о IBM Rational Software Architect , которая является попыткой действительно разрешить разработку на сверхвысоком уровне. Цель состоит в том, чтобы вы могли создать философскую бизнес-концепцию в виде объекта, такого как Actor или Class, дать атрибуты сущностей, определить соединения, определить, как информация может проходить через систему во время ее работы, и сделать это все с графическим интерфейсом.

Например, вы можете перетащить объект DataStore, Actor, форму, несколько релевантных классов (например, Customer и т. Д.), Нарисовать некоторые линии соединения между объектами, используя графики и т. Д., И всплыть: когда вы закончите, вы опубликуете работающую программу. (это, очевидно, чрезвычайно упрощено)

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

Это все, что вы хотите, и даже больше, и вы ничего не сдаете в обмене! Правильно?

Почему не все это используют?!?!

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

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

И суть в том, что даже тогда, когда миллионы за миллионами вливаются в проект от десятков компаний и за некоторыми очень громкими именами, вы все равно в конечном итоге получаете код в стиле C на исполняемом слое, который нужно редактировать время от времени. потому что некоторые вещи просто не делают перевод между объектно-ориентированными описаниями классов и UML до уровня программирования / машинного уровня, и автоматизация не может быть полностью завершена.

По моему опыту, это был невероятно сложный способ создания лесов. Это, наверное, самая жестокая вещь, которую я когда-либо скажу о таком огромном технологическом начинании, но это то, что я получил от этого.

От людей из промышленности, с которыми я разговаривал, они, к сожалению, сказали то же самое. По их мнению, они проделали большую работу по созданию документации, бесчисленных диаграмм, моделей, собраний, анализов за месяцы и месяцы, а затем выбросили все это, и команда разработчиков просто написала для него код и часто просто воспринимала его как Еще одна спецификация Binder (которую никто больше не читает). Так что теперь они просто используют Java и какое-то специальное программное обеспечение для создания диаграмм / визуализации, а также Agile, и это конец этой истории.

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

Но, возможно, виноваты все программисты, они просто отказываются признать, что система работает так хорошо, и все же это совсем не похоже на компьютерное программирование. Может быть, программисты, работающие с чистым кодом, просто сопротивляются замене своей работы, подобно создателям свечей и ткачам прошлого, и поэтому отказываются просто выполнять свою ограниченную задачу «Реализация спецификации», и это заставляет всех остальных так расстраиваться, что их выбрасывают и говорят плохие вещи, и это было почти идеально.

Но ... я думаю, в этом может быть какая-то правда, но я думаю, что в основном это не очень хорошо работает. Я думаю, что это превращает что-то, что на самом деле не так сложно большую часть времени (компьютерное программирование), и делает его еще более трудным до такой степени, что, если это сработает, это будет здорово, но, черт возьми, у вас есть долгое время, когда нечего показать, чтобы туда попасть!

Может быть, это будет работать только на предприятии с более чем тысячами человек, а может быть, мы просто еще не там.

Понятия не имею.

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

Или, может быть, мы просто должны дать ему еще 20-50 лет тяжелой работы. Я больше не оптимистичен, что язык программирования является ограничением, больше.

И если раньше языки программирования были ограничением, именно поэтому улучшения дали нам потенциальный порядок улучшения. Если они больше не являются таким ограничением, то любое новшество с большей вероятностью не сможет обеспечить такой порядок улучшений. Но я не могу сказать будущее! Поэтому я предполагаю, что все остальное не "в работе", но, конечно, "слишком рано, чтобы сказать".

Если вы подумаете об этом некоторое время, программирование более высокого уровня в основном способно составлять меньшие части, которые легко доступны и проверены. Вплоть до того момента, когда ваша программа очень просто склеивает код из различных библиотек. Может быть, клей очень выразительный DSL. Вы можете сделать это примерно на каждом языке программирования.

Лично я все больше и больше начинаю ощущать, что решение для возможности компоновки - вопреки тому, что вы можете инстинктивно чувствовать - не найдено в объектно-ориентированном программировании. Эта парадигма, так же как и императивное программирование, предоставляет слишком большую свободу программистам, что, в свою очередь, делает слишком трудным написание кода, который легко использовать повторно.

Скорее, я думаю, что функциональное программирование предоставляет примитивы, которые гораздо лучше подходят для компоновки. Чистые функциональные языки программирования также не позволяют вам определять функции, которые имеют побочные эффекты, что не только уменьшает количество ошибок или облегчает их обнаружение, но также облегчает их использование (объединяет их в большую систему).

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

Я ожидаю, что Lua, используемый игрой для сценариев своих квестов и интерфейсов, будет соответствовать этому критерию. Существуют также похожие языки, специфичные для предметной области (и утилиты для построения карт), которые позволяют дизайнерам уровней быстро и легко сказать «когда игрок разговаривает с Бобом, начните Epic Quest Боба».

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

Ни один из них не является многообещающим в плане увеличения производительности на порядок и выше для рядового разработчика.

Я думаю, что REBOL может соответствовать всем вашим критериям. Вы можете создавать относительно сложные приложения с графическим интерфейсом в несколько строк кода, однако его «специальностью» является создание DSL.