www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - New in C#4

reply bearophile <bearophileHUGS lycos.com> writes:
Thanks to Reddit I have found a nice short document that lists some of the

https://docs.google.com/View?docid=dcj4xk6_17ffc7nmgv

They have added a dynamic invocation, useful if you want to implement a dynamic
language (like IronPython, IronRuby, etc) on top of the dotnet. Object-C shows
this is doable in a very C-like language, and the Boo language shows that in a
statically typed language it can be useful to use a Duck type once in a while
to reduce the "static type pressure". More info on this last concept in the Boo
site.

Something that I like a lot is the named arguments, that I hope to see in D and
Delight someday. They are used often in Python, and they help increase the
readability of the code, sometimes even reducing mistakes.
They have used colons:
foo(x: 1, z: 3)
While Python uses equal signs:
foo(x=1, z=3)
I think they are about equally readable.
(I think there's a problem with named arguments, that you can solve in some
ways, for example with an extra hidden bitfield argument that encodes what
arguments are given and what not).

Bye,
bearophile
Oct 29 2008
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article

 They have used colons:
 foo(x: 1, z: 3)
 While Python uses equal signs:
 foo(x=1, z=3)
 I think they are about equally readable.
 (I think there's a problem with named arguments, that you can solve in some


ways, for example with an extra hidden bitfield argument that encodes what
arguments are given and what not).

 Bye,
 bearophile


Vote++ for named arguments.  I've been meaning to bring this up for a while.
Given that it's a pure syntactic sugar feature and therefore shouldn't cause any
significant ripple effects (at least none that I'm aware of) and greatly
simplifies design and use of APIs with lots of optional parameters, I think
it's a
no brainer.
Oct 29 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 30, 2008 at 12:18 AM, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from bearophile (bearophileHUGS lycos.com)'s article

 They have used colons:
 foo(x: 1, z: 3)
 While Python uses equal signs:
 foo(x=1, z=3)
 I think they are about equally readable.
 (I think there's a problem with named arguments, that you can solve in some


 ways, for example with an extra hidden bitfield argument that encodes what
 arguments are given and what not).

 Bye,
 bearophile


 Vote++ for named arguments.  I've been meaning to bring this up for a while.
 Given that it's a pure syntactic sugar feature and therefore shouldn't cause
any
 significant ripple effects (at least none that I'm aware of) and greatly
 simplifies design and use of APIs with lots of optional parameters, I think
it's a
 no brainer.


I think it would be nice, but it has come up a few times in the past,
and never got much traction.

--bb
Oct 29 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Oct 29, 2008 at 10:37 AM, bearophile <bearophileHUGS lycos.com> wrote:

 Thanks to Reddit I have found a nice short document that lists some of the

 https://docs.google.com/View?docid=dcj4xk6_17ffc7nmgv

 They have added a dynamic invocation, useful if you want to implement a
dynamic language (like IronPython, IronRuby, etc) on top of the dotnet.
Object-C shows this is doable in a very C-like language, and the Boo language
shows that in a statically typed language it can be useful to use a Duck type
once in a while to reduce the "static type pressure". More info on this last
concept in the Boo site.


Aw, man, they beat me to it.  I always wondered if it would be cool to
have a language that supported both static and dynamic programming
natively.  It was going to be the "cool thing" in the next language I
made ;)  (it probably still will!)


 Something that I like a lot is the named arguments, that I hope to see in D
and Delight someday. They are used often in Python, and they help increase the
readability of the code, sometimes even reducing mistakes.
 They have used colons:
 foo(x: 1, z: 3)
 While Python uses equal signs:
 foo(x=1, z=3)
 I think they are about equally readable.
 (I think there's a problem with named arguments, that you can solve in some
ways, for example with an extra hidden bitfield argument that encodes what
arguments are given and what not).


Or, you could enforce that named arguments must all have default
values, or that they must _all_ be given when the function is called.
Since it's getting resolved at compile time, no bitfield is necessary.
 It's the same thing as arguments with default values -- all the
compiler does is it inserts the default values at the call site.

Named parameters are very cool, though, and are invaluable for things
like GUI APIs.  Combined with structs, they can also remove the need
for a separate struct literal syntax.  S(x: 5, y: 10) looks pretty
damn nice.
Oct 29 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jarrett Billingsley:

 Since it's getting resolved at compile time, no bitfield is necessary.


When we have designed ShedSkin we have had to deal with named arguments too,
including situations like:

import sys
def foo(a, b): return a - b
def bar(b, a): return a / b
fun = [foo, bar]
if sys.argv[1] == "1":
    fun[0], fun[1] = fun[1], fun[0]
print fun[0](a=5.0, b=3.0)

The relative input/output:
C:\>args.py 0
2.0
C:\>args.py 1
1.66666666667

Bye,
bearophile
Oct 29 2008
parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Oct 29, 2008 at 3:50 PM, bearophile <bearophileHUGS lycos.com> wrote:

 Jarrett Billingsley:

 Since it's getting resolved at compile time, no bitfield is necessary.


 When we have designed ShedSkin we have had to deal with named arguments too,
including situations like:


Ooh, that's icky.  Well I'd argue then that in the equivalent in D:

float foo(float a, float b) { return a - b; }
float bar(float b, float a) { return a / b; }
auto fun = [&foo, &bar];
...
fun[0](a: 5, b: 3); // error

the last line would be an error only because function pointers are not
the same as functions, and their parameters do not have names.
Similar to how currently, a function pointer or delegate to a function
that takes optional parameters cannot be called the same way as the
original function.

Still, "only" being able to call functions directly while using
named/default parameters covers a _great_ majority of use cases.
Covering the rest seems to be wasting a lot of implementation time and
performance on something that most people honestly will not use that
much.
Oct 29 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Jarrett Billingsley:

 Still, "only" being able to call functions directly while using
 named/default parameters covers a _great_ majority of use cases.
 Covering the rest seems to be wasting a lot of implementation time and
 performance on something that most people honestly will not use that
 much.


I agree that implementing part of the semantics of named arguments is better
than nothing. In ShedSkin for example we haven't implemented the argument
syntax ** yet (pass by dictionary, not so easy to implement in C++), the full
argument pass semantics in Python is quite refined:

def foo(x, y=5, *z, **w):
    print x, y, z, w







Note that if D becomes more functional, then function
pointers/delegates/closures become quite more commonly used. So you are
limiting more than you think.

Bye,
bearophile
Oct 29 2008
prev sibling parent reply =?iso-8859-1?Q?Julio=20C=e9sar=20Carrascal=20Urquijo?= <jcarrascal gmail.com> writes:
Hello Jarrett,


 Aw, man, they beat me to it.  I always wondered if it would be cool to
 have a language that supported both static and dynamic programming
 natively.  It was going to be the "cool thing" in the next language I
 made ;)  (it probably still will!)



Actually Boo supported the same thing before them. Their IQuakFoo interface 


