On Sunday, 14 April 2019 at 08:33:29 UTC, Nicholas Wilson wrote:
> On Sunday, 14 April 2019 at 08:21:38 UTC, Walter Bright wrote:
>> Also, upending the code base with large changes and reorganizations is not likely to get incorporated, and be aware that people can and do disagree strongly about what constitutes improvement and what doesn't. When in doubt, do a small version and see how it goes.
>
> The DMD codebase suffers from systemic misorganisation, both on the massive function level, and the complete lack of organisation of the files in the source directory. Small change are never going to fix those issues.
>
> You are trying to find a local optimum, we need to find a more global one, and that involves doing things like https://github.com/dlang/dmd/pull/9511#discussion_r270614236

Long functions and files not "well" organized are the typical issues noticed by an incompetent maintainer.

On Sunday, 14 April 2019 at 12:34:12 UTC, Chris wrote:
> On Sunday, 14 April 2019 at 09:42:01 UTC, Laeeth Isharc wrote:
> [...]
>
>> [...]
>
> That's all good and well and I sincerely congratulate you on your success. But what I see is the following divide: those who say that D works for their business usually use it for very specific purposes with a custom made ecosystem they've built up over the years (as I did too) maybe bound to a particular version of dmd or D1, and it's often for in-house purposes, e.g. analyzing the stock market or optimizing internet ads or machine learning. D is of course a good tool for that kinda stuff (as is Lisp or Scala). But once you have to step out of your biotope things get hairy. Once customers depend on your software directly (as in: installing it directly on a machine, interfacing with it via plug ins or accessing an API on your web server), you're out in the wild with D as far as tooling and stability (breaking changes) are concerned. In other words, D is good for fenced off software that is built for very specific purposes. When it comes to "general purpose", however, it's a different story all together. This is what I'm trying to convey.
>
> [...]

While I would agree with your arguments 5 years ago, I can't agree these days. So much happened which made D and its eco system usuable from small companies to big companies.

Please provide details where you see the issues, otherwise it is impossible to understand what you mean.

Kind regards
Andre

On Sunday, 14 April 2019 at 12:49:04 UTC, Andre Pany wrote:
> On Sunday, 14 April 2019 at 12:34:12 UTC, Chris wrote:
>
> While I would agree with your arguments 5 years ago, I can't agree these days. So much happened which made D and its eco system usuable from small companies to big companies.
>
> Please provide details where you see the issues, otherwise it is impossible to understand what you mean.
>
> Kind regards
> Andre

One example is vibe.d, I used it until roughly a year ago (I had used it for years) and I remember the dozens of compiler warnings with every new version of dmd. Sönke / vibe.d devs were (and still are?) playing catch-up with dmd. See, the more you use third party stuff in D the more you have to worry about, it's no loner only your own code you have to worry about. What if the maintainer doesn't have the time to fix it? You'll be stuck with a particular version of dmd and vibe.d or any other third party software. This actually makes you think twice if you wanna depend on a lib in D. It's a constant gamble as it may hit you any time. It doesn't happen to me in other languages, funny that.

Another one is the eternal issue of autodecode - and now there's talk of std.v2. Every time I come back to have a look at what's going on in D, I think "Thank God I made the switch!" Nowadays I spend more time writing new code (= new features = happier users) instead of fixing / worrying about old code. D may be a bit more stable now, as you say, but we can see autodecode and std.v2 on the horizon. The calm before the storm.

On Sunday, 14 April 2019 at 13:08:36 UTC, Chris wrote:
> On Sunday, 14 April 2019 at 12:49:04 UTC, Andre Pany wrote:
>> On Sunday, 14 April 2019 at 12:34:12 UTC, Chris wrote:
>>
>> While I would agree with your arguments 5 years ago, I can't agree these days. So much happened which made D and its eco system usuable from small companies to big companies.
>>
>> Please provide details where you see the issues, otherwise it is impossible to understand what you mean.
>>
>> Kind regards
>> Andre
>
> One example is vibe.d, I used it until roughly a year ago (I had used it for years) and I remember the dozens of compiler warnings with every new version of dmd. Sönke / vibe.d devs were (and still are?) playing catch-up with dmd.

