Am Thu, 09 Jan 2014 23:32:37 +0000
schrieb "Brad Anderson" <eco@gnuk.net>:

> On Thursday, 9 January 2014 at 20:40:30 UTC, H. S. Teoh wrote:
> > On Thu, Jan 09, 2014 at 09:19:40PM +0100, Jacob Carlborg wrote:
> >> On 2014-01-09 17:35, Marco Leise wrote:
> >> 
> >> >I Phobos should follow OpenGL in this regard and use a
> >> >prefix like `etc` for useful but not finalized modules, so
> >> >early adapters can try out new modules compare them with any
> >> >existing API in Phobos where applicable (e.g. streams,
> >> >json, ...) and report any issues. I have a feeling that right
> >> >now most modules are tested by 2 people prior to the merge,
> >> >because they spent a life in obscurity.
> >> 
> >> That has been suggested before and the counter argument is that
> >> people will start using and complain when it's changed, even
> >> if it's
> >> in an experimental. Someone here said that the javax. packages
> >> originally was experimental packages to they continued to live
> >> in
> >> the javax namespace to avoid breaking changes.
> > [...]
> >
> > Maybe instead of calling it 'etc' we should outright call it 'experimental'. If you have code like:
> >
> > 	import experimental.myawesomemodule;
> > 	...
> >
> > I doubt you'd object very much when you have to rename it to:
> >
> > 	import std.myawesomemodule;
> > 	...
> >
> > since the word 'experimental' staring you in the face every
> > time you
> > open up the file will be a constant nagging reminder that you're
> > depending on something unstable, giving you motivation to want
> > to move
> > it to something stable as soon as you can.
> >
> >
> > T
> 
> I was of the opinion that phobos needed an experimental section for getting real world testing of proposed modules but these days I think we should just stick things up on dub (including modules proposed for inclusion in phobos).

Dub is a nice extension to D, but it falls way to short for what I expect package management to do on Linux:

o system wide installation of shared libraries
o keep one library per ABI, where ABI is a cross of:
  (x86,amd64) x (dmd,ldc,gdc) x (compiler version)
o therefore accept custom library installation paths
o remove packages that weren't explicitly requested and are
  not a dependency of something else

Actually I don't expect dub to do all that. It duplicates
parts of the existing package manager, which has to be used to
seamlessly integrate with the rest of the system anyway.
Dub does make building foreign packages a snap and that's what
it is great for, but soon people will expect complete
applications with their dependencies to be in the package
list. At least as soon as someone writes something _popular_
in D that uses more than just DMD. (This excludes vibe.d for
example, which is - I think - the most notable D product
outside of this community.)

-- 
Marco

Am Fri, 10 Jan 2014 08:42:14 +0100
schrieb Jacob Carlborg <doob@me.com>:

> On 2014-01-10 01:57, Manu wrote:
> 
> > I've heard that, and I think that's a lame argument. Would people rather break peoples code *who deliberately chose to use a beta feature, and accept the contract while doing so (that it would later be moved to 'std' proper)*, or consistently produce features that have very little proven foundation in practical application? It takes year(/s) before enough people can have had a crack at a new API in enough scenarios to reveal where it went right, and where it went wrong.
> 
> I think it's a good idea, others don't.

When do we have a meeting of the elders to decide on this matter?

-- 
Marco

Am Thu, 09 Jan 2014 15:51:36 -0500
schrieb Jerry <jlquinn@optonline.net>:

> Marco Leise <Marco.Leise@gmx.de> writes:
> 
> > Am Thu, 09 Jan 2014 15:20:13 +0000
> > schrieb "John Colvin" <john.loughran.colvin@gmail.com>:
> >
> 
> > The point about graphemes is good. D's functions still stop
> > mid-way. From UTF-8 you can iterate UTF-32 code points, but
> > grapheme clusters are the new characters. I.e. the basic need
> > to iterate Unicode _characters_ is not supported!
> > I cannot even come up with use cases for working with code
> > points and think they are a conceptual black hole. Something
> > carried over from a time when grapheme clusters didn't exist.
> 
> Actually, you can do tons of NLP without grapheme clusters.  If you're paranoid, you standardize on a specific Unicode normalization first.
> 
> You can probably get a bit better results by paying attention to clusters, but I suspect it will be a marginal improvement.
> 
> That said, I do agree with the OP that the string API is currently more complex to understand than I'd like.  However, it's significantly easier to use than what's in standard C++ for anything beyond ascii.
> 
> Jerry

Sorry, I got confused with the Unicode definitions. I see now that a grapheme cluster is e.g. \r\n. What I really meant is that Phobos needs to support graphemes. But seeing that monsters like this exist: n͠g, I don't even know if this is one character or two, but right now Phobos sees it as three characters.