Off course, before that there was ActionScript 3 which mixed both (though 
dynamic is the default).
Oct 29 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Julio César Carrascal Urquijo:

 Actually Boo supported the same thing before them. Their IQuakFoo interface 



When the LDC compiler works well (based on LLVM) I think the underlying VM may
be used in ways similar to the dotnet VM or the JavaVM, so you can even think
about putting in the D language more reflection, some native forms of dynamic

ones in Boo, etc.

Bye,
bearophile
Oct 29 2008
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
bearophile wrote:

 Julio César Carrascal Urquijo:

 Actually Boo supported the same thing before them. Their IQuakFoo interface 



 
 When the LDC compiler works well (based on LLVM) I think the underlying VM may
be used in ways similar to the dotnet VM or the JavaVM, so you can even think
about putting in the D language more reflection, some native forms of dynamic

ones in Boo, etc.


This seems to be a common misconception.
LLVM doesn't actually have a VM in the traditional sense. It provides a 
virtual instruction set, but there's no common abstractions other than 
basic types (integers, floats), vectors of them, structs, static arrays, 
pointers, functions and global variables (I hope I didn't miss 
anything). Anything else has to be synthesized from those elements by 
whatever compiler frontend (or hand-coder -- not recommended) generates 
the instructions.

For example: there are no "virtual functions" in LLVM. There's just 
structs whose first member happens to be a pointer to a global constant 
array (or struct) of function pointers that can take a pointer to the 
struct as their first argument.

In other words: every language compiling to LLVM translates its 
high-level abstractions into those low-level types. And every one of 
them probably does it in a slightly different way.
It's more like a sort of typed, somewhat-platform-independent assembly 
designed for ease of optimization.
It's usually compiled to native code, so LLVM typically isn't even 
loaded into memory at the time your code is running. There's an 
interpreter and a JIT, but neither of these expose any kind of 
reflection API usable by the program they're running.

LLVM is being used to _implement_ a dotnet and Java VM, but it's not 
much like such a VM in itself.
Oct 30 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Frits van Bommel:

 This seems to be a common misconception.


Thank you very much for the explanations, I was very wrong. I think LLVM
developers have to put this important information in more evidence.

Bye,
bearophile
Oct 30 2008
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 29 Oct 2008 17:37:25 +0300, bearophile <bearophileHUGS lycos.com>  
wrote:


 Thanks to Reddit I have found a nice short document that lists some of  

 https://docs.google.com/View?docid=dcj4xk6_17ffc7nmgv

 They have added a dynamic invocation, useful if you want to implement a  
 dynamic language (like IronPython, IronRuby, etc) on top of the dotnet.  
 Object-C shows this is doable in a very C-like language, and the Boo  
 language shows that in a statically typed language it can be useful to  
 use a Duck type once in a while to reduce the "static type pressure".  
 More info on this last concept in the Boo site.

 Something that I like a lot is the named arguments, that I hope to see  
 in D and Delight someday. They are used often in Python, and they help  
 increase the readability of the code, sometimes even reducing mistakes.
 They have used colons:
 foo(x: 1, z: 3)
 While Python uses equal signs:
 foo(x=1, z=3)
 I think they are about equally readable.
 (I think there's a problem with named arguments, that you can solve in  
 some ways, for example with an extra hidden bitfield argument that  
 encodes what arguments are given and what not).

 Bye,
 bearophile


I'm waiting for named arguments, too! They make could more readable and  
self-documenting:
graphicsDevice->updateSettings(true, true, false, true); // wtf??

Compare to the following:
graphicsDevice->updateSettings(fullScreen: true, verticalSync: true,  
enableBloom: false, fullScreenAA: true);

I once had the following Color class:

class Color
{
     this (byte alpha, byte red, byte green, byte blue) { ... }
}

and used it as follows:

Color c = new Color(255, 0, 255, 0); // opaque green color

After refactoring, alpha became last argument in ctor:

     this(byte red, byte green, byte blue, byte alpha) { ... }

Note that this change didn't raise any compilation error, nothing that  
would notify my of possible error.

Needless to say that I didn't enjoy searching all the code that used Color  
to reorder parameters (although some artifact were nice :)
It would save me quite some time if I initialized all my instances as  
follows:

Color c = new Color(alpha: 255, red: 0, green: 255, blue: 0);

Now compiler could raise an error if parameters order was changed. Even  
better - compiler could reorder parameters for me automatically if given  
that all of them are specified and no params ommited (unlike Python). This  
makes code more robust to refactoring.
Oct 29 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Denis Koroskin:


 graphicsDevice->updateSettings(fullScreen: true, verticalSync: true,  
 enableBloom: false, fullScreenAA: true);


Seeing this, now I think the syntax with equals is a little shorter, so maybe I
prefer the equals:

graphicsDevice->updateSettings(fullScreen=true, verticalSync=true,  
enableBloom=false, fullScreenAA=true);



 compiler could reorder parameters for me automatically if given  
 that all of them are specified and no params ommited (unlike Python).


Maybe I don't understand what you are saying, but Python too reorders arguments.

Bye,
bearophile
Oct 29 2008
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 29 Oct 2008 23:28:25 +0300, bearophile <bearophileHUGS lycos.com>  
wrote:


 Denis Koroskin:


 graphicsDevice->updateSettings(fullScreen: true, verticalSync: true,
 enableBloom: false, fullScreenAA: true);


 Seeing this, now I think the syntax with equals is a little shorter, so  
 maybe I prefer the equals:

 graphicsDevice->updateSettings(fullScreen=true, verticalSync=true,
 enableBloom=false, fullScreenAA=true);



 compiler could reorder parameters for me automatically if given
 that all of them are specified and no params ommited (unlike Python).


 Maybe I don't understand what you are saying, but Python too reorders  
 arguments.


"unlike Python" is related to omitting parameters. Python allows that but  
it doesn't really fit statically typed langugages, I believe.


 Bye,
 bearophile
Oct 29 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Denis Koroskin:

"unlike Python" is related to omitting parameters. Python allows that but it
doesn't really fit statically typed langugages, I believe.<


I don't understand what you mean, in Python if you omit necessary arguments you
receive an error:

def foo(x, y=5): print x,y




Bye,
bearophile
Oct 29 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Oct 29, 2008 at 4:28 PM, bearophile <bearophileHUGS lycos.com> wrote:

 Denis Koroskin:


 graphicsDevice->updateSettings(fullScreen: true, verticalSync: true,
 enableBloom: false, fullScreenAA: true);


 Seeing this, now I think the syntax with equals is a little shorter, so maybe
I prefer the equals:

 graphicsDevice->updateSettings(fullScreen=true, verticalSync=true,
 enableBloom=false, fullScreenAA=true);


Er, what?  They are exactly the same size..

Besides, = is already an expression in D.  f(x = 5) has a well-defined
meaning already.
Oct 29 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Jarrett Billingsley:


 Er, what?  They are exactly the same size..


