Re[2]: Возможности ЯП vs Тьюринг-полнота
От: maxkar  
Дата: 20.11.21 13:29
Оценка: 10 (2)
Здравствуйте, Muxa, Вы писали:

M>А можно пример языка без таких функций? А то кроме шейдерных языков ничего в голову не приходит.


TeX, например, там своя "виртуальная машина". Хотя в реализациях есть обычно какой-то ввод или интеграция со внешним миром. Поэтому если не нравится TeX, можно взять PostScript. Если вывод (специфический) еще есть, то ввод я там совсем плохо представляю.

А еще можно рассматривать системы типов в статически типизированных языках как отдельный специализированный язык. "Проверка типов" и "вычисление типов" — это выполнение программы на языке типизиции, происходит во время компиляции кода. Нетривиальные системы типов бывают Тьюринг-полными. Полезность статической типизации признанана многими, ввод/вывод совершенно не нужен.
Re[3]: Возможности ЯП vs Тьюринг-полнота
От: samius Япония http://sams-tricks.blogspot.com
Дата: 20.11.21 14:24
Оценка: 19 (2)
Здравствуйте, maxkar, Вы писали:

M>А еще можно рассматривать системы типов в статически типизированных языках как отдельный специализированный язык. "Проверка типов" и "вычисление типов" — это выполнение программы на языке типизиции, происходит во время компиляции кода. Нетривиальные системы типов бывают Тьюринг-полными. Полезность статической типизации признанана многими, ввод/вывод совершенно не нужен.


А если рассматривать системы вообще (не типов), то надо упомянуть Правило 110. При доказанной Тьюринг-полноте полностью отсутствует ввод и вывод. Отдельный вопрос — считать ли Правило 110 языком. Ну да почему бы и нет, если Брэйнфак языком считается...
Re[2]: Возможности ЯП vs Тьюринг-полнота
От: Pzz Россия https://github.com/alexpevzner
Дата: 20.11.21 18:40
Оценка:
Здравствуйте, Muxa, Вы писали:

M>А можно пример языка без таких функций? А то кроме шейдерных языков ничего в голову не приходит.


JS в браузере. Ну т.е., у него есть, конечно, ввод-вывод. Но он весь из себя свой, специфический, и живет в своем собственном мире, а не напрямую в хостовой ОС.
Re: Возможности ЯП vs Тьюринг-полнота
От: Sinclair Россия https://github.com/evilguest/
Дата: 22.11.21 03:47
Оценка:
Здравствуйте, Shmj, Вы писали:
S>Как это называется? Как называются возможности языка с т.з. реализации доступа к системе?
Обычно это называется ввод/вывод. Или, в более широком смысле, среда исполнения (runtime).

Вы, в целом, мыслите в верном направлении.
Действительно, тьюринг-полнота мало говорит о прикладной полезности. Для того, чтобы программа, даже самая простая, приносила пользу, она должна как-то взаимодействовать с "внешним миром".
Математические абстракции вроде функций Чёрча или машины Тьюринга вопросов ввода-вывода избегают.

Но вот занятная штука: с течением времени оказалось, что встроенным IO оборудованы только нишевые либо игрушечные языки.
Возьмём, к примеру, язык ЛОГО. Безо всяких магических библиотек программы на этом языке управляют черепашкой, наглядно показывая результат своей работы.
Туда же можно отнести BASIC — в нём, в зависимости от диалекта, есть встроенные операторы типа PRINT, а также LINE и CIRCLE.
Опять — безо всяких библиотек имеем ввод/вывод; причём более похожий на "взрослые" системы, чем ЛОГО.

Куда ещё можно посмотреть? Можно посмотреть на SQL. В нём неявно предполагается, что оператор SELECT выведет результат в консоль клиента — ну, или на крайний случай, отдаст результат в программно-интерпретируемом виде . В некотором смысле, в SQL встроены возможности по "вводу" команд и к "выводу" результатов. Аналогичным образом построены командные интерпретаторы вроде bash, сmd.exe и powershell.

Кстати, к этому же напрямую относится вообще концепция консоли как устройства ввода-вывода — операционные системы много поколений подряд реализуют эту концепцию. В зависимости от предпочтений разработчиков языков, взаимодействие с консолью может быть реализовано как часть языка, как внешняя библиотека, либо как некий компромисс между этими полюсами (посмотрите на Паскаль, где функции Read и Write невозможно даже задекларировать на том же языке, не говоря уж о том, чтобы написать).

Наверное, можно понять, почему современные языки общего назначения отказались от встроенных возможностей по вводу-выводу.
Уж очень этот ввод/вывод получается платформенно-зависимым; в итоге, язык может оказаться непригодным за пределами своей маленькой ниши. Удобнее всего вынести ввод-вывод за пределы языка, оставив его в рамках библиотек.
Будут ли эти библиотеки реализованы "магией" или какой-то документированной особенностью среды исполнения — дело десятое. В итоге, мы можем на одном и том же языке писать программы для браузерной песочницы, где в качестве ввода/вывода у нас есть волшебные объекты вроде document и window, и для серверной стороны, где ничего подобного нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Возможности ЯП vs Тьюринг-полнота
От: ути-пути Россия  
Дата: 24.11.21 12:16
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Это те, библиотеки для которых можно написать на них самих.


S>Если язык нуждается в библиотеках, которые не возможно написать на нем самом — значит это не полноценный ЯП.


Бери глубже — надо чтобы язык работал без ОС, а лучше вообще без готового железа. Так что останутся тебе всякие HDL, хотя и к ним можно будет придраться.

Это я к чему: зачем тебе вообще такое деление?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[4]: Возможности ЯП vs Тьюринг-полнота
От: Shtole  
Дата: 05.12.21 14:59
Оценка:
Здравствуйте, Muxa, Вы писали:

S>>ТС привел пример js.

M>Вот же есть там всё
M>
const input = prompt("Please enter your age:");
M>alert(`You are ${input} years old`);


Кстати. Когда-то давно мне понадобилось дёргать из джаваскрипта нативные андроидные функции. Я посмотрел на евенты, которые можно было захендлить у контрола WebView и... ничего подходящего не нашёл. Вещь в себе, блин. Зато можно было сделать кастомную имплементацию alert(), видимо, чтобы по стилю из GUI не выбивалась. Я подумал-подумал, и быстренько накидал AQL (Alert Query Language).

В обратную сторону было легче, там было что-то типа executeScript().

Извините, что вы о высоком, о Тьюрингах, а я тут со всякой фигнёй
Do you want to develop an app?
Re: Возможности ЯП vs Тьюринг-полнота
От: Холодный Украина  
Дата: 05.12.21 16:14
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Такой вопрос возник.


S>Вот есть некий полноценный Тьюринг-полный ЯП. На нем можно реализовать любой из возможных алгоритмов.


S>Однако же в этом языке нет возможности доступа к API операционной системы ни в каком виде.

Язык это инструмент. Как всякий инструмент предназначен для решения некоторого класса задач. Пляски вокруг полного тьюринга не имеют практического смысла. Имеет смысл конкретное применение. Так же как от теоремы Кантора или от того что 2+2=4 толку никакого, если нет практического приложения этой штуки. Я тут придумал Недетерминированная машина Тьюринга. Архитектура. Язык. Система. Программирование.
https://www.facebook.com/groups/1084931979000426
Для автоматизации и ИИ бомба. А толку?
Гляньте там начал только ролики выкладывать. С удовольствием пообщаюсь. Может кто что подскажет.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.