Вышел Boost 1.35

C++ вместе с legacy не нужен, Java не нужна, lisp не нужен. D - наше всё. Аминь!

>C++ вместе с legacy не нужен, Java не нужна, lisp не нужен. D - наше всё. Аминь!

анонимус тоже не нужен ? :)

>> C++ вместе с legacy не нужен, Java не нужна, lisp не нужен. D - наше всё. Аминь!

> анонимус тоже не нужен ? :)

И анонимусы не нужны!

> давай, я не против :)

Давайте начнём с перечисления больших успешных проектов, написанных на D? :) Потом можно подискутировать о доступности IDE типа Eclipse для Java и VS для C#. Понятно, что можно хоть в mcedit/notepad писать, но большинству требуется браузер классов, рефакторинг, интеграция с отладчиком и т.п. На следующем шаге можно рассмотреть, как полно D поддерживается стандартным юниксовым тулсетом: autotools, pkg-config, gdb тот же (для gdb деманглер дишных имён писать нужно, как я понимаю?) Про библиотеки тоже можно поговорить. Судя по wiki4d, кое-что есть, но альфа-версии - это аргумент.

Немаловажным фактором является наличие нескольких гуру мирового масштаба, которые бы воспели диферамбы новому языку и своей вилле, на которую они заработали при помощи этого языка. Без этого народные массы на язык смотреть не будут, примером чему является Лисп и небезызвестная статья П.Грэма ;)

+1...вот как они его до хоть какого-то вменяемого состояния допилят. А то писать на нем сейчас что-то сложнее хеловорд или одноразового проекта смысла нет.

> Я бы сказал что конструкторы в С++ по факту ненужны.

Тебе не нужны - не используй.

> Программисты-бобры которым надо не реализовывать гениальный концепт, а писать много кода пользуются методами типа postInit() и Create(...)

И как наличие этих методов противоречит конструкторам?

> Путать зависимость от стандартной библиотеки и зависимость от third-party компоненты не стоит. От third-party должен зависть бэкэнд

Вот только не надо умных терминов из SE - ты собираешься менять хэдер TApplication.h, или нет?

>То, что выигрыш от нее должен окупать затраты на ее использование.

а ты попробуй. И убедишься, что в случае питона выигрыша не будет.

>Вопрос в том, какая степень схожести является приемлемой (== не создающей лишних проблем).

что такое "лишние проблемы" ?

>Бугага. Подумай еще хоть 5 минут, или больше не пиши на эту тему.

лень, чесслово. Подскажешь?

>> Да, кстати, о минимизации необходимости путем REPL... в насквозь статически типизированных Ocaml и Haskell есть REPL. Его наличие не зависит от модели типизации.

> а я говорил, что зависит?

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

> C++ вместе с legacy не нужен, Java не нужна, lisp не нужен. D - наше всё. Аминь!

Тогда сгинь с треда про C++ (в который опять вклиниваются лисповоды) на сайте, написанном на Java! ;)

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

да потому что ты ошипкой в лоб получишь сразу =) Или не получишь, но результат можешь посмотреть сразу.

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

Честно говоря, если бы MOP был не только в CLOS, но и в остальной (не-ОО) части Лиспа, то с его top-level формами можно было сделать и полноценную статическую типизацию. С выводом типов, как в хаскелле.

Мне всегда было интересно, почему почти все, заявляющие "xxx не нужен", на xxx ничего сложнее hello world не писали. Иногда попадаются особо продвинутые, которые говорят "xxx не нужен" после написания 99 bottles of beer.

D сейчас можно использовать по крайней мере как язык для одноразовых скриптов, если скрипту требуется высокая производительность (бывает). C++ как минимум из-за legacy. Java - как один из самых быстрых языков, реализованных для всех основных платформ. У каждого языка есть немалое количество важных преимуществ, иначе их бы _вообще_ никто не использовал. На одном фанатизме даже ОС не выбирают... ;)

>>То, что выигрыш от нее должен окупать затраты на ее использование.

>а ты попробуй.

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

>>Бугага. Подумай еще хоть 5 минут, или больше не пиши на эту тему.

>лень, чесслово. Подскажешь?

Для начала подумай, как определить наличие полей на объектах, отличных от self (аргументах методов и функций); что делать с полиморфными коллекциями; что делать с декораторами.

>Давайте начнём с перечисления больших успешных проектов, написанных на D? :) Потом можно подискутировать о доступности IDE типа Eclipse для Java и VS для C#. Понятно, что можно хоть в mcedit/notepad писать, но большинству требуется браузер классов, рефакторинг, интеграция с отладчиком и т.п. На следующем шаге можно рассмотреть, как полно D поддерживается стандартным юниксовым тулсетом: autotools, pkg-config, gdb тот же (для gdb деманглер дишных имён писать нужно, как я понимаю?) Про библиотеки тоже можно поговорить. Судя по wiki4d, кое-что есть, но альфа-версии - это аргумент.

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

>Немаловажным фактором является наличие нескольких гуру мирового масштаба, которые бы воспели диферамбы новому языку и своей вилле, на которую они заработали при помощи этого языка. Без этого народные массы на язык смотреть не будут, примером чему является Лисп и небезызвестная статья П.Грэма ;)

