Re[4]: Возможности ЯП vs Тьюринг-полнота
От: Sinclair Россия https://github.com/evilguest/
Дата: 19.11.21 10:17
Оценка: 3 (1) +2
Здравствуйте, Muxa, Вы писали:

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

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

Так эти функции — это же магия компилятора среды исполнения. Их невозможно реализовать на javascript.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Возможности ЯП vs Тьюринг-полнота
От: Muxa  
Дата: 19.11.21 07:17
Оценка: +3
S>Таких языков не делают, т.к. нет смысла.

понятно, очередная надуманная проблема
Re: Возможности ЯП vs Тьюринг-полнота
От: Sharov Россия  
Дата: 19.11.21 07:50
Оценка: +3
Здравствуйте, Shmj, Вы писали:

S>Как это называется? Как называются возможности языка с т.з. реализации доступа к системе?


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

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


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

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


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

А еще можно рассматривать системы типов в статически типизированных языках как отдельный специализированный язык. "Проверка типов" и "вычисление типов" — это выполнение программы на языке типизиции, происходит во время компиляции кода. Нетривиальные системы типов бывают Тьюринг-полными. Полезность статической типизации признанана многими, ввод/вывод совершенно не нужен.
Возможности ЯП vs Тьюринг-полнота
От: Shmj Ниоткуда  
Дата: 19.11.21 06:37
Оценка: -1 :)
Такой вопрос возник.

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

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

В память записать можно, действия с данными выполнить можно. А вот как-то сообщить пользователю нет — т.к. нет доступа ни к клаве, ни к экрану, ни к динамику, ни к файлам — вообще ни к чему.

Вроде язык тьюринг- полный — но бесполезный.

Возьмем JavaScript, для примера, который исполняется в песочнице браузера. Мы не можем прочесть произвольный файл на диске — но у нас есть возможность манипулировать HTML-разметкой окна браузера, доступ к хранилищу браузера, возможность делать сетевые запросы.

С т.з. языка — это просто некие внешние функции. Просто функции. И они вообще никак ни на что не влияют с точки зрения вычислимости.

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

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

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

Как это называется? Как называются возможности языка с т.з. реализации доступа к системе?
Re: Возможности ЯП vs Тьюринг-полнота
От: Muxa  
Дата: 19.11.21 06:51
Оценка: +2
S>Как это называется? Как называются возможности языка с т.з. реализации доступа к системе?

Система ввода-вывода.
А можно пример языка без таких функций? А то кроме шейдерных языков ничего в голову не приходит.
Отредактировано 19.11.2021 6:57 Muxa . Предыдущая версия .
Re[3]: Возможности ЯП vs Тьюринг-полнота
От: Sharov Россия  
Дата: 19.11.21 11:22
Оценка: +2
Здравствуйте, Shmj, Вы писали:

S>>Стандартные библиотеки это называется.

S>Если язык взрослый и можно работать с железом не через внешние библиотеки а напрямую — то никакие библиотеки не нужны.

Пример языка можно? Зачем io встраивать в язык?
Кодом людям нужно помогать!
Re[6]: Возможности ЯП vs Тьюринг-полнота
От: Shmj Ниоткуда  
Дата: 19.11.21 11:55
Оценка: :))
Здравствуйте, Sharov, Вы писали:

S>Что значит взрослые языка?


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

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

S>Си, кмк, более чем взрослый, однако и там это не встроено в сам язык, а через

S>библиотеки.

Но эти библиотеки можно написать и самому на там же C.

S>Зачем еще что-то нужно кроме ассемблера? Т.е. по факту предлагается скрестить ОС(прерывания, api) и компилятор. Зачем?

S>Наверное, что-то такое пытались делать. Едва ли этот язык будет удобен для чего-нибудь кроме написания ядер ОС.

Это другой вопрос.
Re[4]: Возможности ЯП vs Тьюринг-полнота
От: Sharov Россия  
Дата: 19.11.21 08:39
Оценка: 4 (1)
Здравствуйте, Muxa, Вы писали:

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

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


ОК, я думал про фс. Ну тогда xslt. Он вроде ТП.
Кодом людям нужно помогать!
Re: Pac-Man complete
От: Qbit86 Кипр
Дата: 19.11.21 07:03
Оценка: 3 (1)
Здравствуйте, Shmj, Вы писали:

S>Как это называется? Как называются возможности языка с т.з. реализации доступа к системе?


Есть шуточное название для подобного — «Pac-Man complete». Язык будет Pac-Man complete, если на нём можно реализовать игру Пакман.
Глаза у меня добрые, но рубашка — смирительная!
Re: Возможности ЯП vs Тьюринг-полнота
От: samius Япония http://sams-tricks.blogspot.com
Дата: 19.11.21 07:28
Оценка: -1
Здравствуйте, Shmj, Вы писали:

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


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

Тюринг-полнота — гораздо слабже, чем возможность реализовать любой из возможных алгоритмов. Там всего лишь о вычислимых, более того, на Тьюринг-машине.

S>Как это называется? Как называются возможности языка с т.з. реализации доступа к системе?

Ввод-вывод?
Re[2]: Возможности ЯП vs Тьюринг-полнота
От: Shmj Ниоткуда  
Дата: 19.11.21 11:20
Оценка: -1
Здравствуйте, Sharov, Вы писали:

S>Стандартные библиотеки это называется.


