6 ms·

All the more reason the code which controls money probably shouldn't be an object oriented language compiled to bytecode. Strict functional will be looked back

All the more reason the code which controls money probably shouldn't be an object oriented language compiled to bytecode. Strict functional will be looked back on as the obvious choice.

ufo 5y ago
Most of these are just plain old scams (phishing, inside jobs, etc), which aren't affected by the choice of programming language. There are also a bunch of hacks where off-blockchain software is compromised.
- mattwilsonn888 5y ago
  You must not understand the terminology. The first five are clear contract code bugs. Even if there are scams, I'm not sure what you want to conclude about how to improve contract code from that. What I stated is well accepted.
dnautics 5y ago
Probably don't necessarily need strict functional, just need explicit "commit" statement or function where all of the mutations to the Blockchain are gathered the end of the function it makes it very clear what got changed
MichaelBurge 5y ago
Scammers will hire developers to make fake Github activity just so people looking see an active project, and then "rugpull" months later taking everything. If you debate OOP vs. functional or choice of programming language as if it were the central issue, you are helping scammers con investors by focusing on the wrong thing. At least one cryptocurrency has made a sales pitch of "Haskell is a secure language immune to exploits", and it's important to remind ourselves that using a technology that agrees with our preferences or programmer identity doesn't change the scam-status of it.
woodruffw 5y ago
I don't think a functional programming language can stop someone who's intentionally attempting to perpetrate a scam. It also probably couldn't entirely stop vulnerabilities in these "smart" contracts, but that's an entirely separate topic.
carlosdp 5y ago
Do you have any idea what comprises the source code for most traditional banking infrastructure? It ain't modern functional languages, I'll tell ya that much. >_>

All the more reason the code which controls money probably shouldn't be an object oriented language compiled to bytecode. Strict functional will be looked back on as the obvious choice.

ufo 5y ago

Most of these are just plain old scams (phishing, inside jobs, etc), which aren't affected by the choice of programming language. There are also a bunch of hacks where off-blockchain software is compromised.

mattwilsonn888 5y ago
You must not understand the terminology. The first five are clear contract code bugs. Even if there are scams, I'm not sure what you want to conclude about how to improve contract code from that. What I stated is well accepted.

dnautics 5y ago

Probably don't necessarily need strict functional, just need explicit "commit" statement or function where all of the mutations to the Blockchain are gathered the end of the function it makes it very clear what got changed

MichaelBurge 5y ago

Scammers will hire developers to make fake Github activity just so people looking see an active project, and then "rugpull" months later taking everything. If you debate OOP vs. functional or choice of programming language as if it were the central issue, you are helping scammers con investors by focusing on the wrong thing. At least one cryptocurrency has made a sales pitch of "Haskell is a secure language immune to exploits", and it's important to remind ourselves that using a technology that agrees with our preferences or programmer identity doesn't change the scam-status of it.

woodruffw 5y ago

I don't think a functional programming language can stop someone who's intentionally attempting to perpetrate a scam. It also probably couldn't entirely stop vulnerabilities in these "smart" contracts, but that's an entirely separate topic.

carlosdp 5y ago

Do you have any idea what comprises the source code for most traditional banking infrastructure? It ain't modern functional languages, I'll tell ya that much. >_>