Брюс Эккель признался в бессилии

>Это Хоар, Дейкстра, Брукс? Или кто?

Дейкстра. Стыдно незнать...

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

Не нужно забывать ни о свойствах операции абстрагирования ни о свойствах реальной аппаратуры. Если в гипотетической аппаратуре заложена поддержка многопоточности, вы что всё равно будете наворачивать свою машину состояний? Или всё-таки станете писать с многопоточностью? Это аналогично спорам по поводу jit,byte-кода Java, если есть процессор кушающий нативный код построенный компилятором Java, разве не логично под этот процессор только такой код и генерить? Другое дело что этот код может дать как сама Java так и C++ или там python :-)

Дейкстра

Всем, ответившим "Дейкстра" - СПАСИБО! ;)

Всем, кто еще ответит - спасибо заранее. :D

Вырождение начинается с мистификации достижений предков. Как-то раньше писали многопотоковые программы и некоторые даже не падали. А что привыкли чтобы вам место падения указывалось большой красной стрелочкой? А на 2.2 не отлаживали таких монстриков? А там потоки в core-ке сами в себя кладуться и ничего увидеть нельзя :-) Слабачки, для вас умные манагеры напридумывали PSP, который, если мусор выкинуть, сводится к требованию читать собственный код. Читайте, читайте, или вы писатели? А что на Java нельзя так написать чтобы баг вылазил через 10000 циклов обработки очередного запроса из-за пропущенной синхронизации программного потока?

> Вырождение начинается с мистификации достижений предков.

Это ответ мне? На какую реплику? o_O

Прошу всех, прежде чем постить, прочитать статью (если сможете).
Автор пишет ("о наболевшем") о том, что ему хотелось бы видеть
в "идеальном" языке программирования. То, что он ссылается на
Python 3K не означает, что это не относиться другим языкaм (C++,
Java).

- многопоточность, параллелизм. Легкость создания многопоточных
программ, threadsafe interpreter.
- легкая инсталяция (one-button installation), incremental update.
- прозрачная связь с GUI libs
- "Smart Libraries", "встроенный" context help - все это связано с RTTI, Reflection:
"I want the component to tell me what it does, how to use it, and even to reach out and wire itself into my program (for example, by looking at the available variables and putting candidates into its argument list, with drop-down menus that allow you to select appropriate alternatives)."
- Support for DSL Creation. Не совсем понял, может кто обьяснит?

... а ведь все эти задачи программисты из оффтопика решают
(и большинство успешно решили) уже многие годы.

Лучше бы он признался в бессилии (половом), чем в ламерстве ...

Неосилил Хаскель и его чудесный STM? Вот придет время, и спохватятся те, кто фп не учил :-)

> Support for DSL Creation. Не совсем понял, может кто обьяснит?

Domain Specific Languages - это сейчас трендово :) Для каждой задачи полагается разрабатывать свой небольшой язык программирования.

> а ведь все эти задачи программисты из оффтопика решают (и большинство успешно решили) уже многие годы.

Причем здесь оффтопик? но фраза "уже решили многие годы" - решает :D

> Линуксу 16! (ЗЫ. Молодая половозрелая девушка, которую надо лишить девственности! l-) ;-)))))) )

Поздний осенний спермотоксикоз бушует среди онанимусов.

Просто данный фрукт живет с книжек по жабе и С. Продажи падают вот он и начинает готовить новую почву для новых книженций.

>>Для каждой задачи полагается разрабатывать свой небольшой язык программирования.

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

> Льва Толстого тоже в топку.

+1. Выкопать - и в топку.

>я по пьяни с А.Н. попутал

Это ваще апокриф.

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

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

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

Собственно про пост: согласен с Эккелем в вопросе EasyInstall и Tkinter (надо срочно менять на wxPython). Остальное - прогон.

> Не знал, что язык определяет мышление?

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

бедняга эккель

> Толстой как бы - профессиональный писатель

он больше морализатор, чем писатель. Раноплановые характеры, за которыми не видно самого писателя (но зато ощущается дух произведения), создавал Достоевский

> надо срочно менять на wxPython

Менять Tk на глючную обёртку вокруг пионерского клона ублюдочного MFC? Дудки.

> Менять Tk на глючную обёртку вокруг пионерского клона ублюдочного MFC? Дудки.

Ладно, PythonGtk или еще что угодно.

