Re: duck!

[lurker]

Andrei Alexandrescu Wrote:

> I was talking to Walter about Kenji's adaptTo. We both think it's a very 
> powerful enabler, but adaptTo is a bland name. After discussing a few 
> marketing strategies, I proposed "duck". It's short, simple, and evokes 
> "duck typing".
> 
> class C
> {
>  int draw(){ return 10; }
> }
> interface Drawable
> {
>  long draw();
> }
> ...
> auto c = new C;
> auto d = duck!Drawable(c);

Object c = new C;
auto d = duck!Drawable(c); // awes

does this work? After all, c is a C:

Object c = new C;
auto d = duck!Drawable(cast(C)c);

One fears this feature has little real world use. But it's a great way to add 
additional bloat to the puny little Phobos...

It's amusing as always that the syntax is being discussed before we even know 
how this works. How does the int -> long coercion work there? Any possibility 
to get a written spec for this?

Re: duck!

[abram]

Walter Bright wrote:
> Kagamin wrote:
>> Walter Bright Wrote:
>>> One would think programmers are above all that, but we are not.
>>
>> Ask people what they think about "cross-platform" .net ad campaign.
>
> I don't know anything about that.

Liar COM (and then some) guy. 

Re: duck!

[abram]

Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> Please substitute: "X does duck typing in the D programming
>> language". What is X?
>>
>> FWIW this was the story with "immutable". Walter got tired of
>> explaining: "Invariant implements immutable types in the D
>> programming language".
>
> Boy did I ever get tired of that. It's a classic example of names
> mattering - it's not just a bikeshed color.

Maybe you should explain "bikeshed". Did someone steal your bike? From 
your parent's shed? 

Re: duck!

[abram]

Andrei Alexandrescu wrote:
> On 10/16/2010 12:38 PM, Steven Schveighoffer wrote:
>> On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu
>>  wrote:
>>
>>> The problem with "adaptTo" is that, just like itoa or printf, it is
>>> too boring to have marketing value.
>>
>> Wait, really? This statement has no place in a programming language
>> decision IMO. Nobody is going to start using D because it has a
>> function *named* duck.
>>
>> Let's change writef to shazam! Let's call File BitLocker! And 'to'
>> really should be called transformationVehicle!
>
> I think ducktype is an important feature of D. I want to give it a
> name that is correspondingly resounding. The likes of files, writef,
> and conversions are commonplace. That's all.
>

Sounds like an epitaph! 

Re: duck!

[abram]

Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> On 10/16/2010 03:26 PM, Walter Bright wrote:
>>> A lot of people do think duck typing is very important.
>> It's the defining feature of Go.
>
> That makes me curious about the etymology of duckduckgo.com !

Sympathy plea? 

Re: duck!

[abram]

Walter Bright wrote:

> It reminds me of when a friend visited my house. After a very brief
> interval, he announced could tell it was a quality house, not a cheap
> facade. Intrigued, I asked him how. He said that the screw slots
> holding the wall plates on were all aligned the same way. It's a
> wholly irrelevant detail, added absolutely nothing to the function,
> but he said such attention to detail indicated the contractor cared
> about getting the details right.

That reminds me of many a house I considered buying: what's behind those 
walls? Nuff said, but I'll go on. Are there rats in the cellar? Lead 
pipes? Asbestos? Walls cover it all. Show me what's under those walls and 
maybe you'll have a sale. Wait, that's the wrong "argument". Time out, 
regroup.: I would not buy anything "glossed over" (ref: engine 
compartments of cars people buy. Oh yes, they pressure wash them and give 
them a coat of laquer!).

Re: What do people here use as an IDE?

[Gour D.]

On Sat, 16 Oct 2010 08:59:10 -0500
>> "Andrei" == Andrei Alexandrescu wrote:

Andrei> Yah. Emacs' formatting abilities are like real estate prices in
Andrei> Houston: once you got calibrated to them, it's hard to move
Andrei> away.

It looks there is no perfect IDE for D available (yet) - Qt is missing
D support, Codeblocks lacks integration with e.g. QtD...so now when
we'll start learning D (when will this TDPL arrive), I think I may
just continue using Emacs, but I wonder if you (D users using Emacs)
can recommend what would be the best code-completion system for it?


Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA



signature.asc
Description: PGP signature

Re: [nomenclature] systems language

[Steven Wawryk]

C does allow allocation on the stack.  But of course you're right that 
it doesn't have constructors/destructors, nor classes and OO.  It's 
interesting that device drivers for linux use a (partial) manual 
implementation of polymorphism and require a lot of boilerplate.


so wrote:
C doesn't have scope mechanism (constructor/destructor) either, though 
it is a great tool.


On Fri, 15 Oct 2010 12:10:05 +0300, Steven Wawryk  
wrote:




To me it means that it can be used for applications on platforms that 
provide no operating system support, for example tightly embedded 
applications or writing an operating system.  This implies that the 
language run-time (or at least the parts of it that need operating 
system support) is unavailable, so as much hardware interfacing and 
resource management as are needed by the application need to be 
written for the purpose.


C and C++ qualify.  I'm new to D and still learning about it, but with 
the deprecation of scoped classes and delete, I'm not sure that D 
qualifies.



On 14/10/10 23:00, Justin Johansson wrote:

Touted often around here is the term "systems language".

May we please discuss a definition to be agreed upon
for the usage this term (at least in this community) and
also have some agreed upon examples of PLs that might also
be members of the "set of systems languages".
Given a general subjective term like this, one would have
to suspect that the D PL is not the only member of this set.

Cheers
Justin Johansson

PS. my apologies for posting a lame joke recently;
certainly it was not meant to be disparaging towards
the D PL and hopefully it was not taken this way.





--Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [nomenclature] systems language

[Denis Koroskin]

On Sun, 17 Oct 2010 07:22:46 +0400, Steven Wawryk   
wrote:



dsimcha wrote:

== Quote from Steven Wawryk (stev...@acres.com.au)'s article


C and C++ qualify.  I'm new to D and still learning about it, but with
the deprecation of scoped classes and delete, I'm not sure that D  
qualifies.
 Why?  The elimination of scope and delete just serves to uglyify the  
relevant
concepts (which are unsafe and infrequently used) and save keywords.   
The concepts

can still be expressed:
 scope T -> std.typecons.scoped!T


Good - ugly is better than nothing.  Can this be used for class members  
of struct's too?




delete foo -> foo.__dtor();  GC.free(cast(void*) foo);


If I wrote my own minimal run-time with no garbage collector I guess  
GC.free would be replaced by my own memory manager's free function. Does  
D allow me to hook my own allocation function into new?


New uses gc_malloc under the hood, override it and you should be fine.

Re: [nomenclature] systems language

[Steven Wawryk]

dsimcha wrote:

== Quote from Steven Wawryk (stev...@acres.com.au)'s article


C and C++ qualify.  I'm new to D and still learning about it, but with
the deprecation of scoped classes and delete, I'm not sure that D qualifies.


Why?  The elimination of scope and delete just serves to uglyify the relevant
concepts (which are unsafe and infrequently used) and save keywords.  The 
concepts
can still be expressed:

scope T -> std.typecons.scoped!T


Good - ugly is better than nothing.  Can this be used for class members 
of struct's too?




delete foo -> foo.__dtor();  GC.free(cast(void*) foo);


If I wrote my own minimal run-time with no garbage collector I guess 
GC.free would be replaced by my own memory manager's free function. 
Does D allow me to hook my own allocation function into new?

Re: [nomenclature] systems language

[SK]

On Sat, Oct 16, 2010 at 1:36 AM, Paulo Pinto  wrote:
> Maybe you should improve your english skills. I was being sarcastic.
>

I ran a diagnostic on my English and guess what?  It's just fine!
What's not fine is the way Gmail displays threads.  At least in my
configuration, it looked like you were responding to my post.  So now
I'm a more enlightened Gmailer.

Re: duck!

[Michel Fortin]

On 2010-10-16 22:02:35 -0400, Leandro Lucarella  said:


I agree that "nametwo" is useless, but what you're proposing is plain
dynamic typing, not duck typing. Duck-typing is what Go (and adaptTo)
does. In dynamic languages you have to check for the methods existence
at runtime just because is the only way to do it, but if you want to use
a duck, you *need* to know that the object you're working with *can*
quack().

That doesn't make dynamic typing a bad idea, it can be useful, but
please don't name it "ducktype" as Andrei suggested.


What Go does is not duck typing, it's structural typing. It clearly has 
some of the benefits of duck typing and thus shares some similarities 
with it, but it's not the same.




In my argumentation, I try to stick to Wikipedia's definition of duck typing:


In computer programming with object-oriented programming languages, 
duck typing is a style of dynamic typing in which an object's current 
set of methods and properties determines the valid semantics, rather 
than its inheritance from a particular class or implementation of a 
specific interface.


[...]

In duck typing, one is concerned with just those aspects of an object 
that are used, rather than with the type of the object itself.


[...]

Duck typing is aided by habitually not testing for the type of 
arguments in method and function bodies, relying on documentation, 
clear code, and testing to ensure correct use. Users of statically 
typed languages new to dynamically typed languages are usually tempted 
to add such static (before run-time) type checks, defeating the 
benefits and flexibility of duck typing, and constraining the 
language's dynamism.


Read twice that last sentence. Clearly, statically implementing an 
interface is not what duck-typing is about. It could perhaps qualify as 
some sort structural typing, but it's better known as the adapter 
pattern.




--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: __traits(getMember) and uniform call syntax

[Jonathan M Davis]

On Saturday 16 October 2010 17:03:51 Tomek Sowiński wrote:
> What's the status quo on member functions defined outside the type?
> 
> import std.array;
> 
> void main() {
> int[] arr = [1,2];
> 
> // compiles, should it?
> int a = __traits(getMember, arr, "front");
> 
> // compiles (called popFront), should it?
> __traits(getMember, arr, "popFront");
> 
> // doesn't compile
> // __traits(getMember, arr, "popFront")();
> }
> 
> 
> I'd appreciate if someone told apart bugs from features.

Uniform function syntax doesn't change the member functions of a type. It just 
allows you to call functions as if they were member functions. And how could it 
be otherwise? Every time you imported a new module, it could completely change 
the set of member functions for any types in the current module. That would be 
really bad. Not to mention, all of the code that relies on knowing what the 
member functions actually are would be screwed if uniform function syntaxt 
affected __traits(getMember ...).

Arrays don't have member functions. getMember _might_ give you properties like 
length (I'd have to try it to know for sure), but it has no member functions, 
so 
of course it isn't going to find popFront() and the like in its member 
functions.

If you want that sort of behaviour, use __traits(compiles, ...) instead.

Uniform function syntax is syntactic sugar. It should not change the meaning of 
a program like it would if you tried to make them member functions according to 
__traits.

- Jonathan M Davis

Re: duck!

[Leandro Lucarella]

Michel Fortin, el 16 de octubre a las 18:19 me escribiste:
> On 2010-10-16 17:45:56 -0400, Andrei Alexandrescu
>  said:
> 
> >unittest
> >{
> > auto x = new Drawable;
> > auto a = nameone!Widget(x); // works
> > //auto b = nameone!ColoredWidget(x); // doesn't compile
> > auto c = nametwo!ColoredWidget(x);
> > c.draw(); // works
> > c.setColor(red); // throws NotImplemented during runtime
> >}
> >
> >"nameone" implements Kenji's current code. "nametwo" is the looser
> >form of duck typing: whatever methods match will work, and the
> >rest are implemented to throw during runtime.
> 
> What you're proposing above is just useless, and I'm honestly quite
> surprised you don't realize that.
> 
> The real duck type almost already exists in Phobos, and it's called
> a variant. The only problem with it is that it is powerless when it
> comes to calling functions without casting it's content to a type
> first. Make it so this code can run and then you'll have implemented
> duck typing for real:
> 
>   class Duck { void quack(); }
>   Variant v = new Duck;
>   v.quack();
> 
> Well, mostly. It could also be argued that this too should work too:
> 
>   Variant v = cast(Object)(new Duck);
>   v.quack();
> 
> but that'd require runtime reflexion as part of ClassInfo.

I agree that "nametwo" is useless, but what you're proposing is plain
dynamic typing, not duck typing. Duck-typing is what Go (and adaptTo)
does. In dynamic languages you have to check for the methods existence
at runtime just because is the only way to do it, but if you want to use
a duck, you *need* to know that the object you're working with *can*
quack().

That doesn't make dynamic typing a bad idea, it can be useful, but
please don't name it "ducktype" as Andrei suggested.

-- 
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
--
Sometimes I think the sure sign that life exists elsewhere in the universe
Is that that none of them tried to contact us

Re: duck!

[Leandro Lucarella]

Andrei Alexandrescu, el 16 de octubre a las 19:19 me escribiste:
> >I hate myself, I just keep replying when I know this matter is closed,
> >if both you and Andrei like something, is a dead end for any
> >alternatives...
> >
> >Well, at least I will be able to say "I tried"...
> 
> How about this: we call "adapt" the strict adaptation of one
> interface to another and "ducktype" the loose adaptation that might
> fail dynamically. Would that float your boat?

I don't find it ideal, but it's definitely better.

What I don't get is what the purpose/use of "ducktype" in D. And why do
you even have to pass a type to ducktype? If you aren't certain if the
object implements a function or not, that's not really duck-typing
either, that's just dynamic typing and in that case, why do you even
bother to specify an interface?

I really don't see a point to it...

-- 
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
--
at ease, eating well (no more microwave dinners and saturated fats),
a patient better driver, a safer car (baby smiling in back seat),
sleeping well (no bad dreams), no paranoia,

Re: Typeless function arguments

[Rainer Deyke]

On 10/16/2010 19:26, dsimcha wrote:
> The rule with uninstantiated template bodies is that the code needs to be
> syntactically correct, but not necessarily semantically correct (since the
> semantics can only be fully analyzed on instantiation).  void foo(t) looks
> syntactically incorrect.

I think 'void foo(t)' is syntactically correct.  You can't know that 't'
isn't the name of a type without semantic analysis.


-- 
Rainer Deyke - rain...@eldwood.com

Re: Typeless function arguments

[dsimcha]

== Quote from Tomek Sowiński (j...@ask.me)'s article
> Funny thing:
> void foo(T)(t); // typeless argument
> If you don't instantiate the template, it actually compiles. Bug?

IMHO yes, this is a bug.  What you wrote is syntactic sugar for:

template foo(T) {
void foo(t);
}

The rule with uninstantiated template bodies is that the code needs to be
syntactically correct, but not necessarily semantically correct (since the
semantics can only be fully analyzed on instantiation).  void foo(t) looks
syntactically incorrect.

Re: duck!

[Andrei Alexandrescu]

On 10/16/2010 07:50 PM, Denis Koroskin wrote:

On Sun, 17 Oct 2010 04:17:18 +0400, Andrei Alexandrescu
 wrote:


On 10/16/2010 05:57 PM, kenji hara wrote:

Current dmd does not enough support runtime reflection.

[snip]

I think runtime reflection is not needed. What you'd need to do for
the "loose duck" is generate code that throws for all interface
methods that are not present in the class. Am I wrong?

Andrei


interface ICanQuack
{
void quack() { ... }
}

class Duck
{
void quack() { .. }
}

Object o = new Duck();
Duck d = duck!(ICanQuack)(o);

d.quack(); // throw or not?


Throw... but now I see what Kenji meant. Thanks! So really there's three 
levels:


- statically-enforced conformance

- statically-decided conformance

- dynamically-decided conformance

Now we have three names to find, not one :o).


