www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D to ASM.js vs D to Dart (VM)

reply Etienne <etcimon gmail.com> writes:
Following my previous post about new opportunities for D with ASM.js, 
I've caught up with a lot of reading about Dart after seeing the 
seriousness of the project and a virtual machine being integrated to 
chrome directly. The benchmarks are already very promising[1]

My position has changed, and I now think D would be in a better position 
if it ran in the Dart VM. In other words, ASM.js has become the Dart 
language - the solution is to introduce a D to Dart compiler[2]. This 
compiler would be written in D with Pegged, the same way I'm writing 
this ASN.1 compiler[3]

This would require the interfaces from the Dart libraries (front-end DOM 
objects) to be built into a D library. Of course, the D=>Dart compiler 
would need to handle druntime and phobos as well for complete 
integration. I don't think this task is half as complicated as it would 
have been to go the D=>LLVM=>ASM.js route.

The best part of it all is this: you can compile the back-end 
(server-side) code to a binary executable using vibe.d and achieve 
immense performance improvements vs what runs in the Dart VM, and send 
the front-end code to Dart. This obviously seems like a durable and 
promising opportunity.

Comments?

[1] https://www.dartlang.org/performance/
[2] https://www.dartlang.org/articles/why-not-bytecode/#compiling-to-source
[3] https://github.com/globecsys/asn1.d
May 15 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Etienne:


 the solution is to introduce a D to Dart compiler[2]. This 
 compiler would be written in D with Pegged,


How much RAM is this going to use?

Bye,
bearophile
May 15 2014
parent Etienne <etcimon gmail.com> writes:
On 2014-05-15 4:48 PM, bearophile wrote:

 Etienne:


 the solution is to introduce a D to Dart compiler[2]. This compiler
 would be written in D with Pegged,


 How much RAM is this going to use?

 Bye,
 bearophile


Good question, I'd be aiming for a 64 bit compiler with ~4 GB max memory 
usage, the ASN.1 compiler I made with pegged stayed well below 2 GB with 
1000 lines of BNF->PEG rules unless I had 700+ lines of code to parse 
(which check every OR possibility at 3 levels deep for the longest 
matching solution).

It's very efficient when you generate the grammar in a separate D file 
and make good use the garbage collector rather than mixin the grammar 
directly. 
https://github.com/globecsys/asn1.d/blob/master/asn1/parser/parser.d#L1022
May 15 2014
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 15 May 2014 at 20:34:31 UTC, Etienne wrote:

 My position has changed, and I now think D would be in a better 
 position if it ran in the Dart VM. In other words, ASM.js has 
 become the Dart language - the solution is to introduce a D to 
 Dart compiler[2].


Chrome runs pnacl which is a lot more efficient than Dart, but a 
D to Dart converter would be interesting for sharing code.


 Of course, the D=>Dart compiler would need to handle druntime 
 and phobos as well for complete integration.


That sounds like a bad idea. No sane person would write Dart code 
in D. The main benfit would be in sharing datastructures/RPC-like 
functionality.
May 15 2014
parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-15 4:58 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 That sounds like a bad idea. No sane person would write Dart code in D.
 The main benfit would be in sharing datastructures/RPC-like functionality.


The Phobos and druntime would most likely be type-resolved and inlined 
when converted to Dart code. It's mostly to stay in D. This compiler 
wouldn't really generate Dart code for... you know.. being "used". It 
would mostly allow to use the power of 
templates/alias/ctfe/contracts/auto/etc for browser-executed code (going 
through Dart is a side-effect)
May 15 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 15 May 2014 at 21:05:12 UTC, Etienne wrote:

 On 2014-05-15 4:58 PM, "Ola Fosheim Grøstad" 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 The Phobos and druntime would most likely be type-resolved and 
 inlined when converted to Dart code. It's mostly to stay in D. 
 This compiler wouldn't really generate Dart code for... you 
 know.. being "used". It would mostly allow to use the power of 
 templates/alias/ctfe/contracts/auto/etc for browser-executed 
 code (going through Dart is a side-effect)


Ok, as a Dart developer I would never use this:
1a. The files will be too big.
1b. Compiling from D to Dart to JS will lead to insanely big 
files.
2. The dart IDE has browser integrated debugging.
3. What is the benefit, it will be wiped out once PNaCl is 
available as a D backend?
May 15 2014
parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-15 5:10 PM, "Ola Fosheim Grøstad"

 Ok, as a Dart developer I would never use this:
 1a. The files will be too big.


There's really no issue with big files, because dart minify, tree 
shaking and the general VM caching opportunities & further optimizations 
can take care of it.


 1b. Compiling from D to Dart to JS will lead to insanely big files.


This compiler would be a bet that the VM can offer more and better 
optimizations. Tree shaking and minification can provide good advantages 
and refactoring opportunities for the time being, it's nothing we've 
never seen with the current JS libraries.


 2. The dart IDE has browser integrated debugging.


The dart code generated by D=>Dart compiler would be pretty-printed and 
suitable debugging through the dart IDE


 3. What is the benefit, it will be wiped out once PNaCl is available as
 a D backend?


The idea so far has been that the Dart VM will run on source code rather 
than bytecode like PNaCl, and it will be faster for it.

First, you can further optimize the script if you're flexible on the 
data types. It's impossible to fit 2 longs into an int with PNaCl, but 
the Dart VM will do it if that could be something the source code allows.

Second, you can keep doing "tree shaking" even during the program 
execution. Haven't used a part of the code for a while? Fine, lets just 
take it out of the memory and serialize the data for later.

Finally, you keep the debug info with you in the browser. I don't know 
what the complexity of debugging bytecode in the browser would be, it's 
hard to come accross a good visual GDB debugger and we all know how long 
that's been around.

