Professional programming is hard: dealing with large amounts of data, network requests which can fail in umpteen bizarro ways, and Gordian Knot style interdependencies. And then, to top it all off, there's all those different programming paradigms to choose from.
For example, in passive programming, communication between program modules happens through public function/method calls.
In reactive programming, communication occurs through publishing events to which subscribers react.
Both styles of programming differ in how they manage state [responsibility]. Both styles differ in how dependencies are expressed. And both styles differ in the strains put on you, the put-upon, well-paid programmer, trying to construct a mental model of the code and its interactions.
In the July/August issue of acmqueue, Andre Medeiros proposes that modules employ both approaches in Dynamics of Change: Why Reactivity Matters — Tame the dynamics of change by centralizing each concern in its own module (open, DOI: 10.1145/2956641.2971330) (DX). He provides an introduction to the two approaches — their advantages and shortcomings — and then illustrates how combining the two provides a clearer presentation of state for the developer.
(Score: -1, Flamebait) by Anonymous Coward on Thursday August 25 2016, @06:11AM
I make flow chart of the coding, you approve flow chart.
(Score: 2) by fleg on Thursday August 25 2016, @06:39AM
havent read TFA, but that sounds a lot like Robert Martin's "Single Responsibility Principle" which itself was another way of saying that most ancient of programming slogans "loose coupling, tight cohesion".
or has he got some new insight (yeah i know, i should read TFA!)
(Score: 0) by Anonymous Coward on Thursday August 25 2016, @03:58PM
Neither coupling or cohesion are well-defined. And in practice, things naturally intertwine in the domain. Intertwining is both the power and Tums of software.
(Score: 3, Informative) by meustrus on Thursday August 25 2016, @04:21PM
Coupling is a measure of how much two separate components depend on each other to function. This is a proxy for how many quirks a component has to maintain exactly as-is because other components depend on it working that way.
Cohesion is a measure of how often code within a single component is reused. This is a proxy for whether that code actually belongs in the same place, which itself is a proxy for whether the component is prone to too much coupling. It's easier to measure cohesion than coupling, however.
They are basically the same measurement, but coupling refers to the integration between components and cohesion refers to the integration inside a component. The only things that remain to be defined are what a "component" is (should be self-explanatory most of the time) and how to measure the two metrics.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: -1, Redundant) by Anonymous Coward on Thursday August 25 2016, @07:00PM
How exactly does one measure dependency? What is the unit of measure?
(Score: 0) by Anonymous Coward on Friday August 26 2016, @06:33PM
I'd like to see some actual examples against code
(Score: -1, Offtopic) by Anonymous Coward on Thursday August 25 2016, @06:54AM
Do not make me laugh. .......too late. HA HA HA HA
Sure OK. Put your GitHub profile up there, call it a portfolio. Go to interviews where they ask for a sales pitch of the projects on your GitHub profile. Interviewers ask you to clarify certain points of your documentation. Wait, what. Are they pumping you for information so they can get free support up front before they steal your work? You'll find out when you don't get the job, sucker.
(Score: 2) by Aiwendil on Thursday August 25 2016, @07:07AM
Did I miss something or are he just suggesting message passing? (Or possibly not exposing the internal of an object (ie, mimd the private/public)?)
(Score: 2, Informative) by quietus on Thursday August 25 2016, @02:48PM
Yeah, you missed something (you are, ofcourse, not alone in just skimming the article -- after all, this is the interwebbythingy we're passing electrons back and forth on).
The whole article is about [code] maintainability. Reactive programming is a natural fit if you've got some async functionality [network requests, data loading] in your program, and your language allows it. The author argues that it should be the default style of programming [if possible], as you can read what the module does directly in code. With 'passive' programming however, you'll first have to trace the different function/method calls -- i.e. check out the functionality in other modules -- before you can completely understand a single module's functionality.
Now, even if you work by default in reactive style, you'll encounter situations where 'passive' programming is a more natural fit -- think a centralized data store with its own built-in methods, or any other synchronous action. Where, [when] and how to combine both styles within the same module so as to get to cleaner, more elegant, hence more maintainable code, is what the article is about.
(Score: 2, Insightful) by Anonymous Coward on Thursday August 25 2016, @08:42AM
> Professional programming is about dealing with software at scale. Everything is trivial when the problem is small and contained
No! There are many, many, many problems which are difficult to manage even on one CPU. Ever tried solving a QCD problem? Or modelling a beam of 1e13 protons in the CERN booster chain? One approach is massive parallelisation, but it is not the only way to address this sort of problem, and even if you do go down the route of parallelisation MPI handles that stuff for you.
What about controls systems where reliability is the key? What about firmware/hardware where small memory footprint and low CPU usage are key?
I am almost angry that this guy thinks that anything that isn't a web app is "trivial".
Grumps.
Maybe I should try to get past the first two sentences of TFA now...
(Score: 2, Interesting) by Anonymous Coward on Thursday August 25 2016, @09:34AM
Even worse. Looking at the examples in the article, this guy writes business software in Java and thinks that dependency injection somehow replaces event handling.
(Score: 2, Touché) by quietus on Thursday August 25 2016, @02:59PM
Whooossshhh!!!
(It never occurred to me that looking at the pics alone would be a good way to summarize an entire article. A brave new world opens.)
(Score: 2) by meustrus on Thursday August 25 2016, @04:25PM
It's easy to forget that the hard problems exist, because we tend to drink until we forget when we don't get to work on them.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 1, Interesting) by Anonymous Coward on Thursday August 25 2016, @04:39PM
> ... easy to forget that the hard problems exist...
My tiny company / engineering consultancy specializes in hard problems -- we model highly nonlinear systems with multiple inputs and multiple coupled outputs. No shortage of work. Not for the faint of heart. Pay is OK (less than lawyers) but we get a lot of satisfaction. We'd make more money as quants, but where is the satisfaction in making rich people richer?
My best engineer-programmer has a great attitude -- we like problems, more problems mean more work.
(Score: 0) by Anonymous Coward on Thursday August 25 2016, @02:27PM
We are all Visual Basic programmers now
(Score: 1, Funny) by Anonymous Coward on Thursday August 25 2016, @02:47PM
Except for the blind. They use Haptic Basic instead.
(Score: 1, Funny) by Anonymous Coward on Thursday August 25 2016, @04:01PM
They get a Prickly Screen of Death
(Score: 0) by Anonymous Coward on Friday August 26 2016, @04:22AM
Pretty sure this is just the Observer pattern explained poorly.