Andrei

Re: duck!

[Denis Koroskin]

On Sun, 17 Oct 2010 04:17:18 +0400, Andrei Alexandrescu  
 wrote:



On 10/16/2010 05:57 PM, kenji hara wrote:

Current dmd does not enough support runtime reflection.

[snip]

I think runtime reflection is not needed. What you'd need to do for the  
"loose duck" is generate code that throws for all interface methods that  
are not present in the class. Am I wrong?


Andrei


interface ICanQuack
{
void quack() { ... }
}

class Duck
{
void quack() { .. }
}

Object o = new Duck();
Duck d = duck!(ICanQuack)(o);

d.quack(); // throw or not?

Re: __traits(getMember) and uniform call syntax

[Tomek Sowiński]

Tomek Sowiński napisał:

> What's the status quo on member functions defined outside the type?
> 
> import std.array;
> 
> void main() {
> int[] arr = [1,2];
> 
> // compiles, should it?
> int a = __traits(getMember, arr, "front");
> 
> // compiles (called popFront), should it?
> __traits(getMember, arr, "popFront");
> 
> // doesn't compile
> // __traits(getMember, arr, "popFront")();
> }
> 
> 
> I'd appreciate if someone told apart bugs from features.

The latter two are compiler bugs to me, __traits(getMember, ...)() should work, 
but please 
shed some light regardless.

-- 
Tomek

Re: duck!

[Andrei Alexandrescu]

On 10/16/2010 05:18 PM, Leandro Lucarella wrote:

Walter Bright, el 16 de octubre a las 11:16 me escribiste:

Label it "adaptTo" and few will even notice it. Label it "duck" and
people will click on the link to see what it does. It's important
that people notice that D has these things, and "duck" helps with
that.


Well, maybe I'm not people, but I wouldn't click on anything named duck.
And if you ask me, marketing is OK for a name product, but not for
writing source code. You are putting marketing in the wrong place.

I would hate to have to write meaningless code like:

auto wow = buzz!Word(cool);


I've been in this business a long time, and while you'd think that
programmers are above "what's in a name", we are just like everyone
else. A catchy name gets results. Borland, for example, added a
trivial and boring feature to their linker, called it "smart
linking", and managed to get an unbelievable amount of hoopla from
the computer press out of it. They did it again with another feature
they called "zoom".


You are underestimating people, if your targets are morons, that's the
kind of people you'll get in the community.


Which blog article would you click on? "Interface Adapter for D" or
"Duck Typing for D"?


Probably "Duck typing for D", but why can't you name the function
"adapt", "adaptTo" or "as" and the article "Duck typing for D"???
The article is the right place to do marketing and use cool names to get
the attention, NOT THE CODE.


"duck" is a great name for the feature. It's short&  sweet, fits
right in with the popularity of duck typing, stands out, isn't
boring, etc. Heck, as proof, look at all the interest in this
thread!!


What you're saying now is just plain stupid:

1. A long thread generally indicated the presence of something
controversial, not something good and accepted (those threads are
usually short, or filled with just "+1").
2. You can just post "hi" in this NG and get a thread of thousands of
messages ;)

I hate myself, I just keep replying when I know this matter is closed,
if both you and Andrei like something, is a dead end for any
alternatives...

Well, at least I will be able to say "I tried"...


How about this: we call "adapt" the strict adaptation of one interface 
to another and "ducktype" the loose adaptation that might fail 
dynamically. Would that float your boat?


Andrei

Re: duck!

[Andrei Alexandrescu]

On 10/16/2010 05:57 PM, kenji hara wrote:

Current dmd does not enough support runtime reflection.

[snip]

I think runtime reflection is not needed. What you'd need to do for the 
"loose duck" is generate code that throws for all interface methods that 
are not present in the class. Am I wrong?


Andrei

__traits(getMember) and uniform call syntax

[Tomek Sowiński]

What's the status quo on member functions defined outside the type?

import std.array;

void main() {
int[] arr = [1,2];

// compiles, should it?
int a = __traits(getMember, arr, "front");

// compiles (called popFront), should it?
__traits(getMember, arr, "popFront");

// doesn't compile
// __traits(getMember, arr, "popFront")();
}


I'd appreciate if someone told apart bugs from features.

-- 
Tomek

Re: [nomenclature] systems language

[div0]

On 16/10/2010 19:27, Paulo Pinto wrote:

Would that make Smalltalk, Lisp, Oberon, Modula-3, Component Pascal, Ada,
Mac Pascal system programming languages?

All of them were used to write operating systems, in some of them the
operating system and
language are the same, kind of.


Well true, but the main problem with a lot of those systems is that you 
can only program on them in that language; they are all special 
execptions rather than general computers.


They used to make h/w Lisp machines back in the late 70s, where all the 
OS was written in Lisp; but you could only program them in Lisp. I 
wonder how they did the garbage collector as Lisp doesn't have pointers?


I guess they either wrote the garbage collector entierly in assembly or 
added a bunch of Lisp functions to allow them to manipulate the address 
space, effectively added pointers to the language.


For C, in principle you only need a trivial amount of assembly to handle 
the processor specific calls to switch privilege levels and load 
process/thread state.


For something like Java/Python you'd need a huge amount of assembly if 
you wanted to avoid using another lower level language.


There's nothing special about a systems language; it's just they have 
explicit facilities that make certain low level functionality easier to 
implement. You could implement an OS in BASIC using PEEK/POKE if you mad 
enough.


--
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

Typeless function arguments

[Tomek Sowiński]

Funny thing:

void foo(T)(t); // typeless argument

If you don't instantiate the template, it actually compiles. Bug?

-- 
Tomek

Re: duck!

[Leandro Lucarella]

Walter Bright, el 16 de octubre a las 11:16 me escribiste:
> Label it "adaptTo" and few will even notice it. Label it "duck" and
> people will click on the link to see what it does. It's important
> that people notice that D has these things, and "duck" helps with
> that.

Well, maybe I'm not people, but I wouldn't click on anything named duck.
And if you ask me, marketing is OK for a name product, but not for
writing source code. You are putting marketing in the wrong place.

I would hate to have to write meaningless code like:

auto wow = buzz!Word(cool);

> I've been in this business a long time, and while you'd think that
> programmers are above "what's in a name", we are just like everyone
> else. A catchy name gets results. Borland, for example, added a
> trivial and boring feature to their linker, called it "smart
> linking", and managed to get an unbelievable amount of hoopla from
> the computer press out of it. They did it again with another feature
> they called "zoom".

You are underestimating people, if your targets are morons, that's the
kind of people you'll get in the community.

> Which blog article would you click on? "Interface Adapter for D" or
> "Duck Typing for D"?

Probably "Duck typing for D", but why can't you name the function
"adapt", "adaptTo" or "as" and the article "Duck typing for D"???
The article is the right place to do marketing and use cool names to get
the attention, NOT THE CODE.

> "duck" is a great name for the feature. It's short & sweet, fits
> right in with the popularity of duck typing, stands out, isn't
> boring, etc. Heck, as proof, look at all the interest in this
> thread!!

What you're saying now is just plain stupid:

1. A long thread generally indicated the presence of something
   controversial, not something good and accepted (those threads are
   usually short, or filled with just "+1").
2. You can just post "hi" in this NG and get a thread of thousands of
   messages ;)

I hate myself, I just keep replying when I know this matter is closed,
if both you and Andrei like something, is a dead end for any
alternatives...

Well, at least I will be able to say "I tried"...

-- 
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
--
"All mail clients suck. This one just sucks less." -me, circa 1995

Re: duck!

[kenji hara]

Current dmd does not enough support runtime reflection.


// test code
class A
{
int quack() { return 10; }
}

void main()
{
Object o = new A();
TypeInfo ti;

ti = typeid(o);
if( auto ti_c = cast(TypeInfo_Class)ti ){

auto members = ti_c.getMembers("quack");
assert(members !is null);   // --> failed!!

foreach( mi; members ){
if( auto mi_fn = cast(MemberInfo_function)mi ){
assert(mi_fn.name == "quack");
auto fp = mi_fn.fp;
auto ti_fn = mi_fn.typeInfo;
//...
}
}
}
}


Kenji Hara.

2010/10/17 Andrei Alexandrescu :
> On 10/16/2010 03:30 PM, Michel Fortin wrote:
>>
>> On 2010-10-16 16:05:52 -0400, Andrei Alexandrescu
>>  said:
>>
>>> On 10/16/2010 02:54 PM, kenji hara wrote:

 Adapter-Pattern! I'd have forgotten the name.
 It is NOT equals to duck-typing.
>>>
>>> It's a subset of duck typing. I don't think calling a function that
>>> supports a limited form of duck typing "duck" is a lie.
>>
>> Not a lie, just a word with a deceptive meaning that'll lead people to
>> believe something else than the truth. Some cynically call that
>> marketing speech.
>
> As Walter said, that's probably why he, you, and myself aren't marketers.
>
>> In my opinion, a duck type in D should be a variant that allows you to
>> call all the functions of the underlying object, and throws (at runtime)
>> when no matching function is found. I think you'll agree with me that
>> this is very far from the adapter pattern.
>
> In fact I had this idea while running:
>
> interface Widget
> {
>    void draw();
>    void move(int x, int y);
> }
>
> interface ColoredWidget : Widget
> {
>   void setColor(Color c);
> }
>
> class Drawable
> {
>   void draw();
>   void move(int x, int y);
> }
>
> unittest
> {
>    auto x = new Drawable;
>    auto a = nameone!Widget(x); // works
>    //auto b = nameone!ColoredWidget(x); // doesn't compile
>    auto c = nametwo!ColoredWidget(x);
>    c.draw(); // works
>    c.setColor(red); // throws NotImplemented during runtime
> }
>
> "nameone" implements Kenji's current code. "nametwo" is the looser form of
> duck typing: whatever methods match will work, and the rest are implemented
> to throw during runtime.
>
> Question is, of course, figuring out good substitutes for nameone and
> nametwo.
>
> Kenji, do you think you could also implement nametwo?
>
>
> Andrei
>

Re: duck!

[Jonathan M Davis]

On Saturday 16 October 2010 15:06:21 Walter Bright wrote:
> Andrei Alexandrescu wrote:
> > On 10/16/2010 03:26 PM, Walter Bright wrote:
> >> A lot of people do think duck typing is very important.
> > 
> > It's the defining feature of Go.
> 
> That makes me curious about the etymology of duckduckgo.com !

I think that it's supposed to come from duck duck goose.

- Jonathan M Davis

Re: duck!

[Walter Bright]

Steven Schveighoffer wrote:
I'm just saying that marketability of D does 
not change no matter what appropriate term you choose.


And this is our fundamental disagreement. I think the choices of names matters a 
lot.