So, this is mostly a bet that minified files pushed in a Dart VM will be 
better off than bytecode in most cases
May 15 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 15 May 2014 at 21:33:24 UTC, Etienne wrote:

 There's really no issue with big files, because dart minify, 
 tree shaking and the general VM caching opportunities & further 
 optimizations can take care of it.


It can do some tree shaking if you turn off metainfo. But D 
templates is bound to lead to bloat. Dart is a dynamic language 
and does not benefit much from templates. The power of Dart is in 
closures, but are you sure that D closures are compatible?


 1b. Compiling from D to Dart to JS will lead to insanely big 
 files.


 This compiler would be a bet that the VM can offer more and 
 better optimizations. Tree shaking and minification can provide 
 good advantages and refactoring opportunities for the time 
 being, it's nothing we've never seen with the current JS 
 libraries.


Dart2js produce large files, acceptable performance, but big.


 The idea so far has been that the Dart VM will run on source 
 code rather than bytecode like PNaCl, and it will be faster for 
 it.


Never. PNaCl will stay faster, it is IR based and multi threaded. 
Dart is a dynamic language designed to be JS compatible. The 
advantage with dart source distribution is in download size and 
future proof compatibility, not speed.
May 15 2014
parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-15 6:04 PM, "Ola Fosheim Grøstad"

 It can do some tree shaking if you turn off metainfo. But D templates is
 bound to lead to bloat. Dart is a dynamic language and does not benefit
 much from templates. The power of Dart is in closures, but are you sure
 that D closures are compatible?


Templates are compile-time, a D compiler always takes care of all its 
compile-time duties =)


 Dart2js produce large files, acceptable performance, but big.


That's a temporary issue, I'm looking at years from now when/if Dart is 
more mature and implemented in more browsers as an alternative to javascript

Also, I talked about caching in the VM

http://1.bp.blogspot.com/-W1p7BELpIDE/UH42kXZeFsI/AAAAAAAANLA/kZGulTfNjQg/s1600/Screen+Shot+2012-10-16+at+9.39.29+PM.png



 Never. PNaCl will stay faster, it is IR based and multi threaded. Dart
 is a dynamic language designed to be JS compatible. The advantage with
 dart source distribution is in download size and future proof
 compatibility, not speed.


There's a lot of advantages to a source-code VM vs a bytecode VM.

Javascript is compiled into a source-code VM, sure it'll never exceed 
the power of a byte-code VM because without more type information the 
optimization opportunities are limited

See these benchmarks over time as an example:
http://iq12.com/files/v8/v8_score.png

Dart is still very young and does not benefit from as many optimizations 
for the moment.

This same team (the V8 team) decided that a VM based on dynamic typing 
in a type-safe language would be better than pure bytecode because of 
adaptive and profile-guided optimizations. To me that's truly 
groundbreaking, and based on these charts - I'd trust them!
May 15 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 15 May 2014 at 22:16:06 UTC, Etienne wrote:

 This same team (the V8 team) decided that a VM based on dynamic 
 typing in a type-safe language would be better than pure 
 bytecode because of adaptive and profile-guided optimizations. 
 To me that's truly groundbreaking, and based on these charts - 
 I'd trust them!


Yes, but not faster than a C-like IR. Still, you do get a 
non-intrusive GC, so in that sense it is a better option than 
PNaCl.
May 15 2014
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/15/2014 6:16 PM, Etienne wrote:

 This same team (the V8 team) decided that a VM based on dynamic typing
 in a type-safe language would be better than pure bytecode because of
 adaptive and profile-guided optimizations. To me that's truly
 groundbreaking, and based on these charts - I'd trust them!


Using bytecode doesn't prevent any of that.
May 15 2014
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 15 May 2014 at 22:16:06 UTC, Etienne wrote:

 On 2014-05-15 6:04 PM, "Ola Fosheim Grøstad"

 It can do some tree shaking if you turn off metainfo. But D 
 templates is
 bound to lead to bloat. Dart is a dynamic language and does 
 not benefit
 much from templates. The power of Dart is in closures, but are 
 you sure
 that D closures are compatible?


 Templates are compile-time, a D compiler always takes care of 
 all its compile-time duties =)


 Dart2js produce large files, acceptable performance, but big.


 That's a temporary issue, I'm looking at years from now when/if 
 Dart is more mature and implemented in more browsers as an 
 alternative to javascript

 Also, I talked about caching in the VM

 http://1.bp.blogspot.com/-W1p7BELpIDE/UH42kXZeFsI/AAAAAAAANLA/kZGulTfNjQg/s1600/Screen+Shot+2012-10-16+at+9.39.29+PM.png



 Never. PNaCl will stay faster, it is IR based and multi 
 threaded. Dart
 is a dynamic language designed to be JS compatible. The 
 advantage with
 dart source distribution is in download size and future proof
 compatibility, not speed.


 There's a lot of advantages to a source-code VM vs a bytecode 
 VM.

 Javascript is compiled into a source-code VM, sure it'll never 
 exceed the power of a byte-code VM because without more type 
 information the optimization opportunities are limited


Only if you are speaking about V8, as the other VMs (Nashorn, 
Webkit, Gecko) do use bytecodes, multiple levels actually.

--
Paulo
May 15 2014
parent Etienne <etcimon gmail.com> writes:
On 2014-05-16 2:14 AM, Paulo Pinto wrote:

 Only if you are speaking about V8, as the other VMs (Nashorn, Webkit,
 Gecko) do use bytecodes, multiple levels actually.

 --
 Paulo


Well it does need to be converted to bytecode at some point but my point 
is that there can be changes in the code's typing - Javascript is not 
typed so the dynamic typing is taken for granted but in a typed language 
it's an important decision to just switch over an 64 bit -> 8 bit 
dynamically depending on profiling, it has the potential to adjust 
instructions for branch prediction to succeed more and even carry more 
into the CPU registers for tight algorithms which (theoretically) would 
beat plain C with -O3 on intel compilers with an intel cpu =)
May 16 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 16/05/14 00:16, Etienne wrote:


 Templates are compile-time, a D compiler always takes care of all its
 compile-time duties =)


