Thread overview | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
April 15, 2015 How D could gain more traction? | ||||
---|---|---|---|---|
| ||||
Hi people. I've followed D for many years, although I haven't used it for anything big or even have a good knowledge of Phobos. I currently work in C++ a lot, although I am convinced that in theory the only reason not to run away from C++ is being tied down to a large existing codebase; and yet I'm also convinced that I couldn't sell D to my team or manager. So why's that? In my opinion the biggest and only mistake is to preach D to the C++ choir only. Of course some will say, we can't avoid this, the native choir is the only one D should or could preach to. Even if this is true or not, I said C++, not native, choir. Nowadays those two continue to be synonyms, but the point of D is that they shouldn't. More on this below. All the many and severe flaws in the C++ language are fixed in D, but the shortcomings of the C++ standard library are not. Some will say there are no fundamental flaws in it that don't come from the language, and I agree. However it has the shortcoming of being too narrow. The D standard library has followed the C++ paradigm, but C++ is quite useless without Qt, Boost etc. The only reason why this hasn't caused more detriment to C++ is (besides these 3rd-party libraries being by now quite established and thus standard de facto), that there is no native alternative to C++, except D, which has the same library problem. I've heard people say that things such as Qt or whatever not belonging in the standard library because a cross-platform language should not assume the existence of a screen, mouse or keyboard in the device. That's good and all as a statement (embedded devices can implement only part of the standard library, as is the case in .NET and Java) but it's not even a purist point of view, it's just outdated. In theory and practice nowadays it makes almost less sense in comparison to assume the existence (or relevance) of a text console. Nowadays a standard library should include classes or functions, not only for data structures, algorithms etc., but also for: GUI cross-platform creation, graphics, multi-threading at low and high level, SQL, XML, JSON, networking on all layers from raw sockets to TPC and HTTP, FTP, etc... etc.; and since the reason for native is performance, I would also throw in some advanced math (linear algebra, Newton-Raphson, etc.) If you don't agree that this should be included in a standard library, I think you're kind of still sitting in the C++ choir even if you prefer D. At this point I would of course not propose to expand the std namespace. It would be as simple as dlang.org endorsing chosen existing libraries for these core functionalities, and afterwards some publicity work. Otherwise try to convince a _business_ guy that switching to D will have any significant advantage (he will implicitly expect you to "prove it in advance"). These all-in-one solution standard libraries are in my opinion the main reason of the huge success of .NET, Java, Visual Basic 1-6, huge in absolute terms and certainly compared to D. In my company (SKF, 50k employees worldwide) they use C++ but they are expanding the use of WinDev! (I won't blame you if you don't know what the latter is, just google it.) Managers know only when a project is late. Your thoughts? |
April 15, 2015 Re: How D could gain more traction? | ||||
---|---|---|---|---|
| ||||
Posted in reply to XavierAP | On Wednesday, 15 April 2015 at 09:39:09 UTC, XavierAP wrote:
> Nowadays a standard library should include classes or functions, not only for data structures, algorithms etc., but also for: GUI cross-platform creation, graphics, multi-threading at low and high level, SQL, XML, JSON, networking on all layers from raw sockets to TPC and HTTP, FTP, etc... etc.; and since the reason for native is performance, I would also throw in some advanced math (linear algebra, Newton-Raphson, etc.) If you don't agree that this should be included in a standard library, I think you're kind of still sitting in the C++ choir even if you prefer D.
Andrei Alexandrescu has said that he wants the kitchen sink approach for the standard library. While it might not go quite as far as you would like, the direction seems the same.
|
April 15, 2015 Re: How D could gain more traction? | ||||
---|---|---|---|---|
| ||||
Posted in reply to XavierAP | On Wednesday, 15 April 2015 at 09:39:09 UTC, XavierAP wrote:
> Otherwise try to convince a _business_ guy that switching to D will have any significant advantage (he will implicitly expect you to "prove it in advance"). These all-in-one solution standard libraries are in my opinion the main reason of the huge success of .NET, Java, Visual Basic 1-6, huge in absolute terms and certainly compared to D.
Yeah, the notion of a standard library has shifted: in .net it's preset project items, on which IDE starts the package manager, which fetches the corresponding library and the item becomes ready to use. This way the user sees little difference to traditional notion of a standard library. I suppose java has even longer history of usage of 3rd party libraries.
|
April 15, 2015 Re: How D could gain more traction? | ||||
---|---|---|---|---|
| ||||
Posted in reply to XavierAP | On Wednesday, 15 April 2015 at 09:39:09 UTC, XavierAP wrote:
> also for: GUI cross-platform creation, graphics, multi-threading at low and high level, SQL, XML, JSON, networking on all layers from raw sockets to TPC and HTTP, FTP, etc... etc.; and since the reason for native is performance, I would also throw in some advanced math (linear algebra, Newton-Raphson, etc.) If you don't agree that this should be included in a standard library, I think you're kind of still sitting in the C++ choir even if you prefer D.
It is a good idea fix the pavement before you build bikes and wheelchairs. C++ is still fixing the pavement... Large sections of Python 2's pavement is largely unused. If anything D should focus on the basics.
|
April 15, 2015 Re: How D could gain more traction? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | I understand such a library collection would have many holes right now, but movement also creates its own momentum. I just think it would be good that dlang.org provided some more guidance.
I don't know, I hope to get some time on lazy Sundays to finally read Alexandrescu's book which I bought quite long ago, then start using D for more hobby projects and get to know more libraries and maybe get involved in the projects.
On Wednesday, 15 April 2015 at 10:05:37 UTC, Kagamin wrote:
> I suppose java has even longer history of usage of 3rd party libraries.
Yeah but Java's standard library itself includes many such utilities, and I think it was the key ingredient for its success in the 90s, together with the multi-platform support, but imo even more instrumental.
But probably the best example to follow for D both in general and at this point, which is forgot to mention, is Python. Its success story is almost unbelievable: the language design is godawful, so many people like it, but I can't help thinking that they just love what they can do with it, because "there's one package for that" always which is standard de facto.
If D had got the same amount of community involvement, it would have a complete kitchen sink standard library collection by now. But I think those two things have to go in sync.
|
April 15, 2015 Re: How D could gain more traction? | ||||
---|---|---|---|---|
| ||||
Posted in reply to XavierAP | On Wednesday, 15 April 2015 at 11:45:37 UTC, XavierAP wrote: > I understand such a library collection would have many holes right now, but movement also creates its own momentum. I just think it would be good that dlang.org provided some more guidance. Yes, there is a lot of overlap in the D community: 4 D compiler projects, a bunch of IDE projects, a bunch of GUI library projects, a bunch of (basic) game engine projects... All rather large in scope if you want to reach a complete state. What is needed is a committee ;). But seriously, if you had a nice public API design on paper then maybe people would flock behind the same project rather than creating their own. Unless they do it for educational reasons/entertainment. > But probably the best example to follow for D both in general and at this point, which is forgot to mention, is Python. Its success story is almost unbelievable: the language design is godawful, so many people like it, but I can't help thinking that they just love what they can do with it, because "there's one package for that" always which is standard de facto. Python is pretty close to pseduo code and has managed to grow a community that cares about API design which the language supports fairly well. Since the language is inefficient and provides no static typing good programmers tend to write cleaner code in it... Bad language qualities can lead to better coding ;) |
April 15, 2015 Re: How D could gain more traction? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | Exactly, and with the overlapping efforts the result is less than the division among the parts, because none of them reach critical mass. But this has already been kind of done in the past regarding Tango vs. Phobos. I think it would be good to extend the same guidance to a gradually growing set of necessary libraries. I was thinking less ambitiously about seeing what promising already existing projects can be used, but it may be worth it to design the APIs we'd like as you say and contrast them. |
April 15, 2015 Re: How D could gain more traction? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On 16/04/2015 12:00 a.m., "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote: > On Wednesday, 15 April 2015 at 11:45:37 UTC, XavierAP wrote: >> I understand such a library collection would have many holes right >> now, but movement also creates its own momentum. I just think it would >> be good that dlang.org provided some more guidance. > > Yes, there is a lot of overlap in the D community: 4 D compiler > projects, a bunch of IDE projects, a bunch of GUI library projects, a > bunch of (basic) game engine projects... All rather large in scope if > you want to reach a complete state. > > What is needed is a committee ;). But seriously, if you had a nice > public API design on paper then maybe people would flock behind the > same project rather than creating their own. Unless they do it for > educational reasons/entertainment. Nope. Good API isn't good enough. For things like window creation, image library ext. If they ain't in phobos, it ain't gonna get used. That's my experience with Devisualization anyway. |
April 15, 2015 Re: How D could gain more traction? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On Wednesday, 15 April 2015 at 12:00:54 UTC, Ola Fosheim Grøstad wrote:
clip
>
> Yes, there is a lot of overlap in the D community: 4 D compiler projects, a bunch of IDE projects, a bunch of GUI library projects, a bunch of (basic) game engine projects... All rather large in scope if you want to reach a complete state.
>
> What is needed is a committee ;). But seriously, if you had a nice public API design on paper then maybe people would flock behind the same project rather than creating their own. Unless they do it for educational reasons/entertainment.
>
clip
D biggest problem is that it is so fun to use it leads people to want to create their own _ insert project here _
|
April 15, 2015 Re: How D could gain more traction? | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin | On Wednesday, 15 April 2015 at 09:57:29 UTC, John Colvin wrote:
> On Wednesday, 15 April 2015 at 09:39:09 UTC, XavierAP wrote:
>> Nowadays a standard library should include classes or functions, not only for data structures, algorithms etc., but also for: GUI cross-platform creation, graphics, multi-threading at low and high level, SQL, XML, JSON, networking on all layers from raw sockets to TPC and HTTP, FTP, etc... etc.; and since the reason for native is performance, I would also throw in some advanced math (linear algebra, Newton-Raphson, etc.) If you don't agree that this should be included in a standard library, I think you're kind of still sitting in the C++ choir even if you prefer D.
>
> Andrei Alexandrescu has said that he wants the kitchen sink approach for the standard library. While it might not go quite as far as you would like, the direction seems the same.
The problem with a kitchen sink approach is that you have to make sure the libraries stay up to date - and phobos already has a few rotting modules.
See: python, many people actively avoid using the standard library in favor of third party libraries that accomplish the same task.
|
Copyright © 1999-2021 by the D Language Foundation