5 ms·

This articulates well something that's always been in my mind - code is just a precise expression of business logic. Programmers are actually business administr

This articulates well something that's always been in my mind - code is just a precise expression of business logic. Programmers are actually business administrators making low granularity business decisions. You could make programming less complex but it doesn't obviate the need for making those low-granularity decisions -- you're just choosing to go with the "defaults".

PaulDavisThe1st 4y ago
I understand your point, but I really intensely dislike the term "business logic" when used as some sort of universal. A bunch of us write code that nothing to do with any "business logic", even if there is some other sort of set of workflow rules & design that need to apply. I write a DAW, and we face two major fundamental problems: 1. most DAW users don't use many features, but they do tend to use different sets of features. So if you want to be useful to lots of users, you need a LOT of features. 2. the corollary of (1) is that there are, unlike in "business logic" applications, oodles of workflows in use, and the application needs to support as many of them as possible without friction or bugs.
- roncesvalles 4y ago
  I mean business logic in a very broad sense. You have your DAW and it does something. That's the abstract model. You could define what it does in a high-granularity sense (point 1), but you also need to define what it does at lower levels of granularity. What you define at those lower levels is still part of the the abstract model of the DAW. Hence it's "business logic". Whether you use a while-loop instead of a for-loop, that's not business logic but an implementation detail. Programmers make a ton of "implementation detail" type decisions but they also make a ton of decisions that affect the abstract definition of the thing, and these I define as "business logic".
  - PaulDavisThe1st 4y ago
    The point is there isn't really a "thing the program should do". If you compare to e.g. some sort of data entry or data analysis UI, you can describe the process the user is intended to follow, and that defines your "business logic". With creative apps, this "process the user is intended to follow" doesn't exist. We're not implementing the rules of an employer or a company, we're providing open-ended workflows for people who don't know what they're doing.
    - e12e 4y ago
      It's still "enter data/modify data" along with suitable UI/ux and views to enable that. Of course a DAW can probably be viewed as a low code tool for programming sound - so implementing a DAW is more similar to implementing a spreadsheet - than using a spreadsheet. Still, the user has a goal, a process of achieving that goal - and the software needs to support the process and achieving that goal - eg output a track. The fact that there are many users, with different goals and processes - doesn't mean that it's not "business logic" both to "crossfade" and "shift pitch".
      - PaulDavisThe1st 4y ago
        "Business logic" normally dictates the relative ordering and contextual legality of certain operations and data values. This doesn't apply to creative apps. Do this then that, or that then this, or the other and then that and the other other, etc, etc. > It's still "enter data/modify data" along with suitable UI/ux and views to enable that. While I agree that this is technically true, I'm not sure anything useful comes of viewing things in this way. Undecided, but doubtful. > Still, the user has a goal, a process of achieving that goal This just isn't true. Talk to creative people. Even someone doing a task like audio mastering, which is not particularly creative, doesn't begin with a goal. Musicians typically have only a vague idea, if they have an idea at all, of what they are trying to accomplish. That will change over time as they work on a piece and the process coalesces into "I'm trying to ..." as opposed to the earlier stage of endless "let's try ..."
        e12e 4y ago
        > "Business logic" normally dictates the relative ordering and contextual legality of certain operations and data values. Wikipedia gives the following definition for "business logic" > In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program. I (and i believe op) lean on the "domain logic" end when talking about business logic. So the fader toggles bits in the raw data, but in a way that input and output is sound data that can flow through the application. Your DAW needs both the bit fiddling - and the "flow input through the fader and out to file" parts. > Musicians typically have only a vague idea, if they have an idea at all, of what they are trying to accomplish. I'm talking much more abstract here - "improve recording" is a goal - there's a current domain state, and the goal is to modify it in some way. I'm talking about user intent in interacting with the domain.
- alwaysbeconsing 4y ago
  It's true that it's a bit of an expansion of the word "business", but it doesn't really mean "something to do with commerce". It's just the parts of the code that handle the rules of the system that directly enable the user's goals, and not any of the auxiliary, supporting infrastructure. So for a DAW business logic is pretty broad, true, but it would be stuff like, faders or muting a track and the effect on the mix, whether you can copy-paste a snippet of audio, and routing audio through plugins. And not things like the file format of a project, or the code that interprets hardware interfaces.
- dustingetz 4y ago
  this is a failure of abstraction. over time, the platform detail handling gets separated into the runtime (for example memory management, now cloud provisioning, my startup is a language that abstracts distributed state). the reason we get ahead of the abstractions is that software is so valuable that we will spend $100M to bring a product to market by force of capital and its worth it because historically the winner takes most, this is just economic imperialism/conquering and barely a level removed from physical violence. it is sad actually how self interested we all are, imagine the world if we could figure out how to cooperate!