Unfortunately it does not. It causes unnecessary bloat. Take this for 
example:

void foo (T) (T t);

foo(new Foo);
foo(new Bar);

This will generate two functions, even though the machine code is 
exactly the same for both.

-- 
/Jacob Carlborg
May 15 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 16 May 2014 at 06:46:08 UTC, Jacob Carlborg wrote:

 On 16/05/14 00:16, Etienne wrote:


 Templates are compile-time, a D compiler always takes care of 
 all its
 compile-time duties =)


 Unfortunately it does not. It causes unnecessary bloat. Take 
 this for example:

 void foo (T) (T t);

 foo(new Foo);
 foo(new Bar);

 This will generate two functions, even though the machine code 
 is exactly the same for both.


If the machine code is the same, the function can be merged by 
the optimizer.
May 18 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
deadalnix:


 If the machine code is the same, the function can be merged by 
 the optimizer.


But in general isn't it more efficient to not generate bloat 
instead of generating it, detecting it, and removing it?

Bye,
bearophile
May 18 2014
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 18.05.2014 10:02, schrieb bearophile:

 deadalnix:


 If the machine code is the same, the function can be merged by the
 optimizer.


 But in general isn't it more efficient to not generate bloat instead of
 generating it, detecting it, and removing it?

 Bye,
 bearophile


Which you can only do if the compiler can see the whole code.

It doesn't work in binary libraries.

--
Paulo
May 18 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Paulo Pinto:


 Am 18.05.2014 10:02, schrieb bearophile:

 But in general isn't it more efficient to not generate bloat 
 instead of
 generating it, detecting it, and removing it?

 Bye,
 bearophile


 Which you can only do if the compiler can see the whole code.

 It doesn't work in binary libraries.


I think in this case avoiding part of the problem is better than 
avoiding none of it :-) There are other similar situations where 
avoiding the template bloat is useful. This generates two 
instances of doubleIt in the binary:


T doubleIt(T)(T x) { return x * 2; }
void main() {
     immutable r1 = doubleIt(10);
     immutable r2 = doubleIt(cast(const int)10);
}


The asm, from DMD:

_D4temp15__T8doubleItTiZ8doubleItFNaNbNiNfiZi:
         enter   4,0
         add EAX,EAX
         leave
         ret

_D4temp16__T8doubleItTxiZ8doubleItFNaNbNiNfxiZxi:
         enter   4,0
         add EAX,EAX
         leave
         ret

Bye,
bearophile
May 18 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 18.05.2014 10:18, schrieb bearophile:

 Paulo Pinto:


 Am 18.05.2014 10:02, schrieb bearophile:

 But in general isn't it more efficient to not generate bloat instead of
 generating it, detecting it, and removing it?

 Bye,
 bearophile


 Which you can only do if the compiler can see the whole code.

 It doesn't work in binary libraries.


 I think in this case avoiding part of the problem is better than
 avoiding none of it :-) There are other similar situations where
 avoiding the template bloat is useful. This generates two instances of
 doubleIt in the binary:


 T doubleIt(T)(T x) { return x * 2; }
 void main() {
      immutable r1 = doubleIt(10);
      immutable r2 = doubleIt(cast(const int)10);
 }


 The asm, from DMD:

 _D4temp15__T8doubleItTiZ8doubleItFNaNbNiNfiZi:
          enter   4,0
          add EAX,EAX
          leave
          ret

 _D4temp16__T8doubleItTxiZ8doubleItFNaNbNiNfxiZxi:
          enter   4,0
          add EAX,EAX
          leave
          ret

 Bye,
 bearophile



Right, but what about more complex examples with nested templates, 
mixins and inlining?

At what moment does the optimizer give up and passes the work down to 
the linker?

Usually the work is done on basic block level, it doesn't have the full 
picture.

There are a few interesting talks from LLVM where Chandler Carruth shows 
how pages of code can be generated out of innocent looking code, because 
of nested calls.

--
Paulo
May 18 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 18 May 2014 at 08:02:59 UTC, bearophile wrote:

 deadalnix:


 If the machine code is the same, the function can be merged by 
 the optimizer.


 But in general isn't it more efficient to not generate bloat 
 instead of generating it, detecting it, and removing it?

 Bye,
 bearophile


Yes, that is not the most efficient way :D Hopefully, this can be 
done AOT so that is ok.
May 18 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 18 May 2014 at 08:02:59 UTC, bearophile wrote:

 deadalnix:


 If the machine code is the same, the function can be merged by 
 the optimizer.


 But in general isn't it more efficient to not generate bloat 
 instead of generating it, detecting it, and removing it?

 Bye,
 bearophile


It is much more difficult task I believe as template bodies can 
change dramatically even from a slightest change in parameter 
types. Compiler needs to prove instance equivalence in some way 
to do this which sounds harder than just comparing result 
assembly.
May 19 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 19 May 2014 at 18:05:29 UTC, Dicebot wrote:

 On Sunday, 18 May 2014 at 08:02:59 UTC, bearophile wrote:

 deadalnix:


 If the machine code is the same, the function can be merged 
 by the optimizer.


 But in general isn't it more efficient to not generate bloat 
 instead of generating it, detecting it, and removing it?

 Bye,
 bearophile


 It is much more difficult task I believe as template bodies can 
 change dramatically even from a slightest change in parameter 
 types. Compiler needs to prove instance equivalence in some way 
 to do this which sounds harder than just comparing result 
 assembly.


Comparing assemble at link time is an option. Comparing IR is 
another (LLVM does this).
May 19 2014
prev sibling next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 15 May 2014 at 20:34:31 UTC, Etienne wrote:

 This compiler would be written in D with Pegged, the same way 
 I'm writing this ASN.1 compiler[3]


