Hof Examples Discussion Two

Moved from SummaryOfHofExamples because it's intended to be a summary.

(Regarding multiple independently-refreshing GUI panel example.)

• Assumes one is stuck using JS/DOM, which only has one kind of built in "timer", and it requires HOF's as input unless one rolls their own timer. Thus, the "benefits" of HOF's are only specific the particular client. It's comparable to saying it's easier to use the TutorialDee query language on the RelProject than on an SQL-based RDBMS. A UI "timer" does not have to inherently depend on HOF's in its interface. VB classic had one that did not "expose" or require HOF's, for example.

• If you feel the environment unrealistically forces HOFs to be used -- and counter that with an imaginary environment that doesn't require HOFs -- then why not imagine your imaginary environment a step further, to wit: "No matter what your requirement is, there is already an existing application that does it. Therefore, HOFs are never needed." (Indeed, by the same logic, we never need any programming!) Obviously, this is absurd reasoning; we can't consider imaginary tools when examining real applications. If we're going to consider real applications rather than abstractions, we have to accept the real requirements and real conditions that the real environments impose.

  • Do you claim HOF's are "less code" for all possible client designs/tool? It seems pretty clear that being less for the HtmlStack (with JS) does not by itself "prove" it's less code for every possible client design. Further, "less code" is not always the primary factor to consider.

  • [It's obvious that higher-order functions, and for that matter anything ever, cannot be less code for all possible client designs. The proof's simple: Imagine a client with a language that has only one instruction, run(), which runs the exact program you want to write. No language feature can possibly produce shorter code for your program than that language does. This however does not change the fact that higher-order functions, where available, are an optimal solution for a range of programming problems. -DavidMcLean]

