www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Linux Agora D thread

reply Gour <gour atmarama.net> writes:
Hello!

Few days ago I sent a short post to Linux Agora site explaining why
I'm not participating any longer in 'learning Haskell' reading group
and suggesting D as possible target of one of the future groups.

However, it looks that some are not excited about it:

http://www.linuxagora.com/vbforum/showpost.php?p=3D6313

I've tried to reply as best as I know, but...

He posted to his Hacker News as well:

http://news.ycombinator.com/item?id=3D1783810

If anyone has something to add, pls. feel free to do it...


Sincerely,
Gour

--=20

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA
----------------------------------------------------------------
Oct 21 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday 21 October 2010 23:18:15 Gour wrote:

 Hello!
 
 Few days ago I sent a short post to Linux Agora site explaining why
 I'm not participating any longer in 'learning Haskell' reading group
 and suggesting D as possible target of one of the future groups.
 
 However, it looks that some are not excited about it:
 
 http://www.linuxagora.com/vbforum/showpost.php?p=6313
 
 I've tried to reply as best as I know, but...
 
 He posted to his Hacker News as well:
 
 http://news.ycombinator.com/item?id=1783810
 
 If anyone has something to add, pls. feel free to do it...
 
 
 Sincerely,
 Gour


For the most part, he seems to be spot on - certainly he's more knowledgeable 
than many D detractors out there. The main thing that I'd disagree with would
be 
D's future, since he obviously thinks that it's never going to go anywhere, but 
only time will tell on that one.  My guess is that he was an active D user who 
got sick of things not stabilizing, which is quite understandable. While things 
have improved considerably, there are quite a few bugs in the compiler, and it 
doesn't yet completely implement the D spec per TDPL. However, the situation
has 
much improved with the language as a whole no longer having massive changes on
a 
semi-regular basis, so there's definitely a light at the end of the tunnel.

Still, at this point, you have people comparing D to languages which are 
essentially complete with compilers lacking much in the way of serious bugs,
and 
D just doesn't measure up to that yet, even if it has great promise, and it 
works well enough to do a lot with it. Many such people just aren't going to 
want anything to do with D until it's stable in the way that C++ or Java is 
stable - both the compiler and the standard library.

In any case, that poster seems knowledgeable enough that I don't see much point 
in arguing with him. His opinion obviously differs from that of most of us on 
this list, but it's generally based quite soundly on facts, so only time will 
prove him wrong.

- Jonathan M Davis
Oct 21 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jonathan M Davis wrote:

 In any case, that poster seems knowledgeable enough that I don't see much
point 
 in arguing with him. His opinion obviously differs from that of most of us on 
 this list, but it's generally based quite soundly on facts, so only time will 
 prove him wrong.


Sure, but it all depends on how one interprets those facts.

For example, C++ is hardly the same language it was in 1988 or so, when it 
became widely used. I don't think any pre-2000 C++ compiler would be remotely 
considered usable today. Languages that are not dead go through substantial 
revisions and upgrades. It is not a defect in D that it does so, too.

As anyone can see in the changelog, we've stopped adding features to D2 and are 
working on toolchain issues. There's been a lot of progress there.
Oct 22 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 22 October 2010 00:09:31 Walter Bright wrote:

 Jonathan M Davis wrote:

 In any case, that poster seems knowledgeable enough that I don't see much
 point in arguing with him. His opinion obviously differs from that of
 most of us on this list, but it's generally based quite soundly on
 facts, so only time will prove him wrong.


 
 Sure, but it all depends on how one interprets those facts.
 
 For example, C++ is hardly the same language it was in 1988 or so, when it
 became widely used. I don't think any pre-2000 C++ compiler would be
 remotely considered usable today. Languages that are not dead go through
 substantial revisions and upgrades. It is not a defect in D that it does
 so, too.
 
 As anyone can see in the changelog, we've stopped adding features to D2 and
 are working on toolchain issues. There's been a lot of progress there.


Oh, I agree that he's wrong, and I agree that D2 is making serious progress,
but 
he's got enough of his facts right that I don't think that he can be convinced 
by correcting what he's saying. I see value in correcting people if they 
misunderstand the situation, but trying to convince someone whose opinion
differs 
when they have their facts more or less straight is likely to just result in 
heated arguments.