A lexer, parser, and set of AST classes for D already exists. You 
may want to use them instead.

https://github.com/Hackerpilot/Dscanner/tree/master/std/d
May 15 2014
prev sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 15 May 2014 at 20:34:31 UTC, Etienne wrote:

 My position has changed, and I now think D would be in a better 
 position if it ran in the Dart VM.


Even if I _were_ a Chrome user, I'd have precisely zero interest 
in a browser monoculture.  To wit, [P]NaCl and Dart effectively 
don't exist in my world.  ASM.js is only slightly better in this 
regard because it at least _runs_ on other browsers.

-Wyatt
May 16 2014
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 16 May 2014 at 12:55:30 UTC, Wyatt wrote:

 On Thursday, 15 May 2014 at 20:34:31 UTC, Etienne wrote:

 My position has changed, and I now think D would be in a 
 better position if it ran in the Dart VM.


 Even if I _were_ a Chrome user, I'd have precisely zero 
 interest in a browser monoculture.  To wit, [P]NaCl and Dart 
 effectively don't exist in my world.  ASM.js is only slightly 
 better in this regard because it at least _runs_ on other 
 browsers.

 -Wyatt


See my post:

http://forum.dlang.org/thread/lktk12$15u1$3 digitalmars.com?page=3#post-qjxnftlafeeaskifcefd:40forum.dlang.org

I don't trust product / company centric software. It will lock 
you in or lock you out.
May 16 2014
parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-16 9:12 AM, Chris wrote:

 I don't trust product / company centric software. It will lock you in or
 lock you out.


Google doesn't have a reputation of creating company centric software. 
SPDY was adopted by other browsers as well. If steam picks up on Dart, 
it could very well be adopted even by IE14 if that browser doesn't go 
the Netscape way ;)
May 16 2014
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
16-May-2014 17:21, Etienne пишет:

 On 2014-05-16 9:12 AM, Chris wrote:

 I don't trust product / company centric software. It will lock you in or
 lock you out.


 Google doesn't have a reputation of creating company centric software.
 SPDY was adopted by other browsers as well. If steam picks up on Dart,
 it could very well be adopted even by IE14 if that browser doesn't go
 the Netscape way ;)


MS have TypeScript. Seems like everybody has their own favorite idea of 
better JavaScript.

-- 
Dmitry Olshansky
May 16 2014
parent Etienne <etcimon gmail.com> writes:
On 2014-05-16 9:36 AM, Dmitry Olshansky wrote:

 16-May-2014 17:21, Etienne пишет:

 On 2014-05-16 9:12 AM, Chris wrote:

 I don't trust product / company centric software. It will lock you in or
 lock you out.


 Google doesn't have a reputation of creating company centric software.
 SPDY was adopted by other browsers as well. If steam picks up on Dart,
 it could very well be adopted even by IE14 if that browser doesn't go
 the Netscape way ;)


 MS have TypeScript. Seems like everybody has their own favorite idea of
 better JavaScript.


I'm guessing they'll have to make some browser plugins for each of those 
"better javascript"s just like we need to install perl/python/ruby to 
run them. Though I assume at that point there's going to be a "winning 
browser"
May 16 2014
prev sibling next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 16 May 2014 at 13:21:22 UTC, Etienne wrote:

 On 2014-05-16 9:12 AM, Chris wrote:

 I don't trust product / company centric software. It will lock 
 you in or
 lock you out.


 Google doesn't have a reputation of creating company centric 
 software. SPDY was adopted by other browsers as well. If steam 
 picks up on Dart, it could very well be adopted even by IE14 if 
 that browser doesn't go the Netscape way ;)


You're kidding, aren't you. How can anything developed by a 
company become a real standard, catering for what developers 
need? The thread about Go not featuring generics is a good 
example. Look at what happened to Java. Market shares, strategic 
thinking, these all play into it, and don't forget the BIG EGOS 
you usually find among those who run those huge companies. Do you 
think that all decisions are made based on sound empirical 
evidence? Yeah, right.
May 16 2014
parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-16 9:45 AM, Chris wrote:

 You're kidding, aren't you. How can anything developed by a company
 become a real standard, catering for what developers need? The thread
 about Go not featuring generics is a good example. Look at what happened
 to Java. Market shares, strategic thinking, these all play into it, and
 don't forget the BIG EGOS you usually find among those who run those
 huge companies. Do you think that all decisions are made based on sound
 empirical evidence? Yeah, right.


You know the C programming language was pushed forward by AT&T right? 
And you know Google's SPDY is part of the HTML2 draft? I don't know what 
your opinions on the big corporate machines are, but some really smart 
software engineers and pioneers are being employed there with 
revolutionary ideas.
May 16 2014
next sibling parent Etienne <etcimon gmail.com> writes:
On 2014-05-16 9:52 AM, Etienne wrote:

 SPDY is part of the HTML2 draft


My bad I meant HTTP 2 ;)
May 16 2014
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 16 May 2014 at 13:52:37 UTC, Etienne wrote:

 On 2014-05-16 9:45 AM, Chris wrote:

 You're kidding, aren't you. How can anything developed by a 
 company
 become a real standard, catering for what developers need? The 
 thread
 about Go not featuring generics is a good example. Look at 
 what happened
 to Java. Market shares, strategic thinking, these all play 
 into it, and
 don't forget the BIG EGOS you usually find among those who run 
 those
 huge companies. Do you think that all decisions are made based 
 on sound
 empirical evidence? Yeah, right.


 You know the C programming language was pushed forward by AT&T 
 right? And you know Google's SPDY is part of the HTML2 draft? I 
 don't know what your opinions on the big corporate machines 
 are, but some really smart software engineers and pioneers are 
 being employed there with revolutionary ideas.