In standard Python coding style usually in function calls with named arguments
you don't put a space after the equal:
foo(x=10)

But I have just seen that after a comma people (like me) usually put a space:
foo(x: 10)

So the second line is a char longer. But I agree it's a not unimportant detail.



 Besides, = is already an expression in D.  f(x = 5) has a well-defined
 meaning already.


The following D code gives a syntax error:

import std.stdio: writefln;
int f(int x) { return x + 10; }
void main() {
    writefln( f(x=5) );
}

While this works, and assigns x to 5 in the main:

import std.stdio: writefln;
int f(int x) { return x + 10; }
void main() {
    int x;
    writefln( f(x=5) ); // Output: 15
    writefln(x); // Output: 5
}

In Python x = 5 is never an expression (this precisely to avoid the typical bug
of C code of using = instead of ==).
And the named arguments don't change the value of the variable in the calling
frame:

x = 10
f(x=5)


Overall I agree than the syntax with the colon is probably better for D.
(While a syntax that I don't like much is the .. instead of : to define an
array slice).

Bye,
bearophile
Oct 29 2008
parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Oct 29, 2008 at 4:59 PM, bearophile <bearophileHUGS lycos.com> wrote:


 So the second line is a char longer. But I agree it's a not unimportant detail.


Double negative "not unimportant" -> "important" ?  ;)  I know, you
just made a mistake.


 In Python x = 5 is never an expression (this precisely to avoid the typical
bug of C code of using = instead of ==).


OK.


 And the named arguments don't change the value of the variable in the calling
frame:

 x = 10
 f(x=5)



I'm not saying that named parameters would in D.  Your example is
precisely what I meant by "f(x = 5) already has a well-defined meaning
in D."  You're not telling me anything new.


 Overall I agree than the syntax with the colon is probably better for D.
 (While a syntax that I don't like much is the .. instead of : to define an
array slice).


In Python, in Python, in Python.  I'm pretty sick of hearing about
Python.  D is not Python, D did not come from Python, D is not made to
cater to Python users and is not designed for the same things that
Python is used for.  Syntactic choices for symbols, operators, or
keywords is a completely moot issue.  Please drop it.
Oct 29 2008
parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Wed, 29 Oct 2008 21:09:50 -0000, Jarrett Billingsley  
<jarrett.billingsley gmail.com> wrote:


 In Python, in Python, in Python.  I'm pretty sick of hearing about
 Python.  D is not Python, D did not come from Python, D is not made to
 cater to Python users and is not designed for the same things that
 Python is used for.  Syntactic choices for symbols, operators, or
 keywords is a completely moot issue.  Please drop it.


In the python forums they're not this ;)

Seriously though D isn't just from C++. Its on one of the main description  
pages that
it borrows from Python and why not. Borrow from anywhere and everywhere if  
it leads to
improvements.
But yeah, lay off painting the bike-shed.
Nov 04 2008
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
bearophile escribió:

 Denis Koroskin:
 

 graphicsDevice->updateSettings(fullScreen: true, verticalSync: true,  
 enableBloom: false, fullScreenAA: true);


 
 Seeing this, now I think the syntax with equals is a little shorter, so maybe
I prefer the equals:
 
 graphicsDevice->updateSettings(fullScreen=true, verticalSync=true,  
 enableBloom=false, fullScreenAA=true);


You didn't just replace ":" for "=", you also removed spaces! :P

graphicsDevice->updateSettings(fullScreen:true, verticalSync:true, 
enableBloom:false, fullScreenAA:true);

graphicsDevice->updateSettings(fullScreen=true, verticalSync=true, 
enableBloom=false, fullScreenAA=true);

See? Now they are the same length.

It's not a matter of preference in D, because "a=b" is an expression, so 
"=" can't be used for named arguments. I think ":" can, because that is 
used in statements... and in ?:, but there would be no ambiguities there.
Oct 29 2008
parent Jesse Phillips <jessekphillips gmail.com> writes:
On Wed, 29 Oct 2008 18:49:53 -0200, Ary Borenszweig wrote:


 bearophile escribió:

 Denis Koroskin:
 

 graphicsDevice->updateSettings(fullScreen: true, verticalSync: true,
 enableBloom: false, fullScreenAA: true);


 
 Seeing this, now I think the syntax with equals is a little shorter, so
 maybe I prefer the equals:
 
 graphicsDevice->updateSettings(fullScreen=true, verticalSync=true,
 enableBloom=false, fullScreenAA=true);


 
 You didn't just replace ":" for "=", you also removed spaces! :P
 
 graphicsDevice->updateSettings(fullScreen:true, verticalSync:true,
 enableBloom:false, fullScreenAA:true);
 
 graphicsDevice->updateSettings(fullScreen=true, verticalSync=true,
 enableBloom=false, fullScreenAA=true);
 
 See? Now they are the same length.
 
 It's not a matter of preference in D, because "a=b" is an expression, so
 "=" can't be used for named arguments. I think ":" can, because that is
 used in statements... and in ?:, but there would be no ambiguities
 there.


His point was that after typing ':' he will usually put a space. I don't 
really understand this argument, as I know of people that will complain 
when spaces aren't put around ' = '.

I do like the idea of name the arguments in the call for readability. I 
don't think it should be mandatory, nor do I believe anyone has suggested 
that.
Oct 29 2008
prev sibling parent ore-sama <spam here.lot> writes:
bearophile Wrote:


 Seeing this, now I think the syntax with equals is a little shorter, so maybe
I prefer the equals:
 
 graphicsDevice->updateSettings(fullScreen=true, verticalSync=true,  
 enableBloom=false, fullScreenAA=true);
Oct 30 2008
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Denis Koroskin" <2korden gmail.com> wrote in message 
news:op.ujsxznwqo7cclz proton.creatstudio.intranet...

 On Wed, 29 Oct 2008 17:37:25 +0300, bearophile <bearophileHUGS lycos.com> 
 wrote:


 Thanks to Reddit I have found a nice short document that lists some of 

 https://docs.google.com/View?docid=dcj4xk6_17ffc7nmgv

 They have added a dynamic invocation, useful if you want to implement a 
 dynamic language (like IronPython, IronRuby, etc) on top of the dotnet. 
 Object-C shows this is doable in a very C-like language, and the Boo 
 language shows that in a statically typed language it can be useful to 
 use a Duck type once in a while to reduce the "static type pressure". 
 More info on this last concept in the Boo site.

 Something that I like a lot is the named arguments, that I hope to see 
 in D and Delight someday. They are used often in Python, and they help 
 increase the readability of the code, sometimes even reducing mistakes.
 They have used colons:
 foo(x: 1, z: 3)
 While Python uses equal signs:
 foo(x=1, z=3)
 I think they are about equally readable.
 (I think there's a problem with named arguments, that you can solve in 
 some ways, for example with an extra hidden bitfield argument that 
 encodes what arguments are given and what not).

 Bye,
 bearophile


 I'm waiting for named arguments, too! They make could more readable and 
 self-documenting:
 graphicsDevice->updateSettings(true, true, false, true); // wtf??

 Compare to the following:
 graphicsDevice->updateSettings(fullScreen: true, verticalSync: true, 
 enableBloom: false, fullScreenAA: true);


