Several comments lamented the loss of a great technology. I couldn't care less. There are men and women behind this technology, several of them close friends of mine, and that's the real problem here. For them, obviously, but also for HP. HP loses a really large pool of talented engineers. That's another great blow to the morale of the engineering community at HP. If something like UDC can go belly up in a matter of weeks, who's next?
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...
.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.
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.
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.
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.
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.
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".
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.
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...)
"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?;-)
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
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?
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?
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;-)
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.
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).
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;-)
Anyone that can say with a straight face that France defended Iraq for commercial reasons is a tragic illustration of the power of propaganda.
(Hint to the deluded: Iraq at its best was about 0.3% of the commercial exchanges with France. So we'd piss off one of our largest commercial partners for this fraction of a percent? Get real, lamer.)
France stood up to the Nazis when Poland was invaded.
The precise time table is: Sep 1, 1939: Poland invasion Sep 3, 1939: France declares war to protect its ally Sep 5, 1939: US proclaim neutrality in the conflict
It's not until the US were attacked themselves that they came to the rescue. Who was the weasel?
Updated: See what happens when you donâ(TM)t pay attention to the big picture? Eric Bogs was kind enough to tell me Iâ(TM)m an idiot and a gullible fool for not realizing this was Yahooâ(TM)s Weekly World News, which is akin to The Onion. Hey, itâ(TM)s still a fun article.
The rest of the Yahoo web site is also funny, though. I did not know about it.
I use Ghostscript's 'ps2pdf' program to generate PDF files. It does keep bookmarks, at least when printing from FrameMaker (I don't use Word too much, but that's probably the same thing).
So here is what I do (not quite as easy as you'd like, but it works): - First, install ghostscript or some package with ps2pdf. Left as an exercise for the reader. - Second, print to a postscript file, generate PDF hints - Third, invoke ps2pdf on the generated PS file. You generally want to include all the required fonts in the document, ps2pdf doesn't seem too good at finding fonts by itself.
ps2pdf also solved another problem for me, namely printing from Classic applications when my printer's driver exists only for OSX - Solution: print to PS, convert to PDF, print the PDF from OSX.
Slashdot Mirror
Several comments lamented the loss of a great technology. I couldn't care less. There are men and women behind this technology, several of them close friends of mine, and that's the real problem here. For them, obviously, but also for HP. HP loses a really large pool of talented engineers. That's another great blow to the morale of the engineering community at HP. If something like UDC can go belly up in a matter of weeks, who's next?
IMHO, a more general (and interesting) technique is meta-programming. You can automatically add code. See http://mozart-dev.sourceforge.net/pi-tracer.html for an example.
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...
.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.
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.
It's not in the looks. From http://xlr.sourceforge.net/info/xl.html:
A lot of ideas come from older languages.
Think C/C++... without the syntactic and semantic complexity.
Think Lisp... without the parentheses.
Think XML... with better support for highly structured data such as program.
There are links to explanations on the original 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.
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.
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.
Ouch. I need to fix the headers. It should say GPL there. Do not use until it says so ;-)
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".
Thanks for the unistd.h info. It's not needed on OSX, so I did not see it. ;-) Pre-alpha it is... But thanks for trying, and thanks for reporting.
Well, it looks like I need to do a new build pass on Linux
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...)
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? ;-)
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
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?
... Guess why I posted a story on Slashdot? Anybody interested in helping?
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
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.
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).
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 ;-)
Anyone that can say with a straight face that France defended Iraq for commercial reasons is a tragic illustration of the power of propaganda.
(Hint to the deluded: Iraq at its best was about 0.3% of the commercial exchanges with France. So we'd piss off one of our largest commercial partners for this fraction of a percent? Get real, lamer.)
See Damn french for more info.
France stood up to the Nazis when Poland was invaded.
The precise time table is:
Sep 1, 1939: Poland invasion
Sep 3, 1939: France declares war to protect its ally
Sep 5, 1939: US proclaim neutrality in the conflict
It's not until the US were attacked themselves that they came to the rescue. Who was the weasel?
See this page for more info.
The rest of the Yahoo web site is also funny, though. I did not know about it.
Time travel into the future of programming: http://mozart-dev.sf.net
I use Ghostscript's 'ps2pdf' program to generate PDF files. It does keep bookmarks, at least when printing from FrameMaker (I don't use Word too much, but that's probably the same thing).
So here is what I do (not quite as easy as you'd like, but it works):
- First, install ghostscript or some package with ps2pdf. Left as an exercise for the reader.
- Second, print to a postscript file, generate PDF hints
- Third, invoke ps2pdf on the generated PS file.
You generally want to include all the required fonts in the document, ps2pdf doesn't seem too good at finding fonts by itself.
ps2pdf also solved another problem for me, namely printing from Classic applications when my printer's driver exists only for OSX - Solution: print to PS, convert to PDF, print the PDF from OSX.
Hope this helps...