C isn't the best programming language. Only because something is 
everywhere, doesn't mean it's good (Windows comes to mind, and 
other big brands). As to the revolutionary ideas, are they really 
revolutionary or do they serve some corporate interest? Are there 
better ideas that will never be put into practice because they 
don't serve or even go against corporate interest? Is D still a 
small player because it is too community-oriented? (I hope this 
will never change!)

Mind you, how many of the big "be all end all"-technologies that 
have been hyped over the years are really good (including 
community base projects)? JS, Java, Ajax, PHP, Ruby, iOS, Android 
...? With good I mean really good, not omnipresent.
May 16 2014
next sibling parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-16 10:15 AM, Chris wrote:

 C isn't the best programming language. Only because something is
 everywhere, doesn't mean it's good (Windows comes to mind, and other big
 brands). As to the revolutionary ideas, are they really revolutionary or
 do they serve some corporate interest? Are there better ideas that will
 never be put into practice because they don't serve or even go against
 corporate interest? Is D still a small player because it is too
 community-oriented? (I hope this will never change!)

 Mind you, how many of the big "be all end all"-technologies that have
 been hyped over the years are really good (including community base
 projects)? JS, Java, Ajax, PHP, Ruby, iOS, Android ...? With good I mean
 really good, not omnipresent.


I'll have to go with: If it managed to serve corporate interest, that's 
because you were satisfied by it and suggested to others to "vote with 
their money". The company name is merely there to take that cash and 
re-distribute it to whom deserves it. I doubt the smartest person in the 
world could produce a microprocessor chip from sand without help
May 16 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 16 May 2014 at 14:20:36 UTC, Etienne wrote:

 On 2014-05-16 10:15 AM, Chris wrote:

 C isn't the best programming language. Only because something 
 is
 everywhere, doesn't mean it's good (Windows comes to mind, and 
 other big
 brands). As to the revolutionary ideas, are they really 
 revolutionary or
 do they serve some corporate interest? Are there better ideas 
 that will
 never be put into practice because they don't serve or even go 
 against
 corporate interest? Is D still a small player because it is too
 community-oriented? (I hope this will never change!)

 Mind you, how many of the big "be all end all"-technologies 
 that have
 been hyped over the years are really good (including community 
 base
 projects)? JS, Java, Ajax, PHP, Ruby, iOS, Android ...? With 
 good I mean
 really good, not omnipresent.


 I'll have to go with: If it managed to serve corporate 
 interest, that's because you were satisfied by it and suggested 
 to others to "vote with their money".


... or because nobody ever had a real choice (Windows comes to 
mind again). Talking about creating monopolies, cartels and the 
like. This goes for everything, not just software. Do people 
learn English, because they think it is a beautiful language or 
because they have to, if they want to access a global market? 
Does the omnipresence of English mean that it's the best language 
ever (Bien sûr!) and that's why people "vote" for it? Isn't it 
sometimes just choosing the lesser evil instead of being able to 
choose something really good?


 The company name is merely there to take that cash and 
 re-distribute it to whom deserves it. I doubt the smartest 
 person in the world could produce a microprocessor chip from 
 sand without help
May 16 2014
next sibling parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-16 10:41 AM, Chris wrote:

 Isn't it sometimes just choosing the lesser evil instead of being able
 to choose something really good?


Alright, so you can try and make something really good and see if it can 
satisfy 95% of the world's offices as much. Even with infinite funds and 
teammates, chances are you'll quickly end up admiring that "dreadful 
Microsoft"'s employees for putting up with that shit and making 
something good out of it.. whatever the salary. Companies don't make 
humans miserable; humans make humans miserable. Hatred for humans 
because they serve other humans under a banner is just plain ignorance
May 16 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 16 May 2014 at 14:46:43 UTC, Etienne wrote:

 On 2014-05-16 10:41 AM, Chris wrote:

 Isn't it sometimes just choosing the lesser evil instead of 
 being able
 to choose something really good?


 Alright, so you can try and make something really good and see 
 if it can satisfy 95% of the world's offices as much. Even with 
 infinite funds and teammates, chances are you'll quickly end up 
 admiring that "dreadful Microsoft"'s employees for putting up 
 with that shit and making something good out of it.. whatever 
 the salary.



 Companies don't make humans miserable; humans make humans 
 miserable.


And companies are run by humans, if I'm not completely mistaken. 
It's not the army that kills people, it's the humans in the army 
that kill other humans. Stoutly reasoned!


 Hatred for humans because they serve other humans under a 
 banner is just plain ignorance


Who's talking about hatred? Being skeptical doesn't involve 
hatred. The thing is that the best engineers cannot put their 
ideas into practice, if the company rejects it for whatever 
reason (there are so many, partly highly ridiculous, reasons why 
good ideas have been rejected, one could write a book about it). 
And yes, if humans serve under a banner, you have the right to 
criticize them, because they accept the banner and what it stands 
for. The fact that we all have to serve somebody to put food on 
our tables, doesn't mean it is right.
May 16 2014
parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-16 10:57 AM, Chris wrote:

 And companies are run by humans, if I'm not completely mistaken. It's
 not the army that kills people, it's the humans in the army that kill
 other humans. Stoutly reasoned!


 Hatred for humans because they serve other humans under a banner is
 just plain ignorance


 Who's talking about hatred? Being skeptical doesn't involve hatred. The
 thing is that the best engineers cannot put their ideas into practice,
 if the company rejects it for whatever reason (there are so many, partly
 highly ridiculous, reasons why good ideas have been rejected, one could
 write a book about it). And yes, if humans serve under a banner, you
 have the right to criticize them, because they accept the banner and
 what it stands for. The fact that we all have to serve somebody to put
 food on our tables, doesn't mean it is right.


