Re: Do you think "iamnotback" really has the" Bitcoin killer"?
For the language, I have mostly the low level part on the git, with the module system, the dynamic tree with reference pointer, http/rpc server, and most C runtime, and the vector lib for the raytracing. Then the modules method can be called from a js application with http/json/rpc.
For the high level part to make application, i dont have much theory
I would go for something very basics who can call module function and handle Event with json like data type, and in the spirit akin to BASIC with simple one line statement easy to evaluate, charm is really the kind of things im looking to have good OOP encapsulation in module with an interface.
Js as far as i know is weak for defining good object sur typing and interface, but if I understand well, your idea is to have a source language with good sur typing and interface définition, and transpiling to js to have équivalent code.
But for me i would still rather stick to a kernel in pure C, that can expose module interface to js/html5 app, and having the node/server side in C rather than node.js. Much better for performance, memory use, and portability. The only thing it really miss now is a good html templating system to generate html5/js page based on input data. For this im not sure if the best is to have browser side generated html like angular js, or something that can generate preformated html from the node, or using xslt which can be done by both server & browser. Or something entierely different to define UI and Event handling and rpc call in html5/js.
That would do in sort to have part of application in C modules with the framework, and part of application on js/html5 who can call those modules. But having another source language to transpile this part of the app with the UI and modules interface, why not.
But all the part with binary data crypto & transcoding in js
For the high level part to make application, i dont have much theory
I would go for something very basics who can call module function and handle Event with json like data type, and in the spirit akin to BASIC with simple one line statement easy to evaluate, charm is really the kind of things im looking to have good OOP encapsulation in module with an interface.Js as far as i know is weak for defining good object sur typing and interface, but if I understand well, your idea is to have a source language with good sur typing and interface définition, and transpiling to js to have équivalent code.
But for me i would still rather stick to a kernel in pure C, that can expose module interface to js/html5 app, and having the node/server side in C rather than node.js. Much better for performance, memory use, and portability. The only thing it really miss now is a good html templating system to generate html5/js page based on input data. For this im not sure if the best is to have browser side generated html like angular js, or something that can generate preformated html from the node, or using xslt which can be done by both server & browser. Or something entierely different to define UI and Event handling and rpc call in html5/js.
That would do in sort to have part of application in C modules with the framework, and part of application on js/html5 who can call those modules. But having another source language to transpile this part of the app with the UI and modules interface, why not.
But all the part with binary data crypto & transcoding in js
We will have to dig into the details in an interactive slack soon. I am thinking apps should be mostly client-side code and they should run both in the browser and as installed app on mobile. App devs could use any languages and frameworks they want. I would like to try to over time standardize a platform so the app dev only has to maintain one body of code and it runs every where. We'll even eventually have our own superapp which acts as an app installer and an app store (all decentralized, no censorship/fees possible).
But I need to work with some app devs to see what works well and how we can stage it. Might have to take it in incremental steps and our first goal is to get to launch asap.
Any way, that is why a strongly typed language that transpiles to JavaScript is something I am considering. C can also be compiled to JavaScript with Emscripten (as I think you've alluded to above).
Server-side we probably want C/C++ code, but perhaps Node.js is okay for the proof-of-concept stage. Remember we are trying to get to market asap. Then there will be funds to throw into development to refine everything.
Let's talk this out on a slack soon.