Oberon space

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

Предполагалось, что повысится читаемость, ясность и исключится возможно путать аргументы. В php не путать параметры без справки просто нереально, но он не типизированный.
P.S Это всего лишь заметки. Я стараюсь делать подобные для размышлений.

Хочу поделиться с записями, сделанными на начало прошлого года и содержащими идеи на тему, какими фичами должен обладать ЯП, условно приближенный к идеальному.
-) Все входные аргументы подпрограмм подлежат обязательной проверке assert-подобным выражением.

procedure WriteChar
(
  x: int; Math.InRange(x, 0, WndWidth - 1);
  y: int; Math.InRange(y, 0, WndHeight - 1);
  col: str; ANY;
)Смысл: координаты должны быть в рамках окна, а строка цвета - любой.

Особенности:
- Объявление одного аргумента - одна строка.
- Аргумент отделяется от охраны символом ";"
- Охрана - обычное логическое выражение. Если оно включает подпрограммы, то те не должны рекурсивно ссылаться на объявляемую подпрограмму.
- Константа ANY = TRUE.

Дополнение:
Так как охрана может быть сложной и писать её полностью может быть затруднительно, неплохим вариантом видится введение соглашений (см.  Соглашения).

-) Именованные параметры.
При вызове подпрограммы должны указываться пары: имя параметра ":" значение.

WriteChar(x: 3; y: 4; col: 'black');! Исключение: если переменная/константа имеет то же имя, что и параметр, то может указываться просто имя параметра:
WriteChar(x, y, col: 'red');

-) Опциональные параметры.
Параметры, которые могут быть опущены при вызове. При этом в теле подпрограммы будут находиться проверки компилятора на проинициализированность подобных аргументов.

procedure WriteChar
(
  x: ...
  y: ...
  optional Col: string; ANY; (* охрана типа осуществляется только, если аргумент инициализирован *)
)
{
  ...
  if !IsSet(Col)
  {
    Col := Console.Col;
  }
}IsSet - проверяет, установлен ли аргумент. Прямое присваивание значения аргументу автоматически устанавливает его.

-) Аргументы со значением по умолчанию. Значение должно быть константным выражением!

function Random
(
  Min: int = 0; Min >= 0; (* охрана сработает всегда *)
  Max: int = 99; Max >= Min; (* охрана сработает всегда *)
): int;
-) Аргументы по ссылке:
- in - после вызова переменная получает статус Unknown (равносильно неинициализированности)
- out - внутри подпрограммы имеет начальный статус Unknown
- inout - аналог var

-) Язык со сборкой мусора.

-) procedure и function для логического разделения подпрограмм. () после имени обязательно.

-) Обязательное присвоение значений переменным при объявлении с необязательной охраной.

VAR
  AbsX: int = x + Con.Window.x1; AbsX in [0; Con.Width - 1];-) Записи-константы и записи, создаваемые на лету.

coords := (x: MyX, y); (* Заметьте, "y" не указывается два раза, та как имя переменной совпадает с именем поля в записи *)-) Опциональные поля записей.

Cell = record
  optional Opacity: float = 1.0; (* прозрачность ячейки *)
end;-) Обязательное присвоение значений полям записи.

TCoord = record
  x: int = -1;
  y: int = -1;
end;-) Соглашения.
Служат для точного указания особенностей подпрограмм.
Пусть соглашение - логическая функция.
Пусть часть функций работает с абсолютными координатами консоли, а другая с относительными (относительно границ логически подокна).

convention  (Con: TConsole) UsesRelativeCoords ()
(
  x: int;
  y: int;
)
{
  result := Math.InRange(x, Con.WndWidth - 1) and Math.InRange(y, Con.WndHeight - 1);
}

procedure WriteChar
(
  x: int; ANY;
  y: int; ANY;
  Ch: char; ANY;
); UsesRelativeCoords;

{
  ...
}Те аргументы, которые указанны в соглашении, обзяаны быть и в подпрограммах, использующих эти соглашения.

Как всё сложно.

[17.1] What are some ways try / catch / throw can improve software quality?