FYI: those are just deprecations. This thing that allows us to slowly change DMD, but still have stability.

Since a bit more than a year, vibe.d is part of the project tester and thus is ensured to always compile as its testsuite is run on every PR.

On Sunday, 14 April 2019 at 12:34:12 UTC, Chris wrote:
> On Sunday, 14 April 2019 at 09:42:01 UTC, Laeeth Isharc wrote:
> [...]
>
>> Yes - the tolerance for experimentation is an important question.
>>  In firms where there isn't much of a tolerance for experimenting and for some of those experiments to fail then it's probably not the right environment to use D.  But I think the more interesting places to work are quite different.
>
> That's all good and well and I sincerely congratulate you on your success. But what I see is the following divide: those who say that D works for their business usually use it for very specific purposes with a custom made ecosystem they've built up over the years (as I did too) maybe bound to a particular version of dmd or D1, and it's often for in-house purposes, e.g. analyzing the stock market or optimizing internet ads or machine learning. D is of course a good tool for that kinda stuff (as is Lisp or Scala). But once you have to step out of your biotope things get hairy. Once customers depend on your software directly (as in: installing it directly on a machine, interfacing with it via plug ins or accessing an API on your web server), you're out in the wild with D as far as tooling and stability (breaking changes) are concerned. In other words, D is good for fenced off software that is built for very specific purposes. When it comes to "general purpose", however, it's a different story all together. This is what I'm trying to convey.

Yes well I don't claim to know about the demands of a business having lots of customers.  I would prefer to have as few customers as possible just due to temperament.

And it's about who your customers are, not just the number of them.

Weka.io have done well but they distribute binaries not source.

Like I say - I think most code is developed behind closed walls.  And I would guess that it's a minority of commercial code that is distributed as source libraries.


> D was a personal success for you, good, but I'm sure in a few years people will tell similar stories about Crystal, Nim and whatnot.

Of course and I hope those languages succeed. Zig too. It's a big world and there is room for plenty of emerging languages.  I don't think the success of one must come at the expense of others - I don't believe life is a zero-sum game as it's inherently generative.

> When you started using D it had the edge over other languages in some respects, but other languages have caught up and offer ease of use on top of that.

No I don't think so.  I think it was better for me and it still is.  That doesn't mean it's better for you because you are a different person doing different things.

If you come to dconf I will show you some of the things we are doing.  Or there's an event the day before that might be interesting.  Laeeth at kaleidic dot io


 > This is what doesn't
> register with the D community. Some users live happily in their respective self-made D biotopes, while others want more, a broader focus (and they mean well as they want D to be suceessful in the world not just in niches). These are the two factions, and it's the biotope faction that dominates the Foundation and the forum,

The Foundation is a new creature that doesn't do that much right now.  People talk of it like an empire!  Bearing in mind Ali wrote a book making it easy to learn D and he is helping the Foundations I hardly think one had grounds to say the Foundation is oriented towards narrow uses of D.

I sponsored the Autumn of Code and the projects selected weren't things that are the biggest priority for me personally, but they were good projects that would benefit D overall.  So I don't really recognise your assertion there either.

Maybe I will have another announcement ready by Dconf, but we shall see.

Importing C and later C++ headers - do you see that as a niche thing?  How about making it possible to write Excel add-ins and Jupyter kernels in D?  In my opinion you need to justify your assertion better.

 indeed the "biotopeism" in the
> community is so far advanced that people have stared to fork D, the ultimate stage of "Ok, I'll do my own thing.", which is of course only a logical consequence of the insular mentality that permeates D culture. You encourage people to do it themselves, they will finally fork.

Yes it's a bunch of opinionated individualists.  Plenty of people forked D already but I wouldn't say there's much information in that - rather I would be extremely puzzled if people weren't forking D.  Whether anything should come of it I don't know.


