October 07, 2020
On Tuesday, 6 October 2020 at 18:49:08 UTC, Meta wrote:
> On Tuesday, 6 October 2020 at 18:30:15 UTC, Steven Schveighoffer wrote:
>> [...]
>
> Excellent point; the only reason Filter, staticSort, staticMap, Reverse, Repeat, etc., etc. exist is because of the limitations of working with AliasSeq. If type functions can allow us to replace most of these uses with good old std.range/algorithm code, that's a huge win in my book.
>
> We have a big chance to go left when C++ went right and went all-in on template metaprogramming. Let's leave templates to do what they were designed for - genericizing structures and algorithms, and leave the compile-time computation to CTFE + type functions.

C++ has constexpr...

We have a big chance to become a language even bigger than C++ without doing anything more. Hooray.
October 07, 2020
On Tuesday, 6 October 2020 at 18:17:51 UTC, Steven Schveighoffer wrote:
> On 10/6/20 1:51 PM, foobar wrote:
>> On Tuesday, 6 October 2020 at 12:35:15 UTC, Stefan Koch wrote:
>>> [...]
>> 
>> Last time I looked D was a small language but very powerful. It innovated and did things you could not do in C++. Now this forum has been taken over by beginners who want a big language which does the same as before, only differently. Yawn.
>
> Everything you just said is wrong.
>
> -Steve

Said Stefan Koch:

>No, type functions don't do anything original they mirror how type manipulation works within templates providing a familiar and usable interface.

Everything YOU just said is wrong.
October 06, 2020
On 10/6/2020 9:17 PM, H. S. Teoh wrote:
> So what does this imply in terms of Phobos code in D? ;-)  Should we
> uglify Phobos for the sake of performance?

I'd phrase it more as do what we gotta do for performance, yes.

> Keeping in mind, of course,
> what I said about the difficulty of optimizing for the general case
> without pessimizing some legitimate use cases -- or maybe even the
> *common* case, if we lose sight of the forest of common use cases while
> trying to optimize our chosen benchmark trees.

Of course, we have to use our brains instead of doing things blindly :-)
October 07, 2020
On Wednesday, 7 October 2020 at 02:33:21 UTC, Andrei Alexandrescu wrote:
> On 10/6/20 9:07 PM, claptrap wrote:
>> On Tuesday, 6 October 2020 at 23:39:24 UTC, H. S. Teoh wrote:
>>> On Tue, Oct 06, 2020 at 11:16:47PM +0000, claptrap via Digitalmars-d wrote: [...]
>>>>
>>> I would write it like this:
>>>
>>>     int[] vals = [4,7,28,23,585,73,12];
>>>
>>>     int[] getMultiplesOf(int i)
>>>     {
>>>         return vals.filter!(v => (v % i) == 0).array;
>>>     }
>>>
>>> One line vs. 4, even more concise. ;-)
>> 
>> The point is to show language not library.
>
> That's a made-up restriction, and it's odd that it is being discussed here as a virtue.

If you're trying to compare how the two features work in practice it's not going to be very illuminating if you hide all the workings behind a function call. Ie what good is

int[] getMultiplesOf(int i)
{
    return vals.tf_filter(v => (v % i) == 0);
}

vs...

int[] getMultiplesOf(int i)
{
    return vals.filter!(v => (v % i) == 0).array;
}

Yeah that helps a lot :)
October 07, 2020
On Tuesday, 6 October 2020 at 23:16:47 UTC, claptrap wrote:
[...]
>
> Its the same basic algorithm, search a list and make a new list from the entries that satisfy a certain condition. It beggars belief that anyone would argue that the second version is not better on every metric that is important in writing good code. It's clearer, more intuitive, more concise, it will almost definitely be faster and less wasteful of resources. Newbies will grep it far quicker than the other versions. That means faster to write and easier to maintain and debug.
>
> I'm honestly losing the will to live here.

Thank you. I was myself wondering why this feature was encountering such an amount of resistance, especially from the top tier of the language specialists. Maybe they are so used to the complexity of the template language that they don't perceive how challenging for the mere mortal it is in practice.
October 07, 2020
On Wednesday, 7 October 2020 at 03:12:46 UTC, Adam D. Ruppe wrote:
> On Wednesday, 7 October 2020 at 01:27:17 UTC, claptrap wrote:
>> IE. Whats the learning curve like?
>
> It is hard to say right now because

No it's not :)

