• janAkali@lemmy.oneEnglish
    9·
    1 year ago

    Not a language per se, but subsets of languages used for fantasy consoles usually do not implement import functionality. TIC-80, PICO-8, etc. etc. WIKI I wouldn’t call that a feature, but it drives you to write less and more space-optimized code.
    Now that I think about it, source code size could be a feature in itself, look at codeGolf-oriented esolangs:

    • Pyth
    • CJam
    • GolfScript
    • Microscript/Microscript II
    • Seriously
    • Rotor
    • Minkolang
    • Gaia
    • Jelly
    • 05AB1E
    • japt
    • and more…
  • sparr@lemmy.worldEnglish
    8·
    1 year ago

    The unnamed language that is compiled by cc.

    To elaborate… C[++] is really two different languages, with mostly distinct feature sets, handled in most cases by different compilers, interpreters, parsers, etc.

    The unnamed language with keywords like #ifdef and #include which produces text output is a templating system that is functionally independent of the unnamed language with keywords like for and unsigned which actually compiles to a binary.

    You can use cpp to run all the logic and conditionals in that first language to produce output, even if you replace the second language with something else like python or assembly.

    You can use cc to compile that second language from source to binary, without support from the preprocessor.

    That second language, the one that cc understands and compiles, does not have the ability to import functions or values or whatever from other files.

    • the_sisko@startrek.websiteEnglish
      4·
      1 year ago

      I’d argue that’s not true. That’s what the extern keyword is for. If you do #include , you don’t get the actual printf function defined by the preprocessor. You just get an extern declaration (though extern is optional for function signatures). The preprocessed source code that is fed to cc is still not complete, and cannot be used until it is linked to an object file that defines printf. So really, the unnamed “C preprocessor output language” can access functions or values from elsewhere.

      • sparr@lemmy.worldEnglish
        1·
        1 year ago

        No, it can’t. The compiler can’t do anything with content from any file not explicitly passed to it. You’re mixing up the compiler and the linker (and the linker has nothing to do with either language, it can link binaries compiled from any language).

  • ChrisLicht@lemm.eeEnglish
    4·
    1 year ago

    I’m not smart enough to know, but what kind of use case(s) do you imagine for this?

    • snek_boi@lemmy.mlOP
      31·
      1 year ago

      I know encapsulation is desirable in part because of security. I figured something similar could happen by removing the ability to import anything from another program. However, I struggled to think about other situations in which no imports were desirable, and so I wondered…

      • Ethan@programming.devEnglish
        3·
        1 year ago

        There are certainly situations where it would be valuable to be able to place limits on what can be imported, but I can’t imagine trying to work with a language that was completely devoid of imports. Because that would mean 100% of your source would have to be in a single file, which sounds absolutely awful for anything but the most trivial applications.

  • vector_zero@lemmy.world
    2·
    1 year ago

    Knowing programmers, I think a major unintended side effect of such a paradigm would be HUGE monolithic source files.

    • sparr@lemmy.worldEnglish
      4·
      1 year ago

      Nah, you’d just get a preprocessor like C/C++ to do #include for you prior to compiling.