[profession,link] Stevey on Next Big Language

[piggymouse]

Асилил писульку Стиви про NBL. Вообще конечно чувак должен был понимать, что предсказания такого масштаба из уст сотрудника Гугля вызовут у публики однозначную реакцию.

А вы как думаете, кто станет NBL?

Особенно хорошо конечно это читается вскоре после писульки Рэндса про программирующих менеджеров. Советую тем, кто этого ещё не делал, употребить эти два текста совместно. А я пошёл пить лекарство и много думать.

Comments

[avva.livejournal.com]

На 95% совпадает с Perl6, но конечно он имеет в виду какую-нибудь херню типа новой версии ECMAScript.

[piggymouse.livejournal.com]

Меня вот что смущает. С одной стороны, он отрицает вовлечённость Гугля (я не знаю, читал ли ты его текст до или после того, как он добавил синенький дисклеймер в начале). С другой стороны, он прозрачно намекает на strong corporate backing, что у меня плохо соединяется с Perl или ECMAScript. Какая из нынешних крупных компаний может вынашивать такие планы и публиковать их?

Кстати, с Perl и O'Reilly у него некая натяжка — я лично не рассматриваю O'Reilly как strong corporate backing; они всё-таки мелковаты, да и ниша не та. Т

[avva.livejournal.com]

У Перла нет конечно никакого strong corporate backing. Да Йегге и не знает ничего особо про Perl6, мне кажется. Corporate backing может быть у Adobe и ее партнеров в случае ECMAScript (потому что новый проект Adobe - Adobe Apollo - может очень сильно выиграть от развития и популярности ECMAScript, мне кажется). Но это только слухи, которые я тоже в каких-то блогах вычитал. Да и в конце концов, может быть просто, что он чушь несет :)

[caseq.livejournal.com]

Мне кажется, Perl6 можно вычеркивать после пункта "C-like syntax" :) Ну и tool support, я боюсь, будут довольно предсказуемые проблемы..

[cmm.livejournal.com]

> он прозрачно намекает на strong corporate backing, что у меня плохо соединяется с Perl или ECMAScript.

ну эта.
гугель вообще-то половину фултаймовых мозильщиков содержит.
а грядущая третья версия той мозиллы всё больше смахивает на кросс-платформенный ECMAScript IDE с HTML-рендерером, ежели судить по соответствующим блогам.

и славно; ECMAScript (спецификация, во-всяком случае) — довольно милый язычок, а грядущая версия так и вовсе выглядит как Scheme с сишным синтаксисом.

[piggymouse.livejournal.com]

Ну вот пишет же он:

Note: after I wrote this entry, one or two commenters speculated that I might be talking about something Google is doing. They're barking up the wrong tree: I may not be the smartest feller ever to fall off the cabbage truck, but I'm not -that- stupid. The speculation in this blog is all based on stuff I've read on the net. It's purely my own ideas and opinions, and I don't speak for Google (nor in today's entry, even -about- Google). You'll have to look beyond Google for clues about NBL. Enjoy!

Как это совместимо? Типа Мозилла не Гуголь?

[cmm.livejournal.com]

Мозилла не Гугель, стопудово.
плюс Гугель неслабо вложился, во всех смыслах, в тот же Питон.
да и незачем, наверное, вообще пытаться всерьёз интерпретировать прогоны г-на Йегге.

[syarzhuk.livejournal.com]

>плюс Гугель неслабо вложился, во всех смыслах, в тот же Питон.

Это где?

[cmm.livejournal.com]

по официальным данным, они пишут на Питоне всё что можно не писать на крестах.
ну и Ван Россума в работниках держат.

[caseq.livejournal.com]

Я думаю что ничего конкретного он в виду не имеет. Он просто фантазирует на тему свойств, которыми должен обладать такой язык -- и, надо признать, у него неплохо получается, хотя вот вещи типа continuation я бы выкинул :)

