I would say that at the very highest level (specifically the first paragraph or so), this article has got the right idea. Then it takes a bad idea and runs around like a headless chicken with it.
They talk about the fact that computer programs are represented by 'collections of arbitrary ASCII tokens' as if it is impossible to discern the meaning of the program. Er, that's what parsers are for. They parse 'collections of arbitrary ASCII tokens' into data structures. Incredibly, those data structures look a lot like their XML structure. Except, if one wishes and is clever, you can do fun things with those arbitrary data structures that are hard to do in XML (e.g. turn them into graphs vs. XML's trees). You manipulate the data structure, serialize it into text and save it. And you're done. Simple. Their problem is a non-problem.
There is also a serious lack of understanding of the term 'semantics' in this document. They are *not* representing the programs semantics in XML, they are merely storing its abstract syntax as opposed to its concrete syntax. Giving things a bunch of XML tags does not infer semantics - those semantics are defined and implemented elsewhere.
In my opinion, there are several factors that have held back so-called 'extensible programming'. Here's a couple that spring to mind. Firstly is the sheer awfulness of most parser generators. They're fiddly to use, and accept laughably limited forms of grammars. This dates back to when parsing was a very processor intensive job - these days, however, Earley parses and the like can cope with any grammar you chuck at them in comparable time to e.g. yacc. Secondly, most languages don't have macro languages, and those that do (like C) tend to do it at the token level, which lacks power and is prone to disaster unless the programmer is incredibly careful. Those that operate at the syntax level (basically LISP) work with languages whose syntax is so restricted that it's difficult to generalize to modern languages. However, I feel that Template Haskell provides a solid indication as to how modern languages can incorporate macro powerful and practical systems. And, before anyone dismisses this reccomendation, I'm *not* a functional programming fan - I just think that TH approaches the problem in a way that can be applied to other languages.
> The closest thing I've seen to what this article talks about was CLOS's > MOP, which was great, but once again, a lot of people had a hard time > groking it.
It's not talking about anything like the MOP (Meta Object Protocol). That's all about changing the dynamic behaviour of objects. These guys are talking about fiddling with things at compile time. We can argue about whether they have got hold of the right end of the proverbial stick re: representing program structure, but it's important to note that MOP's are a solution to a different problem.
[There are, admittedly, compile time MOP implementations for e.g. C++, but I'm not aware of any that are used in practical situations.]
MOV's are typically very cheap, stack operations typically aren't. At the risk of generalizing, I'll assert that generally stack based VMs are built with a particular target language in mind, and that register machines aren't. With a register machine you're more likely to be playing by someone elses rules.
IME if you develop and analyse your instruction set carefully, you can often reduce the amount of 'redundant' instructions necessary in a stack based solution. Let me give you a trivial example. In something I'm working on, I removed a couple of pages of instructions (huge amounts of DUP'ing and SWAP'ing amongst them) that were generated to analyse and assign a functions arguments in a dynamic language, and replaced them with a single instruction. Yes, I've bloated the instruction set by doing so. Yes, I increased performance an awful lot, and also made the compiler a *lot* easier to understand at the expense of a very small addition to the VM. Because of the frequency that particular op is called, and the saving involved, that sort of design choice is often where you can make the useful big savings.
In the paper referenced, the claim is that 1 in 4 instructions in a Forth VM is a DUP. That instantly makes me think that either the instruction set is horribly designed, or the compiler was generating massively inefficient code. Possibly both. The possible lesson to be learned from this is that, regardless of whether you have a stack or register based VM, other design decisions are likely to have at least as great an impact on performance.
There's also the possibility to use a hybrid machine that's mostly stack based, but if - for some reason - you find yourself DUP'ing or SWAP'ing a lot, having a few registers knocking around may solve that problem very nicely, without turning the whole thing into a register based machine. i.e. you can bolt it on in a mostly backwards compatible, low effort, fashion if you find you have the need.
Don't confuse modelling and UML
on
UML Fever
·
· Score: 1
Let me start with two obvious points: sometimes people abuse even the best technologies; UML is not the best technology anyone ever invented.
I am confident about this second point for two reasons. Firstly because off and on I have been involved in the UML standardization process [I still attend some of the meetings, although more out of vague interest than active participation since the group I was part of long ago rolled over when several large companies jumped up and down on us] and because it's a view shared by most people involved in that effort. Secondly because I am very active in the modelling community, and some of us have much better technologies than UML available to us. And we can do some very cool things now, trust me - some of this stuff is being used in places that continue to surprise me when I learn of them. Whilst the technology is still developing, it is already classed as industrial strength (although small industrial would probably be accurate at the current time).
Modelling is a Good Thing when used in the right situations. Modelling and UML should not be seen as being synonymous with each other. Modelling doesn't even need diagrams, and it is about far more than class diagrams even if those are involved.
I predict that over the next few years UML will decrease in importance as modelling as a more general concept increases. Of course, UML will still be important, if for no other reason than everyone owns UML books, but different modelling languages will be used when they are appropriate. All hail the new future.
Slashdot Mirror
I would say that at the very highest level (specifically the first paragraph or so), this article has got the right idea. Then it takes a bad idea and runs around like a headless chicken with it.
They talk about the fact that computer programs are represented by 'collections of arbitrary ASCII tokens' as if it is impossible to discern the meaning of the program. Er, that's what parsers are for. They parse 'collections of arbitrary ASCII tokens' into data structures. Incredibly, those data structures look a lot like their XML structure. Except, if one wishes and is clever, you can do fun things with those arbitrary data structures that are hard to do in XML (e.g. turn them into graphs vs. XML's trees). You manipulate the data structure, serialize it into text and save it. And you're done. Simple. Their problem is a non-problem.
There is also a serious lack of understanding of the term 'semantics' in this document. They are *not* representing the programs semantics in XML, they are merely storing its abstract syntax as opposed to its concrete syntax. Giving things a bunch of XML tags does not infer semantics - those semantics are defined and implemented elsewhere.
In my opinion, there are several factors that have held back so-called 'extensible programming'. Here's a couple that spring to mind. Firstly is the sheer awfulness of most parser generators. They're fiddly to use, and accept laughably limited forms of grammars. This dates back to when parsing was a very processor intensive job - these days, however, Earley parses and the like can cope with any grammar you chuck at them in comparable time to e.g. yacc. Secondly, most languages don't have macro languages, and those that do (like C) tend to do it at the token level, which lacks power and is prone to disaster unless the programmer is incredibly careful. Those that operate at the syntax level (basically LISP) work with languages whose syntax is so restricted that it's difficult to generalize to modern languages. However, I feel that Template Haskell provides a solid indication as to how modern languages can incorporate macro powerful and practical systems. And, before anyone dismisses this reccomendation, I'm *not* a functional programming fan - I just think that TH approaches the problem in a way that can be applied to other languages.
> The closest thing I've seen to what this article talks about was CLOS's
> MOP, which was great, but once again, a lot of people had a hard time
> groking it.
It's not talking about anything like the MOP (Meta Object Protocol). That's all about changing the dynamic behaviour of objects. These guys are talking about fiddling with things at compile time. We can argue about whether they have got hold of the right end of the proverbial stick re: representing program structure, but it's important to note that MOP's are a solution to a different problem.
[There are, admittedly, compile time MOP implementations for e.g. C++, but I'm not aware of any that are used in practical situations.]
MOV's are typically very cheap, stack operations typically aren't. At the risk of generalizing, I'll assert that generally stack based VMs are built with a particular target language in mind, and that register machines aren't. With a register machine you're more likely to be playing by someone elses rules.
IME if you develop and analyse your instruction set carefully, you can often reduce the amount of 'redundant' instructions necessary in a stack based solution. Let me give you a trivial example. In something I'm working on, I removed a couple of pages of instructions (huge amounts of DUP'ing and SWAP'ing amongst them) that were generated to analyse and assign a functions arguments in a dynamic language, and replaced them with a single instruction. Yes, I've bloated the instruction set by doing so. Yes, I increased performance an awful lot, and also made the compiler a *lot* easier to understand at the expense of a very small addition to the VM. Because of the frequency that particular op is called, and the saving involved, that sort of design choice is often where you can make the useful big savings.
In the paper referenced, the claim is that 1 in 4 instructions in a Forth VM is a DUP. That instantly makes me think that either the instruction set is horribly designed, or the compiler was generating massively inefficient code. Possibly both. The possible lesson to be learned from this is that, regardless of whether you have a stack or register based VM, other design decisions are likely to have at least as great an impact on performance.
There's also the possibility to use a hybrid machine that's mostly stack based, but if - for some reason - you find yourself DUP'ing or SWAP'ing a lot, having a few registers knocking around may solve that problem very nicely, without turning the whole thing into a register based machine. i.e. you can bolt it on in a mostly backwards compatible, low effort, fashion if you find you have the need.
Let me start with two obvious points: sometimes people abuse even the best technologies; UML is not the best technology anyone ever invented.
I am confident about this second point for two reasons. Firstly because off and on I have been involved in the UML standardization process [I still attend some of the meetings, although more out of vague interest than active participation since the group I was part of long ago rolled over when several large companies jumped up and down on us] and because it's a view shared by most people involved in that effort. Secondly because I am very active in the modelling community, and some of us have much better technologies than UML available to us. And we can do some very cool things now, trust me - some of this stuff is being used in places that continue to surprise me when I learn of them. Whilst the technology is still developing, it is already classed as industrial strength (although small industrial would probably be accurate at the current time).
Modelling is a Good Thing when used in the right situations. Modelling and UML should not be seen as being synonymous with each other. Modelling doesn't even need diagrams, and it is about far more than class diagrams even if those are involved.
I predict that over the next few years UML will decrease in importance as modelling as a more general concept increases. Of course, UML will still be important, if for no other reason than everyone owns UML books, but different modelling languages will be used when they are appropriate. All hail the new future.