Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Saturday, 3 February 2018 at 01:52:04 UTC, psychoticRabbit wrote: On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote: I am personally confused with D's message. I think that point hits the cause of your problem with D (along with your need to 'choose' something over 'something' else). Stop looking for the meaning of D .. and start experiencing it. (there is no meaning...to anything!) Stop comparing D to other things, and just enjoy what it has to offer. (tribalism not cool!) And btw. one persons technical justification for using x, is another persons technical justification for not using x. Plenty of experienced programmers (who never used D before) now enjoy using D, even if they still have to program in other languages...in order to earn a living. Too many corporations have big investments in other languages. Don't expect D to compete here anytime soon. That is the nature of business. If D is to take off anywhere, it will be in the open source community, and startups - not a google or facebook, and certainly never microsoft. D has a lot of good and interesting things to offer to the world of software development, including an amazing, reasonably efficient standard library (with support from the compiler). It also supports all major platforms that matter (although it's hard to argue that windows 32bit 'matters' ;-). And there is no corporate backer making this all happen. It's just people who want to build something great, and give up their time to do it. D has the benefit of having a compiler expert, and an algorithm expert in the core team. The advantage from this cannot be underestimated (which is why many are willing to look the other way when it comes to lack of significant management skills ;-) ..and I'd rather it that way, than the other way (i.e great managers, who don't understand a thing). Both would be nice.. but who has that? Probably the best response to what he wrote and to similar sentiments expressed by others over the years, but I'll add one caveat: it has been mentioned here that D has been used a little by a few teams at both Facebook and Microsoft, dunno about Google. Though as you said, no sign that they'll embrace it much more, and probably better to have it adopted at many more smaller places. But D is on a road trip...it's not at its destination (I'm not sure it even knows - or cares - where its going ;-) Just enjoy the road trip! Or jump out. It's entirely your choice. But the road trip will continue, and those on it, will keep enjoying new sights... According to Linus, it is impossible to know your destination if your scope is wide enough, such as a general-purpose programming language or an OS kernel, as this is what he said in response to a question about whether linux could still be designed at the scale it reached 16 years ago: "I will go further and claim that _no_ major software project that has been successful in a general marketplace (as opposed to niches) has ever gone through those nice lifecycles they tell you about in CompSci classes. Have you _ever_ heard of a project that actually started off with trying to figure out what it should do, a rigorous design phase, and a implementation phase? Dream on. Software evolves. It isn't designed. The only question is how strictly you _control_ the evolution, and how open you are to external sources of mutations. And too much control of the evolution will kill you. Inevitably, and without fail. Always. In biology, and in software. Amen." http://yarchive.net/comp/evolution.html
Re: Inline code in the docs - the correct way
On Friday, 2 February 2018 at 20:15:11 UTC, H. S. Teoh wrote: This is the kind of thing you should be promoting to Andrei to convince him that dpldocs is better. ;-) I'm updating my fork now and check out this merge conflict: <<< HEAD * source = The [isInputRange|input range] to encode. === * source = The $(REF_ALTTEXT input range, isInputRange, std,range,primitives) * to _encode. b905180b1fffa78f922677ee90ed8ae9b803fc4f My syntax is so much prettier. (note that the stupid leading _ is something I strip out too. Ddoc's most moronic "feature". Can we PLEASE kill that?!?!?!!)
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On 2/2/2018 7:06 AM, Benny wrote: Other languages have slogans, they have selling points. When i hear Go, you hear uniformal, fast, simple syntax language. When i hear Rust, you hear safe, manual memory management. When i hear D, you hear ... ... ... ... Fast code, fast
Re: The delang is using merge instead of rebase/squash
On Sunday, 19 November 2017 at 04:44:24 UTC, Meta wrote: On Friday, 24 March 2017 at 16:34:46 UTC, Martin Nowak wrote: On Tuesday, 21 March 2017 at 20:16:00 UTC, Atila Neves wrote: git rebase master my_branch git checkout master git merge --no-ff my_branch Yes, that's about what we aim for, rebase w/ --autosquash though, so that people can `git commit --fixup` new fixup commits to open PRs w/o leaving noise behind. https://github.com/dlang-bots/dlang-bot/issues/64 Requires a local checkout of the repo which the bot doesn't have atm. Did we come to any consensus on this? I ran into a dilemma with https://github.com/dlang/phobos/pull/5577 where I added a couple fixup commits, and now I don't want to merge until somebody rebases it because the history will be polluted with those extra commits. Also, looking at the PRs linked in this thread, I see that they're still open so AFAICT there is no clear solution. This is an important issue; rebase workflows are standard practice; http://kensheedlo.com/essays/why-you-should-use-a-rebase-workflow/ https://help.github.com/articles/configuring-commit-rebasing-for-pull-requests/
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote: Other languages have slogans, they have selling points. When i hear Go, you hear uniformal, fast, simple syntax language. When i hear Rust, you hear safe, manual memory management. When i hear D, you hear ... ... ... ... When i hear D, you hear: "The freedom to program, the way you want". (if you listen carefully..then you'll hear it)
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote: I am personally confused with D's message. I think that point hits the cause of your problem with D (along with your need to 'choose' something over 'something' else). Stop looking for the meaning of D .. and start experiencing it. (there is no meaning...to anything!) Stop comparing D to other things, and just enjoy what it has to offer. (tribalism not cool!) And btw. one persons technical justification for using x, is another persons technical justification for not using x. Plenty of experienced programmers (who never used D before) now enjoy using D, even if they still have to program in other languages...in order to earn a living. Too many corporations have big investments in other languages. Don't expect D to compete here anytime soon. That is the nature of business. If D is to take off anywhere, it will be in the open source community, and startups - not a google or facebook, and certainly never microsoft. D has a lot of good and interesting things to offer to the world of software development, including an amazing, reasonably efficient standard library (with support from the compiler). It also supports all major platforms that matter (although it's hard to argue that windows 32bit 'matters' ;-). And there is no corporate backer making this all happen. It's just people who want to build something great, and give up their time to do it. D has the benefit of having a compiler expert, and an algorithm expert in the core team. The advantage from this cannot be underestimated (which is why many are willing to look the other way when it comes to lack of significant management skills ;-) ..and I'd rather it that way, than the other way (i.e great managers, who don't understand a thing). Both would be nice.. but who has that? But D is on a road trip...it's not at its destination (I'm not sure it even knows - or cares - where its going ;-) Just enjoy the road trip! Or jump out. It's entirely your choice. But the road trip will continue, and those on it, will keep enjoying new sights...
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Saturday, 3 February 2018 at 00:11:06 UTC, Adam D. Ruppe wrote: On Friday, 2 February 2018 at 23:49:14 UTC, aberba wrote: It appears most core contributors are not into networking or web services so they may not see it as a blocker. I do tons of HTTP stuff in D; to me it is a solved problem. Though I haven't implemented http2 since I don't need it; http 1.1 has much better compatibility (and will for many years to come) and performs plenty well enough for API client use, and server use is handled behind a production server anyway, so it works quite well. A http2 client might be worth doing someday, but right now there's just no pressing need, even using http resources every day. Yeah. I do know you're on of the few guys into web services.
Re: Inline code in the docs - the correct way
On 2/1/2018 6:09 AM, Steven Schveighoffer wrote:
On 1/31/18 9:58 PM, Walter Bright wrote:
On 1/31/2018 5:37 PM, Steven Schveighoffer wrote:
Where it breaks down is when you have many nested tags, and you end with )
Long ago, I adjusted my text editor so that when the cursor is placed on ),
the matching ( is found. Ditto for { }, [ ], < >, and #if/#elif/#else/#endif
(!). It's been incredibly convenient.
This has literally been in vim since I started using it, what, 15 years ago? It
doesn't matter.
The #if too?
When I'm reviewing a PR, I don't see the matching as easily.
True, but that applies to anything with a block structure.
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Friday, 2 February 2018 at 23:49:14 UTC, aberba wrote: It appears most core contributors are not into networking or web services so they may not see it as a blocker. I do tons of HTTP stuff in D; to me it is a solved problem. Though I haven't implemented http2 since I don't need it; http 1.1 has much better compatibility (and will for many years to come) and performs plenty well enough for API client use, and server use is handled behind a production server anyway, so it works quite well. A http2 client might be worth doing someday, but right now there's just no pressing need, even using http resources every day.
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Friday, 2 February 2018 at 23:49:14 UTC, aberba wrote: On Friday, 2 February 2018 at 21:09:20 UTC, Rubn wrote: [...] D can equally do HTTP in whatever way Go does it. It appears most core contributors are not into networking or web services so they may not see it as a blocker. Its more of an ecosystem issue and not a language issue. [...] Now I can't fix my statement ... The statement doesn't make sense to me.
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Friday, 2 February 2018 at 21:09:20 UTC, Rubn wrote: On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote: HTTP: If you are focusing on Http then yah Go is probably the better choice, it looks like it is entire geared towards http development. I wouldn't use D for http just like I wouldn't use C++ for http. D can equally do HTTP in whatever way Go does it. It appears most core contributors are not into networking or web services so they may not see it as a blocker. Its more of an ecosystem issue and not a language issue. Even with D, we have libraries like request (http://code.dlang.org/packages/requests) for HTTP/FTP. Its does support http2 yet though but its enough for all my HTTP needs for now. We also have vibe.d which I don't get the point which saying it might be abandoned is not a reason to ignore it as useful or enough. I've seen several people here submitting pull requests in every release of it. Considering the size of this community (in my estimation), vibe.d is well supported. It does more than what express for NodeJS does on its own. There in also an effort to make D work on Alpine Linux which is very common for packaging applications into lightweight docker containers. Support for D in the cloud also require some amount of work since none of them support D SDKs. The Internet and the web is continuously growing and communication protocols are quite significant in the change.
Re: Inline code in the docs - the correct way
On Friday, 2 February 2018 at 20:15:11 UTC, H. S. Teoh wrote: This is the kind of thing you should be promoting to Andrei to convince him that dpldocs is better. ;-) I've laid out my arguments several times, including this point. Actually, $(REF) was introduced after I made the argument, so it is a slight win, though ddoc, over the last two years, has barely caught up to what I was able to accomplish independently in two weeks.
Re: Quora: Why hasn't D started to replace C++?
On Fri, 02 Feb 2018 20:04:33 +, Seb wrote: > Not could - it's now is: > https://forum.dlang.org/post/tzyleprmwjmdnjhhp...@forum.dlang.org Sometimes y'all get things done so quickly I'm surprised everybody's a volunteer. --Ryan
Re: [RFC] IDE starter kit
On Friday, 2 February 2018 at 20:42:55 UTC, Ivan Trombley wrote: Here's how I get started: - Install DMD. - Install Visual Studio Code. - Add Jan Jurzitza's (webfreak) serve-d and Native Debug plugins to VSC. C:\D\dmd2\windows\bin\..\..\src\phobos\std\math.d(543,33): Deprecation: integral promotion not done for `-x`, use '-transition=intpromote' switch or `-cast(int)(x)` emsi_containers 0.5.3: building configuration "library"... dsymbol 0.2.8: building configuration "library"... ..\..\..\dub\packages\dsymbol-0.2.8\dsymbol\src\dsymbol\conversion\first.d(189,15): Error: no property 'symbol' for type 'const(Type2)' ..\..\..\dub\packages\dsymbol-0.2.8\dsymbol\src\dsymbol\conversion\first.d(189,42): Error: no property 'symbol' for type 'const(Type2)' ..\..\..\dub\packages\dsymbol-0.2.8\dsymbol\src\dsymbol\conversion\first.d(192,23): Error: no property 'symbol' for type 'const(Type2)' ..\..\..\dub\packages\emsi_containers-0.5.3\emsi_containers\src\containers\unrolledlist.d(504,15): Deprecation: integral promotion not done for `~this.registry`, use '-transition=intpromote' switch or `~cast(int)(this.registry)` ..\..\..\dub\packages\emsi_containers-0.5.3\emsi_containers\src\containers\unrolledlist.d(504,15): Deprecation: integral promotion not done for `~this.registry`, use '-transition=intpromote' switch or `~cast(int)(this.registry)` ..\..\..\dub\packages\emsi_containers-0.5.3\emsi_containers\src\containers\unrolledlist.d(504,15): Deprecation: integral promotion not done for `~this.registry`, use '-transition=intpromote' switch or `~cast(int)(this.registry)` ..\..\..\dub\packages\dsymbol-0.2.8\dsymbol\src\dsymbol\conversion\first.d(248,35): Error: no property 'identifierList' for type 'const(AliasDeclaration)' ..\..\..\dub\packages\emsi_containers-0.5.3\emsi_containers\src\containers\unrolledlist.d(504,15): Deprecation: integral promotion not done for `~this.registry`, use '-transition=intpromote' switch or `~cast(int)(this.registry)` ..\..\..\dub\packages\dsymbol-0.2.8\dsymbol\src\dsymbol\conversion\first.d(938,14): Error: no property 'symbol' for type 'const(Type2)' ..\..\..\dub\packages\dsymbol-0.2.8\dsymbol\src\dsymbol\conversion\first.d(939,18): Error: no property 'symbol' for type 'const(Type2)' ..\..\..\dub\packages\emsi_containers-0.5.3\emsi_containers\src\containers\unrolledlist.d(504,15): Deprecation: integral promotion not done for `~this.registry`, use '-transition=intpromote' switch or `~cast(int)(this.registry)` ..\..\..\dub\packages\emsi_containers-0.5.3\emsi_containers\src\containers\unrolledlist.d(504,15): Deprecation: integral promotion not done for `~this.registry`, use '-transition=intpromote' switch or `~cast(int)(this.registry)` ..\..\..\dub\packages\emsi_containers-0.5.3\emsi_containers\src\containers\unrolledlist.d(504,15): Deprecation: integral promotion not done for `~this.registry`, use '-transition=intpromote' switch or `~cast(int)(this.registry)` ..\..\..\dub\packages\emsi_containers-0.5.3\emsi_containers\src\containers\unrolledlist.d(504,15): Deprecation: integral promotion not done for `~this.registry`, use '-transition=intpromote' switch or `~cast(int)(this.registry)` ..\..\..\dub\packages\emsi_containers-0.5.3\emsi_containers\src\containers\unrolledlist.d(504,15): Deprecation: integral promotion not done for `~this.registry`, use '-transition=intpromote' switch or `~cast(int)(this.registry)` ..\..\..\dub\packages\dsymbol-0.2.8\dsymbol\src\dsymbol\semantic.d(123,21): Error: no property 'symbol' for type 'dparse.ast.Type2' ..\..\..\dub\packages\dsymbol-0.2.8\dsymbol\src\dsymbol\semantic.d(124,21): Error: no property 'symbol' for type 'dparse.ast.Type2' ..\..\..\dub\packages\dsymbol-0.2.8\dsymbol\src\dsymbol\semantic.d(128,21): Error: no property 'symbol' for type 'dparse.ast.Type2' ..\..\..\dub\packages\dsymbol-0.2.8\dsymbol\src\dsymbol\semantic.d(130,21): Error: no property 'symbol' for type 'dparse.ast.Type2' dmd failed with exit code 1. Failed to install serve-d (Error code 2) - Get busy. Yes. Now I'm busy cleaning my C:\Users\***\AppData\Roaming\ folder.
Re: D build and SCons
On Thu, Feb 01, 2018 at 12:56:28PM +, Russel Winder wrote: [...] > Apologies for taking so long to get to this. Not a problem, you and I are both busy, and it's perfectly understandable that we can't respond to things instantly. > On Thu, 2017-12-28 at 10:21 -0800, H. S. Teoh via Digitalmars-d wrote: [...] > > OK, I may have worded things poorly here. What I meant was that > > with "traditional" build systems like make or SCons, whenever you > > needed to rebuild the source tree, the tool has to scan the *entire* > > source tree in order to discover what needs to be rebuilt. I.e., > > it's O(N) where N is the size of the source tree. Whereas with tup, > > it uses the Linux kernel's inotify mechanism to learn about which > > file(s) being monitored have been changed since the last invocation, > > so that it can scan the changed files in O(n) time where n is the > > number of changed files, and in the usual case, n is much smaller > > than N. It's still linear in terms of the size of the change, but > > sublinear in terms of the size of the entire source tree. > > This I can agree with. SCons definitely has to check hashes to > determine which files have changed in a "not just space change" way on > the leaves of the build ADG. I am not sure what Ninja does, but yes > Tup uses inotify to filter the list of touched, but not necessarily > changed, files. For my projects build time generally dominates check > time so I don't see much difference. Except that Ninja is way faster > than Make as a backend to CMake. In small projects like my personal ones, SCons still does a fast enough job that I don't really care about the difference between O(N) and O(n). So I still use SCons for them -- SCons does have a really nice interface and is generally pleasant to work with, so I don't feel an immediate need to improve the build system. But in a large project, like the one I work with at my job, containing 500,000 source files (not counting data files and the like that also need to be processed by the build system), the difference can become very pronounced. In our case, we use make, which doesn't scan file contents, and recursive make at that, so the initial scanning pause is not noticeable. However, this perceived speed comes at the heavy cost of reliability. On more occasions than I'd wish anyone else to experience, I've had problems with faulty software builds caused not by actual bugs in the code, but merely by make not rebuilding something when it should be, or not cleaning up stray stale files when it should, causing stale object files to be linked instead of the real objects. It has simply become an accepted fact of life to `make clean; make`. Well actually, it's even worse than that -- our `make clean` does *not* clean everything that might potentially be a problem, so I have for the last ≥5 years resorted to a script that manually deletes everything that isn't under version control. (What makes it even sadder is that the version control server is overloaded and it's faster to delete files locally than to checkout a fresh copy of the workspace, which is essentially what my script amounts to.) At one point I was on the verge of proposing SCons as a make replacement, but balked when initial research into the prospect showed that SCons consistently had performance issues with needing to scan the entire source tree before it begins building. That, coupled with general resistance to change in your average programmer workforce and their general unfamiliarity with make alternatives, made me back off from making the proposal. Had tup been around at that time, it would likely have turned the tables with its killer combo of sublinear (relative to workspace size) scanning and reliability. That's why I think that any modern build system that's going to last into the future must have these two features, at a minimum. > > I think it should be obvious that an approach whose complexity is > > proportional to the size of the changeset is preferable to an > > approach whose complexity is proportional to the size of the entire > > source tree, esp. given the large sizes of today's typical software > > projects. If I modify 1 file in a project of 10,000 source files, > > rebuilding should not be orders of magnitude slower than if I modify > > 1 file in a project of 100 files. > > Is it obvious, but complexity is not everything, wall clock time is > arguably more important. Using inotify() to update your dependency tree has basically zero wall clock time because it's done in the background. You can't beat that with anything that requires scanning upon invocation of the build tool. > As is actual build time versus preparation time. SCons does indeed > have a large up-front ADG check time for large projects. I believe > there is the Parts overlay on SCons for dealing with big projects. I > believe the plan for later in the year is for the most useful parts of > Parts to become part of the main SCons system.
Re: [RFC] IDE starter kit
On Friday, 2 February 2018 at 20:42:55 UTC, Ivan Trombley wrote: Here's how I get started: - Install DMD. - Install Visual Studio Code. - Add Jan Jurzitza's (webfreak) serve-d and Native Debug plugins to VSC. - Get busy. this entire procedure also works on windows now as you no longer need LDC for serve-d/workspace-d to work :)
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
When i hear Go, you hear uniformal, fast, simple syntax language. When i hear Rust, you hear safe, manual memory management. When i hear D, you hear ... ... ... ... I usually hear awesome meta-programming and ranges. I think D community had put lot of effort in making these things work because (1) these are cool (2) increases expressive power. Unfortunately at the detriment of tooling and libraries. I think we should put a stop to adding new features in D2 at some point and focus on stability, libraries and tools. Can't wait to see how the road map looks like for 18H1.
Re: Quora: Why hasn't D started to replace C++?
On Friday, 2 February 2018 at 21:14:12 UTC, Walter Bright wrote: On 2/2/2018 11:08 AM, Russel Winder wrote: Hummm… could it be that Andrei did not define the task appropriately, train the person appropriately, and mentor the person appropriately. Management has to be able to delegate and achieve required results without doing the work themselves. Of course. But all that is far easier said than done. Andrei and I are not born managers, we are learning as we go. So I ask for your indulgence and understanding where we fall short. Would it be easier for hire a proven manager(Or at least look for mangers that are able to volunteer)?
Re: Quora: Why hasn't D started to replace C++?
On 2/2/2018 11:08 AM, Russel Winder wrote: Hummm… could it be that Andrei did not define the task appropriately, train the person appropriately, and mentor the person appropriately. Management has to be able to delegate and achieve required results without doing the work themselves. Of course. But all that is far easier said than done. Andrei and I are not born managers, we are learning as we go. So I ask for your indulgence and understanding where we fall short.
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote: HTTP: If you are focusing on Http then yah Go is probably the better choice, it looks like it is entire geared towards http development. I wouldn't use D for http just like I wouldn't use C++ for http.
Re: Quora: Why hasn't D started to replace C++?
On Friday, 2 February 2018 at 18:17:30 UTC, H. S. Teoh wrote: On Fri, Feb 02, 2018 at 03:06:57PM +, Mark via It has, to some extent. But the fundamental problem remains that more manpower is needed so that he can be freed up to do the more important things. Having to personally review all new public symbols added to Phobos, for example, just doesn't seem scalable in the long run. But, as Andrei himself said, the last time he left that decision to somebody else, there was a noticeable deterioration in the quality of code in Phobos. So we need not only more manpower, but also more *trusted* manpower; people who share the same views as Andrei, whom he can trust to make the right decisions without his intervention. There's no silver bullet to this, and it's indeed a very difficult task. Having done this for a lot of my life, my advice is simply to keep that always present in every decision, and, sometime, be more permissive in the short term decisions, to just archive that more important long term goal. Growing (and discovering!), talents it's indeed a job by itself. /P
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On 2/2/18 1:38 PM, welkam wrote: On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote: ** Wall of text ** I dont post here often but... Most of what you complain is known already and/or not entirely correct. People who work on D are not some glue sniffing brain dead individuals that are incapable of understanding that documentation is not perfect, library support is lacking and user experience is not at the same level as C#. That and more are known here. Over the years that I lurked here I saw many people come on forums and complain about things that are obvious and say them in a way that indirectly imply incompetence of core contributors. Things don't work not because of incompetence but because there is not enough people working on things. Thats why you get answers you get. To fix problems we need people who work so either you become one (fix it yourself) or get some one else to work (pay money). The entire D project is fueled by coffee and dislike of C/C++ and its amazing that it achieved so much with so little It is pretty amazing, and it's a testament to how appealing the D language can be, even with all its surrounding pain points. As a long time lurker it seems like I see posts like Benny's more often recently than I recall seeing in years past. This makes me happy--to me it's a sign that more people are seriously considering D than used to. I also think it's good to be reminded of what newcomers' pain points are, and I'm glad Benny took the time to list his.
Re: [RFC] IDE starter kit
Here's how I get started: - Install DMD. - Install Visual Studio Code. - Add Jan Jurzitza's (webfreak) serve-d and Native Debug plugins to VSC. - Get busy.
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote: HTTP: D has no default HTTP server. So you need to rely on vibe.d. Vibe.d being a external package that then relies on a few people to maintain it. D has no future proof HTTP. There is currently no official http2 build in to vibe.d. Test branches do not count ;) D interfaces with C and C++ so you are not limited to vibe.d. You have entire C and probably all C++ HTTP libraries. And you didnt benchmark D. You benchmarked vibe.d
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote: ** Wall of text ** I dont post here often but... Most of what you complain is known already and/or not entirely correct. People who work on D are not some glue sniffing brain dead individuals that are incapable of understanding that documentation is not perfect, library support is lacking and user experience is not at the same level as C#. That and more are known here. Over the years that I lurked here I saw many people come on forums and complain about things that are obvious and say them in a way that indirectly imply incompetence of core contributors. Things don't work not because of incompetence but because there is not enough people working on things. Thats why you get answers you get. To fix problems we need people who work so either you become one (fix it yourself) or get some one else to work (pay money). The entire D project is fueled by coffee and dislike of C/C++ and its amazing that it achieved so much with so little
Re: Inline code in the docs - the correct way
On Fri, Feb 02, 2018 at 07:46:51PM +, Adam D. Ruppe via Digitalmars-d wrote: > On Friday, 2 February 2018 at 18:45:50 UTC, H. S. Teoh wrote: > > In an ideal world, you wouldn't need to encode any of this stuff > > inside a ddoc comment. > > Well, that's what the Phobos REF macro does... sort of. You write > $(REF symbolName, std, module) and the macro figures out the link. > Though, even that macro is based on the url structure on dlang.org... [...] Well exactly, and that's the problem. The macro arguments require knowledge of the URL structure on dlang.org. And also knowledge of the FQN of the symbol. When the FQN changes, you have to update *every link* that refers to that symbol. That's like coding in the bad ole days before encapsulation was a common practice. Everything depended on everything else, and changing one small thing causes a ripple effect that requires touching the rest of the code in 100 different places. We should be leveraging what the compiler is already capable of doing, and keep the docs agnostic of the nitty-gritty details of the symbol's FQN or where it might reside in the URL tree. It's plain and simple encapsulation, as applied to docs. [...] > > Since ddoc comments are processed by the compiler, and the compiler > > has all of the information necessary to resolve identifiers, > > arguably all that *should* be needed is just a way to indicate in > > the docs, "this word is an identifier", and the compiler would > > figure out what it's referring to, perhaps expand it into a > > fully-qualified name like std.range.primitives.isInputRange. > > Right, this is exactly what adrdox does and it has been a smashing > success to me. It'd be nice if ddoc did it too (at least so I don't > have to deal with so many merge conflicts on the broken phobos source > links!) [...] This is the kind of thing you should be promoting to Andrei to convince him that dpldocs is better. ;-) T -- Today's society is one of specialization: as you grow, you learn more and more about less and less. Eventually, you know everything about nothing.
Re: Quora: Why hasn't D started to replace C++?
On Thursday, 1 February 2018 at 11:40:32 UTC, rjframe wrote: On Thu, 01 Feb 2018 11:11:20 +, Martin Tschierschke wrote: Idea: There should be some kind of news ticker for all enhancements and important decisions, maybe at first just via twitter with a special #tag beside #dlang where all updates are announced. And a place on the homepage, where this feed is displayed separately. The announce forum gets most things; if you're not reading it you'll want to (between that and the changelog for the compiler and library, that's most activity). A twitter bot to pull all announce posts from core committers might not be a bad idea. Not could - it's now is: https://forum.dlang.org/post/tzyleprmwjmdnjhhp...@forum.dlang.org
Re: Inline code in the docs - the correct way
On Friday, 2 February 2018 at 18:45:50 UTC, H. S. Teoh wrote: In an ideal world, you wouldn't need to encode any of this stuff inside a ddoc comment. Well, that's what the Phobos REF macro does... sort of. You write $(REF symbolName, std, module) and the macro figures out the link. Though, even that macro is based on the url structure on dlang.org... it separates package arguments because it needs to $2_$3.html#$1 which doesn't match any generator. But it is a heck of a lot better than the old way of $(LINK2 std_string.html, std.string) which is just plain broken (and btw a few of those are still there :( ). Since ddoc comments are processed by the compiler, and the compiler has all of the information necessary to resolve identifiers, arguably all that *should* be needed is just a way to indicate in the docs, "this word is an identifier", and the compiler would figure out what it's referring to, perhaps expand it into a fully-qualified name like std.range.primitives.isInputRange. Right, this is exactly what adrdox does and it has been a smashing success to me. It'd be nice if ddoc did it too (at least so I don't have to deal with so many merge conflicts on the broken phobos source links!)
Re: [RFC] IDE starter kit
On Friday, 2 February 2018 at 15:13:49 UTC, aberba wrote: Anyways, DLangUI currently stands as the defacto cross-platform GUI library for D. Its keeps getting better in functionality. In this context, I'm talking about a lazy and convenient Windows user first experience with D. He doesn't know anything about dub, packages or about the excellent work of Vadim. It will be nice for him to type "import std.ui" instead to download dub, install it, launch command prompt, run some mysterious dub command and download 5 dependencies just to display a window. Even the fact that you must use dub to have a GUI project is not understandable for a first time user. The current GUI Sample for D in Visual Studio just throws an exception and the code looks painfully too similar to the one I found in my first Windows programming book from the '90s :)
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Friday, 2 February 2018 at 17:24:47 UTC, H. S. Teoh wrote: On Fri, Feb 02, 2018 at 05:01:58PM +, bachmeier via Digitalmars-d wrote: [...] The things you want - a perfect out-of-the-box Windows experience, where you can make requests for others to do the things you want - is not what D has to offer. While I agree that in an open-source volunteer project like this one, it doesn't make sense to go around telling others what to do (it's their own free time, they get to decide what they like to work on), I think the bit about a perfect out-of-the-box Windows experience is something that we can and should work on, even if we may never get there, given our current manpower. Reducing unnecessary barriers like this will only benefit us in the long run. I don't think it's a good idea to just give up on it or ignore it. And AFAIK, there *are* some people working on improving Windows support, though progress is slow because of limited manpower. (And there's where more volunteers to step up to the plate would help expedite things.) So IMO it's unfair to say that D has absolutely nothing to offer on this front -- it's not perfect yet, but we're getting there! T Not sure what happened to my response... Improving the Windows experience is definitely a good thing. The Windows experience is not yet what it should be, and that's where you either have to do the work or pay someone else to do the work.
Re: Quora: Why hasn't D started to replace C++?
On Fri, Feb 02, 2018 at 07:08:47PM +, Russel Winder wrote: > On Fri, 2018-02-02 at 10:17 -0800, H. S. Teoh via Digitalmars-d wrote: > […] > > It has, to some extent. But the fundamental problem remains that > > more manpower is needed so that he can be freed up to do the more > > important things. Having to personally review all new public > > symbols added to Phobos, for example, just doesn't seem scalable in > > the long run. But, as Andrei himself said, the last time he left > > that decision to somebody else, there was a noticeable deterioration > > in the quality of code in Phobos. So we need not only more > > manpower, but also more *trusted* manpower; people who share the > > same views as Andrei, whom he can trust to make the right decisions > > without his intervention. > > Hummm… could it be that Andrei did not define the task appropriately, > train the person appropriately, and mentor the person appropriately. > > Management has to be able to delegate and achieve required results > without doing the work themselves. [...] Exactly. Tech people like us tend to shy away from this sort of thing, but it's clearly something sorely needed here. T -- Verbing weirds language. -- Calvin (& Hobbes)
Re: Quora: Why hasn't D started to replace C++?
On Fri, 2018-02-02 at 10:17 -0800, H. S. Teoh via Digitalmars-d wrote: > […] > It has, to some extent. But the fundamental problem remains that more > manpower is needed so that he can be freed up to do the more > important > things. Having to personally review all new public symbols added to > Phobos, for example, just doesn't seem scalable in the long > run. But, > as Andrei himself said, the last time he left that decision to > somebody > else, there was a noticeable deterioration in the quality of code in > Phobos. So we need not only more manpower, but also more *trusted* > manpower; people who share the same views as Andrei, whom he can > trust > to make the right decisions without his intervention. Hummm… could it be that Andrei did not define the task appropriately, train the person appropriately, and mentor the person appropriately. Management has to be able to delegate and achieve required results without doing the work themselves. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Inline code in the docs - the correct way
On Fri, Feb 02, 2018 at 10:49:18AM -0700, Jonathan M Davis via Digitalmars-d wrote: > On Friday, February 02, 2018 15:12:45 Adam D. Ruppe via Digitalmars-d wrote: > > On Thursday, 1 February 2018 at 02:10:22 UTC, Jonathan M Davis > > > IMHO, the main problem with ddoc for documentation is that it > > > doesn't automatically handle stuff like cross-links, and it > > > fundamentally can't, because to do that properly, you have to > > > generate all of the docs at once with a standard layout for where > > > everything goes so that the links can link to stuff. > > > > Well, maybe, it could do something like adrdox's symbol lookup but > > instead of generating a link directly, it could replace it with > > $(REF) and let the macro definitions handle it. > > > > Wouldn't be perfect tho, that macro is clunky to use and define > > because it doesn't know all the details, but it would be a move up > > from what we have, and may even work inside code examples. > > I thought about that, but it falls flat on its face as soon as not all > of the user-defined types are from the library being documented. The > simplest example would be if I were to publish my own library but it > used types from Phobos in its API. Turning those types into links > would then try to link to my project's documentation, which wouldn't > work. Best case, I could create redirects to the Phobos docs, so that > might work, but it gets messy fast, and any types from 3rd party > libraries which were used in the API would have the same problem. > Somehow, the links would have to be made to work regardless of whether > the types were part of the project being documented. [...] In an ideal world, you wouldn't need to encode any of this stuff inside a ddoc comment. Since ddoc comments are processed by the compiler, and the compiler has all of the information necessary to resolve identifiers, arguably all that *should* be needed is just a way to indicate in the docs, "this word is an identifier", and the compiler would figure out what it's referring to, perhaps expand it into a fully-qualified name like std.range.primitives.isInputRange. Then this can be handed to a stylesheet that would turn it into a link of some sort. Cluttering ddoc comments with URLs (or, as a proxy, macros containing information specific to URLs) that, arguably, the code itself shouldn't depend on, is something I have ideological issues with. It's one thing to refer to a full URL to some online reference like a technical spec that's unchanging and, ostensibly, will always be out there; it's quite something else to explicitly spell out links to a particular symbol using a hard-coded path that can change any time. E.g., today I may link to MyType as: $(LINK $(WEBROOT)/mypackage/mymod.html#MyType) but tomorrow I may have a major refactoring and now I have to change *all* such links to: $(LINK $(WEBROOT)/mynewpackage/newsubpackage/newmod.html#MyType) instead, whereas the code itself actually doesn't need to change at all, because the compiler already knows where's the new location of the symbol, using standard identifier resolution. Why can't I just write `[MyType]` (or whatever other syntax you prefer), and let the compiler figure out what the right fully-qualified name is? Once the compiler figures it out, the stylesheet takes care of turning it into a HTML link or the equivalent in whatever other output format you may be using. On a higher level, even explicit links to symbols in Phobos docs are a bad idea. What if 5 months later we decide to move dlang.org/phobos to dlang.org/docs/phobos? Or if a Phobos refactoring moves a symbol to another module? Any explicit URLs in user ddoc comments will break, and will have to be updated *one-by-one*. Whereas if we let the compiler do its job, the worst that would happen is we update the stylesheet to point to dlang.org/docs/phobos/* instead of dlang.org/phobos/*, and *all* links in generated ddocs will be automatically corrected. Any change in the path to the symbol's doc will already have been resolved by the compiler -- if your code compiles at all. tl;dr: I think anything more than plain old markup saying "this is a symbol that needs a link" in a doc comment is a bad idea. Ddoc comments shouldn't be replicating the job of the compiler, and that poorly. T -- If creativity is stifled by rigid discipline, then it is not true creativity.
Re: Quora: Why hasn't D started to replace C++?
On Fri, Feb 02, 2018 at 03:06:57PM +, Mark via Digitalmars-d wrote: > On Wednesday, 31 January 2018 at 23:38:22 UTC, H. S. Teoh wrote: [...] > > And I'll be frank that sometimes Andrei can take some effort to > > convince, and it takes a certain amount of dogged persistence (and > > thick-skin) to get through to him sometimes. And it doesn't help > > that he has so much on his plate, and generally doesn't have enough > > time to dedicate to all the decisions waiting upon him to make, so > > sometimes it can be frustrating trying to get through to him. [...] It seems that what I said above caused a bit of a stir. So let me clarify that it was not intended to be a personal critique of Andrei, and I apologize if it came across that way. It was more intended as a friendly dig on, shall we say, one of his more endearing personality traits -- strong opinions on technical issues and the guts to stick to them. And to his credit, I don't know if somebody else in his shoes would be able to do better than he does now. Having to make sometimes tough decisions, e.g., rejecting work that somebody put a lot of effort into for the sake of the larger picture, while under the pressure of so many other responsibilities, is not something I envy. We should be glad Andrei is willing to shoulder this burden, since otherwise D would not be where it is today. > In DConf 2016 Andrei literally said "I'm in charge of too many things. > Please get me fired!" [1]. Sadly, it doesn't seem like much firing has > happened since then. :-( [...] It has, to some extent. But the fundamental problem remains that more manpower is needed so that he can be freed up to do the more important things. Having to personally review all new public symbols added to Phobos, for example, just doesn't seem scalable in the long run. But, as Andrei himself said, the last time he left that decision to somebody else, there was a noticeable deterioration in the quality of code in Phobos. So we need not only more manpower, but also more *trusted* manpower; people who share the same views as Andrei, whom he can trust to make the right decisions without his intervention. T -- "Maybe" is a strange word. When mom or dad says it it means "yes", but when my big brothers say it it means "no"! -- PJ jr.
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote: [snip] D is a fantastic language. If I can derive some gist from OP, we need high quality libraries for people to use. There are two things here: libraries (of) high quality (features, performance, stability) Most of the stated facts are known and there are many such threads in this forum. However actionable things will become reality only with *quality man power*. Probably the D website should highlight that before people come here to compare it with Rust, Go, C++ etc which are backed up by $$$ corporations. D might have lost it's mind share, but is trying hard to catch up to it. That's why you see things on D blog and so on.
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote: 75. Go 69. .Net 67. Rust 64. Pascal < This one surprised even me. 63. Crystal 60. D 55. Swift 51. Kotlin It is interesting that you took the time to score different languages, but of course, there probably are a lot languages or frameworks that you didn't score. Anyway, I think in most cases polyglot programmers looking for high productivity would pick a language from a very small set of parameters, which basically has very little to do with the language itself: What would be the most productive tooling for this very narrow problem I am facing? Then you look at tooling that has been used for similar problems, and the eco system around that. Rust, Crystal, Kotlin and Pascal would typically be very far down on that list. The eco system being an issue. In reality many programming tasks can be solved efficiently with "interpreted" languages like Python or the Javascript-ecosystem. I.e. you can get good performance and high productivity for many applications if you are selective in how you build your application. The reason for this? They have been used for many different applications, so other people have already done the groundwork.
Re: Inline code in the docs - the correct way
On Friday, February 02, 2018 15:12:45 Adam D. Ruppe via Digitalmars-d wrote: > On Thursday, 1 February 2018 at 02:10:22 UTC, Jonathan M Davis > > IMHO, the main problem with ddoc for documentation is that it > > doesn't automatically handle stuff like cross-links, and it > > fundamentally can't, because to do that properly, you have to > > generate all of the docs at once with a standard layout for > > where everything goes so that the links can link to stuff. > > Well, maybe, it could do something like adrdox's symbol lookup > but instead of generating a link directly, it could replace it > with $(REF) and let the macro definitions handle it. > > Wouldn't be perfect tho, that macro is clunky to use and define > because it doesn't know all the details, but it would be a move > up from what we have, and may even work inside code examples. I thought about that, but it falls flat on its face as soon as not all of the user-defined types are from the library being documented. The simplest example would be if I were to publish my own library but it used types from Phobos in its API. Turning those types into links would then try to link to my project's documentation, which wouldn't work. Best case, I could create redirects to the Phobos docs, so that might work, but it gets messy fast, and any types from 3rd party libraries which were used in the API would have the same problem. Somehow, the links would have to be made to work regardless of whether the types were part of the project being documented. - Jonathan M Davis
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Fri, Feb 02, 2018 at 05:01:58PM +, bachmeier via Digitalmars-d wrote: [...] > The things you want - a perfect out-of-the-box Windows experience, > where you can make requests for others to do the things you want - is > not what D has to offer. While I agree that in an open-source volunteer project like this one, it doesn't make sense to go around telling others what to do (it's their own free time, they get to decide what they like to work on), I think the bit about a perfect out-of-the-box Windows experience is something that we can and should work on, even if we may never get there, given our current manpower. Reducing unnecessary barriers like this will only benefit us in the long run. I don't think it's a good idea to just give up on it or ignore it. And AFAIK, there *are* some people working on improving Windows support, though progress is slow because of limited manpower. (And there's where more volunteers to step up to the plate would help expedite things.) So IMO it's unfair to say that D has absolutely nothing to offer on this front -- it's not perfect yet, but we're getting there! T -- What did the alien say to Schubert? "Take me to your lieder."
Re: adrdox vs markdown vs ddoc
On Thursday, 1 February 2018 at 14:51:41 UTC, ag0aep6g wrote: On 02/01/2018 07:18 AM, Seb wrote: It tells quite a bit about the complexity of Ddoc that I had to add support for -D to run.dlang.io ... [...] I'm not a fan of Ddoc by any means, but that has been fixed in Ddoc does this too now: https://run.dlang.io/is/75Z55o Uhh, is it a good idea to generate documentation on run.dlang.io? Isn't this an open invitation for XSS? Simple example, one can replace all links on the page with malicious ones: https://run.dlang.io/is/wYLpVx I don't think it's a big problem as user needs to explicitly approve the code by hitting Run. Also all the other Web editors (JSBin, JSFiddle etc.) allow you to do the same and even load the HTML + JS when you open the page. Nevertheless, I added the "sandbox" feature of IFrames: https://www.html5rocks.com/en/tutorials/security/sandboxed-iframes -> now even any kind of JS code can't be executed. Thanks!
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote: You don't want any comments on your post, but this being the internet, it's necessary to respond when you disagree. D has a nice community IF you fit into the mold. As a Windows user i am frankly fed up with people giving responses as "report it, fix it yourself" when it has been clearly stated that i do as much. Or when a opinion is voiced about potential improvements, it comes down to "do it yourself or pay for it". It is my personal opinion that: * Do it yourself * Pay for it * Report it ( when the author has stated that they did ) Those comments add nothing to any discussions, they sidetrack discussion and only alienate people. Just do a google search and its horrible how many posts show up with this type of comment or variation. Some people feel overly aggressive in defending D from criticism that it only alienates people. It has alienated me. Whenever i think about D, it positive feeling to move forward is always matched with dread thinking about some people or comments when i want to talk about issues. The nice people here do not way up, to the people with a chip on there shoulder, that just ruin your day/mood. It also does not help when comments boil down how "windows users do not contribute" when they actually do. Its very condescending and just scares away people. The reason you hear this is because you are getting an explanation of how things work around here. You write "Those comments add nothing to any discussions" and in a sense that is true. But that's because there really isn't a reason to have a discussion. You are getting an answer. There is nothing to be gained from saying "someone should do this and this and this". When you get those responses, it is simply people explaining how things are done. It wouldn't make sense to go into a clothing store and complain that they don't sell fried chicken. If you're in the market for fried chicken, don't go to a clothing store. The things you want - a perfect out-of-the-box Windows experience, where you can make requests for others to do the things you want - is not what D has to offer.
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote: D has no default HTTP server. So you need to rely on vibe.d. Vibe.d being a external package that then relies on a few people to maintain it. You could also use my libs, which have been around far longer than vibe.d and work fairly well with a variety of things including http serving, cgi interfacing, databases, gui, scripting, all in easy-to-use independent modules and often using reliable first-party libraries to avoid bugs. Of course, you can be forgiven for not knowing that, since I don't aggressively advertise them. I'm tempted to package it all together someday though... a "just works" thing with the packaged libs and maybe even an IDE would be nice. But alas, I don't have an IDE packaged like that (yet, at least).
Re: ExpressionTuple is referenced in the specs, but doesn't seem to be defined
On Wednesday, 31 January 2018 at 12:35:37 UTC, Nick Treleaven wrote: It's now called an Expression List: https://dlang.org/ctarguments.html#homogenous-lists That page needs an update too, we should call them sequences. I'll try to update the docs soon. There are still various places that need fixing, but this fixes the one from your link: https://github.com/dlang/dlang.org/pull/2161
Re: Inline code in the docs - the correct way
On Thursday, 1 February 2018 at 02:10:22 UTC, Jonathan M Davis wrote: Personally, I hate markdown, because it makes certain syntax magical - e.g. it's not uncommon that a commit message ends up looking bad when github uses it as the message for a PR, because some piece of code contained * or some other piece of syntax that markdown decides to do something magical with. Yeah. I _much_ prefer the explicit syntax used by ddoc, so I can't say that I'm at all happy at the idea of markdown syntax being added to ddoc. I agree, which is why adrdox only has a few magic syntaxes at top level and they are in places where I think it is more important to be extremely convenient (like cross-linking*). But, at the same time, some special syntax can be REALLY nice. So I went with the hybrid approach: certain ddoc macro blocks actually run magic syntax: $(LIST * List item here * another list item * third list item ) The bracket clearly indicates that you want to opt-in to the special syntax, then you get to use that syntax for a while for the convenience. Another benefit is you can add other tweaks like class names for the HTML inside the bracket since there is a spot for that. But anyway, the bracket also lets me use different syntaxes or reuse the same in a few places and generate different things. And BTW it is worth noting that ddoc ALREADY has a little bit of this: see the "Params:" section! * BTW I almost wanted that syntax to be a bit uglier so you can embed it in code samples too unambiguously but that made me use it less instead of more... IMHO, the main problem with ddoc for documentation is that it doesn't automatically handle stuff like cross-links, and it fundamentally can't, because to do that properly, you have to generate all of the docs at once with a standard layout for where everything goes so that the links can link to stuff. Well, maybe, it could do something like adrdox's symbol lookup but instead of generating a link directly, it could replace it with $(REF) and let the macro definitions handle it. Wouldn't be perfect tho, that macro is clunky to use and define because it doesn't know all the details, but it would be a move up from what we have, and may even work inside code examples.
Re: [RFC] IDE starter kit
On Friday, 2 February 2018 at 13:04:19 UTC, rumbu wrote: On Thursday, 1 February 2018 at 12:21:24 UTC, rjframe wrote: [...] [snip] [...] As a typical very lazy & convenient Windows user, even I don't want to discourage you, let me tell you that every developer from the Windows world will have a copy of Visual Studio installed. New Project -> Console Application -> Hit F5. It just works. Set a breakpoint -> Hit F5. It just works. [...] DLangUI has DML which is like QML for QtQuick in Qt. Its possible to create a UI builder for it in Visual Studio or better still an independent tool like Glade for Gtk. Anyways, DLangUI currently stands as the defacto cross-platform GUI library for D. Its keeps getting better in functionality. - not enough samples in VS. At least an updated GUI app and and a Web server app must be available. Just as a proof of concept.
Re: Quora: Why hasn't D started to replace C++?
On Wednesday, 31 January 2018 at 23:38:22 UTC, H. S. Teoh wrote: And IIRC, Andrei had already bought into the ddox system by then (the process of merging it might have already begun, I'm not 100% certain), so dpldocs was already starting from a disadvantaged position, whatever merits it may have on its own. And I'll be frank that sometimes Andrei can take some effort to convince, and it takes a certain amount of dogged persistence (and thick-skin) to get through to him sometimes. And it doesn't help that he has so much on his plate, and generally doesn't have enough time to dedicate to all the decisions waiting upon him to make, so sometimes it can be frustrating trying to get through to him. T In DConf 2016 Andrei literally said "I'm in charge of too many things. Please get me fired!" [1]. Sadly, it doesn't seem like much firing has happened since then. :-( [1] https://www.youtube.com/watch?v=4oDK91E3VKs&feature=youtu.be&t=9m42s
My choice to pick Go over D ( and Rust ), mostly non-technical
First of all, please do not repost this on Reddit or any other forum. This is focused for the D community alone to help deal with internal issues and it does not need to be ridiculed as this is a personal opinion. As some have seen my posting in the past week regarding D, i like to explain my reasoning. I have been looking for the language to use for my next project, one of them was D. But the choice was more or less between Rust, D and Go. As all 3 offered good multi-platform support ( essential ), fast, low memory usage. It came down to a list of criteria. I will mostly focus on D and Go as mentioning Rust too much will simply sidetrack the post too much. HTTP: D has no default HTTP server. So you need to rely on vibe.d. Vibe.d being a external package that then relies on a few people to maintain it. D has no future proof HTTP. There is currently no official http2 build in to vibe.d. Test branches do not count ;) Go is the only one in the short-list that has a default HTTP solution that is well tested by loads of people, is fast ( especially with pre-fork ) and future proof. Performance: When it comes down to anything HTTP related unfortunately D is lagging behind on this part. Especially vibe.d www.techempower.com/benchmarks/previews/round15. The techempower is just as example. My own tests show the same performance issues where D at minimum to a un-preforked Go loses over 30% in real life, network tested benchmarks ( not some silly local device benchmarks that most people do ). It also shows D has a higher CPU usage for the relative lower performance. Pre-forking Go increases the CPU usage but also performance. All of my own tests are done with LDC ( optimized flags ) not DMD. Sure, benchmarks are the devils breath but it makes no sense building a application that even with database queries are slow compared to the rest. Build: DMD is fast, no doubt about it but Go is just instant in my case for the same type of content i need ( Go HTTP vs D vibe.d ). Other issues in my past with D also did not help, namely the regressions and constant bug-fix releases. Its time for D to figure out a stable API. Its really bad when one compiles editor plugin code and sees "deprecated function" all over the output. How up to date is the https://dlang.org/deprecate.html even? Community / Code examples: D has a nice community here on the forum but out in the real world "the internet" D is more or less non existing. Google searches end up so many times back to this forum with a LOT of outdated code going back 5+ years, what does not work anymore as API changes happened. The fact that a lot of code out there is old or non functional is a issue. Worse when 80% of the search results end up in this forum, showing that D does not have a very broad community. I do not deny that D is used by some big companies as a C++ replacement but the impression is that those are mostly closed source projects where very few code surfaces on the web. Package support: Again ... D has very few packages and a LOT of them are frankly so old that they do not work properly anymore with the current DMD versions. Deprecated functions galore. If D had 1195 active, well supported high quality packages but it has not. Most packages at best have one decent package and that is it. You want to produce PDFs? fpdf 2015-Apr-06, a very limited PDF generation tool last updated 3 years go. You want to produce Excel's? Excel-d but it faces the same issue as being the only native project. What if the author ... GRPC? Imap? ... As i post this code.dlang.org is down so no more comparing. *sigh* https://github.com/avelino/awesome-go https://github.com/zhaopuming/awesome-d < missing Excel-d Just looking on Github for D vs Go packages. 323 vs 15,351 (dlang vs golang) ... This is again related to popularity and community. So there is much more chance for finding something exotic as a base project in Go then ever in D. Windows support: But unlike D, Go's Windows support is simply better. Plugins work out of the box with VSC. It has its own Jetbrain IDE. Is Go perfect, no... Dealing with Gopath is stupid. Who's idiotic idea that was instead of managing simply by project location. Its no fun dealing with the Go Sqlite plugin ( what is 3th party ) on Windows but then your are in actual production doing something, not fighting D to get your IDE working. Or fighting dub versions when LDC and DMD are both installed and in the environment path. The amount of strange issues, not bugs or cross platform support issue that crosses D Windows users, simply leaves a bad taste. Windows / Community issues: From a persona point of view, its tiring with some people looking down on the fact that i use Windows and have true issues related to D. That have been reported and helped fix but its a never ending stream of fixing one thing, running into another. Currently n
Re: adrdox vs markdown vs ddoc
On Thursday, 1 February 2018 at 12:06:44 UTC, Kagamin wrote: Well, there's line-oriented tabular data format, forgot the name (re*-something), it looks like definition list: What bugs me with that sample is that the headers are repeated a lot... but it isn't bad. But re* sounds like maybe restructuredText which I borrowed some ideas from too.
Re: adrdox vs markdown vs ddoc
On Thursday, 1 February 2018 at 19:21:52 UTC, H. S. Teoh wrote: As far as nested comments are concerned, I'm a firm believer in ddoc'd unittests, so I hardly ever bother with inline code examples, much less ones that need comments, and pretty much never ones that need block comments. I use the documented unittests too, but they do have some pretty big limits: it is hard to embed them around explanatory text and actually using them as tests has a few limits: * the unittest is not fully isolated, but users will copy/paste them into separate code. It may pass the test because of, for example, an import outside the test, but then fail to compile for the end user. * automated tests are designed for automation and resiliancy, but good examples are designed for interactivity and tinkering by the user. They are almost opposite in purpose! (even the above goes in - a unittest tests a unit... a good example shows how to put the pieces together) * unittests with a main function are a little wonky, but you can make it work. I still kinda like it... but I think it is actually overrated.
Re: How programmers transition between languages
On Friday, 2 February 2018 at 14:04:09 UTC, Russel Winder wrote: On Fri, 2018-02-02 at 10:03 +, Atila Neves via Digitalmars-d wrote: […] Whether it's .a or .so depends on the dependent package being `staticLibrary` or `dynamicLibrary`. It's possible for a package to be both if it has a configuration for each. I think that is one of my points, the package source downloaded from the Dub repository should not be determining whether a .a or ,so is produced, it should be determined by the receiver of the downloaded package. Personally I don't even see the point - just link all the .o files. In a traditional build system static libraries might be useful to specify that multiple targets link to this particular binary blob. With dub there's only ever one binary anyway. But a static library is just a collection of .o files so I think it fits with "link all the .o together". Not quite. There's an extra step and when linking with a static library unused symbols are thrown away by default. That hid a dmd bug in 2.078.0 that only manifests when linking with the object files themselves. It is clear that there is a move in the Go, Rust, D communities to rejecting the concept of shared library, and that 100MB executables are acceptable. On a desktop, 100MB executables are, at least to me. Shared libraries aren't going to magically make 100MB executables disappear, it depends on how much code is actually shared. And at this point in time I think shared libraries are mostly a mistake. The only time I use them is when I have to, as in when developing Python extensions. The single biggest argument for shared libraries in D is GtkD. Linking an executable with a static GtkD library takes ages, and when developing you do a lot of linking. Fast turnaround, and thus reasonable development times, requires use of a shared library for GtkD. That's a fair point. Atila
Re: Quora: Why hasn't D started to replace C++?
On Thu, 2018-02-01 at 19:28 +, John Gabriele via Digitalmars-d wrote: > On Thursday, 1 February 2018 at 03:00:07 UTC, Walter Bright wrote: > > On 1/31/2018 5:58 PM, H. S. Teoh wrote: > > > cosmetic features. > > > > I tough lesson I've learned is that cosmetics matter, a lot. > > Sometimes much more than substance. There's no getting away > > from it. I agree but only if s/Markdown/AsciiDoctor/g > This is one reason I recommend markdown for docs. Cosmetics is > what markdown does best. People *like* looking at it and editing > it. It's like typing an email or a forum comment. > > Other reasons I recommend it are: > >* everyone already knows it (it's at github, stackoverflow, and > reddit), > >* it's fairly easy to write (as easy as possible while still > looking good), > >* there's an open spec (CommonMark), and > >* writing new language-specific markup formats appears to be > something that's not done anymore. There's javadoc, texinfo, > doxygen, docbook, groff --- all very ... *mature* technologies. > In modern projects: Rust uses markdown, Python uses reST, Git > uses asciidoc --- all general-purpose non- language-specific > lightweight markup formats. > > The only reason I can think of for *not* using markdown for > project docs is if your project is another competing lightweight > markup format. Markdown was created to write a few HTML pages. AsciiDoc (and thus AsciiDoctor) was invented to be a front end to the DocBook/XML toolchain. Thus Markdown is for a few small very simple webpages, AsciiDoctor is for creating any form of document from a page to a book. They are similar where Markdown has functionality, but AsciiDoctor has so much more, and most people end up finding they want all the extras. XeLaTeX and Sphinx/ReStructuredText are the competition for AsciiDoctor. Markdown is lacking in functionality people will find they need to use. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Quora: Why hasn't D started to replace C++?
On Thu, 2018-02-01 at 19:41 +, John Gabriele via Digitalmars-d wrote: > […] > It's trivial to put multiple markdown files together into a large > doc, if that's desired. Just put a bunch of .md files together > into the same directory and run your markdown processor on them. > They can link to each other in the [normal > way](./other-file.html#normal-way). Auto generation of contents pages, and indexes? Tables? Nested lists? The CommonMark crib sheet says nothing. AsciiDoctor has all of them, though I prefer XeLaTeX. > Markdown provides a simple, practical, modern, and commonly-known > way to get docs written fast and by anyone who wants to pop in > and improve them. There's no easier way to write plain text docs > that look as good. AsciiDoctor. > Sorry, can't recall if I already mentioned this, but D suffers > from a perception that it's "old", or "the language that tried > and failed to replace C++". Something simple like markdown for > its docs sends a clear message that D is modern and knows when to > pivot to new and better ways after the old ways are not serving > it anymore. Markdown is so last decade. Ditto AsciiDoctor. XeLateX so last millenium. The question is choosing the right tool for the job, not pandering to hipster fashionistas. Clearly one reviews new ways and moves to them if that provides a better way forward, but the goal is more important that the technology. There are the autogenerated reference pages. JavaDoc, Doxygen, all have their upside and downside. D has DDOC, is it fit for purpose? Should it be replaced (by Doxygen) or evolved? Maybe Markdown fits here, but without table support you end up hacking stuff. cf. vast tracts of early JavaDoc stuff. For the documents no created by scanning the source code, you want something like Markdown, AsciiDoc, ReStructuredText, XeLaTeX. I think Sphinx/ReStructuredText actually can do both from code generated reference and other documents – it does for many projects as well as Python. I happen to rate AsciiDoc far better than Markdown as a lightweight text markup, though actually I prefer XeLaTeX. However, simply trading emails about "I think X is best" is not going to get anyone anywhere. Only when someone actually does something is there movement forward. So unless some actually creates a demo of the (Markdown|AsciiDoctor|XeLaTeX) system nothing will change. Of course if Walter and/or Andrei don't like it, it will be wasted effort. > Incidentally, choosing an established standard like markdown is a > good way to short-circuit bikeshedding about "it what ways should > ddoc be updated to include some markdown features?". Just pick > standard CommonMark markdown and you're done. s/Markdown/AsciiDoctor/g > One last note and I'll (try to!) stop: it's difficult enough to > get good writers to help with docs. Much more so when they've got > to first learn your own language-specific markup (which is only > useful with your project). This is a good and strong point, that has been raised in many other places I frequent. One group changed from their custom DocBook/XML to Sphinx because someone did stuff rather than talking about it. AsciiDoctor would clearly have been a better solution, evolution using the DocBook toolchain, but they went for the revolution because people put effort into it to make the decision happen. The core point is how are you going to get pull requests from people to update and evolve the documentation. An esoteric, indeed unique, markup language is clearly the wrong choice. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: How programmers transition between languages
On Fri, 2018-02-02 at 10:03 +, Atila Neves via Digitalmars-d wrote: > […] > Whether it's .a or .so depends on the dependent package being > `staticLibrary` or `dynamicLibrary`. It's possible for a package > to be both if it has a configuration for each. I think that is one of my points, the package source downloaded from the Dub repository should not be determining whether a .a or ,so is produced, it should be determined by the receiver of the downloaded package. > Personally I don't even see the point - just link all the .o > files. In a traditional build system static libraries might be > useful to specify that multiple targets link to this particular > binary blob. With dub there's only ever one binary anyway. But a static library is just a collection of .o files so I think it fits with "link all the .o together". It is clear that there is a move in the Go, Rust, D communities to rejecting the concept of shared library, and that 100MB executables are acceptable. > And at this point in time I think shared libraries are mostly a > mistake. The only time I use them is when I have to, as in when > developing Python extensions. The single biggest argument for shared libraries in D is GtkD. Linking an executable with a static GtkD library takes ages, and when developing you do a lot of linking. Fast turnaround, and thus reasonable development times, requires use of a shared library for GtkD. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: An idea for commercial support for D
On Friday, 2 February 2018 at 10:21:35 UTC, Joakim wrote: I can't be bothered to strain through your tortured analogies that make no sense and explain to you all the ways you're wrong. I'm respecting you enough to point out that none of your points make any sense, most would just ignore crazy analogies like this and move on, content to let you stew in this nonsense. Well, that sure is an interesting way of responding to criticism. By giving up, you've made your argument ever weaker that it was before. But all power to you..and you're hybrid 'ransom the open source community' model ...just don't work on my projects, unless your contribution is free.
Re: [RFC] IDE starter kit
On Thursday, 1 February 2018 at 12:21:24 UTC, rjframe wrote: Basically, in the two years or so I've been here, newcomers have consistently had IDE problems. visual-d is perfect if you've got Visual Studio (especially with recent improvements), but otherwise you have to spend a bunch of time getting something set up just to try a language you're not yet sure about. [snip] Thank you for your time, and your thoughts --Ryan [0]: https://forum.dlang.org/post/p4sba9$1bga$1...@digitalmars.com As a typical very lazy & convenient Windows user, even I don't want to discourage you, let me tell you that every developer from the Windows world will have a copy of Visual Studio installed. New Project -> Console Application -> Hit F5. It just works. Set a breakpoint -> Hit F5. It just works. Every other IDE is not worth the experience. Why in the world a lazy and convenient user should be so masochistic to install debuggers, symbol converters or syntax highlighting and intellisense plugins if he can have all of these plus many more out of the box? I you want my opinion regarding what's bad in the *first* Windows experience, here it is: - poor dub support. Ignoring inherent Windows dub problems, convenient Windows users are too lazy to open the ugly cmd window and run some commands; it will be nice to integrate dub in Visual Studio. Right click, resolve dependencies, you know the rest. - default install directory. In corporate environments, creating folders in the root drive is a no-go. - Intel OMF. My BitDefender installation keeps complaining for every 32 bit executable I make despite of zillion samples I sent to them. If you cannot compile even Hello World, why bother? - there is no official GUI library (remember, we are talking about GUI-centric lazy convenient guys here); - not enough samples in VS. At least an updated GUI app and and a Web server app must be available. Just as a proof of concept.
Re: Quora: Why hasn't D started to replace C++?
On Thu, 2018-02-01 at 17:25 +, Benny via Digitalmars-d wrote: > On Thursday, 1 February 2018 at 15:47:50 UTC, Russel Winder wrote: > > For me: > > > > aptitude install ldc > > aptitude install gdc > > aptitude install dmd-bin > > aptitude install dub > > > > Seems to work fine, and no conflicts. > > > > […] > > Please try Windows and then come back ;) Uuurrr… no. Those people who choose to use a system such as Windows, for which no-one is providing packaging, have a responsibility to: a) raise the problems; and b) help fix raised problems. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Quora: Why hasn't D started to replace C++?
On Thu, 2018-02-01 at 08:17 -0800, H. S. Teoh via Digitalmars-d wrote: > On Thu, Feb 01, 2018 at 03:47:50PM +, Russel Winder via > Digitalmars-d wrote: > > […] > > For me: > > > > aptitude install ldc > > aptitude install gdc > > aptitude install dmd-bin > > aptitude install dub > > > > Seems to work fine, and no conflicts. > > [...] > > Only because the OS has a sane packaging system (and some people were > kind enough to package the compilers in nice packages). For > less-privileged OSes, the user experience could be drastically > different. ;-) I see two obvious inferences: a) use a platform with a good packaging system, and good packaging team. b) if you cannot use a such a system, raise the problem and then get involved in fixing it. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: [RFC] IDE starter kit
On Fri, 02 Feb 2018 06:14:03 +, b4s1L3 b. wrote: > Actually nowadays if DMD is already setup, Coedit doesn't require more > configuration. Completion, all DCD features, and D-Scanner warnings just > work out of the box since the tools are distributed with the IDE. In a > way Coedit is already a "starter pack" and since a while. > > I don't know why but in this kind of topics it's never mentioned, > however since version 2 i can find testimonials showing that it works > out of the box: > https://forum.dlang.org/post/tiyuogdlwwoqpckvk...@forum.dlang.org I know that I tend to forget about it. Unless releases are announced on announce, or I use it, I generally don't pay attention. I just checked the IDE page on the wiki, and we have much more than I'd expected.
Re: An idea for commercial support for D
On Friday, 2 February 2018 at 09:26:51 UTC, Iain Buclaw wrote: On 31 January 2018 at 09:43, Joakim via Digitalmars-d wrote: I'm sure you can find much better D devs to contribute such work by posting bounties on the D or ldc bountysource pages: https://www.bountysource.com/teams/d https://www.bountysource.com/teams/ldc-developers I was surprised to see a gdc bounty page. I was even more surprised that the one notable bounty is an issue that's either blocked by Walter, or waiting on someone to implement array op templates in druntume/object.d. :-) Heh, the lead gdc dev doesn't know that gdc bounties exist, not sure I could have made my case for their being hidden any better. :) On Friday, 2 February 2018 at 09:30:08 UTC, Iain Buclaw wrote: I'm reminded of airlines who have a "Priority" or "Privileged" queuing system at the gate. If you didn't want to wait in line to board, then you should have paid up. Not sure if any parallels ring with you here. :-) Any system that requires payment can be superficially compared to any other, but the real salient point here is the discrepancy: to even get on the flight, you have to pay for a ticket, whereas he paid nothing for the open-source sections of a mixed codebase. So, he's more like a guy who shows up at the gate without a ticket _and_ barges into the Priority queue, which is a sure way to get thrown out of the airport altogether. :D And I have no problem with priority queues, baggage fees, etc., as the reason they charge for those is to _lower_ the ticket price for the cheapest consumer, a concept called price discrimination (and before I get the usual nonsense about how that's illegal, or it should be, it isn't and it shouldn't): https://en.m.wikipedia.org/wiki/Price_discrimination So I pay less for my cheap flights, while others who want to lug a ton of suitcases or get through the line faster pay more, which is only fair. On Friday, 2 February 2018 at 09:50:32 UTC, psychoticRabbit wrote: On Friday, 2 February 2018 at 08:56:04 UTC, Joakim wrote: So given that all your claims are easily logically proven to be nonsense, there's no point in going any further. You need to do better than that to convince me ;-) I wasn't trying to convince you. I pointed out that your statements were a mess of logical contradictions and suggested that we stop there. Now.. I might entertain a model of paying someone, *after* they had committed there fix back to the community, as open source (and the fix has been formely approved and confirmed) - but certainly not beforehand. But even that really worries me, as people may then refuse to contribute unless they know they're going to get paid. And, it assumes that people in that open source community project have the means to pay them. What happens to that open source community when the funds are not there?? Do the developers just go off and look for other projects that do have funds, like they were 'bounty' hunters. Is that the future we should be creating? Your so called hybrid model, is like my neighbour borrowing my lawn mower, and while he's got it, he notices it needs an oil change, does the oil change, and then refuses to give me back the lawn mower till I've reimbursed him. But he never paid for the lawn mower did he?? Well.. my neigbour says, if you can't pay me for the oil, then I'll take the new oil out, put the old oil back in, and then you can have your lawn mower back. I don't want neighbours like that. I can't be bothered to strain through your tortured analogies that make no sense and explain to you all the ways you're wrong. I'm respecting you enough to point out that none of your points make any sense, most would just ignore crazy analogies like this and move on, content to let you stew in this nonsense.
Re: [RFC] IDE starter kit
On Friday, 2 February 2018 at 06:14:03 UTC, b4s1L3 b. wrote: On Thursday, 1 February 2018 at 12:21:24 UTC, rjframe wrote: As a followup to [0], I want to take a look at packaging DlangIDE with a DMD compiler and tools, so we have an out-of-the box IDE for people giving D a try. This would be independent of the rest of the system, so moving on (either to Visual Studio, ldc, gdc, or whatever the programmer's preferred IDE/tooling might be) would require re-installing the compiler. Most of this post will be Windows-centric, but if this is popular/useful/ successful I'd also manage macOS and Linux kits. Basically, in the two years or so I've been here, newcomers have consistently had IDE problems. visual-d is perfect if you've got Visual Studio (especially with recent improvements), but otherwise you have to spend a bunch of time getting something set up just to try a language you're not yet sure about. Some sort of learner's or starter's IDE makes sense to me. My hypothetical programmer follows the path: 1) Discovers website. Runs some examples. 2) Plays with the online compiler in the tour. 3) Wants to download a compiler to work with. Wants an IDE, but does not have Visual Studio installed (or maybe doesn't want to install an extension yet). 4) Downloads the starter pack and starts learning. 5) Falls in love and takes the time to set up D with his/her preferred toolset. Actually nowadays if DMD is already setup, Coedit doesn't require more configuration. Completion, all DCD features, and D-Scanner warnings just work out of the box since the tools are distributed with the IDE. In a way Coedit is already a "starter pack" and since a while. I don't know why but in this kind of topics it's never mentioned, however since version 2 i can find testimonials showing that it works out of the box: https://forum.dlang.org/post/tiyuogdlwwoqpckvk...@forum.dlang.org Coedit is also a great alternative of zero configuration IDE for D beginners. I have a 2018 goal to finish my mini book I started last year for complete beginners to computer programming like I was when I started computer programming from scratch through self-directed learning. I recommend Sublime text editor in the introduction but I think one of these IDEs with a click to compile and run button will help me further simplify the instructions for setting up a development environment. The book is about beginning computer programming using D where I try to make the explanations less technical as possible and not overwhelming reader with too much details. Its gets more technical as student learn more stuff. I still have some typos and corrections to do though... You can find it at https://github.com/aberba/learn-coding
Re: How programmers transition between languages
On Thursday, 1 February 2018 at 12:19:48 UTC, Russel Winder wrote: On Tue, 2018-01-30 at 11:55 +, rjframe via Digitalmars-d wrote: On Tue, 30 Jan 2018 10:38:31 +, Russel Winder wrote: […] Are you sure? Every project on my PC places the build files in $PROJECTDIR/.dub/build; the source is in ~/.dub/packages. I see the source of the dependencies both in ~/.dub/packages and in the project .dub directory, but I see the compilation products in ~/.dub/packages. There are every compiled version in obscure named sub- directories and the last compiled (unknown compiler and options) in the dependency directory. Compilation seems to be only of .a and not (.so|.dll). Whether it's .a or .so depends on the dependent package being `staticLibrary` or `dynamicLibrary`. It's possible for a package to be both if it has a configuration for each. Personally I don't even see the point - just link all the .o files. In a traditional build system static libraries might be useful to specify that multiple targets link to this particular binary blob. With dub there's only ever one binary anyway. And at this point in time I think shared libraries are mostly a mistake. The only time I use them is when I have to, as in when developing Python extensions. Atila
Re: An idea for commercial support for D
On Friday, 2 February 2018 at 08:56:04 UTC, Joakim wrote: So given that all your claims are easily logically proven to be nonsense, there's no point in going any further. You need to do better than that to convince me ;-) Now.. I might entertain a model of paying someone, *after* they had committed there fix back to the community, as open source (and the fix has been formely approved and confirmed) - but certainly not beforehand. But even that really worries me, as people may then refuse to contribute unless they know they're going to get paid. And, it assumes that people in that open source community project have the means to pay them. What happens to that open source community when the funds are not there?? Do the developers just go off and look for other projects that do have funds, like they were 'bounty' hunters. Is that the future we should be creating? Your so called hybrid model, is like my neighbour borrowing my lawn mower, and while he's got it, he notices it needs an oil change, does the oil change, and then refuses to give me back the lawn mower till I've reimbursed him. But he never paid for the lawn mower did he?? Well.. my neigbour says, if you can't pay me for the oil, then I'll take the new oil out, put the old oil back in, and then you can have your lawn mower back. I don't want neighbours like that.
Re: Quora: Why hasn't D started to replace C++?
On Friday, 2 February 2018 at 08:39:58 UTC, Paolo Invernizzi wrote: On Friday, 2 February 2018 at 08:21:33 UTC, Martin Tschierschke [...] Maybe there should be a blog post, with some kind of status report every .. weeks or .. month? Telling more about the focus of the D foundation, statistics of downloads, number of fixed bugs, partly similar to Adams week in D but more official. I think the content of such a post may find its way into more mainstream IT magazines, if marked as official d foundation press release even more. The best status report I've met is definitely the FreeBSD quarterly status report: https://www.freebsd.org/news/status/status.html I suggest to take a look at that, as an inspiration and yes, a quarterly report is enough. /Paolo Yes, looks very good!
Re: An idea for commercial support for D
On 2 February 2018 at 09:56, Joakim via Digitalmars-d wrote: > On Friday, 2 February 2018 at 02:04:07 UTC, psychoticRabbit wrote: >> >> On Wednesday, 31 January 2018 at 08:43:46 UTC, Joakim wrote: >>> >>> ... >>> >>> My time-limited model makes sure all source is made open eventually, once >>> the developers have been paid for their work. >>> >> >> This deceptive hybrid model (based I my understanding of it per the >> description above) is really offensive to those of us who understand the >> concept of open-source, and the benefits that flow from it. >> >> You (not you personally - I mean the person implementing such a hybrid >> model) lure people in with free open source, then, when something is found >> to be wrong with it, you make them wait for the fix.. until.. .. .. your >> ransom has been paid. >> >> Utterly offensive (the model that is). >> >> Open source means just that ... Open source - It's turtles all the way >> down. >> >> Ransom-ware is something very different. > > > Except it's none of those things, as you yourself grasp that it's a "hybrid > model," ie not purely open source. So it cannot be deceptive, offensive, or > ransom-ware, since it's perfectly clear that it's its own thing. And that > mixed model is pretty much the way all software is built these days, > including the linux kernel as mentioned earlier in this thread, so you are > clearly using such mixed software too, just by the fact that you posted in > this thread. > > So given that all your claims are easily logically proven to be nonsense, > there's no point in going any further. I'm reminded of airlines who have a "Priority" or "Privileged" queuing system at the gate. If you didn't want to wait in line to board, then you should have paid up. Not sure if any parallels ring with you here. :-)
Re: An idea for commercial support for D
On 31 January 2018 at 09:43, Joakim via Digitalmars-d wrote: > On Tuesday, 30 January 2018 at 19:45:51 UTC, Laeeth Isharc wrote: >> >> On Sunday, 4 January 2015 at 08:31:23 UTC, Joakim wrote: >>> >>> This is an idea I've been kicking around for a while, and given the need >>> for commercial support for D, would perhaps work well here. >>> >>> [...] >> >> >> By the way, in case you are interested in this path personally still, I'd >> be willing to pay for D support, tuition, help with getting stuck, code >> review etc for colleagues. Not for patches that aren't immediately open >> sourced, but we fixed windows paths on DMD for example, and there might be >> scope for occasional paid work on dmd and dub like that. Also porting >> headers. > > > I appreciate the offer, but I'm not looking for paying work on the D > language. I understand the assumption most make that I'm looking to make > money off the D language itself by pushing this commercial model, but I'm > actually not interested in developing language-related software like > compilers, tooling, or the standard library, even if paid for it. I got > stuck porting much of those D tools for Android, but it's a one-time > excursion for me. > > What I'm actually interested in is using D to make commercial Android apps, > and while I think D is a great language already, I think it could be made > better by using this commercial model I've sketched out. And the better D > is, obviously the better any commercial apps I develop with it. > > Back when I first wrote about mixing open and closed source like this in my > 2010 Phoronix article, nobody considered it a world-beating model. Maybe > people now assume I'm just keying these ideas off the success of Android in > using a similar mixed model, but my article was published when Android had > only single-digit market share so I hardly paid attention to it, as it was > only one of a gaggle of mobile OS's competing at the time: > > https://en.m.wikipedia.org/wiki/Android_(operating_system)#Market_share > > While I had heard of a few companies using similar mixed models here and > there, none were that successful back then, so my article was based mostly > on theory. I think the evidence since then has proven that theory > resoundingly accurate, given all the huge projects, such as Android, iOS, > Safari, Chrome, LLVM/clang, using mixed models now. Even Microsoft, who > used to look askance at open source, has gotten in the game, open-sourcing > .NET and several of their other projects. > > In my article, I added another elaboration where even closed-source patches > are eventually open-sourced, which I still believe to be the endgame of how > this market eventually develops, even though AFAIK I'm still the only person > that ever used that time-limited model on an actual project, which is > mentioned in the article's prologue. Such open-sourcing happens in an > ad-hoc manner right now, where a company will develop a proprietary module > for a mixed codebase and then eventually open-source it if they feel like > it: > > http://www.brianmadden.com/opinion/Samsung-contributes-KNOX-to-Android-Open-Source-Project-Is-this-the-end-of-Android-Fragmentation > > My time-limited model makes sure all source is made open eventually, once > the developers have been paid for their work. > > As for the other paid work you mention, I'm actually not a very experienced > D dev, probably about intermediate level. I did take some assembly language > programming classes back in my college days decades ago, so I was able to > figure out the low-level details needed to get D working on Android. > > I'm sure you can find much better D devs to contribute such work by posting > bounties on the D or ldc bountysource pages: > > https://www.bountysource.com/teams/d > https://www.bountysource.com/teams/ldc-developers > I was surprised to see a gdc bounty page. I was even more surprised that the one notable bounty is an issue that's either blocked by Walter, or waiting on someone to implement array op templates in druntume/object.d. :-)
Re: [RFC] IDE starter kit
On 2018-02-01 23:42, rjframe wrote: basically this whole idea is solved by an installer for DlangIDE that includes the DMD installer in case it's needed. Exactly. -- /Jacob Carlborg
Re: An idea for commercial support for D
On Friday, 2 February 2018 at 02:04:07 UTC, psychoticRabbit wrote: On Wednesday, 31 January 2018 at 08:43:46 UTC, Joakim wrote: ... My time-limited model makes sure all source is made open eventually, once the developers have been paid for their work. This deceptive hybrid model (based I my understanding of it per the description above) is really offensive to those of us who understand the concept of open-source, and the benefits that flow from it. You (not you personally - I mean the person implementing such a hybrid model) lure people in with free open source, then, when something is found to be wrong with it, you make them wait for the fix.. until.. .. .. your ransom has been paid. Utterly offensive (the model that is). Open source means just that ... Open source - It's turtles all the way down. Ransom-ware is something very different. Except it's none of those things, as you yourself grasp that it's a "hybrid model," ie not purely open source. So it cannot be deceptive, offensive, or ransom-ware, since it's perfectly clear that it's its own thing. And that mixed model is pretty much the way all software is built these days, including the linux kernel as mentioned earlier in this thread, so you are clearly using such mixed software too, just by the fact that you posted in this thread. So given that all your claims are easily logically proven to be nonsense, there's no point in going any further.
Re: Quora: Why hasn't D started to replace C++?
On Friday, 2 February 2018 at 08:21:33 UTC, Martin Tschierschke wrote: On Thursday, 1 February 2018 at 22:38:36 UTC, Walter Bright wrote: On 2/1/2018 3:11 AM, Martin Tschierschke wrote: Idea: There should be some kind of news ticker for all enhancements and important decisions, maybe at first just via twitter with a special #tag beside #dlang where all updates are announced. And a place on the homepage, where this feed is displayed separately. It's already there on the right side of https://dlang.org/ with a special #tag beside #dlang The focus was on a feed with _two_ tags #dlang and #dfoundation for example. In the feed on the homepage everything is mixed up and I am feeling a lot information about progress - made in the background - is missing. Maybe there should be a blog post, with some kind of status report every .. weeks or .. month? Telling more about the focus of the D foundation, statistics of downloads, number of fixed bugs, partly similar to Adams week in D but more official. I think the content of such a post may find its way into more mainstream IT magazines, if marked as official d foundation press release even more. The best status report I've met is definitely the FreeBSD quarterly status report: https://www.freebsd.org/news/status/status.html I suggest to take a look at that, as an inspiration and yes, a quarterly report is enough. /Paolo
Re: Quora: Why hasn't D started to replace C++?
On Thursday, 1 February 2018 at 22:38:36 UTC, Walter Bright wrote: On 2/1/2018 3:11 AM, Martin Tschierschke wrote: Idea: There should be some kind of news ticker for all enhancements and important decisions, maybe at first just via twitter with a special #tag beside #dlang where all updates are announced. And a place on the homepage, where this feed is displayed separately. It's already there on the right side of https://dlang.org/ with a special #tag beside #dlang The focus was on a feed with _two_ tags #dlang and #dfoundation for example. In the feed on the homepage everything is mixed up and I am feeling a lot information about progress - made in the background - is missing. Maybe there should be a blog post, with some kind of status report every .. weeks or .. month? Telling more about the focus of the D foundation, statistics of downloads, number of fixed bugs, partly similar to Adams week in D but more official. I think the content of such a post may find its way into more mainstream IT magazines, if marked as official d foundation press release even more.
