Squirrel

[valexey_u]

В любом компилируемом языке, есть стандартные конструкции. Которые позволяют оперировать переменными. Алгоритмы + структуры данных = программы. А значит можно написать всё.

Мда...

Ну, во-первых компилируемых ЯП не существует.

Во-вторых компилируемость к рассматриваемому тобой вопросу не имеет никакого отношения в принципе.

В третьих, переменные (если ты подразумеваешь изменяемые переменные) тут не в тему - они не обязательны.

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

Ну и частный нюанс - иногда корректность данных выдаваемых алгоритмом зависит от того, КОГДА (то есть за какое время) эти данные поступят на выход.

Так что вопросы программирования и возможностей ЯП не ограничиваются лишь полнотой по Тьюрингу.

И это я пока даже не начал говорить о человеческом факторе, а ЯП все же (за редким исключением) создаются для человеков, и этот фактор один из важнейших в программировании.

[valexey_u]

Есть ли конкретные примеры. Вроде так как в языке x отсутствует фича a, реализация конктретных алгоритмов невозможна, что сужает круг применения данного языка.

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

У языка Тьюринга имеративная парадигма? А у Марковского языка?

[Jordan]

valexey_u

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

Можно несколько примеров, что бы лучше в голове улеглось.

[DddIzer]

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

а причем здесь подвох? ... тут все OK - тело цикла может ВООБЩЕ отсутствовать (если в условии есть побочный эффект)..  просто , в случае Си (С++) возможностей реализовать такую ситуацию на порядок больше (рассмотрите оператор  следования (,), и  for  вместе с семантикой присваивания). Но данном в конкретном случае..  я говорю о банальной ОПЕЧАТКЕ которую тяжело найти...

[DddIzer]

У языка Тьюринга имеративная парадигма? А у Марковского языка?

я сказал, то что сказал.. и сказал ЭТО для того, что бы не вступать в подобные дискуссии.

[Jordan]

DddIzer

а причем здесь подвох? ... тут все OK - тело цикла может ВООБЩЕ отсутствовать (если в условии есть побочный эффект)..

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

Но данном в конкретном случае..  я говорю о банальной ОПЕЧАТКЕ которую тяжело найти...

Теперь понятно, по какому пути идёт Вирт.

[valexey_u]

valexey_u

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

Можно несколько примеров, что бы лучше в голове улеглось.

Ну, например нет ни одного алгоритма который можно было бы реализовать на Обероне, но нельзя на брейнфаке.

[DddIzer]

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

Если вы возьмете  классиков жанра "K&R"  - то  исключительно ради производительности...(т.е. дает ПРИНЦИПИАЛЬНУЮ возможность писать родственный исполнителю код, особенно выгодно если задача формулируется в терминах близких к исполнителю и достаточно массивна, что бы откинуть мысль работать на уровне ассемблера).. имхо для классных специалистов знающих особенности реализации (компилятора) и архитектуру процессора.. это самое то.. а вот для начинающих (тем более на классе задач решаемых ими)- это "шаманские пляски и наставления"... из серии.. "так писали классики", "профессионалы пишут именно так"," замечено, что в некоторых случая использование адресной арифметики ведет увеличению производительности генерируемого компилятором кода".

[DddIzer]

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

[Geniepro]

DddIzer

а причем здесь подвох? ... тут все OK - тело цикла может ВООБЩЕ отсутствовать (если в условии есть побочный эффект)..

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

Но данном в конкретном случае..  я говорю о банальной ОПЕЧАТКЕ которую тяжело найти...

Теперь понятно, по какому пути идёт Вирт.

Для того, что бы уменьшить вероятность подобных подвохов, в языке Ада, например, кроме таких неопускаемых операторных скобок, как if-end if, loop-end loop, для указания пустого тела того же цикла необходимо явно написать оператор null (аналог ассемблерной команды NOP), иначе будет ощибка компиляции...

[DddIzer]

Для того, что бы уменьшить вероятность подобных подвохов, в языке Ада, например, кроме таких неопускаемых операторных скобок, как if-end if, loop-end loop, для указания пустого тела того же цикла необходимо явно написать оператор null (аналог ассемблерной команды NOP), иначе будет ощибка компиляции...

я вот другое не понял... нафига Вирт оставил их (операторные скобки) в Обероне... (в Аде  и С,С++ -  понятно, с помощью их можно организовать локальное окружение)

[ilovb]

Операторные скобки в Обероне? O_o

[DddIzer]

Операторные скобки в Обероне? O_o

а что вас так удивляет? ( BEGIN .... END  - еще с незапамятных времен  -позволяет группировать произвольное количество операторов как и { ... }, только не очень понятно зачем это в случае Оберона) -  модуль и тело процедуры , имхо, можно и нужно трактовать как отдельные конструкции.

[ilovb]

Тык в обероне их же нет.

[valexey_u]

Тык в обероне их же нет.

Подтверждаю - блоков в Обероне нет.