I think we're both right, just arguing about the risks of both 
extremities of the evilness scale in companies. They can be really good, 
and really bad. Break down those too big to fail more power to the 
people etc. etc.
May 16 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 16 May 2014 at 15:02:42 UTC, Etienne wrote:

 On 2014-05-16 10:57 AM, Chris wrote:

 And companies are run by humans, if I'm not completely 
 mistaken. It's
 not the army that kills people, it's the humans in the army 
 that kill
 other humans. Stoutly reasoned!


 Hatred for humans because they serve other humans under a 
 banner is
 just plain ignorance


 Who's talking about hatred? Being skeptical doesn't involve 
 hatred. The
 thing is that the best engineers cannot put their ideas into 
 practice,
 if the company rejects it for whatever reason (there are so 
 many, partly
 highly ridiculous, reasons why good ideas have been rejected, 
 one could
 write a book about it). And yes, if humans serve under a 
 banner, you
 have the right to criticize them, because they accept the 
 banner and
 what it stands for. The fact that we all have to serve 
 somebody to put
 food on our tables, doesn't mean it is right.


 I think we're both right, just arguing about the risks of both 
 extremities of the evilness scale in companies. They can be 
 really good, and really bad. Break down those too big to fail 
 more power to the people etc. etc.


Yep. Look at the open source communities, all the forks and 
fights. There used to be Tango vs Phobos. On the other hand, it's 
good that people can just do their own thing, if they're not 
happy with an existing project (for what ever reason). With 
companies, you have to stick with whatever decision they make, 
you ain't got no choice there. I remember that Apple removed my 
development tools after an upgrade and I had to download them 
again through the AppStore (had to register etc.). That was it 
for me. Good night! I'm on ArchLinux now. Never looked back.
May 16 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, May 16, 2014 at 03:20:33PM +0000, Chris via Digitalmars-d wrote:
[...]

 Yep. Look at the open source communities, all the forks and fights.
 There used to be Tango vs Phobos. On the other hand, it's good that
 people can just do their own thing, if they're not happy with an
 existing project (for what ever reason). With companies, you have to
 stick with whatever decision they make, you ain't got no choice there.
 I remember that Apple removed my development tools after an upgrade
 and I had to download them again through the AppStore (had to register
 etc.). That was it for me. Good night! I'm on ArchLinux now. Never
 looked back.


Yeah, the thing with open source is that if you don't like something,
you have the right and the ability to go and change it yourself. With
proprietary software, you're out of luck. The most you can do is to
submit a bug report and pray that they will fix it soon, hopefully in
the next release, which is probably months or perhaps years away.

I remember one time there was a nasty Phobos bug that was a showstopper
for one of my projects. I needed the fix right away, since it was
critical to the project, and judging by the track record of D bugfixes,
it may take months before somebody notices the issue in bugzilla. Well,
no problem, just checkout git HEAD, find the offending code, add a
temporary fix to it. Then I can happily resume my project without
worrying too much, until the "official" fix is merged.  With a
proprietary product, usually you don't even get to *see* their
bugtracker, much less dig into the code and fix it yourself. Your
project gets stuck with imperfect workarounds that only works sometimes,
and you have to uglify your code which becomes a maintenance nightmare
down the road. If Phobos had been a proprietary product, I would've
given up D and moved on to something else.


T

-- 
There are two ways to write error-free programs; only the third one works.
May 16 2014
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/2014 10:41 AM, Chris wrote:

 On Friday, 16 May 2014 at 14:20:36 UTC, Etienne wrote:

 I'll have to go with: If it managed to serve corporate interest,
 that's because you were satisfied by it and suggested to others to
 "vote with their money".


 ... or because nobody ever had a real choice


...or because fools are plentiful and easily swayed by theatrics, 
popularity, gimmicks, projected image and other such easily-manipulated 
and fabricated idiocy.

There's all sorts of reasons why the whole "voting with their wallets" 
thing is a complete and total fantasy.
May 16 2014
prev sibling parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Friday, 16 May 2014 at 14:15:20 UTC, Chris wrote:

 Mind you, how many of the big "be all end all"-technologies 
 that have been hyped over the years are really good (including 
 community base projects)? JS, Java, Ajax, PHP, Ruby, iOS, 
 Android ...? With good I mean really good, not omnipresent.


Agree with you on all of those, except for iOS.  I know many of 
us hate how much its success is driven by marketing, but it 
appears to be a very solid product technically.  At least that's 
what I read, I haven't bought an Apple product in a decade 
because of their crazy stance on patents and how closed they've 
become.

However, just looking at iOS technically, even the latest iPad 
Air and iPhone 5s run on just 1 GB of RAM and still regularly 
outperform Android devices, which is crazy considering Android 
superphones/tablets have up to 3 GBs of RAM these days.  iOS 
devices repeatedly benchmark as the least laggy for touch.  Nick 
may not believe in people voting with their wallets, but iOS 
devices have garnered Apple a couple hundred billion in profits 
so far:

http://www.phonearena.com/news/Samsung-and-Apple-reportedly-earned-87.9-of-the-smartphone-market-profits-for-the-last-6-years_id54030

I suppose you can hate on Obj-C, but that's not really iOS.  The 
latest release got bogged down in all the bling, but that's more 
like Apple heaped too much icing on top: the cake is still great.

