On Thu, Mar 08, 2012 at 07:14:30PM -0500, Nick Sabalausky wrote:
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.278.1331251506.4860.digitalmars-d@puremagic.com...
[...]
> I've heared that in countries like China which have a tonal language, the percentage of people with "perfect pitch" is incredibly high - something like 90-99%. Whereas in other places, like the US, it's *way* below half the population (something like 10%, IIRC).
[...]

I'm not sure if there's a direct correlation though... because Chinese tones are not pitch-perfect; they are relative to a reference pitch which differs from person to person.


T

-- 
The most powerful one-line C program: #include "/dev/tty" -- IOCCC

"Marco Leise" <Marco.Leise@gmx.de> wrote in message news:op.wavn0e059y6py2@marco-leise.homedns.org...
>You are free too use Hebrew, Cyrillic or Arabic characters for your
>identifiers right now. Only the keywords and druntime/Phobos
>would remain English:
>
>int main()
>{
>int ??????? = 42; // <- I really love this mind-fuck !!!
>return ???????;
>}

Yea, I love that about D.

"deadalnix" <deadalnix@gmail.com> wrote in message news:jjbcok$2pm9$1@digitalmars.com...
>
> BTW, I'm not aware of any successful recent language using a lot of abbreviations in its standard lib. That is not a proof, but definitively should be looked at.

I interpret that as a trend of "If you *can* do something [use non-abbreviated symbol names], you *should*." Just like games industry: They *can* use smaller text now that TVs have higher resolutions, so now they *insist* on making all their text as tiny as possible just because they can. (Never mind the pesky fact that tiny text in a higher resolution is *STILL TINY TEXT!* Erm, ok, ranty side-track over...)

On Thu, Mar 08, 2012 at 07:07:04PM -0500, Nick Sabalausky wrote: [...]
> But yea, it would be interesting to see a langauge that was based on something very different. A German-based one would be fun. Or even better, something that doesn't use the Latin alphabet, like Japanese or Hebrew or Russian. Or Swahili (which is an awesome-sounding language). Designing/using an Arabic (right-to-left, IIRC) programming language would be a great mind-fuck. Heh one of us should hack up DMD to produce a NihonD, using (or at least allowing) kanji instead of the kanas wherever appropriate :) That'd be both fun to make and to use.
[...]

You *do* realize that D allows non-Latin characters for identifiers, right? With suitable use of alias, you could write some really funky code:

	import std.stdio;
	alias std.stdio.writeln показать;
	alias size_t размер;
	alias string строка;
	alias void пустой;

	размер количество(Тип)(Тип[] массив) {
		return массив.length;
	}

	пустой main(строка[] параметров) {
		размер к = количество(параметров);
		показать("Я получил ", к, " параметров из командой строки");
	}

(Pity D doesn't let you alias keywords, else you could get rid of
"return" and "main" too. :-P)

However, this is only the lexical aspect of things. The grammar is still essentially inherited from C, which inherited from a primarily English-speaking tradition. So the above code is still rather awkward because many nouns are in the wrong case.

We can do better. What about a language that has inflections, like Greek or Russian? Function calls can then be indicated by putting the function name (verb) in imperative mood, whereas using the function name in nominative case (gerund) turns it into a function pointer.  Variables (nouns) can have nominative case to indicate the object a particular method should be invoked on, and accusative case for other parameters.

Now of course, to keep things manageable (and consistent), we'll have to eliminate the nasty complicated special-cases, spelling exceptions, and all that stuff that we find in natural languages. All word endings are universally applied, and must all be unambiguous.  Furthermore, most of human language is descriptive, whereas in a programming language, especially an imperative one, you'd want to be using imperatives almost all the time. So some natural language features won't be very useful.

So what we want is to identify common functionality that programming languages need, and encode those in our "verbs" and "nouns". Here's my first stab at it:

- Verbs represent functions, and can have an imperative form (function
  call), a gerund form (function pointer/delegate), or an indicative
  form (function declaration).

- Nouns represent variables, and can have a nominative form (variable
  declaration), an instrumental form (indicating the object a method is
  invoked from), a genitive form (indicating data source, i.e. "in" in
  D), a dative form (indicating data sink, or "out" in D), an accusative
  form (generic parameter), or a construct form (member access).

- Furthermore, plural nouns represent arrays, and have their own set of
  endings for nominative, instrumental, genitive, dative, accusative.
  (So you get array notation for free, no need for special symbols.)

