Jump to content

Daklu

Members
  • Content Count

    1,824
  • Joined

  • Last visited

  • Days Won

    82

Daklu last won the day on December 25 2018

Daklu had the most liked content!

Community Reputation

339

4 Followers

About Daklu

  • Rank
    Bringing the Fu to you
  • Birthday 03/04/1970

Profile Information

  • Gender
    Male
  • Location
    Portland, Oregon

LabVIEW Information

  • Version
    LabVIEW 2009
  • Since
    2006

Recent Profile Visitors

8,073 profile views
  1. Here you're talking about the complexity of an application that uses the framework, in which case I agree the application's complexity isn't necessarily increased by the unused framework options. (This is especially true if the person inheriting the code has previously used the framework. I'm not convinced it's true if the inheritor knows nothing about the framework.) I'm talking about the complexity of the framework itself (which is also what your original comment seemed to refer to) and how easy it is to build a mental model of how the thing works. More behavioral exceptions and opti
  2. I disagree. While it is entirely realistic to build apps without using priority queues, having this option available does add complexity to the AF and DQMH. If you show someone a regular piano and an electric piano/synthesizer and ask then which is more complicated, what do you think they'll say? Having more optional features available, especially when they're easily discoverable by users, adds complexity. Users are going to spend a non-zero amount of time considering those optional features and adjusting their mental model of how the framework works.
  3. The AF priority queue does enforce ordering. The DQMH priority queue does not. (I'm not advocating for one or the other... personally I think priority queues are a bad idea.)
  4. That's a great example, and I'll add that I think your conclusion holds even if you didn't look at the implementation. On the surface the conceptual model presented by the AF seems more complex. It has multiple priority levels available whereas the DQMH has only a single priority level. But the AF implementation behaves predictably--messages sent in order (with the same priority level) execute in order, while the DQMH implementation may not. On the other hand, I think Fab strongly recommends only sending Exit/Abort messages as priority, and as long as one follows that rule you coul
  5. Yeah, I agree with you for the most part. Maybe that's because the applications LV developers are typically asked to write are a small fraction of the kinds of software that can be written. My projects almost always boil down to some sort of machine control or acquire/analyze/present. (I've not heard of anyone building a load-balancing web server, a cool 3D game, or a spreadsheet using LV.) Eh... that may be true for some of them. There's an inherent impedance in connecting non-AF code to AF code that tends to encourage people to use AF for the entire app. (At least there w
  6. 1. What application architecture do you use for higher-level organisation? I'm going to be pedantic and change my answer, since the options listed are frameworks, not architectures. 😋 The architecture I most frequently use is the "hierarchical actor architecture." If one were to ask for a little more detail, I'd say "hierarchical actors with asynchronous name-data messages."
  7. The things I've read always refer to it as "accidental" complexity, but you can think of it as "unnecessary", "incidental", or simply "non-required" complexity. It's just complexity in a system that isn't a necessary to meet the requirement (both functional and non-functional) of the system. System complexity is a subjective evaluation, so these are more abstract ideas than concrete rules to follow.
  8. Hmm... I'd slightly change that to say the payoff of a good architecture is in managing an application's inherent complexity. IMO, the whole point of a framework is to increase productivity, so a "good" framework is one that does that. Naturally, the frameworks we're talking about here are neither wholly good or bad, just good or less-good for a specific set of project requirements. I disagree with the claim that a good framework makes complex applications simpler. An application with complicated requirements is going to have some minimum amount of inherent complexity. The best a
  9. Funny you mention this. Here's a slide from the most recent version of my Fundamentals of AOP presentation.
  10. Is this restricted to AF actors specifically, or would our own actors also be first-class citizens?
  11. I have experienced the exact same thing using LapDog over the past 10 years. There are very few (if any?) times when I have to have to write lengthy boiler-plate code that could be made more efficient with scripting.
  12. I chose, "Other publicly available message-passing-style 'framework,'" though I could have also chosen "Your own or your company's internal framework or templates" or "Other (please post, this includes architecting each application from scratch)" since outside of a few templates I typically write each app more or less from scratch. (I will yank modules used in previous apps and modify as needed, but I don't typically bother making them into reuse packages.) Predictably, I use LapDog, and I'm glad you put "framework" in quotes as messaging libraries aren't frameworks. [Edit
  13. FYI, I got a file permission error on Windows 10 when trying to set the file extensions I wanted the launcher to handle. It was easy enough to fix by manually giving myself write permission to C:\ProgramData\LabVIEW Tray Launcher\config.ini, but it is an issue I ran into. Also, do you have the source up on GitHub?
  14. That's in line with what I remembered, but I didn't want to spread misinformation. (Age plays havoc on my memory.)
  15. My apologies if I misrepresented what you said. Can you elaborate on why you recommend against using XControls?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.