Андрей Александреску. сойдёт за гуру ?

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

> да потому что ты ошипкой в лоб получишь сразу =)

Еще раз бугага. Ошибка может сильно зависить от потока исполнения, который зависит от данных. Здесь помогу скорее unit-тесты, но 100%-покрытия тестами не бывает, а 100%-проверка компилятором - обычное дело.

http://www.dsource.org/projects/poseidon - активно пилимая IDE, на также активно портируемом SWT - DWT. Так что работа идет, за что респект разрабам.

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

Хорошо. А какие лично ты можешь выделить killer features в D, которые обеспечат языку хорошее будущее, даже не смотря на то, что хорошо проработанной и надёжной инфраструктуры у него сейчас мало?

> Андрей Александреску. сойдёт за гуру ?

url на его диферамбы языку? :)

> На следующем шаге можно рассмотреть, как полно D поддерживается стандартным юниксовым тулсетом: autotools

Зачем оно для D?

> для gdb деманглер дишных имён писать нужно, как я понимаю?

Деманглер для gdb уже написан. Проприетарный ZeroBugs с бесплатной бетой тоже их понимает.

Остальное вполне справедливо. Почти все гуи, ide и прочие либы в альфе-бете.

>> Андрей Александреску. сойдёт за гуру ?

>url на его диферамбы языку? :)

Он принимает участие в разработке, этого мало? А его книга о D собирается выйти в конце года.

> Здесь помогу скорее unit-тесты, но 100%-покрытия тестами не бывает, а 100%-проверка компилятором - обычное дело.

А убережёт ли компилятор от всех ошибок, связанных с неправильной работой с типами?

>> Андрей Александреску. сойдёт за гуру ?

> url на его диферамбы языку? :)

Пока нет. Жди в конце осени его книгу про D2.

>Если ты разработчик - знай и люби свой инструмент (как минимум - помнить про pylint)

попробуй, натрави его на Pylons, узнаешь много интересного :)

>D сейчас можно использовать по крайней мере как язык для одноразовых скриптов, если скрипту требуется высокая производительность (бывает). C++ как минимум из-за legacy. Java - как один из самых быстрых языков, реализованных для всех основных платформ. У каждого языка есть немалое количество важных преимуществ, иначе их бы _вообще_ никто не использовал. На одном фанатизме даже ОС не выбирают... ;)

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

> Он принимает участие в разработке, этого мало? А его книга о D собирается выйти в конце года.

Ну для CLOS тоже есть очень качественные книжки академического вида. Только я совсем не про такие книжки :) Без рекламы ничего не делается. CLOS тоже не идиоты разрабатывали, но много ли народа начало на Лисп смотреть, если бы не эти замечательные сказки про то, как в Лиспе всё ажурно? :)

> А убережёт ли компилятор от всех ошибок, связанных с неправильной работой с типами?

Зависит от языка. В Си/Си++ - нет, ты и сам это знаешь. В Algol68, ошибок, связанных с типами, быть вообще не могло, IIRC.

"There is no silver bullet" (c)

> Зачем оно для D?

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

> Деманглер для gdb уже написан.

В какую версию gdb этот деманглер включён? Или надо качать исходники, патчить, собирать?

Да, выражение "высокопроизводительные скрипты" немного смешно звучит. :)

А про Java что не так? Я же не утверждаю, что перечислил их самые важные преимущества.

> Ну для CLOS тоже есть очень качественные книжки академического вида. Только я совсем не про такие книжки :) Без рекламы ничего не делается

Рекламы? Это как Sun рекламировало Java? Такого не будет, конечно. Но наверняка Александреску найдет хорошие слова для D :)

> Он принимает участие в разработке

К сожалению....

> А его книга о D собирается выйти в конце года.

угу ... осенью обещал.

>> Он принимает участие в разработке

> К сожалению....

Посмотрим на результат...

> В какую версию gdb этот деманглер включён? Или надо качать исходники, патчить, собирать?

Патчить. А чем ZeroBugs не устраивает? У него даже cli интерфейс совместимый с gdb есть.

> Но наверняка Александреску найдет хорошие слова для D :)

Ну он и про плюсы жизнерадостно пишет, но многие люди не готовы оценить всю тонкость секса с нагромождением шаблонов, когда есть варианты сделать проще :)

>Хорошо. А какие лично ты можешь выделить killer features в D, которые обеспечат языку хорошее будущее, даже не смотря на то, что хорошо проработанной и надёжной инфраструктуры у него сейчас мало?

да хотя бы design by contract. D - это Eiffel для бедных, с синтаксисом близким к C++. ну и наличие в языке одновременно кое-каких возможностей метапрограммирования (те же mixins) при прозрачной интеграции с C. ту же Tango на Java сделать было бы на порядок сложнее

>url на его диферамбы языку? :)

http://s3.amazonaws.com/dconf2007/WalterAndrei.pdf

> Патчить. А чем ZeroBugs не устраивает? У него даже cli интерфейс совместимый с gdb есть.

