> That's a curious statement, because I was trained mainly as a C/C++ programmer, and still use them for my job every day. I was very well-versed in the intricacies of C, and somewhat C++, yet I was very unhappy with them.  For several years I would scour the net during my free time to look for a better language.  I wasn't very impressed with D the first time I saw it, for various reasons, and it wasn't until I found a copy of TDPL in a local bookstore and decided on a whim to buy it, that I really got started with D.  And the rest, as they say, is history. :D
>
> Even though I suspect that I'm in the minority here, I'm pretty sure there's got to be others out there in C/C++ land who are like me, longing for a better language but just haven't found a suitable candidate yet.  So don't discount us C/C++ veteran folk just yet!

My programming language at work remains C++ too, therefore I agree that D's clean syntax is very attractive to C++ developers.

Java and C# are also "post-C++" languages, and thus their syntax is closer to D (imports, reference types, etc). D's clean and powerful syntax may not be as attractive to them.

Unfortunately C++ developers generally have to use this language in cases where garbage collected languages like Java and C# wouldn't be used.

So D's garbage collector may be a problem to convince most C++ professional developers, and D may not seem enough of an improvement for most Java/C# professional developers.

But as it can teach both the C++ and the Java/C# way of programming, as it's syntax has remained close to all of them, D can indeed be "sold" as the best first OO programming language.

Learning C++, Java or C# afterwards is quite easy.

And once you have tried D, you probably will continue to use it and promote it, like I do.

On Friday, 3 March 2017 at 19:49:06 UTC, Jared Jeffries wrote:

> I think that the programming tutorial using D as the first programming language is what is really need, and fortunately I see that now it's on his way.
>

Ali Çehreli's book is really good in that regard. he explains programming from ground up (i.e. explans bits and bytes and what variable means etc.) in a very straightforward and clever way. It's one of the best programming intro I've seen regardless of the used language. That it uses D is the icing of the cake and as you said, learning D allows to know the concepts used in C, C++, Java and C#.


> What D needs too is probably more "fame" on the beginners forums.
>

Indeed.

> How can people start learning a language, if they don't even know it exists, and perfectly fulfill their needs ?
>
> To be well known, D just need that people talk about it more for beginners.
>
> D is not *just* a language for meta-programming experts and execution speed addicts.
>
> IMHO, it's also both the *simplest & complete* alternative to C++, Java and C# out there for people learning OO programming.
>
> That must be said on every forum, at each occasion.
>
> Stop trying to convince only the expert programmers, most of them are probably not interested in leaving their C++, Java or C# language and IDE for D...

Besides the personal preferences, there are real business and technical constraints that make it difficult to change for the "experts". In my work, for instance (big government like institution), there is official IT policy that projects have to be written in Java for Weblogic application servers using Oracle as databases. So if you want support from the IT department, you better use what they offer in their catalogue. I have the luck of working on a legacy project (started in 1993), not very visible but central to the whole business of
our directorate, which means that we can force a little bit the hand of the IT department, so that they have to support our historical constraints (the project is a mix of C (99), Oracle Pro*C, perl 5, bash and a java frontend). Now I'm trying to introduce a little bit of D but that will only be possible when we have definitely moved from Solaris/SPARC to Linux/x86_64.
TL;DR
Difficult to introduce D when the project runs on Solaris/SPARC and interfaces with Oracle DB.

On Friday, 3 March 2017 at 19:18:31 UTC, jmh530 wrote:
> A Jupyter kernel would go a long way to students being able to easily play around with it in a browser. There's already dabble (D REPL) that one could make use of. I was surprised at the breadth of the list of kernels available these days.

There is also drepl:

https://github.com/drepl/drepl

though of course it's not comparable with a Jupyter kernel.

