Когда в языке есть eval(), умеющий выполнять программы в виде строк, остальное неважно — хоть в дерево эти строки подвесить, хоть в список, хоть в циклический буфер:) Но это когда язык интерпретируемый. Если язык компилируемый, то для eval() программе нужно или тащить с собой компилятор (что совсем неразумно) или — что разумнее — иметь встроенный скриптинг на скриптовом языке и интерпретатор этого языка в виде библиотеки. Хотя языковая поддержка для таких вещей все равно желательна — например для прозрачного доступа к объектам компилируемого языка из скрипта.
Непривычный синтаксис усложняет понимание. Это примерно то же самое как в статьях, в которых пытаются объяснить что же такое монады, используются примеры на Haskell. Возможно, внутри Haskell это даже достаточно простая и естественная концепция, но когда смотришь на код, мозгу с непривычки не за что зацепиться:)
Меня интересуют в первую очередь си-подобные языки. Ну и конечно всего не охватить в одной статье… хотя конечно Rust можно было упомянуть, я просто не успел еще разобраться с его макросами. По Rust (как и по Nim) на данный момент крайне мало документации, надеюсь в ближайшее время что-то поменяется в лучшую сторону в связи с выходом 1.0. Что же касается lisp, то это язык с сильно отличающимся от «мейнстрима» синтаксисом, этот фактор усложняет понимание.
Что автор бросил университет ради разработки своей игры? Типа Билл Гейтс бросил университет, Стив Джобс бросил университет, Марк Цукерберг бросил университет, чем автор хуже?
Нет, не надо бросать университет, мы таки не в солнечной Калифорнии. А чтобы туда попасть, высшее образование может быть весьма кстати. Но это мое ИМХО конечно же.
Я вот тоже с удовольствием почитал бы статью об Обероне, о его фичах. Вот только автор (судя по предыдущей дискуссии) считает что фичи — это плохо, а хорошо то что в Обероне их нет. А как писать о том чего нет?
Мы у оберонщиков под пытками выяснили, что в Обероне есть какая-то «типа рефлексия» — возможность получать процедуру по имени процедуры и имени модуля… Кто знает, может там еще есть что-то интересненькое…
Только движущиеся галактики на небе как-то неестественно выглядят. Они на самом деле двигались бы с такой большой скоростью?
ИМХО естественнее было бы видео с движущейся камеры (то есть мы видели бы перемещение относительно деревьев, домов и т.д.), и неподвижные галактики как фон неба.
Да конечно. Я же говорю что это скорее психологический момент. В тех же Rust и Go мне например не нравится навязывание «египетского» стиля скобок как единственно возможного.
Серьезно. Пробелы невидимы, и по слепоте три от четерых или четыре от пяти можно и не отличить:) Особенно если идет не код одного блока в столбик, а завершение сразу нескольких блоков.
Ну это наверное дело привычки… мне вот не нравится программирование на отступах:) (хотя я разумеется в своих программах на С++ строго придерживаюсь одного из стилей выравнивания кода — Allman_style)
Мне нравится чтобы все элементы программы были «осязаемы». С пробелами такая проблема — а сколько их нужно использовать для отступа? Один, два, четыре, что с табуляцией, в разных редакторах табуляция соответствует разному числу пробелов… Что если я ошибусь на один пробел в большой длинной программе… Пробелы невидимы, и если на них повешена какая-то семантика, то получается, что я не могу точно видеть часть своей программы, как-то так:)
Хотя возможно вы и правы, спорить не буду:)
А чем вам не нравятся фигурные скобочки и точка с запятой?
Про скобки я могу только одно сказать — в текущем множестве общедоступных для ввода с любой клавиатуры символов (т.е. ASCII) их мало. Даже для шаблонов пришлось взять «угловые», которые мешаются с «больше-меньше», что не есть хорошо для компиляторов. Реально нужно не меньше 5 видов скобок.
А что касается точки с запятой — это разделитель между выражениями. Да, конечно можно попробовать исхитриться и без нее, но для меня это вполне естественный атрибут программы. Как минимум — способ визуально разделить программу на части. Это вообще малоизученная тема, точная семантика точек с запятыми и запятых «плавает» от языка к языку и даже внутри одного языка от конструкции к конструкции; но тем интереснее будет ее изучить.
Хоть я и не согласен с автором, но такие темы здорово мотивируют на разработку и доведение до ума собственных идей и проектов в области создания языков программирования, за что автору спасибо.
А где можно с этим ознакомиться подробнее? (интересно, на чем же он основан тогда?...)
Нет, не надо бросать университет, мы таки не в солнечной Калифорнии. А чтобы туда попасть, высшее образование может быть весьма кстати. Но это мое ИМХО конечно же.
Мы у оберонщиков под пытками выяснили, что в Обероне есть какая-то «типа рефлексия» — возможность получать процедуру по имени процедуры и имени модуля… Кто знает, может там еще есть что-то интересненькое…
ИМХО естественнее было бы видео с движущейся камеры (то есть мы видели бы перемещение относительно деревьев, домов и т.д.), и неподвижные галактики как фон неба.
Мне нравится чтобы все элементы программы были «осязаемы». С пробелами такая проблема — а сколько их нужно использовать для отступа? Один, два, четыре, что с табуляцией, в разных редакторах табуляция соответствует разному числу пробелов… Что если я ошибусь на один пробел в большой длинной программе… Пробелы невидимы, и если на них повешена какая-то семантика, то получается, что я не могу точно видеть часть своей программы, как-то так:)
Хотя возможно вы и правы, спорить не буду:)
Про скобки я могу только одно сказать — в текущем множестве общедоступных для ввода с любой клавиатуры символов (т.е. ASCII) их мало. Даже для шаблонов пришлось взять «угловые», которые мешаются с «больше-меньше», что не есть хорошо для компиляторов. Реально нужно не меньше 5 видов скобок.
А что касается точки с запятой — это разделитель между выражениями. Да, конечно можно попробовать исхитриться и без нее, но для меня это вполне естественный атрибут программы. Как минимум — способ визуально разделить программу на части. Это вообще малоизученная тема, точная семантика точек с запятыми и запятых «плавает» от языка к языку и даже внутри одного языка от конструкции к конструкции; но тем интереснее будет ее изучить.