The fact that D2 is not 100% stable is, of course, not something that we want, 
but I do agree that it's completely understandable why D is the way it is at
the 
moment and that it's not unreasonable for it to be that way. D is improving and 
it will eventually reach the same level of stability that modern C++ compilers 
enjoy. However, it's also pretty much a given that many people won't want to
use 
D until it has a level of stability comparable with the compilers that they use 
for more mature languages. But there's nothing that we can do about that except 
continue to improve D until it reachs that point. And the more stable it 
becomes, the easier it will become to get people to try it and stick with it.

- Jonathan M Davis
Oct 22 2010
next sibling parent reply retard <re tard.com.invalid> writes:
Fri, 22 Oct 2010 00:33:15 -0700, Jonathan M Davis wrote:


 On Friday 22 October 2010 00:09:31 Walter Bright wrote:

 Jonathan M Davis wrote:

 In any case, that poster seems knowledgeable enough that I don't see
 much point in arguing with him. His opinion obviously differs from
 that of most of us on this list, but it's generally based quite
 soundly on facts, so only time will prove him wrong.


 
 Sure, but it all depends on how one interprets those facts.
 
 For example, C++ is hardly the same language it was in 1988 or so, when
 it became widely used. I don't think any pre-2000 C++ compiler would be
 remotely considered usable today. Languages that are not dead go
 through substantial revisions and upgrades. It is not a defect in D
 that it does so, too.
 
 As anyone can see in the changelog, we've stopped adding features to D2
 and are working on toolchain issues. There's been a lot of progress
 there.


 
 Oh, I agree that he's wrong, and I agree that D2 is making serious
 progress, but he's got enough of his facts right that I don't think that
 he can be convinced by correcting what he's saying. I see value in
 correcting people if they misunderstand the situation, but trying to
 convince someone whose opinion differs when they have their facts more
 or less straight is likely to just result in heated arguments.
 
 The fact that D2 is not 100% stable is, of course, not something that we
 want, but I do agree that it's completely understandable why D is the
 way it is at the moment and that it's not unreasonable for it to be that
 way. D is improving and it will eventually reach the same level of
 stability that modern C++ compilers enjoy. However, it's also pretty
 much a given that many people won't want to use D until it has a level
 of stability comparable with the compilers that they use for more mature
 languages. But there's nothing that we can do about that except continue
 to improve D until it reachs that point. And the more stable it becomes,
 the easier it will become to get people to try it and stick with it.


What annoys me the most in pro D articles is the author usually tries to 
prove (in a naive way) that despite all the deficiencies the language and 
tool chain is better even *now* than all of the competition or that the 
*potential* is so high that the only logical conclusion is to move to D 
*now*. Clearly this isn't the case. These kind of articles give people 
the wrong impression. I'm just trying to bring up the *pragmatic* point 
of view.

For instance, I'm starting the implementation of a 64-bit systems/
application programming project *now*. The implementation phase will last 
N months (assume optimistic waterfall process model here). How many weeks/
months must the N at least be to make D a feasible option?

A typical lead developer / project manager has to make decisions based on 
some assumptions. E.g.

Platform      Implementation  Developer  Performance  Platform
              Time            Market     Index        Risk factor
--------------------------------------------------------------
C/x64 Linux   12 months       good       100          medium
C++/x64 Linux 10 months       ok         110          high
Java/x64 JVM  8 months        excellent  80           low

Python/Linux  4-5 months      very good  30           low
D             12+ months?     very bad   80-115 ?     very high

The metrics are imaginary. The point was to show that language goodness 
isn't a single scalar value.

Why I think the D platform's risk is so high is because the author 
constantly refuses to give ANY estimates on feature schedules. There's no 
up-to-date roadmap anywhere. The bugzilla voting system doesn't work. 
Lots of production ready core functionality is missing (for example how 
long has d2 distribution had a commercial quality xml framework?)

For example gcc has had 64-bit C/C++ support quite long. But it took 
several years to stabilize. The implementation of a 64-bit X-ray machine 
firmware in D cannot begin one week after 64-bit DMD is announced.
Oct 22 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:

 What annoys me the most in pro D articles is the author usually tries to 
 prove (in a naive way) that despite all the deficiencies the language and 
 tool chain is better even *now* than all of the competition or that the 
 *potential* is so high that the only logical conclusion is to move to D 
 *now*. Clearly this isn't the case. These kind of articles give people 
 the wrong impression. I'm just trying to bring up the *pragmatic* point 
 of view.
 
 For instance, I'm starting the implementation of a 64-bit systems/
 application programming project *now*. The implementation phase will last 
 N months (assume optimistic waterfall process model here). How many weeks/
 months must the N at least be to make D a feasible option?


