Здравствуйте, 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. И так далее.
Тут как раз вопрос в том, много ли этих "и так далее". У меня такой статистики нет, поэтому утверждать, что я прав, не берусь.
Здравствуйте, 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.
Ну воот, начинается юление.
Здравствуйте, 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.