Здравствуйте, Sinclair, Вы писали:

S>Сама по себе трансляция — тривиальна; в приличных языках её можно отловить путём введения типизации на индексах.

Хм. В каких же, например?
Явно не в промышленных, в которых трансляция уже не так тривиальна.

S>Проблема индексации с единицы — в том, что безо всякой трансляции она провоцирует ошибки.

Довольно сильное утверждение. Обосновать можете?

S>Арифметика таких индексов беспричинно сложна. Вам привели банальный пример, в котором нет никакой трансляции, а просто нужно обращаться к элементам массива "по кругу". И уже в нём паскалевская арифметика провоцирует ошибки.

Ну, один пример — это ни о чем. К тому же пример сильно специфический. Я вот за последние годы ни разу кольцевых буферов не организовывал (сейчас занимаюсь разработкой геоинформационной системы). Если речь о написании драйверов и менеджеров памяти — тут применяйте Ц, мне не жалко.

Здравствуйте, AlexRK, Вы писали:

ARK>Ну, один пример — это ни о чем. К тому же пример сильно специфический. Я вот за последние годы ни разу кольцевых буферов не организовывал (сейчас занимаюсь разработкой геоинформационной системы). Если речь о написании драйверов и менеджеров памяти — тут применяйте Ц, мне не жалко.
Блин, у меня подобного кода тонны в прикладных приложениях. Или возьмём для примера такую ситуацию — буфер разделён на сегменты по 512 байт. Нужно рассчитать смещение в байтах N-ного байта M-ного блока от начала буфера.

В С: offset = M*512 + N
В паскалеподобных: offset := (M-1)*512 + N-1

Очень красиво, да.

Здравствуйте, AlexRK, Вы писали:

ARK>Хм. В каких же, например?
ARK>Явно не в промышленных, в которых трансляция уже не так тривиальна.
В любых, где есть перегрузка операций. Т.е. в C++ и C#.
Применяем паттерн Декоратор — и вперёд, на танки.
ARK>Довольно сильное утверждение. Обосновать можете?
Вы же только что его сами же и продемонстрировали.

ARK>Ну, один пример — это ни о чем. К тому же пример сильно специфический. Я вот за последние годы ни разу кольцевых буферов не организовывал (сейчас занимаюсь разработкой геоинформационной системы). Если речь о написании драйверов и менеджеров памяти — тут применяйте Ц, мне не жалко.
Ну речь же не только о кольцевых буферах. Уложить, к примеру, прямоугольную матрицу в линейный массив — опять нужно ((x-1)*h)+y-1. И так далее.

Здравствуйте, Sinclair, Вы писали:

S>В любых, где есть перегрузка операций. Т.е. в C++ и C#.
S>Применяем паттерн Декоратор — и вперёд, на танки.

А, вон что.
Но я говорил не об этом, а о ручной трансляции "на бумажке" — где, собственно, и ошибся.

S>Вы же только что его сами же и продемонстрировали.

"Мамой клянусь, треугольник" (с)

S>Ну речь же не только о кольцевых буферах. Уложить, к примеру, прямоугольную матрицу в линейный массив — опять нужно ((x-1)*h)+y-1. И так далее.

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

Здравствуйте, Cyberax, Вы писали:

C>Блин, у меня подобного кода тонны в прикладных приложениях.

Не срача ради, а токмо научного интереса для: какие, например, у вас прикладные приложения и зачем там кольцевые буфера?

Здравствуйте, dolor, Вы писали:

D>а, хотел бы вместо && писать 'and'

Я бы, наоборот, заменил все ключевые слова на последовательности небуквенных символов. То есть вместо:

if (condition1)
    while (condition2) {
        . . .
    }

писал бы:

? (condition1)
    @ (condition2) {
        . . .
    }

Тогда новые "ключевые слова" можно было бы вводить не опасаясь, что их кто-то уже использовал в программе в качестве идентификаторов.

Здравствуйте, AlexRK, Вы писали:

C>>Блин, у меня подобного кода тонны в прикладных приложениях.
ARK>Не срача ради, а токмо научного интереса для: какие, например, у вас прикладные приложения и зачем там кольцевые буфера?
Такой код у меня во вполне обычном учётном приложении, в рисовании специальных графических виджетов.