I was just going to bring up the "series of bool params" issue. I very 
frequently find myself going out of my way to create trivial enums just to 
avoid using bool parameters.

Similar to named parameters, as much as I normally dislike VB, I've long 
been jealous of its "optional params can be in the middle" capability.

For instance:
void foo(int a, char[] b, int c=0, char[] d="", int e, char[] f, bool 
g=false) {/*...*/}
foo(17, "blah", , , 8.4, "stuff"); // <- Wow!!

That makes it *enormously* easier to design APIs with optional parameters. 
No more mucking around with potentially-conflicting function overloads just 
to work around the "optional params must be last" requirement. No more 
conflict between the desire to organize params in a conceptually-logical 
order and the need to, again, put the optional params at the end.

Plus, it seems like it would be fairly simple to implement. It's always 
seemed like a fairly obvious feature to me.
Oct 29 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Denis Koroskin wrote:

 I once had the following Color class:
 
 class Color
 {
     this (byte alpha, byte red, byte green, byte blue) { ... }
 }
 
 and used it as follows:
 
 Color c = new Color(255, 0, 255, 0); // opaque green color
 
 After refactoring, alpha became last argument in ctor:
 
     this(byte red, byte green, byte blue, byte alpha) { ... }
 
 Note that this change didn't raise any compilation error, nothing that 
 would notify my of possible error.
 
 Needless to say that I didn't enjoy searching all the code that used 
 Color to reorder parameters (although some artifact were nice :)
 It would save me quite some time if I initialized all my instances as 
 follows:
 
 Color c = new Color(alpha: 255, red: 0, green: 255, blue: 0);
 
 Now compiler could raise an error if parameters order was changed. Even 
 better - compiler could reorder parameters for me automatically if given 
 that all of them are specified and no params ommited (unlike Python). 
 This makes code more robust to refactoring.


The first thing  I thought of when reading this is Eclipse JDT's "Change 
Method Signature" refactoring that will look up all the calls in your 
project & automatically reorder the parameters for you.
Oct 29 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Robert Fraser escribió:

 Denis Koroskin wrote:

 I once had the following Color class:

 class Color
 {
     this (byte alpha, byte red, byte green, byte blue) { ... }
 }

 and used it as follows:

 Color c = new Color(255, 0, 255, 0); // opaque green color

 After refactoring, alpha became last argument in ctor:

     this(byte red, byte green, byte blue, byte alpha) { ... }

 Note that this change didn't raise any compilation error, nothing that 
 would notify my of possible error.

 Needless to say that I didn't enjoy searching all the code that used 
 Color to reorder parameters (although some artifact were nice :)
 It would save me quite some time if I initialized all my instances as 
 follows:

 Color c = new Color(alpha: 255, red: 0, green: 255, blue: 0);

 Now compiler could raise an error if parameters order was changed. 
 Even better - compiler could reorder parameters for me automatically 
 if given that all of them are specified and no params ommited (unlike 
 Python). This makes code more robust to refactoring.


 
 The first thing  I thought of when reading this is Eclipse JDT's "Change 
 Method Signature" refactoring that will look up all the calls in your 
 project & automatically reorder the parameters for you.


Me too. :-)
Oct 30 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Ary Borenszweig wrote:

 Robert Fraser escribió:

 Denis Koroskin wrote:

 I once had the following Color class:

 class Color
 {
     this (byte alpha, byte red, byte green, byte blue) { ... }
 }

 and used it as follows:

 Color c = new Color(255, 0, 255, 0); // opaque green color

 After refactoring, alpha became last argument in ctor:

     this(byte red, byte green, byte blue, byte alpha) { ... }

 Note that this change didn't raise any compilation error, nothing 
 that would notify my of possible error.

 Needless to say that I didn't enjoy searching all the code that used 
 Color to reorder parameters (although some artifact were nice :)
 It would save me quite some time if I initialized all my instances as 
 follows:

 Color c = new Color(alpha: 255, red: 0, green: 255, blue: 0);

 Now compiler could raise an error if parameters order was changed. 
 Even better - compiler could reorder parameters for me automatically 
 if given that all of them are specified and no params ommited (unlike 
 Python). This makes code more robust to refactoring.


 The first thing  I thought of when reading this is Eclipse JDT's 
 "Change Method Signature" refactoring that will look up all the calls 
 in your project & automatically reorder the parameters for you.


 
 Me too. :-)


Of course I also ate a piece of that cake. ^^

I keep getting the impression that we 3 are the only people in the D NG 
that have used JDT extensively.
That's unfortunate because I feel most people here don't realize how 
much an IDE like JDT (or something comparable, like IntelliJ IDEA, but 
not VS) can shape and improve the development workflow (and thus have 
potential implications in language design).
And it's not something that can be easily understood in foresight - one 
really has to try it out (rich IDE functionality) for some time and even 
then, you might not notice it until it is *taken* from you. Fun story, 
that happened to me:

When I started looking for work after graduation, recruiters asked me if 

bias (apparently some people do, even in the workplace), so I judged 
both in terms of language only, and I really didn't have much of a 

only). I was slightly inclined to Java, but only because I had used it more.
But months later, when I started working on a project that had a desktop 


Suddenly many of the things I had taken from granted were gone, and I 
missed them a lot more than I expected (one example is the Ctrl-1 
"Assign to Local Variable" refactoring which gradually become one of my 
most used refactoring, almost as much as Refactor-Rename). It was almost 
like going from C to BASIC (when I only knew BASIC, it didn't seem so 
sucky).
It has become so that now that I am searching for other job 


