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.

On Wednesday, 29 August 2018 at 23:47:11 UTC, Laeeth Isharc wrote:
> On Tuesday, 28 August 2018 at 08:51:27 UTC, Chris wrote:

>
> Julia is great.  I don't see it as a competitor to D but for us one way researchers might access libraries written in D.  One could do quite a lot in it, but I don't much fancy embedding Julia in Excel for example, though you could.  Or doing DevOps in Julia.  Perhaps more of a Matlab substitute.
>
> Look around and you can find people grumpy about any language that's used.
> http://www.zverovich.net/2016/05/13/giving-up-on-julia.html
>
> Languages really aren't in a battle to the death with each other.
>  I find this zero-sum mindset quite peculiar.

I'm old enough to a) not become enthusiastic about a language and b) know that you can find fault with any language. It's not about "life or death". D was promising and I liked it and it did things for me no other language could do for me - back in the day. Nowadays many languages have similar features, especially the useful ones that have proven to be, well, useful and not the latest fad. But D has some major issues that have become clear to me after using it for quite a while:

1. unsolved issues like autodecode that nobody seems to care about
2. obvious facepalm moments all over the place (see 1.)
3. moving the goal posts all the time and forcing you into a new paradigm every 1 1/2 years (first it was "ranges", then "templates" and now it's "functional", wait OOP will come back one day). Yeah, a language that doesn't come with a paradigm or ideology, no, a language that only nudges you into a certain direction and makes your code look old and just soooo "not modern" according to the latest CS fashion of the day. "Why do you complain? If you think C++ (as the D leadership did for a long time), of course your code will break, you knob! If it breaks it's for your own good (for now)."
4. nitpicking over details of half baked features that shouldn't be there in the first place, but hey! let's break valid existing code to fix them - or not - or, what about @volatileSafeUB (it's sooo not C++)? Yeah, sounds great. We'll just have to issue a compiler message "error: cannot assign `size_t` to `size_t`"
5. complete and utter negligence of developer reality (ARM, Android, iOS, tools etc.). It's all left to spare time enthusiasts - and their code will break in 4 weeks too. Just you wait and see
6. the leadership doesn't address the issues and gives evasive answers as in "Programmers who..." or on hindsight you're always wiser, other engineers have made mistakes too
7. I've seen it all before, many times, and it's a sign of a sinking ship, rearranging the deck chairs on the Titanic
8. what a pity
9. I hope D will be great again

On Fri, Aug 31, 2018 at 09:37:55AM +0000, Chris via Digitalmars-d wrote: [...]
> 3. moving the goal posts all the time and forcing you into a new paradigm every 1 1/2 years (first it was "ranges", then "templates" and now it's "functional", wait OOP will come back one day).
[...]

Wait, what?  Since when has this ever been a "choose one paradigm among many" deal?  Templates are what enables range-based idioms to succeed, and ranges are what makes it possible to write functional-like code in D.  Since when have they become mutually exclusive?!


T

-- 
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel

On Friday, 31 August 2018 at 14:38:36 UTC, H. S. Teoh wrote:
> On Fri, Aug 31, 2018 at 09:37:55AM +0000, Chris via Digitalmars-d wrote: [...]
>> 3. moving the goal posts all the time and forcing you into a new paradigm every 1 1/2 years (first it was "ranges", then "templates" and now it's "functional", wait OOP will come back one day).
> [...]
>
> Wait, what?  Since when has this ever been a "choose one paradigm among many" deal?  Templates are what enables range-based idioms to succeed, and ranges are what makes it possible to write functional-like code in D.  Since when have they become mutually exclusive?!
>
>
> T

I wasn't talking about that, but about the fact that users are slowly but surely nudged into a certain direction. And yes, D was advertised as a "no ideology language".

On Fri, Aug 31, 2018 at 03:13:30PM +0000, Chris via Digitalmars-d wrote:
> On Friday, 31 August 2018 at 14:38:36 UTC, H. S. Teoh wrote:
> > On Fri, Aug 31, 2018 at 09:37:55AM +0000, Chris via Digitalmars-d wrote: [...]
> > > 3. moving the goal posts all the time and forcing you into a new paradigm every 1 1/2 years (first it was "ranges", then "templates" and now it's "functional", wait OOP will come back one day).
> > [...]
> > 
> > Wait, what?  Since when has this ever been a "choose one paradigm among many" deal?  Templates are what enables range-based idioms to succeed, and ranges are what makes it possible to write functional-like code in D.  Since when have they become mutually exclusive?!
[...]
> I wasn't talking about that, but about the fact that users are slowly but surely nudged into a certain direction. And yes, D was advertised as a "no ideology language".

Sorry, "slowly but surely nudged" sounds very different from "forcing you into a new paradigm every 1 1/2 years".  So which is it?  A nudge, presumably from recommended practices which you don't really have to follow (e.g., I don't follow all D recommended practices in my own code), or a strong coercion that forces you to rewrite your code in a new paradigm or else?


T

-- 
IBM = I'll Buy Microsoft!

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."

On Friday, 31 August 2018 at 09:37:55 UTC, Chris wrote:
> On Wednesday, 29 August 2018 at 23:47:11 UTC, Laeeth Isharc wrote:
>> On Tuesday, 28 August 2018 at 08:51:27 UTC, Chris wrote:
>
>>
> 9. I hope D will be great again

Are you someone who lives by hope and fears about things that have a meaning for you?  Or do you prefer to take action?  If the latter, what do you think might be some small step you could take to move the world towards the direction in which you think it should head.  My experience of life is that in the end one way and another everything one does, big or small, turns out to matter and also that great things can have quite little beginnings.

So what could you do towards the end you hope for ?

On Friday, 31 August 2018 at 15:43:13 UTC, H. S. Teoh wrote:

> [...]
>> I wasn't talking about that, but about the fact that users are slowly but surely nudged into a certain direction. And yes, D was advertised as a "no ideology language".
>
> Sorry, "slowly but surely nudged" sounds very different from "forcing you into a new paradigm every 1 1/2 years".  So which is it?  A nudge, presumably from recommended practices which you don't really have to follow (e.g., I don't follow all D recommended practices in my own code), or a strong coercion that forces you to rewrite your code in a new paradigm or else?
>
>
> T

Ah yeah, fair play to you. I knew I someone would see the force / nudge thing. You're nudged over the years until you end up being forced to use a certain paradigm. There's nothing wrong with languages "forcing" you to use certain paradigms as long as it's clear from the start and you know what you're in for. But moving the goalposts as you go along is a bit meh. I remember that Walter said that once he didn't care about (or even understand) templates. Then it was all templates, now it's functional programming (which I like). What will be next? Forced `assert` calls in every function? I can already see it... But, again, it's this attitude of nitpicking over words (nudge / force) instead of addressing the issues that alarms me. It's not a good sign.

On Friday, 31 August 2018 at 18:24:40 UTC, Laeeth Isharc wrote:
> On Friday, 31 August 2018 at 09:37:55 UTC, Chris wrote:
>> On Wednesday, 29 August 2018 at 23:47:11 UTC, Laeeth Isharc wrote:
>>> On Tuesday, 28 August 2018 at 08:51:27 UTC, Chris wrote:
>>
>>>
>> 9. I hope D will be great again
>
> Are you someone who lives by hope and fears about things that have a meaning for you?  Or do you prefer to take action?  If the latter, what do you think might be some small step you could take to move the world towards the direction in which you think it should head.  My experience of life is that in the end one way and another everything one does, big or small, turns out to matter and also that great things can have quite little beginnings.
>
> So what could you do towards the end you hope for ?

Hope is usually the last thing to die. But one has to be wise enough to see that sometimes there is nothing one can do. As things are now, for me personally D is no longer an option, because of simple basic things, like autodecode, a flaw that will be there forever, poor support for industry technologies (Android, iOS) and the constant "threat" of code breakage. The D language developers don't seem to understand the importance of these trivial matters. I'm not just opinionating, by now I have no other _choice_ but to look for alternatives - and I do feel a little bit sad.

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.