3 ms·

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

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.
- theamk 3y ago
  If we are talking about source code distribution, then Python-with-stdlib-only would be have smaller overall dependencies (measured in bytes or executables), easier to build (no build step) and faster to build (0 seconds). The runtime speed will be much lower but you don't need high performance for terminal graphics. But if you want a really lightweight language, you'll want something like Lua. It's like 0.2MB in a single binary which has a (very small) stdlib already built in it. There is a reasons old-style routers/embedded devices with megabytes of flash came with lua (and rarely python/perl), and almost never with gcc or other languages.
  - anthk 3y ago
    They came with TCL.

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.
theamk 3y ago
If we are talking about source code distribution, then Python-with-stdlib-only would be have smaller overall dependencies (measured in bytes or executables), easier to build (no build step) and faster to build (0 seconds). The runtime speed will be much lower but you don't need high performance for terminal graphics. But if you want a really lightweight language, you'll want something like Lua. It's like 0.2MB in a single binary which has a (very small) stdlib already built in it. There is a reasons old-style routers/embedded devices with megabytes of flash came with lua (and rarely python/perl), and almost never with gcc or other languages.
- anthk 3y ago
  They came with TCL.