On 31/10/2014 6:39 a.m., Laeeth Isharc wrote:
Hi.
Thanks for all the thoughts, and sorry it has taken me a little while to
reply.
Adam - I liked your book very much: it really complemented the other
resources out there, especially in communicating a refreshing spirit of
enthusiasm and fearless exploration.
ketmar - I took a look at script.d very briefly. I would love if I
could use some kind of D-like and D-friendly scripting language on the
client (Suliman has a point!), but my understanding is that I cannot if
I want to use standard browsers without a plugin - Chrome, Firefox, etc.
BTW what was the story behind dscript? It seems to have changed its
name and no longer have so much connection to D:
http://forum.dlang.org/thread/422be824.6030...@nospam.org
"It would be awesome to write front-end tools in D. However, there won't
be much browser support unless you're backed by Google or Microsoft."
Etienne - yes, indeed. That is exactly the problem. In theory your
suggestion of compiling D to Javascript sounds intriguing, but I wonder
if in practice it will be worth it on the client (I confess that you
likely know much more about this than me). Even if interoperability
with the ecosystem is possible, I suppose it will be clunkier to write
in D compiled to JS than in Dart because there are fewer people pouring
energy into the project to make it easy. I don't mind reimplementing
some things on the back end in order to make it fast, beautiful, and
efficient but I have no interest in re-writing anything in user
interface domain. (Others may be different).
As a second-best, but overall pretty appealing choice (superficially,
since I haven't written anything substantial in it), Dart at least has a
C-like syntax, seems to avoid most of the JS infelicities, and has some
of the benefits of type-checking. It hasn't taken off yet, but my guess
is it will.
"What kind of client are you doing? If you are writing a web page,
you don't need any kind of script language API. JavaScript or
dart or whatever talk with your server application through http
requests or websockets, whereas script language APIs are meant
for extending your application in the same process. For example,
a text editor might have a script language to make custom
functions for hotkeys." - Adam Ruppe
Proprietary trading analytics and charting - still at an early stage so
the design is not fully mapped out. I understand that if I run D on
server and Dart on client then I don't need to worry about APIs. But 1)
if I decide to run Dart on server and write my number-crunching
analytics in D then I suppose I either need the Dart headers translated
to D (API) or have the Dart web server talk to a D analytics server via
a socket. And 2) I cannot say that I definitely do not want to cache
things and do some work on client, and so I need to see what's possible
to avoid getting trapped in purely local optimum. 3) It's a long way
from being relevant, but ultimately realtime data licensing occurs at
local user level for Bloomberg etc, so much better to be able to tap in
to a data source the user already has.
"Dart makes most sense for internal web applications."- Ola
Yes - exactly my situation.
"Dart VM is available as a standalone, which can be set up to act
as a web server. But you want to integrate it into D?" - Ola
There are already C headers, and it is simple to wrap any C function
manually so you can call it from Dart. Perhaps it would be possible to
do something like PyD (I am still learning templates/CTFE so I don't
know), but for now I was just thinking of converting the 3000 line odd
(but mostly whitespace) header from .h to .d. Most of it's easy, but I
struggled a bit with syntax for using alias in D to declare function
pointer return types and parameters (I think I get it now).
Why bother? D seems just perfect for the particular kind of quant
financial work I want to do, but for the time being it is lacking on web
server and client. Vibe.d is great, but is not a complete framework
from what I have seen (which is fine, since it doesn't pretend to be
one, but makes it harder if you don't want to spend your time on this).
And we discussed the client above. So I need to have some way for Dart
to talk to D.
That's Cmsed, it can generate javascript (prototype currently but
possible for jquery) ajax code for calling routes and CRUD for data models.
The next version is a bit off from having that support but it will have
much better development.
"I don't think so, but integrating DartVM into D means you have to
deal with two different garbage collectors or put a substantial
amount of work into making D use the Dart collector."
Thanks for the warning. I will have a low number of users, and whilst
on occasion working data sets might be large, they won't stick around
for very long so pre-allocating buffers should work fine (I hope).
Thanks once again to everyone for all the suggestions and observations.
Laeeth/
On Wednesday, 29 October 2014 at 22:12:32 UTC, Laeeth Isharc wrote:
Hi.
I have had a look around for these, but was not able to see them.
It looks perhaps like dart_api.h is the main file to convert - I will
have a crack at starting this unless anyone knows of any already in
existence.
Rationale for using Dart in combination with D is that I am not
thrilled about learning or writing in Javascript, yet one has to do
processing on the client in some language, and there seem very few
viable alternatives for that. It would be nice to run D from front to
back, but at least Dart has C-like syntax and is reasonably well
thought out.
Am I missing any existing bindings somewhere?
Thanks.
Laeeth.
