www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Dart and D: features that could be used in D,

reply Timothee Cour <thelastmammoth gmail.com> writes:
A1)
Google's Dart (https://www.dartlang.org) looks like a very promising
replacement for javascript. It can compile to javascript to ensure
portability (but chromium runs it natively) but the language itself reminds
more of D to a surprising extent. Dart language has features such as:


static typing (but can also have dynamic typing, akin to std.variant, with
better support/syntax than D)
ahead of time compilation
unicode support
built in serialization/deserialization via json
annotations
mixins (used to emulate multiple inheritance)
generics
vector/AA litterals
alias (called typedef in dart), is, assert
try/catch/finally
operator overloading
properties (same parenthesis-less caller syntax as in D)
delegates (called closures)
nesting functions, 1st class functions, lambda => syntax
DDOC (called dartdoc)
D-like syntax and nesting comments,
introspection (runtime only AFAIK)

A2)
Also features that would be nice to have in D or were better designed than
in D:

* cascade operations: they perform a series of operations on the members of
a single object:
foo.bar(1)..baz(3)
equivalent to:
foo.bar(1)
foo.baz(3)

* better way to define default constructors:
class Point {
  num x;
  num y;
  num z;
  // Syntactic sugar for setting z and x before the constructor body runs.
  Point(this.z, this.x){...}
}
This is more explicit and flexible than D's way for default struct
constructors, which can only allow to set all fields in order, without
skipping some, and doesn't allow to do anything else in the ctor.

* named constructors

* distinguish integer divide (~/) vs divide (/), so that 5/2=2, 5~/2=2

* shorthand function declaration with => (used not just for lambdas)

* for (var x in collection) //better syntax than foreach(var;collection)

* better syntax for optional positional arguments:
void fun(int x, [int y, int z=3]){...}
Thinking of which, this would actually solve a long standing problem in D,
that of specifying optional parameters AFTER a variadic template:
void fun(T...)(T args, [string file=__FILE__,int line=__LINE__]){...}

* export for libraries

* async/wait etc

* great IDE/debugger/package manager/static analyzer

also the following which I've previously proposed adding to D:

* string interpolation $variableName (or ${expression})
assert('foo. ${s.toUpperCase()} bar' == 'foo. STRING INTERPOLATION bar');

* optional named parameters arguments (with simplest possible syntax)

* import all except specified symbols:
import 'package:lib2/lib2.dart' hide foo; // Import all names EXCEPT foo.

A3)
And then some design decisions which wouldn't work for D: everything is an
object, no struct (just class), VM, etc.

A4)
there were may previous threads regarding using D on the web via compiling
to javascript. In light of this it would seem a lot easier to compile D to
dart.
Feb 27 2014
next sibling parent "Suliman" <evermind live.ru> writes:
What needed to create language that can be run everywhere? I mean 
would it be hard to add support of running D code in web-browser?

it's better to write all logic at one language, that on 2 or 3.
Feb 27 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Timothee Cour:


 * better way to define default constructors:
 class Point {
   num x;
   num y;
   num z;
   // Syntactic sugar for setting z and x before the constructor 
 body runs.
   Point(this.z, this.x){...}
 }
 This is more explicit and flexible than D's way for default 
 struct
 constructors, which can only allow to set all fields in order, 
 without
 skipping some, and doesn't allow to do anything else in the 
 ctor.


A variant of this idea was discussed, and I think it's a good 
idea.



 * distinguish integer divide (~/) vs divide (/), so that 5/2=2, 
 5~/2=2

 * shorthand function declaration with => (used not just for 
 lambdas)


Both good. But for the first you need a different syntax in D.



 * optional named parameters arguments (with simplest possible 
 syntax)

 * import all except specified symbols:
 import 'package:lib2/lib2.dart' hide foo; // Import all names 
 EXCEPT foo.


Probably both good, if well designed.

