![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
piggymouseАсилил писульку Стиви про NBL. Вообще конечно чувак должен был понимать, что предсказания такого масштаба из уст сотрудника Гугля вызовут у публики однозначную реакцию.
А вы как думаете, кто станет NBL?
Особенно хорошо конечно это читается вскоре после писульки Рэндса про программирующих менеджеров. Советую тем, кто этого ещё не делал, употребить эти два текста совместно. А я пошёл пить лекарство и много думать.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2007-02-13 11:28 pm (UTC)А вот если говорить абстрактно, на тему того, какие условно новые фишки могут/обязаны попасть в мейнстримовый язык будущего, то я вижу целых две штуки:
1) Нативная поддержка массивной параллельности. Летом в МГУ приезжал технический директор Микрософта и сказал, что они там у себя в Микрософте рассчитывают на тысячеядерные десктопы через десять лет. 'Nuff said, imho, в то время как Стиви про мультитредовость что-то дико невнятное сказал, что будет, да, но так, как обычно.
2) Прямой доступ к процессу компиляции. Не AST macros, а именно прямой доступ, как в форте, например. Чтобы можно было писать using (Lang.Lisp) { some lisp code } или что-нибудь похожее, но чтобы эта самая Lang.Lisp реализовывалась средствами языка же. Это следующий логичный шаг в цепочке "возможность заводить собственные имена переменных/процедур (macro assembler)", "возможность создавать собственные типы данных (структуры) (C/macro assembler)", "возможность заводить собственные абстракции (OOP)". Причём сейчас необходимость уже вроде видна невооружённым глазом: в третьем шарпе появился кусок SQL синтаксиса, соответственно возникает резонный вопрос, почему именно разработчики решают, какой именно синтаксис вводить в язык?
no subject
Вторая фича внушает уважение, но с ней я вижу две проблемы: большую (цена разработки IDE и прочих тулзов вырастет ещё на порядок, потому что кто-то же должен будет сказать "от этой скобки до этой используй такой-то syntax highlighting, Intellisense™ etc.") и небольшую (не раскрыта тема того, на какую фазу компиляции предполагается влиять; разумный IMO вариант — иметь сменные компиляторы в байткод типа JVM/CLI, а из байткода пусть just-in-time компилирует уже спецзаточенный зверь от вендора; однако, такой вариант сильно ограничивает смешивание языков с действительно сильно отличающейся средой исполнения).
no subject
Date: 2007-02-14 08:57 am (UTC)А большая проблема на самом деле является частью ещё большей проблемы. Вот я сказал "как в форте, например", а в форте же всё очень просто и незатейливо: лексический анализатор разделяет лексеммы по пробелам (и его, вроде, никто не трогает во избежание), а синтаксический реализует самый тупой вариант рекурсивного спуска -- берём очередную лексемму и сразу решаем, что делать дальше, без всяких трекбеков етс (можно, наверное, попытаться что-нибудь понетривиальней вставить, но опять же сомневаюсь, что кто-нибудь это делает, хотя один фортофанат мне как-то говорил, что прецеденты вроде были). В результате множество просто-реализуемых языков получается довольно специфическое.
А вот как сделать настраиваемый LALR автомат, да чтобы ещё это и прозрачно было, и настраивалось прям из кода, а не из отдельного файлика, и чтобы ошибки отлавливались (включая конфликты при попытке использования разных синтаксисов -- до того, как кто-нибудь попытается эти синтаксисы использовать вместе), и с достаточно гибким определением момента, когда разбор нужно прекращать (чтобы добавить в синтаксис очередной элемент, например) -- это непонятно. Зато если это сделать, то интеллисенс с хайлайтом приложатся автоматически, скорее всего (дописываем к состояниям автомата ещё какую-то инфу и всё, ИДЕ же и так код постоянно разбирает, чтобы обычный интеллисенс работал).
Я не знаю, может быть эта задача в общем случае и не решаема удовлетворительным образом, а может наоборот вполне решаема, причём индуктивно, через маленькие плавные изменения, а не построением Единой Всеобъемлющей Стройной Системы. Неизвестно!
no subject
Date: 2007-02-14 08:39 pm (UTC)Это фсмысле Javascript'овского eval?
Самое смешное, что практически все нужные человеку фичи были в пятом Клиппере. Я тут недавно ходил на презентацию, где чувак (главный архитектор monster.com) в течение полутора часов из XML и C# пытался сваять то, что в Клиппер было встроено в язык :)
no subject
Date: 2007-02-15 11:10 am (UTC)Гыгыгыгы!
no subject
Date: 2007-02-15 12:11 pm (UTC)Там были:
- конвенция по умолчанию, что количество переменных в вызове функции и в её описании может не совпадать (например, если функция f(a,b,c,d) вызвана как f(a,,c), то реально вызов выглядит как f(a,nil,c,nil);
- офигительный препроцессор, позволявший вводить новые команды (мы пользовались какой-то библиотекой для виндовсподобных окошек под досом; там были функции типа OpenWindow(fromX, fromY, toX, toY, borderSize, borderColor, backgroundColor и ещё миллион параметров; естественно, вызывать, даже пропуская параметры, значения которых подставляются по умолчанию, неудобно - пользуясь препроцессором, они вводили новую команду, соответственно вызов выглядел как WINDOW FROM (fromX,fromY) TO (toX, toY);
- замечательная концепция code block - кусок кода, хранящийся в переменной, который можно вызвать в любой момент времени (фактически closure); учитывая, что куски кода можно хранить в базе или даже вводить с клавиатуры, можно было такого наворотить...
- офигительный оператор dbEval, у которого были параметры - имя таблицы, первая запись для обработки (по умолчанию 1), условие выхода (по умолчанию EOF) и code block, который нужно выполнить над каждой записью. С его помощью можно было делать почти всё.
Ну и для особо одарённых, туда можно было подключать объектные файлы, скомпилированные на С - была куча народа, которые в свободное от работы время на Клиппере писали игрушки и сетевые драйверы :)
no subject
Date: 2007-02-15 12:26 pm (UTC)Моё "гыгыгыгы" скорее ностальгическое.
no subject
Date: 2007-02-15 09:54 am (UTC)ссукасобака через пару лет выйдет - так это не язык, а ОС.