3 ms·
> Universities focus too much on mathematical formulas in my opinion; real systems are not clean and simple like a math function with few variabes. How many va
by runeks 9y ago
> Universities focus too much on mathematical formulas in my opinion; real systems are not clean and simple like a math function with few variabes.
How many variables your functions consume depends on how much you split them up, although you'll of course end up with thousands of functions for a real application, if they each consume ~3 arguments. So, in other words, the limitation is to what degree your language enables you to split up your application in tiny, obviously simple fragments.
Mathematical functions can describe anything. Haskell consists of mathematical functions, and is Turing-complete, and because of its purity makes it easy to split up your functions into tiny ones (or at least sufficiently small).
For example, this[1] module is a Bitcoin payment channel server I'm writing in Haskell. The module describes, mostly at the type-level, three different Bitcoin networks (live, test, test-derive), and presents an interface to the Bitcoin network, which either fetches information from the Blockchain or deterministically derives test transactions.
Everything can be split up into tiny pieces like this, it just takes time, as the purity prevents you from utilizing loopholes that later turn out to be unmaintainable. It forces you to understand the essence of what you're trying to describe, because otherwise you can't capture all the invariants properly without too much duplicate code.
[1] https://github.com/runeksvendsen/rbpcp-handler/blob/master/src/RBPCP/Handler/Internal/Blockchain.hs https://github.com/runeksvendsen/rbpcp-handler/blob/master/s...
- wvh 9y agoI think we're talking on a different level here. I'm rather thinking about the performance from an ops perspective. If you write highly specific code that runs close to the processor, of course predictability improves. But if you write a web application, possibly running in a virtualised environment, using remote databases and other network services, good look predicting performance to the end user. Even talking about tight loops, you simply can't predict if it will go and stay in the processor cache in layered, multi-tenant situations like that. There is little correlation between theory and practice of a complex system when it comes to performance and reliability. For example, big-O notation tells you very little about the myriads of wonderful ways systems and networks can crash and burn. Disks never failed in my university classes. The more you know about the difference between a perfect theoretical system and the harsh randomness of a real one, the foresight of experience, the better a programmer you are, and this is not generally knowledge that comes from formal education. In short, to be a better programmer, you need to know the difference between the best case ideal scenario and what is actually going to happen, usually when you least expect it...