On Monday, 7 January 2013 at 19:59:44 UTC, Walter Bright wrote:
> On 1/7/2013 5:31 AM, Chris wrote:
>> Nice article. Once I have enough time I would like to write a short article
>> about how D has solved practical issues for me.
>
> Please do!

I'd love to.

>
>
>> I think it is not enough to talk
>> about all the features of the language (templates, GC) without giving practical
>> examples
>
> This is a very important point. Without showing how features combine to solve interesting problems, people tend to view lists of features as just
>
>    ...buzz...buzz...buzz...buzz...buzz...

Exactly, especially since not everyone who uses a programming language uses it because of _all_ the features but because it solves certain specific problems for them. Think of scientists who create a tool for their research (e.g. Hidden Markov models - http://en.wikipedia.org/wiki/Hidden_Markov_model). They are not necessarily interested in templates, but they might need speed, concurrency and interfacing to existing C libraries. Python took off in the scientific community (well, it was designed as a scientific language, I think). The question is usually "What can the language do for me? How can it help me?" The good thing about D is that it can help a lot of people in a lot of different ways (systems programming, UTF-8, concurrency etc.) but not everyone needs all features (and you don't need to use them all at the same time). D can boast that it has it all but people need to see what "all" means, and here we need practical examples (real projects).

Another thing, IMO, is that there is an overemphasis on C++ vs. D. Usually people have to choose between systems programming (learn C/C++) or high level (learn Python, Ruby etc.). Most non-programmers who need to write a piece of software opt for Python and other scripting languages, because nobody wants to learn C/C++ only to write a small parser for data files. With D you no longer have to choose. You can write both quick and dirty script-like stuff and stuff that is close to the machine. Python and Ruby took off, I think, because they appealed to people who are not fully fledged programmers but who want or need to do some programming. This is the crowd the D community has to get on board. Don't forget that this is what has made JavaScript one of the most widely used languages (alas!).

On Mon, 7 Jan 2013 14:48:38 +0300
Max Klyga <email@domain.com> wrote:
> 
> bearophile, WHY U KEEP POSTING ABOUT OTHER LANGUAGES?! http://alltheragefaces.com/img/faces/large/misc-jackie-chan-l.png
> 

Because it's good to not have blinders on when developing or using a language.

I do like that image though. :)

On Monday, 7 January 2013 at 22:14:46 UTC, Ali Çehreli wrote:
> On 01/07/2013 01:57 PM, Phil Lavoie wrote:
>
> > I meant scope objects work fine in most cases, but sometimes
> its good to
> > explicitly delete objects on the heap.
>
> Usually, what is needed is to just finalize the object. The memory that it sits on should still be managed by the GC.

This is all fine when GC is precise. With current GC in 32 bits I'd rather have manual deallocation than leaks. This is actually what I successfully did in a photo editing app: using 'delete' for large chunks of data (uncompressed photos) and GC for the rest. This way everything worked smoothly.

On Monday, 7 January 2013 at 12:16:04 UTC, thedeemon wrote:
> On Monday, 7 January 2013 at 11:31:46 UTC, bearophile wrote:
>
>> There is also Rust.
>
> I had the impression that Rust was at embryonic stage where it changes all the time, can't really live by itself and is not born yet. It's an interesting project but not a language one would use today for real work. Or am I mistaken?

Yeah, my impression is it's still pretty embryonic, especially on the library side.

On Sunday, 13 January 2013 at 16:00:27 UTC, SomeDude wrote:
> On Monday, 7 January 2013 at 12:16:04 UTC, thedeemon wrote:
>> On Monday, 7 January 2013 at 11:31:46 UTC, bearophile wrote:
>>
>>> There is also Rust.
>>
>> I had the impression that Rust was at embryonic stage where it changes all the time, can't really live by itself and is not born yet. It's an interesting project but not a language one would use today for real work. Or am I mistaken?
>
> Yeah, my impression is it's still pretty embryonic, especially on the library side.

Also we don't know how well it performs, although it looks like the design is intended to perform reasonably well.