as big, if not bigger, than Java).


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 06 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Bruno Medeiros escribió:

 Ary Borenszweig wrote:

 Robert Fraser escribió:

 Denis Koroskin wrote:

 I once had the following Color class:

 class Color
 {
     this (byte alpha, byte red, byte green, byte blue) { ... }
 }

 and used it as follows:

 Color c = new Color(255, 0, 255, 0); // opaque green color

 After refactoring, alpha became last argument in ctor:

     this(byte red, byte green, byte blue, byte alpha) { ... }

 Note that this change didn't raise any compilation error, nothing 
 that would notify my of possible error.

 Needless to say that I didn't enjoy searching all the code that used 
 Color to reorder parameters (although some artifact were nice :)
 It would save me quite some time if I initialized all my instances 
 as follows:

 Color c = new Color(alpha: 255, red: 0, green: 255, blue: 0);

 Now compiler could raise an error if parameters order was changed. 
 Even better - compiler could reorder parameters for me automatically 
 if given that all of them are specified and no params ommited 
 (unlike Python). This makes code more robust to refactoring.


 The first thing  I thought of when reading this is Eclipse JDT's 
 "Change Method Signature" refactoring that will look up all the calls 
 in your project & automatically reorder the parameters for you.


 Me too. :-)


 
 Of course I also ate a piece of that cake. ^^
 
 I keep getting the impression that we 3 are the only people in the D NG 
 that have used JDT extensively.
 That's unfortunate because I feel most people here don't realize how 
 much an IDE like JDT (or something comparable, like IntelliJ IDEA, but 
 not VS) can shape and improve the development workflow (and thus have 
 potential implications in language design).
 And it's not something that can be easily understood in foresight - one 
 really has to try it out (rich IDE functionality) for some time and even 
 then, you might not notice it until it is *taken* from you. Fun story, 
 that happened to me:
 
 When I started looking for work after graduation, recruiters asked me if 

 bias (apparently some people do, even in the workplace), so I judged 
 both in terms of language only, and I really didn't have much of a 

 only). I was slightly inclined to Java, but only because I had used it 
 more.
 But months later, when I started working on a project that had a desktop 


 Suddenly many of the things I had taken from granted were gone, and I 
 missed them a lot more than I expected (one example is the Ctrl-1 
 "Assign to Local Variable" refactoring which gradually become one of my 
 most used refactoring, almost as much as Refactor-Rename).


I recently discovered you can do the same with Ctrl+2, L :-)

Of course in D that'll be

auto whatever = <your expression here>;

Do here's a clear example where a language helps not being repetitive, 
and that kind of shortcut becomes less useful.

But refactoring is an essential thing in TDD, and I think that can't be 
easily supported by any language without using a proper IDE.

I also have the sensation we are the only guys that used JDT. In my 
workplace everyone feels very, very comfortable using Java; not because 
of the language itself, but because of Eclipse. It's amazing the speed 
boost you get once you get used to it. You don't have to look at 
external documentation files, you don't have to read someone else's code 
to understand what's going on. You don't need to remember lots of names, 
where's everything is located.

But, as Bruno says, you can't really feel it unless you try it.
Nov 06 2008
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
news:gf03qh$23sg$1 digitalmars.com...

 Bruno Medeiros escribió:

 Ary Borenszweig wrote:

 Robert Fraser escribió:

 Denis Koroskin wrote:

 I once had the following Color class:

 class Color
 {
     this (byte alpha, byte red, byte green, byte blue) { ... }
 }

 and used it as follows:

 Color c = new Color(255, 0, 255, 0); // opaque green color

 After refactoring, alpha became last argument in ctor:

     this(byte red, byte green, byte blue, byte alpha) { ... }

 Note that this change didn't raise any compilation error, nothing that 
 would notify my of possible error.

 Needless to say that I didn't enjoy searching all the code that used 
 Color to reorder parameters (although some artifact were nice :)
 It would save me quite some time if I initialized all my instances as 
 follows:

 Color c = new Color(alpha: 255, red: 0, green: 255, blue: 0);

 Now compiler could raise an error if parameters order was changed. 
 Even better - compiler could reorder parameters for me automatically 
 if given that all of them are specified and no params ommited (unlike 
 Python). This makes code more robust to refactoring.


 The first thing  I thought of when reading this is Eclipse JDT's 
 "Change Method Signature" refactoring that will look up all the calls 
 in your project & automatically reorder the parameters for you.


 Me too. :-)


 Of course I also ate a piece of that cake. ^^

 I keep getting the impression that we 3 are the only people in the D NG 
 that have used JDT extensively.
 That's unfortunate because I feel most people here don't realize how much 
 an IDE like JDT (or something comparable, like IntelliJ IDEA, but not VS) 
 can shape and improve the development workflow (and thus have potential 
 implications in language design).
 And it's not something that can be easily understood in foresight - one 
 really has to try it out (rich IDE functionality) for some time and even 
 then, you might not notice it until it is *taken* from you. Fun story, 
 that happened to me:

 When I started looking for work after graduation, recruiters asked me if 

 bias (apparently some people do, even in the workplace), so I judged both 
 in terms of language only, and I really didn't have much of a preference 

 slightly inclined to Java, but only because I had used it more.
 But months later, when I started working on a project that had a desktop 


 Suddenly many of the things I had taken from granted were gone, and I 
 missed them a lot more than I expected (one example is the Ctrl-1 "Assign 
 to Local Variable" refactoring which gradually become one of my most used 
 refactoring, almost as much as Refactor-Rename).


 I recently discovered you can do the same with Ctrl+2, L :-)

 Of course in D that'll be

 auto whatever = <your expression here>;

 Do here's a clear example where a language helps not being repetitive, and 
 that kind of shortcut becomes less useful.

 But refactoring is an essential thing in TDD, and I think that can't be 
 easily supported by any language without using a proper IDE.

 I also have the sensation we are the only guys that used JDT. In my 
 workplace everyone feels very, very comfortable using Java; not because of 
 the language itself, but because of Eclipse. It's amazing the speed boost 
 you get once you get used to it. You don't have to look at external 
 documentation files, you don't have to read someone else's code to 
 understand what's going on. You don't need to remember lots of names, 
 where's everything is located.

 But, as Bruno says, you can't really feel it unless you try it.


