Slashdot Mirror
Can Reactive Programming Handle Complexity?
Nerval's Lobster writes "A recent article on Reactive Programming, which suggested that five lines of Reactive could solve a problem that required 500 lines using Java or 200 lines using triggers, led many readers to question (passionately) whether Reactive enables you to address not just typical problems, but complex ones as well. In a follow-up column, Espresso Logic CTO Val Huber argues that, while it certainly can't solve all use cases, Reactive Programming is very capable of addressing many complex problems, and can address all other scenarios via a transparent integration with procedural languages. He shows how Reactive can handle complexity using two different scenarios: a classically complicated database application (a bill of materials price rollup) and procedural integration (to address external systems such as email and transactions not limited by a database update). Take a look at his work; do you agree?"
I disagree.
Can bullshit walk?
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
A few problems:
- What about circular reactions?
- Is SQL really that right language for encoding business logic?
- Triggers are kind of an anti-pattern.
- What about atomicity? What if I need the whole reaction chain to work or none of it.
I'm afraid there more questions than answers with this proposed pattern.
You must be British.
You can program reactively in Java?
I'm first.
... at sloppy seconds.
is that sorta like web 2.0?
active programming
re-active programming
quantum programming
recursive programming
state dependent programming
mindful programming
VR programming
genetic programming
dna programming
yep, the universe is a simulation
It's actively trying to find out how many ways it can screw itself over, and over, and over again.
Jerking off,
Masturbating,
you can't get past the fact that you're a seed of the universe, stuck in itself.
It is a tool. Like any other tool you apply it when your skill and experience tells you to. I belive the term commonly associated with this is "professional".
It appears that reactive programming would require an incredibly bloated and powerful backend. In effect, it moves most of the logic to the framework and allows the programmer to just hook a few pieces together. I can't imagine it scaling well with all the extra event notifications one would introduce. It looks like it would change from one event causing the execution of a chunk of code to multiple chained events triggering a conditional series of smaller chunks of code.
The problem lies in the overhead of notifications.
It might be "fewer lines of code" to write, but there's just no way in hell it could be as run-time efficient.
You are absolutely correct. What is needed is proactive programming.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
I concur.
I don't know what the 500 lines of java code are, but i guess they are grabbing input and cleaning it and opening database connections and whatnot. assuming that he's counting import statements and puts curly brackets on their own lines. sure 500 lines.
I don't know much about this Reactive stuff, but i don't see anything in this sample code that tells me where the input is coming from or where it is going to or if it's being cleaned in the process. Somehow Reactive also creates an environment in which nothing unexpected ever gets entered?
As background, I am the director of engineering in a small Java/Postgres-based shop. We run a cloud backend for our mobile apps.
This "methodology" reads from the first sentence like an extended infomercial for a consulting shop, or a company trying to create the aura of "thought leadership" to get more investment cash. The formula is simple and time-honored: (1) arbitrarily single out a well-worn software practice to receive a snappy marketing name and be held above all other practices, (2) claim it's new, and (3) offer to implement this bleeding-edge buzzword to clueless executives. For a small fee, of course. It's the same formula that gave us Agile.
In my opinion, what they've described here is a large step *backward.* Not only is this a relatively trivial use of the GoF Observer pattern, but bizarrely, it's done in SQL using triggers, causing immediate database vendor lock-in and creating a maintainability nightmare. It's how software was made back in the 90s when Enterprise SQL database vendors ruled the land. Sprinkling business logic around in the SQL instead of centralizing it in a much more suitable language for logic like Java is a completely terrible idea, unless you're an Oracle sales rep.
This one is safely ignored.
Having read TFA, it looks to me like all they have done is compared a schema which was not properly normalised, with something which was; for example the 'reactive' code calculates total cost as quantity x price, where as the author is conjecting that the SQL version would have a total-price field, and therefore have to have '500' lines of code to keep this field updated.
Smells like snake oil to me.
You have to ask, "Why would the SQL schema need a totalprice field?" ... then you have to recalculate the totalprice every time you look at it.
If your business logic says that the totalprice is always Q x price, then ditch the field and ditch all the code which enforces the relationship. But
There are other examples of denormalised data in the sample provided, and in all cases the 'reactive' code simply calculates the value on the fly - and as other commenters have mentioned, this blows up as soon as the business rule is no longer valid, such as "when a product's price is changed, DONT change the price on quoted or shipped orders, DO change the price on scheduled or reoccuring orders"
it might be a good way of prototyping and get an early set of working, testable specs. i don't like the approach, though, seems awkward, but that's maybe just me ...
What ever happend to Fuzzy Logic?
Sure, it may work exactly as hyped. But that doesn't matter.
Why would I want my hosting coupled to the framework I'm using, and to a particular database as well? If their hosting sucks, or if they raise their rates, I'm stuck.
No thanks!
This is just marketing hype dressed up as a question. Having said that, anything that gets anyone enthused about programming is good, I guess.
What I really don't like is when Val Huber refers to a previous article he submitted as if it were written by a third party.
Now, I love SQL (and triggers are ok) - and so does Val Huber - I'm sure we would get along fine.
Val, you've been doing SQL for 20 years! woot. So that means you started back 'round '94.
(Aw. I started back in '85. I was doing websites in '94 - remember Lycos?)
But it's just using SQL Triggers, Val - why give it some sort of fancy name? Ohh everyone else does that, like "Web2"? or "The Cloud", etc?
Still stinks - but hopefully someone may actually pick up how to use some of the cool features of SQL.
This comment was written with the intention to opt out of advertising.
I've done reactive programs. They make fun little interface gizmhos. But holy shit, try debugging something that does something complex. You can't assure when, where and how variables might be changing in some outer reaches of your program while another part of the program is assuming they are momentarily fixed. It's going to be unpossible to seriously optimize a reactive program.
So yeah for silly data base queries of simple mathematical calcs go for it. Complex programs. run away
Some drink at the fountain of knowledge. Others just gargle.
Actually, I think VR programming would be useful. Imagine this: instead of needing to purchase 2 or 3 monitors to see all the information you need (and still sometimes needing to change what takes up a whole screen), you could wear something like the Oculus Rift, and have as many virtual monitors around you as you need.
By the way, I thought I'd add, the only reactive style language that I've really found could get modestly complex and still not be incomprehensible is Lab view. It's event driven, and the you can literally see where and how a variable is being modified with the wires it draws (unless you like using globals. The problem with labview is feeding a wire through a lot of graphical levels is so annoying that you end up resorting to globals more than you should.). Labview takes a really different mind set to do well but anyone can be crappy at it and get the job done. It's the only program I've felt comfortable modifying in the middle of an experimental run. It's just really robust in that the errors one makes tend not to be fatal. Maybe it's because visually you can see the logic and know the scope of any side effects. But major application complexity? nope. Get complex interfaces hacked together fast? yes.
Some drink at the fountain of knowledge. Others just gargle.
It is a tool. Like any other tool you apply it when your skill and experience tells you to. I belive the term commonly associated with this is "professional".
My experience is that nearly anytime you see a problem reactive programming could address you would be better off designing a program in which evaluation is lazy, and every calculation is memoized. Spend a little time designing for laziness and memoization and there's no need to lock everything into being based on a reactive language.
Some drink at the fountain of knowledge. Others just gargle.
A lot of what is in the example reminds me of a 4GL I worked with in the 1980s that had a feature called "computed fields". The idea is extremely nice conceptually, and seems to nest nicely, as well as be easily integrated with other functionality. The main problem is performance. Some pretty smart people worked on the tools, but (with the complexity of real life systems) you tend to end up with the same values being continually recalculated. It turns out that (because of the generality of the functionality, and the inability to predict when values will be updated or queried) it is extremely difficult to suppress these duplicate calculations. A typical application developer will create code that results in values being recalculated thousands of times in a single transaction. The problem is both worse and more intractable than is experienced with computed columns in spreadsheets.
This is stupid. Posting back to Slashdot BI. I'm really really close to leaving. Thanks for killing slash dot dice.
I'm a fan of reactive programming, it's pretty neat. However, the article cherry picked the scenario that perfectly fits reactive programming. Furthermore, calculating a couple formulas is hardly complex, show me geographically distributed caches kept in sync with a few lines of code and I would be more impressed.
I came to the datacenter drunk with a fake ID, don't you want to be just like me?
Show me a dozen enterprise apps written in this style that work well. I don't care about sample methods. There are plenty of developers who have rewritten Excel documents into Java applications with proven benifits. Where are the testimonials for doing the opposite? Is Amazon using this for its shopping cart? Did NASA use it? Are big open source project being made with it?
If you want to learn how to do it yourself I am writing a whole book on the topic, "Dataflow and Reactive Programming Systems" http://dataflowbook.com/
This seems like a magic version of logic programming. Rather than defining precedural instructions, you provide a set of rule that a logic engine then uses when accepting input. My understanding is this is how Prolog and Datalog work, an example being Cascalog in Clojure where you define a query and the logic engine will infer the necessary joins and such to make it happen.
Generally this model of thinking appeals to me, but in practice it is difficult to get right unless your language has explicit support for it. Functional languages with tools like pattern matching and multimethods are a great example of supporting this kind of workflow.
In some ways I can see the model handling extremely complex problems. With that said, the reactive programming model seems like it misses the advantage by simply reacting to changes in input. As others have mentioned, what happens with circular reactions or highly inefficient operations? A logical programming model allows for an engine of sorts that analyzes the "reactions" in order to find where it can be optimized as well as decide whether it is flawed.
Obviously a logical programming model is not a panacea, and I'm not an expert, but it seems a more genuine attempt at handling the sort of complexity that reactive programming aims to solve.
We would all be programming in Perl, or better yet, how about APL?
Reactive programming as a concept is pervasive in hardware description languages, such as Verilog and VHDL. These languages are largely event based, support concurrent function evaluation, deferred assignment, etc.
The Americans considered themselves the winners because afterwards America became an entirely separate country. The British considered themselves the winners for exactly the same reason.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
This seems extremely similar to tasks in ada. The variables are in the sensitivity list.
brandish elegantly terse accessors!
address not just typical problems, but complex ones as well
If they find that complex problems are not typical, that tells us a lot about the scope of their experience.
Are we in the great circle of IT change where the business logic is being taken back to the data-level where it was originally before the joys of middleware. Used properly database triggers are the perfect place to enforce business data rules - because you cannot enforce them at a lower level.
Are there specific use cases or patterns where reactive programming may excel, and be integrated into a more traditionally developed system (to minimize reactive complexity through human written code complexity - no way around the complexity...)?
I have no reactive application experience, just wondering if it is possible and if it could be beneficial.
BlameBillCosby.com
Please tell me the browser cache is screwing with me. Please tell me that my wife wants to have sex more often ( ok that isn't going to happen, I have a 12 and 15 year old) Do we really have Slashdot.org back?
It is basically the same deal over and over. We need to reduce complexity in programming, so we build yet another abstraction layer. We hide the complexity from the programmer and deal with it in the infrastructure, thus creating more bugs and worse performance. The bugs get (very) slowly fixed and the performance issues are compensated by evolving hardware, which takes a few years. Such is life. If it were not for some initiatives like this one, SAP would be written in machine code.
That is not to say that this is the solution to all problems, neither that this is even the best alternative for anything, but it's just the way that software evolves, and as such, time will tell.
If you specify the same memory area in an application for your variables you open up the application for some serious illegitimate usage. It looks to me like using database triggers is pretty much the same thing. However, if someone has sufficient access to your database they could just make their own "triggers". It is a cool concept though.
Having to work for a living is the root of all evil.
This is the 3rd Reactive article in the past year. Whose dick at Slashdot is Val Huber sucking?
Each time it's this PR-ish piece on how his Reactive Progamming model isn't such a bad idea. How the hell does he get these articles to run when so many other good articles get shot down?
STOP IT SLASHDOT. No one wants your Reactive Programming marketing articles.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Aren't these called constraints or propagation networks?
Structure and Interpretation of Computer Programs and Higher-order Perl have got something to say about these.
Reactive Programming (RP) is just flow based programming (FBP) which has been used successfully for 40+ years. Modern RP adds some nice syntactic sugar that makes it more feasable. I have been using RX https://rx.codeplex.com/ some time ago and am pretty happy with it. It combines very well with f# and functional programming. Always try to isolate small autonomous components and test them seperately with http://blogs.msdn.com/b/rxteam... and http://visualrx.codeplex.com/ . Here is a free book about FBP http://www.jpaulmorrison.com/f... You get comparable easy message based concurrency but you have to take care to stay synchron as much as possible because it can get complex pretty easily.
all /. articles on the subject load, then reload, then reload, then I close the tab.
So, I have no idea what all this is about.
If reactive programming is so great, why didn't he show us the sendMail function as a reactive method instead of an, "external procedural function." Also, these guys seem to have their heads in the clouds, as if requirements would be as simple as, "send an email." I had a boss who asked me to do something similar and he ended up later adding the following requirements all of a sudden. Note: This was a custom exe that I wrote that ran when our cruise control built a project (not ccnet or jenkins which would have had better email support, and also they didn't have time for me to set something new up or learn a management system so they just wanted me to code a solution so they could ship their product on time):
1) send the email to a set of groups of email addresses on a case-by-case basis, the groups were stored in an xml file (manually designed by another team, no schema)
2) customize the subject with a unicode checkmark on success or failure
3) oh and my client wanted the subject colored differently, but settled on me skipping that
4) send the email via gmail programmatically using tls on a specific port (couldn't use 443, 25, 465, etc. however 587 worked, but this was subject to change in the future as needed) because our network admins had blocked smtp delivery ports
5) must check the ssl certificate for validity when negotiating delivery of the email, drop it if auth failed and just write a log statement
6) flag failure messages as important in outlook, i.e. request outlook show a red flag on the email so outlook can filter / sort by importance
7) the content of the message must be rewritten from plaintext in custom generated html at the time of delivery based on a template
8) compress the contents of a directory in an archive and attach to the email
9) also save the attachments to a network drive along with a copy of the content of the message as a text file, creating paths as necessary each path representing the project & build #.
10 The network drive has been known to lose connectivity from time to time which can cause your data to fail to write, so be sure when copying the data to the drive to guarantee the save over a network. I'm giving you a heads up on that one, because it was something I encountered not something we prepared for or that anyone was aware of.
Oh, and they had this weird requirement that it all be written in perl, which I didn't know at the time. Which was ironic considering they didn't want me learning new software at the time. The reason was that another team had in a sister company had already written a big nasty perl script for maintaining the CC and they didn't want to have to reinvent that work.
Anyways, apply reactive programming to the above without using external procedural methods and enjoy. Don't forget you have a standard working day to get it working because this is blocking everyone on the team from properly testing their code. Oh, and it has to be practical if you do attempt this, no monkey business e.g., "call to some method that will be defined elsewhere that you should assume works in theory." That's magic not science.
Methinks reactive programming is a nice academic study, but when it meets the real world you're going to have to roll up your sleeves and call in the real engineers to make anything actually happen. Customers and feature owners have unrealistic expectations, short deadlines, strange requirements, sudden added features that don't fit into your perfect scribbles on the napkins, oddball software requirements, and oh btw they need it yesterday.
In several cases involving UI design, the programming paradigm is event driven. Too many times, events get out of control.
The Mediator Pattern handles some of the pifalls.
Using this pattern, events can be used in several layers:
UI Event -> business tasks -> model changes -> UI change to reflect model.
Just make sure you define a clear flow of events and that there are no loops.
At first glance, this looks like an article about a new programming technique. I was immediately sceptical, but took a peek because the example (a bill of materials) is something I've actually worked on in the past (for the building industry). It quickly became apparent that the article is:
1) Written by someone who either doesn't understand the problem domain, or is plain dishonest
2) Presents a product, not a technique/methodology/process.
Adopting the same approach, I could tell you that our solution solved the problem with a single line of C++ - but let's call it Abracadabra Programming for effect:
activeSnapshotTree.calculateQuantities(activeSnapshotFilter);
This is genuinely the single line of code that rebuilds a snapshot of the current bill of quantities (filtered according to the project timeline, classifications, tags, recipes, etc). Clearly Abracadabra Programming outperforms Reactive Programming. Instructive? Not really - unless you were looking to license our development framework.
I've always enjoyed reading Slashdot over the years. It's covered a lot of material and hosted innumerable discussions that would alternately baffle or bore almost everyone I know, but it's been beneficial and instructive for me. That all seems to be slowly and gently sliding off a cliff. There's a steady influx of brainless novice articles and poorly disguised advertisements (like this one). Am I alone in finding Slashdot of decreasing interest and value? Is there another site to fill the gap?
finally proven wrong?
So really, what is reactive programming trying to accomplish here? Can I write tight, fast code that is sustainable over the long term, or is it just another stupid fucking thing bad developers insist they need so they can browse the web while the company struggles under the weight of their shoddy software?
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
TFA - TL;DR
Can you write a test suite in the time this tool saved in coding?
I didn't think so either.
programs like
1)Spew shit
2)take creditcard number
3)stickit on a list
Is that the kind of task they think is 'complex' ?
building block langauges are only as good as their building blocks and if one you need doesnt exist then 'too bad'
Is this the system they built the obamacare websites with?
Who needs this new thing when BASIC did all the 'Simple' things already 25 years ago??