Bye,
bearophile
Feb 27 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
I don't like any of the syntax changes mentioned. I do like the 
suggestions for better IDEs and similar tools. We can always do 
more to improve these.
Feb 27 2014
prev sibling next sibling parent "Asman01" <jckj33 gmail.com> writes:
On Thursday, 27 February 2014 at 10:27:41 UTC, Timothee Cour 
wrote:

 A1)
 Google's Dart (https://www.dartlang.org) looks like a very 
 promising
 replacement for javascript. It can compile to javascript to 
 ensure
 portability (but chromium runs it natively) but the language 
 itself reminds
 more of D to a surprising extent. Dart language has features 
 such as:


 static typing (but can also have dynamic typing, akin to 
 std.variant, with
 better support/syntax than D)
 ahead of time compilation
 unicode support
 built in serialization/deserialization via json
 annotations
 mixins (used to emulate multiple inheritance)
 generics
 vector/AA litterals
 alias (called typedef in dart), is, assert
 try/catch/finally
 operator overloading
 properties (same parenthesis-less caller syntax as in D)
 delegates (called closures)
 nesting functions, 1st class functions, lambda => syntax
 DDOC (called dartdoc)
 D-like syntax and nesting comments,
 introspection (runtime only AFAIK)

 A2)
 Also features that would be nice to have in D or were better 
 designed than
 in D:

 * cascade operations: they perform a series of operations on 
 the members of
 a single object:
 foo.bar(1)..baz(3)
 equivalent to:
 foo.bar(1)
 foo.baz(3)

 * better way to define default constructors:
 class Point {
   num x;
   num y;
   num z;
   // Syntactic sugar for setting z and x before the constructor 
 body runs.
   Point(this.z, this.x){...}
 }
 This is more explicit and flexible than D's way for default 
 struct
 constructors, which can only allow to set all fields in order, 
 without
 skipping some, and doesn't allow to do anything else in the 
 ctor.

 * named constructors

 * distinguish integer divide (~/) vs divide (/), so that 5/2=2, 
 5~/2=2

 * shorthand function declaration with => (used not just for 
 lambdas)

 * for (var x in collection) //better syntax than 
 foreach(var;collection)

 * better syntax for optional positional arguments:
 void fun(int x, [int y, int z=3]){...}
 Thinking of which, this would actually solve a long standing 
 problem in D,
 that of specifying optional parameters AFTER a variadic 
 template:
 void fun(T...)(T args, [string file=__FILE__,int 
 line=__LINE__]){...}

 * export for libraries

 * async/wait etc

 * great IDE/debugger/package manager/static analyzer

 also the following which I've previously proposed adding to D:

 * string interpolation $variableName (or ${expression})
 assert('foo. ${s.toUpperCase()} bar' == 'foo. STRING 
 INTERPOLATION bar');

 * optional named parameters arguments (with simplest possible 
 syntax)

 * import all except specified symbols:
 import 'package:lib2/lib2.dart' hide foo; // Import all names 
 EXCEPT foo.

 A3)
 And then some design decisions which wouldn't work for D: 
 everything is an
 object, no struct (just class), VM, etc.

 A4)
 there were may previous threads regarding using D on the web 
 via compiling
 to javascript. In light of this it would seem a lot easier to 
 compile D to
 dart.



I've hear that Microsoft's equivalent so-called TypeScript was 
more successfully than Google's one, more people like much more 
TypeScript syntax and features, like I do.
Feb 27 2014
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 2/27/14, 7:19 AM, Timothee Cour wrote:

 And then some design decisions which wouldn't work for D: everything is
 an object, no struct (just class), VM, etc.


In a programming language you can make everything look like an object 
but implement it as a primitive type. So that could work in D (but I 
think nobody would like it, although it can make the language much simpler).
Feb 27 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 27.02.2014 17:48, schrieb Ary Borenszweig:

 On 2/27/14, 7:19 AM, Timothee Cour wrote:

 And then some design decisions which wouldn't work for D: everything is
 an object, no struct (just class), VM, etc.


 In a programming language you can make everything look like an object
 but implement it as a primitive type. So that could work in D (but I
 think nobody would like it, although it can make the language much
 simpler).


Yep, that is how for example .NET, Eiffel, Smalltalk, Lisp and many 
other languages work.
Feb 27 2014
parent reply "Bienlein" <jeti789 web.de> writes:
On Thursday, 27 February 2014 at 17:16:54 UTC, Paulo Pinto wrote:

 Yep, that is how for example .NET, Eiffel, Smalltalk, Lisp and 
 many other languages work.


An object in Smalltalk is not a primitive type. Even ints, 
floats, chars, etc. in Smalltalk are no primitive types but 
objects. Not wanting to be a rogue. Just pointing out ;-).
Feb 28 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 28.02.2014 13:15, schrieb Bienlein:

 On Thursday, 27 February 2014 at 17:16:54 UTC, Paulo Pinto wrote:

 Yep, that is how for example .NET, Eiffel, Smalltalk, Lisp and many
 other languages work.


 An object in Smalltalk is not a primitive type. Even ints, floats,
 chars, etc. in Smalltalk are no primitive types but objects. Not wanting
 to be a rogue. Just pointing out ;-).


