Здравствуйте, VladD2, Вы писали:
VD>Нет никаких проблем в отказе от С++. Я бросил этот недоязык 10 лет назад и ни капельки не жалею.
Соболезную)))
Моё мнение: C++ очень плох, но лучше ничего нет. Естественно мы говорим только про решения имеющие инфраструктуру вокруг языка, а не поделки энтузиастов.
VD>Они и сделали. Но невозможное сделать нельзя. Тащить шаблоны плюсов в другой язык — гробить этот язык.
И без шаблонов полно нужных библиотек.
VD>Короче, это очередной поиск отмазок. Если у вас руки не из задницы, то за месяц вы спокойно создадите себе окружение.
Месяц (или несколько) работы только над этим? Возможно. Но у нас дела есть и другие. От применения D пока только приятность программистам (и при этом ещё кстати некое снижение быстродействия, хотя не так критично) — всё тоже самое можно делать и на C++, но без затраты этого месяца или более.
VD>Какие на фиг монстры на С++? О чем вообще речь?
Вот неполный список библиотек валяющихся с одного из проектов:
Boost (ну эту в других языках требовать не будем — это по сути доработка и расширение C++)
wxWidgets (есть биндинги у Питона и ещё кучи языков, включая даже Хаскель; wxPython использовали на практике — удобно)
АхТк
Curl(есть в Питоне)+wxCurl
libavcode+libavformat (есть в Питоне)
Lua
OpenCV (есть в Питоне)
OpenSSL (есть в Питоне)
SFML (есть в Питоне)
sqlite(есть в Питоне)+wxsqlite
wxwebconnect (есть аналог в Питоне)
Что касается D, то к нему можно подключить (как C библиотеки) некую часть, но и только — никаких приличных биндингов нет. Добавим к этому что в стандартной системе локализации gettext есть C/C++/Python и ещё куча языков, но не D.
Вот я гляжу на это всё и вижу что перейти с C++ на Питон не особо проблематично (ну точнее нам то это не подходит, но по совершенно другим причинам). А вот что бы с C++ на D перейти...
Здравствуйте, kaa.python, Вы писали:
KP>Живой язык — это язык употребляющийся для коммерческой разработки. Rust еще не родился даже, и, возможно, и не родиться. Но вероятность рождения есть. В случае с D такой вероятности уже нет, хотя, лично я, долгое время на это очень надеялся.
Ты не прав, руби в таком зомби состоянии например прожил практически десять лет, пока рельсы не появились, питон в свои первые
десять лет тоже не был особо уж популярен.
Здравствуйте, kaa.python, Вы писали:
KP>Он не завоевал успеха не потому что плох, и не потому что мышление костное, а потому, что не надо находить в первой версии языка "критический недостаток", все бросать и начинать пилить уж точно правильнуе версию. Язык для коммерческой разработки отличается от языка для домашних проектов тем, что дает не только и не столько развитие и новые круты примочки, сколько стабильность и возможность собрать старый код новым компилятором (при этом не требуя переписать чуть меньше 50%).
Тут я согласен, но в случае D все-таки были и объективные причины начинать вторую версию. Брайт, как и создатели C#,
в самом начале допустил очень грубую ошибку, начал делать "нативную яву", а надо было "убийцу C++", а это абсолютно
разные мало совместимые языки.
Здравствуйте, kaa.python, Вы писали:
KP>Отчасти то, о чем ты пишешь, и было причиной того, что D не взлетел. В то же время, за Rust стоит Мозилла, и ей же язык нужен не просто прикола ради, а для собственного проекта. Из этого можно сделать вывод о том, что надежда на "взлетит" есть. Хотя, я с тобой согласен — она не велика.
Да надежда есть, но поддержка корпораций ничего ни гарантирует, например Dylan поддерживала Apple в период своего первого расцвета, а Smalltalk корпорации как раз и закопали.
Здравствуйте, kaa.python, Вы писали:
KP>Последнее вермя меня просто неописуемо прет от Rust, посути — это тот язык которого мне давно не хватало. Так вот, к чему я это. На данный момент я затеял перевод руководства пользователя, полагаю что его проще перевести пока оно еще не очень большое (около 24 страниц). Собственно вопрос в том, не хочет ли кто-то присоедениться к переводу руководства? KP>Если хочется посмотреть на то, что из себя представляет Rust, то можно почитать заметки про него.
Почему бы вам не написать пару-тройку статей в наш РСДН о Расте?
Я бы с удовольствием почитал. Особенно про шаблоны. В чем они так радикально проще С++нутых?
Да и другие, я уверен, тоже.
И вам польза — публикация в известном журнале.
Можно при смене работы козырять...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Почему бы вам не написать пару-тройку статей в наш РСДН о Расте? LVV>Я бы с удовольствием почитал. Особенно про шаблоны. В чем они так радикально проще С++нутых? LVV>Да и другие, я уверен, тоже.
Идея со статьями отличная, я сам об этом думал. Но, на данный момент, однозначно рано: во-первых, язык сырой и часто меняется; во-вторых, я сам на данный момент пытаюсь понять, на сколько мне этот язык нравится и на сколько он меня устраивает. Все же составить впечатление сходу довольно трудно. Попутно работаю над биндингами к libevent и планирую из дальше в одной задумке использовать.
Но если все устроит, то после биндингов возьмусь за статьи
LVV>И вам польза — публикация в известном журнале. LVV>Можно при смене работы козырять...
Ну, допустим, чем козырять, у меня и так куча всего... Но статьи штука хорошая.
Здравствуйте, kaa.python, Вы писали: LVV>>Почему бы вам не написать пару-тройку статей в наш РСДН о Расте? LVV>>Я бы с удовольствием почитал. Особенно про шаблоны. В чем они так радикально проще С++нутых? LVV>>Да и другие, я уверен, тоже.
KP>Идея со статьями отличная, я сам об этом думал. Но, на данный момент, однозначно рано: во-первых, язык сырой и часто меняется; во-вторых, я сам на данный момент пытаюсь понять, на сколько мне этот язык нравится и на сколько он меня устраивает. Все же составить впечатление сходу довольно трудно. Попутно работаю над биндингами к libevent и планирую из дальше в одной задумке использовать. KP>Но если все устроит, то после биндингов возьмусь за статьи
Это не важно, что язык меняется. Тут важно ухватить идеи, заложенные в язук, и их изложить.
Вон Влад как Немерлю разложил по полочкам — класс!!!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, kaa.python, Вы писали:
KP>>Угу, на уровне использования в повседневных разговорах языка Высоких Эльфов
FR>Ну на Хаскеле пишут же
Ещё бы
curl, hslua, OpenCV, OpenSSL, SFML, sqlite и многое другое.
Причём это только hackage, но когда я начинал изучать Haskell, весь список был максимум в 5-6 экранов.
Здравствуйте, alex_public, Вы писали:
_>И без шаблонов полно нужных библиотек.
А без шаблонов они к Ди подключается на раз. Так что не надо выдумывать. Это все отмазки.
VD>>Короче, это очередной поиск отмазок. Если у вас руки не из задницы, то за месяц вы спокойно создадите себе окружение.
_>Месяц (или несколько) работы только над этим? Возможно. Но у нас дела есть и другие.
Это из серии анекдота — "Что думать? Трясти надо!...". Этот месяц вы потеряете ровно один раз. И быстро его отиграете на первом же проекте. А на втором у вас будет внушительная фора.
Признайтесь себе честно, что проблема не в языках или библиотеках, а в вашем мировозрении. Вы просто боитесь непредвиденных обстоятельств и слишком привыкли к этому плохому. Вот и кажется вам, что лучше ничего не придумали.
Так и не придумают, потому что для консерватора все к чему он не привык — худшее.
_>Boost (ну эту в других языках требовать не будем — это по сути доработка и расширение C++)
Это подпорки к кривому язяку, чтобы он хоть чуточку походил на нормальные.
_>wxWidgets (есть биндинги у Питона и ещё кучи языков, включая даже Хаскель; wxPython использовали на практике — удобно)
Короче, лично мне все ясно. Ты даже не удосужился разобраться в вопросе (попробовать язык на практике), но уже вынес обвинительный приговор языку.
_>Что касается D, то к нему можно подключить (как C библиотеки) некую часть, но и только — никаких приличных биндингов нет. Добавим к этому что в стандартной системе локализации gettext есть C/C++/Python и ещё куча языков, но не D.
Какую часть? Практически для всего перечисленного или есть готовые решения, или это сишные библиотеки которые без проблем используются из Ди напрямую.
_>Вот я гляжу на это всё и вижу что перейти с C++ на Питон не особо проблематично (ну точнее нам то это не подходит, но по совершенно другим причинам). А вот что бы с C++ на D перейти...
А я гляжу на тебя и других таких же критиков и понимаю, что реальных причин вы не назовете, так как они не технические.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>И система типов гарантирует, что объекты не будут иметь ссылок на объекты из других потоков.
Можно с этого места подробней? Я так понимаю, что ты уникальные указатели имел ввиду? А что насчет разделяемых? А как данные м/у потоками передавать, коль есть такая прикладная необходимость?
Здравствуйте, vdimas, Вы писали:
C>>Азул живёт — у них машины покупают высокоскоростные трейдеры, которые на латентности собаку съели. V>А какая латентность получается? А то озвученные 1ms — это никуда не годится.
У них он полностью pauseless с помощью аппаратной реализации forwarding pointers.
Здравствуйте, vdimas, Вы писали:
C>>И система типов гарантирует, что объекты не будут иметь ссылок на объекты из других потоков. V>Можно с этого места подробней? Я так понимаю, что ты уникальные указатели имел ввиду? А что насчет разделяемых? А как данные м/у потоками передавать, коль есть такая прикладная необходимость?
Всё просто — только иммутабельные объекты могут посылаться между задачами (с помощью очередей сообщений). Это означает, что они могут быть скопированы как по значению, так и по ссылке (на усмотрение реализации).
Мутабельные данные есть, но:
1) Мутабельность надо указывать явно.
2) Мутабельные данные ограничены одним потоком.
Ну и есть ещё unsafe-блоки, с помощью которых можно делать хаки.
Здравствуйте, VladD2, Вы писали:
VD>Это из серии анекдота — "Что думать? Трясти надо!...". Этот месяц вы потеряете ровно один раз. И быстро его отиграете на первом же проекте. А на втором у вас будет внушительная фора.
Не уверен что фора вообще будет. D даёт приятность кода, но не сокращение его по сравнению с C++. Если в команде уже умеют проф. писать на C++, то...
_>>Boost (ну эту в других языках требовать не будем — это по сути доработка и расширение C++) VD>Это подпорки к кривому язяку, чтобы он хоть чуточку походил на нормальные.
Хыхы, и у каких же нормальных языков в стандартную библиотеку входит функциональность типа Boost.Spirit? )
VD>10 секунд в гугле и нашел: VD>http://wxd.sourceforge.net/
Ты действительно думаешь что я этого не видел? ) Посмотри внимательно сам эту ссылку. Это действительно биндинг, находящийся в каком-то пре-альфа состояние (практические ничего не работает) и реализованый через какое-то wx.NET (), само находящееся в не лучшем состояние. Причём он уже устарел (так и не родившись), т.к. мы используем более новую версию библиотеки, чем у них там может подключаться.
AxTk не имеет никакого отношения к Tcl/Tk вообще. )))
_>>OpenCV (есть в Питоне) VD>Это С-шная библиотека.
Не совсем. У неё от рождения 3 интерфейса: C (неудобный естественно), C++, Python.
VD>Короче, лично мне все ясно. Ты даже не удосужился разобраться в вопросе (попробовать язык на практике), но уже вынес обвинительный приговор языку.
Хыхы, ну давай начнём с самого начала. Покажи мне GUI библиотеку, которую я могу использовать в реальном проекте ма D. Желательно кроссплатформенную, но как минимум работающую на windows и имеющую там красивый нативный вид.
И вот точно такое со всем языком творится все эти годы. И как ЭТО использовать в бизнес-проекте? А хотелось бы конечно...
VD>А я гляжу на тебя и других таких же критиков и понимаю, что реальных причин вы не назовете, так как они не технические.
Здравствуйте, alex_public, Вы писали:
_>Не уверен что фора вообще будет. D даёт приятность кода, но не сокращение его по сравнению с C++. Если в команде уже умеют проф. писать на C++, то...
Вот это уже другой разговор. Тут, правда, можно поспорить, но по крайней мере это уже не выглядит совершенно высосанным из пальца.
D действительно не сильно ушел от С++ (особенно 11-го) по возможностям, но все же есть, как минимум, два фактора которые делают разработку на D более быстрой:
1. Скорость компиляции. D модульный язык с весьма высокой скоростью компиляции. Это делает разработку намного более интерактивной.
2. D имеет безопасное подмножество и позволяет переложить управление памяти на GC. Так что куски проекта которые не требуют диких оптимизаций можно писать существенно быстрее и проще.
Ну, и естественно в D есть множество мелких фич облегчающих жизнь программиста. Так что заявление о том, что D ничего не даст явно не соответствуют действительности. Другой вопрос, что есть и более мощные языки.
_> Ты действительно думаешь что я этого не видел? )
Судя по тому что ты ниже накидал ссылок на С-ишные библиотеки, такое предположение не безосновательно.
_>Посмотри внимательно сам эту ссылку. Это действительно биндинг, находящийся в каком-то пре-альфа состояние (практические ничего не работает)
Как это можно понять из ссылки? Судя по копирайтам 2005-го и 2010-го годов, скорее можно сказать, что это весьма зрелый продукт. В прочем, порывшись я таки нашел информацию об этом.
_> и реализованый через какое-то wx.NET (),
Даже беглого чтения описания достаточно чтобы понять, что ты, не прав.
Он реализован не через wx.NET, а портирован с wx.NET. В основе лежит библиотека выставляющая C-интерфейс:
xD is not a D port of wxWidgets, so it uses the C++ libraries. It is composed of two parts: (2 static libraries)
* wxc is a C++ library which exposes the wxWidgets API as a collection of D-friendly functions (extern "C").
* wxd is a library written in D which parallels the wxWidgets (C++) classes, ported over from wx.NET (C#).
Очевидно, что wx.NET использует ту же С-шную библиотеку.
_>само находящееся в не лучшем состояние. Причём он уже устарел (так и не родившись), т.к. мы используем более новую версию библиотеки, чем у них там может подключаться.
Тут — да. Любая библиотека являющаяся оберткой для библиотеки на другом языке будет отставать от жизни. Вопрос только насколько критично.
_>И ты предлагаешь использовать это в рабочем проекте? )))
ОК, wxWidgets — это С++-ное решение. Но на нем же мир не кончается. Есть GTK. Судя по этой ссылке библиотека в релизном состоянии. Почему не воспользоваться ей? Вам ведь нужен GUI, а не конкретная либа?
Ну, сори. Уж больно название они выбрали забавное. Как я понял — это опять какая-то надстройка над wxWidgets.
Складывается ощущение, что wxWidgets главный код в вашем проекте. У вас там своя то логика есть? Не ужели ее меньше чем возни с GUI-ом?
_>>>OpenCV (есть в Питоне) VD>>Это С-шная библиотека.
_>Не совсем. У неё от рождения 3 интерфейса: C (неудобный естественно), C++, Python.
Совсем. То что к чему-то прикрутили обертку на С++ не значит, что сама библиотека стала С++-ной. Создай свою обертку на D и будет даже удобнее.
_>Хыхы, ну давай начнём с самого начала. Покажи мне GUI библиотеку, которую я могу использовать в реальном проекте ма D. Желательно кроссплатформенную, но как минимум работающую на windows и имеющую там красивый нативный вид.
_>Я могу даже подсказать полезную ссылку: http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries
_>И вот точно такое со всем языком творится все эти годы. И как ЭТО использовать в бизнес-проекте? А хотелось бы конечно...
А что вас не устраивает в GTK то?
Кстати, а для каких платформ вы код пишите?
_>А я гляжу на тебя и вижу теоретика. )
D я не использую, так как использую несколько (мягко говоря) более мощный язык (думаю все знают какой). Но я четко вижу, что потенциальные пользователи D откровенно забивают на него по причине лени и страха. И именно это приводит к тому, что до сих пор не решены, казалось бы, мелкие проблемы.
Посуди сам. Что стоит 3-4 конторам взяться за тот биндинг к wxWidgets? Или даже написать свой кроплатформный аналог?
Но все ждут пока другие пройдут этот путь, чтобы потом... продолжить писать на С++ и периодически материться на жизнь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>D действительно не сильно ушел от С++ (особенно 11-го) по возможностям, но все же есть, как минимум, два фактора которые делают разработку на D более быстрой: VD>1. Скорость компиляции. D модульный язык с весьма высокой скоростью компиляции. Это делает разработку намного более интерактивной. VD>2. D имеет безопасное подмножество и позволяет переложить управление памяти на GC. Так что куски проекта которые не требуют диких оптимизаций можно писать существенно быстрее и проще.
Мне вот кажется, что если бы C++11 не вышел, то D возможно и взлетел бы.
VD>Ну, и естественно в D есть множество мелких фич облегчающих жизнь программиста. Так что заявление о том, что D ничего не даст явно не соответствуют действительности. Другой вопрос, что есть и более мощные языки.
Как бы это сказать... Я сомневаюсь что D что-то даст в "бизнес масштабах". Но и приятность работы программеров тоже важна, при условии что за это не надо платить слишком много. Т.е. я бы сказал переходить на D (у нас как раз я определяю все подобные вещи), при условии наличия активной D инфраструктуры (т.е. библиотек, как существующих, так и в активной разрабоке по всем новым поводам).
_>>AxTk не имеет никакого отношения к Tcl/Tk вообще. ))) VD>Ну, сори. Уж больно название они выбрали забавное. Как я понял — это опять какая-то надстройка над wxWidgets. VD>Складывается ощущение, что wxWidgets главный код в вашем проекте. У вас там своя то логика есть? Не ужели ее меньше чем возни с GUI-ом?
Ты не совсем понял. wxWidgets — это жирнющий монстр, в котором GUI скорее всего и половину не занимает. Т.е. это полноценный фреймворк, позволяющий писать реальные кроссплатформенные приложения. Кстати, в каких-то элементах его функциональность пересекается с Boost'ом (конфиги, файлы, сокеты и т.п.), но в большинстве своём дополняет.
И соответственно существует множество разных полезных библиотек, использующих разные элементы wxWidgets как базис. Даже без GUI.
Конкретно AxTk — это кроссплатформенное распознование/синтез речи (ну в смысле обёртка для sapi и т.п.), реализованное с использованием wxString и т.п.
Ну и потом кроме отдельных полезных библиотек есть ещё много wx объектных обёрток к C библиотекам. Т.е. wxCurl, wxsqlite и т.п.
В общем это просто большая удобная инфраструктура вокруг большой библиотеки, не входящая в неё саму. У QT тоже что-то похожее есть.
_>>Не совсем. У неё от рождения 3 интерфейса: C (неудобный естественно), C++, Python. VD>Совсем. То что к чему-то прикрутили обертку на С++ не значит, что сама библиотека стала С++-ной. Создай свою обертку на D и будет даже удобнее.
Ну достаточно посмотреть что там внутри, что бы понять кто тут к кому обёртка. ) Там внутри сплошные классы и шаблоны. ) Хотя вообще это к теме дискуссии никакого отношения не имеет вообще — зачем об этом спорим? )))
VD>А что вас не устраивает в GTK то?
Оно страшное под windows.
VD>Кстати, а для каких платформ вы код пишите?
Windows — основные деньги. OS X — мелкая добавка. Linux версию держим для красоты (типа что бы было, т.к. нам это ничего не стоит). Под iOS собирается проект, но с точки зрения бизнеса пока не нужен. Думаем что делать с Андроидом (java — гадость), захватывающим мир планшетов.
VD>D я не использую, так как использую несколько (мягко говоря) более мощный язык (думаю все знают какой). Но я четко вижу, что потенциальные пользователи D откровенно забивают на него по причине лени и страха. И именно это приводит к тому, что до сих пор не решены, казалось бы, мелкие проблемы.
А у этого твоего языка случаем проблем не больше чем у D? ) Кстати, я пока так и не нашёл время его посмотреть подробно, хотя планирую. Правда это в любом случае будет не для практической работы, т.к. .Net там.
VD>Посуди сам. Что стоит 3-4 конторам взяться за тот биндинг к wxWidgets? Или даже написать свой кроплатформный аналог?
Ммм, вот как раз в идеале было бы написать свой кроссплатформенный фреймворк (для начала просто GUI) на D. Это же нативный язык со всеми возможностями для этого. Причём с учётом возможностей D он был бы ещё намного красивее. Но как раз такой проект не то что 3-4 конторы не потянут (в приемлемое время), но похоже никто сейчас не возьмётся. Если посмотреть на тот же wxWidgets, то там просто тонны кода (т.к. он релизован нативно под каждую платформу, на ifdef грубо говоря), причём что бы его повторить, нужны спецы под разные платформы и языки (к примеру в OS X варианте там Objective-C++ используется ).
Что касается биндинга, то это и мы потянули бы сами. Если бы серьёзно решили потратить на это время. Но как бы не до этого...
VD>Но все ждут пока другие пройдут этот путь, чтобы потом... продолжить писать на С++ и периодически материться на жизнь.
Ну да, типа того))) Типа ждём халявы. ))) Я и не отрицаю.
Нюанс в том, что во многих других языках (включая даже Хаскель) эта халява имеется...
Здравствуйте, alex_public, Вы писали:
_>Хыхы, ну давай начнём с самого начала. Покажи мне GUI библиотеку, которую я могу использовать в реальном проекте ма D. Желательно кроссплатформенную, но как минимум работающую на windows и имеющую там красивый нативный вид.
_>Я могу даже подсказать полезную ссылку: http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries
Сорри, что вклиниваюсь в беседу. А ты прорабатывал для себя основные библиотеки, указанные по этой ссылке? Меня интересует DIUP — это обёртка над IUP — библиотека для С и Lua, имхо, неплохая альтернатива для WxWidgets (я как-то давал тебе ссылку на этот проект). Но на той страничке ссылка DIUP мёртвая, а вручную что-то не находится. Не довелось искать этот биндинг?
Кстати, там есть ссылка на проект Harmonia, его делал местный c-smile (HTMLLayout), он где-то описывал все проблемы, с которыми он столкнулся в тогдашнем D, было полезно.
Здравствуйте, PSV100, Вы писали:
PSV>Сорри, что вклиниваюсь в беседу. А ты прорабатывал для себя основные библиотеки, указанные по этой ссылке?
Я смотрел там две отдельные вещи: 1. биндинги к известным мне C++ библиотекам, умеющим выглядеть нативно 2. родные D библиотеки (как нечто новое для себя).
По поводу пункта 1 там всё очень печально — ни одного законченного продукта.
По поводу пункта 2 обнаружился довольно симпатичный вариант в потенциале — DFL. Оно сделано уже нормально в стиле D, использует нативные контролы и даже имеется в наличие визуальный редактор. Но оно только под window и пока ещё очень бедное. Т.е. набор фунцкиональности там только самый самый базовый.
PSV> Меня интересует DIUP — это обёртка над IUP — библиотека для С и Lua, имхо, неплохая альтернатива для WxWidgets (я как-то давал тебе ссылку на этот проект). Но на той страничке ссылка DIUP мёртвая, а вручную что-то не находится. Не довелось искать этот биндинг?
IUP в общем то не плохой продукт, как я посмотрел. Но под OSX вроде как используется не нативный интерфейс. Само программирование в стиле C тоже не особо привычно. Ну и редакторов визуальных не видно, хотя это не так принципиально.
Кстати, странно что IUP нет там в списке нормально работающих с D — оно же в чистом C интерфейсе, а значит в теории может быть использовано из D напрямую...
PSV>Кстати, там есть ссылка на проект Harmonia, его делал местный c-smile (HTMLLayout), он где-то описывал все проблемы, с которыми он столкнулся в тогдашнем D, было полезно.
Ага. Ну сам HTMLayout нам не особо интересен, а вот про D я вроде что-то такое читал, когда его разбирал.
Здравствуйте, alex_public, Вы писали:
PSV>> Меня интересует DIUP — это обёртка над IUP — библиотека для С и Lua, имхо, неплохая альтернатива для WxWidgets (я как-то давал тебе ссылку на этот проект). Но на той страничке ссылка DIUP мёртвая, а вручную что-то не находится. Не довелось искать этот биндинг?
_>IUP в общем то не плохой продукт, как я посмотрел. Но под OSX вроде как используется не нативный интерфейс. Само программирование в стиле C тоже не особо привычно. Ну и редакторов визуальных не видно, хотя это не так принципиально.
_>Кстати, странно что IUP нет там в списке нормально работающих с D — оно же в чистом C интерфейсе, а значит в теории может быть использовано из D напрямую...
Насколько я понимаю, этот IUP довольно редко кто использует, это далеко не Qt, и в основном из-под Lua.
), само находящееся в не лучшем состояние. Причём он уже устарел (так и не родившись), т.к. мы используем более новую версию библиотеки, чем у них там может подключаться.
).
