a single script including all tasks - why not?

[Søren Dyhr]

As a sort of deviation, from the thread "single table structure, why not" are we into encapsulation or reusable code.

My past experience always has been that I put all this effort into creating a generic, reusable application, only to find that it would have been easier if I had simply written a straightforward purpose-built one.

We have all our hunches and sense of direction, although it's stumbling near to ignore quantum leaps, by this practice. Some weeks ago was I baffled from the reasoning in one single script per solution ...and I'm still struggling with it.

It was stated in another debate forum, that the occurrence of script parameters, have made modularization ready for obliviance, and the reasoning behind this statement:

Modular scripting is a very popular technique for reusing code. Rather than making a single script, it often is easier to read a script that has been broken down into sub-parts. Those sub-parts can be stitched together using the Perform Script command. This uncluttered ScriptMaker by making it easier to locate the script you need. Modular scripting can even allow you to use the same sub-script in more than one master script.

I theorized that the same FileMaker Pro script may run slower if it is modularized. If FileMaker has to load several scripts into memory rather than one big one, I thought it could possibly take longer. So, I tested it. In the example I used in MODULAR.FP3, the componetized script took 25 percent longer to execute. That's not a big difference, but it should make you stop and consider whether modularization is really needed. My point is that you shouldn't just blindly modularize scripts to the "nth" degree. Use modular scripting wisely.

From: http://www.filemakerpros.com/Optimizing2.sit

...was made ridiculous old fashion.

The poster found it so obvious that he didn't feel the inclination to bring in the premises this conclusion is based on, and he wouldn't debate it further with me.

My problem is that I can't find genuine arguments against it, and posting informal fallacies doesn't help either - only my hunch and sense of direction prevents me from accepting it wholehearted, I can list a few issues that makes it an inconvenient way to arrange ones coding ...but from there into make it strictly logical reasoning... Hopefully will some of the geniuses roaming these pastures be better equipped than me in this reasoning???

Perhaps what have blurred my mind is the excitement I felt over the principle of encapsulation presented in this:

http://www.filemakermagazine.com/modules.php?op=modload&name=News&file=article&sid=607&mode=thread&order=0&thold=0

...which I perhaps falsely feel is a sense of "coming home" to real programming. I can't tell if the original poster refrains from third party plugins as well, but it makes sense if he does. But it still nagging me - is it a quantum leap he presents???

--sd

Edited March 23, 2006 by Guest

[Ender]

Code reuse is an important part of procedural programming (including scripting.) The idea of using a single script with branching to determine the operation vs. using different scripts does indeed seem to have the same arguments as the "single table, why not?" discussion. Sure, it's possible, but what's the advantage?

My opposition to this would be the same. For different types of functions, it's easier for the developer to figure out what's going on if the scripts are separate.

I don't see how the Modular Scripting article has much relevance to the discussion, as the modularization could still occur in a single-script solution; the script would just be calling itself.

[Razumovsky]

...indeed seem to have the same arguments as the "single table, why not?" discussion. Sure, it's possible, but what's the advantage?

Hey, I thought that 'single table' guy had some good points!

In this case, I would have to agree though. Especially with the import script feature, it can be very handy to have modularization. I have drastically reduced the number of scripts using parameters, but still keep them divided into categories, branching done within:

Navigate

Validate

Print...

unfortunately, my copy of FM3 is still installed on my apple IIe out in the carriage house.

-Raz

[Søren Dyhr]

I don't see how the Modular Scripting article has much relevance to the discussion, as the modularization could still occur in a single-script solution; the script would just be calling itself.

Indeed, but what it does to the readability of a scripts - dear me!It makes it a "hanging judge and sheriff" job ...no one but the original developer can read it straight away - but needs to seek shelter under the debuggers tracing.

Recursions inside recusions, might very easily occure - not the easiest task to maintain single handed anyway!

Conventional wisdom goes like this: http://www.cs.cmu.edu/People/clamen/OODBMS/Manifesto/htManifesto/node5.html

...but is filemaker really an entirely different ballgame?? Well the principles are borrowed from real programming, but I lack the ability to ignore them entirely.

I like Matt Petrowski's using a header'ish declaration to include a prefab module - but what he seems to forget, is when suggesting a $$$ variable (tribble it is) is that Get(ScriptResult) isn't limited to work inside one file only as global parameters are. So the incapsulation could be made even tighter than what he suggests - no global field is required.

--sd

