XL Compiler Bootstrapped

descubes inputs: "An XL compiler bootstrapped two days ago (that means it compiled itself). Take a look at the project homepage to discover this language, designed around concept programming ideas, which is a sort of cross between C++, Lisp and XML. Much help is now needed to improve this rudimentary first iteration." One thing to note is that the C++ version of the compiler came in at 4500 lines, while the XL equivalent came in at some 2700 lines. This seems to imply that XL may be easier to work in than C/C++. Might XL someday be nudging the old workhouse out of a job in the near future?

Comments

4500 vs. 2700?

[rekkanoryo]

That's a huge difference in line count between the two versions. If XL is that good a language, it may be worth learning. Now maybe I can get that 1400-line C++ program I've been working on for a year to be less than 1000 lines!

Re:4500 vs. 2700?

[CrypticSparrow]

Its a big mistake to confuse number of lines with a "better" language.
To me, "better" means to more readable, more maintainable, compiles to better object core, etc, etc.
Who cares how many lines it needs?

Re:4500 vs. 2700?

[Curien]

While you're correct that LOC is not a measure of how good a language is, it can be a rough measure of the level of abstraction afforded by a language, when compared to a similar language.

Re:4500 vs. 2700?

[joto]

Its a big mistake to confuse number of lines with a "better" language.

I would tend to disagree. There have been many studies that show that the same programmer will on average produce approximately the same number of codes in any given language. A language that offers better abstraction, will therefore give higher programmer efficiency.

To me, "better" means to more readable, more maintainable, compiles to better object core, etc, etc. Who cares how many lines it needs?

True, there are other considerations. Python will usually make you more efficient than, say C++. But well-crafted C++ code is likely to run faster. The holy grail is good abstractions, easy (but safe) low-level access, small run-time, and fast code. I wouldn't be surprised if concept programming was a step in the right direction.

Re:4500 vs. 2700?

[descubes]

The main source of the difference is that I made use of XL's extensibility (meta-programming) to add an extension to the language for use in the compiler (an example of domain-specific extension). See the "translate extension" post http://xlr.sf.net/031105.html.

So, in that particular case, I believe that the difference really represents a difference in the level of abstraction.

Re:4500 vs. 2700?

[KILNA]

You can probably get it down to a single line of perl, tho the terminal may wrap a few times.

Re:4500 vs. 2700?

[jilles]

Lines of code is indeed a pretty bad abstraction for complexity. I always prefer a little verbosity (e.g. using more than one character for variable names, always use brackets for blocks, even though they are one line only). However, if an equivalent program takes up significantly less space in a particular language that can point out poor levels of abstraction in the other language. The general trend of new programming languages is that they reduce the amount of lines of code needed for programs (and, ironically, require more loc for hello world). Java is a good example of less lines of code and more functionality compared to e.g. C.

IMHO one of the major problems of modern programming languages is its reliance on ascii as the storage and editing medium. Most of the innovations in IDEs for example try to work around the fact that the program is stored in ascii by maintaining a parse tree of the entire source code. This allows for all sorts of on the fly transformations (refactoring) and presentations (e.g. uml diagrams). The problem with this approach is that the internal representation is richer than the external. This information is typically lost when you exit the IDE or requires hacks like putting stuff in comments so the compiler can ignore it (e.g. GUI editors). Many of the concepts you work with in an IDE do not exist in first class representations at the source code level.

Because things need to be typed in manually, many programming languages are full of syntactic sugar which aim to reduce the amount of typing. For example the distinction between for and while is that for requires less typing than the equivalent while for some special cases of while. Neither captures the concept of iteration very well. In some languages this is addressed with more syntactic sugar.

Syntactic sugar is a poor replacement for proper abstractions. Intentional progamming may be a way out. However, I have yet to see a convincing and insightful example. So far all I see is variations of lisp.

Re:4500 vs. 2700?

[descubes]

IMHO one of the major problems of modern programming languages is its reliance on ascii as the storage and editing medium. Most of the innovations in IDEs for example try to work around the fact that the program is stored in ascii by maintaining a parse tree of the entire source code. This allows for all sorts of on the fly transformations (refactoring) and presentations (e.g. uml diagrams).

Yes! You nicely pointed out some of the reasons for a standard syntax tree representation in XL. The properties you mention (accessibility to third-party tools, persistence, representability to the programmer ("rendering"), extensibility (more data than in the source)) are all important, and discussed on the Mozart web site.