- Adjectives represent types, and agree with the modified noun in case
  and number, so they can appear anywhere in a command without
  ambiguity, even separated from the modified noun proper. Adjectives
  have no construct form.

Here's an arbitrary assignment of endings to word forms, just for illustration's sake:

	Imperative verb:	-ize
	Gerundive verb:		-ing
	Indicative verb:	-ation

			Nouns		Adjectives
			sg	pl	sg	pl
	Nominative:	-on	-ons	-dic	-tic
	Instrumental:	-ect	-ects	-oid	-idic
	Genitive:	-in	-ins	-nous	-rous
	Dative:		-out	-outs	-ny	-ney
	Accusative:	-or	-ors	-like	-ive
	Construct:	-'s	-s'

Some grammatical particles we might need:

	is		Introduces function body
	;		Separates statements
	.		Ends function body

So here's some sample code. For illustration purposes I'm just transliterating D keywords, though in an actual implementation of such a language you'd want language-specific words instead.

	stringtic truncation stringrous arrayins is
		returnize arrays' 1..$ons

	intdic maination stringtic argumentors is
		intdic lenon arguments' lengthin;
		writelnize stdoutout lenor;
		writelnize stdoutout truncize argumentors;
		returnize 0or.

Here's the equivalent D code:

	string[] trunc(string[] array) {
		return array[1..$];
	}
	int main(string[] argument) {
		int len = argument.length;
		stdout.writeln(len);
		stdout.writeln(trunc(argument));
	}

Note that word order is relatively free, because word endings make the function of each word unambiguous. So the above code could be written like this instead:

	stringtic stringrous arrayins truncation is
		1..$ons arrays' returnize

	intdic maination stringtic argumentors is
		intdic lenon lengthin arguments';
		lenor stdoutout writelnize;
		stdoutout writelnize truncize argumentors;
		0or returnize.

OK, this sounds like a horrendous butchering of English, but imagine if the root words were non-English, and the endings weren't butcherings of English endings. You'd have a really unique language with almost free word order.

Or, if spelt-out endings are too annoying to type, we can use symbols instead, like this:

	stdout> writeln! arguments<


T

-- 
Creativity is not an excuse for sloppiness.

On Thu, Mar 08, 2012 at 07:40:09PM -0500, Nick Sabalausky wrote:
> "Ary Manzana" <ary@esperanto.org.ar> wrote in message news:jjbg62$2vi3$1@digitalmars.com...
[...]
> > I just stumbled upon this again in Ruby. I have a time object. I want to know if it's in the past. I wrote:
> >
> > time.past?
> >
> > it worked! :-)
> 
> I don't like to do such things (especially in dynamic languages). I'd be concerned about it *seeming* to work, but not exactly as I expect. Just seems to be programming by guesswork and assumptions. I don't trust it.
[...]

Exactly! What if it just happened to do what you *think* it does that one time, but actually does something different? Then you'd end up with nasty subtle bugs everywhere that only show up when you run into boundary conditions or when you pass in parameters that break your initial (wrong) assumptions.


T

-- 
Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr

On Thu, Mar 08, 2012 at 07:07:49PM -0500, Jonathan M Davis wrote:
> On Thursday, March 08, 2012 15:52:37 H. S. Teoh wrote:
[...]
> > $(selector)
> > .html(htmlcode)
> > .add(more_nodes)
> > .css(some_styles)
> > .filter(unwanted_nodes)
> > .click(click_handler)
> > .show();
> > 
> > Writing this in function composition order would cause an instant quantum leap in unreadability.
> 
> Which just goes to show that it's also a question of what you're used to, because I find that using the order that you did here rather than normal function call chaining is what causes an instance quantum leap in unreadibility.
[...]

The order I did it here can be read from top to bottom, just like a sequence of statements. The function composition order would have to be read from bottom to top, contrary to the general flow of control in the rest of the code. That's what makes it unreadable.


T

-- 
If it tastes good, it's probably bad for you.

On Thursday, March 08, 2012 18:46:56 H. S. Teoh wrote:
> On Thu, Mar 08, 2012 at 07:07:49PM -0500, Jonathan M Davis wrote:
> > On Thursday, March 08, 2012 15:52:37 H. S. Teoh wrote:
> [...]
> 
> > > $(selector)
> > > .html(htmlcode)
> > > .add(more_nodes)
> > > .css(some_styles)
> > > .filter(unwanted_nodes)
> > > .click(click_handler)
> > > .show();
> > > 
> > > Writing this in function composition order would cause an instant quantum leap in unreadability.
> > 
> > Which just goes to show that it's also a question of what you're used to, because I find that using the order that you did here rather than normal function call chaining is what causes an instance quantum leap in unreadibility.
> 
> [...]
> 
> The order I did it here can be read from top to bottom, just like a sequence of statements. The function composition order would have to be read from bottom to top, contrary to the general flow of control in the rest of the code. That's what makes it unreadable.

