Семинар по языку Python в Киеве

> У ctypes есть большой недостаток: он не годится для C++. :) А так, 
> действительно, рулит.

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

> Это и SIP и SWIG умеют. :)

Основная причина использования boost::python возможность легко
мешать различные уровни автоматизации генерации оберток. Ничего 
подобного никто больше не умеет. Я могу легко часть файла
полность на откуп gccxml отдать, часть ф-ции написать с интерфейсами
из классов boost::python а для части указать явные спецификации
отображения и все будет правильно поднято и опознано.

> Я умею и могу пользоваться плюсовыми шаблонами, если сильно прижмёт, 
> но никогда их не любил. :) 

Самая мощьная вещь в программировании за последние лет 10. IMHO.
В смысле совмещения уникальной гибкости с высокой скоростью.
Их даже к фортрану пытаются прикрутить счас.

> Поэтому мини-языки SIP и SWIG для меня 
> гораздо приятнее этого убогонького недоязычка, 
> автору которого место в 
> дурке или на погосте. (с)

Я тут че то IMHO не заметил нигде в тексте 8((.
В отличии от SIP и SWIG "недоязычок" является полноценным C++ кодом
(а не велосипедом, пусть и специализированным), со всеми вытекающими
например с возможностью применять внутри него все возможности
языка.А его авторы входят в комитет по стандартизации C++ и что бы Вы 
по поводу С++ не думали в дурку вроде не собираются и уж явно сделали 
в программировании поболее всех кто когда либо постился на LORе. 
Полученные файлы являются обычными заголовочными файлами так-же со
всеми вытекающими. Короче если Вы серьезно пишете на C++ то
boost::python ОЧЕНЬ полезная вещь . Хотя бы как замена PyCXX.

> Самая мощьная вещь в программировании за последние лет 10.

Прям мощнее, чем Лисп? :P

Я к тому, что от этих шаблонов тащишься только до тех пор, пока не узнаешь о Лиспе. Потом начинает мучить странное чувство, что что-то с ними не так.

> но и в самом деле, elmer и ctypes разными вещами занимаются и никак не взаимозаменяемы.

Тогда процитирую оттуда же:

It should be noted that extending Python and embedding Python is quite the same activity, despite the different intent.

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

> Прям мощнее, чем Лисп? :P

Товарищи любители лиспа. Задрали тыкать его куда ни попадя.
Знал одного человека, который так от fort тащился.

Вам нравится лисп - пользуйтесь.

Сначала обращаем внимание на слово СКОРОСТЬ. Затем 
учим С++, знакомимся с классами типа std::iterator_traits,
а после этого с ACE. Вы неосилили шаблоны дальше std::vector<int>?
По моему дела обстоят именно так.

Много серьезного софта ниписано на лиспе? Много под него серьезных 
библиотек/frameworks(расчеты,ООБД,аналоги ACE,ROOT,Django,Zope...)? 
Когда лисп будет хотя-бы в одном проценте программистских контор я 
подумаю о его серьезном изучении. 

> пока не узнаешь о Лиспе

Видеокурс мита достаточное знакомство? Не попадает. IMHO.
От С++/шаблонов по скорости даже близко.
Если мне понадобятся такие возм. то лично 
я возьму питон с плюсами.

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

Я сам пишу на C++ и Питоне. :) Но таки разве вам не хотелось бы, чтоб шаблоны C++ были такими же мощными, как лисповские макросы? ;) Увы, на плюсовых шаблонах даже простые вещи делаются сложно, а уж про сложные я молчу. И да, во многих лиспах есть опциональная статическая типизация, в том числе в CL и Lush. Последний вполне может конкурировать по скорости с C++. Ещё есть OCaml c Caml4p, есть MetaOCaml. Есть, наконец, Template Haskell. Всё равно будете говорить, что шаблоны C++ - верх совершенства?

> Но таки разве вам не хотелось бы, чтоб шаблоны C++ были такими же 
> мощными, как лисповские макросы? ;) 

Мне много чего не хватает в С++. В т.ч. и в шаблонах, но по 
сов. возможностей я не вижу другого выбора.

> И да, во многих лиспах есть опциональная статическая типизация, в 
> том числе в CL и Lush.

Если они умеют перезагрузку ф-ций(статическую на этапе компиляции),
если их макросы умеют частичную специализацию как в С++. Т.е.
есть например аналогично этому(один из примеров):

template<class X>   class Y{....};
template<class X *> class Y{здесь что-то другое};

