For example, DUP would exist in two different wordlists. One version would handle interpretation semantics and the other would handle compilation semantics. Colon simply changes the search order.

I've seen embedded Forths (not supporting vocabularies) that work like this. Maybe there would be two search orders and they get selected by : and ;. Has this been tried?

Why stop at two search orders? One could create a user defined search order FOO that sets up the search order (and word to handle numbers) when executed.

That other bit, the number handler, would be NOOP when interpreting, LITERAL when compiling, etc.

: parse" ( -- addr len )
    '"' parse ;

: (p") ( -- buff )                        
    parse" buf-allot dup>r place r> ;

: ", ( a1 n1 -- ) \ compile a1,n1 at here (counted)
    here over 2+ allot place ;  

: s" ( -<string">- -- a1 n1 )
    (p") count   \ interpret action
    compilation> \ compile action
      drop parse" postpone sliteral ;

: ," ( -<string">-  ) \ compile counted parsed string at here
    parse" ",
    compilation>
      drop postpone s" postpone ", ;

MFX is proprietary to Testra, but last I heard they gave it away for
free (it isn't good for anything except developing for the MiniForth
processor, which you have to buy from them).

There was a good SIGFORTH article by Jay Melvin about the cmforth
metacompiler, which is shockingly simple (unfortunately this is just a
citation, fulltext is walled):

  http://dl.acm.org/citation.cfm?id=382125.382916

Please keep the line length to about 70 chars.

When compiling, the compile-only dictionary was searched first, and if
nothing was found, the normal dictionary would then be searched.

It didn't have actual ANS wordlists though.

A few builds were done with a third dictionary, but as far as I recall
no one actually used this and it was dropped.

Let'd say you have a word FOO that has compilation and execution
forms.  If you redefine FOO you have to redefine the compiling FOO as
well or when you use FOO in a colon definition you'll get the old
behaviour.  Very bug-prone.  There are other ways of achieving the
effect you need, most of 'em better.

I remember that I was very much baffled by how to write a cross-
compiler. I had written a 65c02 cross-compiler previously, but it
wasn't very good. My defining words had different names, such as |:
and |CREATE and so forth, to distinguish them from the UR/Forth
defining words. That was ugly and awkward. This would not be
acceptable at Testra, and I would have gotten fired if I did that.

When I wrote MFX, I assumed that other people knew how to write cross-
compilers. I didn't bother to do any research on what other people
have done, because I always figure things out for myself. Still
though, I assumed that other people did know how to write cross-
compilers. Now, in these last 3 years that I've been visiting
comp.lang.forth, I have discovered that nobody knows how to write a
cross-compiler. There is a lot of talk about how easy it is, but
nobody actually knows how. In this thread we have both Anton Ertl and
Andrew Haley who clearly don't know how to do it. We have Stephen Pelc
saying that it is necessary to simulate the target processor at
compile-time in order to make the defining words work. He said that in
this thread:
http://groups.google.com/group/comp.lang.forth/browse_thread/thread/c...

A couple of days ago Brad Eckert promoted John Passaniti to sainthood
because he says that it is not necessary to write code, but only to
talk about code. He said that in this thread:
http://groups.google.com/group/comp.lang.forth/browse_thread/thread/3...
This is what he said:

On Oct 2, 9:43 am, Brad Eckert <hwfw...@gmail.com> wrote:

As a software engineer, writing code is one major aspect of what I do.  I'd say on an average day at work, I'm probably spending 75% of my time writing code.  The rest of the time, I'm also charged with a variety of other responsibilities, from analysis, design, managing projects, measuring progress, and so on.  Those are typically not skills that a person with a strict "programmer" title has to deal with, but they are essential.

You don't recognize this because you don't actually work as a programmer and you don't work in a group larger than yourself.  You aren't responsible for products.  You aren't responsible for developing standards.  You aren't responsible for coordinating efforts of other programmers.  You aren't responsible for schedules.  You aren't responsible for research.  You aren't responsible for meeting compliance requirements.  You aren't responsible for finding ways to make the process of developing software better.

The closest you've ever come to an understanding of any of these things is when you actually worked as a programmer in the distant past.  Too bad it didn't work out for you; if it had, you would have probably learned that restricting yourself to just programming and not diving deeper into the many other issues that come up in software development is limiting not only your career, but your experience.

I think we're also seeing why you never made it as a programmer.  Your definition of being a programmer doesn't include any of the skills beyond programming that are needed to actually build, maintain, and sustain systems.  Why would anyone want to hire someone with such a limited view of what their job is ("I just write code and don't worry about that other stuff").  By restricting yourself to just writing code and avoiding the larger issues in software development, you've effectively put a big sign on your head saying, "I do only one thing, don't hire me if you want anything more or deeper."

