Qt SDK with integrated D and bindings for D ?
-
Hi!
Would be nice, if you create an Qt SDK with integrated D and bindings for D.
There already existing outdated D-bindings for Qt called "QtD":
http://www.dsource.org/projects/qtd
You already mentioned it at
http://developer.qt.nokia.com/wiki/Category:LanguagebindingsC++ is not a modern language. So there comming permanently new programming-languages out.
But I think for native-compilers D could be the follower of C/C++.Qt already tried to publish bindings for Java called Qt Jambi. But Jambi is more an alternative to the not so much used SWT. Because every Jambi developer needed to put to its platform independent Java-binaries (mostly *.jar files) platform dependent DLL's or so's.
But the most Java-developer prefered to create 100% platform independent Java-programs. And so they used Swing.
Additional Qt Jambi programs runs slower then Qt C++ programs.
Qt developer wants to create platform dependent, fast programs. And D is fast like C/C++. But a little bit more modern.Greatings
theuserbl -
Had some comments ready for this, but will not post. I'm interested in how the discussion will unfold.
Just take a look here to see how plausible your proposal is: "language popularity":http://langpop.com/. Inclusion in SDK is very, very unlikely (even Jambi was never included in SDK, and for good reasons), as C++ is very popular, and available for basically every platform in existence.
-
@sierdzio: Its an henn <-> egg problem.
D and other new languages aren't so much used, because there are not so much libraries (like GUI-libraries) written in it and for it. And the developer of that libraries (like Qt) looking, which language is mostly used.But that hen - egg problem can be solved, when a big library-creator working together with a creator of a new modern language.
Edit: For example look at Objective C. Since years no one used it. But after Apple have created its MacOSX and the libraries upon it, it is much more used, then before.
-
about Apple: sadly, you are right ;)
Yeah, I generally agree with you here. C++ has some drawbacks, too. Currently though, looking at the reality, I would say there is no way for this change to happen. Even now, some people in Qt look at JS entering into QML as a stab in the back. We are attached to C++, and have grown accustomed to both it's pros and cons :)
Anyway, Qt is Open Governed, and Open Sourced, if there gathers enough people to do the work, it can be done. I don't think it plausible, but it may come true.
-
I think that additional language bindings for Qt for other languages is always worthwhile.
However on the other points I think your view of the world is somewhat different to my own.
"C++ is not a modern language." -- but still remains practical, efficient, maintained, understood at solving computer problems in 2012.
"Jambi is more an alternative to the not so much used SWT." -- SWT is far more used than QtJambi is, the major driving force behind that is IBM and Eclipse. Even as a Qt supporter; I don't think it is fair to say SWT is not so much used, I think some publishers have claimed the Eclipse ecosystem is worth over a Billion dollars back in '06. [Source: InfoWorld.com 18-Sep-2006, IT Jobs Report, page 22, article: Eclipse: A Billion-Dollar Baby?]
"Because every Jambi developer needed to put to its platform independent Java-binaries (mostly *.jar files) platform dependent DLL’s or so’s.
But the most Java-developer prefered to create 100% platform independent Java-programs. And so they used Swing."I think you misunderstand the two points here, they are not related.
Point 1) Are you aware that each Java Runtime Environment includes a bunch of platform dependant DLLs or DSOs. Also that Swing and AWT itself is implemented via the use of those DLLs/DSOs. Just because they are hidden to you (because you did not take the time to look) does not mean they do not exist. In this regard QtJambi is no different, but I can understand your point, a developer wishing to use QtJambi must think about how to bundle platform dependant JARs so their application deploys correctly. However changes are being made reduce the amount of work needed to deploy an application, there are technologies like OSGi and Jigsaw (either already here or on their way) that will do all the heavy lifting with regards to managing the platform specific part.
Point 2) The platform indepedancy claim is really being honoured at the API level presented to the application programmer. Would you believe it but the Qt C++ API also attempts to achieve this across the wide range of devices it has been targeted for. There is no need when using QtJambi for an application programmer to understand any C++, use any C++, they can do all their working in Java using their favorite development environment with a high degree of confidence that if they wanted their application to work on one of the other major desktop platforms (windows/linux/mac) they only need to switch 2 JAR files in their project.
...
While I do not know enough about the language D to comment on that matter, I can confirm my own findings with Qt C++ application compared with Qt Java application development.
I think Java assisted by its incredibly good tooling is a faster application development environment (than C++). I think that building and maintaining large (many committers, many LoC, many independant teams working on modules) reliable projects in Java is far easier (than C++). I think that it is too easy for bugs in C++ applications to cause unrecoverable crashing with 1 bug bringing the while application down.
While I appreciate a better job of building (faster, memory efficient) an application is possible in C++ this does not come without a cost, many classes of application exists where the efficiency difference is just not that important. [I remember a talk I heard when QML was being explained that when Qt devs tested they found JavaScript to not be that much slower; I cracked out my wry smile] We're living in a world where a mobile handset device has ~1Gb memory and quad-channel memory exists on the performance desktop (and will soon be in that mobile handset).
Many of my points are not really caused by Java (the language) itself but by the use of a VM. I look forward to other VMs and languages on VMs becoming mainstream in the future; but for now JVM will do for me.
Maybe some of these points translate well to the language D.