If names don't matter, why not name your son "Sue" ? :-)

But were there functions named zoomTechnology() and smartLink()?  Were 
their tools named zoom or smartl or something?  Is that what pushed them 
over the edge, or was it the bullet on the packaging that said:


* Includes zoom technology!


I don't believe that there is any fundamental difference between the name of a 
function and the name of the technology.




But people don't search google for "duck typing programming languages" 
and pick the language they're going to use from this list!


They may very well search "duck typing in the D programming language". Heck, 
that's what I do when I'm investigating whether language X supports feature Y. I 
do it a lot.



I think you 
are really going cuckoo over this feature like it's the best thing since 
ranges, and I don't see it being that.


I am happy with the name ranges for what it does, I think it's exactly right. Am 
I going cuckoo over this one? Perhaps. But I also believe that even getting the 
small details right is important.


It reminds me of when a friend visited my house. After a very brief interval, he 
announced could tell it was a quality house, not a cheap facade. Intrigued, I 
asked him how. He said that the screw slots holding the wall plates on were all 
aligned the same way. It's a wholly irrelevant detail, added absolutely nothing 
to the function, but he said such attention to detail indicated the contractor 
cared about getting the details right.



Invariant vs. immutable is not the same as adaptTo vs. duck.  Invariant 
already had a meaning in D1, and when choosing a new name, it was 
logical to use immutable.  Is immutable an 'exciting marketing term'?  
No, it's as boring as they come.  But it's definitely the best term for 
the job.  Let's focus on choosing the best term for what 'adaptTo' does, 
and when we market that D does duck typing in an article or a list of 
features (that shows up on google), we can include all the features of D 
that do duck typing.


With invariant I *always* had to explain it (even to people with no knowledge of 
the D1 meaning), and people would looked puzzled even after the explanation. 
With immutable, I stopped having to explain it. The name change was a big win.

Re: duck!

[Michel Fortin]

On 2010-10-16 17:45:56 -0400, Andrei Alexandrescu 
 said:



unittest
{
 auto x = new Drawable;
 auto a = nameone!Widget(x); // works
 //auto b = nameone!ColoredWidget(x); // doesn't compile
 auto c = nametwo!ColoredWidget(x);
 c.draw(); // works
 c.setColor(red); // throws NotImplemented during runtime
}

"nameone" implements Kenji's current code. "nametwo" is the looser form 
of duck typing: whatever methods match will work, and the rest are 
implemented to throw during runtime.


What you're proposing above is just useless, and I'm honestly quite 
surprised you don't realize that.


The real duck type almost already exists in Phobos, and it's called a 
variant. The only problem with it is that it is powerless when it comes 
to calling functions without casting it's content to a type first. Make 
it so this code can run and then you'll have implemented duck typing 
for real:


class Duck { void quack(); }
Variant v = new Duck;
v.quack();

Well, mostly. It could also be argued that this too should work too:

Variant v = cast(Object)(new Duck);
v.quack();

but that'd require runtime reflexion as part of ClassInfo.

--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: duck!

[Walter Bright]

Andrei Alexandrescu wrote:

On 10/16/2010 03:26 PM, Walter Bright wrote:

A lot of people do think duck typing is very important.

It's the defining feature of Go.


That makes me curious about the etymology of duckduckgo.com !

Re: Feature discussion: __traits(getSource, function)

[Nick Sabalausky]

"Adam D. Ruppe"  wrote in message 
news:i9cud5$1um...@digitalmars.com...
> Well, it sounds like I'm not the only one who'd find this useful, so I 
> took a look
> at the compiler.
>
> It seems to only store file and line internally (I might have missed 
> something
> though) so the path of least resistance seems to be exposing that, and 
> then
> pulling the source with a library function.
>
> But I'll keep looking, since avoiding the library function would be nice 
> (no -J
> and no bugs!).

I've been dealing with ddmd's source a bit lately. Unless it's different in 
dmd, the entirety of the source file should be available here:

// Relevent snippets from ddmd, probably similar in dmd:
class Module // in Module.d
{
File srcfile;
}

class File // in File.d
{
ubyte* buffer;// data for our file
uint len; // amount of data in buffer[]
}

So if you have a "Module myModule", then you can get the full original 
source code of the module with (D-ified):

myModule.srcfile.buffer[0..myModule.srcfile.len];

You're right that aside from the Module, dmd only keeps track of filename 
and line number (via the "Loc" struct, which is a member of most classes in 
the AST). You should be able to add members to Loc for "starting index in 
source file" and "ending index", and then just use those to index into 
Module.srcfile.buffer. (Although at that point, it's not really a "Line Of 
Code", more like "Location Of Code"...and for all I know there might be 
places that are reliant on it actually having the semantic meaning of "line 
of code", expecialy since Loc appears to have an "equals(Loc)" member).

I'd probably start by adding those members to Loc's ctors, searching all the 
files for all Loc instantiations, and updating them as relevent. You'll 
probably also have to find wherever dmd keeps track of the current line 
number (probably in the lexer or parser somewere, but I've never looked into 
those, so I don't even know where they are), and keep track of the current 
srcIndex, etc. along with it.

Re: duck!

[Jimmy Cao]

The very important principle here for the naming is making it obvious that D
supports an element of duck-typing.
Naming it duck! does just that.
Advertisability is not what I would use to describe it.  How about clarity,
articulateness, and lucidity?

On Sat, Oct 16, 2010 at 4:52 PM, Michael Chen  wrote:

> totally agreeed. let advertisability to influence a function name is
> ridiculous to me. you gotta have some princeple for names, but
> advertisability? i dont think so.

Re: duck!

[Walter Bright]

Steven Schveighoffer wrote:
On Sat, 16 Oct 2010 16:31:34 -0400, Walter Bright 
 wrote:


If I google for "adapt for D" I'll get a hopeless mess of irrelevant 
links. "duck typing for D" should be much better. Remember that google 
ranks pages by relevance, and searching for "duck" will give higher 
ranking for pages with "duck" in the url, title, headings, etc. That's 
just what we want.


And it should come up with the page on digitalmars.com titled 'duck 
typing in D' which describes how to use templates or the adaptTo type to 
achieve duck typing.



When writing fiction, it's a good idea to constantly shift which words used to 
describe something. But when writing tech manuals, and when making things search 
engine friendly, it pays to use a single term and use it consistently.


For example, once upon a time I read some article on arrays, and it variously 
referred to the array "elements", "entries", and "values". Really, that sucked, 
as the reader was left being not quite sure if they meant the same thing or not.


If you expect people to search for "duck typing" (and I do) then why stick 
another level of indirection? Call it a "duck". When you find yourself 
constantly saying "duck typing: see adaptTo", then you named it wrong.

Re: duck!

[Andrei Alexandrescu]

On 10/16/2010 04:52 PM, Michael Chen wrote:

totally agreeed. let advertisability to influence a function name is
ridiculous to me. you gotta have some princeple for names, but
advertisability? i dont think so.


It is a function, but it implements an entire feature - like e.g. 
"cast". What if D has casting but called it e.g. "force"?


I'm looking for a name that is descriptive and evocative.


Andrei

Re: duck!

[Andrei Alexandrescu]

On 10/16/2010 04:00 PM, Steven Schveighoffer wrote:

But naming the function that does duck
typing 'duck' doesn't seem to me like it makes or breaks D at all.


You do find it important, otherwise you wouldn't have spent cumulative 
hours arguing about it.


Andrei

Re: duck!

[Michael Chen]

totally agreeed. let advertisability to influence a function name is
ridiculous to me. you gotta have some princeple for names, but
advertisability? i dont think so.

On Sunday, October 17, 2010, Steven Schveighoffer  wrote:
> On Sat, 16 Oct 2010 16:26:15 -0400, Walter Bright 
>  wrote:
>
>
> Steven Schveighoffer wrote:
>
> Think of it another way. Remember zip files? What a great name, and yes, it 
> seemed silly at first, but zip entered the lexicon and D has a zip module and 
> it never occurs to anyone it might be better named std.compressedArchive. 
> Phil Katz renamed arc files "zip" files, called his compressor "pkzip" and 
> blew away arc so badly that most people are unaware it even existed.
>
> I think the catchy, silly "zip" name was a significant factor in getting 
> people to notice his program. In contrast, the superior "lharc" with its 
> "lzh" files never caught on.
>
>  These are completely unsubstantiated statements focused on a very narrow set 
> of variables.  It's like all those studies that say X causes cancer because 
> look most people who use X have cancer.  Well, yeah, but they are all 40-70 
> yr old people, who freaking knows how many factors went into them getting 
> cancer!!!  And it proves itself again and again when the next year, they say, 
> 'well that study was flawed, we now *know* that it was really Y'.
>
>
> It's an example of a phenomenon I've seen over and over. How about the names 
> Google and Yahoo? Boy did I think they were stupid names for companies and 
> products. Boy was I wrong. How about the perjorative name "twitter" and the 
> hopelessly undignified verb "tweet"? I still can't bring myself to say I 
> "tweeted". Ugh.
>
>
> This is called cherry picking.  What about microsoft, IBM, apple, gillette, 
> DOS, etc.  All these names aren't "wacky", yet they are still successful.  
> How do you explain that?  You might lump GoDaddy.com as one of those 'wacky' 
> names that made it, but that has nothing to do with it.
>
> Google and Yahoo succeeded because their product was good.  D will succeed 
> because it does duck typing, not because the function that does duck typing 
> is called 'duck'.  Now, if D was all about duck typing, and you called it 
> 'ducky', then I think that the name might be appropriate, and actually help 
> with marketing.  But naming the function that does duck typing 'duck' doesn't 
> seem to me like it makes or breaks D at all.  I want to be clear that duck is 
> not my first choice, but it's certainly a name that makes sense.  I'm just 
> saying that marketability of D does not change no matter what appropriate 
> term you choose.
>
>
> I also couldn't believe all the mileage Borland got out of naming minor 
> features "zoom technology" and "smart linking". So I don't buy that we 
> programmers are above all that.
>
>
> But were there functions named zoomTechnology() and smartLink()?  Were their 
> tools named zoom or smartl or something?  Is that what pushed them over the 
> edge, or was it the bullet on the packaging that said:
>
> * Includes zoom technology!
>
>
>
> "duck" *is* indicative of what the feature does, and so it is a lot better 
> than "zoom" or "smart" or "yahoo", which I'd have a hard time justifying. I 
> guess that's why I'm not a marketer!
>
>
> Yes, duck is a valid option.  And the fact that duck typing is what it does 
> is a very good reason to use it.  I just don't see 'marketing draw' as being 
> a factor whatsoever.  It's useless noise.
>
>
> Besides, duck isn't the compiler name, it's a very very small part of the 
> library.  I think you associate more weight to this than there actually is.
>
>
> A lot of people do think duck typing is very important.
>
>
> And D already does duck typing.  Templates do duck typing.  'adaptTo' does it 
> too, and it's cool, but it's not *that* important (no offense, Kenji).
>
>
> Let's concentrate on finding the name that best describes the function.  This 
> might be 'duck', but let's leave marketing considerations out of it.  If duck 
> was a verb that meant 'walk like a...'  then I'd agree it was a fine term.
>  How about if we can say D's functions are named intuitively instead of after 
> some colloquial term that describes the function?
>  And yeah, I agree zip is now a de-facto term, so much so that I think 
> std.range.Zip should be renamed :)  But was it zip that made the tool famous 
> or the tool that made zip famous?
>  Let's also not forget the hundreds, probably thousands, of 'cute' names that 
> didn't save their respective products because the marketing material sucked.
>
>
> I think 'zip' got peoples' attention, and then pkzip delivered the goods 
> (better than arc). lharc, on the other hand, had a ponderous name and failed 
> despite being significantly better. So yeah, I think the name got pkzip on 
> the map, but yes, the product also had to deliver. A cute name is not enough 
> to save a crap product, but it will help with a good one.
>
> If you want peopl

Re: duck!

[Andrei Alexandrescu]

On 10/16/2010 03:58 PM, Rainer Deyke wrote:

On 10/16/2010 14:02, Walter Bright wrote:

If it's a cringeworthy name, I'd agree. But "duck" is not cringeworthy.


Fact: I cringe every time I hear "duck typing".


Me too, for a long time. Then I had to get used to it because most 
everybody was using it.


Andrei

Re: duck!

[Andrei Alexandrescu]

On 10/16/2010 03:43 PM, kenji hara wrote:

Yes, it certainly is not a lie.
In Naming Type System, adaptTo extends duck.

But, people who you want to appeal it will think that all of
duck-typings each person imagine possible.
As a result, by knowing duck supports only Adapter-Pattern, they will
be lied to and angry.
It will negatively affect D.

D also has duck-typing by template, so naming adaptTo duck will be
making ambiguous situations.
(Like Tuple and TypeTuple)

Please reconsider it.

Kenji.


One way to go would be to implement the looser form of duck typing under 
the name "duck" and the current stricter variant under the name "adapt". 
(See my previous message.)



Andrei

Re: duck!

[Andrei Alexandrescu]

On 10/16/2010 03:30 PM, Michel Fortin wrote:

On 2010-10-16 16:05:52 -0400, Andrei Alexandrescu
 said:


On 10/16/2010 02:54 PM, kenji hara wrote:

Adapter-Pattern! I'd have forgotten the name.
It is NOT equals to duck-typing.


It's a subset of duck typing. I don't think calling a function that
supports a limited form of duck typing "duck" is a lie.


Not a lie, just a word with a deceptive meaning that'll lead people to
believe something else than the truth. Some cynically call that
marketing speech.


As Walter said, that's probably why he, you, and myself aren't marketers.


In my opinion, a duck type in D should be a variant that allows you to
call all the functions of the underlying object, and throws (at runtime)
when no matching function is found. I think you'll agree with me that
this is very far from the adapter pattern.


In fact I had this idea while running:

interface Widget
{
void draw();
void move(int x, int y);
}

interface ColoredWidget : Widget
{
   void setColor(Color c);
}

class Drawable
{
   void draw();
   void move(int x, int y);
}

unittest
{
auto x = new Drawable;
auto a = nameone!Widget(x); // works
//auto b = nameone!ColoredWidget(x); // doesn't compile
auto c = nametwo!ColoredWidget(x);
c.draw(); // works
c.setColor(red); // throws NotImplemented during runtime
}

"nameone" implements Kenji's current code. "nametwo" is the looser form 
of duck typing: whatever methods match will work, and the rest are 
implemented to throw during runtime.


Question is, of course, figuring out good substitutes for nameone and 
nametwo.


Kenji, do you think you could also implement nametwo?


Andrei

Re: duck!

[Andrei Alexandrescu]

On 10/16/2010 03:26 PM, Walter Bright wrote:

It's an example of a phenomenon I've seen over and over. How about the
names Google and Yahoo? Boy did I think they were stupid names for
companies and products. Boy was I wrong. How about the perjorative name
"twitter" and the hopelessly undignified verb "tweet"? I still can't
bring myself to say I "tweeted". Ugh.

I also couldn't believe all the mileage Borland got out of naming minor
features "zoom technology" and "smart linking". So I don't buy that we
programmers are above all that.


C++ credits a lot of its early success to provide "class" which is 
essentially a synonym to "struct". Technically it wasn't even necessary 
with that semantics, yet everybody wet their pants when they saw the 
keyword.



"duck" *is* indicative of what the feature does, and so it is a lot
better than "zoom" or "smart" or "yahoo", which I'd have a hard time
justifying. I guess that's why I'm not a marketer!

Besides, duck isn't the compiler name, it's a very very small part of
the library. I think you associate more weight to this than there
actually is.


A lot of people do think duck typing is very important.


It's the defining feature of Go.


Andrei

Re: std.algorithm.remove and principle of least astonishment

[Andrei Alexandrescu]

On 10/16/2010 03:14 PM, Steven Schveighoffer wrote:

On Sat, 16 Oct 2010 15:51:23 -0400, Andrei Alexandrescu
 wrote:


On 10/16/2010 01:39 PM, Steven Schveighoffer wrote:

I suggest wrapping a char[] or wchar[] (of all constancies) with a
special range that imposes the restrictions.


I did so. It was called byDchar and it would accept a string type. It
sucked.

char[] and wchar[] are special. They embed their UTF affiliation in
their type. I don't think we should make a wash of all that by
handling them as arrays. They are not arrays.


The compiler thinks they are. And they look like arrays (T[] looks like
an array to me no matter what T is). And I *want* an array of characters
in most cases. If you want a special type for strings, make them a
special type.

D should not have this schizophrenic view of strings. Plus it strikes me
as extremely unclean and bloated for every algorithm that might have a
range of char's passed into it to treat it specially (ignoring what the
compiler says).


