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.
