Насколько высоко должны / пойдут языки высокого уровня?
Я знаю, что это очень абстрактно, но я считаю, что это очень сфокусировано.
Сегодня существует множество языков высокого уровня: C#, Java, VB, Python и т. Д., Все они созданы для отвлечения от низкоуровневой сложности и обеспечения более удобного программирования. Языки высокого уровня могут уменьшить и в большинстве случаев полностью устранить необходимость выполнения низкоуровневых операций, специфичных для процессов (таких как манипулирование указателями и управление памятью). Многие также удаляют сведения о платформе (например, манипулирование файлами, создание пользовательского интерфейса и т. Д.)
Мои два вопроса:
- Что еще можно / нужно абстрагировать? Существуют ли еще какие-либо семантики низкого уровня, присутствующие в современных языках высокого уровня, которые будут / должны быть абстрагированы дальше?
- В какой момент универсальный язык высокого уровня становится очень высокоуровневым, то есть ориентированным на достижение цели?
8 ответов
Одна из проблем, связанных с включением абстракций очень высокого уровня в язык, заключается в том, что иногда они не подходят для всего, что вы хотите сделать, поэтому в конечном итоге вам также понадобятся абстракции более низкого уровня. Проблема с наличием абстракций высокого и низкого уровня на одном и том же языке заключается в том, что абстракции высокого уровня могут очень легко стать утечками, если вы можете исследовать их с помощью абстракций низкого уровня.
Java, например, даже не является языком высокого уровня, но он спроектирован так, чтобы быть безопасным (в том смысле, что абстракции не просачиваются) в первую очередь. Поэтому некоторые вещи просто невозможно сделать в Java. Например, вы не можете написать сборщик мусора Java в Java, или свернуть свою собственную объектную систему, используя полиморфизм приведения указателя, или написать операционную систему (по крайней мере, не традиционную).
В отличие от этого, D предлагает услуги как высокого, так и низкого уровня. Например, сборщик мусора D написан на D. Это звучит хорошо, и по большей части это так. Однако, когда вы начинаете смешивать уровни абстракции в одной кодовой базе, абстракции могут просочиться, особенно если вы используете приведения или объединения, чтобы победить систему типов. Поэтому, чтобы успешно программировать на D, вам иногда может потребоваться информация о низкоуровневых деталях, чтобы справиться с вытекающими абстракциями, даже если они вам не нужны для текущей задачи.
- Что еще можно / нужно абстрагировать? Это всегда зависит от вашей цели. Здесь нет четкой линии, но я думаю, что все сводится к тому, какой контроль вам нужен? Обычно существует довольно тяжелый компромисс между абстракцией и возможностями.
- Когда универсальный язык высокого уровня становится ориентированным на цель? Как только вы сможете сказать языку / среде программирования, что вы хотите вместо того, что нужно делать.
В действительности, хотя... линия совершенно произвольна, конечно.
Определенные доменные языки могут быть очень "высокого уровня". Хорошим примером этого является 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."
Это фактический исходный код.:)
Я думаю, что гипотетический язык будущего позволит вам написать верификатор вместо реализации. Затем компилятор анализирует этот верификатор и (пытается) написать реализацию, соответствующую вашей спецификации. (Очевидно, что компилятор должен давать сбой или иногда прибегать к грубой силе, потому что он не решает проблемы).
По сути, логический язык с нелепыми оптимизациями по сравнению с грубым принуждением к ответу.
Несмотря на то, что код проверки может быть длиннее кода реализации, он действует как лучшая документация и ближе к тому, как выглядит спецификация. Вы тратите больше времени на набор кода для меньшего количества документации / спецификации / рассинхронизации кода.
Например:
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;
}
У Tcl есть официальное предложение ( Tcl Improvement Proposal (TIP) 131), которое в значительной степени решает проблему навсегда. Все, что ему нужно, - это волонтер для выполнения работы. Есть даже скелетная реализация, в которой не учтены лишь некоторые детали.
Хм, я думаю, что некоторые языки пытаются возглавить некоторые дополнительные абстракции: Clojure с его STM и Erlang с моделью Actor.
- Единственное, что я могу видеть, что я не вижу, как это будет сделано, - это язык с проверками параллелизма, подобный проверке со статической типизацией. Я говорю это потому, что существует проблема остановки.
- Когда он косит мою лужайку, делает мне кофе по утрам, проверяет мою электронную почту и сообщает мне, что произошло в новостях.
- В настоящее время некоторые "языки" предназначены для UAT (что близко к тому, что можно назвать целью, и для цели требуются тесты, потому что это единственный способ, которым это можно объяснить, например, пригодность для тестовой части); они могут быть объединены с языками программирования.
- Практически каждый язык получает доступ ко все большему количеству высокоуровневых интерфейсов (т. Е. Абстракции), требующих от вас все меньше и меньше кода и абстрагирующихся от ОС (посмотрите, насколько легко сделать приложение с графическим интерфейсом теперь на C# по сравнению с C++ MFC, по сравнению с в C++ Win32 API).
- Что касается языков программирования, они могли бы получить больше лучших возможностей других методов разработки: я имею в виду Аспектно-ориентированное программирование, которое могло бы помочь решить многие проблемы ОО и уже частично реализовано в некоторой форме в C# и Java (например, проблемы, связанные с регистрация, транзакции...).
- Конечная цель UML (была?) - позволить UML вместе с деталями диаграмм быть достаточными для кодирования системы; UML также является языком (в более широком смысле).
- Также должна быть включена среда IDE: теперь вы можете установить, как диалоговое окно должно изменяться из среды IDE, в то время как вам часто приходилось кодировать его раньше. Позже вы сможете оформить все свое приложение или веб-сайт из выпадающего списка тем, как любое другое приложение с поддержкой скинов. И многое другое может прийти.
Представьте себе объединение тех, кто находится в единой среде, потому что среда разработки является большой частью разработки, так же как и библиотеки, к которым у вас есть доступ, и уровень доступа.