Why isn't iOS good?
May 16 2014
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 16.05.2014 21:53, schrieb Joakim:

 On Friday, 16 May 2014 at 14:15:20 UTC, Chris wrote:

 Mind you, how many of the big "be all end all"-technologies that have
 been hyped over the years are really good (including community base
 projects)? JS, Java, Ajax, PHP, Ruby, iOS, Android ...? With good I
 mean really good, not omnipresent.


 Agree with you on all of those, except for iOS.  I know many of us hate
 how much its success is driven by marketing, but it appears to be a very
 solid product technically.  At least that's what I read, I haven't
 bought an Apple product in a decade because of their crazy stance on
 patents and how closed they've become.

 However, just looking at iOS technically, even the latest iPad Air and
 iPhone 5s run on just 1 GB of RAM and still regularly outperform Android
 devices, which is crazy considering Android superphones/tablets have up
 to 3 GBs of RAM these days.  iOS devices repeatedly benchmark as the
 least laggy for touch.  Nick may not believe in people voting with their
 wallets, but iOS devices have garnered Apple a couple hundred billion in
 profits so far:

 http://www.phonearena.com/news/Samsung-and-Apple-reportedly-earned-87.9-of-the-smartphone-market-profits-for-the-last-6-years_id54030


 I suppose you can hate on Obj-C, but that's not really iOS.  The latest
 release got bogged down in all the bling, but that's more like Apple
 heaped too much icing on top: the cake is still great.

 Why isn't iOS good?


No, when compared against what Symbian OS could do with less resources.
May 16 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/2014 4:10 PM, Paulo Pinto wrote:

 Am 16.05.2014 21:53, schrieb Joakim:

 Why isn't iOS good?


 No, when compared against what Symbian OS could do with less resources.


I don't know what the hardware was like on Symbian's short-lived 
touch-screen stuff, but heck, PalmOS ran beautifully on a 16MHz 
Dragonball with 8MB RAM (and yea, those are "M"s, not "G"s), let alone 
the later ARM-based Palms. (I loved my Visor Deluxe and Zire 71 :) )
May 17 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/2014 3:53 PM, Joakim wrote:

 On Friday, 16 May 2014 at 14:15:20 UTC, Chris wrote:

 Mind you, how many of the big "be all end all"-technologies that have
 been hyped over the years are really good (including community base
 projects)? JS, Java, Ajax, PHP, Ruby, iOS, Android ...? With good I
 mean really good, not omnipresent.


 Agree with you on all of those, except for iOS.  I know many of us hate
 how much its success is driven by marketing, but it appears to be a very
 solid product technically.  At least that's what I read, I haven't
 bought an Apple product in a decade because of their crazy stance on
 patents and how closed they've become.

 However, just looking at iOS technically, even the latest iPad Air and
 iPhone 5s run on just 1 GB of RAM and still regularly outperform Android
 devices, which is crazy considering Android superphones/tablets have up
 to 3 GBs of RAM these days.  iOS devices repeatedly benchmark as the
 least laggy for touch.  Nick may not believe in people voting with their
 wallets, but iOS devices have garnered Apple a couple hundred billion in
 profits so far:

 http://www.phonearena.com/news/Samsung-and-Apple-reportedly-earned-87.9-of-the-smartphone-market-profits-for-the-last-6-years_id54030


 I suppose you can hate on Obj-C, but that's not really iOS.  The latest
 release got bogged down in all the bling, but that's more like Apple
 heaped too much icing on top: the cake is still great.

 Why isn't iOS good?


The problem with iOS devices isn't software bloat, it's overall design 
and, as you mentioned, Apple's...uhh...orwellian-ness. (IMO, anyway) I 
could go on and on and on about iPhone's design problems (and have done 
so ;) )

And I'm not surprised Android is a little slower/laggier than iOS, what 
with Dalvik. I don't care how much they've optimized it, a JVM-alike at 
the system-level on a mobile device is just asking for "second-place at 
best" (performance-wise anyway). They're now forced to go out of their 
way with stuff like ART just to mitigate some of the problems Dalvik 
introduced. That's the one big thing I *do* think Apple really got right 
- native system-level with ARC, instead of mobile JVM clone.

(FWIW/BTW, MS has actually hit a rather interesting middle-ground with 
WinRT's sort-of-a-VM-but-not-exactly approach. Not that I'm a fan of 
Win8/WinRT/Metro/MS/etc, but that particular aspect is quite noteworthy 
IMO.)


 Nick may not believe in people voting with their wallets,


Well, to be clear (and without trying to get too political about it), I 
do believe in *attempting* to vote with one's wallet, and that it can be 
a *factor* in what succeeds and what doesn't. I just don't believe it's 
remotely close to being the sole primary factor or that it remotely 
implies "what succeeds must therefore be good". And I think all that's 
unfortunate.
May 17 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 17.05.2014 20:12, schrieb Nick Sabalausky:

 On 5/16/2014 3:53 PM, Joakim wrote:

 On Friday, 16 May 2014 at 14:15:20 UTC, Chris wrote:

 Mind you, how many of the big "be all end all"-technologies that have
 been hyped over the years are really good (including community base
 projects)? JS, Java, Ajax, PHP, Ruby, iOS, Android ...? With good I
 mean really good, not omnipresent.


 Agree with you on all of those, except for iOS.  I know many of us hate
 how much its success is driven by marketing, but it appears to be a very
 solid product technically.  At least that's what I read, I haven't
 bought an Apple product in a decade because of their crazy stance on
 patents and how closed they've become.

 However, just looking at iOS technically, even the latest iPad Air and
 iPhone 5s run on just 1 GB of RAM and still regularly outperform Android
 devices, which is crazy considering Android superphones/tablets have up
 to 3 GBs of RAM these days.  iOS devices repeatedly benchmark as the
 least laggy for touch.  Nick may not believe in people voting with their
 wallets, but iOS devices have garnered Apple a couple hundred billion in
 profits so far:

 http://www.phonearena.com/news/Samsung-and-Apple-reportedly-earned-87.9-of-the-smartphone-market-profits-for-the-last-6-years_id54030



 I suppose you can hate on Obj-C, but that's not really iOS.  The latest
 release got bogged down in all the bling, but that's more like Apple
 heaped too much icing on top: the cake is still great.

 Why isn't iOS good?


 The problem with iOS devices isn't software bloat, it's overall design
 and, as you mentioned, Apple's...uhh...orwellian-ness. (IMO, anyway) I
 could go on and on and on about iPhone's design problems (and have done
 so ;) )

 And I'm not surprised Android is a little slower/laggier than iOS, what
 with Dalvik. I don't care how much they've optimized it, a JVM-alike at
 the system-level on a mobile device is just asking for "second-place at
 best" (performance-wise anyway). They're now forced to go out of their
 way with stuff like ART just to mitigate some of the problems Dalvik
 introduced. That's the one big thing I *do* think Apple really got right
 - native system-level with ARC, instead of mobile JVM clone.