Y<int> c;
Y<int *> c2;//разные классы

Тогда да. Это хороший аналог шаблонов. Если нет то толку от них мало
(IMHO).Аналог ACE например не реализуешь никак(например).

> Последний вполне может конкурировать по скорости с C++.

Я думаю Вы имели в виду что отставание не катастрофическое а 
всего раза в 2-3? Даже если это дейсвительно полностью компилируемый 
лисп (что достигается это за счет усечения чисто лисповых фич таких
как манипуляция кодом во время исполнения) то для него нет 
компиляторов подобных icpc(intel),pcpp(portland group) или ,хотя бы,
g++. В такое я готов поверить.

> Ещё есть OCaml c Caml4p, есть MetaOCaml. Есть, наконец, Template 
> Haskell. Всё равно будете говорить, что шаблоны C++ - верх 
> совершенства?

Из того что Вы привели ничего не знаю дальше типов языков. Соотв.
и сравнивать не могу. Но то что толковых либ нет ни под что из 
перечисленного резко сужает возможности применения встроенного 
в них добра.

Поправлю в свете этого свою фразу про шаблоны. Она относится только
к mainstream языкам : java,C#,object paskal,basic.  Возможно что
были придуманы более хорошие(удобные, мощьные) вещи. Но тут я привык
руков. фразой "Жираф большой, ему видней". В смысле что плюсы 
стандартизовались несколько лет коллективом совсем не глупых людей.
И еще тысячи слали свои Ench. Proposal.
Ни один другой язык не получил к себе столько внимания в этом смысле.
Питон,руби,перл, к сожалению, не имеют даже близко подобных 
механизмов, в них подобные вещи прих. делать на этапе исполнения, 
причем руками(или либами) от чего еще сильнее страдает скорость.

template<class X>   class Y{....};
template<class X *> class Y{здесь что-то другое};

Y<int> c;
Y<int *> c2;//разные классы

Ну, я еще не настолько силен в Лисп, чтобы приводить контрпримеры.
Однако, сразу бросается в глаза, что для Лиспа в такой постановке
задача абсолютно не имеет смысла. Ибо нет деления на автоматическую
память и кучу, а также ссылочной арифметики.

Даже если предположить, что пусть в первом случае будет класс X,
а во втором -- Y, то и тогда динамическая типизация, по идее, тоже
делает это бессмысленным. А если даже и найти подходящий практически
осмысленный пример на эту тему, так еще вопрос, нужна ли в таком случае
высокая производительность? В общем, потягаться на предмет
производительности в подобной постановке задачи можно, но изначальная
ориентация на сферических коней в вакууме на мой взгляд делает эту
задумку слегка неразумной.

Опять же, есть еще такая ядреная штука, как мультиметоды, которую я все
еще ниасилил, ибо не вижу реального применения. Возможно, по тем же
причинам, что и в этом случае :-).

> Ну, я еще не настолько силен в Лисп, чтобы приводить контрпримеры.
> производительности в подобной постановке задачи можно, но 
> изначальная
> ориентация на сферических коней в вакууме на мой взгляд делает эту
> задумку слегка неразумной.
...
> лил, ибо не вижу реального применения. Возможно, по тем же
> причинам, что и в этом случае :-).


Час попробую пояснить.
У меня есть шаболнный класс Y, который я пользую для реализации
какого-то функционала. Он написан в общем виде для всех типов.
Но потом мне приходит в голову идея что алгоритмы можно эффективнее
(по другому) реализовать в случае когда параметром шаблона будет 
указатель. И я делаю спец. шаблона - шаблонный класс, который 
совпадает по имени, но имеет входной тип не X а (X *). Причем внутри 
устройство классов Y может кардинально отличатся(може тне быть каких-то полей) или наоборот появится новые, я могу этот класс 
унаследовать от другого и т.д. Компилятор выберет наиболее подходящий 
класс в момент инстанцирования(т.е. при компиляции). Возможности таких 
вещей огромны, фактически я могу имитировать много питоновского
функционала, связанного с динамической типизацией. Только все это
будет ЛЕТАТЬ т.к. делается компилятором на этапе компиляции один раз
и на всегда. Вот еще жесткий пример. Я делаю класс массива на стеке.

template<class X,int size> class sarr{
  private:
    X data[size];
  public:
    тут ф-ции.
}

sarr<int,10> k;

А потом замечаю что очень часто использую массивы с размером 4.
Сосстветственно я беру и пишу специализацию

template<class X,4> class sarr{
  private:
    X data[4];
  public:
    тут ф-ции.
}

