> Unfortunately, for speech and language processing (synthesis, speech recognition etc) Python is too slow. Everybody uses Python at first, but the serious code that is later put into real world applications is usually written in C or C++. This is a fact. I know people who developed speech analysis frameworks in Python and are now thinking of rewriting it in C++ for commercial purposes.
>
> Python is good for protoyping, but if you need fast applications, it is usually C/C++ (or D).


What you are saying is not wrong, except for the generalizations to "everybody".

Obviously you are not aware of the other people/industries who use python for non-performane critical applications (not prototype, but real large applications), there are several reasons, but don't want to bore you with details (one of which is the "super structure").

I do wish we were using D everywhere, and I do use it for personal and small tools at the job.

- engineer

On Saturday, 14 March 2015 at 18:33:24 UTC, Russel Winder wrote:
> On Sat, 2015-03-14 at 18:11 +0000, Chris via Digitalmars-d wrote:
> […]
>> 
>> This may be part of it. But I know that open source free software in this sector is also written in C/C++ or Java. I haven't seen a single system that was acceptable in Python. Sooner or later they all go back to C.
>
> Java will have the same problem as Python regarding shipping source to
> anyone who knowns how to decompile Java.
>
>> I just don't see the point in using Python only to rewrite performance critical parts in C/C++ or D. Why not start with D or C from scratch. Also, I know that this Cython and C module mixing becomes a mess very quickly which makes development tricky and deployment a pain in the a**. I believe that as soon as you have to mix languages like that, there is something wrong, and you begin to rely heavily on an infrastructure that helps you to keep track of the whole mess.
>
> I would reject C as a language of implementation for everything except
> small operating systems – which includes many embedded things, most
> being effectively operating systems. I can see people using C++, but it
> would be better if they used D, but I doubt this will happen :-(
>
> Mixing Python, Cython, and C does require standard compiled project
> management, but is no worse than pure C, C++ or D systems. I would
> suggest that the "messiness" is due to the Python people not doing the
> Cython and C properly, and the C people objecting to having Python
> involved. It usually comes down to the people and not the technology.

+1

Using Python with C++ for small critical sections reduces our code development and maintenance costs significantly. The C++ constitutes about 3% of our code base. For the rest Python does the job very well.

There is no mess, the code base and build system are nicely segregated into performance critical code and the rest.

My hope is that D can replace the Python/C++ mix with one language that is both cheap for development/maintenance and achieve the C++ performance when necessary.

But even with a single language the performance critical code would still be kept separate. It can often get messy and it's important that only those with specific algorithm and low-level expertise make changes in it.

Cheers,
Stew

Le 13/03/2015 01:20, Andrei Alexandrescu a écrit :
> A friend of mine needed to complete a small project and thought of using
> a language he didn't know for it. He already knew I work on D so he
> considered it alongside Go. He ended up choosing the latter, and
> documented his decision making process in a few notes that he
> subsequently shared with me. I'll paste below a sort of transcript of
> his handwritten notes.
>
> I think this is valuable information from a relatively unbiased
> potential user, and good ideas and action items on how we can improve
> our curb appeal. Even mistaken perceptions are good signal - it means
> our materials weren't explicit enough to dispel them.
>
> ====================
>
> * Golang: simple!
>
> + very small language, very concise & simple
> + playground/tutorial
> + easy to start using it, no-nonsense
> + vast libraries
> + no inheritance
> + one binary to distribute
> + good for servers
> + feels like a better C (mostly)
> - can't write generic code involving arrays/slices
> - no good IDE
> + Google!
> + clear feeling it's here to stay
> + visible, many projects
> + enforced style (indentation, exports)
>
> * Dlang: big!
>
> # big language
> # IDE?
> # small subset?
> # libraries?
> # will it be around?
> # Perception matters
> ## how stable is it?
> ## not great for servers or UIs; what then?
> ## new house in unpopulated neighborhood; there's an "Enter, it's open"
> sign but sits emtpy; by comparison Go -> condo in hip, trendy area
>
> * Ideas for D
>
> # what C++ should be but cannot
> ## too late for C++, but not for D
> ## some or all of @safe, immutable, pure should be the default
> # libraries, projects should be prominently listed and nurtured
> # single-idea advantage; D seems to embody too many ideas at once
> ## concurrency?
> ## networking?
> ## generics?
> ## interoperability with C and C++?
> ## focus on one!
> # must attract/hook casual users
> # unclear what's a good IDE - JetBrains? is there Vim support?
> # what's D's equivalent to frameworks such as react.js?
> # language designers think of features, users think of purpose
> ## react, go, rust, java -> purpose
> ## D, C++ -> "Ivy league candidates" having a response for every
> programming language design challenge there is, but less focused on
> purpose (Andrei's note: I assume D more at fault than C++ on this)
>
> General feeling: "I don't feel smart enough for D and am looking for a
> quick way to accomplish a goal. I've read the Wikipedia article on D and
> didn't understand a few things. The examples seem to show off the
> language but that made them confusing. I wanted to get more into it, but
> by that time Go had already won - I looked at the tutorials, changed the
> sample code a bit right in the browser to see how it'd work for me, it
> was easy, I was in already. Some of my comments therefore illustrate my
> shortcomings than the language's, but that's true one way or another for
> all programmers (that's why technical superiority of a language doesn't
> guarantee its success)."
>
> ===============
>
> I'd love us to derive a few action items from this and other feedback.
>
>
> Andrei

IMO D seems more complicated than it really is. Mostly cause of presentation of documentation, lack of examples, tutorials,...

Even there is some great changes can appear between versions, it's not a big issue, cause it will not impact small projects.

I think that the main issue is the first impression the user can have of the D ecosystem. Newbies want to be taken by hand during their first steps with a new language.

And the First page a the web site need to show what can be/is achieved with D, talk about main features, market benefits,...
Documentation is only interesting for someone already use D, so it can be in a dedicated domain name.

Take a look to the new Qt web site :
http://www.qt.io/

Documentation :
http://doc.qt.io/

I also want encourage everybody, cause the D website made some really good changes during last months.

On Saturday, 14 March 2015 at 14:45:07 UTC, rumbu wrote:
> I take the risk to be blamed, but let me tell you that the  developer world does not spin around R, Python, Fortran, Haskell and Go. These are nice languages for a bunch of *nix nerds or very specialized engineers but their usage is very limited.

For some definition of "very limited" - the developers you hang out with. The developer world is a big place.

Hi.

Some points I think are important follow.  I can't do much on these myself for now as computer use limited by a spinal injury.

1. Compilation speed of D under reference compiler compares very favourably to most (all?) other compiled languages.  This facilitates rapid iteration, which works nicely with the 'plasticity' of D code.  This should be emphasized on the landing page, and there should be a few standardised concrete reference points since for better or for worse modern people don't take you seriously if you don't quantify it.

2. D is a very powerful language whose essential features are easy to learn.  Coming from C, and not having written a great deal of code since about twenty years ago, it took me a few months to be productive in D (about the same as python, which I learnt shortly before D).  The generics and metaprogramming are not so straightforward, but you don't need to use them to be productive very quickly.  We should emphasize D can be a native code python (but is more than this if that is what you need)

3. I have said so before (the GroupBy docs) - standard library documentation is 'perfectly clear' if you have a technical mindset and are used to reading formalisms, but it is horrendously intimidating if not (which applies to many people).  We need more examples, and they should put the use in context rather than just being tiny fragments - ie show how to do something useful with the function (cf python docs).  There should also be a guide to functions writing from point of what one wants to achieve.  toLower in std.string, but I need to go to std.ascii for doing the same thing to a character.  Eminently logical, but not obvious if you don't know where to look.

4. Need a better guide to libraries and frameworks oriented to how to accomplish common tasks.  (I really don't see why you wouldn't bundle vibed with dmd+phobos since small frictions have large consequences when you are starting out).

5. Different channels for tutorials organized by use case (accessible from front page not sidebar) - writing a server, writing a script, pulling data from the Fed website and charting it, simple gui app, simple database app.  Take cybershadow's slides comparing nodejs code to vibed code.

6. More user stories accessible from front page and well organised.  Make it visual and personal.  Facebook (not just warp, but odbc, any other stories), Sociomantic, Adroll, Remedy, etc.

7. It doesn't make sense for D to 'concentrate on XYZ use case' (languages can't be centrally planned - which is not to say identifying impediments is not useful), and nor is it a problem that it 'hasn't gone anywhere' since 2001.  Things develop at their own pace, and periods of quiet building are often needed before breaking out into the next stage.  An overnight success is a long time indeed in the making.

8. Libraries are a rougher area.  RSS, XML, JSON, Redis, databases, MIME, IMAP, HDF5, etc - there are solutions, but nothing standard and no consistency in documentation.

9. Mobile seems important for future of the language but seems the effort of a small number of people.

10. Calling D a systems programming language makes me think I shouldn't use it for non-systems purposes.  That's no longer on the front page, but it is the next thing I see here: http://dlang.org/getstarted.html.  What proportion of newcomers to D want to use it for systems programming?

11. This week in D.  should there be a tour of useful frameworks from code.dlang?

12. a good part of Pandas style functionality is not so hard to do.  Vlad Levenfeld has written a framework that may be interesting here, but it is still under development.

13. charting?

On Saturday, 14 March 2015 at 23:47:24 UTC, Walter Bright wrote:
> On 3/14/2015 3:19 PM, deadalnix wrote:
>> On Saturday, 14 March 2015 at 19:48:14 UTC, Walter Bright wrote:
>>> The point is, with a library abstraction the core language can be simplified.
>>> D's ability to create user defined literals largely ends the pressure to make
>>> more complicated and specialized core language literals.
>> It makes it sounds like you don't know the spec about string literals.
>
> I know I don't know what you're driving at :-)

