www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Linux Agora D thread

reply Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

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
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 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 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
 C#/Windows 64 7 months        very good  85           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 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 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 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 next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

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 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
prev sibling 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 C#/Windows 64 7 months very good 85 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
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
 C#/Windows 64 7 months        very good  85           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 reading this newsgroup), 90-150 (D was #1 in the language shootout but the guy 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 next sibling parent 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
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
 C#/Windows 64 7 months        very good  85           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 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 next 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
 C#/Windows 64 7 months        very good  85           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 next 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
prev sibling parent "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. I think the #1 reason is this: Yes D2 compiler has stopped adding 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