• Eval has not been ruled out for the "management" of screen processes. There is no identified "tight loop" that would make them a bottleneck. (It may require the built-in timer interface to initiate for reasons given above).

  • There's no tight loop, but the number of independent panels is arbitrary -- it could be 30 or 300. Also, assume that this app -- like any modern Web app -- could run on anything from a desktop machine to a low-end mobile phone. As a general rule, CPU usage should be minimised in order to minimise power consumption.

  • Most monitoring apps/utilities need to fit on one screen, otherwise it defeats the purpose. And mobile devices have smaller screens, and thus less panels to tax processing. Not fitting one screen would be a rare request, with no known actual cases. The summarization strategy would probably be refactored such that 2 or more panels are consolidated into one, such as by states instead of cities. -t

    • [If two or more panels are to be consolidated into one, it will be easier to perform this refactoring under the higher-order function version, in which the number of panels is arbitrary and easy to change. -DavidMcLean]

    • Suuuure they are. They are magical! A HOF once made my dick grow 14 inches!

    • [Again, is your rudeness necessary? It's trivially true that the number of panels is easy to change in the JavaScript version that uses higher-order functions, because the number of panels is only specified once. -DavidMcLean]

    • Indeed. Top, take a look at the source, line 18: "var numberOfDivisions = 30". That's all there is to it.

    • That's a setup parameter. You don't need HOF's to have setup parameters.

    • True, but no one said you need HOFs to have setup parameters, did they? What was said (paraphrasing) is that this example -- which uses HOFs -- defines the number of panels via a single setup parameter.

    • I don't see that to be unique to HOF's

    • [It isn't. We aren't saying it is. We're saying the JavaScript version, which uses higher-order functions, defines the number of panels via a single setup parameter. -DavidMcLean]

    • That's not a HOF issue. It's web programming 101 to implement something like this:

for i=1 to getParameter("panelCount")
  print out panel HTML or DOM-appender code using i for ID
end for

.

• That's the point. It's not a HOF issue. For the third time, we aren't saying it's a HOF issue.

• In practice, it probably wouldn't be done that way because the URL, normalizing range, panel title, and other info would need to be given such that we'd probably create a panel-creator function/method. I usually do so on the server side rather than client-side because the app is usually getting info from a database of sort. Plus, doing it server side means we can avoid more version-specific browser-side JS issues (or loading bloated libraries to hide browser vendor-specificness.) Further, one can inspect the HTML for debugging and QA. If you write directly to the DOM, there's not much to inspect unless you use a DOM tree inspector, which is not very easy to read for most humans.

• Indeed, some bits have been hard-coded in the example to keep the focus on relevant aspects. The guy who commissioned it from me has, no doubt, dynamically pulled the panel count from somewhere.

You're quibbling here. I've given the actual requirements. You're making up non-requirements.

YOU started the quibbling. I and readers have no way to verify they are actual requirements. Even if the written requirements state "must have ability to have unlimited panels", it likely would not be practical in practice. I would expect the reasoning and utility behind having so many actually stated. That's part of scenario presentation.

Like it or not, that's what it is and those are the requirements. It's used to monitor user activity on some sort of collaboration/communications thing and there can be any number of users. I think it's for troubleshooting when things misbehave, not 24x7 monitoring, so it's a reasonable UseCase to have a lot of panels and scroll up and down looking at the overall pattern and red peaks. Furthermore, it is clearly undesirable to choose a facility that requires higher CPU and power consumption (eval) than one that requires lower CPU and power consumption (HOFs), regardless how many panels are needed. That's true even if the number of panels is 1, if the 'eval' expression needs to be evaluated repeatedly. I think that rules out 'eval'.

That's not how you monitor peaks. Sounds like a bad project design to me. And you are hogging network bandwidth and other resources by putting so much activity in the non-visible portions (out of scrolling range). HOF's help you do the wrong thing faster? Lovely.

Beware of conflating HOFs with your personal objections toward the application requirements and/or design. That would be like blaming 'while' loops for awkward font management in Microsoft Word. The scenario is not a VU meter, so peaks aren't being "monitored" in the usual "ride the levels" sense. Once again, you're quibbling about the requirements. They are what they are. If you expect to change the requirements, why not change them to not require the application in the first place? We certainly don't need HOFs (or anything else) in an application that doesn't exist. As for shutting down activity in areas that scroll outside of the viewing area to save bandwidth, I could easily do that but there's no need -- the link I provided is to a simplified demo, not the actual product.

I have no way to verify your claim about the requirements. Usually with something this involved, there are multiple ways to achieve similar results. One can often go to the customer and say, "This approach gives you sufficient alerts, yet goes with the flow of our existing tool-set and skills/experience such that the project will go smoother." It's called "negotiation". The requester often hasn't thought out all possible ways to achieve a similar result because they are not IT experts or haven't had time to think about it more. Now I will agree that in some cases one is stuck with fitting the requirements exactly as written because it's a signed contract, and in that case one may have to gut it out and/or even switch tool-sets to achieve exactly what's written. But usually there's some flexibility. Before signing the contact, a smart contractor will point out that non-visible elements may be taxing the network and other servers for no purpose such that the requirements should be reworked. I would probably not recommend a web browser for heavy-duty GUI work and instead suggest perhaps a C++ Windows or Delphi client. Browsers are flaky when too much is going on at the same time. You've come down with BrowserAbuseSyndrome.

Yet again, you're quibbling about the requirements. You'll have to accept that the requirements, as given, are accurate and that there's nothing to negotiate. As for shutting down activity in areas that scroll outside of the viewing area to save bandwidth, I could easily do that but there's no need -- the link I provided is to a demo, not the actual product. You are squirming desperately to avoid using HOFs, and you're not presenting arguments against using HOFs that are based in programming, ComputerScience, or SoftwareEngineering. Your arguments don't even appear to have a reasonable business case, because the apparent claim that HOFs require some leap in "tool-set" (we're using Javascript, which supports HOFs) or "skills/experience" (HOFs are easy) is unsustainable. If you were assigned this project, I suspect your responses would result in the boss and the client getting rather irritated. Meanwhile, I've delivered the solution that was requested and it works as intended -- a happy boss and a happy client are the result. I get a bonus, you get a disciplinary.

YOU are the one squirming desperately by making up goofy requirements out of your ass to force-justify them via mass exaggeration. Eval's or frames would probably work just fine, despite your drama-queening about them and anointing HOF's magic ivory tower knighthood. Lisp lost the Great FP Civil War in the 80's because they invited just enough Sandy Hook programmers to create frankencode for job security purposes or GoldPlating boredom. You had your chance to introduce realistic examples and choked, relying on browser design flaws. Stop reenacting the Civil War! The HOFsouth lost! Now Fuckhoff!

[There haven't really been any new requirements added since the example was introduced on ArrayDeletionExample, if I'm not mistaken. Your emotional attack on Lisp is completely off-topic, considering this application uses only JavaScript. -DavidMcLean]

You never said the panels go beyond the visible screen. You kept increasing the quantity. And HOF's were one of the allegedly selling points of the Lisp fad.

[No, we didn't say the panels did that. You did, and then we said this design could handle it. It wasn't actually specified, as a requirement or otherwise, until you brought it up. -DavidMcLean]

So you are admitting you added to the original requirements.

[No, I'm accusing you of adding to the original requirements. ;) ]

I just asked a question to figure out what you were talking about.

[Being able to support an arbitrary number of panels, whether it's one, ten, or a hundred, has been both a requirement and supported by the example from the start. Screen sizes and the number of panels the screen can hold, by contrast, haven't really been a consideration. (Also, the "Lisp fad" and Lisp's following collapse have no relation to higher-order functions. It's about the AiWinter, for the most part.) -DavidMcLean]

It's impossible to support an arbitrary number of panels. Even if written in machine language, a 100k active refreshing panels would bring both clients and servers to a halt. (And you may get arrested by DHS for initiating a DOS attack.) Perhaps what the customer meant was that your API didn't impose an arbitrary limit software-wise. That's NOT the same as being practical at gazillion panels performance-wise and usability-wise. For example, I may ask for a GUI engine that in theory could open a million windows. I put that in the specification to avoid unnecessary surprise limits. But that doesn't mean I'm asking it to actually support a million windows machine-resources-wise. That's because I want my hardware to be the actual bottleneck, if I decide to push it that hard, and not have software limits to be the bottleneck, such as a predefined array dimension of say 500 windows.

And the AI push did make Lisp and FP the "in thing" for a while even outside of AI.

[Obviously the number of concurrent panels is limited by hardware. This system only doesn't impose a software limit, so it hypothetically could operate with an arbitrary number of panels. Since higher-order function techniques require less CPU processing than an equivalent eval-based technique, it'll also have a higher upper bound imposed by hardware. -DavidMcLean]

By that argument, assembly language would probably be better than HOF's. In most CBA software, the database or the network is the bottleneck, not CPU. In a typical CBA setting, I doubt what "they are actually monitoring" would cause the CPU to be the bottleneck. Most likely those panels would be querying a few databases, and having 50 or so queries going on every few seconds would be too much for a database doing real work. Your example just smells suspicious. If it's a factory, then they'd probably use industrial grade UI's and monitors and not a web browser for such. Web browsers are not designed for that kind of use and are probably not well-tested for that kind of load.

[This is a client-server arrangement, and we've already discussed that the client may be a mobile device with poor CPU capability. We want to minimise CPU processing on that system, both because the CPU is poor and because it increases battery life to use it less. -DavidMcLean]

If it's a mobile app, then then network is also going to be a bottleneck, not just CPU. Thus, either you only have a few panels visible and active (since mobile apps have small screens), which is not going to be an Eval problem, or you have bunches of panels outside of scroll range hogging network bandwidth, and CPU. You can't have your cake and eat it also.

[Eval will be a problem on a mobile device even if there's only one panel, because it uses more CPU and therefore more battery power. This was already pointed out above. -DavidMcLean]

Pfffft. Fine, I concede that HOF's are 0.0001% more efficient for that example IF we are stuck using the HtmlStack. Put a microfeather in your cap.

[Higher-order functions are more efficient than eval() for every example, whether we're "stuck using the HtmlStack" or not, because they don't do any parsing at runtime. Parsing is slow. -DavidMcLean]

We've argued the "speed thing" already somewhere else. I'll LetTheReaderDecide whether speed is the overriding concern. Again, in the vast majority of CBA's, the CPU is not the bottleneck, and in such situations, I place code readability and maintenance above speed.

• Can you "show me the math", or even provide evidence, to demonstrate HOFs are less readable or maintainable than the alternatives?

[Again, in this example, we're talking about a mobile device, and we want to minimise CPU usage to maximise battery life. The overhead of parsing is a definite showstopper for eval()-based solutions on this platform. -DavidMcLean]

Processing about 2 eval's a second isn't going to make a shit of difference to a human observer. You are quibbling over dust. If mobile apps cared so much over such small grains, then why do they spend CPU on bouncy scrolling, cursor shadows, and other 3D-like shading?

• [Those are "features" and must be included to meet requirements. eval() is just a tool, and if it's possible to implement the system without it one usually will avoid it, because then one will have more CPU cycles available to implement bouncy scrolling, cursor shadows, and other 3D-like shading instead. -DavidMcLean]

[Not at all. An observer will find their battery life shortened, potentially significantly.]

Bullshit!

[A very eloquent response. I commend you.]

Show me the math.

[Sure thing. http://moduscreate.com/javascript-performance-tips-tricks/ From this benchmarking, we see that eval()'d code runs at about 97 ops/sec; compare and contrast with basically any other benchmark there, all of which are at least 20k ops/sec. This is because eval() is significantly more CPU-intensive, so it consumes more CPU cycles and hence more battery power. -DavidMcLean]

Eval-ing a function call (name) is only one operation. Thus, if we average 2 a second for the mobile device (per above), and take your 97 figure, then that will only slow it down about 2%, which a user wouldn't typically notice. If performance is that important, then it should be written as a native device app anyhow, not HtmlStack.

[Yes, there's no visibly noticeable application slowdown in this two-eval()s-per-second scenario. Again, we're talking about a mobile device, and it's the device's battery power we're concerned with, which will be impacted. Also, you've imagined the two-eval()s-per-second requirement. The example we're working from wouldn't need two eval()s per second; it has thirty panels, and each one triggers four times a second. If it were using eval()s, it'd need to perform over a hundred eval()s per second. -DavidMcLean]

What the hell are you monitoring that needs to be updated four times a second? I've never seen anything that needed to even be close to that frequency accept heavy-duty industrial equipment, which wouldn't hire a general CBA to produce their monitors. That's not what browsers are meant for. If you are lucky enough to get one to work, that's wonderful, but risky.

[No idea. That's what the original example does, though, and it does it competently. Can your solutions compete? -DavidMcLean]

So you have "no idea" what it's used for, yet are submitting it as a "representative" CBA example???

[I didn't submit it. It's not my example. I believe the original source of the example did discuss what it monitors. -DavidMcLean]

I can't re-find the original link. Do you remember where it was? The demo uses local "internal" dummy functions to generate values. That's not necessarily the conditions of the real world.

• [ArrayDeletionExample, no?]

• That's a long topic.

• [Search for "collection of divisions". As for using dummy functions to generate values, yes, the demo is using those. However, those aren't part of the example, because the value-generation is all on the server-side and we can't even see the server-side code (which is good because it's irrelevant). -DavidMcLean]

• I only see implementation description. I see very little about what real-world CBA purpose it has as far as allowing some human to do his/her job better. That was the issue.

• "[R]eal-world CBA purpose" is irrelevant when discussing programming techniques.

• Bullshit! ArgumentByLabToy is limiting. That's a naive claim.

• It's a reasonable claim. What "real-world CBA purpose" has any impact on whether I choose to use a while loop vs a for loop, or a named function vs an anonymous function, or a switch statement vs nested 'if' statements? And so on.

• Because certain code patterns or "needs" are simply rare in some domains (sometimes because there's a different or better way to do something). You may end up trying to sell refrigerators to Eskimos if you don't know the domain.

• You appear to be constructing a relationship between code constructs and application domains, which I've not seen before in either ComputerScience or SoftwareEngineering literature. Can you demonstrate that such a relationship exists?

• It's only anecdotal and so is your upcoming counter claim. We check such on a case-by-case basis by studying actual or realistic CBA examples. It's common sense that programming languages and coding patterns should be road-tested if possible. If you think lab-toys are a good enough test, that's fine. LetTheReaderDecide and let's end this. But from the practical side, if you really want to sell HOF's to a wider audience, you'll probably eventually have to present realistic CBA examples. Your shortcut is failing.

• I don't want to "sell HOFs to a wider audience", which is a rather peculiar thing to say about a programming construct, anyway. Programming is not shaped by the application domain. Programming is programming; it is a craft unto itself. HOFs are "sold" -- to the extent that they're sold at all -- by the efficacy of languages that implement them, like Javascript and Clojure.

• Re: "Programming is not shaped by the application domain." Saying so does not make it true. Programming code is mostly for the human head, not for machines. The machine doesn't care between machine language and Lisp. And the marketplace has consistently favored semi-domain-specific languages.

• Programming is not taught by advising use of 'if' statements in this domain and 'switch' statements in that, and it would be ludicrous to do so. Programming is not done by using 'if' statements in this domain and 'switch' statements in that, and it would be ludicrous to do so. So, in the absence of any evidence to the contrary, your counter-claim must be considered invalid. What, by the way, is a "semi-domain-specific" language? The marketplace (at present) is dominated by C#, Java, PHP and Javascript. Are those what you consider "semi-domain-specific"?

• For the most part, yes. You wouldn't want to write an operating system in Php. And "If" statements etc. are probably not a good example. Constructs for parallel programming are probably a better example. In application languages you don't need them much (unless you are doing it wrong). However, you'd really want them in SystemsSoftware. And you probably don't want garbage collection in a missile control system because it adds unpredictability to micro-timing.

• ['if' statements are a perfectly fine example. Higher-order functions operate on around the same level of detail as would an 'if' statement or (slightly more accurately) a 'for' loop. -DavidMcLean]

• Not. For one, the meat is separated from the bread. Second, it could be one meat per multiple bred pairs. It's a slinky in the copy room.

• [Could you communicate in a non-metaphorical fashion? I'm not sure what you mean or how it means higher-order functions don't operate on the same level of detail as 'for' loops (which they do). -DavidMcLean]

• I don't see much similarity, other than being a "unit of code".

• [A higher-order function call is a unit of code that would be used at the same level of detail as a 'for' loop or 'if' statement, as opposed to being a broader structural unit of code like a class or module. In many common cases, such as maps and filters, the semantics are also quite similar to that of a foreach loop (although performing more specific operations, so they're more concise than a foreach loop doing the same thing). What did you mean about "meat" and "bread"? Would you mind restating those points without metaphor? -DavidMcLean]

• It's my opinion that they are not similar. But the point is that in my observation, HOF's are more confusing to average developers than the equivalent with objects etc. such that a shop might as well stick with objects unless there is a need for a large usage volume of them, which appears to be rare per lack of representative domain scenarios found. The WetWare/psychology behind the perception (or lack of) of HOF's is murky and speculative.

• Do you find HOFs more confusing than the equivalent with objects, etc.?

• I do find debugging them with IDE's more confusing (having to resort to old-fashion debugging). It may be that I can leverage my prior experience debugging objects whereas I don't yet know how to do so with HOF's effectively. That is a staff time & cost factor to consider: leveraging what you already know.

• What language(s) and IDE(s) are you using?

• I don't wish to get into that. You'll probably find an "obvious" magic button I missed and make me look pretty stupid. The bigger general point is that one can leverage what they already know and get almost the same thing so they don't have to find that "obvious" new button for the new thing. A good many developers are even blinder than me, especially bigger organizations that can't easily toss out the ol' fogies for a fresh new batch of FastEyes from India.

• My intent is not to make you look stupid; I've no intention of correcting what you're doing. This threadlet will end with two words from you (no, not those two words): The language name and the IDE name. I'm simply curious.

• Another day perhaps. It's not a pivotal issue.

• Perhaps not pivotal, but certainly very interesting. How difficult is it to type two words?

• Let's find out:

not today

.

• Also, there are different ways to funnel the messages around between the panels. It may be more efficient to have a "value queue" with a table/struct with columns such as: "panel_ID, element_ID, value". The queue is updated at the fastest rate of any of the panel updates. Slower panels simply receive less messages.

• [Wait, are you suggesting it's more efficient to have a database table on the client-side? Seriously?]

• No, the slash was intended to mean it could also be a C-like "struc". Or an array, if you will.

• [How would a queue on the client-side, whether constructed using a C-like struct or an array or even a table, help with this design? At all? -DavidMcLean]

• It has fewer independent "threads" polling the server. Before, each panel was treated more or less like an independent little browser window as far as communication with the server(s). We may get more efficiency by having fewer or a single poller. There are different ways to allocate these. True, it may put more work on the server-side, but that's often what you do if you want to lessen the load on the client.

• [But then the panels are no longer being refreshed independently and asynchronously, which was a requirement. -DavidMcLean]

• I thought you said client-side efficiency was the most important thing. Without verifying if this really is a CBA, the "requirements" can all over the map.

• [This is a custom application written for business. It's trivially a custom business application. And the independent asynchronous refresh of individual panels has been a stated requirement the whole time. -DavidMcLean]

• I have no way to independently verify that. Ideally we'd have a detailed description of what is being monitored so we know what really matters and what doesn't.

• [From the original example on ArrayDeletionExample: "I was tasked to address the situation where a large number of divs need to be updated asynchronously using AJAX so neither the page nor some large portion thereof need to be bulk-reloaded, and that's what I came up with. It could as easily be something to display live stock portfolio updates, or monitor live status of sales points in a retail store, or keep track of live shelf loading in a warehouse, balances of accounts in something, whatever. Etc." -DavidMcLean]

• Yup, that's it. It's my scenario, and that's what I was originally given. Subsequently -- when, by the way, the guy who presented this problem told me that my "code was working great" -- he mentioned it was for performing diagnostics on some Web-based communications/collaboration environment (I don't remember the details, but they were neither interesting nor relevant) and he mentioned the display was a varying number of (typically) between (roughly) 30 and 300 thin horizontal "status" strips, one per user, populated by pulling data from a Web service. That's why I changed it from the original "Brady Bunch" panels to strips -- to make it more realistic. I don't know if it's actually a bar graph or some other display, but it doesn't matter -- the server-side determines that. The important point here is that using HOFs made this particular solution easy. It was easy to write, it's easy to read, it's easy to modify, it's simple, and it works well. I'm happy, the guy who needed it is happy, and there was no need to waste time discussing the requirements or grind out complex alternatives just to avoid a wee programming construct like HOFs. No drama needed.

• The guy had no problem with HOFs, by the way -- he's young and relatively new to programming. When I showed him the code and explained it, he got it immediately. He didn't find HOFs difficult, complex or awkward; he just took them on board as another construct he could use. That's why HOFs are good -- for some things, they make the code easier to write, easier to read, easier to modify, are simpler, and work better than alternatives like eval(). That said, I'd be delighted to see a non-HOF solution to this that's as easy to write, as easy to read, as easy to modify, that's as simple, and that works as well.

• Keep in mind that if we were not stuck with the HtmlStack, we would NOT need to use EITHER hof's or Eval's. Network diagnostic screens are arguably outside of CBA. That's more of a technician tool, closer to SystemsSoftware. The customer is not a business or domain user, but a network technician. I still classify this scenario as a client-specific issue. If you want to balk, go ahead. You think HOF's are magical, I view them as a smell that our CBA tools are immature or lacking, requiring us to use the GO-TO of FP: the HOF. In both the multi-refresh-panel case and the parallel query case/scenario, if the app language/tool simply had the proper or working (non-clicking) constructs, then we wouldn't have to use the risky and confusing pointer-ish HOF's. And yes I feel that most CBA coders would find HOF's confusing, especially during debugging. If your experience with other CBA devs differ, so be it. I call it as I see it.

  • [Higher-order functions are not the goto of functional programming. Tail recursion is the goto of functional programming, and in most functional programming one avoids writing out "raw" tail recursion by using higher-order functions. Higher-order functions are not risky, confusing, or pointer-ish; tail recursion is significantly more confusing, hence the tendency to avoid it in favour of higher-order functions (which are implemented using tail recursion). -DavidMcLean]

• Keep in mind that if we were not stuck with computers, we would not need to use programming. It isn't a network diagnostic. The customer is a business or domain user, not a network technician. By "communications/collaboration" application, I meant it's a user-to-user messaging and collaboration tool, where users communicate via human language. The monitor is for troubleshooting behaviour and interaction problems, not network problems. It has nothing to do with technical networking. If it's about networking, it's about human networking. And, if you feel all this app needs is "non-clicking" frames to reject HOFs, please show a simpler, easier to read, easier to modify example that suffers only from clicking. I'll turn down the speakers. Finally, do you have evidence that "CBA coders" would find HOFs confusing? Or, is it that you find HOFs confusing, and are projecting that onto your colleagues?

• As far as what confuses CBA devs, I only have anecdotes, which is all you have also. Maybe I'll code up a frame example one of these days as an example. However, I don't claim it would be "easier to modify", only easier for a typical CBA dev to read and understand. Being readable and understandable to a wider coder audience is usually more important than "easy to modify" in my experience because it's the more-predictable route for the business. Taking 10 hours to change but having a 90% success rate is preferable to most businesses over taking 5 hours but having a 50% success rate (meaning half of devs can't fix/change it properly). That's just what my experience tells me about what businesses prefer and/or tolerate with regard to the balance of efficiency versus risk. At times I have forgone my own favorite abstractions for similar reasons. (Sometimes I use them anyhow even knowing it's probably not what the biz would prefer. The rebel in me occasionally leaks out.) If your experience with other devs is different, so be it. We'll AgreeToDisagree on that issue rather than have an anecdote battle.

• Have you asked your colleagues about HOFs? I'd be curious to know their specific responses.

• Hey, the bar-graph version appears to have a memory leak in FireFox 18. It fills up RAM in the process monitor and eventually crashes. http://shark.armchair.mb.ca/~dave/hofajax/

• Try FireFox 18.0.1. I've been running it for a while and about:memory shows nominally stable behaviour.

• Windows 7, 32 bit, 18.0.1 still leaks on my PC.

• Strange -- I'm not experiencing that, but I've got a lot of RAM on all my boxen. Works fine on a Nexus 7 and an HTC Desire Z too, having run it for an extended period. It also works on IE 10.0.1 and Chrome 24.0.1312.57. Haven't tried any other browsers, but I'll blow the dust off my iPad and try it there if I can be bothered. I'll try a Javascript leak detector on it when I get a moment, and I'll eyeball the code to make sure I'm not inadvertently keeping alive something I shouldn't. Or maybe it's not leaking at all but caching something? Perhaps the crash was unrelated.

• It could be a fluke combo on my PC, graphics driver, etc. Could you by chance put the text version (grid) one back up in addition to the bar graph one? I'll see if that leaks also. I can see it tick upwards in the Task Manager stats. If you have a lot of RAM, it may take a while to fill up.

• Could be, but I'd be surprised if it is. I suspect it's either caching or I've had a brain fart and done something überstupid. I've got a version at work designed to run flat out with over 300 divs. I'll run it for a while tomorrow; it should quickly highlight any problem. I didn't keep the grid version but it's trivial -- I'll re-create it when I get a moment. [...time passes...] I think I know what it is -- I've been überstupid. I'll fix it tomorrow.

• If you find the cause, I'd be curious to know. (I hear HOF's can put somebody's eye out :-)

• I thought I'd committed a schoolboy error, but no. With 300 divisions on a nominal 10ms refresh rate per division under Windows 8, memory consumption on IE 10.0.1 and Chrome 24.0.1312.57 remains constant over time. Firefox 18.0.1 demonstrates a rapid increase in memory consumption -- a clear memory leak. Obviously, this is a FireFox problem.

• [Looks like a Firefox 18.0.2 was just released; perhaps it fixes this memory leak? -DavidMcLean]

• Tried it; doesn't fix it. Subjectively, it may have slowed the rate of memory consumption. I did not run it long enough to see whether memory consumption reaches a plateau and levels off or grows without bound.

• Switch to frames, ticking sounds are slightly less annoying than a memory leak :-) Or combine them both, then we get a ticking time bomb that culminates in a glorious crash.

• [(Un)fortunately, the clicking and memory leak are client-specific issues for different clients. More's the pity. -DavidMcLean]

• What, you've never used Fire Explorer?

• Perhaps with too many refreshing panels, FF gets overloaded such that it has no spare cycles for garbage collection, and thus the garbage piles up on the street corner. Just a suggestion. A test of this theory would be to see if the increase plateaus if much fewer panels are used.

• [The latest Firefox is now 19.0.2. Some of the updates between then and 18.0.2 may be the fix. -DavidMcLean]