PaulDavisThe1st 4y ago

I understand your point, but I really intensely dislike the term "business logic" when used as some sort of universal. A bunch of us write code that nothing to do with any "business logic", even if there is some other sort of set of workflow rules & design that need to apply. I write a DAW, and we face two major fundamental problems: 1. most DAW users don't use many features, but they do tend to use different sets of features. So if you want to be useful to lots of users, you need a LOT of features. 2. the corollary of (1) is that there are, unlike in "business logic" applications, oodles of workflows in use, and the application needs to support as many of them as possible without friction or bugs.

roncesvalles 4y ago
I mean business logic in a very broad sense. You have your DAW and it does something. That's the abstract model. You could define what it does in a high-granularity sense (point 1), but you also need to define what it does at lower levels of granularity. What you define at those lower levels is still part of the the abstract model of the DAW. Hence it's "business logic". Whether you use a while-loop instead of a for-loop, that's not business logic but an implementation detail. Programmers make a ton of "implementation detail" type decisions but they also make a ton of decisions that affect the abstract definition of the thing, and these I define as "business logic".
- PaulDavisThe1st 4y ago
  The point is there isn't really a "thing the program should do". If you compare to e.g. some sort of data entry or data analysis UI, you can describe the process the user is intended to follow, and that defines your "business logic". With creative apps, this "process the user is intended to follow" doesn't exist. We're not implementing the rules of an employer or a company, we're providing open-ended workflows for people who don't know what they're doing.
  - e12e 4y ago
    It's still "enter data/modify data" along with suitable UI/ux and views to enable that. Of course a DAW can probably be viewed as a low code tool for programming sound - so implementing a DAW is more similar to implementing a spreadsheet - than using a spreadsheet. Still, the user has a goal, a process of achieving that goal - and the software needs to support the process and achieving that goal - eg output a track. The fact that there are many users, with different goals and processes - doesn't mean that it's not "business logic" both to "crossfade" and "shift pitch".
    - PaulDavisThe1st 4y ago
      "Business logic" normally dictates the relative ordering and contextual legality of certain operations and data values. This doesn't apply to creative apps. Do this then that, or that then this, or the other and then that and the other other, etc, etc. > It's still "enter data/modify data" along with suitable UI/ux and views to enable that. While I agree that this is technically true, I'm not sure anything useful comes of viewing things in this way. Undecided, but doubtful. > Still, the user has a goal, a process of achieving that goal This just isn't true. Talk to creative people. Even someone doing a task like audio mastering, which is not particularly creative, doesn't begin with a goal. Musicians typically have only a vague idea, if they have an idea at all, of what they are trying to accomplish. That will change over time as they work on a piece and the process coalesces into "I'm trying to ..." as opposed to the earlier stage of endless "let's try ..."
      - e12e 4y ago
        > "Business logic" normally dictates the relative ordering and contextual legality of certain operations and data values. Wikipedia gives the following definition for "business logic" > In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program. I (and i believe op) lean on the "domain logic" end when talking about business logic. So the fader toggles bits in the raw data, but in a way that input and output is sound data that can flow through the application. Your DAW needs both the bit fiddling - and the "flow input through the fader and out to file" parts. > Musicians typically have only a vague idea, if they have an idea at all, of what they are trying to accomplish. I'm talking much more abstract here - "improve recording" is a goal - there's a current domain state, and the goal is to modify it in some way. I'm talking about user intent in interacting with the domain.
alwaysbeconsing 4y ago
It's true that it's a bit of an expansion of the word "business", but it doesn't really mean "something to do with commerce". It's just the parts of the code that handle the rules of the system that directly enable the user's goals, and not any of the auxiliary, supporting infrastructure. So for a DAW business logic is pretty broad, true, but it would be stuff like, faders or muting a track and the effect on the mix, whether you can copy-paste a snippet of audio, and routing audio through plugins. And not things like the file format of a project, or the code that interprets hardware interfaces.
dustingetz 4y ago
this is a failure of abstraction. over time, the platform detail handling gets separated into the runtime (for example memory management, now cloud provisioning, my startup is a language that abstracts distributed state). the reason we get ahead of the abstractions is that software is so valuable that we will spend $100M to bring a product to market by force of capital and its worth it because historically the winner takes most, this is just economic imperialism/conquering and barely a level removed from physical violence. it is sad actually how self interested we all are, imagine the world if we could figure out how to cooperate!