А в нем разворачиваю все циклы и получаю по всей проге ускорение.

Используя подобные техникм blitz разрывает встроенные в фортран 
массивы по скорости векторных операций в разы.

Я Вас уверяю что это никакие не кони в вакууме а очень полезные
вещи на которых построен ВЕСЬ С++. Посмотрите на реализацию стан-
дартной библиотеки. Все серьезные либы под С++ крайне
интенсивно используют шаблоны в целом и подобную технику в частности.
Если Вы не используете активно С++, то хотя бы гляньте на возможности
того же ACE(достал уже ним да )). Это монстр, поведение которго
можно до неузнаваемости изменить с пом. параметров шаблонов.
В некотором смысле многие либы использут шаблоны как css для html
(кроме прямого назначения) имитируя динамическую типизацию.
Это классы настроек. И в отличии от virtual здесь нет никаких
накладных расходов на этапе исполнения => скорость очень высокая.

Простите за оффтоп, но это нормально, что gccxml у меня дохнет на заголовочных файлах от gcc-4.1.1? :P

$ cat hello.cpp
#include <iostream>

int main()
{
        std::cout << "Hello cruel world!" << std::endl;
        return 0;
}
$ make hello
g++     hello.cpp   -o hello
$ ./hello
Hello cruel world!
$ gccxml hello.cpp -fxml=hello.xml
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4/string:53,
                 from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4/bits/locale_classes.h:47,

                 from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4/bits/ios_base.h:47,
                 from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4/ios:50,
                 from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4/ostream:45,
                 from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4/iostream:46,
                 from hello.cpp:1:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4/bits/basic_string.h: In
   member function `bool std::basic_string<_CharT, _Traits,
   _Alloc>::_M_disjunct(const _CharT*) const':
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4/bits/basic_string.h:329: error: syntax
   error before `;' token
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4/bits/basic_string.h:330: error: syntax
   error before `;' token

template<class X,int size> class sarr{
  private:
    X data[size];

template<class X,4> class sarr{
  private:
    X data[4];

Насколько я понимаю, конкретный размер все-равно определяется на момент
конкретизации шаблона (потому как шаблоны -- не более, чем продвинутые
макросы). То есть,

sarr<int,4> k;

и

sarr<int> k;

эквивалентны в плане производительности. Или Вы можете привести
соответствующие бенчмарки, показывающие обратное?

> Только все это будет ЛЕТАТЬ т.к. делается компилятором на этапе
> компиляции один раз и на всегда.

"Преждевременная оптимизация является причиной большинства проблем в
программировании" (С) Д. Кнут. Это же касается и выбора средства для
решения задачи. Судя по приведенному примеру у меня вообще
закладывается подозрение, что Вы корректно определяете место, которое
необходимо оптимизировать.

Если быть более конкретным, то я предполагаю, что в приведенном Вами
примере Вы пытаетесь продемонстрировать преимущества статического
ограничения на размер массива. В Лиспе есть возможность задавать как
динамические, так и статические размеры массива. В Вашем примере на C++
размер массива будет ограничен в каждом конкретном случае (или Вы
можете привести пример, где можно использовать шаблон с динамическим
значением?), у Лиспа при статической подстановке эта оптимизация будет
выполняться автоматически каждый раз, когда задается конкретный размер
массива (впрочем, в C++ это будет происходить точно так же).

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

>Где именно ожидается прирост скорости? При размещении, при выталкивании?

Он имеет ввиду что для ситуации частичной спецификации шаблона он может применить более оптимальный алгоритм:

#include <iostream>

using namespace std;

template <class X, int size>
class test
{
private:
X data[size];
public:
void hello() { cout << "generic" << endl; };

};

template <class X>
class test<X,4>
{
private:
X data[4];
public:
void hello() { cout << "optimized"<< endl;};

};

int main(void)
{
test<int, 10> ten;
test<int, 4> four;
ten.hello();
four.hello();
return 0;
}

output:

$./test
generic
optimized

Вот там и будет "прирост в скорости" и т.д.

> Вот там и будет "прирост в скорости" и т.д.

Ну так вот именно это я и подразумеваю под "сферическими конями". На Лиспе так тоже можно написать. Можно конкретнее, во сколько раз будет выше прирост скорости от замены одной статической константы на другую?

>> $: << '../src'

>конечно, японский - красивый язык, особенно на рисовой бумаге. руби, насколько я знаю, детище японца, а им не привыкать к тому, что на каждый чих - свой иероглиф. конечно, лаконичность английского удручает, но он, по крайней мере, обходится 26 буквами. у меня тако чувство, что для то го, чтобы комфортно "читать" руби, надо сначала начать чувствовать себя комфортно в японском. ничего личного, просто мысли вслух живущего сопровождением чужого ... кода.

А Вы пробовали понять что здесь написано? Перл ни разу не видели? Тут после прочтения трех глав Programming Ruby любой поймёт что здесь написано:

Как мыслит типичный рубист:

к $: вызывается метод << с параметром '../src'

$: - глобальная переменная

<< - добавить элемент в массив

'../src' - строка, путь

Даже не зная что храниться в $: можно понять что там лежат пути к каталогом, где надо искать либы.

А переменной $-) там нет? Или $_$. Или @_@, а фигли, язык из смайликов - это фича!

>А переменной $-) там нет? Или $_$. Или @_@, а фигли, язык из смайликов - это фича!

Это вообще-то из перла пришло. А перл придумали не японцы, так что про японию не не надо сочинять.

а \r\n тебя не смущает? Вот в вижуал бейсике строка пишется так:

"Hello world" & VbCrLf

Правда здорово? Срочно ставь венду! А фигле, смайликами типа \r\n писать...

> А Вы пробовали понять что здесь написано? Перл ни разу не видели? Тут после прочтения трех глав Programming Ruby любой поймёт что здесь написано: > > Как мыслит типичный рубист: > > к $: вызывается метод << с параметром '../src'

совершенно неочевидно, что это вызов метода, скорее похоже на оператор <<

> > $: - глобальная переменная

и сколько же их таких?

> > << - добавить элемент в массив

всегда или, все-таки, это - перегруженный оператор для конкретного типа?

"столько образования на один бифштекс!" (ц) а.райкин

> Это вообще-то из перла пришло.

И вместе с перлом бы ушло прямо у могилу, если бы Мацумото, как сорока-воровка не подбирал всякие какушки и блестящие перделочки. Ведь смайлики - это так красиво! Всяко лучше убогого sys.path!

>совершенно неочевидно, что это вызов метода, скорее похоже на оператор <<

Я же предупредил что надо прочитать хотя бы несколько глав из Programming Ruby. В ruby любой оператор - это метод

>и сколько же их таких?

Вам действительно необходимо их знать? Зачем?

>всегда или, все-таки, это - перегруженный оператор для конкретного типа?

это метод << класса Array.

>И вместе с перлом бы ушло прямо у могилу,

Нет уж лучше пусть питон с бейсиком уйдут туда

>если бы Мацумото, как сорока-воровка не подбирал всякие какушки и блестящие перделочки. Ведь смайлики - это так красиво! Всяко лучше убогого sys.path!

Вы на VB посмотрите - там ещё проще. Как раз для быдлокодеров, которые увидев неочевидные для них вещи начинают винить во всём язык программирования. От зависти? Или у питонистов какой-то комплекс на двоеточия?

А рубибыдлокодеры и правда считают, что чем непонятнее, тем круче? Тогда brainfuck and befunge ист дер ихний друкъ. Правда, они слишком концептуально чисты, в отличие от вашего громоздильного раби о семи золотых костылях. Вот уж вавилонское столпотворение, тут и Дилан и Смолток, и перловка между строк! Мля, мне это напоминает понты младшеклассников, только что узнавших 5 иностранных слов и на улице выдающих себя за иностранцев: "Вельми кошерно бы заимпрувить имплементацию антиалиасинга фонтов в мозилле и поенхансить дас хинтингсуппорт ин ден фритайпен шаред либе! Вив ля гран бидлёкод е ле глориёз бидлёкодери!!! Мацумото-сенсей банзай нах! КТУЛХУ ФХТАГН!!!".

>А рубибыдлокодеры и правда считают, что чем непонятнее, тем круче?

А питонобыдлокодеры и правда считают, что если им непонятно, то никому не понятно? Почему они не могут понять что есть языки, которые сперва надо понять, а потом уже говорить про них.

Напоминают пятикласников, увидевших лисп и кричащих "ой, тут много скобок, значит это гавно".

PS. Человеку видевшему только лисп ваш питон покажется страшнее brainfack-ов. Научитесь наконец мыслить более глобально, а не по примерам в MSDN и мануалах

Остаётся только надеяться, что придёт GPLная Жабба и зохавает их больной моск.

> Почему они не могут понять что есть языки, которые сперва надо понять, а потом уже говорить про них.

Потому что автор языка должен заботиться о том, чтоб синтаксис а) был логичным, б) содержал как можно меньше особых случаев и исключений, и в) легко поддавался визуальной токенизации. И Гвидо об этом думает. Ибо читал в своё время умные учебники. А Ларри был лингвистом и вместо учебников по CS читал статьи о редукции диффузных умляутных форм и абруптивизации (глоттализации) согласных в американских языках. А потом писал диссертацию о влиянии этих статей на на синтаксис языка Perl. А Матц вообще кроме хентайной манги ничего не читал. ДАВИТЬ ТАКИХ БЫДЛОКОДЕРОВ ИБО НЕ ЗНАЮТ, ЧТО ТВОРЯТ.

> А питонобыдлокодеры и правда считают, что если им непонятно, то никому не понятно?

А теперь встань и скажи, перлобыдло, громко, чтоб мы все слышали: "Свидетельствую, что $: понятнее и элегантнее, чем sys.path". Если хватит смелости. Потом тебя отвезут обратно в палату, дадут компота и больше не будут обижать.

> Свидетельствую, что $: понятнее и элегантнее, чем sys.path

А чо? Тут любой дурак догадается, что $ обозначает sys, потому что напоминает букву S. А : обозначает path, потому что компоненты PATH в юниксе всегда разделяются двоеточием. Интуитивно понятно как "$@ твою мать", Ларри - бог, а Мацутомо - пророк ево.

>Можно конкретнее, во сколько раз будет выше прирост скорости от замены одной статической константы на другую?

Та не от замены! Эта константа делает что-то вроде pattern matching по которому выбирается реализация алгоритма.

И что, в лисповых макрах pattern matching уже отменили? Уж не говорю про хаскель и камл.

>И что, в лисповых макрах pattern matching уже отменили? Уж не говорю про хаскель и камл.

Епт. Как знал что не надо было так говорить. При чем тут паттерн матчинг - мы не его апсуждаем и тем более не его в плюсах, а просто как частичной спецификацией шаблона в плюсах можно шаманить различные алгоритмы.

> Человеку видевшему только лисп ваш питон покажется страшнее brainfack-ов.

"CNN сообщает: в лесах Массачусетса обнаружен юноша, воспитанный в стае лиспобыдлокодеров".

> Поправлю в свете этого свою фразу про шаблоны. Она относится только
к mainstream языкам : java,C#,object paskal,basic. Возможно что
были придуманы более хорошие(удобные, мощьные) вещи.
стоит взглянуть на http://nemerle.org/

> Я же предупредил что надо прочитать хотя бы несколько глав из Programming Ruby. В ruby любой оператор - это метод

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

> Вам действительно необходимо их знать? Зачем?

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

> это метод << класса Array.

похоже на правду, но это не делает руби более читабельным

> Нет уж лучше пусть питон с бейсиком уйдут туда

а что останется, кроме рельсов, которые кроме как для простеньких типовых задачек, никуда не "едут"? поверьте мне, я потратил несколько месяцев (слава богу, мне дали это время) на проверку всех наиболее вероятных вариантов. руби-на-рельсах едут *только туда, куда их разработчики хотят ехать*! шаг влево или вправо карается немыслимыми костылями и полным хаосом.

> Или у питонистов какой-то комплекс на двоеточия?

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

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

> Простите за оффтоп, но это нормально, что gccxml у меня дохнет на 
> заголовочных файлах от gcc-4.1.1? :P

Здесь сплошной оффтоп))).
Попробуй вынуть из CVS последнюю версию. Может быть поможет.

to eugine_kosenko

Подустал я Страуступа пересказывать )). Особенно
учитывая что Вы меня не читаете. Не нравятся шаблоны - 
пишите на лиспе. Хороший язык для поделок. Только я могу Вам
100% гарантию дать что при сегодняшнем уровне языковых средств
(я говорю о MIT Sheme) никуда далее академического языка
она не продвинется. Есть конечно крайне редкие исключения(AutoCAD), но
 это именно исключения - нашелся ОЧЕНЬ большой любитель.

И в частности потому что есть С++ с шаблонами.
И это совсем не IMHO, это констатация факта.

<quote>
template<class X>   class Y{....};
template<class X *> class Y{здесь что-то другое};
</quote>


Господа, я бесконечно преклоняюсь перед вашими глубокими познаниями в 
С++, однако несочтите за нескромность, но 

template<class X *> class Y{здесь что-то другое};
не разу не частичная специализация template<class X>   class Y{....};
должно быть:
template<class X>   class Y<X*>{....};

за сим ...

А с какой книги лучше начать изучать питон?

Чтобы по качеству была не хуже Pragmatic Programming Ruby

>А переменной $-) там нет? Или $_$. Или @_@, а фигли, язык из смайликов - это фича!

Оказывается питон тоже язык смайликов:

def __init__ (self, contents=[]) : self.contents = contents [:]

:]

>И в частности потому что есть С++ с шаблонами.
>И это совсем не IMHO, это констатация факта.
>koder (*) (24.11.2006 11:39:05)

А вот вам тоже "не IMHO" - только си++приплюснутые не видят что эре C++ приходит конец ... Еще не пришел - НО! Сомнений уже ни у кого нет - С++ будет потихоньку сдавать позиции. Я тихонько надеюсь что не Яве а какому нибудь сакцессору OCaml'а - но тут ХЗ...

О, интересная точка зрения! Ну, может быть, до конца еще далеко, но уже появился очень сильный конкурент в лице C++/CLI - наследника старого доброго C++, но заточеннного под работу на виртуальной машине, конкретно .NET CLI. По-моему скромному имху такое можно сделать не только для .NET, но и для других cхожих систем, где все вертится вокруг некой виртуальной машине.

По поводу синаксиса специализаций прогнал ((. Последние 8 месяцев
пишу на чистом C под встраив. систему, подзабыл ((.

> не видят что эре C++ приходит кон
> Сомнений уже ни у кого нет - С++ будет потихоньку сдавать позиции.

Во первых подобные басни мы слышим еще со времен массового внедрения
Васика. Потом была Ява. Безусловно доля плюсов будет уменьшатся.
Но во-первых никак не за счет уже стоящей одной ногой в гробу Явы,
а из-за шарпа. А задачи под С++ будут еще очень долго.

> Я тихонько надеюсь что не Яве а какому нибудь сакцессору OCaml'а 

К счастью ни тому ни другому. Ну а про Ocaml так это только
под БУ-га-га подходит. В обозримом будущем ничего альтернативным
языкам не светит.

У меня возникает мнение что люди(большинство) которые тут посты пишут 
никакого отношения к коммерческому или вообще какому либо серьезному
программированию не имеют. Иначе у них не было бы таких
розовых очков на счет возможностей Ocaml/Lisp/Fort/.... 
Я так понимаю это или студенты или админы, которые от нечего делать 
всякую муть учат, или вообще пионэры думают что умных слов набрались.
Да же в некомм. программировании - гляньте на дистры линуха. Ну 
че много там прог не на C/C++/Java? Или иксы писанные в MIT, оплоте
Sсhema - они на чем? Если еще сами не доросли смотрите
на чем пишут большие бородатые дяди у которых получаетцо.

> А с какой книги лучше начать изучать питон?
> Чтобы по качеству была не хуже Pragmatic Programming Ruby
Pragmatic Programming Ruby не читал, ничего сказать по эт пов. 
не могу. Лучше всего начать с официальной доки. Там есть 
хороший туториал. Есть много неплохих книг но учитывая какой 
прорыв питон сделал за последние 5-6 лет все они СИЛЬНО устарели.
Из новых IMHO толковых нет.

Да кстати, еще. По пов. конца С++. В Linux/Unix плюсы IMHO переживут 
и яву и шарп и еще потопчутся по их могиле. Примерно как 
Fortran в научн. программировании успешно похоронил 
APL/PL1/Algol/тут_еще_ВАГОН_всякого_языкового_хлама.

Думаю всех переживёт только javascript

Сейчас ему (в его основной области применения) даже альтернативы не предвидятся (особенно под Unix/Linux)

>кстати, о лиспе. никак не пойму, чего все так уповают на эту >посредственность. если уж и вправду нужна лаконичность, forth - оно >самое.

Типа на Лиспе Форт нельзя соорудить как встроенный язык, так же как и С++ шаблоны для лисповых макр - лишь частный случай. Если С++ расширяемый и шаблоны так прекрасны, почему boostовская лямбда такая убогая ?

>Только я могу Вам 100% гарантию дать что при сегодняшнем уровне >языковых средств (я говорю о MIT Sheme) никуда далее академического >языка она не продвинется.

И чего Вы к MIT Scheme привязались. Расскажите лучше о CL, в каком месте он академический и как Вы будете то, что на нем пишется, делать на С++ (и с какой СКОРОСТЬЮ) ?