Hmm, proof that even hindsight doesn't necessarily confer wisdom...
The 1960s-70s fossil fuel reserve estimates came from the energy companies themselves. The reason for the low numbers, at least in the UK, was that they were going to be taxed at a much higher rate if their ROI was going to be over 50+ years instead of 20.
This was picked up on BBC Broadcasting House (radio prog) this morning. I believe the source referred to (IPCC?) says "range between 1.5 and 6 degrees", so a 6 degree rise is the least likely outcome.
Not that lower temperatures are necessarily much better, but The Observer has picked what it sees as the most sensational "option".
It was never intended to be computationally complete [...] The fact that someone tries to come up with a standard that would be widely accepted shows our industry as a maturing one
I agree with your first statement, which is not surprising as I stated it in my first message, but I don't think many will agree that any set of standards, no matter how redundant, inflexible and unmaintainable, represent progress in the industry.
Your views on LISP per se are not particularly relevant, the point is that there are generic programming concepts in multiple XML specs. that can and should have been factored out. XML is not, as you say yourself, an alternative to LISP, but XML with appropriate coherent extensions could well be.
This is nonsense both in theory and in practice - XACML has a grammar, and it isn't XML. The spec's 220 pages describe this grammar - the mere fact that they say things like
The MatchId attribute SHALL specify a function that compares two arguments, returning a result type of boolean.
instead of providing a formal definition such as a BNF can't disguise this.
Now if this spec was part of a coherent and properly factored set of XML standards the job of the implementor would be vastly easier, since implementations of things like expression evaluators would be common and could be shared - easier to learn, write and maintain.
Rather than pretending to people that it's "relatively easy" to implement specs. like XACML using standard XML tools, a more useful contribution would be showing how useable Scheme, Haskell or other language semantics can be mapped to XML (if required), so helping rationalize the situation.
You appear to be under the same impression as AC above, that this is a debate about conciseness. It's actually about coherence.
The fact that XACML invents most of a full programming language, as does XSLT, JSP ad nauseam results in massive duplication and hence confusion, lost productivity, efficiency and flexibility.
You are welcome to express your logic in XML syntax, just don't invent a different syntax, grammar and feature set for each "application".
Fair comment. I'm kind of hopeful about the current Scheme implementations becoming useful, particularly for implementing the kind of mini-languages as discussed here, but Allegro CL etc. would be great for application-building.
Sure, I don't have a big problem with XML being used to express data. The problem with XACML and its ilk is that people are trying to use XML to express logic, maths, control etc. just like a real programming language. Worse, the way they do this is usually partial and specific to every Tom, Dick and Harry XML "vocabulary".
I meant not specific to the programming language(s) with which the construct is being consumed.
Well, you are simply shifting the problem from the programming language to the other, "language-independent" language. In reality, there's no reason to privilege one language over another arbitrarily, and certainly not to mandate the use of multiple, highly redundant languages.
"middle ground", "vocabulary" and "ontology" [...] actually mean quite a bit to some of us. If you've ever found yourself in the middle of a situation in which integration between a few complex systems is involved, all from different vendors, you would find reasons to overlook XML's warts.
Passing over the obvious question regarding the decisions never to address XML's admitted warts but always to effectively compound them, you refer again to the XML programming model and its supposed advantages.
Once again, I have to point out that the relevant language, the one actually expressing the information we are interested in, is not defined by (constrained by) the XML specification but by higher-level specifications such as XACML. Any appeal to productivity, efficiency etc. must therefore show how XML tools help manage XACML semantics specifically, in comparison to standard language processing tools such as YACC.
Any transformation from XACML using standard XML tools cannot, by definition, improve on a representation of the underlying concrete syntax of XACML, since they know nothing about it.
Similarly, any appeal to authority regarding the acceptance of XML is no more relevant than the acceptance of ASCII. Naturally this doesn't stop every new language ("vocabulary") being described as "standard XML", but such descriptions are wholly misleading.
(lambda (x) (* 2 x))
I think thats a slightly different use case than XACML is addressing. XACML is about asserting policies. No one is trying to do mathematical calculations in it.
You appear not to have read the specification. Section A 14 describes the logical, arithmetic and other functions of XACML in some detail. It looks as though someone has invested considerable effort in deciding how 2x should be expressed in this "Access Control Markup Language".
Of course it doesn't necessarily know what to do from there -- because that's domain specific knowledge
Only if you consider such general things as variables and operators to be domain-specific.
"General APIs" are probably not a useful concept here. It's possible to view DOM (but not SAX) as an AST, but this just serves to show how limited the grammar of XML is in relation to a conventional language.
I'm sure you're one of those people who insists on doing their configuration through a language specific construct, such as using eval() in Perl.
Not sure I follow you - what kind of construct would not be language-specific?
XML provides a middle ground for these languages.
"middle ground", "vocabulary" and "ontology" are certainly the kind of phrases you see in conjunction with XML. Unfortunately they mean very little.
every programming or scripting language has several means of reading XML.
No doubt. And probably a means of reading CSV files too. If you are implying by this that the ability to read XML structures is a significant contribution to the generation or interpretation of such languages as XACML then I think we'd have to disagree.
XML here is a simple "wrapper" or syntax abstraction for the concrete syntax underlying XACML (or whatever). By itself, does nothing to constrain or interpret the latter.
To take a simple example (from a guy called Philip Wadler, who has this on a T shirt)
1. Start with a mathematical function, say 2x
2. Now represent it in a convenient programming language, say Scheme: (lambda (x) (* 2 x))
3. But in XML, the syntax has to be explicitly flagged in frequently gruesome detail: <abstraction> <var>x</var> <expression> <appl ication> <const>*</const><arguments> <const>2</c onst> <var>x</var> </arguments> </application> </expression> </abstraction>
For any non-trivial language, XML is just baggage, it doesn't add anything useful.
Yeah, that doesn't surprise me at all, I'm sure you're right in your diagnosis that a somewhat higher-level language - Perl - can be more productive, and occasionally more efficient, than Java+XML.
I don't think there is a mainstream attempt to unify languages like Java, XML, XSLT etc. However, there is probably a consensus that the best starting point is Scheme, the LISP-like teaching language. This starts from the basic principle that programs-are-data, meaning that Scheme can happily substitute for both Java and XML. This has led people to provide mappings between XML, XSLT etc. and Scheme.
More interestingly, there are some usable Scheme implementations around now, so it's a good time to play with it if you have some time. Grab, say, DrScheme and/or SISC (Scheme on top of Java) and go through the famous Structure and Interpretation of Computer Programs book - I found it very enlightening and not too dry, despite some reviews to the contrary.
One of the beauties of XML is so many different language bindings exist.
That XML is a lingua franca is frequently asserted but can't be proved. The reason is that XML has no (or more strictly, very limited) semantics.
To say that your application can "understand" XML because it can use the DOM API doesn't mean that it can interpret XACML, or any other XML "ontology". You might just as well argue that you can understand Danish because you can parse the "å" character.
All you are saying when you assert that XML applications can be written in any language is that the semantics of XACML (or whatever) can be mapped to various programming languages.
This feature is shared by any machine-readable language, many of which are arguably better at representing XACML semantics than XML.
Like so many other "XML-based" standards, XACML is horribly constrained by the lack of general logical or procedural primitives in XML. As we all know, XML is not a programming language - it was never intended to be computationally complete - yet there seem to be a neverending stream of attempts that effectively try to turn it into one.
It is a fundamental mistake to try to shoehorn semantics which will generally include logic - such as an access control decision - into a language which has no support for them. While XACML "is not intended to form the basis of an authorization decision by itself" it must of necessity include the means to combine and modify rules - hence requiring logical operators which of course have no standard representation in XML.
The specific result is that each attempt to use XML for anything other than the simplest semantics (SOAP, Schema, XSLT, JSP...) must invent its own representations of operators, variables, modules and so forth.
The general result is one unholy mess. We, the poor bloody coding infantry, have to face learning a dozen or more ways of representing the same fundamental concept in a multitude of languages, each supposedly specialized for a narrowly-defined task, but in reality incorporating almost-but-not-quite-all the features of a general purpose language. XML's ugly syntax becomes the least of our problems - that can always be hidden by visual tools or 'generators', but no tool is likely to be able to reunite fundamental concepts fragmented into so many different representations.
Standards such as these do not represent progress, they represent a growing mass of redundancy that one day will have to be refactored into more coherent form. Anyone who studied LISP, or some other language capable of representing the popular data and programming paradigms (logic, procedural, declarative...) will be aware that common ways of representing such semantics have been known for decades. The fact that the practice of XML continues to ignore such basic prior art is an extraordinary indictment of the state of our industry today.
I welcome any explanation from the individuals or organizations concerned as to what obliged them to make yet another idiosyncratic elaboration of the generally incoherent and unusable body of XML specifications.
I doubt if the above bluster on security is going to enlighten many people.
You appear to be arguing that type safety is not a security feature, or not a "runtime" security feature (when are class loaders used?).
Whatever. There are a bunch of features in Java intended to ensure the integrity of the application and its data. Call them what you please, the fact is that the general requirement, and a general VM, must allow for them.
It is complete nonsense to suggest that secure applications can be built with 'runtime safety'. Access controls are not applied based only on what the code is, but on who is using the code. Similarly for auditing, non-repudiation etc.
>Regarding static and dynamic typing, it is a mistake to assume that the use of both models must or should imply separate languages.
You have trouble understanding the difference between "no more than two" and "exactly two"?
Unfortunately, I can only read what was written, not what you wish you'd written shortly afterwards. You say "you only need two languages", which most people will interpret as "at least two".
>For your reference, the original intent that LISP be an intermediate language is described here [uni-erlangen.de].
I think that paper must be going way over your head if you think that it has anything to do with CLR/JVM-style intermediate languages.
Perhaps. But then the notion of a LISP-style intermediate language was apparently news to you, so I venture to suggest that the notion of this intermediate language being directly interpreted by the VM may be news to you too. It's this IL that one manipulates in typical CLOS MOP implementations, or in the MetaJ Java interpreter.
>I take it that you don't use SQL or XML?
Like about so many things, you are wrong in this regard, too.
Nope, I'm simply reading your posts less selectively than you are. You have a record of generally promoting C Sharp and the CLR over Java, and, intentionally or not, leading people up the Dotnet garden path. Now that the patent issue has come home to roost, I trust we can look forward to 'guidance' that's less biased than the following?
It's pretty clear at this point that Microsoft holds no patents on core C#/CLR technology, and we can presume that they designed C#/CLR to avoid running afoul of any Sun patents. Whatever patents Microsoft may hold are at best tangential. Overall, that leaves us with a significantly better situation for C#/CLR than Java/JVM: with Java/JVM, we have to trust Sun's promises, with C#/CLR, we don't have to trust anybody.
My recollection is that real Mono implementers like Miguel de Icaza never engaged in the debate as far as to call anybody crazy. Mostly they went on their way oblivious. Last time I criticized Miguel on this point, he replied to the effect that 'that's what they said about Linux at first'. Draw your own conclusions!
Well, I may have overestimated the potential for convergence:-)
I think you misunderstood. I used to be a "Java fan" and am responsible for its adoption by several companies.
I see.
But Sun has demonstrated bad faith and incompetence when it comes to Java over the last half dozen years: not only has Sun patented key aspects of Java, they have also pulled out of several standardization efforts, and they have failed to deliver essential technologies and enhancements that they promised.
But it seems that Dotnet is the lesser of two evils after all, and people following your earlier advice to embrace C Sharp are now the ones who have cause to worry.
Sun, in contrast, have continuously opened up the specs, tools and standardization processes over the last year, as OSS developers are happy to acknowledge. Yes, they still retain patents, so in deciding who is the lesser evil one has to compare MS's record with Sun's. Two points in Sun's favour are that they've allowed the Kaffe and JBoss people access to the JVM and J2EE test suites (previously licensed) and that IBM, BEA and a bunch of other implementors are apparently happy to continue investing in Java (TM) and working with Sun.
I find it rather ironic that Swing, the GUI that Java-baiters love to hate, is now elevated to a must-have API. It seems that when it is present people demand an alternative; when it isn't, AWT and SWT are somehow no longer acceptable.
There is still some hope for C#: the Mono project is actually increasingly relying on non-.NET APIs
So you're saying that the less hope there is for Mono cloning Dotnet, the more hope there is for C Sharp? I trust that those who are still following youradvice can keep this principle clearly in mind.
And so to the collaborative development of a new programming language, which appears to have got off to a rather rocky start:
1. Java-style byte codes are an awful representation for manipulating programs.
Quite right, and one reason why we're not talking about Java, but about an alternative to Java.
2. Programs can manipulate persistent data directly rather than mapping it to and from storage systems.
Well, not in Java, and not in anything with a Java runtime.
You're really not paying attention are you? Java isn't relevant here, something like SQL might be.
3. Commercial workflow has nothing to do with operating system processes or threads.
From whose perspective? Not from mine, if I'm programming logic using BEA WebLogic Workshop. This allows me to express my program as a sequence of steps that can be distributed over a number of machines, persisted, paused and resumed, managed and interrupted.
The goal of high-level programming systems is to abstract and automate - abstract away from system details such as workflow to thread mapping and automate processes such as memory management.
4. I have no idea whose "original intent" for LISP that is supposed to have been.
Indeed? My view is that the history of LISP is highly relevant to modern language design. As several people have observed, all language developments tend to converge towards something like CLOS. For your reference, the original intent that LISP be an intermediate language is described here.
I think multi-language support is vastly overrated. [...] I do think a platform should support mixing high-performance statically typed code and convenient dynamically typed code, but for that, you only need two languages (java/bsh, C/Tcl, C++/Python, etc.).
I take it that you don't use SQL or XML?
I agree that Dotnet-style "multilanguage" support is overrated, but that's a limitation of the CLR, not the principle.
Regarding static and dynamic typing, it is a mistake to assume that the use of both models must or should imply separate languages. This paper, and implementations such as Strongtalk (on Smalltalk) and typed modules (on Scheme) show the benefits of unifying the approaches, which are after all nothing more than (partial) program verification techniques.
4. I don't want security features in my day-to-day language: they are complex and costly.
Obviously your requirements are somewhat different from typical corporate IT systems. That's perfectly OK, we will keep this in mind when evaluating any future recommendations.
Java is not a particularly well-engineered platform because many of its tradeoffs were driven by one environment (platform-independent, untrusted client software) and make no sense for a general-purpose language.
On the contrary, a VM must be able to deal with untrusted code as well as trusted, otherwise it wouldn't be general-purpose.
The Java VM supports different levels of trust, allowing code from different sources to coexist. What's more, it can do so efficiently, since the JIT allows things like access checks that are always true to be optimized out - something impossible in the purely compiled languages you seem to be advocating.
And C# has copied most of those bad tradeoffs.
Well, it missed the opportunity to innovate, we can agree there.
Perhaps it's good that both Java and C# are removing themselves from the space of open, free languages: it might be best to start over with a simpler, better engineered system anyway.
Good, glad to see that our thinking on this has, er, converged. Not that you're quite with us Java fans yet, I trust you've seen NZHeretic's post?
What I wanted to say was that I'm with you on the importance of creating an alternative VM.
That there are real opportunities, in both technical and "political" terms, is perhaps surprising. Some technical ones are:
1. A language with source / "bytecode" equivalence. Code is distributed in a form that it can be manipulated and further developed in. This eliminates the use/development barrier, smooths the development tool chain and helps foster open source practices. Eclipse, for example, would like to treat Java like this but it can't quite get there.
2. Persistent data. Programs can manipulate persistent data directly rather than mapping it to and from storage systems.
3. Global processes. Processes and threads become shareable and potentially persistent, merging workflow capabilities into the basic language. (Workflow systems are everywhere, if not workflow packages).
4. Multilanguage support can be added, but without conflicting with (1). There must still be one universal, intermediate language - an extended every which way Scheme, say - but more convenient user languages resembling SQL, Java, VB etc. can be used to map to this. Actually this was the original intent of LISP circa 1963...
5. Secure by design (TM) of course. And not just by stopping buffer overruns. Java now has a good set of controls, but features from J2EE such as isCallerInRole() need to be made intrinsic to the system.
No doubt there are plenty of other things that could be added neatly at the outset instead of grafted on via APIs as with Java/Dotnet. And the work of other OSS implementors in the LISP, Perl and Java groups can be leveraged to avoid starting from scratch.
Why should OSS and Linux make do with inferior clones?
Slashdot Mirror
Hmm, proof that even hindsight doesn't necessarily confer wisdom...
The 1960s-70s fossil fuel reserve estimates came from the energy companies themselves. The reason for the low numbers, at least in the UK, was that they were going to be taxed at a much higher rate if their ROI was going to be over 50+ years instead of 20.
Greenpeace UK do not object to offshore wind farms - see this press release welcoming a November govt announcement.
This was picked up on BBC Broadcasting House (radio prog) this morning. I believe the source referred to (IPCC?) says "range between 1.5 and 6 degrees", so a 6 degree rise is the least likely outcome.
Not that lower temperatures are necessarily much better, but The Observer has picked what it sees as the most sensational "option".
It was never intended to be computationally complete [...] The fact that someone tries to come up with a standard that would be widely accepted shows our industry as a maturing one
I agree with your first statement, which is not surprising as I stated it in my first message, but I don't think many will agree that any set of standards, no matter how redundant, inflexible and unmaintainable, represent progress in the industry.
Your views on LISP per se are not particularly relevant, the point is that there are generic programming concepts in multiple XML specs. that can and should have been factored out. XML is not, as you say yourself, an alternative to LISP, but XML with appropriate coherent extensions could well be.
This is nonsense both in theory and in practice - XACML has a grammar, and it isn't XML. The spec's 220 pages describe this grammar - the mere fact that they say things like
The MatchId attribute SHALL specify a function that compares two arguments, returning a result type of boolean.
instead of providing a formal definition such as a BNF can't disguise this.
Now if this spec was part of a coherent and properly factored set of XML standards the job of the implementor would be vastly easier, since implementations of things like expression evaluators would be common and could be shared - easier to learn, write and maintain.
Rather than pretending to people that it's "relatively easy" to implement specs. like XACML using standard XML tools, a more useful contribution would be showing how useable Scheme, Haskell or other language semantics can be mapped to XML (if required), so helping rationalize the situation.
You appear to be under the same impression as AC above, that this is a debate about conciseness. It's actually about coherence.
The fact that XACML invents most of a full programming language, as does XSLT, JSP ad nauseam results in massive duplication and hence confusion, lost productivity, efficiency and flexibility.
You are welcome to express your logic in XML syntax, just don't invent a different syntax, grammar and feature set for each "application".
Fair comment. I'm kind of hopeful about the current Scheme implementations becoming useful, particularly for implementing the kind of mini-languages as discussed here, but Allegro CL etc. would be great for application-building.
it basically looks to me like just a collection of schemas
It isn't. Take a look at the appendix, you'll find 30-40 pages on data types, expressions, operators etc. - deja vu all over again.
Sure, I don't have a big problem with XML being used to express data. The problem with XACML and its ilk is that people are trying to use XML to express logic, maths, control etc. just like a real programming language. Worse, the way they do this is usually partial and specific to every Tom, Dick and Harry XML "vocabulary".
I meant not specific to the programming language(s) with which the construct is being consumed.
Well, you are simply shifting the problem from the programming language to the other, "language-independent" language. In reality, there's no reason to privilege one language over another arbitrarily, and certainly not to mandate the use of multiple, highly redundant languages.
"middle ground", "vocabulary" and "ontology" [...] actually mean quite a bit to some of us. If you've ever found yourself in the middle of a situation in which integration between a few complex systems is involved, all from different vendors, you would find reasons to overlook XML's warts.
Passing over the obvious question regarding the decisions never to address XML's admitted warts but always to effectively compound them, you refer again to the XML programming model and its supposed advantages.
Once again, I have to point out that the relevant language, the one actually expressing the information we are interested in, is not defined by (constrained by) the XML specification but by higher-level specifications such as XACML. Any appeal to productivity, efficiency etc. must therefore show how XML tools help manage XACML semantics specifically, in comparison to standard language processing tools such as YACC.
Any transformation from XACML using standard XML tools cannot, by definition, improve on a representation of the underlying concrete syntax of XACML, since they know nothing about it.
Similarly, any appeal to authority regarding the acceptance of XML is no more relevant than the acceptance of ASCII. Naturally this doesn't stop every new language ("vocabulary") being described as "standard XML", but such descriptions are wholly misleading.
(lambda (x) (* 2 x))
I think thats a slightly different use case than XACML is addressing. XACML is about asserting policies. No one is trying to do mathematical calculations in it.
You appear not to have read the specification. Section A 14 describes the logical, arithmetic and other functions of XACML in some detail. It looks as though someone has invested considerable effort in deciding how 2x should be expressed in this "Access Control Markup Language".
Of course it doesn't necessarily know what to do from there -- because that's domain specific knowledge
Only if you consider such general things as variables and operators to be domain-specific.
"General APIs" are probably not a useful concept here. It's possible to view DOM (but not SAX) as an AST, but this just serves to show how limited the grammar of XML is in relation to a conventional language.
I'm sure you're one of those people who insists on doing their configuration through a language specific construct, such as using eval() in Perl.
l ication>c onst>
Not sure I follow you - what kind of construct would not be language-specific?
XML provides a middle ground for these languages.
"middle ground", "vocabulary" and "ontology" are certainly the kind of phrases you see in conjunction with XML. Unfortunately they mean very little.
every programming or scripting language has several means of reading XML.
No doubt. And probably a means of reading CSV files too. If you are implying by this that the ability to read XML structures is a significant contribution to the generation or interpretation of such languages as XACML then I think we'd have to disagree.
XML here is a simple "wrapper" or syntax abstraction for the concrete syntax underlying XACML (or whatever). By itself, does nothing to constrain or interpret the latter.
To take a simple example (from a guy called Philip Wadler, who has this on a T shirt)
1. Start with a mathematical function, say 2x
2. Now represent it in a convenient programming language, say Scheme: (lambda (x) (* 2 x))
3. But in XML, the syntax has to be explicitly flagged in frequently gruesome detail:
<abstraction>
<var>x</var>
<expression>
<app
<const>*</const><arguments>
<const>2</
<var>x</var>
</arguments>
</application>
</expression>
</abstraction>
For any non-trivial language, XML is just baggage, it doesn't add anything useful.
"it" referring to XML, or to XACML?
Presumably a heterogenous environment wouldn't be an entirely Java environment?
If so, I think I am obliged to learn both.
Java is a good high-level language.
Are you sure?
Then why do the access control rules need to be specified in another language (XACML)?
And why can't users work with Java code?
This sounds so general because it is very general
So why not use a general-purpose language rather than inventing your own?
Yeah, that doesn't surprise me at all, I'm sure you're right in your diagnosis that a somewhat higher-level language - Perl - can be more productive, and occasionally more efficient, than Java+XML.
I don't think there is a mainstream attempt to unify languages like Java, XML, XSLT etc. However, there is probably a consensus that the best starting point is Scheme, the LISP-like teaching language. This starts from the basic principle that programs-are-data, meaning that Scheme can happily substitute for both Java and XML. This has led people to provide mappings between XML, XSLT etc. and Scheme.
More interestingly, there are some usable Scheme implementations around now, so it's a good time to play with it if you have some time. Grab, say, DrScheme and/or SISC (Scheme on top of Java) and go through the famous Structure and Interpretation of Computer Programs book - I found it very enlightening and not too dry, despite some reviews to the contrary.
Pointers are on the Schemers site.
Er, yes it is. Perhaps you meant to say " proof is not the plural of anecdote"?
One of the beauties of XML is so many different language bindings exist.
That XML is a lingua franca is frequently asserted but can't be proved. The reason is that XML has no (or more strictly, very limited) semantics.
To say that your application can "understand" XML because it can use the DOM API doesn't mean that it can interpret XACML, or any other XML "ontology". You might just as well argue that you can understand Danish because you can parse the "å" character.
All you are saying when you assert that XML applications can be written in any language is that the semantics of XACML (or whatever) can be mapped to various programming languages.
This feature is shared by any machine-readable language, many of which are arguably better at representing XACML semantics than XML.
Like so many other "XML-based" standards, XACML is horribly constrained by the lack of general logical or procedural primitives in XML. As we all know, XML is not a programming language - it was never intended to be computationally complete - yet there seem to be a neverending stream of attempts that effectively try to turn it into one.
It is a fundamental mistake to try to shoehorn semantics which will generally include logic - such as an access control decision - into a language which has no support for them. While XACML "is not intended to form the basis of an authorization decision by itself" it must of necessity include the means to combine and modify rules - hence requiring logical operators which of course have no standard representation in XML.
The specific result is that each attempt to use XML for anything other than the simplest semantics (SOAP, Schema, XSLT, JSP...) must invent its own representations of operators, variables, modules and so forth.
The general result is one unholy mess. We, the poor bloody coding infantry, have to face learning a dozen or more ways of representing the same fundamental concept in a multitude of languages, each supposedly specialized for a narrowly-defined task, but in reality incorporating almost-but-not-quite-all the features of a general purpose language. XML's ugly syntax becomes the least of our problems - that can always be hidden by visual tools or 'generators', but no tool is likely to be able to reunite fundamental concepts fragmented into so many different representations.
Standards such as these do not represent progress, they represent a growing mass of redundancy that one day will have to be refactored into more coherent form. Anyone who studied LISP, or some other language capable of representing the popular data and programming paradigms (logic, procedural, declarative...) will be aware that common ways of representing such semantics have been known for decades. The fact that the practice of XML continues to ignore such basic prior art is an extraordinary indictment of the state of our industry today.
I welcome any explanation from the individuals or organizations concerned as to what obliged them to make yet another idiosyncratic elaboration of the generally incoherent and unusable body of XML specifications.
I doubt if the above bluster on security is going to enlighten many people.
You appear to be arguing that type safety is not a security feature, or not a "runtime" security feature (when are class loaders used?).
Whatever. There are a bunch of features in Java intended to ensure the integrity of the application and its data. Call them what you please, the fact is that the general requirement, and a general VM, must allow for them.
It is complete nonsense to suggest that secure applications can be built with 'runtime safety'. Access controls are not applied based only on what the code is, but on who is using the code. Similarly for auditing, non-repudiation etc.
>Regarding static and dynamic typing, it is a mistake to assume that the use of both models must or should imply separate languages.
You have trouble understanding the difference between "no more than two" and "exactly two"?
Unfortunately, I can only read what was written, not what you wish you'd written shortly afterwards. You say "you only need two languages", which most people will interpret as "at least two".
>For your reference, the original intent that LISP be an intermediate language is described here [uni-erlangen.de].
I think that paper must be going way over your head if you think that it has anything to do with CLR/JVM-style intermediate languages.
Perhaps. But then the notion of a LISP-style intermediate language was apparently news to you, so I venture to suggest that the notion of this intermediate language being directly interpreted by the VM may be news to you too. It's this IL that one manipulates in typical CLOS MOP implementations, or in the MetaJ Java interpreter.
>I take it that you don't use SQL or XML?
Like about so many things, you are wrong in this regard, too.
That was the point.
Nope, I'm simply reading your posts less selectively than you are. You have a record of generally promoting C Sharp and the CLR over Java, and, intentionally or not, leading people up the Dotnet garden path. Now that the patent issue has come home to roost, I trust we can look forward to 'guidance' that's less biased than the following?
It's pretty clear at this point that Microsoft holds no patents on core C#/CLR technology, and we can presume that they designed C#/CLR to avoid running afoul of any Sun patents. Whatever patents Microsoft may hold are at best tangential. Overall, that leaves us with a significantly better situation for C#/CLR than Java/JVM: with Java/JVM, we have to trust Sun's promises, with C#/CLR, we don't have to trust anybody.
My recollection is that real Mono implementers like Miguel de Icaza never engaged in the debate as far as to call anybody crazy. Mostly they went on their way oblivious. Last time I criticized Miguel on this point, he replied to the effect that 'that's what they said about Linux at first'. Draw your own conclusions!
That should read Kaffe and Parrot, got my Java developments confused...
Well, I may have overestimated the potential for convergence :-)
I think you misunderstood. I used to be a "Java fan" and am responsible for its adoption by several companies.
I see.
But Sun has demonstrated bad faith and incompetence when it comes to Java over the last half dozen years: not only has Sun patented key aspects of Java, they have also pulled out of several standardization efforts, and they have failed to deliver essential technologies and enhancements that they promised.
But it seems that Dotnet is the lesser of two evils after all, and people following your earlier advice to embrace C Sharp are now the ones who have cause to worry.
Sun, in contrast, have continuously opened up the specs, tools and standardization processes over the last year, as OSS developers are happy to acknowledge. Yes, they still retain patents, so in deciding who is the lesser evil one has to compare MS's record with Sun's. Two points in Sun's favour are that they've allowed the Kaffe and JBoss people access to the JVM and J2EE test suites (previously licensed) and that IBM, BEA and a bunch of other implementors are apparently happy to continue investing in Java (TM) and working with Sun.
I find it rather ironic that Swing, the GUI that Java-baiters love to hate, is now elevated to a must-have API. It seems that when it is present people demand an alternative; when it isn't, AWT and SWT are somehow no longer acceptable.
There is still some hope for C#: the Mono project is actually increasingly relying on non-.NET APIs
So you're saying that the less hope there is for Mono cloning Dotnet, the more hope there is for C Sharp? I trust that those who are still following your advice can keep this principle clearly in mind.
And so to the collaborative development of a new programming language, which appears to have got off to a rather rocky start:
1. Java-style byte codes are an awful representation for manipulating programs.
Quite right, and one reason why we're not talking about Java, but about an alternative to Java.
2. Programs can manipulate persistent data directly rather than mapping it to and from storage systems.
Well, not in Java, and not in anything with a Java runtime.
You're really not paying attention are you? Java isn't relevant here, something like SQL might be.
3. Commercial workflow has nothing to do with operating system processes or threads.
From whose perspective? Not from mine, if I'm programming logic using BEA WebLogic Workshop. This allows me to express my program as a sequence of steps that can be distributed over a number of machines, persisted, paused and resumed, managed and interrupted.
The goal of high-level programming systems is to abstract and automate - abstract away from system details such as workflow to thread mapping and automate processes such as memory management.
4. I have no idea whose "original intent" for LISP that is supposed to have been.
Indeed? My view is that the history of LISP is highly relevant to modern language design. As several people have observed, all language developments tend to converge towards something like CLOS. For your reference, the original intent that LISP be an intermediate language is described here.
I think multi-language support is vastly overrated. [...] I do think a platform should support mixing high-performance statically typed code and convenient dynamically typed code, but for that, you only need two languages (java/bsh, C/Tcl, C++/Python, etc.).
I take it that you don't use SQL or XML?
I agree that Dotnet-style "multilanguage" support is overrated, but that's a limitation of the CLR, not the principle.
Regarding static and dynamic typing, it is a mistake to assume that the use of both models must or should imply separate languages. This paper, and implementations such as Strongtalk (on Smalltalk) and typed modules (on Scheme) show the benefits of unifying the approaches, which are after all nothing more than (partial) program verification techniques.
4. I don't want security features in my day-to-day language: they are complex and costly.
Obviously your requirements are somewhat different from typical corporate IT systems. That's perfectly OK, we will keep this in mind when evaluating any future recommendations.
Java is not a particularly well-engineered platform because many of its tradeoffs were driven by one environment (platform-independent, untrusted client software) and make no sense for a general-purpose language.
On the contrary, a VM must be able to deal with untrusted code as well as trusted, otherwise it wouldn't be general-purpose.
The Java VM supports different levels of trust, allowing code from different sources to coexist. What's more, it can do so efficiently, since the JIT allows things like access checks that are always true to be optimized out - something impossible in the purely compiled languages you seem to be advocating.
And C# has copied most of those bad tradeoffs.
Well, it missed the opportunity to innovate, we can agree there.
Perhaps it's good that both Java and C# are removing themselves from the space of open, free languages: it might be best to start over with a simpler, better engineered system anyway.
Absolutely.
Good, glad to see that our thinking on this has, er, converged. Not that you're quite with us Java fans yet, I trust you've seen NZHeretic's post?
What I wanted to say was that I'm with you on the importance of creating an alternative VM.
That there are real opportunities, in both technical and "political" terms, is perhaps surprising. Some technical ones are:
1. A language with source / "bytecode" equivalence. Code is distributed in a form that it can be manipulated and further developed in. This eliminates the use/development barrier, smooths the development tool chain and helps foster open source practices. Eclipse, for example, would like to treat Java like this but it can't quite get there.
2. Persistent data. Programs can manipulate persistent data directly rather than mapping it to and from storage systems.
3. Global processes. Processes and threads become shareable and potentially persistent, merging workflow capabilities into the basic language. (Workflow systems are everywhere, if not workflow packages).
4. Multilanguage support can be added, but without conflicting with (1). There must still be one universal, intermediate language - an extended every which way Scheme, say - but more convenient user languages resembling SQL, Java, VB etc. can be used to map to this. Actually this was the original intent of LISP circa 1963...
5. Secure by design (TM) of course. And not just by stopping buffer overruns. Java now has a good set of controls, but features from J2EE such as isCallerInRole() need to be made intrinsic to the system.
No doubt there are plenty of other things that could be added neatly at the outset instead of grafted on via APIs as with Java/Dotnet. And the work of other OSS implementors in the LISP, Perl and Java groups can be leveraged to avoid starting from scratch.
Why should OSS and Linux make do with inferior clones?