It would do wrong or useless things otherwise. I'd probably do some 
things differently if I started over, but given the circumstances I 
think std.algorithm does the best it could ever do with strings.


Andrei

Re: std.algorithm.remove and principle of least astonishment

[Steven Schveighoffer]

On Sat, 16 Oct 2010 17:28:17 -0400, Andrei Alexandrescu  
 wrote:



On 10/16/2010 02:58 PM, Tomek Sowiński wrote:

Andrei Alexandrescu napisał:


On 10/16/2010 01:39 PM, Steven Schveighoffer wrote:

I suggest wrapping a char[] or wchar[] (of all constancies) with a
special range that imposes the restrictions.


I did so. It was called byDchar and it would accept a string type. It
sucked.


Why it sucked?


Because 99% of the times you'd want to pass byDchar, but it was easy to  
forget. Then the algorithm would compile and run without byDchar, just  
with useless semantics.


So call it string, and make the compiler use it as the default type for  
string literals.


-Steve

Re: std.algorithm.remove and principle of least astonishment

[Andrei Alexandrescu]

On 10/16/2010 02:56 PM, klickverbot wrote:

On 10/16/10 9:47 PM, Andrei Alexandrescu wrote:

Thanks for the input. This is not a bug, it's what I believe to be a
very intentional feature: strings are not ordinary arrays because
characters have variable length. As such, assigning to "the first
character in a string" is not allowed because the assignment might mess
up the next character.


I see that there is a problem due the difference of code units and code
points, but why does the following work then?

tmp = tmp[ 0 .. i ] ~ tmp[ ( i + 1 ) .. $ ];

This is equivalent to my (naïve?) mental model of remove(), and thus it
seems very counter-intuitive to me that one works, but the other doesn't.


To drive my point home: if you wanted to replace not 'x', but instead a 
multibyte character, your algorithm wouldn't work. It essentially 
assumes the string has one byte per character, and the needed cast to 
byte[] reflects that.


If anything, I'd call this a success.


Andrei

Re: std.algorithm.remove and principle of least astonishment

[Andrei Alexandrescu]

On 10/16/2010 02:56 PM, klickverbot wrote:

On 10/16/10 9:47 PM, Andrei Alexandrescu wrote:

Thanks for the input. This is not a bug, it's what I believe to be a
very intentional feature: strings are not ordinary arrays because
characters have variable length. As such, assigning to "the first
character in a string" is not allowed because the assignment might mess
up the next character.


I see that there is a problem due the difference of code units and code
points, but why does the following work then?

tmp = tmp[ 0 .. i ] ~ tmp[ ( i + 1 ) .. $ ];

This is equivalent to my (naïve?) mental model of remove(), and thus it
seems very counter-intuitive to me that one works, but the other doesn't.


Strings are dual types. They have [] and .length but not with the 
semantics required by ranges. So formally they don't support 
isRandomAccessRange and hasLength.


Andrei

Re: std.algorithm.remove and principle of least astonishment

[Andrei Alexandrescu]

On 10/16/2010 02:58 PM, Tomek Sowiński wrote:

Andrei Alexandrescu napisał:


On 10/16/2010 01:39 PM, Steven Schveighoffer wrote:

I suggest wrapping a char[] or wchar[] (of all constancies) with a
special range that imposes the restrictions.


I did so. It was called byDchar and it would accept a string type. It
sucked.


Why it sucked?


Because 99% of the times you'd want to pass byDchar, but it was easy to 
forget. Then the algorithm would compile and run without byDchar, just 
with useless semantics.


Andrei

Re: std.algorithm.remove and principle of least astonishment

[Pelle]

On 10/16/2010 09:56 PM, klickverbot wrote:

On 10/16/10 9:47 PM, Andrei Alexandrescu wrote:

Thanks for the input. This is not a bug, it's what I believe to be a
very intentional feature: strings are not ordinary arrays because
characters have variable length. As such, assigning to "the first
character in a string" is not allowed because the assignment might mess
up the next character.


I see that there is a problem due the difference of code units and code
points, but why does the following work then?

tmp = tmp[ 0 .. i ] ~ tmp[ ( i + 1 ) .. $ ];

This is equivalent to my (naïve?) mental model of remove(), and thus it
seems very counter-intuitive to me that one works, but the other doesn't.


Try it with ä or ░ instead of x.

Re: duck!

[Steven Schveighoffer]

On Sat, 16 Oct 2010 16:31:34 -0400, Walter Bright  
 wrote:


If I google for "adapt for D" I'll get a hopeless mess of irrelevant  
links. "duck typing for D" should be much better. Remember that google  
ranks pages by relevance, and searching for "duck" will give higher  
ranking for pages with "duck" in the url, title, headings, etc. That's  
just what we want.


And it should come up with the page on digitalmars.com titled 'duck typing  
in D' which describes how to use templates or the adaptTo type to achieve  
duck typing.


-Steve

Re: duck!

[Steven Schveighoffer]

On Sat, 16 Oct 2010 16:26:15 -0400, Walter Bright  
 wrote:



Steven Schveighoffer wrote:
Think of it another way. Remember zip files? What a great name, and  
yes, it seemed silly at first, but zip entered the lexicon and D has a  
zip module and it never occurs to anyone it might be better named  
std.compressedArchive. Phil Katz renamed arc files "zip" files, called  
his compressor "pkzip" and blew away arc so badly that most people are  
unaware it even existed.


I think the catchy, silly "zip" name was a significant factor in  
getting people to notice his program. In contrast, the superior  
"lharc" with its "lzh" files never caught on.
 These are completely unsubstantiated statements focused on a very  
narrow set of variables.  It's like all those studies that say X causes  
cancer because look most people who use X have cancer.  Well, yeah, but  
they are all 40-70 yr old people, who freaking knows how many factors  
went into them getting cancer!!!  And it proves itself again and again  
when the next year, they say, 'well that study was flawed, we now  
*know* that it was really Y'.


It's an example of a phenomenon I've seen over and over. How about the  
names Google and Yahoo? Boy did I think they were stupid names for  
companies and products. Boy was I wrong. How about the perjorative name  
"twitter" and the hopelessly undignified verb "tweet"? I still can't  
bring myself to say I "tweeted". Ugh.


This is called cherry picking.  What about microsoft, IBM, apple,  
gillette, DOS, etc.  All these names aren't "wacky", yet they are still  
successful.  How do you explain that?  You might lump GoDaddy.com as one  
of those 'wacky' names that made it, but that has nothing to do with it.


Google and Yahoo succeeded because their product was good.  D will succeed  
because it does duck typing, not because the function that does duck  
typing is called 'duck'.  Now, if D was all about duck typing, and you  
called it 'ducky', then I think that the name might be appropriate, and  
actually help with marketing.  But naming the function that does duck  
typing 'duck' doesn't seem to me like it makes or breaks D at all.  I want  
to be clear that duck is not my first choice, but it's certainly a name  
that makes sense.  I'm just saying that marketability of D does not change  
no matter what appropriate term you choose.


I also couldn't believe all the mileage Borland got out of naming minor  
features "zoom technology" and "smart linking". So I don't buy that we  
programmers are above all that.


But were there functions named zoomTechnology() and smartLink()?  Were  
their tools named zoom or smartl or something?  Is that what pushed them  
over the edge, or was it the bullet on the packaging that said:


* Includes zoom technology!



"duck" *is* indicative of what the feature does, and so it is a lot  
better than "zoom" or "smart" or "yahoo", which I'd have a hard time  
justifying. I guess that's why I'm not a marketer!


Yes, duck is a valid option.  And the fact that duck typing is what it  
does is a very good reason to use it.  I just don't see 'marketing draw'  
as being a factor whatsoever.  It's useless noise.


Besides, duck isn't the compiler name, it's a very very small part of  
the library.  I think you associate more weight to this than there  
actually is.


A lot of people do think duck typing is very important.


And D already does duck typing.  Templates do duck typing.  'adaptTo' does  
it too, and it's cool, but it's not *that* important (no offense, Kenji).


Let's concentrate on finding the name that best describes the  
function.  This might be 'duck', but let's leave marketing  
considerations out of it.  If duck was a verb that meant 'walk like  
a...'  then I'd agree it was a fine term.
 How about if we can say D's functions are named intuitively instead of  
after some colloquial term that describes the function?
 And yeah, I agree zip is now a de-facto term, so much so that I think  
std.range.Zip should be renamed :)  But was it zip that made the tool  
famous or the tool that made zip famous?
 Let's also not forget the hundreds, probably thousands, of 'cute'  
names that didn't save their respective products because the marketing  
material sucked.


I think 'zip' got peoples' attention, and then pkzip delivered the goods  
(better than arc). lharc, on the other hand, had a ponderous name and  
failed despite being significantly better. So yeah, I think the name got  
pkzip on the map, but yes, the product also had to deliver. A cute name  
is not enough to save a crap product, but it will help with a good one.


If you want people to notice something and give it a chance to be good,  
having a boring name (that is also not google-friendly) will never give  
it a chance.


But people don't search google for "duck typing programming languages" and  
pick the language they're going to use from this list!  I think you are  
really going cuckoo over this feature

Re: duck!

[Rainer Deyke]

On 10/16/2010 14:02, Walter Bright wrote:
> If it's a cringeworthy name, I'd agree. But "duck" is not cringeworthy.

Fact: I cringe every time I hear "duck typing".


-- 
Rainer Deyke - rain...@eldwood.com

Re: duck!

[Andrej Mitrovic]

