promethea.incorporated

brave and steely-eyed and morally pure and a bit terrifying… /testimonials /evil /leet .ask? .ask_long?


nuclearspaceheater:

socialjusticemunchkin:

shlevy:

socialjusticemunchkin:

nuclearspaceheater:

I was reading about Ethereum.

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

1 week ago · tagged #baby leet #software horrors · 53 notes · source: nuclearspaceheater · .permalink

  1. lisp-case-is-why-it-failed reblogged this from nuclearspaceheater
  2. nuclearspaceheater reblogged this from nuclearspaceheater and added:
    A bug in an official Ethereum-dev wallet, that was just discovered a week ago, makes accounts that it created vulnerable...
  3. mitoticcephalopod reblogged this from mugasofer
  4. mugasofer reblogged this from lisp-case-is-why-it-failed
  5. almostcoralchaos reblogged this from speakertoyesterday
  6. veronicastraszh reblogged this from socialjusticemunchkin and added:
    Right. The “one right way to do things” philosophy actually goes back to (at least) Eiffel. I think I better way to...
  7. consulo-cuniculos reblogged this from nuclearspaceheater
  8. socialjusticemunchkin reblogged this from nuclearspaceheater and added:
    Okay yes, my totally non-expert intuitions and vague guesses were corrected by people who know better (insert that...
  9. mhd-hbd reblogged this from socialjusticemunchkin and added:
    In short:Etherium — shit language, “gotcha”-lawmaking, and assasination markets.Let’s go over to ColorCoin instead.
  10. speakertoyesterday reblogged this from socialjusticemunchkin and added:
    In fairness they seem to have copied the syntax (which might as well be C syntax) and not the interesting semantic...
  11. shlevy reblogged this from socialjusticemunchkin and added:
    Wat
  12. laropasucia reblogged this from socialjusticemunchkin
  13. sysice reblogged this from nuclearspaceheater
  14. theinternetcrab reblogged this from shkreli-for-president
  15. shieldfoss reblogged this from shkreli-for-president and added:
    Mmm yes and the new fork shall be developed solely by credentialed workers, we cannot have people like Brendan Eich, no...
  16. shkreli-for-president reblogged this from nuclearspaceheater and added:
    we’re going to have to kill the entire software development industry and start over. hard fork hard fork hard fork