On Fri, 2019-10-18 at 13:35 +0000, Guillaume Piolat via Digitalmars-d wrote:
> On Friday, 18 October 2019 at 11:36:45 UTC, Chris wrote:
> > But how does D scale?
> > 
> 
> I'm glad you asked!
> Your question is not very specific ("scales") but let's try.

How does any programming language scale? It doesn't, it's just a programming language.

If we take scale to mean able to be as easily used by 200 programmers on a 10,000,000 line codebase as as 1 programmer on a 100 line codebase, then generally no-one has any idea, and certainly no data. For any language. The whole scaling argument regarding codebases is usually vacuous philosophising. Most teams use a programming language and then find out how to use it for big codebases as for little ones when their little codebase becomes a big one. cf. FORTRAN, Fortran, C++, COBOL, Go, Rust, Lisp, SML, etc.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Friday, 18 October 2019 at 13:54:19 UTC, Russel Winder wrote:
> On Fri, 2019-10-18 at 13:35 +0000, Guillaume Piolat via Digitalmars-d wrote:
>> On Friday, 18 October 2019 at 11:36:45 UTC, Chris wrote:
>> > But how does D scale?
>> > 
>> 
>> I'm glad you asked!
>> Your question is not very specific ("scales") but let's try.
>
> How does any programming language scale? It doesn't, it's just a programming language.
>
> If we take scale to mean able to be as easily used by 200 programmers on a 10,000,000 line codebase as as 1 programmer on a 100 line codebase, then generally no-one has any idea, and certainly no data. For any language. The whole scaling argument regarding codebases is usually vacuous philosophising. Most teams use a programming language and then find out how to use it for big codebases as for little ones when their little codebase becomes a big one. cf. FORTRAN, Fortran, C++, COBOL, Go, Rust, Lisp, SML, etc.

Where is no data or conclusive evidence, there are some anecdotes.
- some people with large python codebases, even full-time, tend to tell me that dynamic types don't "scale" that well past 10 kLOC
- some problems reveal themselves "at scale". For example in a C++ constructor you can leave a filed uninitialized. I've once 2 weeks on such a bug that cascaded in a complicated system.  D has .init and would have avoided that.
- Java seems to scale exceptionally well thanks to a culture of reuse and comparably simple language
I don't think it's all in our heads that some language are more conducive to "scale", whatever that means.

On Friday, 18 October 2019 at 07:56:26 UTC, drug wrote:
> On 10/17/19 11:48 PM, aliak wrote:
>> On Thursday, 17 October 2019 at 18:00:39 UTC, Mike Parker wrote:
>>> On Thursday, 17 October 2019 at 16:50:15 UTC, Rumbu wrote:
>>>
>>>> [...]
>>>
>>> Private to the module *is* correct in D.
>>>
>>> http://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/
>> 
>> That's debatable: https://github.com/aliak00/d-isms/blob/master/da-faq/06-access-levels.md
>
> You complain that `doAmazingStuff` can access private members of class A if this function and this class are placed together in one module and continue complain that if you put that class in its own module then `doAmazingStuff` now cannot access private members of A and isn't a "first class" citizen of class A. Could you explain you position clearly?

My position on what? No private access is the consequence of moving a function out of a module.

On Friday, 18 October 2019 at 11:36:45 UTC, Chris wrote:
>>> Desktop / server only I suppose. How does it scale?
>>
>> Hence the iOS effort.
>
> I couldn't wait anymore. Something so basic (not simple). That's when D comes back to bite you. Sad but true.
>
I have this view. If current libraries or services in all languages do not satisfy your needs and you want to build your own solution then D is the perfect language. If you want to take a bunch of libraries, put some glue code and shit a product then D is a bad language for you.

I never had false idea that D is full of wonderful libraries for all my needs so I never had any problem when I didnt found something in dub. I bet most people have similar view.

On Thursday, 17 October 2019 at 18:18:49 UTC, Jacob Carlborg wrote:
> On 2019-10-16 13:14, Atila Neves wrote:
>
>> What tooling what you like to see developed that doesn't exist now?
>> I keep reading online that Go has great tooling, but having used it I don't know what people mean when they say that. Likewise, I read that people want D to have great tooling but I also don't know what they mean then either.
>
> In general the compiler (DMD) needs to be able to be used as a library to build various tools on top of it. A great start is to have a full working LSP [1] server which uses DMD as a library under the hood. Features supported by LSP include:

<snip>

I agree and support all of this. I know that dmd as a library right now can only be used from dub with `~master`. What is the technical reason stopping a version number again?

On Thursday, 17 October 2019 at 18:38:31 UTC, Rumbu wrote:
> On Thursday, 17 October 2019 at 17:56:03 UTC, H. S. Teoh wrote:
>> On Thu, Oct 17, 2019 at 04:50:15PM +0000, Rumbu via Digitalmars-d wrote:
>>> On Thursday, 17 October 2019 at 16:26:07 UTC, Atila Neves wrote:
>>> > On Thursday, 17 October 2019 at 15:24:09 UTC, Rumbu wrote:
>>> > > On Thursday, 17 October 2019 at 12:51:17 UTC, Atila Neves wrote:
>>> > > > What is it about OOP in D that you find lacking?
>>> > > > 
>>> > > 
>>> > > The general attitude "OOP is bad, let's use a struct instead".
>>> > 
>>> > I don't know what to do about this. I prefer structs myself.
>>> 
>>> Wonderful. Then why ask in the first place?
>>
>> He was just trying to understand where you're coming from. Doesn't mean he has to agree with you.
>
> I already stated that my opinion is irrelevant and suggested to take the survey as starting point for the Vision. Why ask about an opinion if you really don't care? Just to make me feel better for ten seconds? Wow, I appreciate.

