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:
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 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
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 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
parent reply Gour-Gadadhara Dasa <gour atmarama.net> writes:
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
next sibling parent reply 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
parent reply Gour-Gadadhara Dasa <gour atmarama.net> writes:
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
parent reply 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
parent Gour-Gadadhara Dasa <gour atmarama.net> writes:
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 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

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.



better langauge anyway (IMO) that I find D's immaturity to be a huge 


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


 20 years D will be a serious contestant and mature implementations beat C+=
+ 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 =


still argue to your boss to use it instead because of your personal "produc=
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=


 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 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



  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

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

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



  parent reply Jerry <jlquinn optonline.net>  writes:


jasonw <user webmails.org> writes:

 Don't get me wrong, D is already much faster than many "toy"

 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



 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.


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 reply Russel Winder <russel russel.org.uk>  writes:


On Tue, 2011-05-03 at 23:14 -0400, dsimcha wrote:
[ . . . ]




=20

 is that they both have abstractions you can't get beneath in your most=


=20

 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=


=20

 don't make metaprogramming easy.



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



 next sibling 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:
 [ . . . ]


 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.



 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  "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:
[ . . . ]


 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.



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



prev sibling next sibling parent  Gour-Gadadhara Dasa <gour atmarama.net>  writes:


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  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

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

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 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  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  Gour-Gadadhara Dasa <gour atmarama.net>  writes:


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  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  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



  parent reply Gour-Gadadhara Dasa <gour atmarama.net>  writes:


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



 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 Gour-Gadadhara Dasa <gour atmarama.net>  writes:


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



  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



  parent reply 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


http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=raw



 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


 http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=raw


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


 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



 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


 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.



 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


 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



 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 next sibling parent reply 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.


 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.



 Apr 17 2011



  parent  Gour-Gadadhara Dasa <gour atmarama.net>  writes:


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 reply 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.


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.



 Apr 17 2011



  parent  Gour-Gadadhara Dasa <gour atmarama.net>  writes:


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  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