The Linux 64 bit dmd is well on its way to completion. The library compiles,
and 
simple programs work. I'm working my way through the test suite (which is
fairly 
extensive).


 A typical lead developer / project manager has to make decisions based on 
 some assumptions. E.g.
 
 Platform      Implementation  Developer  Performance  Platform
               Time            Market     Index        Risk factor
 --------------------------------------------------------------
 C/x64 Linux   12 months       good       100          medium
 C++/x64 Linux 10 months       ok         110          high
 Java/x64 JVM  8 months        excellent  80           low

 Python/Linux  4-5 months      very good  30           low
 D             12+ months?     very bad   80-115 ?     very high
 
 The metrics are imaginary. The point was to show that language goodness 
 isn't a single scalar value.
 
 Why I think the D platform's risk is so high is because the author 
 constantly refuses to give ANY estimates on feature schedules.


Would you believe them if I did?



 There's no 
 up-to-date roadmap anywhere. The bugzilla voting system doesn't work. 
 Lots of production ready core functionality is missing (for example how 
 long has d2 distribution had a commercial quality xml framework?)


That depends on if your project needs an xml framework or not. Worst case,
which 
is far from bad, you can always connect to any C library. Googling "c xml 
library" turned up several on the front page.



 For example gcc has had 64-bit C/C++ support quite long. But it took 
 several years to stabilize. The implementation of a 64-bit X-ray machine 
 firmware in D cannot begin one week after 64-bit DMD is announced.


It's foolish to assume any compiler is reliable if you're going to be writing 
critical software. Assuming perfection in any part of such a system is a 
thorough misunderstanding of how to create reliable systems.

I believe it is also an error to require a tool be perfect before you can pick 
it up. All that is required is that its benefit/cost is higher than that of 
other tools. D has quite a few advantages that are available with it right now.
Oct 22 2010
parent reply retard <re tard.com.invalid> writes:
Fri, 22 Oct 2010 02:42:49 -0700, Walter Bright wrote:


 retard wrote:

 
 Why I think the D platform's risk is so high is because the author
 constantly refuses to give ANY estimates on feature schedules.


 
 Would you believe them if I did?


http://en.wikipedia.org/wiki/Software_development_process

"Without project management, software projects can easily be delivered 
late or over budget. With large numbers of software projects not meeting 
their expectations in terms of functionality, cost, or delivery schedule, 
effective project management appears to be lacking."

http://en.wikipedia.org/wiki/Estimation_in_software_engineering

"The ability to accurately estimate the time and/or cost taken for a 
project to come in to its successful conclusion is a serious problem for 
software engineers. The use of a repeatable, clearly defined and well 
understood software development process has, in recent years, shown 
itself to be the most effective method of gaining useful historical data 
that can be used for statistical estimation. In particular, the act of 
sampling more frequently, coupled with the loosening of constraints 
between parts of a project, has allowed more accurate estimation and more 
rapid development times."

http://en.wikipedia.org/wiki/Application_Lifecycle_Management

"Proponents of application lifecycle management claim that it
* Increases productivity, as the team shares best practices for 
development and deployment, and developers need focus only on current 
business requirements
* Improves quality, so the final application meets the needs and 
expectations of users
* Breaks boundaries through collaboration and smooth information flow
* Accelerates development through simplified integration
* Cuts maintenance time by synchronizing application and design
* Maximizes investments in skills, processes, and technologies
* Increases flexibility by reducing the time it takes to build and adapt 
applications that support new business initiatives"

http://en.wikipedia.org/wiki/Cowboy_coding

"Lack of estimation or implementation planning may cause a project to be 
delayed. Sudden deadlines or pushes to release software may encourage the 
use of quick and dirty or code and fix techniques that will require 
further attention later."

"Cowboy coding is common at the hobbyist or student level where 
developers may initially be unfamiliar with the technologies, such as the 
build tools, that the project requires."

