Board members are board members. They do not have executive function in the same sense as an Executive Director. The latter carries out the strategic plans decided by their Board, and serves as the day-to-day executive function. The Haskell Foundation's Board responsibilities are clearly delineated on the site, and is the more accessible position of the two. It is also unpaid, and not a function (necessarily) of tech experience, unlike the Executive Director, who must necessarily have at least some experience with project delivery and Haskell's ecosystem + community in order to function.
If you're worried that the Foundation might not live up to your expectations or go awry, keep in mind that it can only function insofar as it has input from the community. Feel free to apply for the board at https://haskell.foundation/board-nominations/, and if you think you can execute HF's technical agenda, try out for the Executive director position at https://haskell.foundation/ed-job-description/.
Haskell Foundation spoke to them very early on and continuously throughout the process. They decided not invest in any way, financially or with in-kind support.
The problem is with the structure of the VM and its bytecode language. There are additional problems with Solidity, but the VM itself is the problem. Solidity only amplifies a poor architecture: https://medium.com/kadena-io/the-evm-is-fundamentally-unsafe...
It's in the sense that it's extremely difficult to write a program and fully understand what it's doing - that's why higher order representations and correct-by-construction languages were invented. Rather than putting bandaids on it with secondary and tertiary frameworks, languages like Haskell were built to be correct by construction.
But then there's the question of whether any of those flaws are even reasonable to take upon your contract when you consider their use-case within a blockchain context. If you're only ever running terminating programs, why expose the entire language to the attack surface of non-determinism and re-entrancy bugs when there are very reasonable and expressive CbyC languages available?
We're seeing a small cottage industry of state-machine verification techniques presenting themselves over the past year. K-framework has its accessibility proofs (ranging over the state space of possible program paths), Manticore has its symbolic state analysis, and a few others do roughly the same thing. None of these frameworks are focusing on improvement of the language or supplementing its features - they're just trying to make up for how easy it is to write bug-ridden EVM contracts! Good on them, but it points to how fundamentally flawed the EVM is by design.
There's another "real drug" hidden in the subtext of your post and Semantic's post, right in between
"Sure new code might have bugs, and deep semantic changes to code can break anything..."
and
"Its language features allow concise, correct, and elegant expression of the data structures and algorithms we work with."
- the notion that fundamental abstractions (not just the ones someboy thought up like the Gang of Four) compose well. This is something that we've seen the industry slowly migrating towards in the form of functional JS flavors like typescript and purescript, Java's lambdas, Scala's Cats and so on.
The ability to refactor and as importantly be confident that your refactor is not messing with the semantics of anything upstream is a hidden feature of static types applied to expressive abstractions.
So far, I have only seen this achieved with Haskell's libraries, type system, and reliance on fundamental mathematical concepts while also being able to avoid any "there's something rotten in Denmark" moments. The content in the Hackage ecosystem is a wonder of the modern programming world, warts and all.
There are many rough edges to the development process, as always, but at least in Haskell you can limit the language's contributions to that edgeset. It actually makes you want to produce good code and be a better developer as a result!
I worked for years in Scala, and the biggest problem I had was OOP fanatics who clung to stale design patterns and out of date knowledge of general programming principles despite FP being both the simpler, cleaner, more legible, and more maintainable approach. Part of this is the fault of the individual not asking more of themselves, and part of this is the language, encouraging people to feel good about their FP+OOP hybridity, which is entirely incompatible as a concept. I've never had a new grad who could not make the switch to an FP mindset. I have, however, had older or more established devs who don't want to learn and thought they could get away with shit work (which is the main cause of scalability issues, not new concepts).
For the record, I never used more complicated concepts than Monads and MTL in my day to day usage. If you can deal with Monads, you can deal with MTL. If you can't deal with Monads, then you didn't put in the 1 whole day of work it takes to become comfortable with the concept. If you can learn what an AbstractFactoryBean is, you can damn sure learn that a Monad consists of 4 functions across 3 interfaces and that Functor:fmap => Applicative:(pure + ap + fmap) => Monad(>>= + pure + ap + fmap).
This makes me worry for Facebook if this is the quality of functional programmer they employ. Nearly every point of this rant shows an ignorance of even the most cursory parts of the subject (eta expansion, typeclasses, partial application/currying). Did OP bother to pick up a single book in the process of learning FP?
The IDE has great potential, and I've used it extensively for sandboxed and mini projects, but it's still not mature enough to replace any of the editors I'm already using (and I think they know that over at HfM).
I'm definitely keeping an eye on it, and once they come up with better pre-existing project support, and possibly git integration, it will most definitely be a candidate for replacing atom or Emacs for me. The feel of it is just fantastic.