On Friday, 3 March 2017 at 18:45:50 UTC, Nick Sabalausky (Abscissa) wrote:
> On 03/03/2017 10:40 AM, Russel Winder via Digitalmars-d wrote:
>>
>> IDEs, vastly more supportive, useful software development functionality
>> than editors, especially for debugging, yes.
>>
>>
>> It's that last one, the one about getting working software developed
>> faster, that is the one that has moved me away from Emacs to IDEs. But
>
> Perhaps ironically, I used to be big on IDE's (back before the bloat). But between the bloat that started happening to them about 10+ years ago, and various factors that led me to (oddly enough) actually prefer printf debugging, I switched to more basic editors with the whole "Linux is my IDE" setup.
>
>> everyone to their own, there is no universal truth in this arena.
>>
>
> Definitely true.
>
> But I do really wish though, that the IDE devs would start prioritizing efficiency, UI snappiness, and startup time. Yea, those toold do more, but they don't do THAT much more that would technologically necessitate THAT much of a performance discrepancy. (The plain-old-editors are far more capable than I think IDE users seem to beleive).
>
>

The thing that annoys me with IDE's is generally not the IDE itself, or even their heaviness. The main problem I encounter with them is that they often end up being tied with the project itself, which means that if you want to build or modify an exist project, you have to install the same IDE as the original developer used. On open source projects it doesn't happen too often, but at work it happens all the time. The java jockeys use eclipse with a lot extensions, it take a day alone to install that shit (and be careful some of them work only on 32 bit eclipse while other require 64 bit eclipse). The frontend guys, use another java environment. The desktop apps of our project used and Visual Studio . The thing is, the old version of our app, which requires still support until it is replaced by a new one app, doesn't compile under a recent Visual Studio.

TL;DR
The big issue with IDE's is that they become part of the projects themselves.

On Saturday, 4 March 2017 at 09:13:15 UTC, Seb wrote:
> On Friday, 3 March 2017 at 19:18:31 UTC, jmh530 wrote:
>> A Jupyter kernel would go a long way to students being able to easily play around with it in a browser. There's already dabble (D REPL) that one could make use of. I was surprised at the breadth of the list of kernels available these days.
>
> There is also drepl:
>
> https://github.com/drepl/drepl
>
> though of course it's not comparable with a Jupyter kernel.

A D repl followed by a Jupyter kernel would be a great assist in engaging the data science community.

On Sat, Mar 04, 2017 at 09:06:52AM +0000, Rico Decho via Digitalmars-d wrote: [...]
> Unfortunately C++ developers generally have to use this language in cases where garbage collected languages like Java and C# wouldn't be used.
> 
> So D's garbage collector may be a problem to convince most C++ professional developers, and D may not seem enough of an improvement for most Java/C# professional developers.

Ah, the good ole GC phobia.  It was somewhat of a deterrent to me in the beginning too, I admit, but honestly, in retrospect, a lot of the GC phobia among the C/C++ crowd (including myself at the time) amounts to nothing more than unfounded prejudice, mostly stemming from initial impressions of the original GC in Java which was very sucky and had all sorts of problems. Modern GCs addressed most of these problems. Now, it's true that D's current GC needs a lot of improvement, but it really isn't as bad as people seem to think it is.

For most applications, it's actually liberating to be able to finally stop thinking about the nitty-gritty of memory management at every turn, and to be able to focus on the actual algorithms at hand. It does require a different mindset than when you're writing C++, though, so this may not click for a while at first.

It's actually rather rare to *need* to avoid the GC -- only niche applications need that, like if you're writing a game engine that has to avoid stop-the-world pauses (which can be easily worked around, btw), or real-time medical applications where if it stops for 10ms somebody dies. 90% of real world programs out there work just fine with the GC.

IME, many C/C++ folks' GC aversion are actually more religious than anything else.  I know C coders who swear against ever using any sort of GC, but then go ahead and (re)invent their own form of GC, albeit full of bugs, design flaws, and nasty unhandled corner cases that real GCs avoid. But of course, they'd never admit that their design was inferior, because GCs suck by definition, and therefore even their most flawed memory management designs must necessarily be better.