The "new" XL compiler, the one that bootstrapped, is an attempt at vastly simplifying that tree representation. It's now down to 7 node types.

Re:4500 vs. 2700?

[OppressiveGiant]

My guess is that this probably has something to do with the fact that some languages have the ability to natively parse their own code. I know this is the case with scheme. I know this language is based of lisp as is scheme, so I'm geussing that this is probably part of the reason why there is such a huge difference in the. The XL version probably doesn't have to deal with memory management or raw parsing of the text. I wrote a scheme interpreter in scheme for a class and its at someting around 800 lines of code, and I'm sure that the Chez scheme probably has a significantly larger amount of code than that.

Re:4500 vs. 2700?

[jonadab]

> That's a huge difference in line count between the two versions.

Huge? Hardly. Statistically speaking, it's barely significant. It's
within one order of magnitude, for crying out loud.

If they'd written it in Perl, it'd be three hundred lines including comments
and some clown over at perlmonks.org would be trying to golf it down small
enough to fit into a signature.

Lines of Code

[Sangloth]

Would braces count as lines?

if (X == Y)
{
Z = X * 2;
return Z;
}

I'd be happier if the braces were in the language... using white space seems intangible.

Re:Lines of Code

[descubes]

XL is mostly defined by its parse tree. As you can see with the Moka example (a Java parser) on the Mozart web site (http://mozart-dev.sf.net/moka.html), I have nothing against writing a parser for a brace-enabled language ;-)

In XL, braces are used for pragmas, i.e. compiler plug-ins. If you write {derivation} dsin(x)/dx, it tells the compiler to hand over the dsin(x)/dx parse tree to the derivation plug-in. See http://mozart-dev.sf.net/derivation.html for an example.

For program structure, I prefer to use indent myself. Braces and indent are actuallyl redundant. So you got a case where what the compiler cares about (the braces) and what the brain cares about (the look of the program, mostly determined by the indentation) can conflict. I've seen very badly indented code which was a pain to decipher. As usual, personal history influences how you design ;-)

Re:Lines of Code

[Anonymous Coward]

I perfer braces, simply because I use editors which auto-indent my code, though moving away from ASCII totally would solve all those issues, but then where would the vi users be?

XL?

[Ricwot]

I'm a fan of english, now if only a programming language was:

"be a calculator"

and that was it, I'd be so happy!

Re:XL?

[egrinake]

"When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop."

-- Alan Perils

:)

Re:XL?

[orthogonal]

I'm a fan of english, now if only a programming language was:
"be a calculator"
and that was it, I'd be so happy!

That will almost work.

Unfortunately the user interface of the calculator leaves a little to be desired. For instance to add "2 + 2", you need to do the following:

type "mov ax, 02" followed by <enter>
type "mov bx, 02" followed by <enter>
type "add ax, bx" followed by <enter>
type "push ax" followed by <enter>
type "call DECIMAL_OUTPUT_ROUTINE" followed by <enter>
type "mov dl, 0Dh" followed by <enter>
type "mov ah, 02" followed by <enter>
type "int 21" followed by <enter>
type "mov dl, 0Ah" followed by <enter>
type "mov ah, 02" followed by <enter>
type "int 21" followed by <enter>
type "mov ah, 4Ch" followed by <enter>
type "int 21" followed by <enter>

Re:XL?

[Ricwot]

That could take away from the simplicity, or in my language,

"don't be a gimp"

Re:XL?

[joto]

Is he a friend of Alan J. Perlis, or is he just a really dangerous guy?

Re:XL?

[Anonymous Coward]

Just make sure you don't ask for a nice hot cup of tea. That one is computationally expensive.

Re:XL?

[Anonymous Coward]

ldr r1,=#2
ldr r2,=#2
add r1,r1,r2
blal output_routine
mov r14,pc

Re:XL?

[leerpm]

Fatal Exception Occured.

Computer: "To be or not to be a calculator, that is the question."

Re:Meanwhile, in Cally-forn-ee-ah

[Anonymous Coward]

100% not funny.

.NET

[JohnFluxx]

This is why we need something like .NET

I often wish to use programming languages other than C++, but the library bindings aren't there.

For example, I'm currently struggling to use libkabc from C# so I can use the kontact name and addressbook.

Re:.NET

[kko]

