More confusion for recruiters
More confusion for recruiters
…to an intermediate set of instructions for a virtual machine…
…called the brainfuck interpreter
I realized a while ago that there’s nothing stopping me from writing rust like this
;println!("This is great") ;println!("I think everyone should write rust like this") ;println!("Probably works in most languages that use semicolons") ;There is a Tiger Jyhton version for the web www.tigerjython.ch/en
But at least just for educational purposes😅
It uses XML-like syntax:
<fun> <name>sum</name> <in> <int>foo</int> <int>bar=0</int> </in> <out><int>foo+bar</int></out> </fun>I like it, this is clearly very enterprisey and solution focused, but I would like to suggest a couple of amendments if I may?
Namespaces
We should make full use of namespaces. Make the structural tags be in a language specific namespace (to be referenced in every function spec, obviously) but change the in an out params to use the parameter name as the tag, namespaced to the function they’re for, with a type attribute.
In memory message queues Have all function invocations be marshaled as xml documents posted to an in memory message queue. Said documents should use a schema that validates the structure and a function specific schema to validate the types of arguments being passed. Namespace everything.
I reckon we could power a medium sided country if we could generate energy from the programmers despair.
Make sure to make ample use of mixed content elements.
<statement><var>bar</var> = <int>0</int></statement>Technically I think python already has an intermediate step that it uses before it starts running a script that compiles it into a lower-ish language (at least the cpython interpreter does this, it probably isn’t a part of the language specification though)
The actual line between JIT languages and interpreted languages is pretty thin since I think most interpreted languages do something similar to minimize the amount that needs to be done at runtime
SELECT and stuff.