That we have a large number of string literals, in the core of the language, many of which could probably be language construct.

On 3/14/2015 8:41 PM, deadalnix wrote:
> On Saturday, 14 March 2015 at 23:47:24 UTC, Walter Bright wrote:
>> On 3/14/2015 3:19 PM, deadalnix wrote:
>>> On Saturday, 14 March 2015 at 19:48:14 UTC, Walter Bright wrote:
>>>> The point is, with a library abstraction the core language can be simplified.
>>>> D's ability to create user defined literals largely ends the pressure to make
>>>> more complicated and specialized core language literals.
>>> It makes it sounds like you don't know the spec about string literals.
>>
>> I know I don't know what you're driving at :-)
>
> That we have a large number of string literals, in the core of the language,
> many of which could probably be language construct.

I haven't looked into it - anything in particular you have in mind?

I'd also prefer to get rid of /+ +/ comments, I thought they'd be more useful than they are.

On 3/13/2015 2:20 PM, bearophile wrote:
>>> something like a "var" keyword to denote mutable values,
>> Transitive const may make this problematic.
> I don't understand, but perhaps you misunderstood me. I am talking about
> variables. In strict mode they are constant by default. This means in this code
> both x and y are immutable:
>
> auto x = 10;
> foreach (y; 0 .. 10) {}
>
> So in strict mode if you want them mutable you need a new keyword like "var":
>
> var x = 10;
> foreach (var y; 0 .. 10) {}