[T-Square]

Just to add my two cents:

To elaborate on my original quote in this context: over the years I have had the opportunity to work several major projects from conception through maturation and decline.

In each case, I started by solving immediate problems with specific code (version 1). Then I moved to a stage where I saw common themes that I turned into generalized routines. This usually was a massive endeavor that resulted in broad changes to the struture and function of the database (version 2). After a fallow period, some small problem would crop up, and I would return to the scene of the crime to do clean-up. I would spend days trying to follow the bouncing script ball and cursing myself for not explaining my code better. By this time, the software platform would have a new version (or two) out, and I'd discover that its capabilities were so much better that I'd buy the new package and start rebuilding from scratch.

Reusable code has always sounded like a good idea, but because so much changes so quickly, I haven't really succeeded in reusing more than the general approach of a given algorithm.

As for modular code, it's a tossup for me. Sometimes I think it's easier if the whole process is in one place; sometimes a shorter routine is clearer. FM's previous need for global vars made modular scripts troubling for me; I seemed to spend all my time trying to figure out what script had set which global to what value.

David

[Søren Dyhr]

David

I'm fully with you on this - exactly my experience as well, but I was merely hoping for a straight forward mathematical/logical expression to disregard this developers conclusions, which in my view is exaggerating the way scriptparamters should be utilized.

I can't find no evidence pointing in his direction, but on the other hand doesn't it hardly helping me persuading him with plucking's in this list:

http://www.nizkor.org/features/fallacies/index.html#index

--sd

[Razumovsky]

Actually, on re-reading:

My point is that you shouldn't just blindly modularize scripts to the "nth" degree. Use modular scripting wisely.

Seems quite sound. He does not say 'don't modularize,' but simply that when you do, it should be for a good reason.

[Søren Dyhr]

My thoughts as well, but having all tasks tied up in a single script, adressed with hardwired scriptparamters from the application as well as parts called recursively are likely to confuse me at least, there is going to be sprinkled a lot of Exit Scripts into the code to prevent continuing in irrelevant sections.

What is really tough in my head to handle is the lifetime of a scriptparamter in recursive calls, because it's stacked while commands like:

"Push, Pop, Pull, Peek, Size, Mark, Get Mark, Drop, Drop to Mark and Clear" BTW earlier on availiable from one of Jazz Media's plugins.

...only vaugly are posible - at least a Clear would be handy.

--sd

[Razumovsky]

Perhaps, but that is not what the guy who you quoted seems to be suggesting. I believe you are committing a Straw Man fallacy...

-Raz

[Ender]

Egad! Now we have TWO philosophers. :hammer:

[Razumovsky]

Sorry, I just couldn't pass that one up.:wink2:

[Søren Dyhr]

Perhaps, but that is not what the guy who you quoted seems to be suggesting.

I've been confusing you, I'm not one who dares wrestling with JMO, but WITH someone who claims that the deeper meaning with scriptparameters is to join all scripted tasks in one single - which I "feel" is an exaggeration or misinterpretation like saying that a certain kind of music makes you think of a deep forrest. There is no evidence that the composers intentions were the deep forrest.

What I miss in his statement is the premisses for such an conclution. The screwed would always say - "it depends!" just like Socratees arguing against Meno on "...if virtue can be learned"

--sd

[Ender]

I think I'm a little too 'concrete-sequential' to follow you anymore. I give up. :crazy2:

[Søren Dyhr]

I think I'm a little too 'concrete-sequential' to follow you anymore. I give up.

An I'm perhaps a little too concerned with process of reasoning. Lets enstead establish a list of thumbs up's and jikes.

Let me start:

1) Is pretty tough to debug, although recursions might solve some of the modularity the readability might suffer from. Especially work made by teams will be dragged down by this further abstraction.

2) Features from FMInc are usually not instated with one single purpose in mind, mono-causality seldomly exists.

3) Encapsulation of code might, help you thinking more focused on issues in real need for care, if tightly closed objects are used as "set and forgets" ...since the inner mechanics already surposingly works as expected.

4) I guess we all tend to exaggerate our discoveries, until we get the hang if the proper use - improvisation requires knowledge and expirience ...but sometimes are we hyped by a mass psychosis, that short-circuits virtues for a short while until we get to our senses. Hyperbole might be anglosaxon expression for this behaviour?

If you have more to this list please Wiki with me, since it might be too tough a quest to find a logical expression of why it works inadequately.

--sd