Solidity is the JavaScript-like programming language designed for developing smart contracts that run on the Ethereum Virtual Machine (EVM).
My intuitions are saying that the language should be functional, simple, high-level and damn well tested. Ideally it should also be close enough to natural language that it would be partially self-documenting and difficult to hide nasty tricks in. And it should have a strict syntax so that there’s only one correct way to do anything ever, and deviating from it would produce an obvious error instead of unexpected behavior and it would be noticed at “compile-time” so that the only programs that ever get to run are Correct.
I’m not an expert yet but these features sound like inspiration should be taken from the likes of Ada, Haskell, Python etc.
…so they chose javascript instead
what has the world done to deserve this
And it should have a strict syntax so that there’s only one correct way to do anything ever, and deviating from it would produce an obvious error instead of unexpected behavior and it would be noticed at “compile-time” so that the only programs that ever get to run are Correct.
Python
Wat
That was more about the “natural language-resembling” part; to my knowledge none of those languages would satisfy all of the requirements, but Python programs are actually readable while javascript is…javascript.
“Natural language-resembling” sounds to me like how you get COBOL. Natural language is not optimized for smart contracts, and so I’d expect that it would be full of false-friends and other traps, and programming constructions that are similar-to-but-not-actually what you expect them to be are an on-going source of many troubles.
Okay, I don’t mean it in that sense; I mean in the sense that stuff that doesn’t need to be complicated isn’t complicated.
To take a simple example, in Python one can just do a loop like “for var in array…” which, when implemented solidly, should be no less secure and predictable than Javascript’s more complex looping of “i = 0, i < length(array), i++…” or whatever it was.
In fact, my totally non-expert intuitions suspect that it’d be easier to sneak unexpected behavior to something with such imperative boilerplate (the underhanded C contest remaining a favorite for a reason) whereas pure well-defined functions if done correctly will do exactly what they should and making them deviate from their intended behavior should be the weird thing that sticks out. “for var in array…” will loop through each element of the array exactly once or otherwise python has been broken, but having to fuck around with an explicit “i” seems like it would introduce the possibility of fucking around with it to make the program do something it should not do.
Or to take an example from Julia: sum(primes(2000000)) returns the sum of primes under 2 million and it’s the job of the language to do it properly, but if I wrote my own code to do it without such (presumably very well checked and proven, in the case of the smart contract language) ready-made functions an innocent mistake (or something that’s made to look like an innocent mistake) could make it skip some primes or introduce non-primes, thus invalidating the result. If people need to spend time checking the prime-testing algorithm of each individual program it’s time away from the things that actually need attention. The less there is to fuck up with, the less chance there is to fuck up. (Although once again I suspect having it be something like “sum(primes_in(1..2000000))” would make it more reliable as this would make it explicit that we’re dealing with a range and selecting the primes from it instead of eg. the first 2 million prime numbers. Simple is good, but unambiguous is vital.)