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.
"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.