T

-- 
Why have vacation when you can work?? -- EC

On Sat, 2017-03-04 at 09:29 +0000, Patrick Schluter via Digitalmars-d wrote:
> 
[…]
> The thing that annoys me with IDE's is generally not the IDE itself, or even their heaviness. The main problem I encounter with them is that they often end up being tied with the project itself, which means that if you want to build or modify an exist project, you have to install the same IDE as the original developer used. On open source projects it doesn't happen too often, but at work it happens all the time. The java jockeys use eclipse with a lot extensions, it take a day alone to install that shit (and be careful some of them work only on 32 bit eclipse while other require 64 bit eclipse). The frontend guys, use another java environment. The desktop apps of our project used and Visual Studio . The thing is, the old version of our app, which requires still support until it is replaced by a new one app, doesn't compile under a recent Visual Studio.
> 
> TL;DR
> The big issue with IDE's is that they become part of the projects
> themselves.

I thought this sort of crap had gone out with the naughties. Any modern project uses something such as CMake, SCons, Meson, Gradle, etc. and the IDEs have plugins to generate the projects from the build system specifications. This is certainly true for all the JetBrains and Eclipse systems I use. As soon as you have to start defining the project in the IDE you are on to a total loser. So I am agreeing that the experience outlined above is wrong, but I am also saying I have not had that experience with IDEs in the last five years or more.


-- 
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@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Fri, 2017-03-03 at 09:33 -0800, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Mar 02, 2017 at 07:12:07PM -0500, Nick Sabalausky (Abscissa)
> via Digitalmars-d wrote:
> > […]
> Ahh, the memories! (And how I am dating myself... but who
> cares.)  Such
> fond memories of evenings spent poring over AppleSoft code trying for
> the first time in my life to write programs. And those lovely error
> messages with backwards punctuation:
> 
> 	?SYNTAX ERROR
> 
> :-)

Youngster. :-)

Oh for the days when the only error message you ever got was 0c4.

> […]
> I was skeptical of OO, and especially of Java, at the time.  It's
> odd,
> given that I had just been learning C++ in college and was familiar
> with
> OO concepts, but when I saw the way Java pushed for OO to the
> exclusion
> of all else, I balked.  Call me a non-conformist or whatever, but
> every
> time I see too much hype surrounding something, my kneejerk reaction
> is
> to be skeptical of it.  I eschew all bandwagons.

So how come you are on the D bandwagon? ;-)

Having been involved in the OO scene 1983 to well now I guess, yes I look back on the function/OO war and the religious aspects of it all with great embarrassment.