I'm going to go with duck on this one. It could be an attractive name
to put in reddit/yc titles.. "Can your language duck? D can, with
duck!". Plus it's easily greppable and easy to type. And I don't like
stuttering words like adaptTo, there's two repeating t's in there
*and* I need a shift, that is an outrage!

Not every word in the language/lib has to be dead-serious. :)


On 10/16/10, Walter Bright  wrote:
> Lutger wrote:
>> Justin Johansson wrote:
>>
>>> On 16/10/2010 6:30 PM, Christof Schardt wrote:
> auto d = duck!Drawable(c); // awes
 What about "as" ?

 auto d = as!Drawable(c);

 Christof
>>> This is a totally brilliant suggestion by Christof as
>>> anyone who understands the XPath 2.0 type language
>>> would tell you also.
>>>
>>> While finding duck! rather cute, marketing intelligence
>>> will confirm that Christof's as! suggestion is the way to go.
>>>
>>> I feel woeful that I did not think of it myself.  Award
>>> for naming suggestion definitely goes to Christof.
>>>
>>> Justin
>>
>> plus, it's shorter to type.
>>
>> *ducks*
>
> Try googling "as for D"
>

Re: std.algorithm.remove and principle of least astonishment

[Rainer Deyke]

On 10/16/2010 13:51, Andrei Alexandrescu wrote:
> char[] and wchar[] are special. They embed their UTF affiliation in
> their type. I don't think we should make a wash of all that by handling
> them as arrays. They are not arrays.

Then rename them to something else.  Problem solved.


-- 
Rainer Deyke - rain...@eldwood.com

Re: duck!

[kenji hara]

Yes, it certainly is not a lie.
In Naming Type System, adaptTo extends duck.

But, people who you want to appeal it will think that all of
duck-typings each person imagine possible.
As a result, by knowing duck supports only Adapter-Pattern, they will
be lied to and angry.
It will negatively affect D.

D also has duck-typing by template, so naming adaptTo duck will be
making ambiguous situations.
(Like Tuple and TypeTuple)

Please reconsider it.

Kenji.

2010/10/17 Andrei Alexandrescu :
> On 10/16/2010 02:54 PM, kenji hara wrote:
>>
>> Adapter-Pattern! I'd have forgotten the name.
>> It is NOT equals to duck-typing.
>
> It's a subset of duck typing. I don't think calling a function that supports
> a limited form of duck typing "duck" is a lie.
>
> Andrei
>
>

Re: duck!

[Walter Bright]

Kagamin wrote:

Walter Bright Wrote:

One would think programmers are above all that, but we are not.


Ask people what they think about "cross-platform" .net ad campaign.


I don't know anything about that.

Re: duck!

[Walter Bright]

Lutger wrote:

Justin Johansson wrote:


On 16/10/2010 6:30 PM, Christof Schardt wrote:

auto d = duck!Drawable(c); // awes

What about "as" ?

auto d = as!Drawable(c);

Christof

This is a totally brilliant suggestion by Christof as
anyone who understands the XPath 2.0 type language
would tell you also.

While finding duck! rather cute, marketing intelligence
will confirm that Christof's as! suggestion is the way to go.

I feel woeful that I did not think of it myself.  Award
for naming suggestion definitely goes to Christof.

Justin


plus, it's shorter to type. 


*ducks*


Try googling "as for D"

Re: duck!

[Walter Bright]

Kagamin wrote:

Walter Bright Wrote:


Which blog article would you click on? "Interface Adapter for D" or "Duck
Typing for D"?


You are somewhat right. The right place for marketing is an article, not the
library source, right?


They're both important. Especially consider that Phobos is open source, is on 
the internet just a click away, and the words used in it are indexed by Google.




What would you click on? "Duck typing for D" or
dsource.org/phobos/src/trunk?


If I'm looking at a list of modules for Phobos, and I see "std.duck" as a 
clickable link, I'll click on it.


If I google for "adapt for D" I'll get a hopeless mess of irrelevant links. 
"duck typing for D" should be much better. Remember that google ranks pages by 
relevance, and searching for "duck" will give higher ranking for pages with 
"duck" in the url, title, headings, etc. That's just what we want.

Re: duck!

[Michel Fortin]

On 2010-10-16 16:05:52 -0400, Andrei Alexandrescu 
 said:



On 10/16/2010 02:54 PM, kenji hara wrote:

Adapter-Pattern! I'd have forgotten the name.
It is NOT equals to duck-typing.


It's a subset of duck typing. I don't think calling a function that 
supports a limited form of duck typing "duck" is a lie.


Not a lie, just a word with a deceptive meaning that'll lead people to 
believe something else than the truth. Some cynically call that 
marketing speech.


In my opinion, a duck type in D should be a variant that allows you to 
call all the functions of the underlying object, and throws (at 
runtime) when no matching function is found. I think you'll agree with 
me that this is very far from the adapter pattern.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: duck!

[Walter Bright]

Steven Schveighoffer wrote:
Think of it another way. Remember zip files? What a great name, and 
yes, it seemed silly at first, but zip entered the lexicon and D has a 
zip module and it never occurs to anyone it might be better named 
std.compressedArchive. Phil Katz renamed arc files "zip" files, called 
his compressor "pkzip" and blew away arc so badly that most people are 
unaware it even existed.


I think the catchy, silly "zip" name was a significant factor in 
getting people to notice his program. In contrast, the superior 
"lharc" with its "lzh" files never caught on.


These are completely unsubstantiated statements focused on a very narrow 
set of variables.  It's like all those studies that say X causes cancer 
because look most people who use X have cancer.  Well, yeah, but they 
are all 40-70 yr old people, who freaking knows how many factors went 
into them getting cancer!!!  And it proves itself again and again when 
the next year, they say, 'well that study was flawed, we now *know* that 
it was really Y'.


It's an example of a phenomenon I've seen over and over. How about the names 
Google and Yahoo? Boy did I think they were stupid names for companies and 
products. Boy was I wrong. How about the perjorative name "twitter" and the 
hopelessly undignified verb "tweet"? I still can't bring myself to say I 
"tweeted". Ugh.


I also couldn't believe all the mileage Borland got out of naming minor features 
"zoom technology" and "smart linking". So I don't buy that we programmers are 
above all that.


"duck" *is* indicative of what the feature does, and so it is a lot better than 
"zoom" or "smart" or "yahoo", which I'd have a hard time justifying. I guess 
that's why I'm not a marketer!



Besides, duck isn't the compiler name, it's a very very small part of 
the library.  I think you associate more weight to this than there 
actually is.


A lot of people do think duck typing is very important.


Let's concentrate on finding the name that best describes 
the function.  This might be 'duck', but let's leave marketing 
considerations out of it.  If duck was a verb that meant 'walk like 
a...'  then I'd agree it was a fine term.


How about if we can say D's functions are named intuitively instead of 
after some colloquial term that describes the function?


And yeah, I agree zip is now a de-facto term, so much so that I think 
std.range.Zip should be renamed :)  But was it zip that made the tool 
famous or the tool that made zip famous?


Let's also not forget the hundreds, probably thousands, of 'cute' names 
that didn't save their respective products because the marketing 
material sucked.


I think 'zip' got peoples' attention, and then pkzip delivered the goods (better 
than arc). lharc, on the other hand, had a ponderous name and failed despite 
being significantly better. So yeah, I think the name got pkzip on the map, but 
yes, the product also had to deliver. A cute name is not enough to save a crap 
product, but it will help with a good one.


If you want people to notice something and give it a chance to be good, having a 
boring name (that is also not google-friendly) will never give it a chance.


And besides, as Andrei pointed out, I'll get really tired of saying ad infinitum 
"Yes, you can do duck typing in D, just use the adaptTo function." Say that 1000 
times, and you too will decide that "duck" is a better name.

Re: duck!

[so]

Wouldn't linking adaptTo to opDispatch (if the functions we are after not  
supported by that class) make it complete duck-typing?


On Sat, 16 Oct 2010 23:05:52 +0300, Andrei Alexandrescu  
 wrote:



On 10/16/2010 02:54 PM, kenji hara wrote:

Adapter-Pattern! I'd have forgotten the name.
It is NOT equals to duck-typing.


It's a subset of duck typing. I don't think calling a function that  
supports a limited form of duck typing "duck" is a lie.


Andrei




--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: std.algorithm.remove and principle of least astonishment

[Steven Schveighoffer]

On Sat, 16 Oct 2010 15:51:23 -0400, Andrei Alexandrescu  
 wrote:



On 10/16/2010 01:39 PM, Steven Schveighoffer wrote:

I suggest wrapping a char[] or wchar[] (of all constancies) with a
special range that imposes the restrictions.


I did so. It was called byDchar and it would accept a string type. It  
sucked.


char[] and wchar[] are special. They embed their UTF affiliation in  
their type. I don't think we should make a wash of all that by handling  
them as arrays. They are not arrays.


The compiler thinks they are.  And they look like arrays (T[] looks like  
an array to me no matter what T is).  And I *want* an array of characters  
in most cases.  If you want a special type for strings, make them a  
special type.


D should not have this schizophrenic view of strings.  Plus it strikes me  
as extremely unclean and bloated for every algorithm that might have a  
range of char's passed into it to treat it specially (ignoring what the  
compiler says).


-Steve

Re: std.algorithm.remove and principle of least astonishment

[Steven Schveighoffer]

On Sat, 16 Oct 2010 15:49:56 -0400, Andrei Alexandrescu  
 wrote:



On 10/16/2010 01:39 PM, Steven Schveighoffer wrote:

Andrei, I am increasingly seeing people struggling with the decision to
make strings bidirectional ranges of dchar instead of what the compiler
says they are. This needs a different solution. It's too
confusing/difficult to deal with.


I'm not seeing that. I'm seeing strings working automagically with most  
of std.algorithm without ever destroying a wide string.


I've seen several posts regarding char[] being considered differently by  
the compiler and std.algorithm.


The most prominent was the fact that:

foreach(x; str)

iterates over individual char's, not dchars.

While I agree that a bidirectional range is the only sane way to view  
utf-8 strings, a char[] is not necessarily a utf-8 string.  It's an array  
of utf-8 code points.  At least to the compiler.


You can interpret it as a utf-8 string, or as an array.  And the compiler  
allows both.  std.algorithm doesn't.  This half-ass attempt to make  
strings safe just fosters confusion.


My suggestion is to make a range that enforces the correct restrictions on  
strings.  The compiler should treat string literals as a polysemous type  
that is by default this new type, or could optionally be an array of  
immutable characters.


So for example if you define:

struct string(T) if (is(T == char) || is(T == wchar))
{
   private immutable(T)[] data;
   // range functions to ensure data is only accessed via dchar
   ...
}

Which then is used by the compiler to represent string literals, then we  
have control over what a string literal allows without littering  
std.algorithm with special cases (and any external algorithms that might  
encounter strings).


So for example, I'd want something like this:

immutable(char)[] asciiarr = "abcdef";
auto str = "abcdef"; // typed as string

foreach(x; str)
{
   assert(is(typeof(x) == dchar));
}

foreach(ref x; str) // fails

foreach(ref x; asciiarr) // ok, x is of type immutable(char)

The truth is, 100% of the time for me, I want to use string literals to  
represent ASCII strings, not utf-8 strings (I speak English, so I care  
almost nothing for unicode).  And std.algorithm steadfastly refuses to  
treat them as such.  I think it's just too limited.  Yes, it would be nice  
if by default strings were bi-directional ranges of dchar, to be on the  
safe side, but I also want the ability to have an array of chars, which  
works as an array, even in std.algorithm, *and* is initializeable via  
string literals.



My requirements for the string struct would be:

1. only access via dchar
2. prevent slicing a code point
3. Indexing returns a dchar as well, which provides pseudo-random access  
(if you access an index that's in the middle of a code point, you get an  
exception).


-Steve

Re: duck!

[Andrei Alexandrescu]

On 10/16/2010 02:54 PM, kenji hara wrote:

Adapter-Pattern! I'd have forgotten the name.
It is NOT equals to duck-typing.


It's a subset of duck typing. I don't think calling a function that 
supports a limited form of duck typing "duck" is a lie.


Andrei

Re: duck!

[Walter Bright]

Andrei Alexandrescu wrote:
Please substitute: "X does duck typing in the D programming language". 
What is X?


FWIW this was the story with "immutable". Walter got tired of 
explaining: "Invariant implements immutable types in the D programming 
language".


Boy did I ever get tired of that. It's a classic example of names mattering - 
it's not just a bikeshed color.

Re: duck!

[Walter Bright]

Max Samukha wrote:
I think that is a wrong approach to marketing. Even microsoft avoids 
giving fancy names to API functions. It is ok to give a fancy name to an 
API (Windows Presentation Foundation, etc) or a product but the mundane 
function names should be as boring and factual as they deserve it. It is 
poor programmers and not marketing folks who will be using them.


If it's a cringeworthy name, I'd agree. But "duck" is not cringeworthy.


As other people said, there are better ways of marketing D. For example, 
you may want to hire a professional web designer to make D's web site 
look less amateurish.


We're doing that, too.

Re: std.algorithm.remove and principle of least astonishment

[Tomek Sowiński]

Andrei Alexandrescu napisał:

> On 10/16/2010 01:39 PM, Steven Schveighoffer wrote:
>> I suggest wrapping a char[] or wchar[] (of all constancies) with a
>> special range that imposes the restrictions.
> 
> I did so. It was called byDchar and it would accept a string type. It
> sucked.

Why it sucked?

-- 
Tomek

Re: duck!

[Andrei Alexandrescu]

On 10/16/2010 01:43 PM, Michel Fortin wrote:

On 2010-10-16 13:19:36 -0400, Andrei Alexandrescu
 said:


The problem with "adaptTo" is that, just like itoa or printf, it is
too boring to have marketing value. I think the feature is going to be
_big_. We can't leave a big feature to a name like "adaptTo". The New
York Times won't have a headline like "adaptTo changes the name of the
game".


It's risky in my opinion to bet that it's going to be a feature big
enough that everyone will remember what it means. Also, "duck" is a
misnomer. The commonly-accepted meaning of duck typing is basically
dynamic dispatch based on function names, and when the function doesn't
exist it's a runtime error. I bet you'll get a ton of negative feedback
for misrepresentation or deformation of the concept. That said, it could
bring attention, but perhaps not the kind of attention you'd like.


interface Duck
{
void walk();
void quack();
}

class Whatsthis
{
void walk();
void quack();
}

auto a = duck!Duck(new Whatsthis);

It's duck typing all right. The term does not have an academic canonical 
name. I doubt this is ever going to cause a rumpus or be a source of 
confusion.



Programmers like automated things. That feature should be called "magic
adapters" or "cheap adapters"


*yawn*


(or some variation of that) because it's
an adapter and it's magic/cheap, and people can search "adapter" and
immediately get hundreds of results explaining the concept. And the
function name could be "adaptTo", or "adapt" (or "magic" if you want it
to look funny).


Please substitute: "X does duck typing in the D programming language". 
What is X?


FWIW this was the story with "immutable". Walter got tired of 
explaining: "Invariant implements immutable types in the D programming 
language".



And I think I agree with your arguments about "as" having problems.



I'd go with the longer "ducktype". Length is not as important as
evocative power and brand name!

auto d = ducktype!Drawable(obj);


At this point, why not call it ducktape™. Now that's a brand name.


Meh.


Andrei

Re: std.algorithm.remove and principle of least astonishment

[klickverbot]

On 10/16/10 9:47 PM, Andrei Alexandrescu wrote:

Thanks for the input. This is not a bug, it's what I believe to be a
very intentional feature: strings are not ordinary arrays because
characters have variable length. As such, assigning to "the first
character in a string" is not allowed because the assignment might mess
up the next character.


I see that there is a problem due the difference of code units and code 
points, but why does the following work then?


tmp = tmp[ 0 .. i ] ~ tmp[ ( i + 1 ) .. $ ];

This is equivalent to my (naïve?) mental model of remove(), and thus it 
seems very counter-intuitive to me that one works, but the other doesn't.

Re: duck!

[kenji hara]

Adapter-Pattern! I'd have forgotten the name.
It is NOT equals to duck-typing.

adaptTo supports Adapter-Pattern.

Thanks Michel.

Kenji Hara

2010/10/17 Michel Fortin :
> On 2010-10-16 14:32:10 -0400, Walter Bright 
> said:
>
>>> Nobody is going to start using D because it has a function *named* duck.
>>
>> Maybe not, but it will raise awareness that "D has duck typing".
>> Otherwise, I guarantee you that people will argue that "I need duck typing,
>> and Z has it and D does not" if it is named adaptTo.
>
> The problem is that D doesn't have duck-typing. The adapter pattern isn't
> duck-typing. Duck-typing is when you have an object and can call a 'quack'
> function on it and if there's no 'quack' function you get a runtime error.
>
> It's like saying D is a dynamic language, people will know you're
> bullshitting them.
>
> --
> Michel Fortin
> michel.for...@michelf.com
> http://michelf.com/
>
>

Re: std.algorithm.remove and principle of least astonishment

[Andrei Alexandrescu]

On 10/16/2010 01:39 PM, Steven Schveighoffer wrote:

I suggest wrapping a char[] or wchar[] (of all constancies) with a
special range that imposes the restrictions.


I did so. It was called byDchar and it would accept a string type. It 
sucked.


char[] and wchar[] are special. They embed their UTF affiliation in 
their type. I don't think we should make a wash of all that by handling 
them as arrays. They are not arrays.



Andrei

Re: std.algorithm.remove and principle of least astonishment

[Andrei Alexandrescu]

On 10/16/2010 01:39 PM, Steven Schveighoffer wrote:

Andrei, I am increasingly seeing people struggling with the decision to
make strings bidirectional ranges of dchar instead of what the compiler
says they are. This needs a different solution. It's too
confusing/difficult to deal with.


I'm not seeing that. I'm seeing strings working automagically with most 
of std.algorithm without ever destroying a wide string.


Andrei

Re: std.algorithm.remove and principle of least astonishment

[Andrei Alexandrescu]

On 10/16/2010 01:39 PM, Steven Schveighoffer wrote:

My guess is that since INPUT is a string, phobos has unwisely decided to
treat strings not as random access arrays of chars, but as a
bidirectional range of dchar.


s/un//

:o)

Andrei

Re: std.algorithm.remove and principle of least astonishment

[Andrei Alexandrescu]

On 10/16/2010 01:29 PM, klickverbot wrote:

Hello all,

I decided to have a go at solving some easy programming puzzles with
D2/Phobos to see how Phobos, especially ranges and std.algorithm, work
out in simple real-world use cases (the puzzle in question is from
hacker.org, by the way).

The following code is a direct translation of a simple problem
description to D (it is horrible from performance point of view, but
that's certainly no issue here).

---
import std.algorithm;
import std.conv;
import std.stdio;

// The original input string is longer, but irrelevant to this post.
enum INPUT = "93752xxx746x27x1754xx90x93x238x44x75xx087509";

void main() {
uint sum;

auto tmp = INPUT.dup;
size_t i;
while ( i < tmp.length ) {
char c = tmp[ i ];
if ( c == 'x' ) {
tmp = remove( tmp, i );
i -= 2;
} else {
sum += to!uint( [ c ] );
++i;
}
}

writeln( sum );
}
---

Quite contrary to what you would expect, the call to »remove« fails to
compile with the following error messages: »std/algorithm.d(4287):
Error: front(src) is not an lvalue« and »std/algorithm.d(4287): Error:
front(tgt) is not an lvalue«.

I am intentionally posting this to this NG and not to d.…D.learn, since
this is a quite gross violation of the principle of least surprise in my
eyes.

If this isn't a bug, a better error message via a template constraint or
a static assert would be something worth looking at in my opinion, since
one would probably expect this to compile and not to fail within Phobos
code.

David


Thanks for the input. This is not a bug, it's what I believe to be a 
very intentional feature: strings are not ordinary arrays because 
characters have variable length. As such, assigning to "the first 
character in a string" is not allowed because the assignment might mess 
up the next character.


It's a good test bed. Simply replacing this:

   auto tmp = INPUT.dup;

with this:

   auto tmp = cast(ubyte[]) INPUT.dup;

makes the program work and print 322 (you also must include std.conv).

How do you all believe we could improve this example?

1. remove() could be specialized for char[] and wchar[] because it can 
be made to work with some effort and is a worthwhile algorithms for 
strings.


2. to!(ubyte[]) should work for char[] by making a copy and casting it 
to ubyte[]. So this should have worked:


   auto tmp = to!(ubyte[])(INPUT);

to! is better than cast because it always does the right thing and never 
undermines type safety.


Whadday'all think?


Andrei

Re: duck!

[kenji hara]

'Duck Typing' is a very broad concept.
adaptTo is supported only in part.

For example, you can not adapt class from class.
It has semantic problem of object states, so I never support it.

// this is invalid example
class C{ draw(){ return 10; } }
class X{ draw(){ return value; } int value; }
X x = adaptTo!X(new C());
// x.value == ??, cannot provide generally.


If you call it a duck, it will tell a lie!

Kenji Hara.

2010/10/17 Walter Bright :
> Leandro Lucarella wrote:
>>
>> Walter and you have the same convoluted brain, I can understand why he
>> instantly recognize it ;)
>
>
>
>> I already made my point, it make no sense to keep defending my position
>> since, evidently, is a pure subjective matter.
>
> It certainly is a glorious bikeshed.
>
>> I just think auto a_bird = duck!Bird(a_duck) is not obvious at all
>> compared to auto a_bird = adapt!Bird(a_duck). I even think adaptTo is
>> even cleaner, and I tend to hate long names, specially when camelCase is
>> involved, but since you didn't like it I, as others, suggested simply
>> adapt). If one could write auto a_bird = adapt!a_duck(Bird), adapt would
>> be as clear as adaptTo is with the current syntax. With adaptTo!Type you
>> even have the precedent of the to!Type template, so it seems like a nice
>> extension.
>
> Microsoft has a tradition of naming their products after what they do:
> Windows, Word, Office, etc. It's obvious why they do it, and it works, but
> it is just so generic and dull.
>
> Being the upstart language, D needs now and then something a little more
> attention-getting than generic terms. The "duck" feature is important for
> two reasons:
>
> 1. duck typing is all the rage now
>
> 2. being able to implement duck typing as a library feature (rather than a
> language one) is a great demonstration of what D can do
>
> Label it "adaptTo" and few will even notice it. Label it "duck" and people
> will click on the link to see what it does. It's important that people
> notice that D has these things, and "duck" helps with that.
>
> I've been in this business a long time, and while you'd think that
> programmers are above "what's in a name", we are just like everyone else. A
> catchy name gets results. Borland, for example, added a trivial and boring
> feature to their linker, called it "smart linking", and managed to get an
> unbelievable amount of hoopla from the computer press out of it. They did it
> again with another feature they called "zoom".
>
> Which blog article would you click on? "Interface Adapter for D" or "Duck
> Typing for D"?
>
> "duck" is a great name for the feature. It's short & sweet, fits right in
> with the popularity of duck typing, stands out, isn't boring, etc. Heck, as
> proof, look at all the interest in this thread!!
>

Re: duck!

[Jimmy Cao]

Haha!
But many people consider the interface system in Go as duck-typing,
so imo duck! is a very suitable name.

On Sat, Oct 16, 2010 at 2:25 PM, Adam D. Ruppe wrote:

> > The problem is that D doesn't have duck-typing.
>
> But it does and it has for a long time:
>
> void func(A)(A a) {
>   a.quack();
> }
>
> This new thing looks to me to be more like Go typing (lol?), where objects
> fulfill
> interfaces without explicit templates on the functions nor decorations on
> the
> class. Here's a name!
>
> go!IWhatever(myclass)
>
> hahaha.
>

Re: Feature discussion: __traits(getSource, function)

[Adam D. Ruppe]

Well, it sounds like I'm not the only one who'd find this useful, so I took a 
look
at the compiler.

It seems to only store file and line internally (I might have missed something
though) so the path of least resistance seems to be exposing that, and then
pulling the source with a library function.

But I'll keep looking, since avoiding the library function would be nice (no -J
and no bugs!).

Re: duck!

[Adam D. Ruppe]

> The problem is that D doesn't have duck-typing.

But it does and it has for a long time:

void func(A)(A a) {
   a.quack();
}

This new thing looks to me to be more like Go typing (lol?), where objects 
fulfill
interfaces without explicit templates on the functions nor decorations on the
class. Here's a name!

go!IWhatever(myclass)

hahaha.

Re: duck!

[Andrei Alexandrescu]

On 10/16/2010 12:38 PM, Steven Schveighoffer wrote:

On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu
 wrote:


The problem with "adaptTo" is that, just like itoa or printf, it is
too boring to have marketing value.


Wait, really? This statement has no place in a programming language
decision IMO. Nobody is going to start using D because it has a function
*named* duck.

Let's change writef to shazam! Let's call File BitLocker! And 'to'
really should be called transformationVehicle!


I think ducktype is an important feature of D. I want to give it a name 
that is correspondingly resounding. The likes of files, writef, and 
conversions are commonplace. That's all.


Andrei

Re: duck!

[Jimmy Cao]

According to wikipedia,
duck typing is a style of dynamic typing where an object's
methods/properties determine what i can do.

On Sat, Oct 16, 2010 at 2:14 PM, Kagamin  wrote:

> Michel Fortin Wrote:
>
> > The problem is that D doesn't have duck-typing. The adapter pattern
> > isn't duck-typing. Duck-typing is when you have an object and can call
> > a 'quack' function on it and if there's no 'quack' function you get a
> > runtime error.
>
> Isn't that dynamic typing?
>

Re: duck!

[Andrej Mitrovic]

What's all this arguing about anyway?

import std.conv : duck;

alias duck as;
alias duck adaptTo;

Done deal.

