4 ms·

> Not all software has an implied framework within it. Most Unix command-line utilities do not, for example, with only a few exceptions, and discounting the C s

> Not all software has an implied framework within it. Most Unix command-line utilities do not, for example, with only a few exceptions, and discounting the C standard library as something worthy of the label “framework”. The C standard library is exactly that though, a framework for writing UNIX command line tools :) (for anything else it's much less useful)

vidarh 4y ago
> The C standard library is exactly that though, a framework for writing UNIX command line tools :) It doesn't fit the term as used in the article at all, though, in that it doesn't dictate the overall program's flow of control.
- flohofwoe 4y ago
  The overall program flow in this case is: shell => CRT => main(argc, argv) => exit code => shell (to me, the CRT and C standard lib are not strictly separate, although that's debatable of course)
  - vidarh 4y ago
    Except none of these steps are dictated by the C standard library (some may be dictated by some libc's) EDIT: To expand on this: You can call the code from stuff other than a shell; I'm assuming you mean "C runtime" by CRT, and some libc's may have issues without them, though usually only access to argc/argv and atexit(), and you can certainly write C without linking with the initialisation code; and while you'll of course usually enter via main() you don't have to. You decide the control flow.
    - pjmlp 4y ago
      CRT also does stuff like floating point emulation, loading dynamic libraries on demand instead of at load time (e.g on AIX and Windows), handling threads post C11, or runtime checks in hardened code.
      - vidarh 4y ago
        The point is all of that is optional. You can - and I have - write C to be executed on bare hardware with no initialisation code, and depending on your choice of libc you can still use it (though some functionality may not be available).
        pjmlp 4y ago
        At which point it is no longer C, rather a programing language that vaguely resembles ISO C.
        vidarh 4y ago
        Of course it is still C. You've just opted not to use some of the functionality. Nothing stops you from e.g. providing your own startup code which then calls the appropriate initialisation code either. The point being that there's no enforced inversion of control in the sense used by the article, and so calling it a framework in the sense described by the article is meaningless. Even if we postulated the inversion of control was there, the fact you can replace all parts of it still means it does not fit the article definition.
        pjmlp 4y ago
        Not from the point of view of ISO C and the expected semantics of the abstract C machine.
        vidarh 4y ago
        If you were to write a program that relies on those aspects of the abstract C machine and don't provide those aspects, then you might have an argument, in that in that case the observable behaviour would be different, but if you choose not to make use of that functionality, its presence is entirely irrelevant. This is also massively shifting goal posts. You first wrote "At which point it is no longer C". By your argument here, e.g. the Linux kernel is not written predominantly in C. But nobody uses the term that way. If you were to speak specifically about ISO C, maybe, but the person I replied to initially did not limit it to ISO C. As such this is also entirely irrelevant to the original argument.
    - camgunz 4y ago
      The kernel loads your program, and schedules its execution. This is basically the same as using an async framework and sending the entry point to your application. If you're willing to extend a little, there are also signal handlers, or setting up callbacks in pthreads. Again this isn't to be reductive, but to say this is a super common method of encapsulating irrelevant stuff. It doesn't seem to be a significant differentiation between "I'm a library" and "I'm a framework".
coldtea 4y ago
A library is not a framework. You can write framework-free apps while using libraries (in fact, most do - not wanting to be burdened with a framework doesn't mean you have to write all functionality yourself). A framework is either about inversion of control (it calls your code, e.g. you write web request controller logic, and it sets up the infrastructure for calling your controllers), and/or a set of ways to structure your code, like classes to extend, folder structure, a set of patterns you must follow to work with it, like a specific MVC-like organization of code, and so on.
- flohofwoe 4y ago
  Well to be pedantic, the CRT invokes a callback called 'main' with preprocessed (command line) parameters, in the 'main callback' you're expected to do something with the parameters that have been passed to you (for instance read data from stdin, process it and write back to stdout), and then return from the 'main callback' with a success or failure code. Ok, I'm throwing together the CRT and standard lib here, but in the end both are parts of the "UNIX command line tools framework" which is supposed to provide a programming environment to easily extend the UNIX shell with your own commands.
  - coldtea 4y ago
    Yes, in the same sense that "all programs are just permutations of 0 and 1 in the end". Similarly, "libc is the same as a framework" is not an abstraction/assumption at any meaningful level, or really pertinent to the discussion.
- camgunz 4y ago
  By this definition everything is a framework. You're never the one calling code, it's always the BIOS, the bootloader, the kernel program loader, etc. I don't want to go all ad-reductio, but this is one of the points I have against the anti-framework people: the code you write is actually a pretty small percentage of the total code that makes up your system/application. Good engineering is working to make sure that code is differentiating code, not irrelevant code like garbage collection, HTTP header parsing, etc.

vidarh 4y ago

> The C standard library is exactly that though, a framework for writing UNIX command line tools :) It doesn't fit the term as used in the article at all, though, in that it doesn't dictate the overall program's flow of control.

flohofwoe 4y ago
The overall program flow in this case is: shell => CRT => main(argc, argv) => exit code => shell (to me, the CRT and C standard lib are not strictly separate, although that's debatable of course)
- vidarh 4y ago
  Except none of these steps are dictated by the C standard library (some may be dictated by some libc's) EDIT: To expand on this: You can call the code from stuff other than a shell; I'm assuming you mean "C runtime" by CRT, and some libc's may have issues without them, though usually only access to argc/argv and atexit(), and you can certainly write C without linking with the initialisation code; and while you'll of course usually enter via main() you don't have to. You decide the control flow.
  - pjmlp 4y ago
    CRT also does stuff like floating point emulation, loading dynamic libraries on demand instead of at load time (e.g on AIX and Windows), handling threads post C11, or runtime checks in hardened code.
    - vidarh 4y ago
      The point is all of that is optional. You can - and I have - write C to be executed on bare hardware with no initialisation code, and depending on your choice of libc you can still use it (though some functionality may not be available).
      - pjmlp 4y ago
        At which point it is no longer C, rather a programing language that vaguely resembles ISO C.
        vidarh 4y ago
        Of course it is still C. You've just opted not to use some of the functionality. Nothing stops you from e.g. providing your own startup code which then calls the appropriate initialisation code either. The point being that there's no enforced inversion of control in the sense used by the article, and so calling it a framework in the sense described by the article is meaningless. Even if we postulated the inversion of control was there, the fact you can replace all parts of it still means it does not fit the article definition.
        pjmlp 4y ago
        Not from the point of view of ISO C and the expected semantics of the abstract C machine.
        vidarh 4y ago
        If you were to write a program that relies on those aspects of the abstract C machine and don't provide those aspects, then you might have an argument, in that in that case the observable behaviour would be different, but if you choose not to make use of that functionality, its presence is entirely irrelevant. This is also massively shifting goal posts. You first wrote "At which point it is no longer C". By your argument here, e.g. the Linux kernel is not written predominantly in C. But nobody uses the term that way. If you were to speak specifically about ISO C, maybe, but the person I replied to initially did not limit it to ISO C. As such this is also entirely irrelevant to the original argument.
  - camgunz 4y ago
    The kernel loads your program, and schedules its execution. This is basically the same as using an async framework and sending the entry point to your application. If you're willing to extend a little, there are also signal handlers, or setting up callbacks in pthreads. Again this isn't to be reductive, but to say this is a super common method of encapsulating irrelevant stuff. It doesn't seem to be a significant differentiation between "I'm a library" and "I'm a framework".

coldtea 4y ago

A library is not a framework. You can write framework-free apps while using libraries (in fact, most do - not wanting to be burdened with a framework doesn't mean you have to write all functionality yourself). A framework is either about inversion of control (it calls your code, e.g. you write web request controller logic, and it sets up the infrastructure for calling your controllers), and/or a set of ways to structure your code, like classes to extend, folder structure, a set of patterns you must follow to work with it, like a specific MVC-like organization of code, and so on.

flohofwoe 4y ago
Well to be pedantic, the CRT invokes a callback called 'main' with preprocessed (command line) parameters, in the 'main callback' you're expected to do something with the parameters that have been passed to you (for instance read data from stdin, process it and write back to stdout), and then return from the 'main callback' with a success or failure code. Ok, I'm throwing together the CRT and standard lib here, but in the end both are parts of the "UNIX command line tools framework" which is supposed to provide a programming environment to easily extend the UNIX shell with your own commands.
- coldtea 4y ago
  Yes, in the same sense that "all programs are just permutations of 0 and 1 in the end". Similarly, "libc is the same as a framework" is not an abstraction/assumption at any meaningful level, or really pertinent to the discussion.
camgunz 4y ago
By this definition everything is a framework. You're never the one calling code, it's always the BIOS, the bootloader, the kernel program loader, etc. I don't want to go all ad-reductio, but this is one of the points I have against the anti-framework people: the code you write is actually a pretty small percentage of the total code that makes up your system/application. Good engineering is working to make sure that code is differentiating code, not irrelevant code like garbage collection, HTTP header parsing, etc.