Loading ...
Sorry, an error occurred while loading the content.

Re: CHAT: the Ithkuil of programming languages?

Expand Messages
  • George Corley
    ... Interesting. I had not thought of a longer instruction set requiring more memory. I guess I just presumed that the program s code was converted into some
    Message 1 of 34 , Feb 27, 2013
    • 0 Attachment
      On Wed, Feb 27, 2013 at 5:56 PM, H. S. Teoh <hsteoh@...> wrote:

      >
      > In my understanding, it's not even an "experiment", it's a joke language
      > deliberately made to as minimal as possible (and therefore, very hard to
      > program in). The joke is that even such a horribly badly-designed
      > language is "Turing-complete" -- that is, it is capable of performing
      > exactly the same computations as any other serious programming language
      > can (given, of course, enough time and memory -- which may be vastly
      > greater than that needed by a more traditional programming language).
      > The name comes from the language being deliberately made to mess with
      > the programmer's head.
      >

      Interesting. I had not thought of a longer instruction set requiring more
      memory. I guess I just presumed that the program's code was converted into
      some deeper language like machine code or whatnot when the program was
      compiled. But now that I think of it, if that were the case there would
      probably no point in the Java Runtime Environment or other such things.
    • Logan Kearsley
      ... Longer source code generally isn t the problem, for exactly the reason you guess- length of source has very little relation to the size of compiled machine
      Message 34 of 34 , Mar 1, 2013
      • 0 Attachment
        On 27 February 2013 19:45, George Corley <gacorley@...> wrote:
        > On Wed, Feb 27, 2013 at 5:56 PM, H. S. Teoh <hsteoh@...> wrote:
        >
        >> In my understanding, it's not even an "experiment", it's a joke language
        >> deliberately made to as minimal as possible (and therefore, very hard to
        >> program in). The joke is that even such a horribly badly-designed
        >> language is "Turing-complete" -- that is, it is capable of performing
        >> exactly the same computations as any other serious programming language
        >> can (given, of course, enough time and memory -- which may be vastly
        >> greater than that needed by a more traditional programming language).
        >> The name comes from the language being deliberately made to mess with
        >> the programmer's head.
        >
        > Interesting. I had not thought of a longer instruction set requiring more
        > memory. I guess I just presumed that the program's code was converted into
        > some deeper language like machine code or whatnot when the program was
        > compiled. But now that I think of it, if that were the case there would
        > probably no point in the Java Runtime Environment or other such things.

        Longer source code generally isn't the problem, for exactly the reason
        you guess- length of source has very little relation to the size of
        compiled machine code. The point of the JRE isn't that conversion to
        machine code isn't done (in fact, the JRE generates machine code
        internally), it's to provide an intermediate step in translation so
        that only one program (the JRE) has to be written multiple times to
        run on different machines, and everything else can just be written to
        be compatible with the JRE.

        The problem is the presence of information about intent, which can be
        used to produce optimizations. For example (because it's relevant to a
        project I'm working on right now), if I'm working in a purely
        functional language and I want to specify that some stuff should
        happen in a strictly sequential order, that's not very hard to do, but
        doing so introduces a ton of incidental overhead that has absolutely
        nothing to do with my actual goal- the compiler will end up allocating
        and recycling stack frames, grabbing memory for intermediate results,
        etc., just to throw it all away again later. If, on the other hand,
        the language includes built-in mechanism for specifying sequential
        execution, the compiler will know that that's all I want, and
        sequential execution is something that physical microprocessors do
        really, really well, so it will be able to skip all of the incidental
        junk and just do the minimum required for the result I actually want.

        That principle generalizes to an enormously wide variety of features.
        If an instruction for a particular feature is present in the language,
        the compiler can recognize your intent and do the Just the Right
        Thing, and nothing else. If it's not, and you have to compose other
        smaller instructions to get what you want, the compiler may not be
        able to recognize your intent, and will thus frequently be required to
        do a lot of extra useless things- taking more time and more memory-
        because it can't prove that you *didn't* want them to happen.

        -l.
      Your message has been successfully submitted and would be delivered to recipients shortly.