FAQ: You'll have less if statements in your code: you won't have to check for errors each time you call a function. Conditional statements are known to contain more bugs than other statements. With less if tests, you'll ship a better product, faster.

FQA: This is cargo cult programming. Conditional statements are error-prone because they are used to handle complicated scenarios, where an action can result in many different outcomes, which affect the next actions. In order to make errors less probable, one has to simplify the model of the desired behavior of the software. The problem is the complexity that leads to if statements, not the if keyword, and using different keywords is not going to solve the problem by itself.

Exceptions are supposed to simplify the error handling model based on the assumption that in most cases, a function that detected an error can't handle it, and has to propagate it to the caller. Finally, a "high-level" enough caller is reached and actually makes a decision (pops up an error message, tries a different action, etc.).

Despite its promises, this approach has inherent problems. There's a "social" problem - with exceptions, people are not aware of the different errors that may happen in the code because most of the code doesn't deal with errors. And when people rarely think about a particular aspect of an application, ultimately this aspect is unlikely to be handled well. There's a more "technical" problem - functions essentially doing nothing upon error except for propagating errors to the caller still can't be completely unaware of errors. That's because they may need to release the resources they acquired before returning to the caller, which may lead to more errors, which must also be handled. Finally, in practice exception support has run-time overhead, and very significant code size overhead, even if exceptions are never raised at run time, and even if they are not mentioned in your code. C++ devotees may claim otherwise; you can check by compiling your code with and without exception support (if your compiler doesn't have such a flag, compile code as C and as C++ instead). This is unacceptable in resource-constrained systems.

Отрицательный результат - тоже результат. И хотя нас часто порывает принять за данность выполнение программы в идеальном окружении с идеальным пользователем, а всю логику обработки ошибок закинуть как можно выше, это не выход. Пора уже понять, что практически все функции не способны гарантировать результат. Что исключения одного класса обезличиваются при всплывании, превращаясь в нечто вроде TIOError. Что если мы хотим обработать 250 вызовов функций по-разному, нам понадобятся 250 обработчиков и их логика должна быть на том же уровне, что и вызов функций.

Посмотрите на самые азы - арифметику. +, -, * - возможность выхода за границы типа (переполнение), / - тоже + деление на 0. Практически каждая функция из rtl в php может вернуть ошибку. Работа со строками, массивами, форматами - чем угодно. Если возвращаемое значение функции и есть её результат, то механизм исключений будет использоваться всегда. Или же его тросянка. Часть функций с кодами ошибок, другая на исключениях. Вопрос. А что есть исключение? То, что сейчас модно называть исключением, является ничем иным как штатной ситуацией. Зачем вводить исключения, потом для них же магические способы финализации, затем перегрузку операторов, которая без исключений вообще нежизнеспособна. Затем возвращение сложных структур функциями. Что более фундаментально? Что автономно? Что проще в реализации? С какой кстати высший уровень должен знать все типы исключений низших, а если не знать, то иметь лишь единственный молчаливый способ их обработать? Наконец, зачем ещё один goto на адрес в стёковой структуре, когда стремимся к безопасному, надёжному и наглядному коду, где прыжкам в неизвестность просто не место.

P.S Кстати, пример изначально неверного подхода к проектированию можно увидеть в обероновском модуле Files. Там функции работают с идеальной файловой системой и понятия ошибки нет вообще.

Заключение: для действительно исключительных ситуаций (определённого класса) достаточно функций-финализаторов.

Форум тормозит не слабо. Один раз некоторое время показывал ошибку соединения с БД.
Проверьте, что там у вас со стилями:

Ссылки типа: http://oberon.talk4fun.net/Themes/Default/SyntaxHighlighter/js/*.js/ Штук 15 пытаются грузиться и получают 404 каждый раз.

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

Я тоже не дизайнер, но ношу идею своего движка. Когда-нибудь. Потом смотрю на объём исходного кода, шаблонов и ресурсов у современных движков и возвращаюсь к реальности.

Javascript - Number.

Оазис для обсуждения наболевших тем. Спасибо.
Рад видеть забытые ники на форуме.