Что-то на выходных потянуло на философские размышления о времени. И как-то вспомнился такой язык программирования, как D. Вальтер Брайт начал им заниматься в 1999-м, впервые D был представлен миру в 2001. А сейчас на дворе уже 2012-й. Ни много, ни мало, но на разработку D уже ушло 13 лет, а с момента его появления на публике минуло уже 10 лет.
Для сравнения: язык C++ начал свою историю с 1979-го, имя свое получил в 1983-м, а первый публичный релиз состоялся в 1985-м. Через 13 лет после начала работ над C++ – а это 1992-й год – он был уже вполне себе мейнстримовым языком. Через 10 лет после публичного релиза – 1995-й – самым мейнстримом из мейнстримов. Работы по стандартизации C++ шли полным ходом. STL к тому времени уже существовал, и самым серьезным образом дорабатывался чтобы войти в стандарт языка.
Я с языком D познакомился где-то в районе 2001-2002 годов. Тогда было понятно, что это еще очень сырой проект. Но интересный. Поэтому время от времени его развитием я интересовался. И мне нравилось то, что я видел. Язык развивался в нужную сторону. В частности, со временем Брайт добавил в D шаблоны, да какие шаблоны! В C++ на тот момент таких не было.
В общем, на мой взгляд, где-то в районе 2005-2006 годов язык D уже был готов к релизу. Да и момент тогда был очень удобный. Ведь в это время случился взрыв интереса к Ruby на волне успеха Ruby-On-Rails. И Ruby тогда очень хорошо показал, что в какой-то конкретной нише может выстрелить даже не очень известный язык, без большого коммьюнити, без большого количества инструментов, без поддержки больших игроков.
И можно было бы вспомнить тогдашнюю ситуацию с C++. Это было время, когда усилиями Sun (Java) и Microsoft (C#) программирование на неуправляемых языках (т.н. native code) начало приобретать черты маргинального направления. И будущее самого языка C++ было туманным: работа над следующим стандартом языка казалась долгостроем, который никогда не закончится.
Вот в этот момент язык D, который был почти что C++, но много лучше, имел свой шанс на успех.
В то время я сам был готов его использовать. Для этого нужна была всего лишь малость – стабилизация. Выпуск официальной версии языка и переход только к его поддержке – исправлению ошибок, оптимизации, совершенствованию инструментария, расширения библиотек и т.д. Без этого взять курс на переписывание в течении нескольких лет нескольких сотен тысяч строк C++ного кода с параллельной разработкой новых проектов уже на D я бы не решился.
Такой переход к стабилизации языка для Вальтера Брайта был сродни подвигу. Если кто тогда следил за D, тот может помнить, что Брайт выпускал новые версии компилятора где-то раз в 2-3 недели. Иногда добавляя что-то очень классное, иногда ломая совместимость со старым, иногда просто устраняя несколько десятков ошибок. Но никто тогда не видел ни какого-то плана развития языка, ни даже списка озвученных целей, которые Брайт стремиться достичь в D.
Тем не менее, в конце 2006 в конце туннеля забрезжил свет и в самом начале 2007 состоялся релиз D 1.000.
Казалось бы – вот оно, свершилось! Но счастье длилось очень недолго. Уже по весне 2007-го зашли разговоры о языке D2, который не будет совместим с D1. И в середине 2007-го появилась первая версия компилятора D2. После чего развитие D2 пошло по тому же сценарию, что и D1 – периодические релизы новых версий компилятора и непонятное развитие языка по одному автору ведомому плану.
Это был трындец. После такого поворота даже мне, практически евангелисту языка D, стало понятно, что с D связываться нельзя. Он не взлетит.
В январе 2012-го исполнилось пять лет с релиза D 1.0. Пять лет! Это очень немаленький срок. И где же сейчас D 1.0? Что на нем написано? Какое распространение он получил? Полагаю, все это уже чисто риторические вопросы.
К чему я весь этот поток сознания выплеснул на головы читателей? Когда появились разговоры о D2 многие думали, что это ошибочное решение. Но доказать правомочность их опасений могло только время. И вот незаметно пробежало пять лет. Можно делать неутешительные выводы – скептики оказались правы :(
76 комментариев:
Не помню чья цитата - "D делают учёные, а они бросают пилить дерево как только смогли доказать что спилить его возможно". Лучше, пожалуй, не скажешь
Отлично сказано!
Все еще хуже, никакие они не ученные, самые что ни на есть практики, но с очень большим исследовательским зудом. Ученные они какую-нибудь агду пилят и не претендуют на мейнстримовый язык общего назначения.
@Rustam:
Как по мне, так года с 2007-го там первую скрипку играет Александреску. А его практиком я назвать не могу. Исследователь хренов.
Александреску это диагноз :)
@Rustam:
Тоже отлично сказано! :)
В упоминаемой тобой http://rsdn.ru/forum/philosophy/2222569.1.aspx ветке неплохо помню ругались, самый пик немерле головного мозга на RSDN :)
У немерлистов кстати тот же диагноз что и у Валтьера, ваяют Немерле 2.
Да флейм был эпичный. Подобные разборки тогда были, пожалуй, одной из лучших сторон RSDN, в них очень часто отличные ссылки и интереснейшие мнения проскакивали. Например, познакомиться с Erlang-ом мне захотелось именно после его упоминания в Философии Программирования.
Немерлистам удачи. Помнится, среди них было много очень вменяемых людей. Только, имхо, с такими темпами развития C# никому уже Nemerle не будет нужен на .NET-е.
В D , для меня полным отказом от интереса к языку послужили String Mixing: http://www.d-programming-language.org/mixin.html
Это генерация кода сродни eval-у в других языках.
max!("a < b")(sequence)
Спасибо, но такое счастье не нужно.
В Nemerle как и в других языках идет работа с АСТ, что намного более правильно чем в D2 сегодня. Кстати , в D2 тоже были (а может и есть) разговоры по этому поводу.
Но язык D загнулся. Это факт.
Nemerle 2 это не сейчас.
Прежде всего Nemerle 2 не собирается ломать совместимость с Nemerle 1, как в случае с D2.
И разработка Nemerle 2 будет идти итерационно, а не бросать все на произвол.
P.S.
Вот был бы Nemerle с LLVM бэк-эндом, цены бы ему не было.
Согласен с тем что String Mixing это очень коряво, но к eval никакого отношения они не имеют, так как работают сугубо в compile time.
AST маскросы отложили до D3.
Ну и "живость" немерле по моему та же что и у D, оба так и смогли толком народится :(
Ну лично я тогда String Mixin воспринял хорошо. Поскольку считал, что они должны были бы применяться для чего-то вроде:
mixin( MakeSerializer!("""
type Handshake {
mandatory int version [tag=0x01],
optional int preferredVersion [tag=0x02],...
}
""");
Но то, как их стали использовать (вроде бы для задания текста лямбд в стандартной библиотеке алгоритмов) -- вот это да, херня редкая.
По поводу Nemerle и LLVM я думаю вот что: имхо, сейчас нет смысла делать что-то для менеджед платформ. На JVM уже есть и Scala, и Clojure, на подходе Ceylon и Kotlin. На .NET есть F#. И практика показывает, что они все равно не могут серьезно потеснить Java и C#. Ибо большинство разработчиков под JVM/.NET ничего другого и не нужно. Менталитет может такой ;)
А вот для нативного программирования сейчас делать что-нибудь интереснее. Перспективнее, имхо. Особенно с ростом популярности портативных устройств, которые всегда будут требовательны как к производительности, так и к энергопотреблению.
Зашел сейчас сюда http://www.d-programming-language.org/changelog.html
По тому что уже давно не было ничего ломающего и нового казалось что все-таки D 2.0 релиз не за горами, но смотрю:
Version D 2.058 upcoming Feb 13, 2012
New/Changed Features
Add new => lambda syntax.
Allow 1.userproperty syntax
Convert to -shared dmd switch instead of -dylib
Better use of XMM registers in OS X 32 bit target.
Похоже что эта песня будет вечной.
Хотя конечно новый синтаксис лямбд нужен, слишком уж корявые они на фоне шарпа например.
Даже если они остановятся на том, что есть, вряд ли D будет кому-нибудь нужен кроме горстки оставшихся фанатов. D нужно было релизить пока еще у C++ новый стандарт только на горизонте маячил. Тогда еще был смысл переходить с C++ на D. Сейчас я этого смысла уже не вижу.
Были еще люди, которые на D переходили с Java/C#... Но сейчас, имхо, им будет интересней какой-нибудь функциональный язык (тот же Haskell) или же Google-овский Go.
Google-овский Go это полнейшее убожество (по системе типов на уровне явы ДО дженериков)
ммм... а тебе бы дали возможность переписывать тысячи строк кода?
по-моему, к новому языку надо четко сформулировать требования -- он должен позволять вызывать код, уже написанный на с++, в том числе шаблонный (хотя, возможно, и не слишком сложный шаблонный код -- иначе мы получим второй с++)
вообще интересно, если бы ты сформулировал требования к новому языку -- типа минимум, среднее, максимум -- я естественно это тоже сделаю, но мне не хочется навязывать свою точку зрения
ммм... мой прошлый комментарий попал не в ту ветку, он предназначался в корень и как вопрос к Евгению Охотникову
кстати, мне интересно мнение о новом языке любого человека, пишущего на с++ либо поддерживающего код на с++
@имя
D не позволяет вызывать шаблонный код на C++, максимум на уровне функций и простых классов http://www.d-programming-language.org/cpp_interface.html ну и плюс D'шные интерфейсы совместимы с com http://www.d-programming-language.org/interface.html . Вот c Си уже повеселей линкуется практически свободно http://www.d-programming-language.org/interfaceToC.html
Ну и люди пишут и автоматические и полуавтоматические конвертеры, например есть в составе http://dsource.org/projects/visuald . Тут уже вопрос ресурсов, так конвертация вполне реальна и не только с C++ но и с явы например (так была создана например библиотека http://dsource.org/projects/dwt).
Но по моему D2 был бы вполне годен как язык заменяющий C++ для новых проектов. Переписывание сколь либо объемного существующего кода на C++ по моему бессмысленно.
@Евгений
С тем что опоздал да согласен. Но как язык D2 все равно гораздо лучше чем C++11.
конвертация != вызов кода
с жабки, думаю, не тяжелая проблема конвертнуть, хотя в дженериках может будут тяжелые случаи, и новомодный инференс, которого в яве кот наплакал, все равно тоже может создать проблемы
"язык заменяющий C++ для новых проектов" это непрактичная затея -- сразу идут коту под хвост старые наработки, знание старой стандартной библиотеки, и т.д.
по-моему, гораздо практичнее дописывать и частично переписывать существующие проекты на новом языке
частично переписывать это примерно "рефакторить"
@имя
Там по ссылкам как раз про вызов кода.
По моему для C++ нечто расширяющее его может быть только новая версия C++ и больше ничего, слишком он сложен и при этом недостаточно гибок (в отличии скажем от лиспа или форта).
вопрос, что значит конвертнуть с с++ -- можно так конвертнуть, что при этом полностью потеряются намерение программиста
скажем, программист вызывает f< Util< a,b,c >::result > (123); Util< a,b,c >::result считается во время компиляции на шаблонах и выдает целое число 7 -- да, это можно сконвертить в f< 7 > (123), но нужно ли?
> По моему для C++ нечто расширяющее его может быть только новая версия C++ и больше ничего, слишком он сложен и при этом недостаточно гибок (в отличии скажем от лиспа или форта).
слишком он сложен -- да
недостаточно гибок -- да
а окончательно -- нет, т.к.
1. разработчики пользуются в основном некоторыми "хорошими" подмножествами с++
2. плохой код -- это результат выражения хорошей мысли разработчика негодными средствами с++
насчет хороших подмножеств -- скажем, в пространствах имен названия переменных и классов могут совпадать, и имеются правила, разрешающие и запрещающие такие совпадения -- и давно ли ты пользовался *этой* частью языка?
@имя
Окончательно да, так как язык поддерживающий только подмножество C++ будет ничем ни лучше чем тот же D. А скорее всего и хуже.
я вот про что например: During the lookup of a qualified namespace member name, if the lookup finds more than one declaration of the member, and if one declaration introduces a class name or enumeration name and the other declarations either introduce the same variable, the same enumerator or a set of functions, the non-type name hides the class or enumeration name if and only if the declarations are from the same namespace; otherwise (the declarations are from different namespaces), the program is ill-formed.
@имя
Ну и тот же D кстати во многом и есть попытка оставить только "хорошие" (в видении автора) подмножества C++.
@Rustam
я не сказал "только подмножество"
я предлагаю поддерживать подмножество с++ для целей интероперабельности, и иметь гораздо более мощный и логичный язык внутри себя
> Ну и тот же D кстати во многом и есть попытка оставить только "хорошие" (в видении автора) подмножества C++.
ага, и почти полностью поломать совместимость -- меня это не устраивает
По моему сохранить совместимость невозможно.
> По моему сохранить совместимость невозможно.
*такое* твое высказывание для меня имеет очень мало смысла, т.к. ты вероятно можешь недооценить мои возможности поддержки совместимости; хотя, конечно, если ты всерьез намерен доказать свое высказывание -- я, возможно, с интересом послушаю и поопровергаю (но это будет долго)
а вот высказывания типа "мне категорически нужна вот такая фича, потому что..." для меня представляют *несомненный* интерес
Насчет годного языка, вот есть весьма интересный и симпатичный вариант http://haxe.org/ref по сути попытка перенести плюшки ML в ОО язык с сишным синтаксисом. Жаль что он в основном ориентируется на web да еще и базовая платформа flash.
> По моему сохранить совместимость невозможно.
твое утверждение обосновать очень сложно; гораздо проще тебе например найти дефекты в конкретном плане сохранения совместимости, но для этого я сначала должен такой план подробно представить... а я пока что обсуждаю *необходимость* совместимости
Компиляторы C++ до сих пор еще не вполне совместимы со стандартом, а раньше вообще был ужас, как вспомню как переводил проект с borland C++ на std C++ (visual C++ + gcc) до сих пор плохо становится. Я не верю что можно сделать язык достаточно совместимый с C++ чтобы на нем можно было продолжать разрабатывать уже существующий проект на C++.
Мне категорически нужен новый нативный язык на замену C++. Мне достаточно чтобы он умел вызывать extern "C" и com интерфейсы, то есть то что уже есть в D. D по моему вполне удовлетворительный кандидат, но было бы неплохо что-то более близкое к тому же haxe, то есть плюс алгебраические типы и паттерн матчинг.
Я не вижу необходимости. Реальная совместимость практически приведет к форку C++ со всеми его недостатками и во многом жестко ограничит возможности нового языка.
если устраивает отсутствие ооп (вместе с ко- и контравариантностью), (и не знаю насчет ком-интерфейсов), взгляни на http://felix-lang.org/
у него еще и свой способ интероперабельности с с++
исходя из твоего поста, возникает подозрение, что ты не различаешь "необходимость" и "возможность"
уже не так политкорректно скажу -- твои мнения о невозможности меня не интересуют; дальше можешь хоть 20 постов наклепать на тему невозможности -- я не буду на них отвечать
@имя
Ладно смысла ругаться нет, просто требования у нас разные. Можно не заострять внимание на совместимости с C++ а обсудить сам желаемый язык.
Да Felix интересный, тоже ML в сишном синтаксисе, я его уже давно как-то смотрел, но он еще менее живой чем D или haxe :(
там не только ML -- там тайпклассы, причем с леммами и теоремами, чего даже в хаскеле нет
насчет живости -- там случаются месяцы, когда нет ни одного письма в мейллисте
еще меня смущают байндинги к с++ -- выглядят они как-то зверски и подозреваю документированы плохо
но с теоретической точки зрения весьма похоже на то что надо -- разве что, как я говорил, нет ооп и ко/контравариантности
@имя
С теоретической да. А с практической даже OCaml который на порядок живее этих языков сложно использовать если пишешь код не в одиночку.
из-за совместимости с с/с++ в случае какой-то проблемы всегда есть возможность написать проблемный кусок не на феликсе, а на с++ (это то, чего D лишен -- даже будь у него конвертер, конвертер тоже может заглючить на проблемном месте)
впрочем, плюсовый выхлоп феликса явно выглядет как машинносгенеренный, так что не все там гладко
в целом, я феликс буду рассматривать внимательно и наверно попишу на нем всякую мелочь на 200 строк
я понимаю, что требования разные, и вполне готов с интересом слушать такую фразу, как "у меня (рустама) нет потребности в совместимости с с++"
против чего я выступаю -- это против доказательств *невозможности* -- грубо говоря, для попыток такого доказательства у тебя недостаточно информации, а выдать тебе всю информацию мне доооолго
опять-таки, я с интересом выслушаю фразу типа "мне не нужна STL", и в таком случае поинтересуюсь, что предлагается использовать взамен или хотя бы на каких принципах сделать контейнеры
Я в курсе что это во время компиляции.
Но оперировать текстом вместо объектов, я лучше на С++ попишу :-!
Тем более когда есть средства в виде квази-цитат.
Тут в D должны сделать прорыв с AST, ADT и PatternMatching.
D3 ? ох.. не скоро будет :)
C# и Java не потеснить по многим причинам. Вот скажем в VS есть генератор кода из DB для C#/VB и все.Для другого не будет. Тоже самое , полагаю , и с Java.
F#, мне лично не очень нравится. Не могу рекомендовать его на замену C#. %)
Nemerle изначально ориентировался на эту нишу.
Поэтому логично его там сейчас и использовать.
На Nemerle пишутся несколько коммерческих проектов. Так что слухи о смерти немного преувеличенны :)
Точно могу сказать, что разработчикам C# он нужен, но не все знают/могут/готовы использовать.
Средства метапрограммирования нужны однозначно, чем больше повышаешь свою квалификацию, тем больше это понимаешь.
Да, не всегда нужны, но когда нужны, а их нет, невольно вспоминаешь добрый С , где на макросах можно было сделать элементарные вещи недоступные в 2012-м году :)
Я бы тоже не прочь внимательнее посмотреть феликс, но к сожалению бобик похоже сдох, код из репозитария по инструкции отсюда http://felix-lang.org/web/download.html скачать не удалось.
Судя по документации вся "совместимость" с С++ основана на том что язык по сути препроцессор для C++. Чувствую отладка в нем должна быть веселой :)
Код все-таки нашел поиском по github https://github.com/felix-lang/felix судя по коммитам бобик жив, но похоже популярность при таком отношении к пользователям ему не грозит.
Я нигде ни пытался доказывать невозможность совместимости с C++ это чистое имхо. Тем более ты ниже привел тот же феликс, но это по сути препроцессор С++ со всеми недостатками такого подхода.
Ну и подход "у нас есть секретные документы но мы их вам не покажем" к продуктивной беседе не ведет, так же как и обсуждение того что интересно только тебе, тем более в чужом журнале.
из-за совместимости с с/с++ в случае какой-то проблемы всегда есть возможность написать проблемный кусок не на феликсе, а на с++ (это то, чего D лишен -- даже будь у него конвертер, конвертер тоже может заглючить на проблемном месте)
Этого даже питон не лишен, никаких проблем написать модуль на С/C++. На D в общем тоже, конвертер для этого не нужен D вполне линкуется с C++.
Насчет времени смотрю первый коммит в git репозитарии felix от 06.2001 года (преобразован csv->svn->git)
[сарказм]
Мне нравится новая система комментариев блоггспота. Комментариев 10 страниц, причем зайдя на следующий день, видишь, что цифра комментариев увеличилась, а какие добавились нужно искать вручную. Так держать.
Я включил этот режим ради эксперимента. Будут еще нарекания -- отключу.
Хотя в том же ЖЖ с этим делом еще хуже.
@имя:
>ммм... а тебе бы дали возможность переписывать тысячи строк кода?
Я бы ее сам взял :) Серьезно, на тот момент у нас было всего два или три C++ника под моим началом, так что сменить курс с C++ на что-то другое было вполне реально.
>по-моему, к новому языку надо четко сформулировать требования -- он должен позволять вызывать код, уже написанный на с++, в том числе шаблонный (хотя, возможно, и не слишком сложный шаблонный код -- иначе мы получим второй с++)
Мне не нужно было вызывать старый C++ код из D. У меня был другой план -- переписывание на D некоторой части наших базовых C++ библиотек. Затем портирование под D SObjectizer-а с обеспечением полной интероперабильности между SO-C++ и SO-D на уровне коммуникационных протоколов. Затем постепенное портирование написанных на SO-С++ компонентов. Поскольку приложения у нас были распределенные, то замена старого C++ного компонента на новый D-шный для приложения прошла бы незамеченной.
И большой плюс здесь в том, что написанный нами в стиле "C с классами" с разумным использованием шаблонов C++ный код переписывался вручную в D с небольшими усилиями. Был опыт такой. Студент пятого курса (но толковый) переписал небольшую C++ную библиотеку под D без особых усилий.
>вообще интересно, если бы ты сформулировал требования к новому языку -- типа минимум, среднее, максимум -- я естественно это тоже сделаю, но мне не хочется навязывать свою точку зрения
У меня нет конкретных требований к новому языку. И вообще сомневаюсь, что обычный пользователь языка вроде меня должен такими вещами заниматься. То, что меня не устраивало(вает) в C++ и чего хочется я когда-то давно описал и, думаю, это все еще актуально: http://eao197.narod.ru/better_language/index.html
м.б. действительно стоит или отключить, или показывать иерархические комментарии линейно, если есть такая опиция?
и да, линейную форму читать намного легче
@имя:
>м.б. действительно стоит или отключить, или показывать иерархические комментарии линейно, если есть такая опиция?
Насколько я понял, либо линейно, либо иерархически. Другого не дано.
Вернул все в зад.
> Ну и подход "у нас есть секретные документы но мы их вам не покажем"
ну выставлю я свои "секретные документы", при моей манере кратко выражаться 95% их поймет неправильно, развернется тупая дискуссия -- нафиг
__НО__ если ты (или кто-то другой) имеет серьзные намерения обсудить скажем невозможность совместимости нового языка с с++, и при этом готов постоянно включать мозги, то тебе (ему) стоит об этом заявить
а вот дискуссия "мне (категорически) не хватает..." практически не требует входного порога, так что доступна всем
> к продуктивной беседе не ведет, так же как и обсуждение того что интересно только тебе, тем более в чужом журнале.
мне кажется, что ты по-прежнему меня не понимаешь (впрочем, это стандартная ситуация, не огорчайся)
что касается темы, которую я поднял, то мне кажется она является ответом на невысказанный eao197 вопрос "D, похоже, не взлетит; что делать будем?" -- и мой ответ -- "будем собирать требования к новому языку, D это или не D"
> У меня нет конкретных требований к новому языку. И вообще сомневаюсь, что обычный пользователь языка вроде меня должен такими вещами заниматься.
мне часто такое говорят, и я часто отвечаю -- нельзя давать другим 100% возможность решать "*что* будет для меня хорошо", иначе сделают не совсем то, что надо
(хотя, конечно, ответ на вопрос "*как* сделать то, что будет для меня хорошо" требует уже существенно бОльших знаний)
а подход "вот *если* они сделают хорошо, тогда я возьму и использую" в ЯП, как видим, пока не сработал
> с обеспечением полной интероперабильности между SO-C++ и SO-D на уровне коммуникационных протоколов
это интересная идея, которую я не рассматривал (другая интересная идея из дискуссии -- это com-интерфейсы)
> интероперабильности между SO-C++ и SO-D на уровне коммуникационных протоколов
а как у тебя сейчас данные сериализуются? как компилятор положит в структуру или "строго"?
@имя:
>что касается темы, которую я поднял, то мне кажется она является ответом на невысказанный eao197 вопрос "D, похоже, не взлетит; что делать будем?" -- и мой ответ -- "будем собирать требования к новому языку, D это или не D"
Не-не-не, такого вопроса не подразумевалось даже. Невысказанной осталась такая мысль: "Эти сраные долбо*бы во главе с Брайтом и Александреску не прислушались 5 лет назад к здравомыслящим людям (в том числе и ко мне) и теперь хороший язык сидит глубоко в заднице!" Вопрос о том, что теперь с D (или с каким-то другим языком) делать для меня уже не стоит. Я уже не так много программирую, как раньше, поэтому меня и С++ устраивает. Тем более после принятия C++11.
@имя:
>а подход "вот *если* они сделают хорошо, тогда я возьму и использую" в ЯП, как видим, пока не сработал
Ну это как сказать. Вот в 2004-м я выбирал себе скриптовый язык, то не знал, какие именно языковые возможности мне нужны. Просто сделал short-лист, в котором были и Python с Ruby, попытался на каждом из них представить то, что мне хотелось иметь. И оказалось, что за счет рубиновых блоков кода это работает лучше всего. Уже потом к месту пришлись и такие вещи, как Symbol, и особенности задания HashMap-ов и пр.
Так что работает такой подход, на мой взгляд.
@имя:
>а как у тебя сейчас данные сериализуются? как компилятор положит в структуру или "строго"?
Я когда-то целый проект для этого наваял: http://eao197.narod.ru/objessty/index.htm
До сих пор в C++проектах активнейшим образом используется. Правда вот не доходят руки до развития. Но, есть надежда, что острая нужда скоро заставит к нему вернуться.
> Так что работает такой подход, на мой взгляд.
"выберем лучшее из того, что есть" работает, а "вот *если* они сделают хорошо, тогда я возьму и использую" по-прежнему не работает
точнее работает "выберем лучшее с моей нынешней точки зрения из всего того отстоя, что есть"
руби синтаксически получше питона; зато питон интероперабелен с++ вплоть включая уровень кидания-ловли исключений; но Qt зачем-то выбрала для своего скриптования кривой js; и т.д. -- хорошего скриптового языка так и не сделали
> конвертер для этого не нужен D вполне линкуется с C++
я вполне мог че-то пропустить, т.к. долго на Д не смотрел; как сейчас в коде на Д можно создать новый объект класса с++ -- вручную обернув вызов конструктора extern "C" функцией, или есть пути поудобнее?
> D вполне линкуется с C++
тут весьма полезен был бы краткий "решебник" -- типовая задачи интероперабельности и ее решение на Д
> D вполне линкуется с C++
а как решаются вопросы возможно различного смещения данных в структурах допустим даже си и Д?
> Я уже не так много программирую, как раньше, поэтому меня и С++ устраивает.
я когда это первый раз прочел, то подумал, что это эмоциональное преувеличение -- потому что я сильно плююсь от с++, хотя пишу на нем немного
> Насчет времени смотрю первый коммит в git репозитарии felix от 06.2001 года (преобразован csv->svn->git)
ничего не имею против и только "за" критический аналил феликса;
но если, внезапно, после этого анализа будет высказывание "поэтому берем лучшее, что есть -- ну хотя бы Д" -- то мой ответ будет "нет"
@имя:
>я когда это первый раз прочел, то подумал, что это эмоциональное преувеличение -- потому что я сильно плююсь от с++, хотя пишу на нем немного
Я как раз очень спокойно отношусь к C++. И, если сравнивать его, например, с Java, то даже с большим удовольствием.
ну да, хорошо хоть не жабка... но оправдание слабое, типа "хорошо, что у нас не как в китае, где часто бывает зарплата в 40$ в месяц"
в среднем, для выражения моих мыслей мне пока что лучше всего подходит с++
в феликсе нет ооп, но есть тайпклассы и АлгТД, через которые можно выражать что-то, аналогичное ооп; это непривычно
@имя
Насчет невозможности совместимости. В теории ничего невозможного нет. Но на практике такой язык будет настолько сложным в реализации что не взлетит, для его реализации потребуется _очень_ солидное вложение ресурсов. Ну и он не решит задач которые по моему требуются от языка идущего на смену C++, это в первую очередь безопасность и избавление от тяжелого наследства Си.
как сейчас в коде на Д можно создать новый объект класса с++ -- вручную обернув вызов конструктора extern "C" функцией, или есть пути поудобнее?
Есть extern (C++), но линковатся можно только с родным для D DMC С++ компилятором. Хотя еще есть gdc он должен линковатся с gcc, но я давно его не смотрел. Простые классы как и функции тоже могут оборачиваться в extern (C++).
а как решаются вопросы возможно различного смещения данных в структурах допустим даже си и Д?
D поддерживает выравнивание http://www.d-programming-language.org/attribute.html#align единственно он не умеет напрямую битовые поля, но мощи его метапрограммирования хватает для поддержки в библиотечном виде http://www.d-programming-language.org/phobos/std_bitmanip.html тут миксины вполне рулят.
С феликсом разбираться надо всерьез, но боюсь из-за нехватки времени и из-за по моему бесперспективности это произойдет нескоро :(
Ну и согласен с Евгением: C++ мне скорее нравится чем нет, и он вполне годный инструмент для не очень большой команды достаточно квалифицированных специалистов, но к сожалению и морально и физически (избыточно сложен как для реализации так и для изучения) устарел.
в феликсе нет ооп, но есть тайпклассы и АлгТД, через которые можно выражать что-то, аналогичное ооп; это непривычно
В OCaml есть ООП, но мало кто из камлистов его использует, ФВП, АлгТД и ML модули (полиморфные и параметризуемые) с успехом его заменяют.
@имя
как сейчас в коде на Д можно создать новый объект класса с++ -- вручную обернув вызов конструктора extern "C" функцией, или есть пути поудобнее?
Функцию все-таки придется писать, С++ класс D может только по ссылке использовать. Но все-равно интероп по моему вполне хороший. Да и можно навернуть с обоих сторон аналоги boost::python (которые будут гораздо проще чем для питона) и тогда вообще проблем не вижу (особенно после FFI от OCaml'а например :) ).
Отправить комментарий