Если язык взрослый и можно работать с железом не через внешние библиотеки а напрямую — то никакие библиотеки не нужны.
Re[2]: Возможности ЯП vs Тьюринг-полнота
От: Shmj Ниоткуда  
Дата: 19.11.21 07:13
Оценка:
Здравствуйте, Muxa, Вы писали:

M>Система ввода-вывода.

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

Таких языков не делают, т.к. нет смысла.

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

Но если брать не теорию а практику. Взять тот же C# — в самом низу там функции с модификатором extern. Без реализации — просто название функциии во внешней dll, которая уже умеет работать с железом. Сам C# напрямую ничего не умеет без этих магических функций с extern — даже на консоль вывести не умеет.

Убери из C# это слово extern — и все — он станет абсолютно бесполезным, хотя нисколько не потеряет Тьюринг-полноту.

Т.е., получается, базовое слово в C# — это именно extern. Оно позволяет вызывать функции, созданные на взрослых ЯП, которые уже умеют работать с железом напрямую.
Отредактировано 19.11.2021 7:24 Shmj . Предыдущая версия . Еще …
Отредактировано 19.11.2021 7:13 Shmj . Предыдущая версия .
Re[2]: Шаблоны C++
От: Qbit86 Кипр
Дата: 19.11.21 07:18
Оценка:
Здравствуйте, Muxa, Вы писали:

M>А можно пример языка без таких функций?


Тьюринг-полная подсистема шаблонов C++.
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Pac-Man complete
От: Shmj Ниоткуда  
Дата: 19.11.21 07:25
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Есть шуточное название для подобного — «Pac-Man complete». Язык будет Pac-Man complete, если на нём можно реализовать игру Пакман.


Вот в том то и дело — все понимают, а выразить в точных терминах не могут. Только пошутить об это можно.
Re[2]: Возможности ЯП vs Тьюринг-полнота
От: Sharov Россия  
Дата: 19.11.21 07:55
Оценка:
Здравствуйте, Muxa, Вы писали:

M>Система ввода-вывода.

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

ТС привел пример js.
Кодом людям нужно помогать!
Re[3]: Возможности ЯП vs Тьюринг-полнота
От: Muxa  
Дата: 19.11.21 08:10
Оценка:
S>ТС привел пример js.
Вот же есть там всё
const input = prompt("Please enter your age:");
alert(`You are ${input} years old`);
Re[5]: Возможности ЯП vs Тьюринг-полнота
От: Muxa  
Дата: 19.11.21 09:14
Оценка:
S>ОК, я думал про фс. Ну тогда xslt. Он вроде ТП.

к файлам там вроде тоже есть какой-то ограниченный доступ.
в общем пока что получается список утилитарных узко-специализированных языков для решения задач в конкретных областях.
какой-нибудь vhdl или язык доказательства теорем тоже вполне могут быть тем что ищет ТС.
Re[6]: Возможности ЯП vs Тьюринг-полнота
От: Sharov Россия  
Дата: 19.11.21 09:59
Оценка:
Здравствуйте, Muxa, Вы писали:

S>>ОК, я думал про фс. Ну тогда xslt. Он вроде ТП.

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

Ну да, DSL. Sql (или диалекты) как пример.
Кодом людям нужно помогать!
Re[4]: Возможности ЯП vs Тьюринг-полнота
От: Shmj Ниоткуда  
Дата: 19.11.21 11:29
Оценка:
Здравствуйте, Sharov, Вы писали:

S>>Если язык взрослый и можно работать с железом не через внешние библиотеки а напрямую — то никакие библиотеки не нужны.

S>Пример языка можно? Зачем io встраивать в язык?

Ассемблер и ассемблерные вставки на C/C++. То есть никаких системных библиотек — прямой доступ к прерываниям, системной памяти и т.д.

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

И самая заноза — нет ни одного термина, которым бы можно было обосновать полноценность языка в данном ракурсе.
Отредактировано 19.11.2021 11:53 Shmj . Предыдущая версия .
Re[5]: Возможности ЯП vs Тьюринг-полнота
От: Sharov Россия  
Дата: 19.11.21 11:52
Оценка:
Здравствуйте, Shmj, Вы писали:

S>>>Если язык взрослый и можно работать с железом не через внешние библиотеки а напрямую — то никакие библиотеки не нужны.

S>>Пример языка можно? Зачем io встраивать в язык?
S>Ассемблер и ассемблерные вставки на C/C++. То есть никаких системных библиотек — прямой доступ к прерываниям, системной памяти и т.д.

Ок, справедливо, про слона забыл.

S>На этих взрослых языках пишут базу — работу с системой. А остальные детские языки уже в том или ином виде вызывают эти системные библиотеки, которые нельзя написать на них самих никаким образом.


Что значит взрослые языка? Си, кмк, более чем взрослый, однако и там это не встроено в сам язык, а через
библиотеки. А ассемблер -- и как там с типизацией, как с производительностью у программистов?

Зачем еще что-то нужно кроме ассемблера? Т.е. по факту предлагается скрестить ОС(прерывания, api) и компилятор. Зачем?
Наверное, что-то такое пытались делать. Едва ли этот язык будет удобен для чего-нибудь кроме написания ядер ОС.
Кодом людям нужно помогать!
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...
Пока на собственное сообщение не было ответов, его можно удалить.