Oberon space
General Category => Общий раздел => Тема начата: kkkk от Декабрь 13, 2013, 12:52:35 pm
-
Возвращаясь к нашим баранам. Зачем иметь локальные переменные в отдельной декларативной части? Есть какие-нибудь формальные причины, кроме "здесь так заведено"?
В первую очередь это самое простое из достаточных решений, вдобавок, близкое к генерируемому коду.
Стимулирует писать обозримые процедуры. Кстати, встроенные процедуры смазывают это, но нужны по другой причине.
Простое средство от дополнительных ошибок, связанных с перекрытием.
int i = 0;
func() {
a = i;
{
int i = 1;
b = i;
}
}
или ещё хуже
int i = 0;
func() {
a = i;
int i = 1;
b = i;
}
Дополнительное веселье может начаться, если в языке есть перегрузка функций, тогда может не спасти и типизация при разнотиповом перекрытии.
-
В первую очередь это самое простое из достаточных решений,
Отдельная секция - самое "просто" решение? Издеваешься? Самое простое - это как в питоне:
def func():
i = 0
Проще не могу придумать.
вдобавок, близкое к генерируемому коду.
Не понимаю о чем ты... Вот мне надо генерировать жабаскрипт... ;)
Стимулирует писать обозримые процедуры.
Ой неправда. Достаточно глянуть код самого Мэтра. Зато вот дублирование названия процедуры в конце - да, очень понятно. Как раз на случай необозримых процедур.
Простое средство от дополнительных ошибок, связанных с перекрытием.
Перекрытие и отдельная секция VAR совершенно отртогональные вещи. Твой сишный пример замечательно переписывается на обероне с помощью локальных процедцур. И с теми же потенциальными проблемами. Про которые Вирт, кстати, в репорте молчит. Видимо не счиатает важным. Т.е., про область видимости он упоминает, а вот про то как разрешаются конфликты в случае перекрытия - молчит.
-
Самое простое - это как в питоне
А как в питоне?
-
Самое простое - это как в питоне
А как в питоне?
Я ж привел код:
def func():
i = 0
Функция func и ее локальная переменная i. Если месье любит глобальные переменные - пусть страдает и пишет вот так:
i = 0
def func():
global i
i = 1
Т.е., явно декларирует, что хочет импортировать в локальную область глобальную переменную. А по умолчанию - все локально. И с минимумом усилий для нормальных людей, которые не любят глобальные переменные. И это правильно.
-
Это в смысле так же, как в PHP?
Сочетание директивы global с автоматическим созданием переменной при упоминании?
При котором редко пишуший на языке человек может потратить час на то, чтобы понять, почему это не работает?
Идея явно указывать global неплоха, но становится ужасной, если для локальных нет явного объявления, что переменная создаётся впервые.
-
Это в смысле так же, как в PHP?
Не знаю - повезло, не писал :)
Сочетание директивы global с автоматическим созданием переменной при упоминании?
При котором редко пишуший на языке человек может потратить час на то, чтобы понять, почему это не работает?
Идея явно указывать global неплоха, но становится ужасной, если для локальных нет явного объявления, что переменная создаётся впервые.
Да, кажется страшным. И в большинстве языков хоть что-то есть для обозначения декларации новой переменной (var, let). Но на практике - не сталкивался ни с какими проблемами. Довольно много приходится с питоном иметь дело - вот именно с этим проблем никогда не было. Возможно, как я уже говорил, зависит от стиля пишущего. Я практически не использую глобальные переменные, и у меня нет привычки менять переменные из внешнего скопа во внутреннем (тоже моветон само по себе). Так что все хорошо, проверено лично :)
-
и у меня нет привычки менять переменные из внешнего скопа во внутреннем (тоже моветон само по себе)
Не понял. Какая тогда польза от внутреннего скопа? Или речь опять про функциональные языки?
-
и у меня нет привычки менять переменные из внешнего скопа во внутреннем (тоже моветон само по себе)
Не понял. Какая тогда польза от внутреннего скопа? Или речь опять про функциональные языки?
Не понял. Зачем менять внешнее состояние во внутреннем скопе? Внутренний скоп получил данные, обработал (при этом завел кучу локальных переменных, если надо) и вернул результат. Вход -> выход. Просто и понятно. Конечно удобно иметь внешний "контекст", чтоб не таскать все через аргументы (вход). Поэтому идем на уступку - внешний скоп виден внутреннему. Но вот так вот брать и откровенно гадить во внешнем скопе брутальными присваиваниями - не, этого нам не надо. Возвращаясь к питоновскому примеру:
i = 0
def func():
global i
i = 1
Вот это откровенно хреновый код. И тот, кто такое пишет, должен страдать. По-нормальному должно быть переписано вот так:
i = 0
def func():
return 1
i = func()
-
Кажется понял. Для тебя глобальный скоп и внешний одно и то же?
-
Кажется понял. Для тебя глобальный скоп и внешний одно и то же?
Разница между областями видимости, глобальной для всех процедур, и внешней для конкретной процедуры, -- непринципиальна...
-
Под внешним я подразумевал только 1 родительский уровень:
var a
scope1:{
var a1
scope2:{
var a2
scope3:{
var a3
}
}
}
Для scope3 это одна переменная a2
-
Отдельная секция - самое "просто" решение? Издеваешься? Самое простое - это как в питоне:
def func():
i = 0
У динамических языков своя логика, с моей точки зрения не самая лучшая. Я имел ввиду самое простое для реализации компилятора из достаточно хороших для пользователей языка. Для статически типизированного императивного языка то, что в Питоне ни достаточно хорошо, ни достаточно просто.
вдобавок, близкое к генерируемому коду.
Не понимаю о чем ты... Вот мне надо генерировать жабаскрипт... ;)
естественно, речь о применении Оберона по назначению
Стимулирует писать обозримые процедуры.
Ой неправда. Достаточно глянуть код самого Мэтра. Зато вот дублирование названия процедуры в конце - да, очень понятно. Как раз на случай необозримых процедур.
Правда. Стимулирует - не значит обязует, и то - хлеб. Дублирование названия в конце при сколь-нибудь вменяемом форматировании не несет существенной пользы для обзора необъятной процедуры. А вот простому парсеру языка восстановиться после ошибки в коде, особенно при наличии встроенных процедур в языке, помогает.
Простое средство от дополнительных ошибок, связанных с перекрытием.
Перекрытие и отдельная секция VAR совершенно отртогональные вещи. Твой сишный пример замечательно переписывается на обероне с помощью локальных процедцур. И с теми же потенциальными проблемами. Про которые Вирт, кстати, в репорте молчит. Видимо не счиатает важным. Т.е., про область видимости он упоминает, а вот про то как разрешаются конфликты в случае перекрытия - молчит.
Не ортогональные. Не переписываются примеры на аналогичные с локальными процедурами, а главное в примере и нет никаких локальных процедур. В первую очередь с отдельной секцией очевидно, что если какая-то переменная в ней есть - она именно локальна, и не надо выискивать, есть ли где в мешанине коде объявление/перекрытие
-
Под внешним я подразумевал только 1 родительский уровень:
var a
scope1:{
var a1
scope2:{
var a2
scope3:{
var a3
}
}
}
Для scope3 это одна переменная a2
Но ведь в scope3 доступны также и a1, и даже a. Так какая разница?
-
Вопрос не в том что доступно, а в том, что можно изменять в каждом скопе.
Проблемы с изменением глобального скопа известны и понятны. Но проблемы ведь не в том, что внутренний скоп изменяет переменные внешнего.
Вложенные процедуры, замыкания, локальные переменные в циклах (да и любые локальные переменные в блоках). Все это имеет смысл только при изменении переменных внешнего скопа.
-
Пример кода:
a = 1
b = 2
do -- обмен переменных значениями
local temp
temp = a
a = b
b = temp
end
Какие тут могут быть проблемы?
-
Кажется понял. Для тебя глобальный скоп и внешний одно и то же?
Прежде всего, речь, конечно, о глобальном скопе. Изменение некоего внешнего скопа вещь большее спорная. Но я также склоняюсь к запрету. Ради однообразия. И опять же по опыту использования питона (запрещено) и js (разрешено).
-
У динамических языков своя логика, с моей точки зрения не самая лучшая.
Динамичность здесь постольку поскольку. Никто не мешает сделать питоновский стиль объявление локальных переменных при полной статике (очень хочу пропробовать лично ;)
Я имел ввиду самое простое для реализации компилятора из достаточно хороших для пользователей языка.
То, что мы наблюдает в обероне-07 в плане простоты компилятора - это уже давно "проще, чем надо". Впрочем, если таки дойдет до "избавления от секции VAR" - обязательно поделюсь насколько это "сложно".
естественно, речь о применении Оберона по назначению
Хе-хе. Мне бы все-таки хотелось увидеть более ширпотребное применение оберона (пусть и в измененном виде) - за пределами FPGA (при всем восхищении от решения на FPGA).
А вот простому парсеру языка восстановиться после ошибки в коде, особенно при наличии встроенных процедур в языке, помогает.
Во-первых, имя процедуры ближе к семантическрому анализу, чем к классическому парсеру (у которого на выходе AST). Так что это еще надо постараться, чтобы заиспользовать имя процедуры для восстановления парсера.
Во-вторых, синтаксис с жестким форматированием (опять питон) в этом смысле все равно выглядит намного более удобным (тупо ищем следующую строку с заданным отступом).
В первую очередь с отдельной секцией очевидно, что если какая-то переменная в ней есть - она именно локальна, и не надо выискивать, есть ли где в мешанине коде объявление/перекрытие
Почему сразу "мешанина кода"? У нас же ш культурная процедура на < 10 строк. Естественно, что если выше по коду стоит "переменная = значение", то это переменная локальная. Ну или если совсем страшно, то пусть будет "var переменная = значение". Надобность в отдельной секции все равно не возникает. Особенно если постараться не оглядываться на привычки.
-
У динамических языков своя логика, с моей точки зрения не самая лучшая.
Динамичность здесь постольку поскольку. Никто не мешает сделать питоновский стиль объявление локальных переменных при полной статике (очень хочу пропробовать лично ;)
Это не совсем так. При неявной типизации изменение типа функции, которая инициализирует переменную можно получить неожиданный результат при сохранении компилируемости. К примеру, с INTEGER на REAL при проверке на равенство. Это вполне согласуется с динамическими языками, но статические теряют в контроле.
Я имел ввиду самое простое для реализации компилятора из достаточно хороших для пользователей языка.
То, что мы наблюдает в обероне-07 в плане простоты компилятора - это уже давно "проще, чем надо". Впрочем, если таки дойдет до "избавления от секции VAR" - обязательно поделюсь насколько это "сложно".
Не валите все в одну кучу. Проще чем надо не имеет отношения к традиционной паскалевской секции VAR. Когда будете делиться о "сложности" избавления не забудьте, что я говорил о достаточно простом решении при достаточном удобстве для пользователя-программиста. Питоновский вариант достаточным не считаю.
естественно, речь о применении Оберона по назначению
Хе-хе. Мне бы все-таки хотелось увидеть более ширпотребное применение оберона (пусть и в измененном виде) - за пределами FPGA (при всем восхищении от решения на FPGA).
Тут у меня возникла ассоциация с гламурной ведущей с канала "Дождь", задавшей вопрос Жоресу Алферову, зачем нужна российская электронная промышленность, если она не производит iPhone. Использование Оберона по назначению в том контексте - это компиляция в машинный код, не более.
А вот простому парсеру языка восстановиться после ошибки в коде, особенно при наличии встроенных процедур в языке, помогает.
Во-первых, имя процедуры ближе к семантическрому анализу, чем к классическому парсеру (у которого на выходе AST). Так что это еще надо постараться, чтобы заиспользовать имя процедуры для восстановления парсера.
Во-вторых, синтаксис с жестким форматированием (опять питон) в этом смысле все равно выглядит намного более удобным (тупо ищем следующую строку с заданным отступом).
При построении самодостаточного парсера для Оберона нужно использовать семантический анализ не только касаемо имени в конце процедуры, неужели это сюрприз? А ведь это свойство языка послужило даже одним из эпизодов драмы, время от времени всплывающей на оберонкоре.
Почему сразу "мешанина кода"? У нас же ш культурная процедура на < 10 строк. Естественно, что если выше по коду стоит "переменная = значение", то это переменная локальная. Ну или если совсем страшно, то пусть будет "var переменная = значение". Надобность в отдельной секции все равно не возникает. Особенно если постараться не оглядываться на привычки.
По сравнению с обероновским всё по полочкам, это будет мешанина даже в 10 строках. К тому же их никто не гарантирует, их еще добиваться надо, не забывайте про длительное сопровождение многими людьми. Вдобавок, иное искусственное разбиение на излишне малые процедуры бывает и хуже для понимания, чем уместный 40-строчник.
-
При неявной типизации изменение типа функции, которая инициализирует переменную можно получить неожиданный результат при сохранении компилируемости. К примеру, с INTEGER на REAL при проверке на равенство. Это вполне согласуется с динамическими языками, но статические теряют в контроле.
Пример несколько надуман. Однако тип можно оставить, почему нет. Отдельная секция для этого все равно не нужна:
i: int = 123
Не валите все в одну кучу. Проще чем надо не имеет отношения к традиционной паскалевской секции VAR.
Да, не имеет. По моему мнению секция VAR больше из области "здесь так заведено". Когда-то на заре ЯП было принято расписывать в какую ячейку какая переменная пойдет... А КАПС хорошо смотрелся на монохромном (два цвета) мониторе...
Когда будете делиться о "сложности" избавления не забудьте, что я говорил о достаточно простом решении при достаточном удобстве для пользователя-программиста. Питоновский вариант достаточным не считаю.
Сформулируй точнее, что является достаточным.
Хе-хе. Мне бы все-таки хотелось увидеть более ширпотребное применение оберона (пусть и в измененном виде) - за пределами FPGA (при всем восхищении от решения на FPGA).
Тут у меня возникла ассоциация с гламурной ведущей с канала "Дождь", задавшей вопрос Жоресу Алферову, зачем нужна российская электронная промышленность, если она не производит iPhone. Использование Оберона по назначению в том контексте - это компиляция в машинный код, не более.
Ну вот не надо передергивать. Речь не о чем-то попсовом, а о промышленном и полезном. Виртовские игры с FPGA имеют сугубо академический интерес (а самому Вирту оно вообще интересно, потому что интересно). Выхлоп в виде общечеловеческого блага (не айфона, а глобального) очень косвенный - кто-то под впечатлением от работы Вирта сделает таки что-то практически полезное - будь то новый процессор или компилятор.
При построении самодостаточного парсера для Оберона нужно использовать семантический анализ не только касаемо имени в конце процедуры, неужели это сюрприз? А ведь это свойство языка послужило даже одним из эпизодов драмы, время от времени всплывающей на оберонкоре.
Хорошо, у тебя есть сведения, что виртовский (или какой-то другой) компилятор использует эту особенность для восстановления после ошибок? Или это все-таки было придумано по ходу дела?
По сравнению с обероновским всё по полочкам, это будет мешанина даже в 10 строках.
Начнем с того, что строчек будет уже не 10, а 8 - за счет отсутствия VAR. Где там можно чего-то намешать - не представляю. Я ж говорю - привычка. Желание иметь отдельную одну полку. Хотя с тремя крючками удобнее.
-
...сведения, что виртовский (или какой-то другой) компилятор использует эту особенность для восстановления после ошибок? Или это все-таки было придумано по ходу дела?
Я точно помню, что читало про это где-то в 2006-2008 годах.
-
...сведения, что виртовский (или какой-то другой) компилятор использует эту особенность для восстановления после ошибок? Или это все-таки было придумано по ходу дела?
Я точно помню, что читало про это где-то в 2006-2008 годах.
Исходники же есть. Посмотрите.
-
...сведения, что виртовский (или какой-то другой) компилятор использует эту особенность для восстановления после ошибок? Или это все-таки было придумано по ходу дела?
Я точно помню, что читало про это где-то в 2006-2008 годах.
Свою стратегию восстановления после ошибок Вирт неплохо описал в "Построении компиляторов" (см. п.7.9 Устранение синтаксических ошибок). Правда, среди точек синхронизации он не называет терминаторы процедур (это конечно не означает, что на практике он никогда их не использует для восстановления).
-
Свою стратегию восстановления после ошибок Вирт неплохо описал в "Построении компиляторов" (см. п.7.9 Устранение синтаксических ошибок).
Да, это я читал. Вопрос на самом деле не стоит того, чтобы чего-то там искать в исходниках. Используются именованные концы или не используются... Все равно это атавизм, без которого можно обойтись (в том числе и в деле восстановления от синтаксических ошибок).
-
По сравнению с обероновским всё по полочкам, это будет мешанина даже в 10 строках.
Вот, кстати, хорошая иллюстрация (обсуждалась в курилке): http://www.inf.ethz.ch/personal/wirth/ProjectOberon/Sources/Checkers.Mod.txt
Обрати внимание на то где объявляется переменная цикла, а где сам цикл. Зачем???
-
vlad, это глобальная переменная. Очевидно, что она будет использоваться далеко от объявления. VAR тут совершенно не виноват.
-
vlad, это глобальная переменная. Очевидно, что она будет использоваться далеко от объявления. VAR тут совершенно не виноват.
В данном случае её глобальность никак не проявляется.
-
vlad, это глобальная переменная. Очевидно, что она будет использоваться далеко от объявления. VAR тут совершенно не виноват.
В данном случае её глобальность никак не проявляется.
А причем тут глобальность - переменная используется в секции инициализации(телу) модуля, для которой данная переменная локальна. Единственное, что можно было бы сделать - как в старших Оберонах - произвольное расположение секций, тогда секцию VAR с этой переменной можно было бы прижать к телу модуля
-
2 valexey:
В смысле? Ты про то, что она используется в одном месте?
Ну мне тоже не нравится, что переменная цикла объявляется в VAR. Даже тему создавал по этому поводу.
Но разве это аргумент против VAR?
-
При неявной типизации изменение типа функции, которая инициализирует переменную можно получить неожиданный результат при сохранении компилируемости. К примеру, с INTEGER на REAL при проверке на равенство. Это вполне согласуется с динамическими языками, но статические теряют в контроле.
Пример несколько надуман. Однако тип можно оставить, почему нет. Отдельная секция для этого все равно не нужна:
i: int = 123
Для кого надуман, для кого - бытовуха. Любите валить всё в одну кучу, прям как переменные и код. Эта часть ответа был о реализации в питоне и связи с динамической логикой, а не о том, что для явного задания типа нужна отдельная секция.
Да, не имеет. По моему мнению секция VAR больше из области "здесь так заведено". Когда-то на заре ЯП было принято расписывать в какую ячейку какая переменная пойдет... А КАПС хорошо смотрелся на монохромном (два цвета) мониторе...
Однажды проходя мимо коллеги, внезапно увидел знакомые "BEGIN - END". Когда я спросил его, что это, он ответил, что VHDL, а ключевые слова хоть и не регистрозависимые, но заглавными буквами ему удобней. Я посмеялся, вспомнив широко известную в узких кругах спецолимпиаду. Человеку 24 года, об Обероне не слышал, программирует на Си.
Питоновский вариант достаточным не считаю.
Сформулируй, что является достаточным.
Единое поле видимости для всей функции, очевидность принадлежности, логичность представления. Увы, кроме 1-го, всё достаточно субъективно, особенно 3-й, так что попытки найти идеальный общий знаменатель будут бесплодны.
Хорошо, у тебя есть сведения, что виртовский (или какой-то другой) компилятор использует эту особенность для восстановления после ошибок? Или это все-таки было придумано по ходу дела?
Как минимум тот, что пишу я(свет скорей всего не увидит), с остальными не разбирался. Боже упаси меня придумывать по ходу дела для вашего развлечения.
Начнем с того, что строчек будет уже не 10, а 8 - за счет отсутствия VAR. Где там можно чего-то намешать - не представляю. Я ж говорю - привычка. Желание иметь отдельную одну полку. Хотя с тремя крючками удобнее.
10 строк кода - это 10 строк кода, переменные отдельно. Глянул сейчас на свой код - много функций побольше 10 строк, и самое сложное будет при их дроблении - это выдумывание адекватных названий для этих искусственных лепёшек, и сбор их в единый контекст.
-
По сравнению с обероновским всё по полочкам, это будет мешанина даже в 10 строках.
Вот, кстати, хорошая иллюстрация (обсуждалась в курилке): http://www.inf.ethz.ch/personal/wirth/ProjectOberon/Sources/Checkers.Mod.txt
Обрати внимание на то где объявляется переменная цикла, а где сам цикл. Зачем???
Откуда мне знать? Там, очевидно, напрашивается процедура с кодом инициализации, в которой эта переменная и должна быть объявлена. Видимо автор решил, что для такого модуля можно не заморачиваться.
-
http://www.inf.ethz.ch/personal/wirth/ProjectOberon/Sources/Checkers.Mod.txt
Обрати внимание на то где объявляется переменная цикла, а где сам цикл. Зачем???
Не вижу никакого криминала. Вот если бы переменная i экспортировалась для чтения и записи, тогда да. А так, это внутренние дела суверенного модуля в центре Европы. :) (начитался новостей :) )
-
По сравнению с обероновским всё по полочкам, это будет мешанина даже в 10 строках.
Вот, кстати, хорошая иллюстрация (обсуждалась в курилке): http://www.inf.ethz.ch/personal/wirth/ProjectOberon/Sources/Checkers.Mod.txt
Обрати внимание на то где объявляется переменная цикла, а где сам цикл. Зачем???
Откуда мне знать? Там, очевидно, напрашивается процедура с кодом инициализации, в которой эта переменная и должна быть объявлена. Видимо автор решил, что для такого модуля можно не заморачиваться.
Вот такой код без лишних заморочек и является говнокодищем...
-
vlad, это глобальная переменная.
Дык!!! Именно эту проблему я и пытаюсь тут донести - формально глобальная переменная, а по факту использования - локальная переменная цикла. Вот такое вот несоответствие декларации и фактического использования на простом программерском языке называется "говнокод".
Очевидно, что она будет использоваться далеко от объявления. VAR тут совершенно не виноват.
Э... в смысле не виноват? А кто тогда виноват?
-
А причем тут глобальность - переменная используется в секции инициализации(телу) модуля, для которой данная переменная локальна. Единственное, что можно было бы сделать - как в старших Оберонах - произвольное расположение секций, тогда секцию VAR с этой переменной можно было бы прижать к телу модуля
Это не единственное, что можно сделать :) Можно набраться критического мышления и смелости и сказать, что секция VAR вообще ненужна, а локальные переменные объявлять по мере надобности, максимально ограничивая их область видимости.
-
Но разве это аргумент против VAR?
Я даже и не знаю как прокомментировать... "GOTO легко приводит к говнокоду - но разве это аргумент против GOTO?"
-
Пример несколько надуман. Однако тип можно оставить, почему нет. Отдельная секция для этого все равно не нужна:
i: int = 123
Для кого надуман, для кого - бытовуха.
Гы. На каком языке ты писал и вляпался (неоднократно, раз это бытовуха) вот в такое?
Однажды проходя мимо коллеги, внезапно увидел знакомые "BEGIN - END". Когда я спросил его, что это, он ответил, что VHDL, а ключевые слова хоть и не регистрозависимые, но заглавными буквами ему удобней. Я посмеялся, вспомнив широко известную в узких кругах спецолимпиаду. Человеку 24 года, об Обероне не слышал, программирует на Си.
Ну и что? Я на SQL тоже пишу капсом ключевые слова. Потому что пишу их в фаре без подсветки. Это говорит лишь о том, что у человека нет нормального инструмента. Например, в силу относительной ненужности (как мне - раз в месяц написать несколько строк на SQL).
Вот когда человек, имея язык без VAR и без паскального прошлого, начнет переменные лепить в одну кучку - тогда это будет интересно. Я, возможно, даже соглашусь списать это на устройство мозгов конкретного индивидуума.
Сформулируй, что является достаточным.
Единое поле видимости для всей функции, очевидность принадлежности, логичность представления. Увы, кроме 1-го, всё достаточно субъективно, особенно 3-й, так что попытки найти идеальный общий знаменатель будут бесплодны.
Да, это печально.
Хорошо, у тебя есть сведения, что виртовский (или какой-то другой) компилятор использует эту особенность для восстановления после ошибок? Или это все-таки было придумано по ходу дела?
Как минимум тот, что пишу я(свет скорей всего не увидит)
Так. Понятно. ТруЪ оберонщик детектед. Опять какие-то секретные репозитории и разработки... Можно хотя бы в общих словах - что за компилятор (как компиляторостроитель компиляторостроителю)?
-
Там, очевидно, напрашивается процедура с кодом инициализации, в которой эта переменная и должна быть объявлена. Видимо автор решил, что для такого модуля можно не заморачиваться.
Именно. Да, можно сделать код лучше и имея VAR, но этого не делается. Потому что вступает в силу мой любимый тезис: "на любом языке пишут так, как короче, а не как правильнее". Поэтому мне и непонятно вот это стремление сохранить VAR любой ценой только потому, что и с ним можно писать хороший код. Трудно, но ведь можно...
-
Вот такой код без лишних заморочек и является говнокодищем...
Да, там в одном этом маленьком файле можно наковырять несколько плохих штук... Переменная checks - ничем не лучше. Волшебные циферки - 9, 17...
-
Но разве это аргумент против VAR?
Я даже и не знаю как прокомментировать... "GOTO легко приводит к говнокоду - но разве это аргумент против GOTO?"
Легко ты аргументами манипулируешь.
Как раз отсутствие VAR легко приводит к говнокоду, т.к. место объявления переменной ни чем не ограничено. VAR - это ограничение. Также как отсутствие GOTO - это ограничение.
В обероне переменная объявляется в начале скопа. Есть всего три уровня скопов:
1. Модуль
2. Процедура
3. Вложенная процедура
С какого перепуга скоп должен делиться на две части этими произвольными объявлениями?
scope:
int a;
// до сих в скопе одна переменная a
int b;
// а тут еще b добавилась
end;
Такие скопы даром не сдались.
Если ты хочешь иметь произвольные вложенные скопы (по твоим сообщениям складывается такое впечатление), то к VAR это уже не имеет отношения.
scope1:
int a;
scope2:
int b;
end;
end;
Так ты произвольные объявления хочешь или скопы?
-
Как раз отсутствие VAR легко приводит к говнокоду, т.к. место объявления переменной ни чем не ограничено.
Ты сам согласился, что виртовский код с отделением переменной цикла от цикла некошерен. Не? Я всего лишь предлагаю простое решение этой проблемы. Причем не добавлением новых фич в язык , а переосмыслением старой - выкинуть VAR в существующем виде и добавить объявление переменных "по месту".
С какого перепуга скоп должен делиться на две части этими произвольными объявлениями?
Скоп не делится. Он уточняется по ходу дела. В чем проблема-то? Ну хоть один аргумент против, кроме абстрактных "усложнений компилятора" и "мешанина в коде"? Можно пример мешанины, но такой, что ее нельзя переписать в более короткий и понятный код (без секции VAR). Потому как примеров, когда секция VAR только мешает - вагон, включая код Вирта с переменной цикла в глобальном скопе.
Так ты произвольные объявления хочешь или скопы?
Во-первых, произвольные объявления. После чего операторные скопы (циклы, IF'ы) возникают как естественное дополнение.
-
Скоп не делится. Он уточняется по ходу дела.
Замечу, что это прямая аналогия существующего порядка объявления процедур. Ты не можешь использовать в коде процедуры еще не объявленную процедуру. И никто по этому поводу не бегает и не кричит - как же так, скоп делится. И никто не заставляет объявить все процедуры заранее в отдельной секции PROCEDURES...
-
Скоп не делится. Он уточняется по ходу дела.
Замечу, что это прямая аналогия существующего порядка объявления процедур. Ты не можешь использовать в коде процедуры еще не объявленную процедуру. И никто по этому поводу не бегает и не кричит - как же так, скоп делится. И никто не заставляет объявить все процедуры заранее в отдельной секции PROCEDURES...
Более того, такую возможность Вирт специально выпилил убрав forward declarations в Обероне для процедур.
-
Вообще многие штуки в Обероне не следует воспринимать как некие вечные ценности, и как нечто за чем стоит Великий Замысел. Там очень много ситуационного, которое логично и понятно становится в контексте конкретно Оберон-ОС и Оберон-компа. Ну, например в этом контексте становится очевидным почему Вирт выпилил из Оберона массивы с длиной неизвестной на этапе компиляции. Абсолютно логичный ход вообще то :-)
-
В общем vlad смотри: https://github.com/id-Software/DOOM-3-BFG/blob/master/neo/framework/CmdSystem.cpp
Православные сишники внезапно объявляют переменные всегда (за редким исключением) в начале блока. Вот же парадокс! И с чего это им вздумалось VAR эмулировать?
Ты сам согласился, что виртовский код с отделением переменной цикла от цикла некошерен. Не?
В одном единственном случае. Конкретно в цикле FOR считаю что переменная не должна объявляться вообще. Т.е. это узкое частное решение не делающее ничего кроме очистки VAR от мусора. А ты говоришь о совершенно других вещах.
-
В общем vlad смотри: https://github.com/id-Software/DOOM-3-BFG/blob/master/neo/framework/CmdSystem.cpp
Православные сишники внезапно объявляют переменные всегда (за редким исключением) в начале блока. Вот же парадокс! И с чего это им вздумалось VAR эмулировать?
Это очень олдовые сишники, пришибленные еще С89, в котором по другму было и нельзя. На С++ перешли с С89, но привычка осталась. При этом С++ там используется чисто как Си89 с классами. (видно по переменным типа commandDef_t *cmd, **prev;)
Можно взять пример посовременней:
https://github.com/llvm-mirror/clang/blob/master/examples/clang-interpreter/main.cpp
https://github.com/llvm-mirror/clang/blob/master/lib/StaticAnalyzer/Checkers/ArrayBoundChecker.cpp
-
А КАПС хорошо смотрелся на монохромном (два цвета) мониторе...
Однажды проходя мимо коллеги, внезапно увидел знакомые "BEGIN - END". Когда я спросил его, что это, он ответил, что VHDL, а ключевые слова хоть и не регистрозависимые, но заглавными буквами ему удобней. Я посмеялся, вспомнив широко известную в узких кругах спецолимпиаду. Человеку 24 года, об Обероне не слышал, программирует на Си.
Раньше часто в разных источниках видел код на VHDL, в основном прописью, и вот сейчас когда вижу код на VHDL строчными буквами -- просто не узнаю этот язык. Так что тут дело привычки. Синдром утёнка, да.
На Аде когда-то тоже писали прописью (а синтаксис VHDL основан на синтаксисе Ады), но сейчас в основном всё же на Аде пишут ключевые слова строчными. То есть можно и перепривыкнуть. Никаких бонусов на самом деле верхний регистр ключевых слов в редакторах кода с подсветкой синтаксиса не даёт.
-
А причем тут глобальность - переменная используется в секции инициализации(телу) модуля, для которой данная переменная локальна. Единственное, что можно было бы сделать - как в старших Оберонах - произвольное расположение секций, тогда секцию VAR с этой переменной можно было бы прижать к телу модуля
Это не единственное, что можно сделать :) Можно набраться критического мышления и смелости и сказать, что секция VAR вообще ненужна, а локальные переменные объявлять по мере надобности, максимально ограничивая их область видимости.
Да не нужны тут никакие смелость и критическое мышление. Достаточно просто других привычек. Тех, в которых просто нет секции VAR, а таких языков сейчас подавляющее большинство.
Так что смелость нужна скорее для отстаивания нужности секции VAR...
-
valexey: Это типа хороший код ты привел? :D
-
Да не нужны тут никакие смелость и критическое мышление. Достаточно просто других привычек. Тех, в которых просто нет секции VAR, а таких языков сейчас подавляющее большинство.
Это довольно странно. Ибо я привык писать как раз в стиле произвольного объявления. В 1С вообще в 99% случаев нет никаких объявлений. Обычно объявление - это первое присваивание.
Но это не значит, что мне нравится такой подход. Особенно в чужом коде.
-
Это очень олдовые сишники, пришибленные еще С89, в котором по другму было и нельзя.
Угу. Сам с этого начинал. Но видимо не успело в привычку перейти. Переход на плюсовые объявления по месту произошел легко и естественно.
-
valexey: Это типа хороший код ты привел? :D
Это типа код который пишут те, кто гарантированно знает язык в полном объеме.
-
Это очень олдовые сишники, пришибленные еще С89, в котором по другму было и нельзя.
Угу. Сам с этого начинал. Но видимо не успело в привычку перейти. Переход на плюсовые объявления по месту произошел легко и естественно.
Кстати, в указанном коде использование typedef для обявления структур тоже неиллюзорно намекает на Си.
https://github.com/id-Software/DOOM-3-BFG/blob/master/neo/framework/CmdSystem.cpp#L46
В случае С++ это абсолютная ненужная дичь.
Ну а в плане качества кода.. Циклы там как раз такие о которых на оберонкоре любят беседовать долгими зимними вечерами:
https://github.com/id-Software/DOOM-3-BFG/blob/master/neo/framework/CmdSystem.cpp#L156
https://github.com/id-Software/DOOM-3-BFG/blob/master/neo/framework/CmdSystem.cpp#L386
https://github.com/id-Software/DOOM-3-BFG/blob/master/neo/framework/CmdSystem.cpp#L469
-
В общем vlad смотри: https://github.com/id-Software/DOOM-3-BFG/blob/master/neo/framework/CmdSystem.cpp
Православные сишники внезапно объявляют переменные всегда (за редким исключением) в начале блока. Вот же парадокс! И с чего это им вздумалось VAR эмулировать?
Можно, ещё, посмотреть в исходники ReactOS и увидеть то же самое.
-
А причем тут глобальность - переменная используется в секции инициализации(телу) модуля, для которой данная переменная локальна. Единственное, что можно было бы сделать - как в старших Оберонах - произвольное расположение секций, тогда секцию VAR с этой переменной можно было бы прижать к телу модуля
Это не единственное, что можно сделать :) Можно набраться критического мышления и смелости и сказать, что секция VAR вообще ненужна, а локальные переменные объявлять по мере надобности, максимально ограничивая их область видимости.
В Модуле-3 секция VAR может предшествовать блоку BEGIN END, находящемуся в любом месте, а также перед FOR - это по репорту, по факту - перед любым блочным оператором, и даже вообще не объявляться, первое присваивание и определит тип переменной, но это явно плохой подход.
Секция VAR заставляет продумывать решение, остальные должны страдать
-
Весь этот спор по уровню и осмысленности похож на то, если бы вдруг кому-то вздумалось спорить что лучше packed формат пикселей или же planar? :-)
YUV formats fall into two distinct groups, the packed formats where Y, U (Cb) and V (Cr) samples are packed together into macropixels which are stored in a single array, and the planar formats where each component is stored as a separate array, the final image being a fusing of the three separate planes.
Причем спор такой, что типа нужно решить кто из них кошерней, а другой выпилить нафиг раз и навсегда.
Так вот - реальность она другая, в реальности в некоторых случаях planar лучше, а в некоторых packed. А в некоторых смесь (скажем YUY2). Зависит от того, какие операции чаще будем делать вот с этим вот изображением. Таким образом нужно иметь возможность использовать packed когда это нужно, а когду нужен planar, использовать planar. А также произвольно их смешивать.
По моему и в случае объявления переменных всем вполне очевидны преимущества одного и другого подхода. Не понимаю о чем тут можно спорить вообще.
-
В общем vlad смотри: https://github.com/id-Software/DOOM-3-BFG/blob/master/neo/framework/CmdSystem.cpp
Православные сишники внезапно объявляют переменные всегда (за редким исключением) в начале блока. Вот же парадокс! И с чего это им вздумалось VAR эмулировать?
Можно, ещё, посмотреть в исходники ReactOS и увидеть то же самое.
Эка невидаль! Народ может просто языка не знать! :)
Такое бывает.
У меня коллега всё время путает в каком из .... С или С++ можно где угодно переменную описывать, а где - только сразу после открывающей фигурной.
А по мне, как в Go - тоже ничеGo...
-
В общем vlad смотри: https://github.com/id-Software/DOOM-3-BFG/blob/master/neo/framework/CmdSystem.cpp
Православные сишники внезапно объявляют переменные всегда (за редким исключением) в начале блока. Вот же парадокс! И с чего это им вздумалось VAR эмулировать?
Можно, ещё, посмотреть в исходники ReactOS и увидеть то же самое.
Эка невидаль! Народ может просто языка не знать! :)
Такое бывает.
У меня коллега всё время путает в каком из .... С или С++ можно где угодно переменную описывать, а где - только сразу после открывающей фигурной.
А по мне, как в Go - тоже ничеGo...
Между прочим, ReactOS писана на 89 процентов на Си. А с учетом того, что MSVS не умеет C99, становится очевидно почему же там переменные вначале блока объявляют - другие варианты этот язык просто не поддерживает.
-
valexey: Это типа хороший код ты привел? :D
Это типа код который пишут те, кто гарантированно знает язык в полном объеме.
А разве такое возможно применительно к С++?
Тут вот даже с обероном выясняются постоянно новые нюансы, что уж говорить о С++, который постоянно меняется, к тому же...
-
valexey: Это типа хороший код ты привел? :D
Это типа код который пишут те, кто гарантированно знает язык в полном объеме.
А разве такое возможно применительно к С++?
Тут вот даже с обероном выясняются постоянно новые нюансы, что уж говорить о С++, который постоянно меняется, к тому же...
А у них есть выбор? Они же компилятор пишут :-)
Ну и ты учти, что С++ описан все же лучше и полнее чем Оберон в репорте.
-
Какая замечательная профессия "программист"!
Можно писать какое угодно говно и этому всегда найдется оправдание.
-
Какая замечательная профессия "программист"!
Можно писать какое угодно говно и этому всегда найдется оправдание.
А каков объективный критерий говно или не говно?
На самом деле это ключевой вопрос, иначе все выливается в банальное субъективное нравится/не нравится.
-
С++ описан все же лучше и полнее чем Оберон в репорте.
Про это лучше у Зуева поспрошать... ;)
-
Какая замечательная профессия "программист"!
Можно писать какое угодно говно и этому всегда найдется оправдание.
А каков объективный критерий говно или не говно?
На самом деле это ключевой вопрос, иначе все выливается в банальное субъективное нравится/не нравится.
Как показало недавнее обсуждение на коре, всем насрать на критерии.
Если человек хочет бряк в цикле, то это его желание никакая объективность не сломит.
-
С++ описан все же лучше и полнее чем Оберон в репорте.
Про это лучше у Зуева поспрошать... ;)
Зуев все же компилятор Оберона писать не пробовал :-)
-
Какая замечательная профессия "программист"!
Можно писать какое угодно говно и этому всегда найдется оправдание.
А каков объективный критерий говно или не говно?
На самом деле это ключевой вопрос, иначе все выливается в банальное субъективное нравится/не нравится.
Как показало недавнее обсуждение на коре, всем насрать на критерии.
Если человек хочет бряк в цикле, то это его желание никакая объективность не сломит.
Влияет ли наличие или отсутствие этого бряка на качество кода - вопрос открытый :-)
Умозрительные эксперименты тут не решают, равно как и субъективные хочу/не хочу и ссылки на литературу. Нужно придумать постановку эксперимента который мог бы выявить различие в коде с бряком и без. При этом эксперимент должен быть воспроизводим и должен быть проведен несколькими независимыми исследователями.
Иначе это все антинаучно.
-
Иначе это все антинаучно.
Все уже обсудили на коре. Никакие тут эксперименты не нужны. Бряк в середине рвет цикл на две части, и как следствие цикл становится неструктурным. Для верующих в неструктурное программирование это конечно не помеха.
-
Иначе это все антинаучно.
Все уже обсудили на коре. Никакие тут эксперименты не нужны. Бряк в середине рвет цикл на две части, и как следствие цикл становится неструктурным. Для верующих в неструктурное программирование это конечно не помеха.
А на что это реально влияет? :-) И как это подтверждается экспериментально?
-
В той ветке все есть valexey. Ты хочешь чтобы я все пересказывал тут?
-
Гы. На каком языке ты писал и вляпался (неоднократно, раз это бытовуха) вот в такое?
GNU C, чужое наследие. Зачем многократно, для бытовухи достаточно и 1-го скандала. Вы ведь знаете, что получив граблями по лбу, ходить начинаешь осторожней?
Ну и что? Я на SQL тоже пишу капсом ключевые слова. Потому что пишу их в фаре без подсветки. Это говорит лишь о том, что у человека нет нормального инструмента. Например, в силу относительной ненужности (как мне - раз в месяц написать несколько строк на SQL).
Вот когда человек, имея язык без VAR и без паскального прошлого, начнет переменные лепить в одну кучку - тогда это будет интересно. Я, возможно, даже соглашусь списать это на устройство мозгов конкретного индивидуума.
Работал он в IDE c красиво настроенной подсветкой. На самом деле это всего лишь значит, что каждому - своё. А ваши слова, уж извините, снова вызывают у меня ассоциации. На сей раз с "либералами", "борцами" за свободу и демократию, которые считают, что их мнение - это хорошо и демократично, а чужое - это либо рабская замшелость, либо болезнь, благосклонно списываемая "на устройство мозгов конкретного индивидуума".
Как минимум тот, что пишу я(свет скорей всего не увидит), с другими не разбирался.
Так. Понятно. ТруЪ оберонщик детектед. Опять какие-то секретные репозитории и разработки...
Причина сарказма не понятна. Али указанная особенность - эдакая фантастическая невидаль, существование которой трудно представить, что прям вынь, да положь? Али кто обещал невиданных программистских высот, достигнутых токмо благодаря силушке Оберона и недостижимых на других языках, а теперь коварно не показывает?
Можно хотя бы в общих словах - что за компилятор (как компиляторостроитель компиляторостроителю)?
Но самоирония Вам идёт. Разработка не секретная, а домашняя. Пишу, что скорее всего не увидит свет, потому что адекватно оцениваю силы, учитывая также широту взглядов на проведение времени вне работы (кресло, диван, кровать).
-
В той ветке все есть valexey. Ты хочешь чтобы я все пересказывал тут?
Достаточно будет точных ссылок на описание, постановку и результаты эксперимента.
-
Как два пальца обосцать http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_%D0%91%D1%91%D0%BC%D0%B0_%E2%80%94_%D0%AF%D0%BA%D0%BE%D0%BF%D0%B8%D0%BD%D0%B8
-
Поэтому мне и непонятно вот это стремление сохранить VAR любой ценой
Лихо Вы превратили "простое из достаточных решений" в "сохранить любой ценой", от того и непонятно, что оно было придумано Вами. Вспоминается анекдот: ...
Можно и так и эдак, суть в том, что некоторые не считают, что "эдак" будет лучше в целом.
-
Как два пальца обосцать http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_%D0%91%D1%91%D0%BC%D0%B0_%E2%80%94_%D0%AF%D0%BA%D0%BE%D0%BF%D0%B8%D0%BD%D0%B8
Там нет ничего про качество кода и про влияние break'ов на оное качество. Также там не описан эксперимент который помог бы таковое влияение выявить.
В общем ссылка совершенно не в тему.
-
А ты в литературе там внизу посмотри.
-
А ты в литературе там внизу посмотри.
А там вроде бы литературы нет, только примечания. В примечаниях числится в том числе Dijkstra, Edsger (1968). «Go To Statement Considered Harmful». Что, очевидно, не то.
-
Почему же не то? бряк - это goto. Как раз в тему.
А еще там числится
Bohm, Corrado; and Giuseppe Jacopini (May 1966). «Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules
ps Меня несколько настораживает твоя слепота. Только не говори что тоже не видишь разницы между оператором перехода и оператором повторения. В этом случае говорить не о чем.
-
Почему же не то? бряк - это goto. Как раз в тему.
А еще там числится
Bohm, Corrado; and Giuseppe Jacopini (May 1966). «Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules
ps Меня несколько настораживает твоя слепота. Только не говори что тоже не видишь разницы между оператором перехода и оператором повторения. В этом случае говорить не о чем.
Разницу то я конечно вижу. Также я вижу разницу между тем goto который был при Дейкстре и тем что имеем сейчас. То что было при нем - это жесть содомия и угар в чистом виде. И именно с ним он боролся.
Но еще раз - никто эксперимента доказывающего что goto (пусть будет даже goto, не break) влияет на качество кода (и влияет отрицательно) не поставил. Даже тот, дикий goto что был лет 40-50 назад. Да доказаны теоремы, разработаны методики как с ним бороться. Но самое важное не изучено никак.
-
Кстати, о КАПСе - читаю я код Вирта читаю, и напарываюсь на вот такое:
IF ch = ESC THEN
N.id := neutralize; Viewers.Broadcast(N); FadeCursor(Pointer); LED(0)
ELSIF ch = SETSTAR THEN ...
И по инерции думаю - что это за два новых ключевых слова в языке - ESC да SETSTAR, ужель Вирт еще и их в язык добавил?
-
С++ описан все же лучше и полнее чем Оберон в репорте.
Про это лучше у Зуева поспрошать... ;)
Зуев все же компилятор Оберона писать не пробовал :-)
Но зато он вроде компилятор Зоннона делал на сишарпе...
-
То что было при нем - это жесть содомия и угар в чистом виде. И именно с ним он боролся.
Судя по этим словам, ты не до конца понял с чем боролся Дейкстра.
GOTO плох не тем, что с его помощью легко получить макароны. Это лишь следствие.
Плохо когда программист думает goto'ами.
-
То что было при нем - это жесть содомия и угар в чистом виде. И именно с ним он боролся.
Судя по этим словам, ты не до конца понял с чем боролся Дейкстра.
GOTO плох не тем, что с его помощью легко получить макароны. Это лишь следствие.
Плохо когда программист думает goto'ами.
А чем это плохо? Это ж апофигей императивщины! :-)
Ну и еще раз - где проверяемый эксперимент? Можно долго наворачивать красивые теории, о правильном и не правильном коде и так далее, можно даже подтверждать своей практикой - но это все на уровне ремесла и частных мнений. К истине отношения это не имеет никакого.
-
Но еще раз - никто эксперимента доказывающего что goto (пусть будет даже goto, не break) влияет на качество кода (и влияет отрицательно) не поставил.
Качество кода - это результат выбранного метода построения программы. Так?
В структурном программировании разработан необходимый и достаточный метод построения качественных программ. Для goto в этом методе места не нашлось. (У Дейкстры все разжевано до нельзя)
Осилил конкретный индивидуум этом метод или нет - это отдельный разговор.
На коре я уже говорил, что если ты хочешь изобрести новый метод, то никто не мешает. Доказывай теоремы, иллюстрируй методику на примерах и отстаивай няшность программирования за рамками структурного.
ps Почему ты функциональное программирование не ставишь под сомнение? Может нах. эти чистые функции?
-
А чем это плохо? Это ж апофигей императивщины! :-)
А мы тут вроде про структурщину, а не про императивщину...
Ну и еще раз - где проверяемый эксперимент? Можно долго наворачивать красивые теории, о правильном и не правильном коде и так далее, можно даже подтверждать своей практикой - но это все на уровне ремесла и частных мнений. К истине отношения это не имеет никакого.
Проверяющий что?
-
Но еще раз - никто эксперимента доказывающего что goto (пусть будет даже goto, не break) влияет на качество кода (и влияет отрицательно) не поставил.
Качество кода - это результат выбранного метода построения программы. Так?
В структурном программировании разработан необходимый и достаточный метод построения качественных программ. Для goto в этом методе места не нашлось. (У Дейкстры все разжевано до нельзя)
Осилил конкретный индивидуум этом метод или нет - это отдельный разговор.
На коре я уже говорил, что если ты хочешь изобрести новый метод, то никто не мешает. Доказывай теоремы, иллюстрируй методику на примерах и отстаивай няшность программирования за рамками структурного.
Теоремы тут делу никак не помогут. Где экспериментальное подтверждение, что при структурном программировании получаются более качественные программы? Точнее так - берем язык, ну скажем Аду. Теперь требуется экспериментально подтвердить, что программы писаные без единого break/continue/return (из середины) и goto в среднем качественнее (кстати, критерий что такое "качественная программа" тоже нужно будет определить) чем приложения в коде которых они присутствуют. При этом по остальным параметрам программы должны быть более-менее одинаковы (размер, тематика, квалификация программистов).
ps Почему ты функциональное программирование не ставишь под сомнение? Может нах. эти чистые функции?
Откуда такие сведения?
-
Теоремы тут делу никак не помогут. Где экспериментальное подтверждение, что при структурном программировании получаются более качественные программы? Точнее так - берем язык, ну скажем Аду. Теперь требуется экспериментально подтвердить, что программы писаные без единого break/continue/return (из середины) и goto в среднем качественнее (кстати, критерий что такое "качественная программа" тоже нужно будет определить) чем приложения в коде которых они присутствуют. При этом по остальным параметрам программы должны быть более-менее одинаковы (размер, тематика, квалификация программистов).
Как тебе можно ответить если ты сам вопрос ставишь неправильно? Структурная программа в вакууме не обязана быть лучше программы с goto. Также как метод Гаусса не обязан в частном случае быть лучше изобретения Васи Пупкина (который и математику толком не знает) Но на метод последнего никто в здравом уме полагаться не будет, если тот не построен формально и не доказан.
Вот структурное программирование - это формально, и это доказано. А goto - программирование пальцем в небо.
Как до тебя не доходит простая вещь, что goto - это банальное отсутствие правил?
Откуда такие сведения?
Как минимум ты об этом не говоришь.
-
Теоремы тут делу никак не помогут. Где экспериментальное подтверждение, что при структурном программировании получаются более качественные программы? Точнее так - берем язык, ну скажем Аду. Теперь требуется экспериментально подтвердить, что программы писаные без единого break/continue/return (из середины) и goto в среднем качественнее (кстати, критерий что такое "качественная программа" тоже нужно будет определить) чем приложения в коде которых они присутствуют. При этом по остальным параметрам программы должны быть более-менее одинаковы (размер, тематика, квалификация программистов).
Как тебе можно ответить если ты сам вопрос ставишь неправильно? Структурная программа в вакууме не обязана быть лучше программы с goto. Также как метод Гаусса не обязан в частном случае быть лучше изобретения Васи Пупкина (который и математику толком не знает) Но на метод последнего никто в здравом уме полагаться не будет, если тот не построен формально и не доказан.
Вот структурное программирование - это формально, и это доказано. А goto - программирование пальцем в небо.
Как до тебя не доходит простая вещь, что goto - это банальное отсутствие правил?
А откуда следует что отсутствие правил лучше их наличия? Еще раз: единственный судья - это эксперимент.
Откуда такие сведения?
Как минимум ты об этом не говоришь.
Говорю. Тем кто настаивает на том, что ФП и ФЯ лучше всего на свете и вообще является единственно верным путем.
Ладно, мне надоело говорить - это не продуктивно. Лучше пойду что-нибудь еще попилю. Не структурно :-)
-
Зуев все же компилятор Оберона писать не пробовал :-)
https://sites.google.com/site/zouev54/tekusie-proekty/oberon-for-net
Но результат усилий неизвестен :(
-
Между прочим, ReactOS писана на 89 процентов на Си. А с учетом того, что MSVS не умеет C99, становится очевидно почему же там переменные вначале блока объявляют - другие варианты этот язык просто не поддерживает.
На текущий момент код полностью переработан и переписан на С++, в качестве компилятора используется гнутый компилятор, но попытки перейти на msvc также активно продолжаются.
-
На текущий момент код полностью переработан и переписан на С++, в качестве компилятора используется гнутый компилятор, но попытки перейти на msvc также активно продолжаются.
Где? Обычный С без плюсов: http://svn.reactos.org/svn/reactos/trunk/reactos
Причем такие вещи (избавление от отдельной секции) просто так (just for fun) не переписываются - оно ж и так компилится. Т.е., даже если они переедут на С++, то сначала это будет смена расширения файлов, не более :)
-
Ну, например в этом контексте становится очевидным почему Вирт выпилил из Оберона массивы с длиной неизвестной на этапе компиляции. Абсолютно логичный ход вообще то :-)
Э... А я так и не понял - почему? Потому что всегда можно ограничить что-то конкретной длиной (например, 32 символа для идентификаторов)? Работать будет не всегда, зато просто?
-
Причем спор такой, что типа нужно решить кто из них кошерней, а другой выпилить нафиг раз и навсегда.
Ну конкретно в случае секции VAR она просто становится не нужна - всегда можно просто объявить все переменные в начале блока.
-
Гы. На каком языке ты писал и вляпался (неоднократно, раз это бытовуха) вот в такое?
GNU C, чужое наследие. Зачем многократно, для бытовухи достаточно и 1-го скандала.
И где там в GNU С автовывод типов и перегруженные функции?
Вы ведь знаете, что получив граблями по лбу, ходить начинаешь осторожней?
Конечно. Например, функция, которая возвращала int, переписывается не просто на возврат double, а на возврат safe_double_t. И этот safe_double_t ругается на попытку сравнения на равенство с другим safe_double_t (ну и с int, до кучи).
А ваши слова, уж извините, снова вызывают у меня ассоциации.
Политические пассажи не буду комментировать в принципе.
Али кто обещал невиданных программистских высот, достигнутых токмо благодаря силушке Оберона и недостижимых на других языках, а теперь коварно не показывает?
Вообще да, info21 обещал и обещает. А вот код тоже не показывает (облажавшись пару раз).
Но самоирония Вам идёт. Разработка не секретная, а домашняя. Пишу, что скорее всего не увидит свет, потому что адекватно оцениваю силы, учитывая также широту взглядов на проведение времени вне работы (кресло, диван, кровать).
Дык, у меня тоже домашне-диванная... Однако на гитхаб оно и с дивана замечательно заливается.
-
И где там в GNU С автовывод типов и перегруженные функции?
Нигде, разумеется. Есть скромный typeof, оказывается, иногда и этого достаточно.
Политические пассажи не буду комментировать в принципе.
Во-первых, это уже комментарий, логичней тогда было пропустить эту часть. Во-вторых, несмотря на то что, слова "демократия" и "либерализм" у многих ассоциируются только с политикой, это не отменяет их более широкой трактовки, они вполне могут быть применены и, например, к организации разработки ПО и к общению на форуме. И в-третьих, речь-то в первую очередь о специфической жизненной позиции, когда возможность существования адекватного, но не похожего мнения отстаивается ровно до тех, пока оно применено к себе, а как только её нужно распространить на других, то тут же применяется то же самое поведение, которое немногим ранее усердно изобличалось.
Вообще да, info21 обещал и обещает. А вот код тоже не показывает (облажавшись пару раз).
Это, конечно, интересно. Скажите пожалуйста, какое отношение это имеет ко мне?
Дык, у меня тоже домашне-диванная... Однако на гитхаб оно и с дивана замечательно заливается.
Это хорошо и это ваше право. Скажите пожалуйста, какое отношение это имеет ко мне?
-
И где там в GNU С автовывод типов и перегруженные функции?
Нигде, разумеется. Есть скромный typeof, оказывается, иногда и этого достаточно.
Выяснилось, что автовывод таки присутствует
__auto_type a = expression;
-
И где там в GNU С автовывод типов и перегруженные функции?
Нигде, разумеется. Есть скромный typeof, оказывается, иногда и этого достаточно.
Может typedef? В общем это все в одну кассу - большие возможности подразумевают большую ответственность. Ну и каждый выбирает для себя сам порог, за которым он уже не видит всех последствий использования какой-то возможности. Конкретно сишный typedef - замечательная штука, даже в паскалях/обероне была и есть в каком-то виде (в последнем обероне почти выпилили).
Это, конечно, интересно. Скажите пожалуйста, какое отношение это имеет ко мне?
В общем случае никакого (если ты не info21 :) Я только отметил определенную корреляцию между языковыми предпочтениями и доступностью разработок. Это мое личное наблюдение, основанное на личном восприятии (без цифр статистики).
-
Выяснилось, что автовывод таки присутствует
__auto_type a = expression;
Расширение конкретного вендора? Это уже вообще несколько иная область со своей спецификой (сознательный выбор маневрировать между известными и не очень граблями).
-
Может typedef?
typeof по аналогии с sizeof.
В общем случае никакого (если ты не info21 :) Я только отметил определенную корреляцию между языковыми предпочтениями и доступностью разработок. Это мое личное наблюдение, основанное на личном восприятии (без цифр статистики).
Ну, кто знает. По поводу языковых предпочтений - Вы не заметили это сообщение:
Рукотворный тип, который суть переменная со спецификатором хранения typedef, может быть переопределен во вложенной области видимости, причем самым забавным способом - type a, b, type; с int такое не пройдет. Переменная рукотворного типа не может быть объявлена с signed, unsigned, long, short. Опять же, рукотворный тип может быть объявлен уже с квалификатором const/volatile, что может привести к невозможности объявления переменной с теми же явными квалификаторами.
То, что typedef - это спецификатор хранения, и соответственно синтаксически эквивалентен static, extern, register, auto со всеми вытекающими последствиями, это, насколько я могу судить, достаточно неожиданный нюанс и для многих разработчиков на Си, а не то что... Заодно видно, что перепутать typedef и typeof мне было бы затруднительно.
__auto_type a = expression;Расширение конкретного вендора? Это уже вообще несколько иная область со своей спецификой (сознательный выбор маневрировать между известными и не очень граблями).
Я же указал на расширение конкретного поставщика - GNU C. Да, это не ANSI C и не ISO С99. Но поддерживается не только в gcc: частично в clang, и ещё более частично в tcc. Кстати, конкретно __auto_type - это похоже, совсем свежая новинка.