Given:

    mutable int* p;
    int* q = p;

q cannot be made immutable. But q can be made const.


>>> static full tracking of memory ownership,
>> Makes the language significantly more complex.
> You are probably right. But it also gives good things back to a system language.
> In the last years I've seen that taking twice the time to write my code is a
> good deal if later I can avoid wasting stressful hours searching and fixing
> bugs. So now I am willing to pay a high price up front when I code to avoid some
> bugs later. I have friends that have taken a look at Rust and have dismissed it
> for being too much fussy and hard to get code to compile (despite probably with
> practice the Rust rules should become quite simpler to follow), but Rust looks
> like the right language for me and I'd like the same qualities in the language
> that I like more (D). So in the end I don't know what's the best solution for D.

Rust has indeed done a good job selling people on the complexity of their annotation system. But I think starting with 'return ref' and D's ability to do inference we're actually in good shape with a far simpler system.


>>> less implicit casts (because now we have the safe int(x) sytnax),
>> I think D does very well with implicit casts.
> I am not sure of that. Implicit casts cause some troubles, you can see this if
> you program for a while in a language with no or with very little implicit casts
> like Haskell, and F#.
> In D we have some implicit casts also because the "cast(int)x" syntax is
> dangerous. But now we can write safe casts with the "int(x)" syntax, so there's
> less need of naked implicit casts.

