Re: HTML & ALL Current Tools are really back to ASSEMBLY [...]

In article <c7g7th$4ej$1 (AT) s0b1a68 (DOT) ssa.gov>, Mel writes:

Take a look at what we are doing ! we create TAGS, things like <H1> etc.
and although there are tools (dreamweaver and the like), they are all at the
lowest level of programming (something like assembly as oposed to C++ etc.).

Hardly. It's pretty obvious that you:
a. Never programmed in assembly language for a living
b. Don't understand what the tags are doing for you.

When somebody writes some HTML, they're doing something that's incredibly
high-level, leaving huge amounts of implementation details to the user
agent.

For instance, when you put (to use your example):
<H1>Moose Bites versus Llama Bites</h1>
you're doing both of the following:
1. You're indicating that the page in question compares moose and
llama bites. This enables computers in a different part of the
country to be aware that you have information available to them
on that subject.
2. You're indicating to the user agent that the words "Moose Bites
versus Llama Bites" are very important, and should be presented
to the user in such a way that the user will know that these are
a high-level description of the contents of your page.

You do all of this in a completely platform-independent manner. That's
a lot of bang for very few bytes.

These tools create "brain-dead" developers that constantly have to plough
through tons of tags to do the simplest thing.

Well, no, it doesn't take "tons of tags" to do simple things. It took
two tags: <H1> and </H1> to do all of the above.

Let me make my point by example: if i want to create a page with "say" a tab
notebook inside it.

Well, now you're moving the goal-posts. You're changing from a very simple
thing to wanting a very specific presentation style. Doing the simple thing
is simple. Making it look different takes more work. That should be taken
as self-evident, since you need to now tell the user agent what you'd
like it to do differently.

Notebook (arg1,arg2,...)
rather than some mumbo/jumbo using table & div tags

Well, if somebody provided a macro like this, that would be just fine,
as long as the people using it wanted the presentation that it defined.
If they wanted the presentation, then they'd still need to do more work
to define how they'd like the presentation changed. The "problem" hasn't
been eliminated.

Languages do not solve our problems, they may actually add to them (Java's
and the like). I have nothing against Java per say, but remember we placed
MAN-ON-THE-MOON with assembly language and PDB computers.

Now, you sound as if you're sticking up for assembly language, when before
you were asking why we haven't advanced beyond it. I'm confused.

Of course, it's true that having higher-level languages doesn't allow
us to solve any new problems (in theory), it just makes them easier to
solve. So what? I don't miss writing in assembly language one bit. It
was pretty studly to be able to use a debugger to search through core
for a particular string of bytes and be able to say, "my program's
executing at address 3FC8", but I really do have better things to do.

--
Michael F. Stemper
#include <Standard_Disclaimer>
There is three erors in this sentence.

Michael Stemper wrote:

In article <c7g7th$4ej$1 (AT) s0b1a68 (DOT) ssa.gov>, Mel writes:

Take a look at what we are doing ! we create TAGS, things like <H1
etc. and although there are tools (dreamweaver and the like), they
are all at the lowest level of programming (something like assembly
as oposed to C++ etc.).

Hardly. It's pretty obvious that you:
a. Never programmed in assembly language for a living
b. Don't understand what the tags are doing for you.

When somebody writes some HTML, they're doing something that's
incredibly high-level, leaving huge amounts of implementation details
to the user agent.
[snip]

I'll speak as someone who *has* programmed in assembly language for a living.
(And lots of other languages. And, where necessary, invented my own
languages).

My target is that, at some time in the future, perhaps within 5 years, my HTML
code & CSS code should be "untouched by human hands" when published. And
preferably "unseen by human eyes" when published. And that both the CSS &
strict-(X)HTML will validate at W3C, and work well.

There is no merit in know the abstract syntax of HTML or CSS. (All those
pointy-brackets & curly-brackets, the specific names of the tags, attributes,
properties, values, upper/lower case, single/double quotes, etc). That is what
software should do. Not people.

People should be able to focus in a higher-level of abstraction. I would still
expect to know, in 5 years time, unfortunately, the *elements* within a
document tree, and, somehow, the principles of the CSS specification. But the
idea that someone needs to know that it is "color" not "colour", and that #090
is a sort of darkish-green colour, is just plain silly! Use a colour-picker
for that.

Even that is low level! Unfortunately, no page-layout language even appears to
be on the horizon. We may be stuck with this low level of abstraction for the
next decade. But it would be better than using pointy or curly brackets!
Elements matter, not tags. "Table", not <table ...>...</table>. "Image", not
<img ...>.

I use Dreamweaver. It gives some pointers to possible future directions. For
example, in Standard Mode, Design View, you still handle the elements. You
have to say "insert an image", "make this a header 1", etc. But you don't need
to know what the corresponding HTML looks like. Dreamweaver understands the
correspondence between yout requirement and the code. Or you can say "add
another column here", and let DW put in all the necessary <td>...</td>s. Or
"render this as style "species"", and DW will ensure that you get <span
class="species">...</span>.

This is higher than assembler. Much of it is in visual terms. But lower than a
true page-development & site-development language, where perhaps it should be
possible to have a dialogue about what a site navigation region should look &
act like. Fortunately, Dreamweaver extensions are filling some of the gaps. It
is getting near the stage where it is possible to have a sensible dialogue
about what the navigation menu should look like, and how it should behave, and
have the extension generate suitable HTML, CSS, and JS, that works
cross-browser.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

Michael Stemper wrote:

In article <c7g7th$4ej$1 (AT) s0b1a68 (DOT) ssa.gov>, Mel writes:


Take a look at what we are doing ! we create TAGS, things like <H1> etc.
and although there are tools (dreamweaver and the like), they are all at the
lowest level of programming (something like assembly as oposed to C++ etc.).


Hardly. It's pretty obvious that you:
a. Never programmed in assembly language for a living
b. Don't understand what the tags are doing for you.

When somebody writes some HTML, they're doing something that's incredibly
high-level, leaving huge amounts of implementation details to the user
agent.

For instance, when you put (to use your example):
H1>Moose Bites versus Llama Bites</h1
you're doing both of the following:
1. You're indicating that the page in question compares moose and
llama bites. This enables computers in a different part of the
country to be aware that you have information available to them
on that subject.
2. You're indicating to the user agent that the words "Moose Bites
versus Llama Bites" are very important, and should be presented
to the user in such a way that the user will know that these are
a high-level description of the contents of your page.

You do all of this in a completely platform-independent manner. That's
a lot of bang for very few bytes.

Bravo! And have you seen XUL? <button> and the like is so much easier
than, say, the Windows API in which you have to call a function with,
IIRC, eleven parameters, process messages (WM_COMMAND, WM_PAINT, etc),
keep track of handles, processes, device contexts, etc, ... Definitely
not a step backwards.

I have nothing against Java per say, but remember we placed
MAN-ON-THE-MOON with assembly language and PDB computers.


Now, you sound as if you're sticking up for assembly language, when before
you were asking why we haven't advanced beyond it.

And he misspelled per se.