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