90% of "purely" programming jobs have very little programming, maybe 25%.
Most include every non-programming task needed to complete the job at hand.
These are things such as meetings with your department or other departments,
interacting with users, making phones calls to a variety of people, program
design, program implementation, obtaining design and legal requirements,
complying with legal or industry specifications, producing and printing
documentation, getting coffee for higher ups, spending time discussing
fantasy football with your manager because he knows nothing about
programming nor management, being "required" to go to "social" events with
co-workers on your time off, and even helping "the boss" move because his
alcohol abuse caused him to get divorced and is so messed up emotionally he
can't function, etc.

Programmers are usually the "low man" in department.  They get handed
everything no one else wants to do.  That's true even if it's the job other
people.

Many programmers want to just program.  They don't want to handle the "BS"
of non-programming business and corporate political issues.  Why would they?
They aren't "people" people.  They're "idea" people like scientists,
chemists, and engineers.  It's outside the scope of the job they have, or de
sire.  It's like asking an electrical engineer (EE) to patch drywall.  It's
rarely done.  When it is, it's the manager who gets reprimanded and demoted,
or should be ...  The engineers are not there to patch drywall.  It's not
their skillset.  It's not what they're being paid for either.  They're being
paid far more than a drywall installer or building maintenance.

Your resume seems to indicate you haven't worked for any large companies
either.  Most seem to have fewer than 65 employees.

Some companies, of course, have a lot more hardware design, development,
and debugging to do than those who are using only off-the-shelf
hardware. But even in the latter class you'll see a lot of variation in
how much involvement the "programmer" has in program requirements,
design, etc., in addition to writing and testing code.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

In my experience, team programming doesn't work unless the team
members are given distinct jobs. For example, at Testra I wrote MFX
the development system for the MiniForth, and the other employee used
MFX to write the motion-control program (actually, port it over from
his old 80c320 program). I never actually saw the motion-control
program's source-code (because John Hart didn't trust me not to steal
it and start my own company selling motion-control boards). There was
some overlap in regard to low-level stuff. For example, I was supposed
to write the 16-bit integer addition but I didn't know how and kept
putting it off, so the other guy wrote it. Similarly, some of what I
wrote was actually low-level aspects of the motion-control program,
which I accomplished without knowing anything about motion-control.
For the most part though, giving programmers distinct domains to work
in is the best way to go --- that way they don't step on each other's
feet.

When I was working as an IBM370 assembly-language programmer, I
sometimes had a CSR (customer-service rep) between me and the
customer, and sometimes I had to be my own CSR. I definitely preferred
to have a CSR --- those customers were all liars and cheaters --- I
didn't want to deal with that. I did the CSR thing when necessary ---
that was actually pretty similar to cab driving except that I never
got to beat anybody up.

As to your division of university colleges, how does that make a
difference? See again the job advert; "A Bachelor of Science Degree in
Electrical Engineering or Computer Science, a Master Degree, or a
PhD". Doesn't say anything about "LSA".

It says a Computer Science degree is one of the degrees accepted for the
job.  That's an LSA degree.  It's not an engineering degree.  Someone with a
CS, cannot validly claim to be an engineer.  It may be illegal too.  As for
an MD or PHD, it depends on the degree.  Can they all do the job?  Probably,
but only one is formally trained in programming.

Chuck Moore does not have either a CS or SE degree. As I recall, his
degree is in Physics or Math from MIT. The best practicing application
programmer I know does not have a bachelor's degree in anything, but he
regularly debugs custom hardware that's been sent to him to program, by
reading the schematics and running tests, and writes absolutely
exquisite Forth.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

You have a talent for taking what people write, ignoring the reasonable interpretation, and going straight for the most ridiculous interpretation possible.  Are you this amazingly tedious in real life?  If someone tells you, "I spent all day working on this problem" is your response, "that is clearly factually incorrect, the day is 24 hours long, and you slept during part of that."  Duh.

What is being discussed here is that the common job title of "programmer" describes someone who spends most of their time (unsurprisingly) writing code.  My point-- and one you don't seem to substantially disagree with-- is that software development is a (much) larger set of activities than just coding.

Hugh dismisses this.  The only reasonable interpretation of what Hugh has written on the subject is that anything beyond the act of banging on the keyboard and looking at a flashing cursor is stupid and/or unnecessary work.  And that might actually be true.  If the programming work you've done is generating slide rules with your name on them for future post-apocalyptic generations to cherish, maybe spending time thinking about design and structure isn't necessary.  Or say you want to inefficiently manage a symbol table based on a faulty and untested premise-- no need think about measuring your assumptions and proving your work has value over simpler solutions.  But for the rest of us who aren't paid to slap out ad hoc solutions, things are a bit different.

