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/.
I appreciate the openness of these invitations, but they are ultimately not valuable to large parts of the community. I (like most people) am not in a position to become a board member - certainly not an Executive Director. There are obstacles of both personal qualification and free time (since I don't see any evidence that the position is paid).
Because of that, I'm much more interested in how the Board will determine how it can best serve the community, and gather community feedback. That question can only really be answered after the board members themselves have been chosen.
> I don't see any evidence that the position is paid
> Salary will be commensurate with the experience, qualities, and location of the individual, and will also reflect the Foundation’s status as a non-profit organisation funded by donations.
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.
Here is what I imagine being on the board to be like:
"Call to order! We have here before us a motion to assign the task of deciding whether to remove 'Hello World' as a program from the documentation, given the ambiguity of its semantics. We have a second...the ayes have it, motion approved."
Or more like, "Here, let us nibble away at this $400k cheese, and by the time we get through the paperwork decide to make anything we'll hire someone on Fiverr to do a cornflower blue logo, but it will be SVG so they know we're serious.""
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.
FP Complete appears to be downplaying "Functional Programming" and "Haskell", perhaps because they found it scares off customers. At the same time, they are drowning themselves in generic buzzwords.
Haskell is below Rust on their website, despite being later alphabetically. I suspect they are pivoting away from Haskell toward Rust.
I don't think it's a bad thing. Like them or not, they have a somewhat controversial history; a lot of people worried that their projects would fork the ecosystem, or give them too much control of it - I wouldn't be surprised if they decided that it would be better for the foundation's goal of being a community effort to not be seen as having a heavy hand in it. Some people have expressed similar concerns about Facebook and IOHK as well, just from the financial influence they might have, even though their haskell projects haven't been as close to critical infrastructure as FPComplete's have.
FPC is not that crazy of an organization. Yes, I know in the past there's been drama between its members and other haskellers over stack/cabal etc., but I'd feel more comfortable if the Foundation were able to muster the diplomatic finesse to overcome that.
They are not crazy, they are just of the "I'm doing it!" instead of the "Do you think this is the best?" kind of people. They created some very good stuff (yeah, stack is great, even though I mostly stop at cabal myself), but that's not a committee member attitude.
Anyway, its not a big deal. I even doubt they will have more or less influence over anything because of that decision. It's not like unofficial communication will stop.
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.
FWIW I agree with the intent of this statement. The odd lesson we've learned is that extreme testability can overcome broken tools to create secure code. It's not the outcome you would expect since the orthodox in security engineering is that it depends on secure programming languages, frameworks, and compilers, which we have none of in Ethereum. But somehow people are carrying around hundreds of millions of dollars in smart contracts secured with high-powered testing and verification techniques. It's very weird.
I will also note that our long-term goal for Slither is to directly address some of the problems in Solidity (https://github.com/crytic/slither). It's like 2/3rds of a compiler already. It just needs a little extra push and we can generate EVM bytecode, then start ripping features out of the language that just aren't safe to use. It's amazing how far Ethereum has come with insecure tools but extreme testability. It begs the question what it would look like with both? I know Kadena is going for the clean slate approach (and we're keeping an eye on you all) but our investment at the moment is in adjustments to the current ecosystem.
The problem is likely that the platform won, it has a big ecosystem of tooling developing around it, and targeting it is best route. Maybe they can make a better language that compiles to it. Meanwhile, tool vendors are making tools that correct for flaws in the language rather than a little-known one. Also, given the tools out there, using the platform language with the tools might be safer than the other language.
The language I encouraged people to use for smart contracts was SPARK Ada. It's a mature language used in many industrial projects. Verification is easier with it. Building on what it already had would've cost them less and reduced risk. A SPARK Ada to EVM compiler is all they needed.
The EVM is just a virtual machine. People are working on languages with less opportunity for bugs than Solidity, like Flint: https://github.com/flintlang/flint
The EVM itself isn't the end of the road either. Over the next couple years, Ethereum is migrating to a more scalable sharded version using proof of stake, and it looks like that will allow pluggable execution engines.
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?
EVM is not a language. EVM is deterministic otherwise the whole Ethereum would not function at all. Your criticism is directed more towards ie. Solidity. However alternatives are not availble as far as I know. There are some research projects but everything in this area is in alpha-research state.
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...
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.
Also consider Dante https://github.com/jyp/dante instead of Intero. Similar (not identical, see the README for a quick overview) feature set, doesn't require stack.
In math, we call it "variance" - as in invariance, contravariance, and covariance. They each refer to the character of a given functor between categories. A functor is covariant if a -> b maps to Fa -> Fb, contravariant if a -> b maps to Fb -> Fa, and invariant (otherwise known as exponential) if (a -> b) and (b -> a) map to Fa -> Fb.
Every example of variant functors follow these laws. It helps to say that every higher-kinded type which admits a type parameter (i.e. List, Array, Option, etc) can be seen as an instance of a Functor (in fact, in haskell, they are instances of the Functor Typeclass).
Variance is a statement about the functionality of containers given a pre-existing relationship between types they contain. In Math, keeping with the example set, the functor \pi_n : hTop* -> Grp is canonically covariant, while P: Set -> Set: s -> P(s), the powerset functor, is canonically contravariant.
In keeping with the Scala tradition, Option and List, which you can check obey the functor laws. For more info, see Scalaz or Cats.
1. Heat is not the same thing as passion. It's possible to be passionate, but still run into problems when discussing technology with people who are so convinced of their correctness that there is no actual debate taking place. This happens much of the time with younger devs coming out of college who are, for instance, absolutely convinced that the best way to do [x] is to use [y] technology or [z] paradigm.
As a senior dev on a team of scala/haskell programmers, we see this often. Speaking over someone is not the same as being passionate. People speak over women all the time - I have been on the receiving end of it from devs fresh out of college as someone who's published papers.
2. They were talking biological imperatives. Women's ability to have children dies at ~40. If they want to have kids, they need to get on it. No one said anything about women being only mothers and men being only breadwinners.
Reading you're comments, I'm supposing you're probably the redpill type.