They haven't. That is the whole point.

It is well known among Java developers with Android experience, that 
Dalvik is a kind of good enough implementation, without much effort. 
Almost as a modern BASIC.

It only had improvements on 2.2 (got a JIT), 2.3 (small improvements and 
a little bette GC) and 4.3 (a few more intrisics).

The original Dalvik architect is no longer in the team.

I am waiting eagerly for the Google IO ART session to see how the new 
AOT compiler behaves. Specially when compared with MIDL .NET compilers.


 (FWIW/BTW, MS has actually hit a rather interesting middle-ground with
 WinRT's sort-of-a-VM-but-not-exactly approach. Not that I'm a fan of
 Win8/WinRT/Metro/MS/etc, but that particular aspect is quite noteworthy
 IMO.)


They basically implemented the original model of .NET. Based on the 
available documentation, COM+ VOS as it was called is quite similar to 
WinRT. Then Java happenend, and another design approach was done.

 From the MSDN blogs, it seems the native side has been getting strong 
since the Longhorn failure, which lead to WinRT, RyuJIT, .NET Native and 
stronger focus on C++. This is my opinion, not sure how well it
matches reality.

--
Paulo
May 17 2014
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/2014 9:21 AM, Etienne wrote:

 On 2014-05-16 9:12 AM, Chris wrote:

 I don't trust product / company centric software. It will lock you in or
 lock you out.


 Google doesn't have a reputation of creating company centric software.
 SPDY was adopted by other browsers as well. If steam picks up on Dart,
 it could very well be adopted even by IE14 if that browser doesn't go
 the Netscape way ;)


Google's reputation hasn't very well matched it's reality for quite some 
time. They basically don't give much more of a rat's ass about standards 
and compatibility than MS these days. Even Gmail's alleged "POP3" 
feature works in bizarre non-POP3 ways. If they don't even give half a 
shit about making something as basic and standard as POP3 behave like 
it's supposed to, how can anything that's much more heavily Google-based 
be trusted long-term?

Even if NaCl/Dart/whatever do wind up in all the other browsers, the 
modern-day Google would be prone to making goofy arbitrary changes to 
their version on a whim, with or without reasonable justification. It's 
just how Google is these days. They're not the cute little upstart they 
were 15 years ago. They're a 600lb gorilla now, they full well know it, 
and they're not afraid to use that to pull whatever they feel like. 
"Don't be evil" my ass. It's not as if that was ever setting a very high 
bar in the first place.
May 16 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 16 May 2014 at 12:55:30 UTC, Wyatt wrote:

 Even if I _were_ a Chrome user, I'd have precisely zero 
 interest in a browser monoculture.  To wit, [P]NaCl and Dart 
 effectively don't exist in my world.


Dart compiles to JS, but drops support for IE9 after this summer… 
so it isn't a mono culture, but you do depend on Google strategic 
planning by using Dart.


 ASM.js is only slightly better in this regard because it at 
 least _runs_ on other browsers.


Yes, that's a good quality. You also have Google Closure which is 
type annotated JS that does optimization/minification.
May 16 2014
parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 16 May 2014 at 14:03:05 UTC, Ola Fosheim Grøstad wrote:

 Dart compiles to JS, but drops support for IE9 after this 
 summer… so it isn't a mono culture, but you do depend on Google 
 strategic planning by using Dart.


As I understand it, you take a substantial performance hit for 
doing so.

Belay that, if I wanted a compiler centipede, I'd be more 
interested in targeting Haxe: community-driven and it lets me 


-Wyatt
May 16 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 16 May 2014 at 15:54:44 UTC, Wyatt wrote:

 As I understand it, you take a substantial performance hit for 
 doing so.


I haven't noticed this much. It is a bit more annoying to debug 
on IE. I doubt you get much more than a 40% penalty, but you also 
get working closures, this-pointer etc.


 Belay that, if I wanted a compiler centipede, I'd be more 
 interested in targeting Haxe: community-driven and it lets me


I like the concept, but it takes a lot of resources to cover 
browser bugs. Dart targets current browsers and are tested 
against them. It provides polyfills where the browser is lacking 
and gives you booleans to test for features. You have to count in 
the libraries, IDE, debugger etc.
May 16 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/2014 4:16 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Friday, 16 May 2014 at 15:54:44 UTC, Wyatt wrote:

 As I understand it, you take a substantial performance hit for doing so.


 I haven't noticed this much. It is a bit more annoying to debug on IE. I
 doubt you get much more than a 40% penalty,


That's a pretty big penalty for something that's already so slow.


 but you also get working
 closures, this-pointer etc.
May 17 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 17 May 2014 at 18:25:00 UTC, Nick Sabalausky wrote:

 On 5/16/2014 4:16 PM, "Ola Fosheim Grøstad" 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Friday, 16 May 2014 at 15:54:44 UTC, Wyatt wrote:

 As I understand it, you take a substantial performance hit 
 for doing so.


 I haven't noticed this much. It is a bit more annoying to 
 debug on IE. I
 doubt you get much more than a 40% penalty,


 That's a pretty big penalty for something that's already so 
 slow.


Hm, I think it is roughly 40% slower than Dart, but perhaps 10% 
slower than JS, and sometimes faster than JS (probably because of 
type info).
May 17 2014