6 ms·

Same for every language: if the env is installed and the program has no dependencies, just run build command. This one needs some unspecified versions of gcc,

Same for every language: if the env is installed and the program has no dependencies, just run build command. This one needs some unspecified versions of gcc, make, and ncurses installed.

jvanderbot 3y ago
Minimizing dependencies is a lost art, is mostly what I'm saying.
- sophacles 3y ago
  That's not what you said though, you said i could just download it and type make and it would just work. That's not what happened for me, and it seems to be a very odd way of presenting a very different message. Turns out the minimal dependencies needed involve several OS packages and also the special "dev" versions of those packages installed, and I need to use one of the right subset of terminals. Having the implicit knowledge to get the "magic", doesn't have anything to do with minimizing dependencies. Sounds like the real thing being said is: "It's neat when people use a toolchain and environment I'm familiar with". I don't think that extrapolates to "minimal dependencies are what we want".
  - jvanderbot 3y ago
    "Minimizing Dependencies" Consider the set of dependencies required to recreate this in language / framework X. I assert that this set of dependencies is larger (in some cases much larger) for probably all languages and frameworks, except those that are built using the same language, compiler, and libraries used by, and shipped with, the target operating system. I would also assert that the speed to build, install, and deploy the package would be worse. Larger here means "includes more lines of code", as well as "requires more libraries" and "requires more executables, probably from interpreters". "Worse" here means "more time required to resolve", "requires more downloads", and/or "requires more CPU cycles to solve the multiple levels of indirection from interpretation". It just so happens I have npm, nodejs, cargo, g++, python3, pip, and gcc floating around, and I almost always find that 'make' with `gcc` is the fastest gun in the west, as long as you stick to some basic OS libraries, as this project does. Cargo is real, real close, and probably equal if you ignore the long dependency chains that result for almost any project. But that's much more verbose, and I think the original message implied this for most readers.
    - sophacles 3y ago
      The compiler and libraries aren't shipped with most operating systems. They are available as additional dowloads for most operating systems, just like any other language and environment. But the biggest linux distros, OSX, Windows, and ChromeOS don't ship with a compiler in the default install. I would assert, that this could be done in C, python, rust, and go - no libraries just whatever ships with installing the compiler package. Probably others too but I don't know them well enough to say this about them with the same level of confidence. I will concede that some of the packages to install those languages may be bigger (in the more bytes sense) than gcc + dev versions of the c libraries. Literally it just does a few syscalls to read from input and write to output, all those syscalls are available in the stdlib of the languages I mentioned. Everything else is just a few simple loops and some table lookups (there is the ncurses version that does it a bit different, but it includes the raw vt100 codes too - I'm ignoring the ncurses version to be kind to your assertions about dependencies). For the languages I listed you need the same number of binaries, or fewer. For go - you just need the go binary. For python, the same. For rust you need cargo, rustc and ld (vs C's make, gcc, ld). (note ld here is shorthand for all the tools ld invokes too). As for cpu cycles, you may be right but that is also unrelated to the minimizing dependencies message - although I don't know that the binaries created by rust or go would actually use more CPU cycles, and likely not enough to matter on any computer made in my lifetime. As for compile times - I don't think python or go would have a noticable difference (python is compiled to bytecode to run on a vm at startup, its not a true interpreter so what I mean is that the python text -> bytecode part will not result in a noticeable startup delay). Looking at the project code, I can see several ways to make it have lots of additional dependencies in C or any other language. For instance we could consider the ncurses version in the repo itself, that adds a dependency which must be downloaded (ncurses is installed often by default on linux, but ncurses-dev or whatever is an extra install). But why stop at ncurses, we could make it use glib and getopt and so on. At best, the dependency thing seems orthogonal to the language. As for packaging - well I just don't believe it would be worse. It would be the same set of tools to create the package for each of them - for go and rust you wouldn't even need additional OS dependencies to install the package - really it's just a change of the build command and the binary path to copy into the package, though you would for python - fortunately that is included as part of the default for many OSes that don't include make and C.
- VectorLock 3y ago
  I love glorifying doing things the hard way as much as the next guy, but the fact is dependencies are a way of life. We build on the shoulders of giants. We pull in other peoples code because we don't want to duplicate work, ours is likely not to be as good, any code is a liability, and sometimes _we just aint got time for that._
  - badsectoracula 3y ago
    > We build on the shoulders of giants The problem is that most of the time said giants are actually sand golems and it is giants all the way down.
- the_gipsy 3y ago
  You played this on C, but there is nothing about C that makes this special. You can do this with python, javascript, rust, go... except java maybe. Just imply that the compiler and build systems are installed. There is nothing special in C about implementing some terminal escape sequences that couldn't be done elsewhere. Actually, C is worse: it could all be any compiler/version, make version, or ncurses lib version - nothing is fixed, not even documented. At least in other language there is some standard way of pinning dependencies.
  - sempron64 3y ago
    A lot of pain comes from OS apis which are not supported in the standard library, like graphics, audio, and media. These inevitably need libraries and frameworks to work cross-platform.
    - sophacles 3y ago
      This is also true in C... you make an excellent point: that for toy programs the default stdlib for any given language is often sufficient.
  - jjav 3y ago
    > You played this on C, but there is nothing about C that makes this special. Yes there is something special about C (on Unix/Linux). C is the mother tongue of Unix so it's more intertwined with the system than anything else (other than shell scripting also). You'll nearly always have cc installed. The libraries you need are often in /usr/lib as part of the OS install.
    - the_gipsy 3y ago
      Meh, you can say the same about python, or a bash script for that matter.
      - jjav 3y ago
        I did say the same about shell scripting. Python, no way. Now you have to start pip installing dozens of packages and then you run into dependency mess so then you reach for some tools to manage multiple environments and suddenly you're a few hours into what's become a project when all you wanted was to run a script.
- flykespice 3y ago
  It's because programmers nowadays think efficiency is a one-dimensional concept that only applies to the code. They don't think on the big picture the efficiency on the resulting binary size and build time (implied by the number of dependencies). Another thing that is ignored is the external dependency that the user would need to run the program (whether none with a native compiled binaries or a whole runtime environment to run your python program)

Same for every language: if the env is installed and the program has no dependencies, just run build command. This one needs some unspecified versions of gcc, make, and ncurses installed.

jvanderbot 3y ago

Minimizing dependencies is a lost art, is mostly what I'm saying.

sophacles 3y ago
That's not what you said though, you said i could just download it and type make and it would just work. That's not what happened for me, and it seems to be a very odd way of presenting a very different message. Turns out the minimal dependencies needed involve several OS packages and also the special "dev" versions of those packages installed, and I need to use one of the right subset of terminals. Having the implicit knowledge to get the "magic", doesn't have anything to do with minimizing dependencies. Sounds like the real thing being said is: "It's neat when people use a toolchain and environment I'm familiar with". I don't think that extrapolates to "minimal dependencies are what we want".
- jvanderbot 3y ago
  "Minimizing Dependencies" Consider the set of dependencies required to recreate this in language / framework X. I assert that this set of dependencies is larger (in some cases much larger) for probably all languages and frameworks, except those that are built using the same language, compiler, and libraries used by, and shipped with, the target operating system. I would also assert that the speed to build, install, and deploy the package would be worse. Larger here means "includes more lines of code", as well as "requires more libraries" and "requires more executables, probably from interpreters". "Worse" here means "more time required to resolve", "requires more downloads", and/or "requires more CPU cycles to solve the multiple levels of indirection from interpretation". It just so happens I have npm, nodejs, cargo, g++, python3, pip, and gcc floating around, and I almost always find that 'make' with `gcc` is the fastest gun in the west, as long as you stick to some basic OS libraries, as this project does. Cargo is real, real close, and probably equal if you ignore the long dependency chains that result for almost any project. But that's much more verbose, and I think the original message implied this for most readers.
  - sophacles 3y ago
    The compiler and libraries aren't shipped with most operating systems. They are available as additional dowloads for most operating systems, just like any other language and environment. But the biggest linux distros, OSX, Windows, and ChromeOS don't ship with a compiler in the default install. I would assert, that this could be done in C, python, rust, and go - no libraries just whatever ships with installing the compiler package. Probably others too but I don't know them well enough to say this about them with the same level of confidence. I will concede that some of the packages to install those languages may be bigger (in the more bytes sense) than gcc + dev versions of the c libraries. Literally it just does a few syscalls to read from input and write to output, all those syscalls are available in the stdlib of the languages I mentioned. Everything else is just a few simple loops and some table lookups (there is the ncurses version that does it a bit different, but it includes the raw vt100 codes too - I'm ignoring the ncurses version to be kind to your assertions about dependencies). For the languages I listed you need the same number of binaries, or fewer. For go - you just need the go binary. For python, the same. For rust you need cargo, rustc and ld (vs C's make, gcc, ld). (note ld here is shorthand for all the tools ld invokes too). As for cpu cycles, you may be right but that is also unrelated to the minimizing dependencies message - although I don't know that the binaries created by rust or go would actually use more CPU cycles, and likely not enough to matter on any computer made in my lifetime. As for compile times - I don't think python or go would have a noticable difference (python is compiled to bytecode to run on a vm at startup, its not a true interpreter so what I mean is that the python text -> bytecode part will not result in a noticeable startup delay). Looking at the project code, I can see several ways to make it have lots of additional dependencies in C or any other language. For instance we could consider the ncurses version in the repo itself, that adds a dependency which must be downloaded (ncurses is installed often by default on linux, but ncurses-dev or whatever is an extra install). But why stop at ncurses, we could make it use glib and getopt and so on. At best, the dependency thing seems orthogonal to the language. As for packaging - well I just don't believe it would be worse. It would be the same set of tools to create the package for each of them - for go and rust you wouldn't even need additional OS dependencies to install the package - really it's just a change of the build command and the binary path to copy into the package, though you would for python - fortunately that is included as part of the default for many OSes that don't include make and C.
VectorLock 3y ago
I love glorifying doing things the hard way as much as the next guy, but the fact is dependencies are a way of life. We build on the shoulders of giants. We pull in other peoples code because we don't want to duplicate work, ours is likely not to be as good, any code is a liability, and sometimes _we just aint got time for that._
- badsectoracula 3y ago
  > We build on the shoulders of giants The problem is that most of the time said giants are actually sand golems and it is giants all the way down.
the_gipsy 3y ago
You played this on C, but there is nothing about C that makes this special. You can do this with python, javascript, rust, go... except java maybe. Just imply that the compiler and build systems are installed. There is nothing special in C about implementing some terminal escape sequences that couldn't be done elsewhere. Actually, C is worse: it could all be any compiler/version, make version, or ncurses lib version - nothing is fixed, not even documented. At least in other language there is some standard way of pinning dependencies.
- sempron64 3y ago
  A lot of pain comes from OS apis which are not supported in the standard library, like graphics, audio, and media. These inevitably need libraries and frameworks to work cross-platform.
  - sophacles 3y ago
    This is also true in C... you make an excellent point: that for toy programs the default stdlib for any given language is often sufficient.
- jjav 3y ago
  > You played this on C, but there is nothing about C that makes this special. Yes there is something special about C (on Unix/Linux). C is the mother tongue of Unix so it's more intertwined with the system than anything else (other than shell scripting also). You'll nearly always have cc installed. The libraries you need are often in /usr/lib as part of the OS install.
  - the_gipsy 3y ago
    Meh, you can say the same about python, or a bash script for that matter.
    - jjav 3y ago
      I did say the same about shell scripting. Python, no way. Now you have to start pip installing dozens of packages and then you run into dependency mess so then you reach for some tools to manage multiple environments and suddenly you're a few hours into what's become a project when all you wanted was to run a script.
flykespice 3y ago
It's because programmers nowadays think efficiency is a one-dimensional concept that only applies to the code. They don't think on the big picture the efficiency on the resulting binary size and build time (implied by the number of dependencies). Another thing that is ignored is the external dependency that the user would need to run the program (whether none with a native compiled binaries or a whole runtime environment to run your python program)