Yes they are, kind of, because the ones small enough to fit in 
registers, like SmallInteger are converted to primitive types by the JIT.

The programmer cannot see it, because it is considered an implementation 
detail, likewise in the other environments I mentioned.

--
Paulo
Feb 28 2014
prev sibling next sibling parent reply "thedeemon" <dlang thedeemon.com> writes:
On Thursday, 27 February 2014 at 10:27:41 UTC, Timothee Cour 
wrote:

 A1)
 Google's Dart (https://www.dartlang.org) looks like a very 
 promising
 replacement for javascript. It can compile to javascript to 
 ensure
 portability (but chromium runs it natively)


No, neither Chromium nor even Chrome run it natively. Only 
Dartium which is a separate browser.



 * cascade operations: they perform a series of operations on 
 the members of a single object:
 foo.bar(1)..baz(3)
 equivalent to:
 foo.bar(1)
 foo.baz(3)


In D we can use
with(foo) { bar(1); bar(3); }
Pretty close.

Dart looks like a very nice language for front-end web 
development indeed. If I was doing web-dev I would choose vibe.d 
+ Dart combo.

Some features like its constructors and short form of methods I 
would love to see in D too.

As for compiling D to Dart I'm not sure that's feasible. You'll 
have to chop off lower half of it.
Feb 27 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 27.02.2014 18:29, schrieb thedeemon:

 On Thursday, 27 February 2014 at 10:27:41 UTC, Timothee Cour wrote:

 A1)
 Google's Dart (https://www.dartlang.org) looks like a very promising
 replacement for javascript. It can compile to javascript to ensure
 portability (but chromium runs it natively)


 No, neither Chromium nor even Chrome run it natively. Only Dartium which
 is a separate browser.


 From what I understood on Dart talks last Google IO, work was planned 
to have V8 and Dart VM play together inside Chrome.

Personally, I think unless Google pushes the language fro ChromeOS or 
Android, it will hardly get any real market size.

Like it or not, JavaScript is good enough.

On my field of work, it doesn't matter how many cool languages I know,
we are usually bound by what the whole team is comfortable using, what 
the boss allows for and the technologies that are requested by the 
customers themselves.

--
Paulo
Feb 27 2014
next sibling parent reply "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto wrote:
clip

 Like it or not, JavaScript is good enough.


Really? I've been stuck for the past week or so trying to put 
together a browser based UI using JavaScript + HTML for a work 
related project.  It has been a painful experience. In fairness 
to JavaScript, I didn't know the language very well coming in, 
but still I've found working in this setting rather frustrating.

If the future of applications is really client-server based 
applications, where the client is basically a VM (if we consider 
the browser a VM of sorts) surely there is room for a better 
development model than this HTML + Javascript mongrel.
Feb 27 2014
next sibling parent reply "w0rp" <devw0rp gmail.com> writes:
On Thursday, 27 February 2014 at 18:37:51 UTC, Craig Dillabaugh 
wrote:

 On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto 
 wrote:
 clip

 Like it or not, JavaScript is good enough.


 Really? I've been stuck for the past week or so trying to put 
 together a browser based UI using JavaScript + HTML for a work 
 related project.  It has been a painful experience. In fairness 
 to JavaScript, I didn't know the language very well coming in, 
 but still I've found working in this setting rather frustrating.

 If the future of applications is really client-server based 
 applications, where the client is basically a VM (if we 
 consider the browser a VM of sorts) surely there is room for a 
 better development model than this HTML + Javascript mongrel.


I developed 99% of the JavaScript part of an application for a 
year, and I have extensive JavaScript knowledge. After all that, 
I wrote this. https://w0rp.com/blog/post/javascript-sucks/
Feb 27 2014
next sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Thursday, 27 February 2014 at 19:54:04 UTC, w0rp wrote:

 On Thursday, 27 February 2014 at 18:37:51 UTC, Craig Dillabaugh 
 wrote:

 On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto 
 wrote:
 clip

 Like it or not, JavaScript is good enough.


 Really? I've been stuck for the past week or so trying to put 
 together a browser based UI using JavaScript + HTML for a work 
 related project.  It has been a painful experience. In 
 fairness to JavaScript, I didn't know the language very well 
 coming in, but still I've found working in this setting rather 
 frustrating.

 If the future of applications is really client-server based 
 applications, where the client is basically a VM (if we 
 consider the browser a VM of sorts) surely there is room for a 
 better development model than this HTML + Javascript mongrel.


 I developed 99% of the JavaScript part of an application for a 
 year, and I have extensive JavaScript knowledge. After all 
 that, I wrote this. https://w0rp.com/blog/post/javascript-sucks/


