4 ms·

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 t

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.
    - the_gipsy 3y ago
      It's definitely worse with C. Most projects just give you a general "you need X library". Unknown version. Check with your distro which of multiple (or none) package that might be. Then also the X-devel for the headers. Aaaaand then there's all the arcane configure script nightmares.
    - squeaky-clean 3y ago
      You've never run into a problem where 2 C projects require a some shared system library but require incompatible versions? At least with python you can isolate those through venvs.
      - lelanthran 3y ago
        > You've never run into a problem where 2 C projects require a some shared system library but require incompatible versions? I have and it wasn't a problem. I ran 32bit libs alongside 64bit libs for literal years without a problem.
      - anthk 3y ago
        -I $PATH_TO_INCLUDE -L $PATH_TO_LINK_AGAINST
      - jjav 3y ago
        > You've never run into a problem where 2 C projects require a some shared system library but require incompatible versions? I have to say ... no. And I've worked on some very large C projects at times. Part of it is cultural. In the systems library space, there is a much stronger (nothing is perfect but I'll say much stronger) culture of compatibility awareness. Libraries don't break compatibility randomly without any planning unlike in less mature ecosystems (coughnpmcough). So you don't need to depend on libfoo 3.17.42 because neither 3.17.41 nor 3.17.43 work for you. That's not a thing. Part of it is how the system works. If you look under /usr/lib you'll notice libraries are versioned and have symlinks from major/minor version to them. Different versions coexist and you can link accordingly. Even if you have (rare) badly-behaved library authors who break compatibility, it's not an issue to have multiple versions and each program links to the one it needs.
deleted 3y ago
[deleted]

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.
  - the_gipsy 3y ago
    It's definitely worse with C. Most projects just give you a general "you need X library". Unknown version. Check with your distro which of multiple (or none) package that might be. Then also the X-devel for the headers. Aaaaand then there's all the arcane configure script nightmares.
  - squeaky-clean 3y ago
    You've never run into a problem where 2 C projects require a some shared system library but require incompatible versions? At least with python you can isolate those through venvs.
    - lelanthran 3y ago
      > You've never run into a problem where 2 C projects require a some shared system library but require incompatible versions? I have and it wasn't a problem. I ran 32bit libs alongside 64bit libs for literal years without a problem.
    - anthk 3y ago
      -I $PATH_TO_INCLUDE -L $PATH_TO_LINK_AGAINST
    - jjav 3y ago
      > You've never run into a problem where 2 C projects require a some shared system library but require incompatible versions? I have to say ... no. And I've worked on some very large C projects at times. Part of it is cultural. In the systems library space, there is a much stronger (nothing is perfect but I'll say much stronger) culture of compatibility awareness. Libraries don't break compatibility randomly without any planning unlike in less mature ecosystems (coughnpmcough). So you don't need to depend on libfoo 3.17.42 because neither 3.17.41 nor 3.17.43 work for you. That's not a thing. Part of it is how the system works. If you look under /usr/lib you'll notice libraries are versioned and have symlinks from major/minor version to them. Different versions coexist and you can link accordingly. Even if you have (rare) badly-behaved library authors who break compatibility, it's not an issue to have multiple versions and each program links to the one it needs.

deleted 3y ago

[deleted]