Хотя в Tk есть подвижки внешнего вида, как я понимаю он все равно о темах гтк-кт будет никогда не будет в курсе.

Всем, кто будет говорить, что и на яббе и на C++ можно писать многопоточные программы: да, можно, что-нибудь несложное двухпоточное. Но стоит немного усложнить задачу, и мутексы с семафорами взорвут вам моск. Много сейчас софта способно эффективно использовать все 8 SPE процессора Cell? И даже как-то запинав свою программу, вы никогда не дадите голову на отсечение, что в ней ни при каких условиях не будет ни дедлоков, ни сегфолтов из-за несогласованной работы потоков. Брюс Эккель неглупый человек, и всё это уже понял. Местным кулибиным, наверно, ещё лет 5-10 понадобится, чтобы понять. Ибо. Как уже неоднократно было говорено многими умными людьми, модель разделяемой памяти — худшее, что можно придумать для организации взаимодействия между потоками. И традиционные императивные языки, как только речь заходит о многопоточности, начинают сурово просасывать. А теперь все явщики в этом чате резко встают и бегут смотреть на Эрланг как образец правильного подхода к вопросу. Когда вернётесь, продолжим беседу.

> Ладно, PythonGtk или еще что угодно.

GTK под виндами до сих пор выглядит хуже, чем Tk. На маках, подозреваю, тоже.

Вдобавок, я не уверен, что (L)GPL совместима с питоновской лицензией. Это касается и WxWidgets, и GTK, и Qt.

Вдобавок, я не уверен, что wxWidgets/GTK/Qt портированы на все поддерживаемые Питоном платформы.

И вообще, в чём проблема? Надо wxPython — ставим wxPython, надо PyGTK — ставим PyGTK, в любом дистре оно есть. Нельзя ведь всё засунуть в стандартную библиотеку, в самом деле.

> 2ero-sennin *
заинтересовался ... киньте ссылку на Erlang scalability

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

Тебя кто-то заставляет писать с мютексами и семафорами? Сделай себе Occam. Или Erlang. В Си++ это вполне возможно (и делалось не раз).

Вот здесь неплохо написано про Эрланг: http://www.defmacro.org/ramblings/concurrency.html.

> Сделай себе Occam. Или Erlang. В Си++ это вполне возможно (и делалось не раз).

Ссылку? Наверно, очередное шаблонное чудище и пародия на ФП?

Потом, зачем писать на C++? От него бежать надо в ужасе при малейшей позможности.

>> Сделай себе Occam. Или Erlang. В Си++ это вполне возможно (и делалось не раз).

>Ссылку?

Это было сделано еще во времена, когда статьи печатались на бумаге :D

> Наверно, очередное шаблонное чудище

Тогда это еще не было модно. Шаблоны использовались как параметризованные типы, а не средство метапрограммирования.

> и пародия на ФП?

/me зопесал: ero-sennin не знает, что такое Occam ;)

> зачем писать на C++? От него бежать надо в ужасе при малейшей позможности.

На нем нужно уметь писАть, а в некоторых классах задач альтернатива - только Си.

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

Работа с натив-апи для многопоточности действительно пахнет ошибками и дедлоками, но зачем изобретать велосипед и писать очередной CThread?

> Чего гениального в пропаганде христианских заблуждений?!

Ога, и видимо за эту пропаганду его анафеме предали? ;-)

> Ога, и видимо за эту пропаганду его анафеме предали? ;-)

Именно за них.

> GTK под виндами до сих пор выглядит хуже, чем Tk.

Хмм, давно не инетресовался.

> Вдобавок, я не уверен, что (L)GPL совместима с питоновской лицензией.

Тут опаньки, несовместима.

> http://www.defmacro.org/ramblings/concurrency.html.

одни словеса, а где собственно scalability test? Где Hall Of Fame?

>многопоточные программы: да, можно, что-нибудь несложное ... Эккель неглупый человек, и всё это уже понял

http://en.wikipedia.org/wiki/Dunning-Kruger_effect

... people who have little knowledge think that they know more than others who have much more knowledge ...

хотя ... 20 million processes :) !!!
http://groups.google.com/group/comp.lang.functional/browse_thread/thread/e649...

> Имеется в виду "Дисциплина программирования"?

Да, "Дисциплина". Я их все время путаю :-)

