Re: D is dead
On 8/22/2018 10:37 PM, Shachar Shemesh wrote: Let's start with this one: https://issues.dlang.org/show_bug.cgi?id=14246#c6 https://github.com/dlang/dmd/pull/8697
Re: D is dead
Hang on a second. assert(preserve == Yes.preserveAttributes); Something is smelling an awful lot here. Up to Windows 7 CopyFileW which is used for Windows didn't copy the attributes over[0] but it does now. This is a bug on our end, which should include a fallback to copying manually the file contents over. [0] https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-copyfilew Yeah, keeping exactly the same behavior on every supported platform is never easy. And when you need to support Windows too, by experience I know it can quickly become a pain in the *ss...
Re: D is dead
https://issues.dlang.org/show_bug.cgi?id=19221
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Tuesday, 4 September 2018 at 13:34:03 UTC, TheSixMillionDollarMan wrote: I think D's 'core' problem, is that it's trying to compete with, what are now, widely used, powerful, and well supported languages, with sophisticate ecosystems in place already. C/C++/Java/C# .. just for beginners. Yes, I believe there was an academic early on that allowed students to use D, but when C++17 (etc) came about he held the view that it would be better for D to align its semantics with C++. He was met with silence, except me, who supported that view. D is too much like C++ for a skilled modern C++ programmer to switch over, but D semantics are also too different to compile to C++ in a useful manner. Then it's also trying to compete with startup languages (Go, Rust ) - and some of those languages have billion dollar organisations behind them, not to mention the talent levels of their *many* designers and contributors. Ok, so my take on this is that Rust is in the same group as D right now, and I consider it experimental as I am not convinced that it is sufficient for effective low level programming. Although Rust has more momentum, it depends too much on a single entity (with unclear profitability) despite being open sourced, just like D. Too much singular ownership. Go is also open source in theory, but if we put legalities aside then I think it is having the traits of a proprietary language. They are building up a solid runtime, and it has massive momentum within services, but the language itself is somewhat primitive and messy. Go could be a decent compilation target for a high level language. That said , I think most languages don't compete directly with other languages, but compete within specific niches. Rust: for writing services and command line programs where C++ would have been a natural candidate, but for people who want a higher level language or dislike C++. Go: for writing web-services where Python, Java and C# is expected to be too resource-intensive. D: based on what seems to be recurring themes in the forums D seems to be used by independent programmers (personal taste?) and programmers in finance that find interpreted languages too slow and aren't willing to adopt C++. C++ is much more than just a langauge. It's an established, international treaty on what the language must be. Yes, it is an ISO-standard, and evolve using a global standardisation community as input. As such it evolves with the feedback from a wide range of user groups by the nature of the process. That is not a statement about the quality of D. It's a statement about the competitive nature of programming languages. It kinda is both, but the issue is really what you aim to be supporting and what you do to move in that direction. When there is no focus on any particular use case, just language features, then it becomes very difficult to move and difficult to engage people in a way that make them pull in the same direction. I wonder has already happened to D. No, it mostly comes down to a lack of focus and a process to back it up. Also, memory management should be the first feature to nail down, should come before language semantics... I just do not see, how D can even defeat its' major competitors. But are they really competitors? Is D predominantly used for writing web-services? What is D primarily used for? Fast scripting-style programming? Instead D could be a place where those competitors come to look for great ideas (which, as I understand it, does occur .. ranges for example). No, there are thousands of such languages. Each university has a handful of languages that they create in order to back their comp.sci. research. No need to focus on performance in that setting. You seem to be saying that, raising money so you can pay people, is enough. But I wonder about that. There has to be a focus based on analysis of where you can be a lot better for a specific use scenario, define the core goals that will enable something valuable for that scenario, then cut back on secondary ambitions and set up a process to achieve those core goals (pertaining to a concrete usage scenario). Being everything for everybody isn't really a strategy. Unless you are Amazon, and not even then. Without defining a core usage scenario you cannot really evaluate the situation or the process that has to be set up to change the situation... Well, I've said this stuff many times before.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote: On Friday, August 24, 2018 6:05:40 AM MDT Mike Franklin via Digitalmars-d wrote: > You're basically trying to bypass the OS' public API if > you're trying to bypass libc. No I'm trying to bypass libc and use the OS API directly. And my point is that most OSes consider libc to be their OS API (Linux doesn't, but it's very much abnormal in that respect). Well, it used to be the case that it was normal to call OS directly by using traps, but since the context switch is so expensive on modern CPUs we a have a situation where the calling stub is a fraction of the calling cost these days. Thus most don't bother with it. What usually can happen if you don't use the c-stubs with dynamic linkage is that your precompiled program won't work with new versions of the OS. But that can also happen with static linkage. Trying to bypass it means reimplementing core OS functionality and risking all of the bugs that go with it. It is the right thing to do for a low level language. Why have libc as a dependency if you want to enable hardware oriented programming? Using existing libraries also put limits on low level language semantics. If you're talking about avoiding libc functions like strcmp that's one thing, but if you're talking about reimplementing stuff that uses syscalls, then honestly, I think that you're crazy. No it isn't a crazy position, why the hostile tone? Libc isn't available in many settings. Not even in webassembly.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
The first search engines were created in 1993, google came along in 1998 after at least two dozen others in that list, and didn't make a profit till 2001. Some of those early competitors were giant "billion dollar global companies," yet it's google that dominates the web search engine market today. Why is that? Their original page-rank algorithm. Basically, they found an efficient way of emulating random clicks to all outgoing links from a page and thus got better search result rankings. It was a matter of timing.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Tuesday, 4 September 2018 at 14:23:33 UTC, Joakim wrote: The first search engines were created in 1993, google came along in 1998 after at least two dozen others in that list, and didn't make a profit till 2001. Some of those early competitors were giant "billion dollar global companies," yet it's google that dominates the web search engine market today. Why is that? Well, for one, resources don't matter for software on the internet as much as ideas. It's not that resources don't matter, but that they take a back seat to your fundamental design and the ideas behind it. Google had a $100k angel round in 1998 and a $25 million Series A in 1999. The difference between Google and the $12 billion-ish valued Lycos of the time was not insurmountable, yes, but $25 million was enough to hire dozens of developers, lease offices, and buy the hardware they needed. Similarly, we don't need Google-level funding to produce a developer ecosystem that's sufficiently polished not to be a blocker for corporate VS-only types who rely on autocomplete. But we need a bit more than $4k for that, or it's always going to be someone's personal project that's mostly complete but might be abandoned in six months.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Tuesday, 4 September 2018 at 13:34:03 UTC, TheSixMillionDollarMan wrote: On Tuesday, 4 September 2018 at 01:36:53 UTC, Mike Parker wrote: On Monday, 3 September 2018 at 18:26:57 UTC, Chris wrote: And of course, low manpower and funding aren't the complete picture. Management also play a role. Both Walter and Andrei have freely admitted they are not managers and that they're learning as they go. Mistakes have been made. In hindsight, some decisions should have gone a different way. But that is not the same as not caring, or not understanding/ So please, don't attribute any disingenuous motives to any of the core team members. They all want D to succeed. Identifying core problems and discussing ways to solve them is a more productive way to spend our bandwidth. I think D's 'core' problem, is that it's trying to compete with, what are now, widely used, powerful, and well supported languages, with sophisticate ecosystems in place already. C/C++/Java/C# .. just for beginners. Then it's also trying to compete with startup languages (Go, Rust ) - and some of those languages have billion dollar organisations behind them, not to mention the talent levels of their *many* designers and contributors. C++ is much more than just a langauge. It's an established, international treaty on what the language must be. Java is backed by Oracle (one the of the largest organisations in the world). Go is backed by Google...Rust by Mozilla...(both billion dollar global companies). So one has to wonder, what would motivate a person (or an organisation) to focus their attention on D. That is not a statement about the quality of D. It's a statement about the competitive nature of programming languages. If you've ever read 'No Contest - the case against competition' by Alfie Kohn, then you'd know (or at least you might agree with that statement) that competition is not an inevitable part of human nature. "It warps recreation by turning the playing into a battlefield." I wonder has already happened to D. D should, perhaps, focus on being a place for recreation, where one can focus on technical excellence, instead of trying to compete in the battlefield. I just do not see, how D can even defeat its' major competitors. Instead D could be a place where those competitors come to look for great ideas (which, as I understand it, does occur .. ranges for example). In any case, you have to work out what it is, that is going to motivate people to focus their attention on D. You seem to be saying that, raising money so you can pay people, is enough. But I wonder about that. That's a good question, let me see if I can answer it. Do you know what the first search engine for the web was and when it was created? It wasn't Yahoo, google, or Bing: https://en.m.wikipedia.org/wiki/Web_search_engine#History The first search engines were created in 1993, google came along in 1998 after at least two dozen others in that list, and didn't make a profit till 2001. Some of those early competitors were giant "billion dollar global companies," yet it's google that dominates the web search engine market today. Why is that? Well, for one, resources don't matter for software on the internet as much as ideas. It's not that resources don't matter, but that they take a back seat to your fundamental design and the ideas behind it. And coming up with that design and ideas takes time, the "developmental stage" that Laeeth refers to above. In that incubation stage, you're better off _not_ having a bunch of normal users who want a highly polished product, just a bunch of early adopters who can give you good feedback and are okay with rough edges. For D, that means all the advanced features don't fully play together well yet, and there are various bugs here and there. To use it, you have to be okay with that. Now, it's a fair question to ask when D will leave that developmental stage and get more resources towards that polish, as Chris asks, and I'm not saying I know the answers to those questions. And let me be clear: as long as you don't push the envelope with mixing those advanced D features and are okay working around some bugs here and there, you're probably good now. But simply asserting that others are rushing full-speed ahead with more resources and therefore they will win completely misunderstands how the game has changed online. Resources do matter, but they're not the dominant factor like they used to be for armies or manufacturing. Ideas are now the dominant factor, and D has plenty of those. ;)
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Tuesday, 4 September 2018 at 01:36:53 UTC, Mike Parker wrote: On Monday, 3 September 2018 at 18:26:57 UTC, Chris wrote: And of course, low manpower and funding aren't the complete picture. Management also play a role. Both Walter and Andrei have freely admitted they are not managers and that they're learning as they go. Mistakes have been made. In hindsight, some decisions should have gone a different way. But that is not the same as not caring, or not understanding/ So please, don't attribute any disingenuous motives to any of the core team members. They all want D to succeed. Identifying core problems and discussing ways to solve them is a more productive way to spend our bandwidth. I think D's 'core' problem, is that it's trying to compete with, what are now, widely used, powerful, and well supported languages, with sophisticate ecosystems in place already. C/C++/Java/C# .. just for beginners. Then it's also trying to compete with startup languages (Go, Rust ) - and some of those languages have billion dollar organisations behind them, not to mention the talent levels of their *many* designers and contributors. C++ is much more than just a langauge. It's an established, international treaty on what the language must be. Java is backed by Oracle (one the of the largest organisations in the world). Go is backed by Google...Rust by Mozilla...(both billion dollar global companies). So one has to wonder, what would motivate a person (or an organisation) to focus their attention on D. That is not a statement about the quality of D. It's a statement about the competitive nature of programming languages. If you've ever read 'No Contest - the case against competition' by Alfie Kohn, then you'd know (or at least you might agree with that statement) that competition is not an inevitable part of human nature. "It warps recreation by turning the playing into a battlefield." I wonder has already happened to D. D should, perhaps, focus on being a place for recreation, where one can focus on technical excellence, instead of trying to compete in the battlefield. I just do not see, how D can even defeat its' major competitors. Instead D could be a place where those competitors come to look for great ideas (which, as I understand it, does occur .. ranges for example). In any case, you have to work out what it is, that is going to motivate people to focus their attention on D. You seem to be saying that, raising money so you can pay people, is enough. But I wonder about that.
Re: D is dead
On 04/09/2018 10:27 PM, Ecstatic Coder wrote:
On Tuesday, 4 September 2018 at 09:56:13 UTC, rikki cattermole wrote:
On 04/09/2018 9:40 PM, Ecstatic Coder wrote:
But it seems that the latest version of "std.file.copy" now
completely ignores the "PreserveAttributes.no" argument on Windows,
which made recent Windows builds of Resync fail on read-only files.
What???
There is nothing in the changelog between 2.080.0 and 2.082.0 for
changes to std.file.
Version from July 2017[0]. Version from 2.082.0[1]. They look the same
to me.
[0]
https://github.com/dlang/phobos/blob/d8959320e0c47a1861e32bbbf6a3ba30a019798e/std/file.d#L3430
[1] https://github.com/dlang/phobos/blob/v2.082.0/std/file.d#L4216
Mayb I'm wrong, but what I can say is that I've recently updated DMD and
compiled a windows build of Resync, and that I *HAD* to make
Windows-specific code that removes the "read-only" attributes only on
Windows.
attributes = source_file_path.getAttributes();
source_file_path.getTimes( access_time, modification_time );
version ( Windows )
{
if ( target_file_path.exists() )
{
target_file_path.setAttributes( attributes & ~1 );
}
source_file_path.copy( target_file_path, PreserveAttributes.no );
target_file_path.setAttributes( attributes & ~1 );
target_file_path.setTimes( access_time, modification_time );
target_file_path.setAttributes( attributes );
}
else
{
if ( target_file_path.exists() )
{
target_file_path.setAttributes( 511 );
}
source_file_path.copy( target_file_path, PreserveAttributes.no );
target_file_path.setAttributes( attributes );
target_file_path.setTimes( access_time, modification_time );
}
Honestly I don't see why I have to make this ugly fix on Windows, while
the Linux version has always worked fine on read-only files.
Hang on a second.
assert(preserve == Yes.preserveAttributes);
Something is smelling an awful lot here.
Up to Windows 7 CopyFileW which is used for Windows didn't copy the
attributes over[0] but it does now.
This is a bug on our end, which should include a fallback to copying
manually the file contents over.
[0]
https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-copyfilew
Re: D is dead
On Tuesday, 4 September 2018 at 09:56:13 UTC, rikki cattermole
wrote:
On 04/09/2018 9:40 PM, Ecstatic Coder wrote:
But it seems that the latest version of "std.file.copy" now
completely ignores the "PreserveAttributes.no" argument on
Windows, which made recent Windows builds of Resync fail on
read-only files.
What???
There is nothing in the changelog between 2.080.0 and 2.082.0
for changes to std.file.
Version from July 2017[0]. Version from 2.082.0[1]. They look
the same to me.
[0]
https://github.com/dlang/phobos/blob/d8959320e0c47a1861e32bbbf6a3ba30a019798e/std/file.d#L3430
[1]
https://github.com/dlang/phobos/blob/v2.082.0/std/file.d#L4216
Mayb I'm wrong, but what I can say is that I've recently updated
DMD and compiled a windows build of Resync, and that I *HAD* to
make Windows-specific code that removes the "read-only"
attributes only on Windows.
attributes = source_file_path.getAttributes();
source_file_path.getTimes( access_time, modification_time );
version ( Windows )
{
if ( target_file_path.exists() )
{
target_file_path.setAttributes( attributes & ~1 );
}
source_file_path.copy( target_file_path,
PreserveAttributes.no );
target_file_path.setAttributes( attributes & ~1 );
target_file_path.setTimes( access_time, modification_time );
target_file_path.setAttributes( attributes );
}
else
{
if ( target_file_path.exists() )
{
target_file_path.setAttributes( 511 );
}
source_file_path.copy( target_file_path,
PreserveAttributes.no );
target_file_path.setAttributes( attributes );
target_file_path.setTimes( access_time, modification_time );
}
Honestly I don't see why I have to make this ugly fix on Windows,
while the Linux version has always worked fine on read-only files.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Tuesday, 4 September 2018 at 09:40:23 UTC, Ecstatic Coder wrote: But it seems that the latest version of "std.file.copy" now completely ignores the "PreserveAttributes.no" argument on Windows, which made recent Windows builds of Resync fail on read-only files. Very typical... While D remains my favorite file scripting language, I must admit that this is quite disappointing for such an old language, compared to similar languages like Crystal. Windows can simply be a pain to work with though. Look at Crystal itself, it doesn't support Windows natively as far as I know, so of course you won't have Windows-specific bugs in Crystal...
Re: D is dead
On Thursday, 23 August 2018 at 06:34:01 UTC, nkm1 wrote: On Thursday, 23 August 2018 at 05:37:12 UTC, Shachar Shemesh wrote: Let's start with this one: https://issues.dlang.org/show_bug.cgi?id=14246#c6 The problems I'm talking about are not easily fixable. They stem from features not playing well together. One that hurt me lately was a way to pass a scoped lazy argument (i.e. - to specify that the implicit delegate need not allocate its frame, because it is not used outside the function call). The only real problem with D is that it's a language designed with GC in mind, yet there are numerous attempts to use it without GC. Also, supporting GC-less programming gets in the way of improving D's GC (which is pretty damn bad by modern standards). That's the only real technical problem. For example, the "bug" above just means that D doesn't support RAII (in the C++ sense). That's hardly a *fatal flaw*. Lots of languages don't support RAII. Python, Java, C# - tons of code were written in those. And yes, most of those just use GC to dispose of memory - other resources are rarely used (compared to memory) and it's not a problem to manage them manually. You also mentioned lazy parameters allocating... GC thing again. Just allocate then? No? IMO, if getting the maximum number of users is the main goal, D is indeed going the wrong way. It would be better to get rid of @nogc, betterC, dip1000, implement write barriers and use them to improve GC. Martin Nowak (I think) mentioned that write barriers will decrease performance of D programs by 1-5%. Seems like a small price to pay for better GC with shorter pauses. It would also probably be simpler technically than stuff like dip1000 and rewriting Phobos. Of course, maximizing the number of users is not the only goal, or even the main one. My understanding is that Walter wants a "systems language" with "zero cost abstractions". Well, it's very well possible that D's design precludes that. Other than memory management, I don't see any real fundamental problems. +1 Making D a "true" C++ competitor is not going to happen soon. Even Rust, which IS by definition a true C++ competitor (no GC, etc), will still find it very hard to replace C++ in its current niche markets, like embedded and game development. While putting all the "funded" efforts in making D a *direct* competitor to GC languages (like Go, Crystal, C#, Java, etc) would be an achievable goal, IMHO...
Re: D is dead
On 04/09/2018 9:40 PM, Ecstatic Coder wrote: But it seems that the latest version of "std.file.copy" now completely ignores the "PreserveAttributes.no" argument on Windows, which made recent Windows builds of Resync fail on read-only files. What??? There is nothing in the changelog between 2.080.0 and 2.082.0 for changes to std.file. Version from July 2017[0]. Version from 2.082.0[1]. They look the same to me. [0] https://github.com/dlang/phobos/blob/d8959320e0c47a1861e32bbbf6a3ba30a019798e/std/file.d#L3430 [1] https://github.com/dlang/phobos/blob/v2.082.0/std/file.d#L4216
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote: On 22/08/18 21:34, Ali wrote: On Wednesday, 22 August 2018 at 17:42:56 UTC, Joakim wrote: Pretty positive overall, and the negatives he mentions are fairly obvious to anyone paying attention. Yea, I agree, the negatives are not really negative Walter not matter how smart he is, he is one man who can work on the so many things at the same time Its a chicken and egg situation, D needs more core contributors, and to get more contributors it needs more users, and to get more users it need more core contributors No, no and no. I was holding out on replying to this thread to see how the community would react. The vibe I'm getting, however, is that the people who are seeing D's problems have given up on affecting change. It is no secret that when I joined Weka, I was a sole D detractor among a company quite enamored with the language. I used to have quite heated water cooler debates about that point of view. Every single one of the people rushing to defend D at the time has since come around. There is still some debate on whether, points vs. counter points, choosing D was a good idea, but the overwhelming consensus inside Weka today is that D has *fatal* flaws and no path to fixing them. And by "fatal", I mean literally flaws that are likely to literally kill the language. And the thing that brought them around is not my power of persuasion. The thing that brought them around was spending a couple of years working with the language on an every-day basis. And you will notice this in the way Weka employees talk on this forum: except me, they all disappeared. You used to see Idan, Tomer and Eyal post here. Where are they? This forum is hostile to criticism, and generally tries to keep everyone using D the same way. If you're cutting edge D, the forum is almost no help at all. Consensus among former posters here is that it is generally a waste of time, so almost everyone left, and those who didn't, stopped posting. And it's not just Weka. I've had a chance to talk in private to some other developers. Quite a lot have serious, fundamental issues with the language. You will notice none of them speaks up on this thread. They don't see the point. No technical project is born great. If you want a technical project to be great, the people working on it have to focus on its *flaws*. The D's community just doesn't do that. To sum it up: fatal flaws + no path to fixing + no push from the community = inevitable eventual death. With great regrets, Shachar Same feeling here btw. I regularly have to face strange bugs while updating the compiler or its libraries. For instance, my Resync tool used to work fine both on Windows and Linux. But it seems that the latest version of "std.file.copy" now completely ignores the "PreserveAttributes.no" argument on Windows, which made recent Windows builds of Resync fail on read-only files. Very typical... While D remains my favorite file scripting language, I must admit that this is quite disappointing for such an old language, compared to similar languages like Crystal.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Tuesday, 4 September 2018 at 05:38:49 UTC, Iain Buclaw wrote: On 4 September 2018 at 04:19, Laeeth Isharc via Digitalmars-d wrote: On Monday, 3 September 2018 at 16:07:21 UTC, RhyS wrote: A good example being the resources going into DMD, LDC, GDC... 3 Compilers for one language, when even well funded languages stick to one compiler. And now some people think its a good idea to have DMD also cross compile because "its not hard to do". No, maybe not but who will do all the testing, what resources are going to spend when things do not work for some users ( and the negative impact on their experience )... Its a long list but people do not look past this. It sounds like fun, lets think / or do it. What resources do you think go into GDC? I think Iain would love to hear about all these resources because I am not sure he has been made aware of them because they don't exist beyond him and possibly a tiny number of others helping in part at certain stages. *Looks behind self* *Looks under desk* *Looks under keyboard* There must be resources somewhere, but none appear to be within reach. :-) If Iain had a beer for every person that complained about the effort spent by team GDC without having first thanked him and his vast team then... People are sometimes quite disconnected from reality. At least I have no other explanation for people demanding others do this or do that without doing the minimum necessary to make it appealing for others to work on it. I mean my experience is that you can pay people a lot of money and ask them beforehand do you want to work on X, and it's no guarantee they actually will be willing to when it comes to it. Programmers in general can be very independent-minded people, and if somebody is looking for especially meek and compliant people then if you have come to the D forums you are in the wrong place! One can be much more persuasive with positive words than complaints. Most people are well aware of that so if they are complaining it's in my judgement because they want to complain. People with high standards will do that when they feel powerless. I'm not talking here about notorious highly intelligent trolls like Ola and sock-puppets who never seem to actually write code in D. But nobody who can keep up here is powerless. It's possible to change the world you know, and from the most unpromising start. Forget about what's realistic, and focus on what you want to achieve. Believe me, you can achieve an awful lot from the most unpromising start. People talk about how most people are not super-hackers and one shouldn't expect them to manage without polish. Well hacker is a state of mind,a way of being in the world. Ask Iain if his self-conception is as a super-hacker with l33t skillz that a mere professional programmer couldn't match and you might be surprised (I think his self-conception might be wrong, but that's Dunning Kruger in action for you). It's really much more about values and virtues then capabilities. Are you able to tolerate discomfort and the accurate initial feeling of conscious incompetence? Because that's what real learning feels like once you leave the spoon-feeding stream of education. D is a gift to the world from Walter, Andrei, and those who contributed after it was begun. Just demanding people do stuff for you without doing anything to contribute back - that's not how life works. I don't think I have ever seen this degree of a feeling of entitlement in my life! And I've been working in finance since 1993. If doesn't want to pay money towards the development of IDE integration, doesn't want to do any work themselves, then the least they could do is draw up a feature list of what's missing and find a way to help from time to time with the organisation of the work. That's the only way things ever get done anyway. Have you noticed how the documentation has gotten much better? Runnable examples too. Did that happen because people complained? No - it happened because Seb Wilzbach (and maybe others) took the initiative to make it happen and did the work themselves. A little money goes a long way in open source. So if you're a company and you're complaining and not donating money to the Foundation then what exactly do you expect? We have a few support contracts with MongoDB (a choice made before I got involved) and the legal fees alone were 20k and we pay about 30k USD a year. If a few companies contributed at that scale to the Foundation that's at least a couple of full-time developers. And if you disagree with Andrei and Walter choices about priorities you know you can just direct where the money should be spent as we are with SAoC.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 16:41:32 UTC, Iain Buclaw wrote: 15 years ago, people were complaining that there was only one D compiler. It is ironic that people now complain that there's too many. One needs multiple implementations to confirm the accuracy of the language specification. D still has one implementation, i.e. one compiler with multiple backends, distributed as multiple executables (with tweaks). Anyway, I think people complained about the first and only compiler being non-free. That's not relevant now, of course.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Tuesday, 4 September 2018 at 01:36:53 UTC, Mike Parker wrote: On Monday, 3 September 2018 at 18:26:57 UTC, Chris wrote: I think this sort of misunderstanding is the source of a lot of friction on this forum. Some users think (or in my case: thought) that D will be a sound and stable language one day, a language they can use for loads of stuff, while the leadership prefers to keep it at a stage where they can test ideas to see what works and what doesn't, wait let me rephrase this, where the user can test other people's ideas with every new release. First of all, thanks a lot for your answer. I appreciate it. I have to know where I'm standing in order to be able to plan ahead. I don't think this is unreasonable. D is not a petri dish for testing ideas. It's not an experiment. It's a serious language. Walter, Andrei, and everyone involved in maintaining and developing it want to see it succeed. They aren't just treading water, wasting everyone's time. And I know you keep hearing this, but I'll say it anyway: most of the development is based on volunteer work, and trying to get volunteers to do anything they don't want to do is like asking them to voluntarily have their teeth pulled when they don't need to. I have no doubt at all that Walter, Andrei et al are a 100% serious about D, as in "a professional tool" and I do not question their expertise and experience. However, for a bit more than a year I've been under the impression that scarce resources are spent on features and details that are not critical to production when you use D, while more basic things that are sometimes not related to D as such are put on the long finger. Walter has said that people come to him and ask what they should work on. He provides them with a list of priority tasks. Then they go off and work on something else. That's the nature of unsponsored open-source development and has been the biggest challenge for D for years. I can imagine that. This is why volunteers are not the way to go when it comes to core development and the ecosystem. This is why foundations with a lot of funding and IT companies spend a lot of resources on these two aspects. I have high hopes that some of this can be turned around by raising more money and I have long-term plans to try and facilitate that over the coming months. With more money, we can get people to work on targeted tasks even when they have no vested interest in it. We can pull in full-time coders, maybe get someone to oversee PR reviews so they don't stay open so long, fund development of broader ecosystem projects. There isn't anyone involved in the core D development who isn't aware of the broader issues in the community or the ecosystem, and they are working to bring improvements. I have been around this community since 2003. From my perspective, it has been one continuous march of progress. Sometimes slow, sometimes fast, but always moving, always getting better. And right now there are more people involved than ever in moving it forward. Unfortunately, there are also more demands on more fronts than ever. There are longtime users who become increasingly frustrated when the issues that matter to them still aren't resolved, newcomers who have no context of all the progress that has been made and instead hold D in comparison to Rust, Go, and other languages that have stronger backing and more manpower. That's perfectly legitimate. Which is what I've been talking about in this thread. D is too old to live with its parents :) Too many people already use it in production or are interested in it. There are a) longtime users who still have to put up with OSS style hacks and are growing tired of it (after years of putting in a lot of effort). There are b) new users who are put off by the lack of a smooth ecosystem. And both groups are told that "that's the way we do things around here". And of course, low manpower and funding aren't the complete picture. Management also play a role. Both Walter and Andrei have freely admitted they are not managers and that they're learning as they go. Mistakes have been made. In hindsight, some decisions should have gone a different way. But that is not the same as not caring, or not understanding/ Exactly. As I said in an earlier message, it's not just the money (or the lack thereof), it's the approach. In my opinion Both Walter and Andrei should hire a manager who is not involved in the core development. If you're involved in the core development you cannot be managing things at the same time and "learn as you go along". That's a recipe for disaster. It's not a good idea to mix management and development because they are two completely different things, and you might end up not being good at any of them. A manager could lay down a practical road map based on what users need _most_, secure funding and direct the funding towards the most urgent issues. Everyone
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Tuesday, 4 September 2018 at 01:36:53 UTC, Mike Parker wrote: D is not a petri dish for testing ideas. It's not an experiment. Well, the general consensus for programming languages is that it a language is experimental (or proprietary) until it is fully specced out as a stable formal standard with multiple _independent_ implementations...
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Tuesday, 4 September 2018 at 02:19:20 UTC, Laeeth Isharc wrote: On Monday, 3 September 2018 at 16:07:21 UTC, RhyS wrote: On Monday, 3 September 2018 at 15:41:48 UTC, Laurent Tréguier wrote: Yes. It almost sounds like a smooth experience would be a bad thing to have, especially with the classic "you don't need an IDE anyway" speech. Editing experience seems often dismissed as unimportant, when it's one of the first things new users will come across when trying out D. First impressions can matter a lot. I didn't give a you don't need an IDE speech, and I didn't say a smooth experience was a bad thing. I know, I know. But it's always the same story, whenever people wonder about D's state in IDE integration, often other people will just say that vim + terminal is enough. But in my experience a strong reality orientation leads to good things coming out of life and telling the universe it should be something different from what it is is a recipe for misery and suffering, and why would you do that to yourself? So if you want the world to be different, come up with a plan. It could be I am going to donate X dollars a month to the Foundation to fund IDE development, or if could be figuring out how you can help with the work in whatever way. But just grumbling - I really think that mistakes the nature of the situation, and not to mention human psychology. You can accomplish things with a vision that's thought through and inspires others. Negativity is part of being creative but not if you stop there. I stated it in an earlier post, I've been working on editor/IDE integration myself because of this. I don't just grumble, although I do like grumbling a lot :)
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 22:30:47 UTC, Chris wrote: On Monday, 3 September 2018 at 18:52:45 UTC, Laurent Tréguier wrote: On Monday, 3 September 2018 at 18:26:57 UTC, Chris wrote: it should come with a warning label that says "D is in many parts still at an experimental stage and ships with no guarantees whatsoever. Use at your own risk." Well it comes with the Boost license that says: `THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND` You know exactly what I mean, don't you? I think I know what you mean. But licenses are not decorative. If it says "WITHOUT WARRANTY OF ANY KIND", it means that it actually comes without warranty of any kind.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On 4 September 2018 at 04:19, Laeeth Isharc via Digitalmars-d wrote: > On Monday, 3 September 2018 at 16:07:21 UTC, RhyS wrote: >> >> A good example being the resources going into DMD, LDC, GDC... 3 Compilers >> for one language, when even well funded languages stick to one compiler. And >> now some people think its a good idea to have DMD also cross compile because >> "its not hard to do". No, maybe not but who will do all the testing, what >> resources are going to spend when things do not work for some users ( and >> the negative impact on their experience )... Its a long list but people do >> not look past this. It sounds like fun, lets think / or do it. > > > What resources do you think go into GDC? I think Iain would love to hear > about all these resources because I am not sure he has been made aware of > them because they don't exist beyond him and possibly a tiny number of > others helping in part at certain stages. > *Looks behind self* *Looks under desk* *Looks under keyboard* There must be resources somewhere, but none appear to be within reach. :-)
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Mon, 3 Sep 2018 at 19:35, Laeeth Isharc via Digitalmars-d wrote: > > On Tuesday, 4 September 2018 at 02:24:25 UTC, Manu wrote: > > On Mon, 3 Sep 2018 at 18:45, Laeeth Isharc via Digitalmars-d > > wrote: > >> > >> On Monday, 3 September 2018 at 17:15:03 UTC, Laurent Tréguier > >> wrote: > >> > On Monday, 3 September 2018 at 16:55:10 UTC, Jonathan M > >> > Davis wrote: > >> >> Most of the work that gets done is the stuff that the folks > >> >> contributing think is the most important - frequently what > >> >> is most important for them for what they do, and very few > >> >> (if any) of the major contributors use or care about IDEs > >> >> for their own use. And there's tons to do that has nothing > >> >> to do with IDEs. There are folks who care about it enough > >> >> to work on it, which is why projects such as VisualD exist > >> >> at all, and AFAIK, they work reasonably well, but the only > >> >> two ways that they're going to get more work done on them > >> >> than is currently happening is if the folks who care about > >> >> that sort of thing contribute or if they donate money for > >> >> it to be worked on. Not long ago, the D Foundation > >> >> announced that they were going to use donations to pay > >> >> someone to work on his plugin for Visual Studio Code: > >> >> > >> >> https://forum.dlang.org/post/rmqvglgccmgoajmhy...@forum.dlang.org > >> >> > >> >> So, if you want stuff like that to get worked on, then > >> >> donate or pitch in. > >> >> > >> >> The situation with D - both with IDEs and in general - has > >> >> improved greatly over time even if it may not be where you > >> >> want it to be. But if you're ever expecting IDE support to > >> >> be a top priority of many of the contributors, then you're > >> >> going to be sorely disappointed. It's the sort of thing > >> >> that we care about because we care about D being > >> >> successful, but it's not the sort of thing that we see any > >> >> value in whatsoever for ourselves, and selfish as it may > >> >> be, when we spend the time to contribute to D, we're > >> >> generally going to work on the stuff that we see as having > >> >> the most value for getting done what we care about. And > >> >> there's a lot to get done which impacts pretty much every D > >> >> user and not just those who want something that's > >> >> IDE-related. > >> >> > >> >> - Jonathan M Davis > >> > > >> > The complaints I have is exactly why I'm myself maintaining > >> > plugins for VSCode, Atom, and others soon. Don't worry, I > >> > still > >> > think D is worth putting some time and effort into and I know > >> > actions generally get more things done than words. > >> > I also know that tons of stuff is yet to be done in regards > >> > to > >> > the actual compilers and such. > >> > > >> > It just baffles me a bit to see the state of D in this > >> > department, when languages like Go or Rust (hooray for yet > >> > another comparison to Go and Rust) are a lot younger, but > >> > already have what looks like very good tooling. > >> > Then again they do have major industry players backing them > >> > though... > >> > >> Why is Go's IDE support baffling? It was a necessity to > >> achieve Google's commercial aims, I should think. > >> > >> " > >> The key point here is our programmers are Googlers, they’re not > >> researchers. They’re typically, fairly young, fresh out of > >> school, probably learned Java, maybe learned C or C++, probably > >> learned Python. They’re not capable of understanding a > >> brilliant > >> language but we want to use them to build good software. So, > >> the > >> language that we give them has to be easy for them to > >> understand > >> and easy to adopt." > >> – Rob Pike > >> > >> I don't know the story of Rust, but if I were working on a > >> project as large as Firefox I guess I would want an IDE too! > >> Whereas it doesn't seem like it's so important to some of D's > >> commercial users because they have a different context. > >> > >> I don't think it's overall baffling that D hasn't got the best > >> IDE support of emerging languages. The people that contribute > >> to it, as Jonathan says, seen to be leas interested in IDEs > >> and no company has found it important enough to pay someone > >> else to work on it. So far anyway but as adoption grows maybe > >> that will change. > > > > It's been a key hurdle for as long as I've been around here. > > I've been saying for 10 years that no company I've ever worked > > at can > > take D seriously without industry standard IDE support. > > My feeling is that we have recently reached MVP status... > > that's a > > huge step, 10 years in the making ;) > > I think it's now at a point where more people *wouldn't* reject > > it on > > contact than those who would. But we need to go much further to > > make > > developers genuinely comfortable, and thereby go out of their > > way to > > prefer using D than C++ and pitch as such to their managers. > > Among all developers I've demo-ed or
Re: D is dead
On 9/3/2018 7:19 PM, Laeeth Isharc wrote: The way for D to appeal to more people is not to address the complaints of those who spend more time writing on the forum grumbling but don't use it much, because in my experience you do much better appealing to the people who are your best customers than to those who tell you if only you could do X there would be huge demand. I think that has been Walter's experience too. I've bin in this business a long time. Fun anecdotes: --- I was out jogging with a colleague in the 1990's one day. He said what the world really needs, and what he really needed, was a Java implementation that generated native code. It would set the world on fire! I told him I wrote one, he could get it today from Symantec. He never said another word on the subject. It turns out nobody wanted a native Java compiler. --- Back in the old Datalight days in the 1980s, a big customer said they couldn't use Datalight C because it didn't have Feature X. If only it had X, they'd place a Big Order. So I implemented X, and excitedly showed it to them and asked for the Big Order. They hemmed and hawed, then said what they really needed was Feature Y! After that, I was a lot less credulous of dangling promises of a Big Order. I'd often say sure, and ask for an advance on the order, which worked well at filtering out the chain-jerking. --- Related to me by a friend: X told me that what he really wanted in a C++ compiler was compile speed. It was the most important feature. He went on and on about it. I laughed and said that compile speed was at the bottom of his list. He looked perplexed, and asked how could I say that? I told him that he was using Cfront, a translator, with Microsoft C as the backend, a combination that compiled 4 times slower than Zortech C++, and didn't have critical (for DOS) features like near/far pointers. What he really regarded as the most important feature was being a name brand. --- Henry Ford said that his market research suggested that people wanted a faster horse. --- Trying to figure out where we should allocate our scarce resources is probably the most difficult task I face. I know it looks easy, but it is all too easy to wind up with a faster horse when everyone else developed a car.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Tuesday, 4 September 2018 at 02:24:25 UTC, Manu wrote: On Mon, 3 Sep 2018 at 18:45, Laeeth Isharc via Digitalmars-d wrote: On Monday, 3 September 2018 at 17:15:03 UTC, Laurent Tréguier wrote: > On Monday, 3 September 2018 at 16:55:10 UTC, Jonathan M > Davis wrote: >> Most of the work that gets done is the stuff that the folks >> contributing think is the most important - frequently what >> is most important for them for what they do, and very few >> (if any) of the major contributors use or care about IDEs >> for their own use. And there's tons to do that has nothing >> to do with IDEs. There are folks who care about it enough >> to work on it, which is why projects such as VisualD exist >> at all, and AFAIK, they work reasonably well, but the only >> two ways that they're going to get more work done on them >> than is currently happening is if the folks who care about >> that sort of thing contribute or if they donate money for >> it to be worked on. Not long ago, the D Foundation >> announced that they were going to use donations to pay >> someone to work on his plugin for Visual Studio Code: >> >> https://forum.dlang.org/post/rmqvglgccmgoajmhy...@forum.dlang.org >> >> So, if you want stuff like that to get worked on, then >> donate or pitch in. >> >> The situation with D - both with IDEs and in general - has >> improved greatly over time even if it may not be where you >> want it to be. But if you're ever expecting IDE support to >> be a top priority of many of the contributors, then you're >> going to be sorely disappointed. It's the sort of thing >> that we care about because we care about D being >> successful, but it's not the sort of thing that we see any >> value in whatsoever for ourselves, and selfish as it may >> be, when we spend the time to contribute to D, we're >> generally going to work on the stuff that we see as having >> the most value for getting done what we care about. And >> there's a lot to get done which impacts pretty much every D >> user and not just those who want something that's >> IDE-related. >> >> - Jonathan M Davis > > The complaints I have is exactly why I'm myself maintaining > plugins for VSCode, Atom, and others soon. Don't worry, I > still > think D is worth putting some time and effort into and I know > actions generally get more things done than words. > I also know that tons of stuff is yet to be done in regards > to > the actual compilers and such. > > It just baffles me a bit to see the state of D in this > department, when languages like Go or Rust (hooray for yet > another comparison to Go and Rust) are a lot younger, but > already have what looks like very good tooling. > Then again they do have major industry players backing them > though... Why is Go's IDE support baffling? It was a necessity to achieve Google's commercial aims, I should think. " The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." – Rob Pike I don't know the story of Rust, but if I were working on a project as large as Firefox I guess I would want an IDE too! Whereas it doesn't seem like it's so important to some of D's commercial users because they have a different context. I don't think it's overall baffling that D hasn't got the best IDE support of emerging languages. The people that contribute to it, as Jonathan says, seen to be leas interested in IDEs and no company has found it important enough to pay someone else to work on it. So far anyway but as adoption grows maybe that will change. It's been a key hurdle for as long as I've been around here. I've been saying for 10 years that no company I've ever worked at can take D seriously without industry standard IDE support. My feeling is that we have recently reached MVP status... that's a huge step, 10 years in the making ;) I think it's now at a point where more people *wouldn't* reject it on contact than those who would. But we need to go much further to make developers genuinely comfortable, and thereby go out of their way to prefer using D than C++ and pitch as such to their managers. Among all developers I've demo-ed or introduced recently, I can say for certain that developer enthusiasm is driven by their perception of the tooling in the order of 10x more than the language. That's only because you insist on working for companies where people use IDEs and think the ones that don't must be in boring industries :) Kidding aside, would you care to enumerate what capabilities are missing that would tip the balance for such people were they to be there? And then would you care to estimate the degree of
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Mon, 3 Sep 2018 at 18:45, Laeeth Isharc via Digitalmars-d wrote: > > On Monday, 3 September 2018 at 17:15:03 UTC, Laurent Tréguier > wrote: > > On Monday, 3 September 2018 at 16:55:10 UTC, Jonathan M Davis > > wrote: > >> Most of the work that gets done is the stuff that the folks > >> contributing think is the most important - frequently what is > >> most important for them for what they do, and very few (if > >> any) of the major contributors use or care about IDEs for > >> their own use. And there's tons to do that has nothing to do > >> with IDEs. There are folks who care about it enough to work on > >> it, which is why projects such as VisualD exist at all, and > >> AFAIK, they work reasonably well, but the only two ways that > >> they're going to get more work done on them than is currently > >> happening is if the folks who care about that sort of thing > >> contribute or if they donate money for it to be worked on. Not > >> long ago, the D Foundation announced that they were going to > >> use donations to pay someone to work on his plugin for Visual > >> Studio Code: > >> > >> https://forum.dlang.org/post/rmqvglgccmgoajmhy...@forum.dlang.org > >> > >> So, if you want stuff like that to get worked on, then donate > >> or pitch in. > >> > >> The situation with D - both with IDEs and in general - has > >> improved greatly over time even if it may not be where you > >> want it to be. But if you're ever expecting IDE support to be > >> a top priority of many of the contributors, then you're going > >> to be sorely disappointed. It's the sort of thing that we care > >> about because we care about D being successful, but it's not > >> the sort of thing that we see any value in whatsoever for > >> ourselves, and selfish as it may be, when we spend the time to > >> contribute to D, we're generally going to work on the stuff > >> that we see as having the most value for getting done what we > >> care about. And there's a lot to get done which impacts pretty > >> much every D user and not just those who want something that's > >> IDE-related. > >> > >> - Jonathan M Davis > > > > The complaints I have is exactly why I'm myself maintaining > > plugins for VSCode, Atom, and others soon. Don't worry, I still > > think D is worth putting some time and effort into and I know > > actions generally get more things done than words. > > I also know that tons of stuff is yet to be done in regards to > > the actual compilers and such. > > > > It just baffles me a bit to see the state of D in this > > department, when languages like Go or Rust (hooray for yet > > another comparison to Go and Rust) are a lot younger, but > > already have what looks like very good tooling. > > Then again they do have major industry players backing them > > though... > > Why is Go's IDE support baffling? It was a necessity to achieve > Google's commercial aims, I should think. > > " > The key point here is our programmers are Googlers, they’re not > researchers. They’re typically, fairly young, fresh out of > school, probably learned Java, maybe learned C or C++, probably > learned Python. They’re not capable of understanding a brilliant > language but we want to use them to build good software. So, the > language that we give them has to be easy for them to understand > and easy to adopt." > – Rob Pike > > I don't know the story of Rust, but if I were working on a > project as large as Firefox I guess I would want an IDE too! > Whereas it doesn't seem like it's so important to some of D's > commercial users because they have a different context. > > I don't think it's overall baffling that D hasn't got the best > IDE support of emerging languages. The people that contribute to > it, as Jonathan says, seen to be leas interested in IDEs and no > company has found it important enough to pay someone else to work > on it. So far anyway but as adoption grows maybe that will > change. It's been a key hurdle for as long as I've been around here. I've been saying for 10 years that no company I've ever worked at can take D seriously without industry standard IDE support. My feeling is that we have recently reached MVP status... that's a huge step, 10 years in the making ;) I think it's now at a point where more people *wouldn't* reject it on contact than those who would. But we need to go much further to make developers genuinely comfortable, and thereby go out of their way to prefer using D than C++ and pitch as such to their managers. Among all developers I've demo-ed or introduced recently, I can say for certain that developer enthusiasm is driven by their perception of the tooling in the order of 10x more than the language.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 16:07:21 UTC, RhyS wrote: On Monday, 3 September 2018 at 15:41:48 UTC, Laurent Tréguier wrote: Yes. It almost sounds like a smooth experience would be a bad thing to have, especially with the classic "you don't need an IDE anyway" speech. Editing experience seems often dismissed as unimportant, when it's one of the first things new users will come across when trying out D. First impressions can matter a lot. I didn't give a you don't need an IDE speech, and I didn't say a smooth experience was a bad thing. But in my experience a strong reality orientation leads to good things coming out of life and telling the universe it should be something different from what it is is a recipe for misery and suffering, and why would you do that to yourself? So if you want the world to be different, come up with a plan. It could be I am going to donate X dollars a month to the Foundation to fund IDE development, or if could be figuring out how you can help with the work in whatever way. But just grumbling - I really think that mistakes the nature of the situation, and not to mention human psychology. You can accomplish things with a vision that's thought through and inspires others. Negativity is part of being creative but not if you stop there. Its the same issue why Linux as a Desktop has been stuck with almost no growth. Its easy to break things ( nvidia graphical driver *lol* ), too much is so focused on the Cli that people who do have a issue and are not system users quick run into a flooding swamp. Too much resources split among too many distributions, graphical desktops etc. Choice is good but too much choice means projects are starved for resources, comparability are issues, bugs are even more present, ... Chrome books and Android seem to be doing okay. I run Linux on the desktop and have done full-time since 2014. Maybe you're right that it's not for everyone at this point. And so ? There just wasn't a path for people to put effort into making it utterly easy for non technical people beyond a certain point. Does that mean Linux or Linux on the desktop has failed? I don't think so. It's just not for everyone. It's interesting to see Microsoft making it possible to run Linux on Windows - turns out a minority audience can be an important audience. A good example being the resources going into DMD, LDC, GDC... 3 Compilers for one language, when even well funded languages stick to one compiler. And now some people think its a good idea to have DMD also cross compile because "its not hard to do". No, maybe not but who will do all the testing, what resources are going to spend when things do not work for some users ( and the negative impact on their experience )... Its a long list but people do not look past this. It sounds like fun, lets think / or do it. What resources do you think go into GDC? I think Iain would love to hear about all these resources because I am not sure he has been made aware of them because they don't exist beyond him and possibly a tiny number of others helping in part at certain stages. Its just so frustrating that a lot of people here do not understand. Most programmers are not open-source developers, they are not coding gods, they are simply people who want things to good smooth. Install compiler, install good supported graphical IDE ( and no, VIM does not count! ), read up some simple documentation and off we go... We are not looking to be bug testers, core code implementer's, etc... Sure, and probably most people would be better off at this point using a language that makes getting started easy. One doesn't need to appeal to most people to succeed. That's just a pragmatic statement of the obvious. In time it will change but j don't see how recognising your observation could rationally lead anyone to do something differently from what they would have done before. To change the world you need a goal and a first cut at a plan for getting there. Whether the goal is entirely realistic is much less important than having a plan to begin. And I speak from experience here having at certain points not much more than that. Selfish, ... sure ... but this is how D gain more people. The more people work with your language, the more potential people you have that slowly are interested in helping out. I disagree. At this point the way for D to appeal to more people is to increase its appeal just a bit more to those who are already on the cusp of using D or would be if they had looked into it and to those who use D already in some way but could use it more. The way for D to appeal to more people is not to address the complaints of those who spend more time writing on the forum grumbling but don't use it much, because in my experience you do much better appealing to the people who are your best customers than to those who tell you if only you could do X there
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 17:15:03 UTC, Laurent Tréguier wrote: On Monday, 3 September 2018 at 16:55:10 UTC, Jonathan M Davis wrote: Most of the work that gets done is the stuff that the folks contributing think is the most important - frequently what is most important for them for what they do, and very few (if any) of the major contributors use or care about IDEs for their own use. And there's tons to do that has nothing to do with IDEs. There are folks who care about it enough to work on it, which is why projects such as VisualD exist at all, and AFAIK, they work reasonably well, but the only two ways that they're going to get more work done on them than is currently happening is if the folks who care about that sort of thing contribute or if they donate money for it to be worked on. Not long ago, the D Foundation announced that they were going to use donations to pay someone to work on his plugin for Visual Studio Code: https://forum.dlang.org/post/rmqvglgccmgoajmhy...@forum.dlang.org So, if you want stuff like that to get worked on, then donate or pitch in. The situation with D - both with IDEs and in general - has improved greatly over time even if it may not be where you want it to be. But if you're ever expecting IDE support to be a top priority of many of the contributors, then you're going to be sorely disappointed. It's the sort of thing that we care about because we care about D being successful, but it's not the sort of thing that we see any value in whatsoever for ourselves, and selfish as it may be, when we spend the time to contribute to D, we're generally going to work on the stuff that we see as having the most value for getting done what we care about. And there's a lot to get done which impacts pretty much every D user and not just those who want something that's IDE-related. - Jonathan M Davis The complaints I have is exactly why I'm myself maintaining plugins for VSCode, Atom, and others soon. Don't worry, I still think D is worth putting some time and effort into and I know actions generally get more things done than words. I also know that tons of stuff is yet to be done in regards to the actual compilers and such. It just baffles me a bit to see the state of D in this department, when languages like Go or Rust (hooray for yet another comparison to Go and Rust) are a lot younger, but already have what looks like very good tooling. Then again they do have major industry players backing them though... Why is Go's IDE support baffling? It was a necessity to achieve Google's commercial aims, I should think. " The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." – Rob Pike I don't know the story of Rust, but if I were working on a project as large as Firefox I guess I would want an IDE too! Whereas it doesn't seem like it's so important to some of D's commercial users because they have a different context. I don't think it's overall baffling that D hasn't got the best IDE support of emerging languages. The people that contribute to it, as Jonathan says, seen to be leas interested in IDEs and no company has found it important enough to pay someone else to work on it. So far anyway but as adoption grows maybe that will change.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 18:26:57 UTC, Chris wrote: I think this sort of misunderstanding is the source of a lot of friction on this forum. Some users think (or in my case: thought) that D will be a sound and stable language one day, a language they can use for loads of stuff, while the leadership prefers to keep it at a stage where they can test ideas to see what works and what doesn't, wait let me rephrase this, where the user can test other people's ideas with every new release. D is not a petri dish for testing ideas. It's not an experiment. It's a serious language. Walter, Andrei, and everyone involved in maintaining and developing it want to see it succeed. They aren't just treading water, wasting everyone's time. And I know you keep hearing this, but I'll say it anyway: most of the development is based on volunteer work, and trying to get volunteers to do anything they don't want to do is like asking them to voluntarily have their teeth pulled when they don't need to. Walter has said that people come to him and ask what they should work on. He provides them with a list of priority tasks. Then they go off and work on something else. That's the nature of unsponsored open-source development and has been the biggest challenge for D for years. I have high hopes that some of this can be turned around by raising more money and I have long-term plans to try and facilitate that over the coming months. With more money, we can get people to work on targeted tasks even when they have no vested interest in it. We can pull in full-time coders, maybe get someone to oversee PR reviews so they don't stay open so long, fund development of broader ecosystem projects. There isn't anyone involved in the core D development who isn't aware of the broader issues in the community or the ecosystem, and they are working to bring improvements. I have been around this community since 2003. From my perspective, it has been one continuous march of progress. Sometimes slow, sometimes fast, but always moving, always getting better. And right now there are more people involved than ever in moving it forward. Unfortunately, there are also more demands on more fronts than ever. There are longtime users who become increasingly frustrated when the issues that matter to them still aren't resolved, newcomers who have no context of all the progress that has been made and instead hold D in comparison to Rust, Go, and other languages that have stronger backing and more manpower. That's perfectly legitimate. And of course, low manpower and funding aren't the complete picture. Management also play a role. Both Walter and Andrei have freely admitted they are not managers and that they're learning as they go. Mistakes have been made. In hindsight, some decisions should have gone a different way. But that is not the same as not caring, or not understanding/ So please, don't attribute any disingenuous motives to any of the core team members. They all want D to succeed. Identifying core problems and discussing ways to solve them is a more productive way to spend our bandwidth.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 18:52:45 UTC, Laurent Tréguier wrote: On Monday, 3 September 2018 at 18:26:57 UTC, Chris wrote: it should come with a warning label that says "D is in many parts still at an experimental stage and ships with no guarantees whatsoever. Use at your own risk." Well it comes with the Boost license that says: `THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND` You know exactly what I mean, don't you?
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, September 3, 2018 12:26:57 PM MDT Chris via Digitalmars-d wrote: > There is no real plan and > only problems that someone deems interesting or challenging at a > given moment are tackled. If they solve a problem for a lot of > users, it's only a side effect. The advent of a D Foundation > hasn't changed anything in this regard, and it seems not to be > just a financial issue. It's the mentality. In other words, D is > still unreliable, and if that what the community wants, fine, but > instead of promoting it as a substitute for C/C++, Java etc. it > should come with a warning label that says "D is in many parts > still at an experimental stage and ships with no guarantees > whatsoever. Use at your own risk." That would save both the > language developers and (potential) users a lot of headaches. > > I think this sort of misunderstanding is the source of a lot of > friction on this forum. Some users think (or in my case: thought) > that D will be a sound and stable language one day, a language > they can use for loads of stuff, while the leadership prefers to > keep it at a stage where they can test ideas to see what works > and what doesn't, wait let me rephrase this, where the user can > test other people's ideas with every new release. Plenty of people - whole companies included - use D for real projects and products. It is an extremely powerful tool which can be used for real work. Is it as polished as some other languages? Maybe not, but it's plenty stable for real world use. And it's continually improving. All programming languages and tools are "used at your own risk." They all come with their own sets of pros and cons. If what you want is a language that doesn't change much, then there are plenty of other choices, just like there are plenty of languages that change all the time. Over time D has become more stable, and it doesn't change anywhere near as rapidly as it used to, but if you don't like how it works or is developed, then feel free to go elsewhere. Those of use that stick around find that its pros outweigh its cons. Plenty of folks disagree with us, and they've chosen different languages, which is just fine. In any case, I have better things to do than argue about whether D is a solid, useful language or not. It's the language that I prefer. I'm going to use it as much as I can, and I'm going to continue to contribute to it. If you don't like where D is, and you don't think that it's worth your time to contribute to it, then that's perfectly fine, but it's a waste of my time to continue to argue about it. I spend too much of my time in this newsgroup as it is, and this sort of argument doesn't contribute anything to improving D. - Jonathan M Davis
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 14:26:46 UTC, Laeeth Isharc wrote: I just spoke with Dicebot about work stuff. He incidentally mentioned what I said before based on my impressions. The people doing work with a language have better things to do than spend a lot of time on forums. And I think in open source you earn the right to be listened to by doing work of some kind. He said (which I knew already) it was an old post he didn't put up in the end - somebody discovered it in his repo. He is working fulltime as a consultant with me for Symmetry and is writing D as part of that role. I don't think that indicates he didn't mean his criticisms, and maybe one could learn from those. But a whole thread triggered by this is quite entertaining. Interesting, I did not realize that he had left Sociomantic. Even if he did not release the article, I think it's a good idea that we take some of his criticisms to heart. I, at the very least, agree with at least a few of them, and as we've seen, so do others.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 14:26:46 UTC, Laeeth Isharc wrote: I just spoke with Dicebot about work stuff. He incidentally mentioned what I said before based on my impressions. The people doing work with a language have better things to do than spend a lot of time on forums. And I think in open source you earn the right to be listened to by doing work of some kind. He said (which I knew already) it was an old post he didn't put up in the end - somebody discovered it in his repo. He is working fulltime as a consultant with me for Symmetry and is writing D as part of that role. I don't think that indicates he didn't mean his criticisms, and maybe one could learn from those. But a whole thread triggered by this is quite entertaining. I'm the person how found the post, and I'm enjoying the readings... and I'm learning something also! I'm amused by the amount of different topics, minus one, the original: why feature branches are not an option in DLangLand. /Paolo
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 18:26:57 UTC, Chris wrote: it should come with a warning label that says "D is in many parts still at an experimental stage and ships with no guarantees whatsoever. Use at your own risk." Well it comes with the Boost license that says: `THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND`
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 16:55:10 UTC, Jonathan M Davis wrote: Most of the work that gets done is the stuff that the folks contributing think is the most important - frequently what is most important for them for what they do, and very few (if any) of the major contributors use or care about IDEs for their own use. And there's tons to do that has nothing to do with IDEs. There are folks who care about it enough to work on it, which is why projects such as VisualD exist at all, and AFAIK, they work reasonably well, but the only two ways that they're going to get more work done on them than is currently happening is if the folks who care about that sort of thing contribute or if they donate money for it to be worked on. Not long ago, the D Foundation announced that they were going to use donations to pay someone to work on his plugin for Visual Studio Code: https://forum.dlang.org/post/rmqvglgccmgoajmhy...@forum.dlang.org So, if you want stuff like that to get worked on, then donate or pitch in. The situation with D - both with IDEs and in general - has improved greatly over time even if it may not be where you want it to be. But if you're ever expecting IDE support to be a top priority of many of the contributors, then you're going to be sorely disappointed. It's the sort of thing that we care about because we care about D being successful, but it's not the sort of thing that we see any value in whatsoever for ourselves, and selfish as it may be, when we spend the time to contribute to D, we're generally going to work on the stuff that we see as having the most value for getting done what we care about. And there's a lot to get done which impacts pretty much every D user and not just those who want something that's IDE-related. - Jonathan M Davis Dear Jonathan, you've just said it. There is no real plan and only problems that someone deems interesting or challenging at a given moment are tackled. If they solve a problem for a lot of users, it's only a side effect. The advent of a D Foundation hasn't changed anything in this regard, and it seems not to be just a financial issue. It's the mentality. In other words, D is still unreliable, and if that what the community wants, fine, but instead of promoting it as a substitute for C/C++, Java etc. it should come with a warning label that says "D is in many parts still at an experimental stage and ships with no guarantees whatsoever. Use at your own risk." That would save both the language developers and (potential) users a lot of headaches. I think this sort of misunderstanding is the source of a lot of friction on this forum. Some users think (or in my case: thought) that D will be a sound and stable language one day, a language they can use for loads of stuff, while the leadership prefers to keep it at a stage where they can test ideas to see what works and what doesn't, wait let me rephrase this, where the user can test other people's ideas with every new release.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, September 3, 2018 11:15:03 AM MDT Laurent Tréguier via Digitalmars-d wrote: > It just baffles me a bit to see the state of D in this > department, when languages like Go or Rust (hooray for yet > another comparison to Go and Rust) are a lot younger, but already > have what looks like very good tooling. > Then again they do have major industry players backing them > though... The dynamics are fundamentally different when you're paying someone to work on something. As I understand it, in addition to whatever volunteer work is done, Google and Mozilla pay people to work on those languages. And when you're doing that, it's trivial enough to say that you think that something matters enough to pay someone to work on it even if it's not something that anyone contributing actually wants to do or really cares about having for themselves. Relatively little time has been spent contributing to D by people who are paid to work on it. Even if both Walter and Andrei agreed that something should be treated as top priority, aside from paying someone to work on it through the D Foundation, they really can't make anyone work on it. What gets done is usually what the contributors care about. That's one reason why donations could end up being a game changer over time. It makes it possible to pay someone to do something that no contributors want to spend their free time doing. - Jonathan M Davis
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 16:55:10 UTC, Jonathan M Davis wrote: Most of the work that gets done is the stuff that the folks contributing think is the most important - frequently what is most important for them for what they do, and very few (if any) of the major contributors use or care about IDEs for their own use. And there's tons to do that has nothing to do with IDEs. There are folks who care about it enough to work on it, which is why projects such as VisualD exist at all, and AFAIK, they work reasonably well, but the only two ways that they're going to get more work done on them than is currently happening is if the folks who care about that sort of thing contribute or if they donate money for it to be worked on. Not long ago, the D Foundation announced that they were going to use donations to pay someone to work on his plugin for Visual Studio Code: https://forum.dlang.org/post/rmqvglgccmgoajmhy...@forum.dlang.org So, if you want stuff like that to get worked on, then donate or pitch in. The situation with D - both with IDEs and in general - has improved greatly over time even if it may not be where you want it to be. But if you're ever expecting IDE support to be a top priority of many of the contributors, then you're going to be sorely disappointed. It's the sort of thing that we care about because we care about D being successful, but it's not the sort of thing that we see any value in whatsoever for ourselves, and selfish as it may be, when we spend the time to contribute to D, we're generally going to work on the stuff that we see as having the most value for getting done what we care about. And there's a lot to get done which impacts pretty much every D user and not just those who want something that's IDE-related. - Jonathan M Davis The complaints I have is exactly why I'm myself maintaining plugins for VSCode, Atom, and others soon. Don't worry, I still think D is worth putting some time and effort into and I know actions generally get more things done than words. I also know that tons of stuff is yet to be done in regards to the actual compilers and such. It just baffles me a bit to see the state of D in this department, when languages like Go or Rust (hooray for yet another comparison to Go and Rust) are a lot younger, but already have what looks like very good tooling. Then again they do have major industry players backing them though...
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, September 3, 2018 9:41:48 AM MDT Laurent Tréguier via Digitalmars-d wrote: > On Monday, 3 September 2018 at 15:23:12 UTC, Chris wrote: > > On Monday, 3 September 2018 at 14:26:46 UTC, Laeeth Isharc > > > > wrote: > >> On Monday, 3 September 2018 at 11:32:42 UTC, Chris wrote: > >>> [...] > >> > >> D has never been about smooth experiences! That's a > >> commercial benefit if you think that hormesis brings benefits > >> and you are not looking for programmers of the trained-monkey, > >> strap a few APIs together type. > > > > It's high time it got a bit smoother if you want people to use > > it. Is everybody who doesn't use cli and knows all compiler > > flags by heart a coding monkey? Has it ever occurred to you > > that people want a smooth experience so they can concentrate on > > a job and get done with it? > > Yes. It almost sounds like a smooth experience would be a bad > thing to have, especially with the classic "you don't need an IDE > anyway" speech. Editing experience seems often dismissed as > unimportant, when it's one of the first things new users will > come across when trying out D. First impressions can matter a lot. Most of the work that gets done is the stuff that the folks contributing think is the most important - frequently what is most important for them for what they do, and very few (if any) of the major contributors use or care about IDEs for their own use. And there's tons to do that has nothing to do with IDEs. There are folks who care about it enough to work on it, which is why projects such as VisualD exist at all, and AFAIK, they work reasonably well, but the only two ways that they're going to get more work done on them than is currently happening is if the folks who care about that sort of thing contribute or if they donate money for it to be worked on. Not long ago, the D Foundation announced that they were going to use donations to pay someone to work on his plugin for Visual Studio Code: https://forum.dlang.org/post/rmqvglgccmgoajmhy...@forum.dlang.org So, if you want stuff like that to get worked on, then donate or pitch in. The situation with D - both with IDEs and in general - has improved greatly over time even if it may not be where you want it to be. But if you're ever expecting IDE support to be a top priority of many of the contributors, then you're going to be sorely disappointed. It's the sort of thing that we care about because we care about D being successful, but it's not the sort of thing that we see any value in whatsoever for ourselves, and selfish as it may be, when we spend the time to contribute to D, we're generally going to work on the stuff that we see as having the most value for getting done what we care about. And there's a lot to get done which impacts pretty much every D user and not just those who want something that's IDE-related. - Jonathan M Davis
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On 3 September 2018 at 18:07, RhyS via Digitalmars-d wrote: > > Too much resources split among too many distributions, graphical desktops > etc. Choice is good but too much choice means projects are starved for > resources, comparability are issues, bugs are even more present, ... > > A good example being the resources going into DMD, LDC, GDC... 3 Compilers > for one language, when even well funded languages stick to one compiler. This is an argument that has been batted to death and rebutted for nearly 2 decades now. 15 years ago, people were complaining that there was only one D compiler. It is ironic that people now complain that there's too many.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 15:41:48 UTC, Laurent Tréguier wrote: Yes. It almost sounds like a smooth experience would be a bad thing to have, especially with the classic "you don't need an IDE anyway" speech. Editing experience seems often dismissed as unimportant, when it's one of the first things new users will come across when trying out D. First impressions can matter a lot. Its the same issue why Linux as a Desktop has been stuck with almost no growth. Its easy to break things ( nvidia graphical driver *lol* ), too much is so focused on the Cli that people who do have a issue and are not system users quick run into a flooding swamp. Too much resources split among too many distributions, graphical desktops etc. Choice is good but too much choice means projects are starved for resources, comparability are issues, bugs are even more present, ... A good example being the resources going into DMD, LDC, GDC... 3 Compilers for one language, when even well funded languages stick to one compiler. And now some people think its a good idea to have DMD also cross compile because "its not hard to do". No, maybe not but who will do all the testing, what resources are going to spend when things do not work for some users ( and the negative impact on their experience )... Its a long list but people do not look past this. It sounds like fun, lets think / or do it. Its just so frustrating that a lot of people here do not understand. Most programmers are not open-source developers, they are not coding gods, they are simply people who want things to good smooth. Install compiler, install good supported graphical IDE ( and no, VIM does not count! ), read up some simple documentation and off we go... We are not looking to be bug testers, core code implementer's, etc... Selfish, ... sure ... but this is how D gain more people. The more people work with your language, the more potential people you have that slowly are interested in helping out. But when D puts the carrot in front of the cart instead of the mule. Then do not be so surprised that a lot of people find D extreme frustrating and have a love-hate relationship with it.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 15:23:12 UTC, Chris wrote: On Monday, 3 September 2018 at 14:26:46 UTC, Laeeth Isharc wrote: On Monday, 3 September 2018 at 11:32:42 UTC, Chris wrote: [...] D has never been about smooth experiences! That's a commercial benefit if you think that hormesis brings benefits and you are not looking for programmers of the trained-monkey, strap a few APIs together type. It's high time it got a bit smoother if you want people to use it. Is everybody who doesn't use cli and knows all compiler flags by heart a coding monkey? Has it ever occurred to you that people want a smooth experience so they can concentrate on a job and get done with it? Yes. It almost sounds like a smooth experience would be a bad thing to have, especially with the classic "you don't need an IDE anyway" speech. Editing experience seems often dismissed as unimportant, when it's one of the first things new users will come across when trying out D. First impressions can matter a lot.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 14:26:46 UTC, Laeeth Isharc wrote: On Monday, 3 September 2018 at 11:32:42 UTC, Chris wrote: [...] D has never been about smooth experiences! That's a commercial benefit if you think that hormesis brings benefits and you are not looking for programmers of the trained-monkey, strap a few APIs together type. It's high time it got a bit smoother if you want people to use it. Is everybody who doesn't use cli and knows all compiler flags by heart a coding monkey? Has it ever occurred to you that people want a smooth experience so they can concentrate on a job and get done with it? It's a question of developmental stages too. I was a late developer as a person, but then I continued to develop into my 30s and perhaps 40s too. For human beings there are different kinds of people and implicit life strategies and natural fits with niches. Some are quick to grow up, but stop developing sooner and others mature more slowly but this process may continue long after others are done. I'm not saying a computer language is like a human being, but it is in part an organic phenomenon and social institutions develop according to their own logic and rhythm in my experience of studying them. This is not a yoga class. D is a late developer, and I think that's because it is a tremendously ambitious language. What use case is D intended to target? Well it's not like that - it's a general purpose programming language at a time when people have given up on that idea and think that it simply must be that you pick one tool for the job and couldn't possibly have a tool that does many different kind of things reasonably well. So the kind of use cases D is suited for depends much more on the capabilities and virtues of the people using it than is the case for other languages. (In truth in a negative sense that's true also of other languages - Go was designed to be easy to learn and to use for people who didn't have much programming experience). It's not D's usefulness I'm concerned with, it can do a lot of things. It's just a bit awkward to use in production and there's no reason why things should still be like in 2010. [...] Sure. I would agree with what you write but say that it's a case of capabilities and hormesis too sometime. Nassim Taleb told a story about checking into a hotel and seeing a guy in a suit tip the bellboy to carry his bags upstairs. Later on he saw the same guy in a gym lifting weights (and I think on a Nautilus-type machine which is much inferior to free weights). So any tool can make you lazy, and yet any tool - no matter how shiny, polished, and expensive - sometimes will break and then if you are afraid of the command line or just very out of practice you can end up utterly helpless. It's a matter of balance to be sure. Funny story, but this is not the place for esoteric contemplations. [...] I didn't find the experience last time I tried to be worse than just going through the Android C/C++ native SDK instructions. The first time I tried it was quite tough as I struggled to even build the compiler as the instructions weren't quite right. I disagree about it not being maintainable as it's much easier to keep something you understand and can reason about working, but it's harder to use in the beginning, for sure. I think that the point for Android and ARM is not the build process but integration with Java APIs. If you can't figure out a build process that when I tried it mostly just worked and that doesn't have too much dark magic, I fear for how easy you are going to find JNI. (JNI is fine, but building a D project on Android requires less demanding technical capabilities). I know JNI, I've connected D with Java (and vice versa) a few times. [...] You had one or two people who stubbornly devoted considerable parts of their lives to getting D to build on Android. And instead of saying what a remarkable achievement, and thank you so much for this work, and this is very cool but we really should consider in a constructive manner how to make this easy to use, you are saying I want more! Fair enough - it's a free society, although I don't think you were ever promised that the Android experience would be something different from what it is. I never gave out about the guys (I think one of them is Joakim) who made it possible in the end, because without their efforts we wouldn't have anything. I'm just surprised they don't get more full time support to wrap it up nicely. But I really am not surprised that people burn out doing open source. It's very odd to see, because I came back to this world after a long break. My first 'open source' contribution was to part of Tom Jenning's work on FidoNet in 1989 - an improvement to some node routing table, and in those days people used to be pretty appreciative. Same thing with Chuck Forsberg who invented ZModem and
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 11:32:42 UTC, Chris wrote: On Sunday, 2 September 2018 at 12:07:17 UTC, Laeeth Isharc wrote: That's why the people that adopt D will inordinately be principals not agents in the beginning. They will either be residual claimants on earnings or will have acquired the authority to make decisions without persuading a committee that makes decisions on the grounds of social factors. If D becomes another C++ ? C++ was ugly from the beginning (in my personal subjective assessment) whereas D was designed by people with good taste. That's why it appeals inordinately to people with good taste. [snip] Be that as it may, however, you forget the fact that people "with good taste" who have (had) an intrinsic motivation to learn D are also very critical people who take no bs, else they wouldn't have ended up using D in the first place. Since they've already learned a lot of concepts etc. with D over the years, it's technically easy for them to move on to either an easier language or one that offers more or less the same features as D. I don't think so. If we are talking about the set of technically very capable people with an aesthetic sense then I don't think easier or feature set in a less beautiful way is appealing. This is based on revealed preference, because the conversations I have with technically very capable people that know many other languages as well or better than D go like "what compensation are you expecting? X. But if it's to write D, I can be flexible" and so on. Template meta-programming in D is quite simple. C++ has many of the features that D has. Therefore it's easy to do template meta-programming in C++, and just as easy for others to read your code in C++ as D? I don't think so. Having learnt the concepts in D and that it can be beautiful and easy kind of ruins you for inferior approaches. BTW I was grumbling about some C# wrapper code written manually. It talks to a C style API (connected to an internal C++ code base developed before I became involved). So you have a low level C# side declaration of the C function that returns an exception string by argument. Then you have a C# declaration of a wrapper function that throws an exception if the exception string is not empty. Then you have a layer on top that puts the class back together. Then you have a high level wrapper layer. Then you have the bit that talks to Excel. I thought surely there must be decent code generation possibilities in C#. It's not too bad as a language. I looked it up. Microsoft say use HTML templates. Well, okay... but I'm not sure I like the trade-off of having to do stuff like that versus having to deal with some pain at the command-line now and then. So once they're no longer happy with the way things are, they can dive into a any language fast enough for the cost of transition to be low. You're making an implicit empirical statement that I don't believe to be accurate based on my experience. I would say if a representative programmer from the D community decides the costs no longer offset the benefits then sure they can learn another language because the representative programmer here is pretty talented. But so what?
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 11:32:42 UTC, Chris wrote: On Sunday, 2 September 2018 at 12:07:17 UTC, Laeeth Isharc wrote: That's why the people that adopt D will inordinately be principals not agents in the beginning. They will either be residual claimants on earnings or will have acquired the authority to make decisions without persuading a committee that makes decisions on the grounds of social factors. If D becomes another C++ ? C++ was ugly from the beginning (in my personal subjective assessment) whereas D was designed by people with good taste. That's why it appeals inordinately to people with good taste. [snip] Be that as it may, however, you forget the fact that people "with good taste" who have (had) an intrinsic motivation to learn D are also very critical people who take no bs, else they wouldn't have ended up using D in the first place. Since they've already learned a lot of concepts etc. with D over the years, it's technically easy for them to move on to either an easier language or one that offers more or less the same features as D. So once they're no longer happy with the way things are, they can dive into a any language fast enough for the cost of transition to be low. One has to be practical too. Yes! And being practical involves recognising different objectives, starting points and considerations apply to different situations and contexts. Programming involves more than just features and concepts. Good, out of the box system integration (e.g. Android, iOS) is important too and he who ignores this simple truth will have to pay a high price. Important for whom? It depends a lot! Ask Sociomantic, Bastian, Weka if the lack of Android or iOS integration is a big problem for them, and I don't think you will get the answer that it is important. For what I am doing, Android or iOS would be nice, but it doesn't need to be out of the box, and you can do quite a lot on Android already. I compiled ldc on my Huawei watch, which I never expected to be possible though given it has 4 Gig of RAM it's not that surprising. JNI is not that bad though could certainly be made easier with a bit of work. And I haven't tried, but I guess you could write the GUI stuff in Python or Lua for a simple app and do the heavy lifting with D. Of course for the ecosystem generally yes it matters. why developers of new languages are so keen on giving users a smooth experience when it comes to app development and cross compilation which leads me to the next point: IDEs. D has never been about smooth experiences! That's a commercial benefit if you think that hormesis brings benefits and you are not looking for programmers of the trained-monkey, strap a few APIs together type. It's a question of developmental stages too. I was a late developer as a person, but then I continued to develop into my 30s and perhaps 40s too. For human beings there are different kinds of people and implicit life strategies and natural fits with niches. Some are quick to grow up, but stop developing sooner and others mature more slowly but this process may continue long after others are done. I'm not saying a computer language is like a human being, but it is in part an organic phenomenon and social institutions develop according to their own logic and rhythm in my experience of studying them. D is a late developer, and I think that's because it is a tremendously ambitious language. What use case is D intended to target? Well it's not like that - it's a general purpose programming language at a time when people have given up on that idea and think that it simply must be that you pick one tool for the job and couldn't possibly have a tool that does many different kind of things reasonably well. So the kind of use cases D is suited for depends much more on the capabilities and virtues of the people using it than is the case for other languages. (In truth in a negative sense that's true also of other languages - Go was designed to be easy to learn and to use for people who didn't have much programming experience). No. You don't need an IDE to develop in D Indeed, and much less so than with some other languages because you can understand the code that's out of focus more easily and hold more of it in your head and reason about it. I personally use Sublime and vim, but tools are very personal because problems are different and people think differently and there's not much upside in engaging in a holy war about tools. However, an IDE can a) make coding comfortable and b) boost your productivity. Sure - in can do for some people in some cases. to a): maybe you just grow tired of the text editor & cli approach and you just want to click a few buttons to fix imports or correct typos and be done with it, and as to b): all this helps to boost your productivity, especially when you can easily set up an app or a web service with a few mouse
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 06:29:02 UTC, Pjotr Prins wrote: One thing I want to add that we ought to be appreciative of the work people put in - much of it in their spare time. I wonder if W and others sometimes despair for the lack of appreciation they get. Guido van Rossum burning out (W, notably, was the one to post that here first) is a shame. Even though he created a language which I find less tasteful he did not deserve to be treated like that. Simple. I feel the same. There is no need to put a huge burden on them even if there is something could not be fixed. A good subset of a language is still a good language I think. Powerful, expressive, precise, that's important for me.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 06:29:02 UTC, Pjotr Prins wrote: Hear, hear! Even though some languages like Julia, Rust and Go are much better funded than D - and their creators have excellent taste in different ways - they still have to go through similar evolutionary steps. There is no fast path. Whatever design decision you make, you always end up fixes bugs and corner cases. I was amazed how behind Rust's debugger support was last year (I witnessed a talk at FOSDEM). They are catching up, but it just goes to show... No programming language is ever finished. But most programming languages try to get the basics right first and then add new features. If you want to run you have to learn how to walk first. Languages take time to evolve, but we shouldn't be in a situation where the fixing of basic bugs and flaws are considered part of the "long term goals". One thing I want to add that we ought to be appreciative of the work people put in - much of it in their spare time. I wonder if W and others sometimes despair for the lack of appreciation they get. Guido van Rossum burning out (W, notably, was the one to post that here first) is a shame. Even though he created a language which I find less tasteful he did not deserve to be treated like that. Simple. I hold both Walter and Andrei (and all the other great contributors) in high esteem and D was the right tool for me back in the day. Without it things would have been a lot harder. But I think D is past the laboratory stage and I as a user feel that our actual experience is less important than design experiments. Respect goes both ways, after all it's the users who keep a programming language alive. If there isn't something fundamentally wrong in the communication between the leadership / language developers and the users, why do we get posts like this: "Thanks! Please add anything you think is missing to https://github.com/dlang/dlang.org/pull/2453 since Walter doesn't seem to be interested." https://forum.dlang.org/post/mxgyoflrsibeyavvm...@forum.dlang.org Not good.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Sunday, 2 September 2018 at 12:07:17 UTC, Laeeth Isharc wrote: That's why the people that adopt D will inordinately be principals not agents in the beginning. They will either be residual claimants on earnings or will have acquired the authority to make decisions without persuading a committee that makes decisions on the grounds of social factors. If D becomes another C++ ? C++ was ugly from the beginning (in my personal subjective assessment) whereas D was designed by people with good taste. That's why it appeals inordinately to people with good taste. [snip] Be that as it may, however, you forget the fact that people "with good taste" who have (had) an intrinsic motivation to learn D are also very critical people who take no bs, else they wouldn't have ended up using D in the first place. Since they've already learned a lot of concepts etc. with D over the years, it's technically easy for them to move on to either an easier language or one that offers more or less the same features as D. So once they're no longer happy with the way things are, they can dive into a any language fast enough for the cost of transition to be low. One has to be practical too. Programming involves more than just features and concepts. Good, out of the box system integration (e.g. Android, iOS) is important too and he who ignores this simple truth will have to pay a high price. That's why developers of new languages are so keen on giving users a smooth experience when it comes to app development and cross compilation which leads me to the next point: IDEs. No. You don't need an IDE to develop in D. However, an IDE can a) make coding comfortable and b) boost your productivity. As to a): maybe you just grow tired of the text editor & cli approach and you just want to click a few buttons to fix imports or correct typos and be done with it, and as to b): all this helps to boost your productivity, especially when you can easily set up an app or a web service with a few mouse clicks. In D, if you want to do something with ARM/Android you will invariably end up with a potpourri of build scripts and spaghetti lines full of compiler flags etc. Not smooth, it takes a lot of time to set it up manually and it's not easily maintainable. Doable, yes, but just because something is doable doesn't mean it's recommendable nor that people will actually bother with doing it. I'm under the impression that the D Foundation doesn't pay much attention to these things once they are kind of "doable" and somebody has volunteered to "look into it" with no guarantee whatsoever if and when it will be available to users. And if there are complaints, hey, it is not "official" ask the guy who's looking into it. Not very professional. See, that doesn't really give you confidence in D and it gives you an uneasy feeling. Nothing worse in software development than to be programming thinking "Am I actually wasting my time here?", and of course, you become reluctant to start anything new in D - which is only natural.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Sunday, 2 September 2018 at 12:07:17 UTC, Laeeth Isharc wrote: I've only been programming since 1983 so I had the benefit of high level languages like BBC BASIC, C, a Forth I wrote myself, and Modula 3. And although I had to write a disassembler at least I has assemblers built in. Programming using a hex keypad is not that satisfying after a while. It takes a long time to develop a language, its ecosystem and community. Hear, hear! Even though some languages like Julia, Rust and Go are much better funded than D - and their creators have excellent taste in different ways - they still have to go through similar evolutionary steps. There is no fast path. Whatever design decision you make, you always end up fixes bugs and corner cases. I was amazed how behind Rust's debugger support was last year (I witnessed a talk at FOSDEM). They are catching up, but it just goes to show... One thing I want to add that we ought to be appreciative of the work people put in - much of it in their spare time. I wonder if W and others sometimes despair for the lack of appreciation they get. Guido van Rossum burning out (W, notably, was the one to post that here first) is a shame. Even though he created a language which I find less tasteful he did not deserve to be treated like that. Simple.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Sunday, 2 September 2018 at 14:48:34 UTC, lurker wrote: after the beta i tried it the final again - just to be fair. 1.) install d, install visual d. 2.) trying to to look at options under visual d without a project crashes VS2017 - latest service pack. 3.) VS2017 - displays a problem on startup 4.) creating the dummy project - compile for x64. error something is missing. 5.) deinstall everything and wait for another year this crap does not even work out of the box - what else is not tested in D? i guess you don't intend to draw crowds to D and just keep talking on how to this and that a little better in the compiler pet project. is D that dead that the releases are not tested or do you want to keep all windows users out? Oh and also your error is probably that you're missing the C++ build tools which come with the correct linker for x64, as far as I remember.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Sunday, 2 September 2018 at 14:48:34 UTC, lurker wrote: after the beta i tried it the final again - just to be fair. 1.) install d, install visual d. 2.) trying to to look at options under visual d without a project crashes VS2017 - latest service pack. 3.) VS2017 - displays a problem on startup 4.) creating the dummy project - compile for x64. error something is missing. 5.) deinstall everything and wait for another year this crap does not even work out of the box - what else is not tested in D? i guess you don't intend to draw crowds to D and just keep talking on how to this and that a little better in the compiler pet project. is D that dead that the releases are not tested or do you want to keep all windows users out? Visual D is not official, remember that. Most people would go with VS Code anyway.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Sun, 2 Sep 2018 at 16:05, Andre Pany via Digitalmars-d wrote: > > On Sunday, 2 September 2018 at 14:48:34 UTC, lurker wrote: > > after the beta i tried it the final again - just to be fair. > > > > 1.) install d, install visual d. > > 2.) trying to to look at options under visual d without a > > project crashes VS2017 - latest > > service pack. > > 3.) VS2017 - displays a problem on startup > > 4.) creating the dummy project - compile for x64. error > > something is missing. > > 5.) deinstall everything and wait for another year > > > > this crap does not even work out of the box - what else is not > > tested in D? > > > > i guess you don't intend to draw crowds to D and just keep > > talking on how to this and that a little better in the compiler > > pet project. > > > > is D that dead that the releases are not tested or do you want > > to keep all windows users out? > > There are a lot of motivated people here willing to help you to > get your issue solved if you provide the details. > > I can confirm that DMD is working like a charm for me (different > visual studio versions on build servers, MS build tools on local > pc). I use IntelliJ instead of Visual Studio, but that is only my > personal preferation. > > Kind regards > Andre I'm currently installing VS2017 to test your anecdote (been on 2015 for ages)... although I use VS2017 at work and haven't had any problems.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Sunday, 2 September 2018 at 14:48:34 UTC, lurker wrote: after the beta i tried it the final again - just to be fair. 1.) install d, install visual d. 2.) trying to to look at options under visual d without a project crashes VS2017 - latest service pack. 3.) VS2017 - displays a problem on startup 4.) creating the dummy project - compile for x64. error something is missing. 5.) deinstall everything and wait for another year this crap does not even work out of the box - what else is not tested in D? i guess you don't intend to draw crowds to D and just keep talking on how to this and that a little better in the compiler pet project. is D that dead that the releases are not tested or do you want to keep all windows users out? There are a lot of motivated people here willing to help you to get your issue solved if you provide the details. I can confirm that DMD is working like a charm for me (different visual studio versions on build servers, MS build tools on local pc). I use IntelliJ instead of Visual Studio, but that is only my personal preferation. Kind regards Andre
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Sunday, 2 September 2018 at 14:48:34 UTC, lurker wrote: after the beta i tried it the final again - just to be fair. 1.) install d, install visual d. 2.) trying to to look at options under visual d without a project crashes VS2017 - latest service pack. 3.) VS2017 - displays a problem on startup 4.) creating the dummy project - compile for x64. error something is missing. 5.) deinstall everything and wait for another year this crap does not even work out of the box - what else is not tested in D? i guess you don't intend to draw crowds to D and just keep talking on how to this and that a little better in the compiler pet project. is D that dead that the releases are not tested or do you want to keep all windows users out? Don't worry, that is just the beginning... It's like that in all aspects. The design is fundamentally flawed and no one seems to care(or recognize it). Software is far too complex now days to be using mentalities of the 60's and 70's.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
after the beta i tried it the final again - just to be fair. 1.) install d, install visual d. 2.) trying to to look at options under visual d without a project crashes VS2017 - latest service pack. 3.) VS2017 - displays a problem on startup 4.) creating the dummy project - compile for x64. error something is missing. 5.) deinstall everything and wait for another year this crap does not even work out of the box - what else is not tested in D? i guess you don't intend to draw crowds to D and just keep talking on how to this and that a little better in the compiler pet project. is D that dead that the releases are not tested or do you want to keep all windows users out?
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Saturday, 1 September 2018 at 12:33:49 UTC, rjframe wrote: On Thu, 23 Aug 2018 15:35:45 +, Joakim wrote: * Language complexity Raise your hand if you know how a class with both opApply and the get/next/end functions behaves when you pass it to foreach. How about a struct? Does it matter if it allows copying or not? The language was built because C++ was deemed too complex! Please see the thread about lazy [1] for a case where a question actually has an answer, but nobody seems to know it (and the person who does know it is hard pressed to explain the nuance that triggers this). By this rationale, C++ should be dead by now. Why do you think it's fatal to D? It's worth noting that C++ isn't always chosen for its technical merits. It's a well-known language whose more or less standard status in certain domains means it's the default choice; C++ is sometimes used for projects in which Stroustrup would say it's obviously the wrong language for the job. D is far more likely to require justification based on technical merit. If D becomes another C++, why bother taking a chance with D when you can just use C++, use a well-supported, commonly-used compiler, and hire from a bigger pool of jobseekers? That's why the people that adopt D will inordinately be principals not agents in the beginning. They will either be residual claimants on earnings or will have acquired the authority to make decisions without persuading a committee that makes decisions on the grounds of social factors. If D becomes another C++ ? C++ was ugly from the beginning (in my personal subjective assessment) whereas D was designed by people with good taste. That's why it appeals inordinately to people with good taste. In Hong Kong we had some difficulty hiring a support person for a trading floor. Spoke in some cases to the most senior person in HK for even large and well-known funds (small office in this case) and they simply were not good enough. Thanks to someone from the D community I met a headhunter who used to be at Yandex but realized the money was better as a headhunter. They don't have many financial clients I think, don't have connections on the talent side in finance. But the runners up were by far better than anyone we had found through other sources and the best was outstanding. Good job, I said. It's funny that the person we hired came from a big bank when other headhunters are looking in the same place and know that world better. By the way, how many people did you interact with to find X ? In London if a headhunter puts 10 people before you and you are really pretty happy then that's a good day. He said two hundred ! And they had to come up with a hiring test too. So the basic reason they could find good people in technology in finance when others couldn't is that they have much better taste. Do you see ? The others knew many more people, they had experience doing it, and somebody who had to persuade a committee would have found it hard to justify. Programming ability follows a Pareto curve - see the best and the rest. There might be many more C++, Python and C# programmers. The incidence of outstanding ones is lower than in the D community for the very reason that only someone obtuse or very smart will learn D for career reasons - intrinsic motivation draws the highest talent. It depends if your model of people doing work is an army of intelligent trained monkeys or a force made up of small elite groups of the best people you have ever worked with. Of course the general of the trained monkey army is going to be difficult to persuade. And so ? On the other hand, someone who is smart and has good taste and has earned the right to decide - D is a less popular language that has fewer tutorials and less shiny IDE and debugger support. Well if you're a small company and you are directly or in effect a proxy owner of the residual (ie an owner of some kind) it's a pragmatic question and saying nobody got fired for buying IBM - that's missing the point because the success is yours and the failure is yours and you can't pass the buck. The beauty of being the underdog is that it's easy to succeed. You don't need to be the top dog, and in fact it's not strategically wise to do something that might think you stand a chance - let them think what they want. The underdog just needs to keep improving and keep getting more adoption, which I don't have much doubt is happening. Modern people can be like children in their impatience sometimes! I've only been programming since 1983 so I had the benefit of high level languages like BBC BASIC, C, a Forth I wrote myself, and Modula 3. And although I had to write a disassembler at least I has assemblers built in. Programming using a hex keypad is not that satisfying after a while. It takes a long time to develop a language, its ecosystem and community. An S curve is quite
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Saturday, 1 September 2018 at 18:35:30 UTC, TheSixMillionDollarMan wrote: On Saturday, 1 September 2018 at 12:33:49 UTC, rjframe wrote: [...] Stroustrup also said, that "achieving any degree of compatibility [with C/C++] is very hard, as the C/C++ experience shows." (reference => http://stroustrup.com/hopl-almost-final.pdf (2007) (and here refers to D on page 42 btw - that was 11 years ago now). And yet, D is very intent on doing just that, while also treading its own path. I personally think this is why D has not taken off, as many would hope. It's hard. I think it's also why D won't take off, as many hope. It's hard. Stroustrup was correct (back in the 90's). Yes, it really is hard. Made even harder now, since C++ has evolved into a 'constantly' moving target... D++
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Saturday, 1 September 2018 at 12:33:49 UTC, rjframe wrote: C++ is sometimes used for projects in which Stroustrup would say it's obviously the wrong language for the job. D is far more likely to require justification based on technical merit. If D becomes another C++, why bother taking a chance with D when you can just use C++, use a well-supported, commonly-used compiler, and hire from a bigger pool of jobseekers? Stroustrup also said, that "achieving any degree of compatibility [with C/C++] is very hard, as the C/C++ experience shows." (reference => http://stroustrup.com/hopl-almost-final.pdf (2007) (and here refers to D on page 42 btw - that was 11 years ago now). And yet, D is very intent on doing just that, while also treading its own path. I personally think this is why D has not taken off, as many would hope. It's hard. I think it's also why D won't take off, as many hope. It's hard. Stroustrup was correct (back in the 90's). Yes, it really is hard. Made even harder now, since C++ has evolved into a 'constantly' moving target...
Re: D is dead
On Saturday, September 1, 2018 8:31:36 AM MDT H. S. Teoh via Digitalmars-d
wrote:
> This change may also address the current hackish implementation of
> subclass contracts (which involves catching Errors, an arguably
> dangerous thing to do), though I'm not 100% sure.
AFAIK, there's absolutely nothing required to fix that other than just
implementing it. As I understand it, the assertions act normally and thus
throw AssertErrors, but there should be no technical reason why they
couldn't be transformed into something else. e.g.
in
{
assert(foo < 7);
}
could be lowered to something like
in
{
if(foo < 7)
return false;
return true;
}
The only differences would then be if any functions called in the contract
resulted in an AssertError (sinc that would no longer count as a contract
failure - which is arguably a bug fix) and that explicitly throwing an
AssertError wouldn't work anymore - but I expect that that's rare enough
that it wouldn't be all that big a deal.
- Jonathan M Davis
Re: D is dead
On Sat, Sep 01, 2018 at 01:26:01PM +, rjframe via Digitalmars-d wrote: > On Thu, 23 Aug 2018 07:27:56 +, JN wrote: [...] > > (has anyone ever used contracts?). > > I do. Me too. They are very useful to express intent, even if the current implementation leaves some things to be desired. > It's a shame D doesn't take them seriously. Not sure what you mean by that. Care to elaborate? > As it is, I generally use them solely to express intent, which you > don't get by placing asserts in the function body. I often read the > function signature of functions I'm calling without reading the body, > so separating the asserts from the body is helpful. [...] Yes. The current implementation of contracts leaves some things to be desired, but I'm hopeful after the recent syntax revamp was accepted and merged into git master. The next milestone to fight for is pushing the checking of contracts to the caller, rather than the callee. This will be important to solve the currently very annoying (and debilitating) problem with binary shared libraries, in that it will allow the same shared binaries to be used when compiling both with and without contracts. It should be the end user's build script that decides whether or not contracts are compiled in, but currently this is not the case. This change may also address the current hackish implementation of subclass contracts (which involves catching Errors, an arguably dangerous thing to do), though I'm not 100% sure. T -- Старый друг лучше новых двух.
Re: D is dead
On Thu, 23 Aug 2018 07:27:56 +, JN wrote: > I think a large part is defining what kind of users D wants to attract. I've begun wondering whether "pragmatism" is sometimes used as a code word for indecision. > Is it possible to make a language that both groups would be happy to > use? Perhaps, or perhaps the gap is too wide. Is adding features like > dip1000 and betterC spreading ourselves too thin? Perhaps. Perhaps there > are features that aren't really used, and should be reworked or cut from > the language instead I do think that D can do it. And I think D is the only language I've looked at that can do it. But I think it's going to take Walter and Andrei, in conversation with the core team, putting together a real list of priorities and setting a high-level direction. Look at what the end goal really is and what it will take to get there. The current high level document tends to read as a list of what's already being worked on, but piecemeal improvements probably aren't going to cut it -- this goes back to the leverage conversation Andrei started earlier. > (has anyone ever used contracts?). I do. It's a shame D doesn't take them seriously. As it is, I generally use them solely to express intent, which you don't get by placing asserts in the function body. I often read the function signature of functions I'm calling without reading the body, so separating the asserts from the body is helpful. And they're often useful on interfaces.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Thu, 23 Aug 2018 14:29:23 +, bachmeier wrote: > Weka is an awesome project, but I don't know that most people > considering D should use your experience as the basis of their decision. > At least in my areas, I expect considerable growth in the usage of D > over the next 10 years. Maybe it won't see much traction as a C++ > replacement for large projects like Weka. As long as D calls itself a systems language (which I believe is still the case), the experience of organizations building large systems is extremely important -- for organizations that want to build large systems.
Re: D is dead
On Sat, 01 Sep 2018 11:25:31 +, rjframe wrote: > Should you have to fix the bugs you run into? No. But if they keep you > from doing your work, it seems like the economics of fixing D's bugs can > make sense. If Weka were to assign its own priorities to D's bugs*, and > have one person, once a week, fix the largest-priority bug, how big of > an investment would that be, and would the return be worth it? Many bugs > will definitely not be worth your time, but others might. You've answered this already; my apologies for the noise. --Ryan
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Thu, 23 Aug 2018 15:35:45 +, Joakim wrote: >> * Language complexity >> >> Raise your hand if you know how a class with both opApply and the >> get/next/end functions behaves when you pass it to foreach. >> How about a struct? Does it matter if it allows copying or not? >> >> The language was built because C++ was deemed too complex! Please see >> the thread about lazy [1] for a case where a question actually has an >> answer, but nobody seems to know it (and the person who does know it is >> hard pressed to explain the nuance that triggers this). > > By this rationale, C++ should be dead by now. Why do you think it's > fatal to D? It's worth noting that C++ isn't always chosen for its technical merits. It's a well-known language whose more or less standard status in certain domains means it's the default choice; C++ is sometimes used for projects in which Stroustrup would say it's obviously the wrong language for the job. D is far more likely to require justification based on technical merit. If D becomes another C++, why bother taking a chance with D when you can just use C++, use a well-supported, commonly-used compiler, and hire from a bigger pool of jobseekers?
Re: D is dead
On Thu, 23 Aug 2018 15:34:34 +, Matheus wrote: > Well, I'm D hobbyist and of course it's not a perfect language and you > have some valid points, but on the other hand I think it's very > disrespectful to come into a community and say the product that people > are working mainly as volunteers and without any payment "is dead". > > Matheus. Not necessarily. If you see somebody's about to drive off a cliff, warning them is a good thing to do. If someone thinks the direction D is headed will lead to the end of the language as a good/viable choice for programmers, then trying to change that direction is the best thing s/he can do.
Re: D is dead
On Thu, 23 Aug 2018 19:34:46 +, Abdulhaq wrote: > There is a class of developers who expect things to Just Work TM, > especially if they are told that it Just Works. Each time that they > discover some combination of features that doesn't work they have to > refactor their code and remember not to try that again. Ultimately the > developer painfully learns the things that they should not attempt to > use, or they give up before the process is complete and leave. I expect > the pain caused by this is much more acute in a commercial environment > where the pressure is on. > > Long term D developers have learnt not to bother with certain features > or combinations of features and forget all the pain they went through to > get that knowledge. They are ones saying, come in the water's lovely. +1 It's easy to recommend D to someone because it does X, Y, and Z so well, not realizing they need X, Y, and B. And D has a honeymoon period - it's so awesome and will solve all our problems... until you dig deeper, trying to get more and more out of it and struggle to make sense of how to make it fit together. The pragmatic approach to language design has its downsides.
Re: D is dead
On Thu, 23 Aug 2018 04:02:37 -0700, Walter Bright wrote: > On 8/23/2018 2:09 AM, Shachar Shemesh wrote: >> * The community >> >> Oh boy. >> >> Someone who carries weight needs to step in when the forum is trying to >> squash down on criticism. For Mecca, I'm able to do that [2], but for >> D, this simply doesn't happen. > > If someone is trying to squash criticism, I would like to see what > you're referring to. If a post contains unprofessional behavior, like > using f--k or harassing people, it will get removed. Simply being > critical is not removed (if it was, this this thread would have > disappeared). One problem is that "professional" has a broad range of meanings, and as variety of cultures are represented here. I've had bosses that thought things like "What's the f--- @^Q@#$ is wrong with you?" was professional if the person "deserved" it. It would be nice to have a published code of conduct; it doesn't need to be large or formal, just a simple definition of professional, respectful behavior. Anybody would be able to point to it, rather than hope you or someone who's around enough to feel comfortable calling someone out is on the NG at the time.
Re: D is dead
On Thu, 23 Aug 2018 21:04:36 +0300, Shachar Shemesh wrote: > On 23/08/18 20:52, bachmeier wrote: >> On Thursday, 23 August 2018 at 17:19:41 UTC, Ali wrote: >>> On Thursday, 23 August 2018 at 16:22:54 UTC, Shachar Shemesh wrote: On 23/08/18 17:01, Steven Schveighoffer wrote: My main job is to develop for Weka, not develop D itself. >>> >>> Weka, at some point, made the strategic decision to use a non >>> mainstream language >>> >>> I dont think Weka, have a choice, they have to invest in the >>> development of D itself >> >> I hope a startup can choose D without having to do that. Otherwise D is >> not really a viable option for startups because they need to focus on >> survival rather than language development. > > This! > > Maybe Weka can afford it, but being all smug about it is a destructive > attitude to have. I know that some of Weka's leadership are > uncomfortable about the fact that we, almost by definition, are facing > language related issues that no-one in the community has before us. > > Weka is in a good place, and is going in a good direction, but don't > forget that we are up against giants, and are selling a product where > 0.1% failure is considered the same as utter failure. Being able to > trust the compiler was supposed to be a given. > > Yes, Weka is, at this point, committed. The next start-up isn't. > > Shachar I don't really understand this reasoning; a compiler is a dependency, much like a third party library. When a dependency gets in the way of your product, you have to make a choice. If you can't afford 0.1% failure, then if the compiler is holding you back, the choice seems to be fix the compiler, replace the compiler/ language, or don't do what you want to do. Should you have to fix the bugs you run into? No. But if they keep you from doing your work, it seems like the economics of fixing D's bugs can make sense. If Weka were to assign its own priorities to D's bugs*, and have one person, once a week, fix the largest-priority bug, how big of an investment would that be, and would the return be worth it? Many bugs will definitely not be worth your time, but others might. * I don't know that it's common, but I have maintained third-party bugs in my own tracker; this makes it easy to check their changelog against the bugs I care about, especially when I don't subscribe to the bug in their tracker for one reason or other. Being able to prioritize their bugs against bugs in my own project also helps me decide whether to spend my time fixing the third-party library.
Re: D is dead
On Friday, 31 August 2018 at 08:36:27 UTC, Nick Treleaven wrote: I hadn't understood the rationale for lazy variadic functions https://dlang.org/spec/function.html#lazy_variadic_functions I don't know if this has been updated too but this sentence makes no sense : "Then each of the arguments whose type does not match that of the delegate is converted to a delegate."
Re: D is dead
On Thursday, 23 August 2018 at 09:09:40 UTC, Shachar Shemesh wrote: Please see the thread about lazy [1] for a case where a question actually has an answer, but nobody seems to know it I updated the spec for lazy parameters to add a link to lazy variadic functions at the end, and for the latter I added a simpler version of Steven Schveighoffer's examples of both. So at least in future someone with a similar problem might find out that lazy variadics is another option. https://dlang.org/spec/function.html#lazy-params https://dlang.org/spec/function.html#lazy_variadic_functions I hadn't understood the rationale for lazy variadic functions just from reading the spec. If I learn something that should be mentioned in the spec, I try to make a pull. Failing that, we can file bugzilla issues for missing documentation, even if it's only an enhancement for clarification.
Re: D is dead
On Wednesday, August 29, 2018 2:37:17 AM MDT Walter Bright via Digitalmars-d wrote: > On 8/28/2018 11:52 PM, Jonathan M Davis wrote: > > Would it make sense then to change it to work more like what you and > > Martin were thinking of doing? > > Yes, it would. But it would be a non-trivial effort to remove Kenji's > design. Well, then at least it should be an issue of time and manpower rather than it being something that we can't reasonably fix from a technical perspective. So, then presumably, it's a question of priority and whether it's a pressing enough issue to merit the pain of sorting it out - not that the todo list is ever really getting shorter around here... - Jonathan M Davis
Re: D is dead
On 8/28/2018 11:52 PM, Jonathan M Davis wrote: Would it make sense then to change it to work more like what you and Martin were thinking of doing? Yes, it would. But it would be a non-trivial effort to remove Kenji's design.
Re: D is dead
On Tuesday, August 28, 2018 11:31:40 PM MDT Walter Bright via Digitalmars-d wrote: > On 8/28/2018 6:39 AM, Iain Buclaw wrote: > > Template emission strategy is a mess, we're better off just > > instantiating all templates in all compilation units, and let the > > compiler decide whatever to discard. Even -allinst does not instantiate > > enough to allow the compiler to make such decisions that C++ has no > > problem with (most of the time). > > Martin and I proposed a simple strategy for that, but Kenji implemented a > different algorithm that nobody understands, and has proved inadequate. > There are a couple unresolved bug reports on that. Would it make sense then to change it to work more like what you and Martin were thinking of doing? - Jonathan M Davis
Re: D is dead
On 8/28/2018 6:39 AM, Iain Buclaw wrote: Template emission strategy is a mess, we're better off just instantiating all templates in all compilation units, and let the compiler decide whatever to discard. Even -allinst does not instantiate enough to allow the compiler to make such decisions that C++ has no problem with (most of the time). Martin and I proposed a simple strategy for that, but Kenji implemented a different algorithm that nobody understands, and has proved inadequate. There are a couple unresolved bug reports on that.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Tuesday, 28 August 2018 at 13:39:40 UTC, Iain Buclaw wrote: On Thursday, 23 August 2018 at 15:35:45 UTC, Joakim wrote: On Thursday, 23 August 2018 at 07:37:07 UTC, Iain Buclaw wrote: On Thursday, 23 August 2018 at 06:58:13 UTC, Joakim wrote: On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote: [...] Can you list what you or other Weka devs believe those fatal flaws to be? Because you've not listed any here, which makes you no better than some noob that comes in here, says D has to get better or it will die, then can't articulate what they mean by "better" or worse, mentions something trivial. Of course, you've actually used the language for years, so presumably you've got some real concerns, but do you really think the bug you just posted is "fatal" to the language? If you think there are fatal flaws, you might as well list them, whether technical or the development process, or you will just be ignored like any other noob who talks big and can't back it up. You may be ignored anyway, ;) but at least you'll have made a case that shows you know what you're talking about. I'd define fatal as some that can be fixed, but breaks 100% of everyone's code, even if the change is net positive all round. However how big a problem really is is in the eye of the beholder. An example: Symptom: The compiler can't discard unused symbols at compile time, and so it will spend a lot of time pointlessly optimising code. Problem: D has no notion of symbol visibility. Possible Solution: Make all globals hidden by default unless 'export'. Side effects: Everyone will be spending weeks to months fixing their libraries in order to only mark what should be visible outside the current compilation unit as 'export'. Benefits: Faster compile times, as in, in the most extreme example I've built one project on github with gdc -O2 and build time went from 120 seconds to just 3! So your example of a fatal flaw is that D could be 100X faster at compilation instead of just 10X than most every other native language out there?! C'mon. But that's not true. D isn't a fast language to compile, dmd is just a fast compiler. You may get a little leading edge with codebases that are effectively C. Once you throw templates into the mix though, your problems become exponential. Spending 4 seconds in the front end and codegen, only to wait 2 minutes in the optimizer is horrific. The alternative of discarding what seem to be unused symbols only results in linker error of the obscure edge cases sort. Template emission strategy is a mess, we're better off just instantiating all templates in all compilation units, and let the compiler decide whatever to discard. Even -allinst does not instantiate enough to allow the compiler to make such decisions that C++ has no problem with (most of the time). I think I've hit a variation of this problem before, where pulling in a single selective import in Phobos somewhere meant the entire module was compiled into the executable (though I suppose that could be a linker issue?): https://forum.dlang.org/thread/gmjqfjoemwtvgqrtd...@forum.dlang.org I guess this is why scoped/selective imports didn't help that much in disentangling Phobos. I figured it wasn't a big deal if it was just causing bigger executables, but even though I mentioned compilation speed there, I didn't think of how that's slowing down the compiler too, as you now note. Pruning what's evaluated by the compiler based on scoped/selective imports, rather than apparently including the whole module, and getting D compilers to compile parallelized without separately invoking each module/package, ie a -j flag for the compiler when you invoke it with all your source at once, might be good projects for us to crowdfund, as discussed in this and my earlier Nim thread. Separate parallel compilation works wonders on my octa-core Android/AArch64 phone, where I mostly build D now, would be good to be able to combine that with invoking ldc with all source at once.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Thursday, 23 August 2018 at 15:35:45 UTC, Joakim wrote: On Thursday, 23 August 2018 at 07:37:07 UTC, Iain Buclaw wrote: On Thursday, 23 August 2018 at 06:58:13 UTC, Joakim wrote: On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote: [...] Can you list what you or other Weka devs believe those fatal flaws to be? Because you've not listed any here, which makes you no better than some noob that comes in here, says D has to get better or it will die, then can't articulate what they mean by "better" or worse, mentions something trivial. Of course, you've actually used the language for years, so presumably you've got some real concerns, but do you really think the bug you just posted is "fatal" to the language? If you think there are fatal flaws, you might as well list them, whether technical or the development process, or you will just be ignored like any other noob who talks big and can't back it up. You may be ignored anyway, ;) but at least you'll have made a case that shows you know what you're talking about. I'd define fatal as some that can be fixed, but breaks 100% of everyone's code, even if the change is net positive all round. However how big a problem really is is in the eye of the beholder. An example: Symptom: The compiler can't discard unused symbols at compile time, and so it will spend a lot of time pointlessly optimising code. Problem: D has no notion of symbol visibility. Possible Solution: Make all globals hidden by default unless 'export'. Side effects: Everyone will be spending weeks to months fixing their libraries in order to only mark what should be visible outside the current compilation unit as 'export'. Benefits: Faster compile times, as in, in the most extreme example I've built one project on github with gdc -O2 and build time went from 120 seconds to just 3! So your example of a fatal flaw is that D could be 100X faster at compilation instead of just 10X than most every other native language out there?! C'mon. But that's not true. D isn't a fast language to compile, dmd is just a fast compiler. You may get a little leading edge with codebases that are effectively C. Once you throw templates into the mix though, your problems become exponential. Spending 4 seconds in the front end and codegen, only to wait 2 minutes in the optimizer is horrific. The alternative of discarding what seem to be unused symbols only results in linker error of the obscure edge cases sort. Template emission strategy is a mess, we're better off just instantiating all templates in all compilation units, and let the compiler decide whatever to discard. Even -allinst does not instantiate enough to allow the compiler to make such decisions that C++ has no problem with (most of the time).
Re: D is dead
On Thursday, 23 August 2018 at 09:29:30 UTC, Nicholas Wilson wrote: On Thursday, 23 August 2018 at 07:00:01 UTC, Iain Buclaw wrote: On Thursday, 23 August 2018 at 06:34:04 UTC, Shachar Shemesh wrote: On 23/08/18 09:17, Jacob Carlborg wrote: I don't see why we just can't add support for scoped lazy parameters. It's already in the language just with a different syntax (delegates). That would probably be an easy fix (last famous words :)). I guess it would be better if it could be inferred. Here's the interesting question, though: is this *going* to happen? We've known about this problem for ages now. No movement. It's on my todo list, however I've instead been doomed to work on higher priority things. More generally though, some time should be spent on trying out things in the spirit of "will it blend" just to see what happens. Putting effort towards having a more homogeneous environment in the language should in the long run pay its dividends. Is there even any way to escape a lazy? If no, then lazy is identical to scope lazy. E.g. https://run.dlang.io/is fails to compile Link not found. I assume you tried something like returning a delegate that references a lazy parameter?
Re: D is dead
On 8/27/2018 7:02 AM, Don wrote: I can explain this, since I did the original implementation. [...] Thank you, Don. And you do have my mad respect for figuring out Windows SEH.
Re: D is dead
On Saturday, August 25, 2018 2:16:16 PM MDT Walter Bright via Digitalmars-d wrote: > On 8/25/2018 7:37 AM, Jonathan M Davis wrote: > > In general, any place where D was > > designed around the idea that something would _always_ be there (e.g. > > init values and default initialization) but we've then later added the > > ability to get around it (e.g. void initialization or @disable) has > > tended to not play well with everything else and has caused some fun > > problems. > > It's why that stuff isn't allowed in @safe code, and hence one should > realize one is taking responsibility from the compiler for ensuring the > correctness. D expects someone writing @system code to have a much > greater awareness of how the language and the machine works. > > If you remove the blade guards from the table saw, more things can be done > with it, but you'll need to take much greater care using it. Definitely, but some of the features don't play well together even with @system - e.g. if you have a struct with an invariant, you can't use void initialization, because the invariant will be checked when you assign the struct an actual value later. I was forced to remove the invariant that SysTime had years ago, because of issues related to that, and I've basically given up on using invariants in structs as a result. If I'm in full control of all of the code, it's not a problem, but as soon as I'm providing library code to someone eles, struct invariants become land mines. And just in general, it becomes pretty problematic to try to skip or disable something that the lanugage was built around (e.g. default initialization) - though fortunately, it usually interacts better than invariants tend to do when you do something like void initialization. - Jonathan M Davis
Re: D is dead
On Monday, 27 August 2018 at 07:34:37 UTC, Walter Bright wrote: On 8/23/2018 8:53 PM, David Nadlinger wrote: On Thursday, 23 August 2018 at 23:27:51 UTC, Walter Bright wrote: D deals with it via "chained exceptions", which is terrifyingly difficult to understand. If you believe it is understandable, just try to understand the various devious test cases in the test suite. I don't think that assessment is accurate. Yes, I ported EH to a few new targets and wrote the first correct implementation of exception chaining for LDC, so I'm probably a couple of standard deviations off the average D user in that regard. But said average D user doesn't care about most of the nuances of this problem, like the details of implementing exception chaining without allocating too much, I find myself unable to explain the rationale of the behavior exhibited by the current chaining system. I dared not change it, as I presumed somebody surely built a store around it. It does not simply chain exceptions. or which exceptions take precedence in various intentionally twisted test cases. The only documentation for this is the test suite itself, which does not have any documentation or rationale either, just tests. I would appreciate it if you did document what it's supposed to do and why, as likely nobody else knows. Maybe if I understood why I'd be more forgiving of it :-) What they do care about is that the fact that an error has occurred is propagated sensibly in all cases without requiring extra attention, and that information as to the origin is not lost (hence chaining rather than just replacement). Heck, the fact that we still don't have default backtrace handlers that consistently work on all platforms is probably a much bigger problem than the minutiae of exception chaining behaviour. I wish the minutiae was documented somewhere :-( as I care about the nuances of it, if only because I'm ultimately responsible for keeping it working correctly. I can explain this, since I did the original implementation. When I originally implemented this, I discovered that the idea of "chained exceptions" was hopeless naive. The idea was that while processing one exception, if you encounter a second one, and you chain them together. Then you get a third, fourth, etc. The problem is that it's much more complicated than that. Each of the exceptions can be a chain of exceptions themselves. This means that you don't end up with a chain of exceptions, but rather a tree of exceptions. That's why there are those really nasty test cases in the test suite. The examples in the test suite are very difficult to understand if you expect it to be a simple chain! On the one hand, I was very proud that I was able to work out the barely-documented behaviour of Windows SEH, and it was really thorough. In the initial implementation, all the complexity was covered. It wasn't the bugfix-driven-development which dmd usually operates under . But on the other hand, once you can see all of the complexity, exception chaining becomes much less convincing as a concept. Sure, the full exception tree is available in the final exception which you catch. But, is it of any use? I doubt it very much. It's pretty clearly a nett loss to the language, it increases complexity with negligible benefit. Fortunately in this case, the cost isn't really high. -Don.
Re: "Constructor" was a Very Bad name choice we have never recovered from (Was Re: D is dead)
On Monday, 27 August 2018 at 11:02:14 UTC, Guillaume Piolat wrote: C++ binds the two in the same operation. D does not, T.init must be a valid object. This is a major cultural change, though I believe the D way is superior on the efficiency stand-point (you can create large arrays of valid objects quite fast). I mean, then again, @disable this() ...
Re: "Constructor" was a Very Bad name choice we have never recovered from (Was Re: D is dead)
On Monday, 27 August 2018 at 03:06:17 UTC, John Carter wrote: The last few years I have told myself (and anyone who doesn't back away fast enough) that "Constructors" do _not_ construct objects, they are "Name Binders." (Sort of like lisp's "let" macro) They bind instance variable names to pre-existing sub-objects. One could say there is "storage" and "instantiation" of an object. C++ binds the two in the same operation. D does not, T.init must be a valid object. This is a major cultural change, though I believe the D way is superior on the efficiency stand-point (you can create large arrays of valid objects quite fast).
Re: D is dead
On 8/23/2018 8:53 PM, David Nadlinger wrote: On Thursday, 23 August 2018 at 23:27:51 UTC, Walter Bright wrote: D deals with it via "chained exceptions", which is terrifyingly difficult to understand. If you believe it is understandable, just try to understand the various devious test cases in the test suite. I don't think that assessment is accurate. Yes, I ported EH to a few new targets and wrote the first correct implementation of exception chaining for LDC, so I'm probably a couple of standard deviations off the average D user in that regard. But said average D user doesn't care about most of the nuances of this problem, like the details of implementing exception chaining without allocating too much, I find myself unable to explain the rationale of the behavior exhibited by the current chaining system. I dared not change it, as I presumed somebody surely built a store around it. It does not simply chain exceptions. or which exceptions take precedence in various intentionally twisted test cases. The only documentation for this is the test suite itself, which does not have any documentation or rationale either, just tests. I would appreciate it if you did document what it's supposed to do and why, as likely nobody else knows. Maybe if I understood why I'd be more forgiving of it :-) What they do care about is that the fact that an error has occurred is propagated sensibly in all cases without requiring extra attention, and that information as to the origin is not lost (hence chaining rather than just replacement). Heck, the fact that we still don't have default backtrace handlers that consistently work on all platforms is probably a much bigger problem than the minutiae of exception chaining behaviour. I wish the minutiae was documented somewhere :-( as I care about the nuances of it, if only because I'm ultimately responsible for keeping it working correctly. All this is not to say that nothrow constructors aren't a good idea, though. Not much point to debating that, as they're here to stay.
Re: "Constructor" was a Very Bad name choice we have never recovered from (Was Re: D is dead)
Or to put it another way RAII should be "Taking Ownership of a Resource is Initialization, and relinquishing ownership is automatic at the object life time end, but Failure to Acquire a Resource Is Not An Exceptional Circumstance" Not as catchy, but far less problematic.
"Constructor" was a Very Bad name choice we have never recovered from (Was Re: D is dead)
On Friday, 24 August 2018 at 02:33:31 UTC, Jonathan M Davis wrote: Walter Bright wrote: My personal opinion is that constructors that throw are an execrable programming practice, and I've wanted to ban them. (Andrei, while sympathetic to the idea, felt that too many people relied on it.) I won't allow throwing constructors in dmd or any software I have authority over. Wow. I'm surprised by this. I expect that you'd have a riot on your hands though if you actually tried to push for getting rid of throwing constructors. A generation of programmers have been mislead down a deep rabbit hole thinking that "Constructors" are things that "Construct" objects. This has to led to a generation of vaguely smelly code that "does too much work in the constructor" (of which throwing exceptions is evidence). The last few years I have told myself (and anyone who doesn't back away fast enough) that "Constructors" do _not_ construct objects, they are "Name Binders." (Sort of like lisp's "let" macro) They bind instance variable names to pre-existing sub-objects. This attitude coupled with an a rule of thumb, "make it immutable unless I prove to myself that I _need_ it to be mutable" has led to a major improvement in my code.
Re: D is dead
On 8/25/2018 7:37 AM, Jonathan M Davis wrote: In general, any place where D was designed around the idea that something would _always_ be there (e.g. init values and default initialization) but we've then later added the ability to get around it (e.g. void initialization or @disable) has tended to not play well with everything else and has caused some fun problems. It's why that stuff isn't allowed in @safe code, and hence one should realize one is taking responsibility from the compiler for ensuring the correctness. D expects someone writing @system code to have a much greater awareness of how the language and the machine works. If you remove the blade guards from the table saw, more things can be done with it, but you'll need to take much greater care using it.
Re: D is dead
On 8/25/2018 6:33 AM, Shachar Shemesh wrote: If you allow a feature to be disabled, you really need to keep in mind that feature might be well and truly disabled. Disabling default initializations is not @safe, and that means taking responsibility for it not being default initialized. It's like turning off array bounds checking. Then it's up to you to ensure no buffer overflows are happening. On a pragmatic note, what you're asking for is a set of nested try blocks, one for each field with a throwing constructor, as opposed to one try block around the entire function. This is an expensive proposition in terms of performance. You'll need to weigh that very carefully against saving the default zero initialization of the struct, which is very efficient.
Re: D is dead
On Saturday, August 25, 2018 7:33:47 AM MDT Shachar Shemesh via Digitalmars-
d wrote:
> On 25/08/18 10:56, Walter Bright wrote:
> > On 8/24/2018 6:34 AM, Shachar Shemesh wrote:
> >> No, unlike what I suggest, that doesn't work without carefully
> >> reviewing every single place you put it to see whether the constructor
> >> actually supports destructing a partially constructed object.
> >
> > All D objects are default-initialized before the constructor sees it
> > (unlike C++). A destructor should be able to handle a
> > default-initialized object.
>
> I'm not talking about a default initialized object. I'm talking about an
> object where the constructor started running, but not to completion.
>
> With that said, this statement is, I think, representative of the Lego
> problem D has. All D objects? Really? Even this one?
>
> struct A {
>int a;
>
>@disable this();
>@disable init;
>
>this(int number);
>~this();
> }
>
> If you allow a feature to be disabled, you really need to keep in mind
> that feature might be well and truly disabled.
As I understand it, it's not actually possible to disable the init value.
Even if bodies are provide for the constructor and destructor (so that they
don't give you errors), you just end up with an error like
q.d(14): Error: no identifier for declarator init
You could replace that with something like
@disable void init();
but that's only legal because declaring a member named init has never been
made illegal even though it's generally been agreed upon (by most of the
core devs anyway) that it should be. The way D is designed, there _must_ be
an init value. The closest that you can get to disabling it is the
@disable this();
line which just disables default initialiation. The init value still gets
used when constructing the object, and it can still be used explicitly.
If void initialization of member variables worked the way that some folks
think that it should - including Andrei and Walter:
https://issues.dlang.org/show_bug.cgi?id=11331
https://issues.dlang.org/show_bug.cgi?id=11817
then I think that that would definitely be an example that would fit the
point that you're trying to make (since they you have to worry about the
constructor partially setting values on top of garbage and then trying to
destroy that correctly), but at least for the moment, it doesn't actually
work. Having to worry about destructors running on void initialized objects
is a similar problem, but not quite the same, since that doesn't involve an
exception being thrown from a constructor. Regardless, even if a type is
designed such that its init value can be properly destroyed, and you don't
have to worry about void initialization, it can't be all that hard to design
it such that the destructor won't work properly if the constructor doesn't
complete properly.
What all of this makes me think of though is a similar problem that
FeepingCreature loves to bring up and complain about, which is that
invariants that consider the init value to be invalid (e.g. if the invariant
checks that a member variable is non-null) blow up in your face if the type
has a destructor, because the invariant gets run before the destructor, and
member variables that are pointers will of course be null in the init value.
And while disabling default initialization helps, it doesn't fix the problem
because of code that explicitly uses the init value. To work around this,
he's come up with some weird solution using unions that's probably going to
break on him at some point (though if I understand correctly, he's changed
std.typecons.Nullable to use it, which makes it a lot less likely that it's
going to break). But really, having an invariant that fails for the init
value is generally a recipe for disaster, much as it's easy to see why it
would be desirable for stuff like pointers.
What's worse is that once void initialization is involved, an invariant is
almost certainly going to fail, because the invariant gets called before
opAssign. And that's the number one reason that I never use invariants in
structs anymore.
In any case, all of that is really a tangent with regards to init values,
but it's definitely a sign of how some of the stuff around init values,
constructors, and destructors doesn't really play well together. And sadly,
it's really not that hard to get into a state where your destructor is going
to have serious problems if it's run. In general, any place where D was
designed around the idea that something would _always_ be there (e.g. init
values and default initialization) but we've then later added the ability to
get around it (e.g. void initialization or @disable) has tended to not play
well with everything else and has caused some fun problems.
- Jonathan M Davis
Re: D is dead
On 25/08/18 10:56, Walter Bright wrote:
On 8/24/2018 6:34 AM, Shachar Shemesh wrote:
No, unlike what I suggest, that doesn't work without carefully
reviewing every single place you put it to see whether the constructor
actually supports destructing a partially constructed object.
All D objects are default-initialized before the constructor sees it
(unlike C++). A destructor should be able to handle a
default-initialized object.
I'm not talking about a default initialized object. I'm talking about an
object where the constructor started running, but not to completion.
With that said, this statement is, I think, representative of the Lego
problem D has. All D objects? Really? Even this one?
struct A {
int a;
@disable this();
@disable init;
this(int number);
~this();
}
If you allow a feature to be disabled, you really need to keep in mind
that feature might be well and truly disabled.
Re: D is dead
On Saturday, 25 August 2018 at 07:56:55 UTC, Walter Bright wrote: On 8/24/2018 6:34 AM, Shachar Shemesh wrote: No, unlike what I suggest, that doesn't work without carefully reviewing every single place you put it to see whether the constructor actually supports destructing a partially constructed object. All D objects are default-initialized before the constructor sees it (unlike C++). A destructor should be able to handle a default-initialized object. Then we should add a switch to inject a unittest to run a destructor on a default initialisable object. i.e. if it has a static opCall or an @disable this(); then don't otherwise do. Otherwise this is a well disguised instance of faith based programming.
Re: D is dead
On 8/24/2018 6:34 AM, Shachar Shemesh wrote: No, unlike what I suggest, that doesn't work without carefully reviewing every single place you put it to see whether the constructor actually supports destructing a partially constructed object. All D objects are default-initialized before the constructor sees it (unlike C++). A destructor should be able to handle a default-initialized object.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, 24 August 2018 at 11:55:47 UTC, Petar Kirov [ZombineDev] wrote: One of the things that makes Go successful is the quality/ease of use of its toolchain. They have full cross-compilation support out of the box because they don't rely on anything from the C toolchain (libc, linker, etc.). They implement implement everything themselves, from the syscall layer This is something that has caused breakage on newer versions of macos, and broadly makes it difficult to port to new OSes. Something that might be worth pursuing, though, is implementing some of the things in core.stdc in pure d, like printf or strcmp, but printf *would* ultimately forward to the actual libc fwrite.
Re: D is dead
On Friday, 24 August 2018 at 22:52:07 UTC, Steven Schveighoffer wrote: I really don't want to see dlang have to maintain posix system calls on all supported OSes when that's already being done for us. Windows makes this simpler -- the system calls are separate from the C runtime. It would be nice if Posix systems were that way, but it's both silly to reinvent the system calls (they are on every OS anyways, and in shared-library form), and a maintenance nightmare. Keep in mind that we only need to implement the system calls that we need. I haven't looked into Phobos, and probably never will. My interest is mostly in druntime. At this time, I think we only need 2: `sbrk` and `mmap` for `malloc`. I don't consider that much of a maintenance burden, and `malloc` and friends are my least concern at the moment. We're disproportionately leveraging libc in druntime; there are only a few things needed from libc for druntime, and I think I can demonstrate benefit writing them in D (or if someone else wants to, please do, I may never even get to it). If I even stick around in the D community long enough to pursue this, this change it'll be incremental and I'll demonstrate benefit each step of the way. Mike
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, August 24, 2018 4:44:31 PM MDT Dominikus Dittes Scherkl via Digitalmars-d wrote: > You're underestimating the benefits. It's not just to be > eventually slightly faster. It makes @safe versions possible, > this in turn avoids a lot of @trusted calls, so reduces review > effort. It allows also to develop own kernels (for maybe new > hardware) without needing a c-toolchain an it makes D more self > contained. There are certainly more advantages. And if you don't > like it, the c stuff remains there for you to use. It doesn't reduce the number of @trusted calls at all. Best case, you're talking about using @trusted with syscall instead of a function like stat, and for many of the C functions, it's perfectly reasonable to just mark their bindings as @trusted, eliminating the need to use @trusted yourself entirely. You're not reducing the number of uses of @trusted. All you get out of it is that then you've written the OS code using @system rather than relying on the C programmers to do their job when writing basic OS stuff. You then might catch a problem writing that code that someone writing the same code in C wouldn't have caught as easily, but that's it. You're bypassing a _heavily_ used and tested piece of code written by experts just because you want to be able to have @safe verify it, or because you want to avoid it simply because it's C. And because of the prevalence of pointers to local addresses in such code, there's a pretty good chance that a lot of it will have to be hand-vetted and marked with @trusted anyway instead of being able to take advantage of @safe. And if someone wants to write an OS in D, then fine. They can do it. There's nothing about our current approach that stops them. As I understand it, there have already been a couple of projects to do exactly that, but you're not going to replace the major OSes with D any time soon (or likely ever), and the vast majority of D code is going to be interacting with those OSes - most of which provide their public APIs via C (many via the same POSIX API). By using libc like everyone else, we get to take advantage of that work and work with a more portable API, risking fewer bugs in the process. Right now, we don't have to test all of the bindings in druntime to death, because they're just bindings, and we can rely on the libc guys to have done their job, whereas we would then be doing their jobs if we insisted on bypassing libc. It's a maintenance nightmare for little to no benefit. I don't want to have to deal with it as a maintainer, and I don't want programs that I write to be bypassing libc using a custom implementation just because someone decided that they didn't like the fact that it was in C instead of D. - Jonathan M Davis
Re: D is dead
On 8/24/18 6:16 PM, Jonathan M Davis wrote: On Friday, August 24, 2018 7:46:57 AM MDT Mike Franklin via Digitalmars-d wrote: On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote: I think that you're crazy. No, I just see more potential in D than you do. To be clear, I'm not calling you crazy in general. I'm calling the idea of bypassing libc to call syscalls directly under any kind of normal circumstances crazy. There is tons of work to be done around here to improve D, and IMHO, reimplementing OS functions just because they're written in C is a total waste of time and an invitation for bugs - in addition to making the druntime code that much less portable, since it bypasses the API layer that was standardized for POSIX systems. Let me say that I both agree with Jonathan and with Mike. I think we should reduce Phobos dependence on the user-library part of libc, while at the same time, not re-inventing how the OS bindings are called. For example, using Martin's std.io library instead of . I really don't want to see dlang have to maintain posix system calls on all supported OSes when that's already being done for us. Windows makes this simpler -- the system calls are separate from the C runtime. It would be nice if Posix systems were that way, but it's both silly to reinvent the system calls (they are on every OS anyways, and in shared-library form), and a maintenance nightmare. For platforms that DON'T have an OS abstraction, or it's split out from the user library part of libc, it would be perfectly acceptable to write a shim there if needed. I'd be surprised if it's not already present in C form. -Steve
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, 24 August 2018 at 22:16:25 UTC, Jonathan M Davis wrote: On Friday, August 24, 2018 7:46:57 AM MDT Mike Franklin via Digitalmars-d wrote: On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote: > I think that you're crazy. No, I just see more potential in D than you do. To be clear, I'm not calling you crazy in general. I'm calling the idea of bypassing libc to call syscalls directly under any kind of normal circumstances crazy. There is tons of work to be done around here to improve D, and IMHO, reimplementing OS functions just because they're written in C is a total waste of time and an invitation for bugs - in addition to making the druntime code that much less portable, since it bypasses the API layer that was standardized for POSIX systems. It's the kind of thing that's going to cause us way more work, more bugs, and make us that much less compatible with existing libraries. And for what? To _maybe_ get slightly better performance (which you probably won't get)? I honestly think that trying to bypass libc to talk to the kernel directly is actively worse than just using libc much as it would be great if we somehow lived in a world where every library we used was written in D. But the reality of the matter is that there is a _lot_ out there already written in C where it simply makes no sense to try to replace it. We're always going to need to interoperate with C unless we somehow convince all of the C developers to at least switch to -betterC (which obviously isn't happening). - Jonathan M Davis You're underestimating the benefits. It's not just to be eventually slightly faster. It makes @safe versions possible, this in turn avoids a lot of @trusted calls, so reduces review effort. It allows also to develop own kernels (for maybe new hardware) without needing a c-toolchain an it makes D more self contained. There are certainly more advantages. And if you don't like it, the c stuff remains there for you to use.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, August 24, 2018 7:46:57 AM MDT Mike Franklin via Digitalmars-d wrote: > On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote: > > I think that you're crazy. > > No, I just see more potential in D than you do. To be clear, I'm not calling you crazy in general. I'm calling the idea of bypassing libc to call syscalls directly under any kind of normal circumstances crazy. There is tons of work to be done around here to improve D, and IMHO, reimplementing OS functions just because they're written in C is a total waste of time and an invitation for bugs - in addition to making the druntime code that much less portable, since it bypasses the API layer that was standardized for POSIX systems. It's the kind of thing that's going to cause us way more work, more bugs, and make us that much less compatible with existing libraries. And for what? To _maybe_ get slightly better performance (which you probably won't get)? I honestly think that trying to bypass libc to talk to the kernel directly is actively worse than just using libc much as it would be great if we somehow lived in a world where every library we used was written in D. But the reality of the matter is that there is a _lot_ out there already written in C where it simply makes no sense to try to replace it. We're always going to need to interoperate with C unless we somehow convince all of the C developers to at least switch to -betterC (which obviously isn't happening). - Jonathan M Davis
Re: D is dead
On Thursday, 23 August 2018 at 11:02:31 UTC, Mike Franklin wrote: On Thursday, 23 August 2018 at 10:41:03 UTC, Jonathan M Davis wrote: Languages pretty much always get more complicated over time, and unless we're willing to get rid of more stuff, it's guaranteed to just become more complicated over time rather than less. "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery I think that's actually a mistranslation from what he actually said, but it's still quite good. Liberties were taken there, but it's probably more applicable to this situation than a lot of the times C/Unix beards try to play it as though their tech of choice is beyond culpability. For context, he's talking about the process of aeronautical engineering and the thrust of this statement is really commentary on effort and elegance. A little before that, he talks about the grand irony that so much thoughtful effort and design goes into refining things so they're as simple as possible. But "simple" is relative to the thing and the task (my understanding is that "simple" kind of conflates "reliable" here, too). So this is where he rightly acknowledges that the process of refinement isn't a waste for what it removes even though it's often much greater than the effort to create something in the first place. It's wrapped in a broader understanding that you have to have something that works at all before you can streamline it. -Wyatt
Re: D is dead
On 8/23/2018 6:57 PM, Shachar Shemesh wrote: At this point I can either use the work-around I already have and (try to, obviously unsuccessfully) forget about it, file a bug report that will be (justifiably) ignored because no-one else can reproduce it, or spend an unknown amount of time (two days would probably be low-balling at this point) in trying to get this to reproduce on a watered down version of the code. Which would you pick? You should file a bug report, even with no example. It'll still be a clue, sometimes I can find problems without an example. But still, assuming it is a compiler bug is a dodgy practice. I've drilled down on a lot of bug reports that the submitter was absolutely sure was a compiler bug, that turned out to be invalid.
Re: D is dead
On 8/24/18 10:02 AM, David Nadlinger wrote: On Friday, 24 August 2018 at 03:53:38 UTC, David Nadlinger wrote: […] All this is not to say that nothrow constructors aren't a good idea, though. This was meant to say nothrow DEstructors, as hopefully obvious from context. —David I was about to throw down some constructive criticism, but you caught it early ;)
Re: D is dead
On Friday, 24 August 2018 at 03:53:38 UTC, David Nadlinger wrote: […] All this is not to say that nothrow constructors aren't a good idea, though. This was meant to say nothrow DEstructors, as hopefully obvious from context. —David