[piggymouse.livejournal.com]

Ну он же несколько раз говорит, что имеет в виду некое конкретное усилие, про которое он прочитал. Так что это вроде бы не беспочвенная фантазия, а скорее нечто в жанре предсказания про iPhone.

[caseq.livejournal.com]

Я, признаться, раньше товарища не читал, так что не могу с уверенностью что-то утверждать про его стилистику, но мне кажется все отсылки к конкретному языку не расчитаны на то чтобы их всопринимали буквально, какое-то это все "I heard it through the grapevine"...

[dair-spb.livejournal.com]

мда...

после строки "C++ does need to get replaced someday. It's just horrid, and everyone knows it" остальное читал с изрядной долей скептицизма.

Что это вообще за хрен с горы? Понарасплодилось, блин, минетжеров.

[piggymouse.livejournal.com]

Ну какой же Стиви менеджер?!

А насчёт С++ нужно смирить гордыню. Я смирил в своё время.

[c4nae.livejournal.com]

NBL станет албанский. Ну или албанский диалект пролога, чтоб шутить совсем уж по теме.

[vit-r.livejournal.com]

А чего странного?

Билли придумал дот-нет, чтоб забить жабу. Гугл тоже решил, что он толстый и красивый и будет бить Билли новым языком.

А программистов хлебом не корми, дай чего-нибудь новенькое поковырять.

[piggymouse.livejournal.com]

Виталик, ты как-то сам с собой разговариваешь. Если ты ходил по ссылке, то мог прочитать, что товарищ явным образом отрицает, что описывает некую инициативу Гугля.

[vit-r.livejournal.com]

Оп-с. Ну да, прочитал после интенсивного заседания по диагонали, решил, что пророчится поднятие на щит языка AOP, скорее всего для всяких приблуд SOA

[http://users.livejournal.com/_back_in_white_/]

Запустят compiler.google.com тогда и посмотрим :)

[faceted-jacinth.livejournal.com]

По-моему он всё-таки гонит насчёт того, что описывает реально разрабатывающийся язык, а не свои представления о том, как должен выглядеть NBL.

А вот если говорить абстрактно, на тему того, какие условно новые фишки могут/обязаны попасть в мейнстримовый язык будущего, то я вижу целых две штуки:

1) Нативная поддержка массивной параллельности. Летом в МГУ приезжал технический директор Микрософта и сказал, что они там у себя в Микрософте рассчитывают на тысячеядерные десктопы через десять лет. 'Nuff said, imho, в то время как Стиви про мультитредовость что-то дико невнятное сказал, что будет, да, но так, как обычно.

2) Прямой доступ к процессу компиляции. Не AST macros, а именно прямой доступ, как в форте, например. Чтобы можно было писать using (Lang.Lisp) { some lisp code } или что-нибудь похожее, но чтобы эта самая Lang.Lisp реализовывалась средствами языка же. Это следующий логичный шаг в цепочке "возможность заводить собственные имена переменных/процедур (macro assembler)", "возможность создавать собственные типы данных (структуры) (C/macro assembler)", "возможность заводить собственные абстракции (OOP)". Причём сейчас необходимость уже вроде видна невооружённым глазом: в третьем шарпе появился кусок SQL синтаксиса, соответственно возникает резонный вопрос, почему именно разработчики решают, какой именно синтаксис вводить в язык?

[piggymouse.livejournal.com]

О, интересно. Насчёт параллелньости Стиви кстати высказался настолько определённо, насколько он вообще умеет — он там в конце и Erlang похвалил.

Вторая фича внушает уважение, но с ней я вижу две проблемы: большую (цена разработки IDE и прочих тулзов вырастет ещё на порядок, потому что кто-то же должен будет сказать "от этой скобки до этой используй такой-то syntax highlighting, Intellisense™ etc.") и небольшую (не раскрыта тема того, на какую фазу компиляции предполагается влиять; разумный IMO вариант — иметь сменные компиляторы в байткод типа JVM/CLI, а из байткода пусть just-in-time компилирует уже спецзаточенный зверь от вендора; однако, такой вариант сильно ограничивает смешивание языков с действительно сильно отличающейся средой исполнения).