>
> As there is no way the two factions can communicate with each other, there is only one logical consequence. The faction with the broader focus (like myself) wanders off and what remains are the die hard users who are happy in their biotope, so D will remain a niche language and, of course, there's the danger that some people will break off, fork D and add to the general chaos (and you may read questions like this on Stackoverflow: "Which D should I use? There are N implementations. Dragon, Volt, BetterD, CleanD, SaneD...").

It's really strange to me.  You seem happier not using D and maybe it was the right decision for you given the business you are in.  But without skin in the game you have very strong opinions about the direction the language ecosystem should develop towards.

If you look at the companies using D, how would you describe the niche of D commercially?  I don't think it's possible to do so based on domain.  And note that certain others make the opposite complaint - that D doesn't have a niche and that people should decide what it should be.

I think that adoption is driven by the kinds of people that use D rather than the domain - it's a question of capabilities, culture and values.

Early adopters aren't like normal people.  D isn't ready for adoption by the masses yet, and that's entirely normal and just how the innovation cycle tends to unfold.

On Sunday, 14 April 2019 at 13:30:45 UTC, Seb wrote:
>
> FYI: those are just deprecations. This thing that allows us to slowly change DMD, but still have stability.
>
> Since a bit more than a year, vibe.d is part of the project tester and thus is ensured to always compile as its testsuite is run on every PR.