Hugh's statements demonstrate that he is nothing more than the traditional definition of a programmer.  And again, that's fine-- if that's what he likes and that's what he's good at, then all the more power to him.  But just because he doesn't recognize the value of analysis, design, testing, maintenance, project management, and dozens of other related activities doesn't mean they don't have value.

Part of the problem here is that what experience Hugh has seems stuck somewhere in the 80's.  Take for example the word "design".  In the 80's, the majority of software developers followed some flavor of a waterfall methodology and "design" usually meant a discrete phase that occurred prior to any coding.  Now, the only people following that kind of methodology are those who enjoy seeing projects fail (or those who must do so because of other external factors).  In modern software development (pretty much everything since the mid 90's), the "design" phase is more typically incremental, spread out over the course of the project on smaller sections of the project.  Any up-front design is usually limited to setting up the general architecture, patterns, and practices the rest of the development will follow.  It's usually high-level stuff to keep a project on track, consistent, comprehensible, and maintainable.

Hugh doesn't understand this because he's stuck in time.  When I say a word like "design" he's using a 80's sense of the word and thinks I'm talking about what the agilists call "Big Design Up Front."  He's wrong of course, but he doesn't know that.  Because he relishes in being just a programmer, he's not even aware that things have changed in the past 25ish years.

My guess as to the origins of "software engineer" is that companies were searching for a term that meant "more than just a programmer".  They noted the increased scope of roles and responsibilities engineers in other disciplines had and wanted to convey that in the job title.  For example, most engineers in other disciplines are equally concerned with requirements, analysis, process, methodologies, measurement, maintenance, and so on.  It isn't surprising that employers seeking candidates who saw value in these things would reuse the word "engineer" in the job title.

You of course are free to ignore this and claim that the job title of "software engineer" is invalid for one of your typically tedious reasons.  But what you aren't free to ignore is that regardless of the job title, the role and responsibility of someone hired as a "software engineer" is typically larger than "programmer".

If you want to use terms like "programmer analyst" to describe me and others like me, feel free.  Our employers tend to use more modern terms that better reflect that we aren't just programmers, and aren't just analysts.  Maybe terms like "programmer analyst" and "systems analyst" are still in common use in some industries, but I haven't seen that in embedded systems for years.  Indeed, when we start talking about my actul job, it also includes quite a lot of stuff on the hardware side; I'm also responsible for designing and implementing digital logic in our systems.  

So let me turn this around; what should my job title be in Rod's perfect and universe?  I don't _just_ do programming, I don't _just_ do analysis, I don't _just_ do design, I don't _just_ do the other software activities I've listed (like managing projects and people).  And on top of that, I don't _just_ do software.  What ultra-precise Rod-world job title captures that?  Please let me know because I need to order new business cards (there are a lot of fishbowls in local restaurants offering free lunches).

More likely his reaction is on the defensive because of the
continually sarcastic, acidic tone of your missives, John?

You get back what you give. In your case, I don't think I've seen a
post from you where you exhibit any kind of tact, empathy, or
sympathy. You're clearly a clever guy. It must have occured to you
that, you know, gee, perhaps phrasing your responses in a more tactful
tone might illicit a better response, and draw that person in, towards
you, into a position where they could learn from you?

Instead, your constant combative tone puts people on the defensive.
And like I said, it's very clear that you are a clever and talented
guy. And that makes it all the more sad. Why? Because you clearly
weighed up the options and decided to go on the attack; not just with
Hugh but others too, me included in the past. It suited your
(presumably) shallow ego to go on the attack, to belittle, to
ridicule, rather than extend a friendly comment: "Hey, that Symtab
looks cool, but I'm not sure this application could benefit from that
particular algorithm. You might want to take a look at this: <web
link>. Let us know how you get on."

Sure, he could have thrown it in your face. But at least you tried to
help. I can't really think of any occasion where you've posted a
critique that was intended to help in any way. You know, to extend
some kind of common courtesy, compassion, or just a willingness to
help. You're modus-operandi is quite clear to all here. You never post
any Forth code, you lurk, waiting for a particular type of
conversation/thread to appear. You prefer the very general, high-
level, high-brow discussions on the merits of a particular programming
language or paradigm. Why? Because that's when JP gets his chance to
shine. That's when the great JP can leap up the steps into the JP
Programming Pulpit, and lecture down to his lowly CLF peons about how
they're so stupid to claim that language x is better than language y.
Hark how the mighty JP shall clense his flock with the holy water from
the JP Font of all Knowledge. And lo, thy lowly flock shall repent.
Duly cleansed and corrected.

It's very sad. I read your post above in response to Rod regarding the
attribution of titles to programmers/software engineers, and agreed
with pretty much every word you said. But the tone was once again (why
should we be surprised) the classic JP that we've all come, well,
dread, quite frankly.