-- 
Marco

On 1/10/14 12:49 AM, Jacob Carlborg wrote:
> On 2014-01-10 09:29, Andrei Alexandrescu wrote:
>
>> That's a documentation issue. We've pursued generalization of string
>> algorithms with good result. As such indexOf is susceptible for
>> generalization. However, the justification functions are unlikely to be
>> useful for other data types because most don't have a notion of "filler"
>> object.
>
> They might not have a default "filler" object but you can pass the
> "filler" as an argument.

By that I was implying that the whole notion is not sensible for general types. Honest, I did consider generalizing everything in std.string, but the algorithms left in there made little sense for other types than strings.

Andrei

On 1/10/14 6:07 AM, Regan Heath wrote:
> On Fri, 10 Jan 2014 08:16:53 -0000, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 1/9/14 11:56 PM, Jacob Carlborg wrote:
>>> On 2014-01-10 02:34, Manu wrote:
>>>
>>>> Or just alias the functions useful for string processing...
>>>
>>> I agree. It already has some aliases, converting to lower and uppercase.
>>
>> I wouldn't want to get to the point where many functions have 2-3 names.
>
> This is only a problem if they are all in the same sphere of concern..
> by that I mean if you're looking for string functions and you find 2
> names for the same function this would be wrong/confusing/pointless.
> But, if you have one name in the string category and one in the range
> category and they were both the same function underneath I don't see
> this as the "same" problem, right?

The way I see it one learns a name for an algorithm (low cognitive load) and then uses it everywhere. This is not Go.

Andrei

On Friday, 10 January 2014 at 08:39:13 UTC, Dicebot wrote:
> On Friday, 10 January 2014 at 08:31:28 UTC, Andrei Alexandrescu wrote:
>> On 1/10/14 12:17 AM, Dmitry Olshansky wrote:
>>> 10-Jan-2014 12:15, Jacob Carlborg пишет:
>>>> On 2014-01-10 03:40, Brad Anderson wrote:
>>>>
>>>>> DDox improves on this a bit by giving a table with brief
>>>>> descriptions right up top:
>>>>> http://vibed.org/temp/dlang.org/library/std/string.html
>>>>
>>>> What's the hold up of making the official documentation use DDox?
>>>>
>>>
>>> Seconded.
>>
>> Let's set to switch to ddox with 2.065.
>>
>> Andrei
>
> Let's not put to much stress on release/deployment process (which changing documentation engine will require) and make at least one "simple" release just to get everyone familiar with it.

Updating the website is almost strictly Andrei's domain so he should be able to do it independently of the release process (though integrating updating the website with the release process should probably happen at some point).  ddox was merged with the tools repo 6 months ago and dlang.org 3 months ago so as far as I know all that's left is for Andrei to generate the pages and upload them as 2.065 is completed.

On 2014-01-10 17:14, Andrei Alexandrescu wrote:

> By that I was implying that the whole notion is not sensible for general
> types. Honest, I did consider generalizing everything in std.string, but
> the algorithms left in there made little sense for other types than
> strings.

Fair enough, I just though I found a couple of more that could be generalized.

-- 
/Jacob Carlborg

On 2014-01-10 17:01, Marco Leise wrote:

> Sorry, I got confused with the Unicode definitions. I see now
> that a grapheme cluster is e.g. \r\n. What I really meant is
> that Phobos needs to support graphemes. But seeing that
> monsters like this exist: n͠g, I don't even know if this is
> one character or two, but right now Phobos sees it as three
> characters.

Thunderbird sees that as two characters. Ruby sees it as three.

-- 
/Jacob Carlborg

Am Fri, 10 Jan 2014 18:07:54 +0100
schrieb Jacob Carlborg <doob@me.com>:

> On 2014-01-10 17:01, Marco Leise wrote:
> 
> > Sorry, I got confused with the Unicode definitions. I see now that a grapheme cluster is e.g. \r\n. What I really meant is that Phobos needs to support graphemes. But seeing that monsters like this exist: n͠g, I don't even know if this is one character or two, but right now Phobos sees it as three characters.
> 
> Thunderbird sees that as two characters. Ruby sees it as three.

I think this is the (or one of the) official documents about
where a "user-perceived character" ends:

http://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundary_Rules

According to this, the above n͠g is indeed defined as 2 characters. Ruby is just no better than Phobos :p


»Grapheme cluster boundaries are important for collation,
 regular expressions, UI interactions (such as mouse selection,
 arrow key movement, backspacing), segmentation for vertical
 text, identification of boundaries for first-letter styling,
 and counting “character” positions within text.«

