too early for D2 and too late for D1
Hello! My first post to this newsgroup was a little bit more than 6 months ago and today I've decided to leave D and use C(P)ython + Qt for our open-source project of writing multi-platform desktop application. The D community is very nice and supportive, Walter, Andrei & co. are working hard, but, imho, D is not ready (yet). Recently, after switching from Linux to (Free)PC-BSD I even lost ability to have working compiler on x86_64 (none of the compilers is available in ports). The crucial thing is that D's ecosystem is simply not ready for day-to-day GUI programming and there is no clear roadmap so that one can anticipate when to expect that something will be done. Let me say, that I really like what D has on its plate, but language needs libraries to be successful, otherwise it is only promise-land. I've become tired for programming language's ecosystem to become mature...waited too long with Haskell and arrived to D hoping it is more pragmatic for day-to-day usage, but the situation seems even worse...Yeah, I know...I arrived at the wrong time during D1 --> D2 transition... That's, why I believe that the mantra in the subject, which I coined in IRC the other day, holds true. I'm thankful to all the members of this group for every piece of advice and input I received, as well to Andrei (his book is on my shelf - I even put it in the hardcover), but I want to code my project *today*, have plenty of (GUI) choices, lot of docs, tools and clear roadmap where the certain projects are going. I hope I might re-evaluate D2 sometime in the future for some other project... Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: too early for D2 and too late for D1
Gour-Gadadhara Dasa Wrote: One thing, go hang yourself. We don't like loser talk from people who only waste our time. Everyone agrees here D2 is the right tool for the job. Why did you come here to rant about D? - G.W.
Re: too early for D2 and too late for D1
Gour, please disregard the troll above. If you're going with Python and Qt, I'd wholeheartedly recommend this book: http://www.qtrac.eu/pyqtbook.html Making GUIs with PyQT is dead simple. And Nokia already has that new LGPL(I think?)-licensed binding in place - http://www.pyside.org. So your decision might not be bad at all. What type of desktop app are you building? Does it need to be very-high performance? Python itself isn't too bad with Qt, I don't think it was slow in any way the last time I used it.
Re: too early for D2 and too late for D1
Am 17.04.2011 20:18, schrieb Gary Whatmore: > Gour-Gadadhara Dasa Wrote: > > One thing, go hang yourself. We don't like loser talk from people who only > waste our time. Everyone agrees here D2 is the right tool for the job. Why > did you come here to rant about D? > > - G.W. Do you have a split personality or why do you write "we"?
Re: too early for D2 and too late for D1
Andrej Mitrovic Wrote: > Gour, please disregard the troll above. > > If you're going with Python and Qt, I'd wholeheartedly recommend this > book: http://www.qtrac.eu/pyqtbook.html > Making GUIs with PyQT is dead simple. And Nokia already has that new > LGPL(I think?)-licensed binding in place - http://www.pyside.org. So > your decision might not be bad at all. > > What type of desktop app are you building? Does it need to be > very-high performance? Python itself isn't too bad with Qt, I don't > think it was slow in any way the last time I used it. W-T-F, why are you defending *other* languages? In every young language community the first users have to make sacrifices and build the ecosystem. That's how it goes. If we keep telling them Python is a better choice, nobody will implement the badly needed libraries.
Re: too early for D2 and too late for D1
D2 is ready. There are some compiler bugs that might cause problems, but they will go away hopefully soon. And I don't think GUI programming is the first reason people come to D.
Re: too early for D2 and too late for D1
On 4/17/2011 11:18 AM, Gary Whatmore wrote: One thing, go hang yourself. We[...] Gour-Gadadhara Dasa has done nothing to merit such inexcusable rudeness. I appreciate his polite and thoughtful post about why D is not the right solution for his needs at this time.
Re: too early for D2 and too late for D1
I'm not defending other languages, I'm recommending them. I'm also recommending D when its appropriate. But nobody is forced to use just one programming language. I use at least half a dozen languages throughout my average week; C, C++, Python, Delphi (rarely), D, AHK, batch (hehe, ok that one doesn't count :p), some ASM which I'm just playing around with for now, and probably other languages. Gour doesn't have to quit D, he can use some time-out for a while and see what Python has to offer. In the meantime the D ecosystem will likely grow. Now, these arguments aside, onto the technical side of things. You could build a GUI in Python and then link to D via callback functions. It shouldn't be a problem with either Python's ctypes or Cython, whichever might be easier to use. Python+Qt has been stable for a long while now, so it's really not a bad choice as a GUI language. And it has good documentation and books to learn from, and plenty of example code too. I'm not sure what that would do to performance (linking Python with D), but then again I don't know what type of desktop app Gour is building. On the other hand, I've seen Python being used in a realtime app that is linked with C++. For example Ableton Live (a fairly popular music sequencer) uses the Boost C++ Python binding for a big part of their application. They use it to interface with various MIDI and sequencing hardware, and various hardware manufacturers develop their own Ableton-specific Python scripts that add support to their special hardware so it works nicely in Ableton Live. I believe they might also be using Python to run their GUI, but I can't be sure since I've only heard that offhand from some people commenting about it. Now, there's a Python binding project for D1, PyD, with exception support and various other nice things. I don't know whether anyone will work on a D2 version. But from looking at its source it doesn't look *too* complicated. In fact there's a good part of that code seems to be implementation of common functions which were missing in D1 Phobos, but are here in Phobos2. So maybe it wouldn't be too hard to port that to D2 some day. But I don't know the details.
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 20:26:49 +0200 Andrej Mitrovic wrote: > Gour, please disregard the troll above. :-) > If you're going with Python and Qt, I'd wholeheartedly recommend this > book: http://www.qtrac.eu/pyqtbook.html Yeah...I just got reply from Mark if he is planning 2nd ed. or the first one is still not obosolete. > Making GUIs with PyQT is dead simple. And Nokia already has that new > LGPL(I think?)-licensed binding in place - http://www.pyside.org. I know about, although I may try with PyQt due to py3k support. > So your decision might not be bad at all. Well, it's not ideal, but some kind of compromise. > What type of desktop app are you building? Does it need to be > very-high performance? Vedic astrology program. Performance *might* be issue, although we'll use Swiss Ephmeris C-library and try to compensate possible lack of speed by using Cython. > Python itself isn't too bad with Qt, I don't think it was slow in > any way the last time I used it. Thank you for kind words. ;) Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 13:51:49 -0500 Caligo wrote: > And I don't think GUI programming is the first reason people come to > D. Well, http://d-programming-language.org/ page says: "D is a multi-paradigm programming language that combines a principled approach with a focus on *practicality*." and in my case I've *practical* need to write GUI app. :-) Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: too early for D2 and too late for D1
For what it's worth, the examples from Mark's book still compile with Python 2.7 and the latest PyQt bindings. And PyQt itself comes with examples that are stored in Python\lib\site-packages\pyqt4\examples\ . I don't think a lot has changed that breaks backward-compatibility since the book was published. I don't really know what benefits you would have from Python 3.x, I think 2.7 got some 3.x features backported to that version as well..
Re: too early for D2 and too late for D1
Gour-Gadadhara Dasa Wrote: > Well, http://d-programming-language.org/ page says: "D is a multi- > paradigm programming language that combines a principled approach > with a focus on *practicality*." and in my case I've *practical* need to > write GUI app. That's certainly true, if you think of the potential D2 provides. In 5 -- 20 years D will be a serious contestant and mature implementations beat C++ and traditional languages in many domains. Currently DMD produces much slower executables especially for high performance computing so you would be a total idiot to use D if the project time frame is less than 2 years. If you want to build some fortune 500 website from scratch, D doesn't deliver the functionality you need right now. The PHP/Java/C# platforms have hundreds of millions worth funding backing them. If you build a desktop application, D isn't the best choice, but you can still argue to your boss to use it instead because of your personal "productivity" issues. There's no other logical reason to use D instead of C++/Qt or some other mature GUI toolkit. Bloated executables aren't suitable for embedded platforms either, but in 10 -- 20 years we will have a D compiler that targets platforms with less than 4 MB of RAM+ROM. I find it unlike that we have a reliable D compiler for very small 32-bit embedded devices in 5 years.
Re: too early for D2 and too late for D1
jasonw wrote: > If you want to build some fortune 500 website from scratch, D > doesn't deliver the functionality you need right now. My clients and I would disagree :-) I've been using D, almost exclusively, to write business websites for quite a while now. There's a lot of big advantages there over more traditional web languages. I'm hoping to write up an article detailing some of it in the near future.
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 21:45:59 +0200 Andrej Mitrovic wrote: > For what it's worth, the examples from Mark's book still compile with > Python 2.7 and the latest PyQt bindings. And PyQt itself comes with > examples that are stored in Python\lib\site-packages\pyqt4\examples\ . > I don't think a lot has changed that breaks backward-compatibility > since the book was published. Mark has provided examples for Python 3. > I don't really know what benefits you would have from Python 3.x, I > think 2.7 got some 3.x features backported to that version as well.. Well, I believe that 2.7 is, similar to D1, dead-end, while 3.x is the future, as D2. ;) Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: too early for D2 and too late for D1
On Sun, Apr 17, 2011 at 2:52 PM, jasonw wrote: > Gour-Gadadhara Dasa Wrote: > >> Well, http://d-programming-language.org/ page says: "D is a multi- >> paradigm programming language that combines a principled approach >> with a focus on *practicality*." and in my case I've *practical* need to >> write GUI app. > > That's certainly true, if you think of the potential D2 provides. In 5 -- 20 > years D will be a serious contestant and mature implementations beat C++ and > traditional languages in many domains. Currently DMD produces much slower > executables especially for high performance computing so you would be a total > idiot to use D if the project time frame is less than 2 years. > > If you want to build some fortune 500 website from scratch, D doesn't deliver > the functionality you need right now. The PHP/Java/C# platforms have hundreds > of millions worth funding backing them. > > If you build a desktop application, D isn't the best choice, but you can > still argue to your boss to use it instead because of your personal > "productivity" issues. There's no other logical reason to use D instead of > C++/Qt or some other mature GUI toolkit. > > Bloated executables aren't suitable for embedded platforms either, but in 10 > -- 20 years we will have a D compiler that targets platforms with less than 4 > MB of RAM+ROM. I find it unlike that we have a reliable D compiler for very > small 32-bit embedded devices in 5 years. > 5 to 20 years? 10 to 20 years? How do you come up with those big and depressing numbers? I personally think within 2 to 4 years there is going to be an explosion of software written in D.
Re: too early for D2 and too late for D1
On Sun, Apr 17, 2011 at 4:37 AM, Gour-Gadadhara Dasa wrote: > > Hello! > > My first post to this newsgroup was a little bit more than 6 months ago > and today I've decided to leave D and use C(P)ython + Qt for our > open-source project of writing multi-platform desktop application. > > The D community is very nice and supportive, Walter, Andrei & co. are > working hard, but, imho, D is not ready (yet). > > Recently, after switching from Linux to (Free)PC-BSD I even lost > ability to have working compiler on x86_64 (none of the compilers is > available in ports). Frankly, if your definition of "not ready" is that the compiler isn't packaged for you, D isn't the right community to begin with. > The crucial thing is that D's ecosystem is simply > not ready for day-to-day GUI programming and there is no clear roadmap > so that one can anticipate when to expect that something will be done. The problem with ecosystems is that there is never a roadmap unless your development follows the Microsoft model, where everything is benevolently dictated. That works, but D isn't Microsoft. > > Let me say, that I really like what D has on its plate, but language > needs libraries to be successful, otherwise it is only promise-land. D has libraries, it's just a matter of downloading, building, and reporting bugs rather than installing, reading a book, and firing up the UI designer. They're rough, but they're there. > > I've become tired for programming language's ecosystem to become > mature...waited too long with Haskell and arrived to D hoping it is > more pragmatic for day-to-day usage, but the situation seems even > worse...Yeah, I know...I arrived at the wrong time during D1 --> D2 > transition... > > That's, why I believe that the mantra in the subject, which I coined > in IRC the other day, holds true. > > I'm thankful to all the members of this group for every piece of > advice and input I received, as well to Andrei (his book is on my > shelf - I even put it in the hardcover), but I want to code my project > *today*, have plenty of (GUI) choices, lot of docs, tools and clear > roadmap where the certain projects are going. > > I hope I might re-evaluate D2 sometime in the future for some other > project... > I'm (and I think I can say we're) sad to see you go, and hopefully you'll look to D in the future, but in the present, choose the right tool for the job. It's unwise to do anything else. (Unless you're a college student with too much time on his hands, but I'm pretty sure that's not your situation)
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 15:52:36 -0400 jasonw wrote: > If you build a desktop application, D isn't the best choice, but you > can still argue to your boss to use it instead because of your > personal "productivity" issues. There's no other logical reason to > use D instead of C++/Qt or some other mature GUI toolkit. In my case, I'm going to write desktop application and there is no 'boss' - it's going to be open-source. :-) Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: too early for D2 and too late for D1
Am 17.04.2011 21:52, schrieb jasonw: > Gour-Gadadhara Dasa Wrote: > >> Well, http://d-programming-language.org/ page says: "D is a multi- >> paradigm programming language that combines a principled approach >> with a focus on *practicality*." and in my case I've *practical* need to >> write GUI app. > > That's certainly true, if you think of the potential D2 provides. In 5 -- 20 > years D will be a serious contestant and mature implementations beat C++ and > traditional languages in many domains. Currently DMD produces much slower > executables especially for high performance computing so you would be a total > idiot to use D if the project time frame is less than 2 years. *Much* slower? Really? What benchmarks are you citing? > > If you want to build some fortune 500 website from scratch, D doesn't deliver > the functionality you need right now. The PHP/Java/C# platforms have hundreds > of millions worth funding backing them. > > If you build a desktop application, D isn't the best choice, but you can > still argue to your boss to use it instead because of your personal > "productivity" issues. There's no other logical reason to use D instead of > C++/Qt or some other mature GUI toolkit. > > Bloated executables aren't suitable for embedded platforms either, but in 10 > -- 20 years we will have a D compiler that targets platforms with less than 4 > MB of RAM+ROM. I find it unlike that we have a reliable D compiler for very > small 32-bit embedded devices in 5 years. Do you really think in "10 -- 20 years" somebody will care of your code runs in an embedded platform with only 4MB of RAM+ROM? Memory etc is so cheap that these platforms will get more powerful. Why should it take so long to have such a compiler? On the one hand: Why are D executables so "bloated"? 1. Phobos and druntime is statically compiled in. On a really limited embedded platform you wouldn't use Phobos anyway, but write your own standardlib and runtime that suit your needs (it's not like anybody would use full C++ with STL on such a platform. Well, probably not even C++ at all or only a very limited subset). 2. Garbage from templates/CTFE. You just could use less templates and stuff for your embedded platform.. also I think this will be fixed soon(ish). Don just fixed many things in CTFE, maybe this already fixes bloat, but I'm not sure. So how long could it take until there's "a D compiler that targets platforms with less than 4 MB of RAM+ROM"? I'd say anywhere between right now and never. Maybe someone already decided to develop such a compiler and told nobody yet (right now). Or someone starts now or soon and has it ready in a year or two. If nobody is interesting in developing such a compiler, we'll never have one. So: It will be there once somebody develops it. If he takes LDC or GDC (or maybe even DMD) as a basis maybe something like that could be done relatively fast (if the team is big enough and has time etc). As mentioned before, Phobos would probably not be used on such platforms, so there's no need to wait for Phobos to become more mature/complete until developing such a compiler. Cheers, - Daniel
Re: too early for D2 and too late for D1
Caligo Wrote: > On Sun, Apr 17, 2011 at 2:52 PM, jasonw wrote: > > Gour-Gadadhara Dasa Wrote: > > > >> Well, http://d-programming-language.org/ page says: "D is a multi- > >> paradigm programming language that combines a principled approach > >> with a focus on *practicality*." and in my case I've *practical* need to > >> write GUI app. > > > > That's certainly true, if you think of the potential D2 provides. In 5 -- > > 20 years D will be a serious contestant and mature implementations beat C++ > > and traditional languages in many domains. Currently DMD produces much > > slower executables especially for high performance computing so you would > > be a total idiot to use D if the project time frame is less than 2 years. > > > > If you want to build some fortune 500 website from scratch, D doesn't > > deliver the functionality you need right now. The PHP/Java/C# platforms > > have hundreds of millions worth funding backing them. > > > > If you build a desktop application, D isn't the best choice, but you can > > still argue to your boss to use it instead because of your personal > > "productivity" issues. There's no other logical reason to use D instead of > > C++/Qt or some other mature GUI toolkit. > > > > Bloated executables aren't suitable for embedded platforms either, but in > > 10 -- 20 years we will have a D compiler that targets platforms with less > > than 4 MB of RAM+ROM. I find it unlike that we have a reliable D compiler > > for very small 32-bit embedded devices in 5 years. > > > > 5 to 20 years? 10 to 20 years? How do you come up with those big and > depressing numbers? I'd like to be more optimistic, but I'm comparing the development to projects such as LLVM. The ultimate performance goal isn't static. The leading compilers and languages are getting better so the goal is also going higher with every new release of GCC, Fortran compilers, and LLVM. Don't get me wrong, D is already much faster than many "toy" languages. Faster than Java and C# in some applications. What's relevant is that the C/C++/Fortran users will only switch if D provides concrete performance improvements over their *existing* toolchains. It has taken LLVM several years and they're not yet even on par with GCC in all benchmarks. The web application issue depends on the amount of libraries. It's a community issue. The main embedded issue is code bloat. Nobody has come up with a proof of concept solution to typeinfo and template bloat. It's impossible to think it will be solved without proof of concept in less than 5 years. You disagree?
Re: too early for D2 and too late for D1
On 4/17/2011 1:00 PM, Adam D. Ruppe wrote: I've been using D, almost exclusively, to write business websites for quite a while now. There's a lot of big advantages there over more traditional web languages. I'm hoping to write up an article detailing some of it in the near future. Hopefully in time for the D article contest!
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 15:11:43 -0500 Andrew Wiley wrote: > Frankly, if your definition of "not ready" is that the compiler isn't > packaged for you, D isn't the right community to begin with. First of all, there is no 64bit compiler for FreeBSD. I was researching about gdc and Iain Buclaw told me (on IRC) that there might be problem with dmd runtime on FreeBSD. Moreover, "QtD requires a patched dmd compiler.", so I simply do not have time to fight such things. > D has libraries, it's just a matter of downloading, building, and > reporting bugs rather than installing, reading a book, and firing up > the UI designer. They're rough, but they're there. Can you name me some serious GUI application using e.g. QtD & sqlite database badck-end written in D2? > I'm (and I think I can say we're) sad to see you go, and hopefully > you'll look to D in the future, but in the present, choose the right > tool for the job. It's unwise to do anything else. /me nods > (Unless you're a college student with too much time on his hands, but > I'm pretty sure that's not your situation) Right. I'm not college student, want to program in my free time and desire to write open-source application instead of building ecosystem for what I anyway do not have required skills. :-) Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: too early for D2 and too late for D1
On 4/17/2011 1:27 PM, Daniel Gibson wrote: 1. Phobos and druntime is statically compiled in. On a really limited embedded platform you wouldn't use Phobos anyway, but write your own standardlib and runtime that suit your needs (it's not like anybody would use full C++ with STL on such a platform. Well, probably not even C++ at all or only a very limited subset). On 16 bit DOS computers, you can't use C++ STL or even exception handling.
Re: too early for D2 and too late for D1
On 4/17/11, Gour-Gadadhara Dasa wrote: > Well, I believe that 2.7 is, similar to D1, dead-end, while 3.x is the > future, as D2. ;) But you've opened this topic because D2 is not ready, and now you want to switch to Python 3 which might not be ready yet as well? E.g. see: python3wos.appspot.com I know a year or two ago there was a severe lack of libraries for Py3. Maybe things are better now, but I haven't checked. It's your call. :)
Re: too early for D2 and too late for D1
Walter Bright Wrote: > On 4/17/2011 1:27 PM, Daniel Gibson wrote: > > 1. Phobos and druntime is statically compiled in. On a really limited > > embedded platform you wouldn't use Phobos anyway, but write your own > > standardlib and runtime that suit your needs (it's not like anybody > > would use full C++ with STL on such a platform. Well, probably not even > > C++ at all or only a very limited subset). > > On 16 bit DOS computers, you can't use C++ STL or even exception handling. I'd like to hear your comments about the 32-bit D2 and minimal executables issue. If I use dietlibc and gcc, the minimal (static) binary is about 0.2 kilobytes. DMD should have some switch (-embedded) which leaves out all the cruft I don't need. I'd like to use the cool new features and start with this kind of minimal executables. 0.5 - 50 kilobyte range is optimal.
Re: too early for D2 and too late for D1
On 4/17/2011 1:46 PM, jasonw wrote: I'd like to hear your comments about the 32-bit D2 and minimal executables issue. If I use dietlibc and gcc, the minimal (static) binary is about 0.2 kilobytes. DMD should have some switch (-embedded) which leaves out all the cruft I don't need. I'd like to use the cool new features and start with this kind of minimal executables. 0.5 - 50 kilobyte range is optimal. Are you talking about static linking, or using shared libraries?
Re: too early for D2 and too late for D1
On 4/17/2011 2:37 PM, Gary Whatmore wrote: In every young language community the first users have to make sacrifices and build the ecosystem. That's how it goes. While I'm not endorsing the rude tone of the rest of this post, this is an extremely good point. According to Wikipedia, Python is about 8 years older than D. I imagine that 8 years ago people were saying the same things about Python that they say about D now. Back then, everyone was using Perl for Python's niche and probably (I wasn't a programmer back then) saying how Python's ecosystem is too immature, Perl is good enough despite its warts, there's so much existing code written in it, etc. There will always be a tradeoff between using the latest and greatest language that the ecosystem hasn't caught up with yet and using an older language with tons of legacy baggage, bad-in-hindsight or outdated design decisions and great, mature tools and libraries. D is strongly in the former category. Java and C++ are in the latter. Python is somewhere in between. Ironically, unlike the real trolls we deal with, Gour seems to understand this. All he's saying is that D2 does not embody the tradeoff he wants to make right now.
Re: too early for D2 and too late for D1
On 4/17/2011 1:34 PM, Gour-Gadadhara Dasa wrote: Moreover, "QtD requires a patched dmd compiler.", so I simply do not have time to fight such things. I'd also like to know which bugzilla entry has that patch!
Re: too early for D2 and too late for D1
Walter Bright Wrote: > On 4/17/2011 1:46 PM, jasonw wrote: > > I'd like to hear your comments about the 32-bit D2 and minimal executables > > issue. If I use dietlibc and gcc, the minimal (static) binary is about 0.2 > > kilobytes. DMD should have some switch (-embedded) which leaves out all the > > cruft I don't need. I'd like to use the cool new features and start with > > this > > kind of minimal executables. 0.5 - 50 kilobyte range is optimal. > > Are you talking about static linking, or using shared libraries? I mentioned static binaries, but I meant statically linked binaries. So yes, a situation where everything, including the standard library, is statically linked.
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 13:45:06 -0700 Walter Bright wrote: > I'd also like to know which bugzilla entry has that patch! See: https://bitbucket.org/qtd/repo/wiki/Home and https://bitbucket.org/qtd/repo/wiki/DmdPatch Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: too early for D2 and too late for D1
On 04/17/2011 03:00 PM, Adam D. Ruppe wrote: jasonw wrote: If you want to build some fortune 500 website from scratch, D doesn't deliver the functionality you need right now. My clients and I would disagree :-) I've been using D, almost exclusively, to write business websites for quite a while now. There's a lot of big advantages there over more traditional web languages. I'm hoping to write up an article detailing some of it in the near future. Don't forget the iPad2 contest... Andrei
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 22:44:20 +0200 Andrej Mitrovic wrote: > But you've opened this topic because D2 is not ready, and now you want > to switch to Python 3 which might not be ready yet as well? E.g. see: > python3wos.appspot.com Fortunately, Python comes with the big "batteries included" so that besides pyQt & pytz, no need for anything else. Moreover, the majority of stuff from the above list is Plone, Zope & Django stuff which we do not care about. Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: too early for D2 and too late for D1
"Adam D. Ruppe" wrote in message news:iofgtn$1ifg$1...@digitalmars.com... > jasonw wrote: >> If you want to build some fortune 500 website from scratch, D >> doesn't deliver the functionality you need right now. > > My clients and I would disagree :-) > > I've been using D, almost exclusively, to write business websites > for quite a while now. There's a lot of big advantages there over > more traditional web languages. I'm hoping to write up an article > detailing some of it in the near future. Yea. Java and C# might be more mature than D right now, but D is just such a better langauge anyway (IMO) that I find D's immaturity to be a huge improvement over Java/C#'s limitations. As far as the maturity of PHP though...PHP has *never* been anything that even remotely resembed "mature" (or "stable" for that matter), and I don't believe for a second that it ever will be. It is popular, heavily used, and has a big ecosystem, but it's like a metropolitan city that's built in a really big playground sandbox using silly putty instead of mortar. It's like VB or COBOL: A toy that businesses have mistaken for a serious langauge.
Re: too early for D2 and too late for D1
== Quote from Gour-Gadadhara Dasa (g...@atmarama.net)'s article > --Sig_/Ckct3lX7w5hlz_Hd5UDhpMB > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > On Sun, 17 Apr 2011 15:11:43 -0500 > Andrew Wiley wrote: > > Frankly, if your definition of "not ready" is that the compiler isn't > > packaged for you, D isn't the right community to begin with. > First of all, there is no 64bit compiler for FreeBSD. I was > researching about gdc and Iain Buclaw told me (on IRC) that there > might be problem with dmd runtime on FreeBSD. Emphasis on the word 'might' O:) There should be little reason why the compiler won't build/work sweet as roses - as no one's tested though, there may be some gaps in the C bindings that trigger static asserts, throw undefined identifier errors, or evoke some wacky occurrences in runtime.
Re: too early for D2 and too late for D1
2011/4/17 Gour-Gadadhara Dasa > > On Sun, 17 Apr 2011 15:11:43 -0500 > Andrew Wiley wrote: > > > Frankly, if your definition of "not ready" is that the compiler isn't > > packaged for you, D isn't the right community to begin with. > > First of all, there is no 64bit compiler for FreeBSD. I was > researching about gdc and Iain Buclaw told me (on IRC) that there > might be problem with dmd runtime on FreeBSD. > > Moreover, "QtD requires a patched dmd compiler.", so I simply do not > have time to fight such things. > I just want to add one thing. I am, too, trying to develop "real" open source applications in my free time, as well as practical closed source applications at work. The problem I have been facing even since the start, and are still facing, is that even if _I_ can be motivated to overcome these hurdles, I cannot expect everyone else to feel the same motivation for a new "obscure" C-like language. * At work, I have a hard time explaining to my co-workers why they need 3 hand-rolled, "this particular version" of compilers and libraries they've never heard of, just to compile my simple 200-line Mpeg analyzer. * At my free time it's even worse. Finding people able and willing to spend some time on MY pet project for free is hard enough in itself. Explaining to them why they must first spend an afternoon dealing with dependencies drive away the few that got past the first criteria. My view, is the D community right now are thinking long and hard about their own needs, and less of the needs of their users. (For a language, the application programmer IS the user.) Maybe even rightly so, getting things language-wise right from the start IS important! However, if it is desirable to attract developers that want to use D for productivity right now, there are a lot of practical issues that needs addressing, rough edges to smoothen, and hardly any of them lie in the language itself.
Re: too early for D2 and too late for D1
> 2011/4/17 Gour-Gadadhara Dasa > > > On Sun, 17 Apr 2011 15:11:43 -0500 > > > > Andrew Wiley wrote: > > > Frankly, if your definition of "not ready" is that the compiler isn't > > > packaged for you, D isn't the right community to begin with. > > > > First of all, there is no 64bit compiler for FreeBSD. I was > > researching about gdc and Iain Buclaw told me (on IRC) that there > > might be problem with dmd runtime on FreeBSD. > > > > Moreover, "QtD requires a patched dmd compiler.", so I simply do not > > have time to fight such things. > > I just want to add one thing. I am, too, trying to develop "real" open > source applications in my free time, as well as practical closed > source applications at work. > > The problem I have been facing even since the start, and are still > facing, is that even if _I_ can be motivated to overcome these > hurdles, I cannot expect everyone else to feel the same motivation for > a new "obscure" C-like language. > * At work, I have a hard time explaining to my co-workers why they > need 3 hand-rolled, "this particular version" of compilers and > libraries they've never heard of, just to compile my simple 200-line > Mpeg analyzer. > * At my free time it's even worse. Finding people able and willing to > spend some time on MY pet project for free is hard enough in itself. > Explaining to them why they must first spend an afternoon dealing with > dependencies drive away the few that got past the first criteria. > > My view, is the D community right now are thinking long and hard about > their own needs, and less of the needs of their users. (For a > language, the application programmer IS the user.) Maybe even rightly > so, getting things language-wise right from the start IS important! > However, if it is desirable to attract developers that want to use D > for productivity right now, there are a lot of practical issues that > needs addressing, rough edges to smoothen, and hardly any of them lie > in the language itself. It's normal to have to deal with a new toolchain when dealing with a new programming language. It doesn't matter how mature a programming language and its toolchain are; if you're not familiar with it, then you have some learning to do. That's true of any programming language. Now, that's obviously a hurdle, but it's one that you always have to deal with when dealing with a new programming language, no matter how good it is or isn't. It's true that if the language were more mature, it would probably be easier to install and set up the compiler and standard libraries (particularly since Linux distros would then be set up to just install them all properly if you tell it to install the appropriate package or packages), but there are _always_ issues with getting someone to use a new language. As for improvements to D, its libraries, and its toolchain, those improvements _are_ happening. All you have to do is look at the changelog to see that work is being done. However, there are only so many people involved, and it takes time. So, no, in many ways, D is not ready for prime time, but it's getting there. D is very useable at this point, but there's a still a lot of work to be done for it, and whether it'll do what you're looking for and do it well enough depends entirely on what you're trying to do. GUI applications would be one area where it's definitely behind, but GUI libraries are one of the hardest and most complicated types of libraries out there, so they're likely to be behind. We'll get there, but it takes time. D continues to improve, but it still has a ways to go. But if you're willing to put up with its issues as it matures, it's well worth using. - Jonathan M Davis
Re: too early for D2 and too late for D1
On 4/17/2011 1:54 PM, jasonw wrote: Walter Bright Wrote: On 4/17/2011 1:46 PM, jasonw wrote: I'd like to hear your comments about the 32-bit D2 and minimal executables issue. If I use dietlibc and gcc, the minimal (static) binary is about 0.2 kilobytes. DMD should have some switch (-embedded) which leaves out all the cruft I don't need. I'd like to use the cool new features and start with this kind of minimal executables. 0.5 - 50 kilobyte range is optimal. Are you talking about static linking, or using shared libraries? I mentioned static binaries, but I meant statically linked binaries. So yes, a situation where everything, including the standard library, is statically linked. Many D features, such as the GC, are simply going to require a significant amount of code in the library. It is possible to cut down the library size if you are willing to eschew some features.
Re: too early for D2 and too late for D1
On 4/17/2011 1:55 PM, Gour-Gadadhara Dasa wrote: On Sun, 17 Apr 2011 13:45:06 -0700 Walter Bright wrote: I'd also like to know which bugzilla entry has that patch! See: https://bitbucket.org/qtd/repo/wiki/Home and https://bitbucket.org/qtd/repo/wiki/DmdPatch I clicked around that for a while, but can't seem to find the patch file dmd.dmd-version.patch
Re: too early for D2 and too late for D1
On 4/18/11, Walter Bright wrote: > On 4/17/2011 1:55 PM, Gour-Gadadhara Dasa wrote: >> On Sun, 17 Apr 2011 13:45:06 -0700 >> Walter Bright wrote: >> >>> I'd also like to know which bugzilla entry has that patch! >> >> See: >> >> https://bitbucket.org/qtd/repo/wiki/Home and >> >> https://bitbucket.org/qtd/repo/wiki/DmdPatch > > I clicked around that for a while, but can't seem to find the patch file > dmd.dmd-version.patch > > http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=raw
Re: too early for D2 and too late for D1
Am 18.04.2011 00:27, schrieb Andrej Mitrovic: > On 4/18/11, Walter Bright wrote: >> On 4/17/2011 1:55 PM, Gour-Gadadhara Dasa wrote: >>> On Sun, 17 Apr 2011 13:45:06 -0700 >>> Walter Bright wrote: >>> I'd also like to know which bugzilla entry has that patch! >>> >>> See: >>> >>> https://bitbucket.org/qtd/repo/wiki/Home and >>> >>> https://bitbucket.org/qtd/repo/wiki/DmdPatch >> >> I clicked around that for a while, but can't seem to find the patch file >> dmd.dmd-version.patch >> >> > http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=raw This should probably be mentioned at the bitbucket wiki.
Re: too early for D2 and too late for D1
On 4/17/2011 3:27 PM, Andrej Mitrovic wrote: http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=raw Got it, tanks!
Re: too early for D2 and too late for D1
On 4/18/11 12:34 AM, Daniel Gibson wrote: https://bitbucket.org/qtd/repo/wiki/Home and https://bitbucket.org/qtd/repo/wiki/DmdPatch I clicked around that for a while, but can't seem to find the patch file dmd.dmd-version.patch http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=raw This should probably be mentioned at the bitbucket wiki. Ah, sorry, this was a side effect of QtD currently being in limbo between Bitbucket (DVCS hosting) and DSource (wiki, issue tracker). I just replaced the Bitbucket Wiki frontpage with a link to DSource until someone finds time to properly migrate all the contents – the patch was not the only dead link… As for the patch itself, it is more or less just a quick hack to be able to access e.g. the module a declaration is in, which is needed for some parts of the enum handling code – Max Samukha knows the details. It should also be noted that you don't necessarily need to patch DMD if your application builds fine without the patch. David
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 21:49:34 + (UTC) Iain Buclaw wrote: > There should be little reason why the compiler won't build/work sweet > as roses - as no one's tested though, there may be some gaps in the C > bindings that trigger static asserts, throw undefined identifier > errors, or evoke some wacky occurrences in runtime. The guy on #D.gdc told me he was able to build dmd on 64bit FreeBSD, but the 'application' crashes due to GC. (He, according to his own words, wanted to use D, but went back to C.) Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 23:54:30 +0200 Ulrik Mikaelsson wrote: > My view, is the D community right now are thinking long and hard about > their own needs, and less of the needs of their users. (For a > language, the application programmer IS the user.) Maybe even rightly > so, getting things language-wise right from the start IS important! > However, if it is desirable to attract developers that want to use D > for productivity right now, there are a lot of practical issues that > needs addressing, rough edges to smoothen, and hardly any of them lie > in the language itself. I agree. Shortly after I joined this place, Walter sent a post listing different ways how community can help D. Here it is: * Write articles about D and post them online in various forums * Go through bugzilla and submit patches for bugs * Provide D interfaces (.di files) to popular C libraries * Integrate D support for your favorite editor * Write convoluted code to try and break the compiler * Contribute to the GDC and LDC projects *Write library modules for an area that you know well Interestingly enough, it's not listed 'write general-purpose application in D...so that others can see D is useful for writing practical applications' and that just the way I thought I could contribute :-) Anyway, enough talk. I wish all success to D2 so that we might consider it as viable alternative for our project(s) in not so distant future. Bye... ;) Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: too early for D2 and too late for D1
"David Nadlinger" wrote in message news:ioftkj$2811$1...@digitalmars.com... > On 4/18/11 12:34 AM, Daniel Gibson wrote: > https://bitbucket.org/qtd/repo/wiki/Home and > > https://bitbucket.org/qtd/repo/wiki/DmdPatch I clicked around that for a while, but can't seem to find the patch file dmd.dmd-version.patch >>> http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=raw >> >> This should probably be mentioned at the bitbucket wiki. > > Ah, sorry, this was a side effect of QtD currently being in limbo between > Bitbucket (DVCS hosting) and DSource (wiki, issue tracker). I just > replaced the Bitbucket Wiki frontpage with a link to DSource until someone > finds time to properly migrate all the contents - the patch was not the > only dead link. > > As for the patch itself, it is more or less just a quick hack to be able > to access e.g. the module a declaration is in, which is needed for some > parts of the enum handling code - Max Samukha knows the details. > I've had need for a feature like that, too. Luckily in my case, I only needed to get the name of the current module (within some mixed-in code), so I was able to hack my way through with a dummy var and some mangle/demangle gymnastics. I definitely agree that a more general "get module of symbol" is needed.
Re: too early for D2 and too late for D1
On Apr 18, 11 07:34, David Nadlinger wrote: On 4/18/11 12:34 AM, Daniel Gibson wrote: https://bitbucket.org/qtd/repo/wiki/Home and https://bitbucket.org/qtd/repo/wiki/DmdPatch I clicked around that for a while, but can't seem to find the patch file dmd.dmd-version.patch http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=raw This should probably be mentioned at the bitbucket wiki. Ah, sorry, this was a side effect of QtD currently being in limbo between Bitbucket (DVCS hosting) and DSource (wiki, issue tracker). I just replaced the Bitbucket Wiki frontpage with a link to DSource until someone finds time to properly migrate all the contents – the patch was not the only dead link… As for the patch itself, it is more or less just a quick hack to be able to access e.g. the module a declaration is in, which is needed for some parts of the enum handling code – Max Samukha knows the details. It should also be noted that you don't necessarily need to patch DMD if your application builds fine without the patch. David The patch is now integrated into dmd :) https://github.com/D-Programming-Language/dmd/commit/2e261cd640e5266c569ad224ffbfe229a0315d97
Re: too early for D2 and too late for D1
On 4/18/11 4:00 AM, Adam D. Ruppe wrote: jasonw wrote: If you want to build some fortune 500 website from scratch, D doesn't deliver the functionality you need right now. My clients and I would disagree :-) I've been using D, almost exclusively, to write business websites for quite a while now. There's a lot of big advantages there over more traditional web languages. I'm hoping to write up an article detailing some of it in the near future. Please do so! :-) I'm very curious about this.
Re: too early for D2 and too late for D1
On 2011-04-17 22:27, Daniel Gibson wrote: Am 17.04.2011 21:52, schrieb jasonw: Gour-Gadadhara Dasa Wrote: Well, http://d-programming-language.org/ page says: "D is a multi- paradigm programming language that combines a principled approach with a focus on *practicality*." and in my case I've *practical* need to write GUI app. That's certainly true, if you think of the potential D2 provides. In 5 -- 20 years D will be a serious contestant and mature implementations beat C++ and traditional languages in many domains. Currently DMD produces much slower executables especially for high performance computing so you would be a total idiot to use D if the project time frame is less than 2 years. *Much* slower? Really? What benchmarks are you citing? If you want to build some fortune 500 website from scratch, D doesn't deliver the functionality you need right now. The PHP/Java/C# platforms have hundreds of millions worth funding backing them. If you build a desktop application, D isn't the best choice, but you can still argue to your boss to use it instead because of your personal "productivity" issues. There's no other logical reason to use D instead of C++/Qt or some other mature GUI toolkit. Bloated executables aren't suitable for embedded platforms either, but in 10 -- 20 years we will have a D compiler that targets platforms with less than 4 MB of RAM+ROM. I find it unlike that we have a reliable D compiler for very small 32-bit embedded devices in 5 years. Do you really think in "10 -- 20 years" somebody will care of your code runs in an embedded platform with only 4MB of RAM+ROM? Memory etc is so cheap that these platforms will get more powerful. Why should it take so long to have such a compiler? On the one hand: Why are D executables so "bloated"? 1. Phobos and druntime is statically compiled in. On a really limited embedded platform you wouldn't use Phobos anyway, but write your own standardlib and runtime that suit your needs (it's not like anybody would use full C++ with STL on such a platform. Well, probably not even C++ at all or only a very limited subset). This is quite a big advantage C and C++ have. The runtime will almost always be available on the platform and you can link to it dynamically. You can use Tango as a dynamic library on Mac OS X and a Hello World application will be the same size as a Hello World application written in C. -- /Jacob Carlborg
Re: too early for D2 and too late for D1
jasonw writes: > Don't get me wrong, D is already much faster than many "toy" > languages. Faster than Java and C# in some applications. What's > relevant is that the C/C++/Fortran users will only switch if D > provides concrete performance improvements over their *existing* > toolchains. It has taken LLVM several years and they're not yet even > on par with GCC in all benchmarks. I would challenge this statement somewhat. I do high-performance programming in C++. I don't expect D compilers to generate faster code than C++, but to rather that they will achieve parity. What I do expect is that D will make it significantly easier to write and maintain this fast code. That is worth quite a bit. Developer time is important even when writing high-performance code.
Re: too early for D2 and too late for D1
On 5/3/2011 7:58 PM, Jerry wrote: I would challenge this statement somewhat. I do high-performance programming in C++. I don't expect D compilers to generate faster code than C++, but to rather that they will achieve parity. What I do expect is that D will make it significantly easier to write and maintain this fast code. That is worth quite a bit. Developer time is important even when writing high-performance code. My experience in tuning D code for speed is that if you write "C++" code in D, you will get the same performance as C++. However, D makes it a *lot* easier to reorganize/refactor code to try and make it run faster, and this makes for better algorithms and hence faster code. For example, should I pass an object around by ref or by value? In C++, I've got to convert all my -> to . or vice versa, throughout the code. With D, I just change the alias declaration.
Re: too early for D2 and too late for D1
On 5/3/2011 10:58 PM, Jerry wrote: What I do expect is that D will make it significantly easier to write and maintain this fast code. That is worth quite a bit. Developer time is important even when writing high-performance code. +1000. IMHO one of D's biggest accomplishments is how far it pushes the ability to write fast code and write code fast in the same language. In fact, that's the single biggest reason I use it. Even if current implementations aren't quite as fast as C++, they're a lot faster than probably anything else with similar productivity. Equivalently, D is probably a lot more productive than anything with similar performance. BTW, yes, I know Java and C# can be pretty fast sometimes. The problem is that they both have abstractions you can't get beneath in your most performance-critical code. If you're writing code from scratch (as opposed to something that would benefit from tons of libraries that D doesn't have yet), I also think they're not as productive because they don't make metaprogramming easy.
Re: too early for D2 and too late for D1
Walter Bright wrote: > My experience in tuning D code for speed is that if you write "C++" > code in D, you will get the same performance as C++. However, D > makes it a *lot* easier to reorganize/refactor code to try and make > it run faster, and this makes for better algorithms and hence > faster code. Anecdote: Friday, I was asked to justify my decision to use D to a company exec. He pointed me to some benchmarks that had ruby vs python vs php vs C++ and asked how D would stack up. (The benchmark was sorting an array of integers, nothing really fancy.) Of them, Python had the shortest code, but C++ was the fastest, by far. Not really surprising. I first ported C++ to D. Equal lines of code, equal performance. The optimized builds did show D lagging ~20% behind g++ though. But, 20% behind g++ is still about 8x faster than the interpreted languages, so not bad. But, then I made a few minor tweaks. Slicing instead of copying. Array operations and foreach instead of iterator loops, stuff like that. The D code was now the shortest of all - even beating Python by a couple lines - while being just as readable and editable as the "productivity languages". And, to my surprise, the standard compile actually *beat* the optimized C++ build, running twice as fast! I was expecting it to be about equal, but instead, it just spanked it. Shorter code, easier to read code *AND* faster code, it beat all the competition in all the categories. Very pleasing result for everyone involved. Now, I dislike benchmarks as a general rule. Real world code is a lot more complex than these trivial things realize. But hell, when they work /for/ me, I won't complain. (Also, while a weaker comparison, I find this same trend continues to apps as a whole too. My D web app is about 1/8 the size in code of the smallest open source PHP program I found with similar features. 40% faster too. But Perpetually Hideous Programs are, well, perpetually hideous. Beating PHP is no great feat.)
Re: too early for D2 and too late for D1
This is an awesome case history of exactly what we are trying to achieve with D. Any chance you could make an article out of this? Brief is ok. Essentially showing the different language versions, then what you did to the D one that kicked ass. On 5/3/2011 8:42 PM, Adam D. Ruppe wrote: Walter Bright wrote: My experience in tuning D code for speed is that if you write "C++" code in D, you will get the same performance as C++. However, D makes it a *lot* easier to reorganize/refactor code to try and make it run faster, and this makes for better algorithms and hence faster code. Anecdote: Friday, I was asked to justify my decision to use D to a company exec. He pointed me to some benchmarks that had ruby vs python vs php vs C++ and asked how D would stack up. (The benchmark was sorting an array of integers, nothing really fancy.) Of them, Python had the shortest code, but C++ was the fastest, by far. Not really surprising. I first ported C++ to D. Equal lines of code, equal performance. The optimized builds did show D lagging ~20% behind g++ though. But, 20% behind g++ is still about 8x faster than the interpreted languages, so not bad. But, then I made a few minor tweaks. Slicing instead of copying. Array operations and foreach instead of iterator loops, stuff like that. The D code was now the shortest of all - even beating Python by a couple lines - while being just as readable and editable as the "productivity languages". And, to my surprise, the standard compile actually *beat* the optimized C++ build, running twice as fast! I was expecting it to be about equal, but instead, it just spanked it. Shorter code, easier to read code *AND* faster code, it beat all the competition in all the categories. Very pleasing result for everyone involved. Now, I dislike benchmarks as a general rule. Real world code is a lot more complex than these trivial things realize. But hell, when they work /for/ me, I won't complain. (Also, while a weaker comparison, I find this same trend continues to apps as a whole too. My D web app is about 1/8 the size in code of the smallest open source PHP program I found with similar features. 40% faster too. But Perpetually Hideous Programs are, well, perpetually hideous. Beating PHP is no great feat.)
Re: too early for D2 and too late for D1
On Tue, 2011-05-03 at 23:14 -0400, dsimcha wrote: [ . . . ] > BTW, yes, I know Java and C# can be pretty fast sometimes. The problem > is that they both have abstractions you can't get beneath in your most > performance-critical code. If you're writing code from scratch (as > opposed to something that would benefit from tons of libraries that D > doesn't have yet), I also think they're not as productive because they > don't make metaprogramming easy. I don't know about C#/CLR (no experience of knowledge) but for Groovy/Scala/Java/Clojure on the JVM, and indeed Python on the PVM, if there is a small piece of code that is truly performance critical and you can't get the JVM/JIT to make it fast enough and native code can then you call out to C or C++ -- real performance data not speculation is required here though. Of course this is far, far easier with Python. Much of the "need flexibility"/"developer time is more important than run time because I am just using APIs that are already optimized" HPC-ish stuff is now happening in Python with C/C++/Fortran libraries, cf. NumPy, SciPy. Why is D not an up-front contender here more widely than it is? Ease of creating GUIs and rendering data mostly I would suggest. It's so much about data visualization rather than computation these days. Python has easy connection to Qt, GTK, wxWidgets, etc. QtDesigner, Glade, and wxGlade make laying out the UI easy, generating XML specification. Then the dynamic aspects of Python make it trivial to read in XML and instantiate all the widgets and connect up the events. C, C++, Go, and D are not even in the race except for systems such as games where the timings are so critical, assembly language is a real contender. I wonder if D could get more traction by adding dataflow to the evolving actor and data parallelism stuff. With Groovy/GPars (dynamic languages make metaprogramming really trivial btw) we are seeing a take up of dataflow as well as actor model and data parallelism. There are even commercial Java dataflow frameworks that are storming the analytics using JVM world. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: too early for D2 and too late for D1
On 5/4/2011 3:13 AM, Russel Winder wrote: On Tue, 2011-05-03 at 23:14 -0400, dsimcha wrote: [ . . . ] BTW, yes, I know Java and C# can be pretty fast sometimes. The problem is that they both have abstractions you can't get beneath in your most performance-critical code. If you're writing code from scratch (as opposed to something that would benefit from tons of libraries that D doesn't have yet), I also think they're not as productive because they don't make metaprogramming easy. I don't know about C#/CLR (no experience of knowledge) but for Groovy/Scala/Java/Clojure on the JVM, and indeed Python on the PVM, if there is a small piece of code that is truly performance critical and you can't get the JVM/JIT to make it fast enough and native code can then you call out to C or C++ -- real performance data not speculation is required here though. Of course this is far, far easier with Python. Much of the "need flexibility"/"developer time is more important than run time because I am just using APIs that are already optimized" HPC-ish stuff is now happening in Python with C/C++/Fortran libraries, cf. NumPy, SciPy. True but somewhat irrelevant. The problem with this is that you're still writing the critical bits in C/C++, and furthermore a dialect of C/C++ that requires a well-defined ABI. In my experience, when mixing languages there's always friction along the borders. Furthermore, when you do something like this you have to specify types explicitly. D and C++ are the only languages I'm aware of that let you write efficient generic code. After using D, C++ seems half-assed in this area. D is the only language I'm aware of that lets you do it **well**.
Re: too early for D2 and too late for D1
On 4/05/11 4:08 AM, Walter Bright wrote:
For example, should I pass an object around by ref or by value? In C++,
I've got to convert all my -> to . or vice versa, throughout the code.
With D, I just change the alias declaration.
How do you manage to change a pass-by-value to pass-by-reference by
changing an alias?
e.g.
struct Vec3(T) { ... }
T dot(Vec3!T a, Vec3!T b)
{
return a.x * b.x + a.y * b.y + a.z * b.z;
}
/* lots more functions that pass Vec3 by value */
How would you change Vec3!T to be passed by reference by changing an
alias param?
P.S.
In C++, you'd change
T dot(Vec3 a, Vec b)
to
T dot(Vec3 const& a, Vec3 const& b)
No need to change . to ->
Re: too early for D2 and too late for D1
Not sure about the sometimes, but nowadays they can be very fast. Regarding .Net/CLR, the bytecode only exists as portable assembly. When a an assembly (.dll/.exe )file is loaded the complete code is JITed before execution starts. Another possibility is to use ahead of time compilation and thanks to ngen, already deploy the assembly in native code. If you think that the JIT is not doing a good work compiling your code, you can step down to C++/CLI which is able to blend native code and managed. On the Java world, usually the methods are only compiled after a certain threshold has been reached, most JVMs allow to customize this threshold via a non standard parameter. if you set it to zero, you get the same behavior as in .Net. If you are also not happy with the JITed code, you can turn to a real compiler like the Excelsior JET. http://www.excelsior-usa.com/jet.html -- Paulo "Russel Winder" wrote in message news:mailman.24.1304493198.14074.digitalmar...@puremagic.com... On Tue, 2011-05-03 at 23:14 -0400, dsimcha wrote: [ . . . ] > BTW, yes, I know Java and C# can be pretty fast sometimes. The problem > is that they both have abstractions you can't get beneath in your most > performance-critical code. If you're writing code from scratch (as > opposed to something that would benefit from tons of libraries that D > doesn't have yet), I also think they're not as productive because they > don't make metaprogramming easy. I don't know about C#/CLR (no experience of knowledge) but for Groovy/Scala/Java/Clojure on the JVM, and indeed Python on the PVM, if there is a small piece of code that is truly performance critical and you can't get the JVM/JIT to make it fast enough and native code can then you call out to C or C++ -- real performance data not speculation is required here though. Of course this is far, far easier with Python. Much of the "need flexibility"/"developer time is more important than run time because I am just using APIs that are already optimized" HPC-ish stuff is now happening in Python with C/C++/Fortran libraries, cf. NumPy, SciPy. Why is D not an up-front contender here more widely than it is? Ease of creating GUIs and rendering data mostly I would suggest. It's so much about data visualization rather than computation these days. Python has easy connection to Qt, GTK, wxWidgets, etc. QtDesigner, Glade, and wxGlade make laying out the UI easy, generating XML specification. Then the dynamic aspects of Python make it trivial to read in XML and instantiate all the widgets and connect up the events. C, C++, Go, and D are not even in the race except for systems such as games where the timings are so critical, assembly language is a real contender. I wonder if D could get more traction by adding dataflow to the evolving actor and data parallelism stuff. With Groovy/GPars (dynamic languages make metaprogramming really trivial btw) we are seeing a take up of dataflow as well as actor model and data parallelism. There are even commercial Java dataflow frameworks that are storming the analytics using JVM world. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: too early for D2 and too late for D1
On 5/4/2011 12:55 PM, Peter Alexander wrote: On 4/05/11 4:08 AM, Walter Bright wrote: For example, should I pass an object around by ref or by value? In C++, I've got to convert all my -> to . or vice versa, throughout the code. With D, I just change the alias declaration. How do you manage to change a pass-by-value to pass-by-reference by changing an alias? alias Vec3!T* V; T dot(V a, V b); Now I can change V to whatever I want, pointer or value, without having to edit anything but the alias.