> 2DonkeyHot

Прочите те статью (сами не будьте Dunning-Kruger_effect) -
автор поста провокатор.

>> Но стоит немного усложнить задачу, и мутексы с семафорами взорвут вам моск.

Вам

>> Много сейчас софта способно эффективно использовать все 8 SPE процессора Cell?

Мало, и ?

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

Голову-нет , ящик пива , не вопрос

>> Брюс Эккель неглупый человек, и всё это уже понял.

А все остальные, типа, проспаться не могут ?

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

Без разделяемой памяти - это ___принципиально___ сделать невозможно

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

Не надо антропоморфировать с себя

>> Ога, и видимо за эту пропаганду его анафеме предали? ;-)

> Именно за них.

Хорошая пропаганда, выходит, раз так батюшек торкнула :-).

Ну, в таком случае Бруно тоже пропагандировал христианские заблуждения :-).

Уже. И что? Сравнивая поведение Еккеля, утверждающего, "я не могу" и анонимуса, утверждающего "да он туп, вот я...", я нахожу, что это _может_ быть проявлением указаного эффекта:

# incompetent individuals tend to overestimate their own level of skill,

# incompetent individuals fail to recognize genuine skill in others,

# incompetent individuals fail to recognize the extremity of their inadequacy,

>автор поста провокатор.

Причём у него это получается :)

> Пишите автоматы, как завещали древние.

Имя твое неизвестно, напоминание твое бессмертно. Для себя раз и навсегда решил проблему "треды в плюсях", написав класс Thread. Разумеется, это ОО-обертка к обычному КА.

> Без разделяемой памяти - это ___принципиально___ сделать невозможно

Я так понял, имеется ввиду, в существующих архитектурах?

>> Без разделяемой памяти - это ___принципиально___ сделать невозможно

> Я так понял, имеется ввиду, в существующих архитектурах?

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

>> Сделай себе Occam. Или Erlang. В Си++ это вполне возможно (и делалось не раз).

>Ссылку? Наверно, очередное шаблонное чудище и пародия на ФП?

http://sobjectizer.sf.net (короткое описание: http://www.rsdn.ru/article/devtools/sobjectizer.xml, более развернутое описание: http://eao197.narod.ru/desc/so_4_book.pdf)

По сравнению с Erlang-ом это монстр, конечно. Но ваш тезис о том, что на С++ можно написать только приложение с 2-3 потоками опровергает. Поскольку уже пять лет в эксплуатации крутится система, в которой сейчас под 200 агентов и 90 потоков.

>> Как уже неоднократно было говорено многими умными людьми, модель разделяемой памяти — худшее, что можно придумать для организации взаимодействия между потоками. > Без разделяемой памяти - это ___принципиально___ сделать невозможно

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

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

> что-бы потоки обменялись хоть чем-то (блокировкой, сообщением и тд...), нужно что-бы у них была хоть какая-то общая часть

ИМХО, ты поменял местами причину и следствие. Нити по определению исполняются в общем адресном пространстве. Они не обязаны общаться через общую память (могут хоть через TCP-сокеты), но через общую память - самое практичное.

> что-бы потоки обменялись хоть чем-то (блокировкой, сообщением и тд...), нужно что-бы у них была хоть какая-то общая часть

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

Но в любом случае, это вопрос терминологии, и все друг друга поняли, я думаю.

> По сравнению с Erlang-ом это монстр, конечно. Но ваш тезис о том, что на С++ можно написать только приложение с 2-3 потоками опровергает. Поскольку уже пять лет в эксплуатации крутится система, в которой сейчас под 200 агентов и 90 потоков.

Ну не надо всё воспринимать буквально. Можно, если сильно хочется, и на C++, и на брейнфаке, если к нему добавить интерфейс для работы с общей памятью. Но зачем? Чтоб самому потрахаться и других за..ть? %)

> 2DonkeyHot
>> поведение Еккеля, утверждающего, "я не могу".

В статье говориться "Я, _возможно_, никогда не смогу написать корректную
threaded program in C++ or Java, не смотря на годы учений -
это тяжело". Ответ - "используй пакеты/надстройки в C++, Java",
которые позволяют сделать это легко.
При этом, ни о каком приемуществе Pythona, не идет речь, а наоборот
Еккел говорит, что ни Ruby, ни Python - are NOT threadsafe.