>
>> See the point is even even though I understand that, it took me a while to grep it, and I couldn't just rattle that off the top of my head, it'd take me a fair while to figure out how to do that. (Maybe i wouldn't even be able to on my own)
>
> That might just be because you've never seen a combination of patterns like that before... and that's OK, I made up that particular thing just a few hours ago. (Though it is based on some ideas Andrei and I have been bouncing back and forth.)

Yeah Im not that that used to it, but the point is you have too work at it to see whats going on, there's two nested functions calls, more things passed around, more branches and recursion.

I have no problem with recursion, there's algorithms that make more sense as recursion, but this is not one, it's iterating over a list, to make it recursive you end up with 2 or 3 times more things going on in in order to make it work. Two functions, more branches, more things passed backwards and forwards, more construction of AliasSeq or whatever.

Just compare how much is going on in the template version vs the TF version.



> But with a little library refinement and some tutorials, maybe it would prove to be easy to learn and to use.

I'd rather 600 lines added to the compiler so I can concentrate on things I have to learn, I can write less code, my code is more intuative and less bug prone, because im not having to bend shit out of shape to make it recursive.



October 07, 2020
On Wednesday, 7 October 2020 at 02:10:03 UTC, Daniel K wrote:
> On Wednesday, 7 October 2020 at 01:07:17 UTC, claptrap wrote:
>> On Tuesday, 6 October 2020 at 23:39:24 UTC, H. S. Teoh wrote:
>>> On Tue, Oct 06, 2020 at 11:16:47PM +0000, claptrap via Digitalmars-d wrote: [...]
>>>>
>>> I would write it like this:
>>>
>>> 	int[] vals = [4,7,28,23,585,73,12];
>>>
>>> 	int[] getMultiplesOf(int i)
>>> 	{
>>> 	    return vals.filter!(v => (v % i) == 0).array;
>>> 	}
>>>
>>> One line vs. 4, even more concise. ;-)
>>
>> The point is to show language not library.
>>
>>
>>> Thing is, what someone finds intuitive or not, is a pretty subjective matter, and depends on what programming style he's familiar with and/or prefers.  What a C programmer finds readable and obvious may be needlessly arcane to a Java programmer, and what an APL programmer finds totally obvious may be completely impenetrable to anyone else. :-P
>>
>> We're not looking for "is this intuitive to Java programmers", we're asking is this intuitive to D programmers, so if they already know D then *you have context* in which to judge whether it's intuitive or not. And "It's just like regular D code but with types" pretty much hits the nail on the head as fair as intuitive goes.
>
> If recursive templates are not intuitive to you, perhaps you still have more D to learn, to become this mythical "D programmer".

There's 2 or 3 times more stuff going on in the template version. Two function calls, more things passed around, array or alias seq slicing, appending, more ifs and elses, etc...

Is less intuitive because it's an algorithm that makes more sense as iteration, so you have to bend it all out of shape to make it recursive.

I like code as simple as possible, that isnt it.


> My 16 lines of template essentially compiled in D for at least the past 10 years.
> It literally is "regular D code".

By regular D code, I mean non-teplate / meta code. I thought that was obvious.


> If recursion and declarative programming isn't intuitive to you in general, then perhaps that's not D's problem at all.

Recursion is fine, there's algorithms that make more sense that way, this isnt one of them. Thats the point. You're forcing everything in meta land to be recursive.

If all you have is a hammer....

And if all you've had is a hammer for 10 years, you start to doubt the existing of screws.


October 07, 2020
On Wednesday, 7 October 2020 at 08:26:21 UTC, claptrap wrote:
> On Wednesday, 7 October 2020 at 03:12:46 UTC, Adam D. Ruppe wrote:
>>
> Yeah Im not that that used to it, but the point is you have too work at it to see whats going on, there's two nested functions calls, more things passed around, more branches and recursion.
>
> I have no problem with recursion, there's algorithms that make more sense as recursion, but this is not one, it's iterating over a list, to make it recursive you end up with 2 or 3 times more things going on in in order to make it work. Two functions, more branches, more things passed backwards and forwards, more construction of AliasSeq or whatever.
>
> Just compare how much is going on in the template version vs the TF version.

Appologies, Ive just woke up and I replied here in response to Daniel Ks example code, not yours Adam. Hopefully it still kinda makes sense.
October 07, 2020
On Wednesday, 7 October 2020 at 02:33:21 UTC, Andrei Alexandrescu wrote:
> On 10/6/20 9:07 PM, claptrap wrote:
>> On Tuesday, 6 October 2020 at 23:39:24 UTC, H. S. Teoh wrote:
>>> On Tue, Oct 06, 2020 at 11:16:47PM +0000, claptrap via Digitalmars-d wrote: [...]
>>>>
>>> I would write it like this:
>>>
>>>     int[] vals = [4,7,28,23,585,73,12];
>>>
>>>     int[] getMultiplesOf(int i)
>>>     {
>>>         return vals.filter!(v => (v % i) == 0).array;
>>>     }
>>>
>>> One line vs. 4, even more concise. ;-)
>> 
>> The point is to show language not library.
>
> That's a made-up restriction, and it's odd that it is being discussed here as a virtue.

No, it's not. It's central to the argument.

>
> Beginners are attracted to large languages that have everything built in. A good language is focused on general primitives that allow writing a great deal in libraries.

Then do lisp or forth but not D or C++.

October 07, 2020
On Wednesday, 7 October 2020 at 08:49:21 UTC, Patrick Schluter wrote:
> On Wednesday, 7 October 2020 at 02:33:21 UTC, Andrei Alexandrescu wrote:

>> That's a made-up restriction, and it's odd that it is being discussed here as a virtue.
>
> No, it's not. It's central to the argument.

Exactly right. There comes a time when you try to do something that isn't covered by libraries,  what do you do then?

>> Beginners are attracted to large languages that have everything built in. A good language is focused on general primitives that allow writing a great deal in libraries.
>
> Then do lisp or forth but not D or C++.

Right again. Funtional programming is only pleasant in a dedicated FP language, and even then you need to memorize a large set of library constructs to be productive.

D could improve on FP, both language and performance, but adding type variables is a better cultural fit... (And Stefan is only putting forth a concept, not the end result)