On Monday, 7 January 2013 at 22:21:59 UTC, Chris wrote:
> Another thing, IMO, is that there is an overemphasis on C++ vs. D. Usually people have to choose between systems programming (learn C/C++) or high level (learn Python, Ruby etc.). Most non-programmers who need to write a piece of software opt for Python and other scripting languages, because nobody wants to learn C/C++ only to write a small parser for data files. With D you no longer have to choose. You can write both quick and dirty script-like stuff and stuff that is close to the machine. Python and Ruby took off, I think, because they appealed to people who are not fully fledged programmers but who want or need to do some programming. This is the crowd the D community has to get on board. Don't forget that this is what has made JavaScript one of the most widely used languages (alas!).

A really important advantage that scripting languages provides that D does not currently provide, is direct runtime interpretation of the language. This is very important for the use cases of script languages such as Ruby and PHP, because often they are used for coding and testing on the fly, ie., used in an environment that requires frequent changes with almost instant feedback.

You can also embed a scripting language directly into other applications, and store "code" as data, which can be transmitted from one machine to another over the wire. We can store and transmit D code too, but getting it to automatically run on the other end is not so easy or convenient.

All of these things D, as a language, probably can do (although perhaps only as a subset of the full language), but the tools are simply not there yet.

A language such as C++ seems like a bad fit for a scripting language because of it's complexity and the difficultly with parsing through it. Also a scripted language probably should not have low level access that is provided by languages such as D and C/C++.

--rt

On Tuesday, 15 January 2013 at 06:30:33 UTC, Rob T wrote:

> A really important advantage that scripting languages provides that D does not currently provide, is direct runtime interpretation of the language. This is very important for the use cases of script languages such as Ruby and PHP, because often they are used for coding and testing on the fly, ie., used in an environment that requires frequent changes with almost instant feedback.

This is true. On the other hand, if you do quick and dirty stuff (count the frequency of certain words, parse data files etc.), the compilation time is not really an issue, and due to unnecessarily ugly syntax (PHP, Perl) or indentation (t)errors (Python) you sometimes lose time, or cannot just copy and paste snippets to test them without checking your spaces.

[...]

> A language such as C++ seems like a bad fit for a scripting language because of it's complexity and the difficultly with parsing through it. Also a scripted language probably should not have low level access that is provided by languages such as D and C/C++.
>
> --rt

Why not? In my experience small scripts often turn into bigger programs and sooner or later you need some sort of low level features. Then you have to write modules in C/C++ and use Swig or something to integrate them. That's why I prefer D, because you can get the whole shebang _if necessary_. There are also copyright issues. If you deliver a Python program, anyone could rip it, even if you compile it to byte code. If you distribute native executables, it's harder to rip your program. In general, I find scripting languages less useful for projects that (might) develop into something bigger. Now that I come to think of it, scripting languages are inherently "quick and dirty", that's why they are not really scalable (think of the class system in Python and Lua, not the real deal).

Chris:

> or indentation (t)errors (Python)

In practice Python usually decreases the number of indentation-related bugs, even considering the "dangling else" warning we have added to D, because indentation and block nesting are the same thing, it's more DRY :-)

Bye,
bearophile

On Tuesday, 15 January 2013 at 11:00:29 UTC, bearophile wrote:
> Chris:
>
>> or indentation (t)errors (Python)
>
> In practice Python usually decreases the number of indentation-related bugs, even considering the "dangling else" warning we have added to D, because indentation and block nesting are the same thing, it's more DRY :-)
>
> Bye,
> bearophile

Maybe it does, but it's annoying while you are writing it, and to be honest, indentation bugs are far and few between, in my experience, if you use the curly braces consistently. Only you have more freedom. What I was referring to was the annoying Python message "Wrong indentation in line ...", when you run a script, which makes it hard to copy & paste and just test a snippet, before you integrate it properly. Well, that's me. Other people like rules and regulations.

> Maybe it does, but it's annoying while you are writing it, and to be honest, indentation bugs are far and few between, in my experience, if you use the curly braces consistently. Only you have more freedom. What I was referring to was the annoying Python message "Wrong indentation in line ...", when you run a script, which makes it hard to copy & paste and just test a snippet, before you integrate it properly. Well, that's me. Other people like rules and regulations.
> 

Stereotypes of people who never actually used it, other than tried it and gave up because they didn't configure their editor correctly and blaming python for it. I bet my last indentation error was more than two years ago.