I used Eclipse constantly back when I was working with Java (before I 

from version 5 through the early .NET versions. But ever since leaving Java, 
I've been finding myself deliberately avoiding Eclipse just because I'd much 
rather use an IDE that's responsive (and not so heavly Java-centric) than 
one that has a few extra bells and whistles. Don't get me wrong, I love IDE 
bells and whistles (that's why I used to be such a Visual Studio fan, and 
used Eclipse when I switched to Java), but when trying to interact with the 
IDE starts to feel like running through knee-deep molasses, as it frequently 
does with Eclipse, it's just not worth it to me.
Nov 06 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Nick Sabalausky wrote:

 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
 news:gf03qh$23sg$1 digitalmars.com...

 Bruno Medeiros escribió:

 Ary Borenszweig wrote:

 Robert Fraser escribió:

 Denis Koroskin wrote:

 I once had the following Color class:

 class Color
 {
     this (byte alpha, byte red, byte green, byte blue) { ... }
 }

 and used it as follows:

 Color c = new Color(255, 0, 255, 0); // opaque green color

 After refactoring, alpha became last argument in ctor:

     this(byte red, byte green, byte blue, byte alpha) { ... }

 Note that this change didn't raise any compilation error, nothing that 
 would notify my of possible error.

 Needless to say that I didn't enjoy searching all the code that used 
 Color to reorder parameters (although some artifact were nice :)
 It would save me quite some time if I initialized all my instances as 
 follows:

 Color c = new Color(alpha: 255, red: 0, green: 255, blue: 0);

 Now compiler could raise an error if parameters order was changed. 
 Even better - compiler could reorder parameters for me automatically 
 if given that all of them are specified and no params ommited (unlike 
 Python). This makes code more robust to refactoring.


 The first thing  I thought of when reading this is Eclipse JDT's 
 "Change Method Signature" refactoring that will look up all the calls 
 in your project & automatically reorder the parameters for you.


 Me too. :-)


 Of course I also ate a piece of that cake. ^^

 I keep getting the impression that we 3 are the only people in the D NG 
 that have used JDT extensively.
 That's unfortunate because I feel most people here don't realize how much 
 an IDE like JDT (or something comparable, like IntelliJ IDEA, but not VS) 
 can shape and improve the development workflow (and thus have potential 
 implications in language design).
 And it's not something that can be easily understood in foresight - one 
 really has to try it out (rich IDE functionality) for some time and even 
 then, you might not notice it until it is *taken* from you. Fun story, 
 that happened to me:

 When I started looking for work after graduation, recruiters asked me if 

 bias (apparently some people do, even in the workplace), so I judged both 
 in terms of language only, and I really didn't have much of a preference 

 slightly inclined to Java, but only because I had used it more.
 But months later, when I started working on a project that had a desktop 


 Suddenly many of the things I had taken from granted were gone, and I 
 missed them a lot more than I expected (one example is the Ctrl-1 "Assign 
 to Local Variable" refactoring which gradually become one of my most used 
 refactoring, almost as much as Refactor-Rename).


 I recently discovered you can do the same with Ctrl+2, L :-)

 Of course in D that'll be

 auto whatever = <your expression here>;

 Do here's a clear example where a language helps not being repetitive, and 
 that kind of shortcut becomes less useful.

 But refactoring is an essential thing in TDD, and I think that can't be 
 easily supported by any language without using a proper IDE.

 I also have the sensation we are the only guys that used JDT. In my 
 workplace everyone feels very, very comfortable using Java; not because of 
 the language itself, but because of Eclipse. It's amazing the speed boost 
 you get once you get used to it. You don't have to look at external 
 documentation files, you don't have to read someone else's code to 
 understand what's going on. You don't need to remember lots of names, 
 where's everything is located.

 But, as Bruno says, you can't really feel it unless you try it.


 
 I used Eclipse constantly back when I was working with Java (before I 

 from version 5 through the early .NET versions. But ever since leaving Java, 
 I've been finding myself deliberately avoiding Eclipse just because I'd much 
 rather use an IDE that's responsive (and not so heavly Java-centric) than 
 one that has a few extra bells and whistles. Don't get me wrong, I love IDE 
 bells and whistles (that's why I used to be such a Visual Studio fan, and 
 used Eclipse when I switched to Java), but when trying to interact with the 
 IDE starts to feel like running through knee-deep molasses, as it frequently 
 does with Eclipse, it's just not worth it to me. 
 
 


Well, I'm not sure if that was your case, but if we are talking web 
development (something I did in my job), then the Java web development 
component of Eclipse (WTP, which extends JDT), is noticeably slow and 
somewhat unstable on several parts. It really isn't up to par to basic 
JDT, which is much more mature, although WTP has been improving lately. 



-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 07 2008
parent "Nick Sabalausky" <a a.a> writes:
"Bruno Medeiros" <brunodomedeiros+spam com.gmail> wrote in message 
news:gf1tci$2s5o$1 digitalmars.com...

 Nick Sabalausky wrote:

 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
 news:gf03qh$23sg$1 digitalmars.com...

 Bruno Medeiros escribió:

 Ary Borenszweig wrote:

 Robert Fraser escribió:

 Denis Koroskin wrote:

 I once had the following Color class:

 class Color
 {
     this (byte alpha, byte red, byte green, byte blue) { ... }
 }

 and used it as follows:

 Color c = new Color(255, 0, 255, 0); // opaque green color

 After refactoring, alpha became last argument in ctor:

     this(byte red, byte green, byte blue, byte alpha) { ... }

 Note that this change didn't raise any compilation error, nothing 
 that would notify my of possible error.

 Needless to say that I didn't enjoy searching all the code that used 
 Color to reorder parameters (although some artifact were nice :)
 It would save me quite some time if I initialized all my instances 
 as follows:

 Color c = new Color(alpha: 255, red: 0, green: 255, blue: 0);

 Now compiler could raise an error if parameters order was changed. 
 Even better - compiler could reorder parameters for me automatically 
 if given that all of them are specified and no params ommited 
 (unlike Python). This makes code more robust to refactoring.


 The first thing  I thought of when reading this is Eclipse JDT's 
 "Change Method Signature" refactoring that will look up all the calls 
 in your project & automatically reorder the parameters for you.


 Me too. :-)


 Of course I also ate a piece of that cake. ^^

 I keep getting the impression that we 3 are the only people in the D NG 
 that have used JDT extensively.
 That's unfortunate because I feel most people here don't realize how 
 much an IDE like JDT (or something comparable, like IntelliJ IDEA, but 
 not VS) can shape and improve the development workflow (and thus have 
 potential implications in language design).
 And it's not something that can be easily understood in foresight - one 
 really has to try it out (rich IDE functionality) for some time and 
 even then, you might not notice it until it is *taken* from you. Fun 
 story, that happened to me:

 When I started looking for work after graduation, recruiters asked me 

 anti-Microsoft bias (apparently some people do, even in the workplace), 
 so I judged both in terms of language only, and I really didn't have 

 version 2.0 only). I was slightly inclined to Java, but only because I 
 had used it more.
 But months later, when I started working on a project that had a 


 comparison. Suddenly many of the things I had taken from granted were 
 gone, and I missed them a lot more than I expected (one example is the 
 Ctrl-1 "Assign to Local Variable" refactoring which gradually become 
 one of my most used refactoring, almost as much as Refactor-Rename).


 I recently discovered you can do the same with Ctrl+2, L :-)

 Of course in D that'll be

 auto whatever = <your expression here>;

 Do here's a clear example where a language helps not being repetitive, 
 and that kind of shortcut becomes less useful.

 But refactoring is an essential thing in TDD, and I think that can't be 
 easily supported by any language without using a proper IDE.

 I also have the sensation we are the only guys that used JDT. In my 
 workplace everyone feels very, very comfortable using Java; not because 
 of the language itself, but because of Eclipse. It's amazing the speed 
 boost you get once you get used to it. You don't have to look at 
 external documentation files, you don't have to read someone else's code 
 to understand what's going on. You don't need to remember lots of names, 
 where's everything is located.

 But, as Bruno says, you can't really feel it unless you try it.


 I used Eclipse constantly back when I was working with Java (before I 

 fan from version 5 through the early .NET versions. But ever since 
 leaving Java, I've been finding myself deliberately avoiding Eclipse just 
 because I'd much rather use an IDE that's responsive (and not so heavly 
 Java-centric) than one that has a few extra bells and whistles. Don't get 
 me wrong, I love IDE bells and whistles (that's why I used to be such a 
 Visual Studio fan, and used Eclipse when I switched to Java), but when 
 trying to interact with the IDE starts to feel like running through 
 knee-deep molasses, as it frequently does with Eclipse, it's just not 
 worth it to me.


 Well, I'm not sure if that was your case, but if we are talking web 
 development (something I did in my job), then the Java web development 
 component of Eclipse (WTP, which extends JDT), is noticeably slow and 
 somewhat unstable on several parts. It really isn't up to par to basic 
 JDT, which is much more mature, although WTP has been improving lately. I 




I've done a lot of web work, but none of the Java work I've done was web (at 
least not server-side anyway). The was just normal ordinary Java 
applications, command-line and GUI, and the occasional embedded applet. The 
.NET versions of Visual Studio have, unfortunately, been getting 
increasingly boated, but in my experience, Eclipse is still more boated. 
Although, I can't say much about Visual Studio's web stuff. The last time I 
used Visual Studio for web, it was still called InterDev.
Nov 07 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Ary Borenszweig wrote:

 Bruno Medeiros escribió:

 Ary Borenszweig wrote:

 Robert Fraser escribió:

 Denis Koroskin wrote:

 I once had the following Color class:

 class Color
 {
     this (byte alpha, byte red, byte green, byte blue) { ... }
 }

 and used it as follows:

 Color c = new Color(255, 0, 255, 0); // opaque green color

 After refactoring, alpha became last argument in ctor:

     this(byte red, byte green, byte blue, byte alpha) { ... }

 Note that this change didn't raise any compilation error, nothing 
 that would notify my of possible error.

 Needless to say that I didn't enjoy searching all the code that 
 used Color to reorder parameters (although some artifact were nice :)
 It would save me quite some time if I initialized all my instances 
 as follows:

 Color c = new Color(alpha: 255, red: 0, green: 255, blue: 0);

 Now compiler could raise an error if parameters order was changed. 
 Even better - compiler could reorder parameters for me 
 automatically if given that all of them are specified and no params 
 ommited (unlike Python). This makes code more robust to refactoring.


 The first thing  I thought of when reading this is Eclipse JDT's 
 "Change Method Signature" refactoring that will look up all the 
 calls in your project & automatically reorder the parameters for you.


 Me too. :-)


 Of course I also ate a piece of that cake. ^^

 I keep getting the impression that we 3 are the only people in the D 
 NG that have used JDT extensively.
 That's unfortunate because I feel most people here don't realize how 
 much an IDE like JDT (or something comparable, like IntelliJ IDEA, but 
 not VS) can shape and improve the development workflow (and thus have 
 potential implications in language design).
 And it's not something that can be easily understood in foresight - 
 one really has to try it out (rich IDE functionality) for some time 
 and even then, you might not notice it until it is *taken* from you. 
 Fun story, that happened to me:

 When I started looking for work after graduation, recruiters asked me 

 anti-Microsoft bias (apparently some people do, even in the 
 workplace), so I judged both in terms of language only, and I really 

 only up to version 2.0 only). I was slightly inclined to Java, but 
 only because I had used it more.
 But months later, when I started working on a project that had a 


 comparison. Suddenly many of the things I had taken from granted were 
 gone, and I missed them a lot more than I expected (one example is the 
 Ctrl-1 "Assign to Local Variable" refactoring which gradually become 
 one of my most used refactoring, almost as much as Refactor-Rename).


 
 I recently discovered you can do the same with Ctrl+2, L :-)
 
 Of course in D that'll be
 
 auto whatever = <your expression here>;
 
 Do here's a clear example where a language helps not being repetitive, 
 and that kind of shortcut becomes less useful.
 
 But refactoring is an essential thing in TDD, and I think that can't be 
 easily supported by any language without using a proper IDE.
 
 I also have the sensation we are the only guys that used JDT. In my 
 workplace everyone feels very, very comfortable using Java; not because 
 of the language itself, but because of Eclipse. It's amazing the speed 
 boost you get once you get used to it. You don't have to look at 
 external documentation files, you don't have to read someone else's code 
 to understand what's going on. You don't need to remember lots of names, 
 where's everything is located.
 


