Bemi Faison wrote: > Scott Sauyet wrote: > >> Perhaps in a more complex scenario? I'm trying to see how your >> example is more readable than a naive variation. [...] >> [...] >> So I'm simply not seeing the simplicity. > > Flow breaks down complexity into granular structures called "states". > Simple projects would only have few states, which would make such > structure seem like overkill. Complex projects benefit from this > structure, because encapsulation helps compartmentalize code. Flow is > useful since this structure scales (is repeatable), but does decrease > readability in smaller projects.
Is there some level of complexity that you can capture in a fairly simple demo that shows the advantages of your framework? Although I mostly understand `how`, even after a few days of pondering this, I still haven't wrapped my head around `why`. > Readability is also subjected to what you want to comprehend. Are you > reading code to understand _how_ something happens, or _what_ *is* > happening? Clearly both are parts of comprehension, but I'd argue that > the latter is more important. In order to write JavaScript, > programmers must deconstruct context (e.g., goals and purpose) into > actionable statements. Thus, "readable JavaScript" really means, the > ease with which we can reconstruct the context. If you've found > yourself studying code while mumbling, "What were they doing here?" or > "Where does this function go?", that's our minds trying to reconstruct > context. I find that readability is mostly about the ability to have well- named, short functions that perform clearly defined tasks. I try to write so that higher level of the code perform their work by breaking it down into smaller meaningful pieces, which themselves break down into still simpler ones, continuing this until the how the pieces themselves work are as straightforward as possible. There are plenty of times, when reading others' code that I do ask "What were they doing here?" and even times like that in my own code. But I'm trying to see how your Flows would remove or even reduce that. > I feel Flow is more readable when you're looking for context, as > opposed to actions. Action-based code (like your example) can be very > elegant and readable, but requires this extra effort of comprehension. > This is very much the difference between imperative and declarative > languages, and I've found value when mixing the two. Flow does this by > making context first-class members of your code. Can you explain more fully what you mean by making context a first class member of the code? I'm simply not getting it from the examples I've seen. >> What is the advantage of `targeting` versus `calling` beyond the >> tedium of coding wrappers where needed? Is it the more declarative >> definition? It's nice to have functions guard their own pre- and post- >> conditions rather than have the calling code have to check them, but >> does that make enough difference to call for a fairly intrusive >> framework to manage it? > > Closed systems make for confident systems. Related functions often > work with and rely on each other. In such cases it's important to > manage the state of their execution environment. If we only call > functions directly, we risk not managing that state, or requiring that > each function performs more concurrency logic. It is declarative, the > way a SQL statements tells the database (a closed system) to do > something, without worrying how the pre/post actions. With Flow, you > are "querying" states of your program, letting Flow handle what's > needed before reaching that state. I do understand the advantages of declarative coding. Much of the advancement in computer languages is a progression from imperative to declarative constructs, techniques, and languages. I believe also in closed systems, where implementation details are hidden behind smaller public interfaces. But I guess it's simply not clear to me where the lines are between the public interface and private details of a Flow- based system. >>> Plus, the _map_ construct masks the >>> underlying framework, letting external/existing routines remain >>> ignorant of the logic behind each "call". > >> Are all functions encapsulated this way public? Or is there a way to >> hide implementation details? > > I don't quite follow what you're asking. Flow does not provide direct > access to any functions. The "map" is a linked-list of closured calls, > which direct Flow to their corresponding. It's also a convenience you > don't have to use. You say that it doesn't provide direct action to functions, instead to "closured calls". I understand that what is exposed is a set of functions with access to a particular closure state. Those are still functions, right? :-) These are all publicly available, no? I am very much in favor of making any implementation details entirely private. I'm trying to see if Flow allows me to do so. -- Scott -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
