В продолжение темы “Заморозят ли развитие языка Python”: заморозили таки! Принят документ PEP 3003, объявляющий мораторий на любые изменения в синтаксисе, семантике и встроенных функциях языка Python. Мораторий начнется с выхода Python 3.1 и продлится не менее двух лет (в течении которых планируется выпустить Python 3.2). Т.е. следующие изменения в языке возможны только с Python 3.3.
Оперативно работают, респект!
Да интересно, есть шанс получить существенно ускоренный питон. Как я понимаю гуглевцы на него конкретно наехали по поводу быстродействия
ОтветитьУдалитьВообще-то странно. Python не тот язык, которому нужно предъявлять претензии по поводу быстродействия.
ОтветитьУдалитьИ язык Go, имхо, ну никак не целит в нишу Python-а. (Почитываю ваше обсуждение на RSDN -- много ерунды там написано. Кстати, в D шаблоны появились далеко не сразу -- где-то в районе 2005-2006 годов. Что и затормозило выход D 1.000. А изначально Брайт хотел делать язык без шаблонов).
Так вот, возвращаясь к Go. Судя по Google C++ Code Guidelines (отсутствие исключений, ограничения на шаблоны, не использование STL) Go как раз должен заменить C++ в разработке околосистемного софта (типа http-серверов и прочей лабуды).
А претензии к Python-у в публичных обсуждениях -- это какой-то ложный след.
Да первоначально D был наверно такой же простой как Go. И если ты прав насчет того что Go замена C++ то очень даже скоро мы там шаблоны увидим :).
ОтветитьУдалитьВообще мне тоже показалось что Go именно замена C/C++ и сишных модулей питона. Но язык конечно по выразительности очень близок к D.
А претензии к Python-у в публичных обсуждениях -- это какой-то ложный след.
Наверно, но автор ветки про Go на rsdn как-то все это в одно связал.
Может Брайта надоумит поступок Гвидо ван Россума и они также заморозят Д.
ОтветитьУдалить2SAnty: Десять лет такого не происходило, вряд ли сейчас произойдет. Как я понимаю, у них с Александреску и Ко еще много зайцев в шляпе припрятано. Просто хотят выпустить D 2.0, а потом за нововедения примутся. Помнится, ходили разговоры о поддержке макросов...
ОтветитьУдалитьДа и, имхо, поезд D уже ушел. Года бы на два-три раньше.
Да и, имхо, поезд D уже ушел. Года бы на два-три раньше.
ОтветитьУдалитьНу еще есть шансы, за счет поддержки параллелизма.
>Ну еще есть шансы, за счет поддержки параллелизма.
ОтветитьУдалитьЕсть у меня большие сомнения на этот счет. Поскольку все нововведения в язык добавлялись потому, что авторам языка показалось, что они будут востребованы. Реального использования не было. Та же вирусная константность и иммутабельность -- ну не однозначная это штука. Вот в C++ mutable не от хорошей жизни ввели. Так что есть шансы, что народ попробует D 2.0, набъет шишки и потребует язык серьезно переделать.
Очень похожая константность и чистота функций давно опробована в функциональщине так что если не накосячат в реализации больших проблем быть не должно
ОтветитьУдалить>Очень похожая константность и чистота функций давно опробована в функциональщине так что если не накосячат в реализации больших проблем быть не должно
ОтветитьУдалитьОстается только напомнить, где находятся все эти опробированные ФЯ по отношению к мейнстриму :)
В мейнстриме константность есть только в C++, причем не строгая. Ни в C#, ни в Java, ни в Ruby/Perl/Python/VB/Tcl ее нет.
К тому же в ФЯ иммутабельнось на первом месте изначально. А D императивный язык. И почему нельзя иметь иммутабельный объект с ссылкой на мутабельные данные -- я лично не понимаю.
Ну Эрланг уже вплотную к майнстриму подобрался, F# тоже скоро там будет. Ну и технология же все-равно обкатана, несмотря на немайнстримность использующих ее языков.
ОтветитьУдалитьА D императивный язык OCaml тоже :) У D вполне вменяемое функциональное подмножество, кроме выразительности ничем ни хуже чем у того же OCaml'а
И почему нельзя иметь иммутабельный объект с ссылкой на мутабельные данные -- я лично не понимаю.
Как минимум вся оптимизация и "потокобезопасность" при этом теряется.
>Ну Эрланг уже вплотную к майнстриму подобрался,
ОтветитьУдалитьПодобраться еще не значит стать :)
>F# тоже скоро там будет.
А вот тут сомневаюсь.
>Как минимум вся оптимизация и "потокобезопасность" при этом теряется.
Если у нас есть иммутабельный объект M в котором есть ссылка на немутабельный объект C, то какие проблемы с оптимизацией и потокобезопасностью доступа к объекту M?
PS. По последним сводкам TIOBE, язык D рискует выпасть из первой двадцатки. Индекс TIOBE начинает исправляться :)