At the office we're using a lot of .NET right now (most of the guys are using VB.NET, which I hate, but I'm going off on a tangent here...). We have a lot of old code and libs using C/C++, so I usually create wrappers using Managed C++. Interop is kinda weird (I don't think I really understand Interop), but the classes I create using Managed C++ usually work just fine.
From what you're trying to do, I guess you are using Mono (am I right?). Isn't there some sort of Managed C++ for Mono? You might find it easier to write a wrapper over libkabc using C++ and exposing it as a .NET class for your C# code.

Re:.NET

[DrSkwid]

What you *really* need is a better way for libraries, and other code, to expose their functionality.

Unix started down this road with 'everything is a file' but failed to follow through on that promise.

When the Unix creators decided to take what they already knew and start again, 'everything is a file' became a design philosophy.

Consequently, devices can be accessed through the file system
One can draw to a screen via files, or open a internet network connection

The magic for all off this is a unified protocol 9p. All file access is via 9p so if your program can speak 9p it can serve files to anyone. One binds a programs namespace into your own and off you go. The network becomes utterly transparent.

In this way one waves bye bye to bindings and other marshalling techniques, who needs 'em.

If your programming language can open and read and write files, it can do anything.

It is just one of the many benefits that plan9 has brought to us.
Too bad people are letting it slip past them.

Re:.NET

[4of12]

If your programming language can open and read and write files, it can do anything.

Forgive me and call me dense, I don't get it yet. Where does the philosophy of "everything is a file" buy you much over "everything is a network connection"?

It still seems like there's a lot of work to be done in higher level layers on the raw interface so you can build things with more logic in them (think of odd beasts like SQL servers, SMTP, authentication servers, etc.). These "files" still behave differently and an app developer has to know how to interact with each flavor of file, no?

Maybe 9p is a great idea - can it be introduced initially as a layer in something like glibc, or does it need kernel support?

Re:.NET

[descubes]

.NET is a good framework, arguably better than the raw "Win32" API. But there is not much innovation in the languages themselves. XL and .NET are quite orthogonal.

Re:.NET

[DrSkwid]

You are correct in that as much as you need special code for dealing with what the files do as you would need special code to do other things.

The point I was specifically addressing, binding's to the gui components, serves as a good example.

The poster was crowing about .NET's "seamless bindings". Any .NET language can, apparently, have access to any of the available components. (I can't verify this but I imagine it pushes DCOM and the IDL a bit further). The problem for language writers is that the libraries for something such as KDE is written in C++ and Gnome in C. You can't just #include <somelibfile.h> into python or javascript or expect it to compile into your Gnome project.

But right off the bat python could write to the screen, open network connections :

ctl = file('/net/tcp/clone', 'r+')
id = ctl.read()
ctl.write('connect 66.35.250.150!80\n')
ctl.flush()
data = file("/net/tcp/%s/data" % (id), 'r+')
data.write('GET / HTTP/1.1\nhost: slashdot.org\n\n')
data.flush()
print data.read()

, communicate with the authentication server, read my email :
print file('/mail/fs/mbox/1/subject').read()

if you cant see anything interesting in that then plan9 probably isn't for you

600 vs 800?

[AtariAmarok]

I've long wanted C++ to compile on my Atari 8-bit XL computer. At last, the moment has come!

Re:Meanwhile, in Cally-forn-ee-ah

[orthogonal]

[Arnold Schwarzenegger joke:] 100% not funny.

So the rumors are true! There is at least one Republican on Slashdot!

Take that, you stereotypers of Slashdot!

I gotta say ...

[Hanji]

That website smells an awful lot like, "Let's see how many buzzwords we can fit into as small a space as possible!"

Of course, I didn't actually read any of it, so it could actually be damn cool. I'm personally of the opinion that we've yet to see a language that doesn't suck in one way or another...

Maybe this is The One (tm) ... or have I been watching the Matrix a few too many times?

Re:I gotta say ...

[joto]

I've actually read it once. A long time ago. He seems to be going in the right direction. In my opinion, this is Stroustrups "much smaller and cleaner language struggling to get out" from C++.

Getting it up to the production quality needed to compete with C++ is much more than a one-man task, though. And chances are it will die out like any other MFTL-project. But I would like to give him the benefit of doubt on this one.

Re:I gotta say ...

[Curien]

>In my opinion, this is Stroustrups "much smaller and cleaner language struggling to get out" from C++.

