D needs to get its shit together!
Seriously! D is starting to gain momentum and if things are not stabilized it's going to slow D down. 1 ==>> The VERY FIRST order of business is very simple: When a new user goes to start using D for the first time, D is a PITA to get working! Don't believe me?!?! Just try getting D installed on all 3 major systems for DMD, LDC, GDC, with an IDE, some utilities, possibly arm support(even though it's new and expected to have some issues), etc. The issues really start popping up when you are trying to use x86 + x64. Library issues that result in strange error messages instead of "This compiler is not compatible with the phobos v2.4324". And guess what? This happens to regular users too! They either. A) know how to fix them from fixing them in the past or helping others(so it doesn't count because the problem still exists) or B) have a specific setup that happens to avoid the major issues(e.g., just use linux x86) then act like there isn't any problems with D. But no one wants to work on the part of D that deals with these problems cause it's boring and most "experts" can deal with the problems in a few mins to a few hours... doesn't seem like a huge waste of time(even though it is, since it's a waste). D needs to just work! Library errors, setup problems, IDE integration should just work! It seems the changes of it working are about 75-85%... that IS LOW! It should be 99%. (And I'm talking across the board) DMD, LDC, GDC, Visual D, Coedit(or whatever the other main IDE's are), the utilities(Dustmite, DFormat, etc) should all just work seamlessly and without hassle with each other. What is the main problem? It's very simple: The way the paths are stored and retrieved is ancient and prone to bugs and it seems there is no clear cut way on how to get everything to find everything else. Also, versioning is not always there so even if the paths are right, the files in them may not be! Multiple versions should be able to exist side by side(since D is ever changing and sometimes new versions simply don't work like they should, then downgrading starts causing problems). Solution Ideas: This is a simple problem that needs to be fixed. The installer needs to be updated to act as more of a package manager(a graphical one for us on windows) that has versioning checks and such in it. It doesn't have to be fancy, but should do a bit more work than the current on which is basically more trouble then just compressing the zip and editing sc.ini by hand. 1. A unified path/directory layout that is unambiguous and every D app can rely on. e.g., \Dlang\Compilers\DMD\v2\73.01 (the v2 stuff hence forth replaced with \Dlang\Compilers\DMD\v2\main <- a junction/link to the current version, usually the latest \Dlang\Compilers\DMD\Lib\Phobos\x86\coff\ \Dlang\Compilers\DMD\Lib\Phobos\x86\omf\ \Dlang\Compilers\DMD\Lib\Phobos\x64\coff \Dlang\Compilers\DMD\Lib\Phobos\x64\omf (even though it doesn't exist, just empty, maybe a text file in it stating that it is not used for x64) \DLang\Source\DMD\v... \DLang\Docs\v... \DLang\IDEs\VisualD\v... \DLang\Utilities\DFormat\v... \DLang\Utilities\DustMite\v... \DLang\Packages\Derelict\v... and so fourth. I'm not saying it has to be exactly like the one above, but the above is unambiguous. One could change compiler versions, even have a "master" compiler that simply chooses dmd, ldc, gdc, etc and could verify versions if necessary, etc. Everything gets organized and has a place that is logical and hence easy to find, easy to use, and helps in diagnosing problems. Versioning and dependencies could be charted. (e.g., a change in one version of something doesn't necessarily break it's usage with everything else that hasn't been updated, so we can have a table of things that work with each other based on versions. We can change, say, the version of DMD to use and the front end can consult the master version table to see what utilities that work with it and then update all the hard links. External usages(like windows dlls, link.exe) are all handled. They are a) copied from their windows locations. b) noted the location they are copied from by adding a text file in the directory, etc) (and the installer\manager can refresh everything) One can install on demand any aspect so everything isn't created at once. As time evolves, this system of organization gets cleaner, clearer, and more optimal rather than the current system which seems to just be stagnant and relatively broke. It works, for the most part, but as time goes on it doesn't get any better at it's job. It's usually the same problems over and over and that is why you always get a steady stream of users having issues with D due to problems that are easily fixable with a little elbow grease and thought and a significant amount of desire to get the problem fixed[breath!]. Versioning gets better and better. If D1 had this type of system, we could
Re: D needs to get its shit together!
On 2017-06-16 05:53, Mike B Johnson wrote: Seriously! D is starting to gain momentum and if things are not stabilized it's going to slow D down. 1 ==>> The VERY FIRST order of business is very simple: When a new user goes to start using D for the first time, D is a PITA to get working! Don't believe me?!?! Just try getting D installed on all 3 major systems for DMD, LDC, GDC, with an IDE, some utilities, possibly arm support(even though it's new and expected to have some issues), etc. The issues really start popping up when you are trying to use x86 + x64. Library issues that result in strange error messages instead of "This compiler is not compatible with the phobos v2.4324". And guess what? This happens to regular users too! They either. A) know how to fix them from fixing them in the past or helping others(so it doesn't count because the problem still exists) or B) have a specific setup that happens to avoid the major issues(e.g., just use linux x86) then act like there isn't any problems with D. But no one wants to work on the part of D that deals with these problems cause it's boring and most "experts" can deal with the problems in a few mins to a few hours... doesn't seem like a huge waste of time(even though it is, since it's a waste). D needs to just work! Library errors, setup problems, IDE integration should just work! It seems the changes of it working are about 75-85%... that IS LOW! It should be 99%. (And I'm talking across the board) DMD, LDC, GDC, Visual D, Coedit(or whatever the other main IDE's are), the utilities(Dustmite, DFormat, etc) should all just work seamlessly and without hassle with each other. What is the main problem? It's very simple: The way the paths are stored and retrieved is ancient and prone to bugs and it seems there is no clear cut way on how to get everything to find everything else. Also, versioning is not always there so even if the paths are right, the files in them may not be! Multiple versions should be able to exist side by side(since D is ever changing and sometimes new versions simply don't work like they should, then downgrading starts causing problems). Solution Ideas: This is a simple problem that needs to be fixed. The installer needs to be updated to act as more of a package manager(a graphical one for us on windows) that has versioning checks and such in it. It doesn't have to be fancy, but should do a bit more work than the current on which is basically more trouble then just compressing the zip and editing sc.ini by hand. 1. A unified path/directory layout that is unambiguous and every D app can rely on. e.g., \Dlang\Compilers\DMD\v2\73.01 (the v2 stuff hence forth replaced with \Dlang\Compilers\DMD\v2\main <- a junction/link to the current version, usually the latest DVM [1] is doing some of this. [1] https://github.com/jacob-carlborg/dvm -- /Jacob Carlborg
Re: D needs to get its shit together!
DVM [1] is doing some of this. Cool, does it keep things well organized and deals with windows issues(link.exe., dlls, etc) or just uses the "D way" which is a hairball?
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 06:58:57 UTC, Jacob Carlborg wrote: DVM [1] is doing some of this. [1] https://github.com/jacob-carlborg/dvm Might it not be better when some of this is actually part of D? - Multi-version support - Integrated all the tools so editors know/can rely on them. I have seen this topic a few times reading here. - Editor support like half working in a lot of cases - ... There are always tools out there to "fix" some issues with D but Mike does have a point in stating that everything feels fragmented. /++ DMD / LDC are totally different installations. LDC requiring different setup. LDC is frankly the default if you need real performance but the way its developed / published / talked about, its a side project not a main part of D. And because of that LDC feels like it always needs to cache-up to D mainline. Ifs ironic that i needed to use: dub --compiler=C:\D2\bin\ldc2.exe To get ldc to work... If i take a look at Rust ... RustUp great installer, multi platform support, great cross compiling support ( still some issue with dependencies ). Go has the same great cross platform compile support. But D it feels like a struggle to figure out. Why not publishing Dmd and LDC together as one package, one installation, one version. /++ Why is dcd, dfmt, dscanner, not part of the base installation of D??? Webfreak wrote workspace-d and is now writing serve-d to combine code-d and the rest. But its again a side project. Its odd there is no default language server protocol for D and it needs a 3th party developer to implement it and then maintain it outside of D again. So if webfreak gets too busy with life, a breaking change happens in D, there goes the support. Like with many 3th party plugins ... How about file watching, i know there is a D plugin that monitors your directory and allows for recompiling ( most languages have a feature like this ) but again, its 3th party not part of D mainline, despite it being darn handy. D is indeed way too fragmented. Clearly a lot of good developers but the way its handled, it feels like DMD and Phobos are the only focus. And all the rest is side or not integrated. This is just my feeling. And when resources are split like this, it is indeed much more difficult for new users to get going.
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 10:12:06 UTC, Wulfklaue wrote: On Friday, 16 June 2017 at 06:58:57 UTC, Jacob Carlborg wrote: DVM [1] is doing some of this. [1] https://github.com/jacob-carlborg/dvm Might it not be better when some of this is actually part of D? There is an official D installer for Posix systems that can handle multiple compilers and all versions quite well. IIRC does dvm only support DMD? - Multi-version support - Integrated all the tools so editors know/can rely on them. I have seen this topic a few times reading here. I think you are just complaining about Windows. Everything is nicely packaged under Linux, Posix and OSX. - Editor support like half working in a lot of cases The beauty of D is that you don't need a fancy editor. - ... There are always tools out there to "fix" some issues with D but Mike does have a point in stating that everything feels fragmented. /++ DMD / LDC are totally different installations. LDC requiring different setup. Really? curl i.dlang.io | bash -s dmd curl i.dlang.io | bash -s dmd-2.072.2 curl i.dlang.io | bash -s dmd-newCTFE curl i.dlang.io | bash -s dmd-nightly curl i.dlang.io | bash -s ldc curl i.dlang.io | bash -s ldc-beta curl i.dlang.io | bash -s ldc-1.1.0 curl i.dlang.io | bash -s gdc LDC is frankly the default if you need real performance but the way its developed / published / talked about, its a side project not a main part of D. And because of that LDC feels like it always needs to cache-up to D mainline. Are there any features between 2.073.2 (latest LDC beta) and 2.074.1 that you actually miss? Ifs ironic that i needed to use: dub --compiler=C:\D2\bin\ldc2.exe To get ldc to work... --compiler=ldc2 works very well for me. If i take a look at Rust ... RustUp great installer, multi platform support, great cross compiling support ( still some issue with dependencies ). Go has the same great cross platform compile support. But D it feels like a struggle to figure out. Why not publishing Dmd and LDC together as one package, one installation, one version. Because the top contributors to DMD are unfamiliar with the LDC codebase. However, there are ongoing efforts to make the frontend accessible as a library. /++ Why is dcd, dfmt, dscanner, not part of the base installation of D??? Because there is a very easy way to fetch & build them since DUB is part of the release: dub fetch dscanner dub build dscanner There is even a DUB API that tools can use. Too complicated? Webfreak wrote workspace-d and is now writing serve-d to combine code-d and the rest. But its again a side project. Its odd there is no default language server protocol for D and it needs a 3th party developer to implement it and then maintain it outside of D again. So if webfreak gets too busy with life, a breaking change happens in D, there goes the support. Like with many 3th party plugins ... Don't forget that D is an open source project driven by volunteers. How about file watching, i know there is a D plugin that monitors your directory and allows for recompiling ( most languages have a feature like this ) but again, its 3th party not part of D mainline, despite it being darn handy. Because there's only so much that can be in a standard library. It's way to thick imho anyways. What's wrong with using a DUB package? If it is that common to your work, you can add the project to you D include directory. D is indeed way too fragmented. Clearly a lot of good developers but the way its handled, it feels like DMD and Phobos are the only focus. And all the rest is side or not integrated. This is just my feeling. And when resources are split like this, it is indeed much more difficult for new users to get going. Yes because tools come and go whereas a standard library or a package manager stays. With the limited volunteers time there's only so much that can be done. And in your free time, you usually work on problems that are interesting to you?
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote: Seriously! D is starting to gain momentum and if things are not stabilized it's going to slow D down. [...] I don't know what is so hard about tar -zxvf dmd.XYZ.tar.xz or unzip dmd.XYZ.zip. Am I missing something? Perhaps rather than developing a wall of text maybe you could spend the time and energy learning how to compile and link code using an actual compiler instead of an IDE framework. You would then have the skills to use D anywhere with/without the flavour of the month IDE. bye, lobo
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote: When a new user goes to start using D for the first time, D is a PITA to get working! Don't believe me?!?! Just try getting D installed on all 3 major systems for DMD, LDC, GDC, with an IDE, some utilities, possibly arm support(even though it's new and expected to have some issues), etc. The issues really start popping up when you are trying to use x86 + x64. Library issues that result in strange error messages instead of "This compiler is not compatible with the phobos v2.4324". And guess what? This happens to regular users too! They either. A) know how to fix them from fixing them in the past or helping others(so it doesn't count because the problem still exists) or B) have a specific setup that happens to avoid the major issues(e.g., just use linux x86) then act like there isn't any problems with D. But no one wants to work on the part of D that deals with these problems cause it's boring and most "experts" can deal with the problems in a few mins to a few hours... doesn't seem like a huge waste of time(even though it is, since it's a waste). I'm going to summarize this as "D has issues that aren't likely to be worked on any time soon by the core team". It boils down the following (and I write this every time I see this gets posted): People working on (and with) D for free are already invested in things they are interested in. Your choices are - Invest time to work on these yourself (-> directly leads to results) - Pay someone to work on these (-> should directly lead to results unless you get swindled) - Write about it here (-> raise awareness, may lead to results, but unlikely) While I can understand your frustration (and share it for a couple of issues) and raising awareness for issues is a good thing, the third of these options is (historically speaking) unlikely to yield results by itself in this community as people's time is limited. If you want these issues dealt with, go with option one or two. D needs to just work! Library errors, setup problems, IDE integration should just work! It seems the changes of it working are about 75-85%... that IS LOW! It should be 99%. (And I'm talking across the board) Everything *I* need works well enough (and I'm fairly convinced it is the same for the majority of D users, though that is speculation). If you want something fixed, do it yourself or pay someone to do it.
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 10:38:44 UTC, Seb wrote: There is an official D installer for Posix systems that can handle multiple compilers and all versions quite well. IIRC does dvm only support DMD? Good for the poxis platform set ... but D is used on more then only linux and osx. I think you are just complaining about Windows. Everything is nicely packaged under Linux, Posix and OSX. And that makes the point wrong? No it does not ... The beauty of D is that you don't need a fancy editor. That is a straw man argument... Every language can be more productive with a editor, especially when people first learn the language. Lets not turn this into a editor/ide vs ... discussion. You got your preference, that is clear by now. Really? curl i.dlang.io | bash -s dmd curl i.dlang.io | bash -s dmd-2.072.2 curl i.dlang.io | bash -s dmd-newCTFE curl i.dlang.io | bash -s dmd-nightly curl i.dlang.io | bash -s ldc curl i.dlang.io | bash -s ldc-beta curl i.dlang.io | bash -s ldc-1.1.0 curl i.dlang.io | bash -s gdc Thanks but again besides the point. The Original poster is referring to the experience for new users. Do you expect every user to know Linux commands? Do you expect them to run Linux? The fact that your over emphasizing on this, clearly shows that there is a gap in D there multi-platform support. Thanks for the information. Its useful for me but that is NOT THE POINT! Are there any features between 2.073.2 (latest LDC beta) and 2.074.1 that you actually miss? Up to recently Dmd and Ldc used to be much more separated in there future set. And please do tell ... having 2.073.2 vs 2.074.1 version difference may not be a lot but its still not a single platform support. Bugs or issues solved in DMD 2.074.1 can hamper somebody who is cross compiling for production. And visa versa. Is it that difficult to have both versions synchronized and released as one package? Why the push back to even mentioning this. --compiler=ldc2 works very well for me. Nice to know, yet, that did not work in my case and it needed the path. Because the top contributors to DMD are unfamiliar with the LDC codebase. However, there are ongoing efforts to make the frontend accessible as a library. Good to know... Because there is a very easy way to fetch & build them since DUB is part of the release: dub fetch dscanner dub build dscanner Again, this is straw man argumentation. This assumes knowledge of dub, knowledge of the tools used, it assume the editor can interact and find the builds. And frankly, running it like that also pollutes a project ( seen it, done it, got the medal ). Read the freaking original poster his text. He is frustrated that for new users, maybe people with little to no background D is simply a mess. I pointed out that Rust and Go are WAY more easy to setup everything and interact with advanced features because they integrated a lot more. And on a side note: There is nothing more fun as running into a bug with dfmt or some other third party plugin because a change that happened in dmd. Example: latest DMD, a change happened, plugin does not compile. Now please do tell how a totally new user will find his way around? They will post here, get some crispy comment and maybe leave. Or hell, they may not even post here. Don't forget that D is an open source project driven by volunteers. So do you and every other person remind the people who point out issues. And the point is? Well, its all volunteer project so never expect a improvement until somebody wants to fix it. Strange because Rust is highly volunteer based and yet they have a more coherent structure. So why is that? Now that is a good question... Because there's only so much that can be in a standard library. It's way to thick imho anyways. What's wrong with using a DUB package? What i am talking about is not part of the standard library, hell, it has nothing to do with the library at all. Its part of the standard tool set. Total different things... If it is that common to your work, you can add the project to you D include directory. Again ... very, VERY unclear how and what is possible in D. Sure, i can figure it things out but it takes time. And the next guy also needs to put time into this. And the next guy... Yes because tools come and go whereas a standard library or a package manager stays. With the limited volunteers time there's only so much that can be done. And in your free time, you usually work on problems that are interesting to you? Maybe that is the same reason why D has a issue drawing in new non-C/C++ developers? Maybe because too many people live in there high tower assuming its easy for everybody else. And no offense but some responses here feel like: "Hey somebody pointed out a problem. Lets jump on this person for pointing it out". I am already seeing the arguments that D is all about volunteers and the push back. "Hey,
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 11:50:20 UTC, Wulfklaue wrote: On Friday, 16 June 2017 at 10:55:04 UTC, Moritz Maxeiner wrote: Everything *I* need works well enough (and I'm fairly convinced it is the same for the majority of D users, though that is speculation). If you want something fixed, do it yourself or pay someone to do it. Well, i do not have the time. Then hire someone. Want me to donate? Straw man. Donations are not the same as paying for a specific service (i.e. no contractual obligations). Does that solve the issue. Yes. No ... because there is no clear infrastructure in place to actually hire people to work on the language and the environment. Claiming a solution does not work because it's hard to use does not help your cause. If you are interested in donations, there is such infrastructure, it's called the D Foundation. If you are interested in contract work, you are correct, there is no such infrastructure; however, there not being a ready made infrastructure for hiring does not preclude you from finding someone yourself, e.g. through the accounce newsgroup. Pointless to even mention this, it like all the other discussions like this. People mention issue. Blow back. Heated discussions. And the people who complain give up. Those that point fingers continue living in there bubble and ... nothing changes or improves. You are deliberately inflaming a previously neutral subthread with hyperboles and a personal attack. The matter remains simple: If you (or anyone else) has an issue, it's good (as I stated) to raise awareness for it; but if you want something done and don't want (or can't) do it yourself, you have to either convince someone else that your time is worth more than theirs, or you have to pay someone to deal with it. I do not have a issue donating money. In the process of setting up a company and maybe can support D from that angle. But i do have a issue when people react like this whenever people with good intention get blow back. Again, you are deliberately using inflammatory speech against someone who has given the OP a rational response as to why I think doing *only* this won't help his cause. The original poster his topic title is a bad choice but his points are not. Straw man. I never said anything on those points. Just reading the history on the mail group and you see so many time the same issues. In the very post of mine you quote I write about stating this every time these kinds of issues pop up (which strongly implies that it does so not rarely). And the exact same responses. I'm not sure why that bothers you. It would be strange to me for the same kind of issue in the same context to receive a different response. And the exact same nothing happening because people give up. That is the crux of having limited human resources in a volunteer project. [...] But for some reason i can not help to feel that some people are almost against this, the attitude here simply STINKS when it comes down to issues. The whole "it works for me, so how dare you complain" is really demotivating and frankly scares people away. This is the third time you are being intentionally inflammatory in a previously neutral correspondence, even utterly twisting my post into something that simply is not there. What I wrote boils down to "It works for me, so don't expect me to fix it for you for free. I think it is the same for most others here". If that is demotivating to you, I am forced to wonder if you consider your time objectively worth more than that of others. Hey, it works for me "not dumb dumb" but its the wast of time figuring out things that are much more easy in other languages. Fourth time you are being inflammatory, even going as far as completely inventing statements I have not made. But that also means anybody coming with limited programming knowledge or no linux knowledge and wants to do more then a "hello world", will run into the exact time wasting issues. And if that bothers you enough to take action, your courses are *still* the following: - Do the work yourself - Hire someone to do the work - Convince someone that their time is better spend on dealing with this than on whatever it is that interests them But please, do shoot the messengers. Like that will help. Fifth time you are being intentionally inflammatory and trying to twist my post. I informed the OP that I think it unlikely this will convince someone to choose to spend their free time on this, than on something else. It boggles my mind how you could possibly twist that into "shooting the messengers". I am already far into my project with D but at the same time i can not help getting this nagging feeling that D has major issues beyond its base language. Mostly its community and structure. I see less of this with for instance Rust despite being a WAY younger language and audience. Its almost like D is stuck in
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote: Seriously! D is starting to gain momentum and if things are not stabilized it's going to slow D down. [...] All decent ideas- except for the bit about D1, as it has been deprecated- but obviously nobody has been willing to work on adding such fit and finish. If you believe someone should volunteer their time to work on this, the obvious question is why don't you do it? If you think there is a market for paid support that includes such polish, you could charge for it. On the other hand, maybe D is not meant for the kind of user who needs such an easy path. What does it matter if you set D up really easily and then can't grasp such a sprawling, lower-level language? Perhaps _this_ is the right packaging for D right now, to keep away the kinds of casual users who would not be suited for D. I don't have a strong opinion on that, just making an observation. It works well for me, and having a long history of using OSS projects that are _much_ worse to set up, I can't complain. :)
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 13:14:46 UTC, Moritz Maxeiner wrote: Fifth time you are being intentionally inflammatory and trying to twist my post. Well, i am sorry that you see it all as intentionally inflammatory. You might have noticed that after responding to you, my post was more general. Not person specific. My apology to you for the misunderstanding. I will not post about this anymore. No point wasting anybody there time. Its not like anything is going to change anyway, that much is now clear to me.
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 11:50:20 UTC, Wulfklaue wrote: I am already far into my project with D but at the same time i can not help getting this nagging feeling that D has major issues beyond its base language. Mostly its community and structure. I see less of this with for instance Rust despite being a WAY younger language and audience. Its almost like D is stuck in the past, in some kind of pre-2000 C++ attitude. Like i said, maybe its me. D as a base language works but for such a old language ( lets be honest about that ), its a real struggle on the other areas beyond the language. We don't notice the rivers carving the canyons in our brief lifespans, so would never know that it happened without some point of reference in the past to compare to. While D's progress doesn't move at such a glacial pace (thankfully!), it still won't be very noticeable to someone who hasn't been around here long enough. If you could move your point of reference back in time a bit, you'd know that a great deal of progress has been made. That doesn't mean that such complaints aren't valid and shouldn't be raised, but it's nice to have some perspective to moderate your expectations. Progress *is* being made. The volunteer argument keeps coming up because that *is* the reality. There's no one around here who can snap their fingers and get a team of people to put their heads down and make improvements on a daily basis. Rust and Go, however, do have that benefit. So we move forward, bit-by-bit, slowly but surely. I've been using D and coming to these forums since 2003 (and, by the way, using DMD on Windows without a hitch for all that time) and I can point to many periods in the intervening years when we passed major milestones. There used to be no IDE plugins at all. No installers. DMD was distributed in a single zip for all platforms. We had no build tools, no DUB, no web frameworks, a substandard standard library, a clunky web interface for the newsgroups... So please, don't take your snapshot view of the current state of affairs and take that as evidence that the rivers aren't carving the canyons, because they very much are.
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 13:30:21 UTC, Joakim wrote: On the other hand, maybe D is not meant for the kind of user who needs such an easy path. What does it matter if you set D up really easily and then can't grasp such a sprawling, lower-level language? Perhaps _this_ is the right packaging for D right now, to keep away the kinds of casual users who would not be suited for D. Today I agree with that, but in 1-2 years when mir/lubeck are in better shape I'm probably going to disagree. Hoping someone packages something together like an Anaconda for D that just easily works.
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 13:54:54 UTC, Wulfklaue wrote: On Friday, 16 June 2017 at 13:14:46 UTC, Moritz Maxeiner wrote: Fifth time you are being intentionally inflammatory and trying to twist my post. Well, i am sorry that you see it all as intentionally inflammatory. Only those specific instances where you used expressions designed to elicit an emotional response. You might have noticed that after responding to you, my post was more general. Not person specific. My apology to you for the misunderstanding. The trouble is that you replied to two different people in the same post (this is btw not very well supported by newsgroups, for which the forum is a frontend) and even after becoming more general kept referring to points I made in my post. I will not post about this anymore. That is your choice, though I fail to see why you think you shouldn't. I think you should keep reporting such issues in the ecosystem, since without that there is indeed no way they are ever going to be dealt with. It's just that reporting in and of itself does not guarantee a fix with our current human resources. If you want such a guarantee, it's on you to convince someone (be that yourself or someone else) to do it. No point wasting anybody there time. Its not like anything is going to change anyway, that much is now clear to me. It shouldn't, because it's not the case. The ecosystem is being worked on, albeit slowly. No progress != slow progress.
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote: D needs to just work! I think that D is quickly gaining increasingly picky and demanding users because it's breaking out in the general programmer population. Not all of these programmers have used C++ and perhaps have higher expectations when it comes to "just work". If you look at the complaints from 8 years ago (where ragequitting D was more common), everyone of their points have be adressed, and most things have improved. Perhaps complaints are poised to get higher in intensity precisely because things have become better ;)
Re: D needs to get its shit together!
On Fri, 2017-06-16 at 15:08 +, Guillaume Piolat via Digitalmars-d wrote: > On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote: > > D needs to just work! > > > I think that D is quickly gaining increasingly picky and > demanding users because it's breaking out in the general > programmer population. > > Not all of these programmers have used C++ and perhaps have > higher expectations when it comes to "just work". > > If you look at the complaints from 8 years ago (where > ragequitting D was more common), everyone of their points have be > adressed, and most things have improved. > > Perhaps complaints are poised to get higher in intensity > precisely because things have become better ;) > The corollary is that The D Foundation has to make sure the D experience (DMD, RDMD, LDC, LDMD, GDC, GDMD, Dub, etc.) works out of the box, either with a downloader or a Chocolatey package on Windows; downloader, MacPorts and Homebrew on MacOS, and packaging for Debian, Fedora, Arch, OpenBSD, FreeBSD, etc. Most of it is there, but it isn't as slick an experience as say Rust and Go. It about being a good and proactive downstream for all the packaging systems (which is mostly there) and having good installers where needed, mostly there. I suspect a big part of the difficulty is resources, but it is also having three tool chains. Clearly Rust and Go have people paid (directly or indirectly) to deal with front of house, customer facing stuff. D has some volunteers most of whom are back office, just want to get on with code please type people. If it is true that there is increased traction for D, then getting some resource into the front of house stuff will be critical to that traction fading and disappearing. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 15:47:15 UTC, Russel Winder wrote: If it is true that there is increased traction for D, then getting some resource into the front of house stuff will be critical to that traction fading and disappearing. Yes, daily downloads of dmd are up 25-30% this year: http://erdani.com/d/downloads.daily.png
Re: D needs to get its shit together!
On Fri, 2017-06-16 at 16:47 +0100, Russel Winder wrote: > […] > If it is true that there is increased traction for D, then getting > some > resource into the front of house stuff will be critical to that > traction fading and disappearing. s/to that/to avoid that/ -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D needs to get its shit together!
On 2017-06-16 09:53, Mike B Johnson wrote: DVM [1] is doing some of this. Cool, does it keep things well organized It depends on what you definition of organized. DVM is a tool that allows you to easily install D compilers. It also allows to easily switch between multiple versions of the compiler. That is, you can have one window (terminal) with one version and another window with another version. On Posix it installs everything ~/.dvm. Each compiler is placed in its own directory, it's mostly the zip archives available on dlang.org unpacked. Here's an example of how the directory structure looks like on Posix: $ tree -L 2 .dvm .dvm ├── archives │ ├── dmd.2.073.0.osx.zip │ ├── dmd.2.074.0-b1.osx.zip │ └── dmd.2.074.0.osx.zip ├── bin │ ├── dmd-2.073.0 │ ├── dmd-2.074.0 │ ├── dmd-2.074.0-b1 │ ├── dvm │ ├── dvm-current-dc │ ├── dvm-default-dc ├── compilers │ ├── dmd-2.073.0 │ ├── dmd-2.074.0 │ ├── dmd-2.074.0-b1 ├── env │ ├── default │ ├── dmd-2.073.0 │ ├── dmd-2.074.0 │ ├── dmd-2.074.0-b1 └── scripts └── dvm and deals with windows issues(link.exe., dlls, etc) or just uses the "D way" which is a hairball? I'm not that familiar with Windows (the Windows support was contributed by another developer) so I'm not sure which issues you refer to. -- /Jacob Carlborg
Re: D needs to get its shit together!
On 2017-06-16 17:47, Russel Winder via Digitalmars-d wrote: Most of it is there, but it isn't as slick an experience as say Rust and Go. It about being a good and proactive downstream for all the packaging systems (which is mostly there) and having good installers where needed, mostly there. I suspect a big part of the difficulty is resources, but it is also having three tool chains. Clearly Rust and Go have people paid (directly or indirectly) to deal with front of house, customer facing stuff. D has some volunteers most of whom are back office, just want to get on with code please type people. Also, IIRC, Go uses its own tool chain, i.e. not relying on system compiler and linker. This can help as well since you have more control over the tool chain. -- /Jacob Carlborg
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 17:10:41 UTC, Jacob Carlborg wrote: On 2017-06-16 09:53, Mike B Johnson wrote: DVM [1] is doing some of this. Cool, does it keep things well organized It depends on what you definition of organized. DVM is a tool that allows you to easily install D compilers. It also allows to easily switch between multiple versions of the compiler. That is, you can have one window (terminal) with one version and another window with another version. On Posix it installs everything ~/.dvm. Each compiler is placed in its own directory, it's mostly the zip archives available on dlang.org unpacked. Here's an example of how the directory structure looks like on Posix: $ tree -L 2 .dvm .dvm ├── archives │ ├── dmd.2.073.0.osx.zip │ ├── dmd.2.074.0-b1.osx.zip │ └── dmd.2.074.0.osx.zip ├── bin │ ├── dmd-2.073.0 │ ├── dmd-2.074.0 │ ├── dmd-2.074.0-b1 │ ├── dvm │ ├── dvm-current-dc │ ├── dvm-default-dc ├── compilers │ ├── dmd-2.073.0 │ ├── dmd-2.074.0 │ ├── dmd-2.074.0-b1 ├── env │ ├── default │ ├── dmd-2.073.0 │ ├── dmd-2.074.0 │ ├── dmd-2.074.0-b1 └── scripts └── dvm and deals with windows issues(link.exe., dlls, etc) or just uses the "D way" which is a hairball? I'm not that familiar with Windows (the Windows support was contributed by another developer) so I'm not sure which issues you refer to. Thanks. At least D has something going on correctly here. My feeling is, unless DVM works well with windows, that it probably currently doesn't offer much help. If it does manage the versioning well and can deal with the environmental issues well then it is close to what I am asking. If that's the case, it should be polished off and used as the main front end and hosted by D. You didn't state if it works congruently with all the major compilers. The issues in windows are: 1. coff/omf. Requires use of windows and visual studio/C stuff who's locations and versions change over the years. This can be a major headache finding the right version. Mainly because the error messages, when using the wrong version, do not suggest that it is a versioning error. dvm could have the option to search the entire system for the files it needs(e.g., link.exe, various dlls that are generally used, etc) and attempt get things to work. 2. Managing different compilers: Not too bad but if you end up with some problems here, then it gets multiplied by the factor of the number of issues with each compiler. if LDC has an issue with the x64 dlls and dmd with the x32 and they are always looking in the same place because the versions are different and wrong, then it becomes a issue with a "factor of 4" problem. This can become even worse when you try cross compiling and such. 3. Re-installation can be problematic. sci.ini is overwritten. If you hand coded the paths to get everything to work, guess what? Well, who cares? You have plenty of time to waste, right? 4. Reinstalling one thing can break something else. This depends on how fragile the setup was at the start. 5. People that don't have problems with their setup generally think everything "just works" and bitch at others for complaining. Ignorance is bliss, but it's still ignorance. Life is more complicated and everything just doesn't work for everyone because everyone system is different. I don't use standard paths to install things and when an installer hard codes paths that don't exist, it breaks on my system. That is not my fault. The installer shouldn't be so ignorant and do it's job properly. Usually it was written by someone who thinks that when other people have problems on their system, it is due to their ignorance rather than the ignorance of the installer writer(Because they think: Hey, it worked on my system and my system is the same as everyone elses). Same goes for utilities. I have over 1 billion files on my system, I use it for around 20 different non-complementary subjects(graphics, music, programming, etc). When everything is "competing for space" and things are not set up to work together, one seemingly unrelated program and effect every other one. (e.g., simply by adding to the path variable and break things with error messages that are meaningless to the real problem) Most ignorant people do not take those things in to account because they oversimplify... and that usually causes problems down the road for the rest of us. As D becomes increasing popular, there are going to be more variation in the system and the flaws in it will become larger and larger. It's best to start working on fixing those flaws before they become too large to manage and weaken the whole structure. We all know this to be true on some level, but it is actually fact. It is the way of life, everything breaks down. The more flaws it has at the start, the faster it will break down... unless they are fixed at the start. Fixing them near the end just results in a huge
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote: When a new user goes to start using D for the first time, D is a PITA to get working! Don't believe me?!?! I'm running Debian GNU/Linux (testing). Here's the installation process for the 3 major D compilers. $ apt install gdc $ gdc my_first_program.d GDC is too old for you? Fine, let's use ldc: $ apt install ldc $ ldc2 my_first_program.d Or if you want the bleeding edge version of D: (download dmd .deb package from dlang.org) $ dpkg -i dmd_***.deb $ rdmd my_first_program.d Debian maintainers, one word: Thank you!
Re: D needs to get its shit together!
On Sat, 2017-06-17 at 08:27 +, Sebastien Alaiwan via Digitalmars-d wrote: > On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote: > > When a new user goes to start using D for the first time, D is > > a PITA to get working! Don't believe me?!?! > > I'm running Debian GNU/Linux (testing). Here's the installation > process for the 3 major D compilers. > > $ apt install gdc > $ gdc my_first_program.d Or use aptitude, which I believe remains the Debian preferred high- level tool. > GDC is too old for you? Fine, let's use ldc: > > $ apt install ldc > $ ldc2 my_first_program.d Definitely, caveat aptitude. > Or if you want the bleeding edge version of D: > > (download dmd .deb package from dlang.org) > $ dpkg -i dmd_***.deb > $ rdmd my_first_program.d I wonder if it is better to use the d-apt repository for DMD rather than downloading. Downloading is always a pain for updating packages. http://d-apt.sourceforge.net/ OK so it is on SourceForge, but it does work. > Debian maintainers, one word: Thank you! That's two words. :-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D needs to get its shit together!
On Saturday, 17 June 2017 at 08:27:33 UTC, Sebastien Alaiwan wrote: On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote: When a new user goes to start using D for the first time, D is a PITA to get working! Don't believe me?!?! I'm running Debian GNU/Linux (testing). Here's the installation process for the 3 major D compilers. $ apt install gdc $ gdc my_first_program.d GDC is too old for you? Fine, let's use ldc: $ apt install ldc $ ldc2 my_first_program.d Or if you want the bleeding edge version of D: (download dmd .deb package from dlang.org) $ dpkg -i dmd_***.deb $ rdmd my_first_program.d Debian maintainers, one word: Thank you! Sorry, doesn't help me or people in general. Also, simple examples are not proof that the solutions are general. It may be that easy on linux or it may not be, but it's definitely not that case on windows FOR almost ALL installations.
Re: D needs to get its shit together!
On 2017-06-17 08:06, Mike B Johnson wrote: Thanks. At least D has something going on correctly here. My feeling is, unless DVM works well with windows, that it probably currently doesn't offer much help. If it does manage the versioning well and can deal with the environmental issues well then it is close to what I am asking. If that's the case, it should be polished off and used as the main front end and hosted by D. You didn't state if it works congruently with all the major compilers. No, unfortunately it only allows to install DMD. The issues in windows are: 1. coff/omf. Requires use of windows and visual studio/C stuff who's locations and versions change over the years. This can be a major headache finding the right version. Mainly because the error messages, when using the wrong version, do not suggest that it is a versioning error. dvm could have the option to search the entire system for the files it needs(e.g., link.exe, various dlls that are generally used, etc) and attempt get things to work. No, DVM doesn't do anything to try to find the installation of Visual Studio. Unless the compiler already can find it, it won't help. DVM was created before the compiler supported Visual Studio and I haven't kept the tool up to date to match that. 3. Re-installation can be problematic. sci.ini is overwritten. If you hand coded the paths to get everything to work, guess what? Well, who cares? You have plenty of time to waste, right? That's a difficult problem. What if you messed up sc.ini and that's the reason you want to reinstall? -- /Jacob Carlborg
Re: D needs to get its shit together!
On Saturday, 17 June 2017 at 06:06:53 UTC, Mike B Johnson wrote: 1. coff/omf. Requires use of windows and visual studio/C stuff who's locations and versions change over the years. This can be a major headache finding the right version. Mainly because the error messages, when using the wrong version, do not suggest that it is a versioning error. This isn't as severe as you make it sound. If the latest version of VS doesn't work, the one before will. It's easy to prevent such issues in the future. Since we never know if a new version of VS will break things, this can be solved by one person who can monitor the beta releases of VS and submit PRs to the appropriate repositories if the paths change, or (as happened with VS 2015) the C runtime library changes, or some other breakage arises. Then DMD can get support for the new version before it's released. Could that person be you? 2. Managing different compilers: Not too bad but if you end up with some problems here, then it gets multiplied by the factor of the number of issues with each compiler. if LDC has an issue with the x64 dlls and dmd with the x32 and they are always looking in the same place because the versions are different and wrong, then it becomes a issue with a "factor of 4" problem. This can become even worse when you try cross compiling and such. What I've done in the past is to keep the latest DMD on the system path, then set up Command Prompt shortcuts initialized with a different batch file to set override it with paths to different compilers/versions. If DVM could get support for LDC and GDC, then you'd have everything in one convenient app. 3. Re-installation can be problematic. sci.ini is overwritten. If you hand coded the paths to get everything to work, guess what? Well, who cares? You have plenty of time to waste, right? Backup the sc.ini file. 4. Reinstalling one thing can break something else. This depends on how fragile the setup was at the start. Like what? 5. I have over 1 billion files on my system, I use it for around 20 different non-complementary subjects(graphics, music, programming, etc). When everything is "competing for space" and things are not set up to work together, one seemingly unrelated program and effect every other one. (e.g., simply by adding to the path variable and break things with error messages that are meaningless to the real problem) Most ignorant people do not take those things in to account because they oversimplify... and that usually causes problems down the road for the rest of us. So, what are you proposing here? Educate us. What are we supposed to take into account? I use my computer also for graphics, music, programming, document editing, all sorts of stuff. The only breakage I've ever had has usually been related to anti-virus software, though in the past there was an occasional issue with things like SecuRom. What exactly should the D community to in order to alleviate these major breakages you have on your system? As D becomes increasing popular, there are going to be more variation in the system and the flaws in it will become larger and larger. It's best to start working on fixing those flaws before they become too large to manage and weaken the whole structure. I would like to reiterate here what I mentioned earlier in this thread -- people in the D community are currently fixing flaws all the time. That we aren't fixing the flaws that particularly peeve you does not mean nothing is being done. I would also like to reiterate that if something is important enough to you, then you could do something about it besides coming to the forums and calling the rest of us ignorant. Write a DIP. File issues on Bugzilla. Submit pull requests. Take on responsibility for ensuring Visual Studio compatibility. Or do nothing, but please don't act as if we're all just sitting here twiddling our thumbs.
Re: D needs to get its shit together!
On Saturday, 17 June 2017 at 13:23:06 UTC, Mike Parker wrote: On Saturday, 17 June 2017 at 06:06:53 UTC, Mike B Johnson wrote: [...] This isn't as severe as you make it sound. If the latest version of VS doesn't work, the one before will. It's easy to prevent such issues in the future. Since we never know if a new version of VS will break things, this can be solved by one person who can monitor the beta releases of VS and submit PRs to the appropriate repositories if the paths change, or (as happened with VS 2015) the C runtime library changes, or some other breakage arises. Then DMD can get support for the new version before it's released. Could that person be you? [...] What I've done in the past is to keep the latest DMD on the system path, then set up Command Prompt shortcuts initialized with a different batch file to set override it with paths to different compilers/versions. If DVM could get support for LDC and GDC, then you'd have everything in one convenient app. [...] Backup the sc.ini file. [...] Like what? [...] So, what are you proposing here? Educate us. What are we supposed to take into account? I use my computer also for graphics, music, programming, document editing, all sorts of stuff. The only breakage I've ever had has usually been related to anti-virus software, though in the past there was an occasional issue with things like SecuRom. What exactly should the D community to in order to alleviate these major breakages you have on your system? [...] I would like to reiterate here what I mentioned earlier in this thread -- people in the D community are currently fixing flaws all the time. That we aren't fixing the flaws that particularly peeve you does not mean nothing is being done. I would also like to reiterate that if something is important enough to you, then you could do something about it besides coming to the forums and calling the rest of us ignorant. Write a DIP. File issues on Bugzilla. Submit pull requests. Take on responsibility for ensuring Visual Studio compatibility. Or do nothing, but please don't act as if we're all just sitting here twiddling our thumbs. You realize your mentality is like a dead rat? It just stinks. Your solutions are not solutions. They are patches. I wouldn't hire you to fix my plumbing because in a few months I'll have to fix it again. You are ok with that, because you get paid either way. Keep kicking the can down the road... It may get you a bit of exercise but in the long run you are just wasting everyone's time. I also suggest you get out of the 1970's. Software and computers have come a long way. We shouldn't have to resort to the same mind set 40+ years ago. I shouldn't have to backup sc.ini, just because you think it is the way doesn't mean it is. That mindset for sc.ini pervades all your so called solutions. There are better ways, too bad you don't care or are too ignorant to see them.
Re: D needs to get its shit together!
On Saturday, 17 June 2017 at 14:01:38 UTC, Mike B Johnson wrote: You realize your mentality is like a dead rat? It just stinks. Your solutions are not solutions. They are patches. I wouldn't hire you to fix my plumbing because in a few months I'll have to fix it again. You are ok with that, because you get paid either way. Keep kicking the can down the road... It may get you a bit of exercise but in the long run you are just wasting everyone's time. I also suggest you get out of the 1970's. Software and computers have come a long way. We shouldn't have to resort to the same mind set 40+ years ago. I shouldn't have to backup sc.ini, just because you think it is the way doesn't mean it is. That mindset for sc.ini pervades all your so called solutions. There are better ways, too bad you don't care or are too ignorant to see them. That's fine. One more piece of advice I have for you. If you want anyone to take you seriously, check the attitude at the gate. Good luck!
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 13:14:46 UTC, Moritz Maxeiner wrote: If you are interested in donations, there is such infrastructure, it's called the D Foundation. I imagine that it's not possible to make donations to the foundation that are restricted for the use of advancing a specific aspect of the language (e.g. tooling). I don't know if anyone is looking at the state of the ecosystem from the persepctive of a corporation considering whether or not to use D for some project. Of course, such a perspective is immaterial if there is little community interest in corporate adaption of D...
Re: D needs to get its shit together!
On Saturday, 17 June 2017 at 22:57:46 UTC, Mark wrote: On Friday, 16 June 2017 at 13:14:46 UTC, Moritz Maxeiner wrote: If you are interested in donations, there is such infrastructure, it's called the D Foundation. I imagine that it's not possible to make donations to the foundation that are restricted for the use of advancing a specific aspect of the language (e.g. tooling). IANAL, but if you tie a monetary exchange to a specific service, it's not a donation, but payment for services (to be) rendered. I don't know if anyone is looking at the state of the ecosystem from the persepctive of a corporation considering whether or not to use D for some project. I would imagine the people at Sociomantic do. Of course, such a perspective is immaterial if there is little community interest in corporate adaption of D... People who work on/with something in their free time for their own purposes are imho (rightfully) unlikely to care about catering to third party corporate interests.
Re: D needs to get its shit together!
On Saturday, 17 June 2017 at 23:14:24 UTC, Moritz Maxeiner wrote: IANAL, but if you tie a monetary exchange to a specific service, it's not a donation, but payment for services (to be) rendered. Good point. People who work on/with something in their free time for their own purposes are imho (rightfully) unlikely to care about catering to third party corporate interests. Okay. Fair enough.
Re: D needs to get its shit together!
On Saturday, 17 June 2017 at 15:01:34 UTC, Mike Parker wrote: On Saturday, 17 June 2017 at 14:01:38 UTC, Mike B Johnson wrote: You realize your mentality is like a dead rat? It just stinks. Your solutions are not solutions. They are patches. I wouldn't hire you to fix my plumbing because in a few months I'll have to fix it again. You are ok with that, because you get paid either way. Keep kicking the can down the road... It may get you a bit of exercise but in the long run you are just wasting everyone's time. I also suggest you get out of the 1970's. Software and computers have come a long way. We shouldn't have to resort to the same mind set 40+ years ago. I shouldn't have to backup sc.ini, just because you think it is the way doesn't mean it is. That mindset for sc.ini pervades all your so called solutions. There are better ways, too bad you don't care or are too ignorant to see them. That's fine. One more piece of advice I have for you. If you want anyone to take you seriously, check the attitude at the gate. Good luck! Cool. Since we are friends now, I have some advice for you: I suggest that if you want anyone to take you seriously, I suggest you check your mediocrity mentality at the door. See how that works?!?! Probably not. I suggest you get with the program and stop assuming it's ok to waste peoples time, including your own. The world would be a better place if people like you stopped playing your little games and grow up. Then people like me wouldn't have to constantly put you in your place.
Re: D needs to get its shit together!
On Sunday, 18 June 2017 at 08:40:22 UTC, Mike B Johnson wrote: Cool. Since we are friends now, I have some advice for you: I suggest that if you want anyone to take you seriously, I suggest you check your mediocrity mentality at the door. See how that works?!?! Probably not. I suggest you get with the program and stop assuming it's ok to waste peoples time, including your own. The world would be a better place if people like you stopped playing your little games and grow up. Then people like me wouldn't have to constantly put you in your place. Mike, if people do not want to listen, simply accept that... Going on a yelling tirade solves nothing. I already concluded from this "discussion" that there is no point trying to point out issues with D. Maybe too many people in the past pointed out the same stuff and they are tired of it. Whatever the issue is, simply move on. If they do not want to attract new people or want to make it more easy, who are we to talk about it ( as the same new people ). There are good people in the D community but in some responses you get the attitude like "how do you not know something so simple". And i am not talking about this topic. There are responses that borderline "how stupid are you". Maybe not in those words but you can read it clearly. Maybe because i got some of those responses that i also felt more "inflammatory" in this topic by generalizing. But reading comments like: Perhaps _this_ is the right packaging for D right now, to keep away the kinds of casual users who would not be suited for D. It angers the hell out of me when people look down on other developers because they do not have the right background or are somehow considered less trying to deal with inadequacies in the D ecosystem. I am not targeting any person here but there are people here with good intentions and people who to not realize how there responses look down on people. Some do not understand that not everybody has 10+ years in developing C/C++ programs and knows every terminology and understands every aspect of the memory management and the ins and out. But there is no point fighting this attitude. Just use D for what you need it or move to a different language. I am at this moment contemplating moving my code base to different language for this same reason. My impression of D: * The forums is a mixed bag of good intention people who give you the answer you need. Some people who look down for asking a stupid question. Some people who take criticism about D such a personal level. And people who are simply rude, maybe there have good intention but have short fuse ( i wonder who that is :) ). * Git: I found the people who managed the code summations to D GIT way more helpful and frankly very pleasant. I learned a lot in a short amount of time despite being a total noob at this. Frankly, sometimes i wish i NEVER discovered the forums because seeing some of the discussions and reading the past discussions, it feels like a darn pool of evil. Good, bad and just ugly. It frankly demotivates... And it has now **highly** opinionated my attitude about D, to the point that makes me wonder. As a potential employer: If i hire people with no D knowledge and they need to learn D. They go to these forums and get sucked into this. What about easy of learning, issues they may run into. It means time i need to spend teaching new employees to avoid some of the issues mentioned here ( and a lot of past topics that i found ). I do not understand because on other language forums the discussions are more civilized, there seem to be less looking down on people. Maybe i use the Rust argument a bit too much but to be good at Rust a good background is extreme helpful and yet, i do not notice the same attitude with people ask stupid questions or are not happy about something. I really, REALLY think that some people have been living so long in a bubble, that they do not understand how person some of there responses are and how it affects future posting from new members. There are a lot of other things... but it will sidetrack things even more. Its already a wall of text by now. But it really comes down in its most simple form: "Language good, library can use some work but useful, standard documentation disaster ( until you discover the library doc ), community mixed bag, 3th party plugins again mixed bag ( some good, some bad, some not maintained ), language future not 100% sure about where it will end up". And that is my personal and honest opinion... - - And please, do not quote my text piece by piece, ripping me a new one for being inflammatory or whatever. Its how I from MY perceptive see things. Just as you, the person reading this will have there own opinion. - - As for me, i will be looking a bit more into other languages and there communities. For a hobby project D is
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote: Just try getting D installed on all 3 major systems for DMD, LDC, GDC, with an IDE, some utilities, possibly arm support(even though it's new and expected to have some issues), etc. The issues really start popping up when you are trying to use x86 + x64. Library issues that result in strange error messages instead of "This compiler is not compatible with the phobos v2.4324". Might be worth considering something like the Android SDK installer. It looked like this: http://cache.filehippo.com/img/ex/4515__android_sdk_1_8_5_15.png Essentially it was a cross-platform package manager GUI, which allowed installing platform support for various platform versions side-by-side, as well as additional utilities and dependencies. It also exposed its functionality via command-line tools and IDE integrations. This translates fairly well to the D ecosystem, and could serve as a decent work-around for Windows' lack of native package management. We have some of the pieces as separate tools (Digger, DVM, the dlang.org/install.sh script, the Windows' installer's Visual Studio detection/integration), could be nice tying them together into a palatable GUI. Digger has a rudimentary one, which probably could be wrapped into a native-like app using Electron, but still lacking features such as managing GDC/LDC.
Re: D needs to get its shit together!
On Sunday, 18 June 2017 at 14:53:57 UTC, Wulfklaue wrote: But it really comes down in its most simple form: "Language good, library can use some work but useful, standard documentation disaster ( until you discover the library doc ), some people keep saying that. and i dont understand them. i think the documentation of the d language is good. i could learn the whole language with just looking at http://dlang.org/spec/spec.html It contains many examples and is easy to read. Someone exclusively coming from the scripting-world might have issues though, i am not sure
Re: D needs to get its shit together!
On Sunday, 18 June 2017 at 15:47:34 UTC, Vladimir Panteleev wrote: On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote: Just try getting D installed on all 3 major systems for DMD, LDC, GDC, with an IDE, some utilities, possibly arm support(even though it's new and expected to have some issues), etc. The issues really start popping up when you are trying to use x86 + x64. Library issues that result in strange error messages instead of "This compiler is not compatible with the phobos v2.4324". Might be worth considering something like the Android SDK installer. It looked like this: http://cache.filehippo.com/img/ex/4515__android_sdk_1_8_5_15.png Essentially it was a cross-platform package manager GUI, which allowed installing platform support for various platform versions side-by-side, as well as additional utilities and dependencies. It also exposed its functionality via command-line tools and IDE integrations. This translates fairly well to the D ecosystem, and could serve as a decent work-around for Windows' lack of native package management. We have some of the pieces as separate tools (Digger, DVM, the dlang.org/install.sh script, the Windows' installer's Visual Studio detection/integration), could be nice tying them together into a palatable GUI. Digger has a rudimentary one, which probably could be wrapped into a native-like app using Electron, but still lacking features such as managing GDC/LDC. Digger is great, as is the Windows installer, and I appreciate the work that has gone into them. Sadly though in the current year we have been ruined by everything being made easy for us - personally I have no problem taking things apart to get to the bottom of a problem when it doesn't work, but in the business world that is not universally true, alas. So I think what lets us down sometimes is tiny little things that maybe aren't complicated to fix, but are maybe a bit specific. For example it's not so easy to build 64 bit dmd on Windows from the command line (and I don't understand why we don't distribute a binary). Or the installer somehow doesn't seem to work with VS 2015 and I haven't even had the time to figure out what the problem is because it's not on my machine and I don't develop much on Windows at all myself. Having a tsar of ergonomics or user experience might be something valuable. Not really a tsar, but just someone to co-ordinate improvement of those little frictions that one doesn't even notice after using D for a while, but that are a big impediment to a newcomer. I mean you could sit with someone new to the language and see what they struggle with, or do it remotely and chat every week. You would learn a lot that way. It doesn't need to be an expensive resource - an intern could do that. The culture is shaped a bit by C/C++ world, but actually I disagree with Joakim that D is a low-level language. I don't really use it that way myself, and others before me - including Liran at Weka (who is pretty low-level when he needs to be) - have observed that D has qualities of a compiled Python. And people who use it like the latter are a bit accustomed to comfort, and so it's a bit of a shock when for exaple someone comes from C# or Python on Windows and wants to install zeromq and realises (or worse, doesn't) they have to build the C library themselves on Windows when they never even heard of cmake before. This was a real example, and the person grumbled that D was a lousy language for that reason... It's also true that an excessive love of comfort is a civilisation-killer, and I think that's one of the strengths of the community - that people who persist are those who aren't put off by things being a bit difficult in the beginning - but perhaps its a matter of balance, and one could think about how to make the experience a bit easier. (Yes, I realise that even today, Windows native code library management is a problem - I just use that as an example).
Re: D needs to get its shit together!
On Sunday, 18 June 2017 at 14:53:57 UTC, Wulfklaue wrote: I already concluded from this "discussion" that there is no point trying to point out issues with D. Maybe too many people in the past pointed out the same stuff and they are tired of it. In an open-source community, the best way to change something is to make a start on it yourself and try to get others interested. Or if you can afford it you can see if Walter or Andrei might be interested in helping you under a consulting arrangement, or try to find someone else in the community that you could pay to change it for you. If you don't want to do the work, and can't pay, then you can still try to persuade people - and often enough, if you are gently persistent and your point is good, you'll be able to influence things over time. What doesn't work is complaining and expecting others to fix your stuff for you. In theory, when you purchase products and services your supplier ought to be much more responsive than where you don't pay. My experience has been that even when you pay quite a lot - millions of dollars - one can often be disappointed in just how responsive a commercial supplier will be. So increasingly over time for me I have come to see the merits of open-source, because at least I can figure out how to change something and find someone who will help me do the work. There are good people in the D community but in some responses you get the attitude like "how do you not know something so simple". And i am not talking about this topic. There are responses that borderline "how stupid are you". Maybe not in those words but you can read it clearly. I do not recognise this attitude at all - in fact it's remarkable how helpful people are, and how some of the best people in the community spend a great deal of time helping others for free. Perhaps _this_ is the right packaging for D right now, to keep away the kinds of casual users who would not be suited for D. Yes - it's an advantage for D in its present state of development that the frictions act as a shield and tend to mean the people who persist have a high level of technical ability and resourcefulness, and the people shape the culture. If you go buy something precious, they don't give you the hard sell. They say this X is not for everyone, but if you would like to understand it, here is what the thing is like. And I think it's like that with D - it's not for everyone, but if it were I wouldn't be here. I am not targeting any person here but there are people here with good intentions and people who to not realize how there responses look down on people. Some do not understand that not everybody has 10+ years in developing C/C++ programs and knows every terminology and understands every aspect of the memory management and the ins and out. Personally I programmed intensely in C and assembler from 1983 - 1988 at high school, a little from 1996-1998 and I picked up programming again in 2014. So in the beginning I had no idea why people were so focused on memory because when I learnt to program memory was pretty fast vs CPU and that changed whilst I was doing other things. But I learnt a lot just in a couple of years from being around here - and it wouldn't have been the case in a different community. I don't think it's true that people here look down on you or that they expect you to understand every nuance of memory management. One might feel initially inadequate, yes, but that's what it's like to learn something new. And people may also be a bit short on time - but it's not their responsibility to spend their free time to teach you. It's nice when they do, but it's up to us to teach ourselves using whatever resources we can find. Frankly, sometimes i wish i NEVER discovered the forums because seeing some of the discussions and reading the past discussions, it feels like a darn pool of evil. Good, bad and just ugly. It frankly demotivates... You must be reading different forums from me. And it has now **highly** opinionated my attitude about D, to the point that makes me wonder. As a potential employer: If i hire people with no D knowledge and they need to learn D. They go to these forums and get sucked into this. I'm paying people to work in D, and have done since 2015. I personally would never hire someone who would be put off by robust exchanges or who would lack the resourcefulness and ability to tolerate discomfort that everything not being completely shiny (documentation, installation on Windows) would deter them. In fact, I would go further and say that D is a good hiring filter for the very reasons that you find offputting (though you interpret the meaning of things differently from me). And I'm in a different business, most likely, and it may be that at this point the language is a good fit for me and not for some others - that's okay. D isn't for everyone, and it doesn't need to
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 14:40:42 UTC, jmh530 wrote: On Friday, 16 June 2017 at 13:30:21 UTC, Joakim wrote: On the other hand, maybe D is not meant for the kind of user who needs such an easy path. What does it matter if you set D up really easily and then can't grasp such a sprawling, lower-level language? Perhaps _this_ is the right packaging for D right now, to keep away the kinds of casual users who would not be suited for D. Today I agree with that, but in 1-2 years when mir/lubeck are in better shape I'm probably going to disagree. Hoping someone packages something together like an Anaconda for D that just easily works. What's missing from Lubeck that you would like to see? Wrt Anaconda for D - it's the native code (C) libraries that are the biggest pain point. Same thing as with Python really. So I wonder if we could figure out a way to host build configuration and build itself for the C libraries underlying dub bindings and wrappers. It's really a Windows-specific problem, because even today there doesn't seem to be a great answer. I played with chocolatey a bit, but it doesn't always seem to be that helpful in practice.
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 15:54:36 UTC, Joakim wrote: On Friday, 16 June 2017 at 15:47:15 UTC, Russel Winder wrote: If it is true that there is increased traction for D, then getting some resource into the front of house stuff will be critical to that traction fading and disappearing. Yes, daily downloads of dmd are up 25-30% this year: http://erdani.com/d/downloads.daily.png " But when will D take off. There are no jobs in D. D hasn't taken off yet so it won't etc etc. "
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 11:50:20 UTC, Wulfklaue wrote: Maybe that is the same reason why D has a issue drawing in new non-C/C++ developers? What's your evidence for this? I'm curious. Not that the composition of new adopters matters particularly - it's just interesting to know. Well, i do not have the time. Want me to donate? Does that solve the issue. No ... because there is no clear infrastructure in place to actually hire people to work on the language and the environment. If you're serious, put up some money and maybe I can match it (and there is a decent chance one or two other larger commercial users might contribute also). One doesn't need much infrastructure to organise things, BTW. I have a private gitlab instance and a way to pay people and we're already trying to make the ecosystem a better in modest ways - for example we have already contributed back our internal changes on our own fork to dub.
Re: D needs to get its shit together!
On Sunday, 18 June 2017 at 21:53:35 UTC, Laeeth Isharc wrote: Wrt Anaconda for D - it's the native code (C) libraries that are the biggest pain point. Same thing as with Python really. So I wonder if we could figure out a way to host build configuration and build itself for the C libraries underlying dub bindings and wrappers. Sometimes it can be a problem on Linux / OS X as well, especially if one wants to link to little known C/C++ libraries, e.g. libnoise for the DREPL. There is a DEP about it: https://github.com/dlang/dub/wiki/DEP5
Re: D needs to get its shit together!
On Sunday, 18 June 2017 at 21:02:40 UTC, Laeeth Isharc wrote: The culture is shaped a bit by C/C++ world, but actually I disagree with Joakim that D is a low-level language. I don't really use it that way myself, and others before me - including Liran at Weka (who is pretty low-level when he needs to be) - have observed that D has qualities of a compiled Python. And people who use it like the latter are a bit accustomed to comfort, and so it's a bit of a shock when for exaple someone comes from C# or Python on Windows and wants to install zeromq and realises (or worse, doesn't) they have to build the C library themselves on Windows when they never even heard of cmake before. I think there is scope for a D version of something like anaconda for python. The easier it is to get users up and running, the better.
Re: D needs to get its shit together!
On Sunday, 18 June 2017 at 21:53:35 UTC, Laeeth Isharc wrote: What's missing from Lubeck that you would like to see? I don't have an issue with missing functions at this point. I just hope that we can get some operator overloading so that I don't have to write mtimes all over the place. My ideal would be a DIP that adds the option to overload opBinary for \, .+, .-, .*, ./. Lubeck could use \ for inverse, .+ etc. for element-wise matrix operations, and * for mtimes, etc. Very Matlab-like. Wrt Anaconda for D - it's the native code (C) libraries that are the biggest pain point. Same thing as with Python really. Wrt to my post above, I had forgotten that I made the point about anaconda already. Long weekend away. So I wonder if we could figure out a way to host build configuration and build itself for the C libraries underlying dub bindings and wrappers. It's really a Windows-specific problem, because even today there doesn't seem to be a great answer. I played with chocolatey a bit, but it doesn't always seem to be that helpful in practice. Sounds like something to think about.
Re: D needs to get its shit together!
On Mon, 2017-06-19 at 12:36 +, jmh530 via Digitalmars-d wrote: > […] > > I think there is scope for a D version of something like anaconda > for python. The easier it is to get users up and running, the > better. I'd say the Dub repository is this, or at least should be at least the basis for it. Ceylon has Herd, JVM languages otherwise has Maven Central and JCenter, C++ now has Conan. However, I think Cargo for Rust is current the technology leader in mixing a curated central repository. Dub could usefully be split into two a curated part where stuff gets removed as well as added, with review and possible rejection before adding, and a free for all section from which is never lost and can be added to freely. Cargo and Ceylon effectively have this. The trick is not to actually have a free for all added bit (a la PyPI) but to allow for DVCS accessed packages. -- Russel. = Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.win...@ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder signature.asc Description: This is a digitally signed message part
Re: D needs to get its shit together!
On Sunday, 18 June 2017 at 15:47:34 UTC, Vladimir Panteleev wrote: On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote: Just try getting D installed on all 3 major systems for DMD, LDC, GDC, with an IDE, some utilities, possibly arm support(even though it's new and expected to have some issues), etc. The issues really start popping up when you are trying to use x86 + x64. Library issues that result in strange error messages instead of "This compiler is not compatible with the phobos v2.4324". Might be worth considering something like the Android SDK installer. It looked like this: http://cache.filehippo.com/img/ex/4515__android_sdk_1_8_5_15.png +1
Re: D needs to get its shit together!
On Monday, 19 June 2017 at 13:36:01 UTC, Russel Winder wrote: I'd say the Dub repository is this, or at least should be at least the basis for it. Ceylon has Herd, JVM languages otherwise has Maven Central and JCenter, C++ now has Conan. However, I think Cargo for Rust is current the technology leader in mixing a curated central repository. Dub could usefully be split into two a curated part where stuff gets removed as well as added, with review and possible rejection before adding, and a free for all section from which is never lost and can be added to freely. Cargo and Ceylon effectively have this. The trick is not to actually have a free for all added bit (a la PyPI) but to allow for DVCS accessed packages. dub is more like conda, Anaconda's package manager. What I mean is one thing that someone can download and install one file and everything just works. For instance, one download and a (Windows) user has DMD/LDC/DUB, DlangScience/Mir/Lubeck, and some of the database and plotting libraries installed. Basically, reduce the amount of time for a Python/R/Matlab user to get up and running on D. Would help get new users.
Re: D needs to get its shit together!
On Mon, 2017-06-19 at 14:43 +, jmh530 via Digitalmars-d wrote: > […] > dub is more like conda, Anaconda's package manager. Good point. Also I should separate dub the executable from Dub the repository of stuff more carefully. > What I mean is one thing that someone can download and install > one file and everything just works. For instance, one download > and a (Windows) user has DMD/LDC/DUB, DlangScience/Mir/Lubeck, > and some of the database and plotting libraries installed. > Basically, reduce the amount of time for a Python/R/Matlab user > to get up and running on D. Would help get new users. Continuum Analytics do a great job with Anaconda/Miniconda but they have an income stream against which they can post the costs of the people and equipment to keep it working and up to date. Dub, both executable and repository, seem to have a little volunteer labour, and hence maintenance is not reliable, in the sense of there is no guarantee effort can be put into it. But yes, I'd say putting effort into something like Anaconda/Miniconda for D and it's packages would be a good idea. I am guessing extending dub so that when it downloads and builds executables, it can also install them in a platform specific way. For the package managed platforms by building a local package and installing it? I am guessing the next step would be packaging dmd, rdmd, ldc2, and gdc? -- Russel. = Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.win...@ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder signature.asc Description: This is a digitally signed message part
Re: D needs to get its shit together!
On Monday, 19 June 2017 at 12:46:19 UTC, jmh530 wrote: I just hope that we can get some operator overloading so that I don't have to write mtimes all over the place. My ideal would be a DIP that adds the option to overload opBinary for \, .+, .-, .*, ./. Lubeck could use \ for inverse, .+ etc. for element-wise matrix operations, and * for mtimes, etc. Very Matlab-like. I'd like to second more flexibility around unary and binary operators, perhaps we can have another keyword for instance "record" that is essentially a D struct but allows the user to specify their own operators - it could be included unofficially at first without impacting the rest of the D language with the stipulation that it is not used in D's core libraries or in anything important. This functionality would allow notation native to different fields in analysis to be used.
Re: D needs to get its shit together!
On Wednesday, 21 June 2017 at 18:35:33 UTC, data pulverizer wrote: On Monday, 19 June 2017 at 12:46:19 UTC, jmh530 wrote: I just hope that we can get some operator overloading so that I don't have to write mtimes all over the place. My ideal would be a DIP that adds the option to overload opBinary for \, .+, .-, .*, ./. Lubeck could use \ for inverse, .+ etc. for element-wise matrix operations, and * for mtimes, etc. Very Matlab-like. I double-checked and noticed that Matlab doesn't actually have .+/.-, just +/-. Since D's a[] + b[] doesn't seem all that different from Matlab's a + b, with the restriction that there needs to be destination memory, it seems like it would be a confusing to add in another way of doing things. So maybe just add \ and another operator for matrix multiplication. I don't really know. I'd like to second more flexibility around unary and binary operators, perhaps we can have another keyword for instance "record" that is essentially a D struct but allows the user to specify their own operators - it could be included unofficially at first without impacting the rest of the D language with the stipulation that it is not used in D's core libraries or in anything important. This functionality would allow notation native to different fields in analysis to be used. An interesting idea, but I don't know if they would go to for it. If you want more operator overloading on a class, you could put the class as a member of the "record" and alias this it?
