Earlier quoted context omitted.
Yes, because some purely functional approaches cannot beat imperative ones when it comes to resource usage.
Could you give a concrete example?
[deleted]
Modern Functional Programming: The Onion Architecture
91–100 of 100 posts
Re: Modern Functional Programming: The Onion Architecture
#92Earlier quoted context omitted.
Yes, because some purely functional approaches cannot beat imperative ones when it comes to resource usage.
Could you give a concrete example?
I think the grandparent comment boils down to saying "there's no known persistent data structure with O(1) random access for read and write". Whether you need such a structure (for a cache, histogram, frame buffer, etc.) is up to you.
Some functional languages allow transient data structures (via something like ST or uniqueness types), so you can match the performance of any imperative algorithm at the cost of ugly code.
Re: Modern Functional Programming: The Onion Architecture
#93Earlier quoted context omitted.
Yes, because some purely functional approaches cannot beat imperative ones when it comes to resource usage.
Could you give a concrete example?
Hash tables are a big example. You can implement pure associative arrays, and they have some nice benefits, but the best functional implementations still have much poorer asymptotic performance than a basic hash table.
Pure data structures also tend to include a lot of extra pointers. That can create a lot of overhead. A pure list of 32-bit integers will need either 4 or 8 bytes of overhead (depending on whether you're running 32 or 64 bit) for every item stored. A resizable array just needs whatever empty space it preallocates, plus the occasional memcpy when it needs to add capacity. Also locality of reference and all that fun stuff.
Re: Modern Functional Programming: The Onion Architecture
#94Earlier quoted context omitted.
My own opinions on the matter aside, I don't fully understand why anyone who likes dynamic scoping would dislike dependency injection.
Because of things like: https://github.com/google/guice 4k LOC of "lightweight" garbage for... variable lookups?
So your issue is with the implementation? I can understand that, I guess. Personally I don't like either dynamic scoping or DI; it had just never occurred to me that someone might prefer one to the other.
Re: Modern Functional Programming: The Onion Architecture
#95Earlier quoted context omitted.
Yes, because some purely functional approaches cannot beat imperative ones when it comes to resource usage.
Could you give a concrete example?
Neural networks are a good example where mutable structures are the only realistic choice. You're dealing with fully connected networks of millions of nodes, each of which needs to be updated multiple times for each layer at every pass.
Re: Modern Functional Programming: The Onion Architecture
#96I'd not say this is a feature of functional programming. This is a feature of Object Oriented elements being included in fp languages. These are the same things we were going to happen when using Java and C++ years ago. You can even see similar graphics here: https://docs.oracle.com/javase/tutorial/java/concepts/object... I remember there was another in this tutorial that shared more with the image in this post. Alth…
As far I understand, the difference is that in OO you normally transform data as you jump from layer to layer, here what do you have assembled is a simple program that will be interpreted by the lower layer
Re: Modern Functional Programming: The Onion Architecture
#97Earlier quoted context omitted.
The graphics are both indeed circular which makes them look alike, but the meaning is completely different. In the OO graphic, it's representing a single cell organism, hence the circle. This is not the complete application. It's encapsulating the state of a single process, and only through externally interacting with the organism can the state be inspected & changed, all based on time. The circles in the FP represen…
Them being circular has nothing to do with what are they representing. They are showing off the idea of hiding implementation through abstracting it. This is the exact same concept that both of these photos are showing.
> Them being circular has nothing to do with what are they representing.
Please read my comment, that's what it says right after the first comma.
> They are showing off the idea of hiding implementation through abstracting it. This is the exact same concept that both of these photos are showing.
My comment breaks down how the hiding of implementation is completely different between the two, can you point what you think is incorrect so we're not talking past each other? Or is there anything you need clarification on?
Re: Modern Functional Programming: The Onion Architecture
#98Earlier quoted context omitted.
The graphics are both indeed circular which makes them look alike, but the meaning is completely different. In the OO graphic, it's representing a single cell organism, hence the circle. This is not the complete application. It's encapsulating the state of a single process, and only through externally interacting with the organism can the state be inspected & changed, all based on time. The circles in the FP represen…
Them being circular has nothing to do with what are they representing. They are showing off the idea of hiding implementation through abstracting it. This is the exact same concept that both of these photos are showing.
[deleted]
Re: Modern Functional Programming: The Onion Architecture
#99How does this architecture constrast with Rust? Has anyone built anything like this in Rust?
It makes me think of an article where the author tries to abstract the implementation of IO from the the domain logic. [1]
[1] https://blog.skcript.com/asynchronous-io-in-rust-36b623e7b96...
Re: Modern Functional Programming: The Onion Architecture
#100I didn't understand a word, and I bet 99% of people who clicked the link didn't either.
And there's the rub. I don't doubt this stuff is useful, and I'd like to know more. But it seems really hard to bring this stuff "down from the mountain" in a way that makes it easier to understand and utilize for us mere mortals.
Here are two blog posts on free monads that should be accessible for people who understand what a monad is and are able to read Haskell:
http://www.haskellforall.com/2012/06/you-could-have-invented...
http://www.haskellforall.com/2012/07/purify-code-using-free-...