"Custom software applications, even when using a proven development 
cycle, can experience problems with the client concerning requirements. 
Cowboy coding can accentuate this problem by not scaling the requirements 
to a reasonable timeline, and may result in unused or unusable components 
being created before the project is finished. Similarly, projects with 
less tangible clients (often experimental projects, see independent game 
development) may begin with code and never a formal analysis of the 
design requirements. Lack of design analysis may lead to incorrect or 
insufficient technology choices, possibly requiring the developer to port 
or rewrite their software in order for the project to be completed."

"Many software development models, such as Extreme Programming, use an 
incremental approach which stresses functional prototypes at each phase. 
Non-managed projects may have few unit tests or working iterations, 
leaving an incomplete project unusable."


 I believe it is also an error to require a tool be perfect before you
 can pick it up. All that is required is that its benefit/cost is higher
 than that of other tools.


That's what I said.


 D has quite a few advantages that are
 available with it right now.


But it doesn't matter. Like you said, the benefit/cost matters.
Oct 22 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 22/10/2010 11:17, retard wrote:

 Fri, 22 Oct 2010 02:42:49 -0700, Walter Bright wrote:


 retard wrote:

 Why I think the D platform's risk is so high is because the author
 constantly refuses to give ANY estimates on feature schedules.


 Would you believe them if I did?


 http://en.wikipedia.org/wiki/Software_development_process

 "Without project management, software projects can easily be delivered
 late or over budget. With large numbers of software projects not meeting
 their expectations in terms of functionality, cost, or delivery schedule,
 effective project management appears to be lacking."

 http://en.wikipedia.org/wiki/Estimation_in_software_engineering

 "The ability to accurately estimate the time and/or cost taken for a
 project to come in to its successful conclusion is a serious problem for
 software engineers. The use of a repeatable, clearly defined and well
 understood software development process has, in recent years, shown
 itself to be the most effective method of gaining useful historical data
 that can be used for statistical estimation. In particular, the act of
 sampling more frequently, coupled with the loosening of constraints
 between parts of a project, has allowed more accurate estimation and more
 rapid development times."

 http://en.wikipedia.org/wiki/Application_Lifecycle_Management

 "Proponents of application lifecycle management claim that it
 * Increases productivity, as the team shares best practices for
 development and deployment, and developers need focus only on current
 business requirements
 * Improves quality, so the final application meets the needs and
 expectations of users
 * Breaks boundaries through collaboration and smooth information flow
 * Accelerates development through simplified integration
 * Cuts maintenance time by synchronizing application and design
 * Maximizes investments in skills, processes, and technologies
 * Increases flexibility by reducing the time it takes to build and adapt
 applications that support new business initiatives"

 http://en.wikipedia.org/wiki/Cowboy_coding

 "Lack of estimation or implementation planning may cause a project to be
 delayed. Sudden deadlines or pushes to release software may encourage the
 use of quick and dirty or code and fix techniques that will require
 further attention later."

 "Cowboy coding is common at the hobbyist or student level where
 developers may initially be unfamiliar with the technologies, such as the
 build tools, that the project requires."

 "Custom software applications, even when using a proven development
 cycle, can experience problems with the client concerning requirements.
 Cowboy coding can accentuate this problem by not scaling the requirements
 to a reasonable timeline, and may result in unused or unusable components
 being created before the project is finished. Similarly, projects with
 less tangible clients (often experimental projects, see independent game
 development) may begin with code and never a formal analysis of the
 design requirements. Lack of design analysis may lead to incorrect or
 insufficient technology choices, possibly requiring the developer to port
 or rewrite their software in order for the project to be completed."

 "Many software development models, such as Extreme Programming, use an
 incremental approach which stresses functional prototypes at each phase.
 Non-managed projects may have few unit tests or working iterations,
 leaving an incomplete project unusable."


What's your point with all of this? That Walter should do estimates?