Great.  Now I have something to go an read for laughs whenever I 
feel my blood-pressure exceeding safe limits :o)
Feb 27 2014
prev sibling next sibling parent Martin Drasar <drasar ics.muni.cz> writes:
On 27.2.2014 20:54, w0rp wrote:

 I developed 99% of the JavaScript part of an application for a year, and
 I have extensive JavaScript knowledge. After all that, I wrote this.
 https://w0rp.com/blog/post/javascript-sucks/


I think it was someone on Slashdot who posted this wonderful comment:

"JavaScript is a crap language that can't be fixed. If they ever add an
honest garbage collector to the base language then most programs will
delete themselves upon execution."
Feb 27 2014
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 27 February 2014 at 19:54:04 UTC, w0rp wrote:

 On Thursday, 27 February 2014 at 18:37:51 UTC, Craig Dillabaugh 
 wrote:

 On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto 
 wrote:
 clip

 Like it or not, JavaScript is good enough.


 Really? I've been stuck for the past week or so trying to put 
 together a browser based UI using JavaScript + HTML for a work 
 related project.  It has been a painful experience. In 
 fairness to JavaScript, I didn't know the language very well 
 coming in, but still I've found working in this setting rather 
 frustrating.

 If the future of applications is really client-server based 
 applications, where the client is basically a VM (if we 
 consider the browser a VM of sorts) surely there is room for a 
 better development model than this HTML + Javascript mongrel.


 I developed 99% of the JavaScript part of an application for a 
 year, and I have extensive JavaScript knowledge. After all 
 that, I wrote this. https://w0rp.com/blog/post/javascript-sucks/


 Craig&w0rp

I really do understand yeez. Really. At the moment I'm working 
with JS (again). Nightmare. Disaster. The server side is 
programmed in D, the user (client) side needs JS, ain't no other 
way. I have made a real, real, real, reeeeel effort, I've tried 
to replicate, mimic, emulate, imitate ... (running out of words 
here) every good programming pattern ever invented. But to no 
avail. JS is madness and I seriously don't understand why it has 
survived the way it is, why people just didn't abandon it years 
ago. It is madness. Frustration. Alienation.
    Every time I write something in JS, I feel like a complete 
programming novice, with the only difference that I know exactly 
what I want and how I would do it in any other programming 
language. But not so in JS. It defies reason and common human 
logic. JS degrades programmers. Years of experience are naught, 
you have to beg and cajole, you're at the mercy of a psychopathic 
tyrant.
    Whenever I program in JS I become highly irritable. When I 
program in D, I'm calm, I know what I want, and I know I will get 
it.
    I don't understand why we haven't got over JS yet. The 
Internet is so important and we still have to program things in 
JS. I don't get it. Now don't mention PHP with me ...
Feb 28 2014
next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 28 February 2014 at 11:21:51 UTC, Chris wrote:

 On Thursday, 27 February 2014 at 19:54:04 UTC, w0rp wrote:

 On Thursday, 27 February 2014 at 18:37:51 UTC, Craig 
 Dillabaugh wrote:

 On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto 
 wrote:
 clip

 Like it or not, JavaScript is good enough.


 Really? I've been stuck for the past week or so trying to put 
 together a browser based UI using JavaScript + HTML for a 
 work related project.  It has been a painful experience. In 
 fairness to JavaScript, I didn't know the language very well 
 coming in, but still I've found working in this setting 
 rather frustrating.

 If the future of applications is really client-server based 
 applications, where the client is basically a VM (if we 
 consider the browser a VM of sorts) surely there is room for 
 a better development model than this HTML + Javascript 
 mongrel.


 I developed 99% of the JavaScript part of an application for a 
 year, and I have extensive JavaScript knowledge. After all 
 that, I wrote this. 
 https://w0rp.com/blog/post/javascript-sucks/


  Craig&w0rp

 I really do understand yeez. Really. At the moment I'm working 
 with JS (again). Nightmare. Disaster. The server side is 
 programmed in D, the user (client) side needs JS, ain't no 
 other way. I have made a real, real, real, reeeeel effort, I've 
 tried to replicate, mimic, emulate, imitate ... (running out of 
 words here) every good programming pattern ever invented. But 
 to no avail. JS is madness and I seriously don't understand why 
 it has survived the way it is, why people just didn't abandon 
 it years ago. It is madness. Frustration. Alienation.
    Every time I write something in JS, I feel like a complete 
 programming novice, with the only difference that I know 
 exactly what I want and how I would do it in any other 
 programming language. But not so in JS. It defies reason and 
 common human logic. JS degrades programmers. Years of 
 experience are naught, you have to beg and cajole, you're at 
 the mercy of a psychopathic tyrant.
    Whenever I program in JS I become highly irritable. When I 
 program in D, I'm calm, I know what I want, and I know I will 
 get it.
    I don't understand why we haven't got over JS yet. The 
 Internet is so important and we still have to program things in 
 JS. I don't get it. Now don't mention PHP with me ...