On 10/16/10, Jimmy Cao  wrote:
> I think it's safe to say this is pretty much duck-typing in D (?)
> So then, if duck! is used, it puts emphasis on what the function allows D to
> do (duck-typing),
> while if as! is used, it sounds more intuitive (kinda like ".respond_to?" in
> Ruby) .
>
> So going with my previous statement,
> if you keep using duck!, or adaptTo!, or whatever this becomes, it will
> eventually stick and will sound intuitive no matter what.
> In that way, I think as! is not necessarily such a good choice.
>
> Also, I really agree with Kagamin and Walter's argument, that simply the
> name "duck!" would raise awareness for this features.
>
> 2010/10/16 so 
>
>> Reading wikipedia, definition and the examples exactly match adaptTo.
>> Before naming it, i think we should first be clear about if it is really
>> duck-typing or not.
>>
>>
>> On Sat, 16 Oct 2010 21:44:51 +0300, Michel Fortin <
>> michel.for...@michelf.com> wrote:
>>
>>  On 2010-10-16 14:32:10 -0400, Walter Bright 
>>> said:
>>>
>>>  Nobody is going to start using D because it has a function *named* duck.
>
  Maybe not, but it will raise awareness that "D has duck typing".
 Otherwise, I guarantee you that people will argue that "I need duck
 typing,
 and Z has it and D does not" if it is named adaptTo.

>>>
>>> The problem is that D doesn't have duck-typing. The adapter pattern isn't
>>> duck-typing. Duck-typing is when you have an object and can call a
>>> 'quack'
>>> function on it and if there's no 'quack' function you get a runtime
>>> error.
>>>
>>> It's like saying D is a dynamic language, people will know you're
>>> bullshitting them.
>>>
>>>
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>>
>

Re: duck!

[Jimmy Cao]

I think it's safe to say this is pretty much duck-typing in D (?)
So then, if duck! is used, it puts emphasis on what the function allows D to
do (duck-typing),
while if as! is used, it sounds more intuitive (kinda like ".respond_to?" in
Ruby) .

So going with my previous statement,
if you keep using duck!, or adaptTo!, or whatever this becomes, it will
eventually stick and will sound intuitive no matter what.
In that way, I think as! is not necessarily such a good choice.

Also, I really agree with Kagamin and Walter's argument, that simply the
name "duck!" would raise awareness for this features.

2010/10/16 so 

> Reading wikipedia, definition and the examples exactly match adaptTo.
> Before naming it, i think we should first be clear about if it is really
> duck-typing or not.
>
>
> On Sat, 16 Oct 2010 21:44:51 +0300, Michel Fortin <
> michel.for...@michelf.com> wrote:
>
>  On 2010-10-16 14:32:10 -0400, Walter Bright 
>> said:
>>
>>  Nobody is going to start using D because it has a function *named* duck.

>>>  Maybe not, but it will raise awareness that "D has duck typing".
>>> Otherwise, I guarantee you that people will argue that "I need duck typing,
>>> and Z has it and D does not" if it is named adaptTo.
>>>
>>
>> The problem is that D doesn't have duck-typing. The adapter pattern isn't
>> duck-typing. Duck-typing is when you have an object and can call a 'quack'
>> function on it and if there's no 'quack' function you get a runtime error.
>>
>> It's like saying D is a dynamic language, people will know you're
>> bullshitting them.
>>
>>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>

Re: duck!

[Kagamin]

Michel Fortin Wrote:

> The problem is that D doesn't have duck-typing. The adapter pattern 
> isn't duck-typing. Duck-typing is when you have an object and can call 
> a 'quack' function on it and if there's no 'quack' function you get a 
> runtime error.

Isn't that dynamic typing?

Re: duck!

[Kagamin]

Walter Bright Wrote:

> Which blog article would you click on? "Interface Adapter for D" or "Duck 
> Typing 
> for D"?
> 
You are somewhat right. The right place for marketing is an article, not the 
library source, right? What would you click on? "Duck typing for D" or 
dsource.org/phobos/src/trunk?

Re: duck!

[so]

Reading wikipedia, definition and the examples exactly match adaptTo.  
Before naming it, i think we should first be clear about if it is really  
duck-typing or not.


On Sat, 16 Oct 2010 21:44:51 +0300, Michel Fortin  
 wrote:


On 2010-10-16 14:32:10 -0400, Walter Bright   
said:


Nobody is going to start using D because it has a function *named*  
duck.
 Maybe not, but it will raise awareness that "D has duck typing".  
Otherwise, I guarantee you that people will argue that "I need duck  
typing, and Z has it and D does not" if it is named adaptTo.


The problem is that D doesn't have duck-typing. The adapter pattern  
isn't duck-typing. Duck-typing is when you have an object and can call a  
'quack' function on it and if there's no 'quack' function you get a  
runtime error.


It's like saying D is a dynamic language, people will know you're  
bullshitting them.





--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: std.algorithm.remove and principle of least astonishment

[klickverbot]

In case it was not clear, this is what I want to achive:
»tmp = tmp[ 0 .. i ] ~ tmp[ ( i + 1 ) .. $ ];«

Re: duck!

[Steven Schveighoffer]

On Sat, 16 Oct 2010 14:32:10 -0400, Walter Bright  
 wrote:



Steven Schveighoffer wrote:
On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu  
 wrote:


The problem with "adaptTo" is that, just like itoa or printf, it is  
too boring to have marketing value.
 Wait, really?  This statement has no place in a programming language  
decision IMO.


One would think programmers are above all that, but we are not.


We are not talking about a feature name, we are talking about a *function*  
name.  I personally think 'as' is better than 'adaptTo' or 'duck'.



Nobody is going to start using D because it has a function *named* duck.


Maybe not, but it will raise awareness that "D has duck typing".  
Otherwise, I guarantee you that people will argue that "I need duck  
typing, and Z has it and D does not" if it is named adaptTo.


People will search on "duck typing in D" and with the duck template,  
they'll drop right in on it. With "adaptTo", it'll be on page 67 of the  
results, they'll never find it, and will conclude that D cannot do duck  
typing.


I would expect them to search for it and find the 'duck typing' section of  
the D marketing documents, and see that 'D does duck typing, see  
adaptTo'.  Or find it on wikipedia.


Unless you plan on handing people a full copy of the phobos docs as  
'marketing material'...


Let's change writef to shazam!  Let's call File BitLocker!  And 'to'  
really should be called transformationVehicle!


Think of it another way. Remember zip files? What a great name, and yes,  
it seemed silly at first, but zip entered the lexicon and D has a zip  
module and it never occurs to anyone it might be better named  
std.compressedArchive. Phil Katz renamed arc files "zip" files, called  
his compressor "pkzip" and blew away arc so badly that most people are  
unaware it even existed.


I think the catchy, silly "zip" name was a significant factor in getting  
people to notice his program. In contrast, the superior "lharc" with its  
"lzh" files never caught on.


These are completely unsubstantiated statements focused on a very narrow  
set of variables.  It's like all those studies that say X causes cancer  
because look most people who use X have cancer.  Well, yeah, but they are  
all 40-70 yr old people, who freaking knows how many factors went into  
them getting cancer!!!  And it proves itself again and again when the next  
year, they say, 'well that study was flawed, we now *know* that it was  
really Y'.


Besides, duck isn't the compiler name, it's a very very small part of the  
library.  I think you associate more weight to this than there actually  
is.  Let's concentrate on finding the name that best describes the  
function.  This might be 'duck', but let's leave marketing considerations  
out of it.  If duck was a verb that meant 'walk like a...'  then I'd agree  
it was a fine term.


How about if we can say D's functions are named intuitively instead of  
after some colloquial term that describes the function?


And yeah, I agree zip is now a de-facto term, so much so that I think  
std.range.Zip should be renamed :)  But was it zip that made the tool  
famous or the tool that made zip famous?


Let's also not forget the hundreds, probably thousands, of 'cute' names  
that didn't save their respective products because the marketing material  
sucked.


-Steve

Re: duck!

[Kagamin]

Walter Bright Wrote:

> One would think programmers are above all that, but we are not.

Ask people what they think about "cross-platform" .net ad campaign.

Re: duck!

[Walter Bright]

Michel Fortin wrote:
On 2010-10-16 14:32:10 -0400, Walter Bright  
said:



Nobody is going to start using D because it has a function *named* duck.


Maybe not, but it will raise awareness that "D has duck typing". 
Otherwise, I guarantee you that people will argue that "I need duck 
typing, and Z has it and D does not" if it is named adaptTo.


The problem is that D doesn't have duck-typing. The adapter pattern 
isn't duck-typing. Duck-typing is when you have an object and can call a 
'quack' function on it and if there's no 'quack' function you get a 
runtime error.


If you make an interface that consists solely of the 'quack' function, then 
duck!quack(object) satisfies the requirement if object has a 'quack' function.


It's like saying D is a dynamic language, people will know you're 
bullshitting them.

Re: duck!

[so]

As "as" looks sweet, you have rather compelling points, "duck" sure grabs  
too much attention.


On Sat, 16 Oct 2010 21:16:08 +0300, Walter Bright  
 wrote:



Leandro Lucarella wrote:

Walter and you have the same convoluted brain, I can understand why he
instantly recognize it ;)





I already made my point, it make no sense to keep defending my position
since, evidently, is a pure subjective matter.


It certainly is a glorious bikeshed.


I just think auto a_bird = duck!Bird(a_duck) is not obvious at all
compared to auto a_bird = adapt!Bird(a_duck). I even think adaptTo is
even cleaner, and I tend to hate long names, specially when camelCase is
involved, but since you didn't like it I, as others, suggested simply
adapt). If one could write auto a_bird = adapt!a_duck(Bird), adapt would
be as clear as adaptTo is with the current syntax. With adaptTo!Type you
even have the precedent of the to!Type template, so it seems like a nice
extension.


Microsoft has a tradition of naming their products after what they do:  
Windows, Word, Office, etc. It's obvious why they do it, and it works,  
but it is just so generic and dull.


Being the upstart language, D needs now and then something a little more  
attention-getting than generic terms. The "duck" feature is important  
for two reasons:


1. duck typing is all the rage now

2. being able to implement duck typing as a library feature (rather than  
a language one) is a great demonstration of what D can do


Label it "adaptTo" and few will even notice it. Label it "duck" and  
people will click on the link to see what it does. It's important that  
people notice that D has these things, and "duck" helps with that.


I've been in this business a long time, and while you'd think that  
programmers are above "what's in a name", we are just like everyone  
else. A catchy name gets results. Borland, for example, added a trivial  
and boring feature to their linker, called it "smart linking", and  
managed to get an unbelievable amount of hoopla from the computer press  
out of it. They did it again with another feature they called "zoom".


Which blog article would you click on? "Interface Adapter for D" or  
"Duck Typing for D"?


"duck" is a great name for the feature. It's short & sweet, fits right  
in with the popularity of duck typing, stands out, isn't boring, etc.  
Heck, as proof, look at all the interest in this thread!!



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: duck!

[Max Samukha]

On 10/16/2010 09:16 PM, Walter Bright wrote:

Leandro Lucarella wrote:

Walter and you have the same convoluted brain, I can understand why he
instantly recognize it ;)





I already made my point, it make no sense to keep defending my position
since, evidently, is a pure subjective matter.


It certainly is a glorious bikeshed.


I just think auto a_bird = duck!Bird(a_duck) is not obvious at all
compared to auto a_bird = adapt!Bird(a_duck). I even think adaptTo is
even cleaner, and I tend to hate long names, specially when camelCase is
involved, but since you didn't like it I, as others, suggested simply
adapt). If one could write auto a_bird = adapt!a_duck(Bird), adapt would
be as clear as adaptTo is with the current syntax. With adaptTo!Type you
even have the precedent of the to!Type template, so it seems like a nice
extension.


Microsoft has a tradition of naming their products after what they do:
Windows, Word, Office, etc. It's obvious why they do it, and it works,
but it is just so generic and dull.

Being the upstart language, D needs now and then something a little more
attention-getting than generic terms. The "duck" feature is important
for two reasons:

1. duck typing is all the rage now

2. being able to implement duck typing as a library feature (rather than
a language one) is a great demonstration of what D can do

Label it "adaptTo" and few will even notice it. Label it "duck" and
people will click on the link to see what it does. It's important that
people notice that D has these things, and "duck" helps with that.



I think that is a wrong approach to marketing. Even microsoft avoids 
giving fancy names to API functions. It is ok to give a fancy name to an 
API (Windows Presentation Foundation, etc) or a product but the mundane 
function names should be as boring and factual as they deserve it. It is 
poor programmers and not marketing folks who will be using them.


As other people said, there are better ways of marketing D. For example, 
you may want to hire a professional web designer to make D's web site 
look less amateurish.

Re: duck!

[Michel Fortin]

On 2010-10-16 14:32:10 -0400, Walter Bright  said:


Nobody is going to start using D because it has a function *named* duck.


Maybe not, but it will raise awareness that "D has duck typing". 
Otherwise, I guarantee you that people will argue that "I need duck 
typing, and Z has it and D does not" if it is named adaptTo.


The problem is that D doesn't have duck-typing. The adapter pattern 
isn't duck-typing. Duck-typing is when you have an object and can call 
a 'quack' function on it and if there's no 'quack' function you get a 
runtime error.


It's like saying D is a dynamic language, people will know you're 
bullshitting them.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: duck!

[Michel Fortin]

On 2010-10-16 13:19:36 -0400, Andrei Alexandrescu 
 said:


