Re: My first experience as a D Newbie
On Thursday, 19 October 2017 at 18:10:04 UTC, H. S. Teoh wrote: Told by whom? The responses here seem to be a good indicator that he is wasting his time. The past responses in similar topics. Even Andrei or Walter can be convinced over time, if one is persistent enough. :-D There have been cases of this in the past. Of course, this presumes that one cares about the issue enough to persist in the face of opposition, which may or may not be the case here. You mean like those where people are told, if you write a proposal it may get accepted. Then the author does all the work, writes the code changes, gets pushed to make more changes, gets ignored over time and loses interest, only for year later it showing up again and the process repeats? And nothing gets done to the point the author simply moved on to other languages. Yes, those have been very successful ( sarcasm ) in persuading people to put time into D development. D has a bad track record with implementations of proposals, even when the actual code has been written. There has always been a standard: Walter writes it, its going to get accepted with a high ratio in one form or another. Somebody who is not a core member, well ... But this is my last response on this. Moving on to a different language because from my point of view, D will not be very open / marketing focused to non C++ developers. And some people seem very willing to push people there buttons when topics like this come up. As we see in this topic. I regret that the actions of few constantly ruin the work of others ( to bring people in ). What seems to be a recurring theme. But let bygones be bygones. Good fortune to you all.
Re: My first experience as a D Newbie
On Monday, 16 October 2017 at 09:01:20 UTC, rikki cattermole wrote: And yet my elderly-ish mother uses Linux Mint and she hates technology. It isn't as clear cut as it may appear, these issues. Off-topic but the issue with Linux is not when you have it stable running ( assuming everything works perfectly out of the box ). Its when you update software. Nothing more fun as lockups when your kernel is updated but you need the update because it allows some other feature to work. We are talking in the mindset of developers, not mothers who only use skype/browser/mail and do not care if the software is out of date. :)
Re: Will D continu to live after walter death?
On Thursday, 12 October 2017 at 15:04:57 UTC, moechofe wrote: What is the wanted lifetime of the project? Is D will manage to pass through time? It is valuable to start a 40 years old project using D? Its a serious topic but that gets way too much joking. While D is part of the foundation, that is not the issue. It is leadership, focus, goals, long term vision ... There are not that many people that can take over that task successfullly. I noticed its all a joke to people. Posted in a other topic about the fragmented nature of D and the high focus on solo developers. And the issue of what happens if a main developer of a extension has no more time or god forbids dies. That same applies to D as a language. That D is in a Foundation means nothing. Apple without Jobs is still Apple but you can see the difference in there products after his dead.
Re: My first experience as a D Newbie
On Sunday, 15 October 2017 at 20:27:35 UTC, Laeeth Isharc wrote: D is much less gratifying than other languages for most people. Just like Windows was more gratifying than Linux for most people in 2000. And I suppose that's likely to change slowly, but continue to be the case for a while so long as people working on Windows don't notice when something isn't working and fix things at root cause. It's usually not that much more difficult to do so than work around it, and it usually pays off even considered selfishly. I can appreciate your frustration, but considering how many years knowing a programming language can pay off for, a few hundred hours spent to learn something new isn't that much. That's like a couple of months full-time and if it works out the payback period should easily be a year. Viewed rationally, that's a pretty good return on investment compared to most other opportunities available. In a world where there are lots of smart people and knowledge is widely available, the barriers to opportunity (there must be barriers, otherwise the opportunity would be competed away) are often emotional ones. So I like things where the difficulty is front-loaded, because they tend to be neglected by modern people who are used to quick gratification. And whilst it surely can be frustrating, the situation is already better both on Windows and as regards documentation and tooling than it was in 2014. It's not difficult to make little changes towards what one would like to see oneself. When you invest this time into a language, you have expectations. A person expects for a language this old, that every puzzle fits together without issue. Call me spoiled if you want but quick gratification it is not. The time wasted on dealing with issue on D, is time you can have spend in a different language actually writing code/testing. Its a barrier to the language its own success when its not as user friendly as the other languages. If a person needs to do a action in Windows and it takes him 5 mouse clicks. But hey, under Linux you can do it with one command line arg, ... the Linux approach sound more easy right? Until you add the time needed to learn the command and assuming there are no issues. What is more rewarding or punishing? There is a reason that Windows is still so popular. Windows does not get in the way. It just keep working. Can it be improved, yes! MS puts a massive amount of time and money in there testing. And it shows in there platform. Its the same reason why Linux as a desktop OS will never work out. Too much puzzle pieces that do not fit, too much assumed that people need ( and have the time ) to learn the complicated way. A lack of inter-testing beyond just the basic compile tests ( i mean really usage ). Its easy to see the same attitude in D as a community project. There are GREAT pieces being written but everybody is working more as a solo developer, with no clear guideline. That is the big difference between a language like D and corporate backed languages. I can easily think of a dozen extensions to D, that need to be part of the standard library or extended library of D, like DCompute, mir-algorithm, ... Why? Because its again lose projects that you as a end consumer need to discover. Most of the time written and maintained by one person. Too much here is so single person focused, that its hard to see people continue the work if that person has no more time. Too much here is single issue focused and it shows in the developers there background, what results in the testing of platforms, the interaction etc. Maybe i explain this badly, but D seems has a lot of issues that people here are not aware off because they are already in the D mindset. And its those issues that show up the most, when one first tries this language.
Re: My first experience as a D Newbie
On Friday, 13 October 2017 at 13:14:39 UTC, Steven Schveighoffer wrote: Thanks for replying. I did not mean my post as a slight against your knowledge, but really about my ignorance -- I don't know what the expectations of a Windows user are. I think the Windows users we do have on the core team (Walter being the main one) probably aren't typical Windows developers. But my experience seems to be most of the "I've tried to use D for 10 days and it sucks!" rants come from the Windows side, and they are mostly about installation and IDE woes. On my mac, I just do "dvm install 2.076.0" and I'm up and running. I think at some point, an actual company will pick up the maintenance of a good D IDE for windows, and will solve this problem. Unfortunately, we have to rely on volunteers right now, and that company hasn't materialized. One note about your requirements, auto-completion I think is something that I love about IDEs for other languages (I would be lost in xcode without it) and is something I've never used with D (all my attempts have been disasters). It's definitely something we need to improve the experience on. As one of those Windows users that has a love/hate relationship with D, i can only state that the issues that the OP has faced, are similar to those that i seen. DMD in general installs good on Windows ( minus the path at times not getting registered and the need to logout/reboot ). The issues mostly come from the editor support and at times horrible dub package breaking. D has the habit of breaking backward comparability in specific releases, mostly from improper testing the compiler vs the dub packages. The issue with with code-d, serve-d and other VSC solutions that go from the above mentioned path issues, dub package breaking, support packages refusing to compile, the simple fact that some maintainers assume that GIT is standard installed, ... The list is long and currently code-d and serve-d are broken again. At times they work, reinstall them on a other system and they break. Its probably the main reason why i do not use D for any big projects. The feeling that things break constantly or do not work the same on almost the exact systems. D and everything around it on Windows feels fragile, that is the best way to describe it. Same with some of the user friendliness of the compile options the moment you step outside simple run/build and start playing with shared libraries etc. Trust me when saying that a lot of other languages feel more complete. Even the D error output feels year 2000, compared to Rust, Crystal etc... Probably very usable for D experts but lackluster for a language that seeks adoption in 2017. Same issue with the 3 different compilers and different command options. The steps needed to figure out cross compiling is bigger then Go, Rust, ... Let alone the above mentioned shared libraries. D is a marvelous project with a clear C++ developers focus, and i can only conclude that C++ developers are people who are into sadomasochism based upon some of the friendliness features :) That is always the issue with a language that focuses on a specific group of developers, with a mindset that they can find there way around similar design. But it does not work so well on developers who like the current new generation of languages that make things more easy on the brain. The issue is not only located in the Windows issue but also somewhat in the design mentality it seems. That give the impression that Windows is just a side project and people who do not come from a C/C++ background there complaints are reduced to complainers. Instead of focusing on adding new features, do a audit and fix the library its GC reliance, better documentation, more user friendly compiler options, better (universal) editors support for people who do not use the dlangide/visualstudio plugin, ... you know, the boring stuff. I have probably put in a few hundred hours try to learn D and get going. And half that time was pure wasted on bugs, editor issues, frustration, hours looking up something that is so easy in other languages, ... Recently i was helping a developer who was benchmarking D+Vibe.d, on his OsX he never got parallel support to work ( error fault 11 ) for Vibe.d, resulting in vibe.d running single core and losing to Crystal and Rust big time ( single core tests ). I do not expect him to pick up D based upon those results. That was two developers trying to find the correct way to force vibe.d to work parallel on his system. Lets not count the hours lost for use both. So currently i am more then a bit salty about D again. Its always something left or right that just does not work properly. His response was Go simply works even if it was slower then D. I can state the same that despite Go its fault, it simply works, same with the editor support etc. And that is frankly bad advertisement for D. Now excuse
Re: My first experience as a D Newbie
On Thursday, 12 October 2017 at 01:26:33 UTC, jmh530 wrote: On Wednesday, 11 October 2017 at 22:23:12 UTC, Rion wrote: On Wednesday, 11 October 2017 at 18:29:38 UTC, qznc wrote: At least on Ubuntu, this gives me an IDE: dub run dlangide I have not used it much and I don't know if it works on Windows, but it might be the easiest way once you installed dmd and dub. Windows 10: dub run dlangide Failed to find a package named 'dlangide'. You have to fetch it first if you don't already have it: dub fetch dlangide dub run dlangide Of course, you might still have an issue... I know but this illustrates the OP his point. Do you see a warning tell people they can need to use fetch? Its the small details that can made the experience much more nice but because everybody here is such D experts, they can not see that for a new user he will not have a clue what is going on. D is riddled with less then friendly behavior simply because the developers are used to this and they do so from memory. Why does it take a whole bunch of commands to make a shared library and link it. Go has it down to a simple clean command. Seen it also in other languages where is more easy. Yet D focuses on the old C++ style because the people developing D all come from this background and do not realism that there is something called user friendly. Its everywhere over the D landscape and it makes it hard for people who are not C++/D aluminate then it needs to be. Its a missed opportunity and instead of always focusing on adding new language features, there need to be a clear period of focusing on user friendliness. And by the way that command above on my tablet results in: Fetching dcd 0.9.1 (getting selected version)... dlangui 0.9.160: building configuration "default"... Error: out of memory dmd failed with exit code 1. 1.3GB free on a 4GB system... Out of memory really!
Re: My first experience as a D Newbie
On Wednesday, 11 October 2017 at 18:29:38 UTC, qznc wrote: At least on Ubuntu, this gives me an IDE: dub run dlangide I have not used it much and I don't know if it works on Windows, but it might be the easiest way once you installed dmd and dub. Windows 10: dub run dlangide Failed to find a package named 'dlangide'.
Re: My first experience as a D Newbie
On Wednesday, 11 October 2017 at 17:55:18 UTC, Steven Schveighoffer wrote: I have to say as someone who uses mostly non-windows systems, these problems only seem to crop up for Windows developers. I don't know if it's a different expectation or a different mindset or something else. Its probably more the fact that most of the developers use Unix based system for development, be it OSx or Linux. As a result Windows is the overlooked system what results in a lack of testing. You really do not want to know the amount of times issues showed up because editor plugins crashes or did not work on windows properly. Very frustrating when its your first experience with a language. It also helps that for instance has a more unified package manager so for people it can simply be apt-get install a few packages and that is it. The patting and other issues are most of the time properly resolved. And it does not help when most plugins are developed by one developer, that is on the above mentioned Unix based systems.
Re: D on quora ...
On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis wrote: D's GC isn't going anywhere. The implementation may be improved or replaced, but there are huge advantages to having the GC (particularly with regards to memory safety), and there _are_ actually times when using a GC is faster than something like reference counting. We don't want D's standard library to rely on the GC when it doesn't need to, but there are language features that require it and really couldn't work with it, and there are cases where it's going to be involved by default for @safety reasons. For someone who wants to avoid the GC or minimize its use, there are things that they will need to do (e.g. you have to be careful with lambdas and probably use functors or functions, because closures are frequently needed when dealing with lambdas, and that means using the GC; @nogc will catch those cases for you so that you know when a lambda isn't going to work). But while it should be possible for someone to avoid the GC if they need to, that does not mean that we're looking to get rid of it or even have not using it be the default. It just means that we don't want to force its use where that doesn't make sense. Honestly, I would _hate_ to use D without a GC. Without it, @safe memory managament would not be possible, and you'd have to valgrind everything. As it stands, you only have to do that when you have sections of @trusted code that would potentially be a problem. And there's a lot of code that's cleaner for not having to worry about managing memory. That's not to say that using the GC is always better or that other solutions are not more appropriate for some circumstances - and the fact that D gives you control over a lot of that is fantastic - but this idea that GCs are always nothing but bad and should be avoided by the plague is just nonsense. GCs have their pros and cons, but they can be fantastic, and idiomatic D programs actually mitigate a lot of the downsides that you can get with a GC, because they do so much with the stack rather than the heap (which is generally better performance-wise regardless of how heap allocations are managed). Yes, we could use a better GC, but overall, the GC is really just a PR problem and not a real one. Most programs can use it and be plenty performant. And those that can't have the tools necessary to minimize its use or even outright avoid it (though honestly, if someone is looking to outright avoid it, I'd lean towards wondering what the point of using D was in the first place; the proponents of the -betterc stuff still think that it's worth it though). Plenty of folks have managed to write performant programs that involve D's GC. - Jonathan M Davis The issue is only mentioned, because it keeps getting talked about ( mostly one sided ) on forums and sites like the above mentioned quora.com. Its hard to change people there perception, without counter arguing. Currently as i write this, these claims on quora are unchallenged. I can make a few simple demos and have D use by default 5 to 10 more memory then the exact same C or C++ program. While D does not actually use it ( its only marked as allocated for the GC ), it does not dispel the notion or feeling of people that a GC = bad. Other aspects like being unsure when the GC will trigger can also influence people to a non-gc language. The Go developers have done a massive ( an impressive ) amount of work on trying to reduce GC pauses in the last two years, and that communication and effort has helped to reduce the GC myth ( for people looking at Go ). Another part of the issue is, while D can be run without the GC, i can not tell what parts of the standard library can work without the GC. Even a simple output parsing gave me a compile error when running nogc a while ago. When every new languages besides Rust or Zig are GC. That same "flaw" is not looked upon as a issue. It seems that D simply carries this GC stigma because the people mentioning are C++ developers, the same people D targets as a potential user base. D can have more success in targeting people from scripting languages like PHP, Ruby, Python, where the GC is not looked upon as a negative. The same effect can be seen in Go its popularity with drawing developers from scripting languages despite it not being there intention. I always felt that D position itself as a higher language and in turn scares people away while at the same time the people it wants to attracts, with most are already set in there ways and looking at excuses to discredit D. The whole C++ has all of D features and does not need a GC / GC is bad excuse we see in the quora.com posting fits that description ( and not only there, also on other sites ). If the GC issue can not be tackled and even with the recent communication blogs, it still keeps showing up. Is it maybe not better to focus the marketing features that
D on quora ...
https://www.quora.com/What-is-your-review-of-D-programming-language It seems that D still has the GC being mentioned up to today. Maybe its better to move the standard library slower to a non gc version in the future...
