Re: CHAT: the Ithkuil of programming languages?
- On Tue, Feb 26, 2013 at 5:57 PM, Logan Kearsley <chronosurfer@...>wrote:
> On 26 February 2013 13:05, Daniel Burgener <burgener.daniel@...>Not ridiculously more complex, but Ido replaces many regularities of
> >> Well, I don't think we can have a conversation about this without
> >> mentioning Fith as the FORTH of conlangs.
> >> I had thought that Lojban might be comparable to Prolog, but now I'm
> >> thinking its more of a Haskell.
> > Agree on the Haskell. My first thought was "What would Haskell be?" but
> > then I read your post before actually trying to come up with something
> > you seem to have a perfect idea.
> > How about Ido as C++? They're both reforms on one of the most
> > languages.
> Is Ido ridiculously more grammatically complex than Esperanto? I think
> that's a requirement for a true C++ analog.
Esperanto (verb endings, correlatives, pronouns) with more natlangish
- On 27 February 2013 19:45, George Corley <gacorley@...> wrote:
> On Wed, Feb 27, 2013 at 5:56 PM, H. S. Teoh <hsteoh@...> wrote:Longer source code generally isn't the problem, for exactly the reason
>> 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.
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.