Slashdot Mirror
How Reactive Programming Differs From Procedural Programming
Nerval's Lobster writes "A recent post on Reactive Programming triggered discussions about what is and isn't considered Reactive Logic. In fact, many have already discovered that Reactive Programming can help improve quality and transparency, reduce programming time and decrease maintenance. But for others, it raises questions like: How does Reactive differ from conventional event-oriented programming? Isn't Reactive just another form of triggers? What kind of an improvement in coding can you expect using Reactive and why? So to help clear things up, columnist and Espresso Logic CTO Val Huber offers a real-life example that he claims will show the power and long-term advantages Reactive offers. 'In this scenario, we'll compare what it takes to implement business logic using Reactive Programming versus two different conventional procedural Programming models: Java with Hibernate and MySQL triggers,' he writes. 'In conclusion, Reactive appears to be a very promising technology for reducing delivery times, while improving system quality. And no doubt this discussion may raise other questions on extensibility and performance for Reactive Programming.' Do you agree?"
not re-active! ;-)
Paul B.
There really is no such thing, they just made up the term for attention. What he is describing might be called "tools" programming, but it's not new or different. I have written "Tools" in various languages for over 20 years. If they think they are going to market a few bucks with a "re-branding" program good for them. It worked for "Cloud" and I knew better then too.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Hello, Paul. How are we doing this evening? ;)
We used to make websites by regenerate all html pages when the database changes. It delivers really fast then.
How does RP handle dupes?
I know I put in my $0.02 previously, so I won't bother again.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
1) The proactive, forward looking teams adopt it first, and have great success.
2) The "emerging trend followers" hop on board, and have reasonable results.
3) The rest of the industry follow and have mixed results, without it being any more successful than any other methodology.
Don't be blinded - initial results always look very promising.
Anybody around here remember Jackson Structured Programming The initial OOP wave? The whole CASE moevement? GUI application builders that were supposed to end the need for programmers?
The golden rule is that "whatever methodology technology you choose, half of adopters will always get sub-average results". The question you have to ask yourself Is are your team smarter than the average team?
Yet another super awesome framework/system/language/whatever to make a shopping cart in as few lines as possible.
The someone tries to build something remotely complex and it all falls to shit and the code ends up as spaghetti.
The guy who built it then leaves the company and they can't find anyone else with the skills to understand how it works
The problem is not the model, but the idea that one size fits everything.
And the biggest problem is that the management, and very often the developers are unable to switch between the different approaches.
It is simple, you want something fast and dirty, and right now? REACTIVE
You got the market, and now is time to make your product stable and reliable? SWITCH TO CONVENTIONAL.
As simple as that.
Point proven.
Sig Battery depleted. Reverting to safe mode.
Buzz words! Get your red hot buzzwords! These buzzwords are fresh folks! No one's even figured out what they mean yet! You snooze, you lose! You there, little boy, I bet you could use Web 3.0!
The world's burning. Moped Jesus spotted on I50. Details at 11.
Sounds like the spreadsheet engine has grown up!
Isn't reactive programming essentially a repackaging of Table Oriented Programming?
"First they came for the slanderers and i said nothing."
this is just rebadged functional programming, except using deliberately confusing syntax
Snowden and Manning are heroes.
This article summary ends "And no doubt this discussion may raise other questions on extensibility and performance for Reactive Programming.' Do you agree?""
But a superior ending would be "Don't you agree?"
Because any response to "Don't you agree?" is better for marketing FUD because any potential answer ("Yes", "No") can be interpreted with being in agreement with the leading question?
(This comment is revelvant specifically because the term is "Reactive programming" is a worthless marketing buzzword and I am staying on-topic discussing how to improve superior ambiguity. And I can argue it is revelvant because "revelvant" is not a word and can have any retroactive intended meaning! So double the value of this post in the marketing department!)
Priest: "Universe from nothing, no laws of physics, sped up time"+ huge discrepancies. Creationism? No. Big Bang Theory
This is commonly known as creating a reusable framework and does absolutely nothing to change programming, of which database programming is only a small part anyway.
Another great trolling headline from Slashdot.
yeah...see this is true, and my question is WHY?
this happens predictably (at least for any rational person who looks at how this part of the computing industry changes over time)
but still people spend good time/money, sometimes lots of a few people's time, to make another and the cycle starts over again
is it possible to interview for a company, or be the head 'coder' during a major decision time for a new client or product, and just say, "No, from a coding perspective this is theoretically possible but it can't be done. This is bad design and we can code something that has this function and meet our quality standards."
can that happen?
Thank you Dave Raggett
Absolutely...there's not nearly enough RFC 6921-compliant applications.
Articles like this really annoy me. There are so many things wrong, it's hard to decide where to start. He concludes in favour of reactive by comparing java and mysql complete with all white space, comments and declarations, with a few bullet pointed reactive expressions in order to fluff up the numbers as much as possible. He makes no attempt to give a balanced viewpoint and makes conclusions based on false statistics and insignificant results. I've seen many so-called experts write junk like this to promote whatever their shiny new API is over the years. Most of them have ended up in limited edge systems, maintained by developers who would rather be doing anything than dealing with the nightmare.
Reactive might be a good idea, but I'm tired of dealing with people sucked in by junk science like this.
For example, the "Purchase Order" entity includes a reference to a sales rep. From it's inclusion we infer that is important data, so it would also need to be added as a "reaction". There's also no hint on how these "reactions" are actually implemented. The original article claims that consistency is enforced but doesn't really explain why.
The above might be what they mean, but that's not sufficient for consistency. If your database field is merely a duplicate of derived data in other entities, you shouldn't pat yourself on the back for avoiding a problem you created in the first place! You can also overlook a use case in the analysis phase too, and then you'll fail to include it regardless of the framework.
I think I'd like to see an example with all the entities included and some normalisation. Then maybe I might be convinced that RP has any advantages over triggers.
Plan My Week for iPhone
See JBoss Drools, JRules, Blaze, etc.
This is nothing new. You can wrap up the complexity of the code in a toolkit/framework/library but this is just functional programming driven by events. Nothing to see here. Move along. Don't believe the hype.
"As flies to the wanton boys are we to the gods; they kill us for sport." - William Shakespeare, King Lear
from what i've read on wikipedia, "Reactive Programming" is really just function as a variable with caching.
example:
c = 5 // outputs 9 // outputs 10
b = 4
a = b + c
print(a)
c = 6
print(a)
this isnt rocket surgery
Anons need not reply. Questions end with a question mark.
Their presentation makes analogies between "reactive programming" and spreadsheets and specifically references the power of "chaining" to have multiple functions firing as the result of changes.
There are a number of issues with this kind of event chaining that you run into as you get past the toy cases.
1) Fan-out. How many actions are being kicked off by a simple change?
2) Latency - this is a direct corollary to the fanout. Are all of the chained functions being run synchronously? If so, what happens when someone introduces a very slow function that gets run as the result of a user input. So the user changes the price of a part and every purchase order in the system is suddenly being updated?
3) Synchronicity - of course, as soon as you find out that your synchronously run chained functions slow things down you start running them in the background. Now, you have a problem where you don't know if something is up-to-date or not. And, in this model, it's not possible to find out if something is up-to-date.
The examples that they gave are very poor use cases for triggers even. Most general ledger systems I've looked at, running on top of a database, would just recalculate the balance on demand. If your database is large enough that the recalculation starts to take significant time, you cache the result and invalidate it using a trigger. Most GL systems typically make entries much more frequently than they need to calculate the balance for an account. If the recalculation of the balance takes significant time, you probably don't want to do it every time an entry is made anyhow.
Stored procedures and triggers are already here and I see no evidence that there is anything new here. If the database is in a correct normalized form this will not reduce the amount of code one iota.
Do ***NOT*** put this sort of logic in the application code. Use properly written stored procedures, foreign key constraints, and database triggers and don't let "application" programmers (especially not agile ones or those who invent new terminology for well known and previously solved problems) within 100 miles of the logic.
And as far as the users being able to understand it "better" I have only one word to say: Bwahahahahahahahahahaha!
To me, the whole idea is already well addressed within the SQL language. You're either talking about setting up a good definition of business rules for your data (DDL) or creating another way to look at your data (Views).
While there is room for improvement in the way that SQL defines (and especially exposes) the final definition, it's so far down the path to what the authors contemplate that I don't see why taking a different approach makes any sense. Maybe handle this information at the interface between the database and the application(s)?
The example logic provided would be very valuable information for SQL's Query Optimizer to have in planning how to execute statements. At large volumes of customers, it becomes very important to consider the performance impacts of defining and enforcing logic - you always should (to the best of your resources and ability).
During the age of NoSQL: have people forgotten about the benefits of the tool that was 'holding them back'?
I've been looking at ways to make CRUD applications "declarative" using almost nothing but data dictionaries (field tables) and attributes. It can be done for relatively simple and controlled scenarios, but if you have unanticipated requirements or are stuck using an existing database that has built up years of baggage/cruft, then it requires custom interventions.
CRUD is conceptually relatively simple, but the devil's in the details and those details can really be devils.
Yes, you can simplify CRUD by making certain presumptions. However, if you have to violate those presumptions, then your clean abstractions take a big hit to the nuts and the fixes are messier than what you'd get hand coding most of it from scratch or from minimalist libraries.
That appears to be "trick" used here: when your scenario lines up nicely with your framework's assumptions, the framework handles most of the grunt work like magic. It's essentially a circus trick for the naive.
Until the day CRUD is somehow finally fully tamed with a great framework that handles all the goofy needs of specific shops, my preferred compromise is to use "smallish" abstractions, AKA "helper routines" that can optionally be used to simply things, but are NOT required. I like to say you need a way to: date your abstractions, but not marry them.
And these components have sub-components that can be partially used as needed also so that I only have to reinvent 1/3 of the wheel if I can't use the whole component. That way real-world requirements that "break" my larger-scale abstractions don't entirely boot me out of the framework (to be left hand coding all the details) because I can still use most of the smaller-scale abstractions that the bigger ones were built out of. It's kind of a fractal "next resort" down the abstraction ladder.
It's not perfect, but a decent compromise between hand-coding all from scratch and (alleged) do-it-all frameworks (like TFA) that are not flexible. But, you do have to know the parts well.
Table-ized A.I.
Ok, there are a lot of people commenting on this below who have absolutely no idea what reactive programming is about. So I'll try to clear it up a bit.
Reactive programming is not polling.
If you call a function and wait for it to return a result, you aren't doing reactive programming.
If you are working in a REPL or command-line environment, and you have to type a command every time you want to obtain a result, your system is not reactive.
Reactive programming is not events and triggers. Well... let's say it this way: reactive programming is to events/triggers as writing in [C/C++/Java/C#/Haskell/etc.] is to writing in assembly. In other words, you really could do the same exact thing with events or triggers than you can do with reactive programming. But events and triggers are very basic compared to what is meant by reactive programming.
Events and triggers are typically used when a little reactivity is needed. When you build your system around reactivity, using events and triggers quickly becomes inefficient and you need something built for the task. You would pick a reactive programming language or framework for such a complex job, just like (most of) you would choose high-level languages and frameworks over assembly for building a social media website.
Reactive programming isn't an agile framework. It's not some new way of describing object-oriented programming. And it's not the right tool for every job, but for some jobs, it's the perfect tool.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
That is one of the least informative articles I have read in a long time.
In fact I feel dumber for having read it.
It picks numbers out of thin air for the "standard programing" model,
then it has some magic pixie dust that represents the result in
reactive programming as a few lines of code.
I was thinking along the same lines, except that I would say 'relational' rather than 'SQL' because SQL is neither the only nor the ideal implementation of the relational model.
In one significant way they are different, however. Part of Codd's insight was that the deductive power of his model should be less than Turing-complete, so that issues of undecidability don't arise (triggers were not part of Codd's model.) This restriction made automatic query optimization and reasonable transaction times feasible, while those (relatively few) problems requiring the power of a Turing machine could be handled in a Turing-equivalent host language.
In contrast, the proponents of 'reactive programming' seem to be wandering into the realm of logic programming, which has been around for at least 4 decades (Prolog), without giving any indication that they are aware of its pitfalls.
I've been learning QML (Qt's declarative markup language) and it works this way.
Values for properties of UI elements are expressions that can refer to other elements' properties. When the values of the properties in the other elements change, this element's property's value changes as well.
Just like OOP eventually breaks down into CPU instructions, and you can use any Turing complete language to implement anything, I think he has a fair point. It sounds like a way to design a language so that complex event/trigger type stuff are easier to implement and debug systematically, perhaps using a slightly different way of thinking. It might not be a fancy thing, but I don't think there's anything wrong about giving it a name.
Don't kid yourself that it isn't fundamentally a style implemented with events.
I suppose that's why I said:
... you really could do the same exact thing with events or triggers than you can do with reactive programming. But events and triggers are very basic compared to what is meant by reactive programming.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
It's a level of abstraction. If the only difference is that a "reactive" paradigm allows you to write the same code in less lines, each of which is less complex, it's an improvement over creating events/triggers. I don't know whether that's actually the case, but if it is, the above applies.
It looks like most any comments on that article get pruned pretty quickly. Post a thoughtful critical comment and watch it disappear.
Also, who in their right mind would want to obfuscate all of their business logic across a number of database tables? Sure, maybe it's less code but if it's not something that can be understood by someone other than the original developer, it has little long term value. Developers get thrown under the bus all of the time, I say write your code (and use "clean reading" technologies) as if it were to literally happen and some poor soul needs to try and pick it after.
I'll take 100 lines of readable code over 5 lines of obfuscated bullshit any day.
I don't know Val Huber, but can judge his "technology" ( hardly worth that name, though ) by what he is doing: putting the logic of a server-side application inside an RDBMS. After years and years of Hibernate applications with abysmally bad mainainability, now that finally finally finally-thank-god there are mature no-SQL databases, this guy goes back to where we were in the 80s.
Moreover: comments on that article simply get suppressed. Which says enough about this guy's capability to sustain critical thought. Dupe. Total dupe.
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
Lead, Follow or get out of the way!
try this with any real-world problem beyond this simplistic example and you'll be so deep in a mess that you'll yearn to have even COBOL back.
also good luck becoming familiar which such a codebase (er, trigger base) after just 3 months worth of iterations. the only reason for such an approach to imply "reduced maintenance" is that it would be absolutely unmaintanable. real world apps don't have 500 loc, they have more like 500k. good luck grasping the behaviour of a system staring at 200k worth of triggers. so now, good boy, go ahead and change just one of them and be fascinated by the impact. oh, these kids with their brand new macs ... i lov'em, they are soooo funny and they make us old hacks soooo indispensable! :-)
Give it as many names you like, but bondsbw is on a posting spree trying to convince people that reactive programming languages doesn't have to us CPU cycles to call functions.
They were handing out the blue pills, not the tasty yellow ones. So, not so good.
They make me feel like I've been chewing on aluminum foil for an hour.
Sleep your way to a whiter smile...date a dentist!
... you really could do the same exact thing with events or triggers than you can do with reactive programming. But events and triggers are very basic compared to what is meant by reactive programming.
I kind of get the diretion you're going in, but I stil don't see. can you give an example? I see your analogy about C++ versus assembly but I only really understand it because I nuderstand C++.
Presumably reactive programm automates some (how/what?) or many or most of the difficulties away...
SJW n. One who posts facts.
You've told us what it isn't. That's as much use as telling us that strawberries are not yellow and curved.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
But... but... last week I was supposed to do _functional_ programming, because it's so much better than procedural/imperative. And now they're telling me _reactive_ is the new hotness. Damn. I'll never get this HelloWorld done.
Sounds a lot like excel is changing it's name. I'm not sure that this programming technique is anything other than the brackety crap you type into the tiny text box at the top of an excel worksheet... you know, that thing that leaves you wanting a programming language for anything more complex than summing a column or sticking two bits of text together.
In other words, you really could do the same exact thing with events or triggers than you can do with reactive programming. But events and triggers are very basic compared to what is meant by reactive programming.
You have a fundamental lack of understanding, not only of events and triggers but also of what a paradigm is. The limits you have encountered are language specific and has nothing to do with the paradigm itself and everything that is possible and efficient in "reactive programming" is just as possible and efficient in languages with proper event support. Mostly those are different variants on basic since lower level languages don't try to hide what the CPU does in that manner.
The thing with different paradigms is that you can implement them in pretty much any programming language. You can write object oriented C or assembler. In fact that is a great way to get a structure in your code in those languages. You can write procedural code in Java and C++ and that way avoid many of the problems those languages have.
You can write event driven code (Or interrupt driven or whatever you want to call it.) in C and assembler too. Solving the same problem in the same language but using different paradigms is a great way to point out the benefits and drawbacks of each method.
If you somehow think that reactive programming is different from one of the traditional paradigms, then please write a concrete example on how they would be different in the same language because at the moment I am pretty convinced that you are a shill.
... in a schema ... nice! Not.
From the linked article:
Enhanced Quality
Encapsulating logic into database column definitions (across a variety of possible architecture) ensures automatic reuse of the logic across use cases.
I nearly fell of my chair.
The point of new paradigms in programming languages is to make the complexity of the expression match the complexity of the idea being expressed, not the complexity of the (platform specific) implementation.
Crappy illustration:
C++ - Event-trigger
// event
// trigger
// actual code you want to get around to actually writing
// some routine that modifies a continuously
vector triggers;
void add_trigger(Trigger * t);
void reactive_variable::modify_value(int new_value)
{
this.value = new_value;
for (i = triggers.begin(); i != triggers.end(); i++){
i.react(new_value);
}
}
int main()
{
reactive_variable a;
Trigger *b = new Trigger(COPY_VAR);
a.add_trigger(b);
Trigger *c = new Trigger(ADD_VAR, 1);
a.add_trigger(c);
a.modify_value(2);
enter_event_loop();
return 0;
}
Incomplete, inelegant and probably buggy, but you get the picture.
Verilog - Reactive
assign b = a;
assign c = a+1;
inital a = 2;
always @(posedge clk)
a = count(input);
Easy to understand whats going on and spot errors. 'b' will always equal 'a' and 'c' will always be one more.
so Reactive Programming is basically syntactic sugar making event handling a bit easier.
Fair enough... though I can't help thinking of Node.js and all those callbacks being heralded as a new revolution in programming when I hear about this stuff. As an old fart, I know there's nothing really new... just kids who think they need any new paradigm because they never had the balls to learn how the old stuff worked.
Reactive programming is based on the totally opposite concept of COME FROM statement. Waiting for a future Dijkstra to write a paper on how evil COME FROM is.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
So what you're saying is: reactive programming is to software development as zombo.com is to the web?
Actually, that's a good illustration, thanks!
Especially the bit about hardware. I guess if = just means a wire, then if one side changes, then so does the other. I guess you'd have to insert a D-latch to make it non-reacive. I guess nothing in the assignments is clocked.
I expect with care and crazy templates you could make a reactive framework for C++ if one chose.
SJW n. One who posts facts.
There was once a language called magic that allowed this to be done and was really good at it. A bank wrote their system with it. Then 5 years later someone tried to re-write the banking app. 10 years later they're still reverse engineering the original app to provide the functionality.
as it is eaten so it shall pass
Read the story about Clever Hans and you will see how reactive works vs proactive. You will see the flaws.
Before I read your post, I didn't have the first clue about Reactive Programming. Now I know five things that it isn't! Thanks, bondsbw.
The downside of reactive programming, however, is exactly the same as the downside of the event/trigger logic that has been available in databases for decades, namely the difficult-to-trace side-effects caused by out-of-order execution that is basically mandated in reactive programming.
It's not so obvious when you're first writing code, but it's a headache when you're maintaining it (I disagree with the article on this point). Take the example in the original article... let's say you go back and add a requirement that people can pay for multiple invoices at once or for partial amounts. You have to check every single trigger to see if it refers back to the original payment information and adjust it accordingly. You'll have to change the data model to handle partially paid components (currently "paid" is a boolean), and any trigger that reads or modifies "paid" will have to be adjusted.
This alone isn't a problem -- you'd have to make similar changes in OOP, procedural, or functional languages... the issue is that in those languages you're more likely to be able to trace the dependant code and understand the flow. If you have access to the entire code base, you could search it I suppose, but each trigger operates like a "COME FROM" command in INTERCAL... it's as if your code is running along operating and all of a sudden an execution branch just pops in, performs some change, and lets you carry on, without telling you. I've had to debug some brutal issues caused by this sort of programming and it's difficult precisely because you're not sure where the execution path is coming from nor in what order it's being executed. It's almost entirely un-auditable once it gets complex enough to perform real-world tasks. If this was a real-world billing system, you'd have payments, refunds, discounts, credits, and a dozen other bits each making each "reaction" more complex. Each would require its own line of reactive code and each would depend on at least several of the others, and it's very easy to lose track of what's going on.
I realize people can write bad code in any paradigm, but bad code in reactive is far more difficult to debug, fix, and maintain, IMHO.
So it's basically LabView/VI except more confusing. Just what we needed.
Seing the example, it came to my mind the AOP that you can use with Spring over Java, am I right or am I missing something?
I guess hardware is always reactive, you just get to decide what it is reacting to and any one point. Reminds me of a micro architecture lecture where someone asked what happens if you don't put a value on the opcode port...
From the article, I think the idea is to enable hardware-like features to programmers.
It's not clear (and other posts are clearly as confused about this) whether reactive programming is meant to be a language-level paradigm (which IMHO would be interesting and useful) or some kind of 'philosophy' like agile.
If the latter, then I guess it would be about creating frameworks, which would get seriously messy, or some kind of meta-programming.
For C++, I think Qt-style signals and slots is the best you're likely to get, since you don't need to care how the event loop and triggers work, you just 'emit' in the right places and 'connect' up whatever object you'd like to change accordingly.
I don't know why people keep submitting this garbage from Espresso Logic, who is just taking advantage of the fact the the term "reactive" has been overloaded to mean different things to exploit the hype surrounding the Reactive Manifesto and related technologies (e.g., Akka, Rx, Node.js, etc.) to push their own, completely unrelated product, which is based on the more traditional (i.e., the one you find in Wikipedia) definition of "Reactive Programming".
"Reactive programming", as defined by the Reactive Manifesto (which is what all the hype is about), is about designing applications that operate in an entirely asynchronous and non-blocking manner, so as to maximize CPU utilization and fully exploit parallelism, and ensure that the system is always responsive to new events (user input, incoming data streams, errors, changes in load, etc.) rather than having resources tied up waiting for external processes (e.g., blocking on I/O). It has nothing to do with "reactive databases".
cp /dev/zero ~/signature.txt
This seems like the way nodejs works, where everything is done in a callback (anonymous function). Maybe you layer a triggering framework on it but that's all it is.
This is the second "reactive programming" article and I don't think it's anything other than callbacks. Someone is trying to get PR for some paradigm they think they invented.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Both slashdot articles are authored by "ValHuber" who works at Espresso Logic Expresso Logic's web page is bannered by
"Reactive Service for SQL Data
RESTful API with reactive logic and security in 4 easy steps
Dramatic reduction in development & maintenance time"
I think it is time we stop marketing for this consulting company.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
This is just forward-chaining logic programming. I.e., if x changes then do y, and people have been using this in design for years - several large vertical applications have this feature built in.
The problem with this kind of code is that, when there is contextual dependency on what is to be done (which happens often in real life), the code becomes riddled with special cases accessing data from far flung parts of the system to determine the contextual state - this starts to look akin to spaghetti code with everything accessible from anywhere in the program: Hello, global state!
The other problem is that, without fixed flow of control, debugging becomes more difficult, even if you have a specialized debugger that doesn't make you trace through the machinery.
Plus, people not used to this kind of programming will embed code which must be specifically ordered within one or more triggers not realizing that trigger orders are usually unspecified, leading to fragile code.
In the end, this is just like any other programming paradigm - useful for things that it's useful for, not so useful for things that don't fit well. You should know how to program on systems like this. You should also know how they're implemented so that you don't screw up when you have to program in one.
That is all.
Is "Reactive" logic an event-driven model with reused logic for column calculations/validation?
Making the comparison with a database implementation. I think, is very weak. A spreadsheet makes much more sense, and applying this to UI, even more sense:
Consider a text entry (t1) with coords((x = 200, y = 300)
and another text entry (t2) with coords(x =t1.x , y = 320)
Then whenever I move/size the screen, t2 will stay at the same x coord as t1. I could also disable/enable the save button based on whether these text entries have anything in them (enabled: !t1.text.length.isEmpty() && ! t2.text.length.isEmpty()). Again, if the text changes, the save button is enabled/disabled... I don't send events or listen to them. The equation varies over time.
I think DB is poor in the sense you have to know what you are listening for (register a trigger). However, imperative languages make this somewhat kludgy as well to implement. F#, Haskell, Elm make this much easier to cleanly handle.
And we know the problems of global variables.
You really must be an expert, because I haven't understood a damned thing by reading your explanation...
This is a UDP joke, I don't care if you get it or not...
only a couple thing that popped out which made me stop reading:
1. he notes he used 500 lines of code to do the same thing in java / hibernate
i haven't used java / hibernate before so i had a peek under the hood
in total the files he showed totalled 459 lines of code
over half those lines are comprised of either empty lines or comments
2. the files seem to include a number of java related base classes
for example "import java.util.Set;"
except it's done in all java class files
all of which also include "import buslogicdemo.util.HibernateFactory;" and "import buslogicdemo.data.*;" which sound like custom classes
so would you not have some upper level dummy file that includes common appropriate dependencies once instead of replicating their inclusion everywhere?
i also had a look at this "5 lines" of code
which is great and all. except there's nothing there to actually get data in / out of the system
whereas the java code looks like it takes care of that
either way, "yes" you can make updates to a database as if you were treating it like a massive excelspreasheet with multiple sheets / areas to deal with
but given the complete lack of any identifying detail of what's going on, have fun when you make an update that accidentally generates a circular depency and effectively prevents and further access to your data while meanwhile filling up your disc til your server konks out