Напомню, речь изначально шла о том, что в Обероне, например, не нужно пустое пространство для разделения, так как эту роль выполняют ключевые слова (которые не нравятся многим), которые выглядят особенно. «Глаз цепляется», знаете такое выражение?
Это не сравнительный график языков, это совмещенные графики динамики эксплозии синтаксиса. Но и простоту с примитивностью путать не стоит.
А рефлексия не нужна в составе языка. Она отлично работает на уровне компонентов.
Шаблоны вообще лишают вас связи с реальным кодом. Для простых случаев, конечно, все работает.
Понимаете, трудно соблюсти баланс между сложностью и облегчением работы программиста. Нет ни одной реальной метрики, в числах, в графиках. Никто не знает, насколько та или иная фича нужна в языке. Поэтому нам приходится доверять мемам о том, что действительно, шаблоны «улучшают» код на Икс процентов.
Это разные подходы. В ситуации незнания кто-то предпочитает «делать» фичи, а кто-то выбирает «не делать» фичи. Ну а рассудил всех рынок. Деятельные люди там в почете.
Стайл-гайдам не все равно, они советуют писать именно так. Разделять пустотой объявления и действия, переносить скобку после объявления на новую строку. И так далее.
Хотелось бы уточнить, что автором графика является не Н. Вирт, это просто его заслуги отображени на картинке зеленой линией.
Исходный текст тут www.uni-vologda.ac.ru/cs/syntax/ariphm.htm
В последующих обсуждениях автору картинки предлагали считать уже примитивы AST. Но так как грамматика для человека, а AST для компилятора, то я бы оставил именно грамматику показателем динамики усложнения языка (не сравнительной сложности, а просто сложности). Есть же объективные пределы человеческого мозга, что и сколько надо держать в памяти. Каждый раз, добавляя ключевое слово в язык, вы повышаете нагрузку на мозг.
Не работал с вычислениями на GPU, но читал о них.
Насколько я понимаю, ключевых особенностей несколько: необходимость передавать данные в память/из памяти GPU, необходимость поддерживать структуры, пригодные для массово-параллельной обработки набора значений за одну инструкцию, необходимость эффективного управления тысячами вычислительных циклов на каждом маленьком ядре GPU. Вполне очевидно, что возникает необходимость в отдельном DSL, возможно, на базе Оберона. Но совмещать концепции в одном языке, как мне кажется, будет контрпродуктивно. То есть, гетерогенный язык это трудно. А вот гетерогенные компоненты составить уже возможно. Линковщик разберет продукт компиляции кода для CPU и GPU и что-то сможет предпринять. Но это мои частные рассуждения.
С моей точки зрения эстетически приятнее когда код плотный, аккуратно разбит на иерархические блоки.
С этой точки зрения код на Обероне мне приятнее, чем разреженный код на Java, где пустого места на единицу площади иногда больше, чем кода.
Но ведь операторные скобки сейчас расставляет IDE. А например в вашей статье про Brainfuck VM длинные квалификаторы, длиннее, чем слово BEGIN, но вы не стали их сокращать.
А рефлексия не нужна в составе языка. Она отлично работает на уровне компонентов.
Шаблоны вообще лишают вас связи с реальным кодом. Для простых случаев, конечно, все работает.
Понимаете, трудно соблюсти баланс между сложностью и облегчением работы программиста. Нет ни одной реальной метрики, в числах, в графиках. Никто не знает, насколько та или иная фича нужна в языке. Поэтому нам приходится доверять мемам о том, что действительно, шаблоны «улучшают» код на Икс процентов.
Это разные подходы. В ситуации незнания кто-то предпочитает «делать» фичи, а кто-то выбирает «не делать» фичи. Ну а рассудил всех рынок. Деятельные люди там в почете.
Исходный текст тут www.uni-vologda.ac.ru/cs/syntax/ariphm.htm
В последующих обсуждениях автору картинки предлагали считать уже примитивы AST. Но так как грамматика для человека, а AST для компилятора, то я бы оставил именно грамматику показателем динамики усложнения языка (не сравнительной сложности, а просто сложности). Есть же объективные пределы человеческого мозга, что и сколько надо держать в памяти. Каждый раз, добавляя ключевое слово в язык, вы повышаете нагрузку на мозг.
Не работал с вычислениями на GPU, но читал о них.
Насколько я понимаю, ключевых особенностей несколько: необходимость передавать данные в память/из памяти GPU, необходимость поддерживать структуры, пригодные для массово-параллельной обработки набора значений за одну инструкцию, необходимость эффективного управления тысячами вычислительных циклов на каждом маленьком ядре GPU. Вполне очевидно, что возникает необходимость в отдельном DSL, возможно, на базе Оберона. Но совмещать концепции в одном языке, как мне кажется, будет контрпродуктивно. То есть, гетерогенный язык это трудно. А вот гетерогенные компоненты составить уже возможно. Линковщик разберет продукт компиляции кода для CPU и GPU и что-то сможет предпринять. Но это мои частные рассуждения.
С этой точки зрения код на Обероне мне приятнее, чем разреженный код на Java, где пустого места на единицу площади иногда больше, чем кода.
Но это все вкусовщина, конечно.