That's not what I see. It looks much more like an updated version of Ada to my eyes. Even the claims made are very similar to those made against C++ when Ada95 was new-fangeled and against C when Ada was born.

Re:I gotta say ...

[descubes]

Getting it up to the production quality needed to compete with C++ is much more than a one-man task, though. And chances are it will die out like any other MFTL-project.

... Guess why I posted a story on Slashdot? Anybody interested in helping?

Re:I gotta say ...

[descubes]

It looks much more like an updated version of Ada to my eyes. Even the claims made are very similar to those made against C++ when Ada95 was new-fangeled and against C when Ada was born.

XL took from Ada a few ideas of syntax, those that I believed improved legibility. That's about it. What are the "claims" you are talking about?

Re:I gotta say ...

[Anonymous Coward]

> ... Guess why I posted a story on Slashdot? Anybody interested in helping?

Not particularly, no. Nor am I interested in discovering the "glory of Python", in the words of Python's fanboys. I'm quite happy with C++ and wxWindows as my framework. I give you about 6 months before your piece of shit language starts to languish, and the virtual moths are flying around your long-since-updated project web page.

Might I suggest you stop wasting everybody's time now, including your own, and just delete the CVS tree right now.

Thanks and have a great day!

Re:I gotta say ...

[descubes]

I give you about 6 months before your piece of shit language starts to languish, and the virtual moths are flying around your long-since-updated project web page.

And I bet I'll last more than 6 months. I raise the stakes: one free copy of Linux for every user of Slashdot if I've given up in 6 months.

Re:I gotta say ...

[Curien]

I didn't mean that to be derogatory. It's just the whole, "Just as good as C++, but a clearer syntax, better abstractions, etc". I'm not saying it's wrong -- just that I've heard it before.

So exactly what is the language?

[grotgrot]

The web site seems to completely lack examples. It also isn't apparent how they do 'objects' (ie bundles of data and the functions that operate on them). It just looks like a very poor man's version of Python to me.

Re:So exactly what is the language?

[descubes]