-- 
Bruno Medeiros - Software Engineer
Nov 19 2010
prev sibling next sibling parent Fawzi Mohamed <fawzi gmx.ch> writes:
On 22-ott-10, at 10:56, retard wrote:


 [...]
 What annoys me the most in pro D articles is the author usually  
 tries to
 prove (in a naive way) that despite all the deficiencies the  
 language and
 tool chain is better even *now* than all of the competition or that  
 the
 *potential* is so high that the only logical conclusion is to move  
 to D
 *now*. Clearly this isn't the case. These kind of articles give people
 the wrong impression. I'm just trying to bring up the *pragmatic*  
 point
 of view.

 For instance, I'm starting the implementation of a 64-bit systems/
 application programming project *now*. The implementation phase will  
 last
 N months (assume optimistic waterfall process model here). How many  
 weeks/
 months must the N at least be to make D a feasible option?


D1/tango is feasible now (using ldc)


 A typical lead developer / project manager has to make decisions  
 based on
 some assumptions. E.g.

 Platform      Implementation  Developer  Performance  Platform
             Time            Market     Index        Risk factor
 --------------------------------------------------------------
 C/x64 Linux   12 months       good       100          medium
 C++/x64 Linux 10 months       ok         110          high
 Java/x64 JVM  8 months        excellent  80           low

 Python/Linux  4-5 months      very good  30           low
 D             12+ months?     very bad   80-115 ?     very high

 The metrics are imaginary. The point was to show that language  
 goodness
 isn't a single scalar value.

 Why I think the D platform's risk is so high is because the author
 constantly refuses to give ANY estimates on feature schedules.  
 There's no
 up-to-date roadmap anywhere. The bugzilla voting system doesn't work.
 Lots of production ready core functionality is missing (for example  
 how
 long has d2 distribution had a commercial quality xml framework?)


D1/tango also has a good xml parser


 For example gcc has had 64-bit C/C++ support quite long. But it took
 several years to stabilize. The implementation of a 64-bit X-ray  
 machine
 firmware in D cannot begin one week after 64-bit DMD is announced.
Oct 22 2010
prev sibling next sibling parent Gary Whatmore <no spam.spam> writes:
retard Wrote:


 What annoys me the most in pro D articles is the author usually tries to 
 prove (in a naive way) that despite all the deficiencies the language and 
 tool chain bla blah blah


This guy has nothing better to do? Sheesh..


 For instance, I'm starting the implementation of a 64-bit systems/
 application programming project *now*. The implementation phase will last 
 N months (assume optimistic waterfall process model here). How many weeks/
 months must the N at least be to make D a feasible option?


D has everything you need and rest are available via C bindings. You can start
your product now. Use DMD for 32-bit code, LDC/GDC for 64-bit. Problem solved.
The N is zero. Even hello world is usually simpler in D.


 A typical lead developer / project manager has to make decisions based on 
 some assumptions. E.g.
 
 Platform      Implementation  Developer  Performance  Platform
               Time            Market     Index        Risk factor
 --------------------------------------------------------------
 C/x64 Linux   12 months       good       100          medium
 C++/x64 Linux 10 months       ok         110          high
 Java/x64 JVM  8 months        excellent  80           low

 Python/Linux  4-5 months      very good  30           low
 D             12+ months?     very bad   80-115 ?     very high


The numbers for D are

5-6 months (almost as good as python), very good (lots of unemployed students

got jealous). Risks are very low because everyone knows C and D is almost
compatible with C if you can't handle object oriented meta programming code.


 Why I think the D platform's risk is so high is because the author 
 constantly refuses to give ANY estimates on feature schedules. There's no 
 up-to-date roadmap anywhere. The bugzilla voting system doesn't work. 
 Lots of production ready core functionality is missing (for example how 
 long has d2 distribution had a commercial quality xml framework?)


64-bit DMD, world fastest stdlib (Phobos 2), other libraries, D3, world
domination --->


 For example gcc has had 64-bit C/C++ support quite long. But it took 
 several years to stabilize. The implementation of a 64-bit X-ray machine 
 firmware in D cannot begin one week after 64-bit DMD is announced.


We don't need X-ray machines. There is a lot of work replacing all C/C++ apps
with D code. You know, solitaire.exe, notepad.exe, things like that. Much
better when done in D.

 - G.W.
Oct 22 2010
prev sibling parent so <so so.do> writes:
On Fri, 22 Oct 2010 11:56:19 +0300, retard <re tard.com.invalid> wrote:


 What annoys me the most in pro D articles is the author usually tries to
 prove (in a naive way) that despite all the deficiencies the language and
 tool chain is better even *now* than all of the competition or that the
 *potential* is so high that the only logical conclusion is to move to D
 *now*. Clearly this isn't the case. These kind of articles give people
 the wrong impression. I'm just trying to bring up the *pragmatic* point
 of view.


