ShaunR

I have done this for VIP, and Zip packages for an installer I've had on the back burner for a while.

I already have that superpower I once used lots of letters so that if you read the for loops top to bottom the letters spelt out my name and a message. I also once heard that wether you use "a" or "i" depends on if you came from a mathematical or engineering background. What's really stange (for me) is in C and PHP; I use "i". But in Pascal, and Python ; I use "a". I know that to a certain extent it is muscle memory since if I use "i" in Pascal, I nearly always leave out the colon before the equal sign. Maybe it's a coping mechanism because I switch between languages so much.

Been there. Done that. Wouldn't a DSNewHandle suffice?

There is DSMaxMem and DSMemStats which aren't much use. Do you have any info on DSMemStatsSlow and DSMemStats2?

Did this today (and any other day I write C). for (int i=0; i < len; i++){ The big question is .. should it have been "a" instead of "i"?

I think you answered your own question there and used the two term method that I described. This is exactly why I said:

I don't think it's that hard. You just have to use two words, one of which describes the domain. Learning complexity, system, complexity, code complexity, network complexity et. al. They all adequately describe what's being talked about. I only had an issue with "accidental" complexity. When using non-domain terminology (like "accidental", "inherent" etc) it needs more defintion in the statement, for example "the inherent complexity of the code". The inherent complexity of the system, etc. This is mainly a grammatical problem rather than semantic.

Thanks.It worked great but I don't think I'm going to go through the other 13 versions and installing it.

Hmm. No 64 bit versions for 2009-2015. Thanks for the info.

I've got it in 2019 but not in all the other versions. Is there a separate test install for each version?

Potato, Potato Like i keep saying (and you agreed earlier) the Priority Queue is ordered PRIORITIES, not necessarily the elements (we disagree on this bit). The underlying implementation is irrelevant the name-it could even be a linked list.

Moderator comment: Discussion started here. Nice. However this is mine.

I don't think it does Cyclomatic Complexity Correct if I'm wrong because I rarely use it.

Perhaps in the AF case. However it's also fairly common for the underlying implementation to be a stack (LIFO). That is effectively what the DQMH implementation is. Like "accidental"? You understimate the power of a marketing department, my friend

Huh? I never said anything about an elderly person. Are you in the right thread?

Well. My supermarket obviously isn't as isn't classy as yours. Flashing a Platinum Amex and then moving to the front would probably get you a bop on the nose.

Yes. A Priority Queue orders priorities.

This I can get behind! 2&3 also map onto Whitebox and Blackbox testing. There is a test for 1 that I have seen (can't remember off hand what it was called) but it was mainly for c/c++ and counted things like the number of if/else or entries in Case statements to arrive at a figure for "complexity"

Yes. I'm saying the "concept" of priority queues doesn't.

As far as I'm aware. There is no guarantee (or expectation) that priority queues enforce ordering, only that higher priority messages will be executed before lower priority messages. I'm not familiar with the internal workings of the AF but if what you say is true (that order, at the same level, is guaranteed) then more of what you term "complexity" happens when that isn't required. An emergency stop springs to mind where you may not want the previous buffered messages to be executed, just the E-Stop. With the AF (based on your description) the user has to categorise different messages to different levels and I would suspect you woud also argue that is a "complexity". I wouldn't, however. Neither would I for the DQMH. I take your point about debugging and difficult to diagnose for the DQMH under certain conditions but it is a limitation of the design, and probably adequate for most scenarios if you don't make the guaranteed order assumption. The AF code also means practical debugging complexity due to the code paths which doesn't exist in the DQMH. So it's all 6 of one and half-a-dozen of the other to me. I expect the reverse order is more surprising to most people but it probably compiles and executes significantly faster than the AF one (just a hunch) so the limitations may have been a compromise to that. If you need a priority queue that guarantees order then that feature in the DQMH is not for you but I go back to my original statement that "here is no guarantee (or expectation) that priority queues enforce ordering, only that higher priority messages will be executed before lower priority messages." (this is a discussion that crops up in task schedulers too, by the way).

OK. But good or bad wasn't the question. I was after the definition of "Accidental Complexity" and what you've just said brings me back to what I said originally Here I am saying that the underlying complexity of the framework is a necessary evil that has been "accepted and considered" rather than "accidental". What you seem to be confirming from my interpretation of your suggestion is that any hidden complexity is "accidental" in the context of the meaning and therfore a Framework is accidental complexity. Anyway. I've pretty much come to the conclusion that it's just more of a woolly buzz phrase like "Synergy" and "The Cloud". It obviously means different things to different people and I've a sneaking suspicion that it's meaning depends on where blame will be apportioned

Exactly, but according to your definition it would be "accidental complexity". This is why I said in an earlier post that people confuse architecture and frameworks. I personally use a SOA architecture but within each service I may use QMH or Actors or whatever framework best achieves the goal. Many people choose one framework and fit everything inside it, making it their architecture. And lets be frank (or brian). Most LV frameworks are written and intended to be just that. So LVOOP is "accidental complexity"? (Just teasing) I don't really think it is a thing by these definitions when talking about complexity. Rube goldberg code exists but it isn't really "accidental". It is the product of brute forcing a linear thought process rather than iteratively designing one. Neither case is "accidental". Bolt-on bug fixes to cure the symptom rather than the cause might be argued as "accidental complexity" but that is just bad practice (of which I'm sure we are all guilty at some point). From the feeback it seems more of a weazel phrase for inelegant/inefficient code (except AQs take on it) in order to not admit it as such. I suspect this phrase is only used when things go wrong on a project and probably has an unquantifiable quality about it..

Nah. Don't buy it. This is a change in requirements and there is no added complexity of the space itself. This is still a change in requirements and this is definitely an excuse for claiming value-added when no intention to add exits! Just because a user infers a feature that was never offered; it doesn't mean that the code is more complex. It just means the User (or Product Owner) has identified a new requirement. We were talking about code complexity growth and the term "accidental complexity" implies some sort of hidden cost - unkown or impossible to know, at design time (from what I can tell). This is why I asked for clarification. I've never heard of it and it just sounds like an excuse. By that definition, wouldn't the framework itself be an "accidental complexity" rather than the "considered and acceptable" complexity of a tried and tested template for design? Maybe I'm just getting too hung up on "accidental" and what it implies.

What is "accidental complexity"? This sounds like an excuse given to management.

No link? For shame!