I see where you're coming from. It's just not the same for me. I find function chaining to be much easier to read when it's done the normal way. And if I'm looking for functions to be like a sequence of statements, then I'm going to write them that way instead of chaining them.

- Jonathan M Davis

On Thu, Mar 08, 2012 at 07:07:43PM -0500, Jonathan M Davis wrote:
> On Thursday, March 08, 2012 12:10:07 H. S. Teoh wrote:
> > IMO, making all abbreviations in Phobos consistent would be a big step forward.
> 
> You know, people keep saying that the abbreviations are inconsistent, but I don't buy that. _What_ abbreviations are inconsistent?
[...]

My comment was referring specifically to the pull request that adds "secs" as an alternative for "seconds". From what Walter said, he seems to be against any renaming changes, so any existing inconsistencies that we might find seems likely to be rejected as well.

But at the end of the day, this *is* just bikeshedding, so perhaps it's not worth spending so much time and energy on. People will get used to the quirky names eventually, and life goes on. *shrug*


T

-- 
Why can't you just be a nonconformist like everyone else? -- YHL

On Thursday, March 08, 2012 20:42:31 H. S. Teoh wrote:
> On Thu, Mar 08, 2012 at 07:07:43PM -0500, Jonathan M Davis wrote:
> > On Thursday, March 08, 2012 12:10:07 H. S. Teoh wrote:
> > > IMO, making all abbreviations in Phobos consistent would be a big step forward.
> > 
> > You know, people keep saying that the abbreviations are inconsistent, but I don't buy that. _What_ abbreviations are inconsistent?
> 
> [...]
> 
> My comment was referring specifically to the pull request that adds "secs" as an alternative for "seconds". From what Walter said, he seems to be against any renaming changes, so any existing inconsistencies that we might find seems likely to be rejected as well.
> 
> But at the end of the day, this *is* just bikeshedding, so perhaps it's not worth spending so much time and energy on. People will get used to the quirky names eventually, and life goes on. *shrug*

I think that most of the major issues with inconsistencies have been fixed. Sure, there may be a few left, but the longer that they're there, the more costly it is to fix them. And D is reaching the point where it needs to be stable. Constantly tweaking the standard library just doesn't cut it. I made quite a few changes to try and fix inconsistencies (such as function names which weren't camelcased like they were supposed to be), and that was painful enough, and engendered plenty of complaints in spite of the fact that there were quite a few people arguing for fixing the names to make Phobos consistent.

I really don't think that Phobos is really any more quirky or inconsistent than your average standard library. It's not perfect, but it isn't particularly inconsistent either. We'll continue to make improvement to it (primarily by adding new stuff), but it's increasingly costly to make breaking changes. And, on the whole, it's not like what we have is horrible. The biggest problems involve whole modules (which are generally older) which need to be redesigned, and those will happen. But minor stuff like tweaking function names doesn't really buy us enough to be worth it anymore. If a function changes sufficiently to merit a full replacement, then maybe we can change its name and phase out the old one (e.g. if we change the functions in std.string which take patterns to take regexes instead), but changing a name to change a name just isn't worth it when we're trying to provide a serious offering with D and Phobos. We're too far along.

- Jonathan M Davis

On Thu, Mar 08, 2012 at 07:07:04PM -0500, Nick Sabalausky wrote: [...]
> Heh one of us should hack up DMD to produce a NihonD, using (or at least allowing) kanji instead of the kanas wherever appropriate :) That'd be both fun to make and to use.
[...]

On another note, I've always dreamt about a language where keywords are i18n'd. Every keyword has an equivalent in every language (well, up to the languages currently supported, of course), and can be used interchangeably.

Support for Arabic and Hebrew would be tricky because of the right-to-left thing, but cool if it can be pulled off. Even cooler would be to support top-to-bottom, right-to-left for traditional Chinese writing. Don't know how it would interoperate with code written in English, though. :-P (Though it would mainly be a display issue, since at the Unicode level everything is just an unambiguous sequence of characters.)


T

-- 
They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill