Squirrel

[valexey_u]

В общем всё правда. Уверен что сам движок писали на С++, так как разработчикам нравится С++, взяли за основу ангел скрипт. Проще и лучше(?) взять, уже написанное, чем писать своё.

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

Странно выбирать язык по синтаксису :-)

Не знаю, по мне, так Angel Script и так очень простой, впрочем, это простительно пожалуй для встраиваемого языка, ибо его применение ограничено.

Вообще, если бы мне нужен был бы скриптовый (встраиваемый) язык для моего приложения, то я бы не стал париться, и взял бы в качестве такового тупо С++ :-)

[valexey_u]

Вообще, если бы мне нужен был бы скриптовый (встраиваемый) язык для моего приложения, то я бы не стал париться, и взял бы в качестве такового тупо С++ :-)

Но тут ключевое слово, конечно же, "мне". Чем шире предполагается аудитория, и примитивней задача которую следует решать на встроенном языке, тем язык должен быть проще и дуракоустойчивей. Целиться на сложную задачу и широкую аудиторию одновременно не выйдет.

[Jordan]

Вообще, если бы мне нужен был бы скриптовый (встраиваемый) язык для моего приложения, то я бы не стал париться, и взял бы в качестве такового тупо С++ :-)

Но тут ключевое слово, конечно же, "мне". Чем шире предполагается аудитория, и примитивней задача которую следует решать на встроенном языке, тем язык должен быть проще и дуракоустойчивей. Целиться на сложную задачу и широкую аудиторию одновременно не выйдет.

Язык си, топорный и простой язык, если не использовать всякие if (a = b), захватил умы программистов. Оберон ещё проще, + устойчив + нацелен на широкую аудиторию. Опять же на нём можно написать, всё. Так как компилируемый и есть указатели. Или модула 2. Системный язык. Уверен если бы он был популярен, на нём писали бы всё. Если уж на си умудряются писать всё, то и на обероне можно.

[Jordan]

И на старом добром паскале можно писать всё.

[valexey_u]

Вообще, если бы мне нужен был бы скриптовый (встраиваемый) язык для моего приложения, то я бы не стал париться, и взял бы в качестве такового тупо С++ :-)

Но тут ключевое слово, конечно же, "мне". Чем шире предполагается аудитория, и примитивней задача которую следует решать на встроенном языке, тем язык должен быть проще и дуракоустойчивей. Целиться на сложную задачу и широкую аудиторию одновременно не выйдет.

Язык си, топорный и простой язык, если не использовать всякие if (a = b), захватил умы программистов. Оберон ещё проще, + устойчив + нацелен на широкую аудиторию. Опять же на нём можно написать, всё. Так как компилируемый и есть указатели. Или модула 2. Системный язык. Уверен если бы он был популярен, на нём писали бы всё. Если уж на си умудряются писать всё, то и на обероне можно.

Ух, какой букет заблуждений!

Ну, для начала - не существует компилируемых и интерпретируемых языков. Нет такого понятия. Существуют компиляторы и интерпретаторы для какого-либо языка.

Язык си простой и топорный.. Ну да, объяви ка мне, пожалуйста, указатель на функцию в Си (ака процедурный тип). И да, он стал столь популярен в том числе и благодаря всяким if (a=b), ибо дюже удобно. Ты считаешь не Си топорным и простым, а некое подмножество Си которое ложится на подмножество Оберона. Это, мягко говоря, не верное представление о языке.

Указателей в Обероне по сути вменяемых нет. То что есть - сильно ограниченное их подмножество. Ну, допустим есть у нас RECORD, и есть у него поле типа INTEGER, получи пожалуйста указатель на это поле.

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

Модула-2 была популярной. Весьма популярной. Но... Не взлетело.

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

Ну а больше всего Оберону мешает конечно же неполнота его описания в language report'e. Там дикое количество неоднозначностей, из за которых каждая следующая реализация оказывается не совместимой с предыдущей. В результате имеем парадоксальную ситуацию - чем больше реализаций (компиляторов) Оберона появляется, тем хуже от этого языку. Тем больше хаос.

[Kemet]

И на старом добром паскале можно писать всё.

а уж сколько всего можно написать на старом добром ассемблере

[Kemet]

