Насколько высоко должны / будут идти языки высокого уровня?

Question

Я знаю, что это очень абстрактно, однако я считаю, что это очень сфокусировано.

Сегодня существует множество языков высокого уровня: C # , Java , VB , Python и т. Д., Все создано абстрагироваться от сложностей низкого уровня и обеспечить более удобный для пользователя опыт программирования. Языки высокого уровня могут уменьшить и в большинстве случаев полностью устранить необходимость выполнения низкоуровневых операций, специфичных для процессов (таких как манипулирование указателями и управление памятью). Многие также удаляют сведения о платформе (например, манипулирование файлами, создание пользовательского интерфейса и т. Д.)

Мои два вопроса:

1. Что еще можно / нужно абстрагировать? Существуют ли еще какие-либо семантики низкого уровня, присутствующие в современных языках высокого уровня, которые будут / должны быть абстрагированы дальше?
2. В какой момент язык общего назначения общего назначения становится очень высоким уровнем , a.k.a ориентированным на цель ?

Answer 1

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

Например, Java не настолько высокУровень языка, но он разработан, чтобы быть безопасным (в том смысле, что абстракции не просачиваются) в первую очередь.Поэтому некоторые вещи просто невозможно сделать в Java.Например, вы не можете написать сборщик мусора Java в Java, или свернуть свою собственную объектную систему, используя полиморфизм приведения указателя, или написать операционную систему (по крайней мере, не традиционную).

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

Answer 2

1. Что еще можно / нужно отобрать? Это всегда зависит от вашей цели. Здесь нет четкой линии, но я думаю, что все сводится к тому, какой контроль вам нужен? Обычно между абстракцией и возможностями существует довольно тяжелый компромисс.
2. Когда универсальный язык высокого уровня становится ориентированным на достижение цели? Как только вы сможете сказать языку / среде программирования, что вы хотите вместо того, что она должна делать.

В действительности, хотя ... линия, конечно, совершенно произвольна.

Answer 3

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

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

Например:

int32 Remainder(int32 numerator, int32 denominator) {
    requires denominator != 0
    ensures Math.Abs(result) < Math.Abs(denominator)
    ensures exists n suchthat n*denominator + result == numerator
}
int32 EuclideanRemainder(int32 numerator, int32 denominator) {
    requires denominator != 0
    ensures result >= 0
    ensures result < Math.Abs(denominator)
    ensures exists n suchthat n*denominator + result == numerator
}

приводит к:

//warning: suggested precondition: denominator != int32.MinValue due to Math.Abs
int32 Remainder(int32 numerator, int32 denominator) {
    return numerator % denominator;
}
int32 EuclideanRemainder(int32 numerator, int32 denominator) {
    return ((numerator % denominator) + denominator) % denominator;
}

Answer 4

Определенные доменные языки могут быть чрезвычайно «высокого уровня».Хорошим примером этого является Inform (используется для написания текстовых приключений), где язык программирования мало чем отличается от простого английского.Вот выдержка из примера проекта :

The fireplace is scenery in the Entrance Hall. The description is "Unlit, vacant
[if Search is happening]. It is almost as though you are not expected[end if]."
The sound of the fireplace is "whistling wind". Understand "fire" or "whistling" 
or "wind" as the fireplace. Instead of burning the fireplace: say "There is no 
fuel prepared for a fire."

Это фактический исходный код.:)

Answer 5

Tcl имеет официальное предложение ( Tcl Improvement Proposal (TIP) 131 ), которое в значительной степени решает проблему навсегда. Все, что ему нужно, - это доброволец для выполнения работы. Есть даже скелетная реализация с помощью всего лишь некоторые детали опущены.

Answer 6

Хм, я думаю, что некоторые языки пытаются возглавить некоторые дополнительные абстракции: Clojure с его STM и Erlang с моделью Actor.

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

Answer 7

• В настоящее время некоторые «языки» предназначены для UAT (что близко к тому, что можно назвать целью, а для цели требуются тесты , потому что это единственный способ, которым это можно объяснить Например, Подходит для тестовой части); они могут быть объединены с языками программирования.
• Практически каждый язык получает все больше и больше интерфейсов высокого уровня (т. Е. абстракция ), требующих от вас все меньше и меньше кода и абстрагирующихся от ОС (посмотрите, как легко теперь необходимо создать приложение с графическим интерфейсом в C #, по сравнению с C ++ MFC, по сравнению с C ++ Win32 API).
• Что касается языков программирования, они могли бы получить больше лучших возможностей других методов разработки: я имею в виду Аспектно-ориентированное программирование , которое могло бы помочь решить многие проблемы ОО и уже частично реализовано в некоторых формы в C # и Java (например, вопросы, касающиеся ведения журналов, транзакций ...).
• UML конечная цель ( была? ), чтобы позволить UML viesw вместе с деталями диаграмм быть достаточными для кодирования системы; UML также является языком (в более широком смысле).
• IDE также должны быть включены: теперь вы можете установить, как диалоговое окно должно изменяться из IDE, в то время как вам часто приходилось кодировать его раньше. Позже вы сможете стиль всего вашего приложения или веб-сайта из выпадающего списка тем, как любое приложение с поддержкой скинов. И многое другое может прийти.

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

Answer 8

Я думаю, что фреймворки - это следующий шаг.