"you don't have to read someone else's code to understand what's going 
on." - Hum, I agree with the rest of what you said, but not necessarily 
on this one. In fact I do a lot of "browsing" with Eclipse (Ctrl-click, 
Open Type, etc.), in order to read other's code.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 07 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Bruno Medeiros wrote:

 Ary Borenszweig wrote:

 Robert Fraser escribió:

 Denis Koroskin wrote:

 I once had the following Color class:

 class Color
 {
     this (byte alpha, byte red, byte green, byte blue) { ... }
 }

 and used it as follows:

 Color c = new Color(255, 0, 255, 0); // opaque green color

 After refactoring, alpha became last argument in ctor:

     this(byte red, byte green, byte blue, byte alpha) { ... }

 Note that this change didn't raise any compilation error, nothing 
 that would notify my of possible error.

 Needless to say that I didn't enjoy searching all the code that used 
 Color to reorder parameters (although some artifact were nice :)
 It would save me quite some time if I initialized all my instances 
 as follows:

 Color c = new Color(alpha: 255, red: 0, green: 255, blue: 0);

 Now compiler could raise an error if parameters order was changed. 
 Even better - compiler could reorder parameters for me automatically 
 if given that all of them are specified and no params ommited 
 (unlike Python). This makes code more robust to refactoring.


 The first thing  I thought of when reading this is Eclipse JDT's 
 "Change Method Signature" refactoring that will look up all the calls 
 in your project & automatically reorder the parameters for you.


 Me too. :-)


 
 Of course I also ate a piece of that cake. ^^
 
 I keep getting the impression that we 3 are the only people in the D NG 
 that have used JDT extensively.
 That's unfortunate because I feel most people here don't realize how 
 much an IDE like JDT (or something comparable, like IntelliJ IDEA, but 
 not VS) can shape and improve the development workflow (and thus have 
 potential implications in language design).


I haven't used JDT very much -- I can't stand the standard library in 
Java, so I try to avoid it.

I've used Visual Studio with Resharper. From what I've seen, Resharper 
is much better than JDT. It might just be a matter of default 
configurations, but that's still a strong advantage.

Still, Resharper costs $250 on top of the cost of Visual Studio, and it 
won't work with the free versions of VS.