"There is another option here. Use another programming language."

Thanks for this blog. Whenever I program in JS everything feels 
rather 'undefined'. I would love to see the day when JS becomes 
obsolete.
Feb 28 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Chris:


    Every time I write something in JS, I feel like a complete 
 programming novice,


Probably that's part of the problem. More experience in a 
language helps.

I suggest to use TypeScript (http://www.typescriptlang.org/ ), it 
has static types, more Java-style classes, better modules, and 
more; that give a more tidy and ordered kind of coding. If 
JavaScript gains integers too, programming in TypeScript probably 
becomes bearable even for die hard D programmers :-)

Bye,
bearophile
Feb 28 2014
next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 28 February 2014 at 12:12:38 UTC, bearophile wrote:

 Chris:


   Every time I write something in JS, I feel like a complete 
 programming novice,


 Probably that's part of the problem. More experience in a 
 language helps.


Unfortunately, you cannot get experienced in JS, there's always a 
new pitfall and the more you know it the more you hate it. If you 
don't hate it, you don't know it. On the bright side of things, 
JS teaches you how _not_ to do things and it makes you appreciate 
other languages, real programming languages.

Programming is like this:

Abstract concept of what you wanna do > find out how to do it in 


JS Programming is like this:

Abstract concept of what you wanna do > find out how ... > wait, 
why the f***k is it not > stackoverflow > ah, you cannot do this 
in JS > ah, you can, but you have to reinvent the wheel > now! > 
wait, now, why the f***k > loop through the above ...


 I suggest to use TypeScript (http://www.typescriptlang.org/ ), 
 it has static types, more Java-style classes, better modules, 
 and more; that give a more tidy and ordered kind of coding. If 
 JavaScript gains integers too, programming in TypeScript 
 probably becomes bearable even for die hard D programmers :-)


Thanks a million, I'll check it out.


 Bye,
 bearophile
Feb 28 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 28 February 2014 at 12:12:38 UTC, bearophile wrote:

 Chris:


   Every time I write something in JS, I feel like a complete 
 programming novice,


 Probably that's part of the problem. More experience in a 
 language helps.

 I suggest to use TypeScript (http://www.typescriptlang.org/ ),


Ah, no, it's MS. So is Silverlight. Don't like proprietary stuff. 
If Ceylon is real open source, great.

I'm still dreaming of a language that will replace JS, not just 
compile to JS.
Feb 28 2014
prev sibling parent reply "Asman01" <jckj33 gmail.com> writes:
On Friday, 28 February 2014 at 12:12:38 UTC, bearophile wrote:

 Chris:


   Every time I write something in JS, I feel like a complete 
 programming novice,


 Probably that's part of the problem. More experience in a 
 language helps.

 I suggest to use TypeScript (http://www.typescriptlang.org/ ), 
 it has static types, more Java-style classes, better modules, 
 and more; that give a more tidy and ordered kind of coding. If 
 JavaScript gains integers too, programming in TypeScript 
 probably becomes bearable even for die hard D programmers :-)

 Bye,
 bearophile


And now with full(native, i.e., not using a plug-in) support in 
Visual Studio 2013 check out 
http://blogs.msdn.com/b/mvpawardprogram/archive/2013/11/13/typescript-support-in-vis
al-studio-2013.aspx 
;)
Mar 01 2014
parent reply "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Saturday, 1 March 2014 at 16:37:36 UTC, Asman01 wrote:

 On Friday, 28 February 2014 at 12:12:38 UTC, bearophile wrote:

 Chris:


  Every time I write something in JS, I feel like a complete 
 programming novice,


 Probably that's part of the problem. More experience in a 
 language helps.

 I suggest to use TypeScript (http://www.typescriptlang.org/ ), 
 it has static types, more Java-style classes, better modules, 
 and more; that give a more tidy and ordered kind of coding. If 
 JavaScript gains integers too, programming in TypeScript 
 probably becomes bearable even for die hard D programmers :-)

 Bye,
 bearophile


 And now with full(native, i.e., not using a plug-in) support in 
 Visual Studio 2013 check out 
 http://blogs.msdn.com/b/mvpawardprogram/archive/2013/11/13/typescript-support-in-vis