И работает он везде, где работает gdb? У gdb это основное преимущество.

конфы их почитай :)) у него откровенно бредовые идеи иногда возникают. и ведь болин к нему прислушиваются :( вот недавно на шаблоны наехал. типа некошерные. Конечно, надо мля как в с++ слделать.

> Ну он и про плюсы жизнерадостно пишет

Тебе нужно было, чтобы он хвалебно отозвался о D? Это будет.

> но многие люди не готовы оценить всю тонкость секса с нагромождением шаблонов, когда есть варианты сделать проще :)

В D будет проще.

>А про Java что не так? Я же не утверждаю, что перечислил их самые важные преимущества

ну в фразе про Java куда корректней будет смотрется язык C. разве нет ?

> конфы их почитай :)

Я почитываю - не скажу, правда, что внимательно.

> недавно на шаблоны наехал. типа некошерные

Ссылка есть?

> http://s3.amazonaws.com/dconf2007/WalterAndrei.pdf

Слайды... "What the f... hell we were thinking???" впечатлило... Аргумент! Дальше читать не стал.

>> Андрей Александреску. сойдёт за гуру ?

> url на его диферамбы языку? :)

http://video.google.com/videoplay?docid=6520647478274589397

>Использование pylint (некое подобие статической типизации) дает выигрыш. У меня нет оснований думать, что усиление статической типизации не даст еще больший выигрыш.

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

>Для начала подумай, как определить наличие полей на объектах, отличных от self (аргументах методов и функций); что делать с полиморфными коллекциями; что делать с декораторами.

а как это делают языки со статической типизацией? =) Вот ровно так же. Только я тебя ещё раз предупреждаю - это будет уже не питон =)

>Ну он и про плюсы жизнерадостно пишет, но многие люди не готовы оценить всю тонкость секса с нагромождением шаблонов, когда есть варианты сделать проще :)

к вопросу - Blitz++ на чём предлагаешь переписать чтобы было "проще" ? там производительность на уровне FORTRAN'а, а интерфейс бибилотеки обьектно-ориентированый - именно благодаря шаблонам C++

> Дальше читать не стал.

Ты понял, что отступил от труЪшности, и вернулся на путь истинный :D

> Ссылка есть?

щас поискаю.

> к вопросу - Blitz++ на чём предлагаешь переписать чтобы было "проще" ? там производительность на уровне FORTRAN'а, а интерфейс бибилотеки обьектно-ориентированый - именно благодаря шаблонам C++

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

> думаешь, что выигрыш будет, при этом не забывая огласить - какой именно и в каких местах, или молчишь =)

Зачем? Мне достаточно того, что у меня есть основания так думать, а делать здесь сырой braindump у меня нет желания.

"Giving people dynamic languages doesn't mean they write dynamic programs" (c)

>> Для начала подумай, как определить наличие полей на объектах, отличных от self (аргументах методов и функций); что делать с полиморфными коллекциями; что делать с декораторами.

> а как это делают языки со статической типизацией?

Интересные мне языки изучаю потихоньку.

> Вот ровно так же

Ровно так же не получится.

> Только я тебя ещё раз предупреждаю - это будет уже не питон =)

Блин, еще и ты решил побыть Капитаном Очевидность?

> Ты понял, что отступил от труЪшности, и вернулся на путь истинный :D

Чисто конкретная аргументация. Для пацанов. ;)

>Еще раз бугага. Ошибка может сильно зависить от потока исполнения, который зависит от данных. Здесь помогу скорее unit-тесты, но 100%-покрытия тестами не бывает, а 100%-проверка компилятором - обычное дело.

можно подумать, ты сегфолтов никогда не видел. И то что сегфолты - это в том числе и обращение по неправильному указателю, возникающее из-за того, что в функцию передали не то - никогда не слышал, да? Причем не "не то значение" а именно "не тот тип структуры/объекта". Или в твоем уютном мирке все параметры передаются по значению? =) Ну тогда да, заявление насчет 100% проверки компилятором имеет шанс быть правдой =)

>> Я бы сказал что конструкторы в С++ по факту ненужны.

>Тебе не нужны - не используй.

Давай без словоблудия. Слоган "выделение ресурсов есть инициализация" не имеет смысла для более-менее сложных случаев когда ресурс должен оповещать обладателя о изменении его внутреннего состояния. Чтобы ресурс мог это сделать, он должен получить this который из конструктора не доступен, т.к объект еще не создан.

>> Программисты-бобры которым надо не реализовывать гениальный концепт, а писать много кода пользуются методами типа postInit() и Create(...)

>И как наличие этих методов противоречит конструкторам?

Очень много в C++ завязано на то что объект создается конструктором, например const-поля.

>Вот только не надо умных терминов из SE - ты собираешься менять хэдер TApplication.h, или нет?

Я бы вообще TApplication не делал. Структура нормального приложения должна быть децентрализована.

Александреску уже пол года как не появляется в конфах. Более того, именно он однажды предложил сделать шаблоны в таком виде, в каком они сейчас. Вы утверждаете, что он же предлагает вернуть вариант C++?