faster when working with Resharper. Enough so that if Resharper is not 
functioning, getting it in working order is my top priority.
Nov 07 2008
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:ge9sf5$1vdc$1 digitalmars.com...

 Thanks to Reddit I have found a nice short document that lists some of the 

 https://docs.google.com/View?docid=dcj4xk6_17ffc7nmgv

 They have added a dynamic invocation, useful if you want to implement a 
 dynamic language (like IronPython, IronRuby, etc) on top of the dotnet. 
 Object-C shows this is doable in a very C-like language, and the Boo 
 language shows that in a statically typed language it can be useful to use 
 a Duck type once in a while to reduce the "static type pressure". More 
 info on this last concept in the Boo site.

 Something that I like a lot is the named arguments, that I hope to see in 
 D and Delight someday. They are used often in Python, and they help 
 increase the readability of the code, sometimes even reducing mistakes.
 They have used colons:
 foo(x: 1, z: 3)
 While Python uses equal signs:
 foo(x=1, z=3)
 I think they are about equally readable.
 (I think there's a problem with named arguments, that you can solve in 
 some ways, for example with an extra hidden bitfield argument that encodes 
 what arguments are given and what not).

 Bye,
 bearophile


I'm dissapointed...but not surprised. Looks like the templates are still 
gimped: I don't see anything about an IArithmetic or operator constraints.

I'm also dissapointed with the focus on dynamic programming as I've really 
never seen much need for such a thing in a static language (or in any 
language, IMO). Most people experienced with static typing are probably well 
aware of the pitfalls dynamic typing introduces, so I won't point them out. 
And as far as I've seen, the only benefits that can't already be achieved 
just fine through templates or boxing are just incredibly trivial things 
like not creating an extra variable to hold the string equivilant of one of 
your ints.
Oct 29 2008
parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Oct 29, 2008 at 5:14 PM, Nick Sabalausky <a a.a> wrote:

 And as far as I've seen, the only benefits that can't already be achieved
 just fine through templates or boxing are just incredibly trivial things
 like not creating an extra variable to hold the string equivilant of one of
 your ints.


Er - "holding the string equivalent of an int"?  Which are you arguing
against, then: dynamic typing or weak typing?  They are two separate
axes of typing systems that are often erroneously conflated..

If you're arguing against weak typing - that is, providing loopholes
in the typing system by means of implicit conversions that exist for
no other purpose than convenience - I am with you 100%.  Weak typing
is an absolute abomination that does not deserve to belong in any
language that is to be used as more than a toy.

But if you're arguing against dynamic typing, or more generally
dynamic object manipulation, I'm not sure I'd agree.  Dynamic typing
does have some very nice use cases - RPC (without having to
dynamically generate and compile statically-typed code), database
interaction, GUIs (see obj-c), interaction with other
dynamically-typed languages, etc.  Having either dynamic or static
typing just makes emulating the other a pain or impossible.  Having
both gives you the best of both worlds.
Oct 29 2008
prev sibling next sibling parent digited <digited yandex.ru> writes:
+1 for named arguments
Oct 29 2008
prev sibling next sibling parent reply Janderson <ask me.com> writes:
bearophile wrote:

 Thanks to Reddit I have found a nice short document that lists some of the

 https://docs.google.com/View?docid=dcj4xk6_17ffc7nmgv
 
 They have added a dynamic invocation, useful if you want to implement a
dynamic language (like IronPython, IronRuby, etc) on top of the dotnet.
Object-C shows this is doable in a very C-like language, and the Boo language
shows that in a statically typed language it can be useful to use a Duck type
once in a while to reduce the "static type pressure". More info on this last
concept in the Boo site.
 
 Something that I like a lot is the named arguments, that I hope to see in D
and Delight someday. They are used often in Python, and they help increase the
readability of the code, sometimes even reducing mistakes.
 They have used colons:
 foo(x: 1, z: 3)
 While Python uses equal signs:
 foo(x=1, z=3)
 I think they are about equally readable.
 (I think there's a problem with named arguments, that you can solve in some
ways, for example with an extra hidden bitfield argument that encodes what
arguments are given and what not).
 
 Bye,
 bearophile


It would be nice if this worked with structs as parameters as well:

struct X
{
	int a;
	int b;
}


foo(X x)
{

}

foo(x.a = 10, x.b = 20);
Oct 30 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Janderson:

 It would be nice if this worked with structs as parameters as well:
 
 struct X {
 	int a;
 	int b;
 }
 foo(X x) { }
 foo(x.a = 10, x.b = 20);


At the moment you can do:
foo(X(10, 20));

The docs say: "Struct literals are syntactically like function calls."
So if function calls gain the named arguments, then later you can probably
write:
foo(X(b: 20, a: 10));

Bye,
bearophile
Oct 30 2008
prev sibling next sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
bearophile wrote:

 Thanks to Reddit I have found a nice short document that lists some of the

 https://docs.google.com/View?docid=dcj4xk6_17ffc7nmgv
 


Hum, interesting how they tackled the covariance/contravariance problem 
in generics parameters. It's not as powerful as Java's generics (in Java 
you can have covariance and contravariance in a List-like interface), 
but it's also quite simpler, so it's an interesting compromise.

Hum, I wonder if we can implement a system anywhere like Java's generics 
in D. Could be possible, when we have opImplicitCast.


 They have added a dynamic invocation, useful if you want to implement a
dynamic language (like IronPython, IronRuby, etc) on top of the dotnet.
Object-C shows this is doable in a very C-like language, and the Boo language
shows that in a statically typed language it can be useful to use a Duck type
once in a while to reduce the "static type pressure". More info on this last
concept in the Boo site.
 


I'm usually quite a fan of hard, disciplined, static typing, but it's an 
interesting idea nonetheless. Wonder if it would be worth putting into D.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 07 2008
prev sibling parent "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
The nestable object literal syntax obsoletes some cases where constructutors 
were used before, and where named arguments would be used, but clearly not 
all (deterministic initialization) - it can be used to initialize properties 
via new Person() { First = "Bob", Last = "Smith" }; I can't remember the 
exact syntax.

- Bent

"bearophile" <bearophileHUGS lycos.com> skrev i meddelelsen 
news:ge9sf5$1vdc$1 digitalmars.com...

 Thanks to Reddit I have found a nice short document that lists some of the 

 https://docs.google.com/View?docid=dcj4xk6_17ffc7nmgv

 They have added a dynamic invocation, useful if you want to implement a 
 dynamic language (like IronPython, IronRuby, etc) on top of the dotnet. 
 Object-C shows this is doable in a very C-like language, and the Boo 
 language shows that in a statically typed language it can be useful to use 
 a Duck type once in a while to reduce the "static type pressure". More 
 info on this last concept in the Boo site.

 Something that I like a lot is the named arguments, that I hope to see in 
 D and Delight someday. They are used often in Python, and they help 
 increase the readability of the code, sometimes even reducing mistakes.
 They have used colons:
 foo(x: 1, z: 3)
 While Python uses equal signs:
 foo(x=1, z=3)
 I think they are about equally readable.
 (I think there's a problem with named arguments, that you can solve in 
 some ways, for example with an extra hidden bitfield argument that encodes 
 what arguments are given and what not).

 Bye,
 bearophile
Nov 10 2008