What are you planning for 2016?

[Laeeth Isharc via Digitalmars-d]

On Tuesday, 5 January 2016 at 12:27:12 UTC, Ola Fosheim Grøstad 
wrote:
> I wonder what kind of programming people plan or _hope_ to use 
> D for in 2016?

I am developing some tools in the hedge fund sector that will be 
predominantly written in D, although there will be components 
called in other languages for user interface and libraries.  Not 
just me as I have some other people helping.  It's a 
smallish-size project  (in comparison to the likes of Weka, for 
example) that nonetheless could have quite some impact over time 
at a business level.

At some stage there may be some basic mobile apps - server will 
run D code, and maybe parts of client if it makes sense to do so 
for non-UI stuff especially.

> Do you have plans to:
>
> 1. migrate legacy C++ code bases to D when C++ bindings are 
> final?

There is no legacy code base in my case.  There are some dotnet 
processes to interface to via an API, but that's really pretty 
easy.

> 2. integrate with numerical solutions like TensorFlow?

Probably - not yet at that stage but will explore that later on.

> 3. create web services with vibe.d?

Yes - although these will be internal.  In my domain it can be 
quite different from typical concerns of web guys.  Very small 
number of users, but quite highly valued ones.  Ideally, I would 
have one user, because in the investment world if you create 
something valuable then the smaller the number of people 
exploiting it the better.

Communication between my own components may use nanomsg or tcp 
sockets rather than http.

> 4. run D apps in the cloud?
possibly.  aws lambda can be quite appealing price-wise and I 
have got D working there.  otherwise it's more sensible for my 
use to use dedicated servers and maybe a few Digital Ocean 
instances as needed.

if by cloud you mean to include private cloud then yes.


> 5. run D apps on mobile?

Yes.  See above.  I noticed with Android Wear the device is good 
especially for notifications and for triggering things.  
Notifications are pretty simple things, and executing a script on 
a trigger also.  So the overhead of not having nice wrappers 
around Android SDK (and having to go via JNI) is much less 
burdensome.  Haven't got to the stage of doing much there yet as 
other things are prior.

So my answer to your question below to Joakim:
"Does this mean that you might be able to do commercial stuff 
with D on Android this year?"

is, yes, probably.



> 6. create runtime less programs (games, embedded)?
nope.


> 7. work on the D language/phobos ?
I would like to but won't have the time.  (I made a modest 
contribution last year in a port of the build script to D, but 
digger is better).

> 8. or something else?
>
>
> What other languages do you think you will use or toy with in 
> 2016 and for what purpose?

Lua for light scripting of D components.  C# to hook into dotnet. 
  Javascript for obvious reasons.  Python and C++.


> What would it take for you to use D instead, or what changes 
> would be needed for you to move from language X to D?

I think I am pretty much all-in on D at this point.  I could 
imagine that in time then getting C++ programmers up to speed 
would become a challenge given the documentation (Don from 
Sociomantic talked about this).  But I'm already sold on D and 
don't need more to appreciate its advantages.

The work of Dlangscience could make quite a difference for the 
better down the line - John Colvin's and Ilya's work especially.  
I already use John's work commercially when writing quick scripts 
in a Python notebook (I can write some in D and some in Python in 
the same book), and I'll use Ilya's slices once I get more time.  
bachmeier's work on embedding R might come in handy too, but at a 
later stage of the project.

The idea of being able to write D code and have it compile to 
webassembly is a very interesting one, but whether it would be 
something I could use commercially I don't know as I have little 
experience developing for the web.  I am in a position where it's 
okay to take modest technical risks for prototypes, and there 
could be quite some benefit from this, so I would likely be early 
in exploring this when ready.

As I understand it, the LLVM backend can put out asm.js already 
(maybe webassembly too - I didn't check), but one would need to 
port druntime and possibly some other things.  I wonder how much 
work that would be.



Laeeth.