XSLT is kind of cool and taking off. Not exactly functional but there is no destructive assignment.

Having written many thousands of lines of XSLT, it's more than cool: it's fantastic. That it has no destructive assignment is not at all a point in its favor (though not one against it since it doesn't need it): XSLT is a declarative language, it's computational model is based on the notion of matching a node to a "template" and transforming said node... which makes it perfect for its domain: transforming XML documents. ...XSLT is a domain specific language, and that is why it is so wonderful; and also, I hope, an indication of what Programming Languages of the Future ([echo] future, future, ...) will look like... The main obstacle is bringing DSL's out of esoterica (e.g., Robotics control) and into the mainstream (e.g., GUI design). I'm optimistic: XML is being used for this purpose (where 'computation' can be expressed declaratively, i.e., as a document), for example, in ASP+. Other DSL's, e.g., WebL (Compaq's Web Language) have had moderate success as well... As for Ye Olde General Purpose Language, I hope that notion dies... Instead to be replaced by the Programming in the Large language, which should have extensive facilities for interacting with DSL's. I, of course, love Haskell to death, but my vote has to go to the (emerging) ML2000, with its first class modules, higher-order polymorphism, object types, strict evaluation, and imperative references...

A lot of the things Haskell excels at (IMO) inferior tools are being used in place. For example, Microsoft has build good XSLT translators and two new compilers (C#, VB7) in the last couple years. Unfortunately, C#, not Haskell, will probably be "the" language for the next decade. Fortunately, C++ will not be the language of the next decade.

Time will tell... I'm writing a lot of VB these days. I expect that it would be a giant bitch to write XMLDOM manipulation stuff in Haskell since the DOM is so imperative and OOey. (It's not that great in VB, but I'm sure as hell glad I'm not writing it in Java, if for no other reason than the casting would be a constant syntactic annoyance.) -- Of course, I'm designing an XML generation language (aimed at a different domain than XSLT and XDuce, but with vaguely similar intentions to XMLambda). And I hope, of course, that this will be "the" language for the next decade ;). (Notice how I think that the important language for the next 10 years will be an XML processing language)

On 27-Nov-2000, Benjamin L. Russell wrote:

Just out of curiosity: what makes you so sure about C#? C# has some potential big problems, too: in particular, the ability to declare a portion of the code "unsafe," which can encourage unsafe programming among entrenched C/C++ programmers.

That is twaddle. "Entrenched" C/C++ programmers will doubtless write bad code in any other language, just like Real Programmers and Fortran. The ability to declare a portion of the code as `unsafe' is a feature. It's like `unsafePerformIO' in Haskell! And also no worse than JNI in Java. Do you think that Haskell would be better without `unsafePerformIO'? Static checking and language support for safety are very good things; I've been a supporter of those for a long long time. But to attack C# because it offers *optional* escapes from the language-enforced checking is obtuse. This is not to say that C# doesn't have any serious problems. It does. Number one is that it's a proprietry language controlled by Microsoft, with no implementations on non-Windows platforms. Also the lack of parametric polymorphism makes it much weaker than languages like Sather and Eiffel which have been around for many years, not to mention Pizza and Generic Java. This has lead C# to copy some of Java's other flaws, such as the awful array type. C# has plenty of flaws. Please criticize it for its real flaws, not the imagined ones. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: http://www.cs.mu.oz.au/~fjh | -- the last words of T. S. Garp.

On Mon, 27 Nov 2000, Frank Atanassow wrote:

...

Java. Do you think that Haskell would be better without `unsafePerformIO'?

Without remarking on C#, I just wanted to point out that unsafePerformIO is not part of the Haskell language...

Umm, I hope that everyone in the implementors camps feels unsafePerformIO is a de facto (if not de jure) part of the haskell libraries. I use it an awful lot, and ironically not to do `imperative' type things but rather to deal with the case where files on disk, etc, are static over the entire program lifetime, so that their value can unambiguously be taken to be their contents, etc. In some ways it's aesthetically annoying that the same function name is used for both situations where IO isn't strictly ordered and you don't care if this means you get different file contents depending on when the read happens to occur, and when a file is essentially a `raw string CAF that happens to be on disk rather than compiled in'. ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm|tweed's law: however many computers email: tweed@cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish.

On 27-Nov-2000, Adrian Hey wrote:

On Mon 27 Nov, Fergus Henderson wrote:

...

Do you think that Haskell would be better without `unsafePerformIO'?

Well, a sceptic like me is bound to wonder why such a non-function is provided in a purely functional language. What really worries me is that the damage isn't localised. If you allow such things you can never be sure that any function really is a function, without careful scrutiny of all the code it's dependent on.

This is an issue, but it arises in any "pure" language with a foreign language interface. I think what would be nice to have is a notion of "trust". Only "trusted" people can use unsafePerformIO -- of course as the application developer you can decide who you trust and who you don't trust. It would be possible to use public key crypto to handle trust (if you were worried enough to bother). Then you only have to scrutinze uses of unsafePerformIO that you don't trust. We have been thinking of adding some support for "safety", "purity" and "trust" to Mercury for a while, but haven't quite hammered out exactly what these concepts mean and how they interact (or even whether it is all worthwhile). The general idea is that you could trust :- promise pure declarations (which are similar to unsafePerformIO). There are other :- promise declarations too. To use a :- promise declaration you would have to trust the author. -- Tyson Dowd # # Surreal humour isn't everyone's cup of fur. trd@cs.mu.oz.au # http://www.cs.mu.oz.au/~trd #

On 27-Nov-2000, Nick Kallen wrote:

...

To use a :- promise declaration you would have to trust the author.

It seems like you'd also have to trust the author to write bug-free code too...

I think this is the point. You have to trust them to write pure interfaces. Generally this will involve them writing bug-free code. This is the level of trust you usually give to compiler and library writers. But if people start writing foreign language interface stuff all over the place, you might want to start exerting some control over using it unless you are pretty sure it's bug-free (an deliberately written to be pure). -- Tyson Dowd # # Surreal humour isn't everyone's cup of fur. trd@cs.mu.oz.au # http://www.cs.mu.oz.au/~trd #