Again, too many casts can cause bugs.

I have used languages that did not have implicit casting (Pascal) and didn't have a positive experience with it. It didn't detect a single actual bug, and managed to be quite annoying.

Value Range Propagation is a big win.

On Sunday, 15 March 2015 at 04:32:25 UTC, Walter Bright wrote:
>> That we have a large number of string literals, in the core of the language,
>> many of which could probably be language construct.
>
> I haven't looked into it - anything in particular you have in mind?
>

Not one precisely, but I'm sure we don't need as many as we have. ", `, q", q{, r", x". I've never used several of theses and I'm sure most people here would say the same.

> I'd also prefer to get rid of /+ +/ comments, I thought they'd be more useful than they are.

I use them all the time, and cringe whenever I code in something else because i don't have them. Once you have /* comments */ in some piece of code, you can't comment blocks without going through hoops. that is very annoying./+ comments +/ are one of the simple thing that makes coding in D much more pleasant.

I've been reading through the thread and it seems that the D community has an image problem of some sort. But why? D is great!

Were I to articulate D's key strengths I would say that it allows you to write precise code and be sure that it is correct. This is something you can neither do in the mainstream functional languages (fanatical insistence on hammering the GC as much as possible basically means you can never put any memory where you actually want it), or in low level but unsafe C/C++ where Everything Is Broke All The Time (TM). Don't even get me started on Python or Java which seem like they are trying to force the programmer to avoid both correctness and performance at all costs. D comes with many features for helping enforce algorithmic correctness as well as powerful code generation facilities to write code where you have low level guarantees on what it will do.

But you already knew that. So here comes The Big Question: Do those in the D community actually want it to be as mainstream as Java or Python? There are benefits and (in my view) big drawbacks. Right now the community is hobbyist, which means that the users and developers work on it *because they actually care*. And so far I have been impressed with the quality of the D ecosystem overall.

Well, who is the audience for D? The armies of corporate database programmers? Web developers? Kernel developers? Etc. Food for thought.

On Sunday, 15 March 2015 at 05:29:00 UTC, deadalnix wrote:
> On Sunday, 15 March 2015 at 04:32:25 UTC, Walter Bright wrote:
>>> That we have a large number of string literals, in the core of the language,
>>> many of which could probably be language construct.
>>
>> I haven't looked into it - anything in particular you have in mind?
>>
>
> Not one precisely, but I'm sure we don't need as many as we have. ", `, q", q{, r", x". I've never used several of theses and I'm sure most people here would say the same.
>
>> I'd also prefer to get rid of /+ +/ comments, I thought they'd be more useful than they are.
>
> I use them all the time, and cringe whenever I code in something else because i don't have them. Once you have /* comments */ in some piece of code, you can't comment blocks without going through hoops. that is very annoying./+ comments +/ are one of the simple thing that makes coding in D much more pleasant.