> […]
> 
> To be fair, though, Java as a language in and of itself is not bad at
> all. In fact, in its own way, it's a pretty nicely designed language.
> Idealistic, and in some sense approaching perfection. But in an
> idealistic bubble-world kind of way (the ugliest parts of Java, IMO,
> are
> where it has to interact with the real world -- but nevertheless, it
> isn't *bad* in itself).  The mentality and hype of the community
> surrounding it, though, seem to me to have gone off the deep end, and
> have bred rabid zealots, sad to say, to this very day, of the kind of
> calibre you described above.

Whilst I can see that of the 1994 to 2014 period, I am not sure I see it so much that way now. There are developers in Java shops who are a bit "jobsworth" and care little for personal development, and they are the people who refuse to accept the existence of languages other than Java. However most of the Java folk at the main conferences are actually JVM folk and they know languages such as Kotlin, Scala, Clojure, Groovy, Ceylon, Frege, etc. as well as Java. The zealotry, when present, is more about the JVM than Java per se.

> (I also TA'd a Java course back in the day, and was quite appalled to
> observe the number of thoroughly-confused students who couldn't tell
> control flow from OO, because "classes" had been hammered into their
> heads long before they even understood what a statement was.
> Apparently, imperative statements are non-OO and therefore evil, so
> one
> was supposed to wrap literally everything in classes. Nobody ever
> explained how one would implement class methods without using
> statements, though.  I suppose calling other class methods was
> excepted
> from the "evil" label, but it seemed to escape people's minds that
> eventually nothing would actually get accomplished if all you had was
> an
> infinite regress of calling class methods with no imperative
> statements
> in between. But such was the rabid OO-fanaticism in those days.)

There were, and are, a lot of bad teachers. Overzealous as it seems in this episode. This does not make "objects first" a bad idea per se, it just has to be done properly. Just as teaching bottom up from statement does. A bad teacher can teach any curriculum badly, that should not reflect on the curriculum.

> […]
> 
> Ha!  Let the rotten tomatoes fly, but I am a skeptic when it comes to
> dub (or any other such tool, really -- I mean no offense to Sonke).
> Sure
> they have their place in large software projects with potentially
> complicated external dependencies, but for Hello World? C'mon, now.
> Whatever happened to just:
> 
> 	import std.stdio;
> 	void main() { writeln("Hello world!"); }
> 
> And seriously, what kind of koolaid have kids these days been fed,
> that
> they can no longer work with the filesystem, but needs to be spoonfed
> by
> some automated tool? Y'know, we can't just like download scriptlike.d
> and put it in a subdir, and then import it. Oh, no, there's no app
> for
> this, and you can't do it by pressing a big red button on your
> handheld
> touchscreen, so it doesn't count. Filesystem? What's that? I only
> know
> of downloading stuff in a browser which magically gets shuffled
> somewhere in the "memory" of my device, that automatically gets found
> when I need to find it because technology is just that cool.  What's
> the
> filesystem thing you speak of? Download folder? What's that?

I am not sure where this one comes from. Here in the UK most 6 year olds are now happy manipulating filesystems. Sadly Windows ones, but I'm working on it.

-- 
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@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sat, 2017-03-04 at 19:36 +0000, Jon Degenhardt via Digitalmars-d wrote:
> On Saturday, 4 March 2017 at 09:13:15 UTC, Seb wrote:
> > On Friday, 3 March 2017 at 19:18:31 UTC, jmh530 wrote:
> > > A Jupyter kernel would go a long way to students being able to easily play around with it in a browser. There's already dabble (D REPL) that one could make use of. I was surprised at the breadth of the list of kernels available these days.
> > 
> > There is also drepl:
> > 
> > https://github.com/drepl/drepl
> > 
> > though of course it's not comparable with a Jupyter kernel.
> 
> A D repl followed by a Jupyter kernel would be a great assist in engaging the data science community.

Never underestimate the power of Jupyter within data science and finance. Just last month I reinforced a shift of another hedge fund from Matlab and R to Python using the power of Jupyter.

-- 
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@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 03/05/2017 12:12 PM, Russel Winder via Digitalmars-d wrote:
> On Sat, 2017-03-04 at 09:29 +0000, Patrick Schluter via Digitalmars-d
> wrote:
>>
>> TL;DR
>> The big issue with IDE's is that they become part of the projects
>> themselves.
>
> I thought this sort of crap had gone out with the naughties. Any modern
> project uses something such as CMake, SCons, Meson, Gradle, etc. and
> the IDEs have plugins to generate the projects from the build system
> specifications. This is certainly true for all the JetBrains and
> Eclipse systems I use. As soon as you have to start defining the
> project in the IDE you are on to a total loser. So I am agreeing that
> the experience outlined above is wrong, but I am also saying I have not
> had that experience with IDEs in the last five years or more.
>

It's true for Unity3D, unless you count msbuild/xbuild as being along the same lines as cmake/etc (and even then, I'm not sure how much I'd trust Unity not to mess with hand-edits to the msbuild files...but that fear is mainly just because Unity is very block-boxy when it comes to project building - although not as badly black-boxed as Marmalade's build process last I looked at it, but that was awhile ago).