www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - too early for D2 and too late for D1

reply Gour-Gadadhara Dasa <gour atmarama.net> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


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

--=20
=E2=80=9CIn the material world, conceptions of good and bad are
all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
next sibling parent reply Gary Whatmore <no spam.sp> writes:
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.
Apr 17 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
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"?
Apr 17 2011
prev sibling next sibling parent reply Gary Whatmore <no spam.sp> writes:
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.
Apr 17 2011
next sibling parent reply jasonw <user webmails.org> writes:
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.
Apr 17 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Apr 17 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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!
Apr 17 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 17 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> 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.
Apr 17 2011
prev sibling parent Ary Manzana <ary esperanto.org.ar> writes:
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.
Apr 17 2011
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
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
Apr 17 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 17 2011
parent reply jasonw <user webmails.org> writes:
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.
Apr 17 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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?
Apr 17 2011
parent reply jasonw <user webmails.org> writes:
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.
Apr 17 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 17 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Apr 18 2011
prev sibling parent reply jasonw <user webmails.org> writes:
Caligo Wrote:

 On Sun, Apr 17, 2011 at 2:52 PM, jasonw <user webmails.org> 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?
Apr 17 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
May 03 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.)
May 03 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
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.)

May 03 2011
prev sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
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<T> a, Vec<T> b) to T dot(Vec3<T> const& a, Vec3<T> const& b) No need to change . to ->
May 04 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
May 04 2011
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
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.
May 03 2011
parent dsimcha <dsimcha yahoo.com> writes:
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**.
May 04 2011
prev sibling parent dsimcha <dsimcha yahoo.com> writes:
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.
Apr 17 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 17 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Apr 17 2011
prev sibling next sibling parent Caligo <iteronvexor gmail.com> writes:
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.
Apr 17 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Apr 17 2011
prev sibling next sibling parent Gour-Gadadhara Dasa <gour atmarama.net> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 17 Apr 2011 20:26:49 +0200
Andrej Mitrovic <andrej.mitrovich gmail.com> 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.=20

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?=20

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 --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
prev sibling next sibling parent Gour-Gadadhara Dasa <gour atmarama.net> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 17 Apr 2011 13:51:49 -0500
Caligo <iteronvexor gmail.com> 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=20 --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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..
Apr 17 2011
prev sibling next sibling parent Gour-Gadadhara Dasa <gour atmarama.net> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 17 Apr 2011 21:45:59 +0200
Andrej Mitrovic <andrej.mitrovich gmail.com> 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 --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
prev sibling next sibling parent Caligo <iteronvexor gmail.com> writes:
On Sun, Apr 17, 2011 at 2:52 PM, jasonw <user webmails.org> 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 --=

+ and traditional languages in many domains. Currently DMD produces much sl= ower 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 del=

undreds of millions worth funding backing them.
 If you build a desktop application, D isn't the best choice, but you can =

tivity" 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=

than 4 MB of RAM+ROM. I find it unlike that we have a reliable D compiler f= or 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.
Apr 17 2011
prev sibling next sibling parent reply Andrew Wiley <debio264 gmail.com> writes:
On Sun, Apr 17, 2011 at 4:37 AM, Gour-Gadadhara Dasa <gour atmarama.net> 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)
Apr 17 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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!
Apr 17 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2011 1:55 PM, Gour-Gadadhara Dasa wrote:
 On Sun, 17 Apr 2011 13:45:06 -0700
 Walter Bright<newshound2 digitalmars.com>  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
Apr 17 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 18.04.2011 00:27, schrieb Andrej Mitrovic:
 On 4/18/11, Walter Bright <newshound2 digitalmars.com> wrote:
 On 4/17/2011 1:55 PM, Gour-Gadadhara Dasa wrote:
 On Sun, 17 Apr 2011 13:45:06 -0700
 Walter Bright<newshound2 digitalmars.com>  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


This should probably be mentioned at the bitbucket wiki.
Apr 17 2011
parent reply David Nadlinger <see klickverbot.at> writes:
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


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
Apr 17 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"David Nadlinger" <see klickverbot.at> 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


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.
Apr 17 2011
prev sibling parent KennyTM~ <kennytm gmail.com> writes:
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


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
Apr 17 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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!
Apr 17 2011
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Gour-Gadadhara Dasa (gour 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 <debio264 gmail.com> 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.

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.
Apr 17 2011
prev sibling next sibling parent Gour-Gadadhara Dasa <gour atmarama.net> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 17 Apr 2011 15:52:36 -0400
jasonw <user webmails.org> 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 --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
prev sibling next sibling parent Gour-Gadadhara Dasa <gour atmarama.net> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 17 Apr 2011 15:11:43 -0500
Andrew Wiley <debio264 gmail.com> 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 --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/17/11, Gour-Gadadhara Dasa <gour atmarama.net> 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. :)
Apr 17 2011
prev sibling next sibling parent Gour-Gadadhara Dasa <gour atmarama.net> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 17 Apr 2011 13:45:06 -0700
Walter Bright <newshound2 digitalmars.com> wrote:

 I'd also like to know which bugzilla entry has that patch!

See:=20 https://bitbucket.org/qtd/repo/wiki/Home and https://bitbucket.org/qtd/repo/wiki/DmdPatch Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
prev sibling next sibling parent Gour-Gadadhara Dasa <gour atmarama.net> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 17 Apr 2011 22:44:20 +0200
Andrej Mitrovic <andrej.mitrovich gmail.com> 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 --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
prev sibling next sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/4/17 Gour-Gadadhara Dasa <gour atmarama.net>
 On Sun, 17 Apr 2011 15:11:43 -0500
 Andrew Wiley <debio264 gmail.com> 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.

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.
Apr 17 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
 2011/4/17 Gour-Gadadhara Dasa <gour atmarama.net>
 
 On Sun, 17 Apr 2011 15:11:43 -0500
 
 Andrew Wiley <debio264 gmail.com> 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
Apr 17 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/18/11, Walter Bright <newshound2 digitalmars.com> wrote:
 On 4/17/2011 1:55 PM, Gour-Gadadhara Dasa wrote:
 On Sun, 17 Apr 2011 13:45:06 -0700
 Walter Bright<newshound2 digitalmars.com>  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

Apr 17 2011
prev sibling next sibling parent Gour-Gadadhara Dasa <gour atmarama.net> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 17 Apr 2011 21:49:34 +0000 (UTC)
Iain Buclaw <ibuclaw ubuntu.com> 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.)=20 Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
prev sibling next sibling parent Gour-Gadadhara Dasa <gour atmarama.net> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 17 Apr 2011 23:54:30 +0200
Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> 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.=20 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 --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
prev sibling next sibling parent Jerry <jlquinn optonline.net> writes:
jasonw <user webmails.org> 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.
May 03 2011
prev sibling parent reply Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=20
 opposed to something that would benefit from tons of libraries that D=20
 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. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
May 04 2011
parent "Paulo Pinto" <pjmlp progtools.org> writes:
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" <russel russel.org.uk> wrote in message 
news:mailman.24.1304493198.14074.digitalmars-d 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.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
May 04 2011