А ещё я занимаюсь генетическими ассемблерами — там подобный код примерно 100% всего кода.

Здравствуйте, LaptevVV, Вы писали:

LVV>Добавлю: читаемость кода начинающим, и читаемость кода экспертом — это разные читаемости.
LVV>Соответственно и синтаксис надо сделать настраиваемым в ИДЕ...

Ага, таким образом окончательно убив читаемость кода. Спасибо, не надо!

Здравствуйте, dolor, Вы писали:

D>а, хотел бы вместо && писать 'and'

Я уже так пишу, на Python'е. Все эти &&, || и прочие штуки, действительно анахронизмы в XXI веке. Популярность Python'а (не смотря на его тормознутость и прочие минусы) показала на практике всю важность синтаксиса языка программирования. В принципе, это есть пруф того, что не нужно гоняться за C-like синтаксисом в надежде на то, что C/C++/Java/C# программисты перейдут на ваш язык из-за того, что синтаксис им будет привычен.

Здравствуйте, iLikeCookies, Вы писали:

LVV>>Добавлю: читаемость кода начинающим, и читаемость кода экспертом — это разные читаемости.
LVV>>Соответственно и синтаксис надо сделать настраиваемым в ИДЕ...

LC>Ага, таким образом окончательно убив читаемость кода. Спасибо, не надо!

Предполагается, что начинающие и эксперты могут одинаково хорошо читать код ?

Здравствуйте, Ikemefula, Вы писали:

I>Предполагается, что начинающие и эксперты могут одинаково хорошо читать код ?

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

Здравствуйте, iLikeCookies, Вы писали:

LC>Здравствуйте, Ikemefula, Вы писали:

I>>Предполагается, что начинающие и эксперты могут одинаково хорошо читать код ?

LC>Предполагается, что будет создан синтаксис одинаково хороший и для начинающих и для опытных товарищей.

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

>И еще предполагается, что возможность плодить бесконечное количество разных настроенных синтаксисов приведет к хаосу и разрушениям. И последнее, язык программирования, это такой же язык общения, но между программистами. Если каждый программист будет говорить на своем языке, настроенном под себя, другие вряд ли его поймут и захотят с ним поиграть в песочнице.

То есть, ты выступаешь за естественный язык, вроде английского, русского ?

Здравствуйте, ResidentR6, Вы писали:

RR>Только не говорите что СЛОЖНО реализовать поддержку ключевых слов begin
RR>и end, а также and, or, not, = (вместо ==) и GOTO. Это банально улучшает
RR>ЧИТАЕМОСТЬ кода!!!

Губанов, ты?

Здравствуйте, AlexRK, Вы писали:

ARK>Низкоуровневые/системные вещи можно писать на С. "Математическую хрень" на фортране или специальном DSL.
Ну воот, начинается юление.

Здравствуйте, rusted, Вы писали:

R>А еще массивы должны по умолчанию индексироваться с 1, а не с 0.

Пользуясь случаем, хочу передать привет моей бабушке луч поноса авторам JDBC.

Здравствуйте, AlexRK, Вы писали:

R>>Про BEGIN/END уже написали.
ARK>Вместо кривых скобок? Согласен. Но лучше в нижнем регистре.
R>>Ну и для полной благодати расширение у файлов исходников сделать *.pas
ARK>Это пофиг.

Рекомендую обратиться к ABAP, вот где раздолье.

1. Никаких скобочек. Только суровые IF...ENDIF. DEFINITION...END-OF-DEFINITION.
2. Индексы с 1 (впрочем никаких массивов там нет, бугага)
3. Недавно лишь ввели оператор конкатации строк. Но можно польоваться старым добрым CONCATENATE x y z INTO w.
4. Никаких булевских переменных — это слишком усложняет код. Опять же, сейчас чистоту попортили и стало возможным писать IF x + y < z. (Раньше надо было объявить переменную, потом выполнить присвоение в нее суммы, и лишь потом использовать в условии).
...
7. PROFIT!!!

Я бы сказал что все споры по поводу and vs || бред полный.
Намного более важно рассмотреть "понимаемость структуры кода" в целом.
Для читаемости отдельного метода/класса достаточно соблюдать SRP.