There are many examples on the "old" web site (http://mozart-dev.sf.net/xl.html, linked from the main XL web site). On the new web site, the only real example is the compiler itself ;-)

Re:So exactly what is the language?

[descubes]

It also isn't apparent how they do 'objects' (ie bundles of data and the functions that operate on them)

The bootstrap compiler doesn't need objects, so it doesn't really implement them (and it's partially implemented in the old, non-boostrapped compiler). The language design has them. See http://mozart-dev.sourceforge.net/xl_features.htm, notably "Data inheritance", "Logical inheritance", "Function based dynamic dispatch".

Re:So exactly what is the language?

[grotgrot]

Yes, but the only "object" example was a maximum concept. It is true that one test of a language is if you can write its own compiler in itself.

My other test is what a Space Invaders program looks like. It would have to deal with drawing, responding to user input, timers etc.

hacker site!!!

[Anonymous Coward]

Whoa...check out that SWEET hacker logo in the upper right corner .. anybody else check it?

That logo means this guy is a hacker (no, not the kind that break into computers illegally, the kind that have scrawny mustaches and like to shoot people with guns. Excuse me, like to shoot guns, not necessarily at people. But keep an eye on them anyway if you're a teacher or parent.)

Wow, anybody kool enough to use the neat-o hacker logo must have like the most AWESOME program evarrrrr!

No it doesn't.

[crmartin]

One thing to note is that the C++ version of the compiler came in at 4500 lines, while the XL equivalent came in at some 2700 lines. This seems to imply that XL may be easier to work in than C/C++.

That's just silly. An APL version of it might be only 20 lines long, but it wouldn't be easier to work with because of that.

Re:No it doesn't.

[descubes]

That's just silly. An APL version of it might be only 20 lines long, but it wouldn't be easier to work with because of that.

It would also be possible to write it in one line in C++. A long line, though. However, if you actually look at the code by following the "Browse CVS" link on the web page, you will see that the XL code doesn't look anything like APL.

I realize the limitations of LOC statistics. But I'm still happy to discover that, without any particular effort on my part, code written by the same individual using more or less the same coding style leads to implement the exact same functionality is shorter in C++.

Actually, I even know why. See http://xlr.sf.net/031105.html

Re:No it doesn't.

[crmartin]

Since when has any normal language looked anything like APL? Nor -- even though I used to really like writing APL -- would I suggest it should.

XL looks like a fairly nice language, frankly, but just being more concise isn't a recommendation.

This is only the beginning

[extrasolar]

Soon there will be two-handed gestures, underground clubs, and 10% discounts at Best Buy for possessing a member's card.

A Quick Glance

[jefu]

A quick look at XL shows some interesting things to me. It has support for constrained genericity, programming by contract, the option of using indentation based block structuring or semicolons and end, what looks like a nicely structured rewriting capability that can be used to extend the language for supporting intentional programming, and a few other nice features.

I did not see support for "iterators" mentioned directly, but if the extension mechanism is strong enough that should be doable.

I'll be taking a careful look at it myself. These are some very powerful features. (Sather had many of these and was (in my experience) the best language I've ever used.) If C# had only put in decent syntax for some of these things I could have been persuaded that Microsoft was not the SAOE (Software Axis Of Evil), but they didn't.

Re:A Quick Glance

[descubes]

In the "old" compiler (the one on http://mozart-dev.sf.net) iterators are implemented, though not exactly in the way C++ does it. You write:
for <some expression> loop
and the compiler looks for an iterator that matches . This is how for I in 1..5 loop or for element in array loop are implemented.
In other words, iterators are directly used by the compiler in for loops. This doesn't work in the bootstrap compiler (yet).

User Interfaces for programmers

[ezy]

"Concept"-based programming is the only programming people do.. In non-buzzword terms, it's abstraction. Whether you abstract over code, or data, semantic or syntax... it's all basic abstraction. I read the code for the compiler itself, and didn't really see the kind of abstraction I really wanted to see..

I've taken a stab at this kind of mutable language, and I'm sure more than a few others have, but there's always something missing. It's the same problem that occurred in one of the original mutable languages, LISP (+ macros). While you can go ahead and create domain specific abstractions with syntax, the code to implement a nontrivial abstraction with reasonable semantics and syntax is equally or *more* complex than just using either domain specific tools separately, or using basic functional abstraction in the first place. Nevermind the added complexity of trying not to break anything else in the language at the same time.

After a while, I realized the nut that I, and many other people, were trying to crack is slightly different. You can implement every abstraction buzzword ever mentioned with functional decomposition combined with a preprocessing pass. The important part is not the mechanics, since every programming language since lisp has these mechanics. The important part is the interface to the programmer... and that's a tough problem...

Re:User Interfaces for programmers

[descubes]

"Concept"-based programming is the only programming people do.. In non-buzzword terms, it's abstraction

No. Concept-programming focuses on the limits of abstractions, and consequently on the techniques that help building better abstractions. Concept programming is not what people do. I wish, but it just ain't so. This is discussed ad-nauseam on the Mozart web site.

I read the code for the compiler itself, and didn't really see the kind of abstraction I really wanted to see.

This is really interesting to me. What kind of abstraction would you have wanted there? Please note that the bootstrap compiler is very limited, like any bootstrap compiler, so I can't make use of many fancy features of the "theoretical" XL. But I'm relatively proud of the "translate" extension, for instance (http://xlr.sf.net/031105.html). I think this is a good example of higher-level abstraction. And it's what makes the XL version shorter than the C++ one.

While you can go ahead and create domain specific abstractions with syntax, the code to implement a nontrivial abstraction with reasonable semantics and syntax is equally or *more* complex than just using either domain specific tools separately, or using basic functional abstraction in the first place.

That is just not true. One data point: the symbolic derivation in XL (http://mozart-dev.sf.net/derivation.html) is a few hundred lines of code. The corresponding C++ equivalent using template meta-programming is a few thousands lines of code. The derivative expansion in the source code is shorter than the derivative meta-processing code if you use it only once. Just like inlining the code of a function is shorter than adding all these pesky prototypes if you use the function only once.

You can implement every abstraction buzzword ever mentioned with functional decomposition combined with a preprocessing pass. The important part is not the mechanics, since every programming language since lisp has these mechanics.

The objection "it's easy to build, here are the tools" is not a valid one in my opinion. "It's easy to build a kernel, all you need is a C compiler". Yeah, right.

The important part is the interface to the programmer... and that's a tough problem

And that's precisely where XL and Lisp differ the most. I think XL is more accessible to a majority of programmers, and can appeal to some who would not touch Lisp with a ten foot pole. Yet under the hood, it is so much like Lisp that Lisp-enabled programmers who would not touch C with a ten foot pole could like XL.

I believe you have a good background and could add valuable contribution to the project. Why don't you try to take "one more stab" at this kind of mutable language? ;-)

Re:User Interfaces for programmers

[Asmodeus]

How does this differ from Beta? I've been interested in Beta for a long time, but I've not really seen the benefit of dynamically definable languages evident there - it just seems to go back to the lisp problem of writing, learning, and maintaining a special purpose language on top of a general purpose one. Any new programmer coming to the project is at an immediate disadvantage because of this.

Asmo

Re:User Interfaces for programmers

[descubes]

How does this differ from Beta?

I know very little about Beta, but the little I read indicates a very powerful language, but a not very accessible one.

From a concept-programming point of view, it implements some elementary concepts in a noisy, distorted way. Take function calls as an example. I think it is important to have "A := 3" and "A(3)" be visibly different (regardless of whether you like the := syntax, for instance). From what I understand, both are written 3 -> A in Beta. This is artificial complexity, from my point of view.

um...

[pb]

Has anyone else tried this, and actually gotten it to bootstrap?

With gcc/g++: had to add in a #include <unistd.h> that was missing (needed it for sbrk()); compiled fine, bootstrap died with lots of errors. (it looks like it generates lots of bad C++ code or something)

With icc: Compiled fine (modulo a few harmless warnings); bootstrap compile looks like it has hung (been going now for over 8 minutes!) -- but hey, at least it didn't die, right?

I guess I'll take another look at this one when it isn't pre-alpha. :)

Re:um...

[descubes]

Thanks for the unistd.h info. It's not needed on OSX, so I did not see it.
Well, it looks like I need to do a new build pass on Linux ;-) Pre-alpha it is... But thanks for trying, and thanks for reporting.

Re:um...

[descubes]

With gcc/g++: ... compiled fine, bootstrap died with lots of errors. (it looks like it generates lots of bad C++ code or something)
With icc: Compiled fine (modulo a few harmless warnings); bootstrap compile looks like it has hung (been going now for over 8 minutes!) -- but hey, at least it didn't die, right?

I think both issues have been fixed. There were uninitialized values at a few places...

Looks more like...

[DarkDust]

It looks more like an object oriented Pascal variant to me than the mentioned cross of C++, Lisp and XML. Have a look at the parser source.

But it certainly looks like a nice, clean language, with lots of syntatic sugar removed: they seem to use parens only where absolutely necessary, no semicolons in sight and no curly braces anywhere... well, if you like sugar-free languages this one's for you :-)

Luckily they seem to not follow the current trend of languages without header files, since I personally think header files help writing more elegant APIs (but maybe that's just me).

Re:Looks more like...

[descubes]

The bootstrap compiler is limited. For instance, it doesn't have a 'switch' statement, or dynamic dispatch ("virtual functions" in C++ terms). The name lookup is very constrained by what the C++ back-end can do for me at low cost ;-) So overall, there is still a lot of verbosity and ugliness that is imposed by these limitations.

Regarding header files, the compiler has an "import" statement. XL has modules, with separate files for module interface and module implementation. It's not fully functional in the boostrap compiler (for instance, the body is actually visible to the caller...)

Re:Looks more like...

[dubstop]

It looks more like an object oriented Pascal

Agree. The first thing that I thought of, looking at the source, was the unholy atrocity, sometimes referred to as Modula 5.

Learn more; Books?

[Koos Baster]

I'm very impressed by Concept Programming & XL. It appears to capture many ideas I have had about benefits and shortcomings of pattern matching, functional programming and object orientation.

Could anyone point me to papers/books or PDF resources about this topic?

Re:Learn more; Books?

[descubes]

None that I know of. I think I invented this particular meaning of the terms "concept programming" (the same terms are used on the web to talk about different topics). I never found the time to actually write more than the web site itself. I'm more interested in hacking the compiler.

I'm sorry, I can't tell you

[jrumney]

The compiler source (which resembles neither C++, Lisp, nor XML) is on the website, but contains comments like this:

// This document is confidential.
// Do not redistribute without written permission

Somehow I don't think this language is going to take off unless it is either opened up or adopted by a convicted monopolist.

Re:I'm sorry, I can't tell you

[descubes]

Ouch. I need to fix the headers. It should say GPL there. Do not use until it says so ;-)

Re: LOC isn't everything

[auzy]

i agree completely. LOC really has nothing to do with the quality of the code either. like while (thing 10) { thing++; } is only 3 lines, but it does not make it any more better then: while (thing 10) { thing++; } both really are just as readable. Also, when dealing with stuff like C++, u can discover while VB does things in less code, a game coded in VB will probably never run as well then a c++ equivilent. Looks a bit like eiffel to be honest.. Of course, I cant say anything until I've tried the language

C++, Lisp, XML

[descubes]

than the mentioned cross of C++, Lisp and XML

It's not in the looks. From http://xlr.sourceforge.net/info/xl.html:
A lot of ideas come from older languages.

• XL is a general purpose programming language.
  Think C/C++... without the syntactic and semantic complexity.
  
• XL is a language with a simple, standardized program structure, for meta-programming
  Think Lisp... without the parentheses.
  
• XL is a data language, not just a code language
  Think XML... with better support for highly structured data such as program.
  

There are links to explanations on the original page.

Re:C++, Lisp, XML

[ameoba]

XL is a language that uses indentation to define blocks.

If you've read any of the stories about Python on /., you realize that this is a v. unpopular idea 'round here. I'm suprised that somebody hasn't started railing on XL for this yet.

Just one question.

[Kickasso]

Where's the language manual?

Mozart vs XL

[jefu]

Its hard to keep straight what the mozart project was aiming at and what the xl project is aiming at as the pages use almost identical kinds of layout and style.

I would prefer iterators the way Sather did it though :

loop
i := 4.upto!(17) ; thats the iterator
end ;

XL?

[pmz]

It should have been named XXL, so I could make a mint selling sweatshirts to geeks.

The pain! The pain!

[gooru]

One thing to note is that the C++ version of the compiler came in at 4500 lines, while the XL equivalent came in at some 2700 lines. This seems to imply that XL may be easier to work in than C/C++. Might XL someday be nudging the old workhouse out of a job in the near future?

Ever heard of functional programming? That's the family of programming languages lisp is in? Ever programmed in them? They are freaking painful if you ask me. It makes so much more sense to use a procedural language in everyday programming environments. That's why commercial projects aren't written in lisp or ML or scheme or whatever. Just because the code takes up less space doesn't mean it's any easier to use.

Re: Plan 9

[Szplug]

You said it, but, people aren't to blame for letting it slip past them; the restrictions on its use make it non-Free Software, even though they've revised the license in the hopes of getting it taken up. I wonder though, even if it were to become fully open - would it even be possible to integrate it with Unix / Linux, or reimplement *nix as a subset? Ie, is there even a path for it to become mainstream, now?

C is forever

[Crayon Kid]

Nothing will ever get rid of C or C++. Java tried, C# tried, hell, D language tried. When's the last time you heard of D?

Oh, and if your next question is: why would we want to get rid of C... you're kidding, right?

Re:C is forever

[Anonymous Coward]

C++ is lovely, just as long as the compilers and libraries get sorted out sometime in the coming future for use in high-preformance systems, until then kernels, graphics engines and what not will all have at least there critical secions written in good old C.

Perhaps in the future we'll end up stuck with functional computers, but I predict that we'll be so locked into our procedural languages that we'll end up with our compilers converting them into functional programs to run on the hardware :)

That old axiom..

[Anonymous Coward]

That all computer programs contain at least one bug, and all computer programs contain at least one superfluous function ..
Therefore all computer programs can be reduced to a single instruction that does not work !
Sorry - Couldn't resist :-)

Re: Plan 9

[DrSkwid]

It is true that the story of the license has hindered adoption of this interesting and intreaguing operating system. It serves as an illustration of how fraught with unseen circumstances the world is. Free software wasn't the way to go when plan9 was born 14 years ago. Lucent's Lawyers live in a different world. Bell-Labs has lost many of it's staff. It is a place where lightbulbs have been removed to save money.

The user base, as monitored by newsgroup traffic, has been very slowly growing, a few more people at a time but nothing like a swell. Catch22 : more users = more momentum for change in whatever direction.

There is no-one officially paid to maintain plan9 any more, though it still is under active maintenance.

It won't die for a good while yet, it is a nice antithesis of eye candy & gee whizzery replaced by real magic.

The web site has background pictures

[stephanruby]

The web site has background pictures below the text. That's the only thing I needed to know.