Forgot your password?
typodupeerror

Comment: Re:Spreadsheets are lousy programming models (Score 1) 186

by D-Duff (#45950613) Attached to: How Reactive Programming Differs From Procedural Programming
As with any programming concept and languages, almost every benefit that is gained introduces drawbacks. Some of those drawbacks can be solved, and others we just have to live with. At the end of the day, it's all about picking the right tool for the job and in some cases, the spreadsheet/reactive model is the right tool.

Spreadsheets are computer programs where the typical user doesn't usually care about the problems you mention as long as he gets the correct results.

The pros and cons I had from my reactive programming experience are:
Pro 1) Terse code: My typical defect/kloc remained about the same. So by using about 10x less code to do the same job, my defect count went down proportionally.
Pro 2 ) Live development: No need to stop/compile/start to change a rule, so it's possible to view the result of a rule change quickly. (this also leads to Con 1: Capacity to screw up)
Pro 3 ) No need to repeat formulas: Applying a formula to all the rows in a spreadsheet is tedious.
Pro 4 ) Complex Relationships: It's quite challenging to implement complex object relationships using spreadsheets as each object requires its own worksheet.
Pro 5 ) Data Visualization Tools: Reactive rules encourages developers to clearly layout their data and a good tooling suite can allow developers to visualize everything.

Con 1 ) Capacity to screw up: With live rule editing, a mistake in a rule could get evaluated instantly and potentially corrupt the application data beyond repair. This can be partially solved by good development practices such as taking backups during development.
Con 2 ) Fan Out: As the parent mentions, how many rules are triggered on a data change? This can be solved this using static analysis of the rules to figure out a triggering graph.
Con 3 ) Latency/Synchronicity: A good infrastructure can enable developers to define rules that synchronous, asynchronous or delayed execution. It's also possible to have an infrastructure that allows developers to monitor the cascade of execution. However, each change is executed through event triggers. A large number of changes leads to a large number of events which adds overhead. It wouldn't be a good idea to program a video game with this for instance.
Con 4 ) Large Data Set: Changing a reactive rule on a large data set might lead to a chain of event that takes a large amount of time to execute compared to a customized SQL script that would perform the change in a single batch.

Comment: Reactive Programming : OOP Style (Score 1) 165

by D-Duff (#45660551) Attached to: Why Reactive Programming For Databases Is Awesome
A few years ago, I was curious to know how reactive programming would work on object oriented programming so I wrote an open source tool that tries it out using Java to define the reaction rules:

http://deduced.sourceforge.net/

I liked the amount of functionality I could get in just a few lines of code. Even the user interface was generated by reactive rules.

The thing that puzzled me the most with this tool is the lukewarm reaction of most developers who looked at it even when I proved that it could do things in about 10 times less code than a typical OOP solution.

Java

+ - Do more with less code using OO deduction rules

Submitted by D-Duff
D-Duff (597123) writes "A few years ago, this study implied that spreadsheet development languages required an order of magnitude less code than traditional object oriented languages for some types of applications. With that in mind, I took a stab at bridging this gap by creating the deduced framework and released it under the Apache 2.0 license. It allows the creation of spread sheet type rules between object fields using plain Java. This example shows how it was used to create a simple agile project tracking application using only 15 lines of code. While this framework is quite young, it has a strong appetite for users and contributors."

If I have not seen so far it is because I stood in giant's footsteps.

Working...