@davidar @jbenet In which language the update tools should be written? Is Go preferred or can the tools be in any language? In my opinion, they should be written in a unified language, not being spliced up into several ones - it's easier to manage clusters of code if they're homogeneous. Maybe we could create our own dialect/language, that covers up all IPFS internals - in the sense of making an optimized, declared, object-oriented language (let's name it IPL - InterPlanetary language) for IPFS, with a compiler, that would translate the code into other high-level languages (like Go, Python, C, C++, etc.). This would allow us to develop apps for IPFS (system-administration, archiving, user-apps, etc.) with less coding. The main point is, that it would make the global development process much easier and transparent - and if the "compiler" would be written good enough and supporting enough cross-platform high-level languages, IPL could "run" on every device; IPL would become the ultimate source, that could be used anywhere - any other "source" code deriving from it would become a matter of the end-user, because he can then choose what language suits him the best.
If this idea turns out to be good (enough), I'll try to make some draft doc and start working on a (very basic) compiler/translator.
Maybe some code (although I puzzled with the idea like the whole week, it can be that the whole thing is utter crap - I'm not a specialist for developing programming languages):
$ `need` statements for importing all IPFS things
need ipfs
$ `declare` is used for declaring class
declare someclass [
if [ipfs.node.status <= 0]:
(
ipfs.node.start();
$ Print out the status of last (`l`) global (`__`) event (`v`) made [__lv.status]
$ -1 for internal error (inside this function), 0 for OK and 1 for external error (outside this function)
$ and the log string of that event [__lv.logstr] - like "[INFO]: ", "[WARN]: ", "[ERROR]: "
statusp("Node started.");
$ which is equal to:
print(__lv.logstr + "Node started." + " [STATUS: " + __lv.status + "]");
)
$ Making a `forel` (for elements) loop over `all` elements in `ipfs.node.swarm`
forel [all : ipfs.node.swarm]:
(
$ `_ce` is the local current element, deriving out of the parent `forel` loop
print(_ce.id);
)
str func addthings(str:in, str:out)
{
$ define `ipfs.root`, `___in` is input argument
ipfs.root.set(___in);
$ `forint` loop, going from 0 to 127 by 4
forint [0 -> 127 : 4]:
(
$ As before `_c` + something is the local current argument (`e` - element, `i` - int, `c` - char, etc.)
$ where `_l` + something is the local last argument (like the last index processed within this `forint` loop)
$ plus, the third char (like `__lfa`) indicates the event - so `__lfa` means:
$ `__` - it's global (because ipfs.add is global, also the resulting var must be accessible to it)
$ `l` - it's the last
$ `f` - it's a file
$ `a` - it was added
ipfs.add(ipfs.root + "/folder/" + _ci + ".jpg")
statusp("Added file " + __lfa + " with hash " + __lha)
if [_ci is _li]: (ipfs.node.restart();)
)
}
]
I hope it helps in any way. (And sorry if this community proposal isn't here in the right place - if needed I'll place it somewhere else.)
@CounterPillow commented 13 hours ago:
@vinctux
Even if your proposed language was conceptually sound (which it really_really_ isn't) and solved real-world problems (which it doesn't), the following relevant xkcd still applies:
I'm not a specialist for developing programming languages
Most people aren't, myself included, and the last thing humanity needs are more programming languages designed by people who don't have a firm grasp on the challenges involved. Especially when they don't have a clear goal in mind which they try to solve.
@CounterPillow It was just an idea. Of course making a new "global" standard doesn't solve problem of it predecessors but generally an ultimate source could make things like IPFS available everywhere - which was the point of the proposal. The other solution is to go for one specific, existent language (like Go) and force all devices to support it (if we wish that it runs there), which can turn out to be (at least) that complicated, as making a new language.
EDIT: The proposed IPL wouldn't be anything more than code, that a compiler (which in this case would rather act as a translator) "translate" into another high-lvl language - only things like syntax are changed - internals (like handling of garbage, etc.) are left to target's compiler. A suitable analogy would be that IPL is just an attempt to make all texts available in XYZ-font, not an attempt to make all texts available in ZYX-language.
@jbenet commented 12 hours ago:
@vinctux
in general, i already think it would be useful to have a very small DSL for the ipfs api, which can compile into code in whatever language using one of the associated bindings. this would allow to describe simple programs and replication strategies and easily implement them natively in the various languages. this can be achieved today with just shell scripts on top of the cli api.
Sorry, your proposed language seems related but out of scope in this discussion, feel free to open a note in https://github.com/ipfs/notes/ -- i also agree with @CounterPillow that the language is very far from being "right". don't take this as discouragement, merely a warning that you will have a ton of work to do to make a good language.
if you're genuinely interested in designing this (or other languages) i encourage you to read up and study programming language theory (and practice!) for some time while working on this. I would probably start with a good PL (Programming Languages) text book, and reading (+ understanding!) some of the top papers in POPL (and others). from there, you'll have a strong grounding to attack this. (i estimate that -- if you dive intensely into this -- you may get away with this with just a few weeks of very hard work,)
@CounterPillow i agree with your general points, however i strongly disagree with how you've phrased them. Most technical communities are way too critical, and way too dissuading of innovation. Dennis Ritchie himself was not a language designer when he set off to make "the higher level thing" that eventually turned into C. Other people laughed at him at the time... and then C happened. We should support explorations (no matter how foolish), nurture attempts at improvement (no matter how crazy they might seem), and stimulate the intellect. The key is to make sure all of these intentions materialize into correct constructions, which involves a ton of work, yes, but that just requires hard work, time, and lots of thought. Instead of directly dissuading others, point them towards how to study and solve things correctly.
Migrated from ipfs/archives#5
@davidar @jbenet In which language the update tools should be written? Is Go preferred or can the tools be in any language? In my opinion, they should be written in a unified language, not being spliced up into several ones - it's easier to manage clusters of code if they're homogeneous. Maybe we could create our own dialect/language, that covers up all IPFS internals - in the sense of making an optimized, declared, object-oriented language (let's name it IPL - InterPlanetary language) for IPFS, with a compiler, that would translate the code into other high-level languages (like Go, Python, C, C++, etc.). This would allow us to develop apps for IPFS (system-administration, archiving, user-apps, etc.) with less coding. The main point is, that it would make the global development process much easier and transparent - and if the "compiler" would be written good enough and supporting enough cross-platform high-level languages, IPL could "run" on every device; IPL would become the ultimate source, that could be used anywhere - any other "source" code deriving from it would become a matter of the end-user, because he can then choose what language suits him the best. If this idea turns out to be good (enough), I'll try to make some draft doc and start working on a (very basic) compiler/translator.
Maybe some code (although I puzzled with the idea like the whole week, it can be that the whole thing is utter crap - I'm not a specialist for developing programming languages):
I hope it helps in any way. (And sorry if this community proposal isn't here in the right place - if needed I'll place it somewhere else.)
@vinctux Even if your proposed language was conceptually sound (which it really _really_ isn't) and solved real-world problems (which it doesn't), the following relevant xkcd still applies:
Most people aren't, myself included, and the last thing humanity needs are more programming languages designed by people who don't have a firm grasp on the challenges involved. Especially when they don't have a clear goal in mind which they try to solve.
Please also see this checklist.
@CounterPillow It was just an idea. Of course making a new "global" standard doesn't solve problem of it predecessors but generally an ultimate source could make things like IPFS available everywhere - which was the point of the proposal. The other solution is to go for one specific, existent language (like Go) and force all devices to support it (if we wish that it runs there), which can turn out to be (at least) that complicated, as making a new language.
EDIT: The proposed IPL wouldn't be anything more than code, that a compiler (which in this case would rather act as a translator) "translate" into another high-lvl language - only things like syntax are changed - internals (like handling of garbage, etc.) are left to target's compiler. A suitable analogy would be that IPL is just an attempt to make all texts available in XYZ-font, not an attempt to make all texts available in ZYX-language.
@vinctux
in general, i already think it would be useful to have a very small DSL for the ipfs api, which can compile into code in whatever language using one of the associated bindings. this would allow to describe simple programs and replication strategies and easily implement them natively in the various languages. this can be achieved today with just shell scripts on top of the cli api.
Sorry, your proposed language seems related but out of scope in this discussion, feel free to open a note in https://github.com/ipfs/notes/ -- i also agree with @CounterPillow that the language is very far from being "right". don't take this as discouragement, merely a warning that you will have a ton of work to do to make a good language.
if you're genuinely interested in designing this (or other languages) i encourage you to read up and study programming language theory (and practice!) for some time while working on this. I would probably start with a good PL (Programming Languages) text book, and reading (+ understanding!) some of the top papers in POPL (and others). from there, you'll have a strong grounding to attack this. (i estimate that -- if you dive intensely into this -- you may get away with this with just a few weeks of very hard work,)
@CounterPillow i agree with your general points, however i strongly disagree with how you've phrased them. Most technical communities are way too critical, and way too dissuading of innovation. Dennis Ritchie himself was not a language designer when he set off to make "the higher level thing" that eventually turned into C. Other people laughed at him at the time... and then C happened. We should support explorations (no matter how foolish), nurture attempts at improvement (no matter how crazy they might seem), and stimulate the intellect. The key is to make sure all of these intentions materialize into correct constructions, which involves a ton of work, yes, but that just requires hard work, time, and lots of thought. Instead of directly dissuading others, point them towards how to study and solve things correctly.
@vinctux This is out of scope for this issue, so please move the discussion to ipfs/notes as @jbenet suggested. However, you may be interested to read http://www.haskellforall.com/2015/05/the-internet-of-code.html