Agree on this one except one thing, you have to except it has a really  
high "potential".


 For instance, I'm starting the implementation of a 64-bit systems/
 application programming project *now*. The implementation phase will last
 N months (assume optimistic waterfall process model here). How many  
 weeks/
 months must the N at least be to make D a feasible option?

 A typical lead developer / project manager has to make decisions based on
 some assumptions. E.g.

 Platform      Implementation  Developer  Performance  Platform
               Time            Market     Index        Risk factor
 --------------------------------------------------------------
 C/x64 Linux   12 months       good       100          medium
 C++/x64 Linux 10 months       ok         110          high
 Java/x64 JVM  8 months        excellent  80           low

 Python/Linux  4-5 months      very good  30           low
 D             12+ months?     very bad   80-115 ?     very high


You can't compare D to any of them, at least D2, they are final.
Do people take such risks? Or even question this kind of things? I believe  
not.
most likely it is like :
- "This is our target"
- "This is the best/only for this kind of thing" (educated or not)

In past maybe companies had to do such analysis, now they got tools that  
at least "work".
The next language transition has to be made by programmers themselves.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Oct 22 2010
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Jonathan M Davis wrote:

 Oh, I agree that he's wrong, and I agree that D2 is making serious progress,
but 
 he's got enough of his facts right that I don't think that he can be convinced 
 by correcting what he's saying. I see value in correcting people if they 
 misunderstand the situation, but trying to convince someone whose opinion
differs 
 when they have their facts more or less straight is likely to just result in 
 heated arguments.
 
 The fact that D2 is not 100% stable is, of course, not something that we want, 
 but I do agree that it's completely understandable why D is the way it is at
the 
 moment and that it's not unreasonable for it to be that way. D is improving
and 
 it will eventually reach the same level of stability that modern C++ compilers 
 enjoy. However, it's also pretty much a given that many people won't want to
use 
 D until it has a level of stability comparable with the compilers that they
use 
 for more mature languages. But there's nothing that we can do about that
except 
 continue to improve D until it reachs that point. And the more stable it 
 becomes, the easier it will become to get people to try it and stick with it.


I agree there are plenty of reasons to not use D, but also a lot more reasons
to 
use it.
Oct 22 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:


 As anyone can see in the changelog, we've stopped adding features to D2 and
are 
 working on toolchain issues. There's been a lot of progress there.


After that work on the toolchain issues, it will be good to go back to
implementation issues; I have a list of small design things that need to be
decided upon that can't wait too much time, because once a larger amount of D2
code is written, it will be not easy to fix them (or it will be a pain to fix
them). Most of them are minor things, but not minor enough to be ignored.

Bye,
bearophile
Oct 22 2010
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 22 Oct 2010 03:09:31 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 Jonathan M Davis wrote:

 In any case, that poster seems knowledgeable enough that I don't see  
 much point in arguing with him. His opinion obviously differs from that  
 of most of us on this list, but it's generally based quite soundly on  
 facts, so only time will prove him wrong.


 Sure, but it all depends on how one interprets those facts.

 For example, C++ is hardly the same language it was in 1988 or so, when  
 it became widely used. I don't think any pre-2000 C++ compiler would be  
 remotely considered usable today. Languages that are not dead go through  
 substantial revisions and upgrades. It is not a defect in D that it does  
 so, too.

 As anyone can see in the changelog, we've stopped adding features to D2  
 and are working on toolchain issues. There's been a lot of progress  
 there.


While I agree D2 will be a great platform to develop with, it's currently  
unusable for any major project IMO.


features, but D2 standard library is comprised of half-baked components  
and rapidly changing ones (and getting new instances of these monthly).

Before we can compare apples to apples, we need to stabilize phobos.  But  
I don't think we should rush this, let's make phobos the best it can be  
first, and then freeze it.

I'll say that I developed a medium sized project with Tango, and I think  
at this point, if I wanted to upgrade, I would have to spend significant  
time porting it to the latest version.  That was only about a year and a  
half ago.  Tango may have stabilized in recent times (haven't looked at it  
in a while), but phobos 2 is nowhere near as usable as Tango was a year  
and a half ago.  Lets focus on getting it there and stop worrying about  
how some guy doesn't like D.

