std.data.json formal review

[Sönke Ludwig via Digitalmars-d]

Am 24.08.2015 um 22:25 schrieb Walter Bright:
> On 8/22/2015 5:21 AM, Sönke Ludwig wrote:
>> Am 17.08.2015 um 00:03 schrieb Walter Bright:
>>> D is going to be built around ranges as a fundamental way of coding.
>>> Users will need to learn something about them. Appending .array is not a
>>> big hill to climb.
>>
>> It isn't if you get taught about it. But it surely is if you don't
>> know about it
>> yet and try to get something working based only on the JSON API (language
>> newcomer that wants to work with JSON).
>
> Not if the illuminating example in the Json API description does it that
> way. Newbies will tend to copy/pasta the examples as a starting point.

That's true, but then they will possibly have to understand the inner 
workings soon after, for example when something goes wrong and they get 
cryptic error messages. It makes the learning curve steeper, even if 
some of that can be mitigated with good documentation/tutorials.

>> It's also still an additional thing to
>> remember, type and read, making it an additional piece of cognitive
>> load, even
>> for developers that are fluent with this. Have many of such pieces and
>> they add
>> up to a point where productivity goes to its knees.
>
> Having composable components behaving in predictable ways is not an
> additional piece of cognitive load, it is less of one.

Having to write additional things that are not part of the problem 
(".array", "import std.array : array;") is cognitive load and having to 
read such things is cognitive and visual load. Also, having to remember 
where those additional components reside is cognitive load, at least if 
they are not used really frequently. This has of course nothing to do 
with predictable behavior of the components, but with the API/language 
boundary between ranges and arrays.

>> I already personally find it quite annoying constantly having to import
>> std.range, std.array and std.algorithm to just use some small piece of
>> functionality in std.algorithm. It's also often not clear in which of
>> the three
>> modules/packages a certain function is. We need to find a better
>> balance here if
>> D is to keep its appeal as a language where you stay in "the zone"
>> (a.k.a
>> flow), which always has been a big thing for me.
>
> If I buy a toy car, I get a toy car. If I get a lego set, I can build
> any toy with it. I believe the composable component approach will make
> Phobos smaller and much more flexible and useful, as opposed to
> monolithic APIs.

I'm not arguing against a range based approach! It's just that such an 
approach ideally shouldn't come at the expense of simplicity and relevance.

If I have a string variable and I want to store the upper case version 
of another string, the direct mental translation is "dst = 
toUpper(src);" - and not "dst = toUpper(src).array;". It reminds me of 
the unwrap() calls in Rust code. They can produce a huge amount of 
visual noise for dealing with errors, whereas an exception based 
approach lets you focus on the actual problem. Of course exceptions have 
their own issues, but that's a different topic.

Keeping toString in addition to toChars would be enough to avoid the 
issue here. A possible alternative would be to let the proposed JSON 
text input range have an "alias this" to "std.array.array(this)". Then 
it wouldn't even require a rename of toString to toChars to get both worlds.