al-studio-2013.aspx 
 ;)


As soon as Microsoft releases a Linux version I will be sure to 
try it out :o)
Mar 01 2014
parent "Asman01" <jckj33 gmail.com> writes:
On Saturday, 1 March 2014 at 18:57:03 UTC, Craig Dillabaugh wrote:

 On Saturday, 1 March 2014 at 16:37:36 UTC, Asman01 wrote:

 On Friday, 28 February 2014 at 12:12:38 UTC, bearophile wrote:

 Chris:


 Every time I write something in JS, I feel like a complete 
 programming novice,


 Probably that's part of the problem. More experience in a 
 language helps.

 I suggest to use TypeScript (http://www.typescriptlang.org/ 
 ), it has static types, more Java-style classes, better 
 modules, and more; that give a more tidy and ordered kind of 
 coding. If JavaScript gains integers too, programming in 
 TypeScript probably becomes bearable even for die hard D 
 programmers :-)

 Bye,
 bearophile


 And now with full(native, i.e., not using a plug-in) support 
 in Visual Studio 2013 check out 
 http://blogs.msdn.com/b/mvpawardprogram/archive/2013/11/13/typescript-support-in-vis
al-studio-2013.aspx 
 ;)


 As soon as Microsoft releases a Linux version I will be sure to 
 try it out :o)


Well, you will need to wait a while. :P
Mar 01 2014
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 27.02.2014 19:37, schrieb Craig Dillabaugh:

 On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto wrote:
 clip

 Like it or not, JavaScript is good enough.


 Really? I've been stuck for the past week or so trying to put together a
 browser based UI using JavaScript + HTML for a work related project.  It
 has been a painful experience. In fairness to JavaScript, I didn't know
 the language very well coming in, but still I've found working in this
 setting rather frustrating.

 If the future of applications is really client-server based
 applications, where the client is basically a VM (if we consider the
 browser a VM of sorts) surely there is room for a better development
 model than this HTML + Javascript mongrel.


I didn't say I like it that much, just that it is good enough for what 
enterprise applications, my field of work, are about.

So unless the browser vendors start supporting other languages, our 
customers will only ask for JavaScript, because it is easier to find
guys when doing maintenance support.

They don't care about Dart, TypeScript, CoffeScript, or whatever might 
be the flavour of the month, because it increases their problems to
find people and their internal teams usually don't know those languages
anyway.

The same to any other language out there. Usually when I get to work on 
a cool language at the enterprise level, it is no longer cool, or it was
brought in because some startup belonging to someone close to the CTO 
managed to sneak it in.

The is of course my enterprise world, yours may vary.

--
Paulo
Feb 27 2014
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2014-02-27 at 19:20 +0100, Paulo Pinto wrote:
[…]

  From what I understood on Dart talks last Google IO, work was planned 
 to have V8 and Dart VM play together inside Chrome.


Dartium is a build of Chromium with both, so this is very much the
direction that is possible.


 Personally, I think unless Google pushes the language fro ChromeOS or 
 Android, it will hardly get any real market size.
 
 Like it or not, JavaScript is good enough.
 
 On my field of work, it doesn't matter how many cool languages I know,
 we are usually bound by what the whole team is comfortable using, what 
 the boss allows for and the technologies that are requested by the 
 customers themselves.


Dart has a JavaScript translation back end, so could have a role very
much like CoffeeScript – which arguably hasn't been that successful
given jQuery, Backbone, Ember, Angular, etc.

Ceylon has both JVM and JavaScript back ends and is targetted at
end-to-end single language working: Ceylon in the browser, Ceylon on the
server. If some of the FUD and prejudice that is being put about by
innovation haters in the Javaverse can  be overcome, I think Ceylon
could be a big player in the game of Web applications and services.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Feb 27 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/27/2014 2:19 AM, Timothee Cour wrote:

 * optional named parameters arguments (with simplest possible syntax)


This comes up now and then. The problem with it is it makes function
overloading 
a near impossibility to untangle.
Feb 27 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-02-27 21:43, Walter Bright wrote:


 This comes up now and then. The problem with it is it makes function
 overloading a near impossibility to untangle.


We could quite easy add support for named parameters but still require 
using the same position of the arguments. I don't know if those wanting 
named parameters would be satisfied with this though.