[faceted-jacinth.livejournal.com]

Небольшая проблема действительно небольшая: если уж CLI допускает использование unsafe code (с пойнтерами и прочей радостью), причём существует такая штука, как Managed C++ (хотя я, честно говоря, не в курсе, как именно оно компилится), где прекрасно смешиваются managed и unmanaged классы, то, наверное, "CLI будет достаточно каждому". В крайнем случае можно ещё каких-нибудь аннотаций/атрибутов добавить. Или моего кругозора не хватает на то, чтобы представить "действительно сильно отличающиеся (от CLR) среды исполнения".

А большая проблема на самом деле является частью ещё большей проблемы. Вот я сказал "как в форте, например", а в форте же всё очень просто и незатейливо: лексический анализатор разделяет лексеммы по пробелам (и его, вроде, никто не трогает во избежание), а синтаксический реализует самый тупой вариант рекурсивного спуска -- берём очередную лексемму и сразу решаем, что делать дальше, без всяких трекбеков етс (можно, наверное, попытаться что-нибудь понетривиальней вставить, но опять же сомневаюсь, что кто-нибудь это делает, хотя один фортофанат мне как-то говорил, что прецеденты вроде были). В результате множество просто-реализуемых языков получается довольно специфическое.

А вот как сделать настраиваемый LALR автомат, да чтобы ещё это и прозрачно было, и настраивалось прям из кода, а не из отдельного файлика, и чтобы ошибки отлавливались (включая конфликты при попытке использования разных синтаксисов -- до того, как кто-нибудь попытается эти синтаксисы использовать вместе), и с достаточно гибким определением момента, когда разбор нужно прекращать (чтобы добавить в синтаксис очередной элемент, например) -- это непонятно. Зато если это сделать, то интеллисенс с хайлайтом приложатся автоматически, скорее всего (дописываем к состояниям автомата ещё какую-то инфу и всё, ИДЕ же и так код постоянно разбирает, чтобы обычный интеллисенс работал).
Я не знаю, может быть эта задача в общем случае и не решаема удовлетворительным образом, а может наоборот вполне решаема, причём индуктивно, через маленькие плавные изменения, а не построением Единой Всеобъемлющей Стройной Системы. Неизвестно!

[syarzhuk.livejournal.com]

2) Прямой доступ к процессу компиляции.
Это фсмысле Javascript'овского eval?

Самое смешное, что практически все нужные человеку фичи были в пятом Клиппере. Я тут недавно ходил на презентацию, где чувак (главный архитектор monster.com) в течение полутора часов из XML и C# пытался сваять то, что в Клиппер было встроено в язык :)

[piggymouse.livejournal.com]

Самое смешное, что практически все нужные человеку фичи были в пятом Клиппере.

Гыгыгыгы!

[syarzhuk.livejournal.com]

Ты на нём писал?
Там были:
- конвенция по умолчанию, что количество переменных в вызове функции и в её описании может не совпадать (например, если функция 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, который нужно выполнить над каждой записью. С его помощью можно было делать почти всё.

Ну и для особо одарённых, туда можно было подключать объектные файлы, скомпилированные на С - была куча народа, которые в свободное от работы время на Клиппере писали игрушки и сетевые драйверы :)

[piggymouse.livejournal.com]

Я на нём писал. Это был первый язык, на котором я программировал за деньги.

Моё "гыгыгыгы" скорее ностальгическое.

[109.livejournal.com]

а кто у нас технический директор Микрософта - Рэй Оззи, что ли? этот может пиздануть, да. тем более, что на десять лет никто в здравом уме не планирует. вот красная ссука собака через пару лет выйдет - так это не язык, а ОС.