С++ был создан довольно давно... но досих пор используется при написании некоторых программ. Как по вашему, как долго он ещё будет жить? Что с ним произойдёт при массовом переходе на не x86 платформы?
Посмотри на pattern matching в ML или Haskell, а потом засунь свой lpeg куда подальше. Ты некомпетентен, необразован и невменяем. Одним словом - ничтожество.
:-) При написании "некоторых" программ используется ассемблер, а остальные 99.9999% пишут на си и си++. Поэтому эти языки будут жить еще долго. Да и на замену-то ничего более толкового нет.
Язык платформенно независимый, поэтому ничего с ним не произойдет.
"Вообще" - так не бывает. Все языки имеют смысл в контексте прикладной области, а не "вообще". Луа как язык описания игровой логики - говно (там вообще декларативный язык должен быть как правило), луа как язык конфигураций - ещё большее говно, кто Ion3 юзал, тот знает. Но я вполне допускаю, что есть прикладные области, где Lua может тихо зарулить. Только я про них ничего не знаю.
>язык не такой уж и простой и не такой уж и расширяемый.
программа под названием "схема - язык субстрат" провалилась. Это можно посмотреть в практических реализациях схемы вроде PLT. Там все фичи вроде ООП hardcoded в компилятор.
Академики - те ещё трусы. За что тот же Пол Грэм их и пинает регулярно. Они не то что метапрограммирования без гигиены боятся, они сейчас от языка без жесткой статической типизации шарахаются в ужасе.
+1. Cм. ссылку про "Evolution of Haskell Programmer" где они факториал вычисляют 15 разными способами :) и в конце с катаморфизмами -- что академик напишет сам по себе, а что для студентов, чтобы его объяснения поняли :)))
>они сейчас от языка без жесткой статической типизации шарахаются в ужасе
и правильно делают. Cтатическая типизация это Ъ. Я бы даже не посмотрел в сторону схемы, если бы разбирался в теории типов достаточно хорошо для написания компиляторов c системами типов второго порядка...
ЗЫ а макросы это та же самая потеря информации для компилятора, кстати.
Иметь простейший безтиповый макроязык в основе - нужно и полезно. Давать его в шаловливые ручки пользователей - вредно. Надстроить над таким языком сколь угодно сложную систему типов - не проблема. Все довольны, всё хорошо. И язык теоретически чист, и реализация его проста и эффективна.
В общем, я метапрограммирование рассматриваю как средство реализации языков, как чёрную магию, которую нельзя давать в руки простым смертным.
Почему же? Когда на них навешана статическая типизация, когда макры уже недоступны, то почему нет? Даю их простым смертным, и никто не жалуется. Они даже не знают, что там внутри.
> расказ о том какими костылями ты "статическую типизацию" обеспечивал - и будет моим аргументом.
Никаких костылей. У меня есть реализация Пролога поверх Лиспа (очень много для чего ещё нужно, так что считаем, что есть из коробки), есть язык для работы с AST, есть Pattern matching - то есть, весь джентльменский набор для реализации компиляторов. Этот набор, запрятанный в макру, генерящую код на всё том же Лиспе - и будет той самой мордой статически типизированного языка поверх Лиспа.
> конечно, базовый схемо-подобный язык + компилятор с плагинами и подготовленной инфраструктурой.
Ну и чем тут метапрограммирование помешало? Как раз с ним это делается проще всего - компилятор становится частью языка.
Тривиально. На входе - AST языка без типов (или с аннотациями), у макры есть доступ к environment, где вся информация о типах есть.
Далее AST преобразуется так, что каждому выражению, которое может иметь тип, приписывается id (грубо говоря - типовая переменная), затем для всех пар id-выражение составляются уравнения по очень простой схеме. Система уравнений решается встроенным Прологом, так что никаких хитростей тут не нужно. То место, где Пролог загнулся, высвечиваем как ошибку, если не загнулся - заменяем все переменные, относительно которых система решена, на конкретные типы. Всё, типизированный AST готов, можно компилировать дальше. Задача отработанная до автоматизма и весьма тривиальная.
ну и какие плюсы здесь дают именно макры ? такое количество работы с AST делает это практически компилятором... причем не очень эффективным... потому что внедрение оптимизатора, для которого нужно промежуточное представление, сделает это ещё более компилятором... чего конечно допустить нельзя ! потому что макры !
Почему это допустить нельзя? Чем это макры несовместимы с компиляцией? Метапрограммирование на макрах позволяет настраивать один такой язык над другим, естественным путём, с максимально возможным code reuse, тогда как классический компилятор, не имеющий доступа к рантайму целевого языка, сделать не в пример сложнее.
ладно анонимус, может ты и прав, но я приличных компиляторов на макрах не видел (ссылки ?) по мне, транслятор (c стандартыми либами для лексера/парсера/итп) написать проще... и лисп - далеко не идеальный бекэнд язык... си или ллвм лучше, больше свободы.
Там правда Лисп специфичный - с goto, с ассемблерными вставками, и ты ды. Как раз как низкоуровневый бэкенд самое то, если бы не .net. Ищу теперь хоть немного портабельный способ делать ассемблерные вставки в Common Lisp.
> Ищу теперь хоть немного портабельный способ делать ассемблерные вставки в Common Lisp.
В стандарте они не оговорены, тут я не знаю как их можно делать портабельными, только через FFI в рамках одной системы, уже под другую надо дотачивать.