-Steve
Oct 25 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:

 I'll say that I developed a medium sized project with Tango, and I think 
 at this point, if I wanted to upgrade, I would have to spend significant 
 time porting it to the latest version.  That was only about a year and a 
 half ago.  Tango may have stabilized in recent times (haven't looked at 
 it in a while), but phobos 2 is nowhere near as usable as Tango was a 
 year and a half ago.  Lets focus on getting it there and stop worrying 
 about how some guy doesn't like D.


Haters are always gonna hate, no matter how good D is. But we will continue to 
hammer down all the nails that are sticking up.
Oct 25 2010
prev sibling parent Gour <gour atmarama.net> writes:
On Thu, 21 Oct 2010 23:51:20 -0700

 "Jonathan" =3D=3D Jonathan M Davis wrote:












Jonathan> In any case, that poster seems knowledgeable enough that I
Jonathan> don't see much point in arguing with him. His opinion
Jonathan> obviously differs from that of most of us on this list, but
Jonathan> it's generally based quite soundly on facts, so only time
Jonathan> will prove him wrong.

Thanks.

As far as I'm concerned, I plan to tackle 2nd chapter of TDPL. ;)


Sincerely,
Gour

--=20

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA
----------------------------------------------------------------
Oct 22 2010
prev sibling next sibling parent reply so <so so.do> writes:
He starts with "and things they made worse than C++ (such as struct/class  
asymmetry, the first is stack-based, the second GCed heap)".
Having 2 different keywords for "exact" same purposes (1 difference and it  
doesn't worth mentioning) in a language is good and opposite is bad, with  
this kind of BS start i am not sure he got something to say.

On Fri, 22 Oct 2010 09:18:15 +0300, Gour <gour atmarama.net> wrote:


 Hello!

 Few days ago I sent a short post to Linux Agora site explaining why
 I'm not participating any longer in 'learning Haskell' reading group
 and suggesting D as possible target of one of the future groups.

 However, it looks that some are not excited about it:

 http://www.linuxagora.com/vbforum/showpost.php?p=6313

 I've tried to reply as best as I know, but...

 He posted to his Hacker News as well:

 http://news.ycombinator.com/item?id=1783810

 If anyone has something to add, pls. feel free to do it...


 Sincerely,
 Gour



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Oct 22 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
so wrote:

 He starts with "and things they made worse than C++ (such as 
 struct/class asymmetry, the first is stack-based, the second GCed heap)".
 Having 2 different keywords for "exact" same purposes (1 difference and 
 it doesn't worth mentioning) in a language is good and opposite is bad, 
 with this kind of BS start i am not sure he got something to say.


I think the struct/class distinction has worked out very well in D. It's one of 
the things we nailed. Often, people with a strong C++ background don't
initially 
see it that way, it takes a bit of explaining.
Oct 22 2010
parent "Paulo Pinto" <pjmlp progtools.org> writes:
.Net does the same thing with heap/value objects.

"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i9sipj$68s$1 digitalmars.com...

 so wrote:

 He starts with "and things they made worse than C++ (such as struct/class 
 asymmetry, the first is stack-based, the second GCed heap)".
 Having 2 different keywords for "exact" same purposes (1 difference and 
 it doesn't worth mentioning) in a language is good and opposite is bad, 
 with this kind of BS start i am not sure he got something to say.


 I think the struct/class distinction has worked out very well in D. It's 
 one of the things we nailed. Often, people with a strong C++ background 
 don't initially see it that way, it takes a bit of explaining.
Oct 22 2010
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Gour (gour atmarama.net)'s article

 Hello!
 Few days ago I sent a short post to Linux Agora site explaining why
 I'm not participating any longer in 'learning Haskell' reading group
 and suggesting D as possible target of one of the future groups.
 However, it looks that some are not excited about it:
 http://www.linuxagora.com/vbforum/showpost.php?p=3D6313
 I've tried to reply as best as I know, but...
 He posted to his Hacker News as well:
 http://news.ycombinator.com/item?id=3D1783810
 If anyone has something to add, pls. feel free to do it...
 Sincerely,
 Gour


Sheesh, people will use any excuse just to play the GDC's outdated card...
Oct 22 2010