std.algorithm.remove and principle of least astonishment

[Andrei Alexandrescu]

On 11/23/10 12:15 PM, foobar wrote:
> Andrei Alexandrescu Wrote:
>
>> On 11/23/10 3:49 AM, foobar wrote:
>>> Andrei Alexandrescu Wrote:
>>>
>>>> On 11/22/10 5:59 PM, foobar wrote:
>>>>> Canonical example: DNA.
>>>>> I shouldn't need to write a special function to print it since it IS a string.
>>>>> I shouldn't need to cast it in order to do operations on it like sort, find, etc.
>>>>
>>>> I think it's best to encode DNA strings as sequences of ubyte. UTF
>>>> routines will work slower on them than functions for ubyte.
>>>>
>>>
>>> how would I go about printing DNA sequences then? printing a ubyte should print it's numeric value, and NOT a char. What actually needed here is a ASCIIChar type or even a more stricter DNAChar.
>>
>> Yes, and the language offers the abstraction abilities to define such
>> types.
>>
>>>>> D's [w|D|]char types make no sense since they are NOT characters and the concept doesn't fit for unicode since as someone else wrote, there are different levels of abstractions in unicode (copde point, code unit, grapheme).
>>>>> Naming matters and having a cat called dog (char is actually code unit) is a source of bugs.
>>>>
>>>> I think the names are fine. It doesn't take much learning to understand
>>>> that char, wchar, and dchar are UTF-8, UTF-16, and UTF-32 code units
>>>> respectively. I mean it would be odd if they were something else.
>>>>
>>>>
>>>
>>> The isn't a quantitative issue but an existential one. I agree that it's easy to use dogs once someone tells you that everywhere you want a dog you should denote it with "cat". Why do you need to learn that mistake _AT_ALL_ ?
>>> it is odd for YOU to think otherwise because you have ALREADY learned and accustomed to use a "cat" every time you need a dog. That does not mean that this is indeed correct.
>>> This is the same issue people having with D's enum.
>>>
>>> You just don't seem to get that learning is location depended. What makes sense to YOU based on your location on the learning curve isn't absolute and does NOT reflect on people with a different location on the learning curve. This goes with many of your excellent implementations that get awful names. Very C++ on your part - you need to be a c++ guru just to write a hello world app.
>>
>> I think I don't understand what you're suggesting.
>>
>>
>> Andrei
>
> It's simple, a mediocre language (Java) with mediocre libraries has
> orders of magnitude more success than C++ with it's libs fine tuned
> for performance. Why? because from a regular programmer's POV which
> just wants to get things done (TM), Java is geared towards easy and
> quick use. the are many libs for all common use cases, there is a
> common style and good naming conventions and 9/10 times you can write
> code by the feel without spending half an hour to read documentation.
> There are no obscure function names in Latin or Greek (even if the
> Latin/Greek term is more precise in math terms) in short, Java is
> KISS, C++ is not.

I don't think the dynamics of programming language success can be 
represented with a one-dimensional explanation. There are many other 
factors (marketing, perception, historical setting, etc. etc. etc.) Many 
languages offer easier and quicker ways to get done than Java, which is 
quite verbose. And Java programmers in fact spend large amounts of time 
reading documentation of the massive APIs they are working with. I'm not 
framing that as a bad thing; I'm just clarifying why I think your 
attempt at explaining Java's success is not only incomplete, but wrong.

> If you want D to succeed you need to acknowledge this and act
> according to this. Make the common case trivial and the special case
> possible. "char" is NOT fine and is misleading. I'm not asking to
> change this right now and would accept a response like "it's too late
> to change now" or whatever. However, I do expect you to at least
> acknowledge the issue and not dismiss it.

What would be a good replacement name for "char"?

> Your code might be excellent but it caters only to you and a small
> amount of programmers that share your style.

I'm curious how you validated this assumption.

> D will not succeed in
> general programmer public until you start catering for the common
> people and stop dismissing their complaints.

Since you are trying to build the impression that this is a common 
pattern, you should have no trouble finding plenty of examples.

> D2 is way more complex
> than D1 becasue of this (and the const system) and I'm singling you
> out because you are the main developer of D's standard lib and
> because you set the design goals/style of it.

I have had a Google alert tuned for the exact string "D programming 
language" for a good while. The general opinion that I seem to have 
gathered is that Phobos 2 is a major pro, not a con, in deciding to 
choose D2 versus D1.


Andrei