SpyderTL wrote:That depends. Do you already know x86 Assembly?
Let me put it another way. Which is easier to understand?
or
Code: Select all
<cpu:CopySIAddressToAXAndIncrementSI/>
Why not just write an assembler where the instruction is called CopySIAddressToAXAndIncrementSI instead of lodsb? They have to learn XML, and learn assembly.
So they can see descriptive name of the instruction - they still need to learn assembly. Registers, stacks, the control flow of assembly programs.
When working in a new language, you can pick up working knowledge of the syntax fairly quickly, but most of your time trying to do something useful will be spent figuring out how the standard library works. An IDE that lets you see the symbols/procedures/types exported by another file is useful for this.
The same IDE that references the Intel manual when you hover your mouse over an instruction would be a much more useful tool, than say, forcing them to type and remember 30+ characters (case sensitive and all) for something that only requires 5.
It's not that it's a bad idea, if you're goal is an XML-based language, and you have an IDE that closes tags, autocompletes long and verbose names, to the fact that on my keyboard I can type:
And it auto-generates:
Code: Select all
<cpu:Move>[enter]
[tab]<Source>[enter]
[tab][tab]<Cpu:MemoryAddress>[enter]
[tab][tab][tab]<Cpu:Register>ax</Cpu:Register>[enter]
[tab][tab]</Cpu:MemoryAddress>[enter]
[tab]</Source>[enter]
[tab]<Destination>[enter]
[tab][tab]<Cpu:Register>bx</Cpu:Register>[enter]
[tab]</Destination>[enter]
</cpu:Move>[enter]
12 keystrokes vs 189 keystrokes (or 241 if you count the 52 times I had to press the shift key.)
s-expression:
21 keystrokes (or 25 if you count the 4 times I pressed shift.)
Also, you need to think about for code compactness? It's much easy to comprehend code when you can see as much of it as possible on screen (without being overly messy). In many companies, this:
Code: Select all
switch (item_hit) {
case "coin": points += 1; break;
case "enemy": points += 10; show_message("You hit " + item.name + "!"); break;
case "teammate": points -= 10; show_message("You hit your own teammate!"); break;
case "flag": capture_flag(); break;
}
is considered 'better practice' than this:
Code: Select all
switch (item_hit)
{
case "coin":
points += 1;
break;
case "enemy":
points += 10;
show_message("You hit " + item.name + "!");
break;
case "teammate":
points -= 10;
show_message("You hit your own teammate!");
break;
case "flag":
capture_flag();
break;
}
Simply because the former is much more legible - it's easier to read because a) it looks like a table, with the switch statements on the left, code on the right, and b) you can fit much more on your screen - maybe a switch statement with 50 lines of code could fit completely on screen. 100 lines of
neat code is often better than 500 lines of code of the same code with everything on it's own line, since we're able to visualize the shorter code much better - that is, along as it's
not messy. E.g.:
Code: Select all
switch(i){case "c":p+=1;break;case "e":p+=10;m("You hit "+i.n+"!");break;
case "t":p-=10;m("You hit your own teammate!");break;case "f":f();break;}
That definitely isn't legible. You can go extreme in both ways - it's all about finding a happy medium - the unreadable 2 lines, vs the neat 6 line table, or the verbose 17 lines. The verbose version takes up nearly 3 times as much screen space as the neat table. That results in much more scrolling, and much less code you can see at once.
Extreme case, I work with people that love to write:
Code: Select all
SELECT
a.abc abc,
b.def def
MIN
(
a.ghi
)
jkl
FROM
hij a,
lmn b
WHERE
(
a.opq
=
b.rst
)
AND
(
wxy
=
'z'
)
A lot of tools even generate code like that.
I feel that an XML language, while it may help adoption of someone who is familiar with XML and wants to write a small tool, will be very cumbersome for large complex programs, namely because it will be very verbose, taking up maybe 10+ lines (and 20x the keystrokes) for something that may take 1 line in another language.
)
Congratulations, you win the verbosity award!