Oberon space
General Category => Общий раздел => Тема начата: ilovb от Апрель 27, 2013, 06:31:47 pm
-
http://ru.wikipedia.org/wiki/Squirrel
-
Синтаксис языка ближе к C/C++
Опять.
-
Ога. Я тоже не понимаю любовь к этой допотопной каке.
Желание добавить свистоперделки к Lua еще можно понять. Но поганить няшный луашный синтаксис это низачет.
-
Squirrel представляет собой язык с динамическим определением типов данных - тип переменной определяется значением, которое она хранит в данный момент времени и может меняться при присваивании нового значения.
Строгой типизации нет. Неужели сложно использовать 4 типа данных: ineger, float, boolean, string. Зато сколько ошибок можно исключить.
-
Lua and Squirrel (http://computerscomputing.wordpress.com/2013/02/18/lua-and-squirrel-the-case-for-squirrel/)
When considering an embedded scripting language, the most common choice is Lua, though there are many alternatives. One of those is Squirrel, a Lua-like language with a C-like syntax. Based on its history, one might dismiss Squirrel as simply “Lua with C syntax” or assume that its inclusion of classes and other features makes it heavy compared to Lua, perhaps the work of a spiteful C++ programmer who doesn’t like Lua. In actuality, not only is Squirrel light and performant, it addresses memory performance issues in Lua as well as several inconsistencies in the language, and it supplies features that must be hand-built in Lua.
-
Squirrel представляет собой язык с динамическим определением типов данных - тип переменной определяется значением, которое она хранит в данный момент времени и может меняться при присваивании нового значения.
Строгой типизации нет. Неужели сложно использовать 4 типа данных: ineger, float, boolean, string. Зато сколько ошибок можно исключить.
Подозреваю что там строгая типизация как раз есть, а вот статической нет.
-
Строгой типизации нет. Неужели сложно использовать 4 типа данных: ineger, float, boolean, string. Зато сколько ошибок можно исключить.
Сложно сделать простой и в то же время статически типизированный язык (например, сразу хочется дженериков, а они уже ни разу не простые). Оберон только подтверждает :)
-
Строгой типизации нет. Неужели сложно использовать 4 типа данных: ineger, float, boolean, string. Зато сколько ошибок можно исключить.
Сложно сделать простой и в то же время статически типизированный язык (например, сразу хочется дженериков, а они уже ни разу не простые). Оберон только подтверждает :)
Поэтому поклонники динамической типизации и смотрят до сих пор на языки со статической типизацией как на говно - на них (со статической типизацией) получается либо тонна кода на ровном месте, либо приходится эмулировать динамическую типизацию (опять центнер кода, да еще с ошибками, ибо реализуется ручками на месте), либо имеем дикую аццко-сложную систему типов, которая во время до-олгой компиляции периодически материт программиста длиннющими запутанными сообщениями о ошибках.
-
Надо разрабу логотип наш предложить ;D
ps Вроде ниче так как альтернатива Lua
-
Ещё есть Ангел скрипт
http://ru.wikipedia.org/wiki/AngelScript
Здесь язык, полный по C++. Классы, 20 типов данных и т.д И конечно скобочки.
Используется в проекте FOnline. Столько лет пилили, добавили разные плюшки в движок, 3D текстуры. Но выбор ангел скрипта в качестве скриптов, думаю было ошибкой.
-
Ещё есть Ангел скрипт
http://ru.wikipedia.org/wiki/AngelScript
Здесь язык, полный по C++. Классы, 20 типов данных и т.д И конечно скобочки.
Используется в проекте FOnline. Столько лет пилили, добавили разные плюшки в движок, 3D текстуры. Но выбор ангел скрипта в качестве скриптов, думаю было ошибкой.
Что значит полный по С++? Там нет и половины возможностей C++ :-)
Но если говорить именно о скриптинге, то лучше альтернативы пожалуй я не вижу. Так что если это было ошибкой, то что бы ошибкой не было бы?
-
Ещё есть Ангел скрипт
http://ru.wikipedia.org/wiki/AngelScript
Здесь язык, полный по C++. Классы, 20 типов данных и т.д И конечно скобочки.
Используется в проекте FOnline. Столько лет пилили, добавили разные плюшки в движок, 3D текстуры. Но выбор ангел скрипта в качестве скриптов, думаю было ошибкой.
Что значит полный по С++? Там нет и половины возможностей C++ :-)
Но если говорить именно о скриптинге, то лучше альтернативы пожалуй я не вижу. Так что если это было ошибкой, то что бы ошибкой не было бы?
Полный по С++, я имею ввиду синтаксис си, со всеми скобочкаси, записью классов и т.д
Сам проект претендует на замену старого движка f2, создание своих модов без ограничений. С этим он справляется, есть и онлайн и оффлайн версии. Но если уж делать, то делать упрощённо. То есть предоставить легкий скриптовый язык на базе оберуна, с ограниченным количеством переменных, и нормальной модульностью. Естественно написать свой скриптовый язык к движку. Пусть он будет маленький, но простой. Для скриптования игры возможности ангел скрипта излишни.
Всё это лечится транслятором.
Скриптовый язык нужно, делать как можно проще, что бы в нём разобрался любой человек, который о программировании даже не слышал. А не читать матан
http://www.13d-labs.com/angelscript_manual/main.html
Это моё личное мнение.
-
Я говорю не о самом ангел скрипте, а именно о применении его для конкретной игры.
-
Ещё есть Ангел скрипт
http://ru.wikipedia.org/wiki/AngelScript
Здесь язык, полный по C++. Классы, 20 типов данных и т.д И конечно скобочки.
Используется в проекте FOnline. Столько лет пилили, добавили разные плюшки в движок, 3D текстуры. Но выбор ангел скрипта в качестве скриптов, думаю было ошибкой.
Что значит полный по С++? Там нет и половины возможностей C++ :-)
Но если говорить именно о скриптинге, то лучше альтернативы пожалуй я не вижу. Так что если это было ошибкой, то что бы ошибкой не было бы?
Полный по С++, я имею ввиду синтаксис си, со всеми скобочкаси, записью классов и т.д
Ну, для начала в Си нет классов :-)
Во-вторых синтаксис Angel Script'a весьма далек от синтаксиса C++. Он скорее ближе к синтаксису урезанной java. Ну, например там нет замечательного синтаксиса указателей на функции. Нет и ничего похожего на шаблонный синтаксис. Нет макросов и так далее. Это если только про синтаксис говорить. В плане семантики же Angel Script вообще что-то существенно иное относительно C++.
Сам проект претендует на замену старого движка f2, создание своих модов без ограничений. С этим он справляется, есть и онлайн и оффлайн версии. Но если уж делать, то делать упрощённо. То есть предоставить легкий скриптовый язык на базе оберуна, с ограниченным количеством переменных, и нормальной модульностью. Естественно написать свой скриптовый язык к движку. Пусть он будет маленький, но простой. Для скриптования игры возможности ангел скрипта излишни.
А что в Обероне проще чем в Angel Script'e? Чур синтаксис в пример не приводить.
В Обероне толпа неоднозначностей и недоопределенностей. Ну и известные проблемы с отсутствием конструкторов переменных.
Возможности Angel Script'a ровно такие, чтобы на нем можно было писать дополнительные модули логики приличного размера.
Скриптовый язык нужно, делать как можно проще, что бы в нём разобрался любой человек, который о программировании даже не слышал. А не читать матан
http://www.13d-labs.com/angelscript_manual/main.html
По ссылке матана не обнаружено. Обнаружено описание языка.
Любой человек, который не слышал о программировании, мод написать не сможет, увы. На любом ЯП. Такие товарищи максимум что смогут - поправить конфиг (одну константу заменить на другую), да и то не всегда (у меня есть опыт работы с такими пользователями игры). Ну а для конфигов есть специальные действительно предельно простые языки - INI, json, xml и так далее.
-
В общем всё правда. Уверен что сам движок писали на С++, так как разработчикам нравится С++, взяли за основу ангел скрипт. Проще и лучше(?) взять, уже написанное, чем писать своё.
Просто мне нравится синтаксис оберуна, поэтому ругаю всё остальное, что не похоже на него. :)
Но всё же, можно было сделать общий скриптовый язык проще. :)
-
В общем всё правда. Уверен что сам движок писали на С++, так как разработчикам нравится С++, взяли за основу ангел скрипт. Проще и лучше(?) взять, уже написанное, чем писать своё.
Просто мне нравится синтаксис оберуна, поэтому ругаю всё остальное, что не похоже на него. :)
Но всё же, можно было сделать общий скриптовый язык проще. :)
Странно выбирать язык по синтаксису :-)
Не знаю, по мне, так Angel Script и так очень простой, впрочем, это простительно пожалуй для встраиваемого языка, ибо его применение ограничено.
Вообще, если бы мне нужен был бы скриптовый (встраиваемый) язык для моего приложения, то я бы не стал париться, и взял бы в качестве такового тупо С++ :-)
-
Вообще, если бы мне нужен был бы скриптовый (встраиваемый) язык для моего приложения, то я бы не стал париться, и взял бы в качестве такового тупо С++ :-)
Но тут ключевое слово, конечно же, "мне". Чем шире предполагается аудитория, и примитивней задача которую следует решать на встроенном языке, тем язык должен быть проще и дуракоустойчивей. Целиться на сложную задачу и широкую аудиторию одновременно не выйдет.
-
Вообще, если бы мне нужен был бы скриптовый (встраиваемый) язык для моего приложения, то я бы не стал париться, и взял бы в качестве такового тупо С++ :-)
Но тут ключевое слово, конечно же, "мне". Чем шире предполагается аудитория, и примитивней задача которую следует решать на встроенном языке, тем язык должен быть проще и дуракоустойчивей. Целиться на сложную задачу и широкую аудиторию одновременно не выйдет.
Язык си, топорный и простой язык, если не использовать всякие if (a = b), захватил умы программистов. :) Оберон ещё проще, + устойчив + нацелен на широкую аудиторию. Опять же на нём можно написать, всё. Так как компилируемый и есть указатели. Или модула 2. Системный язык. Уверен если бы он был популярен, на нём писали бы всё. Если уж на си умудряются писать всё, то и на обероне можно.
-
И на старом добром паскале можно писать всё.
-
Вообще, если бы мне нужен был бы скриптовый (встраиваемый) язык для моего приложения, то я бы не стал париться, и взял бы в качестве такового тупо С++ :-)
Но тут ключевое слово, конечно же, "мне". Чем шире предполагается аудитория, и примитивней задача которую следует решать на встроенном языке, тем язык должен быть проще и дуракоустойчивей. Целиться на сложную задачу и широкую аудиторию одновременно не выйдет.
Язык си, топорный и простой язык, если не использовать всякие if (a = b), захватил умы программистов. :) Оберон ещё проще, + устойчив + нацелен на широкую аудиторию. Опять же на нём можно написать, всё. Так как компилируемый и есть указатели. Или модула 2. Системный язык. Уверен если бы он был популярен, на нём писали бы всё. Если уж на си умудряются писать всё, то и на обероне можно.
Ух, какой букет заблуждений!
Ну, для начала - не существует компилируемых и интерпретируемых языков. Нет такого понятия. Существуют компиляторы и интерпретаторы для какого-либо языка.
Язык си простой и топорный.. Ну да, объяви ка мне, пожалуйста, указатель на функцию в Си (ака процедурный тип). И да, он стал столь популярен в том числе и благодаря всяким if (a=b), ибо дюже удобно. Ты считаешь не Си топорным и простым, а некое подмножество Си которое ложится на подмножество Оберона. Это, мягко говоря, не верное представление о языке.
Указателей в Обероне по сути вменяемых нет. То что есть - сильно ограниченное их подмножество. Ну, допустим есть у нас RECORD, и есть у него поле типа INTEGER, получи пожалуйста указатель на это поле.
Вообще говоря, даже возможностей Си (без расширизмов) не хватает на то, чтобы написать на нем действительно ВСЁ. Например обработчик прерываний, в общем сулучае, на нем не написать (для этого используются расширизмы). А уж Оберон... В современном Обероне даже без адских плясок с бубном даже массив размера не известного на этапе компиляции, не завести. Кроме того, Оберон таки подразумевает некий рантайм, в отличие от Си.
Модула-2 была популярной. Весьма популярной. Но... Не взлетело.
Оберон является более низкоуровневым языком нежели Си (хотя прострелить ногу в нем пожалуй сложнее чем в том же Си). Поэтому всё то же что написано на Си, на Обероне написано не будет.
Ну а больше всего Оберону мешает конечно же неполнота его описания в language report'e. Там дикое количество неоднозначностей, из за которых каждая следующая реализация оказывается не совместимой с предыдущей. В результате имеем парадоксальную ситуацию - чем больше реализаций (компиляторов) Оберона появляется, тем хуже от этого языку. Тем больше хаос.
-
И на старом добром паскале можно писать всё.
а уж сколько всего можно написать на старом добром ассемблере
-
Ну, допустим есть у нас RECORD, и есть у него поле типа INTEGER, получи пожалуйста указатель на это поле.
Такой "указатель" не является валидным для Оберона, и это правильно. Но можно получить адрес через SYSTEM.ADR
-
Язык си простой и топорный.. Ну да, объяви ка мне, пожалуйста, указатель на функцию в Си (ака процедурный тип). И да, он стал столь популярен в том числе и благодаря всяким if (a=b), ибо дюже удобно. Ты считаешь не Си топорным и простым, а некое подмножество Си которое ложится на подмножество Оберона. Это, мягко говоря, не верное представление о языке.
но не будете же вы отрицать что Оберон попроще и более внятным будет (взять хотя бы обьявление указателя на функцию).
-
Не будем брать ос где в любом случае, будет машинно зависимый код. Пиши хоть на си, хоть на обероне 2. Но почему на оберуне 2, нельзя писать, всё то, что пишется на си.
Есть ли конкретные примеры. Вроде так как в языке x отсутствует фича a, реализация конктретных алгоритмов невозможна, что сужает круг применения данного языка.
-
valexey_u
Язык си простой и топорный.. Ну да, объяви ка мне, пожалуйста, указатель на функцию в Си (ака процедурный тип). И да, он стал столь популярен в том числе и благодаря всяким if (a=b), ибо дюже удобно. Ты считаешь не Си топорным и простым, а некое подмножество Си которое ложится на подмножество Оберона. Это, мягко говоря, не верное представление о языке.
Даже если писать на таком подмножестве си, от этого он станет непригоден?
-
И на старом добром паскале можно писать всё.
а уж сколько всего можно написать на старом добром ассемблере
Угу. Ассемблер вообще на порядки больше возможностей дает чем паскаль или там Си.
Написание кода на асме сродни хождению пешком - возможностей уйма, можно перелезть любые завалы и бездорожье не страшно, полный контроль. Но к цели движешься довольно медленно.
Паскаль или там Си, или модула-2 - это уже езда на велосипеде. Быстрее, но при условии что нет откровенного бездорожья и завалов. Впрочем, трудно проходимые места можно пройти пешком, перетащив велосипед на себе.
Оберон - мопед. Ездить менее комфортно чем на велосипеде (руль не столь удобный, да и сиденье), зато частенько педали можно не крутить - едет сам. Таскать через завалы его все еще можно, но уже тяжко.
Модула-3 - удобный современный мотоцикл. Предпочтительно ездить по дорогам, но если сильно-сильно припечет, то вдвоем вполне реально перетащить через завалы.
java/c# - обычный шоссейный автомобиль. На случай бездорожья в комплекте идет велосипед (который лежит разобранный в багажнике).
С++ - трансформер. Может превращаться как в велосипед, так и в летающий автомобиль. Требует ручной настройки. Водитель должен быть еще и механиком и летчиком, а иногда и хирургом.
DSL (например SQL) - самолет. Требует аэродром для взлета и посадки. Как добираться от аэродрома до места назначение - решаете сами.
-
В любом компилируемом языке, есть стандартные конструкции. Которые позволяют оперировать переменными. Алгоритмы + структуры данных = программы. А значит можно написать всё.
-
Есть ли конкретные примеры. Вроде так как в языке x отсутствует фича a, реализация конктретных алгоритмов невозможна, что сужает круг применения данного языка.
Нет... ЯВУ которые поддерживают полностью императивную парадигму эквивалентны (в ее рамках).. разумеется, с точки зрения алгоритмического решения задачи (т.е возможности перевести систему из эквивалентного начального состояния в конечное с помощью эквивалентного по результату алгоритма).. а не самого алгоритма (конечной последовательности действий).И, разумеется, они не равноценны с точки зрения удобства описания этой системы, конкретной последовательности действий, и производительности генерируемого кода..
-
Кроме того, они не эквивалентны с точки зрения восприятия человеком текста программ.. Например, ошибочный пустой цикл
1. while (...); {...}
2. while ... do; begin ... end
3. WHILE ... DO; ... END
в 1) 2) - ведут к одинаковым проблемам, НО в 2. (Паскаль) - подобные ошибки я наблюдал только у ОЧЕНЬ слабых студентов-новичков , а вот в 1. (СИ) практически у всех ( и это , несмотря на то, что я ТРЕБУЮ предварительно выписывать алгоритм - и он ПРАВИЛЬНЫЙ (правильно выписано тело цикла))... народ просто смотрит в текст программы 10 -15 минут и не может найти проблему.. а в 3. случае такой проблемы вообще нет...
-
Есть ли конкретные примеры. Вроде так как в языке x отсутствует фича a, реализация конктретных алгоритмов невозможна, что сужает круг применения данного языка.
Нет... ЯВУ которые поддерживают полностью императивную парадигму эквивалентны (в ее рамках).. разумеется, с точки зрения алгоритмического решения задачи (т.е возможности перевести систему из эквивалентного начального состояния в конечное с помощью эквивалентного по результату алгоритма).. а не самого алгоритма (конечной последовательности действий).И, разумеется, они не равноценны с точки зрения удобства описания этой системы, конкретной последовательности действий, и производительности генерируемого кода..
Теперь понятно. Если мы берём языки с императивной парадигмой, они буду отличаться только удобством и генерируемым кодом. То есть все войны между паскалями, с++, си, оберонами, проистекают именно в сравнении удобств описания. Спасибо за короткий и ясный ответ.
Кроме того, они не эквивалентны с точки зрения восприятия человеком текста программ.. Например, ошибочный пустой цикл
1. while (...); {...}
2. while ... do; begin ... end
3. WHILE ... DO; ... END
в 1) 2) - ведут к одинаковым проблемам, НО в 2. (Паскаль) - подобные ошибки я наблюдал только у ОЧЕНЬ слабых студентов-новичков , а вот в 1. (СИ) практически у всех ( и это , несмотря на то, что я ТРЕБУЮ предварительно выписывать алгоритм - и он ПРАВИЛЬНЫЙ (правильно выписано тело цикла))... народ просто смотрит в текст программы 10 -15 минут и не может найти проблему.. а в 3. случае такой проблемы вообще нет...
Даже не знал, что в паскале такое есть. Для чего вообще, нужны такие конструкции с подвохом?
-
В любом компилируемом языке, есть стандартные конструкции. Которые позволяют оперировать переменными. Алгоритмы + структуры данных = программы. А значит можно написать всё.
Мда...
Ну, во-первых компилируемых ЯП не существует.
Во-вторых компилируемость к рассматриваемому тобой вопросу не имеет никакого отношения в принципе.
В третьих, переменные (если ты подразумеваешь изменяемые переменные) тут не в тему - они не обязательны.
Ну и в четвертых - то о чем ты говоришь, называется вычислимостью и полнотой по Тьюрингу. Все полные по Тьюрингу языки эквивалентны в том смысле, что алгоритм реализованный на одном можно реализовать и на другом. Но тут есть нюанс - алгоритм это не приложение. Соответственно если взять два разных ЯП полных по Тьюрингу, то несмотря на то, что на обоих реализуется один и тот же класс алгоритмов, возможности в плане написания на них приложений разные. То есть могут существовать такие классы приложений, что они реализуемы на языке А но не реализуемы на языке Б.
Ну и частный нюанс - иногда корректность данных выдаваемых алгоритмом зависит от того, КОГДА (то есть за какое время) эти данные поступят на выход.
Так что вопросы программирования и возможностей ЯП не ограничиваются лишь полнотой по Тьюрингу.
И это я пока даже не начал говорить о человеческом факторе, а ЯП все же (за редким исключением) создаются для человеков, и этот фактор один из важнейших в программировании.
-
Есть ли конкретные примеры. Вроде так как в языке x отсутствует фича a, реализация конктретных алгоритмов невозможна, что сужает круг применения данного языка.
Нет... ЯВУ которые поддерживают полностью императивную парадигму эквивалентны (в ее рамках).. разумеется, с точки зрения алгоритмического решения задачи (т.е возможности перевести систему из эквивалентного начального состояния в конечное с помощью эквивалентного по результату алгоритма).. а не самого алгоритма (конечной последовательности действий).И, разумеется, они не равноценны с точки зрения удобства описания этой системы, конкретной последовательности действий, и производительности генерируемого кода..
У языка Тьюринга имеративная парадигма? А у Марковского языка?
-
valexey_u
Ну и в четвертых - то о чем ты говоришь, называется вычислимостью и полнотой по Тьюрингу. Все полные по Тьюрингу языки эквивалентны в том смысле, что алгоритм реализованный на одном можно реализовать и на другом. Но тут есть нюанс - алгоритм это не приложение. Соответственно если взять два разных ЯП полных по Тьюрингу, то несмотря на то, что на обоих реализуется один и тот же класс алгоритмов, возможности в плане написания на них приложений разные. То есть могут существовать такие классы приложений, что они реализуемы на языке А но не реализуемы на языке Б.
Можно несколько примеров, что бы лучше в голове улеглось.
-
Даже не знал, что в паскале такое есть. Для чего вообще, нужны такие конструкции с подвохом?
а причем здесь подвох? ... тут все OK - тело цикла может ВООБЩЕ отсутствовать (если в условии есть побочный эффект).. просто , в случае Си (С++) возможностей реализовать такую ситуацию на порядок больше (рассмотрите оператор следования (,), и for вместе с семантикой присваивания). Но данном в конкретном случае.. я говорю о банальной ОПЕЧАТКЕ которую тяжело найти...
-
У языка Тьюринга имеративная парадигма? А у Марковского языка?
я сказал, то что сказал.. и сказал ЭТО для того, что бы не вступать в подобные дискуссии.
-
DddIzer
а причем здесь подвох? ... тут все OK - тело цикла может ВООБЩЕ отсутствовать (если в условии есть побочный эффект)..
Это я понял, но для чего это нужно? Такая конструкция лучше оптимизируется, или так нравилось создателю языка и т.д
Но данном в конкретном случае.. я говорю о банальной ОПЕЧАТКЕ которую тяжело найти...
Теперь понятно, по какому пути идёт Вирт.
-
valexey_u
Ну и в четвертых - то о чем ты говоришь, называется вычислимостью и полнотой по Тьюрингу. Все полные по Тьюрингу языки эквивалентны в том смысле, что алгоритм реализованный на одном можно реализовать и на другом. Но тут есть нюанс - алгоритм это не приложение. Соответственно если взять два разных ЯП полных по Тьюрингу, то несмотря на то, что на обоих реализуется один и тот же класс алгоритмов, возможности в плане написания на них приложений разные. То есть могут существовать такие классы приложений, что они реализуемы на языке А но не реализуемы на языке Б.
Можно несколько примеров, что бы лучше в голове улеглось.
Ну, например нет ни одного алгоритма который можно было бы реализовать на Обероне, но нельзя на брейнфаке.
-
Это я понял, но для чего это нужно? Такая конструкция лучше оптимизируется, или так нравилось создателю языка и т.д
Если вы возьмете классиков жанра "K&R" - то исключительно ради производительности...(т.е. дает ПРИНЦИПИАЛЬНУЮ возможность писать родственный исполнителю код, особенно выгодно если задача формулируется в терминах близких к исполнителю и достаточно массивна, что бы откинуть мысль работать на уровне ассемблера).. имхо для классных специалистов знающих особенности реализации (компилятора) и архитектуру процессора.. это самое то.. а вот для начинающих (тем более на классе задач решаемых ими)- это "шаманские пляски и наставления"... из серии.. "так писали классики", "профессионалы пишут именно так"," замечено, что в некоторых случая использование адресной арифметики ведет увеличению производительности генерируемого компилятором кода".
-
... ну а если отмести в сторону вудуизм... то, вообще говоря, вариативность выбора конкретной последовательности действий дает определенную вероятность того, что запись с помощью нее некоторого алгоритма будет оптимальной в некотором смысле (несильно отличается от традиционной нотации, записывается с минимальным количеством знаков, оставаясь при этом вполне читаемой и обозримой...).
-
DddIzer
а причем здесь подвох? ... тут все OK - тело цикла может ВООБЩЕ отсутствовать (если в условии есть побочный эффект)..
Это я понял, но для чего это нужно? Такая конструкция лучше оптимизируется, или так нравилось создателю языка и т.д
Но данном в конкретном случае.. я говорю о банальной ОПЕЧАТКЕ которую тяжело найти...
Теперь понятно, по какому пути идёт Вирт.
Для того, что бы уменьшить вероятность подобных подвохов, в языке Ада, например, кроме таких неопускаемых операторных скобок, как if-end if, loop-end loop, для указания пустого тела того же цикла необходимо явно написать оператор null (аналог ассемблерной команды NOP), иначе будет ощибка компиляции...
-
Для того, что бы уменьшить вероятность подобных подвохов, в языке Ада, например, кроме таких неопускаемых операторных скобок, как if-end if, loop-end loop, для указания пустого тела того же цикла необходимо явно написать оператор null (аналог ассемблерной команды NOP), иначе будет ощибка компиляции...
я вот другое не понял... нафига Вирт оставил их (операторные скобки) в Обероне... (в Аде и С,С++ - понятно, с помощью их можно организовать локальное окружение)
-
Операторные скобки в Обероне? O_o
-
Операторные скобки в Обероне? O_o
а что вас так удивляет? ( BEGIN .... END - еще с незапамятных времен -позволяет группировать произвольное количество операторов как и { ... }, только не очень понятно зачем это в случае Оберона) - модуль и тело процедуры , имхо, можно и нужно трактовать как отдельные конструкции.
-
Тык в обероне их же нет.
-
Тык в обероне их же нет.
Подтверждаю - блоков в Обероне нет.
-
Тык в обероне их же нет.
В каком?
например в Астив Обероне вот это
MODULE M;
PROCEDURE Run* ();
BEGIN
END Run;
BEGIN
BEGIN
END;
END M.
компилируется без проблем...
-
а вот в Обероне 2 от XDS - нет...
-
Тык в обероне их же нет.
В каком?
например в Астив Обероне вот это
MODULE M;
PROCEDURE Run* ();
BEGIN
END Run;
BEGIN
BEGIN
END;
END M.
компилируется без проблем...
В чисто Виртовском. Глянь грамматику:
http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.Report.pdf
http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon.Report.pdf
В Обероне-2 и, соответственно, CP тоже нет.
-
В чисто Виртовском. Глянь грамматику:
http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.Report.pdf
http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon.Report.pdf
В Обероне-2 и, соответственно, CP тоже нет.
Возможно, просто сейчас ковыряюсь в AO- на предмет мат. расширизмов о которых говорил Kemet.. и заметил это дело.. -а в обычных Оберонах мне и в голову не приходило их использовать.
-
Раз уж мы офтопим. Хотя, что считать на этом форуме офтопом? ;D
Для чего нужны вложенные процедуры? В си их нет. Значит без них программировать можно. Но Вирт их в оберуне 2 оставил.
-
Раз уж мы офтопим. Хотя, что считать на этом форуме офтопом? ;D
Для чего нужны вложенные процедуры? В си их нет. Значит без них программировать можно. Но Вирт их в оберуне 2 оставил.
Ну, к Оберону-2 Вирт руку уже мало прикладывал. А вот то, что он оставил их в Обероне-07, что-то да значит, да.
-
Погуглил вопрос. Народ сам в недоумении для чего это нужно. Ещё есть вложенные классы или Внутренний класс.
... ну а если отмести в сторону вудуизм...
Хорошо сказано. :)
-
Для чего нужны вложенные процедуры? В си их нет. Значит без них программировать можно. Но Вирт их в оберуне 2 оставил.
Вложенные процедуры удобная и нужная штука.
-
Раз уж мы офтопим. Хотя, что считать на этом форуме офтопом? ;D
Для чего нужны вложенные процедуры? В си их нет. Значит без них программировать можно. Но Вирт их в оберуне 2 оставил.
Ну, к Оберону-2 Вирт руку уже мало прикладывал. А вот то, что он оставил их в Обероне-07, что-то да значит, да.
Как оставил? Вроде убирал же???
-
Погуглил вопрос. Народ сам в недоумении для чего это нужно. Ещё есть вложенные классы или Внутренний класс.
А ещё в Модуле-2 были вложенные модули, но в Обероне Вирт их выкинул...
-
Раз уж мы офтопим. Хотя, что считать на этом форуме офтопом? ;D
Для чего нужны вложенные процедуры? В си их нет. Значит без них программировать можно. Но Вирт их в оберуне 2 оставил.
Ну, к Оберону-2 Вирт руку уже мало прикладывал. А вот то, что он оставил их в Обероне-07, что-то да значит, да.
Как оставил? Вроде убирал же???
Из своего мейнстрим-оберона -- нет, не убирал. Посмотри репорты уже :-)
-
Для чего нужны вложенные процедуры? В си их нет. Значит без них программировать можно. Но Вирт их в оберуне 2 оставил.
Вложенные процедуры при компиляции и загрузке находятся в одном пространстве(фрейме), они, по сути, неотделимы от основной процедуры, поэтому попадают в кэш процессора как единое целое, что несколько ускорят работу, а вынесенные во вне процедуры могут снижать производительность изза перезагрузки кэша, лично мы на эту особенность натыкались. И это не только в обероне, но, например, и в фрипаскале (на нём эта проблема и выявилась)...
-
Для чего нужны вложенные процедуры? В си их нет. Значит без них программировать можно. Но Вирт их в оберуне 2 оставил.
Вложенные процедуры при компиляции и загрузке находятся в одном пространстве(фрейме), они, по сути, неотделимы от основной процедуры, поэтому попадают в кэш процессора как единое целое, что несколько ускорят работу, а вынесенные во вне процедуры могут снижать производительность изза перезагрузки кэша, лично мы на эту особенность натыкались. И это не только в обероне, но, например, и в фрипаскале (на нём эта проблема и выявилась)...
Нет.. ибо Оберон не определяет понятие кэша процессора.. - просто это сохранение поддержки классического процедурного стиля разработки.. Это когда сложная задача разбивается на кучу НЕЗАВИСИМЫХ простых. Каждой простой задаче соответствует некоторый алгоритм (который можно рассматривать как составной). Так вот, вложенные процедуры обеспечивают возможность независимости разбиений (т.е. нахождение решения подзадачи можно рассматривать как отдельное, независимое (в контексте основной задачи) действие).
-
Для чего нужны вложенные процедуры? В си их нет. Значит без них программировать можно. Но Вирт их в оберуне 2 оставил.
Вложенные процедуры удобная и нужная штука.
ИМХО только в процедурном программировании.
Главное же - доступ к объемлющему контексту.
Так реализация на уровне модуля это уже обеспечивает - доступ к объемлющему контексту.
Может быть я не вижу, но я пока не открыл для себя такой уж большой выгоды и полезности именно вложенных процедур.
А транслятор усложняет... :)
Если нетрудно, приведите доводы в пользу вложенности.
-
Нет..
Чего "нет"? Вы вообще читали о чём я написал? Я написал об одной возможной проблеме, которая решается вложенными процедурами, ни больше, ни меньше.
-
Valery, ну вот я например люблю так писать:
https://github.com/ilovb/ProjectOberonV4/blob/master/OBS.Mod#L172
https://github.com/ilovb/ProjectOberonV4/blob/master/OBC.Mod#L160
Это удобно. Не нужно протаскивать переменные через параметры (бывает ведь и много переменных)
Процедура локализована ровно там, где используется. (т.е. сразу видно что это вспомогательная штука)
Ну и я предполагаю что такие процедуры должны всегда инлайниться.
-
Нет..
Чего "нет"? Вы вообще читали о чём я написал? Я написал об одной возможной проблеме, которая решается вложенными процедурами, ни больше, ни меньше.
Откровенно говоря, не понимаю как одно с другим связано - после кодогенерации инструкции любой процедуры могут равномерно быть размазаны по всему адресному пространству, если кодогенератор решит, что там оно будет лучше.
-
Откровенно говоря, не понимаю как одно с другим связано - после кодогенерации инструкции любой процедуры могут равномерно быть размазаны по всему адресному пространству, если кодогенератор решит, что там оно будет лучше.
Такой хоккейкомпилятор нам не нужен. Если процедура "размажется", будет нарезана на шматы сала, то будет и много лишних переходов, что плохо, а если это в одном фрейме и у нас есть список этих фреймов (а в рантайме и в симфайлахъ/загружаемых модулях он есть) то очень просто узнать, в какой процедуре находимся (что и делает Оберонистый рантайм, легко и непринужденно).
-
Нет..
Чего "нет"? Вы вообще читали о чём я написал? Я написал об одной возможной проблеме, которая решается вложенными процедурами, ни больше, ни меньше.
Читал.. и еще раз говорю нет.. - повторюсь .. мне не лень... - ЯВУ не гарантирует решение вашей проблемы с помощью вложенных процедур ни больше, ни меньше (но конкретная реализация может) - мы ведь говорим про ЯВУ , а не про конкретную реализацию. :D Закладываться на особенности реализации ИМХО последнее дело.
-
Valery, ну вот я например люблю так писать:
https://github.com/ilovb/ProjectOberonV4/blob/master/OBS.Mod#L172
https://github.com/ilovb/ProjectOberonV4/blob/master/OBC.Mod#L160
Это удобно. Не нужно протаскивать переменные через параметры (бывает ведь и много переменных)
Процедура локализована ровно там, где используется. (т.е. сразу видно что это вспомогательная штука)
Ну и я предполагаю что такие процедуры должны всегда инлайниться.
угу.. тоже самое... только в случае Оберона я это не могу предположить.. и потом, отлаживать такие вещи тяжелее, как ни крути...
-
Нет..
Чего "нет"? Вы вообще читали о чём я написал? Я написал об одной возможной проблеме, которая решается вложенными процедурами, ни больше, ни меньше.
Читал.. и еще раз говорю нет.. - повторюсь .. мне не лень... - ЯВУ не гарантирует решение вашей проблемы с помощью вложенных процедур ни больше, ни меньше (но конкретная реализация может) - мы ведь говорим про ЯВУ , а не про конкретную реализацию. :D Закладываться на особенности реализации ИМХО последнее дело.
Вас может быть удивит, но люди используют в работе вполне конкретные инструменты, а не просто абстрактные парадигмы и сообщения о языках.
-
Вас может быть удивит, но люди используют в работе вполне конкретные инструменты, а не просто абстрактные парадигмы и сообщения о языках.
Я в курсе... но я сомневаюсь что даже на уровне конкретного инструмента (реализации), то о чем вы говорите четко прописано... впрочем, хакайте и эксплойте на здоровье.. моя позиция - без КРАЙНЕЙ необходимости (то есть если вы зажаты в угол) это занятие бесперспективное.
-
DddIzer
Многие неадекватные конструкции языка си были продиктованы исключительно производительностью. У меня ещё остался вопрос, какие у вас есть мысли, по поводу использования { и } в языке? Оптимизация здесь отпадает. Именно желание разработчика языка? Если так тогда, что и сколько нужно принять, что бы такое придумать. :)
В чём весь фетиш этих скобок?
-
Поторопился, с вопросом. В языке limbo, тоже скобочки. Всё же именно создателям языка такое нравилось.
-
Многие неадекватные конструкции языка си были продиктованы исключительно производительностью. У меня ещё остался вопрос, какие у вас есть мысли, по поводу использования { и } в языке? Оптимизация здесь отпадает. Именно желание разработчика языка? Если так тогда, что и сколько нужно принять, что бы такое придумать. :)
В чём весь фетиш этих скобок?
На самом это тоже оптимизация (ну или попытка оптимизации) производительности при наборе кода программы. Конечно, по птичности языка сям до АПЛ как до Китая, но тем не менее они старались -- Ричи с Керниганом.
{ -- короче, чем begin, а } -- короче, чем end. Вот и весь фетиш -- меньше клавиш нажимать, больше текста наберёшь, прежде чем тунельный синдром получишь )))
Для 60-70-х гг прошлого века это имело значение ещё и в плане экономии места на перфокартах, например...
-
Многие неадекватные конструкции языка си были продиктованы исключительно производительностью. У меня ещё остался вопрос, какие у вас есть мысли, по поводу использования { и } в языке? Оптимизация здесь отпадает. Именно желание разработчика языка? Если так тогда, что и сколько нужно принять, что бы такое придумать. :)
В чём весь фетиш этих скобок?
На самом это тоже оптимизация (ну или попытка оптимизации) производительности при наборе кода программы. Конечно, по птичности языка сям до АПЛ как до Китая, но тем не менее они старались -- Ричи с Керниганом.
{ -- короче, чем begin, а } -- короче, чем end. Вот и весь фетиш -- меньше клавиш нажимать, больше текста наберёшь, прежде чем тунельный синдром получишь )))
Для 60-70-х гг прошлого века это имело значение ещё и в плане экономии места на перфокартах, например...
Глянул примеры на апл
http://aplwiki.com/MessageDigestHash
:o
Прям брейнфак своего времени. :)
Теперь утолил свой интерес, по скобочкам. Суду по комментариям о си, типа стройности языка. Ценители всё же нашлись. Человек в принципе, ко всему может привыкнуть, и даже начать это восхвалять.
На стокгольмский синдром, похоже. :)
-
Многие неадекватные конструкции языка си были продиктованы исключительно производительностью. У меня ещё остался вопрос, какие у вас есть мысли, по поводу использования { и } в языке? Оптимизация здесь отпадает. Именно желание разработчика языка? Если так тогда, что и сколько нужно принять, что бы такое придумать. :)
В чём весь фетиш этих скобок?
На самом это тоже оптимизация (ну или попытка оптимизации) производительности при наборе кода программы. Конечно, по птичности языка сям до АПЛ как до Китая, но тем не менее они старались -- Ричи с Керниганом.
{ -- короче, чем begin, а } -- короче, чем end. Вот и весь фетиш -- меньше клавиш нажимать, больше текста наберёшь, прежде чем тунельный синдром получишь )))
Для 60-70-х гг прошлого века это имело значение ещё и в плане экономии места на перфокартах, например...
где-то так, только это было не фетишом для них ... это была фича для ленивых профессионалов -фетишом это является для остальных...
-
Поторопился, с вопросом. В языке limbo, тоже скобочки. Всё же именно создателям языка такое нравилось.
Да элементарно, Ватсон!... :)
Чтобы меньше символов было набирать. Меньше символов - меньше возможных дурацких ошибок-опечаток.
В 69-71 году создавалось жеж... :)
-
Поторопился, с вопросом. В языке limbo, тоже скобочки. Всё же именно создателям языка такое нравилось.
Да элементарно, Ватсон!... :)
Чтобы меньше символов было набирать. Меньше символов - меньше возможных дурацких ошибок-опечаток.
В 69-71 году создавалось жеж... :)
Одно слово - телетайп. И 1 символ в секунду. На этот раз разработчики приложений САМИ набирали свои программы.
-
Ещё вопрос. Почему в си были встроены строки с символом в конце. Для нахождения длины строку требуется перебрать все символы, до конечного символа. Производительности это не прибавляет.
Можно было пойти по стопам basic, bstr строки длина строки хранится в байте или в 4 байтах, к примеру в реализациях delphi, visual basic, object pascal.
В pascale вирт сразу заложил такие строки, но они были ограничены 1 байтом, но что мешало раширить их в си 2 или 4 байтами. Не думаю, что 70-ых годах оперировали 2 гигобайтными строками.
Я знаю, что можно сделать свои динамические строки в си. Но зачем велосипедствовать, если их можно встроить. Как минимум их ненужно освобождать, что облегчает и повышает качество кода.
-
Ещё вопрос. Почему в си были встроены строки с символом в конце. Для нахождения длины строку требуется перебрать все символы, до конечного символа. Производительности это не прибавляет.
Как правильно заметил товарищ valexey - в Си все есть шмат памяти. При этом, когда человек ковыряется в этой памяти ему удобно видеть строки как последовательности байтов, а конец этих байтов - 0. Ему неудобно сначала видеть число, а потом отсчитывать количество байтов, чтоб узнать где конец строки :)
Вот это и сишная строка и массив char'ов и то как это будет лежать в памяти (с точностью до байта).
char s[] = {'a', 'b', 'c', '\x0'};
"размер в начале" тут будет совершенно не в тему
-
Ещё вопрос. Почему в си были встроены строки с символом в конце. Для нахождения длины строку требуется перебрать все символы, до конечного символа. Производительности это не прибавляет.
В Си - нет строк - есть только строковые значения (литералы). - почему? - вероятно в той области использования под которую язык проектировался Ричи(системное программирование).. вполне хватало этой концепции... и они не стали плодить лишнюю сущность.
-
Они ведь писали не только ос и драйвера, но и программы к ней, удобно когда систему можно написать на одном языке. Один язык, один компилятор. Если взять в пример linux, всё написано на си, как ядро, так и прикладные библиотеки, прикладные программы: sed, wget, gtk тысячи их.
Думаю врятли создатели языка, полагали, что на нём будут писать ядро в 10 млн строк.
Чем отличается язык для системного программирования и для прикладного? Помню в turbo pascal был оператор interupt. Что. в си, что в паскале нужен асм для доступа к железу, нужно создать некую прослойку. После чего асм не нужен.
-
Когда говорят, что язык подходит для системного программирования, что под этим подразумевают? Что в си, паскаль есть асм и указатели, и одинаковые операторы, циклы, ветвления и т.д Допустим если бы создатели языка взяли pascal для реализации unix, они бы смогли создать эту систему?
-
Они ведь писали не только ос и драйвера, но и программы к ней, удобно когда систему можно написать на одном языке. Один язык, один компилятор. Если взять в пример linux, всё написано на си, как ядро, так и прикладные библиотеки, прикладные программы: sed, wget, gtk тысячи их.
Думаю врятли создатели языка, полагали, что на нём будут писать ядро в 10 млн строк.
Чем отличается язык для системного программирования и для прикладного? Помню в turbo pascal был оператор interupt. Что. в си, что в паскале нужен асм для доступа к железу, нужно создать некую прослойку. После чего асм не нужен.
вы слишком многого хотите от R&K- они не боги, но обычные практики... как вы думаете.. а предполагали ли создатели PHP- что его будут совать в любую щель буквально через 4 года.. и вправе ли требовать от них "изысканного" дизайна...
-
Ещё вопрос. Почему в си были встроены строки с символом в конце. Для нахождения длины строку требуется перебрать все символы, до конечного символа. Производительности это не прибавляет.
ЕМНИП. Это особенность тех компьютеров, для которых разрабатывался Си -- PDP-7, PDP-11. Там были машинные команд для манипуляции со строками, заканчивающимися нулём.
Можно было пойти по стопам basic, bstr строки длина строки хранится в байте или в 4 байтах, к примеру в реализациях delphi, visual basic, object pascal.
Бейсик тогда был, но никакого BSTR в нём ещё не было, как не было и винды, где эти BSTR появились в visual basic.
Так же не было и паскалей с дельфями. Си разрабатывался в конце 60-х..начале 70-х годов, даже раньше паскаля...
В pascale вирт сразу заложил такие строки, но они были ограничены 1 байтом, но что мешало раширить их в си 2 или 4 байтами.
Подход сей был в том, что бы сделать язык максимально близким к железу (тогдашнему) при сохранении хоть какого-то более-менее высокого уровня. То есть вот такой был выбран компромис.
-
Они ведь писали не только ос и драйвера, но и программы к ней, удобно когда систему можно написать на одном языке. Один язык, один компилятор. Если взять в пример linux, всё написано на си, как ядро, так и прикладные библиотеки, прикладные программы: sed, wget, gtk тысячи их.
Думаю врятли создатели языка, полагали, что на нём будут писать ядро в 10 млн строк.
Чем отличается язык для системного программирования и для прикладного? Помню в turbo pascal был оператор interupt. Что. в си, что в паскале нужен асм для доступа к железу, нужно создать некую прослойку. После чего асм не нужен.
вы слишком многого хотите от R&K- они не боги, но обычные практики... как вы думаете.. а предполагали ли создатели PHP- что его будут совать в любую щель буквально через 4 года.. и вправе ли требовать от них "изысканного" дизайна...
Я не обвиняю и не требую. Мне просто интересно почему было сделано так, а не эдак.
-
Когда говорят, что язык подходит для системного программирования, что под этим подразумевают? Что в си, паскаль есть асм и указатели, и одинаковые операторы, циклы, ветвления и т.д Допустим если бы создатели языка взяли pascal для реализации unix, они бы смогли создать эту систему?
У фирмы Cray была ОС для их суперкомпьютеров, написанная на паскале. Правда, потом перешли на Юникс...
Первые версии винды и макоси были написаны на паскале. Правда, потом перешли на си...
Была советская юникс-подобная OS KRONOS, написанная на модуле-2. Правда, это не совсем паскаль...
Ещё была какая-то Domain/OS (http://en.wikipedia.org/wiki/Domain/OS) -- юникс-подобная система на паскале написанная...
Да куча таких ОС было...
-
Когда говорят, что язык подходит для системного программирования, что под этим подразумевают? Что в си, паскаль есть асм и указатели, и одинаковые операторы, циклы, ветвления и т.д Допустим если бы создатели языка взяли pascal для реализации unix, они бы смогли создать эту систему?
У фирмы Cray была ОС для их суперкомпьютеров, написанная на паскале. Правда, потом перешли на Юникс...
Первые версии винды и макоси были написаны на паскале. Правда, потом перешли на си...
Была советская юникс-подобная OS KRONOS, написанная на модуле-2. Правда, это не совсем паскаль...
Ещё была какая-то Domain/OS (http://en.wikipedia.org/wiki/Domain/OS) -- юникс-подобная система на паскале написанная...
Да куча таких ОС было...
Ух ты я и не знал. Интересно почему, макос и виндовс, переписали на си? Производительность, проблемы с компилятороми, маркетинг?
Если убрать мифы о си, то язык си был компромиссом, между производительностью и высокоуровневостью.
-
Когда говорят, что язык подходит для системного программирования, что под этим подразумевают? Что в си, паскаль есть асм и указатели, и одинаковые операторы, циклы, ветвления и т.д Допустим если бы создатели языка взяли pascal для реализации unix, они бы смогли создать эту систему?
У фирмы Cray была ОС для их суперкомпьютеров, написанная на паскале. Правда, потом перешли на Юникс...
Первые версии винды и макоси были написаны на паскале. Правда, потом перешли на си...
MacOS (точнее тогда еще System) никогда не была написана на паскале. Она была написана на чистом асме. А вот API был паскалевский (и доки долгое время тоже вызовы системных функций в паскаль-нотации описывали, даже после того как перешли с асма на Си).
-
Если убрать мифы о си, то язык си был компромиссом, между производительностью и высокоуровневостью.
А что тут такого? - эта мысль приводится (правда в декларативной форме) практически в любом , более менее внятном руководстве... или обзоре....
-
MacOS (точнее тогда еще System) никогда не была написана на паскале. Она была написана на чистом асме. А вот API был паскалевский (и доки долгое время тоже вызовы системных функций в паскаль-нотации описывали, даже после того как перешли с асма на Си).
Возможно. В какой-то кние я прочитал, как написали эту System и оказалось, что она заняла аж целых 128 кБт, при том что ПЗУ на тех первых маках было 64 кБт. Что бы уместить эту систему в двое меньшем объёме, эппловцам пришлось сотворить чудеса повторного использования кода...
Да, скорее всего речь и правда об ассемблере.
А может там был фортовский подход -- шитый код и всё такое? )))
-
MacOS (точнее тогда еще System) никогда не была написана на паскале. Она была написана на чистом асме. А вот API был паскалевский (и доки долгое время тоже вызовы системных функций в паскаль-нотации описывали, даже после того как перешли с асма на Си).
Возможно. В какой-то кние я прочитал, как написали эту System и оказалось, что она заняла аж целых 128 кБт, при том что ПЗУ на тех первых маках было 64 кБт. Что бы уместить эту систему в двое меньшем объёме, эппловцам пришлось сотворить чудеса повторного использования кода...
Да, скорее всего речь и правда об ассемблере.
А может там был фортовский подход -- шитый код и всё такое? )))
Да нет, там таки просто асм был. А паскаль-API был взят из за Лизы. Ну и прикладное ПО писалось на Паскале частенько. См. исходники первого фотошопа например.