-- 
/Jacob Carlborg
Mar 01 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jacob Carlborg:


 We could quite easy add support for named parameters but still 
 require using the same position of the arguments. I don't know 
 if those wanting named parameters would be satisfied with this 
 though.


I think requiring the same position of the arguments goes against 
one of the main points of having named arguments.

A (temporarily?) solution to Walter's problem (has someone shown 
examples of the problem?) is to just not allow the use of named 
arguments for overloaded functions. This is not a large problem 
because when you have named arguments, you have less need for 
function overloading.

Bye,
bearophile
Mar 01 2014
prev sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2014-03-01 15:19:29 +0000, Jacob Carlborg <doob me.com> said:


 On 2014-02-27 21:43, Walter Bright wrote:
 

 This comes up now and then. The problem with it is it makes function
 overloading a near impossibility to untangle.


 
 We could quite easy add support for named parameters but still require 
 using the same position of the arguments. I don't know if those wanting 
 named parameters would be satisfied with this though.


I did implement something like that in DMD a while ago as an 
experiment. See the comments below that commit:

https://github.com/michelf/dmd/commit/673bae4982ff18a3d216bc1578f50d40f4d26d7a

Walter pointed out that it should work for template arguments. I 
agreed, devised a plan to restructure the whole thing to be less of a 
hack and make it works for templates, then I had no more time to put on 
this. :-(

This planned restructuring did lead to a transition to type-checked 
arrays within DMD though, so the effort wasn't completely wasted.


-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca
Mar 01 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-03-01 17:19, Michel Fortin wrote:


 I did implement something like that in DMD a while ago as an experiment.
 See the comments below that commit:

 https://github.com/michelf/dmd/commit/673bae4982ff18a3d216bc1578f50d40f4d26d7a


I based the "quite easy" on the few changes needed in your implementation.


 Walter pointed out that it should work for template arguments. I agreed,
 devised a plan to restructure the whole thing to be less of a hack and
 make it works for templates, then I had no more time to put on this. :-(


That happens too often :(


 This planned restructuring did lead to a transition to type-checked
 arrays within DMD though, so the effort wasn't completely wasted.


Nice :)

-- 
/Jacob Carlborg
Mar 01 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/27/2014 2:19 AM, Timothee Cour wrote:

 * import all except specified symbols:
 import 'package:lib2/lib2.dart' hide foo; // Import all names EXCEPT foo.


As a general rule, negation features are frequently misunderstood, our brains 
tend to just not see the negation. One should positively import names, not 
negatively not import some.

And there's the maintenance problem - what did the importer mean to do when the 
imported module adds a 'bar' name?
Feb 27 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/27/2014 2:19 AM, Timothee Cour wrote:

 * cascade operations: they perform a series of operations on the members of a
 single object:
 foo.bar(1)..baz(3)
 equivalent to:
 foo.bar(1)
 foo.baz(3)


D has ranges and algorithms to conveniently chain operations.



 * better way to define default constructors:
 class Point {
    num x;
    num y;
    num z;
    // Syntactic sugar for setting z and x before the constructor body runs.
    Point(this.z, this.x){...}
 }
 This is more explicit and flexible than D's way for default struct
constructors,
 which can only allow to set all fields in order, without skipping some, and
 doesn't allow to do anything else in the ctor.


D doesn't allow non-trivial default struct constructors for some good reasons, 
which are a long discussion we've had many times. These reasons don't apply to 
javascript.



 * named constructors


I don't see the point of such over using the factory method idiom.



 * distinguish integer divide (~/) vs divide (/), so that 5/2=2, 5~/2=2


Such are needed so rarely - in C they are done with the modf function, and I've 
never seen modf used in the wild.



 * shorthand function declaration with => (used not just for lambdas)


tomayto, tomahto :-)



 * for (var x in collection) //better syntax than foreach(var;collection)


tomayto, tomahto



 * better syntax for optional positional arguments:
 void fun(int x, [int y, int z=3]){...}
 Thinking of which, this would actually solve a long standing problem in D, that
 of specifying optional parameters AFTER a variadic template:
 void fun(T...)(T args, [string file=__FILE__,int line=__LINE__]){...}


Not sure what that is.



 * export for libraries


What does that mean?



 * async/wait etc


Those are a great idea, and we need to do them at some point.
Feb 27 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 * optional named parameters arguments (with simplest possible 
 syntax)


 This comes up now and then. The problem with it is it makes 
 function overloading a near impossibility to untangle.


Do you have an example of the problem?



 * better way to define default constructors:
 class Point {
   num x;
   num y;
   num z;
   // Syntactic sugar for setting z and x before the 
 constructor body runs.
   Point(this.z, this.x){...}
 }
 This is more explicit and flexible than D's way for default 
 struct constructors,
 which can only allow to set all fields in order, without 
 skipping some, and
 doesn't allow to do anything else in the ctor.


 D doesn't allow non-trivial default struct constructors for 
 some good reasons, which are a long discussion we've had many 
 times. These reasons don't apply to javascript.


The idea of having some syntax like this is nice, it reduces the 
poilerplace code, making the code less noisy and reducing the 
probability of the currenty common bugs caused by having fields 
and arguments with equal or similar names:

class Foo {
     int x;
     this(this.x) {}
     void inc(int x) { this.x += x; }
}



 * shorthand function declaration with => (used not just for 
 lambdas)


 tomayto, tomahto :-)


