> Second, the Serpent language is untyped. It allows any operation to be performed on any data. Every value is a 256-bit sequence which can be used as an address, a contract, an integer, or an array.
I normally dislike people who criticize startups for not being perfect from day one and understand it takes iterations and a wide audience to get things right. But this isn't a normal startup and security was an obvious big piece of the puzzle from day one. Their reputation and developer adoption will depend on it.
Why doesn't the primary Ethereum language have types? This is basic stuff if you're trying to reduce bugs from the outset.
From my understanding they wanted the language to be as accessible as JS... but even JS developers are all converging on types via TypeScript, Flow, and Babel plugins like babel-typecheck. It's basically an accepted requirement of "5th-gen languages"... let alone for language-based interfaces to security focused systems.
Immutability seems like another obvious choice here for catching errors at compile time and forcing careful design considerations.
The fact Tevos is built with OCaml and is focused on code safety/verification gives me hope there is some sanity in the cryptocurrency marketplace. But it still blows my mind that this stuff wasn't given proper foresight.
A security obsessed language designer should have been the first person hired to implement the VM and reference language on top of it. And competent security researchers, like the team in this blog post, should have been brought in to do QA at each major release. It's not like Ethereum has a shortage of funding for critical infrastructure.
This isn't the JS-inspired language, that's Solidity, with it's own hilarious comedy of errors. Serpent is a Python-like language.
What makes Python or JS suitable for any sort of inspiration for smart contract programming is up for debate. Probably the idea that making it popular trumps making it right.
Dynamic types make sense for newbie-friendly web languages like Ruby and stuff like bash/zsh or support languages like Lua is to game development... but I really don't see the downside to adding types for anything outside of that.
It's really not that much of a learning curve nor does it result in a significant amount of boilerplate.
People may believe static types are a drag from using Java or C++ but if you look at modern languages like Golang or typed Erlang/Elixir or Kotlin...it really isn't that bad at all. You don't even need to go hardcore with types the way Haskell does to get most of the safety gains.
It actually provides lots of useful abstractions to make your code more efficent, it makes it easier to read (especially for others using your code), and makes using standard libraries easier to use by just reading the type specs.
So I'm really curious what the motivations were here.
I agree with you! Yet, looking at Node, JS has sorta taken off. And so has Ethereum, despite the poorly designed languages. Maybe they should have done one proper language, then a toy language to make it easy onboarding?
In the end, the Ethereum folks have achieved wild financial success, even if not in the realm of making smart contracts usable. After seeing shitty coding make people independently wealthy many times over, I'm slow to be too harsh on poor technical decisions. Perhaps a more rigorous language would have deterred a few people that turned out to be key in making Eth take off?
OTOH, criticising poor technical skills of billionaires gives me one reason to feel superior to them, so I'll probably continue to do it.
Their wild financial success is based on scamming gullible people into investing in Ponzi schemes. not one ethereum based enterprise has actually produced a product that people are using.
Agreed - even though it's a bit of a learning curve, static typing helped me make more sense of what I was doing - I had to learn it with Swift and I really like (and think it's good for beginners) that there's this layer of 'guidance' integral to the language.
To be fair, the Ethereum author sold shares in his quantum computer Bitcoin miner before starting his own coin. Security was likely not the primary design objective.
That the language was like javascript was one of the selling points (in a very real sense, as there was a lot to be sold before the software could be released).
The introduction of type checking in JS could just as easily be attributed to so many devs coming from other languages who don't want to leave their strong types security blankets behind.
The evidence for types preventing bugs is mixed. A strongly typed language in smart contracts may be entirely reasonable, but the rise of type checking in JS shouldn't be understood as evidence of anything more than many devs like having types.
And giving up types coming from another language feels like flying blind for someone used to having it. (Until you get used to it, imo, and realize that it wasn't helping as much as you thought.)
Also, the error here seemed much, much deeper than the lack of type checking.
I think Ethereum has a lot of potential and really love the platform. With that, the language options that work on top of the EVM are quite awful. There needs to be considerable investment in either building better options or building EVM compilers for well designed languages.
Something functional would be great: OCaml, F#, Haskell with immutability and formally verified abstractions for dealing with the blockchain.
But why do Ethereum people maintain a custom programming language? This could easily add a huge amount of complexity (and security issues) with very few benefits.
Moreover, maintaining a large and critical project without automated tests seems impossible to me.
The problem here is that you are handling a ton of money and it is irresponsible to manage a project in this way. More thinking that many people, including developers, in the community are millionaires, so it is not a resource problem. When you send a rocket to the space you also test it against ETs.
At least Vitalik & Gavin Woods in combination with Joe Lubin (Consensys & Ethereum Foundation) keep pushing it without any talks about reality, but just sell unproven future ideas while they train people and manufacture ICOs (less so after the SEC) and sell Ethereum to dumb enterprise that drunk the cool-aid.
I normally dislike people who criticize startups for not being perfect from day one and understand it takes iterations and a wide audience to get things right. But this isn't a normal startup and security was an obvious big piece of the puzzle from day one. Their reputation and developer adoption will depend on it.
Why doesn't the primary Ethereum language have types? This is basic stuff if you're trying to reduce bugs from the outset.
From my understanding they wanted the language to be as accessible as JS... but even JS developers are all converging on types via TypeScript, Flow, and Babel plugins like babel-typecheck. It's basically an accepted requirement of "5th-gen languages"... let alone for language-based interfaces to security focused systems.
Immutability seems like another obvious choice here for catching errors at compile time and forcing careful design considerations.
Also the language should have a (typed) Quickcheck implementation that hammers each function with random data to check for breakage... and it should be documented as standard practice. https://begriffs.com/posts/2017-01-14-design-use-quickcheck....
The fact Tevos is built with OCaml and is focused on code safety/verification gives me hope there is some sanity in the cryptocurrency marketplace. But it still blows my mind that this stuff wasn't given proper foresight.
A security obsessed language designer should have been the first person hired to implement the VM and reference language on top of it. And competent security researchers, like the team in this blog post, should have been brought in to do QA at each major release. It's not like Ethereum has a shortage of funding for critical infrastructure.