-- 
Marco

I agree that std.algorithm is better than <algorithm>, but let's not pretend that C++11 never happened (that happens from time to time on this forum). The modern C++ version isn't _that_ different:

    for(auto& blah: myContainer) { //for-loop condition on one line
        doSomething(blah->impl->myDataField);
        if(find(blah->impl->mySubContainer.begin(), blah->impl->mySubContainer.end(), key) == blah->impl->mySubContainer.end()) {
            //decltype is way shorter than std::vector<MyType<Blah>>
            //and change-resistant
            return decltype(blah)::iterator{};
        }
     }

Again, I think that std.algorithm is better and that passing a pair of iterators to everything when 99.9% of the time they'll be begin() and end() anyway is a massive PITA. I'm a D convert. Nobody here makes a point of posting D1 code and IMHO there's also no point in posting C++98 / C++2003 code.

Atila

> 	// You can't even write the for-loop conditions in a single
> 	// line!
> 	for (std::vector<MyType<Blah> >::iterator it =
> 		myContainer.start();
> 		it != myContainer.end();
> 		it++)
> 	{
> 		// What's with this (*smartPtr)->x nonsense everywhere?
> 		doSomething((*((*it)->impl)->myDataField);
>
> 		// What, I can't even write a simple X != Y if-condition
> 		// in a single line?! Not to mention the silly
> 		// redundancy of having to write out the entire chain of
> 		// dereferences to exactly the same object twice.
> 		if (find((*(*it)->impl)->mySubContainer, key) ==
> 			(*(*it)->impl)->mySubContainer.end())
> 		{
> 			// How I long for D's .init!
> 			std::vector<MyTypeBlah> >::iterator empty;
> 			return empty;
> 		}
> 	}
>



> OK, let's get one thing straight here. Comparing Phobos to STL is truly
> unfair. I spent almost 2 decades writing C++, and wrote code both using
> STL and without (from when STL didn't exist yet), and IME, Phobos's
> range algorithms are *orders* of magnitude better than STL in terms of
> usability. At least. In STL, you have to always manage pointer pairs,
> which become a massive pain when you need to pass multiple pairs around
> (very error-prone, transpose one argument, and you have a nice segfault
> or memory corruption bug).  Then you have stupid verbose syntax like:
>
> 	// You can't even write the for-loop conditions in a single
> 	// line!
> 	for (std::vector<MyType<Blah> >::iterator it =
> 		myContainer.start();
> 		it != myContainer.end();
> 		it++)
> 	{
> 		// What's with this (*smartPtr)->x nonsense everywhere?
> 		doSomething((*((*it)->impl)->myDataField);
>
> 		// What, I can't even write a simple X != Y if-condition
> 		// in a single line?! Not to mention the silly
> 		// redundancy of having to write out the entire chain of
> 		// dereferences to exactly the same object twice.
> 		if (find((*(*it)->impl)->mySubContainer, key) ==
> 			(*(*it)->impl)->mySubContainer.end())
> 		{
> 			// How I long for D's .init!
> 			std::vector<MyTypeBlah> >::iterator empty;
> 			return empty;
> 		}
> 	}
>
> Whereas in D:
>
> 	foreach (item; myContainer) {
> 		doSomething(item.impl.myDataField);
> 		if (!item.mySubContainer.canFind(key))
> 			return ElementType!MyContainer.init;
> 	}
>
> There's no comparison, I tell you. No comparison at all.
>
>
>> > > I actually feel a lot more productive in D than in C++ with
>> > > strings.  Boost's string algorithms library helps fill the gap
>> > > (and at least you only have one place to look for documentation
>> > > when you are using it) but overall I prefer my experience working
>> > > in D with pseudo-member chains.
>> >
>> > I found that what I got out of taking the time to learn
>> > std.algorithm and std.range was worth far more than the effort
>> > invested.
>> >
>> 
>> Perhaps you're right. But I think there's ***HUGE*** room for
>> improvement.  The key in your sentence is, it shouldn't require
>> 'effort'; if it's not intuitive to programmers with decades of
>> experience, then there are probably some fundamental design (or
>> documentation/accessibility) deficiencies that needs to be
>> prioritised. How is any junior programmer meant to take to D?
>
> No offense, but IME, junior programmers tend to pick up these things
> much faster than experienced programmers with lots of baggage from other
> languages, precisely because they don't have all that baggage to slow
> them down. Old habits die hard, as they say.
>
> That's not to say that the D docs don't need improvement, of course. But
> given all your objections about Phobos algorithms despite having barely
> *used* Phobos, I think the source of your difficulty lies more in the
> baggage than in the documentation. :)
>
>
> T