I definitely care about your opinion. I'm sorry if it came across otherwise. I asked because I wanted to know what your problems with OOP in D are, and to know if anything can be done to mitigate or eliminate them.

> strongly support my opinion: I need a library solution to do OOP in D.

I don't understand what you mean by this. What is it about OOP in D now that you can't get done without a library solution? And why are library solutions insufficient for those purposes?

On Fri, Oct 18, 2019 at 03:09:02PM +0000, welkam via Digitalmars-d wrote: [...]
> I have this view. If current libraries or services in all languages do not satisfy your needs and you want to build your own solution then D is the perfect language. If you want to take a bunch of libraries, put some glue code and shit a product then D is a bad language for you.
[...]

Very interesting view.  This probably explains why I like D so much -- I've never liked the idea of just throwing a bunch of libraries together with some glue code and calling it a product.  But I bet most people would disagree.  *shrug*


T

-- 
Once the bikeshed is up for painting, the rainbow won't suffice. -- Andrei Alexandrescu

On Friday, 18 October 2019 at 16:07:43 UTC, Atila Neves wrote:
> On Thursday, 17 October 2019 at 18:18:49 UTC, Jacob Carlborg wrote:
>> On 2019-10-16 13:14, Atila Neves wrote:
>>
>>> What tooling what you like to see developed that doesn't exist now?
>>> I keep reading online that Go has great tooling, but having used it I don't know what people mean when they say that. Likewise, I read that people want D to have great tooling but I also don't know what they mean then either.
>>
>> In general the compiler (DMD) needs to be able to be used as a library to build various tools on top of it. A great start is to have a full working LSP [1] server which uses DMD as a library under the hood. Features supported by LSP include:
>
> <snip>
>
> I agree and support all of this. I know that dmd as a library right now can only be used from dub with `~master`. What is the technical reason stopping a version number again?

Isn't it because 2.088.1 isn't semver-compliant ? It would need to be tagged at something like 2.88.1 (and thus changing the versioning scheme) to be recognized as a correct version by Dub, if I'm not mistaken

On Fri, Oct 18, 2019 at 12:47:51PM +0000, Adam D. Ruppe via Digitalmars-d wrote: [...]
> My libraries have a pretty good compatibility record. Yes, sometimes I push half-baked stuff and people get warnings or whatever, but I tend to fix those fairly quickly so 99% of the time you grab my code it is probably going to work on old and new compilers alike.
> 
> Many of my modules work with D versions going back two years or more. I actively test on gcc releases now too, and (in)famously avoid third-party library entanglements... again, for the most part.

I actually *really* like your philosophy of avoiding 3rd party library entanglements.  Using 3rd party libraries seems to be the bandwagon these days, but it seems people are turning a blind eye to its downsides.  Being able to just copy the darned source file into my source tree and just compile away is so refreshingly simple and effective, as opposed to needing to install some NP-complete dependency solver, waiting 5 seconds (often more) for said solver to solve that damned dependency graph every time I build, and needing network access just to be able to get a pristine copy of the sources, and when the 3rd party server goes down for whatever reason, you're stuck, ad nauseaum.

I don't like libraries that comes with all sorts of dependency strings attached. Just give me the darned file, plop it in, and compile away -- no strings attached, no fuss, no muss, no requirements of over-complex, over-engineered dependency graphs -- *that's* the best kind of library.


T

-- 
What do you get if you drop a piano down a mineshaft? A flat minor.

On Friday, 18 October 2019 at 12:47:51 UTC, Adam D. Ruppe wrote:
> But actually a lot of the stuff from the last year I like a lot. And cgi.d now uses static foreach in some optional sections. Pretty cool stuff.

I actually just now took the last couple hours in guaranteeing* this compatibility: cgi.d uses mixin to work around the grammar change, but it now has core functions working on gdc as well! With a few more tweaks, 49 of my library modules are now confirmed to work on the newest dmd as well as the gdc that came out of my Slackware package manager.

gdc in upstream gcc release is based on frontend 2.076.0 (Sep 1, 2017). This means my libs have two years of compatibility :)

And fun fact, while I was in there, I  tested my old D1 code. It did need a few trivial tweaks - changing array from C-style to D-style mostly - but it now works on newest dmd as well as old D1 compiler equally well. That's about 11 years of compatibility!

ps don't use those old d1 files i maintain them for the lulz not for the serious use.


* not actually guaranteed in any legal sense i explicitly disclaim all warranties including but not limited to merchantability for a particular purpose. USE AT YOUR OWN RISK.

or give me all your money then maybe we can work out a formal support agreement. lol