There is an enhancement request on this in Bugzilla.
A shorter syntax for simple functions is handy, because one-line 
functions have become very common in D.

Bye,
bearophile
Feb 27 2014
parent reply Timothee Cour <thelastmammoth gmail.com> writes:
On Thu, Feb 27, 2014 at 2:40 PM, bearophile <bearophileHUGS lycos.com>wrote:


 Walter Bright:


  * optional named parameters arguments (with simplest possible syntax)


 This comes up now and then. The problem with it is it makes function
 overloading a near impossibility to untangle.


 Do you have an example of the problem?



Not sure what the problem would be. We could apply the same rules as for
template overloading, ie error when there's a potential ambiguity (or even
disable overloading for functions with named parameter until details are
ironed out). Many languages have this, for good reason (discussed, again,
many times).



 Feb 27 2014



  parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


We could kinda do named parameters today like this:

ParameterTypeTuple!foo args;
args.named_param = 3;
foo(args);

It would be nice if we could declare a variable inside a 
with(auto x = foo) like we can in if() too.



 Feb 27 2014



prev sibling next sibling parent  Timothee Cour <thelastmammoth gmail.com>  writes:


On Thu, Feb 27, 2014 at 12:56 PM, Walter Bright
<newshound2 digitalmars.com>wrote:


 On 2/27/2014 2:19 AM, Timothee Cour wrote:


 * cascade operations: they perform a series of operations on the members
 of a
 single object:
 foo.bar(1)..baz(3)
 equivalent to:
 foo.bar(1)
 foo.baz(3)


 D has ranges and algorithms to conveniently chain operations.



cascade != chaining:

cascade:
a.f1..f2..f3
<=>
a.f1
a.f2
a.f3

chaining:
a.f1.f2.f3
<=>
((a.f1).f2).f3)



 Feb 27 2014



prev sibling next sibling parent  Timothee Cour <thelastmammoth gmail.com>  writes:


  * better syntax for optional positional arguments:

 void fun(int x, [int y, int z=3]){...}
 Thinking of which, this would actually solve a long standing problem in
 D, that
 of specifying optional parameters AFTER a variadic template:
 void fun(T...)(T args, [string file=__FILE__,int line=__LINE__]){...}


 Not sure what that is.


http://d.puremagic.com/issues/show_bug.cgi?id=8687 : Variadic templates do
not work properly with default arguments





  * export for libraries


 What does that mean?


http://wiki.dlang.org/DIP45



 Feb 27 2014



prev sibling  parent  Timothee Cour <thelastmammoth gmail.com>  writes:


  * better way to define default constructors:

 class Point {
    num x;
    num y;
    num z;
    // Syntactic sugar for setting z and x before the constructor body
 runs.
    Point(this.z, this.x){...}
 }
 This is more explicit and flexible than D's way for default struct
 constructors,
 which can only allow to set all fields in order, without skipping some,
 and
 doesn't allow to do anything else in the ctor.


 D doesn't allow non-trivial default struct constructors for some good
 reasons, which are a long discussion we've had many times. These reasons
 don't apply to javascript.


I don't recall this syntax 'Point(this.z, this.x){...}' ever being
discussed; can you please provide a link?

* it avoids the following common bug:

struct Point{int x;int y;}
auto a=Point(1,2,3);
//later on we add a field: struct Point{int x; int a; int y; }
//woops!

* less boilerplate / more DRY / more explicit:

struct Point{
Foo x=32;
Bar y;
Baz z;
this(this.y, this.z){} //instead of this(Bar y, Baz z){this.y=y;this.z=z;}
}


This is arguably a preferable syntax.



 Feb 27 2014