The problem with "adaptTo" is that, just like itoa or printf, it is too 
boring to have marketing value. I think the feature is going to be 
_big_. We can't leave a big feature to a name like "adaptTo". The New 
York Times won't have a headline like "adaptTo changes the name of the 
game".


It's risky in my opinion to bet that it's going to be a feature big 
enough that everyone will remember what it means. Also, "duck" is a 
misnomer. The commonly-accepted meaning of duck typing is basically 
dynamic dispatch based on function names, and when the function doesn't 
exist it's a runtime error. I bet you'll get a ton of negative feedback 
for misrepresentation or deformation of the concept. That said, it 
could bring attention, but perhaps not the kind of attention you'd like.


Programmers like automated things. That feature should be called "magic 
adapters" or "cheap adapters" (or some variation of that) because it's 
an adapter and it's magic/cheap, and people can search "adapter" and 
immediately get hundreds of results explaining the concept. And the 
function name could be "adaptTo", or "adapt" (or "magic" if you want it 
to look funny).


And I think I agree with your arguments about "as" having problems.


I'd go with the longer "ducktype". Length is not as important as 
evocative power and brand name!


auto d = ducktype!Drawable(obj);


At this point, why not call it ducktape™. Now that's a brand name.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: std.algorithm.remove and principle of least astonishment

[Steven Schveighoffer]

On Sat, 16 Oct 2010 14:29:59 -0400, klickverbot  wrote:


Hello all,

I decided to have a go at solving some easy programming puzzles with  
D2/Phobos to see how Phobos, especially ranges and std.algorithm, work  
out in simple real-world use cases (the puzzle in question is from  
hacker.org, by the way).


The following code is a direct translation of a simple problem  
description to D (it is horrible from performance point of view, but  
that's certainly no issue here).


---
import std.algorithm;
import std.conv;
import std.stdio;

// The original input string is longer, but irrelevant to this post.
enum INPUT = "93752xxx746x27x1754xx90x93x238x44x75xx087509";

void main() {
uint sum;

auto tmp = INPUT.dup;
size_t i;
while ( i < tmp.length ) {
   char c = tmp[ i ];
   if ( c == 'x' ) {
  tmp = remove( tmp, i );
  i -= 2;
   } else {
  sum += to!uint( [ c ] );
  ++i;
   }
}

writeln( sum );
}
---

Quite contrary to what you would expect, the call to »remove« fails to  
compile with the following error messages: »std/algorithm.d(4287):  
Error: front(src) is not an lvalue« and »std/algorithm.d(4287): Error:  
front(tgt) is not an lvalue«.


My guess is that since INPUT is a string, phobos has unwisely decided to  
treat strings not as random access arrays of chars, but as a bidirectional  
range of dchar.  This means that even though you can randomly access the  
characters (phobos can't take that away from you), it artificially imposes  
restrictions (such as making front an rvalue) where it wouldn't do the  
same to an int[] or ubyte[].


Andrei, I am increasingly seeing people struggling with the decision to  
make strings bidirectional ranges of dchar instead of what the compiler  
says they are.  This needs a different solution.  It's too  
confusing/difficult to deal with.


I suggest wrapping a char[] or wchar[] (of all constancies) with a special  
range that imposes the restrictions.  This means people will have to use  
these ranges when they want to treat them as bidir ranges of dchar, but  
the current situation is at least annoying, if not a complete turn-off to  
D.  And it vastly simplifies code that uses ranges, since they now don't  
have to contain special cases for char[] and wchar[].


-Steve

Re: duck!

[Walter Bright]

Steven Schveighoffer wrote:
On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu 
 wrote:


The problem with "adaptTo" is that, just like itoa or printf, it is 
too boring to have marketing value.


Wait, really?  This statement has no place in a programming language 
decision IMO.


One would think programmers are above all that, but we are not.


Nobody is going to start using D because it has a 
function *named* duck.


Maybe not, but it will raise awareness that "D has duck typing". Otherwise, I 
guarantee you that people will argue that "I need duck typing, and Z has it and 
D does not" if it is named adaptTo.


People will search on "duck typing in D" and with the duck template, they'll 
drop right in on it. With "adaptTo", it'll be on page 67 of the results, they'll 
never find it, and will conclude that D cannot do duck typing.



Let's change writef to shazam!  Let's call File BitLocker!  And 'to' 
really should be called transformationVehicle!


Think of it another way. Remember zip files? What a great name, and yes, it 
seemed silly at first, but zip entered the lexicon and D has a zip module and it 
never occurs to anyone it might be better named std.compressedArchive. Phil Katz 
renamed arc files "zip" files, called his compressor "pkzip" and blew away arc 
so badly that most people are unaware it even existed.


I think the catchy, silly "zip" name was a significant factor in getting people 
to notice his program. In contrast, the superior "lharc" with its "lzh" files 
never caught on.



If you want to help market D, come up with some better logos, help 
redesign the web site, and maybe write a book (oh wait, you already did 
that :)


We are working on all of that. It's all important.

std.algorithm.remove and principle of least astonishment

[klickverbot]

Hello all,

I decided to have a go at solving some easy programming puzzles with 
D2/Phobos to see how Phobos, especially ranges and std.algorithm, work 
out in simple real-world use cases (the puzzle in question is from 
hacker.org, by the way).


The following code is a direct translation of a simple problem 
description to D (it is horrible from performance point of view, but 
that's certainly no issue here).


---
import std.algorithm;
import std.conv;
import std.stdio;

// The original input string is longer, but irrelevant to this post.
enum INPUT = "93752xxx746x27x1754xx90x93x238x44x75xx087509";

void main() {
   uint sum;

   auto tmp = INPUT.dup;
   size_t i;
   while ( i < tmp.length ) {
  char c = tmp[ i ];
  if ( c == 'x' ) {
 tmp = remove( tmp, i );
 i -= 2;
  } else {
 sum += to!uint( [ c ] );
 ++i;
  }
   }

   writeln( sum );
}
---

Quite contrary to what you would expect, the call to »remove« fails to 
compile with the following error messages: »std/algorithm.d(4287): 
Error: front(src) is not an lvalue« and »std/algorithm.d(4287): Error: 
front(tgt) is not an lvalue«.


I am intentionally posting this to this NG and not to d.…D.learn, since 
this is a quite gross violation of the principle of least surprise in my 
eyes.


If this isn't a bug, a better error message via a template constraint or 
a static assert would be something worth looking at in my opinion, since 
one would probably expect this to compile and not to fail within Phobos 
code.


David

Re: [nomenclature] systems language

[Paulo Pinto]

Would that make Smalltalk, Lisp, Oberon, Modula-3, Component Pascal, Ada,
Mac Pascal system programming languages?

All of them were used to write operating systems, in some of them the 
operating system and
language are the same, kind of.

--
paulo

"div0"  wrote in message 
news:i9c2ue$30f...@digitalmars.com...
> On 14/10/2010 13:30, Justin Johansson wrote:
>> Touted often around here is the term "systems language".
>>
>> May we please discuss a definition to be agreed upon
>> for the usage this term (at least in this community) and
>> also have some agreed upon examples of PLs that might also
>> be members of the "set of systems languages".
>> Given a general subjective term like this, one would have
>> to suspect that the D PL is not the only member of this set.
>>
>> Cheers
>> Justin Johansson
>>
>> PS. my apologies for posting a lame joke recently;
>> certainly it was not meant to be disparaging towards
>> the D PL and hopefully it was not taken this way.
>
> Something not mentioned so far:
>
> The language must be self hostable;
> i.e. you need to be able to write it's runtime in the language itself.
>
> -- 
> My enormous talent is exceeded only by my outrageous laziness.
> http://www.ssTk.co.uk 

Re: automatic code examples in documentation

[Austin Hastings]

Interspersed


On 10/15/2010 11:18 AM, Gerrit Wichert wrote:

This is a post i made deep in the 'improving the join function' thread.
Steven asked me to open a new thread on it, so here it comes.




[ ... ]


I think its a good idea if the compiler executes a syntax check on the example 
section,
like it does on the already implemented syntax checked strings.



The perl and parrot guys do this with POD. The pod syntax is simple 
enough that it is trivial to write code that extracts the examples and 
tries to compile them.


I think development of this started because some readers complained 
about book examples not compiling. The obvious (in perl) solution was to 
filter out the examples and verify them as part of a full build.



Then the compiler part is done with this. This are code examples, not unit 
tests.
They are not run with the other unit tests.
I think code examples are most usefull if they are self-contained little 
programs.

Part of the document generation may be to compile and run the extracted 
examples.
When a example does't compile it can be marked as defunct or excluded from the
documentation. The doc-generator can catch the output of the running examples
and add it to the documentation as result.

Shurely there are some problems when trying to compile the examples like wich
libs to link with, or what about GUI-code, or just code snippets, but for me
this is all secondary, maybe we can make that work later. The most important 
part
is to define the transfer mechanics to get the example code into the 
documentation.

So what do you think?


Doxygen already supports something like this. Quoting the manual:

http://www.stack.nl/~dimitri/doxygen/commands.html#cmdexample


\example 

Indicates that a comment block contains documentation for a

> source code example. The name of the source file is .
> The text of this file will be included in the documentation, just
> after the documentation contained in the comment block. All examples
> are placed in a list. The source code is scanned for documented
> members and classes. If any are found, the names are cross-referenced
> with the documentation.

The usage example looks like:

/** \example example_test.cpp
 * This is an example of how to use the Test class.
 * More details about the example.
 */

Using this approach would have the benefit of nicely solving the
"how do I compile the examples" question, since the examples become 
stand-alone files with the "usual" compilation semantics. (Doxygen 
supports a search path for this kind of thing, so putting the files

in an examples/ subdirectory is trivial.)

=Austin

Re: duck!

[Walter Bright]

Russel Winder wrote:

Groovy uses [...]


!!!

Re: duck!

[Walter Bright]

Leandro Lucarella wrote:

Walter and you have the same convoluted brain, I can understand why he
instantly recognize it ;)





I already made my point, it make no sense to keep defending my position
since, evidently, is a pure subjective matter.


It certainly is a glorious bikeshed.


I just think auto a_bird = duck!Bird(a_duck) is not obvious at all
compared to auto a_bird = adapt!Bird(a_duck). I even think adaptTo is
even cleaner, and I tend to hate long names, specially when camelCase is
involved, but since you didn't like it I, as others, suggested simply
adapt). If one could write auto a_bird = adapt!a_duck(Bird), adapt would
be as clear as adaptTo is with the current syntax. With adaptTo!Type you
even have the precedent of the to!Type template, so it seems like a nice
extension.


Microsoft has a tradition of naming their products after what they do: Windows, 
Word, Office, etc. It's obvious why they do it, and it works, but it is just so 
generic and dull.


Being the upstart language, D needs now and then something a little more 
attention-getting than generic terms. The "duck" feature is important for two 
reasons:


1. duck typing is all the rage now

2. being able to implement duck typing as a library feature (rather than a 
language one) is a great demonstration of what D can do


Label it "adaptTo" and few will even notice it. Label it "duck" and people will 
click on the link to see what it does. It's important that people notice that D 
has these things, and "duck" helps with that.


I've been in this business a long time, and while you'd think that programmers 
are above "what's in a name", we are just like everyone else. A catchy name gets 
results. Borland, for example, added a trivial and boring feature to their 
linker, called it "smart linking", and managed to get an unbelievable amount of 
hoopla from the computer press out of it. They did it again with another feature 
they called "zoom".


Which blog article would you click on? "Interface Adapter for D" or "Duck Typing 
for D"?


"duck" is a great name for the feature. It's short & sweet, fits right in with 
the popularity of duck typing, stands out, isn't boring, etc. Heck, as proof, 
look at all the interest in this thread!!

Re: New slides about Go

[Walter Bright]

Jérôme M. Berger wrote:

Walter Bright wrote:

Nick Sabalausky wrote:

Seems a bad idea to force the overhead of that, but it should
definitely be available as an option. Contrary to what Walter and
Andrei seem to think, 32-bit systems are still very much alive and
will be for quite awhile longer. Especially when you remember that
there are more computers out there than just desktops and servers.
(Ex: When is a phone ever going to need 64-bit? Eventually maybe, but
certainly not anytime soon.)

16 bit processors died around 15 years after the introduction of 32 bit
ones, even for embedded systems. If history repeats itself, figure 32
bit ones have about 5 years to go!


Funny thing is we still use some 8-bit microcontrollers in some
situations :) But you're right, as soon as we need something more we
go directly to 32 bits without stopping in the 16 bits square.


I can tell 16 bits is dead as a doornail because the 16 bit tools biz has dried 
up to nothing.

Re: duck!

[Steven Schveighoffer]

On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu  
 wrote:


The problem with "adaptTo" is that, just like itoa or printf, it is too  
boring to have marketing value.


Wait, really?  This statement has no place in a programming language  
decision IMO.  Nobody is going to start using D because it has a function  
*named* duck.


Let's change writef to shazam!  Let's call File BitLocker!  And 'to'  
really should be called transformationVehicle!


If you want to help market D, come up with some better logos, help  
redesign the web site, and maybe write a book (oh wait, you already did  
that :)


-Steve