Transparency is a great quality.
Submit an expense, get reimbursed and show how funds are being spent!
Transactions will show up here
Share this page and get backers and sponsors to support your collective!
We are ReactiveUI
We are an advanced, composable, reactive model-view-viewmodel cross-platform framework that supports both Xamarin (iOS, Android Forms) and Windows (WinForms, WPF, UWP).
Through contributions, donations, and sponsorship, you allow ReactiveUI to thrive. Your donations directly support meetups, office hours, continued enhancements, and most importantly, great documentation and learning material!
Long ago, when computer programming first came to be, machines had to be programmed quite manually. If the technician entered the correct sequence of machine codes in the correct order, then the resulting program behavior would satisfy the business requirements.
Then we invented a higher-level programming language: C.
Once more, if the programmer wrote the correct sequence of instructions in the correct order, then the resulting program behavior would satisfy the business requirements.
The 1980's: A Revolution in Software
The 1980's saw the invention of a new way to write computer programs: object-oriented programming. The programmer would write code that manipulated the data belonging to re-usable objects, and if the programmer wrote the correct instructions in the correct order, then the resulting program behavior would satisfy the business requirements.
After that, things got pretty boring.
Most modern programming today is basically imperative, meaning it models the traditional fetch-execute cycle of a CPU. Perform and instruction, fetch the next one. Perform that one, and so on. For decades, programmers have had to mould their brains to fit the paradigm of the CPU.
Imperative Programming is Dangerous
When we rely on hoping that the behaviour that emerges from a program is correct, and that reliance is based on nothing more than a programmer's correctness, then we can easily find ourselves in a sticky situation. We can try and mitigate the costs of imperative programming with things like unit tests or integration tests, but why mitigate the costs when there's a better way?
Instead of telling a computer how to do its job, why don't we just tell it what its job is and let it figure the rest out? Imperative programming is error-prone and relies too heavily on the infallibility of the programmer.
There is a Better Way
Instead of imperative programming, we can use a paradigm called Functional Reactive Programming which allows you to model user input as a function that changes over time, abstracting away the idea of mutable state. This is the peanut butter and chocolate of programming paradigms.
Reactive programming can look scary and complex at first glance, but the best way to describe reactive programming is to think of a spreadsheet:
- Imagine three cells, A, B, and C.
- C is defined as the sum of A and B.
- Whenever A or B changes, C reacts to update itself.
That's reactive programming: changes propagate throughout a system automatically.
This is possible thanks to all these people and organizations who contribute their time and/or money to support this collective. Contribute too!