Ну, допустим есть у нас RECORD, и есть у него поле типа INTEGER, получи пожалуйста указатель на это поле.

Такой "указатель" не является валидным для Оберона, и это правильно. Но можно получить адрес через SYSTEM.ADR

[DddIzer]

Язык си простой и топорный.. Ну да, объяви ка мне, пожалуйста, указатель на функцию в Си (ака процедурный тип). И да, он стал столь популярен в том числе и благодаря всяким if (a=b), ибо дюже удобно. Ты считаешь не Си топорным и простым, а некое подмножество Си которое ложится на подмножество Оберона. Это, мягко говоря, не верное представление о языке.

но не будете же вы отрицать что Оберон попроще  и более внятным будет (взять хотя бы обьявление указателя на функцию).

[Jordan]

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

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

[Jordan]

valexey_u

Язык си простой и топорный.. Ну да, объяви ка мне, пожалуйста, указатель на функцию в Си (ака процедурный тип). И да, он стал столь популярен в том числе и благодаря всяким if (a=b), ибо дюже удобно. Ты считаешь не Си топорным и простым, а некое подмножество Си которое ложится на подмножество Оберона. Это, мягко говоря, не верное представление о языке.

Даже если писать на таком подмножестве си, от этого он станет непригоден?

[valexey_u]

И на старом добром паскале можно писать всё.

а уж сколько всего можно написать на старом добром ассемблере

Угу. Ассемблер вообще на порядки больше возможностей дает чем паскаль или там Си.

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

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

Оберон - мопед. Ездить менее комфортно чем на велосипеде (руль не столь удобный, да и сиденье), зато частенько педали можно не крутить - едет сам. Таскать через завалы его все еще можно, но уже тяжко.

Модула-3 - удобный современный мотоцикл. Предпочтительно ездить по дорогам, но если сильно-сильно припечет, то вдвоем вполне реально перетащить через завалы.

java/c# - обычный шоссейный автомобиль. На случай бездорожья в комплекте идет велосипед (который лежит разобранный в багажнике).

С++ - трансформер. Может превращаться как в велосипед, так и в летающий автомобиль. Требует ручной настройки. Водитель должен быть еще и механиком и летчиком, а иногда и хирургом.

DSL (например SQL) - самолет. Требует аэродром для взлета и посадки. Как добираться от аэродрома до места назначение - решаете сами.

[Jordan]

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

[DddIzer]

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

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

[DddIzer]

Кроме того, они не эквивалентны с точки зрения восприятия человеком текста программ.. Например, ошибочный пустой цикл
1. while (...); {...}
2. while ...   do; begin ... end
3. WHILE ...   DO;  ... END
в 1)  2) - ведут к одинаковым проблемам, НО в 2. (Паскаль) - подобные ошибки я наблюдал только у ОЧЕНЬ слабых студентов-новичков , а вот в 1. (СИ)  практически  у всех ( и это , несмотря на то, что я ТРЕБУЮ  предварительно выписывать алгоритм - и он ПРАВИЛЬНЫЙ (правильно выписано тело цикла))... народ просто смотрит в текст программы  10 -15 минут и не  может найти проблему.. а в 3. случае  такой проблемы вообще  нет...

[Jordan]

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

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

Теперь понятно. Если мы берём языки с императивной парадигмой, они буду отличаться только удобством и генерируемым кодом. То есть все войны между паскалями, с++, си, оберонами, проистекают именно в сравнении удобств описания. Спасибо за короткий и ясный ответ.

Кроме того, они не эквивалентны с точки зрения восприятия человеком текста программ.. Например, ошибочный пустой цикл
1. while (...); {...}
2. while ...   do; begin ... end
3. WHILE ...   DO;  ... END
в 1)  2) - ведут к одинаковым проблемам, НО в 2. (Паскаль) - подобные ошибки я наблюдал только у ОЧЕНЬ слабых студентов-новичков , а вот в 1. (СИ)  практически  у всех ( и это , несмотря на то, что я ТРЕБУЮ  предварительно выписывать алгоритм - и он ПРАВИЛЬНЫЙ (правильно выписано тело цикла))... народ просто смотрит в текст программы  10 -15 минут и не  может найти проблему.. а в 3. случае  такой проблемы вообще  нет...

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