Thanks. Good to know that, however, a lot of that stuff came too late for me personally (and it wasn't lack of patience but necessity), and while vibe.d may be stable - for now - what about all the other libs out there? It's still a big gamble with all that talk of std.v2 (which I think is necessary). But if I'll have to rewrite my D code one day anyway, I might as well switch to a different language all together, do it once and be done with it. I don't think I'm alone in this respect. Other users seem to have made similar experiences.

On Sunday, 14 April 2019 at 13:47:04 UTC, Laeeth Isharc wrote:
>
> It's really strange to me.  You seem happier not using D and maybe it was the right decision for you given the business you are in.  But without skin in the game you have very strong opinions about the direction the language ecosystem should develop towards.

I simply see what others do right and tell you guys about it so it may help D to thrive (and I have a few years of (good and bad) experience with D too).

> If you look at the companies using D, how would you describe the niche of D commercially?  I don't think it's possible to do so based on domain.  And note that certain others make the opposite complaint - that D doesn't have a niche and that people should decide what it should be.

It's pretty niche, as far as I know, very specific software, Assembly is still being used for specific tasks too and the companies using it may be very successful, but that doesn't say anything about the overall qualities of the language.

> I think that adoption is driven by the kinds of people that use D rather than the domain - it's a question of capabilities, culture and values.

Yes, very specific use cases, crafted by expert programmers. But the same could be said about Assembly, Lisp and C/C++.

> Early adopters aren't like normal people.  D isn't ready for adoption by the masses yet, and that's entirely normal and just how the innovation cycle tends to unfold.

I'd agree if you were talking about Crystal, but D after 20 years??? Nah!

On Sunday, 14 April 2019 at 14:04:53 UTC, Chris wrote:
>[...]

One thing I always notice when I look at young languages like Crystal, Zig, Kotlin etc is that they are very carefully crafted, while D just throws in random features that seem cool and fun to work with but are never really finished.

On Sunday, 14 April 2019 at 00:00:46 UTC, Walter Bright wrote:
> On 4/13/2019 3:12 PM, Nierjerson wrote:
> > Ok, I'm going to step up and take a role, right here right
> now:
> >
> > 1. You need to find someone who will create two things:
>
> > No point in me giving too many of my thoughts because it is a
> task for you to do
>
> > 2. You and your team need to
>
> > Basically you guys need to
>
> > So, you and your team need to
>
> > It means that you simply have to structure things
>
> > I do hope you can figure this out.
>
> This is not stepping up, it's giving me a list of action items. I have an action item for you:
>
> * Find something great on your list of action items and do it!
>
> ---
>
> Allow me to explain a couple things.
>
> This is not a business. There's some paid work going on, but not a whole lot because there isn't a lot of funding. A good compiler engineer would get $500,000/yr. We just don't have a lot of money.

I realize this, and this is why it is even more prudent to do things as best as possible. For example, if you have a yugo and you are racing F1's you better optimize all variables in all ways to stand a chance.

What you have stated is an excuse. Money helps but you don't have it, so do you just give up? Because that is what you are saying whether you realize it or not.

I'm not blaming you or D's management in any way. I know it is an uphill battle. What I'm trying to do here is make you realize that the way your climbing the mounting is a hard route. You need other people that you trust and will commit and bring in to your inner sanctum. Only you can make that decision.

I've noticed H. S. Teoh mention wanting to fork D. I believe he is quite an intelligent person and seems to have alternative views that could provide more of a balance for you guys. You NEED someone that thinks differently. You might need other people. But ultimately you have to realize it would be beneficial to broaden your group(is it just you and Andre?) and that you have to find the right people.

You have to also realize you have to make changes yourself. You must adapt with the times. If you still manage D with the same mindset you did 10 years ago then something is wrong. This is why you need other people to help you. It is IMPOSSIBLE for you to do what is needed by yourself or even you and Andre! If you think it is then you have already failed.

I'm not saying that progress won't be made, I'm saying that it won't be enough[I could be wrong, but I'm 99.99% likely too be right]. I don't want to see D go down the tubes and I don't want to see D stagnate. It is really the language I enjoy programming in the most, but it is also the language I get frustrated with the most. I like to work on weaknesses, not strength. Anyone can work on their strengths, that's the easy job, but we are held down by our weaknesses and weaknesses actually are most beneficial to build(because of diminishing returns and the way knowledge and experience work together(it's O(n!)).


>
> This means relying on volunteers. The fun thing about volunteers is you can't tell them what to do. A normal occurrence is people ask me what to work on. I present a list A, B, C, D, and the person then does H. Why? Because H interests them.

I know, but it is a double edge sword. There has to be a balance!

Remember, if a volunteer wants to do something on his own he can. You shouldn't stop that, it is tyrannical. But some people need and want structure. The best way is to provide both paths. If someone wants to climb the steep cliff they can, others who want the guided tour need that. If you limit any path then you are selecting only those people who will take it.

D suffers from a lack organized structure. If it had too much structure I would be saying the opposite of what I am saying. I'd be "You guys are too dictatorial, you guys need to chill and relax!".



>
> You might think, what a mess. In many ways that's true. On the other hand, working on D is a MARVELOUS opportunity for anyone who wants to jumpstart their career.

D works well in many ways, I'm not saying it is a total mess... not in the least. What I'm saying is simply this:

The D community almost only works on it's strengths... specific feature sets that the most dedicated want to work on and they neglect those things they are not interested in.

This is great for them because, guess what, they are happy. They say things like "Well, D works for me" or "These businesses use D quite successfully". I've used D successfully... if I only judge it on those things that it is successfully used at.

The problem with that is that the things D does poorly in are never developed to any high level and so it never attracts other people who need those things.

You have to realize because of the way D has been run in the past has setup what it is today. Basically it is self-motivated people who are willing to work on their own for their own cause. This has build up a hodge podge of disorganized libraries, all kinds of problems... Over time it gets worse and requires more effort to maintain. For example, if D depreciates certain features then those libraries general bit rot and all that effort is ultimately wasted. Of course, the strengths of D are not so much effected.



> For example, take Iain Buclaw. He single-handedly, doggedly, and indefatigably improved GDC (which had been abandoned) to the point where it was accepted by and officially incorporated into the Gnu Compiler Collection. This is a monumental, career-making achievement. It's the only thing he ever needs to write on his resume. He's a made man.

Yes, and it is quite amazing that people dedicate their precious time... but it is still not the way to go. You are relying on people to build D for you... what happens when they stop? Even if they trickle in over time you have a certain rate of progression of growth that you think will continue building D:

In your mind you see D's growth as

D(t) = m*t

where m is the rate of growth which depends on volunteers contributing to D(which may change over time but we will use averages).

But you fail to take in to account other variables:

D(t) = m*t - d*t - e*t

d is decay rate. It is a measure of bit rot that occurs that hurts D. e is an environmental cost. Such as other compilers that compete with d(such as taking volunteers).

In fact the equation is far more complicated but you are only looking at the positive side(the things that D was well and keeps it going).

Eventually the costs will outweigh the benefits and D will then end bit rotting itself(it will just end up another compiler in the compiler grave yard, where eventually all compilers end up, even C++ will be there one day, but who wants to die young?).


> Many D contributors have leveraged their work on D into high paying jobs that were otherwise closed to them.

I'm not disputing anything like this. But you are only looking at the positives. Your view is warped. You MUST look at the negatives, no matter how painful it is. Without looking at the negatives they will eventually overtake the positives and then you will be forced to look at them(well, you might die before they come in too play but they will occur none the less).

> I'm very proud of these fellows and their achievements. I'm honored that D was the route to their success. The opportunity is here with D for anyone else who wants to learn and show the world what they can do.

No one is trying to knock anything bad about D, what you have done, your intelligence, anyone else's intelligence, anyones contributions, all the hard work, all the dedication, or anything else that has made D what it is.

This discussion ultimately has nothing to do with D's achievements. They HAVE to be ignored, at least on some level, so one can see the negatives. And without seeing the negatives there is no balanced view and D will eventually reach it's limits.

You have to realize that what is being said is not a specific statement about D, it is a general statement about all things(e.g., you are thinking in terms of functions and I'm thinking in terms of templates, so to speak, meaning my statements are more applicable to a wider class of things). I can say what I have said about C++ too, or anything else. You might say then what is the point? The point is that the better one understands these things the better one can control the various factors for specific outcomes.

1.  You agree that all things reach diminishing returns? Eventually whatever grows as has a growth curve and it must(in practical sense, or maybe just average) end up diminishing? Why? Because growth requires resources and all resources are limited(even if astronomical, they are still limited = finite).

2. All things have other factors that control their growth, so many that they are effectively uncountable.

D's progress, like all things, is some N dimensional function that depends on t and many other things. [meaning that if we know all the data we could model it using an N dimensional function rather precisely]

Such functions have orders of growth and decay. Big O notation takes such things in to account. You know sorting routines have such measures of growth. But you realize that D is just some big sort routine that is very complicated? It takes bits and sorts them in to a new array giving some complex function(the grammar, the machine language specification, etc). It's so complex that you have probably even never tried to simplify it in such a way... but make no mistake, it is still just an abstract machine that has the same types of mathematical abstractions in it.

The point is then that there are negative components and if you ignore them then they will catch up and then take over. You are ignoring most of those components. You should try to find the largest ones and reduce their effect.

See, if we were talking about an optimization problem, say a cpu task scheduler, you would have no problem understanding what I'm talking about. You'd say agree and say "Yes, if we want to maximize throughput we need to minimize task switching(it is costly) so we should run the most important tasks first... but we can't starve the smaller tasks completely." and we would come up with some code that would try to optimize the scheduling of the tasks[which is project management too].

You know all about that kinda stuff but you fail to realize it also exists(in a disguised form) in D's own management, which again, is just a program(all things in life are programs... it's no coincidence that transistors and neurons both are switches or that people use the same term for many disparate things. It's because there is a much deeper connection between all things).

Since you, I believe, do understand Big O/Little O notation and theory, I'll simplify the whole discussion to this:

D = o(t) - O(t)

o(t) is the lower bound of D's growth, it can't do any worse than this.

O(t) is the upper bound on D's decay, it can't do any better than this.

You are only looking at o(t), I'm trying to get you to look at O(t) because you are effectively ignoring it(seems to be what most humans do). You are looking at the positive side(o(t)) and ignoring the negative side(O(t)).


But since O(t) is not 0, there is the risk that D's growth will end up "negative" dead. (The universe seems too dictate that O(t) always overtakes o(t) due to finite resources/diminishing returns/bit rot/etc).

Now, if we want to maximize D's growth, we can't just look at o(t), we must also try to deal with O(t).

You have focused so much on o(t) and ignored almost all O(t) that O(t) is the "low hanging fruit". It's got so many terms in it that are large and can be rather easily dealt with(diminishing returns haven't kicked in) that if you realized this and decided to deal with them(as unpleasant as they seem) that you could give a huge boost to the overall growth of D.

But you keep focusing on o(t).

If this was an algorithm, which it is ultimately, your algorithm will be doomed in the long run. Not because of what you have done with o(t) but because of what you haven't done with O(t).

I'm in no way criticizing you for you and others accomplishments on o(t) but I am criticizing you on your neglect of O(t). My statements are purely based in logic, mathematics and reality. Meaning they are mathematical models(simplifications of reality) that are applicable to all things that can be modeled mathematically(which seems to be almost everything in the universe). It's just like how much things can be represented by a differential equation, or how most things can use computers to solve their problems(which is why compilers are so important since they let us more effectively write programs that solve problems).

The balance is to look at both o(t) and O(t). Most people look at only one and ignore the other as if it didn't exist[It might be a left/right brain thing].


If you spent the next month or two just hard core analyzing O(t) you'd probably do more for D than in the last 5 years. You'll see things you never thought existed(because they didn't in your mind since you never saw them). You just have to drop you preconceived notions and biases that have formed. You have conditioned yourself to look at o(t).

You are, in fact, the best person to do this because you know far more about D overall and generally there is actually some type of interdependence between o and O. Of course, having others to help you break out of the mental box you exist in will speed up the process(it's not an attack, we all exist in our own mental boxes, but expanding our boxes almost always is a good thing).


I'll give you a quick example that may or may not mean anything too you. I've always been right handed and have heavily used it for all things so much so that certain things that require the left hand usually slow me down considerably. Such as typing. I am very fast with my right hand, and my left faster than most peoples right hand... but my left hand is not at all at the same level as my right. I decided to try to balance this by forcing myself to use my left hand for things. I now can use it for many different things such as for a mouse and various tooling(soldering iron, etc) and it feels comfortable(not quite at the same level as the right but it's no longer a determent and if I ever lost my right hand it would be quite easy for me to adapt). This thing though is much deeper because our brains are wired in specific ways to our body. By forcing myself to use my left hand I have actually rewired my brain to some degree in a positive way(more balanced).

I even use two mice because sometimes it's much quicker to grab one with the left hand(which I think is because computer input is rather poorly understood. Imagine having a brain harness where you just think of what you want and it happens... keyboards and mice are just middle men that slow this process down).

Now, 5 years ago I would have never thought about such things because I was rather myopic. Thinking that how I thought about things was the way they existed. I have learned through that, that my thinking is limited by me and has little congruence with the real world. The left hand/right hand is just an example. One must always try too find the other side to things, it actually benefits everything. It's hard to understand this until you have done it enough to see how it works(like all things it is experiential). But it is very powerful. I'm trying to get you to at least take a leap of faith here you should do the same type of thing with D[ultimately in everything you do]. At worst you would have wasted some of your time, at best you might completely change your existence or D's progression. I can't tell you specifics in much of a meaningful way since, if you remember, I'm talking more in general terms. You have to fill in those specific details and then analyze the patterns objectively(taking in to account both sides).

On Sunday, 14 April 2019 at 10:25:03 UTC, Guillaume Lathoud wrote:
> Maybe there is a psychological explanation for the debate here - please bear with me - just speculating:

It's a lot less complicated than it sounds.

Some average joes (you know who they are) with zero skin in the game are given the chance to talk to incredible programmers and have them answer in a sort of ego-tripping trance.

But the only way to have them answer is to troll more or less subtly, and this behaviour has been going on for years.

The lesson should only be that the leadership **should not have to listen to this whole load of non-sense** from anonymous low-achievers that blame their tools. And they want things that works well to fail with them.

Do you imagine half the users of python-dev publicly berating Guido, every day for anything he would says? No, because that would be incredibly ridiculous.

Hence why we have so many "helpful", anonymous poster who come with bullet lists of things to do, every day. This must stop because it is neither helpful nor with good intentions.